Amazon Elastic Kubernetes Service

Amazon Elastic Kubernetes Service (Amazon EKS) is a fully managed Kubernetes service. Kubernetes is an open-source system for automating the deployment, scaling, and management of containerized applications. Amazon EKS runs Kubernetes control plane instances across multiple Availability Zones to ensure high availability. Amazon EKS automatically detects and replaces unhealthy control plane instances, and it provides automated version upgrades and patching for them.

It allows customers to run your EKS clusters using AWS Fargate, which is a serverless compute for containers. Fargate manages servers, the way customers specify it.
EKS is integrated with services including Amazon CloudWatch, Auto Scaling Groups, AWS Identity and Access Management (IAM), and Amazon Virtual Private Cloud (VPC). These integrations enable seamless experience to monitor, scale, and load-balance your applications.
EKS integrates with AWS App Mesh and provides a Kubernetes native experience to consume service mesh features and bring rich observability, traffic controls and security features to applications.

Table of Contents

Amazon Elastic Kubernetes Service Features

Amazon EKS is a managed service that makes it easy for customers to run Kubernetes on AWS without needing to install, operate, and maintain their own Kubernetes control plane or nodes. Kubernetes is an open-source system for automating the deployment, scaling, and management of containerized applications.

Amazon EKS runs Kubernetes control plane instances across multiple Availability Zones to ensure high availability. Amazon EKS automatically detects and replaces unhealthy control plane instances, and it provides automated version upgrades and patching for them.

Amazon EKS is integrated with many AWS services to provide scalability and security for your applications, including the following:

Amazon ECR for container images
Elastic Load Balancing for load distribution
IAM for authentication
Amazon VPC for isolation

High Availability

EKS runs the Kubernetes management infrastructure across multiple AWS Availability Zones, automatically detects and replaces unhealthy control plane nodes, and provides on-demand, zero downtime upgrades and patching.

Serverless option

EKS supports AWS Fargate to provide server-less compute for containers. Fargate removes the need to provision and manage servers, lets customers specify and pay for resources per application, and improves security through application isolation by design.

Secure

EKS automatically applies the latest security patches to customers cluster control plane. AWS also works closely with the community to ensure critical security issues are addressed before new releases and patches are deployed to existing clusters.

Built with the Community

EKS runs upstream Kubernetes and is certified Kubernetes conformant, so applications managed by EKS are fully compatible with applications managed by any standard Kubernetes environment. AWS actively works with the Kubernetes community, including making contributions to the Kubernetes code base that help customers take advantage of AWS services and features.

Amazon EKS automatically manages the availability and scalability of the Kubernetes control plane nodes that are responsible for starting and stopping containers, scheduling containers on virtual machines, storing cluster data, and other tasks. Amazon EKS automatically detects and replaces unhealthy control plane nodes for each cluster.

Amazon EKS provides a scalable and highly-available control plane that runs across multiple AWS availability zones.
Amazon EKS lets customers create, update, or terminate worker nodes for their cluster with a single command.

Kubernetes clusters are integrated with AWS services and technology partner solutions, that allows services such as IAM to provide fine-grained access control and Amazon VPC isolates the Kubernetes clusters from other customers.

Using AWS Cloud Map, a cloud resource discovery service, customers can define custom names for their application resources, then Cloud Map maintains the updated location of these dynamically changing resources.
Customers can also Service mesh to build and run complex microservices applications by standardizing how every microservice in the application communicates. AWS App Mesh is an AWS service that makes it easy to configure part of the application for end-to-end visibility and high-availability.
Since EKS clusters run in an Amazon VPC, customers can use their own VPC security groups and network ACLs. With that customers get a high level of isolation and help them use Amazon EKS to build highly secure and reliable applications.
Customers can assign RBAC roles directly to each IAM entity, which gives them the ability to granularly control access permissions to Kubernetes masters.
Amazon EKS enables customers to assign IAM permissions to their Kubernetes service accounts. Which helps them control access to other containerized services, AWS resources external to the cluster such as databases and secrets, or third party services and applications running outside of AWS.

