Capítulo 17¶

Amazon Web Services (AWS)¶

Comprendiendo la nube más utilizada del mundo¶

Objetivo¶

Este capítulo tiene como propósito que el lector comprenda qué es Amazon Web Services, cómo funciona su ecosistema, cuáles son sus servicios más importantes y cómo puede integrarse con Cloudflare y Firebase para construir arquitecturas modernas, escalables y de bajo costo.[cite:127][cite:129]

Al finalizar, el lector será capaz de seleccionar con más criterio los servicios de AWS adecuados para sus proyectos, distinguir cuándo conviene utilizar AWS y cuándo resulta más sensato optar por Cloudflare, Firebase o una arquitectura híbrida entre varias plataformas.[cite:127][cite:129]

¿Qué aprenderás?¶

Qué es AWS y cómo se organiza su infraestructura global.
Qué significan conceptos como Región, Availability Zone y Edge Location.[cite:127][cite:133]
Cómo pensar servicios fundamentales como IAM, S3, SES, Polly, Lambda, CloudFront, API Gateway, DynamoDB, RDS, EC2, Route 53 y CloudWatch.[cite:148][cite:128][cite:144][cite:142]
Cómo estimar costos y evitar cargos inesperados en AWS.[cite:144][cite:152][cite:155][cite:156]
Cómo diseñar arquitecturas híbridas combinando AWS con Cloudflare y Firebase.

Introducción¶

Imagina que una ciudad entera quiere digitalizarse. No basta con tener un solo edificio grande donde guardar todo. Hace falta energía, carreteras, zonas logísticas, centros administrativos, seguridad, almacenamiento, comunicación y sistemas especializados para distintos tipos de trabajo. AWS se parece a eso: no es un único servicio, sino una ciudad inmensa de infraestructura digital.

Esa es una de las razones por las que tantas personas se sienten abrumadas cuando se acercan por primera vez a AWS. La consola parece infinita, los nombres de los servicios se multiplican y cada problema parece tener al menos tres maneras diferentes de resolverse. Pero debajo de esa complejidad hay una lógica bastante clara: AWS ofrece piezas de infraestructura y servicios administrados para que puedas construir casi cualquier tipo de sistema, desde un sitio estático hasta una plataforma global con millones de usuarios.

Para el lector de este libro, la clave no es memorizar todos los servicios de AWS. La clave es entender su modelo mental. Una vez que eso ocurre, AWS deja de parecer un catálogo caótico y empieza a verse como un conjunto de herramientas. Algunas herramientas son pesadas y poderosas. Otras son ligeras y muy específicas. Algunas competirán directamente con Cloudflare o Firebase. Otras se integrarán perfectamente con ambas.

Este capítulo no está escrito para formar arquitectos certificados de AWS en una sola lectura. Está escrito para que un desarrollador, un docente que construye software o un emprendedor tecnológico comprenda lo suficiente como para tomar buenas decisiones. Esa es la diferencia entre usar la nube por imitación y usarla con criterio.

¿Qué es AWS?¶

Amazon Web Services, conocido como AWS, es la plataforma de computación en la nube de Amazon. AWS ofrece servicios de infraestructura, almacenamiento, red, bases de datos, seguridad, analítica, inteligencia artificial, mensajería, observabilidad y muchas otras categorías, distribuidos globalmente.[cite:129][cite:133]

Historia¶

AWS nació dentro de Amazon a partir de una necesidad muy concreta: convertir capacidades internas de infraestructura en servicios reutilizables. Con el tiempo, esa capacidad dejó de ser solo una ventaja interna y se transformó en una plataforma comercial para otras empresas y desarrolladores.

Amazon¶

Es importante recordar que AWS no surgió como una startup aislada, sino dentro de una empresa que ya operaba a gran escala. Amazon entendía problemas de infraestructura, elasticidad, picos de demanda y operación distribuida mucho antes de que la nube fuera una palabra común.

Filosofía¶

La filosofía de AWS puede resumirse así:

Ofrecer componentes reutilizables de infraestructura y plataforma.
Permitir que cada cliente construya exactamente la arquitectura que necesita.
Cobrar principalmente por uso.
Escalar desde proyectos pequeños hasta sistemas empresariales globales.

En otras palabras, AWS no intenta darte una sola forma de construir. Te da muchas piezas, y esa libertad es al mismo tiempo su mayor fortaleza y una de sus mayores fuentes de complejidad.

Cloud Computing¶

AWS es una plataforma de computación en la nube porque permite consumir recursos tecnológicos como servicio: cómputo, almacenamiento, red, base de datos, mensajería, monitoreo y más. En vez de comprar servidores físicos, instalar hardware o abrir centros de datos propios, el cliente alquila recursos y capacidades bajo demanda.

Infraestructura global¶

La infraestructura global de AWS se basa en Regiones y Availability Zones. AWS explica que su infraestructura en la nube está construida alrededor de AWS Regions y Availability Zones, donde cada Región es una ubicación física del mundo con múltiples zonas de disponibilidad, y cada Availability Zone consiste en uno o más centros de datos discretos con energía, red y conectividad redundantes.[cite:129][cite:133]

Regiones¶

Una Región es un área geográfica separada donde AWS ofrece servicios. AWS recomienda elegir la Región considerando latencia, cumplimiento, disponibilidad de servicios y necesidades operativas.[cite:127]

