Author: Ozzy Brightrose

AWS S3 cost calculator

A Walkthrough of the AWS S3 Cost Calculator

Posted on | by Ozzy Brightrose | Leave a Comment on A Walkthrough of the AWS S3 Cost Calculator

The AWS S3 cost calculator may well get more use than any of Amazon’s other pricing tools. In fact, it may well get more use than any other pricing tool out there.  If you’re going to use it, you need to know how to use it properly.  With that in mind, here is a quick walkthrough of Amazon’s S3 cost calculator.

The basics of Amazon S3 pricing

There are three factors which determine how much you pay for your Amazon S3 usage.  These are: storage, data transfer and number of requests.

Storage

This is pretty straightforward.  You pay per gigabyte of objects stored in your S3 buckets.

Data transfers

More specifically, outbound data transfers to the internet or to other Amazon regions, intraregional traffic is free.

Web requests

On the one hand, the cost for the various requests (PUT, COPY, POST, LIST and GET) is minimal (currently around $0.005 per 1,000 requests).  This means that even though cost optimization is hugely important to making the cloud work for you, this is one time when you could probably, quite justifiably, say “don’t sweat the small stuff” (or at least not as a priority).

On the other hand, GET requests generally involve outbound data transfers for which there is a charge, which means that it might be helpful to look at them specifically and see what you can do to minimize them.

A walkthrough of the AWS S3 cost calculator

Now that we’ve established the basics of the AWS S3 cost calculator, let’s have a look at how it works in practice.

Everything starts with a region

Whole articles could be written on the importance of regions in AWS, but for now, let’s keep it simple.  First of all, you need to be clear on what regions you can use for your storage.  For example, if you’re an ecommerce company handling personal data (e.g. names and addresses), then you may well be restricted as to where they can be stored. 

If you still have a choice of regions, then you can choose one (or more) according to your business priorities.  For example, you may prefer the region with the lowest pricing or the region closest to your customers which should have the lowest latency, depending on your needs and wants.  You can use more than one region if you wish, but then you have to run the calculation for each region.

Standard storage versus reduced redundancy storage

Amazon has a variety of storage classes to suit various use-case scenarios and performance-access requirements.  In theory there are two storage classes for objects which are accessed frequently and/or need to be made available with the maximum possible speed (as in milliseconds).  These are standard storage and reduced redundancy storage, or, as they are currently shown on the AWS S3 cost calculator, storage and reduced redundancy storage.

In theory, standard is the default and reduced redundancy storage, as its name suggests, is intended for data which can be stored with less redundancy than in standard storage, so basically noncritical, reproducible data.  In practice, however, Amazon itself recommends that you do not use reduced redundancy storage because standard storage is more cost-effective, which does rather raise the question of why they bother to have it in the first place.

On point of principle, you should do your level best to calculate your storage needs as accurately as possible as they will make a difference to your monthly bill.  In reality, it probably won’t hurt all that much if you’re a bit out as the storage aspect of S3 is very affordable.

Requests

You’ll notice that PUT, COPY, POST and LIST requests are on one line and GET requests are on another line.  We’re not sure if AWS did this to encourage you to think hard about the number of GET requests you will make, but even if they didn’t we would encourage you to do so.  As previously mentioned, it’s really not the cost of the requests themselves, it’s the data-transfer costs they usually generate.

Data transfers

The AWS S3 cost calculator shows three options:

Inter-Region Data Transfer Out

Data Transfer Out

Data Transfer In

The big ones are;

Inter-Region Data Transfer Out

Data Transfer Out

As these are where the costs of AWS S3 can start to add up.  Having said that, everything is relative and even using AWS extensively it’s still a very affordable option.  The key point to note is that it pays (or saves, however you want to look at it), to think about how you use objects and to see if there is any way in which your applications and/or work processes can be improved to minimize the need for chargeable data transfers. 

