Muéstrame tus 10.000 intentos: cómo empezar en AWS y practicar gratis
Soy Roxs 👩💻| Software Developer | DevOps | DevSecOps | en @295DevOps 🖼 Content Creator. No se puede crecer si no estas dispuesto a saltar a la zona de peligro 🔥
Cuando alguien me pregunta cómo empezar en AWS, casi siempre aparecen las mismas dudas: qué servicio aprender primero, si hace falta una certificación, cuánto cuesta practicar o qué pasa si se rompe algo. Y es lógico. AWS tiene muchísimos servicios y, visto desde afuera, puede parecer enorme.
Pero creo que muchas veces arrancamos por el lugar equivocado.
Antes de intentar entender AWS completo, conviene empezar por algo mucho más simple: hacer pequeños experimentos.
Hace tiempo leí una reflexión de Isra García llamada Muéstrame tus 10.000 intentos. La idea, llevada al mundo tecnológico, tiene muchísimo sentido. A veces queremos diseñar buenas arquitecturas antes de haber construido arquitecturas simples, escribir buen código antes de haber escrito suficiente código o entender cloud antes de haber desplegado, roto, investigado y vuelto a desplegar.
Con AWS pasa exactamente eso.
Tu primera arquitectura probablemente sea sencilla. Tu primera policy de IAM puede fallar. Una Lambda puede darte un error de permisos y una VPC puede parecerte confusa al principio. Todo eso forma parte del aprendizaje.
No necesitás llegar al intento número 100 hoy.
Necesitás hacer el primero.
No intentes aprender AWS completo
Uno de los errores más comunes al empezar es mirar el catálogo completo de AWS y pensar que hay que aprender todo.
No hace falta.
Al principio es mucho más útil entender problemas que memorizar nombres de servicios. Casi cualquier arquitectura cloud necesita resolver algunas cosas básicas: ejecutar aplicaciones, guardar datos, controlar accesos, conectar componentes y observar qué está pasando.
Después podemos asociar cada necesidad con algunos servicios.
| Necesidad | Servicios para explorar |
|---|---|
| Ejecutar aplicaciones | Amazon EC2, AWS Lambda, Amazon ECS |
| Guardar objetos | Amazon S3 |
| Persistir datos | Amazon DynamoDB, Amazon RDS |
| Administrar permisos | AWS IAM |
| Construir redes | Amazon VPC |
| Observar aplicaciones | Amazon CloudWatch |
| Exponer APIs | Amazon API Gateway |
| Distribuir contenido | Amazon CloudFront |
Con este mapa inicial ya hay muchísimo para aprender. No hace falta empezar con arquitecturas multi-región, Kubernetes y veinte microservicios.
Primero entendé una pieza. Después conectá dos. Más adelante tres.
Ahí empieza a aparecer el criterio.
Hay mucho contenido gratuito para empezar
Otra barrera habitual es pensar que aprender AWS necesariamente implica gastar dinero desde el primer día.
Hoy hay varias alternativas para estudiar y practicar antes de meterte de lleno con una cuenta propia.
AWS Skill Builder reúne más de mil recursos gratuitos de formación sobre cloud e inteligencia artificial. Lo interesante es que ya no todo pasa por consumir cursos: también hay experiencias prácticas, juegos, laboratorios y entornos temporales para experimentar.
Y eso es importante porque mirar un video sobre EC2 no es lo mismo que lanzar una instancia, tocar su configuración y entender qué pasa cuando algo no funciona.
Aprender cloud necesita teoría, sí, pero también práctica.
Empezaría por AWS Cloud Practitioner Essentials
Si nunca trabajaste con AWS, un buen primer paso es AWS Cloud Practitioner Essentials.
No lo pensaría solamente como preparación para una certificación. Lo usaría para construir tu primer mapa mental de la nube.
Cuando aparezca EC2, pensá en cómputo. Cuando veas S3, relacioná el servicio con almacenamiento de objetos. Cuando aparezca IAM, hacete una pregunta sencilla: quién puede hacer qué sobre qué recurso. Y cuando llegue VPC, empezá a pensar en redes.
La idea no es memorizar definiciones, sino entender qué problema resuelve cada servicio y cómo encaja dentro de una arquitectura.
Recurso: AWS Cloud Practitioner Essentials.
Después: AWS Cloud Quest
Una vez que tenés los conceptos básicos, podés empezar a trabajar con escenarios.
AWS Cloud Quest es una experiencia gamificada donde avanzás resolviendo desafíos relacionados con servicios de AWS. La versión actual incluye más práctica hands-on, interacciones impulsadas por IA y caminos hacia badges oficiales.
Lo interesante de Cloud Quest es que cambia la forma de pensar.
Dejás de preguntarte solamente “qué es S3” y empezás a preguntarte “cuándo tendría sentido usar S3”.
Parece una diferencia pequeña, pero no lo es.
Ahí comienza a aparecer criterio.
Recurso: AWS Cloud Quest: Cloud Practitioner.
Builder Labs: pasar de la teoría a las manos
Cuando ya entendés los conceptos y empezás a reconocer servicios, llega el momento de practicar.
El plan Builder Labs: Introduction to AWS Cloud reúne laboratorios introductorios sobre VPC, EC2, Lambda, DynamoDB, API Gateway, S3, IAM, KMS, CloudFront y auditoría.
No hace falta detenerse demasiado en cada uno.
Lo importante es que esos laboratorios te obligan a crear, modificar y entender recursos reales.
En algún momento dejás de estudiar servicios por separado y empezás a conectarlos:
Cliente
↓
Amazon API Gateway
↓
AWS Lambda
↓
Amazon DynamoDB
Ese momento es clave.
Porque AWS empieza a dejar de verse como una colección de servicios y empieza a verse como una arquitectura.
Recurso: Builder Labs: Introduction to AWS Cloud.
AWS Builder Center Sandbox: practicar sin una cuenta propia
Otro recurso muy interesante apareció en 2026.
AWS Builder Center comenzó a ofrecer sandboxes temporales para workshops compatibles. Estos entornos no requieren una cuenta AWS personal ni tarjeta de crédito. Cada sandbox puede utilizarse durante hasta ocho horas y luego los recursos se eliminan automáticamente.
Para alguien que está empezando, esto elimina bastante fricción.
No necesitás preocuparte por dejar una instancia corriendo o por configurar una cuenta antes de poder hacer una práctica.
Podés concentrarte en el workshop, desplegar recursos, probar cosas y equivocarte.
Para mí, este tipo de entornos tiene muchísimo valor porque ayuda a sacar el miedo inicial de “no quiero tocar porque capaz me cobran”.
Recurso: AWS Builder Center Sandbox.
¿Querés el verdadero fuego? AWS Microcredentials
Hasta acá ya aprendiste conceptos, hiciste ejercicios y trabajaste con laboratorios guiados.
Pero en algún momento aparece una pregunta más interesante:
¿Podés resolver un problema sin que alguien te diga exactamente qué hacer?
Ahí entran las AWS Microcredentials.
Desde 2026, AWS ofrece estas microcredenciales de forma gratuita. Están pensadas para validar habilidades prácticas en escenarios reales, donde tenés que diagnosticar problemas, configurar servicios e implementar soluciones.
Y esto me parece especialmente valioso porque marca una diferencia clara entre aprender y demostrar.
Una cosa es saber explicar qué hace un servicio.
Otra es recibir un entorno, entender el problema y resolverlo.
Podemos pensar el recorrido así:
Cloud Practitioner Essentials te ayuda a entender.
Cloud Quest te obliga a decidir.
Builder Labs te hace practicar.
Builder Center Sandbox te deja experimentar.
Microcredentials te piden demostrar.
Ese es, para mí, el verdadero fuego.
Recurso: AWS Microcredentials.
En algún momento hay que salir del tutorial
Los laboratorios son excelentes para empezar, pero también tienen un límite.
Siempre hay alguien diciéndote cuál es el próximo paso.
Por eso, después de hacer algunos labs, intentaría construir algo propio.
No tiene que ser complejo.
Por ejemplo, una API sencilla:
Usuario
↓
Amazon API Gateway
↓
AWS Lambda
↓
Amazon DynamoDB
Puede ser una aplicación para registrar tareas, libros, gastos o cualquier cosa que te interese.
Lo importante es que ahora las decisiones son tuyas.
Vos elegís cómo diseñar la tabla, qué permisos necesita la función, cómo exponer el endpoint y dónde mirar cuando algo falla.
Ese tipo de práctica se parece mucho más al trabajo real.
En roxs.dev también podés seguir practicando
Todo esto conecta con la idea detrás de roxs.dev.
Ahí fui reuniendo contenido, proyectos y laboratorios sobre AWS, DevOps, contenedores, Kubernetes, Terraform y otros temas. También están los Labs OnFire, pensados justamente para aprender haciendo.
La idea es simple: no quedarse solamente con la teoría.
Entrás, probás una tecnología, algo falla, lo investigás y seguís.
Ese ciclo se repite todo el tiempo en tecnología.
Recurso: roxs.dev.
¿Y la certificación?
La certificación AWS Certified Cloud Practitioner puede ser un buen objetivo, sobre todo porque ayuda a ordenar conceptos y obliga a recorrer servicios que quizás todavía no conocías.
Pero no la tomaría como el único objetivo.
Si estás estudiando S3, creá un bucket. Si estás viendo IAM, escribí una policy. Si estás aprendiendo Lambda, ejecutá una función. Si estás estudiando CloudWatch, generá un error y revisá los logs.
La teoría se recuerda mucho mejor cuando está asociada a una experiencia concreta.
Para mí, el ciclo de aprendizaje se parece más a esto:
aprender → construir → equivocarse → investigar → corregir → repetir.
La certificación puede acompañar ese camino.
No reemplazarlo.
Extra
AWS Certified Cloud Practitioner - Guía de Estudio Completa by Roxs
Recurso: Guía de Estudio Completa by Roxs
Documentá lo que vas haciendo
También recomiendo empezar a documentar desde el principio.
No hace falta escribir artículos enormes.
Un repositorio simple puede servir:
aws-learning/
├── cloud-practitioner/
├── cloud-quest/
├── vpc/
├── ec2/
├── lambda/
├── dynamodb/
├── api-gateway/
└── first-project/
En cada ejercicio podés anotar qué querías aprender, qué construiste, qué salió mal, cómo lo solucionaste y qué aprendiste.
Con el tiempo, ese repositorio deja de ser una colección de prácticas.
Se convierte en evidencia de tu aprendizaje.
Y también puede convertirse en parte de tu portfolio.
La IA ayuda, pero los intentos siguen siendo tuyos
Hoy tenemos una ventaja enorme: podemos aprender acompañados por ChatGPT, Claude, Kiro y otros asistentes.
Usalos.
Mostrales errores, pediles explicaciones, compará tus hipótesis y hacé preguntas.
Pero intentá no delegar todo.
No es lo mismo preguntar “¿por qué esta policy me devuelve AccessDenied?” que pedir que te construyan toda la solución.
La IA puede acelerar muchísimo el aprendizaje, pero hay una parte que sigue siendo tuya: hacer el intento.
Si la IA hace los 10.000 intentos por vos, la experiencia también se la queda ella.
Una ruta simple para empezar
Si tuviera que resumir todo en una ruta, sería esta:
1. Entender: AWS Cloud Practitioner Essentials
2. Decidir: AWS Cloud Quest
3. Practicar: Builder Labs
4. Experimentar: AWS Builder Center Sandbox
5. Construir: un proyecto propio
6. Demostrar: AWS Microcredentials
7. Documentar y compartir
8. Volver a construir
No hace falta hacer todo en una semana.
Ni en un mes.
El valor está en avanzar de una etapa a la siguiente y volver a repetir el ciclo con problemas cada vez un poco más complejos.
Mostrame tus intentos
Aprender AWS no consiste en memorizar cientos de servicios.
Consiste en desarrollar criterio.
Y el criterio aparece después de haber tomado decisiones, haber cometido errores, haber investigado y haber vuelto a probar.
Tu primera arquitectura puede ser sencilla. Tu primera Lambda puede fallar. Tu primera policy de IAM puede terminar en AccessDenied.
Eso también cuenta.
Hoy tenemos Cloud Practitioner Essentials, Cloud Quest, Builder Labs, sandboxes, comunidades, IA y microcredenciales gratuitas.
Tenemos muchas formas de empezar.
Lo único que nadie puede hacer por vos es acumular experiencia.
Esa aparece cuando intentás.
Quizás no necesites realmente 10.000 intentos.
Pero sí necesitás el primero.
Build with fire. Deploy with power. 🔥
Este artículo toma como inspiración la reflexión “Muéstrame tus 10.000 intentos”, de Isra García, llevada al contexto del aprendizaje de AWS, cloud y tecnología.
