ECS vs EKS vs EC2 on AWS: Where Should You Deploy Your Containers?

Containerization has become integral to businesses aspiring to greater agility, accelerated innovation, and generally maintaining competitiveness. As more and more enterprises continue to use containerization, the question of which containers(ECS vs EKS vs EC2) to use has never been more important.

Containers are lightweight software components used to package an entire application—including its dependencies and configuration—which enable it to run as expected. Containers offer the following benefits, particularly when compared to alternative solutions like virtual machines (VMs):

• Container images have a faster startup time than VM images
• New container image snapshots are much faster than VM snapshot operations
• Containers are much smaller than VMs
• Containers are light
• Containers can run anywhere once built
• Containers have better resource utilization

Large enterprises could end up running thousands of containers over time, which all need to be deployed, managed, connected, and updated. With a few containers you can do this manually, but a large enterprise application in the cloud demands an entire team managing effective automation processes. The problem of managing multiple containers created a need for container orchestration platforms like Kubernetes and Amazon Elastic Container Service (Amazon ECS).

Kubernetes

Amazon ECS

For the last two years, Kubernetes has ranked as one of the most loved platforms among software developers. A container orchestration and container management tool, Kubernetes was designed to solve the challenges of automatically deploying, scaling, and managing containerized applications—making the jobs of technical teams a lot easier in the process.

In the AWS landscape, software teams and DevOps professionals have three approaches to choose from when it comes to running their containerized workloads. ECS vs EKS vs EC2:

• Amazon ECS: ECS is a fully managed container orchestration service that helps you easily deploy, manage, and scale containerized applications.
• Amazon Elastic Kubernetes Service (Amazon EKS): EKS is a Kubernetes service with a fully managed control plane.
• Amazon Elastic Compute Cloud (Amazon EC2): EC2 is a web service that provides secure, resizable compute capacity in the cloud. It can also be used to provision a Kubernetes cluster.

This article will compare these three container deployment options across the below points of contention to help determine the most suitable option for you, your application, and your team:

• Features
• Usability
• Cost
• Security
• Networking options

⚓️⚓️⚓️ Check out our other Kubernetes guides:

• cAdvisor and Kubernetes Monitoring Guide
• Kubernetes Cost Management and Analysis Guide
• Node Exporter and Kubernetes Guide
• Using Terraform to Deploy to EKS

ECS vs EKS vs EC2 (tl;dr)

EC2 in comparison

If you want to skip all the details, here is a quick tl;dr on each of the AWS services and when to use them:

When to Use ECS

• High performance and scalability out-the-box
• Accelerated development
• Integrations with AWS services
• Minimal management overhead
• Easy learning curve

When to Use EKS

• High performance and scalability out-the-box
• Accelerated development
• Integrations with AWS services
• Minimal management overhead
• Cluster portability (to some degree)
• Desired large open-source support
• Leverage K8s extensibility

When to Use EC2

• Experienced K8s operators
• Cluster portability
• Workload portability
• Local cluster development as part of the development lifecycle
• Multi-cloud strategy
• Leverage K8s extensibility

Amazon ECS

Amazon ECS

ECS is a highly efficient, scalable container orchestration platform for running container applications on a managed cluster of Amazon Elastic Compute Cloud (Amazon EC2) instances.

There are seven core components to ECS:

• Clusters: A cluster is a group of container instances that act as a single computing resource.
• Container instances: A container instance is an Amazon EC2 instance registered to be part of a specific cluster.
• Container agent: The container agent is an open-source tool ensuring an Amazon EC2 instance can register to your cluster.
• Task definition: A task definition describes how your application’s docker images should be run. It’s a JSON config file, so think of it as a docker-compose.yml file on steroids.
• Scheduler: The scheduler decides where a service or one-off task will run on your cluster by determining the optimal instance to run it on.
• Services: A service is a long-running task such as a web application, based on a task definition. You can specify how many instances of service will run, and ECS will ensure those services remain running.
• Tasks: A task is the end result of running a task definition. Short-lived operations such as batch jobs can be run as one-off or periodic tasks.

ECS with EC2 Launch Model vs. ECS with Fargate Launch Model