When considering this question, remember to think about the “human factor” or, to put it more bluntly, the fact that people generally appreciate the reality of costs more when those costs impact them in some way.

AWS cost calculator

What AWS Cloud Calculator Doesn’t Show You

Posted on | by Ozzy Brightrose | Leave a Comment on What AWS Cloud Calculator Doesn’t Show You

The AWS cost calculator is a very handy tool, however, like all tools, it has its limitations.  Its first main limitation is that it has to work off certain assumptions and these are stated on the website.  They can, of course, be changed, so it’s worth double-checking whenever you use the tool.  Its second main limitation is that there are certain costs the AWS cost calculator doesn’t show you.

The AWS cost calculator doesn’t show you intended changes in pricing

Like every other company, AWS can and does change its pricing from time to time.  Even though these price changes are planned in advance, they will typically only be put into the AWS cost calculator once they are applied as the AWS cost calculator can (currently) only hold one price at a time.  If you want to create a shield against unexpected rises in on-demand prices, you could look to “bank” reserved instances to lock in the price.  These are available for some services and can last between one and three years.

The AWS cost calculator doesn’t show you the impact of the free tier or promotions

It seems a bit odd that the AWS cost calculator does not show you the impact of the free tier since this can help to lower your bill and thus make AWS more attractive as compared to the competition, especially Microsoft Azure and Google Cloud.  It’s more understandable that they don’t show promotions and discounts since these may vary and different customers may benefit from different promotions.

It’s also worth noting that the AWS cost calculator automatically assumes that you are “starting from zero”.  In other words, if you are an existing customer, it doesn’t see if you would qualify for any volume discounts based on the combination of your current usage plus the extra usage for which you are requesting a cost calculation.  It just assumes that you are a new customer and gives you the “basic” price.  This can actually make quite a noticeable difference to your calculation, so it’s a bit surprising that Amazon does not include it.

The AWS cost calculator doesn’t show you pricing in different regions

More accurately the AWS cost calculator only shows pricing for one region at a time.  If you choose the wrong region, then you will probably get inaccurate pricing.  If you need pricing for different regions, then you’ll need to rerun the calculations for each region.

The AWS cost calculator doesn’t show you the impact of taxes

This is not particularly unusual for pricing tools like this, since they are generally designed to be accessible to anyone from any state in the U.S. and, indeed, in principle, any country in the world and it would become far too complicated for the AWS cost calculator to try to factor in the costs of taxes, especially given the fact that taxes can and do change and the fact that the calculation of taxes can depend on a number of factors which can also change. 

In short, it would simply be horrendously complicated for the AWS cost calculator to try to include the impact of taxes, but each individual company absolutely must factor them into their cost calculations and budgets.

The AWS cost calculator does not show you the impact of exchange rates

This one is obvious when you think about it, but it’s still worth noting if your main working currency is anything other than USD.  You might want to think about how currency fluctuations could impact your pricing and if there’s anything you could do to reduce your exposure or even make it work in your favor, for example buying up reserved instances when the exchange rates are at their best (for you).

The AWS cost calculator doesn’t show the impact of third-party licensing fees

This is another one which may seem obvious, however it can trip you up if comparing AWS to Microsoft Azure.  The Azure TCO calculator assumes that you have Microsoft Software Assurance which gives you access to Azure Hybrid Benefit, in other words, if you have existing Microsoft licenses, you may be able to use their cloud equivalents at a discount.  If you don’t, however, then you will either have to buy Microsoft SA or pay the full license fee for the cloud.  The former tends to be more economical.

The AWS cost calculator doesn’t show you the impact of leap years

According to the AWS cost calculator, a year has 365 days, it does not account for the extra day in leap years.  Admittedly this is probably only going to increase an AWS bill by the tiniest of amounts, however it is still worth noting, especially since 2020 will be a leap year.

For the sake of completeness is that the AWS cost calculator does not support per-second billing options even though these are used by some of the services.

