Amazon SAA-C03: Gestión, operaciones, observabilidad y costos — Guía de estudio

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Forma parte de la AWS SAA-C03 — Guía de estudio completa. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

CloudWatch: Métricas, Espacios de Nombres, Paneles y Alarmas

CloudWatch es el plano de telemetría por defecto para los servicios de AWS, pero su utilidad depende completamente de saber en qué espacio de nombres publica un servicio. Un espacio de nombres es un contenedor para métricas que evita colisiones entre servicios: AWS/Lambda contiene Invocations, Errors y Throttles para funciones, mientras que AWS/Events contiene Invocations, FailedInvocations, TriggeredRules y MatchedEvents para reglas de EventBridge. Esta distinción es importante al diagnosticar pipelines controlados por eventos. Si una regla de EventBridge invoca una API de terceros a través de un destino de API y no llega tráfico al siguiente paso, la respuesta no está en AWS/Lambda; está en AWS/Events. Comprobar TriggeredRules te dice si el patrón de la regla realmente coincidió, y Invocations/FailedInvocations te dicen si el destino en sí fue llamado y si la llamada tuvo éxito. Buscar en las métricas de Lambda porque Lambda es el servicio más familiar pasa por alto el hecho de que la regla puede que nunca haya coincidido con un evento entrante.

La resolución de métricas es una configuración por recurso con implicaciones de coste. La monitorización básica emite métricas cada cinco minutos sin cargo adicional, lo cual es suficiente para cargas de trabajo en estado estable de larga duración, pero demasiado poco granular para reacciones de autoescalado, detección de picos o cálculos de SLO que requieren una resolución por minuto. La monitorización detallada reduce eso a un minuto (y a un segundo para métricas personalizadas de alta resolución), que es lo que se habilita cuando los grupos de escalado necesitan reaccionar rápidamente. Es una funcionalidad de pago, razón por la cual no está activada por defecto.

Cada servicio emite un conjunto de métricas por defecto de forma nativa, pero el hipervisor no puede ver dentro del sistema operativo invitado. CPUUtilization, NetworkIn y DiskReadOps son visibles para EC2 sin esfuerzo; los porcentajes de utilización de memoria y de uso del sistema de archivos requieren el agente de CloudWatch, que es la única forma de obtenerlos. Las métricas de aplicación personalizadas también llegan a través del agente o mediante PutMetricData.

Las alarmas deben distinguir la señal del ruido. Una única alarma sobre CPU > 50% se dispara constantemente durante picos normales y acostumbra a los operadores a ignorarla. Las alarmas compuestas combinan los estados de alarmas hijas con una expresión de regla booleana para que los operadores solo sean alertados cuando se cumpla una condición genuinamente procesable. Para una carga de trabajo donde los picos transitorios de CPU son benignos pero una presión de CPU sostenida combinada con IOPS de lectura de disco elevados indica un problema real:

HighCPUAlarm:
  MetricName: CPUUtilization
  Threshold: 50
  EvaluationPeriods: 3
  Period: 60
  ComparisonOperator: GreaterThanThreshold

HighDiskReadAlarm:
  MetricName: DiskReadOps
  Threshold: 1000
  EvaluationPeriods: 3
  Period: 60

CompositeAlarm:
  AlarmRule: >
    ALARM("HighCPUAlarm") AND ALARM("HighDiskReadAlarm")
  AlarmActions:
    - arn:aws:sns:us-east-1:111122223333:ops-pager

Las alarmas hijas aún pueden pasar al estado ALARM internamente, pero solo la compuesta activa SNS. Dos alarmas independientes que alertan al personal de guardia recrean el problema del ruido; una única alarma con un umbral más alto no capta la correlación.

