Semana 6 · Módulo 6 de 11

Redes en AWS (II): DNS, borde de red y protección

Route 53 y sus políticas de enrutamiento, CloudFront a fondo (orígenes, OAC, caché, funciones en el borde, contenido privado), Global Accelerator, y la protección perimetral con AWS WAF, AWS Shield, Firewall Manager y los certificados de ACM. Es el bloque que responde a «usuarios en todo el mundo», «conmutación por error entre regiones», «DDoS» e «inyección SQL».

Reparto de la semana

Por qué importa

El módulo 5 te enseñó a construir la red dentro de una región. Este módulo trata lo que está entre tus usuarios y tu región: cómo encuentran tu aplicación (DNS), cómo les llega rápido desde cualquier país (CDN y red global de AWS) y cómo se filtran los ataques antes de que toquen tus servidores.

En el examen aparece en:

• 3.4: «edge networking services with appropriate use cases (CloudFront, Global Accelerator)», topologías globales.
• 2.2: Route 53 como parte de la infraestructura global, estrategias de failover y diseños de DR multirregión.
• 1.2: amenazas externas (DDoS, inyección SQL) y la integración de AWS Shield y AWS WAF.
• 1.3: cifrado en tránsito con ACM y TLS, renovación de certificados.
• 2.1 y 4.4: aceleradores en el borde y caché para escalar y abaratar la salida a internet.

DNS y Amazon Route 53

Amazon Route 53 es el servicio DNS gestionado de AWS. Hace tres cosas:

1. Registro de dominios (comprar midominio.com).
2. DNS autoritativo: responde por tus dominios desde zonas alojadas (hosted zones).
3. Health checks (comprobaciones de estado) que cambian las respuestas DNS cuando algo falla.

Es un servicio global con un SLA de disponibilidad del 100 % (consulta el SLA de Route 53).

Zonas alojadas

• Zona pública (public hosted zone): responde a consultas desde internet para un dominio.
• Zona privada (private hosted zone): responde solo dentro de las VPC asociadas (pueden ser de varias cuentas y regiones). Requiere que la VPC tenga activados enableDnsHostnames y enableDnsSupport. Útil para nombres internos (db.interno.empresa).
• Precio: 0,50 USD al mes por zona (las 25 primeras), sin prorrateo; una zona borrada en menos de 12 horas no se cobra (Route 53 pricing).

Registros más usados

El TTL (time to live) indica cuántos segundos pueden cachear los resolvers una respuesta. TTL bajo = cambios (y failover) más rápidos, pero más consultas (y más coste).

Alias vs CNAME

El registro alias es una extensión de Route 53 que apunta a recursos de AWS y se comporta como un A/AAAA.

Las políticas de enrutamiento

Cada registro tiene una routing policy que decide qué responde Route 53. Es de lo más preguntado del bloque.

Detalles que el examen usa:

• Latency ≠ geolocation: latency optimiza rendimiento; geolocation obedece a la ubicación (legal, idioma, licencias) aunque no sea la más rápida.
• En geolocation, crea siempre un registro por defecto (default): si no hay coincidencia y no existe, Route 53 responde «sin respuesta».
• Geoproximity se configura con Traffic Flow (editor visual de políticas) o directamente en los registros; el bias amplía (+) o encoge (−) la región de influencia.
• Multivalue no sustituye a un balanceador: es DNS, con la caché de los clientes de por medio.
• Todas, salvo IP-based, se pueden usar también en zonas privadas.
• Se pueden anidar (por ejemplo, latency entre regiones y, dentro de cada región, weighted entre dos balanceadores) usando alias hacia otros registros.

Health checks

Un health check comprueba periódicamente un recurso y Route 53 usa su estado para dejar de responder con registros no sanos.

Tipos:

• De endpoint: HTTP, HTTPS o TCP contra una IP o un nombre. Los health checkers están repartidos por el mundo y el endpoint se considera sano si más del 18 % de ellos lo ven sano. Intervalo de 30 s (estándar) o 10 s (rápido) y un umbral de fallos consecutivos. Con HTTP/HTTPS, el endpoint debe devolver 2xx o 3xx; opcionalmente, buscar un texto en los primeros 5.120 bytes de la respuesta.
• Calculados (calculated): combinan hasta 255 health checks hijos («sano si al menos 2 de 3 lo están»).
• Basados en una alarma de CloudWatch: su estado sigue el flujo de datos de la alarma.

