Desplegar tu app rápido sin montar EC2, VPC ni IAM: guía PaaS

Respuesta corta#

Para un proyecto pequeño o mediano normalmente no necesitas levantar instancias EC2, diseñar una VPC ni pelear con políticas de IAM. Un PaaS (Platform as a Service) hace ese trabajo por ti: conectas tu repositorio, haces git push y la plataforma compila, despliega, asigna un dominio con HTTPS y opera la capa de infraestructura.

Montar tu propia infraestructura en AWS vale la pena cuando tienes requisitos de cumplimiento, de red o de escala que un PaaS no cubre. Para la mayoría de las startups y equipos pequeños, empezar en un PaaS es más rápido y consume muchas menos horas de ingeniería.

Tu backend ya funciona en localhost, el código está listo, y aparece la pregunta que frena a equipos enteros: ¿dónde despliego esto sin montar un EC2, una VPC, un balanceador, reglas de IAM y media docena de servicios? Es de las dudas más repetidas entre desarrolladores, porque el despliegue termina siendo más difícil que escribir la aplicación. La razón es que las nubes de propósito general como AWS, Google Cloud o Azure son cajas de herramientas, no soluciones terminadas: te dan cientos de servicios y esperan que tú seas a la vez arquitecto, ingeniero de redes y responsable de seguridad.

Documentación: AWS · Documentación de Amazon EC2 ↗ · AWS · Qué es Amazon VPC ↗ · AWS · Buenas prácticas de seguridad en IAM ↗

Qué implica desplegar en AWS «a mano»#

Para publicar una sola aplicación en una instancia EC2 desde cero, el camino mínimo se ve así:

• Crear y configurar una VPC: subredes públicas y privadas, tablas de rutas e internet gateway.
• Lanzar una instancia EC2 y elegir tipo, AMI y almacenamiento.
• Configurar security groups: qué puertos abrir y a quién.
• Definir roles y políticas de IAM con privilegio mínimo.
• Instalar el runtime, las dependencias y un gestor de procesos.
• Montar un balanceador (ALB) y certificados TLS.
• Configurar un pipeline de CI/CD para no desplegar a mano cada vez.
• Resolver monitoreo, logs, backups, parches del sistema operativo y rotación de credenciales.

Cada punto es razonable por separado, pero en conjunto es trabajo de plataforma antes de que tu primer usuario vea la app. Además, en el modelo de responsabilidad compartida de AWS, cuando usas EC2 el sistema operativo invitado, sus parches, la configuración de red y los permisos son responsabilidad tuya. Para un equipo que necesita validar una idea esta semana, eso es tiempo que no se invierte en producto.

Documentación: AWS · Qué es Amazon VPC ↗ · AWS · Buenas prácticas de seguridad en IAM ↗ · AWS · Modelo de responsabilidad compartida ↗ · AWS · Documentación de Amazon EC2 ↗

Qué es un PaaS y por qué resuelve esto#

Un PaaS abstrae esa capa de infraestructura. El flujo típico se reduce a un git push: la plataforma detecta el lenguaje (Node, Python, Go, etc.), construye una imagen o artefacto ejecutable, lo despliega en su capa de cómputo gestionada y te entrega una URL con HTTPS listo.

Muchas plataformas detectan el lenguaje con buildpacks, un mecanismo popularizado por Heroku y estandarizado hoy en el proyecto Cloud Native Buildpacks, que convierte el código fuente en una imagen OCI sin que escribas un Dockerfile. Otras aceptan también un Dockerfile cuando necesitas más control.

Lo que desaparece de tu lista es la VPC, el IAM de infraestructura, los servidores por parchar y la renovación manual de certificados. Lo que sigue siendo tuyo: el código, sus dependencias, los secretos y la configuración de la app. Un PaaS no te exime de seguridad a nivel de aplicación; te quita la parte que no diferencia a tu producto.

Para que tu app funcione bien en cualquier PaaS, y para poder salir de él si algún día lo necesitas, aplica dos principios de The Twelve-Factor App: la configuración vive en variables de entorno, nunca en el código, y el proceso escucha en el puerto que le indica la plataforma.

FROM node:22-slim
WORKDIR /app
ENV NODE_ENV=production

COPY package*.json ./
RUN npm ci --omit=dev
COPY . .

# La plataforma inyecta PORT; la app debe leerlo con process.env.PORT
ENV PORT=8080
EXPOSE 8080
USER node
CMD ["node", "server.js"]

Documentación: Heroku Dev Center · How Heroku Works ↗ · Cloud Native Buildpacks · Documentación ↗ · The Twelve-Factor App (español) ↗ · The Twelve-Factor App · Configuración ↗ · Docker · Referencia de Dockerfile ↗