Los paneles agregan widgets de métricas, widgets de logs y texto. Existen dos patrones para compartir y confundirlos es una trampa común. Si un espectador ya tiene una cuenta de AWS, otórgale una identidad de IAM (o un rol a través de la observabilidad entre cuentas) con cloudwatch:GetDashboard y cloudwatch:GetMetricData. Si el espectador no tiene una cuenta de AWS —un jefe de producto, un stakeholder del cliente— utiliza la funcionalidad integrada para compartir paneles, que produce un enlace para compartir protegido por un único correo/contraseña, un grupo de usuarios de Cognito o una URL pública (raramente apropiado). Enviar capturas de pantalla por correo no es observabilidad, y crear un usuario de IAM con acceso a la consola para un espectador que no es de AWS no es privilegio mínimo.

Observabilidad entre Cuentas con OAM

Saltar entre docenas de cuentas para ver métricas es insostenible. La observabilidad entre cuentas de CloudWatch designa una cuenta de monitorización como un receptor central y cualquier número de cuentas de origen que comparten métricas, logs y trazas con ella a través de recursos de receptor y enlace. El despliegue más rápido a escala es abrir la consola de CloudWatch en la cuenta de monitorización, crear un receptor y desplegar la plantilla de CloudFormation StackSet generada en toda la organización para crear recursos AWS::Oam::Link en cada cuenta de origen:

Resources:
  ObservabilityLink:
    Type: AWS::Oam::Link
    Properties:
      LabelTemplate: "$AccountName"
      ResourceTypes:
        - AWS::CloudWatch::Metric
        - AWS::Logs::LogGroup
        - AWS::XRay::Trace
      SinkIdentifier: arn:aws:oam:us-east-1:111122223333:sink/abc-123

Resolver esto con roles de IAM entre cuentas y consultas manuales es técnicamente posible, pero no te proporciona paneles unificados, consultas de Metrics Insights entre cuentas ni el enriquecimiento automático de etiquetas con el nombre de la cuenta que proporcionan los enlaces de OAM.

Container Insights y Trazado Distribuido

Para cargas de trabajo en contenedores, Container Insights es la funcionalidad canónica de CloudWatch. En EKS, despliega el agente de CloudWatch (o el recolector ADOT) como un DaemonSet más Fluent Bit para el reenvío de logs. El agente extrae métricas de cAdvisor y kubelet y las emite en los espacios de nombres ECS/ContainerInsights y ContainerInsights (CPU/memoria por pod, nodo, espacio de nombres y clúster), mientras que Fluent Bit envía stdout/stderr a grupos de logs como /aws/containerinsights/<cluster>/application, /dataplane y /host. Montar tu propio stack de Prometheus/Grafana es posible; el patrón gestionado es Container Insights más Logs Insights:

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "payments"
| filter log like /ERROR/
| stats count() by kubernetes.pod_name

Las métricas te dicen que algo va lento; las trazas te dicen dónde. X-Ray instrumenta cada servicio en la ruta de una solicitud, propagando un ID de traza a través de la cabecera X-Amzn-Trace-Id y emitiendo segmentos y subsegmentos al daemon de X-Ray o al recolector ADOT. El mapa de servicios visualiza nodos y aristas con porcentajes de latencia, error y fallo. Sin X-Ray, un pico en p99 aparece como una métrica de CloudWatch sin atribución.

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()  # instruments boto3, requests, sqlalchemy, etc.

@xray_recorder.capture('checkout')
def checkout(order_id): ...

Container Insights más X-Ray más CloudWatch Logs es el trípode fundamental para la observabilidad de microservicios.

Los tres flujos de logs: CloudTrail, VPC Flow Logs y CloudWatch Logs

Cualquier estrategia de observabilidad en AWS separa tres flujos de logs distintos: actividad de la API del plano de gestión (CloudTrail), actividad de red del plano de datos (VPC Flow Logs) y salida de la aplicación/SO (CloudWatch Logs). Cada uno responde a una pregunta forense diferente, y confundirlos es un error de diseño común.

