Cloud

AWS Solutions Architect Associate (SAA) 2018 – II

Posted on by Ruben Ortiz

Seguimos con los posts dedicados a mis apuntes para la certificación AWS Solutions Architect Associate (SAA).

⚠️ Actualización — octubre de 2026

Este artículo se publicó originalmente a partir de material de estudio de 2018. AWS ha cambiado considerablemente desde entonces.

Para mantener el valor histórico de los apuntes, no he eliminado la información antigua. Las partes que ya no son válidas aparecen marcadas como OBSOLETO o ACTUALIZACIÓN 2026, explicando cómo funciona actualmente el servicio.

Temas tratados

  • Amazon CloudFront
  • AWS WAF
  • AWS Storage Gateway
  • AWS Snowball y Snow Family
  • Enlaces de interés

Amazon CloudFront

Amazon CloudFront es la CDN —Content Delivery Network— de AWS.

Su objetivo principal es distribuir contenido con baja latencia utilizando la red global de AWS y acercando los datos a los usuarios.

Terminología

Edge Location

Una Edge Location o ubicación de borde es un punto de presencia de la red global de AWS desde el que CloudFront puede servir contenido próximo al usuario.

Las Edge Locations son independientes de las regiones y zonas de disponibilidad de AWS.

CloudFront puede almacenar contenido en caché en estas ubicaciones, reduciendo la latencia al servir elementos como:

  • imágenes;
  • vídeos;
  • CSS;
  • JavaScript;
  • documentos;
  • APIs;
  • contenido dinámico.

⚠️ IMPRECISO — información original:

Una Edge Location puede utilizarse también para escribir contenido.

CloudFront puede aceptar métodos HTTP como POST, PUT, PATCH o DELETE y reenviarlos al origin cuando la distribución lo permite, pero una Edge Location no debe entenderse como almacenamiento persistente en el que escribimos datos.

También existen capas adicionales en la arquitectura de CloudFront, como las Regional Edge Caches, que ayudan a reducir todavía más las solicitudes realizadas al origin.

Origins

⚠️ IMPRECISO — información original:

Un origin puede ser un bucket S3, una instancia EC2, un ELB o Route53.

Actualización 2026

S3, EC2 y Elastic Load Balancing pueden formar parte de una arquitectura de origin.

Route53 no es un origin de CloudFront.

Route53 es un servicio DNS y puede utilizarse, por ejemplo, para hacer que:

www.example.com
       |
       v
   Route53
       |
       v
   CloudFront

pero el origin es el recurso al que CloudFront solicita realmente el contenido.

Actualmente CloudFront admite, entre otros:

  • Amazon S3.
  • Amazon EC2 y otros servidores HTTP.
  • Application Load Balancer.
  • Network Load Balancer.
  • Amazon API Gateway.
  • AWS Lambda Function URLs.
  • AWS Elemental MediaPackage.
  • grupos de origins.
  • VPC origins.

AWS permite incluso utilizar ALB, NLB o EC2 privados mediante CloudFront VPC origins.

Distribution

Una distribution es la configuración de CloudFront que define cómo se distribuye nuestro contenido.

Incluye conceptos como:

  • origins;
  • cache behaviors;
  • dominios;
  • certificados TLS;
  • políticas de caché;
  • headers;
  • restricciones geográficas;
  • funciones ejecutadas en el edge;
  • AWS WAF.

Web Distribution

⚠️ TERMINOLOGÍA HISTÓRICA

En los apuntes originales se diferenciaba entre:

  • Web Distribution.
  • RTMP Distribution.

Actualmente esta división ya no se utiliza de la misma manera.

CloudFront utiliza distribuciones estándar para la entrega de contenido HTTP/HTTPS.

RTMP

⛔ OBSOLETO

RTMP Distribution se utilizaba para streaming multimedia mediante Real-Time Messaging Protocol.

AWS retiró las distribuciones CloudFront RTMP el 31 de diciembre de 2020 y posteriormente eliminó su documentación del Developer Guide.

