AWS Builder Center

Builder Center

Deploying Microservices on AWS Managed Kubernetes with Amazon EKS

Microservices are often packaged as containers, but running containers manually becomes increasingly difficult as the number of services grows. This is where Kubernetes comes in. Amazon Elastic Kubernetes Service (Amazon EKS) is AWS's managed Kubernetes service. It allows teams to run Kubernetes clusters on AWS while AWS manages important parts of the Kubernetes control plane.

Dharmik Desai

Student diploma in computer engineering

Deploying Microservices on AWS Managed Kubernetes with Amazon EKS

Microservices are often packaged as containers, but running containers manually becomes increasingly difficult as the number of services grows.
This is where Kubernetes comes in.
Amazon Elastic Kubernetes Service (Amazon EKS) is AWS's managed Kubernetes service. It allows teams to run Kubernetes clusters on AWS while AWS manages important parts of the Kubernetes control plane.
In this article, we'll walk through the architecture of deploying containerized microservices on Amazon EKS and look at how ECR, Kubernetes, networking, and AWS load balancing fit together.

The Architecture

A simplified architecture looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Internet
|
v
 Application Load Balancer
|
v
 Kubernetes Service
|
+-------------+-------------+
| |
v v
 Microservice A Microservice B
Pod 1 Pod 1
Pod 2 Pod 2
| |
+-------------+-------------+
|
v
Kubernetes Cluster
|
v
Amazon EKS / AWS
The important part is that Kubernetes manages the application workloads while AWS provides the underlying cloud infrastructure and managed services.

1. Start With Containerized Microservices

Imagine an application consisting of three services:
1
2
3
Frontend
Backend API
Database Service
Instead of putting the entire application into one large container, each independently deployable application component can be packaged separately.
For example:
1
2
3
4
5
6
7
8
frontend/
Dockerfile

backend/
Dockerfile

notification-service/
Dockerfile
Each service can then be built into its own Docker image.
1
2
3
Frontend → frontend:1.0
Backend API → backend:1.0
Notification Service → notification:1.0
This is one of the major benefits of combining microservices with containers.
Each service can have its own deployment lifecycle.

2. Build Docker Images

Suppose the backend contains a Dockerfile.
We can build the image with:
1
docker build -t backend:1.0 .
Then test it locally:
1
docker run -p 3000:3000 backend:1.0
Before introducing Kubernetes, it is useful to understand this basic container workflow.
1
2
3
4
5
6
7
8
9
10
Application
|
v
Dockerfile
|
v
Docker Image
|
v
Docker Container
Kubernetes comes later to manage many such containers.

3. Store Images in Amazon ECR

Amazon Elastic Container Registry (Amazon ECR) provides a place to store container images.
The workflow becomes:
1
2
3
4
5
6
7
8
9
10
11
12
13
Developer
|
v
Docker Build
|
v
Docker Image
|
v
Amazon ECR
|
v
Amazon EKS
For example, we might have repositories such as:
1
2
3
my-app/frontend
my-app/backend
my-app/notification-service
Kubernetes can then pull the required images from ECR when creating Pods.
This separation is useful because the container image registry and the Kubernetes cluster have different responsibilities.

4. Create an Amazon EKS Cluster

Amazon EKS provides a managed Kubernetes control plane.
Conceptually:
1
2
3
4
5
6
7
8
9
10
11
AWS
|
+-- EKS Cluster
|
+-- Control Plane
|
+-- Worker Nodes
|
+-- Pods
+-- Pods
+-- Pods
The control plane is responsible for Kubernetes orchestration.
The worker nodes provide compute resources on which application workloads run.
Depending on the architecture, workloads can run using different compute options supported by EKS.

5. Kubernetes Deployments

Once the cluster is available, we need to tell Kubernetes what should run.
A Kubernetes Deployment can describe the desired state of an application.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: apps/v1
kind: Deployment
metadata:
name: backend
spec:
replicas: 2
selector:
matchLabels:
app: backend
template:
metadata:
labels:
app: backend
spec:
containers:
- name: backend
image: <ECR-IMAGE>
ports:
- containerPort: 3000
The important part is:
1
replicas: 2
This tells Kubernetes that we want two replicas of the application.
Instead of manually launching two containers, Kubernetes maintains the desired state.
If a Pod fails, Kubernetes can create another Pod to restore the desired number of replicas.

6. Pods

A Pod is the smallest deployable unit in Kubernetes.
Our architecture might therefore look like:
1
2
3
4
5
6
7
8
9
10
11
12
13
EKS Cluster

Backend Deployment
|
+-- Pod
|
+-- Pod

Frontend Deployment
|
+-- Pod
|
+-- Pod
The application developer generally thinks in terms of deployments and services rather than manually managing individual containers.
This is one of the major differences between running Docker directly on an EC2 instance and using Kubernetes.

7. Kubernetes Services

