Guía

Despliegue automático de reversión (rollback) para una implementación de ECS Fargate fallida sin scripts personalizados.

→Habilite el disyuntor de despliegue de ECS (ECS deployment circuit breaker) con reversión en el servicio ECS.

Por qué: Característica nativa de ECS que revierte automáticamente si las nuevas tareas no logran estabilizarse. Menor sobrecarga operativa en comparación con el sondeo personalizado de CodeBuild o configuraciones complejas de CodeDeploy.

Referencia↗

Implementar en una región primaria, validar con pruebas automatizadas y luego implementar en otras regiones en paralelo.

→Utilice un solo CodePipeline con etapas secuenciales: (1) Desplegar Región A, (2) una etapa de prueba de CodeBuild que ejecuta la validación, (3) una etapa de despliegue paralelo para las Regiones B y C.

Por qué: CodeBuild actúa como una puerta automatizada y programática. Una sola pipeline es más simple que orquestar múltiples pipelines con Step Functions.

Un script de validación de larga duración en un hook de ciclo de vida de CodeDeploy causa un éxito prematuro del despliegue.

→Aumente la propiedad `timeout` para el script específico del hook de ciclo de vida en el archivo `AppSpec.yml`.

Por qué: El tiempo de espera se configura por hook en el archivo AppSpec, no a nivel de grupo de despliegue. Esto asegura que el script de validación tenga tiempo suficiente para completarse.

Acelerar las compilaciones lentas de imágenes Docker en CodeBuild causadas por la descarga repetida de dependencias y capas de imagen en cada ejecución.

→En la configuración del proyecto CodeBuild, habilite `LOCAL_DOCKER_LAYER_CACHE` y configure una caché de S3 para los directorios de dependencias (p. ej., `.m2`, `node_modules`).

Por qué: Aborda directamente ambas fuentes de lentitud. El almacenamiento en caché de capas de Docker reutiliza las capas de imagen sin cambios; el almacenamiento en caché de S3 reutiliza las dependencias de aplicación descargadas.

Implementar un despliegue canary para una función Lambda con reversión automatizada y basada en métricas.

→Utilice AWS SAM con `DeploymentPreference` (p. ej., tipo `Canary10Percent5Minutes`). Agregue una alarma de CloudWatch en la métrica `Errors` como disparador de reversión.

Por qué: SAM se integra nativamente con CodeDeploy para Lambda, automatizando el cambio de tráfico de alias, el monitoreo y la reversión sin scripts personalizados.

Referencia↗

Configure IAM para un CodePipeline en la Cuenta A para desplegar recursos en la Cuenta B.

→El rol de la pipeline (Cuenta A) asume un rol de acción (Cuenta B). El rol de acción en B confía en el rol de la pipeline y tiene permisos de despliegue. El bucket de artefactos S3 y la clave KMS en A deben tener políticas de recursos que otorguen acceso al rol de acción en B.

Por qué: Este es el patrón de acceso entre cuentas estándar y seguro: asunción de rol para acciones, políticas basadas en recursos para acceso a datos.

Implementar un flujo de trabajo GitOps para EKS donde el estado del clúster se reconcilia automáticamente y continuamente con un repositorio Git.

→Despliegue un controlador GitOps (p. ej., Flux, ArgoCD) en el clúster EKS. Configúrelo para monitorear el repositorio Git y aplicar/reconciliar cambios.

Por qué: Este es el patrón GitOps estándar "basado en extracción". El controlador dentro del clúster maneja la reconciliación continua y la detección de deriva, que es el principio central de GitOps.

Permitir que un proyecto de CodeBuild en una cuenta de herramientas central despliegue manifiestos de Kubernetes en clústeres EKS en cuentas de carga de trabajo separadas.

→En cada cuenta de carga de trabajo, cree un rol IAM entre cuentas de confianza para el rol de CodeBuild. Asigne este nuevo rol a un grupo RBAC de Kubernetes en el ConfigMap `aws-auth` del clúster EKS. El script de CodeBuild asume el rol antes de ejecutar `kubectl`.