Precio: hasta 50 health checks de endpoints de AWS gratis; después 0,50 USD al mes cada uno; 0,75 USD para endpoints fuera de AWS; las funciones opcionales (HTTPS, búsqueda de texto, intervalo rápido, medición de latencia) cuestan aparte (Route 53 pricing).

Failover con Route 53: activo-pasivo y activo-activo

flowchart LR
  u["Usuarios"]
  r53["Route 53<br/>registro failover app.ejemplo.com"]
  hc["Health check del primario"]
  subgraph p["Región primaria (eu-south-2)"]
    alb1["ALB + ASG"]
  end
  subgraph s["Región secundaria (eu-west-1)"]
    alb2["ALB + ASG (warm standby)"]
  end
  u --> r53
  r53 -- "PRIMARY (mientras esté sano)" --> alb1
  r53 -. "SECONDARY (si el primario falla)" .-> alb2
  hc --> alb1

• Activo-pasivo: política failover (registro PRIMARY con health check y SECONDARY). El secundario puede ser otra región o una página estática de mantenimiento en S3.
• Activo-activo: políticas weighted, latency o multivalue con health checks en todos los registros; si uno cae, Route 53 deja de devolverlo.
• Con alias a ALB, activa Evaluate target health para heredar la salud del balanceador sin crear health checks propios.
• El failover por DNS depende del TTL y de las cachés de los clientes: no es instantáneo. Si necesitas conmutación en segundos sin depender del DNS, piensa en Global Accelerator.
• Para conmutaciones regionales muy controladas existe Amazon Application Recovery Controller (ARC), con routing controls que actúan como interruptores sobre registros failover.

Route 53 Resolver y DNS híbrido

Cada VPC tiene un resolver DNS de Amazon en la dirección base de la VPC + 2 (por ejemplo 10.0.0.2). AWS lo llama ahora Route 53 VPC Resolver (antes, Route 53 Resolver). Resuelve nombres públicos, nombres internos de EC2 y zonas privadas asociadas.

Para una red híbrida (VPC + centro de datos por VPN o Direct Connect):

• Inbound endpoint: IP privadas en tu VPC a las que el DNS on-premises reenvía las consultas de dominios de AWS (por ejemplo, tu zona privada aws.empresa.com).
• Outbound endpoint + reglas de reenvío (forwarding rules): la VPC reenvía las consultas de dominios on-premises (corp.empresa.com) a tus servidores DNS locales. Las reglas se comparten entre cuentas con AWS RAM.
• Coste: 0,125 USD por hora por interfaz de red del endpoint (eu-south-2, API de precios, septiembre de 2026). Cada endpoint necesita al menos dos direcciones IP, y lo recomendado es repartirlas en dos AZ distintas para que sea altamente disponible.

flowchart LR
  subgraph onprem["Centro de datos"]
    dnsl["DNS local (corp.empresa.com)"]
    srv["Servidores"]
  end
  subgraph vpc["VPC"]
    inb["Inbound endpoint"]
    outb["Outbound endpoint + regla corp.empresa.com"]
    res["VPC Resolver (VPC+2)<br/>zona privada aws.empresa.com"]
    ec2["EC2"]
  end
  srv --> dnsl
  dnsl -- "reenvía aws.empresa.com (VPN/DX)" --> inb --> res
  ec2 --> res --> outb -- "reenvía corp.empresa.com (VPN/DX)" --> dnsl

• Route 53 Resolver DNS Firewall: filtra las consultas DNS salientes de tus VPC (listas de dominios permitidos o bloqueados), por ejemplo para frenar la exfiltración por DNS. Se gestiona centralmente con Firewall Manager.

Amazon CloudFront

Amazon CloudFront es la CDN (content delivery network, red de distribución de contenidos) de AWS: cientos de ubicaciones en el borde (edge locations) y cachés regionales que sirven tu contenido cerca del usuario.

Beneficios:

• Menos latencia: el contenido se cachea cerca del usuario y las conexiones viajan por la red de AWS.
• Menos carga y menos coste en el origen: la caché absorbe las peticiones repetidas; la transferencia del origen de AWS a CloudFront es gratis.
• Seguridad en el borde: TLS, AWS WAF, AWS Shield Standard incluido, restricción geográfica, contenido privado.
• Sirve contenido estático y dinámico (HTTP/HTTPS, WebSocket), incluso sin caché (APIs), porque acelera la conexión.