CloudTrail registra cada llamada a la API de AWS: quién la invocó (userIdentity), desde qué IP, contra qué recurso, con qué parámetros y si tuvo éxito. Es el único servicio que vincula de manera fiable una mutación a una entidad principal (principal) de IAM específica. Una idea errónea común es que CloudWatch Logs es el lugar correcto para buscar la actividad de la API; CloudWatch Logs captura la salida de la aplicación/sistema, no los datos de auditoría a nivel de entidad principal (principal). CloudTrail puede entregar sus eventos a CloudWatch Logs para el filtrado de métricas en tiempo real, pero el registro de auditoría subyacente se origina en CloudTrail.

En un entorno de AWS Organizations, el patrón correcto es un trail de organización creado desde la cuenta de gestión (o de administrador delegado), que inscribe automáticamente las nuevas cuentas miembro y transmite los eventos a un único bucket de S3 en una cuenta de archivo de logs dedicada:

CentralTrail:
  Type: AWS::CloudTrail::Trail
  Properties:
    IsOrganizationTrail: true
    IsMultiRegionTrail: true
    IncludeGlobalServiceEvents: true
    EnableLogFileValidation: true       # SHA-256 digest chain
    S3BucketName: org-cloudtrail-logs
    KMSKeyId: !Ref TrailKmsKey

El bucket de destino necesita versionamiento, una política de bucket que restrinja s3:PutObject a la entidad principal de servicio (service principal) de CloudTrail, cifrado SSE-KMS, acceso de solo lectura entre cuentas para los auditores e, idealmente, S3 Object Lock en modo de conformidad (compliance mode) para garantías WORM (Write Once, Read Many). La validación de archivos de log produce archivos de resumen (digest) firmados para que la manipulación sea detectable. Los eventos de gestión están activados por defecto durante 90 días; retenerlos más allá de ese período requiere un trail. Los eventos de datos (a nivel de objeto de S3, invocación de Lambda, a nivel de elemento de DynamoDB) son opcionales (opt-in) debido a su volumen y costo. Para consultas históricas ad-hoc, CloudTrail Lake o Athena contra el bucket del trail te permiten ejecutar SQL:

SELECT userIdentity.arn, eventTime, requestParameters
FROM cloudtrail_logs
WHERE eventName = 'AuthorizeSecurityGroupIngress'
  AND eventTime BETWEEN '2024-01-08' AND '2024-01-12';

Los VPC Flow Logs capturan metadatos sobre el tráfico IP —la 5-tupla, bytes, paquetes, acción (ACCEPT/REJECT) y estado del log— para una VPC, subred o ENI. No capturan las cargas útiles (payloads). Los destinos de entrega son CloudWatch Logs, S3 o Kinesis Data Firehose. Elige S3 para el archivado; elige CloudWatch Logs cuando necesites filtros de métricas para disparar alarmas sobre patrones de tráfico sospechosos; elige Firehose cuando el requisito sea un análisis casi en tiempo real. La canalización (pipeline) canónica casi en tiempo real para una VPC con NLBs, ASGs y bases de datos:

ENIs → VPC Flow Logs (delivery: Kinesis Data Firehose)
      → Firehose delivery stream (optional Lambda transform)
      → Amazon OpenSearch Service (index: vpc-flow-*)
      → OpenSearch Dashboards

La ruta alternativa CloudWatch Logs → filtro de suscripción → Firehose → OpenSearch funciona, pero añade un salto y costo. S3 es la opción incorrecta cuando el requisito es “casi en tiempo real”. No habilitar los Flow Logs en absoluto es la trampa más perjudicial: cuando ocurre un incidente de seguridad, no hay registro de origen/destino/puerto ni visibilidad de ACCEPT frente a REJECT. El mismo razonamiento se aplica a los logs de acceso de ALB: son opcionales, se entregan a S3 y, sin ellos, no hay registro a nivel de solicitud de las IP de los clientes, los códigos de respuesta, las latencias del destino o los agentes de usuario (user agents). Juntos, los Flow Logs (L3/L4) y los logs de acceso de ALB (L7) constituyen la línea base para el análisis forense del tráfico.

