Guía de Estudio — AWS Certified Cloud Practitioner (CLF-C02)#

☁️ Certificación de nivel fundacional: no exige experiencia previa ni otras certificaciones. Valida que entiendes qué es la nube de AWS, para qué sirve cada servicio importante, cómo se reparte la seguridad, cómo se paga y dónde pedir ayuda. No te pide programar ni configurar nada: te pide elegir bien.

Esta guía está escrita para alguien que parte de cero y quiere aprobar a la primera. Cada tema sigue el mismo orden: la idea en palabras simples → una analogía cotidiana → el término técnico → cómo lo pregunta el examen. Si un párrafo no te queda claro, no sigas de largo: los dominios se apoyan unos en otros (no entenderás bien los security groups sin saber qué es una VPC, ni los Savings Plans sin saber qué es On-Demand).

¿A quién va dirigida? A personas de negocio, ventas, finanzas, gestión de proyectos o estudiantes que necesitan hablar «el idioma de la nube», y a técnicos que empiezan en AWS y quieren una base sólida antes de ir a Solutions Architect – Associate o AI Practitioner.

Antes de empezar#

Cómo usar esta guía con el resto del curso#

El curso tiene varias piezas y cada una cumple un papel distinto. Úsalas en este orden:

Dentro de esta guía encontrarás cuatro tipos de bloques plegables. Intenta responder antes de abrirlos: recuperar de memoria (no releer) es lo que fija un concepto.

El examen en una tabla#

🎯 Lectura estratégica de los pesos: D2 + D3 suman el 64 %. Si vas justo de tiempo, prioriza responsabilidad compartida, IAM y «qué servicio uso para…». Pero no abandones D4: son preguntas casi «regaladas» si te sabes los planes de soporte y los modelos de precios.

Cómo leer una pregunta del examen#

1. Lee la última frase primero. Ahí está la restricción que decide: «MENOR costo», «MENOR esfuerzo operativo», «MÁS alta disponibilidad», «sin administrar servidores».
2. Subraya mentalmente las palabras clave: «auditar quién hizo qué» (CloudTrail), «historial de configuración» (Config), «datos personales en S3» (Macie), «interrumpible» (Spot).
3. Descarta lo que no es de la categoría (si preguntan por almacenamiento de objetos, fuera EBS y EFS).
4. Entre dos finalistas, elige la opción más administrada y más simple que cumpla todo: AWS casi siempre premia «serverless / administrado» frente a «instálalo tú en EC2».
5. En las múltiples elige exactamente 2; cada una debe ser correcta por sí sola.

Plan de estudio#

Elige un ritmo y respétalo. Lo importante no es cuántas horas lees, sino cuántas veces recuperas la información de memoria y a qué intervalos.

La técnica: del «lo leí» al «lo sé»#

📒 Cuaderno de errores: cada pregunta que falles va a una lista con tres columnas: «lo que elegí», «lo correcto» y «la palabra del enunciado que debió delatarlo». Relee esa lista antes de cada simulacro. Es la herramienta más rentable de todo el plan.

Ritmo intensivo: 2 semanas (≈ 2–3 h/día)#

Ritmo relajado: 4 semanas (≈ 1 h/día)#

🚦 Semáforo para agendar: verde si sacas 80 % o más en los tres exámenes de estilo oficial; amarillo (70–79 %) si te conviene una semana más de banco y cuaderno de errores; rojo (< 70 %) si debes volver a la guía en los dominios con más fallos.

🌥️ Dominio 1 — Conceptos de la nube (24 %)#

La computación en la nube es la entrega bajo demanda de recursos de TI (servidores, almacenamiento, bases de datos, software) a través de internet con pago por uso. En vez de comprar y mantener tu propio centro de datos, alquilas lo que necesitas, cuando lo necesitas, y lo devuelves cuando ya no.

🔌 Analogía base: la electricidad. Hace un siglo, las fábricas tenían su propio generador. Hoy se conectan a la red eléctrica y pagan por kilovatio consumido. La nube hace lo mismo con la informática: dejas de «tener un generador» (centro de datos) y te conectas a la «red» de AWS.

1.1 Beneficios de la nube de AWS#

AWS resume las ventajas de la nube en seis beneficios. El examen los parafrasea, así que reconócelos por su idea, no por su nombre exacto:

Además, el examen menciona estas propiedades, que conviene no confundir:

Si el enunciado dice… → piensa en…

• «picos impredecibles», «Black Friday», «ajustar recursos a la demanda» → elasticidad (Auto Scaling).
• «dejar de comprar servidores por adelantado» → gasto variable / OpEx.
• «precios más bajos porque AWS tiene millones de clientes» → economías de escala.
• «lanzar en Europa y Asia en un día» → global en minutos.
• «el equipo deja de parchar hardware y se enfoca en el producto» → dejar de gastar en centros de datos / servicios administrados.

⚠️ Trampa frecuente: «La nube elimina todos los costos» o «la nube hace que AWS se encargue de toda la seguridad». Falso las dos. La nube reduce costos y comparte la seguridad (lo verás en D2).

