Deep Dive into Amazon EKS: A Practical Guide to “Serious Kubernetes Operations” Through Comparison with GKE and AKS

Introduction (Key Summary)

• In this article, we’ll focus on Amazon Elastic Kubernetes Service (Amazon EKS) and, while comparing it with Google Kubernetes Engine (GKE) and Azure Kubernetes Service (AKS), carefully organize the mindset needed for “running Kubernetes properly in production.”
• Amazon EKS is a fully managed Kubernetes service provided by AWS, in which AWS manages the Kubernetes control plane and lets users focus on worker nodes and applications.
• GKE and AKS are also managed Kubernetes services, but each has its own flavor:
  • EKS: Strong in AWS-native integration (IAM / VPC / CloudWatch) and hybrid (EKS Anywhere)
  • GKE: The “canonical Kubernetes” built by Kubernetes’ originator, Google, plus almost serverless operations through Autopilot
  • AKS: Kubernetes with deep integration with Azure AD (Entra ID), Azure Monitor, and DevOps—high affinity with enterprise IT
• Key design points are:
  1. Put into words as a team why you are choosing Kubernetes in the first place
  2. Decide your cluster structure up front (how to split environments, teams, and tenants)
  3. Design networking, security, and IAM/RBAC with a “least privilege” mindset
  4. Prepare mechanisms for upgrades, add-ons, and logging/monitoring from day one
  5. Design with a “common mental model” that will still work in a future multi-cloud / hybrid world
• This article is intended for:
  • SREs / platform engineers who are ready to run Kubernetes seriously in production
  • Backend developers / tech leads who want to clarify the differences between ECS and EKS, GKE and AKS
  • IT and governance staff who want a side-by-side view of AWS / GCP / Azure
• By the end, the goal is that you’ll be able to explain in your own words:
  “Given our team’s situation, which of EKS / GKE / AKS is realistic to adopt and in what kind of architecture.”

1. What Is Amazon EKS? The Basics of “Managed Kubernetes” Common to All Three Clouds

1.1 Overview of Amazon EKS

Amazon EKS is a fully managed Kubernetes cluster service operated by AWS. You don’t need to build and operate your own Kubernetes control plane (API server, etcd, etc.); AWS takes care of scaling, redundancy, patching, and more.

In simple terms, its characteristics are:

• A CNCF-certified Kubernetes-conformant managed service
• AWS operates the control plane (high availability, autoscaling, patching)
• For worker nodes, you can choose from multiple execution environments such as:
  • EC2 nodes
  • Fargate (serverless nodes)
  • EKS Anywhere / Hybrid Nodes (on-premises / edge)
• Tight integration with other AWS services like IAM, VPC, and CloudWatch

In other words, it’s a good fit when:
“We want to adopt Kubernetes as an orchestration model, but we’d rather leave control plane operations to AWS.”

1.2 Common Ground with GKE / AKS

GKE and AKS belong to the same category of services.

• GKE (Google Kubernetes Engine)
  • A managed Kubernetes service provided by Google.
  • Deeply integrated with Google Cloud networking; with Autopilot mode, you can operate with almost no awareness of node management.
• AKS (Azure Kubernetes Service)
  • Azure’s managed Kubernetes service.
  • Azure runs the Kubernetes control plane; users focus on nodes and applications. Strong integration with Azure AD (Entra ID), Azure Monitor, and DevOps is a key feature.

All three services share the following:

• You can use the standard Kubernetes API as-is
• The cloud provider operates the control plane for you
• They support node provisioning, autoscaling, and upgrade workflows

2. Architecture Comparison: Aligning the “Skeleton” of EKS / GKE / AKS

2.1 Control Plane and Data Plane

A Kubernetes cluster is broadly divided into:

• Control plane (API server, etcd, scheduler, etc.)
• Data plane (the nodes on which application containers run)

In each service:

• EKS: AWS manages the control plane; nodes are EC2 / Fargate / EKS Anywhere.
• GKE: Google-managed control plane + Compute Engine nodes or Autopilot.
• AKS: Azure-managed control plane + VM Scale Set nodes.

From the user’s perspective, the common point is that the endpoint kubectl talks to (the API server) is managed by the cloud provider.

2.2 Choices for Nodes and Runtimes

Amazon EKS

