Lesson 02 — Amazon EKS Cluster Design

Learning Objectives

By the end of this lesson, you will be able to:

Explain the major design decisions involved in building an Amazon EKS cluster
Select an appropriate cluster topology for different business requirements
Design secure VPC and subnet architectures for Amazon EKS
Choose between public, private and hybrid API endpoint access
Design worker-node groups for different workload types
Understand single-cluster and multi-cluster strategies
Apply multi-tenancy and workload-isolation patterns
Design highly available and resilient Amazon EKS environments
Plan IP addressing and VPC capacity for Pods
Integrate security, logging, monitoring and governance into cluster design
Develop an enterprise Amazon EKS reference design

Why This Matters

Creating an Amazon EKS cluster is easy.

Designing one that is secure, scalable, supportable and compliant is much more difficult.

A poorly designed cluster may experience:

IP address exhaustion
Weak workload isolation
Excessive administrative access
Cluster-wide outages
Inefficient node utilisation
Difficult upgrades
Uncontrolled costs
Inconsistent logging
Compliance gaps
Large security blast radius

Cluster design decisions affect the entire lifecycle of the platform.

Cluster Design Decisions

↓

Security

↓

Availability

↓

Scalability

↓

Operations

↓

Cost

↓

Compliance

For a Cloud Security Engineer, cluster design is important because security controls must be built into the architecture before production workloads are deployed.

What is Amazon EKS Cluster Design?

Amazon EKS cluster design is the process of deciding how an EKS environment will be structured to meet:

Business requirements
Security requirements
Availability requirements
Performance requirements
Compliance requirements
Operational requirements
Cost requirements

The design includes:

AWS account placement
AWS Region
VPC
Subnets
API endpoint access
Node groups
Namespace structure
Workload isolation
Networking
Identity
Logging
Monitoring
Add-ons
Upgrade strategy
Disaster recovery

Cluster Design Principles

A strong Amazon EKS design should follow these principles:

Amazon EKS Design Principles

├── Secure by Default
├── Highly Available
├── Scalable
├── Automated
├── Observable
├── Recoverable
├── Cost Aware
├── Standardised
└── Governed

Start with Business Requirements

Before selecting a technical architecture, identify the business requirements.

Questions include:

What applications will run on the cluster?
Is the environment development, testing or production?
What data will the applications process?
What availability target is required?
Is internet exposure required?
Are there compliance requirements?
How many teams will share the cluster?
How quickly will workloads scale?
Is multi-region recovery required?
What is the expected cluster lifetime?

Example Requirement Classification

Requirement	Example
Business criticality	Critical payment service
Availability	99.99% target
Data classification	Restricted
Compliance	PCI DSS
Internet exposure	Public customer API
Recovery	Secondary-region recovery
Tenancy	Multiple internal teams
Scaling	High seasonal demand

These requirements influence the final cluster design.

Amazon EKS Design Layers

Enterprise Organisation

↓

AWS Account

↓

AWS Region

↓

Amazon VPC

↓

Amazon EKS Cluster

↓

Node Groups

↓

Namespaces

↓

Workloads

Every layer introduces security and operational decisions.

AWS Account Design

The AWS account is an important isolation boundary.

Enterprises commonly separate accounts by:

Environment
Business unit
Application
Data classification
Regulatory scope
Operational ownership

Example Account Structure

AWS Organization

├── Shared Services Account
├── Security Account
├── Logging Account
├── Development Account
├── Testing Account
├── Production Account
└── Disaster Recovery Account

Production and non-production clusters should generally not share the same AWS account.

Why Use Multiple AWS Accounts?

Benefits include:

Stronger isolation
Separate billing
Separate IAM boundaries
Reduced blast radius
Easier compliance scoping
Independent service quotas
Simpler incident containment

Compromise in Development

Should Not Automatically Provide

Access to Production

Cluster-per-Account Design

Some organisations deploy one major production cluster per AWS account.

Production Account

↓

One Amazon EKS Cluster

↓

Critical Business Workloads

Benefits:

Clear ownership
Strong isolation
Easier billing
Smaller blast radius

Challenges:

More accounts
More operational overhead
More cluster-management effort

Multiple Clusters per Account

Other organisations run several clusters in one AWS account.

Production Account

