Primer proyecto AWS: URL shortener serverless en 2026

Maurice Murphy, desarrollador full-stack con casi una década de experiencia en React, React Native y Node, publicó el 26 de mayo de 2026 su primer proyecto AWS de producción como parte de su transición a Cloud Engineering: un URL shortener serverless construido con Lambda, API Gateway, DynamoDB, S3 y CloudFront, con el objetivo de conseguir un rol cloud para el tercer trimestre de 2026.

De desarrollador full-stack a Cloud Engineer: quién es Maurice Murphy

Un URL shortener serverless es un sistema que recibe una URL larga, genera un código corto único, lo almacena en base de datos, y redirige al usuario al destino original cuando usa ese código. La implementación sin servidores significa que no hay infraestructura que aprovisionar ni mantener: el código se ejecuta bajo demanda y el costo escala con el uso real.

Maurice Murphy es un desarrollador full-stack autodidacta con casi diez años construyendo aplicaciones con React, React Native y Node.js. Según publicó en Dev.to el 26 de mayo de 2026, su experiencia previa con AWS se limitaba a S3. Este proyecto marca su entrada real al ecosistema de cloud.

La transición no es rara. Muchos developers full-stack llegan al cloud después de años trabajando con infraestructura sin ser “dueños” de ella: usaban Vercel, Netlify o algún servicio managed sin necesidad de entender qué había abajo. Ponele que armaste una app con Next.js y la desplegaste en tres clicks: funciona, pero no aprendiste nada de networking, IAM, ni patrones de arquitectura. Maurice decidió cambiar eso.

Por qué un URL shortener como primer proyecto AWS para developers

La elección no es casualidad. Un URL shortener tiene la complejidad justa para ser instructivo sin volverse un pozo sin fondo.

Tiene operaciones CRUD reales (crear un código corto, leerlo para redirigir), necesita persistencia de datos, requiere exponer endpoints HTTP públicos, y se beneficia de distribución de contenido. Eso obliga a usar varios servicios en conjunto, que es exactamente la habilidad que se evalúa en el SAA-C03. Te puede servir nuestra cobertura de configurar pipelines de CI/CD en producción.

La meta de Maurice, como él mismo explica, no era “reinventar la rueda” sino “entender la infraestructura intencionalmente”. Esa distinción importa: cualquier developer con experiencia termina construyendo sistemas complejos por acumulación de features. Lo difícil es diseñar algo complejo desde el principio con criterio, sabiendo por qué cada pieza está ahí.

Los cinco servicios AWS: qué hace cada uno y por qué

Maurice usó exactamente cinco servicios. No más. Eso solo ya dice algo sobre la mentalidad de alguien que estudia SAA-C03 con foco en cost optimization.

Servicio	Rol en el proyecto	Por qué este y no otro
AWS Lambda	Lógica de negocio: genera el código corto, almacena y recupera URLs	Serverless, sin costo en idle, escalado automático
API Gateway	Expone los endpoints HTTP (POST para crear, GET para redirigir)	Integración nativa con Lambda, manejo de rutas, CORS
DynamoDB	Almacena el mapping código corto → URL original	NoSQL managed, latencia baja, sin servidor que administrar
S3	Hosting del frontend estático (HTML/CSS/JS)	Hosting estático prácticamente gratuito para tráfico bajo
CloudFront	CDN que distribuye el frontend con baja latencia	HTTPS gratis, caché en edge, integración con S3

La combinación Lambda + API Gateway + DynamoDB es el stack serverless más común de AWS. Si estudiás para el SAA-C03, esta trinidad va a aparecer en más de una pregunta de arquitectura.

Cómo fluye una URL acortada: arquitectura paso a paso

El flujo end-to-end es más limpio de lo que parece.

El usuario pega su URL en el frontend servido desde S3 via CloudFront, hace submit, y ese request viaja a API Gateway, que lo rutea a una función Lambda. La Lambda genera un código corto único (un hash o un ID alfanumérico), escribe el par código-URL en DynamoDB, y devuelve el código al usuario. Cuando el usuario quiere redirigir, hace un GET con ese código: API Gateway llama a otra Lambda (o la misma, dependiendo del diseño), que consulta DynamoDB, recupera la URL original, y devuelve un 301 o 302.

CloudFront está en el frente, distribuyendo el contenido estático desde ubicaciones de edge. Para el shortener en sí (los redirects), el tráfico igual pasa por API Gateway directamente, sin pasar por caché de CloudFront (porque cada redirect es único y no tiene sentido cachearlo). Sobre eso hablamos en elegir la herramienta de automatización correcta.