• Managed Node Groups (EC2)
  • EC2 node groups integrated with Auto Scaling Groups. You can fine-tune instance types, OS, disks, and more.
• Fargate (EKS on Fargate)
  • You specify vCPU and memory per Pod and run them serverlessly. You barely need to think about node management.
• EKS Anywhere / Hybrid Nodes
  • Run Kubernetes clusters on-premises or at the edge while leveraging EKS Distro and integrated management.

GKE

• Standard Mode:
  • Closer to self-managed; nodes are Compute Engine instances you manage.
• Autopilot Mode:
  • A serverless-leaning mode where billing and scaling are per Pod and you can essentially ignore node management.

AKS

• Node pools (VMSS):
  • Nodes are managed as VM Scale Sets. A best practice is to separate system node pools from user node pools.
• Virtual Nodes / Container Instances integration (in some architectures):
  • You can integrate with serverless containers to handle bursts when needed.

3. Differences in Networking, Security, and Identity Integration

When using Kubernetes in production, networking and permissions are often where people fall into the deepest “swamps.” Let’s align how the three clouds handle these areas.

3.1 Networking (CNI / VPC/VNet)

EKS

• By default it uses the Amazon VPC CNI, which assigns VPC IP addresses directly to Pods (behavior can be tuned by mode).
• A classic pattern is to combine it with the ALB Ingress Controller (AWS Load Balancer Controller) and integrate with ALB/NLB.

GKE

• VPC-native clusters (IP aliases) are mainstream, where Pods also receive IPs from the VPC.
• Deeply integrated with Google Cloud Load Balancers, allowing automatic creation of L7/L4 load balancers.

AKS

• You can choose between Azure CNI and kubenet (Azure CNI is now mainstream).
• You combine it with Azure Load Balancer / Application Gateway / Nginx Ingress Controller and similar components.

From a networking standpoint, the key questions are:

• Do Pods directly get IPs from the cloud VPC/VNet?
• How do Service / LoadBalancer types map to external exposure?

If you understand these two points, you can transfer your knowledge across all three clouds.

3.2 Security (RBAC / Network Policy / Pod Security)

All three clouds use:

• Kubernetes RBAC
• Network policies (Calico / Cilium / Azure Policy for Kubernetes, etc.)
• Pod Security (Pod Security Standards and vendor-specific extensions)

In other words, they share a “standard Kubernetes security model.”

The biggest differences show up in how they integrate with cloud-side identity and permissions.

3.3 Integration with Cloud Identities (IRSA / Workload Identity / Managed Identity)

Amazon EKS

• With IAM Roles for Service Accounts (IRSA) you can:
  • Bind IAM roles to Kubernetes ServiceAccounts
  • Grant minimal AWS resource permissions (S3 / DynamoDB / SQS, etc.) per Pod

GKE

• With Workload Identity,
  • You map Kubernetes ServiceAccounts to Google Service Accounts
  • You can finely control access from Pods to Google Cloud APIs

AKS

• By combining Managed Identities + AAD Pod Identity (now moving to Azure AD Workload Identity),
  • You can grant access to Azure resources on a per-Pod basis.

Side-by-side, it looks like this:

• EKS: ServiceAccount → IAM Role
• GKE: ServiceAccount → Google Service Account
• AKS: ServiceAccount → Managed Identity (Entra ID object)

On the Kubernetes side, if you remember:
“Use ServiceAccounts as the unit for splitting permissions between Pods,”
you’ll find it easy to carry this mental model across clouds.

4. Use-Case-Based Strengths of EKS / GKE / AKS

4.1 Microservices Platform

• This is when you want to run many small microservices under common authentication, logging, monitoring, and deployment pipelines.
• In EKS, combining ALB Ingress Controller with App Mesh makes it easy to build a service mesh and zero-trust-leaning frontend platform.
• GKE is strong in multi-cluster / multi-cloud service mesh through managed integration with Istio and Anthos.
• AKS makes it easy to build an enterprise-friendly API platform by connecting Azure Front Door, Azure API Management, and Azure Monitor.

4.2 Data and Machine Learning Platforms

• This is for cases where you want to run batch jobs, Spark, and ML workloads on Kubernetes.
• With EKS, you can build a cloud-native data/ML platform by combining EMR on EKS and the wider ecosystem (e.g., Kubeflow).
• GKE is very popular among GCP-centric data/ML teams because of its affinity with Vertex AI and BigQuery.
• AKS is often chosen by enterprises with on-prem AD and existing Windows environments, integrating with Azure ML and Synapse.

