Author: Ozzy Brightrose

aws ec2 pricing calculator

What your AWS EC2 pricing calculator doesn’t tell you

Posted on | by Ozzy Brightrose | Leave a Comment on What your AWS EC2 pricing calculator doesn’t tell you

The AWS EC2 pricing calculator is a very handy tool and if you use it properly, it can help you to save a lot of money. Like all tools, however, you need to understand it to use it properly. This means not just understanding what it does do, but understanding what it doesn’t do.

The AWS EC2 pricing calculator just processes the information you enter

The AWS EC2 pricing calculator does your pricing for you, it doesn’t do your thinking for you. In other words, if you tell it you want a certain configuration, it will tell you how much that configuration will cost. It will not tell you whether or not that configuration is a good idea. In particular, it will not tell you whether or not that configuration is sized effectively.

Right-sizing is the key to reducing the cost of EC2

Right-sizing is one of the keys to cost optimization in general and it’s particularly relevant to storage solutions such as EC2. This means that it literally pays to make time out of your busy schedule to keep an eye on your EC2 usage and make sure that it actually does reflect your needs – no less and no more. With that in mind, here is some guidance on how to manage EC2 right-sizing effectively.

Focus on the areas of biggest spend

Even though little savings can add up, bigger savings can add up even more quickly. This means that your priority should usually be the places where you are currently spending the most money.

Ensure that you’re only working on areas which are likely to be stable for the next few months

On similar logic, you also want to focus your efforts on areas which are likely to be stable for the next few months (at least) otherwise all your work could just be wasted when it is changed.

Keep an eye open for areas which are due to change soon

You don’t (usually) want to go through a right-sizing project for these areas as they are now, but you do want to know about any changes which are due to happen as this is an opportunity to ensure that new areas are right-sized from the get-go (and to schedule checks to ensure that they continue to be right-sized as time goes on). 

In particular, you want to give yourself plenty of time to think about what reserved instances you’re going to need, so that predictable work is done at the most economical price and you’re not left crossing your fingers and hoping to get lucky and pick up spot instances to save your budget.

Pay attention to AWS’ instance lifecycle

AWS uses a “carrot-and-stick” approach to getting customers to migrate off instance types it wants to retire and onto new ones it is introducing. It increases the prices of the former and makes the latter more economical by comparison. This means that being prepared to use different instance types can save a whole lot of money. Try to make a point of checking in with the AWS website to keep up to date on what Amazon has planned as this can give you a good hint as to what the pricing trends are likely to be going forward.

Practice good EC2 hygiene

To begin with, make sure that you apply complete and accurate tagging to all your resources. This step can be very easy to miss when you’re busy, but it can make life a lot easier when you want to analyze specific areas of your application environment. 

You might also find it very helpful to define a new gate in your continuous delivery workflow during the staging process to make it easier to confirm your capacity requirements before deploying to production. Ideally, you will also want to install an agent to monitor your memory usage, which can significantly influence any decisions relating to EC2.

Work off exact usage information not guesses

The key point here is that you need to factor in all aspects of your computing resource needs when taking what type of EC2 instance you need and what size it should be. 

Currently, AWS reporting will show you CPU, and I/O utilization for each volume attached to your EC2, plus data on the network usage of each of the network interface cards attached to your EC2. What it doesn’t currently provide is data on memory utilization, hence the advice to install an agent, since the alternative may be to work off educated guesses, which may be better than nothing, but not necessarily a great deal better.

Consider using third-party tools

Accurate data on actual usage will give you a solid basis for working out what kind of resources they will require. In particular, you’ll want to compare using general-purpose EC2 instances with optimized instances. This can be done manually, but if you undertake this exercise regularly, you may find that third-party tools quickly pay for themselves, not just in cost savings but in saving you time, energy and possibly frustration.

Posted in EC2
aws ec2 calculator

What is the AWS EC2 Calculator for?

Posted on | by Ozzy Brightrose | Leave a Comment on What is the AWS EC2 Calculator for?

The AWS EC2 calculator is right at the top of the AWS Simple Monthly Calculator, even above S3. This is probably a good indicator of the popularity of the service. The more you use a service, the more it will contribute to your cloud costs and so the more it pays to understand it. With that in mind, here is a quick guide to the AWS EC2 calculator.

The key factors in the AWS EC2 calculator

The key factors in the AWS EC2 calculator are the region, EC2 instances, EC2 dedicated hosts, EBS Volumes and Elastic Graphics. Other factors include Additional T2/T3 Unlimited vCPU Hours per month, Elastic IP and Data Transfer. Let’s look at the key factors in practice.