1.2 Principios de diseño: AWS Well-Architected Framework#

El AWS Well-Architected Framework es un conjunto de buenas prácticas para diseñar y evaluar arquitecturas en la nube. Se organiza en seis pilares. Hay una herramienta gratuita, la AWS Well-Architected Tool, que te hace preguntas sobre tu carga de trabajo y te devuelve riesgos y mejoras.

🏠 Analogía: es el reglamento de construcción de una casa. No te dice qué casa construir, pero sí que tenga buenas bases (fiabilidad), cerraduras (seguridad), mantenimiento (excelencia operativa), espacios adecuados (rendimiento), presupuesto controlado (costos) y paneles solares (sostenibilidad).

🧠 Mnemotecnia de los 6 pilares: «En Su Fiesta, Elena Ordenó Sushi» → Excelencia operativa, Seguridad, Fiabilidad, Eficiencia del rendimiento, Optimización de costos, Sostenibilidad. En inglés: SCORPS (Security, Cost, Operational excellence, Reliability, Performance, Sustainability).

Principios generales de diseño en la nube que aparecen en preguntas:

• Diseñar para fallas («design for failure»): asume que todo fallará algún día; usa varias AZ y recuperación automática. «Todo falla todo el tiempo» (Werner Vogels).
• Desacoplar componentes: que una parte pueda fallar o escalar sin arrastrar a las demás (colas con Amazon SQS, eventos con Amazon EventBridge, balanceadores).
• Implementar elasticidad: escalar según la demanda (Auto Scaling).
• Pensar en paralelo: muchas máquinas pequeñas en paralelo en vez de una gigante.
• Tratar los servidores como ganado, no como mascotas («cattle, not pets»): reemplazables y creados con plantillas, no reparados a mano.
• Automatizar e infraestructura como código (AWS CloudFormation).
• Usar servicios administrados y serverless para reducir la carga operativa.

Si el enunciado dice… → piensa en…

• «ejecutar cambios pequeños y reversibles», «runbooks», «operaciones como código» → Excelencia operativa.
• «recuperarse automáticamente de un fallo», «probar la recuperación», «Multi-AZ» → Fiabilidad.
• «elegir el tipo de instancia correcto», «usar serverless para ir más rápido» → Eficiencia del rendimiento.
• «apagar recursos ociosos», «etiquetas para atribuir gasto», «rightsizing» → Optimización de costos.
• «reducir la huella de carbono», «maximizar la utilización» → Sostenibilidad.
• «mínimo privilegio», «trazabilidad», «cifrar» → Seguridad.

⚠️ Trampa frecuente: Fiabilidad vs. Eficiencia del rendimiento. Si la frase habla de recuperarse o de cumplir la demanda sin caerse, es Fiabilidad. Si habla de elegir el recurso adecuado o de tecnologías avanzadas, es Eficiencia del rendimiento. Y la Sostenibilidad es el pilar más reciente (el sexto).

1.3 Beneficios y estrategias de migración#

AWS Cloud Adoption Framework (AWS CAF)

El AWS CAF es una guía para que una organización (no solo el equipo técnico) adopte la nube con éxito. Agrupa las capacidades en seis perspectivas: tres de negocio y tres técnicas.

🧠 Mnemotecnia CAF: «Nunca Pidas Gaseosa, Pide Siempre Ollucos» → Negocio, Personas, Gobernanza (los de traje 👔) | Plataforma, Seguridad, Operaciones (los de casco 👷).

El CAF también describe los beneficios de adoptar la nube: menor riesgo del negocio, mejor desempeño ESG (ambiental, social y de gobierno), más ingresos y mayor eficiencia operativa. Y un recorrido en cuatro fases: Envision (visualizar el valor) → Align (alinear y detectar brechas) → Launch (lanzar pilotos) → Scale (escalar).

Las 7R: estrategias de migración

Cuando una empresa migra sus aplicaciones, decide para cada una qué hacer. Ordenadas de menor a mayor esfuerzo y cambio:

🧠 Mnemotecnia 7R: «Retira, Retén, y luego H-L-P-P-F»: reHost, reLocate, rePlatform, rePurchase, reFactor — «Hoy Llega Papá, Prepara Fiesta». Cuanto más avanzas en la frase, más cambia la aplicación.

Servicios y herramientas de migración

⚠️ Trampa frecuente: AWS Snowmobile y Snowcone ya no se ofrecen; no los elijas. Y no confundas DMS (mueve los datos) con SCT (convierte el esquema): en una migración heterogénea se usan los dos.

Si el enunciado dice… → piensa en…

• «guía para que toda la organización adopte la nube», «identificar brechas de habilidades» → AWS CAF.
• «migrar lo más rápido posible sin cambiar código» → Rehost (AWS Application Migration Service).
• «aprovechar la migración para usar un servicio administrado sin rediseñar» → Replatform.
• «rediseñar en microservicios o serverless para ganar agilidad» → Refactor.
• «cambiar a un producto SaaS» → Repurchase.
• «VMware sin cambios ni nuevo hardware» → Relocate.
• «no hay suficiente ancho de banda», «sitio desconectado» → AWS Snowball Edge.

