Amazon SAA-C03: Gestión, Operaciones, Observabilidad y Costo — Guía de estudio

By Laurynas Brazys · 15 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 predeterminado 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 impulsados 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 río abajo, la respuesta no está en AWS/Lambda; está en AWS/Events. Verificar TriggeredRules le indica si el patrón de la regla realmente coincidió, y Invocations/FailedInvocations le indican si el destino mismo fue llamado y si la llamada tuvo éxito. Buscar métricas de Lambda porque Lambda es el servicio más familiar omite el hecho de que la regla quizás nunca haya coincidido con un evento entrante.

La resolución de métricas es una configuración por recurso con implicaciones de costos. La monitorización básica emite métricas cada cinco minutos sin cargo adicional, lo cual es suficiente para cargas de trabajo de estado estable de larga duración, pero demasiado burdo 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 característica de pago, por lo que no está activada por defecto.

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

Las alarmas deben distinguir la señal del ruido. Una sola alarma en CPU > 50% se dispara constantemente durante las ráfagas normales y entrena a los operadores para ignorarla. Las alarmas compuestas combinan estados de alarma secundarios con una expresión de regla booleana para que los operadores solo sean notificados cuando se cumpla una condición genuinamente accionable. Para una carga de trabajo donde los picos transitorios de CPU son benignos, pero la presión sostenida de la CPU combinada con IOPS de lectura de disco elevadas 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 secundarias aún pueden pasar al estado ALARM internamente, pero solo la compuesta activa SNS. Dos alarmas independientes que notifican al personal de guardia recrean el problema del ruido; una sola alarma con un umbral más alto pierde la correlación.

Los paneles agregan widgets de métricas, widgets de registros y texto. Existen dos patrones de uso compartido y confundirlos es una trampa común. Si un espectador ya tiene una cuenta de AWS, concédale 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 gerente de producto, un interesado del cliente), use la función de uso compartido de paneles incorporada, que produce un enlace compartible protegido por un solo correo electrónico/contraseña, un grupo de usuarios de Cognito o una URL pública (rara vez apropiado). Enviar capturas de pantalla por correo electrónico no es observabilidad, y crear un usuario de IAM con acceso a la consola para un espectador que no es de AWS no es el 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 monitoreo como un sumidero central y cualquier número de cuentas de origen que comparten métricas, registros y trazas con ella a través de recursos de sumidero y enlace. El despliegue más rápido a escala es abrir la consola de CloudWatch en la cuenta de monitoreo, crear un sumidero 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 le brinda paneles unificados, consultas de Metrics Insights entre cuentas o el enriquecimiento automático de etiquetas de nombres de cuenta que proporcionan los enlaces de OAM.

Container Insights y Trazado Distribuido

Para cargas de trabajo en contenedores, Container Insights es la característica 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 registros. El agente extrae métricas de cAdvisor y kubelet y las emite a 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 registros como /aws/containerinsights/<cluster>/application, /dataplane y /host. Es posible crear su propia pila de Prometheus/Grafana; el patrón administrado 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 le dicen que algo es lento; las trazas le dicen dónde. X-Ray instrumenta cada servicio en una ruta de solicitud, propagando un ID de traza a través del encabezado X-Amzn-Trace-Id y emitiendo segmentos y subsegmentos al demonio de X-Ray o al recolector ADOT. El mapa de servicio visualiza nodos y aristas con porcentajes de latencia, error y fallas. Sin X-Ray, un pico de 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 taburete de tres patas para la observabilidad de microservicios.

Los tres flujos de registros: CloudTrail, VPC Flow Logs, CloudWatch Logs

Cualquier estrategia de observabilidad de AWS separa tres flujos de registros distintos: actividad de la API del plano de administración (CloudTrail), actividad de red del plano de datos (VPC Flow Logs) y salida de aplicaciones/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 forma fiable una mutación a un principal de IAM específico. Una idea errónea común es que CloudWatch Logs es el lugar adecuado para buscar actividad de la API; CloudWatch Logs captura la salida de aplicaciones/sistemas, no datos de auditoría a nivel de 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 administración (o administrador delegado), que inscribe automáticamente nuevas cuentas de miembro y transmite eventos a un único bucket de S3 en una cuenta de archivo de registros 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 versionado, una política de bucket que restrinja s3:PutObject al principal de servicio de CloudTrail, cifrado SSE-KMS, acceso de solo lectura entre cuentas para auditores e idealmente S3 Object Lock en modo de cumplimiento para garantías WORM. La validación de archivos de registro produce archivos de resumen firmados para que la manipulación sea detectable. Los eventos de administración están activados por defecto durante 90 días; retenerlos más allá de eso 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 debido al volumen y al costo. Para consultas históricas ad-hoc, CloudTrail Lake o Athena contra el bucket del trail le permiten ejecutar SQL:

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

