Análisis exhaustivo de Amazon EKS: Guía práctica para “operar Kubernetes en serio” comparando con GKE y AKS

Introducción (Resumen clave)

• En este artículo nos centraremos en Amazon Elastic Kubernetes Service (Amazon EKS) y, comparándolo con Google Kubernetes Engine (GKE) y Azure Kubernetes Service (AKS), ordenaremos con calma la mentalidad necesaria para “usar Kubernetes de verdad en producción”.
• Amazon EKS es un servicio de Kubernetes totalmente gestionado ofrecido por AWS, donde AWS se encarga del plano de control de Kubernetes y tú te ocupas de los nodos de trabajo y las aplicaciones.
• GKE y AKS también son servicios de Kubernetes gestionados, pero cada uno tiene su propio “sabor”:
  • EKS: Fuerte en integración nativa con AWS (IAM / VPC / CloudWatch) e híbrido (EKS Anywhere)
  • GKE: El “Kubernetes canónico” creado por el propio Google, con operaciones casi serverless gracias a Autopilot
  • AKS: Kubernetes muy integrado con Azure AD (Entra ID), Azure Monitor y DevOps—alta afinidad con el TI empresarial
• Los puntos clave de diseño son:
  1. Dejar por escrito, como equipo, por qué estáis eligiendo Kubernetes en primer lugar
  2. Decidir de antemano la estructura de clusters (cómo separar entornos, equipos y “tenants”)
  3. Diseñar red, seguridad e IAM/RBAC con mentalidad de “mínimo privilegio”
  4. Preparar desde el día uno mecanismos para actualizaciones, add-ons y logging/monitorización
  5. Diseñar con un “modelo mental común” que siga sirviendo en un futuro mundo multi-cloud / híbrido
• Este artículo está pensado para:
  • SREs / ingenieros de plataforma que quieren operar Kubernetes seriamente en producción
  • Desarrolladores backend / tech leads que quieren aclarar las diferencias entre ECS y EKS, GKE y AKS
  • Personal de TI y gobierno que quiere ver AWS / GCP / Azure en paralelo
• Al final, el objetivo es que puedas explicar con tus propias palabras:
  “Dada la situación de nuestro equipo, cuál de EKS / GKE / AKS es realista adoptar y con qué tipo de arquitectura.”

1. ¿Qué es Amazon EKS? Fundamentos del “Kubernetes gestionado” común a las tres nubes

1.1 Visión general de Amazon EKS

Amazon EKS es un servicio de clústeres Kubernetes totalmente gestionado operado por AWS. No necesitas construir ni operar tu propio plano de control de Kubernetes (API server, etcd, etc.); AWS se encarga del escalado, redundancia, parches y mucho más.

En términos sencillos, sus características son:

• Es un Kubernetes conforme al estándar CNCF y certificado
• AWS opera el plano de control (alta disponibilidad, autoescalado, parches)
• Para los nodos de trabajo puedes elegir entre varios entornos de ejecución, como:
  • Nodos EC2
  • Fargate (nodos serverless)
  • EKS Anywhere / nodos híbridos (on-premises / edge)
• Integración estrecha con otros servicios de AWS como IAM, VPC y CloudWatch

En otras palabras, encaja bien cuando:
“Queremos adoptar Kubernetes como modelo de orquestación, pero preferimos delegar la operación del plano de control en AWS.”

1.2 Terreno común con GKE / AKS

GKE y AKS pertenecen a la misma categoría de servicios.

• GKE (Google Kubernetes Engine)
  • Servicio de Kubernetes gestionado por Google.
  • Integración profunda con la red de Google Cloud; con el modo Autopilot puedes operar prácticamente sin gestionar nodos.
• AKS (Azure Kubernetes Service)
  • Servicio de Kubernetes gestionado por Azure.
  • Azure opera el plano de control de Kubernetes; el usuario se centra en nodos y aplicaciones. Su integración con Azure AD (Entra ID), Azure Monitor y DevOps es un punto fuerte.

Los tres servicios comparten:

