AWS amplía las opciones para logs de S3: CloudWatch Logs y S3 Tables con Iceberg

Introducción

Hasta ahora, los equipos de DevOps que necesitaban analizar los logs de acceso a buckets S3 tenían una sola opción: redirigirlos a otro bucket S3 como archivos de texto plano. Esto generaba problemas prácticos: los logs no eran consultables en tiempo real, requerían procesamiento manual para análisis históricos y complicaban la correlación con métricas de otros servicios AWS.

Con la actualización anunciada por AWS en junio de 2026, los administradores pueden ahora elegir entre tres destinos para los logs de acceso a S3:

1. Buckets S3 tradicionales (sin costo adicional).
2. CloudWatch Logs (con cifrado KMS y capacidades de alarma).
3. S3 Tables en formato Apache Iceberg (consultables con SQL estándar sin costo extra de almacenamiento).

Esta flexibilidad permite optimizar costos, mejorar la seguridad y acelerar la detección de incidentes.

Qué ocurrió

AWS implementó dos nuevos destinos para los logs de acceso a S3, disponibles desde junio de 2026 en todas las regiones excepto AWS China y AWS GovCloud (US). La novedad central es la integración directa con servicios de observabilidad nativos de AWS:

• CloudWatch Logs: Los logs se envían como streams de logs, permitiendo:

– Configuración de alarmas basadas en patrones (ej: 4xx o 5xx en solicitudes).

– Agregación cross-account y cross-Region sin necesidad de replicar buckets manualmente.

– Cifrado automático con KMS (claves propias o administradas por AWS).

• S3 Tables (Apache Iceberg): Los logs se materializan como tablas Iceberg en buckets S3, con las siguientes características:

– Consultables con SQL: Integración nativa con Amazon Athena, Amazon Redshift, Trino, Spark SQL y otros motores compatibles con Iceberg.

– Estructura tabular: Los logs se transforman en columnas (ej: bucket, requester, operation, status_code, bytes_sent) en lugar de archivos de texto plano, facilitando análisis históricos con herramientas como QuickSight o Grafana.

Los logs de acceso a S3 suelen ser voluminosos: un bucket con 10,000 solicitudes por segundo genera alrededor de 1.5 GB/día en logs comprimidos. Antes, analizar estos datos requería herramientas externas (como S3 Batch Operations o Athena) o scripts personalizados para parsear archivos .log. Con esta actualización, los equipos pueden reducir la latencia de análisis de horas a segundos y eliminar pasos intermedios de transformación.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

Un equipo de DevOps en una multinacional con buckets en us-east-1, eu-west-1 y ap-southeast-1 puede ahora configurar una única consulta en Athena que cruce logs de las tres regiones sin replicar datos. La consulta:

SELECT bucket, requester, COUNT(*) as error_count
FROM s3_access_logs
WHERE status_code >= 400 AND date >= current_date - interval '1' day
GROUP BY bucket, requester
ORDER BY error_count DESC
LIMIT 10;

… devuelve resultados en menos de 2 segundos, incluso si los logs superan los 10 TB.

Para equipos de Seguridad

Los logs de acceso a S3 son críticos para detectar:

• Accesos no autorizados (ej: s3:GetObject desde IPs extrañas).
• Exfiltración de datos (grandes volúmenes de s3:GetObject en horarios inusuales).
• Ataques de fuerza bruta (múltiples s3:PutObject con credenciales inválidas).

1. Correlación con CloudWatch Logs Insights:

   filter @message like /403/
   | stats count(*) by bin(5min)
   | sort @count desc
   

Esto detecta picos de errores 403 (accesos denegados) en tiempo real.

1. Análisis forense con Iceberg:

   SELECT *
   FROM s3_access_logs
   WHERE requester = 'arn:aws:iam::123456789012:user/analista-externo'
   AND operation = 's3:GetObject'
   AND date = '2026-06-15';
   

… clave para investigar incidentes sin necesidad de descargar archivos .log.

1. Cumplimiento normativo:

Antes, un atacante con permisos en un bucket podía borrar los logs de acceso antes de exfiltrar datos. Con CloudWatch Logs, los logs son inmutables (a menos que se borre el stream completo, lo que genera un evento en CloudTrail). Esto eleva el CVSS score de un ataque de 7.5 (acceso no autorizado) a 8.2 (acceso + ocultamiento de evidencia).

Detalles técnicos

Requisitos y limitaciones

# Ejemplo con AWS CLI para enviar logs a CloudWatch Logs
aws s3api put-bucket-logging \
  --bucket mi-bucket \
  --bucket-logging-configuration '{
    "LoggingEnabled": {
      "TargetBucket": "mi-bucket-logs",
      "TargetPrefix": "logs/",
      "TargetGrants": [{"Grantee": {"Type": "Group", "URI": "http://acs.amazonaws.com/groups/s3/LogDelivery"}, "Permission": "WRITE"}],
      "DestinationFormat": "CloudWatchLogs",  # Nueva opción
      "CloudWatchLogsConfiguration": {
        "LogGroupName": "/aws/s3/mi-bucket-access",
        "KmsKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcd1234-5678-90ef-ghij-klmnopqrstuv"
      }
    }
  }'