1.4 Economía de la nube#

TCO (Total Cost of Ownership, costo total de propiedad): al comparar on-premises vs. nube no basta el precio del servidor. Hay que sumar los costos directos (hardware, licencias, almacenamiento, red) y los indirectos (electricidad, refrigeración, espacio físico, seguridad física, personal que opera, tiempo de aprovisionamiento, hardware ocioso). 🧊 Analogía del iceberg: el precio del servidor es la punta; lo de abajo (energía, personal, local) suele ser lo más grande.

Licencias:

• Licencia incluida (license-included): el precio de la instancia o de RDS ya incluye la licencia (p. ej., Windows Server, SQL Server). Simple, sin compras previas.
• BYOL (Bring Your Own License): reutilizas licencias que ya posees. Algunas licencias se cuentan por socket o núcleo físico y exigen Amazon EC2 Dedicated Hosts. AWS License Manager ayuda a controlar su uso.

⚠️ Trampa frecuente: «Migrar a la nube siempre reduce el costo de inmediato». No: si haces lift-and-shift con servidores sobredimensionados y encendidos 24/7, puedes pagar igual o más. El ahorro llega con rightsizing, elasticidad, servicios administrados y el modelo de compra adecuado.

Si el enunciado dice… → piensa en…

• «reducir el gasto inicial», «sin inversión por adelantado» → OpEx / pago por uso.
• «comparar el costo total del centro de datos con AWS» → TCO (y Migration Evaluator o AWS Pricing Calculator).
• «reducir el tiempo que el equipo dedica a parches y copias» → servicios administrados.
• «instancias infrautilizadas» → rightsizing (AWS Compute Optimizer).

🔐 Dominio 2 — Seguridad y cumplimiento (30 %)#

Es el dominio con más preguntas después de D3 y el que más «se gana» con método: si dominas el modelo de responsabilidad compartida y sabes qué servicio de seguridad hace qué, tienes casi un tercio del examen.

2.1 Modelo de responsabilidad compartida#

La seguridad en AWS se reparte entre AWS y el cliente:

• 🏗️ AWS: seguridad DE la nube. Protege la infraestructura que ejecuta todos los servicios: centros de datos (seguridad física, energía, refrigeración), hardware, red global, el software de virtualización (hipervisor) y, en los servicios administrados, el sistema operativo y el software del servicio.
• 🧑‍💻 Cliente: seguridad EN la nube. Todo lo que pone o configura dentro: sus datos, la gestión de identidades y accesos (IAM), la configuración de security groups y firewalls, el cifrado que elige, el sistema operativo invitado y las aplicaciones (si usa IaaS).

🏢 Analogía del edificio de departamentos: el dueño del edificio (AWS) se encarga de los cimientos, el ascensor, el portero y la cerca perimetral. Tú (cliente) decides a quién le das copia de tu llave, si cierras tu puerta con llave y qué guardas en tu caja fuerte. Si dejas la puerta abierta, no es culpa del portero.

🧠 Mnemotecnia: «AWS cuida DE (la casa DE ladrillos), tú cuidas lo que está EN (lo que metes EN la casa)». Regla de oro: tus datos y quién accede a ellos son SIEMPRE tu responsabilidad, en cualquier servicio.

Cómo cambia según el servicio

Cuanto más administrado es el servicio, más responsabilidades asume AWS. Pero la línea nunca llega a tus datos ni a tus permisos.

Controles heredados, compartidos y específicos del cliente

⚠️ Trampas frecuentes: (1) «AWS parcha el SO de mis instancias EC2» → falso; en EC2 el SO invitado es tuyo. (2) «En RDS el cliente parcha el motor» → falso; lo hace AWS. (3) «AWS es responsable de configurar mis security groups» → falso. (4) «La destrucción de discos al final de su vida útil» → AWS. (5) «Formación del personal» → control compartido.

2.2 Seguridad, gobernanza y cumplimiento#

Cumplimiento (compliance)

• AWS Artifact 📄: portal de autoservicio y gratuito para descargar informes de cumplimiento de AWS (SOC 1/2/3, ISO 27001, PCI DSS…) con Artifact Reports y para revisar y aceptar acuerdos (p. ej., BAA para datos de salud en EE. UU.) con Artifact Agreements. Pista: «el auditor pide el informe SOC de AWS».
• AWS Compliance Programs: AWS se certifica en normas internacionales y sectoriales. Eso significa que la infraestructura cumple; tu carga de trabajo debe cumplir también por tu parte (responsabilidad compartida).
• AWS Audit Manager: recopila evidencias automáticamente de tu uso de AWS y las mapea a marcos (PCI DSS, GDPR, HIPAA) para preparar tus auditorías.
• Regiones y soberanía de datos: los datos no salen de la Región que eliges salvo que tú los muevas o repliques. Si una ley exige que los datos permanezcan en un país, elige la Región adecuada (y puedes reforzarlo con SCP que denieguen otras Regiones).