4.3 Hybrid and Edge

• For data sovereignty, low latency, factories and stores, and other real-world locations, you may want to use Kubernetes on-premises or at the edge.
• EKS Anywhere provides an option to run on-prem Kubernetes with EKS Distro and official support.
• GKE excels at managing multi-cluster setups—including on-prem and other clouds—via GKE on-prem / Anthos.
• AKS can take a similar approach using Arc-enabled Kubernetes to manage on-prem and other-cloud clusters from Azure.

5. Practical Design Points: How to Split Clusters, Namespaces, and Resources

5.1 How to Split Clusters

Common patterns include:

• Split clusters by environment
  • eks-prod / eks-stg / eks-dev
• As scale grows, you may also:
  • Split clusters by product or business unit
  • Separate clusters for services with different importance levels or regulatory requirements (PCI, healthcare, etc.)

In GKE you might have gke-prod / gke-stg, and in AKS you combine subscriptions and resource groups in similar ways.

5.2 The Role of Namespaces

• Within a cluster, the basic pattern is to split apps, teams, and tenants by namespace.
  • e.g., team-a-api / team-a-batch / team-b / platform / observability
• Because RBAC and NetworkPolicy can be designed per namespace, it’s easier to operate when you split namespaces per app or per team.

5.3 Controlling Resources (ResourceQuota / LimitRange)

• EKS / GKE / AKS all support:
  • requests / limits per Pod or container
  • ResourceQuotas per namespace
    So you should always implement mechanisms to prevent “CPU/memory contention.”
• If you neglect this, you will run into the classic cluster incident where one misbehaving Pod impacts other services.

6. Concrete Comparison: The “Personality” Differences Between EKS / GKE / AKS

6.1 Control Plane Operation and Scaling

• EKS:
  • The control plane is replicated across multiple AZs in a region, and AWS manages scaling of the API server, etcd, etc.
  • AWS is actively optimizing for very large clusters (tens of thousands of Pods).
• GKE:
  • As the “home base” of Kubernetes, it has a rich track record for large-scale, high-traffic environments.
• AKS:
  • Azure operates the control plane with an SLA for availability, focusing on stable operations for enterprise IT.

6.2 Managed Add-ons and Integrated Services

• EKS
  • Managed add-ons like VPC CNI, CoreDNS, kube-proxy
  • Easy integration with AWS App Mesh, CloudWatch, AWS X-Ray, AppConfig, Systems Manager, etc.
• GKE
  • Strong one-stop operation of GCP services via Cloud Monitoring / Logging, Cloud Load Balancing, Config Connector, etc.
• AKS
  • Good for enterprise-grade integrated operations via Azure Monitor / Log Analytics / Application Insights, Azure Policy for Kubernetes, Key Vault, DevOps, etc.

6.3 Pricing Models (High-Level Thinking)

Concrete numbers change frequently, so always check the official pricing pages, but conceptually you’ll compare:

• Control plane pricing (free / paid / per cluster)
• Node (VM) pricing
• Billing units for Autopilot / Fargate / serverless options (Pod vCPU/memory, etc.)

Then choose based on how your workloads behave (spiky, 24/7, stopped at night, etc.).

7. Example Architecture: A Simple Web API on EKS Fargate

To make it tangible, let’s outline a simple architecture for running a Web API on EKS Fargate.

7.1 High-Level Picture

• VPC
  • Public subnets: ALB
  • Private subnets: for EKS Fargate
• EKS cluster (Fargate profile associated with the app namespace)
• Deployments in the app namespace: Deployment + Service
• ALB Ingress Controller provisions an ALB based on Ingress

7.2 Sample Deployment Manifest (Conceptual)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-api
  namespace: app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-api
  template:
    metadata:
      labels:
        app: sample-api
    spec:
      serviceAccountName: sample-api-sa
      containers:
        - name: app
          image: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/sample-api:1.0.0
          ports:
            - containerPort: 8080
          env:
            - name: APP_ENV
              value: "prod"
          resources:
            requests:
              cpu: "100m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

7.3 Example of Granting Permissions via IRSA

Here is an example of annotating a ServiceAccount with an IAM role:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sample-api-sa
  namespace: app
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/sa-sample-api-role