• Puedes usar la API estándar de Kubernetes tal cual
• El proveedor cloud opera el plano de control por ti
• Todos soportan aprovisionamiento de nodos, autoescalado y flujos de actualización

2. Comparación de arquitectura: alineando el “esqueleto” de EKS / GKE / AKS

2.1 Plano de control y plano de datos

Un clúster de Kubernetes se divide a grandes rasgos en:

• Plano de control (API server, etcd, scheduler, etc.)
• Plano de datos (los nodos donde corren los contenedores de las aplicaciones)

En cada servicio:

• EKS: AWS gestiona el plano de control; los nodos son EC2 / Fargate / EKS Anywhere.
• GKE: plano de control gestionado por Google + nodos Compute Engine o Autopilot.
• AKS: plano de control gestionado por Azure + nodos en VM Scale Sets.

Desde el punto de vista del usuario, el punto común es que el endpoint con el que habla kubectl (el API server) lo gestiona el proveedor cloud.

2.2 Opciones de nodos y runtimes

Amazon EKS

• Managed Node Groups (EC2)
  • Grupos de nodos EC2 integrados con Auto Scaling Groups. Puedes afinar tipos de instancia, SO, discos, etc.
• Fargate (EKS on Fargate)
  • Especificas vCPU y memoria por Pod y lo ejecutas de forma serverless. Apenas necesitas pensar en gestión de nodos.
• EKS Anywhere / nodos híbridos
  • Ejecutas clústeres Kubernetes on-premises o en el edge aprovechando EKS Distro y gestión integrada.

GKE

• Modo estándar:
  • Más cercano a “self-managed”; los nodos son instancias de Compute Engine que gestionas tú.
• Modo Autopilot:
  • Modo más serverless, donde la facturación y el escalado son por Pod y básicamente puedes ignorar la gestión de nodos.

AKS

• Node pools (VMSS):
  • Los nodos se gestionan como VM Scale Sets. Un patrón recomendado es separar node pools de sistema y de usuario.
• Virtual Nodes / integración con Container Instances (en algunas arquitecturas):
  • Permite integrar contenedores serverless para absorber picos puntuales.

3. Diferencias en red, seguridad e integración de identidad

Al usar Kubernetes en producción, la red y los permisos suelen ser donde más “pantanos” hay. Veamos cómo afronta cada nube estos temas.

3.1 Red (CNI / VPC/VNet)

EKS

• Por defecto usa Amazon VPC CNI, que asigna direcciones IP de la VPC directamente a los Pods (esto se puede ajustar por modo).
• Es clásico combinarlo con el ALB Ingress Controller (AWS Load Balancer Controller) e integrarlo con ALB/NLB.

GKE

• Los clústeres VPC-native (IP aliases) son la norma, donde los Pods también reciben IPs de la VPC.
• Integración profunda con Google Cloud Load Balancers, permitiendo crear automáticamente balanceadores L7/L4.

AKS

• Puedes elegir entre Azure CNI y kubenet (Azure CNI es ahora lo habitual).
• Se combina con Azure Load Balancer / Application Gateway / Nginx Ingress Controller y similares.

Desde el punto de vista de la red, las preguntas clave son:

• ¿Los Pods reciben IPs directamente de la VPC/VNet del cloud?
• ¿Cómo se mapean los Services / LoadBalancer al exterior?

Si entiendes estos dos puntos, podrás trasladar tus conocimientos entre nubes sin demasiadas sorpresas.

3.2 Seguridad (RBAC / Network Policy / Pod Security)

Los tres ofrecen:

• RBAC de Kubernetes
• Network policies (Calico / Cilium / Azure Policy for Kubernetes, etc.)
• Pod Security (Pod Security Standards y extensiones específicas del proveedor)

Es decir, comparten un “modelo estándar de seguridad de Kubernetes”.

Las mayores diferencias aparecen en cómo integran identidades y permisos del lado del cloud.

3.3 Integración con identidades del cloud (IRSA / Workload Identity / Managed Identity)

Amazon EKS