azure-total-cost-of-ownership-calculator

Azure TCO Calculator | Sanity-Check

Posted on | by Ozzy Brightrose | Leave a Comment on Azure TCO Calculator | Sanity-Check

Azure TCO Calculator

The Azure TCO calculator has had (more than) its fair share of criticism.  It has to be acknowledged that quite a bit of this has come from companies with a vested interest in highlighting its flaws.  At the same time, however, it also has to be acknowledged that the Azure TCO calculator, at the very least, has definite limitations.  At best, you should see it as loose guidance rather than as a meaningful estimate of what you are likely to pay.

At the end of the day, the purpose of the Azure TCO calculator is to sell you Microsoft Azure

Keep this thought front and center in your mind at all times.  The Azure TCO (total cost of ownership) calculator is basically a sales tool.  Its job is to present Microsoft Azure in the best possible light without actually lying.  This doesn’t mean that it’s without value, it just means that you need to be ready, willing and able to apply “sanity checks” to its output.

Sanity check #1 – remember the T in TCO stands for Total

When you think about the total cost of ownership of Microsoft Azure, remember that a public cloud migration isn’t just about having your apps in the cloud.  Those apps are (presumably) going to need storage for data and have networking capabilities as well and so these costs will need to be accurately factored into your calculations in order for your estimates to be meaningful. 

You’re also going to need to think about license costs and this is one area where the Azure TCO calculator can get interesting.  For example, if you have Microsoft Software Assurance, then you can make use of Azure Hybrid Benefit for Windows Server and essentially make your current license costs do double duty by using them to run Windows virtual machines on Azure at a lower cost.  If you don’t, however, then you either need to buy Microsoft Software Assurance or pay for the relevant licenses.

Sanity check #2 – think carefully about performance

Microsoft Azure is in competition with other public cloud vendors, most notably AWS and Google Cloud.  Given that decisions to move to the public cloud are often driven by the expectation of cost reduction and the ability to undertake cost optimization, it’s entirely understandable that these companies are all really going to push the potential financial advantages of the move.  Just remember that headline figures can be misleading. 

For example, two companies could charge different prices for what, at first glance, appears to be the exact same instance type, but if the one with the more expensive price actually offered a much better performance then it could actually end up working out to be cheaper.

It can be difficult to impossible to get this sort of detail from pure TCO calculators, but there are two ways you can get it.  The first is to have a good look at studies comparing the relative performance of different cloud operators and the second is to do it yourself.  Most cloud operators, including the big ones, give you the opportunity to try out their services for free for a certain length of time.  It can be very beneficial to take advantage of this, especially since it can act as a “dry run” for your “proper” migration.

For the sake of completeness, you don’t necessarily have to do two (or more) “lift-and-shift” migrations to run these comparisons.  You basically keep your own systems running as they are and then “lift” to the clouds you want to test in order to benchmark them.  In order to be fair, however, you have to resist the temptation to correct any issues you may have noticed on your first run.  Conditions have to be identical for the test to be fair.  There is, however, nothing to stop you noting issues and addressing them later.

Sanity check #3 – remember that pricing structure matters

Broadly speaking, the big cloud vendors all offer three main pricing models, on-demand, reserved instances and spot instances.  There may be other pricing variations and factors at play (such as the ability to use Azure Hybrid Benefit in Azure, if you have Microsoft Software Assurance) but these are the three big ones.

As a rule of thumb, in principle, you want to use spot instances as much as possible, with reserved instances being your next choice and on-demand pricing being a last resort.  Get this right and you really can enjoy massive cost savings and great flexibility.  Get it wrong, however, and you could end up wishing that you’d never migrated to the cloud in the first place.

For the sake of completeness, the other major factors which will influence your cost effectiveness are your ability to monitor costs (and avoid excess usage) and your ability to optimize apps in the cloud (to limit the use of cloud resources).

azure tco calculator

