🏠Inicio 📚Certificaciones 📱Aplicaciones Móviles

🎓Información del examen

✍️Blog 📊Progreso 📅Calendario 💬Soporte

Política de Privacidad Términos de Uso Contáctenos Política de Cookies Aviso Legal Accesibilidad DMCA / Derechos de Autor

Ir al contenido

SAA-C03Guía

Guía

AWS Certified Solutions Architect Associate

Última revisión: mayo de 2026

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.

Secciones

Diseñar Arquitecturas Seguras34 entradas
Diseñar Arquitecturas Resilientes28 entradas
Diseñar Arquitecturas de Alto Rendimiento26 entradas
Diseñar Arquitecturas Optimizadas en Costos24 entradas

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.

Elegir entre Cognito User Pool e Identity Pool.

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.

Añadir un paso de validación personalizado al inicio de sesión de Cognito (por ejemplo, lista de dominios de correo permitidos).

Disparadores Lambda: Pre-registro, Pre-autenticación, Definir/Crear/Verificar Desafío de Autenticación. Validar o rechazar en la función Lambda.

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 datos en `us-east-1`; descifrar en `us-west-2` después de la replicación, sin volver a cifrar.

Clave KMS multirregional. Primaria en una Región, réplica en otra, ambas con el mismo material de clave e ID.

Por qué: Evita la repetición del cifrado para la conmutación por error o la DR entre Regiones.

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.

Elegir entre grupo de seguridad y NACL.

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).

Conectar más de 30 VPCs entre cuentas y on-premises en una topología de hub-and-spoke.

AWS Transit Gateway. Un solo adjunto por VPC; las tablas de enrutamiento segmentan el tráfico.

Por qué: El emparejamiento de malla completa requiere N×(N-1)/2 conexiones. TGW escala linealmente y soporta el acceso entre cuentas a través de RAM.

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.

Detección continua de amenazas en VPC Flow Logs, DNS, CloudTrail, auditoría de EKS, eventos de datos de S3.

Amazon GuardDuty. A nivel de organización a través de la administración delegada de Organizations.

Por qué: Detección de amenazas gestionada. Hallazgos en Security Hub o EventBridge para automatización de respuestas.

Descubrir y clasificar PII / PHI en buckets S3.

Amazon Macie. Descubrimiento de datos sensibles basado en ML, con ámbito en S3, se integra con Security Hub.

Escaneo continuo de CVE para instancias EC2, imágenes ECR, funciones Lambda.

Amazon Inspector v2. Descubre recursos automáticamente mediante Systems Manager Agent, escanea contra CVEs publicados.

Agregar hallazgos de GuardDuty, Inspector, Macie, IAM Access Analyzer en un único panel.

AWS Security Hub. CSPM con las mejores prácticas de seguridad fundamentales de AWS y estándares CIS.

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.

Varios departamentos necesitan acceso delimitado a diferentes prefijos en un bucket S3 compartido.

Puntos de acceso de S3 — uno por departamento, cada uno con su propia política de acceso y (opcionalmente) restricción de VPC.

Por qué: Más limpio que una política de bucket extensa; los puntos de acceso tienen sus propios ARNs y nombres DNS.

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.

Diseñar Arquitecturas Resilientes

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.

Carga de base de datos variable/impredecible con períodos de inactividad.

Aurora Serverless v2. Escala en incrementos de 0.5 ACU; eventos de escala en sub-segundos; no hay pausa total pero un mínimo muy bajo.

Por qué: La v2 mantiene la conexión abierta durante los eventos de escala (a diferencia de la v1). Pago por ACU-segundo.

Lecturas + escrituras de un solo dígito de ms en 3+ Regiones, con replicación "el último escritor gana".

DynamoDB Global Tables. Replicación multi-activa con resolución de conflictos "el último escritor gana".

Por qué: Activo-activo en cada Región; sin líder. Usar cuando la tolerancia a conflictos a nivel de aplicación es aceptable.

Recuperar una tabla de DynamoDB a un punto específico en los últimos 35 días después de una eliminación accidental.

Habilitar la recuperación de point-in-time (PITR). La restauración crea una nueva tabla en el segundo elegido.

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.

Despliegue canary: enviar 10% a v2, 90% a v1.

Enrutamiento ponderado de Route 53. Dos registros con el mismo nombre, diferentes destinos, pesos 10 y 90.

Las instancias EC2 tardan 3 minutos en inicializarse; el escalado horizontal es demasiado lento durante los picos de tráfico.

Pool de espera de Auto Scaling. Instancias preinicializadas que se mantienen detenidas (más barato) listas para iniciar en segundos.

Por qué: El arranque en frío + bootstrap es el elemento que más tarda. El pool de espera saca ese trabajo de la ruta crítica.

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.

Elegir ALB o NLB.

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.

Orden estricto y procesamiento "exactamente una vez" por grupo de mensajes.

Cola SQS FIFO con deduplicación basada en contenido o `MessageDeduplicationId` explícito. Usar `MessageGroupId` para grupos ordenados paralelos.

Por qué: SQS estándar es "al menos una vez" sin garantía de orden. FIFO tiene un rendimiento menor a menos que se use el modo de alto rendimiento.

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.

Copias de seguridad resistentes al ransomware: ni siquiera un administrador puede eliminarlas antes de la retención.

AWS Backup Vault Lock en modo de cumplimiento. Aplicación WORM; ni siquiera el usuario root puede acortar la retención.

Elegir un patrón de DR según los requisitos de RPO/RTO.

Copia de seguridad y restauración: RPO horas, RTO horas, más barato. Pilot Light: RPO minutos, RTO decenas de minutos. Warm Standby: RPO segundos, RTO minutos. Multi-Sitio Activo-Activo: RPO ~cero, RTO segundos, más caro.