Por qué: Este es el patrón estándar y seguro para el acceso a EKS entre cuentas. Sigue el principio de mínimo privilegio al crear un rol dedicado y de confianza para este propósito.

Realizar una migración compleja de esquema de RDS PostgreSQL o MySQL con cero o casi cero tiempo de inactividad.

→Utilice la característica Amazon RDS Blue/Green Deployments. Cree un entorno de staging (verde) sincronizado, aplique los cambios de esquema y luego realice el switchover para promocionarlo a producción.

Por qué: Este es el servicio gestionado diseñado específicamente para actualizaciones de RDS seguras y sin tiempo de inactividad. Maneja la clonación, la sincronización y un switchover rápido (< 1 min) con salvaguardias integradas.

Desplegar una nueva versión de una aplicación de una sola página (SPA) en S3/CloudFront y asegurar que los usuarios reciban la nueva versión inmediatamente con costes mínimos de invalidación de caché.

→Utilice hashing basado en contenido para los nombres de archivo de los activos (p. ej., `app.a1b2c3d4.js`). Después de desplegar nuevos activos, invalide solo el archivo `index.html` en la distribución de CloudFront.

Por qué: Los nombres de archivo con hash son únicos, por lo que CloudFront los trata como nuevos objetos y los obtiene del origen, omitiendo la caché. Solo el archivo de punto de entrada único (`index.html`) necesita invalidación, lo que es significativamente más barato que una invalidación con comodín (`/*`).

Implementar una pipeline de CI/CD para una aplicación AWS CDK que se actualiza automáticamente cuando la propia definición de la pipeline cambia.

→Utilice el constructo CDK Pipelines (`pipelines.CodePipeline`). Este constructo crea una pipeline que incluye una etapa `SelfMutate` por defecto.

Por qué: CDK Pipelines es un constructo de alto nivel diseñado específicamente para este patrón. La etapa `SelfMutate` asegura que la pipeline siempre refleje la última definición del código antes de desplegar los cambios de la aplicación.

Desplegar una nueva versión de aplicación que requiera un cambio de esquema de base de datos compatible con versiones anteriores (p. ej., añadir nuevas columnas) con cero tiempo de inactividad.

→Implemente un patrón de expansión y contracción (o cambio paralelo). Primero, despliegue los cambios aditivos del esquema de base de datos compatibles con versiones anteriores. Segundo, despliegue la nueva versión de la aplicación que utiliza el nuevo esquema. Ambas versiones, antigua y nueva, pueden coexistir con la base de datos actualizada.

Por qué: Este patrón desacopla los despliegues de la base de datos y la aplicación, asegurando que el estado de la base de datos sea siempre compatible con las versiones antigua y nueva de la aplicación, lo que permite despliegues sin tiempo de inactividad.

Lanzar gradualmente una nueva característica a segmentos de usuarios específicos y medir el impacto en métricas de negocio (p. ej., tasa de conversión) utilizando pruebas A/B.

→Utilice Amazon CloudWatch Evidently. Cree una característica con múltiples variaciones, un lanzamiento para controlar el porcentaje de despliegue y un experimento para medir el impacto estadístico en las métricas definidas.

Por qué: Evidently es un servicio diseñado específicamente para el feature flagging y la experimentación A/B, proporcionando no solo el mecanismo de lanzamiento sino también el motor de análisis estadístico para medir el impacto.

Aplicar etiquetas obligatorias en todas las instancias EC2 en el momento del lanzamiento en toda una AWS Organization.

→Utilice una Política de Control de Servicio (SCP) que deniegue `ec2:RunInstances` a menos que las claves de etiqueta requeridas estén presentes en la solicitud.

Por qué: Control preventivo que impide la creación de recursos no conformes. Se aplica a todas las cuentas y no puede ser anulado por políticas IAM locales.

Referencia↗

Gestionar y rotar secretos (p. ej., credenciales de base de datos) utilizados por aplicaciones en múltiples cuentas sin tiempo de inactividad.

