Containers are used to host code without the complexity and resource demands of virtual machines. They allow developers to combine code and dependencies into a standardized package that runs anywhere, making them the ideal foundation for cloud-native applications and microservices.

But containers pose a problem. How do developers and DevOps professionals manage container creation, hosting, networking, and security? A business may deploy dozens of containers to host its apps and services. It’s challenging to manage all of them individually, so, ideally, container management should be automated.

That’s the role of container orchestration software. Container orchestration tools manage the container lifecycle: provisioning, deployment, scaling, networking, and more. Kubernetes—originally developed by Google—is one of the most widely used container orchestration tools.

Amazon Web Services offers a number of container and container orchestration services, including Amazon Fargate, Amazon Elastic Container Service (ECS), and Amazon Elastic Kubernetes Service (EKS). Although all play a role in container hosting and orchestration, they are not identical, and it can be a challenge to understand which is the right orchestration tool for your AWS environment.

This article focuses on the differences between the main AWS container orchestration services: ECS and EKS, and on container security more generally. But to understand those, we have to start with Amazon Fargate.

What is Amazon Fargate?

Amazon Fargate is a serverless infrastructure platform for containers. In this context, “serverless” doesn’t mean containers don’t run on servers. It means the user doesn’t have to concern themselves with managing and paying for servers. Instead, they pay for just the compute resources their containers consume.

It’s useful to contrast Amazon Fargate to EC2, Amazon’s virtual server platform. To host containers on EC2, you have to provision EC2 instances with specific storage, compute, and memory capacities; configure them to run containers securely, and then manage both the containers and the EC2 instances. You pay the full cost of the instances while they’re running.

In contrast, Amazon Fargate allows you to build container images, specify memory and compute resources, and deploy. You don’t have to manage, configure, or scale servers, and you only pay for the compute resources your containers consume.

You’ll note that we’ve not mentioned container orchestration yet. That’s because Amazon Fargate is not a container orchestration service. It’s a serverless container platform on which you can deploy containers managed by a container orchestration service. On AWS, you have two main orchestration options to manage containers running on Fargate: ECS and EKS.

What is Amazon ECS?

Amazon ECS is a managed container orchestration service that runs Docker and Windows containers. It offers a complete orchestration solution with support for Docker image repositories, versatile container deployment and management tools, networking services including service discovery, and container monitoring and logging via Amazon CloudWatch and CloudTrail.

By default, ECS deploys containers to Fargate, although it can manage containers hosted on EC2 or on-premises infrastructure with ECS Anywhere or AWS Outposts. That makes it an excellent choice for businesses that want a fully managed solution and that don’t need Kubernetes compatibility.

It’s important to note that Amazon ECS is based on proprietary Amazon technology. It is not fully portable between cloud platforms.

What is Amazon EKS?

Amazon EKS is a managed Kubernetes service to orchestrate containers hosted in AWS and on-premises. Like ECS, it can orchestrate containers running on AWS Fargate and on EC2 instances. The key benefit of EKS is that it is fully compatible with Kubernetes—it’s based on upstream Kubernetes, so clusters that run on-premises or on other cloud vendor platforms can be moved to EKS with no modification.

Amazon EKS vs Amazon ECS: Choosing A Container Service

The most important distinction between ECS and EKS is that EKS runs Kubernetes. If your business relies on the tooling and architecture provided by Kubernetes, then EKS is probably the best choice. EKS also provides more granular control over how containers are managed, but more control leads to greater complexity.

In contrast, ECS is a simpler container orchestration system. It is intended for businesses that don’t want or need granular control over every aspect of container deployment and management. ECS also integrates tightly with other AWS services, such as CloudWatch and Route 53. That’s a benefit if you want to use those tools, but a drawback if you’d prefer to use different tooling.

AWS Container Security Best Practices

Whichever AWS container orchestration tool you select, your organization is responsible for securing containers and the code and data they contain. As with servers, container misconfiguration is a significant risk vector. Amazon Fargate helps to reduce risk because users don’t manage the underlying server and network infrastructure. However, businesses must nevertheless follow container security best practices.

Use Minimal Images

Containers should run as little code as is practical. Each additional library or service increases the attack surface area. Ideally, containers include only your code and its essential runtime dependencies, excluding development dependencies and other redundant code. If possible, use distroless images or a security-focused lightweight distribution such as Alpine.

Minimal images are also significantly smaller, which means they consume fewer resources and are easier to audit and scan for security purposes.

Use Curated Images from a Secure Container Repository

Image repositories are a potential source of malicious code. It’s estimated that 20% of the most popular images in major public repositories contain vulnerable or malicious code.

Bad actors seeking to infiltrate malware may target insecure public and private repositories in so-called supply-chain attacks. If they can get malicious code into an image hosted in a container repository, that code may find its way inside your networks.

To combat this risk, businesses should create a set of curated images free of known security vulnerabilities. They should store images in a secure repository service, such as Amazon Elastic Container Registry. ECR integrates securely with Amazon ECS and Amazon EKS, and it allows users to create repositories with access permissions managed by AWS Identity and Access Management (IAM).

Don’t Run Containers or Processes Within Containers as Root

Containers should not run as the root user and nor should processes within the container.

• If a process running as root is compromised, the attacker may use root privileges to modify the container’s contents.
• If the container itself runs as root, a bad actor may be able to escalate their privileges on the container’s host operating system in the unlikely event of a container breakout.

Unfortunately, containers often run as the root user by default, so Dockerfiles should be modified to use the USER directive to specify a non-root user.

Don’t Hardcode Credentials

Avoid hardcoding credentials such as passwords or API keys in code that will run in a container, including AWS credentials. If systems that store or process the code are compromised, an attacker will gain access to the credentials.

AWS provides several methods for storing secrets and securely injecting them into containers, including the AWS Secrets Manager. Secrets Manager also enables users to easily rotate secrets, which may not be possible when they are included in production code.

To learn more about container security and all aspects of AWS security, visit our extensive library of AWS security resources.