Rapid Docker on AWS: Which option to choose?

AWS offers more than 100 services. So much choice is both a curse and a blessing. For example, there are at least four options to run containers on AWS: the Elastic Container Service (ECS), the Elastic Kubernetes Services (EKS), operate your own cluster on top of EC2, and Elastic Beanstalk. Futhermore, you can choose between a lot of database services: RDS, Aurora, DynamoDB, DocumentDB, Elasticsearch, Neptune, Redshift, ElastiCache, to name a few.

But before you make your choice, you should think about the goals for your cloud-native architecture.

When designing the Rapid Docker on AWS architecture, we had one goal in mind: a production-ready infrastructure for everyone. We went through a long, iterative design process. We were inspired by numerous customer projects where customers asked us to minimize operational effort or shorten time to market. For years, we have been waiting for new AWS features that would help us achieve our ultimate goal. Now, we are happy to share our solution, which has the following benefits.

Low operational effort

All AWS building blocks used in the architecture described in this book are fully managed services causing minimal operational effort. You don't have to sign TLS certificates or install a database engine. You only have to care about your Docker image with your configuration, source code, and dependencies. AWS even takes care of your data by performing daily backups. AWS also covers security aspects, such as data encryption in-transit (using HTTPS/TLS) and at-rest. In a nutshell, you don't need highly specialized people on your team to operate the infrastructure.

Ready for the future

Architectures are not static anymore. An evolutionary architecture evolves with new requirements. When making use of infrastructure as code (IaC), you can deploy changes to your architecture with confidence. IaC enables you to test changes to your architecture before you apply them to production.

Cost-effective

In an ideal world, you only pay when your system is processing a user request. You never want to pay for idle resources. The architecture described in this book minimizes your costs for idle resources. The database can stop if not used, and you only run as few containers as possible to provide the needed performance.

Highly available

Sooner or later, a single point of failure causes an outage. This Rapid Docker on AWS architecture has no single point of failure and uses redundant components everywhere, from the load balancer to the multiple containers running on different hosts to the redundant database cluster.

Scalable

Your infrastructure is only as powerful as your weakest component. It is not sufficient to scale your web servers to handle a growing amount of requests. You have to scale your database as well. That's why the architecture described in this book scales the whole stack: the load balancer, the Docker containers running web servers, and the database.

Overview of the architecture

The main building blocks of the Rapid Docker on AWS architecture are:

• A load balancer: Application Load Balancer (ALB)
• Docker containers: Amazon ECS & AWS Fargate
• A database: Amazon Aurora Serverless (MySQL-compatible edition)

The following figure shows the high-level architecture:

Next, you will learn more about the main building blocks.

Application Load Balancer

The Application Load Balancer (ALB) distributes HTTP and HTTPS requests among a group of hosts. In our case, the hosts are Docker containers running a web server. An ALB is highly available and scalable by default, and it serves as the entry point into your infrastructure. The traffic flows from the client to your containers as follows:

1. The client makes an HTTP(S) request to the load balancer.
2. The load balancer receives the request and distributes it to one of the containers running a web server.
3. The containerized web server receives the request, does some processing, and sends a response.
4. The load balancer receives the response and forwards it to the client.
5. The client receives the response.

ALB pricing is based on two dimensions. First, you pay $0.0225 per hour (or partial hour) no matter how much traffic it serves. Second, you pay for the higher number of new connections, active connections, or traffic.

Continue on to learn about the Docker aspect of the architecture.

Amazon ECS & AWS Fargate

Amazon ECS is a fault-tolerant and scalable Docker container management service that is responsible for managing the lifecycle of a container. It supports two different modes or "launch types," one of which is AWS Fargate, which eliminates the need for managing a cluster of EC2 instances yourself. Instead, the cluster is managed by AWS, allowing you to focus on the containers rather than on the underlying infrastructure.

ECS is free of charge. Fargate pricing is based on the allocated vCPU and memory over time. A vCPU costs $0.04048 per hour and a GB of memory costs $0.004445 per hour. If you provision 0.25 vCPU and 0.5 GB memory for your container, it costs you $8.89 per month (30 days). To avoid a single point of failure, you should always run two containers at a time, totaling $17.78 per month. Pricing is per second with a minimum of 1 minute.

Amazon Aurora Serverless

Amazon Aurora Serverless is a highly available, scalable, MySQL 5.6-compatible relational database cluster. Depending on the load (CPU utilization and the number of connections), the cluster grows or shrinks within configurable boundaries. Aurora Serverless can scale down to zero when there are no connections for a configurable timespan.

Aurora Serverless pricing is based on three dimensions:

1. Compute and memory capacity measured in Aurora Capacity Units (ACUs). One ACU has approximately 2 GB of memory with an undocumented share of CPU and networking. You pay $0.06 per ACU per hour with a minimum of one ACUs per cluster. If the cluster is stopped you consume zero ACUs.
2. Storage: $0.10 per GB per month.
3. I/O rate: $0.20 per 1 million requests.

If your database is of modest size (e.g., 50 GB), you would pay $5 per month for storage. On average, two ACUs should be sufficient for a modest database, which costs another $86.40 per month if your database runs 24/7. However, many databases are not needed 24/7 and can be stopped if not used like dev systems or internal systems that are used during working hours only.

You have learned about a simple and powerful architecture for your web application consisting of an Application Load Balancer (ALB), ECS, Fargate, and Aurora Serverless.

Do you have any questions? Please leave them in the comments. This is the 1st post of a series. Follow me to make sure you are not missing the following posts.

This post is an excerpt from our new book Rapid Docker on AWS. The book includes code samples for PHP, Ruby (Rails), Python (Django), Java (Spring Boot), and Node.js (Express).