VPC Flow Logs capturan metadatos sobre el tráfico IP —la 5-tupla, bytes, paquetes, acción (ACCEPT/REJECT) y estado del registro— para una VPC, subred o ENI. No capturan cargas útiles. Los destinos de entrega son CloudWatch Logs, S3 o Kinesis Data Firehose. Elija S3 al archivar; elija CloudWatch Logs cuando necesite filtros de métricas para activar alarmas sobre patrones de tráfico sospechosos; elija Firehose cuando el requisito sea análisis casi en tiempo real. La canalización 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 un costo. S3 es incorrecto cuando el requisito es “casi en tiempo real”. No habilitar 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 vs REJECT. El mismo razonamiento se aplica a los registros de acceso de ALB —opcionales, entregados a S3, y sin ellos no hay registro a nivel de solicitud de IPs de cliente, códigos de respuesta, latencias de destino o agentes de usuario. Juntos, Flow Logs (L3/L4) y los registros de acceso de ALB (L7) constituyen la línea base forense del tráfico.

CloudWatch Logs recibe registros de aplicaciones, Lambda y del sistema operativo a través del agente de CloudWatch. Su poder proviene de los filtros de métricas: expresiones de patrón que escanean los eventos entrantes e incrementan una métrica personalizada al coincidir, 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 en 3389 cubre RDP. La ingesta de registros sin alertas produce análisis forenses posteriores al incidente, no prevención.

Para grandes flotas, el estándar es distribuir los registros en una canalización de procesamiento a través de un filtro de suscripción en un grupo de registros, transmitiendo los eventos coincidentes 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 registros sin procesar al almacenamiento sin una canalización de procesamiento: volcar a S3 sin un catálogo de Glue, sin un índice de OpenSearch y sin un grupo de trabajo de Athena significa que los registros existen pero no se pueden procesar durante un incidente. La observabilidad requiere una superficie de consulta, no solo bytes duraderos. Los grupos de registros también necesitan políticas de retención explícitas —el valor predeterminado es “nunca expirar”, lo que quema dinero silenciosamente— y se pueden exportar a S3 para archivado a largo plazo bajo reglas de ciclo de vida.

Detección de eventos a nivel de API con la menor sobrecarga

Para eventos de plano de control de alto valor —CreateImage, AuthorizeSecurityGroupIngress, StopLogging, ConsoleLogin sin MFA— el patrón de menor sobrecarga es CloudTrail → regla de EventBridge → SNS. EventBridge recibe de forma nativa cada evento de administración de CloudTrail, y una regla con un patrón de evento no necesita pegamento 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étricas también funciona, pero añade un grupo de registros, un filtro, una alarma y un costo, por lo que pierde en sobrecarga operativa cuando el requisito es simplemente “alertar sobre la API X”.

AWS Config: Configuración Continua y Desviación

Config y CloudTrail a menudo se confunden, 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 cambió con el tiempo. Esperar que Config registre llamadas a la API es una respuesta clásica incorrecta: Config no sabe que un usuario invocó PutBucketAcl; sabe que a las 14:03:22 la ACL del bucket cambió del estado A al estado B. Para identificar al principal, correlacione el registro de cambio de Config con el evento de CloudTrail en la misma marca de tiempo (Config enlaza profundamente a él en la consola).

Las reglas de Config evalúan los recursos con respecto al estado deseado. Las reglas administradas cubren verificaciones 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 Lambda o usan CloudFormation Guard. Las reglas se evalúan en el cambio de configuración y en un horario, marcan los recursos como COMPLIANT o NON_COMPLIANT, y pueden activar la remediación automática a través de documentos de SSM Automation. Esta es la respuesta de baja sobrecarga operativa a “detectar SSH abierto” o “detectar tipos de instancias de tamaño excesivo”: 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 hechos a mano requiere que construya y mantenga código que Config ya incluye.

Config publica los resultados de la evaluación en SNS. Para automatizar la remediación, conecte una regla de EventBridge al evento de cambio de cumplimiento e invoque un documento de SSM Automation o Lambda:

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

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

Security Hub, GuardDuty y Control Tower