Customers can use EKS on AWS Outposts to run containerized applications that require particularly low latencies to on-premises systems. AWS Outposts is a fully managed service that extends AWS infrastructure, AWS services, APIs, and tools to virtually any connected site.

With EKS on Outposts, customers are able to manage containers on-premises.

Amazon EKS is integrated with AWS CloudTrail to provide visibility and audit history of customer cluster and user activity.

AWS CloudTrail can be used to view API calls to the Amazon EKS API. Amazon EKS also delivers Kubernetes control plane logs to Amazon CloudWatch.

An Amazon EKS cluster consists of two primary components: The Amazon EKS control plane and Amazon EKS worker nodes that are registered with the control plane

The Amazon EKS control plane consists of control plane nodes that run the Kubernetes software, such as etcd and the Kubernetes API server. The control plane runs in an account managed by AWS, and the Kubernetes API is exposed via the Amazon EKS endpoint associated with the customers cluster.
- Each Amazon EKS cluster control plane is single-tenant and unique, and runs on its own set of Amazon EC2 instances.
Amazon EKS worker nodes run in your AWS account and connect to your cluster’s control plane via the API server endpoint and a certificate file that is created for your cluster.

Worker Nodes

Amazon EKS integrates Kubernetes with AWS Fargate by using controllers that are built by AWS using the upstream, extensible model provided by Kubernetes. These controllers run as part of the Amazon EKS managed Kubernetes control plane and are responsible for scheduling native Kubernetes pods onto Fargate. The Fargate controllers include a new scheduler that runs alongside the default Kubernetes scheduler in addition to several mutating and validating admission controllers.

The Kubernetes Cluster Autoscaler automatically adjusts the number of nodes in customers cluster when pods fail to launch due to lack of resources or when nodes in the cluster are underutilized and their pods can be rescheduled onto other nodes in the cluster. There are several types of Kubernetes autoscaling supported in Amazon EKS:

Cluster Autoscaler:- The Kubernetes Cluster Autoscaler automatically adjusts the number of nodes in your cluster when pods fail to launch due to lack of resources or when nodes in the cluster are underutilized and their pods can be rescheduled on to other nodes in the cluster.
Horizontal Pod Autoscaler:- The Kubernetes Horizontal Pod Autoscaler automatically scales the number of pods in a deployment, replication controller, or replica set based on that resource’s CPU utilization.
Vertical Pod Autoscaler:- The Kubernetes Vertical Pod Autoscaler automatically adjusts the CPU and memory reservations for your pods to help “right size” your applications.

Customers can deploy one or more worker nodes into a node group. Nodes are Worker machines in Kubernetes. Amazon EKS worker nodes run in customers’ AWS accounts, and it connects their cluster’s control plane via the cluster API server endpoint. A node group is one or more Amazon EC2 instances that are deployed in an Amazon EC2 Auto Scaling group.

A cluster can contain several node groups, and each node group can contain several worker nodes. The managed node groups are able to have a maximum number of nodes. All instances in a node group must:

Be the same instance type
Be running the same Amazon Machine Image (AMI)
Use the same Amazon EKS Worker Node IAM Role.

Amazon EKS provides a specialized Amazon Machine Image (AMI) called the Amazon EKS-optimized AMI. This AMI is built on top of Amazon Linux 2, and is configured to serve as the base image for Amazon EKS worker nodes.

The AMI is configured to work with Amazon EKS out of the box, and it includes Docker, kubelet, and the AWS IAM Authenticator. The AMI also contains a specialized bootstrap script that allows it to discover and connect to the customers cluster’s control plane automatically.

Kubernetes vs Docker

What is elastic Kubernetes service?

Kubernetes is open source software that allows customers to deploy and manage containerized applications at scale. Kubernetes groups containers into logical groupings for management and discoverability, then launches them onto clusters of EC2 instances. Using Kubernetes customers can run containerized applications including microservices, batch processing workers, and platforms as a service (PaaS) using the same tool set on premises and in the cloud.

What is Docker

Docker is a software platform that allows customers to build, test, and deploy applications quickly. Docker packages software into standardized units called containers that have everything the software needs to run including libraries, system tools, code, and runtime. Using Docker, AWS customers can quickly deploy and scale applications into any environment and know their code will run.