The region

These days a lot of companies will choose their region with legal/compliance issues at the top of their list of priorities and after that, it’s highly likely their next concern will be latency (or the lack thereof). In the unlikely event that all things are equal, however, remember that your choice of region can have a huge influence on the cost of any service. This is particularly obvious when it comes to high-volume services such as AWS EC2.

EC2 dedicated hosts

An EC2 dedicated host is basically a cloud server which is dedicated to your sole use. EC2 dedicated hosts can be a great solution for companies which would like to tap into the cost savings of the public cloud but want or need to keep data in a completely private environment.

One of the nice features of AWS EC2 dedicated hosts is that you can essentially automate administrative tasks via AWS. Basically, you specify your licensing rules and attach them to the AMI. Then you specify your dedicated host management preferences. 

From that point on, in principle, you can treat it as “set and forget” although as always, just because you can, it doesn’t mean that you should. Basically, it can be very dangerous (and/or expensive) to forget about anything in IT and so you should make a point of double-checking everything now and again to make sure it’s still an accurate reflection of your situation.

Amazon EBS Volumes

If you’re going to be storing data which needs to be updated regularly, then Amazon EBS Volumes are a good investment. They are particularly to be recommended if you need to hold data for apps which are used by “frontline staff” such as your customer service team. Not to put too fine a point on the matter, it can be an inconvenience if your back-end staff have to wait a bit, but you may lose business if you make your paying customers wait any longer than they believe is reasonable.

Amazon Elastic Graphics

Amazon Elastic Graphics basically gives your graphics a boost. Whether or not it’s relevant to you obviously depends on the extent, if any, to which you use graphics in your applications.

The issue of data transfers

The reason data transfers are listed as one of the “extra” factors, is because they don’t really relate directly to your use of EC2. They relate to your management of your cloud infrastructure as a whole. In particular, they reflect your ability to design apps which send data along the most economical paths. 

For practical purposes, this basically means that you want data to stay in its own availability zone (sub-region) as much as possible and if that is not possible do your level best to keep it within its own region. AWS charges the highest prices for data transfers between AWS regions and between AWS and the internet so you want to avoid these as much as possible.

For the sake of completeness, there is a little nuance here in some applications such as Amazon CloudFront, which sends users to the data center with the lowest latency at that time, but these exceptions can be ignored for now as they do not have any influence on AWS EC2 costs.

To commit or not to commit?

The aforementioned factors are all, essentially, “technical” factors, but there is one final issue which can greatly influence the cost of the AWS EC2 service and that is the pricing model or models you use. The popularity of EC2 means that AWS offers “Savings Plans” for it. Pretty much like their name suggests, Savings Plans offer AWS users discounts on EC2 (and other services) if they commit to a certain level of usage. 

Using Savings Plans can achieve discounts of up to 72% (under current rates) so if you anticipate using the service a lot, you should probably at least investigate them, especially since they do offer some degree of flexibility. Savings Plans can be used in combination with Reserved Instances and Spot Instances so you have even more opportunities for reducing costs.

aws data transfer calculator

How to Use AWS data transfer calculator

Posted on | by Ozzy Brightrose | Leave a Comment on How to Use AWS data transfer calculator

Making the most of your AWS data transfer calculator

A data transfer calculator can be a bit like weighing scales.  You may not want to look at it, but you probably should and you should probably pay attention to what it’s telling you.  Just like with weighing scales, the initial reading only tells part of the story.  If it looks bad (in other words excessive), the reasons probably lie with your behavior – and usually they can be fixed.

What your data transfer calculator is telling you

At a basic level, your data transfer calculator is telling you how much data you transferred between:

AWS and the internet

Different AWS regions

Different AWS availability zones (essentially sub-regions)

Different AWS services

At a deeper level, it’s telling you how good you are at routing your data traffic effectively.

What your data transfer calculator isn’t telling you

There is a bit of a twist to data transfer calculations which is that some services (like AWS Kinesis) incorporate data transfer into the cost of the service.  While this can be convenient, it also obscures the amount of data you are actually using.  Effectively, this means that the only way to keep a lid on these costs is to be really strict about keeping control of your data flows.

The fundamental rules of cost optimization for AWS data transfers

  • Try to keep all data traffic within the same availability zone if at all possible.
  • If that’s not possible, try to keep it within the same region.
  • Minimize the amount of outbound data you send to other regions or the internet.