├── payments-eks
├── identity-eks
└── analytics-eks

Benefits:

Reduced account-management overhead
Shared networking and services
Easier account-level administration

Challenges:

Shared quotas
Larger account blast radius
More complex access management

Regional Design

Amazon EKS clusters are regional resources.

Select a Region based on:

Customer location
Data residency
Regulatory obligations
Service availability
Latency
Cost
Disaster recovery
Existing enterprise architecture

Single-Region Design

AWS Region

↓

Multi-AZ Amazon EKS Cluster

↓

Production Workloads

This is appropriate when:

Regional resilience is sufficient
Recovery can occur from backups
Regulatory requirements allow a single Region
Application complexity must be minimised

Multi-Region Design

Primary Region

↓

Production Amazon EKS Cluster

↓

Replication and Backup

↓

Secondary Region

↓

Recovery Amazon EKS Cluster

Multi-region designs support:

Disaster recovery
Regional resilience
Geographic performance
Regulatory separation

They also introduce:

Data-replication complexity
DNS failover
Identity consistency
Deployment synchronisation
Increased cost
Recovery testing requirements

Cluster Topology Options

Common Amazon EKS topology patterns include:

Pattern	Description
Shared cluster	Multiple teams share one cluster
Cluster per environment	Separate development, testing and production clusters
Cluster per application	Each major application has its own cluster
Cluster per business unit	Each business unit manages a cluster
Cluster per compliance boundary	Regulated workloads are isolated
Cluster per Region	Separate cluster in each Region

Shared Cluster Design

Shared Amazon EKS Cluster

├── Team A Namespace
├── Team B Namespace
├── Team C Namespace
└── Shared Platform Namespace

Benefits:

Efficient resource use
Fewer clusters
Reduced platform-management overhead
Shared monitoring and services

Risks:

Larger blast radius
Multi-tenancy complexity
Shared control plane
Resource contention
Complex RBAC
Difficult compliance boundaries

Dedicated Cluster Design

Application A

↓

Dedicated EKS Cluster

Application B

↓

Dedicated EKS Cluster

Benefits:

Strong isolation
Independent upgrades
Clear ownership
Smaller blast radius
Easier compliance scoping

Challenges:

Increased cost
More clusters to manage
Duplicate platform services
More operational overhead

Cluster-per-Environment Design

A common enterprise pattern is:

Development Cluster

↓

Testing Cluster

↓

Staging Cluster

↓

Production Cluster

Benefits include:

Environment isolation
Safer testing
Independent access
Controlled promotion
Reduced production risk

Production should not share the same cluster with development workloads.

Single Large Cluster vs Multiple Smaller Clusters

Single Large Cluster	Multiple Smaller Clusters
Better resource efficiency	Stronger isolation
Fewer control planes	Smaller blast radius
Centralised operations	Independent upgrades
More complex tenancy	More operational overhead
Larger failure impact	Higher infrastructure cost
Shared compliance scope	Easier compliance separation

There is no universal answer.

The correct design depends on risk, cost and operational maturity.

Blast Radius

Blast radius describes the potential impact of a failure or compromise.

One Shared Cluster

↓

Control Plane or Policy Failure

↓

Many Applications Affected

Smaller clusters reduce the number of workloads affected by one event.

Multi-Tenancy Design

Multi-tenancy means multiple teams or applications share the same cluster.

Security controls should include:

Namespace isolation
RBAC
Network Policies
ResourceQuotas
LimitRanges
Pod Security Admission
Admission policies
Dedicated Service Accounts
Node isolation where required
Central logging

Namespace Design

Namespaces provide logical isolation.

Example:

Cluster

├── platform-system
├── security-tools
├── payments
├── customer-portal
├── fraud-detection
└── monitoring

Each namespace should have:

Owner
Purpose
Environment
Data classification
Resource quota
Security baseline
Network Policy
Service Accounts

Namespace Naming Convention

Example:

<business-unit>-<application>-<environment>

Examples:

payments-api-prod

digital-portal-dev

security-monitoring-prod

Naming standards improve ownership and automation.

Namespace Baseline

A namespace onboarding process should automatically create:

Ownership labels
ResourceQuota
LimitRange
Default-deny NetworkPolicy
Pod Security labels
Service Accounts
Logging configuration
Monitoring configuration

