Amazon SOA-C02: Monitoreo, Registro y Remediación — Guía de estudio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Forma parte de la AWS SysOps Administrator Associate SOA-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

La monitorización, el registro y la remediación proporcionan el sistema nervioso operativo para los entornos de AWS: detectan problemas, dan contexto e impulsan acciones correctivas. Este dominio abarca la creación de métricas y paneles de control significativos, la recopilación y retención de registros de manera rentable, la construcción de observabilidad de aplicaciones trazable y la automatización de alertas y remediaciones. Las buenas implementaciones equilibran la relación señal-ruido, controlan los costos y garantizan que los manuales de procedimientos (playbooks) y las automatizaciones sean probados y auditables.

Métricas, paneles de control y alarmas de CloudWatch

Diseñe métricas en torno a los SLI de negocio y operativos (latencia, tasa de errores, profundidad de la cola, CPU/memoria para la infraestructura). Utilice métricas integradas (EC2, RDS, ELB) además de métricas personalizadas a través de PutMetricData para contadores a nivel de aplicación (

undefined

). Prefiera dimensiones que permitan el filtrado (InstanceId, ServiceName) y evite dimensiones de alta cardinalidad que disparan los costos de las métricas.

Utilice los paneles de CloudWatch para combinar métricas, registros y alarmas en vistas operativas. Cree widgets en la consola o a través de CloudFormation (AWS::CloudWatch::Dashboard) con cálculos de métricas (metric math) para obtener métricas derivadas: calcule la tasa de errores usando cálculos de métricas (ERRORS/SUM(REQUESTS)) y muestre percentiles (p50, p90, p99). Para las alarmas, elija patrones de configuración según la intención:

Alarmas de una sola métrica para umbrales simples:

undefined

Alarmas compuestas para reducir el ruido combinando condiciones (AND/OR) entre múltiples alarmas.
Detección de anomalías para ajustar umbrales automáticamente: utilice la detección de anomalías de CloudWatch en una métrica con comportamiento estacional esperado.

Criterios de decisión: utilice períodos de evaluación y configuraciones de puntos de datos para alarma para evitar oscilaciones (flapping); active SNS, Auto Scaling o Systems Manager Automation como acciones de alarma. Prefiera alarmas compuestas y detección de anomalías para entornos con líneas base variables.

CloudWatch Logs, Logs Insights y retención

Agregue registros con grupos de CloudWatch Logs y estructúrelos por aplicación y entorno. Cree grupos de registros a través de la CLI:

undefined

y aplique la retención con

undefined

. Utilice filtros de suscripción para transmitir registros a Kinesis Data Firehose (para S3/Redshift), Lambda (procesamiento en tiempo real) o herramientas de socios; comprima y particione en S3 para reducir los costos de almacenamiento.

Utilice CloudWatch Logs Insights para consultas ad-hoc y paneles de control; cree consultas guardadas que extraigan ID de traza y contextos de error (p. ej.,

undefined

). Prácticas de control de costos de retención e ingesta:

Establezca una retención adecuada por grupo de registros (7/30/90/365 días) según las necesidades de cumplimiento y resolución de problemas.
Exporte los registros más antiguos a S3 a través del ciclo de vida de retención o Firehose con compresión y reglas de ciclo de vida a Glacier/Archive.
Utilice muestreo o registros estructurados (JSON) y el Formato de Métrica Embebido (EMF) para reducir los costosos registros de alta cardinalidad sin dejar de derivar métricas.

Criterios de decisión: retención corta para registros de depuración detallados, retención más larga para registros de auditoría/seguridad; dirija los registros de alto volumen a S3 en lugar de una retención indefinida en CloudWatch.

CloudTrail, registros de auditoría e historial de eventos

Habilite CloudTrail en todas las regiones y cuentas; cree un rastro (trail) de organización para el registro de auditoría centralizado en un bucket de S3 seguro, con validación de archivos de registro y cifrado SSE-KMS. Configure eventos de gestión (lectura/escritura) y habilite selectivamente eventos de datos (a nivel de objeto de S3, invocación de funciones de Lambda) donde se requiera una auditoría detallada, ya que los eventos de datos tienen mayor volumen y costo.

Utilice el historial de eventos de CloudTrail en la consola para búsquedas rápidas de 90 días y CloudTrail Lake o Athena sobre los registros exportados a S3 para análisis e investigaciones a largo plazo. Proteja el rastro mediante:

La aplicación de rastros multirregionales para capturar eventos de servicios globales.
La integración de CloudTrail con CloudWatch Logs para detección casi en tiempo real, o con EventBridge para dirigir eventos específicos a Lambda/Systems Manager para remediación automatizada.
La aplicación de políticas de bucket de S3 y S3 Object Lock (si es necesario) para evitar la manipulación.

Criterios de decisión: habilite los eventos de datos solo para buckets/funciones donde la visibilidad forense sea necesaria; utilice rastros centralizados y patrones de acceso entre cuentas para simplificar el cumplimiento.

Trazado de aplicaciones y observabilidad (X-Ray)

Instrumente las aplicaciones con los SDK de AWS X-Ray para emitir segmentos y subsegmentos. Para entornos de ejecución no instrumentados, ejecute el daemon/agente de X-Ray como un sidecar o servicio (tarea de ECS, daemon de EC2 o trazado integrado de Lambda). Configure reglas de muestreo para controlar el volumen de trazas y establezca mapas de servicio en ServiceLens para visualizar las dependencias entre servicios. Anote las trazas con claves de negocio (userId, orderId) y registre excepciones/metadatos para ayudar en la clasificación de problemas (triage).