Pods are not permanent.
They can be recreated, replaced, or moved between nodes.
Therefore, applications should not depend on the IP address of an individual Pod.
Kubernetes Services provide a stable way to access Pods.
For example:
1
2
3
4
5
6
7
8
9
10
apiVersion: v1
kind: Service
metadata:
name: backend-service
spec:
selector:
app: backend
ports:
- port: 80
targetPort: 3000
The Service selects Pods using their labels:
1
2
3
4
5
Service
|
+----> Backend Pod
|
+----> Backend Pod
If one Pod disappears and Kubernetes creates another, the Service continues providing a stable endpoint.

8. Exposing the Application

The frontend may need to be accessible from the internet.
Instead of exposing every Pod directly, an external load balancer can sit in front of the application.
A simplified architecture is:
1
2
3
4
5
6
7
8
9
10
11
12
Internet
|
v
Application Load Balancer
|
v
Kubernetes Service
|
+--------+--------+
| |
v v
 Backend Pod Backend Pod
This provides a clear separation between external traffic and internal application workloads.
For AWS environments, Kubernetes integrations can provision AWS load-balancing resources from Kubernetes configuration.

9. Microservice-to-Microservice Communication

One of the useful features of Kubernetes Services is internal service discovery.
Suppose we have:
1
2
3
4
5
6
7
8
Frontend
|
v
Backend
|
+----> User Service
|
+----> Notification Service
The backend does not need to know the individual Pod IP addresses.
It can communicate with Kubernetes Services.
Conceptually:
1
2
3
4
5
6
7
backend-service
|
v
user-service
|
v
notification-service
Kubernetes handles service discovery and routing between the workloads.

10. Scaling Microservices

One reason Kubernetes is useful for microservices is that different services can scale independently.
For example:
1
2
3
4
5
6
7
8
Frontend
2 Pods

Backend
5 Pods

Notification Service
2 Pods
If the backend receives significantly more traffic, we can increase its replicas without necessarily scaling the other services.
1
2
3
4
5
6
7
8
9
10
11
12
Backend

Before:
Pod 1
Pod 2

After:
Pod 1
Pod 2
Pod 3
Pod 4
Pod 5
This is much more flexible than treating the entire application as one deployment unit.

11. Updating a Microservice

Suppose we release version 2.0 of the backend.
We can build a new image:
1
backend:2.0
Push it to ECR and update the Kubernetes Deployment to use the new image.
Kubernetes can then perform a rolling update.
Conceptually:
1
2
3
4
5
6
7
8
9
Version 1.0
|
| Update
v
Version 2.0

Pod 1 → v2
Pod 2 → v2
Pod 3 → v2
Instead of stopping the entire application at once, Kubernetes can gradually replace the old Pods.
This is an important step toward more reliable application deployments.

12. Where AWS Fits

At this point, several technologies are working together.
TechnologyResponsibility
DockerPackages applications into containers
Amazon ECRStores container images
Amazon EKSRuns and manages Kubernetes workloads
KubernetesOrchestrates Pods, Deployments, and Services
AWS Load BalancingHandles external application traffic
VPCProvides network infrastructure
IAMControls AWS permissions
CloudWatchProvides AWS monitoring capabilities
The important lesson is that these services are not interchangeable.
Each solves a different problem.

13. Docker vs Kubernetes

It is easy to think that Kubernetes replaces Docker.
The concepts are actually different.
Docker helps answer:
How do I package and run my application consistently?
Kubernetes helps answer:
How do I manage many application workloads across a cluster?
A simplified progression is:
1
2
3
4
5
6
7
8
9
10
11
Application
↓
Docker
↓
Container
↓
Multiple Containers
↓
Kubernetes
↓
Automated Orchestration
This is why learning Docker before Kubernetes is useful.
Without understanding containers, Kubernetes can quickly become a collection of YAML files that somehow summon Pods from the digital underworld.

14. When Is EKS Actually Useful?

You don't need Kubernetes simply because your application has two containers.
For a small application, a single EC2 instance running Docker may be easier to operate.
EKS becomes more relevant when requirements include things such as:
  • Multiple microservices
  • Multiple replicas
  • Automated scheduling
  • Service discovery
  • Rolling deployments
  • Scaling
  • High availability
  • Cluster-level orchestration
The architecture should therefore be driven by application requirements rather than by the desire to use the most complicated technology available.

Conclusion

Deploying microservices on Amazon EKS brings together several important cloud and DevOps concepts:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Developer
|
v
 Docker
|
v
 Docker Images
|
v
 ECR
|
v
 EKS
|
+----------+----------+
| | |
v v v
 Frontend Backend Notification
| | |
+----------+----------+
|
v
Kubernetes Services
|
v
AWS Load Balancer
|
v
Users
The interesting part of EKS is not simply running containers on AWS.
It is the combination of containerization, orchestration, networking, scaling, service discovery, and deployment automation.
A practical learning path therefore looks like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
AWS Fundamentals
↓
EC2 + VPC + Networking
↓
Docker
↓
ECR
↓
Kubernetes Fundamentals
↓
Amazon EKS
↓
Microservices
↓
CI/CD + Monitoring
Understanding this progression makes Kubernetes much easier to approach because each new layer solves a problem introduced by the previous one.
# amazon-eks# docker
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article