Docker and Kubernetes on AWS: A Developer's Guide to Containers and Orchestration

Docker and Kubernetes on AWS is the stack many teams reach for when they want repeatable builds, portable application images, and production-grade container orchestration. Docker usually owns the developer workflow: build the image, run it locally, fix it fast. Kubernetes, most often through Amazon Elastic Kubernetes Service, handles scheduling, scaling, service discovery, rollout control, and recovery when containers fail.

Here is the short version. Use Docker to package your application, Amazon ECR to store the image, and Amazon EKS on EC2 or Fargate to run it at scale. That sounds simple. The hard part is learning where Docker ends and Kubernetes begins.

Docker, Kubernetes, and AWS: What Each One Does

Docker packages the application

Docker bundles your code, dependencies, runtime, operating system libraries, and configuration into an image. A Dockerfile gives you a repeatable build. If your API works in a local container on Python 3.12 or Node.js 22, you have a much better chance of getting the same behavior in CI and in production.

Not perfect. Close enough to matter.

Developers still lean on Docker Desktop or Docker Engine for local builds, test containers, and quick integration checks. Docker Compose stays useful when you need an API, PostgreSQL, Redis, and a worker process running together on a laptop.

Kubernetes orchestrates containers

Kubernetes is not a replacement for Docker. It solves a different problem. You describe the desired state in YAML: how many replicas should run, which image to use, what CPU and memory to request, which ports to expose, and how updates should roll out. Kubernetes then keeps working to match that state.

On AWS, Kubernetes usually runs through Amazon EKS, a certified conformant managed Kubernetes service. EKS manages the control plane, including the Kubernetes API server and core control components, so your team does not have to run that layer by hand.

AWS supplies the production platform

A typical AWS container stack includes:

• Amazon EKS for managed Kubernetes.
• Amazon EC2 for worker nodes, unless you choose Fargate.
• Amazon ECR for private container image storage.
• Amazon VPC for networking, subnets, routing, and isolation.
• AWS IAM for access control across users, nodes, and workloads.
• AWS Load Balancer Controller when Kubernetes Services need AWS load balancers.

Kubernetes can also run on self-managed EC2 clusters, but most teams should start with EKS unless they have a strong reason to run the control plane themselves.

Why Docker and Kubernetes on AWS Became the Default Path

The adoption data is not subtle. Flexera's 2023 State of the Cloud survey, covering 750 organizations, found that 45 percent were using AWS ECS or EKS, 42 percent were using Docker, and 40 percent were using Kubernetes not supplied by a cloud provider. Flexera also reported that lack of internal expertise was the top container challenge, cited by 36 percent of respondents.

That matches what you see inside engineering teams. Docker is easy to start. Kubernetes is easy to underestimate. AWS adds strong building blocks, but it also adds IAM, networking, cost controls, and operational rules that developers cannot ignore.

One important change: Kubernetes 1.24 removed dockershim. That does not mean Docker is dead. It means Kubernetes nodes now commonly use Container Runtime Interface implementations such as containerd. You can still build and test images with Docker locally, then run those images on EKS nodes using containerd. Most developers do not need to install Docker Engine on EKS worker nodes.

The Practical Workflow: From Laptop to EKS

1. Build the image locally

Start with a small service. Do not begin with a full microservices migration. Write a Dockerfile, build the image, run it locally, and verify health checks before you touch Kubernetes.

A common beginner mistake is building on an Apple Silicon laptop and pushing an ARM image to ECR while the EKS node group uses x86 Amazon EC2 instances. The pod starts, then fails with a message like exec /app/server: exec format error. Build for the right platform, for example linux/amd64, or run Graviton-based ARM nodes on purpose. Guessing here wastes hours.

2. Push the image to Amazon ECR

Amazon ECR is the natural registry for Docker images on AWS. It keeps images close to EKS and integrates with IAM. In production, scan images, pin versions, and avoid deploying the floating latest tag. Use immutable tags or digests when a release must be auditable.

3. Provision Amazon EKS

You can create EKS clusters through the AWS console, AWS CLI, eksctl, Terraform, Pulumi, or other infrastructure-as-code tools. For a learning project, eksctl is quick. For a team environment, use Terraform or Pulumi so the cluster, node groups, IAM roles, and add-ons are versioned.

Pay attention to these settings early:

