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.

AWS’s compute and data storage services are the beating heart of tens of thousands of businesses. That makes AWS security and compliance a matter of critical concern. It’s all too easy to make a configuration mistake that opens the door to bad actors intent on stealing data and infiltrating malware. For example, estimates put the proportion of misconfigured buckets on Amazon’s Simple Storage Service (S3) at 46%.

In this article, we’re going to look at five of the most common AWS security mistakes and show you how to check if your AWS environment is vulnerable.

How Secure Is AWS?

AWS is a secure cloud platform. However, no platform can be totally secure. AWS is incredibly flexible, but that flexibility gives you the power to shoot yourself in the foot. Cloud users can’t rely on Amazon to take care of all security risks. Responsibility for cloud security is shared between the platform and the user, and who is responsible for what depends on the service. 

AWS’s EC2 infrastructure-as-a-service platform puts more responsibility on users than a platform-as-a-service such as Elastic Beanstalk. But user misconfigurations can create security vulnerabilities on any cloud service, which is why user error causes all of the common security problems we’ll discuss here today.

To learn more about the cloud shared security model, read Who’s Responsible for Cloud Security?

Storing Data in S3 Buckets or EBS Volumes without Encryption

Encryption at rest and in transit makes data worthless to bad actors—even if it is leaked or intercepted. All Amazon data storage services offer strong encryption, but many users fail to activate it.

S3 provides various server-side encryption options alongside key management solutions that simplify the use of encryption keys,  but users can choose to store data unencrypted. Elastic Block Storage offers encryption for data at rest, in transit, and for snapshots, but users can select unencrypted volumes, creating a risk of accidental misconfiguration that could expose sensitive data.

Configuring S3 Buckets with Public Availability

As we mentioned in the introduction, misconfigured S3 buckets cause numerous data leaks. S3 is an object storage service. Data is stored in buckets, and each bucket has configurable access permissions. By default, buckets are private so that only accounts given explicit permission can access them.

However, buckets can, and often are, configured so that anyone on the internet can access them and the data they contain. Sometimes this is a genuine mistake, but buckets are usually made publicly accessible because the user finds it convenient to circumvent access controls. S3 configuration errors have, on many occasions, exposed highly sensitive data on the open internet.

Connecting EC2 Instances Directly to the Internet

There are legitimate reasons to assign EC2 instances a public IP address, but, in most cases, they should be deployed on an internal network with access limited to other resources under your control. For example, if you host a web application’s database server on an EC2 instance, it should not be directly connected to the internet. Access should be mediated by firewalls and limited to web or application servers that need to request data.

Leaving Insecure Ports Open

Software services running on a server connect to the network via a numbered port. Many services use a standard port: SSH on Port 22 or HTTP on Port 80. Several services are widely recognized as insecure, either because they send data unencrypted or they contain software vulnerabilities. FTP (21), Telnet (23), and SNMP (161) are in this category. Ideally, these services should not run on EC2 instances, and the associated ports should be blocked by AWS security groups and network access control lists.

Not Using Multi-Factor Authentication MFA

Although AWS’s Identity and Access Management (IAM) service allows authentication with only a username and password, it is recommended that all users take advantage of multi-factor authentication (MFA). MFA requires users to provide additional authentication factors, which might be a one-time code sent to a mobile device or a hardware security key. MFA eliminates the risk that leaked passwords or brute-force attacks could give bad actor access to your AWS account.

How To Identify Security Risks in Your AWS Environment

We’ve covered the five most common AWS security mistakes, but our list is far from exhaustive. There are many more mistakes and misconfigurations that create risk for your business’s data and infrastructure. 

There are two ways you might go about finding and fixing AWS security mistakes.

  1. Manually assess all of your infrastructure and configurations for security vulnerabilities.
  2. Use the KirkpatrickPrice AWS Scanner, which performs over 50 checks automatically, including checks for the cloud security mistakes we’ve discussed in this article.

The AWS Scanner, part of our comprehensive AWS security and compliance services, quickly and reliably highlights sources of risk, giving you the information you need to secure your AWS infrastructure. Sign up today or contact an AWS security and compliance expert to learn more.