To containerize in AWS or not: the cost perspective
I recently checked the pricing model for Amazon Fargate to see if migrating a fair number of EC2 instance-based workloads to containers would save money. In theory this should have been the case, as a container has less “fat” compared to a full virtual machine. In this case the workload itself was perfectly suited for a container: a single process with single configuration file that was mostly network-bound running on t3.micro instances.
Rather surprisingly using Fargate would cost almost as much as running the same workload on EC2 virtual machines even when minimizing the container specs. The numbers below are based on the AWS pricing calculator. The cost for ten t3.micro instances (2 vCPU, 1GB mem) with 10GB EBS gp2 SSD volumes each in us-west-1 region:
-
Amazon Elastic Block Storage (EBS) pricing (monthly): 36.00 USD
-
Amazon EC2 On-Demand instances (monthly): 90.52 USD
-
Total monthly cost: 126.52 USD
The cost could be roughly halved by moving to t3.nanos.
AWS pricing calculator does not support Fargate, so these numbers are based on Fargate pricing page based on ten services with minimum specs (0.25 vCPU, 0.5GB memory):
-
vCPU cost (monthly): 83.81 USD
-
Memory cost (monthly): 5.52 USD
So Fargate is somewhat cheaper, but in return you’re getting 1/8th of the vCPUs and 1/2 of the memory. Of course an EC2 instance is running a full operating system and has more overhead than a container, but it still seems unlikely that you could actually save money with Fargate especially in CPU-bound workloads. Also splitting support processes into sidecar containers would increase cost further.
With this quick analysis it smells like the main benefactor here is AWS who can run more workloads on less hardware and avoid passing those savings to their customers. But as always with AWS understanding real production-load costs is next to impossible, because everything is charged separately.