What you need to know
- EKS separates an AWS-managed Kubernetes control plane from the compute that runs customer workloads.
- Control-plane communication reaches the customer VPC through EKS-managed network interfaces in selected subnets.
- Worker compute can use Auto Mode, managed or self-managed EC2 nodes, Fargate, or supported hybrid infrastructure.
- Application availability still depends on workload replicas, topology, networking, storage, scaling, and recovery design.
What is Amazon EKS architecture?
Amazon EKS architecture has two main parts: an AWS-managed Kubernetes control plane and a data plane where Pods run. AWS operates the API server, scheduler, controller manager, and etcd-backed control-plane infrastructure. Customers choose and configure workload compute, networking, identity, storage, traffic exposure, policies, and application operations according to the selected EKS mode.
The control plane runs in an AWS-managed account rather than directly inside the customer VPC. EKS creates requester-managed network interfaces in the subnets selected for the cluster so the control plane can communicate with nodes and Pods in the VPC.
Continue reading: Read the concise EKS definition · Read the complete Amazon EKS guide · AWS: What is Amazon EKS? ↗
The AWS-managed control plane
The Kubernetes API server is the entry point for cluster operations. The scheduler assigns pending Pods to suitable nodes, controllers reconcile declared state, and etcd stores Kubernetes API data. EKS operates these components, replaces unhealthy control-plane instances, patches the managed environment, and provides a highly available service across Availability Zones.
Users and automation reach the Kubernetes API endpoint. Authentication is integrated with AWS identity, while Kubernetes authorization determines allowed cluster actions. Control-plane logs can export API, audit, authenticator, controller-manager, and scheduler records to CloudWatch when enabled.
What the control plane does not run
The managed control plane does not run the customer's application containers. Pods run on the selected data-plane capacity. It also does not decide the application's replica strategy, service-level objectives, data recovery, or safe deployment process.
Continue reading: AWS: EKS control-plane best practices ↗
The data plane and compute choices
The data plane supplies CPU, memory, network, and local runtime capacity for Pods. A cluster can use one or more supported compute approaches, subject to their constraints. The right choice depends on required control, workload compatibility, scaling behavior, isolation, and operating capacity.
| Compute model | Who manages the node layer | Best understood as |
|---|---|---|
| EKS Auto Mode | AWS manages more compute and infrastructure capabilities | Managed EC2-based Kubernetes infrastructure |
| Managed node groups | AWS automates parts of EC2 node provisioning and lifecycle | Customer-selected EC2 capacity with assisted operations |
| Self-managed nodes | Customer | Maximum node control and maximum node responsibility |
| AWS Fargate | AWS | Eligible Pods run without customer-managed EC2 nodes |
| Hybrid Nodes | Customer manages connected machines | On-premises or edge compute joined to an AWS-hosted control plane |
Continue reading: How to create a standard EKS cluster · AWS: Manage compute resources ↗
VPC, subnet, and Pod networking
An EKS cluster uses a VPC and at least two suitable subnets in different Availability Zones for standard regional cluster creation. EKS places requester-managed network interfaces in selected subnets for control-plane communication. Nodes also use VPC networking, and the Amazon VPC CNI assigns VPC addresses to Pods on AWS infrastructure under its supported modes.
IP planning is a core architecture decision because nodes, Pods, load balancers, and managed interfaces consume addresses. Private subnets are commonly used for nodes, while public or private load balancers expose selected Services. Security groups, route tables, NAT or VPC endpoints, DNS, and NetworkPolicy together shape reachability.
API endpoint access
The Kubernetes API endpoint can use public, private, or combined access settings. Choose the model based on administrator and automation paths, then restrict allowed public CIDRs and provide private connectivity where required. A private endpoint alone does not make every workload or load balancer private.
Continue reading: AWS: EKS networking requirements ↗ · AWS: Configure EKS networking ↗
How traffic reaches an application
A typical request enters through an AWS load balancer created for a Kubernetes Service or Ingress. The load balancer forwards traffic to supported targets, Kubernetes Services provide stable discovery, and Pods process the request. Exact routing depends on the controller, target type, network configuration, and compute model.
Internal service-to-service traffic stays within the designed cluster and VPC paths. NetworkPolicy can limit Pod flows when supported and correctly configured. Security groups govern VPC interface traffic. TLS termination may occur at the load balancer, within the cluster, or at both layers according to security requirements.
Identity and permissions
EKS architecture includes separate identity paths for people, platform automation, nodes, and workloads. Human or CI identities authenticate through AWS mechanisms and are authorized for Kubernetes actions. Nodes use an IAM role to join and interact with required AWS services. Pods should receive their own narrowly scoped AWS permissions through EKS Pod Identity or IAM roles for service accounts rather than inheriting broad node permissions.
Kubernetes service accounts and RBAC control access to Kubernetes resources. IAM policies control AWS API actions. A sound architecture documents both layers and avoids treating a successful login as unlimited cluster authority.
Continue reading: EKS security best practices · AWS: IAM best practices for EKS ↗
Storage and state
Stateless Pods can be replaced easily, but stateful workloads need deliberate storage and recovery. Container Storage Interface drivers connect Kubernetes storage requests to services such as Amazon EBS and Amazon EFS. Other integrations can support different file, object, or specialized storage requirements.
A PersistentVolume is not a backup. Define encryption, access mode, topology, snapshots, retention, restore testing, and deletion behavior. EBS volumes are tied to an Availability Zone, so scheduling and recovery designs must account for that topology.
Availability and failure boundaries
EKS provides a highly available managed control plane, but workload availability depends on the application architecture. Run appropriate replicas across nodes and Availability Zones, apply topology spread or anti-affinity where needed, use Pod Disruption Budgets carefully, and test node, zone, dependency, and deployment failures.
Separate clusters may reduce some blast radius but add fixed fees and operating overhead. Namespaces provide logical organization but are not a complete security boundary by themselves. Select accounts, VPCs, clusters, node groups, and namespaces based on risk, ownership, lifecycle, and compliance needs.
A production architecture review
Before production, trace one request and one deployment through every layer. Identify who authenticates, which API is called, where traffic enters, how Pods are scheduled, which AWS permissions they obtain, where data persists, which logs record the action, and how the system recovers from failure.
- Control plane: endpoint access, logs, access entries, version policy, and quotas.
- Compute: node or Fargate model, capacity, scaling, isolation, images, and updates.
- Network: CIDR capacity, subnets, routes, endpoints, security groups, policies, DNS, and load balancers.
- Identity: human, automation, node, and workload roles with least privilege.
- State: storage topology, encryption, backup, retention, and tested restore.
- Reliability: replicas, failure domains, health checks, disruption controls, and recovery targets.
- Operations: observability, cost allocation, incident response, ownership, and upgrade rehearsals.
Frequently asked questions
What are the two main parts of EKS architecture?
The two main parts are the AWS-managed Kubernetes control plane and the data plane where customer workloads run.
Is the EKS control plane inside my VPC?
No. The regional EKS control plane runs in an AWS-managed account. EKS creates requester-managed network interfaces in selected customer subnets for communication with the VPC.
Where do EKS Pods run?
Pods can run on EKS Auto Mode capacity, managed or self-managed EC2 nodes, AWS Fargate, or supported hybrid infrastructure, depending on cluster configuration and workload constraints.
Does a highly available EKS control plane make my application highly available?
No. Application availability still requires replicas, suitable topology, healthy compute, resilient dependencies, traffic management, data protection, scaling, and tested recovery.
How do EKS Pods access AWS services?
Use a workload-specific identity such as EKS Pod Identity or IAM roles for service accounts so Pods receive narrowly scoped temporary AWS credentials instead of broad node permissions or embedded keys.