Namespace Request

↓

Approved Template

↓

Secure Namespace Created

↓

Application Team Onboarded

Hard Multi-Tenancy

Hard multi-tenancy is required when tenants are not trusted.

A shared Kubernetes cluster may not always provide sufficient isolation.

For untrusted tenants, consider:

Separate clusters
Separate AWS accounts
Dedicated node groups
Strong network segmentation
Sandboxed runtimes
Separate encryption keys

Low Trust Between Tenants

↓

Prefer Stronger Isolation

↓

Separate Cluster or Account

Soft Multi-Tenancy

Soft multi-tenancy is suitable when teams belong to the same organisation and share a trust model.

Controls still include:

Namespaces
RBAC
Resource quotas
Network Policies
Admission control
Monitoring

VPC Design

Amazon EKS runs inside an Amazon VPC.

The VPC design should include:

Sufficient IP capacity
Multiple Availability Zones
Public and private subnet strategy
Route tables
NAT or egress architecture
VPC endpoints
Security Groups
Network monitoring

Recommended VPC Pattern

Amazon VPC

├── Public Subnets
│   ├── Internet-facing Load Balancers
│   └── NAT Gateways
│
├── Private Application Subnets
│   ├── EKS Worker Nodes
│   └── Application Pods
│
└── Restricted Data Subnets
    ├── Databases
    └── Internal Services

Worker nodes should normally run in private subnets.

Public Subnets

Public subnets commonly host:

Internet-facing load balancers
NAT Gateways
Controlled ingress components

Worker nodes generally should not require public IP addresses.

Private Subnets

Private subnets commonly host:

Worker nodes
Pods
Internal load balancers
Platform services

Private subnets reduce direct internet exposure.

Availability Zone Design

Production clusters should use multiple Availability Zones.

Example:

Region

├── AZ-A
│   └── Private Subnet A
├── AZ-B
│   └── Private Subnet B
└── AZ-C
    └── Private Subnet C

Worker nodes and application replicas should be distributed across the zones.

Subnet Tagging

Subnets used by EKS and AWS load balancers require appropriate tags.

Enterprise designs should standardise:

Public subnet tags
Private subnet tags
Cluster discovery tags where required
Ownership tags
Environment tags

Incorrect subnet tagging may result in load balancers being created in the wrong location.

IP Address Planning

Amazon VPC CNI assigns VPC IP addresses to Pods.

This means that cluster growth consumes subnet IP capacity.

Subnet IP Pool

↓

Worker Node ENIs

↓

Pod IP Addresses

Poor IP planning can prevent new Pods from starting.

IP Exhaustion

Symptoms may include:

Pods remaining Pending
CNI errors
Nodes unable to allocate Pod IPs
Failed scaling events
Service disruption

IP Planning Questions

Ask:

How many nodes are expected?
How many Pods per node?
What is the maximum cluster size?
How much growth is expected?
Are other resources using the same subnet?
Is dual-stack required?
Are secondary CIDR ranges available?

Example Capacity Calculation

20 Nodes

×

30 Pods per Node

=

600 Pod IP Addresses

Additional capacity is needed for:

Nodes
Load balancers
Scaling
Platform services
Failover
Reserved addresses

Secondary CIDR Strategy

Some enterprises attach secondary CIDR ranges to the VPC for Pod networking.

Benefits include:

Additional Pod IP capacity
Separation of node and Pod address spaces
Easier growth planning

IPv6 Considerations

IPv6 may reduce IPv4 pressure.

Consider:

Application compatibility
Security tooling compatibility
Network Policy support
Load balancer design
Logging and monitoring
Hybrid connectivity

EKS API Endpoint Design

Amazon EKS supports:

Public endpoint
Private endpoint
Public and private endpoints

Public Endpoint

Administrator

↓

Internet

↓

Restricted EKS Public API Endpoint

Advantages:

Simple access
Easy CI/CD integration

Risks:

Larger attack surface
Requires strict CIDR restrictions
Requires strong identity controls

Private Endpoint

Administrator

↓

VPN, Direct Connect or Private Access

↓

Private EKS API Endpoint

Advantages:

Reduced internet exposure
Stronger network control

Challenges:

Requires private connectivity
CI/CD runners require VPC access
More operational planning