• Con IAM Roles for Service Accounts (IRSA) puedes:
  • Asociar roles de IAM a ServiceAccounts de Kubernetes
  • Otorgar permisos mínimos a recursos de AWS (S3 / DynamoDB / SQS, etc.) por Pod

GKE

• Con Workload Identity:
  • Mapeas ServiceAccounts de Kubernetes a ServiceAccounts de Google
  • Controlas con granularidad el acceso desde Pods a APIs de Google Cloud

AKS

• Combinando Managed Identities + AAD Pod Identity (en transición hacia Azure AD Workload Identity):
  • Puedes otorgar acceso a recursos de Azure por Pod.

En paralelo, se ve así:

• EKS: ServiceAccount → rol de IAM
• GKE: ServiceAccount → Google Service Account
• AKS: ServiceAccount → Managed Identity (objeto de Entra ID)

En el lado Kubernetes, si recuerdas esto:
“Divide permisos entre Pods usando ServiceAccounts como unidad,”
te será muy fácil aplicar el mismo modelo mental en cualquier nube.

4. Fortalezas por casos de uso: EKS / GKE / AKS

4.1 Plataforma de microservicios

• Cuando quieres ejecutar muchos microservicios pequeños bajo un marco común de autenticación, logging, monitorización y pipelines de despliegue.
• En EKS, combinando ALB Ingress Controller con App Mesh resulta sencillo construir una plataforma de servicios con service mesh y orientación a zero-trust en el frontend.
• GKE es fuerte en service mesh multi-clúster / multi-cloud gracias a la integración gestionada con Istio y Anthos.
• AKS facilita construir una plataforma de APIs “enterprise-friendly” conectando Azure Front Door, Azure API Management y Azure Monitor.

4.2 Plataformas de datos y machine learning

• Casos donde quieres ejecutar jobs batch, Spark y cargas de ML sobre Kubernetes.
• Con EKS, puedes crear una plataforma data/ML cloud-native combinando EMR on EKS y el ecosistema (p.ej. Kubeflow).
• GKE es muy popular entre equipos de datos/ML centrados en GCP por su afinidad con Vertex AI y BigQuery.
• AKS es habitual en empresas con AD on-prem y entornos Windows ya existentes, integrando con Azure ML y Synapse.

4.3 Híbrido y edge

• Por temas de soberanía de datos, baja latencia, fábricas y tiendas, puede interesar correr Kubernetes on-premises o en el edge.
• EKS Anywhere ofrece una opción para ejecutar Kubernetes on-prem con EKS Distro y soporte oficial.
• GKE es muy potente para gestionar infra multi-clúster (incluyendo on-prem y otras nubes) mediante GKE on-prem / Anthos.
• AKS puede seguir un enfoque similar usando Arc-enabled Kubernetes para gestionar clústeres on-prem y de otras nubes desde Azure.

5. Puntos prácticos de diseño: cómo separar clústeres, namespaces y recursos

5.1 Cómo separar clústeres

Patrones comunes:

• Separar clústeres por entorno
  • eks-prod / eks-stg / eks-dev
• Cuando la escala crece, también puedes:
  • Separar clústeres por producto o unidad de negocio
  • Tener clústeres exclusivos para servicios con diferente importancia o requisitos regulatorios (PCI, sanitario, etc.)

En GKE podrías tener gke-prod / gke-stg, y en AKS combinar suscripciones y resource groups de forma parecida.

5.2 Papel de los namespaces

• Dentro de un clúster, el patrón básico es separar apps, equipos y “tenants” por namespace.
  • Ej.: team-a-api / team-a-batch / team-b / platform / observability
• Como puedes diseñar RBAC y NetworkPolicy por namespace, la operación se simplifica si separas al menos por app o por equipo.

5.3 Control de recursos (ResourceQuota / LimitRange)

• EKS / GKE / AKS admiten:
  • requests / limits por Pod o contenedor
  • ResourceQuotas por namespace
    De modo que deberías siempre configurar mecanismos que eviten “pelea” de CPU/memoria.