# Configuración en Terraform
resource "aws_s3_bucket_logging" "example" {
  bucket = aws_s3_bucket.example.id
  target_bucket = aws_s3_bucket.logs.id
  target_prefix = "s3-access-logs/"

  target_format = "Iceberg"  # Requiere versión de AWS Provider >= 5.0
  target_iceberg_configuration {
    catalog_id = "awsdatacatalog"  # Usa Glue Data Catalog
    database_name = "s3_access_logs_db"
    table_name = "mi_bucket_access_logs"
  }
}

-- Primer paso: crear la tabla Iceberg en Athena
CREATE EXTERNAL TABLE s3_access_logs (
  bucket_owner STRING,
  bucket STRING,
  requester STRING,
  request_id STRING,
  operation STRING,
  key STRING,
  request_uri STRING,
  http_status STRING,
  error_code STRING,
  bytes_sent BIGINT,
  object_size BIGINT,
  total_time BIGINT,
  turn_around_time BIGINT,
  version_id STRING,
  host_id STRING,
  sigv STRING,
  cipher_suite STRING,
  auth_type STRING,
  endpoint STRING,
  tls_version STRING,
  event_time TIMESTAMP
)
STORED AS ICEBERG
LOCATION 's3://mi-bucket-logs/s3-access-logs/'
TBLPROPERTIES ('table_type'='ICEBERG');

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

1. Evaluar el destino de los logs según el caso de uso

# Ejemplo: cambiar destino de logs de un bucket existente
aws s3api put-bucket-logging \
  --bucket mi-bucket \
  --bucket-logging-configuration '{
    "LoggingEnabled": {
      "TargetBucket": "nuevo-bucket-logs",
      "TargetPrefix": "cloudwatch-logs/",
      "DestinationFormat": "CloudWatchLogs",
      "CloudWatchLogsConfiguration": {
        "LogGroupName": "/aws/s3/mi-bucket-access",
        "KmsKeyId": "alias/aws/s3"
      }
    }
  }'

2. Configurar alarmas en CloudWatch Logs

1. Crear un Metric Filter en el Log Group:

   aws logs put-metric-filter \
     --log-group-name "/aws/s3/mi-bucket-access" \
     --filter-name "HighDownloadVolume" \
     --filter-pattern '{ $.operation = "s3:GetObject" && $.bytes_sent > 100000000 }' \
     --metric-transformations metricName=HighDownloadVolume,metricNamespace=S3Security,metricValue=1
   

1. Crear una alarma:

   aws cloudwatch put-metric-alarm \
     --alarm-name "S3-HighDownloadVolume-Alarm" \
     --metric-name HighDownloadVolume \
     --namespace S3Security \
     --statistic Sum \
     --period 300 \
     --threshold 5 \
     --comparison-operator GreaterThanThreshold \
     --evaluation-periods 1 \
     --alarm-actions arn:aws:sns:us-east-1:123456789012:S3Alerts
   

3. Optimizar consultas en Iceberg

• Particionar por fecha: Usar PARTITIONED BY (date STRING) en la tabla Iceberg para reducir costos de escaneo.
• Comprimir datos: Iceberg soporta formatos como Parquet o ORC (configurable en la tabla).
• Cachear resultados: Usar Athena Query Result Reuse para consultas frecuentes.

CREATE EXTERNAL TABLE s3_access_logs_optimized (
  -- Campos omitidos por brevedad
)
PARTITIONED BY (date STRING)
STORED AS ICEBERG
LOCATION 's3://mi-bucket-logs/s3-access-logs-iceberg/'
TBLPROPERTIES (
  'table_type'='ICEBERG',
  'format'='parquet',
  'write.format.default'='parquet'
);

4. Auditar permisos

Los nuevos destinos requieren permisos adicionales:

• Para CloudWatch Logs:

  {
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:PutLogEvents",
        "logs:DescribeLogStreams"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    }]
  }
  

• Para Iceberg:

  {
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject"],
      "Resource": ["arn:aws:s3:::mi-bucket-logs/*"]
    }]
  }
  

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/DevOpsRole \
  --action-names s3:PutObject logs:PutLogEvents

Conclusión

La capacidad de redirigir logs de S3 a CloudWatch Logs y S3 Tables (Iceberg) es un cambio disruptivo para equipos de DevOps, Seguridad e Infraestructura. Las ventajas clave son:

1. Reducción de costos: Hasta un 50% menos en almacenamiento para análisis históricos, gracias a Iceberg.
2. Observabilidad integral: Alertas en tiempo real y correlación con métricas de otros servicios AWS.
3. Seguridad reforzada: Inmutabilidad de logs en CloudWatch Logs y cifrado KMS obligatorio.
4. Flexibilidad: Tres opciones de destino para adaptarse a distintos casos de uso (costo, retención, complejidad).

• Para equipos de seguridad: Migrar a CloudWatch Logs y configurar alarmas basadas en patrones de acceso sospechoso.
• Para equipos de infraestructura: Evaluar Iceberg para análisis históricos, especialmente en entornos con múltiples regiones o cuentas.
• Para todos: Documentar los permisos necesarios y probar la configuración en un entorno no productivo antes de escalar.

Esta actualización consolida a AWS como líder en observabilidad de almacenamiento, eliminando barreras técnicas que antes requerían soluciones de terceros (como Splunk o Datadog) para el análisis de logs de S3.