Public and Private Endpoint

This hybrid model allows:

Internal access through private networking
Restricted external administrative access

Public access should be limited to approved CIDR ranges.

Recommended Endpoint Strategy

Environment	Recommended Approach
Sandbox	Restricted public or hybrid
Development	Hybrid or private
Production	Private where operationally feasible
Regulated production	Private with controlled administration

The final decision should match operational requirements.

Worker Node Design

Worker nodes provide compute capacity.

Design decisions include:

Managed or self-managed nodes
Instance types
On-Demand or Spot
Node group count
AMI type
Architecture
Scaling
Availability Zones
Security Groups
IAM roles

Managed Node Groups

Managed Node Groups are suitable for most workloads.

Benefits:

Simplified lifecycle
Managed updates
Integration with EKS
Automated node replacement
Easier scaling

Self-Managed Nodes

Self-managed nodes may be required for:

Custom AMIs
Special bootstrap processes
Unique hardware configurations
Advanced lifecycle control

They require more operational responsibility.

Fargate

Fargate provides serverless Pod compute.

Suitable for:

Lightweight workloads
Isolated application Pods
Reduced node management
Event-driven services

Limitations may include:

DaemonSet requirements
Privileged workloads
Some storage and networking patterns
Cost at scale
Security tooling requirements

Node Group Strategy

Avoid placing every workload in one node group.

Example:

Amazon EKS Cluster

├── System Node Group
├── General Application Node Group
├── Sensitive Workload Node Group
├── Spot Workload Node Group
└── Security Tooling Node Group

System Node Group

Used for:

CoreDNS
Metrics Server
GitOps controllers
Admission controllers
Monitoring agents
Platform services

Separating system workloads improves stability.

Application Node Groups

Application node groups may be separated by:

Environment
Business unit
Workload criticality
Instance type
Compliance tier
Architecture
Cost model

Sensitive Workload Node Group

Use for:

Payment applications
Identity services
Confidential data processing
Regulated workloads

Controls may include:

Dedicated IAM role
Restricted Security Groups
No Spot Instances
Stronger monitoring
Dedicated encryption
Restricted scheduling

Spot Node Groups

Spot Instances reduce cost.

Suitable for:

Batch workloads
Stateless applications
Development workloads
Fault-tolerant services

Avoid relying only on Spot capacity for critical workloads.

Mixed Capacity Strategy

Critical Base Capacity

↓

On-Demand Nodes

+

Elastic Capacity

↓

Spot Nodes

This balances availability and cost.

Instance Type Selection

Consider:

CPU
Memory
Network performance
Storage
GPU requirements
Pod density
Availability
Cost
Architecture

Avoid using one instance type for every workload.

Node Architecture

EKS node groups may use:

x86_64
ARM-based AWS Graviton

ARM-based instances may reduce cost but require compatible container images.

Node Group Isolation

Use:

Taints
Tolerations
Node affinity
Node selectors
Topology spread constraints

Example taint:

kubectl taint nodes sensitive-node \
workload=restricted:NoSchedule

Only approved workloads should tolerate the taint.

Scheduling Example

spec:
  nodeSelector:
    workload-tier: restricted

  tolerations:
    - key: workload
      operator: Equal
      value: restricted
      effect: NoSchedule

Node IAM Role Design

Node IAM roles should contain only permissions required by the node and platform components.

Applications should not depend on broad node permissions.

Use:

EKS Pod Identity
IRSA
Dedicated Service Accounts

Node Security Group Design

Node Security Groups should allow only required communication.

Review:

Control-plane communication
Node-to-node communication
Load balancer access
Administrative access
Outbound connectivity
Security tooling access

Avoid unrestricted inbound rules.

Security Groups for Pods

Security Groups for Pods may provide workload-level VPC controls.

Useful for:

Sensitive workloads
Database access
Legacy applications
Compliance boundaries

They complement Kubernetes Network Policies.

Cluster Autoscaling

Clusters must scale safely.

Scaling components may include:

Horizontal Pod Autoscaler
Vertical Pod Autoscaler
Cluster Autoscaler
Karpenter
Managed node group scaling

Scaling Architecture

Application Load Increases

↓

Horizontal Pod Autoscaler

↓

More Pods Required

↓

Insufficient Capacity

