Amazon SAA-C03: Entrega de contenido, Edge y optimización del rendimiento — Guía de estudio

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Forma parte de la AWS SAA-C03 — Guía de estudio completa. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Amazon CloudFront: Qué es y por qué ayuda

Amazon CloudFront es una red de entrega de contenido (CDN) distribuida globalmente y construida sobre más de 600 puntos de presencia. Su trabajo es terminar el TLS del espectador en el borde más cercano y servir respuestas cacheadas inmediatamente o, en caso de no encontrarlo en caché (cache miss), reenviar la solicitud al origen a través de la red troncal privada de AWS. El beneficio de rendimiento es doble: los aciertos de caché (cache hits) reducen el tiempo de ida y vuelta a milisegundos de un solo dígito y descargan completamente al origen, mientras que los fallos de caché (cache misses) aún se benefician de la terminación optimizada de TLS/TCP en el borde, el soporte para HTTP/2 y HTTP/3, la reutilización de conexiones keep-alive hacia el origen y el tránsito por la red troncal que evita la ruidosa internet pública.

Un error común es pensar que CloudFront solo acelera activos estáticos. Colocar un ALB detrás de CloudFront con una política CachingDisabled aún mejora el rendimiento de las API dinámicas porque el handshake del espectador se completa en el PoP local en lugar de atravesar internet hasta la Región de origen. Si se combina eso con una carga de trabajo mixta —por ejemplo, /static/* servido desde S3 y /api/* servido desde un ALB— una sola distribución puede manejar ambos:

Distribution:
  Aliases: [www.example.com]
  ViewerCertificate: ACM cert in us-east-1
  Origins:
    - Id: s3-static
      DomainName: static-assets.s3.us-east-1.amazonaws.com
      S3OriginConfig:
        OriginAccessControlId: !Ref OAC
    - Id: alb-dynamic
      DomainName: alb-1234.us-east-1.elb.amazonaws.com
      CustomOriginConfig: { OriginProtocolPolicy: https-only }
  DefaultCacheBehavior:
      TargetOriginId: alb-dynamic
      CachePolicyId: CachingDisabled
      OriginRequestPolicyId: AllViewer
  CacheBehaviors:
    - PathPattern: /static/*
      TargetOriginId: s3-static
      CachePolicyId: CachingOptimized
    - PathPattern: /api/*
      TargetOriginId: alb-dynamic
      CachePolicyId: !Ref ShortTtlPolicy

Luego, los registros de alias de Route 53 apuntan www.example.com al d123.cloudfront.net de la distribución; los registros de alias son gratuitos y se resuelven directamente a las IPs anycast de CloudFront.

Los certificados residen en us-east-1

Para cualquier distribución de CloudFront servida en un dominio personalizado, el certificado TLS de cara al espectador en AWS Certificate Manager debe ser emitido en us-east-1 (N. Virginia), sin importar dónde se encuentren el bucket de origen, el ALB o los usuarios. CloudFront es un servicio global cuyo plano de control está anclado en us-east-1; las ubicaciones de borde obtienen el certificado de esa Región. Solicitar un certificado de ACM en eu-west-1 porque tu bucket de S3 se encuentra allí es un patrón incorrecto; la distribución nunca lo verá.

aws acm request-certificate \
  --domain-name media.example.com \
  --validation-method DNS \
  --region us-east-1

Si terminas el TLS por segunda vez entre CloudFront y un origen de tipo ALB, ese certificado de cara al origen reside en la Región del ALB. Solo el certificado del espectador está restringido a us-east-1. La misma regla se aplica a los dominios personalizados optimizados para el borde (edge-optimized) de API Gateway (que utilizan una distribución de CloudFront gestionada por AWS internamente): el certificado debe estar en us-east-1. En contraste, los endpoints regionales de API Gateway toman un certificado de la propia Región de la API.

Origin Access Control para orígenes de S3

Poner un bucket de S3 detrás de CloudFront mientras se deja el bucket público va en contra del propósito: los espectadores eluden CloudFront al acceder directamente al endpoint REST de S3, saltándose WAF, las restricciones geográficas, las URL firmadas y los beneficios de la caché, y exponiendo potencialmente los datos.

La solución moderna es Origin Access Control (OAC), que reemplaza al antiguo Origin Access Identity (OAI). OAC utiliza la firma SigV4, soporta SSE-KMS, funciona en todas las Regiones de S3 (incluidas las lanzadas después de 2022) y admite solicitudes dinámicas. La opción Block Public Access permanece activada, no se necesitan ACLs, y la política del bucket concede acceso de lectura solo al principal de servicio de CloudFront, restringido además por el ARN específico de la distribución:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::media-example-com/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
      }
    }
  }]
}

OAI todavía funciona, pero debe considerarse obsoleto (legacy); elige siempre OAC para nuevos proyectos.

Correctitud de la caché

La efectividad de la caché depende de las cabeceras Cache-Control y Expires que devuelve el origen, combinadas con los TTLs mínimo/por defecto/máximo de la política de caché de CloudFront. Los activos inmutables con huella digital (fingerprinted) deben ser cacheados de forma agresiva; las plantillas HTML que los referencian deben tener una vida corta para que los despliegues se propaguen; el JSON autenticado no debe ser cacheado en absoluto en el CDN compartido:

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300      # HTML that changes
Cache-Control: private, no-store                      # authenticated JSON

Dos trampas simétricas son comunes. Primero, si el origen no emite cabeceras de caché, CloudFront recurre al TTL por defecto de la distribución y puede cachear silenciosamente respuestas dinámicas durante horas. Segundo, un Cache-Control: no-cache generalizado en activos que deberían ser cacheados fuerza a que cada solicitud vuelva al origen y anula el propósito del CDN.

La trampa más peligrosa es cachear respuestas personalizadas sin las cabeceras adecuadas. Si /account/dashboard devuelve HTML específico para el usuario A, pero el origen omite no-store y la política de caché no incluye una cabecera de autenticación o una cookie en la clave de caché (cache key), el borde servirá alegremente la página del usuario A al usuario B. O bien se marcan dichas respuestas como private, no-store, o se incluye el identificador de sesión en la clave de caché y se acepta una tasa de aciertos (hit ratio) más baja.

Para un escenario de optimización de costos donde un grupo de Auto Scaling de instancias EC2 bajo demanda sirve contenido estático, el rediseño correcto es mover los activos a S3, poner CloudFront delante con OAC y eliminar o reducir el ASG. Esto desplaza el costo de cómputo por hora a entrega por solicitud, lo cual es órdenes de magnitud más barato para cargas de trabajo estáticas.

URL firmadas, cookies firmadas y restricción geográfica

CloudFront soporta URL firmadas (acceso con límite de tiempo y opcionalmente restringido por IP a un solo objeto, como la descarga de un video comprado o un enlace único a un PDF) y cookies firmadas (acceso a muchos objetos que coinciden con un patrón de ruta, como un suscriptor autenticado que navega por un catálogo). Ambos utilizan un grupo de claves de confianza (trusted key group) cuya clave pública se sube a CloudFront; la clave privada firma una política que especifica la expiración, el rango de IP de origen o el patrón de URL.

https://d123.cloudfront.net/premium/movie.mp4
  ?Expires=1735689600
  &Signature=...
  &Key-Pair-Id=APKAI...

Esto es distinto de una URL prefirmada de S3, que pasa por alto CloudFront y concede acceso directo al bucket. Combina las URL firmadas de CloudFront con OAC y el bucket permanecerá privado de extremo a extremo.

La restricción geográfica (Geo-restriction) aplica listas de permitidos (allow-lists) o de bloqueo (block-lists) a nivel de país en la distribución, antes de que las solicitudes lleguen a la caché o al origen. Utiliza la base de datos GeoIP mantenida por CloudFront y es el mecanismo económico y a prueba de omisiones de caché para aplicar embargos de licencias. Para una lógica más fina (a nivel de estado, combinaciones de cabeceras), recurre a una CloudFront Function o a Lambda@Edge; para un motor de reglas completo, utiliza WAF.

AWS Global Accelerator

Global Accelerator no es una CDN y no almacena en caché. Proporciona dos direcciones IPv4 anycast estáticas (o BYOIP) anunciadas desde las ubicaciones de borde de AWS a nivel mundial. Las conexiones TCP o UDP del cliente ingresan a la red troncal de AWS en el borde más cercano y se enrutan a través de la red privada de AWS hacia el endpoint más saludable (ALB, NLB, EC2 o Elastic IP) en una o más Regiones agrupadas en grupos de endpoints con controles de tráfico y pesos.

Las IP estáticas ofrecen tres beneficios concretos: los clientes y las listas de permitidos (allowlists) de los firewalls nunca cambian, incluso si se rediseña la arquitectura del backend; el failover regional se completa en segundos al desviar el tráfico entre grupos de endpoints según los cambios en las comprobaciones de estado, evitando por completo la propagación de TTL de DNS; y el handshake de TCP termina en el borde, con el tramo largo ejecutándose en la red troncal de AWS.

Elige Global Accelerator cuando:

• El protocolo no es HTTP: UDP para videojuegos o VoIP, MQTT, SIP, SFTP, TCP personalizado.
• Necesitas IP estáticas para listas de permitidos empresariales o aplicaciones móviles que codifican direcciones de forma fija.
• Necesitas un failover regional en menos de un minuto para despliegues activo-activo con estado.
• La carga de trabajo es dinámica y no cacheable, por lo que una CDN ofrece poco valor.

Elige CloudFront cuando:

• El contenido es cacheable (imágenes, segmentos de video, HTML estático, respuestas de API con TTL).
• Quieres computación en el borde a través de Lambda@Edge o CloudFront Functions.
• Necesitas WAF, URLs/cookies firmadas o cifrado a nivel de campo en el borde.

Hay dos trampas que evitar. Elegir CloudFront para “hacer nuestros servidores de videojuegos más rápidos a nivel mundial” falla porque los videojuegos usan UDP y no son cacheables — se requiere Global Accelerator. Por el contrario, elegir Global Accelerator para un sitio web estático es caro (tarifa fija por hora más un costo por GB) y se pierde el almacenamiento en caché — CloudFront reduciría drásticamente la salida del origen. Para una API HTTP distribuida globalmente pero en una sola Región donde los usuarios toleran la latencia, el enrutamiento simple basado en latencia de Route 53 puede ser suficiente y más barato que cualquiera de los dos.

Políticas de enrutamiento de Route 53 para tráfico global

Route 53 elige a qué endpoint resuelve un cliente; luego, CloudFront o Global Accelerator gestionan la conexión. Tres políticas dominan las arquitecturas globales.

Enrutamiento basado en latencia mide la latencia de red real desde la ubicación del resolver hasta cada Región y devuelve la más rápida. Úsalo para pilas idénticas en múltiples Regiones cuando quieras que los usuarios sean dirigidos a la Región que sea más rápida en ese momento.

Enrutamiento por geoproximidad se basa en coordenadas en lugar de latencia: declaras la ubicación (o la Región de AWS) de cada endpoint, y Route 53 envía a los usuarios al geográficamente más cercano. Su característica distintiva es un valor de sesgo (bias) (−99 a +99) que expande o contrae el área de servicio efectiva — útil para desviar el tráfico gradualmente durante el lanzamiento de una Región o para drenar una Región por mantenimiento. El enrutamiento por geoproximidad requiere el flujo de tráfico de Route 53 (políticas de tráfico) y generalmente se combina con un NLB o ALB regional en cada Región.

RecordSets:
  - Region: eu-west-1
    Endpoint: nlb-eu.example.internal
    Bias: +30       # expand EU service area during launch
  - Region: us-east-1
    Endpoint: nlb-us.example.internal
    Bias: 0
  - Region: ap-southeast-1
    Endpoint: nlb-ap.example.internal
    Bias: 0

Enrutamiento de failover utiliza un par primario/secundario vinculado a comprobaciones de estado. Es un failover a nivel de DNS, sujeto al TTL y al almacenamiento en caché del resolver, por lo que es más lento que el failover en el plano de datos de Global Accelerator — elige el enrutamiento de failover para un activo-pasivo simple donde un minuto de propagación de DNS es tolerable, y Global Accelerator cuando necesites segundos.

Estas políticas se pueden combinar. Un patrón global común: los registros de latencia o geoproximidad de Route 53 apuntan a Global Accelerator (para TCP/UDP) o CloudFront (para HTTPS cacheable), con registros de failover con comprobación de estado por debajo como red de seguridad. La superposición de capas es deliberada: Route 53 elige la Región, Global Accelerator o CloudFront eligen el borde y la ruta a través de la red troncal, y un balanceador de carga regional elige el destino dentro de la Región.

Tipos de endpoint y dominios personalizados de API Gateway

API Gateway ofrece tres tipos de endpoint con topologías distintas:

Los endpoints optimizados para el borde envuelven la API en una distribución de CloudFront gestionada por AWS que no puedes configurar directamente. Esto es conveniente para un alcance global rápido, pero limitante cuando quieres tus propios comportamientos de caché, reglas de WAF o políticas de solicitud de origen. El patrón idiomático para un control máximo es un endpoint Regional expuesto a través de una distribución de CloudFront gestionada por el cliente.

La ubicación del certificado sigue la regla de CloudFront: los dominios personalizados optimizados para el borde requieren un certificado de ACM en us-east-1; los endpoints Regionales requieren el certificado en la misma Región que la API. Las API HTTP imponen un mínimo de TLS 1.2; las API REST admiten políticas de seguridad hasta TLS 1.3.

Certificados de ACM: Emitidos, validados e importados

ACM emite y autorrenueva certificados TLS públicos sin costo y se integra directamente con CloudFront, API Gateway, ALB, NLB y otros servicios de AWS. La validación es mediante validación por DNS (ACM te proporciona un CNAME para colocar en Route 53 o cualquier proveedor de DNS; mientras el registro persista, ACM se autorrenueva para siempre) o validación por correo electrónico (requiere un clic manual en cada renovación, frágil para la automatización). La validación por DNS es la opción predeterminada correcta para cualquier entorno de producción.

Los certificados emitidos por ACM no se pueden exportar y no se pueden usar fuera de los servicios de AWS integrados. Cuando un requisito normativo o de negocio exige una CA de terceros específica —por ejemplo, una API REST que debe encadenarse a un emisor comercial particular y aplicar TLS 1.3— no puedes usar un certificado emitido por ACM. Obtén el certificado de la CA requerida e impórtalo en ACM, luego adjúntalo a un dominio personalizado de API Gateway regional con una política de seguridad TLS 1.3.

La trampa con las importaciones es doble: los certificados importados no se autorrenuevan (hay que reimportarlos antes de que caduquen o el endpoint fallará por completo), y ACM no valida la cadena en la importación —un intermediario roto solo aparecerá en el momento del handshake con clientes reales. Prueba la cadena completa contra un cliente estricto antes del despliegue.

S3 Transfer Acceleration vs. CloudFront

CloudFront optimiza las descargas; S3 Transfer Acceleration optimiza las cargas. Transfer Acceleration utiliza la misma red de borde de CloudFront a la inversa: los PUT ingresan en el borde más cercano y viajan por la red troncal de AWS hasta la región del bucket de destino. Destaca cuando un conjunto de usuarios dispersos globalmente carga objetos de gran tamaño a un bucket en una única región —por ejemplo, ingenieros de campo de todo el mundo que cargan planos de varios gigabytes a us-east-1.

Las dos características coexisten en el mismo bucket: habilita Transfer Acceleration y expón una distribución de CloudFront con OAC para las descargas. Para objetos pequeños o clientes que ya están cerca de la región del bucket, Transfer Acceleration añade costo sin beneficio —utiliza la herramienta de comparación de velocidad de S3 Transfer Acceleration para medir antes de comprometerte. Los clientes deben usar el endpoint s3-accelerate para que la aceleración se active.

AWS WAF para protección de capa 7

AWS WAF inspecciona las solicitudes HTTP(S) antes de que lleguen al recurso protegido. Se adjunta a distribuciones de CloudFront, ALBs, etapas de API Gateway, APIs de AppSync, grupos de usuarios de Cognito, servicios de App Runner e instancias de Verified Access. Una ACL web contiene reglas que coinciden con el URI, las cabeceras, las cadenas de consulta, el cuerpo (hasta 8 KB por defecto, ampliable a 64 KB en ALB/API Gateway), conjuntos de IP y geolocalización.

Los componentes más comunes son las Reglas administradas por AWS (AWS Managed Rules): AWSManagedRulesCommonRuleSet y AWSManagedRulesKnownBadInputsRuleSet cubren los principales exploits de OWASP; AWSManagedRulesSQLiRuleSet y las declaraciones de coincidencia XSS manejan la inyección. Las reglas personalizadas añaden coincidencias geográficas (listas de países permitidos/bloqueados para cumplimiento), coincidencias de conjuntos de IP y reglas basadas en la tasa, que cuentan las solicitudes por IP de origen en una ventana móvil de cinco minutos y bloquean una vez que se excede un umbral. Las reglas basadas en la tasa son la primera línea de defensa contra inundaciones HTTP y el relleno de credenciales (credential stuffing):

{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 500,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority":0,"Type":"NONE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

Las reglas de la región importan. Las ACL web para CloudFront son globales y deben crearse en us-east-1. Las ACL web para recursos regionales (ALB, API Gateway, etc.) se crean en la propia región del recurso.

Para proteger un sitio estático en S3, no puedes adjuntar WAF al bucket —S3 no es un recurso compatible con WAF. El patrón correcto es CloudFront + OAC delante del bucket con la ACL web adjunta a la distribución. El hecho de que el bucket sea inaccesible excepto a través de CloudFront es lo que hace que “inspeccionar todo el tráfico” sea una realidad.

Firewall Manager para la gobernanza de WAF en múltiples cuentas

Gestionar WAF una cuenta a la vez no es escalable. En una Organization, un equipo despliega un nuevo ALB sin adjuntar la línea base corporativa y la postura de cumplimiento retrocede silenciosamente. AWS Firewall Manager resuelve esto con políticas para toda la organización que se aplican a las cuentas y recursos dentro del ámbito.

Requisitos previos: AWS Organizations con todas las características habilitadas, una cuenta de administrador de Firewall Manager designada y AWS Config habilitado en cada cuenta miembro. Los tipos de política cubren AWS WAF, AWS Shield Advanced, grupos de seguridad (auditoría y uso), Network Firewall, Route 53 Resolver DNS Firewall y firewalls de terceros.

Una política de WAF puede aplicar un grupo de reglas “primero” (evaluado antes de las reglas propias de la aplicación), un grupo de reglas “último” (después), o reemplazar la ACL web por completo. Los nuevos ALB o distribuciones de CloudFront que coincidan con el ámbito del recurso reciben automáticamente el conjunto de reglas corporativas, y los recursos no conformes se marcan y —dependiendo de la configuración de remediación— se corrigen automáticamente. Siempre que un escenario mencione “múltiples cuentas”, “administrar de forma centralizada” o “reglas de WAF consistentes en toda la organización”, la respuesta es Firewall Manager, no WAF por cuenta.

Shield Standard frente a Shield Advanced

Asumir que WAF por sí solo detiene los ataques DDoS es un error crítico. WAF opera sobre las solicitudes que le llegan —es excelente contra inundaciones en la capa de aplicación, credential stuffing y firmas de exploits conocidos— pero los grandes ataques volumétricos en las capas 3/4 (inundaciones SYN, reflexión UDP) son absorbidos por AWS Shield.

Shield Standard está activado por defecto sin coste alguno. Defiende automáticamente contra ataques comunes de L3/L4 y se aplica a CloudFront, Route 53 y Global Accelerator, con protección básica para ELB, EC2 y otros recursos. No proporciona visibilidad específica del ataque, la intervención del Shield Response Team ni protección de costes.

Shield Advanced (3000 $/mes por organización, con un compromiso de un año) añade:

Asumir que Shield Standard es suficiente para “DDoS a gran escala con protección de costes y respuesta de expertos” es incorrecto precisamente porque Standard carece de visibilidad, protección de costes y acceso al SRT. Cuando el origen es una instancia EC2 detrás de un ELB y el DNS está con un tercero (por lo que los trucos con alias de Route 53 no son una opción), el patrón recomendado es habilitar Shield Advanced en el ELB y exponer la aplicación a través de CloudFront (también protegido con Shield Advanced) para mover el perímetro de mitigación al borde (edge) y reducir la superficie de ataque que llega a la Región.

La postura correcta de defensa por capas es: Shield para ataques volumétricos de L3/L4, WAF para el filtrado de L7, CloudFront o Global Accelerator como punto de entrada en el borde (edge) al que se asocian ambos servicios, y Firewall Manager para aplicar la política en todas las cuentas.

← Redes y conectividad · Todos los dominios · Bases de datos y almacenamiento en caché →

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

Explorar Amazon →