Modulo 01. Cloud computing y propuesta de valor de AWS

Objetivo del modulo

Entender que aporta la computacion en la nube y por que AWS se ha convertido en una referencia del mercado para infraestructura, plataforma y servicios gestionados.

Resultados esperados

• Explicar elasticidad, pago por uso y agilidad de despliegue.
• Relacionar valor cloud con casos de negocio concretos.
• Distinguir beneficios reales de ideas simplificadas o marketing vacio.
• Conocer la estructura basica de servicios y regiones de AWS.

Desarrollo teorico

Cloud computing no significa "poner servidores en internet". Significa consumir capacidades de computo, almacenamiento, red, bases de datos y otros servicios como recursos bajo demanda, aprovisionables rapidamente y con un modelo de pago muy distinto al del CPD tradicional. La idea clave es pasar de invertir primero en infraestructura y esperar meses para ponerla a producir, a aprovisionar cuando hace falta, escalar con rapidez y ajustar coste a uso real. El NIST define cloud computing mediante cinco caracteristicas esenciales: autoservicio bajo demanda, acceso amplio a traves de red, pool de recursos compartidos, elasticidad rapida y servicio medido. AWS cumple las cinco y ademas anade un ecosistema de servicios gestionados que va mucho mas alla de la virtualizacion basica.

Los cinco argumentos de valor de AWS. AWS popularizo este modelo apoyandose en varios argumentos concretos:

1. Agilidad. Crear una instancia EC2, un bucket S3 o una base RDS lleva minutos, no semanas. Esto no solo acelera despliegues sino que habilita experimentacion: probar una arquitectura nueva cuesta horas de computo, no meses de procurement. Desde la CLI, lanzar una instancia es tan directo como ejecutar aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t3.micro --key-name mi-key. En menos de un minuto tienes un servidor funcional con conectividad de red y almacenamiento listo. Esta velocidad cambia la forma en que los equipos innovan, porque el coste de experimentar se reduce drasticamente.

2. Elasticidad. Una aplicacion puede crecer o decrecer segun demanda. Auto Scaling ajusta la capacidad de computo automaticamente basandose en metricas como uso de CPU, peticiones por segundo o metricas personalizadas de CloudWatch. Lambda ejecuta funciones sin gestionar servidores, facturando por milisegundo de ejecucion y escalando de cero a miles de invocaciones concurrentes sin intervencion manual. Los Elastic Load Balancers distribuyen trafico entre instancias sanas. Esto es especialmente valioso para cargas variables: e-commerce con picos estacionales como Black Friday, aplicaciones con horarios de uso marcados o procesamiento batch que solo necesita potencia puntual. Un ejemplo tipico seria configurar un Auto Scaling Group con minimo dos instancias, deseado tres y maximo diez, vinculado a una alarma CloudWatch que dispara escalado cuando la CPU supera el 70 por ciento.

3. Alcance global. AWS opera en mas de 30 regiones geograficas (us-east-1, eu-west-1, ap-southeast-1, sa-east-1, etc.), cada una con al menos dos Availability Zones y muchas con tres o mas. A esto se suman mas de 400 edge locations para CloudFront y Route 53, Local Zones para cargas sensibles a latencia y AWS Outposts para extender la experiencia AWS al centro de datos del cliente. Esta infraestructura permite desplegar aplicaciones cerca de los usuarios, cumplir requisitos de residencia de datos como GDPR en Europa, y disenar arquitecturas resilientes con redundancia geografica. Para listar las regiones disponibles basta con ejecutar aws ec2 describe-regions --output table.

4. Amplitud de servicios. AWS no es solo EC2 y S3. Incluye mas de 200 servicios organizados en categorias: computo (EC2, Lambda, ECS, EKS, Fargate, Lightsail), almacenamiento (S3, EBS, EFS, Glacier, Storage Gateway), bases de datos (RDS, DynamoDB, Aurora, ElastiCache, Neptune, DocumentDB), red (VPC, Route 53, CloudFront, Direct Connect, Transit Gateway), seguridad (IAM, KMS, GuardDuty, WAF, Shield, Secrets Manager, Security Hub), analitica (Athena, Redshift, Kinesis, EMR, QuickSight), IA y ML (SageMaker, Rekognition, Textract, Comprehend), integracion (SQS, SNS, EventBridge, Step Functions) y muchos mas. Todo esto explica por que AWS no se usa solo para "alojar maquinas" sino como plataforma de construccion de productos digitales completos. Un desarrollador puede construir una aplicacion serverless combinando API Gateway, Lambda, DynamoDB y S3 sin aprovisionar un solo servidor.

5. Modelo economico. El pago por uso (pay-as-you-go) transforma gasto de capital (CapEx) en gasto operativo (OpEx). No hay compromiso inicial obligatorio, aunque existen Reserved Instances y Savings Plans que ofrecen descuentos de hasta el 72 por ciento para cargas estables. Spot Instances permiten acceder a capacidad sobrante con descuentos de hasta el 90 por ciento a cambio de tolerar interrupciones. Herramientas como AWS Cost Explorer, AWS Budgets y el AWS Pricing Calculator ayudan a estimar y controlar el gasto. Esto no significa que cloud sea siempre mas barato; significa que el modelo financiero es diferente y que el coste se puede ajustar a la demanda real. Una empresa que deja instancias EC2 encendidas sin uso 24x7 puede terminar pagando mas que en on-premises.

Modelos de servicio. AWS ofrece servicios en tres niveles claramente diferenciados:

• IaaS (Infrastructure as a Service): Tu gestionas el SO, el runtime, la aplicacion, los datos y la seguridad a nivel de aplicacion. AWS gestiona hardware, red fisica, virtualizacion y los centros de datos. Ejemplo principal: EC2, donde el cliente tiene acceso SSH completo y control total del sistema operativo. Otro ejemplo es EBS, donde el cliente gestiona el sistema de ficheros y el cifrado a nivel de volumen.
• PaaS (Platform as a Service): AWS gestiona ademas el SO, los parches y el runtime. Tu solo gestionas la aplicacion y los datos. Ejemplo: Elastic Beanstalk automatiza despliegue, escalado y monitorizacion de aplicaciones web. RDS gestiona el motor de base de datos, los backups automaticos, los parches del motor y la replicacion Multi-AZ.
• SaaS (Software as a Service): AWS o un ISV gestiona todo el stack. Tu solo consumes la funcionalidad. Ejemplo: Amazon WorkSpaces para escritorios virtuales, Amazon Chime para comunicaciones, o incluso la propia consola de AWS como producto SaaS que consume servicios.

La eleccion de modelo afecta directamente la responsabilidad operativa, el control que retiene el cliente, el coste y la complejidad de operacion diaria. Moverse hacia PaaS y SaaS reduce carga operativa pero tambien reduce flexibilidad y control granular.

Modelo de responsabilidad compartida. AWS gestiona la seguridad "de" la nube (hardware, red fisica, hypervisor, centros de datos, refrigeracion, seguridad fisica). El cliente gestiona la seguridad "en" la nube (configuracion de red virtual con Security Groups y NACLs, sistema operativo y sus parches, cifrado de datos en transito y en reposo, configuracion de IAM, gestion de claves y proteccion de datos). Este modelo es fundamental para entender que migrar a cloud no elimina responsabilidades de seguridad; las redistribuye. Un bucket S3 publico con datos sensibles es responsabilidad del cliente, no de AWS. Configurar IAM con permisos excesivos es responsabilidad del cliente. AWS proporciona las herramientas; el cliente debe usarlas correctamente.

Regiones y Availability Zones. Una Region es un area geografica con al menos dos Availability Zones. Cada AZ es uno o mas centros de datos fisicos con alimentacion electrica independiente, conectividad de red redundante y refrigeracion separada. Las AZ dentro de una region estan conectadas con enlaces de baja latencia y alto ancho de banda. Disenar para alta disponibilidad implica distribuir recursos entre multiples AZs usando servicios como ELB para balanceo y Auto Scaling para mantener capacidad. Elegir region depende de cuatro factores principales: latencia hacia los usuarios finales, cumplimiento normativo y residencia de datos, disponibilidad de servicios especificos (no todos los servicios estan en todas las regiones) y costes, que varian entre regiones (us-east-1 suele ser la region mas economica).

Cuando cloud no es la respuesta automatica. No toda carga de trabajo se beneficia de cloud. Aplicaciones con uso constante y predecible 24x7 pueden ser mas economicas on-premises o en colocation tras un analisis TCO riguroso. Requisitos regulatorios estrictos en ciertos sectores como defensa o gobierno pueden limitar las opciones de cloud publica. Aplicaciones con alta dependencia de hardware especializado como mainframes o sistemas SCADA pueden no encajar facilmente. Latencia ultra-baja por debajo de un milisegundo puede requerir edge computing o procesamiento local. Cloud es una herramienta potente pero no una respuesta universal, y un buen arquitecto sabe cuando recomendar un enfoque hibrido o incluso on-premises.

Contenido ampliado

Puntos clave

• Cloud cambia velocidad, consumo y operacion, no solo el lugar donde viven los servidores.
• AWS aporta amplitud de servicios y madurez operativa a escala global.
• El valor de negocio depende de usar correctamente el modelo, no solo de "migrar".
• El modelo de responsabilidad compartida define que gestiona AWS y que gestiona el cliente.
• La eleccion de region y AZ impacta disponibilidad, latencia y cumplimiento.
• Cloud no siempre abarata; cambia el modelo financiero de CapEx a OpEx.

Checklist operativa

• Identificar que necesidad de negocio resuelve cloud en cada caso concreto.
• Evitar comparar cloud solo por coste bruto sin mirar agilidad, escalabilidad y operacion.
• Relacionar cada beneficio con un servicio o capacidad concreta de AWS.
• Entender que responsabilidades de seguridad recaen en el cliente.
• Elegir region con criterios de latencia, cumplimiento y coste.

Errores frecuentes

• Pensar que cloud siempre abarata por si sola sin optimizacion.
• Confundir rapidez de despliegue con ausencia de gobierno.
• Migrar sin redisenar servicios, responsabilidades ni modelo operativo.
• Asumir que AWS gestiona toda la seguridad por defecto.
• Elegir servicios por popularidad y no por encaje con el caso de uso.
• No considerar el coste de transferencia de datos entre regiones.

Practica sugerida

Elabora una tabla con tres casos de adopcion cloud distintos (startup web, migracion de ERP corporativo, procesamiento batch de datos). Para cada uno indica: que servicios AWS usarias, que modelo de servicio aplica (IaaS/PaaS/SaaS), que beneficios concretos aporta cloud y que responsabilidades de seguridad recaen en el cliente.

Preguntas de autoevaluacion

• Que diferencia hay entre aprovisionar infraestructura en un CPD y en AWS.
• Por que elasticidad no significa lo mismo que alta disponibilidad.
• Que riesgos aparecen si se adopta cloud sin gobierno ni modelo operativo.
• Que significa el modelo de responsabilidad compartida y por que importa.
• Cuando cloud podria no ser la opcion mas adecuada para una carga de trabajo.

Cierre

AWS tiene sentido cuando se entiende como plataforma para desplegar mas rapido, escalar mejor y operar con otro modelo financiero y tecnico. Pero el valor real aparece cuando se combina con gobierno, seguridad bien gestionada y una estrategia clara de adopcion.

Modulo 02. Infraestructura global y modelos de servicio

Objetivo del modulo

Comprender cómo se organiza AWS globalmente y cómo cambian responsabilidades y consumo según el modelo de servicio.

Resultados esperados

• Distinguir regiones, Availability Zones y edge locations.
• Explicar diferencias básicas entre IaaS, PaaS y SaaS.
• Relacionar ubicación y servicio con disponibilidad, latencia y cumplimiento.

Desarrollo teorico

La infraestructura global de AWS se apoya en regiones geográficas, cada una compuesta por varias Availability Zones aisladas entre sí a nivel de energía, red y, en gran medida, infraestructura física. A fecha actual, AWS opera más de 30 regiones con planes de expansión continua. Cada región recibe un identificador como us-east-1 (Virginia del Norte), eu-west-1 (Irlanda), ap-southeast-1 (Singapur) o sa-east-1 (São Paulo). Dentro de cada región existen al menos dos AZs, aunque la mayoría cuenta con tres o más. Desplegar en varias AZ dentro de una región es la primera medida real para mejorar resiliencia ante fallo local, porque cada AZ está diseñada para funcionar de forma independiente en caso de que otra sufra un corte eléctrico, un fallo de red o incluso un evento físico localizado.

Availability Zones en detalle. Cada AZ consiste en uno o más centros de datos físicos con alimentación eléctrica redundante, conectividad de red independiente y refrigeración separada. Las AZs dentro de una región están interconectadas con enlaces de fibra óptica dedicados de baja latencia (típicamente menos de 2 milisegundos entre AZs) y alto ancho de banda. Esta conectividad permite que servicios como RDS Multi-AZ repliquen datos de forma síncrona entre zonas, o que un Auto Scaling Group distribuya instancias EC2 entre varias AZs de forma transparente. Para verificar las AZs disponibles en una región, se puede ejecutar aws ec2 describe-availability-zones --region eu-west-1 --output table, lo que devuelve los identificadores de zona como eu-west-1a, eu-west-1b y eu-west-1c. Es importante saber que los identificadores de AZ son mapeados de forma diferente para cada cuenta de AWS, es decir, eu-west-1a de una cuenta puede corresponder a un centro de datos distinto que eu-west-1a de otra cuenta, para distribuir carga entre todas las zonas de forma equilibrada.

Edge locations y servicios de borde. Las edge locations son puntos de presencia distribuidos globalmente que acercan contenido y algunos servicios al usuario final. AWS cuenta con más de 400 edge locations en ciudades de todo el mundo. CloudFront utiliza estas ubicaciones para almacenar en caché contenido estático y dinámico, reduciendo latencia para usuarios finales. Route 53 también se beneficia de esta red para resolver consultas DNS con baja latencia. AWS Global Accelerator usa la red backbone de AWS para mejorar rendimiento de aplicaciones globales, enrutando tráfico a través de la infraestructura interna de AWS en lugar de internet público. Además de edge locations estándar, AWS ofrece Regional Edge Caches que funcionan como capa intermedia entre las edge locations y la región de origen, manteniendo en caché objetos menos populares que ya habrían sido eliminados de las edge locations pero que aún se solicitan con frecuencia.

Local Zones y Outposts. Para casos que requieren latencia ultra-baja o procesamiento cerca del usuario final, AWS ofrece Local Zones, que extienden servicios de cómputo, almacenamiento y red a ubicaciones metropolitanas específicas. Una Local Zone en Los Ángeles, por ejemplo, permite ejecutar cargas de renderizado de vídeo o gaming con latencia de un solo dígito de milisegundos para usuarios de esa ciudad. AWS Outposts lleva un paso más allá y despliega racks de hardware propiedad de AWS en el centro de datos del cliente, ejecutando los mismos APIs y servicios de AWS pero on-premises. Esto es especialmente útil para cargas con requisitos estrictos de residencia de datos o latencia local, como procesamiento industrial o edge computing en plantas de fabricación.

Decisiones de ubicación. No todas las decisiones de ubicación son técnicas puras. La región afecta latencia, residencia del dato, coste y recuperación ante desastres. Un workload europeo que trate datos personales regulados por GDPR puede necesitar eu-west-1 o eu-central-1 por cumplimiento normativo. Pero la región también afecta el precio: us-east-1 suele ser entre un 10 y un 20 por ciento más barata que otras regiones para muchos servicios. No todos los servicios están disponibles en todas las regiones; servicios nuevos típicamente se lanzan primero en us-east-1 y se expanden progresivamente. Un comando útil para verificar en qué regiones está disponible un servicio específico es consultar los endpoints de servicio en la documentación de AWS o usar aws ssm get-parameters-by-path --path /aws/service/global-infrastructure/services/lambda/regions --output text. La idea importante para Cloud Practitioner es que elegir región no es un detalle menor: afecta disponibilidad, operación, gobernanza y hasta la factura mensual.

Multi-AZ frente a multi-región. Distribuir una carga entre múltiples AZs dentro de una región protege contra fallos de zona individuales, pero no protege contra un evento que afecte a toda la región (algo extremadamente raro pero posible). Para cargas críticas que requieren continuidad ante un fallo regional, se necesita una arquitectura multi-región con replicación de datos entre regiones, DNS failover con Route 53 y, potencialmente, despliegue activo-activo o activo-pasivo. Multi-región añade complejidad significativa en sincronización de datos, consistencia, coste de transferencia entre regiones y gestión operativa. Para la mayoría de las cargas, multi-AZ proporciona un nivel de resiliencia suficiente; multi-región se reserva para aplicaciones de misión crítica con SLAs muy exigentes.

Modelos de servicio y responsabilidad. La infraestructura global se consume a través de diferentes modelos de servicio, y cada uno redistribuye las responsabilidades entre AWS y el cliente de forma distinta:

• IaaS con EC2: El cliente elige región, AZ, tipo de instancia, AMI, almacenamiento y configuración de red. AWS proporciona el hardware y la virtualización. El cliente es responsable del sistema operativo, parches, configuración de seguridad a nivel de OS, antivirus, firewall de host y todos los datos. En la práctica, lanzar una instancia EC2 implica decisiones como aws ec2 run-instances --image-id ami-0abcdef --instance-type m5.large --subnet-id subnet-abc123 --security-group-ids sg-xyz789 --key-name produccion.
• PaaS con Elastic Beanstalk o RDS: AWS gestiona el sistema operativo, los parches del runtime o del motor de base de datos, y la infraestructura subyacente. El cliente se enfoca en el código de aplicación (Beanstalk) o en el esquema y datos (RDS). RDS Multi-AZ crea automáticamente una réplica de standby en otra AZ con failover automático, lo que se activa simplemente con aws rds create-db-instance --db-instance-identifier mi-db --engine postgres --multi-az --db-instance-class db.m5.large.
• SaaS como Amazon Connect o WorkSpaces: El cliente solo configura parámetros de uso y consume funcionalidad. No gestiona infraestructura, sistema operativo ni runtime. La responsabilidad técnica se reduce al máximo, aunque la responsabilidad sobre los datos y su uso sigue siendo del cliente.

Impacto en diseño de arquitectura. Comprender la infraestructura global permite tomar decisiones fundamentales: dónde desplegar para minimizar latencia, cómo distribuir para maximizar disponibilidad, qué nivel de gestión asumir según el modelo de servicio, y cómo equilibrar coste con resiliencia. Un arquitecto que entiende que una AZ no es simplemente un rack sino un centro de datos completo con independencia física, diseña de forma diferente a quien lo trata como un detalle abstracto.

Contenido ampliado

Puntos clave

• Región y AZ son piezas distintas del diseño.
• Multi-AZ mejora resiliencia, pero no sustituye backup ni DR entre regiones.
• El modelo de servicio cambia responsabilidades del cliente.

Checklist operativa

• Identificar si una carga necesita multi-AZ o multi-región.
• Relacionar requisitos legales con ubicación de despliegue.
• Entender si el servicio consumido es más IaaS, PaaS o SaaS.

Errores frecuentes

• Pensar que una sola AZ es suficiente para cualquier servicio crítico.
• Confundir latencia local con continuidad regional.
• No adaptar responsabilidades al tipo de servicio consumido.

Practica sugerida

Dibuja una arquitectura sencilla en una región AWS usando dos AZ y justifica por qué eliges cada componente.

Preguntas de autoevaluacion

• ¿Qué aporta desplegar en varias AZ?
• ¿Cuándo tendría sentido plantear varias regiones?
• ¿Qué cambia para el cliente entre EC2 y un servicio más gestionado?

Cierre

Entender la infraestructura global de AWS ayuda a tomar decisiones básicas de arquitectura con mucho mejor criterio que simplemente "elegir una región cercana".