↓

Cluster Autoscaler or Karpenter

↓

New Worker Nodes

Karpenter Design Considerations

Karpenter can dynamically provision nodes based on workload requirements.

Benefits:

Faster scaling
Flexible instance selection
Improved resource efficiency
Reduced idle capacity

Security considerations:

Protect Karpenter permissions
Restrict allowed instance types
Control subnet and Security Group selection
Validate NodeClass and NodePool resources
Monitor provisioning behaviour

Resource Management Design

Use:

Resource requests
Resource limits
ResourceQuotas
LimitRanges
PriorityClasses
PodDisruptionBudgets

These controls improve reliability and reduce noisy-neighbour risk.

Priority Classes

PriorityClasses determine workload scheduling priority.

Example hierarchy:

Critical Platform Services

↓

Security Services

↓

Production Applications

↓

Development Workloads

Incorrect PriorityClass usage may allow one workload to disrupt others.

PodDisruptionBudgets

PodDisruptionBudgets help maintain availability during:

Node upgrades
Node draining
Maintenance
Scaling events

Example:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-api-pdb

spec:
  minAvailable: 2

  selector:
    matchLabels:
      app: payment-api

Application Availability Design

Applications should use:

Multiple replicas
Multiple Availability Zones
Pod anti-affinity
Topology spread constraints
Readiness probes
Liveness probes
PodDisruptionBudgets
Load balancing

Topology Spread

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule

    labelSelector:
      matchLabels:
        app: payment-api

This distributes Pods across zones.

Ingress Design

Ingress options may include:

AWS Load Balancer Controller
NGINX Ingress Controller
Service type LoadBalancer
API Gateway integration
Private load balancers

Public Application Architecture

Internet

↓

Amazon Route 53

↓

AWS WAF

↓

Application Load Balancer

↓

Ingress

↓

Kubernetes Service

↓

Pods

Internal Application Architecture

Corporate Network

↓

Private Connectivity

↓

Internal Load Balancer

↓

Ingress

↓

Service

↓

Pods

Egress Design

Applications may require access to:

AWS APIs
External SaaS
Package repositories
Partner services
Internal enterprise systems

Options include:

NAT Gateway
Central firewall
Egress proxy
VPC endpoints
Network Policies
DNS controls

VPC Endpoints

VPC endpoints may provide private access to services such as:

Amazon ECR
Amazon S3
CloudWatch
AWS STS
Secrets Manager
Systems Manager

Benefits:

Reduced internet dependency
Improved security
Lower NAT traffic
Controlled service access

DNS Design

Amazon EKS commonly uses CoreDNS.

Design considerations include:

Replica count
Resource requests
Node placement
Availability
Upgrades
Logging
Monitoring
Integration with Route 53 Resolver

Storage Design

Select storage based on workload requirements.

Storage	Typical Use
Amazon EBS	Block storage for a single node
Amazon EFS	Shared file storage
FSx	High-performance file workloads
S3 integration	Object storage

EBS Design

Consider:

Availability Zone binding
Volume encryption
Snapshot policies
Performance class
Backup
Access modes

EBS volumes are tied to an Availability Zone.

EFS Design

Amazon EFS supports shared access across multiple Availability Zones.

Useful for:

Shared content
Web applications
Development tools
Multi-replica file access

StorageClass Governance

Approved StorageClasses should define:

Encryption
Volume type
Reclaim policy
Expansion
Binding mode
Performance settings

Unapproved StorageClasses should be restricted.

Encryption Design

Encrypt:

Kubernetes Secrets
EBS volumes
EFS file systems
Databases
Backups
Logs
Container registries

Use AWS KMS according to enterprise key-management policy.

Secrets Design

Options include:

Kubernetes Secrets with encryption
AWS Secrets Manager
Systems Manager Parameter Store
Secrets Store CSI Driver
External Secrets Operator

Secrets should not be stored in Git.

Identity Design

Human and workload identity must be designed separately.

Human Access

Enterprise Identity Provider

↓

AWS IAM Role

↓

EKS Access Entry

↓

Kubernetes RBAC

Workload Access

Pod

↓

Service Account

↓

EKS Pod Identity or IRSA

↓

AWS IAM Role

EKS Access Design

Access should be separated by role.

Examples:

Platform administrator
Security administrator
Read-only auditor
Application operator
Incident responder
CI/CD deployer

Avoid giving every administrator cluster-admin.

RBAC Design

RBAC should be:

Role-based
Namespace-scoped where possible
Reviewed regularly
Managed through Git
Protected by admission policies
Logged and monitored

Logging Design

Enable and centralise:

API Server logs
Audit logs
Authenticator logs
Scheduler logs
Controller Manager logs
Application logs
Node logs
Admission events
Runtime alerts

Logging Architecture

Amazon EKS Clusters

↓

CloudWatch Logs

↓

Central Logging Account

↓

SIEM

↓

SOC

Monitoring Design

Monitor:

Control-plane health
API latency
Node health
Pod health
Resource use
Autoscaling
Networking
DNS
Storage
Admission controllers
Security tools

Platform Add-On Design

Common add-ons include:

Amazon VPC CNI
CoreDNS
kube-proxy
EBS CSI Driver
EFS CSI Driver
Metrics Server
AWS Load Balancer Controller
External DNS
Cluster Autoscaler or Karpenter
Kyverno or Gatekeeper
Runtime monitoring

Each add-on should have:

Owner
Version
Upgrade plan
Security review
Resource limits
Monitoring
Recovery plan

Add-On Ownership

Platform Team

Owns:

- Version
- Configuration
- Security
- Availability
- Upgrade
- Monitoring

Unowned add-ons become operational and security risks.

GitOps Design

GitOps can manage:

Cluster add-ons
Namespaces
RBAC
Network Policies
Admission policies
Application deployments
Monitoring configuration

Git Repository

↓

Pull Request

↓

Approval

↓

GitOps Controller

↓

Amazon EKS

Infrastructure as Code

Use Infrastructure as Code for:

VPC
Subnets
EKS cluster
Node groups
IAM roles
Security Groups
Logging
Encryption
Add-ons

Benefits include:

Repeatability
Review
Version history
Drift detection
Faster recovery

Upgrade Design

Plan upgrades before the cluster enters production.

The upgrade strategy should include:

Kubernetes version lifecycle
Add-on compatibility
Node AMI updates
API deprecations
Policy compatibility
Workload testing
Rollback planning

Upgrade Sequence

Development Cluster

↓

Testing Cluster

↓

Staging Cluster

↓

Production Cluster

Do not upgrade every cluster simultaneously.

Cluster Lifecycle

Design

↓

Provision

↓

Validate

↓

Operate

↓

Upgrade

↓

Review

↓

Retire

Each stage should have security and governance controls.

Disaster Recovery Design

Recovery options include:

Rebuild from Infrastructure as Code
Restore applications through GitOps
Restore persistent data
Recreate IAM and networking
Restore Secrets
Activate secondary Region

Rebuild-Oriented Recovery

Infrastructure as Code

+

GitOps

+

Backups

↓

Rebuild EKS Environment

The Kubernetes control plane itself is managed, but application and configuration recovery remains the customer’s responsibility.

Recovery Objectives

Define:

Recovery Time Objective
Recovery Point Objective
Maximum acceptable downtime
Data-loss tolerance
Recovery ownership
Test frequency

Cost Design

Major cost areas include:

EKS cluster fee
EC2 worker nodes
Fargate
Load balancers
NAT Gateways
Data transfer
CloudWatch logs
Storage
Security tooling

Cost Controls

Use:

Right-sized instances
Spot capacity for suitable workloads
Autoscaling
Log-retention policies
Shared platform services where appropriate
Resource quotas
Cost allocation tags
Namespace chargeback or showback

Enterprise Amazon EKS Reference Design

AWS Organization

↓

Production AWS Account

↓

Amazon VPC Across Three Availability Zones

├── Public Subnets
│   ├── Internet-Facing Load Balancers
│   └── NAT Gateways
│
├── Private Application Subnets
│   ├── Managed Node Groups
│   ├── Application Pods
│   └── Platform Add-ons
│
└── Restricted Data Subnets
    ├── Databases
    └── Internal Services

↓

Amazon EKS Cluster

