Run Kubernetes on AWS with Amazon EKS

August 09, 2026 Khimananda Oli 7 min read Database

By Khimananda Oli | Last reviewed: August 2026

Teams often struggle to run Kubernetes on AWS with Amazon EKS because they treat it as a simple managed service rather than a shared responsibility model requiring deliberate architectural choices. While EKS removes control plane management, you still own the networking, security boundaries, and node lifecycle configuration essential for production stability. This guide provides the concrete implementation patterns I use when deploying compliant, cost-efficient clusters for global and Nepal-based clients.

Quick answer: To successfully run Kubernetes on AWS with Amazon EKS, provision a multi-AZ VPC with private subnets, deploy managed node groups or Karpenter for compute, configure IRSA for pod-level IAM permissions, and implement comprehensive observability before workloads touch the cluster.

How do you architect a VPC to run Kubernetes on AWS with Amazon EKS securely?

Networking is where most EKS failures originate. A common mistake is deploying into a default VPC or using public subnets for worker nodes, which exposes your infrastructure to unnecessary attack surfaces and complicates compliance audits like SOC 2 or ISO 27001. When you set up a VPC on AWS specifically for EKS, you must plan for IP address exhaustion, private connectivity, and strict egress controls from day one.

Recommended VPC topology when you run Kubernetes on AWS with Amazon EKS: private worker nodes across three AZs with dedicated NAT gateways for resilient egress.

Subnet sizing and CIDR planning

EKS consumes IP addresses aggressively. Each pod requires an ENI-trunked IP from the subnet pool. For production clusters expecting growth, allocate at least /20 for private subnets per AZ. This provides 4,096 IPs per zone, accommodating node scaling and pod density without triggering IP exhaustion events that stall deployments. Public subnets can remain /24 since they only host NAT Gateways and load balancers.

Private endpoint strategy

Disable public API server access immediately after initial bootstrap. Configure VPC endpoints for ECR, S3, STS, and CloudWatch Logs to keep traffic within the AWS backbone. This reduces data transfer costs and eliminates internet exposure for internal services. In regulated environments serving Nepal or international markets, this isolation is often a mandatory compliance control.

What is the most secure way to manage IAM permissions in EKS?

Never attach IAM roles directly to EC2 instances running EKS nodes. This grants every pod on that node identical permissions, violating least-privilege principles and failing security audits. Instead, use IAM Roles for Service Accounts (IRSA) to bind granular AWS permissions to specific Kubernetes service accounts. If you are new to this pattern, review AWS IAM best practices for least-privilege access before implementing.

# Create OIDC provider association (one-time per cluster)
eksctl utils associate-iam-oidc-provider --cluster=prod-eks-cluster

# Annotate service account with IAM role ARN
kubectl annotate serviceaccount my-app-sa \
  -n production \
  eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/MyAppRole

# Trust policy condition for the IAM role
{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.ap-south-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "oidc.eks.ap-south-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub": "system:serviceaccount:production:my-app-sa"
    }
  }
}

This configuration ensures only pods using the my-app-sa service account in the production namespace can assume the role. Audit logs will show precise identity attribution, satisfying SOC 2 CC6.1 and ISO 27001 A.9.4 requirements. Rotate OIDC thumbprints annually and automate validation through CI pipelines.

How do you optimize compute costs when you run Kubernetes on AWS with Amazon EKS?

Compute typically represents 60–80% of EKS spend. Blindly using On-Demand Managed Node Groups leads to massive waste. Implement a tiered compute strategy combining savings plans, spot instances for fault-tolerant workloads, and just-in-time provisioning via Karpenter.

Strategy	Best For	Savings Potential	Operational Overhead
Managed Node Groups (On-Demand)	Stateful databases, critical system pods	0%	Low
Spot Instances + MNG	Batch jobs, dev/test, stateless APIs	60–90%	Medium
Karpenter Auto-Provisioning	Variable workloads, mixed instance types	50–80%	Medium-High
EKS Fargate	Isolated tenants, bursty microservices	Variable	Low
Graviton (ARM) Nodes	General purpose, containerized apps	20–40%	Low

Karpenter decision flow for cost-efficient compute selection when you run Kubernetes on AWS with Amazon EKS in production.

Karpenter over Cluster Autoscaler

In 2026, Karpenter is the de facto standard for EKS autoscaling. Unlike Cluster Autoscaler which scales predefined node groups, Karpenter provisions exactly the right instance type based on pending pod requirements. It supports consolidation natively, terminating underutilized nodes during low-traffic periods. Install via Helm and define NodePools with instance category constraints rather than explicit types to maximize spot availability.

Graviton adoption checklist

Verify all container images support arm64 architecture (multi-arch builds preferred)
Test JVM applications with Corretto or Zulu ARM distributions
Benchmark latency-sensitive workloads; some see 10–15% improvement
Use separate NodePools for ARM and x86 to prevent scheduling conflicts
Apply taints/tolerations if legacy x86-only workloads coexist

What observability stack should you deploy before running production workloads?

You cannot safely run Kubernetes on AWS with Amazon EKS without real-time visibility into cluster health, resource saturation, and application performance. Deploy monitoring before your first business workload. I recommend starting with Prometheus and Grafana for complete observability, supplemented by AWS-native tools for infrastructure metrics.

Install AWS Distro for OpenTelemetry (ADOT): Collect traces, metrics, and logs uniformly. Avoid vendor lock-in while integrating with CloudWatch X-Ray and AMP.
Deploy kube-state-metrics and node-exporter: Expose Kubernetes object state and host-level telemetry. These are non-negotiable for capacity planning.
Configure vertical pod autoscaler (VPA) in recommendation mode: Right-size requests/limits based on actual usage before enabling automatic updates.
Set up alert routing with severity tiers: P1 alerts (node down, API errors >5%) page on-call. P3 alerts (high memory, certificate expiry) go to Slack.
Enable control plane logging: Audit, authenticator, and controllerManager logs must ship to CloudWatch or S3 for compliance retention.