The EC2 launch model allows operators to take control of the underlying infrastructure for container workloads. These are referred to as container instances and are fully configurable. Users can define the instance types, as well as set scaling parameters using Auto Scaling Groups (ASGs). This ownership approach means that teams are responsible for security patches and network security when it comes to their container instances.

Fargate is a serverless engine that offloads the burden of managing infrastructure from users, allowing software teams to focus on optimizing their container applications. The scalability and availability of your container applications are managed by AWS. This model works especially well for workloads that suit serverless tasks.

ECS Pricing

Pricing for the EC2 launch model scales on usage—the more you use it the more it costs. Usage refers to all the AWS resources that you create to store and run your applications, such as EC2 instances, EBS volumes, etc. You can review our AWS ECS pricing and container optimization guide to get a more in-depth overview.

Pricing for the Fargate launch type is based on the amount of vCPU and memory resources that your containerized application uses. vCPU and memory resources are calculated from the time your container images are pulled until the ECS Task is terminated.

Estimating costs for your containerized workloads is imperative when running applications in the cloud. This is especially important when costs scale with usage like ECS—software teams need to be able to plan and manage resource utilization carefully in accordance with their budgets.

ECS Security and Networking

Securing your ECS cluster and the services running on them is managed using AWS Identity and Access Management (IAM). AWS resources must be associated with an IAM service role that has specific permissions (outlined in a policy) to determine which services they can talk to. This model enables high degree security, assuming operators comply with the least privilege principle when it comes to granting permissions.

When it comes to networking, ECS clusters are deployed in an AWS VPC. You can configure your ECS environment to be private and secure to the AWS network by making use of VPC endpoints; any traffic between ECS and other services will not leave the AWS network as a result.

Alternatively, operators can configure their VPC to have an internet gateway deployed, along with the relevant route table configurations to allow traffic that passes through the public Internet.

ECS Advantages

ECS offers native out-of-the-box support with other AWS services, allowing for easy integration between container applications and other AWS components.

A lot of the core functionality of ECS resides within the control plane. This is abstracted away from operators, making it much easier to focus on simpler, core aspects of the service. The management overhead that teams deal with depends on the model they choose: the serverless engine (Fargate), or the managed EC2 container instances.
Overall, the services that operators will engage with are relatively simple to get up and running—without losing much time.

ECS Disadvantages

• Vendor lock-in – Running your applications in containers gives you the flexibility of workload portability. However, container applications in production will typically fit within a larger architecture design. In the context of ECS, this could easily result in several nested integrations with other AWS services which encloses your overall solution within the AWS ecosystem.

Amazon EKS

*Amazon EKS

Amazon EKS is a managed service that allows you to run Kubernetes on AWS—without the need to set up, provision, or maintain your own control plane. EKS is Kubernetes compliant and has a managed control plane.

AWS is responsible for provisioning, running, managing, and auto scaling the Kubernetes master and etcd nodes across multiple AWS AZs (Availability Zones) for high availability. Users are responsible for adding and managing the EC2 worker nodes, unless they opt for the Fargate serverless engine. Amazon EKS clusters run within Amazon VPCs.

EKS Pricing

EKS users pay $0.10 per hour for each Amazon EKS cluster that gets created. If operators opt for the EC2 launch model, any additional costs are based on the AWS resources (EC2 instances) created to run the Kubernetes worker nodes.

If operators use the Fargate launch model, pricing is calculated based on the vCPU and memory resources used from the time you start to download your container image, until the Amazon EKS pod is terminated.

Whichever launch model you opt for, a tool like CloudForecast’s Barometer helps eliminate over-provisioned clusters that might be costing you unnecessary money. CloudForecast does this by providing visibility into CPU and memory usage by cluster, in relation to your AWS cost.

EKS Security and Networking

Kubernetes is API-centric. All of the interaction that takes place between different clients and the API Server is REST-based in order to carry out various CRUD operations. Clients interacting with the API Server range from the engineers using the kubectl CLI, to nodes that have the kubelet (a node agent) running. The rest of the control plane—the scheduler and the controllers—are always talking to the API Server as well.

