Guía AWS Cloud Practitioner CLF-C02

Serverless y contenedores son dos formas modernas de ejecutar aplicaciones en AWS reduciendo carga operativa. Para el examen AWS Cloud Practitioner CLF-C02 no necesitas diseñar una arquitectura avanzada de microservicios ni administrar Kubernetes en profundidad, pero sí debes reconocer qué problema resuelve cada servicio y cuándo elegir uno u otro.

La idea importante es esta: AWS te ofrece varias formas de ejecutar código. Puedes usar servidores virtuales con EC2, funciones serverless con Lambda o contenedores con ECS, EKS y Fargate. Cada opción tiene un nivel diferente de control, responsabilidad operativa, escalado y complejidad.

Objetivos de aprendizaje

1. Antes de empezar: qué significa ejecutar aplicaciones

Cuando una aplicación necesita funcionar, de alguna forma necesita cómputo. Ese cómputo puede venir de una máquina virtual, de una función serverless o de un contenedor. La diferencia está en cuánto tienes que administrar tú y cuánto administra AWS.

Con una instancia EC2 tienes mucho control, pero también más responsabilidad: sistema operativo, parches, capacidad, escalado, configuración, agentes y mantenimiento. Con servicios más gestionados, AWS asume más parte de la operación, aunque el cliente sigue siendo responsable del código, permisos, datos, configuración y seguridad de la aplicación.

Este punto conecta con el modelo de responsabilidad compartida. Serverless no significa “sin responsabilidades”. Significa que no administras servidores directamente.

2. Qué significa serverless

Serverless no significa que no existan servidores. Significa que tú no los administras. AWS se encarga de aprovisionar, operar, escalar y mantener la infraestructura subyacente. Tú te centras más en el código, los eventos, los permisos, la configuración y la lógica de negocio.

Para CLF-C02, asocia serverless con estas ideas:

• No administras servidores directamente.
• El escalado lo gestiona el servicio.
• Normalmente pagas por uso real.
• Encaja bien con eventos y cargas variables.
• Reduce carga operativa.
• No elimina la necesidad de seguridad, IAM, monitorización y buenas prácticas.

3. AWS Lambda

AWS Lambda permite ejecutar código en forma de funciones sin administrar servidores. Una función Lambda se ejecuta cuando ocurre un evento. Ese evento puede venir de muchos sitios: una petición a API Gateway, un objeto subido a S3, un mensaje en una cola, un evento de EventBridge o una invocación desde otra aplicación.

Lambda es uno de los servicios más importantes que debes reconocer en el examen. Si el enunciado habla de ejecutar código por eventos, sin aprovisionar servidores y pagando por ejecución, Lambda suele ser la respuesta.

4. Cómo funciona Lambda de forma sencilla

Imagina que tienes una aplicación donde un usuario sube una imagen a un bucket de S3. Cuando la imagen se sube, quieres crear una miniatura automáticamente. Podrías tener un servidor EC2 siempre encendido esperando nuevas imágenes, pero eso sería más trabajo operativo. Con Lambda, puedes ejecutar una función solo cuando S3 detecta el nuevo objeto.

El flujo sería:

• El usuario sube una imagen a S3.
• S3 genera un evento.
• Ese evento invoca una función Lambda.
• Lambda procesa la imagen.
• Lambda guarda la miniatura en otro bucket o prefijo.

Este tipo de patrón es muy típico de serverless: una acción dispara un evento y una función responde.

5. Casos de uso típicos de Lambda

• Procesamiento de eventos: reaccionar a subidas en S3, mensajes, cambios o eventos programados.
• Backends serverless: funciones detrás de API Gateway.
• Automatización: tareas pequeñas de operación, limpieza o integración.
• Procesamiento ligero: transformar imágenes, validar datos, enriquecer eventos.
• Integración entre servicios: conectar servicios AWS sin mantener servidores propios.

Lambda es muy buena para tareas event-driven, pero no es la respuesta para todo. Si el proceso es muy largo, requiere control total del sistema operativo, necesita runtime muy específico o se ejecuta como una aplicación compleja de larga duración, quizá encaje mejor EC2, ECS o EKS.

6. Contenedores: idea básica

Un contenedor empaqueta una aplicación junto con sus dependencias para ejecutarla de forma consistente. Si alguna vez has oído “en mi máquina funciona”, los contenedores nacen precisamente para reducir ese problema: la aplicación viaja con lo necesario para ejecutarse.

En lugar de instalar manualmente librerías, dependencias y runtime en cada servidor, generas una imagen de contenedor. Luego ejecutas esa imagen como contenedor.

Para CLF-C02, no necesitas dominar Docker, pero sí entender estos conceptos:

• Imagen: plantilla empaquetada de la aplicación.
• Contenedor: ejecución de esa imagen.
• Registro: lugar donde se almacenan imágenes.
• Orquestador: servicio que coordina ejecución, escalado y disponibilidad de contenedores.

7. Amazon ECR

