I Thought EKS Would Be Just Kubernetes in the Cloud. I Was Wrong.
When I started working with Amazon EKS, I initially thought it would be quite simple: take a Kubernetes application, move it to AWS, and let EKS handle the rest. The reality was a little different.
EKS is Kubernetes, but running Kubernetes on AWS means understanding much more than Deployments and Services. You also need to understand IAM, networking, load balancing, storage, container registries, and how AWS services interact with Kubernetes.
This is what I learned while building my first EKS workloads.
From local Kubernetes to EKS
Before working with EKS, I had already used Kubernetes locally with tools such as MicroK8s and K3s.
The basic concepts were familiar:
- Pods
- Deployments
- Services
- ConfigMaps
- Secrets
- Ingress
- ServiceAccounts
So when I started with EKS, I expected the transition to be straightforward.
The Kubernetes YAML was still familiar, but the infrastructure underneath it was completely different.
Instead of managing everything locally, I now had to think about AWS resources:
Developer → Docker → ECR → EKS → AWS infrastructure
That was my first important lesson: EKS does not replace the need to understand AWS. It connects Kubernetes with AWS.
The first challenge: container images
A Kubernetes cluster needs access to the container image.
With a local Kubernetes cluster, I could sometimes work directly with local images or a local registry.
With EKS, I normally push my images to Amazon ECR.
The workflow becomes:
1
2
3
4
5
6
7
8
9
10
11
Application
↓
Docker build
↓
Docker image
↓
Amazon ECR
↓
Amazon EKS
↓
Kubernetes Pod
For example:
1
2
3
4
5
6
7
docker build -t my-backend .
docker tag my-backend:latest \
<account-id>.dkr.ecr.<region>.amazonaws.com/my-backend:latest
docker push \
<account-id>.dkr.ecr.<region>.amazonaws.com/my-backend:latest
Then the Kubernetes Deployment can reference the ECR image.
This seems simple, but it introduced another question:
How does the EKS node get permission to pull the image?
And that brought me to IAM.
Kubernetes and AWS IAM are not the same thing
This was one of the concepts I had to understand properly.
A Kubernetes ServiceAccount and an AWS IAM role are different things.
Kubernetes uses ServiceAccounts to give Pods an identity inside the cluster.
AWS IAM controls permissions to AWS resources.
When a Pod needs to access something such as S3, simply creating a Kubernetes ServiceAccount is not enough.
The Pod needs an AWS identity with the appropriate permissions.
This is where mechanisms such as IAM Roles for Service Accounts (IRSA) and EKS Pod Identity become important.
For example, instead of giving every Pod broad AWS permissions, I can create a dedicated identity for a workload that only needs to read from an S3 bucket.
The principle is simple:
1
2
3
4
5
6
7
Pod
↓
Kubernetes identity
↓
AWS identity
↓
Specific AWS permissions
This is much better than giving every workload access to everything.
It also made me realize that Kubernetes security and AWS security cannot really be treated separately when using EKS.
Networking is another level
The next thing that became more important was networking.
In a local Kubernetes environment, I could focus mostly on Kubernetes networking.
With EKS, I also need to understand the AWS VPC:
- VPC
- Subnets
- Route tables
- Security Groups
- Internet Gateway
- NAT Gateway
- Load Balancers
For example, if an application needs to be publicly accessible, the Kubernetes Service or Ingress can interact with AWS load-balancing services.
So a request can follow a path similar to:
1
2
3
4
5
6
7
Internet
↓
AWS Load Balancer
↓
Kubernetes Service
↓
Pod
Understanding this flow helped me troubleshoot problems much faster.
Instead of asking only:
"Why is my Pod not responding?"
I started asking:
"At which layer is the request failing?"
Is the Pod running?
Is the Service selecting the correct Pods?
Is the target reachable?
Is the AWS load balancer configured correctly?
Is the security group allowing the traffic?
That change in thinking was probably one of the most useful lessons for me.
EKS is managed, but Kubernetes is still your responsibility
Another misconception I had was that EKS would manage almost everything.
EKS removes a lot of the operational work involved in running the Kubernetes control plane, but it doesn't mean that everything becomes automatic.
You still need to think about:
- Workloads
- Resource requests and limits
- Networking
- IAM
- Security
- Observability
- Application availability
- Deployment strategies
- Costs
This is especially important for someone learning Kubernetes.
A managed service does not remove the need to understand the technology.
It changes what you have to manage.
What I would do differently today
If I started another EKS project from scratch, I would avoid trying to learn everything at once.
I would follow a progression like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1. Docker
↓
2. ECR
↓
3. EKS cluster
↓
4. Kubernetes Deployment
↓
5. Service
↓
6. Load Balancer
↓
7. IAM integration
↓
8. Monitoring
↓
9. Security
↓
10. Infrastructure as Code
This makes troubleshooting much easier because each layer is understood separately before combining everything.
I would also pay much more attention to AWS costs from the beginning.
Creating an EKS cluster is easy.
Leaving resources running without checking their cost is also easy.
EKS vs the Kubernetes I already knew
The biggest lesson for me is that EKS didn't replace what I already knew about Kubernetes.
Instead, it added another layer.
I can think about it like this:
| Kubernetes | AWS |
|---|---|
| Pod | Compute infrastructure |
| Service | Load balancing/networking |
| ServiceAccount | IAM integration |
| Container image | ECR |
| Persistent storage | EBS/EFS |
| Ingress | AWS Load Balancer |
| Cluster | EKS |
The mapping isn't always one-to-one, but this mental model helped me understand the relationship between the two technologies.
Final thoughts
My biggest takeaway from EKS is that learning cloud-native technologies isn't only about learning commands.
It's about understanding how different layers work together.
Kubernetes gives me the orchestration layer.
AWS provides the infrastructure and managed services around it.
And IAM, networking, security, and observability connect everything together.
I'm still learning EKS, and I definitely don't consider myself an expert. But moving from local Kubernetes to AWS helped me understand something important:
Knowing Kubernetes is a good starting point. Understanding Kubernetes in the context of cloud infrastructure is the next step.
That's the part I'm currently working on.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article