How To:

Reserved Instance Management & Best Practices Webinar

Today I hosted a webinar alongside my colleague Ciaran Fitzgerald and Zac Stevens, Co-Founder of Elastera. The focus was on Reserved Instance Management and Best Practices.

We covered the following topics:

  • What RI’s are and how they are applied
  • What the “payback period” is and how savings are realised
  • Planning and modeling an RI Quote
  • Ongoing management and monitoring for maximum ROI
  • Overall Best Practices

If you benefit from the webinar or have any questions, please leave a comment below!

twittergoogle_pluslinkedin

Push Notifications for Chrome on OSX at Last! (Update)

Update: Warning, Do Not Enable!
For the moment, please do not enable this flag as it will crash your browser upon relaunch. The only way in then is to delete the profile or, remove the flag from the Local State file.

If you have already enabled this and Version 52.0.2743.116 (64-bit) broke it, you can use the following steps to get your browser with all of your settings back in order:

  1. Navigate to ~/Library/Application Support/Google/Chrome/Local State

  2. Open the file and remove “browser”:{“enabled_labs_experiments”:[“enable-native-notifications”],“last_redirect_origin”:””}, the underlined text.
  3. Save the file and you should now be able to open Chrome.

Has this affected anyone else? Please post so in the comments below.

***

Chrome and OSX notifications will finally play nicely together. When you turn on “Do Not Disturb” mode on your Mac, you will no longer receive popup notifications from new e-mail on Gmail for example. For those who often share their screen on remote meetings, this is priceless.

While the feature is not yet Generally Available, you can easily enable it by entering this into Chrome: “chrome://flags/#enable-native-notifications” and then clicking enable. Then relaunch your Chrome browser.

Your notifications will now all funnel through the OSX Notification Center. Enjoy!

twittergoogle_pluslinkedin

Modeling RDS Reservations