Amazon Elastic Container Registry, o Amazon ECR, es el servicio de AWS para almacenar imágenes de contenedor. Piensa en ECR como un repositorio privado o gestionado donde guardas tus imágenes Docker u OCI para que luego ECS, EKS u otros servicios puedan descargarlas y ejecutarlas.

Si una pregunta habla de almacenar, gestionar o guardar imágenes de contenedor, la respuesta suele ser Amazon ECR.

8. Amazon ECS

Amazon Elastic Container Service, o Amazon ECS, es el orquestador de contenedores nativo de AWS. Permite ejecutar aplicaciones en contenedores sin tener que montar tú mismo toda la plataforma de orquestación.

En ECS trabajas con conceptos como tareas, servicios, clusters y definiciones de tarea. Pero para CLF-C02, lo más importante es entender que ECS ejecuta y coordina contenedores usando una solución propia de AWS.

ECS puede ejecutarse sobre instancias EC2 que tú administras o sobre AWS Fargate, donde no administras servidores.

9. Amazon EKS

Amazon Elastic Kubernetes Service, o Amazon EKS, es Kubernetes gestionado por AWS. Kubernetes es una plataforma muy usada para orquestar contenedores en entornos empresariales. Muchas organizaciones ya usan Kubernetes y quieren llevar esa forma de trabajar a AWS.

La pista más clara en el examen es la palabra Kubernetes. Si el escenario dice que la empresa ya usa Kubernetes, necesita compatibilidad con Kubernetes, quiere ejecutar workloads Kubernetes o habla de clusters Kubernetes gestionados, piensa en EKS.

No confundas ECS con EKS:

• ECS: orquestador de contenedores propio de AWS.
• EKS: Kubernetes gestionado en AWS.

10. AWS Fargate

AWS Fargate es una opción de compute serverless para contenedores. Esto significa que puedes ejecutar contenedores sin administrar instancias EC2. No eliges ni mantienes servidores directamente. Defines lo que necesita el contenedor y AWS se encarga de proporcionar la capacidad subyacente.

Fargate puede usarse con ECS y también con EKS. Para CLF-C02, la frase importante es: Fargate permite ejecutar contenedores sin administrar servidores.

Fargate no sustituye a ECS o EKS como orquestador. Fargate es la capa de ejecución serverless para los contenedores. ECS o EKS coordinan los contenedores; Fargate proporciona la capacidad sin que gestiones EC2.

11. Tabla comparativa para examen

12. Lambda frente a contenedores

Una duda frecuente es: si Lambda ejecuta código y los contenedores también ejecutan aplicaciones, ¿cuándo uso cada uno?

Lambda encaja mejor cuando tienes funciones pequeñas, eventos concretos, ejecución bajo demanda y quieres olvidarte de servidores. Los contenedores encajan mejor cuando tienes aplicaciones empaquetadas, microservicios, dependencias concretas, procesos más continuos o necesidad de portabilidad entre entornos.

13. Arquitectura típica con Lambda

Una arquitectura serverless sencilla puede tener este flujo:

• Un usuario llama a una API.
• Amazon API Gateway recibe la petición.
• API Gateway invoca una función Lambda.
• Lambda ejecuta lógica de negocio.
• Lambda lee o escribe datos en DynamoDB, S3 u otro servicio.
• CloudWatch recoge logs y métricas.

Esta arquitectura es muy común en aplicaciones modernas porque reduce administración de servidores y escala de forma gestionada.

14. Arquitectura típica con contenedores

Una arquitectura con contenedores puede tener este flujo:

• El equipo crea una imagen de contenedor de la aplicación.
• La imagen se sube a Amazon ECR.
• Amazon ECS o Amazon EKS ejecuta los contenedores.
• AWS Fargate puede proporcionar la capacidad sin administrar EC2.
• Un Application Load Balancer puede distribuir tráfico hacia los contenedores.
• CloudWatch recoge logs y métricas.

Este patrón encaja cuando la aplicación ya viene empaquetada como contenedor o cuando el equipo quiere una forma más portable de desplegar servicios.

15. ECS con EC2 frente a ECS con Fargate

Con ECS puedes ejecutar contenedores sobre instancias EC2 o sobre Fargate.

• ECS con EC2: tú administras las instancias del cluster. Tienes más control, pero también más operación.
• ECS con Fargate: no administras instancias EC2. Defines recursos del contenedor y AWS proporciona la capacidad.

Para CLF-C02, si la pregunta insiste en “no administrar servidores para contenedores”, busca Fargate.

16. EKS con Kubernetes

EKS aparece cuando la empresa quiere usar Kubernetes gestionado. Kubernetes tiene sus propios conceptos, como pods, deployments, services y clusters. No necesitas entrar al detalle para Cloud Practitioner, pero sí reconocer que EKS es la opción de AWS para Kubernetes gestionado.

Si la empresa ya tiene equipos formados en Kubernetes o quiere mantener compatibilidad con herramientas del ecosistema Kubernetes, EKS puede ser más adecuado que ECS.