Comparativa: infraestructura propia, PaaS y opciones gestionadas#

La tabla resume las diferencias prácticas entre montar la infraestructura a mano, usar un PaaS y quedarte en servicios gestionados de tu nube. Son tendencias generales: el resultado depende del proveedor concreto, de tu aplicación y de lo que tu equipo ya sepa operar.

Antes de elegir una plataforma concreta, revisa cómo cobra, en qué regiones corre, qué soporte ofrece y si puedes llevarte la aplicación a otro lugar sin reescribirla. Si estás evaluando plataformas gestionadas para equipos sin DevOps dedicado, en Codifly tienes la comparativa de C4C7OPS y Qovery con sus fuentes.

Si prefieres quedarte dentro de AWS, también hay opciones gestionadas: Elastic Beanstalk despliega aplicaciones sin que administres la infraestructura subyacente, y Amazon ECS con Fargate ejecuta contenedores sin servidores que gestionar. Ojo con AWS App Runner: AWS lo cerró a nuevos clientes y recomienda Amazon ECS Express Mode como camino de migración.

Documentación: AWS · Qué es Elastic Beanstalk ↗ · AWS · Amazon ECS en AWS Fargate ↗ · AWS · Cambio de disponibilidad de App Runner ↗

Cuándo sí conviene montar tu propia infraestructura#

Un PaaS no siempre es la respuesta. Considera infraestructura gestionada por ti cuando:

• Tienes requisitos de cumplimiento estrictos, por ejemplo datos que deben residir en una región o cuenta bajo tu control total, o auditorías directas sobre la red (PCI DSS, HIPAA, soberanía de datos).
• Necesitas una configuración de red específica: peering, VPN complejas, subredes aisladas o integración con servicios internos de una VPC corporativa.
• Operas a una escala en la que el costo por unidad de cómputo del PaaS supera claramente el costo de operar tú mismo, incluidas las horas de ingeniería.
• Tu equipo ya tiene ingeniería de plataforma dedicada y la infraestructura es parte del núcleo del negocio.

La elección no es «PaaS contra AWS», es abstracción contra control. Mientras no tengas una de esas necesidades, la infraestructura gestionada por un PaaS es una configuración por defecto razonable. Cuando aparezcan, ese es el punto de inflexión para pasar a EC2 con VPC e IAM, o a orquestación con ECS o EKS.

Documentación: AWS · Qué es Amazon VPC ↗ · AWS · Qué es Amazon ECS ↗

De git push a producción, paso a paso#

• Conecta tu repositorio: vincula tu repositorio de GitHub al PaaS y define el comando de build y el puerto de escucha como variable de entorno.
• Haz git push: la plataforma detecta el cambio, compila, crea el proceso o contenedor y lo expone en un dominio HTTPS automático.
• Configura variables de entorno: añade credenciales y configuración de producción sin tocar servidores ni archivos de sistema.
• Prepárate para migrar si hace falta: mantén la app contenerizada con un Dockerfile estándar y evita dependencias propietarias del PaaS, para poder moverla a ECS o EKS cuando lo necesites.

Ese último paso es el seguro barato: si la app es portable, empezar en un PaaS no te encierra. Siempre puedes migrar después; empezar al revés, montando toda la infraestructura antes de tener usuarios, cuesta semanas que un equipo pequeño no tiene.

Documentación: The Twelve-Factor App (español) ↗ · Docker · Referencia de Dockerfile ↗ · AWS · Qué es Amazon ECS ↗

Decisión final: PaaS o infraestructura propia#

La clave está en evaluar qué recurso es más escaso en tu equipo: horas de ingeniería o control sobre la infraestructura. Si tu prioridad es validar producto, llegar a usuarios y moverte rápido, un PaaS reduce la fricción del despliegue a un git push. Si operas bajo requisitos regulatorios estrictos, necesitas control granular de red o proyectas una escala donde el costo por instancia sea determinante, invertir en EC2, VPC e IAM tiene sentido.

Regla práctica: si tu equipo no tiene a nadie dedicado a infraestructura y tu app no maneja datos con requisitos normativos de aislamiento, despliega en un PaaS. Podrás estar en producción con HTTPS, dominio y escalado básico poco después de terminar el código. Si necesitas controlar subredes, políticas de acceso a nivel de red o integrarte con una VPC corporativa, monta infraestructura propia.

Lo importante es que la decisión sea consciente y no por inercia. Empieza con la opción que te permite entregar valor más rápido y migra solo cuando tengas evidencia clara de que la limitación del PaaS te está frenando.

Documentación: AWS · Modelo de responsabilidad compartida ↗