→Utilice AWS Secrets Manager con rotación automática habilitada. Otorgue acceso entre cuentas utilizando políticas basadas en recursos en el secreto.

Por qué: Secrets Manager admite estrategias de rotación sin tiempo de inactividad (alternancia de usuarios) y proporciona un intercambio seguro y nativo entre cuentas.

Desplegar automáticamente recursos de seguridad de línea base en nuevas cuentas creadas a través de Control Tower Account Factory.

→Utilice el evento de ciclo de vida de Control Tower `CreateManagedAccount` a través de EventBridge para activar una función Lambda que despliega un CloudFormation StackSet. Alternativamente, utilice Customizations for AWS Control Tower (CfCT).

Por qué: La automatización basada en eventos es el patrón estándar y escalable para extender las líneas base de Control Tower sin intervención manual después de la creación de la cuenta.

Habilitar el acceso a SSM Session Manager para instancias EC2 en una subred privada sin acceso a internet.

→Cree endpoints de interfaz de VPC (impulsados por PrivateLink) para los servicios `ssm`, `ssmmessages` y `ec2messages` en la VPC.

Por qué: Los endpoints de VPC permiten que el agente de SSM se comunique con el servicio completamente dentro de la red de AWS, proporcionando el patrón de acceso más seguro sin necesidad de una NAT o internet gateway.

Centralizar logs con retención a largo plazo y protegerlos de eliminación o modificación, incluso por administradores.

→Almacene los logs en un bucket S3 con S3 Object Lock en modo de cumplimiento. Habilite la validación de integridad de los archivos de log de CloudTrail.

Por qué: Object Lock (modo de cumplimiento) proporciona protección WORM que ni siquiera la cuenta raíz puede eludir. La validación de integridad de los archivos de log proporciona una comprobación criptográfica para la manipulación posterior a la entrega.

Proporcionar a los desarrolladores una forma de autoservicio para aprovisionar patrones de infraestructura pre-aprobados sin otorgarles permisos completos de servicios de AWS.

→Utilice AWS Service Catalog. Cree un portfolio de productos aprobados (definidos por plantillas de CloudFormation). Utilice restricciones de lanzamiento para que Service Catalog aprovisione recursos utilizando un rol IAM privilegiado gestionado por el equipo de plataforma.

Por qué: Service Catalog es el servicio de AWS diseñado específicamente para crear catálogos seleccionados de servicios de TI. Las restricciones de lanzamiento son la característica clave de gobernanza, permitiendo a los desarrolladores aprovisionar infraestructura compleja sin tener ellos mismos los permisos subyacentes.

Proporcionar de forma segura secretos únicos a diferentes microservicios que se ejecutan como tareas ECS, asegurando que cada servicio solo pueda acceder a sus propios secretos.

→Cree secretos separados de AWS Secrets Manager para cada servicio. En la definición de tarea de ECS, haga referencia a los ARN de los secretos en la propiedad `secrets` de la definición del contenedor. Limite la política de rol IAM de ejecución de tarea para permitir solo `secretsmanager:GetSecretValue` en el ARN del secreto específico de ese servicio.

Por qué: Esto impone el principio de mínimo privilegio en múltiples capas: el secreto en sí, la política IAM y la definición de tarea ECS. Los secretos se inyectan de forma segura en tiempo de ejecución.

Permitir que un flujo de trabajo de GitHub Actions acceda de forma segura a AWS sin almacenar credenciales de larga duración.

→Configure un proveedor de identidad IAM OIDC para GitHub. Cree un rol IAM con una política de confianza que restrinja al principal federado a la organización, repositorio y rama específicos de GitHub. Utilice la acción `aws-actions/configure-aws-credentials` con OIDC para asumir el rol.

Por qué: La federación OIDC es el método más seguro, ya que proporciona credenciales de corta duración con ámbito para una ejecución de flujo de trabajo específica, eliminando el riesgo de exposición de credenciales de larga duración.

