Antes de tocar EC2, redes o IAM hay que tener claro qué te ofrece AWS, dónde vive cada cosa y cómo te factura. Este módulo sienta esa base: regiones, modelo de responsabilidad compartida, accesos y la gestión multi-cuenta — los conceptos que evitarán que el resto del curso te parezca un mar de siglas.
Objetivos de aprendizaje
Explicar cómo se estructura AWS: regiones, zonas de disponibilidad y edge locations.
Aplicar el modelo de responsabilidad compartida a decisiones operativas reales.
Leer una factura AWS y entender los principales centros de coste.
Configurar acceso por consola, AWS CLI y SDK con perfiles separados.
Diseñar una estructura básica multi-cuenta con AWS Organizations y MFA obligatoria en root.
1.1 ¿Qué es AWS y cómo está organizado?
Amazon Web Services es la nube pública de Amazon: un catálogo de más de 200 servicios — cómputo, almacenamiento, redes, bases de datos, seguridad, IA — accesibles bajo demanda y pago por uso. Lo que para una consultora interesa entender de entrada es que AWS no es un único centro de datos: es una red mundial de regiones independientes con servicios homogéneos.
Nivel
Qué es
Ejemplo
Región
Un conjunto de centros de datos en una zona geográfica. Aislada del resto.
eu-west-1 (Irlanda), eu-south-2 (Madrid)
Zona de disponibilidad (AZ)
Uno o varios centros de datos físicos dentro de una región. Aislados entre sí (energía, red).
eu-west-1a, eu-west-1b, eu-west-1c
Edge location
Puntos de presencia para contenido cacheado (CloudFront) y DNS (Route 53). Hay cientos.
Madrid, Lisboa, París…
Idea clave: los servicios son regionales en su mayoría. Un bucket de S3 vive en una región. Una instancia EC2 vive en una AZ. La alta disponibilidad se consigue replicando en varias AZ; la resiliencia a catástrofe regional, replicando en varias regiones (más caro y más complejo).
1.2 El modelo de responsabilidad compartida
Es el concepto que más veces oirás explicar en cualquier curso de AWS — porque es donde más confusión hay al pasar de on-premise a cloud. AWS resume tu responsabilidad y la suya con una frase: "AWS responsible for security OF the cloud; customer responsible for security IN the cloud".
✓ AWS asume
La infraestructura física (centros de datos, hardware, energía, red física), el hypervisor y los servicios gestionados a nivel de plataforma. Si se rompe un disco, lo cambian ellos.
! Tú asumes
Todo lo que pongas dentro: sistema operativo, parches, configuración de red (Security Groups, NACLs), identidades (IAM), datos (cifrado, backups), aplicaciones y secretos.
La frontera cambia según el servicio. En EC2 administras el SO; en RDS, AWS gestiona el motor pero tú las tablas y las credenciales; en Lambda no hay SO que administrar pero sí controlas el código y los permisos.
Implicación operativa: "está en AWS, está seguro" es falso. Un bucket S3 público mal configurado expone datos aunque AWS funcione perfecto. Tu responsabilidad es la mayor parte del trabajo diario — y este curso entero está dedicado a hacerlo bien.
1.3 Pricing: cómo te factura AWS
AWS factura por uso, con tres mecánicas dominantes según el servicio. Conviene tenerlas en la cabeza antes de tocar nada — el coste se controla en el diseño, no en la factura.
Mecánica
Qué se cobra
Ejemplos
Por hora/segundo
Tiempo que el recurso está encendido
EC2 (segundos), RDS, EKS, NAT Gateway (hora)
Por GB·mes
Volumen de datos almacenados
S3, EBS, snapshots
Por petición / transferencia
Volumen de operaciones o tráfico
S3 (peticiones), CloudFront, salida a Internet
Los tres centros de coste que más sorprenden en factura
Salida de datos a Internet (egress). Subir es gratis, bajar se paga — y en grandes volúmenes se nota.
NAT Gateway. Útil, pero suma por hora y por GB procesado. En multi-AZ se multiplica.
EBS huérfanos y snapshots olvidados. Volúmenes desasociados a instancias que nadie limpia.
Free Tier: AWS regala unos límites mensuales durante 12 meses para que pruebes (750 h/mes de t2.micro, 5 GB de S3, etc.). Suficiente para hacer todos los laboratorios del curso sin coste, siempre que apagues lo que no estés usando. Más detalle en el Módulo 6.
1.4 Acceso a AWS: consola, CLI y SDK
Vas a operar AWS desde tres sitios distintos según la tarea:
🖥️ Consola web
La interfaz gráfica en console.aws.amazon.com. Útil para explorar, hacer cosas puntuales y leer dashboards. No es donde se hace el trabajo serio.
⌨️ AWS CLI
La herramienta de línea de comandos. Es lo que de verdad usa el día a día: scripts, automatización, debugging. aws s3 ls, aws ec2 describe-instances…
📦 SDKs
Librerías para llamar a AWS desde tu código (Python boto3, Node.js, Java, Go…). Misma API que la CLI, distinto consumidor.
🛠️ IaC (avanzado)
Terraform, AWS CDK o CloudFormation: describes la infraestructura en código y AWS la crea. Fuera del alcance de este curso, pero conviene saber que existe.
Sesión típica: configurar la CLI y comprobar identidad
Pulsa "Reproducir" para ver una sesión real de configuración de un perfil nuevo y verificación de la identidad asumida.
aws cli — terminal
Buena práctica: un perfil por cuenta de cliente. Nunca mezcles credenciales en el perfil default. El comando aws sts get-caller-identity te dice qué cuenta y qué identidad estás usando — comprobarlo antes de un comando destructivo evita más de un susto.
1.5 Cuentas, AWS Organizations y MFA
Una cuenta AWS es la unidad de aislamiento, facturación y seguridad. Cada cliente suele tener una cuenta — o varias, si separa entornos. Cuando gestionas varios clientes o varios entornos, AWS te ofrece AWS Organizations: una jerarquía con una cuenta management y cuentas miembro debajo.
Estructura típica multi-cuenta
Cuenta raíz · billing & policiesAWS Organizations · cuenta "management"
OU · Producción
cliente-acme-prod
cliente-globex-prod
OU · Pre-producción
cliente-acme-staging
cliente-globex-staging
OU · Sandbox
sandbox-formacion
experimentos-cloud
Beneficios: facturación consolidada (una factura, descuentos por volumen), Service Control Policies (SCP) para bloquear servicios a nivel organización (p.ej. "nadie puede crear nada fuera de eu-west-1"), y aislamiento real entre clientes y entornos.
MFA: la regla innegociable
Regla de oro: el usuario root de cada cuenta tiene MFA obligatoria, sus credenciales se guardan en bóveda y nunca se usa para el trabajo diario. Para operar se crean usuarios IAM (Módulo 5) o se usa SSO. Una cuenta AWS con root sin MFA es una brecha esperando ocurrir.
1.6 El ciclo de gestión cloud
Todo lo que veremos en los siguientes módulos cabe dentro de un ciclo de cuatro fases. No es una metodología nueva, es la forma natural en la que una consultora opera una cuenta de cliente: se planifica, se construye, se opera y se optimiza — y se vuelve a empezar.
El ciclo de gestión cloud · cada fase se ilumina por turno
1 · PlanDiseñar la arquitectura, dimensionar y presupuestarMódulos 1, 3
2 · BuildDesplegar redes, cómputo y almacenamientoMódulos 2, 3, 4
3 · RunMonitorizar, parchear, responder a incidentesMódulo 5
4 · OptimizeEscalar, abaratar y reforzar disponibilidadMódulo 6
Este curso recorre las cuatro fases en orden. Si en algún momento te pierdes, vuelve a este ciclo: cada módulo pertenece a una fase concreta.
Práctica del módulo
Ejercicio 1.1 · Mapa de regiones para tu cliente
Para un cliente español con clientes finales en España y Portugal y datos sujetos a RGPD, justifica qué región usarías como primaria, qué AZ y si tendría sentido usar una segunda región como DR. Considera latencia, soberanía del dato y coste.
Pista:eu-south-2 (Madrid) y eu-west-1 (Irlanda) son las opciones naturales. Madrid da soberanía del dato en España y mejor latencia; Irlanda tiene catálogo más amplio y suele ser más barata. Para DR, replicar buckets S3 cross-region es el caso típico.
Ejercicio 1.2 · Responsabilidad: ¿de quién?
Para cada incidente, di si la responsabilidad recae en AWS o en el cliente:
Un disco físico falla en el centro de datos donde vive una instancia EC2.
Una instancia EC2 se queda sin parches de seguridad del kernel.
Un bucket S3 se ha configurado público por error y se filtran datos.
Cae una zona de disponibilidad entera por un fallo eléctrico.
Un usuario IAM con contraseña débil es comprometido.
Solución: 1 → AWS · 2 → cliente · 3 → cliente · 4 → AWS (incidente físico) pero la arquitectura multi-AZ que mitiga el impacto es responsabilidad del cliente · 5 → cliente.
Test de comprensión
1. ¿Cuál es la diferencia entre una región y una zona de disponibilidad (AZ)?
Son sinónimos.
Una región es una zona geográfica con varias AZ; cada AZ es un conjunto de centros de datos aislados entre sí dentro de la región.
Una AZ contiene varias regiones.
Las regiones son lógicas y las AZ son físicas.
Respuesta correcta: B. Las regiones agrupan varias AZ aisladas en energía y red, lo que permite la alta disponibilidad multi-AZ.
2. Bajo el modelo de responsabilidad compartida, parchear el sistema operativo de una EC2 es responsabilidad de:
AWS — está en su nube.
El cliente — todo lo que se ejecuta dentro de una EC2 es suyo.
Compartida 50/50.
Del proveedor de la AMI.
Respuesta correcta: B. AWS responde por la infraestructura física y el hypervisor; el SO de la instancia es del cliente.
3. ¿Qué comando te dice qué cuenta e identidad estás usando con la AWS CLI?
aws whoami
aws iam list-users
aws sts get-caller-identity
aws describe-identity
Respuesta correcta: C. aws sts get-caller-identity devuelve cuenta, ARN y ID — comprobación básica antes de comandos destructivos.
4. ¿Qué decisión sobre el usuario root de una cuenta AWS es la correcta?
Usarlo siempre, tiene permiso a todo.
Compartirlo entre el equipo para no perder acceso.
Activar MFA, guardar credenciales en bóveda y no usarlo para trabajo diario.
Eliminarlo cuanto antes.
Respuesta correcta: C. El root es para emergencias administrativas: MFA obligatoria y trabajo diario con usuarios IAM o SSO.
Resumen del módulo
AWS se organiza en regiones (aisladas geográficamente) con varias AZ (centros de datos aislados entre sí dentro de la región).
Responsabilidad compartida: AWS responde por la infraestructura; el cliente, por el SO, datos, IAM y configuración. La frontera depende del servicio.
Pricing: por hora, por GB·mes y por petición/tráfico. Los costes ocultos típicos: egress, NAT Gateway y EBS/snapshots huérfanos.
Accesos: consola para explorar, CLI para operar, SDK para integrar. Un perfil por cuenta de cliente; comprueba siempre identidad antes de comandos críticos.
Multi-cuenta con AWS Organizations + facturación consolidada + SCPs. MFA innegociable en root.
En el siguiente módulo entramos en el bloque más extenso del curso: EC2, el cómputo de AWS.