Why architecture decisions come first
A Kubernetes cluster is easy to create and expensive to redo. Teams that start with a quick eksctl create cluster often discover months later that the VPC CIDR is too small for pod IPs, that every environment shares one cluster, or that stateful workloads are pinned to a single zone. Fixing those means migration, not configuration.
This page covers the design stage of our AWS EKS consulting work. The output is a written architecture your team can review, then build with Terraform modules. If you already have a cluster and want a second opinion, the same review applies.
What a good EKS architecture looks like
- It fits the team that will run it. A three-person platform team should not inherit a twelve-cluster, multi-region design.
- Failure domains are explicit: you can say what happens when a node, a zone or a deployment goes bad.
- IP space has headroom. The VPC CNI gives pods VPC addresses, so subnet sizing is a real constraint.
- Compute choices match workload behaviour, not habit.
- Every decision has a recorded reason and a trigger that would change it.
Single AZ or multi-AZ
Multi-AZ is the production default. Nodes in three zones, replicas spread with topologySpreadConstraints, and a load balancer targeting all of them gives you tolerance for a zone outage. Single-AZ still has a place in development clusters, batch jobs and cost-sensitive test environments.
The trade-offs are concrete:
- Cross-zone traffic is billed. Chatty service-to-service calls across zones add up, so topology-aware routing and zone-aware design matter for high-traffic systems.
- EBS volumes are zonal. A pod using a volume can only reschedule into the same zone. For databases on Kubernetes we plan replicas per zone, or recommend a managed database instead.
- Capacity has to exist in each zone. Autoscaling configuration must allow nodes in all of them.
A minimal spread rule for a stateless service looks like this:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: checkout
Compute: node groups, Karpenter or Fargate
| Option | Best for | Watch out for |
|---|---|---|
| Managed node groups | Steady baseline, system components, predictable workloads | Manual instance family choices, slower scaling |
| Karpenter | Variable load, mixed instance types, Spot usage | Needs a small always-on pool for Karpenter itself |
| Fargate profiles | Isolated or bursty pods, minimal node operations | No DaemonSets, limited storage options, per-pod cost |
Our usual pattern is a small managed node group for cluster-critical add-ons and Karpenter for application capacity, with Fargate only where isolation or zero node management is the point. Detail on scaling is in Karpenter and Cluster Autoscaler configuration.
Networking and access
We design the VPC with separate subnet tiers: private subnets for nodes and pods, public subnets only for load balancers and NAT, and optionally dedicated subnets for secondary pod CIDRs when IP space is tight. Decisions include:
- API endpoint access: private only, public restricted to known CIDRs, or both. Private-only is stronger but needs a way in, such as a VPN or bastion alternative.
- Egress: one NAT gateway per zone for resilience, or fewer for cost, with VPC endpoints for ECR, S3 and STS to reduce NAT traffic.
- Cluster connectivity: peering or Transit Gateway when clusters must reach other VPCs.
Pod-level controls build on this foundation: see network policies and security groups.
How many clusters, and what goes in them
The honest answer depends on blast radius. We typically recommend:
- Production and non-production in separate clusters, ideally separate AWS accounts.
- Namespaces with quotas, RBAC and policies for team separation inside a cluster.
- Extra clusters only for hard boundaries: regulated data, a different upgrade cadence, or a noisy workload that should not share control plane limits.
One large shared cluster is cheaper and simpler until an upgrade, a runaway controller or a noisy neighbour affects everyone. Many small clusters isolate risk but multiply upgrade and monitoring work. We help you pick the point on that curve that suits your team size.
A worked example: sizing the IP space
Suppose a team plans three private subnets, one per zone, and expects the platform to grow from a few services to dozens. With the VPC CNI each pod takes a VPC address, so the question is not how many nodes you need but how many pods will exist at peak, plus rolling update surge, plus headroom for nodes that Karpenter adds in a hurry. We work that estimate per zone, compare it with the subnet sizes on the table, and note whether prefix delegation or a secondary CIDR would be needed.
The point is not precision. It is to find, before any code exists, whether the first year of growth fits inside the network you have drawn. If it does not, the cheapest time to change the CIDR plan is now.
When not to use EKS
Not every workload needs Kubernetes. If you run a handful of stateless services and have no one to operate a cluster, ECS on Fargate or a platform-as-a-service may be cheaper and calmer. We will say so during design rather than sell a cluster you do not need. For broader platform choices see our Kubernetes consulting service.
Common failure modes
- Undersized CIDRs: a /24 per subnet runs out of IPs quickly with the VPC CNI. We size for growth and consider prefix delegation or custom networking.
- Everything in one node group: system pods starved by application load. We isolate critical add-ons with taints and dedicated capacity.
- Public API endpoint left open to the internet: restricted by CIDR or made private.
- Design that ignores upgrades: a cluster layout that cannot be upgraded without downtime is not finished.
Delivery and handover
You receive an architecture document with diagrams, a decision log, a sizing model for nodes and IPs, and a build plan. We hold a review session with your engineers so objections surface before code is written. After approval, implementation usually continues with cluster setup and documented state, and our engagement models explain whether we build it or coach your team through it.
How to tell the design is sound
Run a simple test: can a new engineer explain, from the document alone, what happens when a zone fails, how a new service gets capacity, and how the cluster is upgraded? If yes, the design is doing its job. If you want an independent view of an existing design, book a consultation.