En la documentación oficial de regiones, AWS lista decenas de Regiones activas, incluyendo regiones como US East (N. Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Canada (Central), South America (São Paulo) y Mexico (Central), entre muchas otras.[cite:127]

Availability Zones¶

Las Availability Zones son ubicaciones aisladas dentro de una Región. AWS explica que cada Región tiene múltiples Availability Zones conectadas por redes de baja latencia, alto ancho de banda y gran redundancia, y que cada Availability Zone está formada por uno o más centros de datos físicamente separados.[cite:133]

Esto importa muchísimo: si despliegas todo en una sola zona, un fallo localizado puede dejar fuera tu aplicación. Si despliegas entre múltiples zonas, la arquitectura se vuelve más resistente.

Edge Locations¶

Aunque en los resultados consultados el detalle más profundo se centra en Regions y Availability Zones, AWS también distingue ubicaciones más cercanas al usuario final para servicios de borde como aceleración y entrega de contenido, lo que se conecta directamente con servicios como CloudFront y ciertos patrones globales de distribución.[cite:133][cite:137]

¿Por qué AWS domina el mercado?¶

No basta decir que AWS es “grande”. Hay razones estructurales detrás de su posición dominante.

Historia y madurez¶

AWS llegó antes que muchos competidores al mercado moderno de nube pública y convirtió esa ventaja temporal en ecosistema, documentación, tooling, certificaciones, integraciones y confianza empresarial.

Escalabilidad¶

Su modelo permite escalar desde una instancia pequeña hasta arquitecturas multinivel globales. Esa elasticidad hizo que muchas empresas lo adoptaran como infraestructura base para crecimiento.

Seguridad¶

AWS dedica una enorme parte de su modelo a controles de identidad, red, monitoreo, auditoría y separación de responsabilidades. Esa capacidad de gobernanza es una razón central de adopción corporativa.

Cantidad de servicios¶

Uno de los rasgos más visibles de AWS es su amplitud. Hay servicios para almacenamiento, correo, voz, cómputo, bases de datos, redes, seguridad, IA, analítica, video, IoT y casi cualquier capa imaginable de infraestructura.

Participación de mercado¶

Aunque este capítulo debe basarse exclusivamente en documentación oficial de AWS y no en reportes externos de mercado, el propio tamaño de su infraestructura global, la amplitud de su catálogo y su documentación reflejan por qué AWS se consolidó como referente principal de la computación en la nube.[cite:127][cite:129][cite:137]

Conceptos fundamentales¶

Antes de entrar servicio por servicio, conviene dominar el vocabulario.

Cloud Computing¶

Es el modelo en el que la infraestructura y muchos servicios tecnológicos se consumen como servicio a través de internet.

IaaS¶

Infrastructure as a Service significa que el proveedor entrega infraestructura base como máquinas virtuales, red, discos o balanceadores. EC2 es un ejemplo clásico.

PaaS¶

Platform as a Service sube el nivel de abstracción. En lugar de administrar directamente máquinas virtuales, el desarrollador trabaja sobre una plataforma gestionada.

SaaS¶

Software as a Service es el nivel donde el usuario consume un producto ya terminado.

Serverless¶

Serverless no significa que no existan servidores. Significa que el desarrollador no gestiona directamente la mayor parte de la infraestructura subyacente. AWS Lambda es un ejemplo claro.

Alta disponibilidad¶

Alta disponibilidad implica diseñar para que un fallo aislado no derribe todo el sistema. En AWS, esto suele significar distribuir componentes entre Availability Zones o incluso entre Regiones.[cite:133]

Elasticidad¶

La elasticidad es la capacidad de ajustar recursos según la demanda.

Escalabilidad horizontal¶

Consiste en agregar más instancias o nodos.

Escalabilidad vertical¶

Consiste en aumentar la capacidad de una máquina o recurso individual.

Pago por uso¶

AWS se apoya intensamente en un modelo pay-as-you-go. La ventaja es evitar inversión inicial grande. El riesgo es pagar más de lo esperado si no entiendes bien el patrón de consumo.

Arquitectura global¶

Regiones¶

AWS documenta que una Región es una zona geográfica separada y que cada cuenta puede operar en múltiples regiones según requisitos de latencia, regulación y disponibilidad de servicios.[cite:127][cite:133]

Availability Zones¶

Cada Región incluye múltiples Availability Zones. AWS recomienda desplegar aplicaciones en múltiples Availability Zones para que el sistema siga disponible incluso si una de ellas falla.[cite:133]

Edge Locations¶

Los puntos de borde acercan ciertos servicios al usuario final. Esto es especialmente relevante para distribución de contenido, aceleración y servicios orientados a baja latencia.

CloudFront¶

CloudFront es el CDN de AWS. Permite distribuir contenido desde una red global, aprovechar caché y acercar respuestas a los usuarios finales.

Red global¶

AWS opera una red privada y una infraestructura global que conecta regiones, zonas y servicios. Esta capa es invisible para muchos desarrolladores, pero es la base real de la promesa de escalabilidad y resiliencia.[cite:129][cite:133][cite:137]

Consola AWS¶

La consola de AWS es el panel de administración principal de la plataforma.

Panel principal¶

Desde la consola se accede a servicios, métricas, configuraciones, seguridad, facturación y recursos por cuenta.

Servicios¶

La consola organiza los servicios por categorías, pero a medida que crece la cuenta el buscador se vuelve la herramienta principal.

Facturación¶

La sección de Billing es crítica. No es un panel secundario: es una herramienta de supervivencia.

IAM¶

IAM aparece en casi cualquier flujo profesional porque controla quién puede hacer qué dentro de la cuenta.

Regiones¶

Muchas personas cometen errores porque olvidan que un recurso existe en una Región específica. La consola cambia contexto regional constantemente y eso afecta qué ves y qué administras.[cite:127][cite:133]

Buscador¶

El buscador de la consola es una de las herramientas más útiles cuando el catálogo ya resulta demasiado amplio para navegar visualmente.

Organización¶

La consola puede volverse caótica si no se trabaja con convención de nombres, etiquetas, separación por entornos y políticas claras.

IAM¶

Identity and Access Management, o IAM, es la base del control de acceso en AWS.

Usuarios¶

Un usuario IAM representa una identidad específica dentro de la cuenta.

Grupos¶

Los grupos permiten reunir usuarios con necesidades de permisos similares.

Roles¶

Los roles son fundamentales en AWS. A diferencia de un usuario tradicional, un rol puede ser asumido temporalmente por un servicio, una aplicación o una identidad federada.

Policies¶

Las policies definen permisos. Son documentos que describen qué acciones están permitidas o denegadas sobre qué recursos.

Permisos¶

La gran pregunta de IAM siempre es: quién puede hacer qué sobre qué recurso bajo qué condiciones.

Principio de mínimo privilegio¶

AWS recomienda seguir el principio de mínimo privilegio: conceder solamente los permisos necesarios para realizar una tarea y nada más. Esta es una de las prácticas más importantes de seguridad en toda cuenta AWS.

MFA¶

La autenticación multifactor es una práctica básica y altamente recomendada para proteger identidades sensibles dentro de la cuenta.

Buenas prácticas¶

No usar la cuenta raíz para trabajo diario.
Habilitar MFA.
Diseñar roles por servicio o flujo.
Revisar permisos periódicamente.
Evitar credenciales permanentes innecesarias.
Aplicar mínimo privilegio desde el principio.

Amazon S3¶

Amazon S3 es uno de los servicios más emblemáticos de AWS. AWS lo describe como un servicio de almacenamiento de objetos construido para recuperar cualquier cantidad de datos desde cualquier lugar.[cite:148][cite:149]

Buckets¶

Los buckets son contenedores lógicos donde se almacenan objetos.

Objetos¶

Un objeto es la unidad básica almacenada en S3: archivo más metadata asociada.

Versionado¶

S3 permite versionado, lo que resulta útil para protegerse frente a sobrescrituras o borrados accidentales.

Storage Classes¶

La página oficial de precios enumera varias storage classes, entre ellas S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval y S3 Glacier Deep Archive, cada una pensada para distintos patrones de acceso y costo.[cite:148]

Lifecycle¶

S3 soporta lifecycle rules para transicionar objetos entre clases de almacenamiento o para expirar datos. AWS documenta ejemplos específicos de configuración de S3 Lifecycle para este tipo de automatización.[cite:151]

Signed URLs¶

AWS documenta que se pueden usar presigned URLs para conceder acceso temporal a objetos en S3 sin necesidad de cambiar la bucket policy. Esto es crucial cuando se quiere compartir o subir archivos con control temporal de acceso.[cite:153]

Comparación con Cloudflare R2¶

S3 es el referente histórico del object storage moderno y su API se convirtió en estándar de facto. R2, en cambio, resulta especialmente atractivo cuando la arquitectura ya está muy centrada en Cloudflare y se quiere una integración muy directa con Workers, además de una propuesta distinta alrededor del egreso. En muchas arquitecturas híbridas, S3 sigue siendo la referencia conceptual incluso cuando se usan servicios compatibles con su API.

Amazon SES¶

Amazon Simple Email Service es el servicio de envío de correo de AWS.

Qué es¶

SES permite enviar correos transaccionales y masivos mediante API o SMTP.

Cómo funciona¶

El flujo mental es simple: una aplicación genera eventos de comunicación, SES envía el mensaje y la reputación, autenticación del dominio y políticas de envío determinan buena parte del éxito de entrega.

Sandbox¶

SES comienza con restricciones de sandbox en ciertos escenarios, lo que obliga a validar identidades y controlar a quién se envían correos durante la etapa inicial.

Producción¶

Pasar a producción implica endurecer autenticación, reputación y cumplimiento de buenas prácticas de email.

SMTP¶

SES puede usarse como servidor SMTP para aplicaciones que ya hablan ese protocolo.

API¶

También puede utilizarse mediante API, lo que suele ser preferible en arquitecturas modernas.

Autenticación¶

La autenticación del dominio y del remitente es esencial para reputación y entregabilidad.

DKIM, SPF y DMARC¶

Aunque estos mecanismos pertenecen al ecosistema general de email y no exclusivamente a AWS, son fundamentales al trabajar con SES. Sin una política sana de autenticación de correo, incluso el mejor servicio de envío puede ofrecer malos resultados prácticos.

Costos¶

Este capítulo no incluye cifras detalladas de SES porque en las búsquedas realizadas no se recuperó la página oficial específica de pricing de SES. Sería incorrecto inventarlas. Lo correcto es dejar claro que SES sigue un modelo de facturación por uso, y que en un desarrollo posterior este punto debe completarse con la página oficial de precios de Amazon SES.

Casos de uso¶

Correos de bienvenida.
Restablecimiento de contraseña.
Avisos institucionales.
Envíos masivos informativos.
Reportes automáticos.

Comparación con otros servicios de correo¶

SES suele resultar muy atractivo cuando se necesita volumen, integración programática y cercanía con otros servicios AWS. Sin embargo, exige más atención a autenticación de dominio y entregabilidad que algunas plataformas más enfocadas en experiencia de marketing.

Amazon Polly¶

Amazon Polly es el servicio de texto a voz de AWS.

Qué es¶

Convierte texto en voz sintética mediante varios tipos de voces y modos de síntesis.

Neural Voices¶

La página oficial de precios distingue voces estándar, neural, long-form y generative. Las Neural voices tienen un precio publicado de 16 dólares por cada 1 millón de caracteres fuera del free tier en la versión en inglés consultada.[cite:128]

Generative Voices¶

AWS también publica Generative voices con un precio de 30 dólares por cada 1 millón de caracteres fuera del free tier, según la página oficial consultada.[cite:128]

Idiomas¶

Polly soporta múltiples idiomas y voces, lo que lo vuelve útil para productos educativos, accesibilidad y automatización de contenido de audio.

SSML¶

AWS documenta el soporte de SSML como mecanismo para controlar pronunciación, pausas y matices de la síntesis. Esto es clave cuando el texto contiene nombres, abreviaturas o estructuras que necesitan mejor expresividad.[cite:132]

Pronunciación¶

La capacidad de ajustar pronunciación es especialmente importante en contextos educativos y de lectura institucional.

Costos¶

La página oficial de precios de Polly indica un modelo pay-as-you-go basado en caracteres procesados. Publica además un free tier de 5 millones de caracteres por mes para voces estándar, 1 millón para voces neural, 500 mil para long-form y 100 mil para generative durante los primeros 12 meses.[cite:128]

Casos de uso¶

Lectura de contenidos para accesibilidad.
Voz institucional automatizada.
Narración de materiales educativos.
Respuestas habladas en bots o asistentes.

Comparación con Azure, Google TTS y OpenAI¶

Para este capítulo no corresponde inventar comparativas de precios o capacidades con otros proveedores si no fueron consultadas sus páginas oficiales dentro de esta iteración. La comparación correcta aquí es conceptual: Polly destaca por su integración natural con AWS y por un modelo claro basado en caracteres procesados.[cite:128][cite:132]

AWS Lambda¶

Qué es¶

AWS Lambda es el servicio serverless de ejecución de código de AWS.

Serverless¶

Permite ejecutar funciones sin administrar servidores tradicionales.

Eventos¶

Lambda puede responder a eventos de otros servicios AWS, HTTP mediante API Gateway y múltiples disparadores integrados.

Escalabilidad¶

Una de sus fortalezas es escalar según demanda, aunque esa elasticidad debe entenderse junto con límites, costos y tiempos de ejecución.

Comparación con Cloudflare Workers¶

Lambda es muy flexible y muy bien integrada dentro del universo AWS. Workers, en cambio, suele ofrecer una experiencia más cercana al edge, con runtime más alineado a Web Standards y latencias excelentes para middleware, APIs ligeras y lógica distribuida. Lambda suele ganar cuando ya vives profundamente en AWS; Workers suele ganar cuando la arquitectura prioriza edge y simplicidad operativa en la capa pública.

AWS incluye en su free tier 1 millón de solicitudes gratuitas al mes y hasta 3.2 millones de segundos de tiempo de cómputo al mes para Lambda.[cite:144]

CloudFront¶

CDN¶

CloudFront es la red de distribución de contenido de AWS.

Caché¶

Su función principal es acercar contenido al usuario final y reducir latencia mediante caché distribuido.

Distribuciones¶

La configuración de CloudFront se articula alrededor de distribuciones, orígenes y políticas asociadas.

Comparación con Cloudflare CDN¶

CloudFront es una pieza potente dentro del ecosistema AWS, especialmente cuando el origen también vive allí. Cloudflare CDN, por su parte, suele ofrecer una experiencia muy fuerte en red perimetral, seguridad, caching y tooling edge. La diferencia no siempre está en “quién tiene CDN”, sino en qué tan central es el edge dentro de la arquitectura total.

Además, el free tier de AWS incluye para CloudFront 50 GB de transferencia de salida y 2 millones de solicitudes HTTP y HTTPS al mes durante el periodo aplicable del nivel gratuito.[cite:144]

API Gateway¶

Qué es¶

API Gateway es el servicio administrado de AWS para publicar, proteger y gestionar APIs.

Cómo funciona¶

Actúa como capa de entrada para clientes, enruta solicitudes y puede integrarse con Lambda y otros servicios.

Integración con Lambda¶

Una combinación clásica es API Gateway + Lambda: Gateway recibe la petición, Lambda ejecuta la lógica y devuelve la respuesta.

Casos de uso¶

APIs públicas.
Backends serverless.
Integración segura de microservicios.
Capa unificada de entrada para aplicaciones.

Comparación con Workers¶

API Gateway + Lambda es una solución madura y muy integrada con AWS. Workers puede resolver muchos casos similares con menos piezas visibles cuando el problema se ajusta bien al runtime edge de Cloudflare.

DynamoDB¶

Qué es¶

DynamoDB es la base de datos NoSQL administrada de AWS.

Base NoSQL¶

No sigue el modelo relacional clásico. Está pensada para acceso de baja latencia y alta escala bajo una lógica de clave, partición y patrones de acceso muy bien definidos.

Particiones¶

La forma en que se distribuyen datos y tráfico depende del diseño de claves y del patrón de acceso.

Escalabilidad¶

AWS ofrece un always free para DynamoDB con capacidad suficiente para hasta 200 millones de solicitudes al mes, expresadas como 25 unidades de escritura, 25 unidades de lectura y 25 GB de almacenamiento en la descripción consultada del free tier.[cite:144]

Comparación con Firestore y D1¶

Frente a Firestore, DynamoDB comparte la lógica de no-relacional y gran escala, pero tiene un modelo mental distinto y más orientado a diseño estricto de access patterns.
Frente a D1, DynamoDB ocupa casi el extremo opuesto: NoSQL distribuido frente a SQL ligero y administrado basado en SQLite.

RDS¶

Amazon RDS es el servicio administrado de bases de datos relacionales de AWS. La documentación consultada lo describe como un servicio que facilita configurar, operar y escalar una base de datos relacional en la nube, ofreciendo capacidad redimensionable y gestionando tareas administrativas comunes.[cite:135]

Motores soportados¶

AWS Free Tier menciona compatibilidad de RDS Single-AZ para MySQL, PostgreSQL, MariaDB, Oracle BYOL y SQL Server Express Edition en su descripción del nivel gratuito.[cite:144]

Casos de uso¶

RDS es apropiado cuando el modelo relacional es importante y no quieres operar totalmente una base por cuenta propia.

EC2¶

Máquinas virtuales¶

EC2 es el servicio de máquinas virtuales de AWS. La documentación consultada lo describe como cómputo redimensionable en la nube facturado por hora o segundo.[cite:135]

Tipos de instancia¶

AWS ofrece distintos tipos y tamaños de instancia según CPU, memoria y perfiles de uso.

Escalabilidad¶

EC2 puede escalar verticalmente eligiendo instancias más potentes o horizontalmente mediante múltiples instancias y auto scaling.

Casos de uso¶

Aplicaciones heredadas.
Software que necesita control completo del sistema operativo.
Cargas difíciles de adaptar a serverless.
Servicios que requieren procesos largos, agentes especiales o control fino.

El free tier incluye 750 horas por mes de ciertas instancias t2.micro o t3.micro, según región y sistema operativo elegible, durante 12 meses.[cite:144]

Route 53¶

DNS¶

Amazon Route 53 es el servicio DNS de AWS. La documentación consultada lo describe como un servicio altamente disponible y escalable de DNS, registro de dominios y health checking, diseñado para enrutar usuarios a aplicaciones de internet traduciendo nombres de dominio en direcciones IP.[cite:135]

Dominios¶

También permite comprar y administrar dominios.

Comparación con Cloudflare DNS¶

Route 53 funciona muy bien dentro del ecosistema AWS y ofrece health checks e integración con recursos de la plataforma. Cloudflare DNS, en cambio, suele destacar por su cercanía con el resto del stack perimetral, seguridad y performance del ecosistema Cloudflare. La elección suele depender de dónde vive la infraestructura principal.

CloudWatch¶

Logs¶

CloudWatch es el sistema de observabilidad base de AWS para logs, métricas y alarmas.

Métricas¶

Permite recolectar y visualizar métricas de servicios y aplicaciones.

Alarmas¶

Las alarmas ayudan a detectar umbrales críticos y reaccionar antes de que un problema se convierta en caída visible.

Monitoreo¶

La observabilidad en AWS pasa muy frecuentemente por CloudWatch.

Costos¶

AWS publica una página oficial específica para precios de CloudWatch y la presenta bajo un modelo de free tier y pago por uso.[cite:142]

Costos¶

AWS tiene una enorme flexibilidad, pero esa misma flexibilidad puede producir facturas confusas si no se controla bien.

Free Tier¶

AWS Free Tier incluye tres tipos de ofertas: 12 meses gratis, always free y short-term trials. La documentación oficial consultada lo explica explícitamente.[cite:144][cite:152]

Always Free¶

Entre los ejemplos visibles en la documentación consultada están DynamoDB con capacidad gratuita mensual permanente y Lambda con 1 millón de solicitudes gratuitas mensuales y hasta 3.2 millones de segundos de cómputo por mes.[cite:144]

Pago por uso¶

El modelo dominante es pay-as-you-go. Eso significa que no pagas una cuota fija universal, sino por almacenamiento, solicitudes, tiempo de cómputo, transferencia, monitoreo y otros componentes según el servicio.[cite:148][cite:128][cite:142]

Facturación¶

La facturación en AWS requiere vigilancia constante. No basta con “usar poco”; hay que entender qué dimensiones cobran cada servicio.

Calculadora¶

AWS recomienda usar la AWS Pricing Calculator o las service pricing pages para estimar costos. Además, la documentación de AWS Billing explica que la Price List Query API y las páginas oficiales de pricing son las referencias correctas para información actualizada de precios.[cite:155]

Presupuestos y alertas¶

La prevención de sorpresas depende de presupuestos, monitoreo de uso y alertas tempranas. AWS también documenta APIs para monitorear uso del Free Tier y compararlo con límites mensuales.[cite:156]

Buenas prácticas para evitar cargos inesperados¶

Activar presupuestos desde el primer día.
Revisar Billing con frecuencia.
Entender la dimensión de costo de cada servicio.
Eliminar recursos de prueba que ya no se usan.
Revisar transferencia y almacenamiento olvidado.
No asumir que “si está apagado no cuesta”; algunos recursos cobran por existir, no solo por ejecutarse.

Comparativa¶

AWS¶

AWS es ideal cuando se necesita amplitud extrema de servicios, infraestructura global madura, opciones empresariales y libertad arquitectónica profunda.

Cloudflare¶

Cloudflare resulta especialmente atractivo cuando el edge, la seguridad perimetral, la entrega global y la simplicidad de ciertas capas públicas son prioritarias.

Firebase¶

Firebase brilla cuando el objetivo principal es velocidad de desarrollo con una experiencia BaaS integrada.

Google Cloud¶

Google Cloud compite muy de cerca con AWS en infraestructura general, aunque su experiencia percibida y su posición relativa dependen del caso concreto.

Azure¶

Azure suele encajar muy bien en entornos empresariales integrados con Microsoft.

DigitalOcean¶

DigitalOcean es mucho más simple para ciertos proyectos pequeños o medianos, pero no compite en amplitud de catálogo con AWS.

Supabase¶

Supabase es muy atractivo cuando el corazón del sistema es Postgres y se valora una experiencia de desarrollo más directa.

Cuándo utilizar cada plataforma¶

Usa AWS cuando necesites máxima flexibilidad, muchos servicios o requisitos empresariales complejos.
Usa Cloudflare cuando el edge sea central y quieras resolver frontend, APIs y red perimetral con una experiencia muy moderna.
Usa Firebase cuando la prioridad sea BaaS y rapidez de construcción.
Usa arquitecturas híbridas cuando ningún proveedor por sí solo resuelva de forma óptima todas las capas.

Arquitecturas híbridas¶

Cloudflare + AWS¶

Esta combinación es especialmente poderosa. Cloudflare puede asumir la capa pública, el CDN, WAF, DNS y Workers, mientras AWS aporta almacenamiento, correo, voz, bases de datos o cómputo pesado.

Usuario
  |
  v
Cloudflare DNS / CDN / WAF
  |
  +----> Cloudflare Pages
  +----> Cloudflare Workers
  |
  v
AWS services
  +----> S3
  +----> SES
  +----> Polly
  +----> Lambda

Cloudflare + Firebase + AWS¶

Una app puede usar Firebase para auth y Firestore, Cloudflare para frontend y edge, y AWS para correo transaccional masivo con SES o para síntesis de voz con Polly.

GitHub + Cloudflare + AWS¶

GitHub entrega control de código y despliegue continuo; Cloudflare Pages publica frontend; AWS se usa para servicios especializados como SES, Polly o S3.

Cloudflare Workers + Amazon SES¶

Workers puede construir y validar la petición HTTP pública, aplicar rate limiting o autenticación, y luego delegar el envío real del correo a Amazon SES.

Cloudflare Pages + Amazon Polly¶

Pages entrega el frontend y una API edge o backend invoca Polly para generar audio educativo, lectura accesible o locuciones institucionales.

Cloudflare R2 + AWS¶

Puede parecer extraño mezclar dos servicios de object storage, pero tiene sentido en ciertos casos: R2 para servir binarios públicos integrados con Workers y S3 para flujos específicos o compatibilidad con herramientas ya acopladas al ecosistema AWS.

Casos reales¶

Credenciales Digitales¶

Servicios AWS razonables:

S3 para archivos y respaldos.
SES para correos de emisión y notificación.
Polly para lectura accesible de credenciales o tutoriales de uso.

Justificación técnica: S3 resuelve almacenamiento estable; SES resuelve comunicaciones transaccionales; Polly añade valor de accesibilidad. Cloudflare puede seguir siendo la infraestructura principal hacia el usuario.

Sistema Escolar¶

Servicios AWS razonables:

SES para notificaciones por correo.
S3 para PDFs, constancias y soportes.
RDS si el núcleo requiere base relacional clásica.

NLink¶

Para un acortador tipo NLink, AWS podría usar Lambda + API Gateway + DynamoDB, pero si ya existe una fuerte apuesta por Cloudflare Workers y D1, AWS no necesariamente sería la opción más simple. Aquí AWS sería más justificable si el proyecto ya vive mayoritariamente en esa nube.

IA El Profe¶

Servicios AWS razonables:

Polly para salida de voz.
S3 para materiales y recursos.
SES para comunicación automatizada.

Si el sistema ya usa Cloudflare Workers como gateway y Firebase para auth, AWS puede entrar como proveedor especializado de voz y correo.

Enlace Escolar¶

SES para avisos institucionales.
S3 para archivos y documentos.
Route 53 si toda la operación DNS ya vive dentro de AWS, aunque Cloudflare DNS suele ser más natural si el edge principal también está allí.

Master Finanzas¶

RDS para datos relacionales y consistencia fuerte.
S3 para reportes exportados.
SES para correos de reportes o alertas.
CloudWatch para observabilidad.

Ejemplos reales de uso¶

Amazon SES para envío masivo de correos¶

Patrón típico:

Panel administrativo -> Worker / backend -> SES -> destinatarios

Casos concretos:

Boletines institucionales.
Recuperación de contraseña.
Avisos de inscripción.
Confirmación de emisión de credenciales.

Amazon Polly para generación de voz¶

Patrón típico:

Texto educativo -> API / backend -> Polly -> archivo de audio -> reproducción

Casos concretos:

Lectura de materiales.
Ayuda accesible para usuarios con dificultades visuales.
Audio de bienvenida institucional.

Amazon S3 para almacenamiento¶

Patrón típico:

Cliente / backend -> S3 bucket -> presigned URL / descarga controlada

Casos concretos:

PDFs de constancias.
Fotografías.
Recursos multimedia.
Respaldos.

Cloudflare como infraestructura principal¶

Patrón típico:

DNS / CDN / Pages / Workers en Cloudflare
         |
         +----> SES
         +----> Polly
         +----> S3

Esta arquitectura es especialmente atractiva cuando el producto ya está pensado desde el edge y AWS entra solo para resolver necesidades donde tiene ventajas claras.

Diagramas ASCII¶

Arquitectura AWS¶

                  +----------------------+
                  |      Usuario         |
                  +----------+-----------+
                             |
                             v
                  +----------------------+
                  |   AWS Global Infra    |
                  +----------+-----------+
                             |
        +--------------------+--------------------+
        |                                         |
        v                                         v
+---------------+                         +---------------+
|   Region A    |                         |   Region B    |
+-------+-------+                         +-------+-------+
        |                                         |
   +----+----+                               +----+----+
   | AZ 1   |                               | AZ 1   |
   | AZ 2   |                               | AZ 2   |
   | AZ 3   |                               | AZ 3   |
   +--------+                               +--------+

Regiones y Availability Zones¶

Region
 ├── Availability Zone A
 ├── Availability Zone B
 └── Availability Zone C

S3¶

App / Worker -> S3 Bucket -> Object -> Presigned URL -> Usuario

SES¶

Aplicación -> SES -> autenticación del dominio -> correo entregado

Polly¶

Texto -> Polly -> síntesis de voz -> audio

Lambda¶

Evento / HTTP -> Lambda -> lógica -> respuesta

CloudFront¶

Origen -> CloudFront cache -> usuario

Cloudflare + AWS¶

Usuario
  |
  v
Cloudflare DNS / CDN / WAF
  |
  +----> Pages
  +----> Workers
  |
  v
AWS
  +----> S3
  +----> SES
  +----> Polly
  +----> Lambda

Flujo completo¶

Usuario abre plataforma
      |
      v
Cloudflare Pages entrega frontend
      |
      v
Cloudflare Workers valida / enruta
      |
      +----> SES envía correos
      +----> Polly genera voz
      +----> S3 almacena archivos
      +----> otros servicios según necesidad

Buenas prácticas¶

Elegir Región por latencia, cumplimiento y disponibilidad de servicios.[cite:127]
Desplegar entre múltiples Availability Zones cuando la disponibilidad importe.[cite:133]
Aplicar mínimo privilegio en IAM.
Activar MFA para cuentas sensibles.
Revisar facturación desde el primer día.[cite:144][cite:156]
Usar S3 Lifecycle cuando el patrón de acceso lo justifique.[cite:151]
Usar presigned URLs para acceso temporal en vez de abrir buckets innecesariamente.[cite:153]
No mezclar servicios por moda; integrarlos por ajuste técnico real.

Errores comunes¶

Crear recursos en la Región equivocada y no entender por qué no aparecen en la consola.[cite:127]
Dar permisos excesivos en IAM.
Subestimar costos de transferencia o solicitudes.[cite:148][cite:142]
Tratar AWS como si fuera un solo producto simple.
Elegir EC2 por costumbre cuando un servicio administrado o serverless sería más apropiado.
No usar presupuestos ni seguimiento del Free Tier.[cite:144][cite:156]

Curiosidades¶

AWS distingue entre regiones habilitadas por defecto y regiones que requieren opt-in, especialmente las introducidas después del 20 de marzo de 2019.[cite:127]
La documentación de AWS explica que la infraestructura de una Availability Zone puede estar compuesta por uno o más centros de datos discretos con energía y red redundantes, lo que ayuda a entender por qué Multi-AZ no es solo una abstracción comercial sino una decisión física de resiliencia.[cite:129][cite:133]
En S3, incluso la elección de storage class puede cambiar no solo el precio del almacenamiento, sino también mínimos de tamaño facturable, duración mínima de almacenamiento y cargos de recuperación, lo que demuestra que “guardar archivos” en la nube es más sofisticado de lo que parece.[cite:148]
Amazon Polly permite almacenar en caché y reproducir audio generado sin costo adicional por replay, según su página oficial de precios.[cite:128]

Resumen¶

AWS es una plataforma inmensa de infraestructura y servicios en la nube construida sobre una red global de Regiones y Availability Zones. Su fuerza principal está en la amplitud de su catálogo, su madurez y la libertad arquitectónica que ofrece.[cite:127][cite:129][cite:133]

Pero precisamente por esa amplitud, AWS exige criterio. No se trata de aprender cientos de servicios de memoria, sino de entender modelos: identidad con IAM, almacenamiento con S3, correo con SES, voz con Polly, cómputo con Lambda o EC2, datos con DynamoDB o RDS, observabilidad con CloudWatch y distribución con CloudFront.[cite:148][cite:128][cite:142][cite:144]

Para el lector de este libro, la conclusión más valiosa es esta: AWS no reemplaza automáticamente a Cloudflare o Firebase, ni viceversa. En muchos proyectos profesionales, la mejor solución no será una sola nube, sino una combinación inteligente donde cada pieza se elige por su ajuste técnico, económico y operativo.

Glosario¶

AWS: plataforma de computación en la nube de Amazon.
Region: área geográfica separada donde AWS ofrece servicios.[cite:127]
Availability Zone: ubicación aislada dentro de una Región, formada por uno o más centros de datos discretos.[cite:133]
Edge Location: punto perimetral usado por ciertos servicios de distribución y aceleración.
IAM: sistema de identidad y permisos de AWS.
S3: servicio de almacenamiento de objetos.[cite:148]
SES: servicio de envío de correo de AWS.
Polly: servicio de texto a voz de AWS.[cite:128]
Lambda: servicio serverless de ejecución de código.[cite:144]
CloudFront: CDN de AWS.[cite:144]
API Gateway: capa administrada de entrada para APIs.
DynamoDB: base de datos NoSQL administrada de AWS.[cite:144]
RDS: servicio administrado de bases de datos relacionales.[cite:135]
EC2: máquinas virtuales redimensionables en la nube.[cite:135]
Route 53: DNS administrado y servicio de dominios.[cite:135]
CloudWatch: observabilidad mediante logs, métricas y alarmas.[cite:142]
Free Tier: conjunto de ofertas gratuitas de AWS, incluyendo always free, 12 months free y trials.[cite:144][cite:152]
Presigned URL: URL firmada temporalmente para acceso controlado a un objeto en S3.[cite:153]
Storage Class: clase de almacenamiento en S3 con costos y patrones de acceso distintos.[cite:148]
MFA: autenticación multifactor.

20 preguntas de autoevaluación¶

¿Qué es AWS y por qué no debe confundirse con un solo servicio?
¿Qué diferencia existe entre una Región y una Availability Zone?[cite:127][cite:133]
¿Por qué desplegar todo en una sola Availability Zone puede ser un riesgo?[cite:133]
¿Qué significa IaaS dentro del contexto de AWS?
¿Qué significa serverless y cómo lo ejemplifica Lambda?[cite:144]
¿Qué papel cumple IAM en la seguridad de una cuenta AWS?
¿Por qué el principio de mínimo privilegio es tan importante?
¿Qué es un bucket en S3?
¿Qué utilidad tiene el versionado en S3?
¿Qué problema resuelven las presigned URLs?[cite:153]
¿Qué diferencia conceptual existe entre S3 y Cloudflare R2?
¿Para qué sirve Amazon SES?
¿Qué valor aporta Amazon Polly en productos educativos o accesibles?[cite:128][cite:132]
¿Cuándo conviene usar EC2 en vez de Lambda?
¿Qué diferencia conceptual existe entre DynamoDB y RDS?
¿Qué papel juega Route 53 dentro de AWS?
¿Qué ofrece el Free Tier de AWS y por qué no debe interpretarse como “todo gratis”?[cite:144][cite:152]
¿Qué buenas prácticas ayudan a evitar cargos inesperados?[cite:156]
¿Cuándo conviene una arquitectura híbrida Cloudflare + AWS?
¿Cómo diseñarías una plataforma educativa moderna usando Cloudflare como capa principal y AWS como proveedor especializado?

Proyecto práctico¶

El proyecto práctico de este capítulo consiste en diseñar una arquitectura profesional para una plataforma educativa moderna utilizando Cloudflare Pages, Cloudflare Workers, Cloudflare R2, Amazon SES, Amazon Polly, Amazon S3 y GitHub.

Objetivo del proyecto¶

Diseñar una plataforma para aproximadamente 50,000 usuarios registrados que incluya:

Frontend web moderno.
APIs ligeras.
Almacenamiento de documentos y multimedia.
Envío de correos transaccionales e informativos.
Generación de voz para accesibilidad y contenidos.
Despliegue controlado desde GitHub.

Arquitectura propuesta¶

GitHub
  |
  v
Cloudflare Pages
  |
  +----> Cloudflare Workers
  |
  +----> Cloudflare R2
  |
  +----> Amazon SES
  |
  +----> Amazon Polly
  |
  +----> Amazon S3 (comparativo / integraciones específicas)

Justificación por servicio¶

GitHub¶

Se utiliza como origen de control de versiones, revisión de código y despliegue continuo.

Cloudflare Pages¶

Se utiliza para publicar el frontend por su flujo Git-based, despliegues rápidos y cercanía natural con Workers.

Cloudflare Workers¶

Se utiliza para middleware, APIs públicas ligeras, validación de acceso, integración con SES y Polly y lógica edge.

Cloudflare R2¶

Se utiliza como almacenamiento principal de documentos e imágenes servidos públicamente o por rutas controladas desde Workers, especialmente cuando la arquitectura prioriza el ecosistema Cloudflare.

Amazon SES¶

Se selecciona para envío masivo de correos transaccionales e institucionales. En una plataforma educativa de 50,000 usuarios, esto puede incluir confirmaciones, restablecimientos, notificaciones y boletines.

Amazon Polly¶

Se selecciona para generar audio institucional y lectura accesible de materiales educativos, instrucciones o mensajes relevantes.

Amazon S3¶

Se utiliza aquí de forma comparativa o para flujos específicos donde la compatibilidad histórica con herramientas AWS o integraciones existentes lo justifique.

Flujo funcional del sistema¶

Usuario visita la plataforma
      |
      v
Pages sirve frontend
      |
      v
Workers procesa API y seguridad básica
      |
      +----> R2 sirve documentos e imágenes
      +----> SES envía correos
      +----> Polly genera voz
      +----> S3 se usa si un flujo específico lo requiere

Ejemplo funcional: Worker que delega envío a servicio de correo¶

export default {
  async fetch(request: Request): Promise<Response> {
    if (request.method !== 'POST') {
      return new Response('Method Not Allowed', { status: 405 });
    }

    const body = await request.json();

    if (!body.to || !body.subject || !body.html) {
      return Response.json({ error: 'Missing fields' }, { status: 400 });
    }

    return Response.json({
      ok: true,
      message: 'La solicitud puede reenviarse a Amazon SES desde una integración segura.'
    });
  }
};

Ejemplo funcional: flujo de síntesis de voz con Polly¶

Texto del contenido
   -> Worker / backend seguro
   -> Amazon Polly
   -> audio generado
   -> almacenamiento o reproducción controlada

Comparativa económica y técnica¶

Arquitectura híbrida Cloudflare + AWS¶

Ventajas:

Edge fuerte para frontend y APIs públicas.
Correo especializado con SES.
Voz con Polly.
Menor dependencia de EC2 o backend pesado para casos sencillos.

Desventajas:

Más de una plataforma que coordinar.
Requiere disciplina de integración y observabilidad.

Solución solo AWS¶

Ventajas:

Unificación bajo un solo proveedor.
Integración nativa entre S3, Lambda, SES, Polly, Route 53 y CloudFront.

Desventajas:

Mayor complejidad operativa visible para ciertas capas.
La experiencia de frontend moderno y edge público puede sentirse menos directa que Pages + Workers para equipos pequeños o medianos.

Solución solo Firebase¶

Ventajas:

BaaS muy cohesivo.
Auth, database, hosting, storage y analytics bajo un mismo paraguas.

Desventajas:

No sustituye de forma natural a SES ni a Polly.
Para voz, correo masivo especializado o ciertos patrones de infraestructura, AWS puede resultar más adecuado.

Estimación de costos mensuales¶

Una estimación rigurosa del costo mensual para 50,000 usuarios requeriría consultar en esta misma iteración las páginas oficiales específicas de precios de SES, CloudFront, Lambda, API Gateway y otros componentes exactos del diseño final. Como este capítulo debe basarse exclusivamente en documentación oficial de AWS y no se recuperaron todas esas páginas durante esta iteración, lo correcto es no inventar una cifra final consolidada.

Lo que sí puede afirmarse con base oficial es lo siguiente:

S3 cobra por almacenamiento, solicitudes, recuperación y transferencia según clase y patrón de acceso.[cite:148]
Polly cobra por caracteres procesados y publica tarifas distintas para voces Standard, Neural, Long-Form y Generative.[cite:128]
CloudWatch sigue modelo pay-as-you-go con free tier propio.[cite:142]
Lambda tiene free tier mensual para solicitudes y tiempo de cómputo.[cite:144]

La forma profesional de cerrar esta estimación es construir una hoja de costos con estos ejes:

Correos enviados por mes.
Caracteres sintetizados por Polly.
GB almacenados en R2 y, si aplica, en S3.
Número de requests API.
Transferencia servida al usuario final.
Logs y métricas retenidos.

Lección final del proyecto¶

La arquitectura propuesta demuestra una idea esencial del libro: una plataforma moderna no tiene por qué casarse con un solo proveedor. Cloudflare puede ser la cara pública, rápida y global del sistema. AWS puede aportar servicios muy maduros para almacenamiento especializado, correo y voz. GitHub puede gobernar el ciclo de entrega. La arquitectura profesional nace cuando cada pieza se selecciona por su ajuste real, no por moda ni por lealtad a una marca.