How do you maintain compliance and security posture in EKS?

Running EKS in regulated contexts demands continuous validation, not point-in-time checks. Automate policy enforcement using Kyverno or OPA Gatekeeper. Define Pod Security Standards at namespace level to block privileged containers, hostPath mounts, and root execution. Integrate image scanning into your CI pipeline — reference container registry options including ECR scanning for native integration.

Defense-in-depth security layers required when you run Kubernetes on AWS with Amazon EKS for compliant production environments.

For secrets management, never store credentials in ConfigMaps or environment variables. Use AWS Secrets Manager with the CSI driver to mount secrets as volumes. Enable automatic rotation and audit all access via CloudTrail. This approach satisfies financial and healthcare compliance requirements while simplifying developer workflows. Review secrets management patterns with HashiCorp Vault if you need multi-cloud portability beyond AWS-native tooling.

Production Readiness Checklist Before Going Live

Before declaring your EKS cluster production-ready, validate these non-negotiable items:

Multi-AZ deployment with pod disruption budgets for all critical services
IRSA configured for every workload; no node-level IAM roles in use
Network policies restricting east-west traffic between namespaces
Backup solution tested (Velero or AWS Backup for EFS/EBS snapshots)
Disaster recovery runbook documented and exercised quarterly
Cost allocation tags applied to all resources for chargeback reporting
Control plane upgraded to latest supported version with add-ons compatible

Skipping any of these creates technical debt that compounds during incidents or audits. Budget time for hardening equal to your initial deployment effort.

Next Steps for Your EKS Journey

To successfully run Kubernetes on AWS with Amazon EKS requires disciplined architecture, security-first defaults, and continuous cost governance. Start with the VPC and IAM foundations outlined here before optimizing compute or adding advanced features. Every shortcut taken during setup becomes an incident waiting to happen at scale.

If your team needs hands-on guidance designing, securing, or migrating to EKS — especially for compliance-sensitive workloads — reach out to discuss your specific requirements. I help organizations build production-grade Kubernetes platforms that pass audits, survive traffic spikes, and stay within budget.

Frequently Asked Questions

Yes, the EKS control plane costs $0.10 per hour per cluster.

Install eksctl version 0.200 or later, then run eksctl create cluster with your desired name, region, and node type. This provisions the VPC, subnets, IAM roles, and managed node groups automatically within twenty minutes using current CloudFormation templates.

Yes, EKS supports Kubernetes 1.32 as a standard version in 2026. Always check the official EKS release calendar before upgrading, as AWS maintains three active versions simultaneously and deprecates older releases quarterly to ensure security patch compliance and feature compatibility.

EKS manages the control plane availability, upgrades, and etcd backups automatically. Self-managed clusters require you to handle certificate rotation, API server scaling, and master node recovery manually, significantly increasing operational overhead compared to the managed service model offered by AWS.

Use IRSA to map Kubernetes service accounts to specific IAM roles instead of attaching policies to worker nodes. This grants granular S3 or DynamoDB access at the pod level, following least privilege principles and preventing credential leakage across different application namespaces.

Yes, Fargate removes node management entirely by running pods on serverless compute. It suits spiky workloads but adds cold start latency and lacks DaemonSet support, making it less ideal for monitoring agents or storage drivers that require persistent node-level access.

Enable private endpoint access in the cluster networking settings and disable public access if internal-only traffic is required. Ensure your VPC has proper Route53 private hosted zones configured so kubectl commands resolve correctly without traversing the public internet.

Check pod logs with kubectl logs and describe events for OOMKilled or image pull failures. Common causes include insufficient memory requests, missing environment variables in ConfigMaps, or IAM permission denials when accessing AWS services via IRSA bindings.

Test upgrades in staging first, review deprecated APIs using kubent, and upgrade node groups sequentially. Maintain surge capacity during rolling updates to prevent downtime, and always backup critical resources with Velero before initiating the control plane version bump process.

Karpenter provisions right-sized nodes faster by bypassing Auto Scaling Groups entirely. It reduces waste by selecting optimal instance types based on pending pod requirements, whereas Cluster Autoscaler only scales predefined node groups and often leaves fragmented unused capacity.

Disable public endpoint access and use AWS PrivateLink or SSM Session Manager for kubectl connectivity. Integrate with IAM Identity Center for RBAC authentication, audit all API calls via CloudTrail, and apply network policies to restrict inter-namespace traffic flow.

Deploy Fluent Bit as a DaemonSet to forward container logs to CloudWatch Logs or OpenSearch. Configure multiline parsing for stack traces and add metadata enrichment via filters to correlate logs with specific pods, nodes, and namespaces for effective troubleshooting.

Yes, provision p4d or g5 instance types in dedicated node groups with NVIDIA device plugins installed. Use Karpenter to consolidate GPU nodes when idle and schedule training jobs with priority classes to maximize utilization while controlling expensive accelerator costs.

Verify aws-node DaemonSet health and check ENI allocation limits per instance type. Inspect security group rules allowing node-to-node traffic on required ports, and validate subnet CIDR availability since exhausted IP ranges cause pod scheduling failures silently.

Use Velero to snapshot persistent volumes and export Kubernetes manifests to S3 regularly. Schedule hourly incremental backups and test restores monthly in isolated namespaces to verify recovery procedures work before actual disaster scenarios occur in production environments.