If you attach only s3:GetObject to this IAM role for reading a config file from S3, then the application will have just the minimum necessary permissions to access S3.

The same concept can be applied to GKE’s Workload Identity and AKS’s Managed Identity.

8. Common Pitfalls and How to Avoid Them

8.1 The “Just Put Everything into One Cluster” Problem

• If you cram multiple products and environments into one cluster,
  • RBAC and NetworkPolicy become overly complex
  • A single cluster outage can impact all services
• Solutions:
  • Always separate clusters by environment (prod / stg / dev)
  • Consider dedicated clusters for high-importance products

8.2 Over-Relying on Kubernetes and Ignoring Cloud-Native Features

• If you try to solve everything in a Kubernetes-native way, you may:
  • Skip IAM integration and hardcode long-lived secrets in Pods
  • Run a database container inside the cluster instead of using a managed DB
    …and end up hurting yourself on operations, reliability, and security.
• Solutions:
  • Push stateful components to managed DBs and cloud services wherever possible
  • Integrate with IRSA / Workload Identity / Managed Identity for auth and permissions

8.3 No Upgrade Strategy

• Kubernetes versions periodically reach EOL. Without planning for at least a minor version upgrade every 6–12 months, you may face upgrade hell later.
• Solutions:
  • Decide a regular schedule (e.g., “We upgrade EKS/GKE/AKS every spring and fall”)
  • Always validate on a test cluster before upgrading production in stages

9. Who Benefits, and How? (By Reader Type)

9.1 For SREs / Platform Engineers

• Understanding EKS / GKE / AKS side by side lets you confidently build comparison tables like:
  • “Given our assumptions, this is how far we can go with EKS, and these are similar setups in GKE/AKS.”
• You can also reason consistently about cluster design, IRSA/Workload Identity, network policies, and observability—making it easier to live in a multi-cloud world.

9.2 For Backend Developers / Tech Leads

• When you can explain “why EKS” and “why not GKE/AKS instead,” you can provide convincing technical rationale to your team and leadership.
• From the early design phase, you’ll think of:
  • Containerization (Docker)
  • Kubernetes manifests
  • CI/CD
    as a set, so the path to production becomes much clearer.

9.3 For IT and Governance Staff

• You’ll be able to compare EKS / GKE / AKS in terms of:
  • Governance units (cluster, project, subscription) at the organizational level
  • How to design audit, logging, and access control
• As a result, you’ll gain language that connects security policies and regulations to the real-world cloud architecture.

10. Three Steps You Can Start Today

1. Write down in one sentence “why Kubernetes” for your organization
   • e.g., “To run microservices across teams,” “We want a platform that can survive multi-cloud,” etc.
2. Pick one existing (or planned) containerized app and sketch how you’d run it on EKS / GKE / AKS
   • Roughly design cluster structure, namespaces, required permissions, and CI/CD flow.
3. Try one of IRSA / Workload Identity / Managed Identity in a small experiment
   • Create a small test environment where exactly one Pod gets minimal permissions. This will give you an intuitive feel for “connecting identity with Kubernetes.”

11. Summary: EKS as a Bridge Between “AWS Native” and “Kubernetes”

Amazon EKS is like a bridge between:

• The open orchestration world of Kubernetes, and
• The AWS-native world of IAM, VPC, CloudWatch, and other AWS services.

Meanwhile, GKE and AKS are each optimized for their respective clouds. None of them is an absolute winner. What really matters is:

• Your team’s skill set
• Affinity with existing systems
• Your future multi-cloud / hybrid strategy

With those factors in mind, the key is to eventually reach a statement like:

“For our organization, this specific pattern of EKS/GKE/AKS is the best fit.”

In other words, to find the answer that fits you best.

I hope this article serves as a map for that “answer search.” Take small, manageable steps, experiment as you go, and gradually grow a Kubernetes platform that feels good to operate for you and your team.

References (Official Docs and Guides)

• What Is Amazon EKS? (Official User Guide)
• Amazon EKS Product Page
• EKS Anywhere Overview
• GKE Overview (Official Docs)
• GKE Networking Overview
• What Is Azure Kubernetes Service (AKS)? (Japanese Official)
• Azure Kubernetes Service (AKS) Product Page (Japanese)

Version limits and pricing models may change over time, so please check the latest official documentation and pricing pages when you actually design and implement your systems.