What Are the Limitations of Azure TCO Calculator

Posted on | by Ozzy Brightrose | Leave a Comment on What Are the Limitations of Azure TCO Calculator

The Azure TCO calculator often gets a mixed bag of reviews. Some people find it very useful, other people find it very misleading.  The key point to understand is that the Azure TCO calculator is a tool.  To get the most from a tool, you need to understand how to use it and that starts by understanding what it does and also, and just as importantly, what it doesn’t do.

The Azure TCO calculator basically calculates running costs

The key point to understand about the Microsoft Azure TCO calculator is that it basically calculates what you are likely to pay to run any given set up in Microsoft Azure.  This will obviously play a major role in determining whether or not a move to Microsoft Azure is the right choice for your organization.  There are, however, a lot of other factors involved in this decision and the Azure TCO calculator (currently) does not help with them.  Here are three of the main ones.

The cost of the actual migration

It can take a lot of hard work just to figure out how to move to the cloud in the most cost-effective manner.  Even if you’re using a “lift-and-shift” approach and planning update your apps in the cloud, you may well find yourself faced with the choice of either running a hybrid cloud on a temporary basis, or going 100% public cloud straight away but accepting that this may cause you to lose out in other ways. 

For example, let’s say you have 15 servers.  Five of them are just about at the end of their useful life.  You were going to decommission them anyway, so really, you lose nothing by migrating them to the cloud and sending them for recycling.  Of the other ten, however, five are about halfway through their useful life and five are still fairly new.  You can move these to the cloud and try to sell on the hardware, but you may take a financial hit by doing so.  Alternatively, you could run a hybrid cloud until you need to replace the hardware anyway, but this adds complexity to your IT management and operations and may add to your expenses.

In short, over the long term, using the public cloud will save you the hassle of having to spend money updating your own IT infrastructure, however over the short term, you will still have to absorb the expense involved in the actual cloud migration and the Azure TCO calculator cannot help you calculate this cost, you will need to do it yourself and it is very much recommended to take the time and make the effort necessary to do it properly.

The cost of post-migration work

If you are planning on just doing a lift-and-shift migration or perhaps undertaking a bit of refactoring, then you are unlikely to get the full benefit of having your apps in the cloud.  There is certainly a very decent chance that you will make some cost savings, but containerized legacy apps running on a public cloud are highly unlikely to be able to make the most of the cloud the way cloud-native apps do.  That’s essentially the point of cloud-native apps.

This means that in addition to budgeting for the cost of the actual migration proper, you will also need to budget for the cost of redeveloping the apps in the cloud (or creating new ones).  Again, this is an upfront expense for which you can expect to reap the rewards over the long term, but it is still an expense you will need to factor into your calculations and it’s very much down to you to do the sums properly, the Azure TCO calculator cannot help here.

The cost of failing to undertake proper cost optimization

The Azure TCO calculator basically asks you to input details of your current set-up and gives you an idea of how much it would cost to run the same set-up in the Microsoft Azure public cloud.  This is fine as far as it goes, however, there is a massive degree of nuance.

Firstly, your current set-up is, of course, based on your current usage and if you optimize your apps in the cloud correctly, there is a distinct possibility that you could improve on this, possibly very substantially.  Secondly, it assumes that you will keep a grip on your “cloud hygiene”, basically only run what you need when you need it (and switch it off when you don’t).  If you don’t do this, then your costs will go up and again, that one is on you.  Thirdly, you need to make effective use of reserved instances to get the most value out of the public cloud and again, there’s nothing the Azure TCO calculator can do to help with this.

In short, the Azure TCO calculator is designed to give you “best case” pricing for running your current set-up to the cloud.  It certainly has its limitations, but if you accept it for what it is, it can be very useful.

hybrid multi cloud architecture

The Basics of Hybrid Multi Cloud Architecture

Posted on | by Ozzy Brightrose | Leave a Comment on The Basics of Hybrid Multi Cloud Architecture