¿Dónde está lo interesante acá? En los permisos. Lambda necesita permisos IAM para escribir y leer en DynamoDB. API Gateway necesita permisos para invocar Lambda. S3 necesita una política de bucket que permita acceso público de lectura (o una OAC con CloudFront). Cada una de esas configuraciones es una fuente potencial de errores.

Lo que más enseña: permisos IAM, deploy y debuggear en cloud

Cualquiera que haya configurado IAM por primera vez sabe que los errores de permisos tienen un ciclo humillante: cambiás algo, redeployás, probás, falla de nuevo con un error críptico, leés los logs, modificás el policy, redeployás. Veinte minutos para algo que en local no habría tardado dos.

El deploy a producción en cloud tiene una curva distinta al deploy local. En local, “funciona en mi máquina” es el estándar. En Lambda, el entorno de ejecución es distinto: las variables de entorno van aparte, el tamaño del deployment package tiene límites, los timeouts por default son conservadores (3 segundos en Lambda, suficiente para la mayoría de los casos pero que puede sorprender), y los cold starts existen aunque sean menores en funciones livianas.

Para un proyecto como este, lo más común que sale mal (y que mauricio probablemente enfrentó) es el orden de verificación: antes de debuggear el código de Lambda, verificar que DynamoDB tiene la tabla creada con el partition key correcto. Antes de culpar a API Gateway, verificar que el integration type está en “Lambda Proxy” y no en otro modo. Antes de culpar a CloudFront, verificar que el origin está apuntando al bucket correcto y que la OAC está bien configurada.

El patrón es siempre el mismo: el problema raramente está donde pensás que está.

Cómo este proyecto cubre el SAA-C03 y prepara para entrevistas cloud

El exam guide del SAA-C03 tiene cuatro dominios: Design Secure Architectures (30%), Design Resilient Architectures (26%), Design High-Performing Architectures (24%), y Design Cost-Optimized Architectures (20%).

Este proyecto toca los cuatro.

• Seguridad: IAM roles para Lambda, políticas de acceso a DynamoDB y S3, HTTPS via CloudFront.
• Resiliencia: DynamoDB es multi-AZ por default. Lambda escala automáticamente. No hay single point of failure.
• Performance: CloudFront reduce latencia para usuarios geográficamente distribuidos. DynamoDB tiene latencia de milisegundos en lecturas.
• Costo: Sin servidores idle. Lambda cobra por invocación y duración. DynamoDB cobra por lectura/escritura. Para un proyecto portfolio con tráfico bajo, el costo mensual es prácticamente cero dentro del free tier.

En una entrevista para un rol cloud entry-level, poder describir este proyecto explicando las decisiones de arquitectura (por qué DynamoDB y no RDS, por qué Lambda y no EC2, por qué CloudFront y no solo S3 directamente) es mucho más valioso que listar certificaciones. El SAA-C03 da el marco teórico; el proyecto da el contexto para hablar con criterio. Más contexto en optimizar tu presencia online internacionalmente.

Qué sigue después del primer proyecto: ruta hacia el primer rol cloud

Maurice apunta a un rol de Cloud Engineering para Q3 2026. Eso le da pocos meses para completar el SAA-C03, agregar proyectos al portfolio, y posicionarse en LinkedIn y GitHub.

El siguiente paso natural después de un URL shortener serverless es agregar complejidad controlada: un pipeline CI/CD con GitHub Actions o AWS CodePipeline, IaC con Terraform o AWS CDK (que reemplaza la consola manual y es lo que se usa en equipos reales), y quizás un proyecto multi-región o con autenticación (Cognito + API Gateway). Si querés construir en donweb.com o en cualquier host externo que consuma tus APIs Lambda, el mismo stack aplica.

La diferencia entre Cloud Engineer, Solutions Architect y DevOps Engineer no siempre es clara, pero a grosso modo: el Cloud Engineer construye y opera la infraestructura, el Solutions Architect diseña y recomienda arquitecturas para clientes, y el DevOps Engineer se enfoca en CI/CD, automatización y cultura de deployment. Para alguien con background de full-stack, el Cloud Engineer o el DevOps Engineer es el camino más natural.

Errores comunes al hacer el primer proyecto AWS

Usar el usuario root para todo

Es el error de seguridad más básico y el más frecuente. El usuario root de AWS tiene acceso a todo, incluyendo cambiar los datos de facturación y cerrar la cuenta. Para proyectos y desarrollo, creá un usuario IAM con permisos mínimos necesarios y activá MFA en el root inmediatamente.