• Si lo descuidas, acabarás en el clásico incidente donde un Pod “desbocado” afecta a otros servicios.

6. Comparación concreta: las “personalidades” de EKS / GKE / AKS

6.1 Operación y escalado del plano de control

• EKS:
  • El plano de control está replicado en varias AZs de una región y AWS gestiona el escalado del API server, etcd, etc.
  • AWS está optimizando activamente para clústeres muy grandes (decenas de miles de Pods).
• GKE:
  • Como “casa” de Kubernetes, tiene un historial rico en entornos de gran escala y alto tráfico.
• AKS:
  • Azure opera el plano de control con un SLA de disponibilidad, orientado a operaciones estables para TI empresarial.

6.2 Add-ons gestionados y servicios integrados

• EKS
  • Add-ons gestionados como VPC CNI, CoreDNS, kube-proxy
  • Integración sencilla con AWS App Mesh, CloudWatch, AWS X-Ray, AppConfig, Systems Manager, etc.
• GKE
  • Muy fuerte en operación integrada “one-stop” de servicios GCP mediante Cloud Monitoring / Logging, Cloud Load Balancing, Config Connector, etc.
• AKS
  • Adecuado para operaciones integradas de nivel empresarial con Azure Monitor / Log Analytics / Application Insights, Azure Policy for Kubernetes, Key Vault, DevOps, etc.

6.3 Modelos de precios (visión de alto nivel)

Las cifras concretas cambian a menudo, así que consulta siempre las páginas oficiales de precios, pero conceptualmente compararás:

• Coste del plano de control (gratis / de pago / por clúster)
• Coste de los nodos (VMs)
• Unidades de facturación en opciones Autopilot / Fargate / serverless (vCPU/memoria por Pod, etc.)

Y a partir de ahí eliges según el comportamiento de tus cargas de trabajo (picos, 24/7, se apagan de noche, etc.).

7. Ejemplo de arquitectura: una API web sencilla en EKS Fargate

Para aterrizar ideas, veamos una arquitectura simple para ejecutar una API web en EKS Fargate.

7.1 Vista general

• VPC
  • Subredes públicas: ALB
  • Subredes privadas: para EKS Fargate
• Clúster EKS (perfil de Fargate asociado al namespace app)
• Deployments en el namespace app: Deployment + Service
• ALB Ingress Controller aprovisiona un ALB basándose en un Ingress