Hybrid multi cloud architecture

Hybrid multi cloud architecture is indisputably the most challenging form of cloud architecture to implement, but if you get it right you really can have the best modern information technology has to offer.

Hybrid multi cloud architecture is basically about quality over quantity

What hybrid multi cloud architecture actually means

Before you decide whether or not hybrid multi cloud architecture is right for you, you ought to keep in mind that there are a couple of clear downsides to it.  The first one is its obvious complexity.  The second one is that you are going to reduce your options for volume discounts.  For both of these reasons, hybrid multi cloud architecture is only likely to make sense for larger SMBs who have solid, in-house IT resources.

Hybrid clouds combine private and public clouds.  Multi clouds are exactly that, multiple public cloud environments.  Hybrid multi cloud architecture therefore, combine a private cloud with multiple public cloud environments, all working together as one whole.  Let’s break this up.

A private cloud is a cloud platform which is only used by one tenant.  It has very high security, but also tends to have higher costs and may lack flexibility. 

A public cloud is a cloud platform which is shared between unrelated tenants.  This fact means that it cannot meet the same security standards as private clouds (although it can be a whole lot better than in-house systems run by SMBs which don’t really understand what they’re doing), but they’re plenty secure enough for most purposes, flexible, scalable and very cost effective (at least if you manage your cost optimization properly).

Multi cloud environments are simply instances where implement cloud deployments over multiple cloud vendors.  This may be done for various reasons such as to avoid vendor lock in and/or to ensure business continuity.

Why use a hybrid cloud?

There are two main reasons why businesses opt for hybrid cloud architecture.  The first is so that they can keep sensitive data (often personal data) in a private cloud while using the public cloud for everything else.  The second is because they want to move to the cloud computing environment in stages and need to maintain their own infrastructure until the move is complete.  Even though hybrid clouds are more complex than just using a private cloud or just using a public cloud they can still be vastly preferable to trying to implement a “big bang” migration.

What makes a successful hybrid cloud?

A successful hybrid multi cloud cloud architecture will have both private and public areas working together, for example it will have a centralized identity infrastructure.  Network architecture will ensure that the public cloud functions as an extension of the private cloud and, in particular, that the connection between them works at a decent speed.  Last but definitely by no means least, there absolutely must be unified and cohesive management of both private and public clouds.

Why use a multi cloud environment?

That is actually a more interesting question and there are two main answers to it, which, ironically enough, largely contradict each other.

Answer one – to reduce risk

To use a cliche, you avoid putting all your eggs in one basket.  For example, you don’t just accept the reality of duplication, you embrace it as a way to provide redundancy and hence to increase your chances of being able to maintain 100% business continuity.  Similarly, you accept the extra cost of working with multiple vendors (because you will be giving each lower volume) as the price of avoiding vendor lock in.

Answer two – to increase agility

In this situation, your aim is to grab the “best in breed” functions on different platforms and accept that you’re going to pay a premium for doing so.  For example, you might choose Microsoft Azure to migrate Microsoft workloads, because, understandably, it makes the cloud migration about as easy as it can possibly be.  Then you might choose AWS and/or Google Cloud for other functions.

In this scenario, you’re not worrying about vendor lock-in or even business continuity, you’re just looking to cherry-pick the best resources for any given situation.

Neither approach is right or wrong but given the complexity and expense of running multi cloud environments, it’s strongly recommended to think carefully through all the implications before deciding whether or not a multi cloud approach is really right for you. 

For example, the idea of having redundancy sounds good in theory, but the best cloud vendors will have close to 100% uptime, so realistically just how much redundancy will you need?  Is it really worth the hassle and cost of managing multiple cloud environments? 

Similarly good cloud vendors will have a reasonable approach to assisting customers who wish to leave and this can be investigated prior to signing up with them.  Some cloud vendors may offer better terms if you agree to stay for a certain period, it’s up to each organization to decide if that’s worthwhile.