No configurar billing alerts desde el día uno

AWS cobra por uso real. Si dejás algo mal configurado (una NAT Gateway olvidada, un endpoint de SageMaker sin detener, un Elastic IP sin asociar), la factura llega a fin de mes y te sorprende. Configurá un billing alert en CloudWatch para que te avise si el costo supera, por ejemplo, USD 5. Tarda cinco minutos y puede salvarte.

Hacer todo por consola y no documentar

Hacer click en la consola está bien para aprender, pero si necesitás recrear el entorno o explicarle a alguien cómo está montado, no tenés nada. Aunque sea para un proyecto portfolio, documentá los pasos o mejor aún, migrá a IaC (CloudFormation o Terraform) cuanto antes. En equipos reales, nadie trabaja sin IaC. Complementá con ejecutar agentes sin depender de APIs externas.

Ignorar los logs de CloudWatch

Cada invocación de Lambda escribe en CloudWatch Logs. Cuando algo falla y no sabés por qué, los logs son lo primero que hay que revisar. Suena obvio, pero muchos developers que vienen del frontend no tienen el hábito de ir a los logs del servidor porque nunca administraron uno.

Preguntas Frecuentes

¿Cómo hago mi primer proyecto AWS como desarrollador full-stack?

El camino más efectivo es elegir un proyecto pequeño que use varios servicios conectados entre sí: un URL shortener serverless (como hizo Maurice Murphy) o una API REST con Lambda, API Gateway y DynamoDB son buenas opciones. Arrancá con la consola de AWS para entender cada servicio, luego migrá la configuración a IaC con Terraform o AWS CDK.

¿Cuánto cuesta crear un proyecto serverless en AWS?

Para un proyecto portfolio con tráfico bajo, prácticamente nada. AWS tiene un free tier que incluye 1 millón de invocaciones Lambda por mes, 25 GB de almacenamiento DynamoDB y 5 GB de S3. CloudFront tiene 1 TB de transferencia de datos gratis por mes en el primer año. Si superás esos límites, los costos arrancan en fracciones de dólar por millón de requests.

¿Es posible cambiar de desarrollador full-stack a cloud engineer?

Sí, y la transición es más natural de lo que parece porque muchos conceptos se superponen: APIs, bases de datos, seguridad básica. Lo que hay que agregar es el modelo mental de infraestructura: redes, IAM, patrones de alta disponibilidad y cost optimization. Construir proyectos como el de Maurice Murphy y obtener la certificación SAA-C03 es el camino estándar para hacer esa transición en 6 a 12 meses.

¿Qué servicios AWS debo aprender primero?

Para el SAA-C03 y para roles cloud entry-level: EC2, S3, IAM, VPC, Lambda, RDS, DynamoDB, CloudFront, y API Gateway. De esos, el stack serverless (Lambda + API Gateway + DynamoDB) es el más demandado en roles modernos y el más fácil de practicar sin costo. IAM es transversal a todo y es donde más errores ocurren.

¿Cuál es un buen proyecto práctico para preparar el SAA-C03?

Un URL shortener serverless como el de Maurice Murphy cubre los cuatro dominios del SAA-C03: seguridad (IAM), resiliencia (DynamoDB multi-AZ, Lambda escalado automático), performance (CloudFront CDN) y optimización de costos (arquitectura serverless sin recursos idle). Hay guías paso a paso en Dev.to que replican exactamente este stack para practicar.

Conclusión

Lo que publicó Maurice Murphy el 26 de mayo de 2026 no es solo un proyecto de portfolio: es un mapa de cómo alguien con experiencia real en desarrollo puede hacer la transición al cloud de forma metódica. Eligió un proyecto con complejidad controlada, usó solo los servicios necesarios, y lo alineó con el examen que lo va a certificar. Eso es criterio de arquitectura, no suerte.

Si estás pensando en una transición similar, el punto de partida es el mismo: un proyecto pequeño, deliberadamente diseñado, que te obligue a entender permisos, networking y costos. El primer proyecto AWS para developers no tiene que ser ambicioso. Tiene que ser honesto sobre lo que ya sabés y claro sobre lo que todavía no.

Fuentes

• Maurice Murphy en Dev.to – I Built My First Production AWS Project as a Career Changer (mayo 2026)
• AWS Builders en Dev.to – Mini Project: Serverless URL Shortener con Lambda, API Gateway y DynamoDB
• AWS – Guía oficial del examen SAA-C03 (Solutions Architect Associate)
• 295devops – Aprobé el exam lab AWS Serverless: todo lo que rompí en el camino