Running Docker on AWS provides developers and admins a highly reliable, low-cost way to build, ship, and run distributed applications at any scale. AWS supports both Docker licensing models: open source Docker Community Edition (CE) and subscription-based Docker Enterprise Edition (EE).

Why do we need Kubernetes?

Kubernetes provisions and scales the the control plane, including the API servers and back end persistence layer, across multiple AWS availability zones for high availability and fault tolerance. Amazon EKS automatically detects and replaces unhealthy control plane nodes and provides patching for the control plane. Customers can run EKS using AWS Fargate, which is serverless compute for containers.

Fargate removes the need to provision and manage servers, lets them specify and pay for resources per application, and improves security through application isolation by design. Amazon EKS is integrated with many AWS services to provide scalability and security for your applications. These services include Elastic Load Balancing for load distribution, IAM for authentication, Amazon VPC for isolation, and AWS CloudTrail for logging.

How does Amazon EKS work?

Amazon EKS works by provisioning (starting) and managing the Kubernetes control plane and worker nodes for customers. At a high level, Kubernetes consists of two major components – a cluster of ‘worker nodes’ that run customers containers and the control plane that manages when and where containers are started on their cluster and monitors their status.

Without Amazon EKS, customers have to run both the Kubernetes control plane and the cluster of worker nodes themselves. With Amazon EKS, customers provision their worker nodes using a single command in the EKS console, CLI, or API, and AWS handles provisioning, scaling, and managing the Kubernetes control plane in a highly available and secure configuration. This removes a significant operational burden for running Kubernetes and allows customers to focus on building applications instead of managing AWS infrastructure.

What is the difference between ECS and EKS?

Both ECS and EKS are AWS managed services. Thus the control plane is abstracted from customers, as such they don’t have any control nor visibility on the underlying instances that run those control planes.

Using Amazon EKS, customers can deploy, manage, and scale containerized applications running on Kubernetes on AWS. Amazon EKS runs the Kubernetes management infrastructure for customers across multiple AWS Availability Zones to eliminate a single point of failure. Amazon EKS is certified Kubernetes-conformant, so customers can use existing tooling and plugins from partners and the Kubernetes community. Applications running on any standard Kubernetes environment are fully compatible and can be migrated to Amazon EKS.

AWS customers pay $0.10 per hour for each Amazon EKS cluster that they create. They can use a single Amazon EKS cluster to run multiple applications by taking advantage of Kubernetes namespaces and IAM security policies. Customers can run EKS on AWS using either EC2 or AWS Fargate, and on premises using AWS Outposts.

If you are using EC2 (including with EKS managed node groups), you pay for AWS resources (e.g. EC2 instances or EBS volumes) you create to run your Kubernetes worker nodes. Customers only pay for what they use, as they use it; there are no minimum fees and no upfront commitments.

Amazon EKS on Fargate

For those customers who are using AWS Fargate, pricing is calculated based on the vCPU and memory resources used from the time they start to download their container image until the Amazon EKS pod terminates, rounded up to the nearest second. A minimum charge of 1 minute applies. See detailed pricing information on the AWS Fargate pricing page.

Amazon EKS on AWS Outposts

Amazon EKS on AWS Outposts pricing is simple and works the same as it does in the cloud: the Amazon EKS cluster is deployed in the cloud (not on Outposts) and customers pay $0.10 per hour. Their Kubernetes worker nodes run on the capacity provided by Outposts EC2 at no additional charge.

Amazon ECS

Amazon Elastic Container Service (Amazon ECS) allows customers to easily run, scale, and secure Docker container applications on AWS. Applications packaged as containers locally will deploy and run in the same way as containers managed by Amazon ECS. Amazon ECS eliminates the need to install, operate, and scale your own container orchestration and cluster management infrastructure, and allows them to focus on the resource needs and availability requirements of the containerized application.

Amazon ECS enables customers to grow from a single container to thousands of containers across hundreds of instances without creating additional complexity in how they run their application. AWS customers can run anything: applications, batch jobs, or microservices. Amazon ECS abstracts away all the complexity of the infrastructure so they can focus on designing, building, and running containerized applications.

