Amazon SAA-C03: Entrega de Contenido, Edge y Optimización del Rendimiento — Guía de estudio

By Laurynas Brazys · 15 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 distribuida globalmente, construida sobre más de 600 puntos de presencia. Su función es terminar el TLS del espectador en el borde más cercano y, o bien servir respuestas en caché inmediatamente, o bien hacer un proxy de las solicitudes no encontradas en caché a través de la red troncal privada de AWS hacia el origen. El beneficio de rendimiento es doble: los aciertos de caché reducen el tiempo de ida y vuelta a milisegundos de un solo dígito y descargan completamente el origen, mientras que las solicitudes no encontradas en caché aún se benefician de la terminación TLS/TCP optimizada en el borde, el soporte HTTP/2 y HTTP/3, la reutilización de conexiones keep-alive al origen y el tránsito por la red troncal que evita la ruidosa internet pública.

Un error común es 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 la API dinámica porque el handshake del espectador se completa en el PoP local en lugar de atravesar internet hasta la Región de origen. Combine eso con una carga de trabajo mixta —digamos /static/* servido desde S3 y /api/* servido desde un ALB— y una 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

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 viven en us-east-1

Para cualquier distribución de CloudFront servida en un dominio personalizado, el certificado TLS orientado al espectador en AWS Certificate Manager debe emitirse en us-east-1 (N. Virginia), independientemente de 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 extraen el certificado de esa Región. Solicitar un certificado ACM en eu-west-1 porque su bucket de S3 reside 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 termina TLS una segunda vez entre CloudFront y un origen ALB, ese certificado orientado al origen reside en la Región del ALB. Solo el certificado del espectador está bloqueado en us-east-1. La misma regla se aplica a los dominios personalizados optimizados para el borde de API Gateway (que usan una distribución de CloudFront administrada por AWS internamente): el certificado debe estar en us-east-1. Los endpoints regionales de API Gateway, en contraste, toman un certificado de la propia Región de la API.

Control de acceso de origen para orígenes S3

Poner un bucket de S3 delante de CloudFront mientras se deja el bucket público anula el propósito: los espectadores evitan CloudFront al acceder directamente al endpoint REST de S3, eludiendo WAF, restricciones geográficas, URLs firmadas y beneficios de caché, y potencialmente exponiendo datos.

La solución moderna es el Control de Acceso de Origen (OAC), que reemplaza la antigua Identidad de Acceso de Origen (OAI). OAC utiliza la firma SigV4, admite SSE-KMS, funciona en todas las Regiones de S3 (incluidas las lanzadas después de 2022) y admite solicitudes dinámicas. El Bloqueo de Acceso Público permanece activado, no se necesitan ACL y la política del bucket otorga acceso de lectura solo al principal de servicio de CloudFront, restringido aún más por el ARN de distribución específico:

{
  "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 heredado; siempre elija OAC para nuevos trabajos.

Corrección de la caché

La efectividad de la caché depende de los encabezados Cache-Control y Expires que devuelve el origen, combinados con los TTLs mínimo/predeterminado/máximo de la política de caché de CloudFront. Los activos inmutables y con huella digital deben almacenarse en caché de forma agresiva; los shells HTML que los referencian deben tener una vida útil corta para que las implementaciones se propaguen; el JSON autenticado no debe almacenarse en caché en la CDN compartida en absoluto:

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

Son comunes dos trampas simétricas. Primero, si el origen no emite encabezados de caché, CloudFront recurre al TTL predeterminado de la distribución y puede almacenar en caché silenciosamente respuestas dinámicas durante horas. Segundo, un Cache-Control: no-cache generalizado en activos que deberían almacenarse en caché fuerza cada solicitud de vuelta al origen y anula la CDN.

La trampa más peligrosa es almacenar en caché respuestas personalizadas sin los encabezados adecuados. Si /account/dashboard devuelve HTML específico del usuario A, pero el origen omite no-store y la política de caché no incluye un encabezado de autenticación o una cookie en la clave de caché, el borde servirá felizmente la página del usuario A al usuario B. O bien marque dichas respuestas como private, no-store, o incluya el identificador de sesión en la clave de caché y acepte una menor tasa de aciertos.

Para un escenario de optimización de costos donde un grupo de Auto Scaling de instancias EC2 On-Demand sirve contenido estático, el rediseño correcto es mover los activos a S3, colocar CloudFront al frente con OAC y eliminar o reducir el ASG. Esto cambia 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.

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

CloudFront admite URLs firmadas (acceso con límite de tiempo, opcionalmente restringido por IP, a un solo objeto — una descarga de video comprada, un enlace PDF único) y cookies firmadas (acceso a muchos objetos que coinciden con un patrón de ruta — un suscriptor autenticado navegando por un catálogo). Ambos utilizan un grupo de claves de confianza cuya clave pública se carga en 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 omite CloudFront y otorga acceso directo al bucket. Empareje las URLs firmadas de CloudFront con OAC y el bucket permanece privado de extremo a extremo.

La restricción geográfica aplica listas de permitidos o bloqueados a nivel de país en el nivel de 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 barato y a prueba de bypass de caché para hacer cumplir los embargos de licencias. Para una lógica más fina (a nivel de estado, combinaciones de encabezados), recurra a una función de CloudFront o Lambda@Edge; para un motor de reglas completo, use 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 entran en la red troncal de AWS en el borde más cercano y se enrutan a través de la red privada de AWS al endpoint más saludable (ALB, NLB, EC2 o Elastic IP) en una o más Regiones agrupadas en grupos de endpoints con diales y pesos de tráfico.

Las IPs estáticas ofrecen tres beneficios concretos: los clientes y las listas de permitidos del firewall nunca cambian, incluso si el backend se rediseña; la conmutación por error regional se completa en segundos al cambiar el tráfico entre grupos de endpoints en los cambios de verificación de estado, evitando por completo la propagación del TTL de DNS; y el handshake TCP termina en el borde con el transporte de larga distancia ejecutándose en la red troncal de AWS.

Elija Global Accelerator cuando:

• El protocolo no es HTTP: UDP para juegos o VoIP, MQTT, SIP, SFTP, TCP personalizado.
• Necesita IPs estáticas para listas de permitidos empresariales o aplicaciones móviles que codifican direcciones.
• Necesita una conmutación por error regional en menos de un minuto para implementaciones activas-activas con estado.
• La carga de trabajo es dinámica y no cacheable, por lo que una CDN ofrece poco valor.

Elija CloudFront cuando:

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

Dos trampas a evitar. Elegir CloudFront para “hacer que nuestros servidores de juegos sean más rápidos globalmente” falla porque los juegos son UDP y no cacheables — se requiere Global Accelerator. Por el contrario, elegir Global Accelerator para un sitio web estático es costoso (tarifa fija por hora más por GB) y renuncia al almacenamiento en caché — CloudFront reduciría drásticamente el egreso del origen. Para una API HTTP distribuida globalmente pero de una sola Región donde los usuarios toleran la latencia, el enrutamiento basado en latencia de Route 53 simple 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 se resuelve un cliente; CloudFront o Global Accelerator luego manejan la conexión. Tres políticas dominan las arquitecturas globales.

El enrutamiento basado en latencia mide la latencia de red real desde la ubicación del resolvedor hasta cada Región y devuelve la más rápida. Úselo para stacks idénticos en múltiples Regiones donde desea que los usuarios sean dirigidos a la Región que sea más rápida en ese momento.

El enrutamiento por geoproximidad se basa en coordenadas en lugar de latencia: usted declara la ubicación (o Región de AWS) de cada endpoint, y Route 53 envía a los usuarios al más cercano geográficamente. Su característica distintiva es un valor de sesgo (de -99 a +99) que expande o reduce el área de servicio efectiva, útil para cambiar el tráfico gradualmente durante un lanzamiento Regional o para drenar una Región por mantenimiento. La 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

El enrutamiento de conmutación por error utiliza un par primario/secundario vinculado a comprobaciones de estado. Es una conmutación por error a nivel de DNS, sujeta a TTL y al almacenamiento en caché del resolvedor, por lo que es más lenta que la conmutación por error del plano de datos de Global Accelerator. Elija el enrutamiento de conmutación por error para un modo activo-pasivo simple donde un minuto de propagación de DNS es tolerable, y Global Accelerator cuando necesite segundos.

Estas políticas se componen. 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 conmutación por error con comprobación de estado debajo como red de seguridad. La estratificación es deliberada: Route 53 elige la Región, Global Accelerator o CloudFront elige 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 endpoints de API Gateway y dominios personalizados

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

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

La ubicación del certificado sigue la regla de CloudFront: los dominios personalizados optimizados para borde requieren un certificado 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 ACM: emitidos, validados, importados

ACM emite y renueva automáticamente 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 de DNS (ACM le proporciona un CNAME para colocar en Route 53 o cualquier proveedor de DNS; mientras el registro persista, ACM se renueva automáticamente para siempre) o validación por correo electrónico (clic manual por renovación, frágil para la automatización). La validación de DNS es el valor predeterminado correcto para cualquier cosa en producción.

Los certificados emitidos por ACM no se pueden exportar y no se pueden usar fuera de los servicios integrados de AWS. Cuando un requisito regulatorio o comercial 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 puede usar un certificado emitido por ACM. Obtenga el certificado de la CA requerida e impórtelo a ACM, luego adjúntelo 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 renuevan automáticamente (reimporte antes de la caducidad o el endpoint fallará por completo), y ACM no valida la cadena en la importación; un intermedio roto solo aparecerá en el momento del handshake de clientes reales. Pruebe la cadena completa con un cliente estricto antes de la implementación.

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 PUTs entran por 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 sola Región, por ejemplo, ingenieros de campo de todo el mundo que cargan dibujos de varios gigabytes a us-east-1.

Las dos características coexisten en el mismo bucket: habilite Transfer Acceleration y exponga una distribución de CloudFront con OAC para descargas. Para objetos pequeños o clientes que ya están cerca de la Región del bucket, Transfer Acceleration agrega costos sin beneficios; use la herramienta de comparación de velocidad de S3 Transfer Acceleration para medir antes de comprometerse. 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 URI, encabezados, cadenas de consulta, cuerpo (hasta 8 KB por defecto, expandible a 64 KB en ALB/API Gateway), conjuntos de IP y geolocalización.

Los bloques de construcción más comunes son las Reglas Administradas de AWS: 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 coincidencia geográfica (listas de países permitidos/bloqueados para cumplimiento), coincidencias de conjuntos de IP y reglas basadas en tasas — que cuentan las solicitudes por IP de origen durante una ventana deslizante de cinco minutos y bloquean una vez que se excede un umbral. Las reglas basadas en tasas son la primera línea de defensa contra inundaciones HTTP y relleno de credenciales:

{
  "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 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 se puede 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 cierto.

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

Administrar WAF una cuenta a la vez no es escalable. En una Organización, un equipo lanza 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 a nivel de organización aplicadas a las cuentas y recursos dentro del alcance.

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íticas 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 propiedad de la aplicación), un grupo de reglas “último” (después), o reemplazar completamente la ACL web. Los nuevos ALBs o distribuciones de CloudFront que coincidan con el alcance 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 diga “múltiples cuentas”, “administrar centralmente” o “reglas WAF consistentes en toda la organización”, Firewall Manager es la respuesta, no WAF por cuenta.

Shield Standard vs. Shield Advanced

Asumir que WAF por sí solo detiene los DDoS es un error crítico. WAF opera sobre las solicitudes que le llegan — es excelente contra inundaciones de capa de aplicación, relleno de credenciales y firmas de exploits conocidas — 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 costo. Defiende contra ataques comunes de L3/L4 automáticamente 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 de ataques, interacción con el Equipo de Respuesta de Shield ni protección de costos.

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

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

La postura de capas correcta es: Shield para volumétricos L3/L4, WAF para filtrado L7, CloudFront o Global Accelerator como punto de entrada de borde al que se adjuntan ambos servicios, y Firewall Manager para aplicar la política en cada cuenta.

← Redes y Conectividad · Todos los dominios · Bases de Datos y Caching →

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

Explorar Amazon →