17. Diferencia entre imagen y contenedor

Esta diferencia es sencilla, pero muy importante:

• Imagen: paquete estático con la aplicación y sus dependencias.
• Contenedor: ejecución real de esa imagen.

Una imagen se almacena en ECR. Cuando ECS o EKS necesita ejecutar la aplicación, descarga esa imagen y la ejecuta como contenedor.

18. Serverless y costes

Serverless suele asociarse con pago por uso. En Lambda, pagas por invocaciones y tiempo de ejecución. Esto puede ser muy eficiente para cargas variables o intermitentes. Si una tarea se ejecuta solo unas veces al día, quizá no compense tener servidores encendidos permanentemente.

Pero serverless no siempre significa más barato. Depende del patrón de uso, duración, volumen, arquitectura y requisitos. Para CLF-C02, quédate con la idea general: serverless reduce administración y puede optimizar costes en cargas event-driven o variables.

19. Contenedores y portabilidad

Los contenedores suelen aparecer asociados a portabilidad. Una aplicación empaquetada en contenedor puede moverse más fácilmente entre entornos: portátil del desarrollador, entorno de pruebas, on-premise, ECS, EKS u otras plataformas compatibles.

Esto no significa que mover una aplicación sea automático o sin trabajo, pero sí que el empaquetado en contenedores ayuda a estandarizar la ejecución.

20. Seguridad en serverless y contenedores

Aunque AWS administre parte de la infraestructura, el cliente sigue teniendo responsabilidades importantes:

• Configurar permisos IAM adecuados.
• No dar permisos excesivos a funciones o tareas.
• Proteger secretos y variables sensibles.
• Revisar imágenes de contenedor.
• Controlar acceso a ECR.
• Configurar redes, security groups y endpoints cuando aplique.
• Monitorizar logs, errores y métricas.
• Aplicar mínimo privilegio.

Para el examen, recuerda que usar Lambda, ECS, EKS o Fargate no elimina el modelo de responsabilidad compartida.

21. Servicios relacionados que pueden aparecer

Serverless y contenedores suelen aparecer junto a otros servicios:

• API Gateway: expone APIs y puede invocar Lambda.
• S3: puede generar eventos que invocan Lambda.
• DynamoDB: base de datos NoSQL muy común en arquitecturas serverless.
• SQS: cola para desacoplar procesamiento.
• SNS: notificaciones y patrón pub/sub.
• EventBridge: eventos y reglas de enrutamiento.
• CloudWatch: logs, métricas y alarmas.
• IAM: permisos para funciones, tareas y servicios.
• Application Load Balancer: puede distribuir tráfico hacia contenedores.

22. Cómo razonar preguntas de examen

Cuando leas una pregunta sobre este tema, busca palabras clave:

• Función, evento, sin servidores, ejecución bajo demanda: Lambda.
• Contenedores, tareas, servicios, orquestador AWS: ECS.
• Kubernetes, pods, cluster Kubernetes: EKS.
• Contenedores sin administrar EC2: Fargate.
• Guardar imágenes Docker u OCI: ECR.
• API serverless: API Gateway más Lambda.
• Desacoplar procesamiento: SQS, SNS o EventBridge según el caso.

23. Escenarios típicos de examen

24. Errores típicos

• Confundir ECS y EKS: ECS es el orquestador nativo de AWS; EKS es Kubernetes gestionado.
• Confundir ECR con ECS: ECR almacena imágenes; ECS ejecuta contenedores.
• Pensar que Fargate es un registro de imágenes: no lo es. Fargate ejecuta contenedores sin administrar EC2.
• Elegir Lambda para todo: Lambda es ideal para eventos, pero no siempre para procesos largos o aplicaciones complejas persistentes.
• Pensar que serverless elimina la seguridad: sigues gestionando código, permisos, datos y configuración.
• No ver la pista de Kubernetes: si aparece Kubernetes, normalmente piensa en EKS.
• Olvidar CloudWatch: Lambda y contenedores necesitan logs y métricas para operar correctamente.
• Dar permisos excesivos: funciones Lambda y tareas de contenedor deben usar mínimo privilegio.

25. Resumen visual de decisión

Resumen final

Lambda, ECS, EKS, Fargate y ECR forman una parte importante del bloque de tecnología de CLF-C02. Lambda se asocia a funciones serverless y eventos. ECS se asocia a contenedores con orquestación nativa de AWS. EKS se asocia a Kubernetes gestionado. Fargate se asocia a ejecutar contenedores sin administrar instancias EC2. ECR se asocia a almacenar imágenes de contenedor.

Para acertar preguntas, céntrate en las pistas del enunciado. Si habla de eventos y funciones, piensa en Lambda. Si habla de contenedores en AWS sin Kubernetes, piensa en ECS. Si menciona Kubernetes, piensa en EKS. Si quiere no administrar servidores para contenedores, piensa en Fargate. Si necesita guardar imágenes Docker, piensa en ECR.