Point three may look like it is basically an extension of points one and two (and to a certain extent it is), but the basic idea is that you look at traffic routing first and if you reach a situation where you must transfer to another region or the internet, then you do everything possible to keep a lid on how much data you transfer.  Admittedly you should be doing this at all times, but it does take on a whole new level of importance with data transfers between regions and the internet.

(If you can) choose your region with great care

These days, the choice of AWS region is increasingly likely to be determined by the law than by issues of latency and cost.  Assuming you do have a choice, however, then investigate all your options including the non-obvious ones to see which offers the best overall deal.

If you are constrained by legal requirements, then you really need to be on point with regards to managing your data flow and keeping on top of cost optimization, so as to minimize the impact of the extra costs.

Remember Amazon CloudFront

If your issue is data transfers to the internet, rather than to other Amazon regions, then Amazon CloudFront could be well worth a look.  Basically it’s a content delivery network.  It’s free to transfer data from EC2 to Amazon CloudFront.  Charges to transfer data from Amazon CloudFront to the internet do carry a charge and this varies by region. 

On this point, please note, that you cannot select a region for Amazon CloudFront the way you can for most other services.  Basically, your content will be made available from data centers around the world and when a user requests it, they will be directed to the one which offers the lowest latency at that point in time.  This offers the highest level of speed and convenience to the user, but the downside of this is that costs can be unpredictable. 

Having said that, if you know your user base and their habits, you could probably make an educated guess as to what data centers they’re likely to end up using and hence be able to take an educated guess at what your costs are likely to be.

Think about using a private IP address

Amazon charges more for data transfers made using a public IP address, this includes Elastic IP addresses.  If you can make a point of using private IPs as much as you possibly can, you can really make a difference to your data transfer costs.

Experiment with Amazon pricing tools

Amazon is currently in the process of replacing its Simple Monthly Calculator with a new tool called the AWS Pricing Calculator.  At this point in time, it’s unclear when it will launch (it’s currently in Beta testing) or what, exactly, it will offer.  Based on its website, however, it looks like it’s going to offer a whole lot more flexibility and transparency than the current Simple Monthly Calculator.  Having said that, the Simple Monthly Calculator is still a whole lot better than nothing and can certainly be looked at in the meantime.

Stay on top of pricing changes

The information given in this article is correct for December 2019.  Obviously, AWS pricing can and does change.  Make a point of keeping track of these changes so you can take early action if you need to.

AWS lambda calculator

Understanding the AWS Lambda calculator

Posted on | by Ozzy Brightrose

AWS Lambda Calculator

The AWS Lambda calculator is probably going to become very relevant to you if your company moves to the AWS cloud service. Here is a quick guide to what it is and how it works.

What is AWS Lambda Calculator Anyway?

In the context of AWS, Lambda is a service that allows you to run your code on demand without the need to provision servers. At the current time, Lambda can scale (automatically) from a few requests per day to thousands per second. Given the popularity of the service, it’s entirely possible that it will be developed further so it can scale even higher in the future.

One of the nice features of AWS Lambda is that you just choose the amount of memory you want for any given function and are automatically allocated a proportionate level of CPU power. If you scale the memory up or down, then the CPU power increases or decreases in tandem with it.

AWS Lambda can already run code for many of the major computing languages. These include C#, Go, Java, Javascript (via Node.js), Python and Ruby. Again, its range may be extended in the future, but even now, its offering is probably more than enough for many businesses.

Understanding the AWS Lambda calculator

The bad news is that the AWS Lambda calculator is basic, to put it mildly. In fact, you could reasonably question whether or not it deserves to be classed as a pricing calculator at all, given that it amounts to a drop-down menu of regions plus a list of what they charge per total number of requests and per time block. You then have to do the actual sums yourself, presumably on a proper calculator.

There are two pieces of good news for the mathematically challenged. Firstly, the calculations are so simple; they really can be done with just a basic calculator, even a cellphone calculator. Secondly, if you really want an online calculator, then there are plenty of third-party options available.

Whichever option you choose, you’ll probably find it helpful to understand the basics of AWS Lambda pricing.

Understanding AWS Lambda pricing

The whole point of AWS Lambda pricing is that you literally only pay for what you use. Admittedly, this is often highlighted as a benefit of cloud computing in general, but AWS Lambda takes it to a whole new level. With “traditional” cloud computing, you typically fire up a virtual server, add whatever resources you need, do whatever you need to do and then shut it all back down again.

At least, that’s the theory. As anyone involved in real-world cloud computing will know, in reality, what often happens is that someone spins up the servers and then forgets to shut them down again, or shuts down some of the resources and forgets about the others (like the storage). That is literally impossible with AWS Lambda. It’s either on (in use) or off (out of use). There is no “in-between” or idling and its pricing reflects this.