CloudWatch Logs recibe logs de aplicaciones, de Lambda y del SO a través del agente de CloudWatch. Su poder reside en los filtros de métricas: expresiones de patrón que escanean los eventos entrantes e incrementan una métrica personalizada cuando hay una coincidencia, lo que luego activa una alarma:

# Metric filter detecting inbound SSH sessions from Flow Logs
[version, account, eni, source, dest, srcport, destport=22,
 protocol=6, packets, bytes, start, end, action=ACCEPT, status]

Un filtro paralelo sobre el puerto 3389 cubre RDP. La ingesta de logs sin alertas produce un análisis forense post-incidente, no prevención.

Para flotas grandes, el estándar es distribuir (fan out) los logs a una canalización de procesamiento a través de un filtro de suscripción en un grupo de logs, transmitiendo (streaming) los eventos que coinciden a un Kinesis Data Stream, Firehose o Lambda casi en tiempo real:

{
  "filterPattern": "",
  "destinationArn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/logs-to-os"
}

La trampa es enviar logs en crudo al almacenamiento sin una canalización de procesamiento: volcarlos a S3 sin un catálogo de Glue, sin un índice de OpenSearch y sin un grupo de trabajo (workgroup) de Athena significa que los logs existen pero no se puede actuar sobre ellos durante un incidente. La observabilidad requiere una superficie de consulta, no solo bytes duraderos. Los grupos de logs también necesitan políticas de retención explícitas —el valor por defecto es “nunca expirar”, lo que consume dinero silenciosamente— y pueden exportarse a S3 para un archivado a largo plazo bajo reglas de ciclo de vida.

Detección de eventos a nivel de API con la mínima sobrecarga

Para eventos de alto valor del plano de control —CreateImage, AuthorizeSecurityGroupIngress, StopLogging, ConsoleLogin sin MFA— el patrón con la menor sobrecarga es CloudTrail → regla de EventBridge → SNS. EventBridge recibe de forma nativa cada evento de gestión de CloudTrail, y una regla con un patrón de evento no necesita código “glue” de Lambda:

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["CreateImage"]
  }
}

Enviar CloudTrail a CloudWatch Logs y aplicar un filtro de métrica también funciona, pero añade un grupo de logs, un filtro, una alarma y costo, por lo que pierde en términos de sobrecarga operativa cuando el requisito es simplemente “alertar sobre la API X”.

AWS Config: Configuración continua y deriva (Drift)

A menudo se confunden Config y CloudTrail, pero responden a preguntas fundamentalmente diferentes. CloudTrail registra quién llamó a qué; Config registra cómo se ve el recurso ahora y cómo ha cambiado con el tiempo. Esperar que Config registre las llamadas a la API es una respuesta incorrecta clásica: Config no sabe que un usuario invocó PutBucketAcl; sabe que a las 14:03:22 el ACL del bucket cambió del estado A al estado B. Para identificar el principal, correlaciona el registro de cambio de Config con el evento de CloudTrail en la misma marca de tiempo (Config proporciona un enlace profundo a él en la consola).

Las reglas de Config evalúan los recursos contra un estado deseado. Las reglas administradas (managed rules) cubren comprobaciones comunes (restricted-ssh, s3-bucket-public-read-prohibited, required-tags, ec2-instance-no-public-ip, s3-bucket-versioning-enabled, desired-instance-type), y las reglas personalizadas se ejecutan como funciones de Lambda o usan CloudFormation Guard. Las reglas se evalúan cuando hay un cambio de configuración y de forma programada, marcan los recursos como COMPLIANT o NON_COMPLIANT, y pueden desencadenar una remediación automática a través de documentos de SSM Automation. Esta es la respuesta con baja sobrecarga operativa para «detectar SSH abierto» o «detectar tipos de instancia sobredimensionados»: las reglas ya existen y se integran de forma nativa con SNS y Security Hub. Proponer auditorías manuales periódicas, escaneos programados o escáneres desarrollados a medida requiere que construyas y mantengas código que Config ya incluye de fábrica.