7.2 Manifiesto de Deployment (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 Ejemplo de asignación de permisos con IRSA

Ejemplo de anotación de un ServiceAccount con un rol de IAM:

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

Si a este rol de IAM le adjuntas solo s3:GetObject para leer un archivo de configuración en S3, la aplicación tendrá exactamente los permisos mínimos necesarios para acceder a S3.

El mismo concepto puede aplicarse a Workload Identity en GKE y a Managed Identity en AKS.

8. Errores habituales y cómo evitarlos

8.1 El problema de “meterlo todo en un solo clúster”

• Si metes varios productos y entornos en un único clúster:
  • RBAC y NetworkPolicy se vuelven excesivamente complejos
  • Una caída de ese clúster puede impactar todos los servicios
• Soluciones:
  • Separa siempre clústeres por entorno (prod / stg / dev)
  • Considera clústeres dedicados para productos críticos

8.2 Depender demasiado de Kubernetes e ignorar los servicios nativos del cloud

• Si intentas resolver todo “a lo Kubernetes”, puedes acabar:
  • Ignorando la integración con IAM y metiendo secretos de larga duración en los Pods
  • Ejecutando la base de datos como contenedor dentro del clúster en vez de usar un servicio gestionado
    …y eso se traduce en dolor operativo, fiabilidad baja y más superficie de riesgo.
• Soluciones:
  • Empuja los componentes con estado a BDs gestionadas y servicios del cloud siempre que sea posible
  • Integra IRSA / Workload Identity / Managed Identity para auth y permisos

8.3 No tener estrategia de actualización

• Las versiones de Kubernetes llegan periódicamente a EOL. Sin plan para hacer al menos una actualización de versión menor cada 6–12 meses, acabarás en el infierno de upgrades.
• Soluciones:
  • Define un calendario regular (p. ej., “actualizamos EKS/GKE/AKS cada primavera y otoño”)
  • Valida siempre en un clúster de pruebas antes de actualizar producción por fases

9. ¿Quién sale ganando y cómo? (por tipo de lector)

9.1 Para SREs / ingenieros de plataforma

• Entender EKS / GKE / AKS en paralelo te permite elaborar tablas comparativas del tipo:
  • “Con estas suposiciones, hasta aquí llegamos con EKS, y estos son montajes equivalentes en GKE/AKS.”
• También puedes razonar de forma consistente sobre diseño de clústeres, IRSA/Workload Identity, políticas de red y observabilidad, lo que facilita vivir en un mundo multi-cloud.

9.2 Para desarrolladores backend / tech leads

• Cuando puedes explicar “por qué EKS” y “por qué no GKE/AKS en su lugar”, proporcionas argumentos técnicos sólidos para tu equipo y la dirección.
• Desde fases tempranas de diseño empiezas a pensar en:
  • Contenerización (Docker)
  • Manifiestos de Kubernetes
  • CI/CD
    como un conjunto, y el camino a producción se vuelve más claro.

9.3 Para personal de TI y gobierno

• Podrás comparar EKS / GKE / AKS en términos de:
  • Unidades de gobierno (clúster, proyecto, suscripción) a nivel organizativo
  • Cómo diseñar auditoría, logging y control de acceso
• Así ganas un lenguaje que conecta políticas de seguridad y regulación con arquitecturas cloud concretas.

10. Tres pasos que puedes empezar hoy mismo

1. Escribe en una frase “por qué Kubernetes” para tu organización
   • Ej.: “Para ejecutar microservicios entre equipos”, “Queremos una plataforma que pueda sobrevivir en multi-cloud”, etc.
2. Elige una aplicación en contenedor (existente o planeada) y bosqueja cómo la ejecutarías en EKS / GKE / AKS
   • Diseña por encima estructura de clúster, namespaces, permisos necesarios y flujo de CI/CD.
3. Prueba IRSA / Workload Identity / Managed Identity en un experimento pequeño
   • Crea un entorno de prueba donde un único Pod reciba permisos mínimos. Ganarás una sensación muy clara de cómo “conectar identidad y Kubernetes”.

11. Resumen: EKS como puente entre lo “AWS nativo” y “Kubernetes”

Amazon EKS es como un puente entre:

• El mundo abierto de orquestación de Kubernetes, y
• El mundo nativo de AWS de IAM, VPC, CloudWatch y otros servicios.

Al mismo tiempo, GKE y AKS están optimizados para sus respectivas nubes. No hay un ganador absoluto. Lo que realmente importa es:

• La combinación de habilidades de tu equipo
• La afinidad con sistemas existentes
• Vuestra estrategia futura de multi-cloud / híbrido

Con esos factores en mente, lo importante es llegar a una frase tipo:

“Para nuestra organización, este patrón concreto de EKS/GKE/AKS es el que mejor encaja.”

Es decir, encontrar la respuesta que mejor os encaje.

Ojalá este artículo te sirva como mapa para esa “búsqueda de respuesta”. Ve dando pasos pequeños, experimenta sobre la marcha y ve creciendo poco a poco una plataforma Kubernetes que resulte cómoda de operar para ti y tu equipo.

Referencias (documentación oficial y guías)

• ¿Qué es Amazon EKS? (Guía oficial)
• Página de producto de Amazon EKS
• EKS Anywhere – Descripción general
• Descripción general de GKE (documentación oficial)
• Descripción general de redes en GKE
• ¿Qué es Azure Kubernetes Service (AKS)? (oficial en japonés)
• Página de producto de Azure Kubernetes Service (AKS) (japonés)

Los límites de versión y los modelos de precios pueden cambiar con el tiempo; cuando vayas a diseñar e implementar de verdad, comprueba siempre la documentación y las páginas de precios oficiales más recientes.