⚠️ Artifact vs. Audit Manager: Artifact = informes de AWS (lo que AWS cumple). Audit Manager = evidencias de tu cuenta (lo que tú cumples).

Cifrado

Monitoreo, auditoría y detección

Estos servicios se confunden a menudo. Apréndelos por la pregunta que responde cada uno:

🧠 Mnemotecnia: «Trail = rastro de quién pasó · Config = configuración · Watch = vigila métricas · Guard = guardia de amenazas · Inspector = inspecciona vulnerabilidades · Detective = investiga · Macie = «Mis Archivos Con Información Esensible (PII)» · Hub = centro que junta todo».

Gobernanza multicuenta

• AWS Organizations: agrupa varias cuentas AWS bajo una cuenta de administración, organizadas en unidades organizativas (OU). Da facturación consolidada y políticas centralizadas.
• Service Control Policies (SCP): políticas de Organizations que definen el máximo de permisos disponible en las cuentas de una OU. No otorgan permisos: ponen un «techo». Afectan incluso al usuario root de las cuentas miembro (no a la cuenta de administración). Ej.: «denegar el uso de Regiones fuera de Sudamérica».
• AWS Control Tower: crea y gobierna automáticamente un entorno multicuenta seguro (landing zone) siguiendo buenas prácticas, con controles (antes «guardrails») preventivos y detectivos y un panel de cumplimiento. Usa Organizations por debajo.

🏛️ Analogía: Organizations es el holding que agrupa a las empresas; las SCP son el reglamento interno que ninguna filial puede saltarse; Control Tower es la constructora que te entrega el holding ya montado con el reglamento puesto.

Si el enunciado dice… → piensa en…

• «informe de cumplimiento de AWS», «acuerdo BAA» → AWS Artifact.
• «quién eliminó el recurso», «registro de llamadas a la API», «auditoría de actividad» → AWS CloudTrail.
• «historial de cambios de configuración», «¿el recurso cumple la regla?» → AWS Config.
• «alarma cuando la CPU pase de 80 %» → Amazon CloudWatch.
• «actividad sospechosa», «minería de criptomonedas», «credenciales usadas desde un país inusual» → Amazon GuardDuty.
• «vulnerabilidades de software (CVE)» → Amazon Inspector.
• «PII», «números de tarjeta en S3» → Amazon Macie.
• «causa raíz», «investigar» → Amazon Detective.
• «vista única de seguridad de varias cuentas» → AWS Security Hub.
• «los datos no pueden salir del país» → elegir la Región adecuada (+ SCP).

2.3 Gestión de accesos (IAM)#

AWS Identity and Access Management (IAM) controla quién (autenticación) puede hacer qué (autorización) sobre qué recursos. Es global (no depende de una Región) y gratuito.

El usuario root

Es la identidad creada con el correo de la cuenta y tiene acceso total. Buenas prácticas: activar MFA, no crear claves de acceso para root, no usarlo para el trabajo diario y guardarlo bajo llave. Úsalo solo para las tareas que lo exigen:

• Cambiar la configuración de la cuenta (nombre, correo, contraseña de root).
• Cerrar la cuenta de AWS.
• Cambiar el plan de AWS Support (o cancelarlo).
• Restaurar permisos de un administrador IAM que se bloqueó a sí mismo.
• Registrarse como vendedor en el Reserved Instance Marketplace.
• Configurar MFA Delete en un bucket S3; editar o borrar una política de bucket que bloqueó a todos.
• Activar el acceso de IAM a la consola de facturación; solicitar AWS GovCloud (US).

🧠 Mnemotecnia root: «Root cierra, cambia y rescata»: cierra la cuenta, cambia el correo o la contraseña del root, rescata los permisos de IAM si el único administrador se bloqueó. Si la tarea suena a «gestionar la cuenta como contrato», es de root. Ojo: cambiar el plan de soporte o el nombre de la cuenta ya no son exclusivas del root.

Buenas prácticas de identidad

• Principio de mínimo privilegio: conceder solo los permisos necesarios para la tarea, y nada más. Herramienta de apoyo: IAM Access Analyzer (detecta accesos externos y ayuda a ajustar políticas).
• MFA (autenticación multifactor): algo que sabes (contraseña) + algo que tienes (app de autenticación, llave FIDO/passkey).
• Credenciales temporales en lugar de permanentes: usa roles. Una aplicación en EC2 debe usar un rol de instancia, nunca claves de acceso guardadas en el código.
• Política de contraseñas fuerte y rotación de claves de acceso cuando existan. Las claves de acceso (access key ID + secret) sirven para la AWS CLI y los SDK; no se comparten ni se suben a repositorios.
• Asignar permisos a grupos, no usuario por usuario.

Identidad a escala y secretos

⚠️ Trampas frecuentes: (1) Identity Center = empleados; Cognito = clientes de tu app. (2) Para que una app en EC2 lea S3 → rol IAM, no claves de acceso. (3) «Rotación automática» → Secrets Manager, no Parameter Store. (4) IAM es global; no se crean usuarios «por Región».

2.4 Componentes y recursos de seguridad#

