3-Ways to Optimize AWS Spend using Scalable Application Architecture

It is not uncommon for companies to migrate their application(s) to Amazon Cloud simply by purchasing server capacity and then start seeing rather unusual large monthly bills.  It is very common for some leaders to start questioning the value of AWS migration as the monthly spending goes high and cost of resources with special modern technology skill sets required to run on AWS also moves higher.

All in all, the spending goes higher.  In our years of experience working with Cloud architecture, whether it is on AWS, Microsoft Azure or Google GCP, it is very important to take a hard look at your application architecture even if it is old architecture and consider some changes in order to truly leverage the elasticity of the cloud platform that you are migrating to.  Amazon is the first cloud technology that came up with the word “elastic” in the context of server usage. Here are three ways that you can make sure that your application truly built for AWS:

    1. Application architecture is designed to truly leverage AWS elasticity.

    2. Use of Docker containers on AWS Fargate.

    3. Load based automatic expansion and contraction of AWS resources.

Application architecture is designed to truly leverage AWS elasticity

Regardless of the type of application that you are trying to run on AWS, it is imperative that one has dynamic scaling built-in, meaning, being able to fire up more or bigger hardware when there are more number of users on the system or there are more processes running on the system. If you are using AWS EC2 instances, then one should be able to expand the size of the instance or add more instances as your application load demands more. At the same time, it should automatically contract when the demand goes down.  In case of EC2 instances, it required careful DevOps work (configuration) and scripts to ensure that the increase in number of users leads to an automatic increase in the number of server units.  AWS provides really good configuration based resource usage (CPU / Memory) that can be used to automatically increase the underlying infrastructure. Scripts can also be written that can detect the actual application load and decide when to fire up new instances and similarly, when to bring down instances, when load goes below threshold. The following link is a good reference: https://aws.amazon.com/devops/.

Use of Docker containers on AWS Fargate

Amazon AWS cloud provides Docker containers on their platform called Fargate that runs on Kubernetes technology (https://aws.amazon.com/fargate/). This is very cool technology and building a dynamically scalable architecture is simpler than ever. Particularly, we like that we don’t have to mess around with the underlying OS related setup and maintenance. We package the application properly in a Docker container and this image is self-contained and automatically deployed by AWS in its fargate platform. There are some OS based libraries that need to be packaged in the container image but these can be kept to minimal with experience to make the image very light. Same container image can be deployed on Azure or GCP. This allows for the use of AWS resources in smaller chunks and as needed per demand for the application.

Load based automatic expansion and contraction of AWS resources

In the case of either EC2 or Docker containers, it is extremely important that AWS’ elasticity is utilized and we stretch the usage of resources on AWS when needed. The days of big honking servers running using only 2% CPU and 15% memory in anticipation of load once a year or once a day are gone! We find the most economical is the use of Docker containers on AWS Fargate. We can easily configure the expansion and contraction based on resource usage, which is often tied to application load.  Also, we like to use smallest unit of container so that at any one point in time, we are spending the least and only increase spending with increasing load in small chunks.

We see this in action on many projects and one project in particular has strict requirement of a web service response of 140 ms to a real-time mission critical production machine.  The architecture is performing real well and expands automatically during day peak loads and contracts automatically during the later part of the day into night.

About the Author

Prat Gupta, Ph.D.

Prat is a visionary software architect, investor, entrepreneur who founded different companies under the Bursys Group portfolio of companies. Bursys group has expanded operations since it was founded in 2005 in North America, Europe, and Asia. Bursys Group provides a full range of technology consulting services and software development services. Bursys group has developed and launched FieldEquip, an innovative connected field service platform that brings machine learning and artificial intelligence to solve real-world field service automation problems. Prat also serves on various Boards for profit / Non-profit. Prat loves to engage with innovative & challenging startup ideas and always ready to fund promising ones.