Config publica los resultados de la evaluación en SNS. Para automatizar la remediación, conecta una regla de EventBridge al evento de cambio de conformidad (compliance-change) e invoca un documento de SSM Automation o una Lambda:

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Los agregadores (Aggregators) consolidan la conformidad en toda una organización; los paquetes de conformidad (conformance packs) agrupan reglas para marcos de trabajo como PCI-DSS o HIPAA. Workload Discovery on AWS (anteriormente AWS Perspective) es una solución construida sobre Config que visualiza las relaciones entre recursos y genera diagramas de arquitectura; es la respuesta canónica cuando una pregunta pide una herramienta de inventario que pueda diagramar un entorno existente. Config es un prerrequisito.

Security Hub, GuardDuty y Control Tower

Security Hub es el plano de agregación para los hallazgos (findings) de seguridad. Ingiere datos de GuardDuty (detección de amenazas basada en VPC Flow Logs, DNS y CloudTrail), Inspector (hallazgos de vulnerabilidades), Macie, IAM Access Analyzer y Config, y luego normaliza todo al formato AWS Security Finding Format (ASFF). Habilitar Security Hub también habilita estándares de seguridad, especialmente el estándar AWS Foundational Security Best Practices (FSBP): docenas de comprobaciones automáticas (MFA en la cuenta raíz, S3 público, EBS sin cifrar, CloudTrail multirregional) que internamente se mapean a reglas de Config.

A escala de organización, designa una cuenta de administrador delegado para Security Hub (y para GuardDuty y Config), habilita el servicio y el estándar FSBP para toda la organización con la opción «auto-enable new accounts», y enruta los hallazgos a través de EventBridge a SNS haciendo coincidir Security Hub Findings - Imported filtrado por el ARN del estándar FSBP con Compliance.Status = FAILED. Desarrollar tu propia Lambda para analizar CloudTrail o paneles de control por cuenta añade una carga operativa que Security Hub ya absorbe.

Una división conceptual crucial: Security Hub es detectivo y agregador, no preventivo. Prevenir la deriva (drift) es trabajo de AWS Control Tower, que orquesta una zona de aterrizaje (landing zone) multicuenta bien arquitectada. Account Factory aprovisiona nuevas cuentas con una línea base de redes, registro (logging) e IAM. La gobernanza se expresa a través de barandillas de seguridad (guardrails) de tres tipos:

Los controles proactivos evalúan las plantillas de CloudFormation antes de que se despliegue una pila y se niegan a crear, por ejemplo, una instancia de RDS sin cifrar. Security Hub solo te diría que la instancia sin cifrar existe después de que ya esté en ejecución. Si un requisito dice «prevenir», piensa en Control Tower. Si dice «detectar, notificar o agregar», piensa en Security Hub o Config.

Macie: Descubrimiento de datos sensibles

Macie utiliza ML y coincidencia de patrones para identificar datos sensibles (PII, datos financieros, credenciales) dentro de los objetos de S3. La trampa crítica es asumir que Macie protege los datos. No lo hace. Macie descubre e informa. Uso correcto:

1. Habilita Macie en la cuenta/región de destino.
2. Configura un trabajo de descubrimiento de datos sensibles, apuntando a buckets/prefijos/etiquetas de forma programada.
3. Enruta los hallazgos a través de EventBridge (source: aws.macie) a SNS para notificaciones, a Lambda para remediación (cuarentena, endurecimiento de la política del bucket) o a Security Hub.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Sin el trabajo de descubrimiento, Macie no produce nada. Sin la conexión EventBridge → SNS, los hallazgos permanecen en la consola de Macie sin que nadie se dé cuenta.

Organizations, SCPs y Políticas de Etiquetas