rds-modeling-blog-image[originally posted on https://www.cloudhealthtech.com/blog/modeling-rds-reservations]

In a previous blog series, I discussed the basics of EC2 Reserved Instances, the importance of purchasing them, and how to maximize your return on investment. If you are using Amazon’s Relational Database Service (RDS) to operate and scale a relational database such as MySQL or Oracle in the cloud, it’s highly advisable that you purchase reserved instances. Not only will you minimize your costs, but you also guarantee your ability to launch RDS instances when you need them. If AWS runs out of available RDS instances in a specific region, those with reserved instances have guaranteed capacity while the ones running On-Demand do not.

What is RDS?

Amazon RDS makes it easy to configure, run, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity while managing time-consuming database administration tasks that save your team precious time. With Amazon RDS you can choose from six different database engines, including Amazon Aurora, Oracle, Microsoft SQL Server, PostgreSQL, MySQL, and MariaDB.

Currently the average user spends about 6% of their total AWS bill on RDS. It has become a critical building block for cloud applications. Surprisingly, however, even though RDS reserved instances can save 60%+ on the compute costs of operating an RDS instance, on average only 14% of RDS instances actually run under a reservation.

Why Reserve? (Pricing)

Not unlike EC2 Reservations, RDS Reserved Instances can be purchased for either a 1-year or 3-year term. This results in a significant discount (somewhere between 20-60%) compared to the On-Demand Instance hourly pricing. In addition, it has the added perk of guaranteeing your ability to launch the instances you reserved when you need them.

You can choose between three payment options when you purchase a Reserved Instance:

  • All Upfront
    • Pay for the entire term with one upfront payment.
    • Receive up to a 63% discount off of On-Demand pricing.
    • The payback period is typically around 9 months.
  • Partial Upfront
    • Pay a low upfront payment and receive a discounted hourly rate for the instance for the duration of the Reserved Instance term.
    • Receive up to a 60% discount off of On-Demand pricing.
    • The payback period is typically between 5 and 7 months.
  • No Upfront
    • Pay nothing upfront.
    • Pay only a discounted hourly rate for the duration of the term. Savings are typically around 30% off of On-Demand pricing.
    • The payback period is immediate.

 

All Reserved Instance types are available for Aurora, MySQL, PostgreSQL, Oracle, and SQL Server (except for SQL Server as the license is included) database engines.

How Do I Know What I Should Reserve?

Step 1: What’s my usage?

Analyze your On-Demand usage by choosing a time period such as the previous month, week or even day. You should look to reserve the running instances in a time period that is most reflective of the usage you expect in the future. For more static environments I recommend a longer period of time.

Eliminate any groups or instances that won’t run more than 65% of the time. You can calculate this by the total number of hours the instance ran in a one-month period. See the image below.

Also eliminate any that you don’t expect to be running 6 months from now.

Step 2: Run across multiple Availability Zones?

Your current instance usage will dictate the regions (e.g. us-east-1 or us-west-1) in which you should reserve. However, you’ll still need to decide if you want the reservation to run across multiple Availability Zones (multi-AZ) within a region.

One of the most compelling RDS features is the ability to have a fully managed high availability deployment. But, keep in mind that since multi-AZ support requires an instance running in two different zones, the average compute cost will be doubled.

Step 3: Choose a term: 1-year vs. 3-year?

Most AWS customers gravitate toward the 1-year term for reservations as a hedge against the potential for new instance types being made available during the course of the reservation term. However, since 3-year reservations provide the highest discount rate, think twice before ruling out this option.

Step 4: Evaluate the reservation type – All Upfront, Partial or None?

Sometimes the increased savings you reap from All Upfront reservations are not enough to justify their initial upfront fee. The table below shows how purchasing an All Upfront db.t2.micro reservation will cost $51 more in advance and only offer 2% more in monthly savings. Obviously the number of reservations will affect the dollar amount savings. Just be sure to do the math.

Step 5: In which account should I make a purchase?

If you have more than one account linked to a consolidated bill, you can either purchase in the consolidated account or in each individual linked account.

As reservations can float between linked accounts under a consolidated bill, other accounts can still benefit from the associated discount if a valid instance isn’t running in the purchasing account.

If your goal is to simplify the purchase and management of your reservations and you are indifferent to capacity reservation, you should purchase in your consolidated account. However, if you want to ensure that you’re guaranteed the ability to launch the instances you are reserving whenever you need them, you will want to purchase in each individual linked account.

Final Thoughts

Running relational databases in the cloud? RDS is a simple and cost effective option that takes the database management out of the equation. Utilizing RDS reservations will allow you to take advantage of cost savings that optimize your cloud investment while guaranteeing capacity.

The ability to easily manage RDS usage and reservations and maximize cloud efficiency is at your fingertips with CloudHealth. Try a free 14 day trial to see how you can model, optimize and plan your most cost optimal purchase in seconds.

twittergoogle_pluslinkedin

How To Plan an RI Purchase in 6 Steps

AAEAAQAAAAAAAAOYAAAAJDZkYjUyMjM2LWRiMmEtNDg1YS04ZDJiLTA3Yzk1NzRiYWZiZg

 

[originally posted on LinkedIn Pulse @ http://linkd.in/1H5Kvvr]

Do Reserved Instances make you anxious? They shouldn’t.

A lot of people get caught up in all the different possible reservations you can purchase and wait months before making their first purchase.

Don’t do that.

Below is all you need to start saving money and take advantage of Amazon’s capacity guarantee today.

Step 1: Arrange Your Instances by Their Purpose

How do you group your infrastructure? By project, environment or application? Great. Put them all together and separate by OS and move on to step 2. If you mix Windows and Linux instances, it will complicate the entire process because of licensing and pricing differences.

Step 2: Figure Out the Cost

Once you’ve organized your instances into groups by their purpose, figure out what your current on-demand costs are and arrange your groups in descending order.

Step 3: Find Out Who Makes the Cut

Eliminate any groups or instances that won’t be running more than 65% of the time. Also eliminate any that you don’t expect to be running 1 year from now.

Step 4: Figure Out Where Your Reservations Will Reside

Once you’ve figured out the region (e.g. us-east-1 or us-west-1), you’ll need to specifically choose the availability zone where you currently have the most on-demand usage (e.g. 1a or 1b).

You’ll also have to choose whether they will reside within a VPC or in classic EC2 mode. For most newer customers your infrastructure will most likely already be in a VPC.

Step 5: Decide How Much You’re Going to Give AWS Upfront

Sometimes the increased savings you reap from all upfront reservations are not enough to justify their initial upfront fee. The table below shows how purchasing an all upfront m3.large reservation will cost $308 ($751-$443) more and only offer 2% more in monthly savings. Obviously the number of reservations will affect the dollar amount savings, so make sure to do the math regardless.

Step 6: Determine the Purchasing Account

Do you have more than one account linked to a consolidated bill?

You should:

a)   Purchase in the consolidated account if you don’t care about the capacity reservation. This option simplifies the purchase and management of reservations, but you’re not guaranteed to be able to launch an instance based on a reservation in a linked account if the reservation was made in another account.

b)    Purchase in the linked accounts if you want to receive the cost and capacity reservation of the RI, although the planning process will be significantly more complex. Note: Other accounts can still benefit from the associated discount if a valid instance isn’t running in the purchasing account.

Based on experience, the best advice I can give is to purchase reservations on an account-by-account basis.

Don’t want to spend all this time to model out your purchase? I don’t blame you. I used to do it before we released the RI Optimizer. Have it plan your most cost-optimal purchase in seconds.

twittergoogle_pluslinkedin