El módulo más extenso del curso. Cubre el ciclo de vida completo de una instancia EC2 — desde la elección del tipo hasta la retirada — pasando por AMIs, conexión segura, almacenamiento EBS, modelos de compra y Systems Manager. Lo que de verdad usa quien opera servidores en AWS de cliente.
Objetivos de aprendizaje
Elegir la familia y el tipo de instancia adecuados para un workload.
Construir y mantener AMIs propias para despliegues reproducibles.
Lanzar una instancia con user-data y conectarla de forma segura sin abrir puertos.
Gestionar el ciclo de vida (start, stop, hibernate, terminate) con criterio de coste.
Configurar volúmenes EBS, snapshots y cifrado KMS.
Elegir entre On-Demand, Reserved Instances, Savings Plans y Spot.
Usar Systems Manager (SSM) para sustituir el bastion host clásico.
2.1 ¿Qué es EC2 y cuándo usarlo?
Amazon EC2 (Elastic Compute Cloud) es el servicio de máquinas virtuales de AWS. Una instancia es una VM con CPU, RAM, almacenamiento y red — esencialmente, un servidor — que arrancas y apagas bajo demanda y pagas por segundo (con un mínimo de un minuto).
EC2 sigue siendo la base de la mayor parte de la infraestructura "tradicional" en AWS: ahí donde la aplicación necesita un sistema operativo completo y no encaja en servicios serverless. Para un perfil de administración, EC2 es el servicio donde más tiempo vas a pasar.
EC2 vs alternativas: si tu carga es un proceso corto y desacoplado, plantéate Lambda; si es un contenedor, ECS/Fargate. Pero para servidores con estado, aplicaciones legacy o necesidad de control completo del SO, EC2 sigue siendo la opción correcta.
2.2 Familias y tipos: cómo elegir
AWS clasifica las instancias por familia (la letra) según el perfil de workload, y por tamaño (large, xlarge, 2xlarge…) dentro de la familia. La generación va en el nombre: t3 es la tercera generación de la familia t.
Empieza con la familia M más pequeña que parece encajar. Mide. Sube o baja según necesites.
Si el workload tiene picos cortos y está parado mucho, T (burstable) suele ser óptima.
Si CPU al 100% es habitual, salta a C — sale más barata por unidad de CPU sostenida.
Si la app come RAM (bases de datos, JVMs grandes), R reduce el gasto frente a "estirar" una M.
Generación nueva ≥ generación vieja a igual precio: t3 > t2, m6i > m5.
Anti-patrón típico: dimensionar "al alza por si acaso" desde el inicio. EC2 se redimensiona en minutos: apaga, cambia el tipo, arranca. Empieza pequeño y crece con medición.
2.3 AMIs: la imagen de partida
Una AMI (Amazon Machine Image) es la plantilla con la que se arranca una instancia. Contiene el SO, las particiones, el software preinstalado y la configuración inicial. Hay tres orígenes:
📦 AMIs públicas oficiales
Mantenidas por AWS y los proveedores de SO: Amazon Linux 2023, Ubuntu, Debian, Windows Server. Es lo habitual para empezar.
🛒 AWS Marketplace
AMIs de terceros (Bitnami, Cloudera, appliances). Suelen incluir coste de licencia añadido al de EC2.
🏗️ AMIs propias
Las que tú creas a partir de una instancia configurada. La forma estándar de tener despliegues reproducibles ("golden image").
🔄 AMIs compartidas
Una cuenta puede compartir una AMI con otra cuenta o con toda la organización (Module 5). Útil entre entornos de cliente.
Patrón recomendado: construye una golden AMI con los parches al día, los agentes (CloudWatch, SSM) y la configuración base. Despliega siempre desde ahí. Reconstruye la AMI con frecuencia (semanal o quincenal).
2.4 Lanzar y conectar una instancia
Para lanzar una instancia necesitas: una AMI, un tipo de instancia, una subred (Módulo 3), un Security Group y, si te conectas por SSH, un key pair. Opcionalmente, un script de user-data que se ejecuta en el primer arranque para configurar la máquina.
Sesión: lanzar y comprobar una instancia
aws cli — terminal
El ciclo de vida de una instancia
Una instancia atraviesa estos estados. Cada transición tiene implicaciones de coste y de persistencia de datos.
Practica · ordena el ciclo de vida de una EC2
Arrastra los estados al orden que sigue una instancia desde que la lanzas hasta que la eliminas.
Stopped Apagada · sin coste de cómputo, sí de EBS
Terminated Eliminada · recursos liberados, no se recupera
Running En marcha · facturando por segundo
Pending Arrancando · aún no operativa
Stopping En proceso de apagado
Cuidado con stop vs terminate:stop apaga y conserva el EBS raíz — puedes volver a arrancar. Terminate elimina la instancia y, por defecto, también el EBS raíz (irrecuperable). Para producción se activa DisableApiTermination y DeleteOnTermination=false en los volúmenes importantes.
2.5 EBS y snapshots
El almacenamiento de bloques de una EC2 son los volúmenes EBS. Cada instancia tiene al menos uno (el root) y puede tener varios adicionales. EBS es un servicio independiente: los volúmenes viven en la AZ y pueden desasociarse y reasociarse a otra instancia (en la misma AZ).
Tipo
Perfil
Ideal para
gp3
SSD propósito general · IOPS y throughput configurables
El estándar moderno para casi todo
io2 / io2 Block Express
SSD alto rendimiento · IOPS muy altas y latencia baja
Bases de datos exigentes con SLA
st1
HDD throughput optimizado · barato y secuencial
Logs, big data, streaming
sc1
HDD cold · el más barato
Archivo de acceso muy poco frecuente
Snapshots: el backup de EBS
Un snapshot es una copia incremental del volumen, almacenada en S3 (gestionado por AWS, no lo ves directamente). Solo se guardan los bloques cambiados desde el snapshot anterior, así que tomar snapshots frecuentes es relativamente barato.
Cifrado KMS: los volúmenes y snapshots se cifran en reposo con AWS KMS (Key Management Service). Activa el cifrado por defecto en la región: aws ec2 enable-ebs-encryption-by-default. Sin coste perceptible, sí cumplimiento (RGPD, ENS, ISO 27001).
2.6 Modelos de compra: cómo pagar menos por EC2
EC2 admite cuatro formas de pago. Combinarlas bien puede dividir la factura por 2-3 en una carga predecible.
Modelo
Descuento
Compromiso
Cuándo usarlo
On-Demand
0% (referencia)
Ninguno
Pruebas, picos imprevisibles, primeros meses sin datos
Reserved Instances
~30-60%
1 o 3 años · tipo concreto
Workloads estables y conocidos a 1 año vista
Savings Plans
~30-60%
1 o 3 años · gasto/hora comprometido (flexible)
Como Reserved pero con flexibilidad de cambiar de familia
Spot
Hasta 90%
AWS puede reclamar la capacidad con 2 minutos de aviso
Cargas tolerantes a interrupción: batch, CI, render, procesos sin estado
Practica · empareja workload con modelo de compra
Pulsa un workload de la izquierda y luego el modelo de compra que encaja. Después, "Comprobar".
Web nueva de un cliente, sin datos de uso aún
Servidor de aplicación que lleva 2 años corriendo 24/7
Plataforma SaaS que cambia de tipo cada pocos meses
Render nocturno de vídeo, tolera reintentos
On-Demand
Reserved Instance
Savings Plan
Spot
Estrategia híbrida: en clientes maduros lo habitual es Savings Plan para la base predecible (60-70% del consumo) + On-Demand para el resto + Spot donde se pueda tolerar la interrupción. Las RIs puras casi siempre se han sustituido por Savings Plans por su flexibilidad.
2.7 Systems Manager: adiós al bastion host
AWS Systems Manager (SSM) es el servicio que más cambia la operación diaria respecto a la administración tradicional. Permite conectarte, ejecutar comandos y parchear instancias sin abrir puertos, sin claves SSH gestionadas a mano y sin bastion host.
🔌 Session Manager
Sustituye al SSH. Te abre una sesión segura en la instancia desde la consola o desde tu terminal (aws ssm start-session). Sin puertos abiertos, sin keys, con auditoría completa en CloudTrail.
📜 Run Command
Ejecuta el mismo comando en cientos de instancias a la vez, con resultado centralizado.
🩹 Patch Manager
Parcheo coordinado de una flota: define ventanas, baseline de parches y reporte.
📋 Inventory
Recolecta software instalado, configuración y estado de cada instancia. Útil para auditoría.
Patrón obsoleto a abandonar: el bastion host con un par de claves SSH compartidas en el equipo. Es un único punto de compromiso, no se audita bien y exige mantenimiento. Con SSM no hace falta abrir el puerto 22 a Internet ni gestionar keys: las instancias salen por VPC endpoint hacia el servicio SSM y tú las controlas con permisos IAM.
Práctica del módulo
Ejercicio 2.1 · Elegir tipo y familia
Para cada caso, propón una familia y un tamaño inicial razonable. Justifica:
Servidor web Nginx + PHP para un blog con 2.000 visitas al día.
Base de datos PostgreSQL en una instancia, ~30 GB de datos calientes.
Job de transcoding de vídeo que corre 4 horas al día y satura CPU.
Entorno de desarrollo de un equipo de 3 personas.
Sugerencia: 1 → t3.small (burstable, picos cortos); 2 → r6i.large (más RAM para caches y buffers); 3 → c6i.xlarge (CPU sostenida); 4 → t3.medium (burstable, varios usuarios ligeros).
Ejercicio 2.2 · Lab guiado · Lanza tu primera EC2
En tu cuenta sandbox: (1) crea un Security Group con SSM endpoints; (2) lanza una t3.micro con Amazon Linux 2023 y un user-data que instale Nginx; (3) conéctate por Session Manager (no SSH); (4) comprueba que el servidor responde; (5) crea un snapshot del EBS; (6) termina la instancia y borra el snapshot. Documenta los InstanceId y el coste estimado.
Test de comprensión
1. Tienes un servidor de aplicación con CPU al 90% de media constante. ¿Qué familia EC2 encaja mejor?
T (burstable)
C (compute optimizada)
R (memory optimizada)
G (GPU)
Respuesta correcta: B. C ofrece más CPU por euro para cargas sostenidas. T es para picos cortos, no para uso continuo alto.
2. ¿Cuál es la diferencia entre stop y terminate?
Son sinónimos.
Stop apaga y conserva el EBS raíz; terminate elimina la instancia y por defecto borra el EBS raíz.
Stop borra, terminate apaga.
Ambas eliminan la instancia, pero terminate es más rápido.
Respuesta correcta: B. Stop es reversible; terminate es definitivo. Por eso producción suele activar DisableApiTermination.
3. Un workload puede tolerar interrupciones y se ejecuta en lotes nocturnos. ¿Qué modelo de compra es óptimo?
On-Demand
Reserved Instance a 3 años
Savings Plan
Spot
Respuesta correcta: D. Spot ofrece hasta 90% de descuento a cambio de poder ser reclamado con 2 minutos de aviso — ideal para batch tolerante.
4. ¿Qué te permite Systems Manager Session Manager que sustituye al SSH tradicional?
Acelerar el SSH abriendo más puertos.
Abrir sesiones seguras en las instancias sin abrir el puerto 22, sin gestionar keys SSH, con auditoría completa.
Acceder solo desde la consola web.
Eliminar la necesidad de IAM.
Respuesta correcta: B. Session Manager elimina el bastion host clásico y el SSH gestionado a mano.
Resumen del módulo
EC2 es el servicio de VMs de AWS. Las instancias se eligen por familia (T, M, C, R…) y tamaño.
Construye AMIs propias ("golden image") para despliegues reproducibles y reconstrúyelas con regularidad.