├── Private API Endpoint
├── Restricted IAM Access
├── EKS Access Entries
├── Least-Privilege RBAC
├── Pod Security Admission
├── Kyverno or Gatekeeper
├── Default-Deny Network Policies
├── Dedicated Node Groups
├── Encrypted Storage
├── External Secrets
├── Control Plane Logging
├── Runtime Monitoring
└── GitOps

Enterprise Design Decision Matrix

Requirement	Recommended Design
Strong tenant isolation	Separate clusters or accounts
Cost efficiency	Shared cluster with namespaces
Regulated workload	Dedicated account and cluster
High availability	Multi-AZ nodes and replicas
Regional recovery	Secondary-region cluster
Sensitive application	Dedicated node group
Variable demand	Autoscaling and Karpenter
Private administration	Private API endpoint
Strong supply chain	Signed images and admission verification
Central governance	GitOps and policy as code

Common Cluster Design Mistakes

Insufficient Subnet Capacity

Risk: Pods cannot receive IP addresses.

Control:

Plan for growth.
Use larger or additional CIDRs.
Monitor available addresses.

Production and Development in One Cluster

Risk: Development activity affects production.

Control:

Use separate clusters for production and non-production.

One Node Group for Every Workload

Risk: Weak isolation and inefficient scheduling.

Control:

Create purpose-specific node groups.

Public Nodes

Risk: Increased attack surface.

Control:

Run worker nodes in private subnets.

Unrestricted Public API Endpoint

Risk: The control plane is exposed to unnecessary networks.

Control:

Use private access or restrict public endpoint CIDRs.

No Multi-AZ Capacity

Risk: Availability Zone failure causes service disruption.

Control:

Distribute nodes and workloads across zones.

Broad Node IAM Roles

Risk: Compromised Pods access excessive AWS permissions.

Control:

Use pod-level identities.

No Egress Strategy

Risk: Workloads communicate freely with unapproved destinations.

Control:

Use Network Policies, proxies, firewalls and VPC endpoints.

No Upgrade Plan

Risk: Clusters remain on unsupported versions.

Control:

Define and test regular upgrade cycles.

Missing Add-On Ownership

Risk: Critical platform components become outdated or fail.

Control:

Assign owners and lifecycle processes.

Overloaded Shared Cluster

Risk: Resource contention and large blast radius.

Control:

Set quotas or divide workloads across clusters.

Enterprise Implementation Strategy

Phase 1 — Gather Requirements

Identify business services.
Classify data.
Define availability targets.
Identify compliance obligations.
Estimate workload growth.
Define tenancy requirements.
Define recovery requirements.

Phase 2 — Select Account and Region Strategy

Separate production and non-production.
Select approved Regions.
Define multi-region requirements.
Establish central security and logging accounts.

Phase 3 — Design Networking

Create multi-AZ VPC design.
Size subnets for Pod growth.
Plan public and private subnets.
Define API endpoint access.
Design ingress and egress.
Configure VPC endpoints.

Phase 4 — Design Compute

Choose Managed Node Groups, Fargate or self-managed nodes.
Define node group purposes.
Select instance families.
Plan On-Demand and Spot capacity.
Configure autoscaling.
Define node isolation.

Phase 5 — Design Identity and Security

Configure IAM federation.
Plan EKS access entries.
Define RBAC roles.
Use pod-level identities.
Define Pod Security Admission.
Plan admission policies.
Define Network Policies.

Phase 6 — Design Platform Services

Select required add-ons.
Define ingress.
Define storage.
Define DNS.
Define secrets management.
Define observability.
Assign component ownership.

Phase 7 — Automate Deployment

Build Infrastructure as Code.
Establish GitOps.
Add security tests.
Validate configuration.
Create standard cluster templates.

Phase 8 — Validate the Design

Test failure scenarios.
Test Availability Zone loss.
Test node replacement.
Test scaling.
Test access controls.
Test policy enforcement.
Test recovery.

Phase 9 — Operationalise

Enable logging and monitoring.
Establish alerting.
Define upgrade cycles.
Implement vulnerability management.
Track capacity and cost.
Maintain runbooks.

Phase 10 — Review Continuously

Review architecture.
Review cluster growth.
Review IP capacity.
Review node groups.
Review access.
Review compliance.
Review recovery readiness.

Enterprise Best Practices

As a Cloud Security Engineer:

Begin cluster design with business and risk requirements.
Separate production and non-production environments.
Use AWS accounts as security boundaries.
Deploy worker nodes across multiple Availability Zones.
Run worker nodes in private subnets.
Plan Pod IP capacity before production.
Prefer private EKS API access where practical.
Use Managed Node Groups for standard workloads.
Separate system, application and sensitive workloads.
Use pod-level AWS identities rather than broad node roles.
Implement namespace, network and resource isolation.
Apply Pod Security Admission and enterprise admission policies.
Centralise logging, monitoring and compliance data.
Define ownership for every platform add-on.
Use Infrastructure as Code and GitOps.
Design upgrades and recovery before production.
Monitor capacity, cost and configuration drift.
Test high availability and disaster recovery regularly.
Reassess cluster boundaries as workloads and risk change.

Real-World Scenario

A multinational financial organisation plans to migrate a payment-processing platform to Amazon EKS.

The platform must support:

Public customer transactions
Restricted payment data
High availability
PCI-aligned controls
Seasonal traffic growth
Disaster recovery
Multiple development teams

The architecture team evaluates a single shared enterprise cluster but identifies that payment workloads require a smaller security and compliance boundary.

The final design includes:

A dedicated production AWS account for payment services.
A separate non-production account for development and testing.
A production EKS cluster across three Availability Zones.
Worker nodes in private subnets.
Internet-facing Application Load Balancers in public subnets.
A private EKS API endpoint accessible through approved corporate connectivity.
Dedicated system, application and security node groups.
On-Demand capacity for critical workloads and Spot capacity for non-critical batch processing.
EKS Pod Identity for application access to AWS services.
Restricted Pod Security Admission and Kyverno policies.
Default-deny Network Policies with explicit application flows.
Amazon ECR with image scanning, signing and digest-based deployment.
Centralised control plane, application and runtime logs.
Infrastructure as Code and GitOps for deployment.
A secondary-region recovery environment rebuilt from approved templates and backups.
Quarterly recovery and failure testing.

The design reduces blast radius, supports regulatory reporting and allows the platform to scale without weakening security.

Key Takeaways

Amazon EKS cluster design must begin with business, security and availability requirements.
AWS accounts, clusters, namespaces and node groups provide different levels of isolation.
Production and non-production workloads should be separated.
Shared clusters improve efficiency but increase multi-tenancy complexity and blast radius.
Dedicated clusters provide stronger isolation but increase operational cost.
VPC and subnet design directly affect security, availability and Pod scalability.
Worker nodes should generally run in private subnets across multiple Availability Zones.
Pod IP capacity must be planned carefully when using the Amazon VPC CNI.
Private API endpoints reduce control-plane exposure.
Node groups should be designed for workload type, criticality and trust level.
Pod-level AWS identities reduce dependency on broad node IAM roles.
Cluster add-ons require ownership, monitoring and upgrade planning.
Infrastructure as Code and GitOps support consistency and recovery.
Upgrade, observability and disaster-recovery strategies should be designed before production deployment.

Knowledge Check

1. Why should production and non-production workloads usually run in separate clusters or accounts?

Answer: Separation reduces blast radius, prevents development activity from affecting production, simplifies access control and supports clearer compliance boundaries.

2. Why is subnet capacity important in an Amazon EKS design?

Answer: The Amazon VPC CNI assigns VPC IP addresses to Pods, so insufficient subnet capacity can prevent Pods and nodes from scaling.

3. What is the security benefit of a private EKS API endpoint?

Answer: A private endpoint reduces internet exposure and requires administrators and automation systems to access the Kubernetes API through approved private network paths.

4. Why should sensitive workloads use dedicated node groups?

Answer: Dedicated node groups provide stronger workload isolation, separate IAM roles, targeted monitoring and reduced exposure to less-trusted workloads.

5. What is the purpose of combining Infrastructure as Code with GitOps?

Answer: Infrastructure as Code provides repeatable AWS and cluster provisioning, while GitOps maintains Kubernetes configuration and application state through version-controlled, approved and continuously reconciled deployments.

What’s Next?

In the next lesson, we will explore Amazon EKS Networking, including the Amazon VPC CNI, Pod networking, Services, ingress, egress, Security Groups and enterprise network-security patterns.

➡️ Next Lesson: Lesson 03 — Amazon EKS Networking