Monitorear continuamente todas las políticas IAM en una AWS Organization para identificar y ser alertado sobre recursos compartidos con entidades externas.

→Habilite IAM Access Analyzer a nivel de organización, definiendo la organización como la zona de confianza. Utilice EventBridge para capturar nuevos hallazgos y activar notificaciones.

Por qué: IAM Access Analyzer está diseñado específicamente para utilizar el razonamiento automatizado para encontrar recursos compartidos externamente. Ejecutarlo a nivel de organización proporciona una vista continua y centralizada sin scripts personalizados.

Reducir el radio de impacto de las actualizaciones fallidas de CloudFormation en una arquitectura de pila monolítica o anidada.

→Descomponer la arquitectura en pilas independientes utilizando referencias entre pilas (CloudFormation Exports/Fn::ImportValue).

Por qué: Un fallo en una pila (p. ej., base de datos) no activará una reversión de otras pilas actualizadas con éxito (p. ej., redes), aislando los dominios de fallo.

Gestionar centralmente el parcheo entre cuentas con diferentes programas para entornos de producción y no producción.

→Utilice AWS Systems Manager Patch Manager con líneas base de parches personalizadas, ventanas de mantenimiento separadas para cada entorno y Systems Manager Explorer para informes centralizados de cumplimiento.

Por qué: Soporta nativamente todos los requisitos: definiciones de parches personalizadas, programación flexible a través de ventanas de mantenimiento y visibilidad entre cuentas a través de Explorer.

Previsualizar los cambios de infraestructura en todas las cuentas de destino antes de ejecutar una CloudFormation StackSet update.

→Cree y revise un conjunto de cambios de CloudFormation para la operación StackSet antes de la ejecución.

Por qué: Los conjuntos de cambios son el mecanismo nativo de CloudFormation para previsualizar los cambios exactos de recursos (agregar, modificar, eliminar) que realizará una actualización.

Asegúrese de que CloudFormation espera a que el script UserData de una instancia EC2 se complete con éxito antes de continuar con la creación de la pila.

→Agregue una `CreationPolicy` con `ResourceSignal` al recurso de instancia EC2. Llame al script auxiliar `cfn-signal` desde UserData al finalizar con éxito.

Por qué: Este es el mecanismo nativo de CloudFormation para coordinar con los scripts de configuración en un recurso. La falta de señalización dentro del tiempo de espera activa automáticamente una reversión de la pila.

Detectar cuando los cambios manuales y fuera de banda hacen que los recursos desplegados difieran de la definición de su plantilla de CloudFormation.

→Ejecute la detección de deriva de CloudFormation en la pila periódicamente. Para una detección continua, use la regla de AWS Config `cloudformation-stack-drift-detection-check`.

Por qué: La detección de deriva es la característica nativa para comparar la plantilla de una pila con el estado real de sus recursos. El uso de la regla de Config automatiza esta comprobación.

Proteger recursos con estado (p. ej., un bucket S3 o una base de datos RDS) de eliminación o reemplazo accidental a través de operaciones de pila de CloudFormation.

→En el recurso, establezca `DeletionPolicy: Retain` (o `Snapshot` para RDS). En la pila, habilite `TerminationProtection`. Aplique una `StackPolicy` que deniegue las acciones `Update:Replace` y `Update:Delete` en el recurso crítico.

Por qué: Proporciona defensa en profundidad: Termination Protection evita la eliminación de la pila, DeletionPolicy preserva el recurso si la pila se elimina, y la Stack Policy evita actualizaciones destructivas.

Migrar un CloudFormation StackSet de un modelo de rol IAM complejo y autogestionado a un modelo de permisos más simple para una AWS Organization.

→Actualice el StackSet para usar permisos gestionados por el servicio.

Por qué: Los permisos gestionados por el servicio aprovechan el acceso de confianza de Organizations, eliminando la necesidad de crear y gestionar roles IAM en cada cuenta de destino. También permite el despliegue automático en nuevas cuentas añadidas a UO objetivo.