However, Kubernetes doesn’t have an internal system to store and manage user accounts—users are created and managed outside the cluster. So how does the authentication flow work? Incoming client requests have credentials embedded (or attached to them) and passed off to an external authentication system to validate the user.

Authorization follows a successful user validation, determining what permissions each user has in relation to the different resources on the cluster. Role-based access control (RBAC) is the method which regulates user access. IAM users and roles can be mapped to RBAC roles and service accounts that nodes and pods can assume to regulate permissions.

Now let’s talk networking. In order to communicate with the cluster, you have to configure it to either have public endpoint access control, private endpoint access control—or both. These various networking modes determine how network traffic occurs between worker nodes and the cluster control plane, as well as how operators interact with the cluster’s API server.

EKS has a native network VPC CNI plugin; this integrates the cluster’s networking with the VPC that the worker nodes run in. This network CNI plugin can be uninstalled if operators opt to use alternative CNI plugins like Calico .

EKS Advantages

Similar to ECS, EKS workloads can seamlessly integrate with other AWS services.

Kubernetes as a platform is infrastructure-agnostic. As such, workloads running in other Kubernetes clusters can be migrated to EKS.

Kubernetes is a highly extensible platform. Since EKS is a CNCF-certified Kubernetes distribution, this extensibility is available to software developers using EKS. This allows operators to add more resources in the form of custom resource definitions, which can also be created and used through interaction with the Kubernetes API server.

EKS allows software teams to make use of the vast open-source support from other practitioners in the Kubernetes ecosystem. Plus, cloud-native software tools can be used to help use Kubernetes efficiently, reducing its complexity.

EKS is provisioned with an AWS network VPC CNI plugin which integrates the Kubernetes cluster networking with your AWS VPC.

EKS Disadvantages

Kubernetes, as an orchestration tool, has a complex set of architectural components. Operators and developers will need to have a good understanding of these various components and how they interact to optimize Kubernetes applications.

Amazon EC2

EC2 is designed to make web-scale cloud computing easier for businesses and developers. As a service, it provides the necessary resources for organizations who want a custom Kubernetes cluster in the cloud.

There are a variety of tools that can be used to simplify the process of provisioning a cluster. Some of these tools include Rancher Kubernetes Engine (RKE), K3s , kubeadm , and kOps .

EC2 Pricing

If you opt to use EC2 instances for your Kubernetes cluster, you’ll have five different launch model options to choose from. These options include On-Demand, Savings Plans, Reserved Instances, and Spot Instances. You can also pay for Dedicated Hosts, providing you with EC2 instance capacity on physical servers dedicated to your use.

EC2 Security and Networking

Similar to EKS, security in a custom Kubernetes cluster in the AWS environment can be managed using the aws-auth ConfigMap . This is used to map IAM roles and users to RBAC roles and service accounts in the cluster. Other resources running in the cluster can be associated with service accounts; these can be attached to roles using role bindings.

In terms of networking, provisioning a custom Kubernetes cluster using EC2 instances will have to be done in a VPC (just like ECS and EKS solutions). Additionally, the other networking components selected as part of the architecture will depend on the cluster requirements.

This includes the networking mode for the cluster’s API server, any load balancers used to support traffic management, and whether or not containers will run in both public and private subnets of the VPC.

EC2 Kubernetes Cluster Advantages

Provisioning a custom Kubernetes cluster complements its infrastructure-agnostic architecture. It’s also easier for operators to move workloads to a different environment, such as on-premises.

Managing your own cluster control plane significantly reduces the cost implications of AWS managing this component of your Kubernetes architecture.

A custom Kubernetes cluster complements the local development life cycle. This allows teams to have a local version of the cluster, enabling minimal disparity and configuration drift from the remote cluster running in the cloud.

EC2 Kubernetes Cluster Disadvantages

Software teams are responsible for full ownership of the control plane and ETC nodes. This adds overhead and administrative tasks to achieve optimal cluster functionality at scale.

Operators will need adequate proficiency to successfully administer and manage a Kubernetes cluster in a production environment.

Software teams have to deal with the technical complexities of full Kubernetes architecture ownership in order for workloads to run as expected once deployed.