What makes a successful multi cloud environment?

Basically the same comments apply as for a successful hybrid cloud.

hybrid cloud strategy

Workload Management in Hybrid Cloud Strategy

Posted on | by Ozzy Brightrose | Leave a Comment on Workload Management in Hybrid Cloud Strategy

In very simple terms a hybrid cloud strategy is essentially a strategy for deciding what workload should go where.  Like many simple concepts, however, turning the theory into practice can require a lot of serious thought and coming up with answers to a number of questions.

A hybrid cloud strategy is usually based on the answers to four key questions

The four questions which usually set the foundations for a hybrid cloud strategy are:

What are the regulatory requirements?

What are the management implications?

What does this mean for application performance?

What is the total cost of ownership?

As can be clearly seen, these questions are very broad, which means that answering them usually depends on answering a number of other, more detailed questions, only some of which are likely to have yes/no answers.  You may therefore need to develop a weighting/scoring strategy for assessing priorities.

Pro tip: it’s very risky to assume that everyone will automatically understand what something means.  What’s obvious to you may or may not be obvious to them.  That being so, it’s generally recommended to assign definitions to any significant terms and, obviously, make sure that those definitions are easily accessible to anyone who needs them.

What are the regulatory requirements?

This should be the first question you ask when analyzing any situation because doing so will stop you “falling in love” with a potential solution and spending a whole lot of time and effort putting together a plan to implement it only to discover later that it’s a non-starter with the regulators.

In this context, it has to be said that laws are not necessarily as clear as people would prefer, which means that sometimes you may need to get specific guidance from lawyers or even go to the regulator directly.  Basically, you need to do whatever it takes to make sure you stay on the right side of the law.

For completeness, keeping regulators happy does not necessarily mean you have to use on-premises data centers, in fact it doesn’t even necessarily mean that you will be restricted to using a private cloud.  It may, for example, simply mean that you need to ensure that your cloud provider’s data centers are based in a geographical area the regulator considers acceptable.  You will only know if you check.

It’s also worth noting that security in general does not depend on location (although that’s obviously a factor).  Public clouds can be more secure than poorly-managed private clouds, but they can also be a playground for cybercriminals.  On-premises data centers should be the most secure form of IT infrastructure there is, but only if the company running it knows what it’s doing.  In other words, choose your cloud provider(s) with care and ensure that any in-house IT systems are appropriately resourced.

What are the management implications?

In this context, the term “management implications” has two meanings.  First of all, there is the direct meaning of how you will manage your cloud platforms in general and your data and applications in particular.  This in itself will have different meanings depending on the specific nature of your hybrid cloud deployment, but as a minimum, you can expect cost optimization to be a factor in your considerations.

The second is wider meaning of how you will manage your hybrid cloud environment to support your business as a whole.  For example, where do you expect to see growth and where do you expect to see contraction?  What new areas would you like to develop and are there any old areas you would like to drop?

What does this mean for application performance?

It may seem strange that this question comes so low on the list, but a lot of the time it’s a fairly minor issue, in fact it may even be a non-issue.  If an application is mission critical and needs to work at top speed, then on-premises data centers and/or the private cloud is the way to go, assuming you have the capability to manage them, otherwise, it may be best to accept the slight latency which usually goes along with the public clouds. 

Otherwise, the public cloud is usually absolutely fine from the perspective of application performance, at least it is if you choose a decent public cloud provider.  In particular, you’ll want clear and enforceable SLAs in place along with information about their past track record of maintaining uptime.

What is the total cost of ownership?

The public cloud will almost inevitably come out the winner here for all kinds of reasons, at least, it will assuming that you perform cost optimization in an effective manner.  It will also give you the benefit of being able to eliminate resource-draining capital expenditure (in a depreciating asset) and exchange it for regular monthly payments which can be much easier to manage.