Amazon EKS Capabilities ahora envía logs a CloudWatch: cómo configurar y qué ganar

Introducción

Hasta ahora, los equipos de DevOps que operan clusters EKS con Capabilities (Argo CD, AWS Controllers for Kubernetes, o kro) dependían de soluciones artesanales para colectar logs de los controladores gestionados por AWS. La falta de integración nativa con servicios de logging como CloudWatch obligaba a usar sidecars, forwarders personalizados o soluciones de terceros, generando overhead operativo y puntos de falla adicionales.

Con el lanzamiento de Amazon EKS Capabilities ahora soporta Amazon CloudWatch Vended Logs, los logs de estos controladores se pueden enviar directamente a CloudWatch Logs, S3 o Kinesis Firehose con un par de clicks en la consola o mediante APIs. Esto reduce la complejidad en entornos donde ya se usa CloudWatch para métricas y alertas, y evita depender de soluciones externas para la trazabilidad de eventos críticos como fallos en reconciliación de recursos o configuraciones de Argo CD.

Qué ocurrió

El 17 de junio de 2026, AWS anunció que los controladores de EKS Capabilities pueden actuar como fuentes de entrega de logs para CloudWatch Vended Logs. Esto significa que los logs generados por los controladores de Argo CD, ACK y kro —que se ejecutan en infraestructura gestionada por AWS— pueden ser redirigidos a destinos como CloudWatch Logs, S3 o Kinesis Firehose sin necesidad de agentes externos ni configuraciones complejas.

La integración aprovecha la infraestructura de logging de CloudWatch Vended Logs, que ya es usada por otros servicios de AWS como Lambda o ECS para enviar logs de forma segura y escalable. Según el anuncio oficial, los logs se entregan con retención nativa en CloudWatch Logs, lo que simplifica la depuración de problemas en clusters EKS sin añadir capas adicionales de configuración.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

El impacto principal es la reducción de complejidad operativa en entornos con múltiples clusters EKS que utilicen Capabilities. Antes, los equipos debían implementar soluciones como Fluent Bit en sidecars o usar herramientas externas para colectar logs de los controladores gestionados por AWS. Con esta integración, los logs de Argo CD, ACK y kro se pueden centralizar directamente en CloudWatch Logs, lo que facilita:

• Correlación de eventos: Los logs de los controladores ahora aparecen junto a los logs de las aplicaciones en CloudWatch, permitiendo una vista unificada de problemas.
• Alertas basadas en patrones: Se pueden crear métricas y alarmas en CloudWatch para detectar fallos en reconciliación de recursos o configuraciones erróneas en tiempo real.
• Retención simplificada: CloudWatch Logs aplica políticas de retención nativas, evitando la gestión manual de logs en S3 con lifecycle policies complejas.

Para equipos de Infraestructura y Cloud

Desde la perspectiva de infraestructura, esta integración elimina la necesidad de desplegar forwarders personalizados para colectar logs de controladores EKS Capabilities. Los equipos pueden ahora:

• Reducir el footprint de logging: Al evitar soluciones externas, se disminuye la carga de red y cómputo en los nodos del cluster.
• Unificar herramientas: Los equipos que ya usan CloudWatch para métricas y tracing pueden extender su uso a logs, reduciendo la cantidad de herramientas en el stack.
• Escalar de forma nativa: CloudWatch Vended Logs está diseñado para manejar volúmenes altos de logs, lo que es crítico en clusters con cientos de namespaces o recursos.

Para equipos de Seguridad

Para los equipos de seguridad, la integración aporta dos beneficios clave:

1. Centralización de logs críticos: Los logs de los controladores de EKS Capabilities incluyen eventos de seguridad como cambios en políticas de IAM (en el caso de ACK) o modificaciones en configuraciones de Argo CD. Estos logs ahora pueden ser auditados en CloudWatch Logs, facilitando la respuesta a incidentes.
2. Cumplimiento simplificado: Al usar CloudWatch Logs, los logs pueden ser exportados a S3 para retención a largo plazo o enviados a herramientas de SIEM mediante Kinesis Firehose, cumpliendo con requisitos de auditoría como PCI DSS o HIPAA.

• Según el anuncio de AWS, la integración está disponible en todas las regiones donde EKS Capabilities está soportado.
• El costo sigue el modelo de CloudWatch Vended Logs, que varía según el destino (Logs, S3 o Firehose). Por ejemplo, en us-east-1, el costo de CloudWatch Logs es de $0.50 por GB para los primeros 10 TB/mes (precios de junio 2026).
• No hay cargos adicionales por EKS Capabilities al habilitar esta funcionalidad.

Detalles técnicos

Componentes involucrados

1. Habilitación del logging:

– AWS Console: En la consola de EKS, sección «Capabilities», opción «Logging».

– API de CloudWatch: Usando el endpoint PutLogEvents con el logGroupName configurado para EKS Capabilities.

– Terraform / AWS CDK: Mediante recursos como aws_cloudwatch_log_group y políticas IAM asociadas.

1. Destinos soportados:

– CloudWatch Logs: Para análisis en tiempo real con métricas y alarmas.

– S3: Para retención a largo plazo o análisis con herramientas como Athena.

– Kinesis Firehose: Para envío a herramientas de SIEM como Splunk o Datadog.

1. Formato de logs:

   {
     "timestamp": 1718659200000,
     "logLevel": "ERROR",
     "message": "Failed to reconcile resource: argo-cd/argocd-server",
     "source": "argocd-controller",
     "namespace": "argocd"
   }
   