Security groups vs. network ACL

🏘️ Analogía: la network ACL es la garita del condominio (controla la entrada a toda la subred, revisa a todos al entrar y al salir). El security group es la puerta de tu casa (protege a cada instancia y recuerda a quién dejó salir para dejarlo volver).

🧠 Mnemotecnia: «Security group = Stateful = Solo permite». NACL = «No recuerda» (stateless) y puede decir «No» (Deny).

Protección perimetral y de red

Recursos y herramientas de apoyo

• AWS Trusted Advisor: revisa tu cuenta y recomienda mejoras en optimización de costos, rendimiento, seguridad (p. ej., MFA en root, buckets S3 abiertos, puertos abiertos en security groups), tolerancia a fallos, límites de servicio y excelencia operativa. Con Basic Support solo ves los checks básicos (algunos de seguridad y de cuotas de servicio); el conjunto completo requiere AWS Business Support+ o superior (ver 4.3).
• AWS Marketplace: catálogo de software de terceros (firewalls, antivirus, SIEM, AMIs endurecidas) que compras y despliegas en AWS con facturación en tu factura de AWS.
• AWS Security Center (aws.amazon.com/security), AWS Security Blog, AWS Knowledge Center y la documentación de seguridad: fuentes oficiales de buenas prácticas, boletines y respuestas a preguntas frecuentes.

⚠️ Trampas frecuentes: WAF (ataques web en capa 7) ≠ Shield (DDoS). Shield Standard ya lo tienes gratis; si el enunciado pide «expertos en DDoS 24/7» o «protección de costos», es Advanced. Y para «bloquear una IP específica en la subred» → NACL (los security groups no tienen Deny).

🧰 Dominio 3 — Tecnología y servicios de la nube (34 %)#

Es el dominio más grande y el más «memorístico». La clave no es saber configurar cada servicio, sino reconocer cuál encaja con un escenario. Estudia cada tarea con su tabla «¿cuál uso?» y con las pistas del enunciado.

3.1 Formas de desplegar y operar en AWS#

Todo en AWS es una API: cada clic de la consola, cada comando y cada línea de código terminan siendo llamadas a la API (y por eso CloudTrail puede registrarlas todas).

Conectividad entre tu red y AWS

🛣️ Analogía: Site-to-Site VPN es un camión blindado por la carretera pública; Direct Connect es tu propia carretera privada hasta AWS; Client VPN es el pase individual de cada trabajador.

3.2 Infraestructura global de AWS#

¿Cómo elegir una Región?

Cuatro factores, en este orden habitual de prioridad:

1. ⚖️ Cumplimiento y soberanía de datos (requisitos legales: si la ley exige el país, no hay más que hablar).
2. 📶 Latencia: cerca de tus usuarios.
3. 🧩 Servicios disponibles: no todos los servicios llegan a la vez a todas las Regiones.
4. 💲 Precio: varía entre Regiones.

🧠 Mnemotecnia: «Con Latencia Se Paga» → Cumplimiento, Latencia, Servicios, Precio.

Alta disponibilidad y recuperación ante desastres

• Varias AZ (Multi-AZ) → alta disponibilidad ante la falla de un centro de datos. Es la recomendación por defecto para producción.
• Varias Regiones → recuperación ante desastres (DR) ante un evento regional, o latencia global, o requisitos de continuidad.

⚠️ Trampas frecuentes: una AZ ≠ un único centro de datos (puede tener varios). Edge locations no ejecutan tus instancias EC2 (son para caché y red). Para «alta disponibilidad» la respuesta suele ser varias AZ, no varias Regiones; para «desastre regional», varias Regiones.

3.3 Servicios de cómputo#

Amazon EC2: servidores virtuales

Amazon EC2 (Elastic Compute Cloud) ofrece máquinas virtuales («instancias») que eliges por tipo y tamaño. Una AMI (Amazon Machine Image) es la plantilla con el sistema operativo y el software de arranque. Tú administras el SO (IaaS).

🧠 Mnemotecnia de familias: C = Cómputo/CPU · R = RAM · M = Medio (uso general) · I = IOPS (almacenamiento) · G/P = Gráficos/Proceso en GPU.

Escalado y balanceo

• Amazon EC2 Auto Scaling: añade o quita instancias según la demanda (políticas dinámicas, programadas o predictivas) y reemplaza las instancias en mal estado. Define capacidad mínima, deseada y máxima.
• Elastic Load Balancing (ELB): reparte el tráfico entre varias instancias o contenedores en varias AZ y deja de enviar tráfico a los destinos no saludables (health checks).

Contenedores y serverless

📦 Un contenedor empaqueta la aplicación con todas sus dependencias para que corra igual en cualquier lado (como un contenedor de barco estándar que cabe en cualquier puerto).

Otras opciones de cómputo

¿Cuál uso? Guía rápida de cómputo

⚠️ Trampas frecuentes: Fargate no es un orquestador (usa ECS o EKS); es la forma serverless de correr sus contenedores. Lambda no sirve para procesos de más de 15 minutos. «Lift and shift de un servidor» → EC2, no Lambda.