Correlacione las trazas con los registros incluyendo el ID de traza de X-Ray en los registros de la aplicación (utilice la cabecera de la traza o el SDK para obtener el ID de traza actual) para que las consultas de CloudWatch Logs Insights puedan unir registros y trazas. Para Lambda, habilite el trazado activo (Consola o

undefined

) para enviar trazas automáticamente a X-Ray. Utilice el análisis de trazas para detectar latencias de cola larga (tail latencies), puntos calientes (hotspots) y desgloses de llamadas a la base de datos.

Criterios de decisión: habilite el trazado para servicios críticos y utilice el muestreo adaptativo para limitar el costo; prefiera trazas estructuradas (anotaciones/metadatos) para que la correlación entre registros y trazas sea determinista.

Remediación y alertas automatizadas (EventBridge/Lambda)

Utilice reglas de EventBridge para detectar cambios de estado en alarmas de CloudWatch, eventos de CloudTrail o eventos personalizados y enrutarlos a destinos como Lambda, documentos de Systems Manager Automation, Step Functions o SNS. Cree reglas con transformadores de entrada para pasar un contexto mínimo a la acción de remediación (

undefined

). Implemente funciones Lambda para remediaciones ligeras (reiniciar un servicio, revocar credenciales), pero use SSM Automation o Step Functions para playbooks auditables y de larga duración con puntos de control.

Diseñe las remediaciones con la seguridad en mente: incluya modos de ejecución en seco (dry-run), idempotencia, pasos de validación, privilegio mínimo de IAM, registro de logs y un interruptor de emergencia (kill-switch). Use colas de mensajes fallidos (dead-letter queues) y políticas de reintento en las integraciones de EventBridge/Lambda y publique los intentos de remediación en un registro de auditoría o rastro de seguridad. Pruebe las automatizaciones en una cuenta de staging (preproducción) y ejecute pruebas canary después del despliegue.

Criterios de decisión: prefiera SSM Automation o Step Functions para recuperaciones de varios pasos y que requieran aprobación humana; use Lambda para soluciones simples y rápidas. Siempre incluya una reversión (rollback) manual o un punto de interrupción con intervención humana para acciones arriesgadas.

Errores comunes y criterios de decisión

Confiar en una única métrica para decisiones de estado: combine métricas (p. ej., tasa de errores + latencia + throttles) o use alarmas compuestas/matemática de métricas para evitar falsos positivos.
No tener en cuenta los costos de retención e ingesta de logs: establezca la retención por grupo de logs, enrute los logs masivos a S3 a través de Firehose con compresión y use políticas de ciclo de vida para mover datos antiguos a niveles de almacenamiento más económicos.
Sobreinstrumentación con dimensiones de alta cardinalidad o con el muestreo de trazas deshabilitado: limite las dimensiones y habilite el muestreo adaptativo para controlar el costo mientras se preserva la señal.
Desplegar remediación automatizada sin pruebas: valide en un entorno de staging, use indicadores de dry-run y asegure la idempotencia y reversiones seguras antes de la activación en producción.
Fatiga por alertas debido a alarmas ruidosas: use detección de anomalías, alarmas compuestas, ventanas de supresión y escale solo eventos significativos al personal de guardia (on-call).
Falta de correlación entre logs, métricas y trazas: propague los ID de traza en los logs y las métricas de EMF, y cree consultas guardadas de Logs Insights y vistas de ServiceLens para unificar los datos.

Problema práctico: Escenario de caso de uso

Acme Payments experimenta fallos intermitentes en el procesamiento de pagos durante los picos de tráfico; los ingenieros observan un aumento de la latencia y errores 5xx esporádicos, pero los reinicios automatizados a veces han enmascarado la causa raíz.

Instrumentar el servicio de pagos con el SDK de X-Ray y métricas de EMF; añadir los ID de traza a los logs de la aplicación y enviar las métricas estructuradas OrdersFailed y OrdersProcessed a través de PutMetricData/EMF.
Crear una matemática de métricas en CloudWatch para calcular la tasa de errores (OrdersFailed / OrdersProcessed) y una alarma compuesta que combine tasa de errores > umbral Y latencia p99 > umbral.
Enrutar las acciones de la alarma a una regla de EventBridge que active un flujo de trabajo de Step Functions para pasos de diagnóstico (recopilar trazas/logs recientes, ejecutar comprobaciones de estado) y, si es seguro, un reinicio automatizado a través de SSM Automation.
Configurar la suscripción de CloudTrail y CloudWatch Logs para archivar los logs completos en S3 (comprimidos) con un ciclo de vida hacia Glacier, y establecer una retención corta en CloudWatch para los logs de depuración detallados (verbose).
Ejecutar pruebas de extremo a extremo y transacciones sintéticas canary (CloudWatch Synthetics) para validar la observabilidad y el flujo de remediación antes de habilitar la autorremediación en producción.

Justificación: correlacionar métricas, logs y trazas para localizar la causa raíz en lugar de tratar repetidamente los síntomas; combinar alarmas para reducir el ruido y usar automatización auditable y probada (Step Functions/SSM) para una remediación segura mientras se controlan los costos de almacenamiento de logs.

Todos los dominios · Alta Disponibilidad →

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