We close Part IV with EKS (Elastic Kubernetes Service), the most powerful—and most complex—option for running containers on AWS. It’s important to understand what Kubernetes is, what EKS brings to the table, and above all, when it’s worth it compared to the simplicity of ECS. Spoiler: not always.

Kubernetes (often abbreviated as K8s) is the most popular container orchestrator in the world. It does the same as ECS (run, scale, repair, and coordinate containers), but with two important differences:

• It’s open source and an industry standard: it’s used by companies of all sizes and works on any cloud (AWS, Azure, Google...) or even on your own servers.
• It’s much more powerful and flexible... but also much more complex.

Analogy: if ECS is an automatic car (easy to drive, AWS manages almost everything for you), Kubernetes is a Formula 1 car: incredibly capable and configurable, but requires an expert driver and lots of maintenance. To go to the supermarket, the automatic is more than enough.

Managing Kubernetes on your own is very difficult: you have to install and maintain its “brain” (the control plane), which is complex and delicate. EKS (Elastic Kubernetes Service) solves this: it’s Kubernetes managed by AWS. AWS takes care of the hardest part (the control plane), and you use Kubernetes without having to maintain its core.

Even so—and this is key—EKS is still more complex than ECS. AWS takes away part of the work, but Kubernetes itself has a steep learning curve: its own concepts (pods, deployments, services, ingress...), its own way of configuring, its own ecosystem of tools.

EKS makes sense in these cases:

• You already use Kubernetes or your team has experience with it. You leverage that knowledge.
• You need multi-cloud or want to avoid “vendor lock-in”: you want your application to run on AWS, another cloud, or your own servers without rewriting it. Kubernetes is the common standard.
• Very complex needs: advanced network configurations, sophisticated deployments, or you want to use the huge Kubernetes ecosystem of tools (Helm, operators, service meshes...).
• Large organization with many teams and applications, where Kubernetes’s power outweighs its complexity.

And here’s the most valuable advice of the subchapter. Many people choose Kubernetes because it’s trendy, without needing it, and end up paying a huge complexity cost for nothing. Do NOT choose EKS if:

• You’re just starting with containers. Start with ECS/Fargate; it’s much simpler.
• Your team doesn’t know Kubernetes. The learning curve and maintenance will steal time you should spend on your product.
• Your needs are normal: running a few applications, scaling them, distributing traffic. ECS does this perfectly and with much less effort.
• You want operational simplicity. Fargate (with ECS) gives you containers with almost nothing to manage.

The classic mistake: a small team sets up a complex Kubernetes cluster to run three microservices, and ends up spending more time maintaining Kubernetes than developing their product. With ECS + Fargate they would have had the same thing running in a fraction of the time. Choose the tool for real need, not for fashion.

Always start with the simple (ECS/Fargate). Move to EKS only when you have a concrete and justified reason to need Kubernetes. Complexity must earn its place, not be adopted by default.

• Kubernetes (K8s) is the industry standard container orchestrator: extremely powerful, open source, and portable to any cloud, but very complex. Like a Formula 1 compared to the automatic car that is ECS.
• EKS (Elastic Kubernetes Service) is Kubernetes managed by AWS: AWS maintains the “brain,” but it’s still more complex than ECS.
• Choose EKS if: you already use Kubernetes, need multi-cloud/avoid lock-in, have very complex needs, or a large organization with expertise.
• Do NOT choose EKS if you’re starting out, your team doesn’t know Kubernetes, or your needs are normal: ECS + Fargate does the same with much less effort.
• Golden rule: start with the simple (ECS/Fargate) and move to EKS only with a justified reason. Choose by need, not by trend.

You’ve finished Chapter 17 and Part IV! You now master intermediate AWS architectures: load balancing and auto-scaling, serverless, messaging, content delivery, and containers. In Part V we’ll raise the level of Terraform: starting with modules, the key to reusing and organizing your infrastructure like a pro.