3.4 Bases de datos#

Primera decisión: ¿la gestiono yo o la gestiona AWS?

• Autoadministrada en EC2: control total (versiones raras, acceso al SO), pero tú haces parches, copias, alta disponibilidad y escalado. Útil si necesitas un motor o configuración no soportados.
• Administrada (RDS, Aurora, DynamoDB…): AWS hace aprovisionamiento, parches, copias automáticas, Multi-AZ y escalado; tú te centras en el esquema, las consultas y los datos. Es la respuesta preferida cuando el enunciado dice «reducir la carga operativa».

🧠 Mnemotecnia por forma de los datos: «Tablas → RDS/Aurora · Llave-valor → DynamoDB · Documentos → DocumentDB · Grafos → Neptune · Tiempo → Timestream · Cassandra → Keyspaces · Memoria → ElastiCache (caché) / MemoryDB (durable) · Analítica → Redshift».

⚠️ Trampas frecuentes: Amazon QLDB (libro mayor) está descontinuado: no lo elijas como respuesta. RDS Multi-AZ es para alta disponibilidad; las réplicas de lectura son para rendimiento de lectura. Para migrar bases de datos: AWS DMS mueve los datos y AWS SCT convierte el esquema (ver 1.3).

3.5 Redes#

Amazon VPC (Virtual Private Cloud) es tu red privada y aislada dentro de AWS, en una Región. 🏘️ Analogía del condominio: la VPC es el condominio; las subredes son las manzanas (cada una vive en una sola AZ); el internet gateway es la puerta principal hacia la calle; las route tables son los letreros que indican por dónde ir.

Amazon Route 53

Servicio de DNS (la «guía telefónica» de internet: traduce www.ejemplo.pe a una IP), registro de dominios y health checks. Su nombre viene del puerto 53 del DNS. Políticas de enrutamiento:

Entrega global y rendimiento

⚠️ Trampas frecuentes: CloudFront = caché de contenido; Global Accelerator = ruta optimizada sin caché e IP estáticas. NAT gateway = salida de subred privada; internet gateway = entrada y salida de subred pública. Muchas VPC conectadas → Transit Gateway, no decenas de peerings.

3.6 Almacenamiento#

Tres tipos de almacenamiento, tres analogías:

Amazon S3

Amazon S3 (Simple Storage Service) guarda objetos (archivos + metadatos) en buckets con nombre único global. Capacidad prácticamente ilimitada, objetos de hasta 5 TB, durabilidad de 11 nueves (99,999999999 %). Usos: copias de seguridad, data lakes, sitios web estáticos, medios. Funciones clave:

• Versioning: guarda versiones anteriores; protege de borrados y sobrescrituras accidentales.
• Lifecycle (políticas de ciclo de vida): mover automáticamente objetos a clases más baratas con el tiempo o borrarlos.
• Replicación: copiar objetos a otro bucket en otra Región (CRR) o en la misma (SRR).
• Block Public Access, políticas de bucket y cifrado por defecto; S3 Object Lock para almacenamiento inmutable (WORM).

🧠 Mnemotecnia del termómetro: los datos se van «enfriando»: caliente (Standard) → tibio (Standard-IA / One Zone-IA) → frío (Glacier Instant) → helado (Glacier Flexible) → congelado (Deep Archive). Cuanto más frío, más barato guardar y más caro/lento sacar. ¿No sabes la temperatura? → Intelligent-Tiering, el termostato automático.

Bloques y archivos

Híbrido, respaldo y recuperación

¿Cuál uso? Guía rápida de almacenamiento

⚠️ Trampas frecuentes: EBS se asocia normalmente a una sola instancia y vive en una AZ; para compartir entre muchas instancias → EFS. «Datos que deben guardarse 7 años y casi nunca se leen» → Glacier Deep Archive. «Datos recreables, infrecuentes, más baratos» → One Zone-IA.

3.7 IA/ML y analítica#

Para el CLF-C02 basta con asociar cada servicio con su tarea. Piensa en tres niveles: los servicios de IA «listos para usar» (llamas a una API), la plataforma para crear tus propios modelos y la IA generativa.

🧠 Mnemotecnia de los servicios de IA: «Polly el loro habla 🦜 · Transcribe escribe lo que oye ✍️ · Rekognition re-conoce caras 👀 · Textract extrae texto de papeles 📄 · Comprehend comprende el sentimiento 💬 · Lex conversa 🤖 · Kendra busca 🔍 · Personalize recomienda 🎯 · Translate traduce 🌐».

⚠️ Amazon Forecast está cerrado a nuevos clientes: no lo elijas como respuesta. Para pronósticos hoy se usa SageMaker AI (por ejemplo, SageMaker Canvas).

Analítica de datos

⚠️ Trampas frecuentes: Athena (consultar S3 con SQL, sin servidores) vs. Redshift (data warehouse con datos cargados). Kinesis Data Streams (procesar en tiempo real con tu código) vs. Data Firehose (entregar a un destino sin administrar). Quick Sight visualiza; no almacena ni transforma.

