There is always this mindset that AWS is the most expensive Cloud Computing platform. While I am not sure this is totally true, one thing is for sure: “the cost of your cloud infrastructure is directly proportional to the architecture implemented”. If your architecture uses a combination of expensive services that you do not need, then the bills will start coming in.
AWS has hundreds of services. It is important to know the right tools and services to use for the right scenario. This is why studying Solutions Architecture is important. In that discipline, you learn how to select the right tools based on your use case scenario. People also complain a lot that AWS has duplicate tools sometimes. But I see it as a blessing in disguise. This gives various options for deployment.
For example, in AWS, there are about six different services that can be used to deploy and orchestrate container-based applications:
- AWS Elastic Beanstalk
- Amazon EKS, aka Kubernetes
- AWS AppRunner (you can read my article on it here)
- Amazon ECS
- Lightsail Containers
- Docker on EC2
Choosing the right service to use in collaboration with other AWS services is what determines the bill at the end of the month. Let’s talk about the phases a startup can go through while using AWS so that they do not break the bank while hosting applications on AWS.
Phase 0: Do not rely on Credits for your infrastructure
Credits are very awesome, and AWS is generous enough to give as much as $100,000 to startups that are backed by funding.
This is a huge coverage in terms of infrastructure cost and tempting. Many organizations want to use all the shiny tools in AWS at this stage, because they have this amount of money to splurge on. But two things are usually not put into consideration.
1. The money will eventually get exhausted
2. The credit will expire
When any of the two points mentioned above happens. You see the startup trying to look for means to quickly cut down cost and re-architect as quickly as possible. This is because they have over-provisioned on the credit they had received.
Caution here is to architect carefully to avoid overspending. There are occasions you might want to test with some expensive services, but let that be experimental.
When you are done with the experiments, ensure all the used resources are destroyed to avoid huge bills when the credits expire or get exhausted. So the question at this point is, “How do we architect accordingly?” That is what Phase 1 is all about.
Phase 1: Use simple, affordable tools like Amazon Lightsail
Amazon Lightsail is a form of VPS offering from AWS. This is different from EC2 and even has its console, which is simple and very intuitive.
Lightsail Family is made up of the following services:
- Lightsail Virtual Machines
- Lightsail Managed Databases
- Lightsail Containers
- Lightsail Object Storage
- Lightsail CDN
- Lightsail LoadBalancer
Lightsail Family all have one thing in common. Predictable billing for your AWS Infrastructure. The prices for each of these services are static monthly.
For example, a Lightsail Virtual Machine with a Linux Ubuntu Operating System, with 8GB RAM, 2 vCPU, 160GB SSD, 5TB Monthly data transfer, costs $44/month. This figure is static with no extra cost and is not billed per hour. You can see more about Lightsail Pricing here.
Also, a Lightsail Database running MySQL with 1GB Memory (RAM), 1 vCPU, 40GB SSD Disk
100 GB Transfer/month costs $15/month for a single instance and $30/month for the high availability option.
This means a simple architecture of a Lightsail Virtual Machine for an app and a Lightsail Database (single instance) will cost a total of:
$44 + $15 = $59/month
This is less than $100/month to run an application on AWS. This is a perfect way to begin the journey for your startup and get your MVP ready, and a few users using your app.
The following are videos that can help you get started with setting up a Virtual Machine and Database on Amazon Lightsail
At this stage, it is ok to deploy the apps directly on the virtual machine to move fast. The next step to improve operations will be to put the application in a Docker image to further improve the speed of deployment and reduce errors during the deployment process. If possible, start looking towards automating deployments. Let’s talk about how to deploy Docker images without breaking the bank.
Phase 2: Use Containers
At this stage, your application is stable. There is a process of either pulling code to the server or using other means to run the application. With this, getting Docker in the mix to further standardize things will be a major game-changer.
Containers are a standard way to package application code that makes it easy to run on a Linux machine that has a container runtime installed. Docker is the most popular of all and is quite easy to use. With containers, you do not need to install a runtime for a programming language when you need to set up a virtual machine. All you need to do is pull the container image and run it, and the app begins to run.
To improve deployment speed and reduce errors when making changes to your deployments. At this point, some automation can come in. You can start storing your Docker images in Amazon ECR and deploy to Lightsail Container, which is quite easy to use, manage, and really affordable to use. Lightsail Containers are also quite cost-effective and cost as low as $7/month for 0.25 vCPU and 512MB RAM (no storage because it is usually ephemeral). Billing is still static and not per hour.
At this stage, you can yank off your Virtual Machines and go for Lightsail Containers, which is even simpler to use, manage, and deploy apps on. The other added service will be ECR. ECR is where the Docker image will be stored to deploy to Lightsail. ECR cost is about $0.10 per GB / month. With a properly optimised Docker image, it will not be up to 1 GB.
After running on this for a while and things are stable. There is a choice to remain with the Lightsail family or step into the AWS Management Console proper to explore the right services to use your application as users and traffic continue to grow. This stage is a huge decision because most times there is a lot of re-architecture that will need to happen, both from the application side of things and from the infrastructure side. This point of using Containers on Lightsail is a good spot to remain in for a while. It continues to keep your cost as a minimum, and is easy to manage and monitor. The next phase will be to move away from Lightsail and select the appropriate service(s) for your workload. Let us see how that will play in the next phase.
Phase 3 and beyond: Start Stepping out of Lightsail
At this stage, Lightsail is not able to handle your application requirements anymore, and you need to grow your infrastructure and operational needs. So, using the core AWS services at this point will be more appropriate. Hopefully, some good bucks have been made or some funds raised with the Lightsail infrastructure bootstrap that you have run so far. You have also gotten used to the AWS ecosystem to some extent. Making the right choice at this point is still very important. As I stated earlier, “the cost of your infrastructure is directly proportional to your architecture.
Most of the tools I mentioned earlier are on Lightsail. At this stage, you have more engineers, and your system needs more standardization and scalability, high automation, and reliability. Tools like Amazon ECS, Amazon EKS, and Amazon RDS, or any NoSQL option, will suffice at this point. Since you are already on containers, you can choose from the list I mentioned previously on the option of deploying containers on AWS. This will make your migration smoother sailing. The possibilities of the architecture are limitless.
Most engineers will quickly want to go for Kubernetes even at the very beginning or at this stage. But my take will be to start small and get to this stage. Secondly, your infrastructure must not always end in Kubernetes. I have seen Amazon ECS used at scale and worked efficiently. The knowledge of the team and understanding of the technology play a huge role in the final architecture that will scale. If there is any need for further changes, it will need to happen. No architecture is perfect.
Conclusion
The cost of your infrastructure is highly dependent on the architecture and choice of services used for deployment. From this article, a startup can deliver software solutions for less than $100 a month, then scale up as they grow and change to services that are more complex and meet their needs as they grow. Internal expertise on the service is also crucial for effective management and business continuity.