• VPC design: private subnets for worker nodes are usually the safer default.
• Node groups: choose instance types based on memory and CPU, not habit.
• IAM roles: keep node permissions narrow and use IAM Roles for Service Accounts where possible.
• Kubernetes version: plan upgrades. Do not let clusters drift until support deadlines force a rushed change.

4. Deploy with Kubernetes manifests

Your Deployment points to the ECR image. A Service gives stable networking. ConfigMaps hold non-secret configuration. Secrets store sensitive values, though many production teams connect Kubernetes workloads to AWS Secrets Manager for stronger governance.

Set resource requests and limits. Skip them and scheduling becomes guesswork, and autoscaling behaves badly. I have watched a Java service with no memory limit eat a node until other pods were evicted. Kubernetes did exactly what it was told. The manifest was the problem.

5. Roll out, scale, and observe

Kubernetes Deployments support rolling updates and rollbacks. The Horizontal Pod Autoscaler can scale replicas based on metrics such as CPU utilization, provided metrics are installed and configured. Use readiness probes so traffic only reaches pods that can serve requests. Use liveness probes carefully. An aggressive liveness probe can restart a slow-starting application into a permanent crash loop.

For observability, combine Kubernetes events and logs with AWS-native services such as Amazon CloudWatch. For deeper production setups, many teams add Prometheus, Grafana, OpenTelemetry, and tracing across service boundaries.

EKS, ECS, or Fargate: Which Should You Choose?

Pick Amazon EKS when you need Kubernetes APIs, Helm charts, custom controllers, portability across clusters, or a platform team that already understands Kubernetes. EKS is also a strong fit for multi-service systems with complex deployment needs.

Pick Amazon ECS when you want AWS-native container orchestration with less Kubernetes overhead. ECS is simpler for many teams, especially if portability to other Kubernetes environments is not a requirement.

Pick AWS Fargate when you do not want to manage worker nodes. Fargate can run containers for both ECS and EKS, though you should test pricing and startup behavior for your workload. It is not always cheaper. For steady, high-volume workloads, well-sized EC2 node groups may cost less.

To be blunt, Kubernetes is the wrong first step for a small internal app with two users and no scaling pressure. Docker plus ECS, App Runner, or even a serverless design may get you to production faster.

Security Practices Developers Should Not Skip

Container security is not only an operations concern. Developers make choices that set the security baseline.

• Use minimal base images and update them regularly.
• Scan images in CI and in Amazon ECR.
• Do not bake secrets into Docker images.
• Run containers as non-root where possible.
• Apply Kubernetes network policies if your networking layer supports them.
• Use IAM Roles for Service Accounts instead of broad node-level permissions.
• Review supply chain risk. The XZ Utils backdoor tracked as CVE-2024-3094 was a reminder that trusted open source dependencies can still become a production risk.

Also check admission controls and policies before teams deploy freely into shared clusters. Without guardrails, someone will eventually ship a privileged pod or expose an internal service through the wrong load balancer.

Learning Path for Developers

If you are learning Docker and Kubernetes on AWS, work in this order:

1. Build a simple API and package it with Docker.
2. Add Docker Compose with a database and a cache.
3. Learn Kubernetes basics: Pods, Deployments, Services, ConfigMaps, Secrets, and Ingress.
4. Push images to Amazon ECR.
5. Deploy to Amazon EKS using kubectl.
6. Repeat the deployment with Terraform, Pulumi, or another infrastructure-as-code tool.
7. Add monitoring, autoscaling, and image scanning.

For structured study, this topic maps well to Global Tech Council learning paths in AWS, DevOps, cloud computing, cybersecurity, and programming. Link this article to related Global Tech Council certification and course pages for cloud-native development, AWS operations, and secure software delivery.

Common Pitfalls on AWS Container Projects

• Using Kubernetes too early: learn containers first, then orchestration.
• Ignoring IAM: access design is part of the application architecture on AWS.
• Shipping huge images: larger images slow builds, scans, pulls, and rollouts.
• No resource requests: Kubernetes scheduling depends on them.
• Poor tagging: if every deployment uses latest, rollbacks become messy.
• Weak health checks: readiness and liveness probes should reflect real application behavior.

Final Next Step

Build one containerized service this week. Push it to Amazon ECR, deploy it to a small EKS cluster, and break it on purpose: kill a pod, deploy a bad image tag, set the wrong CPU request, and watch what Kubernetes does. That hands-on loop teaches more than reading YAML examples for days. After that, move into a Global Tech Council AWS or DevOps learning path to formalize the skills and prepare for real production work.