Para vídeo moderno se utilizan protocolos como HLS o DASH sobre HTTP/HTTPS y servicios como CloudFront, S3 o MediaPackage.

CloudFront Signed URLs vs Signed Cookies

El concepto original continúa siendo válido.

Signed URL

Una Signed URL se utiliza normalmente cuando queremos proporcionar acceso a un recurso concreto.

1 URL firmada = acceso a un recurso

Por ejemplo:

/download/software.zip

Signed Cookie

Una Signed Cookie es útil cuando queremos proporcionar acceso a múltiples recursos sin modificar todas las URLs.

Por ejemplo:

/videos/course/*

CloudFront recomienda utilizar Signed Cookies cuando queremos dar acceso a grupos de archivos, como todos los segmentos de vídeo HLS o el área privada de una aplicación.

Policies

Una política de CloudFront puede controlar elementos como:

  • fecha de expiración;
  • fecha a partir de la cual comienza el acceso;
  • dirección IP o rango de direcciones IP;
  • recursos a los que se permite acceder.

Las restricciones disponibles dependen de si utilizamos una canned policy o una custom policy.

Trusted Signers

⚠️ OBSOLETO COMO RECOMENDACIÓN — información original:

El key pair utilizado por CloudFront se crea y administra mediante el usuario root.

Ese era el mecanismo utilizado originalmente con los CloudFront key pairs asociados a cuentas AWS.

Actualización 2026

AWS recomienda actualmente utilizar:

CloudFront Trusted Key Groups

en lugar del sistema antiguo de Trusted Signers basado en cuentas AWS.

El mecanismo moderno funciona aproximadamente así:

Private key
     |
     | firma
     v
Signed URL / Cookie
     |
     v
CloudFront
     |
     | comprueba firma
     v
Public Key
     |
     v
Key Group

Un Key Group contiene una o varias claves públicas que CloudFront utiliza para validar las firmas.

AWS recomienda explícitamente Trusted Key Groups frente al antiguo sistema de Trusted Signers.

Esto elimina además la necesidad de basar una arquitectura moderna en key pairs administrados por el usuario root.

S3 Presigned URLs

Las S3 Presigned URLs siguen existiendo y no deben confundirse con las CloudFront Signed URLs.

Una URL prefirmada de S3 permite proporcionar acceso temporal a un objeto utilizando los permisos de la identidad AWS que genera la URL.

Por ejemplo:

Usuario
   |
   v
Presigned URL
   |
   v
S3

Características principales:

  • tienen una vida limitada;
  • utilizan los permisos de la identidad que las genera;
  • pueden permitir operaciones como GET o PUT;
  • no requieren entregar credenciales AWS al usuario final.

Si la URL se genera utilizando credenciales temporales, dejará de ser válida cuando dichas credenciales expiren, aunque se haya configurado una expiración posterior.

Por tanto:

CloudFront Signed URL

y

S3 Presigned URL

resuelven problemas parecidos, pero pertenecen a mecanismos distintos.

Proteger un origin S3: OAC

Esta funcionalidad no existía en los apuntes originales y actualmente es fundamental al trabajar con CloudFront y S3.

La arquitectura recomendada es:

Internet
   |
   v
CloudFront
   |
   | OAC
   v
S3 privado

CloudFront utiliza Origin Access Control (OAC) para autenticarse frente al bucket.

El bucket puede permanecer privado y permitir el acceso únicamente desde una distribución concreta de CloudFront.

⚠️ OAI — LEGACY

Origin Access Identity (OAI) sigue existiendo para arquitecturas antiguas, pero AWS recomienda utilizar OAC.

OAC soporta funcionalidades que OAI no cubre correctamente, entre ellas:

  • buckets en todas las regiones actuales;
  • SSE-KMS;
  • operaciones dinámicas como PUT y DELETE;
  • autenticación mediante SigV4.

Sobre este tema tengo un artículo específico:

Servir contenido con seguridad usando CloudFront, OAC y S3

Servir contenido con seguridad: CloudFront con OAC y S3

Lambda@Edge

Lambda@Edge permite ejecutar código asociado a eventos de CloudFront.

Puede intervenir en:

Viewer Request
Viewer Response
Origin Request
Origin Response

Esto permite implementar lógicas como:

  • redirects;
  • autenticación;
  • modificación de headers;
  • procesamiento de requests;
  • selección dinámica de origins.

CloudFront Functions

CloudFront Functions no existía cuando escribí originalmente estos apuntes.

Actualmente tenemos dos mecanismos principales para ejecutar lógica en el edge:

CloudFront Functions
          vs
Lambda@Edge

CloudFront Functions

Está pensado para operaciones extremadamente rápidas y ligeras, por ejemplo:

  • redirects;
  • rewrites;
  • normalización de URLs;
  • modificación de headers;
  • autorización sencilla.

Se ejecuta en eventos:

  • Viewer Request.
  • Viewer Response.

Puede escalar a millones de ejecuciones por segundo y sus funciones están diseñadas para ejecutarse en tiempos inferiores al milisegundo.

Lambda@Edge

Es más potente.

Permite también:

  • Origin Request.
  • Origin Response.
  • acceso de red;
  • más memoria;
  • tiempos de ejecución mayores;
  • acceso al body de determinadas solicitudes.

Por tanto, para una lógica sencilla:

CloudFront Functions

y para procesamiento más complejo:

Lambda@Edge

es una buena regla conceptual inicial.

AWS WAF

AWS WAF es el Web Application Firewall de AWS.

Permite inspeccionar solicitudes HTTP/HTTPS y bloquear o permitir tráfico según diferentes reglas.

Por ejemplo:

Internet
   |
   v
AWS WAF
   |
   v
CloudFront
   |
   v
Origin

Podemos crear reglas basadas en:

  • direcciones IP;
  • URI;
  • query strings;
  • headers;
  • patrones;
  • expresiones regulares;
  • tamaño de solicitudes;
  • comportamiento de bots;
  • número de peticiones.

También podemos utilizar AWS Managed Rules para protegernos frente a patrones de ataque conocidos.

WAF Classic

⛔ OBSOLETO

Muchos cursos y documentación de la época de estos apuntes hacen referencia a AWS WAF Classic.

AWS lanzó la versión actual de AWS WAF en noviembre de 2019.

El soporte de AWS WAF Classic terminó el 30 de septiembre de 2025.

Por tanto, cualquier arquitectura nueva debe utilizar el AWS WAF actual.

AWS Storage Gateway

AWS Storage Gateway permite conectar infraestructura on-premises con almacenamiento de AWS.

Conceptualmente:

Aplicaciones on-premises
          |
          v
   Storage Gateway
          |
          v
         AWS

Plataformas compatibles

⚠️ INCOMPLETO — información original:

Storage Gateway soporta Microsoft Hyper-V y VMware ESXi.

Es cierto, pero actualmente existen más posibilidades dependiendo del tipo de gateway.

Entre las plataformas soportadas encontramos:

  • VMware ESXi;
  • Microsoft Hyper-V;
  • Linux KVM;
  • Amazon EC2;
  • appliances físicos.

S3 File Gateway también admite otras plataformas como Nutanix AHV.

Cifrado en Storage Gateway

La información original continúa siendo esencialmente correcta.

Los datos transferidos entre Storage Gateway y AWS están protegidos mediante SSL/TLS.

De forma predeterminada, los datos almacenados por Storage Gateway en S3 utilizan:

SSE-S3

También es posible utilizar:

SSE-KMS

Actualización 2026

S3 File Gateway soporta además:

DSSE-KMS

Dual-layer Server-Side Encryption con AWS KMS.

Tipos de Storage Gateway

Actualmente AWS Storage Gateway ofrece soluciones:

File
Volume
Tape

En la documentación encontramos:

  • Amazon S3 File Gateway.
  • Amazon FSx File Gateway.
  • Volume Gateway.
  • Tape Gateway.

S3 File Gateway

⚠️ INCOMPLETO — información original:

File Gateway (NFS)

Actualmente S3 File Gateway admite tanto NFS como SMB.

La idea es presentar S3 mediante una interfaz tradicional de filesystem:

Servidor on-premises
        |
      NFS/SMB
        |
        v
 S3 File Gateway
        |
        v
       S3

Los archivos escritos en el filesystem se convierten en objetos de S3.

Existe una correspondencia aproximadamente:

archivo <-> objeto S3

y la ruta del fichero se transforma en la key del objeto.

FSx File Gateway

FSx File Gateway permitía proporcionar acceso local de baja latencia a shares almacenados en Amazon FSx for Windows File Server.

⚠️ CAMBIO DE DISPONIBILIDAD

Desde el 28 de octubre de 2024, FSx File Gateway ya no está disponible para clientes nuevos.

Los clientes que ya lo utilizaban pueden continuar usando el servicio.

Volume Gateway

Volume Gateway presenta discos virtuales mediante iSCSI.

Conceptualmente:

Servidor
   |
 iSCSI
   |
   v
Volume Gateway
   |
   v
AWS

Los datos pueden protegerse mediante snapshots point-in-time almacenados como snapshots de Amazon EBS.

Los snapshots son incrementales.

Existen dos modos principales:

  • Stored Volumes.
  • Cached Volumes.

Volume Gateway — Stored Volumes

Stored Volumes permite mantener el dataset principal localmente y enviar copias de seguridad de forma asíncrona a AWS.

Aplicación
   |
   v
Storage local
   |
   | async backup
   v
AWS
   |
   v
EBS Snapshots

Esto proporciona:

  • baja latencia para todo el dataset;
  • datos primarios on-premises;
  • copias duraderas fuera del datacenter.

La descripción original sigue siendo válida.

Volume Gateway — Cached Volumes

Cached Volumes utiliza AWS como almacenamiento principal y mantiene localmente los datos a los que se accede con mayor frecuencia.

Aplicación
   |
   v
Cache local
   |
   v
Volume Gateway
   |
   v
Amazon S3

El beneficio principal es reducir la cantidad de almacenamiento que debemos mantener on-premises mientras seguimos ofreciendo acceso de baja latencia a los datos utilizados frecuentemente.

Actualmente un cached volume puede tener hasta 32 TiB.

Un gateway puede disponer de hasta:

  • 32 volúmenes;
  • 1.024 TiB de almacenamiento total en cached volumes.

Para Stored Volumes:

  • máximo por volumen: 16 TiB;
  • máximo total por gateway: 512 TiB.

Actualización Storage Gateway 2020

En 2020 AWS anunció:

Era posible crear caches locales para Tape Gateway y Volume Gateway de hasta 64 TB, cuatro veces más grandes que anteriormente.

Esta mejora sigue teniendo relevancia histórica.

Actualmente Cached Volume Gateway admite hasta 64 TiB de cache local.

También se introdujo la posibilidad de programar límites de ancho de banda.

Esta funcionalidad continúa existiendo.

Volume Gateway y Tape Gateway permiten definir intervalos durante los que se limita:

  • subida;
  • descarga.

S3 File Gateway también permite programar límites, aunque con diferencias respecto a Volume y Tape Gateway.

AWS Snow Family

⚠️ Esta es probablemente la parte de estos apuntes que más ha cambiado desde 2018. ⚠️

Originalmente AWS ofrecía una familia creciente de dispositivos físicos para mover grandes cantidades de información cuando hacerlo mediante Internet resultaba demasiado lento.

Incluía tecnologías como:

  • Snowball.
  • Snowball Edge.
  • Snowmobile.
  • posteriormente Snowcone.

En 2026, la estrategia de AWS ha cambiado considerablemente.

AWS Import/Export

⚠️ CONTEXTO HISTÓRICO

Los servicios de Import/Export fueron precursores de servicios como Snowball.

La idea básica era mover grandes cantidades de información utilizando soportes físicos en lugar de depender exclusivamente de una conexión de red.

Posteriormente AWS fue evolucionando esta idea hacia los dispositivos Snow.

Snowball Standard

⛔ OBSOLETO PARA NUEVAS ARQUITECTURAS

El Snowball original o Snowball Standard fue la primera generación de dispositivos físicos de AWS destinados fundamentalmente a migraciones de datos.

Posteriormente fue sustituido funcionalmente por Snowball Edge.

No debería utilizarse Snowball Standard como referencia para diseñar actualmente una nueva migración.

Snowball Edge

Snowball Edge evolucionó el concepto original añadiendo:

  • mayor capacidad;
  • procesamiento local;
  • almacenamiento;
  • interfaces compatibles con S3;
  • NFS;
  • capacidad de ejecutar determinadas cargas en el edge.

Las generaciones posteriores llegaron a configuraciones como:

Snowball Edge Storage Optimized

Hasta 210 TB de almacenamiento utilizable.

Snowball Edge Compute Optimized

Hasta:

  • 104 vCPU;
  • 416 GB de memoria;
  • 28 TB NVMe.

Cambio importante de disponibilidad de Snowball Edge

⚠️ ACTUALIZACIÓN 2025/2026

Desde el 7 de noviembre de 2025, AWS Snowball Edge ya no está disponible para clientes nuevos.

AWS recomienda actualmente a clientes nuevos estudiar alternativas como:

  • AWS DataSync para transferencias online;
  • AWS Data Transfer Terminal para determinados escenarios de transferencia física;
  • soluciones de partners de AWS;
  • AWS Outposts para determinados casos de edge computing.

Además, AWS ha anunciado que el soporte de los dispositivos Snowball en las regiones comerciales terminará el 31 de diciembre de 2026.

Por tanto, Snowball debe entenderse actualmente principalmente como una tecnología legacy/transicional, no como la primera opción para nuevas arquitecturas.

Snowcone

Snowcone fue el dispositivo más pequeño de Snow Family.

⛔ SERVICIO RETIRADO

AWS dejó de aceptar pedidos de Snowcone el 12 de noviembre de 2024 y recomendó a los clientes migrar hacia otras alternativas.

Snowmobile

Snowmobile llevaba la idea de las transferencias físicas al extremo.

Era literalmente un contenedor transportado mediante camión diseñado para mover cantidades de datos del orden de exabytes.

Cada Snowmobile podía transportar aproximadamente:

100 PB

Conceptualmente:

Datacenter
    |
    v
Snowmobile
    |
    | transporte físico
    v
AWS

⛔ OBSOLETO — SERVICIO RETIRADO

AWS Snowmobile fue retirado el 14 de marzo de 2024.

Por tanto, esta sección debe considerarse exclusivamente histórica.

¿Qué utilizar actualmente para grandes migraciones?

El esquema mental de 2018 era aproximadamente:

¿Demasiados datos para enviarlos por red?
             |
             v
         Snowball
             |
             v
        Snowmobile

En 2026 el escenario es diferente.

Para una nueva arquitectura habría que evaluar:

                Datos on-premises
                       |
          +------------+-------------+
          |                          |
          v                          v
   Red suficiente               Red insuficiente
          |                          |
          v                          v
      DataSync             Data Transfer Terminal
 Direct Connect             / Partner solutions
          |
          v
         AWS

La elección depende de:

  • volumen de datos;
  • ancho de banda;
  • tiempo disponible;
  • conectividad;
  • ubicación;
  • requisitos de seguridad;
  • coste.

AWS Data Transfer Terminal

Este servicio no existía cuando escribí el artículo.

AWS Data Transfer Terminal proporciona ubicaciones físicas preparadas con conectividad de alta velocidad a la red de AWS.

En vez de que AWS envíe un dispositivo como Snowball:

AWS -> envía dispositivo -> cliente

el cliente lleva sus propios dispositivos a una instalación preparada:

Tus discos / SSD
        |
        v
Data Transfer Terminal
        |
     fibra
        |
        v
       AWS

Actualmente las instalaciones proporcionan conexiones de fibra de hasta 100 Gbps.

El servicio está disponible en este momento para clientes con AWS Enterprise Support.

Caso original: migración masiva de datos on-premises

El escenario original de mis apuntes era:

  1. Utilizar AWS SCT para procesar los datos localmente.
  2. Mover los datos al dispositivo AWS Snowball Edge.
  3. Enviar físicamente el dispositivo a AWS.
  4. AWS carga los datos en Amazon S3.
  5. Utilizar AWS SCT para cargar posteriormente los datos en Amazon Redshift.

El flujo era:

Data Warehouse
on-premises
     |
     v
AWS SCT Agent
     |
     v
Snowball Edge
     |
     | transporte físico
     v
AWS
     |
     v
Amazon S3
     |
     v
AWS SCT
     |
     v
Amazon Redshift

AWS SCT utiliza data extraction agents capaces de trabajar en segundo plano para extraer información de un data warehouse.

La documentación de AWS continúa describiendo este mecanismo y la integración de AWS SCT con Snowball Edge.

Actualización 2026 sobre este escenario

⚠️ ARQUITECTURA LEGACY PARA NUEVOS CLIENTES

Aunque la documentación de AWS SCT todavía describe la integración con Snowball Edge, un cliente nuevo ya no puede adoptar Snowball Edge como antes, porque Snowball Edge dejó de estar disponible para nuevos clientes en noviembre de 2025.

Por tanto, el flujo anterior continúa teniendo valor para entender cómo se realizaban estas migraciones y para determinados clientes existentes, pero no lo recomendaría como diseño de partida para una migración nueva en 2026.

Actualmente evaluaría primero:

  • AWS DataSync.
  • AWS Direct Connect.
  • transferencia directa mediante S3.
  • AWS Data Transfer Terminal.
  • soluciones de partners.

AWS Schema Conversion Tool

AWS SCT continúa existiendo.

Su función principal es facilitar conversiones de esquemas entre diferentes motores y plataformas de bases de datos y data warehouses.

También continúa soportando agentes de extracción para determinadas migraciones hacia Amazon Redshift.

Los agentes pueden extraer información desde tecnologías como:

  • Microsoft SQL Server;
  • Oracle;
  • Teradata;
  • Snowflake;
  • Netezza;
  • Greenplum;
  • Vertica;
  • BigQuery;
  • Azure Synapse Analytics.

La información puede cargarse primero en Amazon S3 y posteriormente importarse en Amazon Redshift.

Resumen de cambios desde 2018

El panorama de estos servicios ha cambiado considerablemente:

CloudFront

Antes:

Web Distribution
RTMP Distribution
Root CloudFront Key Pairs

Ahora:

CloudFront distributions
Signed URLs / Signed Cookies
Trusted Key Groups
OAC
CloudFront Functions
Lambda@Edge

RTMP desapareció en 2020.

AWS WAF

Antes:

AWS WAF Classic

Ahora:

AWS WAF
Managed Rules
Web ACLs
Rate-based rules

WAF Classic terminó su soporte en septiembre de 2025.

Storage Gateway

Los conceptos fundamentales de File, Volume y Tape Gateway continúan existiendo, aunque actualmente existen más protocolos, plataformas de despliegue y opciones de cifrado.

Snow Family

Este es el cambio más importante:

Snowball Standard      -> legacy
Snowmobile             -> retirado en 2024
Snowcone               -> retirado
Snowball Edge          -> cerrado a clientes nuevos
Snowball commercial    -> fin de soporte anunciado para 31/12/2026

Para nuevas transferencias AWS recomienda estudiar servicios como DataSync, Data Transfer Terminal, Direct Connect o soluciones de partners.

Links de interés

¿Te ha ayudado este artículo?

☕ Invítame a un café

Un comentario de “AWS Solutions Architect Associate (SAA) 2018 – II”

  1. Pingback: AWS certifications posts

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Rubenortiz.es
Powered by  GDPR Cookie Compliance
Información sobre privacidad

Este sitio web utiliza cookies para ofrecerte la mejor experiencia de usuario posible. La información sobre cookies se almacena en tu navegador y realiza funciones como reconocerte cuando vuelve a nuestro sitio web y ayudarme a comprender qué secciones de la web resultan más interesantes y útiles.