Security Hub es el plano de agregación para los hallazgos de seguridad. Ingresa 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, luego normaliza todo en el Formato de Hallazgos de Seguridad de AWS (ASFF). Habilitar Security Hub también habilita los estándares de seguridad, especialmente el estándar AWS Foundational Security Best Practices (FSBP), docenas de verificaciones automáticas (MFA raíz, S3 público, EBS sin cifrar, CloudTrail multirregión) mapeadas a reglas de Config bajo el capó.

A escala de organización, designe una cuenta de administrador delegado para Security Hub (y para GuardDuty y Config), habilite el servicio y el estándar FSBP para toda la organización con el interruptor “auto-enable new accounts”, y enrute 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. Crear su propia Lambda de análisis de CloudTrail o paneles por cuenta agrega una carga operativa que Security Hub ya absorbe.

Una división conceptual crucial: Security Hub es detectivo y agregativo, no preventivo. Prevenir la desviación es el trabajo de AWS Control Tower, que orquesta una zona de aterrizaje de varias cuentas bien arquitectada. Account Factory aprovisiona nuevas cuentas con redes, registro e IAM de línea base. La gobernanza se expresa a través de barandillas de tres tipos:

Los controles proactivos evalúan las plantillas de CloudFormation antes de que se implemente una pila y se niegan a crear, por ejemplo, una instancia de RDS sin cifrar. Security Hub solo le diría que la instancia sin cifrar existe después de que esté en ejecución. Si un requisito dice “prevenir”, piense en Control Tower. Si dice “detectar, notificar o agregar”, piense 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 objetos de S3. La trampa crítica es asumir que Macie protege los datos. No lo hace. Macie descubre e informa. Uso correcto:

1. Habilite Macie en la cuenta/región de destino.
2. Configure un trabajo de descubrimiento de datos sensibles, dirigido a buckets/prefijos/etiquetas en un horario.
3. Enrute los hallazgos a través de EventBridge (source: aws.macie) a SNS para notificaciones, Lambda para remediación (cuarentena, ajuste de políticas de bucket) o Security Hub.

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

Sin el trabajo de descubrimiento, Macie no produce nada. Sin el cableado EventBridge → SNS, los hallazgos permanecen en la consola de Macie sin ser notados.

Organizaciones, SCP y políticas de etiquetas

AWS Organizations expone tres tipos de políticas relevantes aquí. Las políticas de etiquetas definen las claves de etiquetas, el uso de mayúsculas y minúsculas y los valores permitidos; informan sobre el incumplimiento y, combinadas con las condiciones aws:ResourceTag/aws:RequestTag, se pueden aplicar. Las Políticas de control de servicios (SCP) definen los permisos máximos disponibles para los principales miembros. Las políticas de respaldo y las políticas de exclusión voluntaria de IA completan el conjunto.

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

Para requerir etiquetas en la creación, combine las políticas de etiquetas con una SCP como:

{
  "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. Las tres son necesarias. La regla required-tags de AWS Config detecta y remedia los recursos existentes que no cumplen con las normas.

Automatización y aplicación de parches de Systems Manager

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

El flujo canónico de aplicación de parches es AWS-RunPatchBaseline (un documento de comando) que se ejecuta en instancias seleccionadas por una etiqueta de grupo de parches, utilizando una línea base de parches que define las reglas de aprobación por sistema operativo. Para las instancias detrás de balanceadores de carga, ejecutar AWS-RunPatchBaseline directamente interrumpe las conexiones a mitad del parche porque las instancias permanecen InService en el grupo objetivo. El patrón correcto es AWSEC2-PatchLoadBalancerInstance, que:

1. Anula el registro de la instancia de su grupo objetivo de CLB o ALB.
2. Espera el drenaje de la conexión / el retraso de la anulación del registro.
3. Invoca el escaneo de la línea base de parches y los pasos de instalación.
4. Reinicia si la línea base lo requiere.
5. Vuelve a registrar la instancia y espera a que el estado del objetivo vuelva a ser healthy.

Dos requisitos previos causan el modo de falla 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 aplicación de parches de SSM. Segundo, la instancia debe ser un nodo administrado — el Agente SSM en ejecución y el perfil de instancia que incluya AmazonSSMManagedInstanceCore. Sin esto, las llamadas de anulación de 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](/es/posts/saa-c03-security-iam/)  ·  [Todos los dominios](/es/posts/aws-saa-c03-study-guide/)  ·  [Alta Disponibilidad](/es/posts/saa-c03-ha-dr/) →

**[Practica estas preguntas →](/es/kb/amazon/)**  ·  **[Práctica cronometrada en ExamRoll.io →](https://www.examroll.io/?utm_source=guide&utm_medium=referral&utm_campaign=saa-c03)**

Explorar Amazon →