Un recurso personalizado de CloudFormation necesita gestionar una tarea que tarda más que el tiempo de espera de 15 minutos de la función Lambda.

→Active una máquina de estados de AWS Step Functions desde la función Lambda del recurso personalizado. La máquina de estados maneja la tarea de larga duración utilizando estados de espera o el patrón Task Token y envía la respuesta de vuelta a la URL pre-firmada de S3 de CloudFormation.

Por qué: Step Functions está diseñado para orquestar flujos de trabajo de larga duración y múltiples pasos, eludiendo eficazmente la limitación de tiempo de espera de Lambda mientras mantiene la integración con CloudFormation.

Aplicar centralmente una política (p. ej., todos los buckets S3 deben tener versionado) en toda una aplicación AWS CDK, independientemente de cómo los desarrolladores definan sus recursos.

→Cree un CDK Aspect que implemente la interfaz `IAspect`. El Aspect visita todos los constructos en el árbol de la aplicación, encuentra todos los constructos de bucket S3 y aplica la configuración requerida o agrega un error de validación si falta.

Por qué: Los Aspects son el patrón oficial de CDK para aplicar preocupaciones transversales e implementar validaciones de política como código de forma centralizada sin modificar constructos individuales.

Evitar que las operaciones automatizadas, como el parcheo a través de las ventanas de mantenimiento de SSM, se ejecuten durante períodos de tiempo específicos y cambiantes (p. ej., un bloqueo financiero trimestral).

→Utilice SSM Change Calendar para definir eventos que marquen los períodos de bloqueo como "cerrados". Asocie el Change Calendar con la ventana de mantenimiento.

Por qué: Change Calendar actúa como una puerta para las automatizaciones. Bloquea automáticamente la ejecución durante los períodos "cerrados" sin requerir cambios manuales en la programación de la ventana de mantenimiento, lo que lo hace muy eficiente para gestionar períodos de bloqueo dinámicos.

Gestionar centralmente la instalación y el versionado de un paquete de software personalizado (p. ej., un agente de monitoreo) en una flota de instancias EC2.

→Empaquete el software utilizando SSM Distributor. Utilice SSM State Manager para crear una asociación que aplique el paquete de Distributor a todas las instancias objetivo.

Por qué: Distributor gestiona el ciclo de vida del paquete (incluidas las versiones). State Manager asegura que el estado deseado (p. ej., "la versión 1.2 del agente está instalada") se aplique continuamente, remediando automáticamente la deriva y configurando nuevas instancias.

Recuperación ante desastres con bajo RPO (< 1 min) y RTO (< 5 min) para una base de datos Aurora y una capa de aplicación entre regiones.

→Utilice una Aurora Global Database para la replicación de bases de datos en menos de un segundo. Para la capa de aplicación, utilice un "warm standby" con un grupo de Auto Scaling configurado a 0 de capacidad deseada, para escalar mediante automatización en caso de failover.

Por qué: Aurora Global Database proporciona un RPO de menos de un segundo y un RTO de menos de 1 minuto. La capa de aplicación en warm standby es rentable a la vez que cumple un RTO rápido.

Reducir el tiempo de escalado horizontal de los grupos de Auto Scaling para instancias que tienen largos tiempos de arranque/inicialización.

→Cree una "AMI dorada" preconfigurada con las dependencias instaladas. Configure un warm pool en el grupo de Auto Scaling para mantener las instancias preinicializadas.

Por qué: Una AMI dorada minimiza el tiempo de arranque. Un warm pool minimiza el tiempo de lanzamiento (inicio vs. lanzamiento). Juntos, reducen drásticamente el tiempo para que una nueva instancia esté lista para servir tráfico.

Un servicio ECS escala su recuento de tareas, pero no puede colocar nuevas tareas porque el clúster EC2 subyacente se ha quedado sin capacidad.

→Habilite el Auto Scaling de Clúster ECS asociando un proveedor de capacidad con el grupo de Auto Scaling de EC2 y el clúster ECS.