3.8 Otras categorías de servicios#

Integración de aplicaciones

Aplicaciones de negocio, cómputo de usuario final y frontend

Herramientas para desarrolladores

🧠 Mnemotecnia CI/CD: «Pipeline es la tubería; dentro, Build construye y Deploy despliega; Artifact guarda las piezas; X-Ray hace la radiografía cuando algo duele». Ojo: AWS CodeCommit y AWS Cloud9 no son respuestas válidas en este curso (cerrados a nuevos clientes); el código fuente suele estar en GitHub, GitLab o Bitbucket conectados a CodePipeline.

IoT y observabilidad

• AWS IoT Core: conectar de forma segura miles de millones de dispositivos IoT a la nube y enrutar sus mensajes.
• AWS IoT Greengrass: ejecutar procesamiento y ML localmente en los dispositivos (en el borde), incluso sin conexión.
• Amazon CloudWatch: métricas, logs, alarmas, paneles; puede disparar acciones (Auto Scaling, notificaciones SNS).
• AWS Health Dashboard: estado de los servicios de AWS en general (service health) y, sobre todo, eventos que afectan a tu cuenta (your account health): mantenimientos programados, incidencias en tus recursos.

⚠️ Trampas frecuentes: SQS (cola, pull) vs. SNS (difusión, push). WorkSpaces (escritorio completo) vs. AppStream 2.0 (una aplicación) vs. WorkSpaces Secure Browser (solo apps web internas desde un navegador seguro). CloudWatch (rendimiento) vs. CloudTrail (auditoría de API). Health Dashboard (eventos de AWS que te afectan) vs. CloudWatch (tus métricas).

💰 Dominio 4 — Facturación, precios y soporte (12 %)#

Pocas preguntas, pero muy predecibles. Tres principios de precios de AWS: pagas por lo que usas, pagas menos si te comprometes (reservas) y pagas menos por unidad cuanto más usas (precios por niveles).

4.1 Modelos de precios#

🚕 Analogía del transporte: On-Demand es tomar un taxi cuando lo necesitas; Reserved Instances es alquilar un auto por 1 o 3 años; Savings Plans es un plan de gasto mensual comprometido que vale para cualquier auto de la flota; Spot es subirte a un asiento libre de última hora muy barato, pero te pueden pedir que bajes; Dedicated Host es alquilar el auto completo con su número de chasis para tu seguro.

🧠 Mnemotecnia de descuentos: «Spot 90, Reserva 72»: Spot llega a 90 % (pero te pueden sacar), RI y Savings Plans llegan a 72 % (pero te comprometes 1 o 3 años). Más compromiso o más riesgo = más descuento.

Si el enunciado dice… → piensa en…

• «carga estable 24/7 durante 3 años» → Reserved Instances o Savings Plans.
• «flexibilidad para cambiar de familia, Región o usar Lambda y Fargate» → Compute Savings Plans.
• «puede detenerse y reanudarse», «tolerante a fallos», «MÁS barato» → Spot.
• «corto plazo, impredecible, no puede interrumpirse» → On-Demand.
• «licencias por socket o núcleo físico» → Dedicated Hosts.
• «asegurar capacidad en una AZ sin compromiso de largo plazo» → On-Demand Capacity Reservations.

Capa gratuita (AWS Free Tier)

• Siempre gratis (Always Free): ciertos límites que no caducan, p. ej. 1 millón de solicitudes al mes en AWS Lambda o 25 GB en DynamoDB.
• Cuentas nuevas (desde julio de 2025): créditos de bienvenida (hasta 200 USD) y la opción de un plan gratuito por tiempo limitado (6 meses) o un plan de pago. Las cuentas anteriores conservaron las ofertas «12 meses gratis» (p. ej., 750 h/mes de ciertas instancias EC2).
• Pruebas gratuitas (trials) de corto plazo para algunos servicios.

ℹ️ Las cifras de la capa gratuita cambian: verifica en la web oficial. Para el examen basta saber que existen ofertas permanentes y ofertas de tiempo limitado, y que conviene configurar AWS Budgets para no llevarse sorpresas.

Transferencia de datos y otros precios

Amazon S3 cobra por GB almacenado (por clase y con precios por niveles), por solicitudes, por recuperación (clases IA y Glacier) y por transferencia de salida. Lambda cobra por solicitudes y duración; EC2 por tiempo de cómputo, almacenamiento EBS y transferencia.

⚠️ Trampas frecuentes: «subir datos a AWS cuesta» → falso, la entrada es gratis. Spot no sirve para una base de datos transaccional que no puede detenerse. Dedicated Instances no sirven para licencias por socket: hace falta Dedicated Host.

4.2 Facturación y gestión de costos#

🧭 Ordena las herramientas por momento: antes de gastar (estimar), mientras gastas (alertar) y después (analizar).

🧠 Mnemotecnia: «Calculator calcula antes · Budgets avisa durante · Explorer explora después · CUR da el detalle CURioso línea por línea».

Varias cuentas y etiquetas