AWS Lambda pricing depends on region, requests and duration

AWS pricing, in general, is usually dependent on the region, so there’s nothing new there. Requests and duration are what you need to understand, along with the slight twist of “provision concurrency”.

For the sake of completeness, you should also be aware that standard AWS charges will also apply to your usage of AWS Lambda. For example, if you need to transfer data from another region, then the transfer will be charged at the standard EC2 data transfer rates. Likewise, if your functions access S3, then you will be charged the standard fees for the read/write requests (and the data stored in S3).

AWS Lambda requests

In the context of AWS Lambda, a request is simply an instruction to start executing code. This is typically made in the form of an event notification or an invoke call.

AWS Lambda duration

Duration is exactly what its name suggests. You start being billed from the moment your code starts executing and you continue being billed until the moment it terminates (or returns). This is rounded up to the nearest 100ms. The key point to note about duration in AWS Lambda is that the price per time block depends on the amount of memory you allocate to the function. It, therefore, pays to write economic code.

AWS Lambda provisioned concurrency

You can think of provisioned concurrency as a turbo-charge for your Lambda functions. Provisioned concurrency fees are similar to duration fees in that they are based on the amount of memory you allocate to the function and the amount of concurrency that you configure on it.

The big difference is that provisional concurrency fee are rounded up to the nearest five minutes. If your function exceeds the configured concurrency, then you will revert to being billed at the standard rate.

cloud migration cost estimate

How to Create a Realistic Cloud Migration Cost Estimate

Posted on | by Ozzy Brightrose | Leave a Comment on How to Create a Realistic Cloud Migration Cost Estimate

Creating a realistic cloud migration cost estimate is essential for keeping your IT budget on track.  Get it right and you’ll get your cloud migration journey off to a great start.  Get it wrong and your finance team could wind up losing sleep over how to balance their books and your colleagues might not be thrilled about seeing “non-essentials” being pulled out of their budgets to compensate for your mistake.

Fortunately, it is possible to create a realistic cloud migration cost estimate.  Here are some tips to  help.

Remember that a cloud migration cost estimate is only as good as the underlying data

This general principle holds true of any estimate, but it’s so important, it’s worth emphasizing.  Basically the difference between an “estimate” and a guess is the amount of research which goes into coming up with the figures.  In theory, overestimating costs can appear less risky than underestimating them but this is actually a debatable point, because it could lead you to avoid taking an action which would actually have saved you money.

It’s a good idea to start by comparing running costs and then move on to cloud migration costs

On the principle of “trust but verify”, it’s generally a good idea to start by checking that a cloud migration would actually reduce costs for you (or result in some other benefit which would justify the increased cost).  While this is likely to be true the vast majority of the time, there may be the occasional exception and there may also be the occasional time when it might be more sensible to delay a cloud implementation.  For example, if you’re planning an office move anyway, you might just want to live with what you have for now and then move everything at once.

When calculating the cost of running your current IT infrastructure, do your best to include indirect costs (such as lost revenue caused by downtime) as well as direct costs (basically anything related to hardware, software and network connectivity, including the costs of the humans involved in keeping them running).  This relates back to the first point.  You need to do everything possible to gather full and accurate data.

On that note, you should be aware that the likes of the AWS price calculator and the Azure TCO calculator are sales tools rather than finance tools, so it’s a good idea to double-check any assumptions they make and see how they apply to you.

Estimating cloud migration costs

Assuming that you’re happy you could save money (or gain some other benefit) be using cloud services, you can then move on to calculating the costs of the actual migration itself.  These are not factored into the pricing calculators offered by the main cloud services so the onus is on you to figure them out for yourself.  While many of the points you need to cover will be fairly obvious, especially if you’re doing a lift-and-shift migration, here are three points you might overlook.

You will probably need to keep data synchronized during the transition period

Even in a lift-and-shift migration, you do not just press a button and have everything transfer over.  Unless you can do your entire cloud migration out of hours, you are probably going to need to keep the data live in your legacy systems until you are ready to “flick the switch” and turn them off and when you do turn them off, you’re going to have to ensure that the data in your new cloud systems is an absolutely exact match of the data in your old systems.  This means that you probably want to budget for skilled labor to make this happen.

Your apps will need to be thoroughly tested before you switch off your legacy systems

Thanks to virtual machines and containers, you can run just about any app on cloud infrastructure.  You may, however, have to make adjustments to them to make them run properly.  What this means in practice is that your intended lift-and-shift migration might turn into a refactoring migration (where you make some adjustments to apps before you migrate them) and/or might require some urgent development work to make legacy apps run in the cloud at all.  Basically, always budget plenty of time and money for thorough testing.