Por qué: Los proveedores de capacidad vinculan el escalado del servicio ECS con el escalado de instancias EC2. Cuando las tareas no se pueden colocar debido a recursos de clúster insuficientes, el proveedor de capacidad escala automáticamente el ASG de EC2.

Escalar dinámicamente una flota de instancias worker EC2 basada en el número de mensajes en una cola SQS.

→Utilice una política de Auto Scaling de seguimiento de objetivos basada en la métrica personalizada: `ApproximateNumberOfMessagesVisible` / `GroupInServiceInstances` (es decir, backlog por instancia).

Por qué: Este es el patrón recomendado para el escalado basado en SQS. Mantiene suficientes workers para procesar el backlog dentro de un tiempo objetivo, escalando eficientemente con la profundidad de la cola.

Crear instantáneas de volúmenes EBS consistentes con la aplicación (no solo consistentes con el fallo) para aplicaciones con estado.

→Utilice AWS Backup con un plan de respaldo. En el plan, use Systems Manager Run Command para ejecutar scripts previos a la instantánea para poner la aplicación en reposo (o habilite VSS para Windows).

Por qué: AWS Backup orquesta todo el proceso. Poner la aplicación en reposo (vaciar los búferes de E/S al disco) antes de la instantánea garantiza la integridad de los datos y un estado de aplicación recuperable.

Asegúrese de que los eventos críticos de una regla de EventBridge no se pierdan cuando un servicio de destino (p. ej., Lambda) no esté disponible temporalmente o esté limitado.

→En el destino de la regla de EventBridge, configure una política de reintentos (Retry Policy) (p. ej., edad máxima de 24 horas) y una cola de mensajes fallidos (Dead-Letter Queue, DLQ) utilizando una cola SQS.

Por qué: La política de reintentos maneja automáticamente los fallos transitorios. La DLQ actúa como una red de seguridad final, capturando los eventos que agotan todos los reintentos para que puedan ser reprocesados más tarde, evitando la pérdida de datos.

Activar alertas en tiempo real sobre patrones de logs específicos e incluir información contextual (p. ej., líneas de logs circundantes) en la notificación.

→Utilice un filtro de suscripción de CloudWatch Logs para transmitir eventos de logs coincidentes a una función Lambda. La función Lambda formatea y envía una notificación detallada (p. ej., a SNS o Chime).

Por qué: Los filtros de suscripción proporcionan transmisión de eventos en tiempo real. Lambda permite una lógica personalizada para extraer y formatear el contexto, algo que los filtros de métricas simples no pueden hacer.

Identificar cuellos de botella de latencia en una aplicación distribuida basada en microservicios.

→Habilite el rastreo de AWS X-Ray en los puntos de entrada (p. ej., API Gateway, ALB) y en el cómputo (p. ej., Lambda, ECS). Utilice el SDK de X-Ray para llamadas posteriores. Analice el mapa de servicios y los rastreos.

Por qué: X-Ray es el servicio de AWS diseñado específicamente para el rastreo distribuido. El mapa de servicios visualiza la cadena de llamadas y resalta los servicios con alta latencia y tasas de error.

Crear una alarma única de alto nivel que represente la salud combinada de una aplicación de varias capas para reducir el ruido de las alertas.

→Cree alarmas individuales de CloudWatch para cada capa (p. ej., tasa de 5xx de ALB, CPU de la aplicación, conexiones RDS). Luego, combínelas usando una alarma compuesta de CloudWatch con lógica OR.

Por qué: Las alarmas compuestas están diseñadas para reducir el ruido de las alarmas creando una alarma única y lógica basada en el estado de múltiples alarmas subyacentes.

Analizar petabytes de logs con consultas SQL complejas (incluyendo joins) y retenerlos durante años de manera rentable.

→Transmita logs a Amazon S3 a través de Kinesis Data Firehose. Catalogue los datos con AWS Glue. Consulte con Amazon Athena. Utilice políticas de ciclo de vida de S3 para pasar los datos a Glacier/Deep Archive para su retención a largo plazo.