Replicar un bucket crítico entre Regiones para DR con un RPO de menos de 15 minutos.

Replicación entre Regiones de S3 (CRR) con Control de Tiempo de Replicación de S3 (RTC). El 99.99% de los objetos en 15 minutos.

Por qué: CRR estándar es de "mejor esfuerzo". RTC añade un SLA + métricas de replicación en CloudWatch.

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.

Tráfico TCP/UDP con baja fluctuación a la Región saludable más cercana; IPs anycast estáticas.

AWS Global Accelerator. Dos IPs anycast; enruta al endpoint más cercano sobre la red troncal de AWS.

Por qué: Mejor que la latencia de Route 53 para tráfico no HTTP. Conmutación por error más rápida (anycast) + lista de permitidos de IP estáticas.

Lambda procesa pedidos de SQS — el mensaje puede entregarse dos veces.

Idempotencia: almacenar el hash de la solicitud en DynamoDB con TTL; PUT-IfNotExists en cada reintento. O usar una cola FIFO con deduplicación.

Las expulsiones voluntarias de pods (drenaje de nodo, autoescalador de clúster) eliminan todas las réplicas de un despliegue.

PodDisruptionBudget de Kubernetes que especifica `minAvailable` o `maxUnavailable`. El clúster lo respeta durante las interrupciones voluntarias.

Diseñar Arquitecturas de Alto Rendimiento

Elegir una clase de almacenamiento de S3.

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.

Bucket de acceso mixto con patrones impredecibles; optimización automática de costos.

S3 Intelligent-Tiering. Monitorea el acceso; mueve automáticamente objetos entre niveles (Frecuente / Infrecuente / Archivo Instantáneo / Archivo / Archivo Profundo). Sin tarifas de recuperación.

Por qué: Pequeña tarifa de monitoreo por objeto, pero más barato que adivinar mal. Predeterminado para patrones desconocidos.

Subir objetos grandes (> 100 MB) de forma fiable y rápida a través de internet.

S3 Multipart Upload (partes paralelas) + S3 Transfer Acceleration (ingesta en el edge de CloudFront).

Por qué: Las partes paralelas saturan el ancho de banda; Transfer Acceleration descarga el salto WAN a la red troncal de AWS.

Elegir tipo de volumen EBS.

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.

Elegir un sistema de archivos compartido.

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.

EFS — elegir modo de rendimiento.

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).

Copia de seguridad de archivo/bloque/cinta on-premises que se integra con S3 / Glacier.

AWS Storage Gateway: File Gateway (NFS/SMB → S3), Volume Gateway (iSCSI → S3 + EBS snapshots), Tape Gateway (VTL → Glacier).

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.

Manipular solicitud/respuesta en el edge.

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.

Elegir ElastiCache Redis o Memcached.

Replicación, persistencia, pub/sub, conjuntos ordenados, conmutación por error Multi-AZ → Redis. Multihilo, clave/valor simple, solo sharding horizontal → Memcached.

El almacén de sesiones Redis necesita HA con conmutación por error automática entre AZs.

Grupo de replicación de ElastiCache para Redis con Multi-AZ + conmutación por error automática habilitada. Primario en una AZ, réplicas en otras.

Latencia de lectura de DynamoDB de microsegundos; caché sin cambios en la aplicación.

DynamoDB Accelerator (DAX). Caché administrada en VPC; mismo SDK de DynamoDB; lectura transparente a través de la caché.

Por qué: ElastiCache requiere lógica de caché a nivel de aplicación. DAX es un reemplazo directo para DynamoDB.

Elegir una estrategia de caché.

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.

Elegir una plataforma de cómputo.

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.

Elegir tipo de API Gateway.

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.

Aplicación móvil/web necesita GraphQL con suscripciones en tiempo real respaldadas por DynamoDB / Lambda.

AWS AppSync. GraphQL administrado, suscripciones WebSocket, autorización granular a través de Cognito / IAM / autorizadores Lambda.

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.

Consultar datos que residen en S3 desde Redshift sin cargarlos.

Redshift Spectrum. Esquema externo sobre Glue Data Catalog; los nodos de Spectrum escanean S3 y transmiten los resultados de vuelta al clúster.

Elegir modo de capacidad de DynamoDB.

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).

La tabla de sesiones de DynamoDB crece sin límite; las sesiones expiran después de 24h.

TTL de DynamoDB en un atributo numérico de época. DynamoDB elimina los elementos caducados asincrónicamente, sin cargo de capacidad de escritura.

Una carga de trabajo HPC necesita la menor latencia posible entre nodos.

Grupo de ubicación en clúster: instancias en la misma AZ en el mismo rack físico. Hasta 10 Gbps de flujo único.

Por qué: Ubicación dispersa → aislamiento máximo (HA); Partición → big-data (Hadoop, Cassandra); Clúster → menor latencia.

Diseñar Arquitecturas Optimizadas en Costos

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.

Tener instancias reservadas (RIs) no utilizadas después de la migración.

Vender en el Mercado de Instancias Reservadas (solo RIs Estándar). O convertir a través de RIs Convertibles a una familia diferente.

Por qué: Las RIs Convertibles ofrecen un descuento ligeramente menor a cambio del derecho a intercambiar.

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.

Funciones Lambda donde el runtime soporta ARM.

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.

Reducir los costos de transferencia de datos.

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.

Los costos de CloudWatch Logs se disparan.

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.

Reducir la salida de S3 / EC2 a internet.

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.

Migrar 100 TB de NFS on-prem a S3.

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.