• AWS Organizations — facturación consolidada: una sola factura para todas las cuentas; el uso se suma para alcanzar antes los descuentos por volumen (precios por niveles) y se comparten los descuentos de RI y Savings Plans entre cuentas. Sin costo adicional.
• Etiquetas de asignación de costos (cost allocation tags): pares clave-valor (proyecto=ecommerce, area=marketing) que, una vez activadas en Billing, permiten atribuir el gasto por proyecto, área o centro de costos en Cost Explorer y en los informes.

⚠️ Trampas frecuentes: Budgets alerta; Cost Explorer analiza; Pricing Calculator estima antes. Ninguna de ellas «detiene» el gasto por sí misma por defecto (Budgets puede configurar acciones). Y las etiquetas no sirven para costos hasta que se activan como etiquetas de asignación de costos.

4.3 Recursos técnicos y AWS Support#

Planes de AWS Support

AWS renovó sus planes de soporte. Los planes vigentes, de menor a mayor, son Basic Support, AWS Business Support+, AWS Enterprise Support y AWS Unified Operations.

* Tiempos y precios orientativos: verifica en la web oficial de AWS Support antes del examen.

🧠 Mnemotecnia de planes: «Básico, Business+, Enterprise, Unified: gratis → IA + expertos → TAM → equipo de misión crítica». Y los tiempos críticos bajan: «30 → 15 → 5». Si el enunciado dice «TAM designado» → Enterprise Support; «equipo de especialistas designado e Incident Detection and Response» → Unified Operations; «todos los checks de Trusted Advisor al menor costo» → Business Support+.

📜 Planes heredados (no son contenido de examen): Developer, Business y Enterprise On-Ramp son planes antiguos que se retiran el 1 de enero de 2027. Puede que los veas en material viejo de internet; no los elijas como respuesta en las preguntas de este curso.

AWS Trusted Advisor

Revisa tu cuenta y da recomendaciones en estas categorías:

🧠 Mnemotecnia Trusted Advisor: «Cuida Rápido Su Tienda Limeña Ordenada» → Costos, Rendimiento, Seguridad, Tolerancia a fallos, Límites de servicio, excelencia Operativa.

Otros recursos de ayuda

⚠️ Trampas frecuentes: Professional Services (consultoría de AWS) vs. APN (socios externos) vs. Managed Services (AWS opera por ti). Reportar abuso → Trust & Safety, no AWS Support. Basic Support no incluye casos técnicos con expertos.

🗺️ Mapa de servicios por categoría#

Úsalo como repaso final: tapa la tercera columna e intenta decir para qué sirve cada servicio.

🚀 Siguiente paso#

Terminaste la primera pasada. Ahora toca convertir lo leído en respuestas rápidas y seguras:

1. Repasa el resumen denso en Conceptos Clave CLF-C02, sobre todo las parejas que se confunden (CloudTrail/Config, SQS/SNS, Athena/Redshift, Security group/NACL).
2. Haz el Simulacro Básico. Si sacas 80 % o más, pasa al Intermedio; si no, repite las flashcards de los dominios donde fallaste.
3. Sigue el plan de estudio que elegiste hasta los tres exámenes de estilo oficial, y lleva al día tu cuaderno de errores.

✅ Checklist final antes de agendar#

Marca mentalmente solo lo que podrías explicarle a otra persona sin mirar:

• Los 6 beneficios de la nube y la diferencia entre elasticidad, escalabilidad, alta disponibilidad y tolerancia a fallos.
• Los 6 pilares de Well-Architected con un ejemplo de cada uno.
• Las 6 perspectivas del AWS CAF y las 7R con un ejemplo de cada una.
• Qué es de AWS y qué es del cliente en EC2, RDS, Lambda y S3.
• CloudTrail vs. Config vs. CloudWatch; GuardDuty vs. Inspector vs. Macie vs. Detective vs. Security Hub.
• Usuario vs. grupo vs. rol; tareas exclusivas del root; Identity Center vs. Cognito.
• Security group vs. NACL; WAF vs. Shield Standard vs. Shield Advanced.
• Región, AZ, edge location, Local Zones, Wavelength y Outposts.
• Familias EC2, tipos de balanceador, ECS/EKS/Fargate/Lambda.
• Qué base de datos usar según la forma de los datos.
• Subred pública/privada, IGW vs. NAT, peering vs. Transit Gateway, CloudFront vs. Global Accelerator.
• Las clases de S3 de la más caliente a la más congelada; EBS vs. EFS vs. instance store.
• Qué hace cada servicio de IA (Polly, Transcribe, Textract…) y de analítica (Athena, Redshift, Glue…).
• On-Demand, RI, Savings Plans, Spot, Dedicated Hosts y sus descuentos.
• Pricing Calculator vs. Budgets vs. Cost Explorer vs. CUR.
• Los 4 planes de AWS Support vigentes y qué los diferencia; las categorías de Trusted Advisor.

🍀 El día del examen: duerme bien, llega (o conéctate) 30 minutos antes, lee primero la última frase de cada pregunta, marca para revisar las dudosas y no dejes ninguna en blanco. ¡Tú puedes!