Hiring consultants can make life a lot easier for everyone

It’s highly unlikely that people who provide in-house IT services are going to be specialists in cloud migrations.  Even if they’ve done one (or more) before, perhaps in previous roles, they’re just not going to have the same sort of skill, experience and general competence which comes with regular practice.  Hiring consultants can, therefore, be money well spent.  Not only can they make your life easier, they can stop you from making costly mistakes and guide you towards getting the best value from your cloud migration.

hybrid cloud pros and cons

Hybrid Cloud Pros and Cons

Posted on | by Ozzy Brightrose | Leave a Comment on Hybrid Cloud Pros and Cons

Hybrid Cloud Pros and Cons

Here is a quick guide to hybrid cloud pros and cons for anyone who might be considering implementing a hybrid cloud in 2020.

A brief guide to hybrid clouds

Hybrid clouds mix together elements of private clouds and public clouds.  For completeness, a private cloud is simply a cloud which is used by one tenant.  It may be hosted on-premises or it may be hosted offsite by a third-party provider, but it is only used by one, specific client.  A public cloud, by contrast, is shared by unrelated clients, which means that unless you are actually a cloud service yourself, it will always be hosted externally.  Well-known public cloud services include Amazon Web Services, Microsoft Azure and Google Cloud.

Hybrid cloud pros and cons tend to be two sides of the same coin.

The pros of hybrid clouds all tend to revolve around the fact that they basically offer companies the opportunity to “have their cake and eat it” by combining the security of a private cloud with the flexibility (and opportunities for significant cost savings) of public clouds.  The cons of hybrid clouds all tend to revolve around the fact that they can be much more complex to implement than straightforward private clouds or public clouds.  Let’s look at what this means in practice.

Flexibility versus complexity

These days some companies may be effectively forced to use private clouds to keep regulators happy and even those which are not may choose to “play safe” and go down this route anyway.  Private clouds can offer many advantages over traditional IT infrastructure, but, at the current time, it is highly unlikely to be as cost-effective as public clouds, so companies might prefer to split their data and apps across two systems, using the private cloud for anything sensitive and public clouds for anything non-sensitive.

This sounds easy on paper, but in reality implementing a hybrid cloud can be a whole lot more complex than “just” implementing a private cloud or a public cloud.  To begin with, you can’t “simply” do one, single lift-and-shift migration, perhaps to a containerized cloud infrastructure and then start reworking your apps in the cloud.  As a minimum you’re going to need to undertake two distinct migrations (one for the private cloud and one for the public cloud) plus think about how the two systems are going to interface with each other.

Get this right and you can have the best of both worlds.  Get it wrong, however, and you could find yourself wasting so much time and money on hassle you could have avoided that you might well end up wishing that you’d just paid up for a full private cloud.

Cost control versus lack of cost transparency

Even though private clouds can work out more economical than traditional IT infrastructure (and offer extra benefits), they still need to be provisioned in a similar way.  If you’re planning on running your own on-premises private cloud, then you’re essentially going to be facing the same sort of resourcing issues as you did before you moved to the cloud.  If you use an external provider then you may have more scope for flexibility, but there are probably going to be some limits, for example a commitment to a minimum processing volume over a certain period of time.

Public clouds, by contrast are all about flexibility and can offer great opportunities for cost optimization so that you only pay for what you need.

The problem may come when you start mixing the two, especially if you need to move data between the public cloud and the private cloud and start incurring charges for the traffic.  You then have to try to figure out what is legitimate usage (and what, if anything, you can do to reduce costs) and what is just people being people and doing what is convenient rather than what is most cost-effective. 

If you go for a hybrid multicloud architecture, then life could become even more complicated as different cloud services can apply different prices and pricing structures to what is essentially the same service, plus you have the potential for even more traffic moving between the different cloud platforms.

Disaster recovery versus security concerns

Public clouds and externally-hosted private clouds have in-built resilience to them.  It is, quite literally, your cloud vendor’s job to do whatever it takes to keep services running and they will build their business around that fact.  For example, they will set up their facilities in buildings and areas which offer maximum security and stability, rather than maximum convenience for staff and customers.

At the same time, handing over any data to an external party basically means that your security is only as good as theirs.  Now, for some SMBs this may not be an issue, especially since SMBs at the smaller end of the scale may not have the means to implement effective security on their own.  For others, however, it could be a major concern which would need to be addressed very seriously.

multi cloud cost management