There are two different charge models for Amazon Elastic Container Service (ECS). Amazon ECS on AWS Outposts follows the same model as EC2 Launch Type.

Fargate Launch Type Model

With Fargate, customers pay for the amount of vCPU and memory resources that their containerized application requests. vCPU and memory resources are calculated from the time they container images are pulled until the Amazon ECS Task* terminates, rounded up to the nearest second. A minimum charge of 1 minute applies.

EC2 Launch Type Model

There is no additional charge for EC2 launch type. AWS customers pay for AWS resources (e.g. EC2 instances or EBS volumes) they create to store and run your application. The only pay for what they use, as they use it; there are no minimum fees and no upfront commitments.

What is Amazon Fargate?

AWS Fargate is a technology that AWS customers can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. With Fargate, they no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale their clusters, or optimize cluster packing.

When customers run their Amazon ECS tasks and services with the Fargate launch type or a Fargate capacity provider, the package they application in containers, specify the CPU and memory requirements, define networking and IAM policies, and launch the application. Each Fargate task has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task.

Benefits of Amazon Fargate

With Fargate, customer can focus on building and operating your applications whether they are running it with ECS or EKS. They only interact with and pay for your containers, and avoid the operational overhead of scaling, patching, securing, and managing servers. Fargate ensures that the infrastructure customers containers run on is always up-to-date with the required patches.

Fargate launches and scales the compute to closely match the resource requirements customers specify for the container. With Fargate, there is no over-provisioning and paying for additional servers. Customers can also get Spot and Compute Savings Plan pricing options with Fargate just like with Amazon EC2 instances. Compared to On-Demand prices, Fargate Spot provides up to 70% discount for interrupt-tolerant applications, and Compute Savings Plan offers up to 50% discount on committed spend for persistent workloads.

Individual ECS tasks or EKS pods each run in their own dedicated kernel runtime environment and do not share CPU, memory, storage, or network resources with other tasks and pods. This ensures workload isolation and improved security for each task or pod.

With Fargate, customers get out-of-box observability through built-in integrations with other AWS services including Amazon CloudWatch Container Insights. Fargate allows them to gather metrics and logs for monitoring their applications through an extensive selection of third party tools with open interfaces.

How to create an EKS cluster?

An Amazon EKS cluster consists of two primary components:

The Amazon EKS control plane
Amazon EKS nodes that are registered with the control plane

The Amazon EKS control plane consists of control plane nodes that run the Kubernetes software, such as etcd and the Kubernetes API server. The control plane runs in an account managed by AWS, and the Kubernetes API is exposed via the Amazon EKS endpoint associated with customers cluster. Each Amazon EKS cluster control plane is single-tenant and unique, and runs on its own set of Amazon EC2 instances.

All of the data stored by the etcd nodes and associated Amazon EBS volumes is encrypted using AWS KMS. The cluster control plane is provisioned across multiple Availability Zones and fronted by an Elastic Load Balancing Network Load Balancer. Amazon EKS also provisions elastic network interfaces in your VPC subnets to provide connectivity from the control plane instances to the nodes (for example, to support kubectl exec , logs , and proxy data flows).

Amazon EKS nodes run in your AWS account and connect to customers cluster’s control plane via the API server endpoint and a certificate file that is created for their cluster.

There are two getting started guides available for creating a new Kubernetes cluster with nodes in Amazon EKS:

Getting started with eksctl – This getting started guide helps customers to install all of the required resources to get started with Amazon EKS using eksctl, a simple command line utility for creating and managing Kubernetes clusters on Amazon EKS. This is the fastest and simplest way to get started with Amazon EKS.
Getting started with the AWS Management Console – This getting started guide helps customers to create all of the required resources to get started with Amazon EKS using the AWS Management Console.

Amazon EKS uses IAM to provide authentication to customers Kubernetes cluster (through the aws eks get-token command, available in version 1.16.156 or later of the AWS CLI, or the AWS IAM Authenticator for Kubernetes), but it still relies on native Kubernetes Role Based Access Control (RBAC) for authorization. This means that IAM is only used for authentication of valid IAM entities. All permissions for interacting with their Amazon EKS cluster’s Kubernetes API is managed through the native Kubernetes RBAC system.