Para el SAP-C02, el networking va más allá de VPCs básicas. CloudFront avanzado, VPC Endpoints, Enhanced Networking y los patrones de PrivateLink son fundamentales para diseñar aplicaciones de alto rendimiento y seguridad.
Contenido
CloudFront es la CDN global de AWS con 450+ edge locations. Para el SAP-C02, el foco está en las funciones avanzadas: caching granular, Lambda@Edge, CloudFront Functions, seguridad y Origin Access Control.
Cache Behaviors — granularidad de caching
Un distribution de CloudFront puede tener múltiples Cache Behaviors con diferentes configs de caché por path pattern.
Lambda@Edge y CloudFront Functions
Lambda@Edge
Ejecuta código Node.js o Python en los edge locations. Modificar requests/responses. Casos: A/B testing, personalización de contenido, validación de JWT, redirecciones complejas. Mayor latencia que CF Functions pero más potente.
CloudFront Functions
JavaScript ultra-ligero ejecutado en el edge. Sub-ms de latencia. Para: URL rewrites/redirects, header manipulation, simple auth. 10x más barato que Lambda@Edge pero con limitaciones (max 2ms, no puede hacer fetch).
Origin Access Control (OAC)
OAC reemplaza al antiguo OAI (Origin Access Identity). Permite que CloudFront acceda a S3 privado usando SigV4 signing, sin exponer el bucket al público.
CloudFront Signed URLs vs Signed Cookies
Signed URLs
Un URL por objeto, con expiración. Para distribución de archivos individuales (ej: video descargable, documento PDF de reporte).
Signed Cookies
Acceso a múltiples archivos en una sesión (ej: usuario premium ve todos los videos del catálogo). No modifica URLs — el acceso viene del cookie.
Origin Groups permiten definir un Primary y un Secondary origin. Si el Primary devuelve errores (4xx, 5xx configurables), CloudFront automáticamente hace failover al Secondary. Patrón fundamental para DR a nivel CDN.
Caso de uso: S3 static website con DR
Primary: S3 bucket en us-east-1. Secondary: S3 bucket replicado en us-west-2. Si us-east-1 da errores, CloudFront sirve desde us-west-2 automáticamente.
Caso de uso: ALB con fallback a S3
Primary: ALB en EC2. Secondary: S3 bucket con versión estática de la app. Si EC2 está caído, se sirve la versión estática (degraded pero disponible).
| Tipo | Servicios | Costo | Cómo funciona |
|---|---|---|---|
| Gateway Endpoint | S3 y DynamoDB únicamente | Gratis | Actualiza la route table de la subnet para enrutar tráfico a S3/DynamoDB sin salir a internet. IP de destino = prefix list del servicio. |
| Interface Endpoint (PrivateLink) | 200+ servicios AWS y SaaS | De pago ($0.01/h + $0.01/GB) | Crea ENI en la subnet con IP privada. El tráfico va a esa ENI → backbone AWS. Soporta DNS privado para override del endpoint público. |
| Gateway Load Balancer Endpoint | Appliances de seguridad 3rd party | De pago | Para insertar appliances de inspección en el flujo de tráfico via GWLB y PrivateLink. |
VPC Endpoint Policies — control granular
Los VPC Endpoints soportan policies que restringen qué acciones y a qué recursos se puede acceder a través del endpoint. Complementan las bucket policies y SCPs.
Ejemplo: Endpoint S3 solo permite acceso al bucket de producción
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::prod-bucket/*"
}Cuándo usar Gateway vs Interface Endpoint para S3
Gateway Endpoint (S3)
Gratis, funciona para acceso desde la misma VPC vía route table. No funciona cross-VPC ni cross-region.
Interface Endpoint (S3)
De pago, pero funciona desde VPCs conectadas via TGW/Peering, desde on-premises via Direct Connect, y cross-region con VPC Peering.
Enhanced Networking usa SR-IOV (Single Root I/O Virtualization) para dar a las instancias acceso directo al hardware de red, eliminando el overhead del hypervisor. Resulta en mayor bandwidth, menor latencia y menor variabilidad de latencia (jitter).
ENA (Elastic Network Adapter)
Hasta 100 Gbps de red. Soportado en todas las instancias modernas. Recomendado para la mayoría de workloads.
Max: 100 Gbps
ENA Express
Extensión de ENA para reducir latencia a sub-100µs y jitter. Para HPC y aplicaciones sensibles a latencia. Instancias c6gn, p4d, etc.
Max: sub-100µs
Intel 82599 VF (legacy)
Hasta 10 Gbps. Instancias legacy (m4, c3, etc.). Reemplazado por ENA en instancias modernas.
Max: 10 Gbps
Placement Group + Enhanced Networking para HPC
Para HPC (simulaciones, ML distribuido, renderizado), la combinación óptima es: Cluster Placement Group (instancias en el mismo rack) + ENA Express (sub-100µs latencia) + instancias de la familia de HPC (hpc6a, p4d). Esto logra una red con rendimiento cercano al bare-metal.
ACM Public vs Private Certificates
ACM Public (gratis)
ACM Private CA (de pago)
ACM — limitaciones clave del examen
SaaS provider pattern
ISV expone su servicio via NLB → Endpoint Service. Los clientes crean Interface Endpoints en sus VPCs. El proveedor aprueba los endpoints (allowlist por AWS account ID). Los CIDRs de proveedor y cliente pueden solaparse — PrivateLink es inmune al solapamiento de CIDR.
Centralized shared services
Una cuenta de Shared Services expone herramientas internas (Jenkins, Artifactory, monitoring) via PrivateLink. Las cuentas de workload crean endpoints sin necesidad de VPC Peering ni TGW. Más seguro que Peering porque el consumer no puede iniciar conexiones al provider.
Cross-region PrivateLink
PrivateLink nativamente es intra-región. Para cross-region: crear una VPC en la misma región que el endpoint service, luego conectar esa VPC a otra región via VPC Peering o TGW. El endpoint service solo necesita estar en una región.
PrivateLink + on-premises
On-premises puede acceder a Interface Endpoints via Direct Connect o VPN (los endpoints son ENIs en la VPC, accesibles desde on-premises si las rutas están configuradas). Requiere habilitar Private DNS desde on-premises o usar el endpoint DNS DNS directamente.
Trampa: "Gateway Endpoints para S3 funcionan desde on-premises via Direct Connect"
Realidad: FALSO. Gateway Endpoints funcionan SOLO dentro de la VPC donde se crean (actualizan la route table). Para acceso a S3 desde on-premises sin internet, usa Interface Endpoint (PrivateLink) para S3.
Trampa: "ACM Public certificates pueden instalarse directamente en EC2"
Realidad: FALSO. Los certificados ACM Public no son exportables. Solo se usan con servicios AWS (ALB, CloudFront, API Gateway). Para EC2, necesitas ACM Private CA (exportable) o importar un certificado de terceros.
Trampa: "Lambda@Edge y CloudFront Functions tienen las mismas capacidades"
Realidad: Diferentes. CF Functions: JavaScript simple, sub-ms, solo viewer request/response, no puede hacer fetch HTTP ni acceder a AWS services. Lambda@Edge: Node/Python, hasta 5-30s de timeout, puede hacer fetch, acceder a DynamoDB, etc. — mucho más poderoso pero más lento y costoso.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa tiene instancias EC2 en subnets privadas (sin internet access) que necesitan acceder a S3 para descargar objetos. El equipo de seguridad requiere que el tráfico hacia S3 nunca atraviese internet público. ¿Cuál es la solución más rentable?
Inicia sesión para llevar tu progreso.