Costs improvements on our Amazon web services account - AWS

Amazon Web Services (also known as AWS) is one of the most powerful tools nowadays to build all of our programming projects, from the most basic or small ones to the most complex we can imagine.
Its ecosystem consists of a series of services that allow us to attack any kind of architecture problems related to our development projects, from small development environments to big ones for production environments.
Some examples about the AWS ecosystem services are:

• Amazon Elastic Compute Cloud (EC2) to handle virtual machines
• Amazon Simple Storage Service (S3) to handle storage of any kind of files (images, videos, plain text, binary files, etc)
• Lambda, that gives us the ability to run serverless code
• Amazon Relational Database Service (RDS) to mount any kind of general use databases either MySQL, PostgreSQL, SQLServer, MariaDB or even Amazon own implementation called Amazon Aurora.

And many other services that we could analyze on different posts in the future.

But let’s go straight to the main point for this specific article which is to show that considering the big potential of this platform, we as developers need to take a big responsibility when implementing anything on the Amazon ecosystem.
Each of the AWS services has its associated use cost (some services offer a free tier that if we stay within certain parameters, the service cost is free for X amount of time. I think right now, they offer 12 months to use the free tier services)
So, as each AWS service has an associated cost, it is very important to keep a strict control of the costs associated with all our AWS accounts to avoid paying more money than what we actually need to spend for the same service.

On big development teams there are usually specific roles in charge of monitor and control that all the service configurations on the AWS instances are correct to avoid paying more than needed and if they detect something to fix they communicate it to the specific team to make the necessary changes to stop that problem as soon as possible.
On smaller teams the responsibility is usually divided between several developers or in some cases there is a specific role like a Technical leader or an Architect.

Let’s see a practical example:
Let’s say we need a new development environment. Let’s call it ‘CI’. Our developers would use it to test some latest integrations between systems/services.
In this environment we have a virtual machine on one EC2 instance and one MySQL database on a RDS instance. A very simple configuration that should show you the point of this article easily.
Now, let’s say the person in charge of creating this new development environment don’t have much idea about what he/she is doing (it could be because the developer doesn’t know the AWS platform yet, is just starting working with it, or it could even be a person that knows the platform but just wait for a specific result he/she doesn’t care much about additional ‘details’, such as the cost of maintaining that environment working).

So, let’s assume that this person, to keep the environment working, leave a RDS instance up and set up on multiple zones, which is something completely normal and very useful to avoid service downtime in critical situations. But… in our particular case that this is a development environment and considering that we are a small team we can say that it is totally unnecessary to have multiple zones for that specific development environment.
That configuration would be recommended for a pre-production, QA or a production environment.
So, in this particular example we can see how if an additional zone is enabled, the RDS instance price doubles instantly to keep the instances working.

I know this is a very simple case, but I think it should be enough to understand the point. Now you can imagine an enormous system, with multiple development environments, several production services, databases, EC2 instances, elasticache instances, elastic beanstalk instances, SQS queues, etc.
On any of those service configurations you could eventually have similar situations like the one mentioned before if there is no monitoring and control of how things are set up on our AWS accounts on each of the steps of our development process.

Well, I hope this information is useful to you and, as always, stay in touch and contact me if you have any suggestions which are always welcome.

Greetings!