1. Seguridad y permisos:

   policies:
     - arn:aws:iam::aws:policy/CloudWatchLogsFullAccess
   

Además, los logs se cifran en tránsito (TLS 1.2+) y en reposo (KMS).

Limitaciones y consideraciones

• Retención en CloudWatch Logs: Por defecto, los logs se retienen por 30 días. Para retención extendida, deben configurarse políticas de lifecycle en el log group.
• Costo: El costo de CloudWatch Logs puede escalar rápidamente en clusters con alto volumen de logs. Se recomienda evaluar el uso de S3 o Firehose para logs de bajo acceso.
• Compatibilidad: La integración solo está disponible para clusters EKS con EKS Capabilities habilitado. Clusters con Capabilities deshabilitado no recibirán logs automáticamente.

Qué deberían hacer los administradores y equipos técnicos

Paso 1: Verificar la versión de EKS y Capabilities

Antes de habilitar el logging, asegúrense de que el cluster cumpla con los requisitos mínimos:

# Verificar versión de EKS
aws eks describe-cluster --name <cluster-name> --query 'cluster.version' --output text

# Verificar si EKS Capabilities está habilitado
aws eks describe-addon --cluster-name <cluster-name> --addon-name argo-cd --query 'addon.status' --output text

Si el cluster no tiene EKS Capabilities habilitado, deben instalarlo primero:

aws eks create-addon --cluster-name <cluster-name> --addon-name argo-cd --addon-version v2.10.0-eksbuild.1

Paso 2: Crear un log group en CloudWatch

Si no tienen uno configurado para EKS Capabilities, créenlo:

aws logs create-log-group --log-group-name /aws/eks/<cluster-name>/capabilities

Paso 3: Habilitar logging para EKS Capabilities

1. Abran la consola de EKS y seleccionen el cluster.
2. Vayan a la pestaña «Capabilities».
3. En «Logging», seleccionen «Enable logging».
4. Elijan el destino (CloudWatch Logs, S3 o Firehose) y configuren los parámetros.

aws eks put-addon-configuration \
  --cluster-name <cluster-name> \
  --addon-name argo-cd \
  --configuration-values '{"logConfiguration": {"cloudWatchLogs": {"enabled": true, "logGroupName": "/aws/eks/<cluster-name>/capabilities"}}}'

resource "aws_eks_addon" "argocd_logging" {
  cluster_name             = aws_eks_cluster.main.name
  addon_name             = "argo-cd"
  addon_version          = "v2.10.0-eksbuild.1"
  configuration_values   = jsonencode({
    logConfiguration = {
      cloudWatchLogs = {
        enabled       = true
        logGroupName = "/aws/eks/${aws_eks_cluster.main.name}/capabilities"
      }
    }
  })
}

Paso 4: Configurar permisos IAM

Asegúrense de que el rol IAM del cluster tenga permisos para escribir en CloudWatch Logs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:log-group:/aws/eks/*:log-stream:*"
    }
  ]
}

Paso 5: Validar la entrega de logs

Verifiquen que los logs están llegando a CloudWatch Logs:

# Listar log streams en el log group
aws logs describe-log-streams --log-group-name /aws/eks/<cluster-name>/capabilities

# Verificar logs recientes
aws logs get-log-events \
  --log-group-name /aws/eks/<cluster-name>/capabilities \
  --log-stream-name <log-stream-name> \
  --query 'events[0:5].message' \
  --output text

Paso 6: Configurar alertas y métricas (opcional)

Creen alarmas para logs críticos, por ejemplo, errores en Argo CD:

aws cloudwatch put-metric-alarm \
  --alarm-name "ArgoCD-Reconciliation-Failures" \
  --metric-name "ErrorLogs" \
  --namespace "AWS/Logs" \
  --statistic "Sum" \
  --period 300 \
  --threshold 10 \
  --comparison-operator "GreaterThanThreshold" \
  --evaluation-periods 1 \
  --alarm-actions "arn:aws:sns:us-east-1:123456789012:ops-alerts"

Paso 7: Evaluar destinos alternativos

Si el volumen de logs es alto, consideren enviar los logs a S3 o Kinesis Firehose para reducir costos:

# Configurar Firehose para enviar logs a Splunk
aws firehose create-delivery-stream \
  --delivery-stream-name "eks-capabilities-logs" \
  --extended-s3-destination-configuration '{
    "RoleARN": "arn:aws:iam::123456789012:role/firehose-delivery-role",
    "BucketARN": "arn:aws:s3:::eks-capabilities-logs",
    "Prefix": "eks-capabilities/",
    "CompressionFormat": "GZIP"
  }'

Conclusión

La integración de Amazon EKS Capabilities con CloudWatch Vended Logs es un avance significativo para equipos que operan clusters EKS con controladores gestionados como Argo CD, ACK o kro. Al centralizar los logs en CloudWatch, los equipos de DevOps, SRE e infraestructura ganan visibilidad unificada, reducción de complejidad operativa y costos predecibles gracias a la escalabilidad nativa de CloudWatch.

Sin embargo, esta funcionalidad no es mágica: requiere planificación para evitar sorpresas en la factura de CloudWatch, especialmente en clusters con alto volumen de logs. Teams con entornos multi-cluster deben evaluar el uso de S3 o Firehose para retención a largo plazo, mientras que equipos con clusters pequeños pueden beneficiarse directamente de CloudWatch Logs para análisis en tiempo real.

Si aún no han migrado sus logs de EKS Capabilities a CloudWatch, ahora es el momento de probar esta integración y validar su impacto en sus flujos de trabajo de debugging y monitoreo.