AWS Organizations expone tres tipos de políticas relevantes aquí. Las políticas de etiquetas (Tag policies) definen las claves de etiqueta, el uso de mayúsculas/minúsculas y los valores permitidos; reportan el incumplimiento y, en combinación con las condiciones aws:ResourceTag/aws:RequestTag, se pueden hacer cumplir. Las políticas de control de servicios (SCPs) definen los permisos máximos disponibles para las entidades principales de las cuentas miembro. Las políticas de respaldo (Backup policies) y las políticas de exclusión voluntaria de IA (AI opt-out policies) completan el conjunto.

Un modelo mental crucial: las SCPs nunca otorgan permisos. Son un filtro sobre lo que IAM (políticas de identidad, políticas de recursos, límites de permisos) podría permitir de otro modo. Una entidad principal debe tener un Allow en IAM y la SCP no debe tener un Deny (o debe incluir la acción en su lista de Allow). “Simplemente adjunta una SCP” nunca es una respuesta completa a una pregunta sobre permisos; sin un Allow de IAM, a la entidad principal se le deniegan los permisos por defecto, independientemente del contenido de la SCP.

Para requerir etiquetas en el momento de la creación, combina políticas de etiquetas con una SCP como la siguiente:

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": { "aws:RequestTag/CostCenter": "true" }
  }
}

La política de etiquetas declara el esquema; la SCP deniega la creación sin la etiqueta; la política de IAM otorga la acción de creación. Se necesitan las tres. La regla required-tags de AWS Config detecta y remedia los recursos existentes que no cumplen con la política.

Systems Manager Automation y Aplicación de Parches

Systems Manager (SSM) es la columna vertebral operativa para las actividades del ciclo de vida en flotas de nodos EC2 e híbridos. Dos constructos son los más importantes para la aplicación de parches: los documentos de automatización (Automation documents) (runbooks declarativos en YAML/JSON que llaman a APIs de AWS o a scripts) y las ventanas de mantenimiento (Maintenance Windows) (que programan esos runbooks para ejecutarse en destinos basados en etiquetas o grupos de recursos dentro de una ventana de cambio con umbrales de concurrencia y error).

El flujo canónico para la aplicación de parches es AWS-RunPatchBaseline (un documento de tipo Command) que se ejecuta en instancias seleccionadas por una etiqueta de Patch Group, utilizando una Patch Baseline que define reglas de aprobación por sistema operativo. Para instancias detrás de balanceadores de carga, ejecutar AWS-RunPatchBaseline directamente interrumpe las conexiones a mitad del parcheo porque las instancias permanecen en estado InService en el grupo de destino. El patrón correcto es AWSEC2-PatchLoadBalancerInstance, que:

1. Da de baja la instancia de su grupo de destino de CLB o ALB.
2. Espera el drenaje de conexiones / el retraso de la baja del registro.
3. Invoca los pasos de escaneo e instalación de la patch baseline.
4. Reinicia si la baseline lo requiere.
5. Vuelve a registrar la instancia y espera a que la comprobación de estado del destino devuelva healthy.

Dos prerrequisitos causan el modo de fallo de “produce errores”. Primero, el rol de IAM pasado como AutomationAssumeRole debe incluir elasticloadbalancing:DeregisterTargets, RegisterTargets y DescribeTargetHealth además de los permisos estándar de SSM para la aplicación de parches. Segundo, la instancia debe ser un nodo administrado (managed node): con el SSM Agent en ejecución y el perfil de instancia incluyendo AmazonSSMManagedInstanceCore. Sin estos, las llamadas para dar de baja el registro fallan o SSM no puede ver la instancia.

schemaVersion: '0.3'
description: Patch instance behind ALB
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId: { type: String }
  TargetGroupArn: { type: String }
  AutomationAssumeRole: { type: String }
mainSteps:
  - name: deregister
    action: aws:executeAwsApi
    inputs:
      Service: elbv2
      Api: DeregisterTargets
      TargetGroupArn: '{{ TargetGroupArn }}'

← Seguridad · Todos los dominios · Alta disponibilidad →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →