Tema 4. Cómputo: EC2, Lambda y contenedores¶

Tres maneras de «correr código» en AWS: máquina virtual, contenedor y función. El error de DAW no es desconocer los logos; es meter una API con WebSocket persistente en Lambda «porque es serverless» o dejar un t3.large 24/7 para un cron de treinta segundos. Foundations M6. Ver glosario.

Al empezar

Empieza por el cuestionario inicial. La red del Tema 3 ya sitúa la instancia; aquí eliges dónde corre el proceso y cuánto pagas por dejarlo encendido.

Propuesta didáctica¶

RA3. Diseña y configura redes virtuales y servicios de cómputo en la nube, aplicando buenas prácticas de seguridad, estrategias de balanceo de carga, escalado automático y aprovechando tecnologías serverless, contenedores y máquinas virtuales según casos de uso específicos.

Criterios de evaluación (RA3)¶

d) Se ha realizado la selección de servicios de computación adecuados según casos de uso.
f) Se han desarrollado prácticas relacionadas con la optimización de recursos computacionales.

Balanceo y Auto Scaling: Tema 8. Aquí se nombra el ASG como pareja natural de EC2.

Contenidos¶

EC2: AMI, familia de instancia, red, compra (On-Demand, Spot, Savings Plans).
Lambda: evento, duración, coste por invocación.
ECS, EKS, Fargate: contenedores con o sin nodos que parchear.
Elastic Beanstalk, Lightsail: nombres; cuándo simplifican.

Programación de aula (orientativa)¶

Quincena	En tutoría	Trabajo autónomo / evidencias
Q5	EC2 + AMI + elección VM/Lambda	PR401; Autocheck del tema

Cuestionario inicial¶

Responde con lo que sepas

Nombra un caso en el que EC2 encaje mejor que Lambda (pista: estado o conexión larga).
¿Qué es una AMI y para qué la usarías al clonar un lab?
¿Spot es un tamaño de instancia (t3.micro) o un modelo de compra?
¿Por qué conviene terminate (o min=0) al acabar el lab aunque «la dejes para mañana»?
En una frase: ¿qué diferencia de operación hay entre una VM y un contenedor?

Este cuestionario es solo para ti: te ayuda a ver qué dominas ya y qué te falta antes o mientras lees el tema. No se entrega en Aules; respóndelo con lo que sepas y, cuando quieras contrastar, abre el bloque Soluciones (autoevaluación) debajo o el índice en Soluciones.

Soluciones (autoevaluación)

API con WebSocket o proceso largo con estado en memoria / puerto persistente: mejor EC2 (o contenedor) que Lambda «porque es serverless».
Una AMI es la plantilla (SO + software) para lanzar instancias iguales; sirve para clonar el lab sin reinstalar a mano.
Spot es un modelo de compra (capacidad interrumpible más barata), no un tamaño t3.micro.
Si no terminate (o min=0), el lab sigue facturando horas, discos y balancers olvidados.
En una VM gestionas (más) el SO y el proceso; en un contenedor empaquetas la app y, con Fargate, dejas de parchear nodos EC2 del clúster.

Bloque Foundations (M6)¶

Amazon EC2¶

Amazon EC2 (Elastic Compute Cloud) es el servicio de máquinas virtuales en AWS: eliges una plantilla (AMI), un tipo (vCPU, RAM, red), la red (VPC/subnet), el disco (EBS, Tema 5) y el security group. Para un desarrollador web es el análogo más cercano a «tengo un servidor Linux en el que instalo Node/Java».

La AMI no es «la instancia encendida»; es la receta. Si cada despliegue reinstala Node a mano, estás pagando tiempo de humano además de hora de VM.

Selección de AMI Quick Start en la consola EC2 — AMI Quick Start al lanzar una instancia.

Crear tu propia AMI (idea Foundations)

Cuando la instancia ya tiene el SO y el software «bien», puedes Actions → Image and templates → Create image. Así lanzas clones iguales sin reinstalar a mano. En el formulario conviene dejar el reboot para snapshot coherente.

Menú Actions: Create image desde una instancia en ejecución — Crear AMI desde una EC2 que ya está lista.

Formulario Create image: nombre, reboot y volúmenes — Nombre de la AMI, reboot para consistencia y volúmenes incluidos.

Características EC2 (Foundations)

Genera máquinas virtuales en la nube (web, correo, ficheros…).
El coste depende de RAM, vCPU, disco e IP pública estática.
Escalable: puedes cambiar tipo (con límites) según necesidad — y apagando cuando no hace falta.

Familias: propósito general, cómputo, memoria, almacenamiento, GPU. Rightsizing: no cojas 2xlarge porque el tutorial lo traía. El modelo de compra (On-Demand, Savings Plans, Spot) no es una familia: Spot puede ser un t3.micro interrumpible.

Familias y tipos de instancia EC2 — Familia / tipo: plantilla de hardware, no el modelo de precio.

Par de claves

Si generas tu propia clave, descárgala en el momento: es la única oportunidad. Si la pierdes, toca recrear la instancia (en Academy suele usarse vockey / labsuser.pem según el lab).

Antes / después. Antes: un t3.large 24/7 «porque así va holgado» para una API de prácticas con pico a las 11:00. Después: tipo más pequeño, apagado fuera de horario (o ASG a cero) y, si el workload es un cron, valorar Lambda. El ahorro no es magia: es dejar de pagar ociosidad.

Lambda¶

AWS Lambda ejecuta una función ante un evento (HTTP vía API Gateway, cola, cron). No gestionas SO. Pagas invocaciones y GB-segundo. Límites de tiempo y tamaño de paquete. Es serverless en el sentido de que no hay una VM que mantengas encendida: el proveedor arranca tu código cuando llega el evento.

Encaja: webhooks, miniaturas, workers cortos. No encaja: procesos de horas, estado en memoria de proceso, un listen(3000) eterno. El cold start existe: un front que espera 10 ms no es el mismo caso que un batch nocturno.

Cuándo NO usar Lambda. WebSockets largos, jobs de vídeo de 2 h, o una app que necesita librerías nativas enormes y SSH al host para depurar. En esos casos EC2 o contenedores suelen ser la hipótesis seria; «serverless» no es sinónimo de «mejor».

Contenedores¶

Si ya empaquetas la API en Docker en clase, el siguiente paso en AWS es dónde corre ese contenedor. No es lo mismo orquestar con el servicio nativo de AWS, con Kubernetes gestionado, o sin nodos que parchear (Fargate). La tabla resume el trade-off; el criterio de DAW es: ¿necesito SSH al host, portabilidad K8s, o solo «correr el contenedor»?

Servicio	Idea	Trade-off
ECS	Orquestación AWS	Menos portable, menos operación que K8s
EKS	Kubernetes gestionado	Más control, más superficie
Fargate	Compute serverless para contenedores	No parcheas el nodo; menos «SSH al host»

No desplegamos un cluster de producción. Sí debes poder decir: «esta API ya va en Docker en clase → ECS/Fargate; este script de 20 s → Lambda; este legado con licencia de SO → EC2».

Opciones de cómputo: EC2, Lambda, ECS y Fargate — Misma carga, distinto nivel de operación: VM, función o contenedor (con o sin nodos).

En EC2 el camino de Foundations es el de siempre: lanzar en una AZ, SG y conectar. En Lambda no hay listen: editas el handler, Deploy y Test.

Diagrama Get started de Amazon EC2 — Flujo Get started de EC2. Fuente: Amazon EC2 User Guide (AWS).

Editor de código de AWS Lambda con handler Node.js — Editor de la función: Deploy / Test en la propia consola. Fuente: AWS Lambda Developer Guide (AWS).

Diálogo de evento de prueba en Lambda — Evento de prueba: invocas sin montar API Gateway todavía. Fuente: AWS Lambda Developer Guide (AWS).

Elastic Beanstalk (subes código, PaaS), Lightsail (VPS simplificado): una línea cada uno.

Errores frecuentes (cómputo)¶

Dejar la instancia del lab encendida el fin de semana.
Elegir Spot para el checkout o para una demo en clase que no tolera interrupción.
Meter en Lambda una API Express «tal cual» con estado en memoria y puerto fijo.
Montar EKS «porque Kubernetes mola» para un único contenedor de prácticas (sobreingeniería).

Relación con red y almacenamiento¶

EC2 sin VPC/SG claros (Tema 3) es un servidor expuesto. El disco de la VM es EBS (Tema 5); los uploads compartidos no se improvisan en el root de la instancia. El ASG (Tema 8) escala grupos de EC2, no sustituye elegir bien el tipo.

Bloque Ampliación Practitioner (CLF-C02)¶

En el CLF-C02 no basta con nombrar EC2 o Lambda: hay que separar tipo de instancia de modelo de precio y elegir servicio según estado, duración y quién opera el entorno (ECS/Fargate, EKS…).

Para el CLF

Spot es un modelo de compra, no un tamaño t3.micro. SageMaker o Rekognition no son «un tipo de EC2». Auto Scaling escala grupos de instancias, no sustituye elegir bien el cómputo. Ampliación y autocheck certificación en Certificación § Tema 4.

Videotutorial¶

Principal (Foundations). ATTA AWS Academy 03 EC2 Linux (~25 min).

Vídeo: Profe Santos Cloud (YouTube). Qué mirar: AMI, tipo pequeño, SG y cómo apagar/terminar; eso es lo que facturas en el lab.

Extra (opcional). Lambda 101 (~14 min) — contraste serverless frente a EC2 24/7. Vídeo: Profe Santos Cloud (YouTube).

Extra. Creación y gestión de EC2 — lanzar instancia: AMI, tipo, par de claves y acceso.

Pares de claves al crear una EC2 — Par de claves al lanzar la instancia.

EC2 Instance Connect: usuario de la AMI y botón Connect — Conectar desde consola (Instance Connect): el usuario suele venir de la AMI (`ubuntu`, `ec2-user`…).

Instancia EC2 en ejecución / consola — Instancia en consola tras el lanzamiento.

El M6 del LMS Academy se indica en clase / Aules.

Actividad / práctica¶

PR401 — Lanzar y comparar cómputo¶

PR401. (RA3 // d, f // PR 0–10). Lanzas el lab Academy M6 (EC2 / AMI) y argumentas si ese mismo workload encajaría en Lambda, mirando estado, duración y coste 24/7.

Tareas: sigue AMI/región del enunciado con tipo pequeño y SG mínimo; documenta evidencias del lanzamiento; en el .md, compara EC2 frente a Lambda (estado, tiempo, puerto persistente, coste); terminate las instancias y deja evidencia de lista vacía o parada.

Entrega: según Cómo entregar las prácticas — fichero PR401.md (o ZIP + img/ si hay capturas).

Guía de apoyo (no sustituye el enunciado): Soluciones · PR401.

Criterio	Descripción	Puntos
Lab EC2/AMI	Lanzamiento según enunciado	0–3
Comparación Lambda	Estado, duración, coste 24/7	0–4
Limpieza	Terminate / evidencias	0–2
Claridad del `.md`	Sin quedarse solo en el logo	0–1
Total		/10

Despliegue: de `npm start` al servicio¶

En clase node server.js abre el puerto 3000 en tu máquina. En EC2 necesitas AMI, SG, IP/ALB y un proceso que sobreviva al logout (systemd, PM2…). En Lambda no hay listen: exportas un handler y API Gateway (u otro evento) invoca. En ECS/Fargate empaquetas la misma idea de proceso en una imagen y defines CPU/memoria del task.

El criterio de DAW no es «cuál es más moderno», sino estado, duración, operación y coste. Anótalo en el entregable PR401 aunque el lab solo te haga lanzar EC2.

Autocheck del tema¶

Comprueba cómputo de esta quincena. CLF: Certificación § Tema 4.

Una AMI es…
a) la instancia encendida · b) la plantilla para lanzar instancias · c) un tipo de precio
V/F. Spot es un tipo de instancia (t3.micro).
Un cron de 30 s cada hora: hipótesis más razonable en Foundations…
a) EC2 24/7 · b) Lambda · c) EKS obligatorio
V/F. Con Fargate administras tú el SO de cada nodo EC2 del clúster.
Empareja: EC2 · Lambda · ECS+Fargate con: (a) handler sin listen · (b) SSH y SO custom · (c) contenedor sin gestionar nodos

Soluciones

b.
Falso — Spot es modelo de precio, no familia/tipo.
b (evento corto; EC2 24/7 suele sobrar).
Falso — Fargate quita la gestión del nodo.
EC2 encaja con (b) SSH y SO a medida; Lambda, con (a) handler sin listen; ECS+Fargate, con (c) contenedor sin gestionar nodos.

Glosario¶

EC2 Elastic Compute Cloud: servicio de máquinas virtuales en AWS. Tú eliges AMI, tipo, red y almacenamiento; sueles parchear el sistema operativo. Es el análogo más cercano a «tengo un Linux donde instalo Node/Java», con factura por tiempo de vida de la instancia.

AMI Amazon Machine Image: plantilla (SO + software) a partir de la cual se lanzan instancias EC2. No es la instancia en ejecución. Si la «buena» AMI solo vive en el disco de un compañero, el despliegue no es repetible.

Lambda Servicio de funciones serverless: ejecuta código ante eventos sin mantener una VM. Se factura por invocaciones y duración. Encaja en workers cortos y webhooks; no sustituye automáticamente a una API con estado persistente en proceso.

ECS Elastic Container Service: orquestación de contenedores gestionada por AWS (propia, no Kubernetes). Útil si ya empaquetas la API en Docker y quieres quedarte en el ecosistema AWS sin montar un clúster K8s.

Fargate Modo de ejecución de contenedores en el que AWS gestiona los nodos: no administras el SO del host. Menos SSH y menos parches de nodo; a cambio, menos control del «hierro» subyacente.