Por qué: Esta es la arquitectura estándar de data lake sin servidor. Athena proporciona potentes capacidades SQL sobre datos de S3, y S3/Glacier ofrece el almacenamiento a largo plazo más rentable.

Monitorizar una métrica con patrones cíclicos predecibles (p. ej., picos diarios/semanales) y activar una alarma solo ante desviaciones genuinas del patrón.

→Configure CloudWatch Anomaly Detection en la métrica. Cree una alarma que se active cuando el valor de la métrica salga de la banda esperada por el modelo.

Por qué: La Detección de Anomalías utiliza aprendizaje automático para aprender los patrones normales de la métrica, creando una banda de umbral dinámica que se adapta a los ciclos. Esto reduce los falsos positivos de picos predecibles y mejora la relación señal/ruido.

Obtener visibilidad integral de las métricas de CPU, memoria, disco y red a nivel de contenedor para cargas de trabajo en EKS o ECS sin instalar y gestionar herramientas de terceros.

→Habilite Amazon CloudWatch Container Insights para el clúster EKS/ECS.

Por qué: Container Insights es un servicio totalmente gestionado que recopila, agrega y visualiza automáticamente métricas de rendimiento detalladas para cargas de trabajo en contenedores, proporcionando una visibilidad profunda con una sobrecarga operativa mínima.

Monitorear la disponibilidad y el rendimiento de una aplicación expuesta a internet desde la perspectiva de los usuarios finales, identificando problemas de red a nivel de ISP y geográficos.

→Habilite Amazon CloudWatch Internet Monitor para la aplicación.

Por qué: Internet Monitor aprovecha los datos de la red global de AWS para proporcionar visibilidad del "clima" de internet que afecta a sus usuarios finales, ayudando a diagnosticar problemas fuera de su entorno AWS.

Medir la experiencia de usuario real de una aplicación web mediante la recopilación de tiempos de carga de página, errores de JavaScript y otras métricas de rendimiento del lado del cliente.

→Integre el fragmento de JavaScript de CloudWatch RUM (Monitoreo de Usuario Real) en la aplicación web.

Por qué: RUM es un servicio gestionado que recopila datos de rendimiento y errores del lado del cliente directamente de los navegadores de los usuarios, proporcionando una visión real de la experiencia del usuario sin pruebas sintéticas.

Emitir métricas de aplicación personalizadas desde una función AWS Lambda con alta resolución y dimensiones, sin añadir la latencia y el coste de las llamadas directas a la API de CloudWatch.

→Utilice el Formato de Métrica Incrustada (EMF) de CloudWatch escribiendo JSON especialmente estructurado en la salida estándar. Una biblioteca cliente puede simplificar esto.

Por qué: CloudWatch Logs extrae métricas de las entradas de log EMF de forma automática y asíncrona, sin incurrir en latencia adicional en la función Lambda y reduciendo costes al evitar llamadas a la API PutMetricData.

Remediar automáticamente volúmenes EBS sin cifrar detectados por AWS Config, asegurando la coherencia de los datos durante el proceso.

→Utilice la auto-remediación de AWS Config con un documento de automatización de Systems Manager. El runbook detiene la instancia, crea una copia cifrada del volumen, intercambia los volúmenes y reinicia la instancia.

Por qué: SSM Automation proporciona un flujo de trabajo robusto, de varios pasos y auditable. Detener la instancia es fundamental para garantizar una instantánea consistente en los datos antes de crear la copia cifrada.

Ejecutar experimentos controlados de ingeniería del caos (p. ej., inyectar latencia de red) con condiciones de detención automáticas para evitar impactos en producción.

→Utilice AWS Fault Injection Simulator (FIS) con una plantilla de experimento. Defina condiciones de detención basadas en alarmas de CloudWatch que supervisan las métricas clave de la aplicación.

