Una referencia escaneable de patrones arquitectónicos que evalúa el examen SAA-C03. Lee de arriba a abajo o salta a una sección.
Diseñar Arquitecturas Seguras
Aplicación de tres capas: web, aplicación, base de datos. La base de datos debe ser inalcanzable desde internet bajo cualquier circunstancia.
Subredes públicas para la capa web (ALB). Subredes privadas para las capas de aplicación y base de datos. El grupo de seguridad de la base de datos solo permite tráfico desde el grupo de seguridad de la capa de aplicación (no desde rangos CIDR).
Por qué: Las tablas de enrutamiento de subredes imponen la accesibilidad; las referencias de grupo de seguridad a grupo de seguridad codifican el principio de mínimo privilegio en la capa de SG y sobreviven a los cambios de IP.
Una instancia EC2 necesita acceder a S3. Evitar credenciales incrustadas.
Rol de IAM adjunto mediante perfil de instancia. El SDK recupera credenciales temporales de IMDSv2.
Por qué: Las claves de acceso de larga duración en las instancias son la causa principal de las filtraciones de credenciales. Los roles rotan automáticamente y nunca se persisten.
Bloquear ataques SSRF que intentan leer metadatos de instancias EC2.
Forzar IMDSv2 (`HttpTokens=required`) en el lanzamiento de la instancia. Rechazar solicitudes no autenticadas de IMDSv1.
Por qué: IMDSv2 requiere un token de sesión mediante PUT antes de que el endpoint de metadatos responda; los ataques SSRF que solo realizan GETs son bloqueados.
El Servicio A en la Cuenta A invoca una función Lambda en la Cuenta B. Mínimo privilegio.
Política basada en recursos en la función Lambda de destino que otorga `lambda:InvokeFunction` al principal de rol de la Cuenta A. El llamante asume su propio rol e invoca directamente, sin necesidad de encadenamiento de roles.
Por qué: Las políticas de recursos son el patrón entre cuentas más simple para recursos con interfaz de servicio (Lambda, S3, SNS, SQS, KMS).
Otras cuentas de AWS necesitan cargar a un bucket S3 central.
Política de bucket que otorga `s3:PutObject` a los principales de cuentas externas. Añadir el requisito de ACL `bucket-owner-full-control` para que el propietario del bucket conserve el control de los objetos.
Por qué: Sin `bucket-owner-full-control` (o `BucketOwnerEnforced` Object Ownership), los objetos cargados son propiedad de la cuenta del escritor.
Evitar que cualquier bucket S3 de la organización se haga público.
Habilitar el Bloqueo de Acceso Público de S3 a nivel de cuenta (y a nivel de Organizaciones mediante SCPs). Sobreescribe las ACLs y políticas a nivel de bucket.
Por qué: La configuración a nivel de cuenta prevalece sobre las configuraciones por bucket, una defensa contra la mala configuración accidental.
Los desarrolladores deben autoaprovisionar roles de IAM pero no pueden otorgar permisos más allá de un conjunto de permisos máximo definido.
Límites de permisos en el principal del desarrollador. Permisos efectivos = política de identidad ∩ límite.
Por qué: Los SCPs se aplican a nivel de cuenta/OU; los límites delimitan a los principales individuales. Usar límites para patrones de administración delegada.
Restringir una OU a Regiones específicas para el cumplimiento de la residencia de datos.
Política de Control de Servicios en Organizations que deniega cualquier acción donde `aws:RequestedRegion` no esté en la lista permitida.
Por qué: Los SCPs son el único mecanismo que puede denegar acciones que la propia cuenta permite. IAM no puede denegar lo que una raíz de cuenta podría conceder.
Inicio de sesión único para la fuerza laboral en varias cuentas de AWS; integración con IdP corporativo.
AWS IAM Identity Center (anteriormente AWS SSO) con federación SAML/OIDC al IdP corporativo. Los conjuntos de permisos se asignan a roles en las cuentas miembro.
Por qué: Identity Center es la identidad canónica de la fuerza laboral multi-cuenta. Cognito es para usuarios finales de aplicaciones, no para empleados.
User Pool = registro / inicio de sesión / emisión de JWT para usuarios de aplicaciones. Identity Pool = intercambio de tokens por credenciales temporales de AWS. La mayoría de las aplicaciones usan ambos: User Pool autentica, Identity Pool autoriza el acceso a AWS.
Necesidad de control total sobre la rotación, eliminación de claves y la pista de auditoría por clave.
Clave KMS administrada por el cliente (CMK). Las claves administradas por AWS (`aws/<service>`) son más sencillas pero no ofrecen control de políticas de clave ni visibilidad sobre el uso individual de la clave.
Por qué: Las CMKs permiten delimitar el acceso por clave en CloudTrail, establecer políticas de clave para uso entre cuentas y deshabilitar/programar la eliminación.
La Cuenta B necesita descifrar objetos S3 cifrados con la CMK de la Cuenta A.
La política de clave en la CMK otorga `kms:Decrypt` a los principales de la Cuenta B. El IAM de la Cuenta B también necesita `kms:Decrypt` en el ARN de la clave. Ambas partes son necesarias.
Por qué: KMS entre cuentas requiere un permiso explícito tanto en la política de clave como en la identidad IAM del llamante (a diferencia de la mayoría de las políticas de recursos).
Cifrar objetos grandes sin que las llamadas a la API de KMS por objeto dominen el costo.
Cifrado de sobre (Envelope encryption). KMS genera una clave de datos (una llamada a la API); usar la clave de datos para cifrar la carga útil localmente; almacenar la clave de datos cifrada junto con el texto cifrado.
Por qué: KMS está limitado por tasa y se cobra por solicitud. El patrón de sobre es la forma canónica de cifrar datos > unos pocos KB.
Elegir entre Secrets Manager y SSM Parameter Store SecureString.
Credenciales de base de datos con rotación automática, compartición entre cuentas, secretos grandes → Secrets Manager. Flags de configuración, ajustes de aplicación, secretos simples, costo más bajo → SSM Parameter Store.
Por qué: Secrets Manager tiene Lambdas de rotación incorporadas para RDS/Aurora/DocumentDB/Redshift; Parameter Store no tiene rotación nativa pero es gratuito para el nivel Estándar.
Rotar la contraseña de RDS automáticamente cada 30 días.
Secrets Manager con rotación administrada. La plantilla de Lambda incorporada maneja la rotación de un solo usuario contra el endpoint de RDS. Las aplicaciones obtienen el secreto en el momento de la conexión (cacheado) - no hay reimplementación de la aplicación.
Mitigar inundaciones HTTP de Capa 7 sin bloquear picos legítimos.
Regla basada en tasas de AWS WAF (por ejemplo, 2000 solicitudes / 5 minutos por IP) en el ALB o CloudFront. Combinar con grupos de reglas gestionados para IPs conocidas como maliciosas.
Por qué: Las reglas de tasa de WAF rastrean por IP de origen; bloquean automáticamente cuando se excede el umbral; liberan después de la ventana.
Aplicación de misión crítica necesita protección de costos DDoS y soporte SRT 24×7.
AWS Shield Advanced en CloudFront / ALB / NLB / Global Accelerator. Incluye protección de costos (reembolsos por el gasto de escalado durante un ataque) + acceso al Equipo de Respuesta de Shield.
Por qué: Shield Standard es automático y gratuito; Advanced añade protecciones y SLA. CloudFront siempre es la puerta principal recomendada.
Con estado, adjuntar a ENI, solo permitir → grupo de seguridad (predeterminado). Sin estado, a nivel de subred, permitir + denegar explícitamente → NACL. Usar NACLs para reglas de denegación general (bloquear rangos IP); SGs para todo lo demás.
Por qué: Las NACLs evalúan el tráfico entrante y saliente por separado. Los SGs permiten automáticamente el tráfico de retorno.
Una instancia EC2 en una subred privada debe alcanzar S3/DynamoDB sin el costo de salida de NAT.
Endpoint de puerta de enlace de VPC para S3 y DynamoDB. Gratuito, entrada en tabla de rutas, sin NAT.
Por qué: Los endpoints de puerta de enlace son solo para S3/DynamoDB. Ahorra cargos de procesamiento de datos de NAT y mantiene el tráfico en la red troncal de AWS.
Una subred privada debe alcanzar las APIs de servicios de AWS (KMS, Secrets Manager, ECR, etc.) de forma privada.
Endpoint de interfaz de VPC (PrivateLink) por servicio. ENI en su VPC, con cargo por hora + por GB.
Por qué: Los endpoints de interfaz funcionan para casi todos los servicios de AWS. Úselos para eliminar la salida de NAT para las llamadas a servicios.
Un proveedor SaaS expone su servicio en-VPC a cuentas de clientes de forma privada, sin emparejamiento de VPC ni mantenimiento de enrutamiento del cliente.
Servicio de endpoint de AWS PrivateLink respaldado por un NLB. Los clientes crean endpoints de interfaz para consumir.
Por qué: Sin preocupaciones de superposición de CIDR, sin mallado de peering, exposición unidireccional (el proveedor no ve el tráfico del cliente).
Conectividad híbrida que necesita ancho de banda predecible, baja latencia y cifrado.
Direct Connect con una VPN Site-to-Site sobre el DX (MACsec o IPsec). DX por sí solo no está cifrado; VPN sobre DX es privado + cifrado + baja fluctuación.
Por qué: Una VPN simple sobre internet es barata pero tiene latencia variable. DX por sí solo es rápido pero en texto claro a nivel de capa de enlace.
Asegurar que todos los volúmenes EBS estén cifrados; remediar automáticamente los recursos no conformes.
Reglas de AWS Config (administradas `encrypted-volumes`) + runbook de automatización de Systems Manager para remediación, activado a través de la acción de remediación de Config.
Registro de auditoría único e inalterable en todas las cuentas de la organización.
Trail de organización con validación de archivos de registro habilitada, escrito en un bucket S3 central con política de bucket que deniega la eliminación.
Por qué: Los trails de organización se habilitan automáticamente en todas las cuentas miembro (actuales y futuras). Los hashes de validación demuestran que los registros no fueron modificados.
Carga de trabajo PCI DSS - aislamiento estricto de cuentas no PCI.
Cuenta de AWS dedicada dentro de una OU de Organizations con SCPs que restringen el acceso a servicios/regiones. VPC, claves KMS, roles IAM separados. Network Firewall o GWLB para inspección de salida.
Por qué: El límite de cuenta es el aislamiento de radio de explosión más fuerte en AWS de AWS.
Certificado TLS público para `*.example.com` en ALB y CloudFront. Renovar automáticamente.
Certificado público de AWS Certificate Manager (ACM) con validación DNS en Route 53. Se renueva automáticamente 60 días antes de la caducidad.
Por qué: Gratuito para usar con servicios integrados de AWS. La validación por correo electrónico funciona, pero la validación DNS se prefiere para la automatización.
Base de datos RDS de producción con conmutación por error en menos de un minuto.
Implementación Multi-AZ de RDS (o clúster de base de datos Multi-AZ). Replicación síncrona a la instancia en espera; conmutación por error automática mediante cambio de endpoint DNS.
Por qué: Multi-AZ es para alta disponibilidad, no para escalado de lecturas. Las réplicas de lectura son para escalar lecturas (y asíncronas; posible retraso).
Elegir Aurora o RDS para una nueva carga de trabajo MySQL/PostgreSQL.
Aurora para mayor rendimiento, conmutación por error más rápida, hasta 15 réplicas de lectura, Global Database, Serverless v2. RDS para motores más antiguos (MariaDB, Oracle, SQL Server) o implementaciones más sencillas/baratas.
Por qué: El almacenamiento de Aurora se comparte entre réplicas (sin retraso de réplica por almacenamiento). Conmutación por error típica < 30s.
Base de datos multirregional activo-pasivo con un retraso de replicación < 1s y un RTO < 1 minuto.
Aurora Global Database. Replicación a nivel de almacenamiento a hasta 5 Regiones secundarias; promover una secundaria a primaria en caso de desastre.
Por qué: La replicación utiliza infraestructura dedicada; el retraso entre Regiones suele ser < 1s. Réplicas de lectura en Regiones remotas para lecturas locales de baja latencia.
Enrutar el tráfico a la Región primaria; conmutar por error a la secundaria en caso de fallo de la comprobación de estado.
Política de enrutamiento de conmutación por error de Route 53. Comprobación de estado activa en el endpoint primario; el registro secundario sirve cuando el primario no está saludable.
Por qué: La comprobación de estado a nivel de aplicación (ruta HTTP) detecta fallos parciales que los sondeos TCP no detectan.
Enviar cada usuario a la Región saludable con la latencia más baja.
Enrutamiento basado en latencia de Route 53. Comprobar la salud de cada endpoint; Route 53 devuelve la respuesta saludable de menor latencia por consulta.
Al reducir la escala, drenar el trabajo en curso y persistir los registros antes de que la instancia termine.
Hook de ciclo de vida de Auto Scaling en `Terminating:Wait`. El hook publica en SNS/EventBridge; el manejador completa el drenaje y llama a `complete-lifecycle-action`.
Reducir el costo de computación en una flota no crítica que tolera interrupciones.
ASG con política de instancias mixtas: capacidad base bajo demanda (On-Demand), capacidad adicional en Spot, múltiples tipos de instancia y AZs para diversificación.
Por qué: La diversificación entre tipos de instancia reduce el riesgo de interrupción de Spot en comparación con un pool único.
HTTP/HTTPS, enrutamiento por ruta/host, integración con WAF, autenticación OIDC → ALB. TCP/UDP/TLS a escala extrema, IP estática por AZ, menor latencia, preservar IP de origen del cliente → NLB.
Insertar una flota de dispositivos de seguridad de terceros en línea para la inspección de tráfico entre VPCs.
Gateway Load Balancer (GWLB) con flota de dispositivos como destinos. Tráfico encapsulado a través de GENEVE; inserción transparente mediante enrutamiento.
Los mensajes "envenenados" siguen haciendo fallar a los manejadores y se vuelven a encolar.
Cola de mensajes fallidos (Dead-Letter Queue) de SQS. Configurar `maxReceiveCount` en la cola de origen; los mensajes que exceden el recuento se mueven a la DLQ para inspección.
Lambda asíncrona falla por tiempo de espera en el downstream - capturar eventos fallidos para reintentar.
Destinos de Lambda: configurar el destino de fallo como SQS / SNS / EventBridge / otra Lambda. También se admiten destinos de éxito.
Por qué: Más limpio que una DLQ en la función: los destinos obtienen la carga útil completa del evento + respuesta; las DLQ solo obtienen el evento de activación.
Un flujo de trabajo de múltiples pasos necesita reintento por tarea con retroceso exponencial y captura de errores.
Flujo de trabajo estándar de AWS Step Functions. Bloque `Retry` con `IntervalSeconds`, `MaxAttempts`, `BackoffRate`. Bloque `Catch` que enruta errores específicos a un estado de recuperación.
El origen de CloudFront (S3 o ALB) falla - recurrir a un origen secundario sin cambios de DNS.
Grupo de origen de CloudFront con primario + secundario. Configurar criterios de conmutación por error (códigos 4xx/5xx). CloudFront reintenta contra el secundario.
Centralizar copias de seguridad en EBS, RDS, DynamoDB, EFS, FSx con una única política de retención.
AWS Backup con planes de copia de seguridad + selección de recursos por etiqueta. Se admite la copia entre cuentas / entre Regiones. Vault Lock para inmutabilidad de cumplimiento.
Proteger objetos S3 de la eliminación accidental y la sobreescritura por ransomware.
Habilitar el Versionado de S3 + Eliminación MFA + Bloqueo de Objetos (modo de gobernanza o cumplimiento) en buckets críticos.
Por qué: El versionado preserva las sobreescrituras/eliminaciones; el Bloqueo de Objetos bloquea la eliminación antes de la retención; la Eliminación MFA añade un segundo factor para la eliminación permanente.
Una aplicación global necesita una conmutación por error con RTO cero entre dos Regiones.
Activo-activo entre Regiones: Global Accelerator o enrutamiento por latencia de Route 53 para el ingreso; DynamoDB Global Tables / Aurora Global Database para los datos; replicación entre Regiones para almacenes de objetos.
Acceso frecuente → Standard. Patrón de acceso desconocido → Intelligent-Tiering. Infrecuente de más de 30 días → Standard-IA. Zona única aceptable, infrecuente → One Zone-IA. Archivo, recuperación en ms → Glacier Instant. Archivo, minutos → Glacier Flexible. Archivo, horas, más barato → Glacier Deep Archive.
Propósito general, predeterminado → gp3 (3000 IOPS base, 125 MB/s; ajustable). Base de datos de alto IOPS → io2 Block Express. Rendimiento secuencial de big data → st1. Archivo frío → sc1. Volúmenes de arranque → gp3.
Por qué: gp3 desacopló IOPS/rendimiento del tamaño; más barato que gp2 con rendimiento equivalente.
Múltiples instancias EC2 deben leer y escribir el mismo volumen de bloque.
EBS Multi-Attach con io2 / io1 (solo instancias Nitro). Adjuntar concurrentemente hasta 16 instancias en la misma AZ.
Por qué: La aplicación debe coordinar las escrituras (sistema de archivos en clúster). EFS es el predeterminado para el acceso a archivos compartidos; Multi-Attach es para bases de datos en clúster que necesitan bloques.
NFS Linux compatible con POSIX, multi-AZ, autoescalado → EFS. SMB Windows / integrado con AD → FSx for Windows. HPC, Lustre, vinculado a S3 → FSx for Lustre. Características de NetApp ONTAP (instantáneas, herramientas de NetApp) → FSx for ONTAP. ZFS → FSx for OpenZFS.
Carga de trabajo variable, escala con el tamaño → Bursting. Alto rendimiento predecible → Provisioned. Sensible a ráfagas pero desea gasto elástico → Elastic (predeterminado para nuevos sistemas de archivos, escala automáticamente).
Activos estáticos + respuestas de API con usuarios globales; reducir la carga del origen.
CloudFront con la política de caché adecuada. TTLs largos para estáticos; la clave de caché incluye solo encabezados/cadenas de consulta esenciales. Usar Origin Shield para orígenes de alta cardinalidad.
Por qué: La tasa de aciertos de caché impulsa tanto el rendimiento como el costo. Una clave de caché incorrecta (por ejemplo, incluir todos los encabezados) destruye la tasa de aciertos.
Ligero, lado del espectador, sub-ms (reconfiguraciones de encabezado, redireccionamientos, A/B) → CloudFront Functions. Más pesado, Node.js / Python, cómputo más largo, acceso a la red → Lambda@Edge.
Carga perezosa (fallo de caché → buscar + poblar): simple, solo almacena en caché lo solicitado. Escritura directa (escribir en caché + DB al actualizar): caché siempre fresca, pero escrituras adicionales. TTL: limita la obsolescencia en cualquiera de los patrones.
Basado en eventos de menos de 15 minutos, escala en sub-segundos, sin infraestructura → Lambda. Contenedores de larga ejecución, sin gestión de nodos → Fargate. Kernel personalizado, GPU, estado persistente, más barato sostenido → EC2.
El arranque en frío de Lambda Java está afectando la latencia p99.
Lambda SnapStart (Java, Python, .NET). Instantánea del tiempo de ejecución inicializado restaurada en la invocación; arranque en frío hasta 10 veces más rápido.
Carga de ráfaga predecible; arranques en frío inaceptables.
Concurrencia aprovisionada. Entornos precalentados listos para invocar a cualquier rendimiento. Combinar con Application Auto Scaling para escalado programado.
Por qué: Cuesta más que el modo bajo demanda pero elimina el arranque en frío. No es necesario para tráfico constante donde la utilización de la concurrencia aprovisionada se mantiene alta de forma natural.
Conjunto completo de características (validación de solicitudes, transformaciones, claves API, planes de uso) → API REST. Menor costo, menor latencia, JWT/OIDC nativo, más simple → HTTP API. Bidireccional en tiempo real → WebSocket API.
Elegir entre Kinesis Data Streams, Firehose, Managed Service for Apache Flink o MSK.
Consumidores personalizados, latencia de ms, retransmisión, fan-out de múltiples consumidores → Data Streams. Simplemente entregar a S3/Redshift/OpenSearch con búfer → Firehose. Procesamiento de streams (ventanas, uniones) → Managed Service for Apache Flink. Compatible con Kafka → MSK.
Las consultas de Athena escanean terabytes; costo / tiempo excesivo.
Particionar los datos por predicado de consulta (fecha, región). Convertir a formato columnar Parquet/ORC. Usar proyección de particiones para evitar viajes de ida y vuelta al catálogo.
Por qué: Athena cobra por TB escaneado. Columnar + particionado a menudo reduce el costo 10-100 veces.
Cargas de trabajo impredecibles / con picos / nuevas → Bajo demanda (On-demand). Constantes, predecibles, intensivas - y sensibles al costo → Aprovisionado con autoescalado. Cambiar de modo como máximo una vez cada 24 horas.
Consultar DynamoDB por un atributo que no es la clave de partición.
Índice Secundario Global (GSI) para consultas sobre una clave de partición diferente. Índice Secundario Local (LSI) para una clave de ordenación alternativa en la misma clave de partición (el LSI debe crearse en el momento de crear la tabla).
Elegir opción de compra de EC2 para una flota estable 24×7.
Compute Savings Plan (1 o 3 años) - 66% de descuento sobre el precio de lista, flexible entre familias de instancias, tamaño, SO, tenancy, Región. RIs solo cuando necesite reserva de capacidad.
Por qué: Los Savings Plans dominan a las RIs para la mayoría de los casos de uso solo por costo (más flexibles, mismo descuento).
Elegir entre Compute Savings Plan, EC2 Instance Savings Plan o SageMaker Savings Plan.
Compute SP: máxima flexibilidad (cubre EC2, Fargate, Lambda) - el mejor valor predeterminado. EC2 Instance SP: bloqueado por familia, mayor descuento. SageMaker SP: solo para SageMaker.
Usar Spot para ahorrar costos en cargas de trabajo tolerantes.
Spot a través de política de instancias mixtas de ASG con estrategia de asignación optimizada por capacidad + múltiples tipos de instancia. Manejar aviso de interrupción de 2 minutos a través de metadatos de instancia.
Por qué: capacity-optimized elige pools con menor probabilidad de ser recuperados. Múltiples tipos diversifican el riesgo del pool.
Reducir el costo de cómputo sin reescribir la arquitectura.
Migrar a instancias Graviton (ARM64). ~20% más baratas, ~40% mejor relación precio-rendimiento para muchas cargas de trabajo. Requiere imágenes de contenedor multi-arquitectura o binarios recompilados.
Establecer la arquitectura en `arm64` (Graviton). 20% más barato por ms que x86, a menudo más rápido. Requiere dependencias nativas compatibles con la arquitectura.
Costo de Lambda demasiado alto; runtime limitado por CPU.
Aumentar la memoria (lo que escala la CPU y la red proporcionalmente). Usar Lambda Power Tuning (herramienta de Step Functions) para encontrar el punto óptimo - a menudo, más memoria es más rápida Y más barata.
Registros y objetos antiguos se acumulan en S3 Standard.
Reglas de ciclo de vida de S3: transición a IA después de 30 días, Glacier Flexible después de 90 días, Deep Archive después de 180 días, expirar después de la retención. Combinar con Intelligent-Tiering para patrones desconocidos.
Visualizar el gasto de S3 en todas las cuentas; encontrar candidatos de optimización.
S3 Storage Lens. Panel a nivel de organización con uso, actividad y recomendaciones de ahorro de costos. Nivel de métricas avanzadas para desglose a nivel de prefijo.
Las tarifas de procesamiento de datos de NAT Gateway dominan la factura.
Reemplazar el tráfico de servicios de AWS con VPC Endpoints (gateway para S3/DynamoDB; interfaz para todo lo demás). Mover las cargas de trabajo que necesitan salida a internet a subredes públicas solo cuando sea necesario.
Por qué: NAT Gateway cobra por GB procesado incluso para el tráfico de servicios de AWS. Los Endpoints eliminan esa ruta.
Misma AZ, misma VPC = gratis. Entre AZs = $0.01/GB por cada sentido. Entre Regiones = caro. Salida a internet = lo más caro, pero gratis a través de CloudFront para contenido cacheable. Siempre salir a través de CloudFront cuando sea posible.
Establecer retención explícita (el valor predeterminado es "Nunca expirar"). Exportar registros antiguos a S3 + Glacier. Usar Logs Insights solo en datos cálidos. Filtrar en el agente (no enviar registros de depuración en producción).
Encontrar candidatos de dimensionamiento correcto en EC2, Auto Scaling Groups, EBS, Lambda.
AWS Compute Optimizer. Lee métricas de CloudWatch + ML, recomienda reducir tamaño o cambiar de familia. Gratuito para activación a nivel de organización.
Detectar picos de gasto inesperados de forma proactiva.
Detección de Anomalías de Costos de AWS (dentro de Cost Explorer). Monitores basados en ML por servicio / cuenta vinculada / categoría de costos. Alertas vía SNS / correo electrónico.
Detener el gasto descontrolado en una cuenta sandbox.
AWS Budgets con acción: al umbral del 80%, ejecutar una notificación SNS; al 100%, adjuntar una política SCP / IAM de denegación a través de Acciones de Budgets.
Imputación de costos por equipo o producto sin cuentas separadas.
Etiquetas de asignación de costos. Activar etiquetas definidas por el usuario en la consola de facturación; aparecerán en Cost Explorer + CUR. Combinar con `aws:CreatedBy` para atribución de identidad.
Instancias EC2 de desarrollo/prueba ejecutándose 24×7 - solo se usan de 9 a 5.
AWS Instance Scheduler (Lambda desplegada con CloudFormation). Etiquetar instancias con nombres de programación; ejecuta inicio/parada tipo cron. O simplemente `aws:autoscaling:scheduledActions` en ASGs de desarrollo.
Por qué: ~70% de reducción en el gasto de cómputo de desarrollo con la parada fuera del horario laboral.
Instancia RDS de desarrollo inactiva por las noches/fines de semana.
Detener la instancia RDS (AZ única; hasta 7 días, luego se inicia automáticamente). O Aurora Serverless v2 con ACU mínima = 0.5 (sin parada completa, pero costo mínimo cuando está inactivo).
Optimización de costos de la flota de contenedores.
Utilización constante y alta → ECS en EC2 (con Spot/Savings Plans) - el más barato. Con picos / de corta duración / sin gestión de nodos → Fargate. Fargate Spot tiene un 70% de descuento sobre Fargate para cargas de trabajo tolerantes.
Poner CloudFront delante. La transferencia del origen al edge es gratuita; del edge al usuario es más barata que la salida directa de EC2/S3 a escala. Habilitar compresión + TTLs adecuados.
Agente de AWS DataSync on-prem; transferencia programada a S3. Cifrado, comprobación de integridad, limitado por tasa. Snowball Edge para 100 TB+ o bajo ancho de banda.
Mover > 1 PB de on-prem a AWS; ancho de banda demasiado lento para transferencia online.
Familia AWS Snow. Snowball Edge Storage Optimized (80 TB) para lo típico; múltiples dispositivos en paralelo para cientos de TB. Snowmobile está retirado - usar múltiples Snowball para escala de petabytes.
RDS / ElastiCache / OpenSearch / Redshift de producción funcionando 24×7.
Instancias Reservadas para bases de datos administradas (no hay equivalente de Savings Plan para estos servicios). 1 año o 3 años; el pago parcial por adelantado suele ser el mejor VPN.
Victorias rápidas y de bajo esfuerzo en costos en toda la cuenta.
Comprobaciones de costos de AWS Trusted Advisor: balanceadores de carga inactivos, EC2 de baja utilización, EBS no adjuntos, RDS subutilizados, Redshift inactivo. El nivel gratuito es limitado; el conjunto completo con soporte Business / Enterprise.