Most aspects of this topic have not changed from the beginning of 2022. However, I am compiling all that we have learned in the past few months, and adding to the already known.

Caveat: In most cases when customers come to us with burgeoning AWS bills, we generally send them in two directions.

The first is to go multi-cloud or for a combination of cloud and on-premises, the original hybrid route.

Or step away from AWS completely. Mind you AWS is expensive. It's like buying a high-end Mercedes or a BMW car. However, if your need is the best performance, scalability and security, stay on with AWS.

I generally do not recommend a shift from AWS to Microsoft Azure or Google Cloud unless there's a service that makes a huge difference that's proprietary to those platforms. And there are a few.

Also if a customer has Enterprise Agreements signed with Microsoft, then there are several licensing benefits they must consider switching to Azure. Cost savings in Azure or GCP most of the time will hardly be worth the effort of moving out of AWS. The right move is to cost optimize.

I generally push customers to other cloud providers or compute models where the bills are halved. More on those in a later article.

So this is generally a guide for you to cut your bills by staying on with AWS.

Reduce Dependency on AWS Proprietary Technology

This is something I tell every customer irrespective of whichever cloud they opt. Do not invest heavily in any proprietary service. They will start very attractive, and extremely easy to set up. But then there's always a catch, and you will see the bills soaring very soon.

It's a very difficult choice to abandon them. Take for example AWS RDS. It takes a developer a few minutes to set up everything and maybe an hour to fine-tune it. In comparison, a solid MySQL/Postgres SQL cluster could take a few days to optimize, and you also need to plan backups and other housekeeping activities.

RDS is a great boon for someone looking at scaling fast, and who needs auto-scaling and scaling down using simple rules.

However, in many cases, a rethink in architecture helps. We have been successful in cutting down the bills on a bunch of RDS instances by 60 percent by moving them to a Percona cluster recently. No significant change in performance or durability.

Choose your plans wisely

I generally ask certain questions to my customers. These inclde Why cannot a dev cluster be on spot instances? Agreed it's not stable. And if it goes away you are not going to lose much. But then your CFO might start loving you.

Unless you have developers sitting up late at night and pushing code, dev clusters need not run 24x7. It’s worth scheduling on/off times for anything which is not in production. AWS does provide you with all schedulers needed.

If you see anything which can be remotely predictive, please consider a longer-term contract. It brings bills down drastically. Reserved Instances can end up being major savings. However, do read the next point.

Get the sizes right

Every cloud provider prices their products based on an amortization calculation on their hardware acquisitions. AWS price drops are also a result of these number crunching. However, not all instances with the same VCPU count and RAM are born equal. At the time of writing these AWS is running six different generations of Intel processors alone across their various instances. There are several instances from AMD's 4 generations of processors, and then there are ARM processors.

Also, some of the newer instances do not suffer from the noisy neighbor problem as much as older T2s do. Hence right-sizing instances, identifying processors used to create them and profiling your applications for the same is very important.

These permutations and combinations cannot be easily explained over an article. This requires proper consultation, and you will need to speak with experts before you freeze on these choices.

Observe and Determine

Observability is a recommended virtue for all modern application platforms. Observability is not about a bunch of AWS Cloudwatch entries that will further increase your bills. This is about choosing the right parameters to study whether it's an HTTP(S) response to a request by a front-end asset, or system loads of an instance.

You will need to observe and learn consistently, and that practice will further help you optimize workloads.

This should have been right on top of the list.

Scrutinize monthly bills with the devops or cloudops team

At Netzary we make it a practice to look at all cloud bills every quarter along with members of the DevOps team. And we have been able to identify assets that we do not use, or should have been killed, stopped or discontinued. We are moving the practice to monthly, and you should do that.

In AWS you will see unused EBS Volumes, unattached reserved IPs, and snapshots that should have been deleted months back. You are also likely to notice services that should have been unsubscribed long back. This is sometimes very boring work, which might test the patience of your engineers. However, this is something you should bring in as a practice.

Know that there's an option to generate credits

Let me share a confession shared by a senior AWS sales guy. AWS is equally paranoid about losing you as a customer because of higher bills, and they will be happy to give you the benefits for a reason.

The reason, however, is important and since any rebates or credits need system approval, and validation you will need some expertise to present it to your account managers.

AWS has a bunch of very smart people, and they will consider so many aspects before they let you go. Of course, for all that you need to be a reasonably heavy customer for them. And that number differs from market to market.

In a market like India where we operate, that number can be as low as $ 20,000 a month to work with you to ensure your bills are lowered.

They will also analyze your bills to check and see how easy it will be for you to let go. If you are locked into many services, then your credits may not be as high as they would be. Because they know it’s tough for you to switch.

Migrate to Kubernetes

I assume if your bills are high, you are running multiple servers. In case the number of servers you run is more than 5, you must consider Kubernetes and containerization. AWS has one of the best-managed Kubernetes platforms. Immediate savings may not be much, but down the line when you expand and grow you will see benefits. If you see yourselves growing, this move will help you cut down the future bills.

Rethink Multizone architectures

For top reliability and availability, every AWS Best practices guide recommends multizone deployment. This indeed ensures the results, but be warned, this comes at a cost especially when you are running complex workloads.

We learned this by burning our fingers. A recent deployment AWS Kubernetes cluster saw bills scaling with multizone availability enabled. AWS bills you for traffic as well as API calls between zones, and this can hurt your pockets.

Before you enable multizone availability, consider the use case and see the cost implications. If you still are not sure, do talk to an expert.

Analyze the lesser-known costs

AWS like other cloud providers does not advertise certain details on cost. For example, take AWS S3. Apart from the storage costs and bandwidth costs, there are minor costs around various web request methods such as POST, PUT, GET etc.

Few developers consider these aspects, but architects need to look at these details carefully before approving the service or rollout.

Some of these are not easy to do. In case you need any help please feel to drop a line to info@netzary.com. Our first round of consulting is always on the house.

Also do check our website on these services. We doS provide a wide range of development and managed services

S Ramdas is the CEO of Netzary Infodynamics.