One Amazon EKS, many edges: How to choose your edge container strategy on AWS

This article explains how to standardize on Amazon EKS across edge locations while choosing appropriate deployment models based on connectivity and infrastructure constraints.

• Separate the container standard (Kubernetes API and workload definition) from the deployment model (where it physically runs)
• Amazon EKS spans four deployment models: EKS Anywhere for air-gapped sites, EKS Hybrid Nodes for connected sites with existing infrastructure, EKS on Outposts for greenfield locations, and EKS in AWS Regions
• Gate deployment decisions on connectivity first: air-gapped or DDIL sites require EKS Anywhere; connected sites can use AWS managed control planes
• For connected sites, match deployment model to existing infrastructure: no infrastructure means Outposts, existing machines mean Hybrid Nodes
• All deployment models run the same Kubernetes distribution and APIs, enabling workload portability without re-platforming
• Migrate existing container fleets by standing up target EKS model, re-pointing CI/CD pipelines, and shifting workloads progressively

Standardizing on one Kubernetes foundation across multiple deployment models eliminates edge fleet fragmentation while fitting each location's unique constraints.