AWS is a large ecosystem that hosts different types of apps, and one of the formats of apps that can be deployed in AWS is containers (link to Docker).
Containers improve the speed of deployment and make it more efficient than the traditional methods of installing the runtime of a programming language and managing the dependencies within the virtual machine. So it is advisable to use containers for deployment.
In AWS, there are various options for deploying containers. Each service for deploying containers is unique in pricing, functionality, scalability, and deployment model.
- Lightsail Containers
- AWS App Runner
- Elasticbeanstalk
- AWS Lambda
- Amazon ECS
- Amazon EKS
Lightsail Containers
Lightsail is a family of services on AWS with a unique pricing model compared to more popular services on AWS. For example, a Lightsail VPS server costs starts at $5/month, capped. This makes billing more predictable.
Lightsail Container is a managed container management and orchestration platform that makes it easy and fast for anyone with little or no experience to deploy a container workload on AWS. It has a simple and intuitive interface that requires minimal configuration to get a container up and running. It skips all the BS of networking, load balancing, and all the things you find in more complex services like ECS and EKS.
Just like its VPS counterparts, Lightsail has a predictable pricing model based on the compute resources selected to deploy.
If you are starting with Container deployments in AWS and you need something managed that saves time without the need to understand the complex AWS Infrastructure, then. Lightsail Container is your go-to tool. You can watch how to set up a Lightsail Container app here.
Lightsail Containers have a brother that is very similar in simplicity and speed, but sits inside the AWS Console. The service is called AWS App Runner.
AWS App Runner
Not very popular and not commonly used, Apprunner is a simple container orchestration tool for deploying microservices very easily. It is a little more advanced than Lightsail but not as advanced and complex as ECS and EKS. Unlike Lightsail, which has its unique console UI, App Runner resides in the AWS Management Console. It has more features compared to Lightsail and uses the core AWS services to run, such as VPC, Elastic Load Balancer, and integrates seamlessly with AWS WAF to provide higher security to container workloads.
It has a simple step-by-step interface setup that makes it easy to deploy a container within seconds and get it up and running with a public URL for accessibility.
You can read more about using AWS App Runner in a previous post I did here.
The next is a rare deployment option that I have barely encountered in my career, but it exists. It uses Elastic Beanstalk to deploy containers.
Elasticbeanstalk
AWS Elastic Beanstalk simplifies deploying and managing containerized applications by automating the provisioning and scaling of infrastructure. It supports Docker containers, allowing you to deploy either a single container or multi-container applications using Docker Compose.
Elastic Beanstalk handles tasks such as load balancing, scaling, and monitoring, freeing developers from infrastructure management. You provide a Dockerfile or a prebuilt container image, and Elastic Beanstalk deploys it on Amazon EC2 instances within an environment. It supports integration with services like Amazon RDS for databases and Elastic Load Balancing for traffic distribution.
Elastic Beanstalk also offers a high level of customization, enabling developers to configure EC2 instances, specify environment variables, and manage application lifecycle policies. It supports rolling updates to ensure minimal downtime during deployments.
With its flexibility, Elastic Beanstalk is well-suited for both development and production workloads, providing a streamlined path to deploy containerized applications while maintaining control over the underlying infrastructure.
This next option is used mostly by Serverless and Lambda lovers. It is deploying Containers on AWS Lambda
AWS Lambda
AWS Lambda supports container-based deployment, allowing developers to package applications and dependencies into container images. This is ideal for use cases requiring specific dependencies, custom runtimes, or larger deployment packages (up to 10 GB). Containers must adhere to Lambda’s runtime interface specifications, ensuring smooth integration with the service.
Once deployed, Lambda provisions resources automatically to execute the containerized function in response to events, scaling dynamically based on demand. This eliminates the need for managing servers, infrastructure, or scaling logic. Containers offer flexibility for porting applications, as they provide a consistent environment across development and deployment. Additionally, AWS Lambda integrates with services like Amazon ECR for container storage, simplifying deployment pipelines.
By combining serverless architecture with the flexibility of containers, Lambda enables efficient, cost-effective, and scalable application deployment without compromising control over runtime and dependencies.
To deploy a container on Lambda might require some extra work to make it work effectively. But there is another option in AWS that goes a step higher to give more flexibility to the deployment process of a container on AWS
Amazon ECS
This is the AWS flagship container orchestrator. It has been around for quite a while. ECS was launched in 2014. It was a game changer in AWS because before ECS, Docker compose was the go-to solution for orchestrating containers, and it was done inside an EC2 instance with no control plane to effectively manage the containers’ life cycle.
The ECS system is made up of the following components:
– Task Definition: define workload parameters
– Task: a running deployment
– Service: expose a task on the network layer, public/private
– Container: the smallest unit of a running workload
ECS started with the EC2 deployment models. This model uses EC2 as its worker nodes for hosting containers, while the ECS control plane is abstracted from the user. This means you have to manage the EC2 instance and all that comes with it. Such as: patch updates, network security, vulnerability scan, and fixes. You also get to choose the specific instance type based on the workload you want to deploy to AWS. It also provides features such as automated scaling, load balancing, and self-healing
In 2017, AWS announced ECS Fargate, which is a Serverless deployment model on ECS. Fargate eliminates the need for an EC2 instance and saves time and operational complexity involved in managing EC2 instances. Although Fargate has some limitations that do not exist in EC2, it has use cases for so many application scenarios, which makes it a good deployment model on ECS. It is easy to use, fast to set up, and less complex to manage. It uses services like the EC2 model, such as VPC, Load Balancer, for its setup.
ECS is widely used by small and medium-scale enterprises for deploying web application workloads, API-based workloads, and various types of applications. It has autoscaling features that make it handle load efficiently and integrates easily with other AWS services.
The last on the list here is Amazon EKS, which is one of the most advanced and complex tools for container orchestration and management.
Amazon EKS
Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service that simplifies deploying, managing, and scaling containerized applications. With EKS, containers are orchestrated using Kubernetes, providing features like automated scaling, load balancing, and self-healing.
EKS manages the Kubernetes control plane, ensuring high availability and reliability while offloading complex administrative tasks such as patching, upgrading, and securing Kubernetes. Developers define their containerized workloads in Kubernetes manifests (e.g., Deployments, Services), and EKS ensures they are deployed and maintained across worker nodes, which can be EC2 instances or AWS Fargate for serverless execution.
EKS integrates seamlessly with AWS services like Elastic Load Balancing, IAM for security, CloudWatch for monitoring, and Amazon ECR for container storage. It supports hybrid and multi-cloud environments, enabling workloads to run consistently across on-premises and cloud infrastructure.
This platform is ideal for complex, large-scale, or highly available applications requiring the advanced capabilities of Kubernetes, while AWS handles the heavy lifting of infrastructure management.
Conclusion
The reason for the multiple options for deploying containers on AWS is to give variety to pick what best suits your organisation based on cost, technical capacity, and growth trajectory of the business. The best advice will be to start with the less complex tools and move up to more complex options as your system grows and when it requires it.
