September 09, 2026
11 min read
By Kokil Thapa | Last reviewed: September 2026
You need to run Kubernetes on AWS with Amazon EKS when a single EC2 box or a Laravel hosting stack on plain VPS stops scaling cleanly. EKS gives you a managed control plane, AWS-native networking, and IAM integration without babysitting etcd on every deploy night. This guide walks through a production-minded path: VPC design, cluster creation with eksctl, worker nodes, ingress, secrets, and the cost traps teams hit after month one.
Quick answer: To run Kubernetes on AWS with Amazon EKS, create a VPC with public and private subnets, launch an EKS cluster via eksctl or Terraform, attach managed node groups in private subnets, configure the AWS Load Balancer Controller for ingress, and bind pod permissions with IAM Roles for Service Accounts (IRSA).
What is Amazon EKS and when should you run Kubernetes on AWS with Amazon EKS?
Amazon Elastic Kubernetes Service (EKS) is AWS's managed Kubernetes offering. AWS runs the control plane across three Availability Zones. You manage worker capacity, workloads, and most day-two operations.
EKS fits teams that already live in AWS. You get tight integration with IAM, VPC, RDS, S3, Secrets Manager, and CloudWatch. If your stack is mostly PHP/Laravel on Apache with Deployer releases, EKS is usually overkill until you need horizontal pod scaling, multi-service isolation, or GPU/ML sidecars alongside web apps.
I've seen small Nepal teams jump to Kubernetes because it sounds modern. That often doubles ops cost before traffic justifies it. Start with managed containers (ECS Fargate) or improved VM deploy pipelines first. Move to EKS when you have clear reasons: multiple microservices, strict isolation, autoscaling beyond one server, or a platform team that can own cluster upgrades.
For background on container orchestration trade-offs, see our comparison of Kubernetes vs Docker Swarm. For Laravel-specific patterns, read Kubernetes for Laravel getting started.
How do you prepare AWS networking before creating an EKS cluster?
EKS is a VPC-native service. Every Pod gets a real IP from your VPC CIDR via the Amazon VPC CNI plugin. Plan IP space early. A /16 VPC with /19 subnets per AZ is a common starting point for mid-size clusters.
Subnet layout
You need at least two Availability Zones. Put worker nodes in private subnets. Put load balancer-facing resources in public subnets when you use internet-facing ALBs. NAT gateways give private nodes outbound access for image pulls and API calls.
- Public subnets: NAT gateways, internet-facing load balancers, bastion hosts if you still use them.
- Private subnets: EKS managed node groups, internal services, RDS endpoints.
- Tagging: Tag subnets so the AWS Load Balancer Controller knows where to place ALBs and NLBs.
If you use eksctl, it can create a sensible VPC for you. For production, I prefer defining the VPC in AWS CloudFormation or Terraform first. That keeps network ownership with your platform team and makes peered VPC rules auditable.
Security groups and endpoint access
Lock the EKS API endpoint carefully. Private-only endpoints suit internal platforms. Public endpoints with restricted CIDR blocks suit teams that kubectl from CI runners or home offices. Never leave 0.0.0.0/0 open unless you accept the risk and compensate with strong auth.
How do you create an EKS cluster with eksctl step by step?
eksctl is the fastest path to a working cluster for engineers who want copy-paste commands today. Install it, configure AWS CLI credentials, then define a cluster config file.
Prerequisites
- AWS CLI v2 installed and configured with an IAM principal that can create EKS, EC2, IAM, and CloudFormation resources.
- kubectl matching your target Kubernetes version (check the EKS platform version table in AWS docs).
- eksctl 0.190 or newer for current EKS API features.
Example eksctl cluster config
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: prod-cluster
region: ap-south-1
version: "1.31"
vpc:
cidr: 10.20.0.0/16
nat:
gateway: HighlyAvailable
managedNodeGroups:
- name: ng-general
instanceType: m7i.large
desiredCapacity: 3
minSize: 2
maxSize: 6
privateNetworking: true
labels:
role: general
tags:
k8s.io/cluster-autoscaler/enabled: "true"
k8s.io/cluster-autoscaler/prod-cluster: "owned"
iam:
withOIDC: true
addons:
- name: vpc-cni
version: latest
- name: coredns
version: latest
- name: kube-proxy
version: latest
Create the cluster:
eksctl create cluster -f cluster.yaml
aws eks update-kubeconfig --name prod-cluster --region ap-south-1
kubectl get nodes
Cluster creation takes 15–25 minutes. eksctl uses CloudFormation stacks under the hood. That is why a failed create often leaves partial stacks you must delete before retrying.
Official references: AWS EKS getting started guide and eksctl cluster documentation.
How do EKS managed node groups compare to Fargate and self-managed nodes?
Worker compute is where most EKS cost and toil live. Pick the model that matches your team's ops capacity and workload shape.
| Option | Best for | Ops burden | Cost profile |
|---|---|---|---|
| Managed node groups | Steady web APIs, queues, most production apps | Low — AWS patches AMIs; you drain and roll | EC2 + EKS control plane (~USD 0.10/hr per cluster) |
| Fargate | Burst workloads, strict isolation, small teams | Lowest — no nodes at all | Higher per-vCPU/per-GB; no idle savings |
| Self-managed ASG nodes | Custom AMIs, GPU tuning, exotic disk layouts | High — you own kubelet, CNI, upgrades | Similar EC2 cost; more engineer hours |
| Spot managed nodes | Batch jobs, CI runners, fault-tolerant workers | Medium — plan for interruptions | Up to 70–90% EC2 savings with trade-offs |
For GPU or ML inference, pair managed GPU nodes with guidance from running AI/ML workloads on Kubernetes with GPUs. For cron-style batch work, see Kubernetes Jobs and CronJobs explained.
On client projects with predictable traffic, I default to two managed node groups: one on-demand for critical services and one Spot for background workers. That balances stability with NPR-friendly savings (Spot can cut compute bills sharply if your jobs tolerate eviction).
How do you expose applications and manage secrets on EKS?
A running cluster is half the job. Production traffic and credential hygiene matter on day one.
Ingress with the AWS Load Balancer Controller
Install the controller with Helm. Annotate your Ingress or Gateway API resources so AWS creates an ALB. Terminate TLS at the ALB with ACM certificates. Keep Pods in private subnets; only the load balancer needs public reachability for internet apps.
helm repo add eks https://aws.github.io/eks-charts
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=prod-cluster \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller
Compare ingress controllers in our Kong vs Traefik vs AWS API Gateway write-up if you need API-layer routing beyond basic HTTP ingress.
IRSA instead of long-lived access keys
Never mount static AWS access keys into Pods. Use IAM Roles for Service Accounts. eksctl can create an OIDC provider with withOIDC: true. Then annotate Kubernetes service accounts with role ARNs. Your app reads S3, SQS, or Secrets Manager using short-lived credentials.
This mirrors how I handle secrets on VM-based Laravel deploys, but with finer per-workload scoping. Deep dive: manage secrets with AWS Secrets Manager.
Resource requests, limits, and autoscaling
Define CPU and memory requests on every Deployment. Without them, the scheduler guesses and the Cluster Autoscaler cannot scale nodes correctly. Read Kubernetes resource limits and requests, then wire Horizontal Pod Autoscaling to CPU or custom metrics.
What production mistakes break EKS clusters after launch?
Most EKS pain shows up weeks after the demo deploy succeeds. These are the failures I watch for on platform work and Linux system administration engagements.
IP exhaustion from the VPC CNI
Each Pod consumes a VPC IP. Dense namespaces with short-lived Jobs can drain subnet IP pools fast. Enable prefix delegation or add secondary CIDR blocks before production traffic spikes. Symptoms look like Pending Pods with insufficient IP errors — not application bugs.
Upgrade drift
EKS supports three Kubernetes versions concurrently on the control plane. Plan upgrades twice a year. Upgrade control plane first, then node groups, then bump add-ons. Skipping versions forces painful jumps. Test in a staging cluster that mirrors production add-ons.
Observability gaps
Install the CloudWatch agent or use Prometheus/Grafana. Without metrics, HPA and Cluster Autoscaler fight blind. For cost visibility, read Kubernetes cost monitoring with Kubecost.
Backup and disaster recovery
etcd backups are AWS's problem. Your PersistentVolume data and etcd-external state are yours. Use Velero with S3 backup targets. See Velero backup and restore for Kubernetes.
CrashLoopBackOff after deploy
Wrong image tags, missing ConfigMaps, and failed health probes cause endless restart loops. Our CrashLoopBackOff debugging guide walks through kubectl commands that save hours.
For teams building custom platforms, enterprise application development and API development services often start on VMs and migrate to EKS once service count grows. The Adventure Third Pole Trek booking platform runs on Laravel + Livewire with traditional deploy pipelines — the right call for that workload shape today.
Automate cluster changes with GitOps (Flux or Argo CD) or Terraform. Manual kubectl edits do not survive staff turnover. Crossplane fans should read Crossplane for Kubernetes-native infrastructure.
Validate YAML before apply using our JSON and YAML formatter tool — small syntax errors cause big outages.
Key Takeaways
- Run Kubernetes on AWS with Amazon EKS when multi-service scaling, isolation, or GitOps workflows justify the control-plane cost (~USD 73/month per cluster plus EC2).
- Plan VPC IP space and private subnets before cluster create; the VPC CNI assigns real VPC IPs to every Pod.
- Use eksctl or Terraform for reproducible clusters, managed node groups for day-two sanity, and IRSA instead of static AWS keys.
- Install the AWS Load Balancer Controller, set resource requests on all Deployments, and wire HPA plus Cluster Autoscaler together.
- Budget for NAT gateways, EBS volumes, and observability stack costs — they often exceed the EKS control-plane fee.
- Keep Velero backups, staged upgrade paths, and a staging cluster that mirrors production add-ons.
People Also Ask
How much does Amazon EKS cost per month?
EKS charges roughly USD 0.10 per hour for the control plane (~USD 73/month per cluster). Worker EC2, EBS, NAT gateways, and load balancers dominate the bill. A three-node m7i.large cluster in ap-south-1 often lands at USD 250–450/month before data transfer. Spot nodes and right-sized requests cut spend significantly.
What Kubernetes version does EKS support in 2026?
AWS publishes supported versions on the EKS platform versions page. As of 2026, new clusters typically launch on 1.30–1.32 tracks. Always check the official matrix before pinning version in eksctl or Terraform. Upgrade before AWS deprecates your control-plane version.
Can you run Laravel on Amazon EKS?
Yes. Containerize the PHP-FPM and Nginx sidecar (or use FrankenPHP), store sessions in Redis, and point queue workers to separate Deployments. It works well at scale but adds complexity versus Deployer on EC2. See our Laravel-on-Kubernetes starter guide for manifest patterns.
Is EKS better than self-managed Kubernetes on EC2?
For most teams, yes. AWS patches the control plane, runs etcd across AZs, and integrates IAM natively. Self-managed K8s on EC2 (Kubespray, kubeadm) suits air-gapped or cost-obsessed teams with strong platform engineers. Compare with deploying Kubernetes with Kubespray if you want full control.
Ship EKS workloads with confidence
You now have a practical blueprint to run Kubernetes on AWS with Amazon EKS: VPC-first design, eksctl cluster creation, managed nodes, IRSA, ALB ingress, and the production traps that cause 3 a.m. pages. Start with a staging cluster, harden observability and backups before production cutover, and keep simpler hosting until Kubernetes clearly pays for itself.
Need help designing a migration path from VM-based Laravel or WordPress to containers? Support and maintenance and custom software development cover architecture reviews through production handoff. Learn about my background or contact us to discuss your AWS and Kubernetes roadmap.
Frequently Asked Questions
Amazon Elastic Kubernetes Service is AWS’s managed Kubernetes offering. AWS runs the control plane across three Availability Zones; you manage worker capacity, workloads, and most day-two operations.
The control plane costs roughly USD 0.10 per hour, about USD 73 per month per cluster. Worker EC2, EBS, NAT gateways, and load balancers usually dominate the bill.
Check AWS’s EKS platform versions page before pinning a version. In 2026, new clusters typically launch on the 1.30–1.32 tracks.
Move to EKS when a single EC2 box or traditional Deployer-on-VPS pipeline stops scaling cleanly and you need horizontal pod scaling, multi-service isolation, or GPU sidecars alongside web apps. If your stack is mostly PHP/Laravel on Apache, EKS is usually overkill until traffic and service count justify it. I've seen small Nepal teams adopt Kubernetes early and double ops cost before traffic warrants it. Start with ECS Fargate or improved VM deploy pipelines first, then adopt EKS when you have multiple microservices, strict isolation needs, autoscaling beyond one server, or a platform team that can own cluster upgrades.
EKS is VPC-native, and every Pod gets a real IP from your VPC CIDR via the Amazon VPC CNI plugin, so plan IP space early. A /16 VPC with /19 subnets per Availability Zone is a common mid-size starting point. Use at least two AZs, place worker nodes in private subnets, and put internet-facing load balancers in public subnets. NAT gateways give private nodes outbound access for image pulls and API calls. Tag subnets so the AWS Load Balancer Controller knows where to place ALBs and NLBs. For production, define the VPC in CloudFormation or Terraform rather than letting eksctl own network design, and lock the EKS API endpoint with private-only access or public access restricted to known CIDR blocks.
Install AWS CLI v2 with credentials that can create EKS, EC2, IAM, and CloudFormation resources, install kubectl matching your target Kubernetes version, and use eksctl 0.190 or newer. Define a ClusterConfig YAML with cluster name, region, Kubernetes version, VPC CIDR, highly available NAT gateways, and managed node groups in private subnets with withOIDC: true for IRSA. Include core add-ons such as vpc-cni, coredns, and kube-proxy. Run eksctl create cluster -f cluster.yaml, then aws eks update-kubeconfig and kubectl get nodes. Cluster creation typically takes 15–25 minutes because eksctl uses CloudFormation stacks; failed creates often leave partial stacks you must delete before retrying.
Managed node groups suit steady web APIs, queues, and most production apps with low ops burden: AWS patches AMIs and you drain and roll nodes, paying EC2 plus the EKS control-plane fee. Fargate fits burst workloads and small teams wanting zero node management, but costs more per vCPU and GB with no idle savings. Self-managed ASG nodes suit custom AMIs, GPU tuning, or exotic disk layouts, but you own kubelet, CNI, and upgrades. For predictable traffic, a practical pattern is two managed node groups: on-demand for critical services and Spot for background workers, cutting compute bills sharply where jobs tolerate eviction.
Install the AWS Load Balancer Controller with Helm in kube-system, pointing it at your cluster name and a dedicated service account. Annotate Ingress or Gateway API resources so AWS creates an Application Load Balancer. Terminate TLS at the ALB using ACM certificates. Keep Pods in private subnets; only the load balancer needs public reachability for internet-facing apps. This keeps your workload tier off the public internet while still serving HTTPS traffic through AWS-native load balancing, which integrates cleanly with VPC subnet tagging and security groups.
IAM Roles for Service Accounts lets Pods assume short-lived AWS credentials via an OIDC provider linked to the cluster. Enable it during cluster creation with withOIDC: true in eksctl, then annotate Kubernetes service accounts with IAM role ARNs. Applications read S3, SQS, or Secrets Manager without mounting long-lived access keys. This mirrors good secrets hygiene on VM-based Laravel deploys but scopes permissions per workload. Never mount static AWS keys into Pods in production; IRSA is the standard pattern when you run Kubernetes on AWS with Amazon EKS.
Most pain appears weeks after a successful demo deploy. IP exhaustion from the VPC CNI is common: each Pod consumes a VPC IP, and dense Jobs can drain subnet pools, leaving Pods Pending with insufficient IP errors. Fix it with prefix delegation or secondary CIDR blocks before traffic spikes. Upgrade drift hurts teams that skip EKS version planning; upgrade control plane, then node groups, then add-ons, using a staging cluster that mirrors production. Observability gaps leave HPA and Cluster Autoscaler blind without CloudWatch or Prometheus/Grafana. Missing Velero backups leave PersistentVolume data unprotected, and CrashLoopBackOff loops often trace to wrong image tags, missing ConfigMaps, or failed health probes.
The Amazon VPC CNI assigns every Pod a real VPC IP address, not an overlay network isolated from your subnet design. That means Pod density directly consumes IPs from the same pools as EC2 instances and RDS endpoints. A /16 VPC with /19 subnets per AZ works for many mid-size clusters, but namespaces running short-lived Jobs or batch workloads can exhaust a subnet faster than expected. Symptoms look like scheduler failures and Pending Pods, not application bugs. Enable prefix delegation or add secondary CIDR blocks before production traffic grows, and treat IP capacity as a first-class capacity metric alongside CPU and memory.
For most teams, yes. AWS patches the control plane, runs etcd across three Availability Zones, and integrates IAM, VPC, RDS, S3, Secrets Manager, and CloudWatch natively. Self-managed Kubernetes on EC2 using Kubespray or kubeadm suits air-gapped environments or cost-obsessed teams with strong platform engineers who want full control over every control-plane component. The trade-off is engineer hours: you babysit etcd, plan upgrades yourself, and own day-two toil that EKS offloads. If you already live in AWS and lack a dedicated platform team, EKS is usually the saner production path.
Yes. Containerize PHP-FPM and Nginx as sidecars, or use FrankenPHP, store sessions in Redis, and run queue workers as separate Deployments. It scales well when you need horizontal pod autoscaling and service isolation alongside other microservices. However, it adds complexity versus Deployer releases on EC2 with Apache and PHP-FPM, which remain the right call for many booking and legal-tech portals until traffic and service count grow. On projects like Adventure Third Pole Trek, Laravel plus Livewire on traditional deploy pipelines still fits the workload shape today; migrate to EKS when multi-service scaling clearly justifies the control-plane and ops overhead.
Expect 15–25 minutes for a typical cluster create. eksctl provisions CloudFormation stacks under the hood for the VPC, control plane, node groups, and related IAM resources. A failed create often leaves partial stacks behind, and you must delete those before retrying or you will hit conflicting resource errors. After the cluster is ready, run aws eks update-kubeconfig for your region and verify with kubectl get nodes. Budget time for post-create add-ons too, including the AWS Load Balancer Controller, observability agents, and IRSA role bindings, before calling the cluster production-ready.
Beyond the cluster itself, production readiness means ingress, secrets, scaling, and backups. Install the AWS Load Balancer Controller for ALB-based ingress with ACM TLS termination. Bind Pod permissions with IRSA instead of static keys. Set CPU and memory requests on every Deployment so the scheduler and Cluster Autoscaler work correctly, then wire Horizontal Pod Autoscaling to CPU or custom metrics. Install CloudWatch or Prometheus/Grafana so autoscaling is not blind. Use Velero with S3 backup targets for PersistentVolume data. Automate changes with GitOps via Flux or Argo CD, or Terraform, because manual kubectl edits do not survive staff turnover. Keep a staging cluster that mirrors production add-ons for upgrade testing.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