Por qué: FIS es el servicio de AWS diseñado específicamente para la ingeniería del caos, proporcionando barreras de seguridad (condiciones de detención) y un catálogo de acciones controladas de inyección de fallos.

Una pila de CloudFormation está atascada en el estado `UPDATE_ROLLBACK_FAILED` porque un recurso fue eliminado o cambiado durante una actualización fallida, impidiendo una reversión limpia.

→Utilice la acción de API `ContinueUpdateRollback`, especificando el ID lógico del recurso problemático en el parámetro `ResourcesToSkip`.

Por qué: Este es el procedimiento de recuperación estándar para forzar la finalización de la reversión indicándole a CloudFormation que ignore el recurso que ya no puede gestionar, devolviendo la pila a un estado estable.

Recibir notificaciones a los pocos minutos de producirse eventos de seguridad críticos, como un inicio de sesión de cuenta raíz, cambios de política IAM o modificaciones de grupos de seguridad.

→Cree reglas de Amazon EventBridge que coincidan con patrones específicos de eventos de gestión de CloudTrail y diríjalas a un tema de SNS para notificación.

Por qué: EventBridge recibe eventos de gestión de CloudTrail en tiempo casi real, proporcionando la latencia más baja para alertas de seguridad basadas en eventos en comparación con métodos de sondeo o basados en logs.

Una función Lambda de alto tráfico está siendo limitada y también está agotando las conexiones a la base de datos RDS cuando escala.

→Solicite un aumento del límite de ejecución concurrente de Lambda. Implemente Amazon RDS Proxy entre las funciones Lambda y la base de datos RDS.

Por qué: El aumento de la concurrencia resuelve la limitación. RDS Proxy es esencial para las aplicaciones sin servidor, ya que agrupa y reutiliza las conexiones a la base de datos, evitando que la base de datos se vea sobrecargada por un gran número de conexiones efímeras.

Implementar failover DNS automatizado entre regiones y activar un runbook de recuperación automatizado para la región fallida.

→Utilice el enrutamiento de failover de Route 53 con comprobaciones de salud asociadas. Cree una regla de EventBridge que capture el evento de cambio de estado de la comprobación de salud de Route 53 y active un runbook de automatización de Systems Manager.

Por qué: Esta arquitectura combina el failover de tráfico automatizado (Route 53) con la respuesta automatizada a incidentes basada en eventos (EventBridge + SSM Automation) para un patrón de resiliencia completo.

Evitar que una base de datos RDS se quede sin almacenamiento y cause una interrupción de la aplicación.

→Habilite el autoescalado de almacenamiento de RDS (RDS Storage Autoscaling) estableciendo un umbral máximo de almacenamiento. Como control secundario, cree una alarma de CloudWatch en la métrica `FreeStorageSpace`.

Por qué: El autoescalado de almacenamiento es una característica proactiva y gestionada que aumenta automáticamente el almacenamiento asignado. La alarma de CloudWatch proporciona una red de seguridad para la supervisión y las alertas.

Necesidad de reprocesar un lote de eventos que fueron procesados incorrectamente debido a un error temporal en un consumidor.

→Configure previamente un EventBridge Archive en el bus de eventos. Después de corregir el error, cree un Replay para reenviar eventos desde la ventana de tiempo específica del incidente.

Por qué: Archive and Replay es la característica nativa de EventBridge para almacenar y reprocesar eventos históricos, crucial para la recuperación de fallos de procesamiento transitorios.

Automatizar todo el proceso de respuesta a incidentes: crear un incidente, involucrar al equipo de guardia, abrir un canal de chat y ejecutar un runbook de remediación cuando se dispara una alarma crítica.

→Cree un plan de respuesta de SSM Incident Manager que defina todos los pasos de interacción y remediación. Configure la alarma de CloudWatch para que active este plan de respuesta como su acción.

Por qué: Los planes de respuesta proporcionan una configuración única y cohesiva para orquestar todos los aspectos de la respuesta a incidentes, reduciendo el esfuerzo manual y asegurando procedimientos consistentes.