Orígenes

Una distribución tiene uno o varios orígenes (de dónde saca el contenido):

• Origin groups: primario + secundario con origin failover si el primario devuelve códigos configurados (por ejemplo 500, 502, 503, 504) o no responde. Solo para peticiones GET, HEAD y OPTIONS.
• Origin Shield: una capa de caché adicional en una región para reducir aún más las peticiones al origen.

OAC (y OAI, heredado)

Para servir un bucket S3 privado solo a través de CloudFront:

• Origin access control (OAC) — la opción recomendada: CloudFront firma sus peticiones a S3 (SigV4) y la bucket policy permite s3:GetObject al principal de servicio cloudfront.amazonaws.com solo para esa distribución (condición AWS:SourceArn). Admite SSE-KMS, peticiones dinámicas (PUT, DELETE) y todas las regiones, incluidas las que exigen opt-in.
• Origin access identity (OAI) — heredado (legacy): no admite SSE-KMS, ni PUT/POST/DELETE, ni las regiones lanzadas después de enero de 2023. Si un enunciado antiguo dice OAI, entiéndelo como «restringir el bucket a CloudFront»; en una respuesta moderna, elige OAC.

Bucket policy para OAC (la usarás en el lab 11):

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

Comportamientos de caché (cache behaviors)

Un cache behavior asocia un patrón de ruta (/api/*, /img/*, *.jpg, y el comportamiento por defecto *) con un origen y una configuración:

• Viewer protocol policy: HTTP y HTTPS, redirigir HTTP a HTTPS, o solo HTTPS.
• Métodos permitidos: GET, HEAD; + OPTIONS; o todos (PUT, POST, PATCH, DELETE) para APIs.
• Cache policy: qué forma la clave de caché (cabeceras, cookies, query strings) y los TTL. Cuantos menos elementos en la clave de caché, más aciertos (cache hit ratio). Hay políticas gestionadas como CachingOptimized y CachingDisabled.
• Origin request policy: qué se reenvía al origen sin que forme parte de la clave de caché.
• Response headers policy: cabeceras que CloudFront añade a la respuesta (CORS, seguridad como HSTS).
• Asociación de funciones en el borde, field-level encryption, signed URLs/cookies (trusted key groups).

Ejemplo típico: /api/* → ALB con CachingDisabled y todos los métodos; * (por defecto) → S3 con CachingOptimized.

TTL: cuánto tiempo se cachea

• Cada cache policy tiene TTL mínimo, por defecto y máximo. Sin cache policy, el TTL por defecto es 24 horas. La política gestionada CachingOptimized usa mínimo 1 s, por defecto 86.400 s (24 h) y máximo 31.536.000 s (365 días).
• El origen puede fijar la duración por objeto con Cache-Control: max-age (o s-maxage, solo para cachés compartidas) o Expires; CloudFront la acota entre el mínimo y el máximo.
• Cuando un objeto caduca, CloudFront revalida con el origen: 304 Not Modified si no ha cambiado.
• stale-while-revalidate y stale-if-error permiten servir contenido caducado mientras se refresca o si el origen falla.

Invalidaciones y versionado

• Una invalidación elimina objetos de todas las cachés antes de que caduquen: aws cloudfront create-invalidation --distribution-id ID --paths "/index.html" "/img/*".
• Las primeras 1.000 rutas de invalidación al mes son gratis (por cuenta); después se paga por ruta. Un comodín (/img/*) cuenta como una ruta.
• Mejor práctica para contenido que cambia a menudo: versionar los nombres de fichero (app.v42.js) en lugar de invalidar: es inmediato, gratuito y los navegadores tampoco sirven la versión vieja.

HTTPS en CloudFront

• Dominio por defecto d1234abcd.cloudfront.net con certificado de AWS.
• Para tu dominio (www.ejemplo.com): añádelo como alternate domain name (CNAME) de la distribución y asocia un certificado de ACM en la región us-east-1 (N. Virginia). Esto es una trampa clásica del examen.
• SNI (Server Name Indication) es la opción normal y sin coste adicional.
• Entre CloudFront y el origen: origin protocol policy (HTTP, HTTPS o match viewer). Con OAC y firma activada, CloudFront → S3 va siempre por HTTPS.

Contenido privado: signed URLs y signed cookies

Para contenido de pago o restringido (vídeos para suscriptores, descargas de clientes):

• Tu aplicación autentica al usuario y genera una signed URL o unas signed cookies con una clave privada; CloudFront las verifica con la clave pública de un trusted key group (recomendado frente a las antiguas CloudFront key pairs, que exigen el usuario root).
• Pueden incluir fecha de caducidad, fecha de inicio y rango de IP (política personalizada).

Si se usan ambas para el mismo fichero, prevalece la signed URL.

Restricción geográfica (geo-restriction)

• Allowlist (solo estos países) o blocklist (todos menos estos), a nivel de toda la distribución y por país. Los usuarios bloqueados reciben un 403 Forbidden.
• CloudFront determina el país con una base de datos de terceros (precisión global del 99,8 % según AWS).
• Para granularidad menor que el país o para bloquear solo parte del contenido: servicio de geolocalización de terceros + signed URLs, o reglas geo match de AWS WAF (con más condiciones).

«Por derechos de distribución, el contenido no puede verse fuera de España» → CloudFront geo-restriction (allowlist). Si la pregunta es de DNS (enviar a los usuarios a un despliegue u otro según su país) → Route 53 geolocation.

Field-level encryption

Cifra campos concretos de un formulario POST (hasta 10 campos, por ejemplo número de tarjeta) en el borde, con una clave pública RSA que subes a CloudFront. El dato viaja cifrado por todo tu stack y solo el componente que tiene la clave privada (por ejemplo, el microservicio de pagos) puede descifrarlo. Requiere HTTPS entre usuario, CloudFront y origen.

«Solo el servicio de pagos debe poder leer el número de tarjeta, aunque la petición pase por varios servidores web» → field-level encryption.

CloudFront Functions vs Lambda@Edge

Dos formas de ejecutar código en el borde:

Lambda@Edge se crea en us-east-1 y CloudFront la replica a las ubicaciones del borde.

Precio y clases de precio

• Pagas transferencia de CloudFront a internet (por GB, según la zona geográfica) y peticiones; la transferencia desde orígenes de AWS es gratis.
• Capa gratuita permanente: 1 TB de transferencia de salida, 10 millones de peticiones y 2 millones de invocaciones de CloudFront Functions al mes.
• Price classes (PriceClass_All, _200, _100): excluyen las ubicaciones más caras a cambio de más latencia para los usuarios de esas zonas.
• Existen también planes de tarifa plana (Free, Pro, Business, Premium) que agrupan CDN, WAF, protección DDoS, DNS y certificados sin cargos por exceso (CloudFront pricing).

AWS Global Accelerator

AWS Global Accelerator mejora la disponibilidad y el rendimiento de aplicaciones TCP y UDP metiendo el tráfico en la red global de AWS desde la ubicación del borde más cercana al usuario.

• Te da 2 direcciones IPv4 estáticas anycast (4 con dual-stack: 2 IPv4 + 2 IPv6), anunciadas desde todas las ubicaciones del borde. Puedes usar tus propias IP (BYOIP).
• Endpoints (accelerator estándar): ALB, NLB, instancias EC2 y Elastic IP, en una o varias regiones, agrupados en endpoint groups por región.
• Health checks continuos y conmutación casi inmediata a otro endpoint o región sano, sin depender del TTL del DNS (las IP no cambian).
• Traffic dials (porcentaje de tráfico por grupo regional) y pesos por endpoint (0-255, por defecto 128): despliegues blue/green y pruebas.
• Client affinity para mantener al mismo cliente en el mismo endpoint.
• Custom routing accelerators: mapean usuarios a instancias y puertos concretos (juegos, VoIP).
• Termina las conexiones TCP en el borde (menos latencia de establecimiento) y no cachea contenido.
• Coste: 0,025 USD por hora por acelerador más un recargo por GB (Data Transfer-Premium) según regiones de origen y destino.

CloudFront vs Global Accelerator

Protección perimetral

Amenazas externas (task 1.2)

• DDoS (denegación de servicio distribuida): inundaciones de capa 3/4 (SYN flood, reflexión UDP) o de capa 7 (inundación de peticiones HTTP).
• Ataques a la aplicación: inyección SQL, cross-site scripting (XSS), inclusión de ficheros, bots, credential stuffing.

AWS los cubre con Shield (DDoS), WAF (capa 7) y, para gestionarlo todo en varias cuentas, Firewall Manager. Arquitectura recomendada frente a DDoS: exponer solo recursos «de borde» (CloudFront, Route 53, Global Accelerator) y ELB, con Auto Scaling detrás, y no exponer instancias directamente.

AWS WAF

AWS WAF es un cortafuegos de aplicaciones web (capa 7) que inspecciona las peticiones HTTP/HTTPS.

• Se asocia a: CloudFront, Application Load Balancer, API Gateway (REST), AppSync (GraphQL), Cognito user pools, App Runner, Verified Access y Amplify, entre otros. No a un NLB ni directamente a una instancia EC2.
• La unidad es la web ACL (en la consola nueva, protection pack (web ACL)): una lista de reglas con prioridad y una acción por defecto (Allow o Block).
• Para CloudFront, la web ACL se crea en us-east-1 (ámbito Global (CloudFront)); para recursos regionales, en la misma región que el recurso.
• Cada recurso tiene como mucho una web ACL; una web ACL puede proteger varios recursos.

Tipos de reglas y condiciones:

• Coincidencias: IP (conjuntos de IP), país (geo match), cabeceras, URI, query string, cuerpo, tamaño, expresiones regulares, inyección SQL (SQLi) y XSS.
• Rate-based rules: cuentan peticiones por IP (u otras claves) en una ventana de 60, 120, 300 o 600 s y aplican la acción cuando se supera el límite (mínimo 10). Frenan inundaciones HTTP, scraping y fuerza bruta.
• Managed rule groups: conjuntos mantenidos por AWS (AWS Managed Rules: Core rule set AWSManagedRulesCommonRuleSet, Known bad inputs, SQL database, IP reputation, Bot Control, Account Takeover Prevention…) o por vendedores de AWS Marketplace.
• Acciones: Allow, Block, Count (para probar sin bloquear), CAPTCHA y Challenge.
• La capacidad de una web ACL se mide en WCU (web ACL capacity units).
• Registros de peticiones a CloudWatch Logs, S3 o Data Firehose; métricas en CloudWatch y muestras de peticiones.

AWS Shield Standard vs Shield Advanced

AWS Firewall Manager

Servicio para gestionar de forma centralizada las reglas de protección en todas las cuentas de una organización:

• Requisitos: AWS Organizations (con todas las funciones), una cuenta administradora de Firewall Manager y AWS Config activado en las cuentas y regiones.
• Tipos de política: AWS WAF, Shield Advanced, security groups de VPC, network ACLs, AWS Network Firewall, Route 53 Resolver DNS Firewall y cortafuegos de terceros (Marketplace).
• Aplica las políticas automáticamente a cuentas y recursos nuevos (por ejemplo, todo ALB nuevo recibe la web ACL corporativa) e informa del cumplimiento.

«Una empresa con 100 cuentas quiere que todos los ALB, actuales y futuros, tengan las mismas reglas de WAF» → AWS Firewall Manager. WAF sola exigiría configurarlo cuenta a cuenta.

AWS Certificate Manager (ACM)

ACM emite, almacena y renueva automáticamente certificados TLS para cifrar en tránsito (task 1.3).

• Certificados públicos gratuitos para usarlos con servicios integrados: ELB, CloudFront, API Gateway, Elastic Beanstalk, App Runner, Amplify, Cognito, OpenSearch, Network Firewall (inspección TLS)…
• Validación del dominio por DNS (recomendada: con un CNAME en Route 53 la renovación es automática) o por email. Hay validación HTTP solo para ciertos casos de CloudFront.
• Validez actual de los certificados públicos de ACM: 198 días; ACM empieza a renovarlos 45 días antes de que caduquen (60 días en certificados antiguos) y solo si la validación sigue siendo posible.
• Regionales: el certificado debe estar en la misma región que el ALB o API Gateway regional, y en us-east-1 para CloudFront (y para API Gateway edge-optimized).
• No se pueden instalar directamente en una instancia EC2 los certificados gestionados (salvo con Nitro Enclaves). Para EC2: certificados exportables de ACM (de pago), ACME o certificados de terceros.
• Importar certificados de otras autoridades es posible, pero ACM no los renueva: tienes que vigilar la caducidad (ACM emite eventos de caducidad a EventBridge y AWS Config tiene una regla gestionada para ello).
• Para certificados privados (servicios internos, mTLS): AWS Private CA.

Arquitecturas globales de referencia

Sitio estático global y seguro

flowchart LR
  u["Usuarios en todo el mundo"]
  r53["Route 53<br/>alias www → CloudFront"]
  waf["AWS WAF (us-east-1)<br/>managed rules + rate-based"]
  cf["CloudFront<br/>certificado ACM us-east-1<br/>Shield Standard"]
  s3[("S3 privado<br/>Block Public Access + OAC")]
  u --> r53 --> cf
  waf -. "asociada" .-> cf
  cf -- "OAC (SigV4)" --> s3

Aplicación multirregión activo-pasivo

• Región primaria y secundaria con ALB + Auto Scaling y base de datos replicada (Aurora Global Database o DynamoDB global tables, módulo 4).
• Route 53 failover con health check sobre el ALB primario (o Global Accelerator con dos endpoint groups y traffic dial 100/0 para conmutar en segundos).
• CloudFront delante si hay contenido cacheable, con origin group primario/secundario.

Trampas típicas del examen

Palabras clave en inglés: global users, lowest latency, static IP addresses, edge locations, cache hit ratio, origin access control, restrict access to S3 to CloudFront only, geo-restriction, distribution rights, SQL injection, cross-site scripting, rate limiting, DDoS protection, cost protection, centrally manage across accounts, certificate renewal.

Resumen

• Route 53: zonas públicas y privadas; alias (ápice, gratis a recursos de AWS) frente a CNAME; ocho políticas: simple, weighted, latency, failover, geolocation, geoproximity, multivalue, IP-based.
• Health checks: HTTP/HTTPS/TCP desde internet (sano si más del 18 % de checkers lo ven sano), calculados, o basados en alarmas de CloudWatch para recursos privados. Failover activo-pasivo con la política failover; activo-activo con health checks en todos los registros.
• Route 53 Resolver: VPC+2; inbound (on-prem → AWS) y outbound + reglas (AWS → on-prem) para DNS híbrido; DNS Firewall.
• CloudFront: orígenes S3 (con OAC), ALB/EC2, VPC origins; cache behaviors, cache policies y TTL; invalidaciones (1.000 rutas gratis al mes) o versionado; certificado de ACM en us-east-1.
• Contenido privado: signed URL (un fichero) vs signed cookies (muchos ficheros); geo-restriction por país; field-level encryption para campos sensibles.
• CloudFront Functions (ligeras, submilisegundo, cabeceras y redirecciones) vs Lambda@Edge (red, cuerpo, SDK, hasta 30 s).
• Global Accelerator: 2 IP anycast estáticas, TCP/UDP, sin caché, failover en segundos.
• WAF (capa 7, reglas, managed rules, rate-based; us-east-1 para CloudFront), Shield Standard (gratis, capa 3/4) y Advanced (3.000 USD/mes, SRT, protección de costes), Firewall Manager (políticas centralizadas en Organizations con AWS Config).
• ACM: certificados públicos gratuitos, renovación automática con validación DNS, regionales; validez actual de 198 días.

Cobertura del temario

Task statements principales de este módulo: 3.4, 1.2 (amenazas externas y servicios de protección), 2.2 (infraestructura global y failover) y la parte de ACM de 1.3.

Task 3.4: Determine high-performing and/or scalable network architectures

Task 1.2: Design secure workloads and applications

Task 2.2: Design highly available and/or fault-tolerant architectures

Task 1.3: Determine appropriate data security controls (parte de ACM)

Otros task statements tocados

• 2.1 «How to appropriately use edge accelerators (CDN)» y «caching strategies»: CloudFront (caché, TTL, cache policies).
• 4.4 «Determining strategic needs for CDNs and edge caching» y rutas con Global Accelerator: «Precio y clases de precio», «CloudFront vs Global Accelerator»; «Network services with appropriate use cases (DNS)»: Route 53.

Practica lo aprendido

Documentación oficial para ampliar

• Choosing a routing policy (Route 53)
• Choosing between alias and non-alias records
• How Route 53 determines whether a health check is healthy
• What is Route 53 VPC Resolver?
• Restrict access to an Amazon S3 origin (OAC)
• Differences between CloudFront Functions and Lambda@Edge
• Decide to use signed URLs or signed cookies
• How AWS Global Accelerator works
• Resources that you can protect with AWS WAF
• AWS Shield Advanced overview
• AWS Firewall Manager prerequisites
• Services integrated with AWS Certificate Manager
• Amazon CloudFront pricing