# Cómo desplegar una aplicación web en AWS desde cero

**Categoría:** DevOps y cloud · **Nivel:** Intermedio · **Lectura:** 16 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/devops-cloud/despliegue-de-una-aplicacion-web-en-aws-desde-cero/

## Respuesta rápida

Publicar una aplicación web en **AWS** (Amazon Web Services) no requiere conocer sus cientos de servicios, sino un **puñado esencial**. **Cómputo:** dónde corre tu app —**EC2** (una máquina virtual que administras tú, máximo control) o alternativas gestionadas como **Elastic Beanstalk**, **App Runner** o **ECS/Fargate** (contenedores) que se ocupan del servidor por vos—. **Base de datos:** **RDS**, base de datos gestionada (PostgreSQL, MySQL…) con copias y actualizaciones automáticas, en vez de instalarla a mano en la instancia. **Almacenamiento:** **S3** para archivos estáticos, imágenes y copias de seguridad. **DNS:** **Route 53** para apuntar tu dominio. **Red y seguridad:** una **VPC** (tu red privada) y **grupos de seguridad** (cortafuegos que definen qué puertos se abren y a quién). Y transversal a todo, **IAM** (identidades y permisos). El primer criterio es **cuánta gestión querés**: EC2 da control total pero te hace responsable de todo (parches, escalado, seguridad del sistema); los servicios gestionados quitan trabajo a cambio de menos control. Dos cosas que evitan disgustos: la **seguridad** —nunca abrir puertos al mundo sin necesidad, no usar la cuenta raíz para el día a día, principio de mínimo privilegio en IAM— y el **coste** —entender la capa gratuita, apagar lo que no se usa y poner **alertas de facturación** desde el minuto uno—. Para no repetir el montaje a mano cada vez, el paso natural es describir todo esto con [Terraform](../infrastructure-as-code-con-terraform/index.md).

## Los servicios esenciales

AWS abruma por su tamaño, pero una aplicación web típica se sostiene sobre **seis piezas**. Conocerlas es el mapa para no perderse en la consola:

| Necesidad | Servicio | Qué hace |
|---|---|---|
| Cómputo | EC2 (o Beanstalk / App Runner / Fargate) | Ejecuta tu aplicación |
| Base de datos | RDS | Base de datos gestionada, con copias automáticas |
| Archivos y estáticos | S3 | Almacena imágenes, backups y contenido estático |
| Dominio | Route 53 | DNS: apunta tu dominio a la aplicación |
| Red | VPC + grupos de seguridad | Tu red privada y el cortafuegos de cada recurso |
| Permisos | IAM | Quién puede hacer qué; identidades y roles |

> **Empezá por lo mínimo, sumá cuando duela**
>
> No hace falta usar los seis desde el primer día. Una app sencilla puede empezar con una **instancia EC2** que corre la aplicación y su base de datos, un **grupo de seguridad** que abre solo los puertos 80 y 443 (y 22 restringido a tu IP) y **Route 53** para el dominio. A medida que el proyecto crece, se *separan* las piezas: la base de datos a **RDS** (para que las copias y actualizaciones dejen de ser tu problema), los estáticos a **S3**, y el cómputo a un servicio gestionado si el mantenimiento del servidor pesa. Sumar complejidad cuando el dolor lo justifica, no antes.

## Qué modelo de despliegue elegir

La decisión que ordena todo es **cuánto querés gestionar vos**. Es un abanico entre control total y comodidad:

| Modelo | Gestionás | Bueno para |
|---|---|---|
| EC2 (máquina propia) | Todo: sistema, parches, escalado | Máximo control; aprender; configuraciones a medida |
| Elastic Beanstalk | Poco: subís el código | Apps clásicas sin querer administrar servidores |
| ECS / Fargate | Los contenedores, no el servidor | Apps ya en Docker |
| App Runner / Lambda | Casi nada | APIs y servicios simples; escalar a cero |

> **Atención**
>
> Elegir EC2 «porque da control» y luego pasar semanas parcheando el sistema, configurando copias y peleando con el escalado es un clásico. Los servicios gestionados **no** son una versión descafeinada: quitan de tu plato trabajo que no aporta valor a tu producto (mantener un sistema operativo no te acerca a tu objetivo) a cambio de ceñirte a su forma de trabajar. La pregunta correcta no es «¿cuál da más control?», sino «¿qué trabajo *quiero* hacer yo y cuál prefiero delegar?». Para aprender cómo funciona todo por dentro, EC2 es ideal; para publicar rápido y mantener poco, un gestionado casi siempre gana.

## Seguridad y coste

Dos frentes donde los principiantes se llevan los sustos: dejar algo abierto que no debían, y recibir una factura inesperada. Ambos se previenen con hábitos simples desde el inicio.

- **No uses la cuenta raíz para el día a día.** Creá un usuario IAM con permisos y activá doble factor en la raíz; guardala.
- **Mínimo privilegio en IAM.** Cada identidad, solo los permisos que necesita; nada de «acceso total» por comodidad.
- **Grupos de seguridad restrictivos.** Abrí solo los puertos necesarios; el 22 (SSH), solo desde tu IP, nunca al mundo.
- **Base de datos sin acceso público.** RDS en subred privada; solo la app llega a ella, no internet.
- **Alertas de facturación desde el minuto uno.** Un presupuesto con aviso evita que un recurso olvidado dispare la factura.
- **Entendé la capa gratuita y sus límites.** Es generosa pero acotada; salirse de ella cuesta, a veces sin avisar claro.
- **Apagá lo que no usás.** Instancias de prueba encendidas de noche y fines de semana son dinero tirado.

> **Atención**
>
> La factura sorpresa casi siempre viene de lo mismo: recursos encendidos que nadie usa, almacenamiento que se acumula, tráfico de salida que no se previó, o un servicio caro elegido por defecto. Controlarlo no es mirar la factura a fin de mes con miedo, sino una práctica continua —medir, atribuir el gasto, optimizar— que tiene nombre propio: **FinOps**. Si el proyecto va a crecer, conviene adoptar esos hábitos temprano; se desarrollan en la guía de [FinOps y control de costos de cloud](../finops-controlar-y-reducir-costos-de-cloud/index.md).

## Errores frecuentes

- **Usar la cuenta raíz a diario.** Un riesgo enorme; crear usuarios IAM con permisos acotados.
- **Abrir puertos al mundo «para que funcione».** Especialmente SSH; restringir a tu IP y a lo imprescindible.
- **Exponer la base de datos a internet.** Debe vivir en subred privada, accesible solo desde la app.
- **No poner alertas de facturación.** La factura sorpresa es casi siempre evitable con un presupuesto con aviso.
- **Elegir EC2 por defecto sin evaluar gestionados.** A veces se asume mantenimiento que un servicio gestionado evitaría.
- **Dejar recursos de prueba encendidos.** Instancias y bases olvidadas siguen facturando; apagar o eliminar.
- **Montar todo a mano y no documentarlo.** Repetirlo o recuperarlo es un infierno; describirlo con Terraform.

## Preguntas frecuentes

**¿Qué servicios de AWS necesito para desplegar una web?**
Para desplegar una aplicación web en AWS no se necesitan los cientos de servicios que ofrece la plataforma, sino un puñado esencial que cubre las necesidades básicas de cualquier aplicación. El primero es el cómputo, es decir, el lugar donde se ejecuta la aplicación, que puede ser una máquina virtual que uno administra directamente o bien un servicio gestionado que se encarga del servidor por uno. El segundo es la base de datos, para lo cual existe un servicio de bases de datos gestionadas que ejecuta motores conocidos y se ocupa automáticamente de tareas como las copias de seguridad y las actualizaciones, evitando tener que instalar y mantener la base de datos a mano en el servidor. El tercero es el almacenamiento de archivos, mediante un servicio de almacenamiento de objetos ideal para guardar contenido estático como imágenes, documentos, archivos subidos por los usuarios o copias de seguridad, de forma duradera y escalable. El cuarto es el servicio de nombres de dominio, que permite apuntar el dominio propio hacia la aplicación gestionando los registros correspondientes. El quinto conjunto es el de red y seguridad, formado por una red privada virtual que aísla los recursos y por los grupos de seguridad, que actúan como cortafuegos definiendo qué puertos se abren y desde dónde se puede acceder a cada recurso. Y el sexto, transversal a todos los demás, es el servicio de identidades y permisos, que controla quién puede hacer qué dentro de la cuenta, permitiendo crear usuarios y roles con permisos acotados en lugar de usar credenciales todopoderosas. No es necesario emplear los seis desde el primer momento, ya que una aplicación sencilla puede comenzar con una instancia de cómputo que ejecute la aplicación y su base de datos, un grupo de seguridad que abra solo los puertos imprescindibles y el servicio de dominio, e ir incorporando el resto a medida que el proyecto crece y lo requiere, por ejemplo separando la base de datos a su servicio gestionado o llevando los archivos estáticos al almacenamiento de objetos. Conocer este puñado de servicios esenciales proporciona el mapa necesario para no perderse en la enorme oferta de AWS y desplegar con criterio.

**¿Conviene usar EC2 o un servicio gestionado?**
La elección entre usar una máquina virtual autoadministrada, como una instancia de cómputo clásica, o un servicio gestionado depende de cuánto trabajo de administración se quiere asumir y de los objetivos del proyecto, y no existe una respuesta única, sino un intercambio que conviene entender. Una instancia autoadministrada ofrece el máximo control y flexibilidad, ya que se dispone de un servidor completo sobre el que se puede instalar y configurar cualquier cosa a medida, lo que resulta ideal para aprender cómo funciona todo por dentro, para configuraciones muy específicas o para casos que requieren un control fino. La contrapartida es que uno se hace responsable de todo lo relacionado con ese servidor: aplicar las actualizaciones y parches de seguridad del sistema, configurar y mantener los servicios, ocuparse de las copias de seguridad, gestionar el escalado cuando aumenta la carga y velar por la disponibilidad, un conjunto de tareas que consume tiempo y que no aporta valor directo al producto. Los servicios gestionados, en cambio, se ocupan de buena parte de esa infraestructura por uno, en distintos grados según el servicio: algunos despliegan la aplicación a partir del código encargándose del servidor subyacente, otros ejecutan contenedores sin que haya que gestionar las máquinas, y otros permiten ejecutar funciones sin administrar servidor alguno y escalar automáticamente. A cambio de esa comodidad, se cede algo de control y hay que ceñirse a la forma de trabajar del servicio. La clave para decidir no es preguntarse cuál da más control, ya que la máquina autoadministrada siempre ganará en ese aspecto, sino qué trabajo se quiere hacer uno mismo y cuál se prefiere delegar. Si el objetivo es aprender a fondo o se necesita un control muy específico, la instancia autoadministrada es adecuada; si lo que se busca es publicar rápido y mantener poco, dedicando el esfuerzo al producto en lugar de a administrar servidores, un servicio gestionado suele ser la mejor opción. En muchos casos, además, se puede empezar de una manera y evolucionar hacia otra a medida que cambian las necesidades.

**¿Cómo evito una factura sorpresa en AWS?**
Evitar una factura inesperada en AWS es una de las mayores preocupaciones de quien empieza, y afortunadamente se logra con un conjunto de hábitos sencillos aplicados desde el primer momento. Lo más importante y prioritario es configurar alertas de facturación o un presupuesto con avisos, de modo que se reciba una notificación cuando el gasto acumulado o previsto supere un umbral definido; esto convierte una posible sorpresa de fin de mes en un aviso temprano que permite reaccionar a tiempo, y es la primera medida que conviene establecer nada más crear la cuenta. En segundo lugar, es fundamental entender la capa gratuita y sus límites, ya que AWS ofrece una capa gratuita generosa pero acotada, con límites de uso y de tiempo para muchos servicios, y salirse de esos límites, a veces sin un aviso evidente, genera cargos; conocer qué está cubierto y hasta qué punto ayuda a no llevarse sustos. En tercer lugar, hay que apagar o eliminar los recursos que no se usan, porque una causa muy frecuente de facturas elevadas son instancias de prueba encendidas de forma innecesaria durante noches y fines de semana, bases de datos olvidadas, volúmenes de almacenamiento que se acumulan o direcciones reservadas sin utilizar, todos ellos generando cargos de forma continua aunque no se estén aprovechando. En cuarto lugar, conviene prestar atención a los costes menos evidentes, como el tráfico de datos de salida hacia internet, que se factura y a veces se subestima, o el crecimiento del almacenamiento con el tiempo. En quinto lugar, es recomendable revisar periódicamente el desglose de gastos que ofrece la plataforma para identificar qué servicios consumen más y por qué, atribuyendo el gasto a cada parte del sistema. Adoptar estos hábitos desde el principio, con las alertas de facturación como red de seguridad imprescindible, transforma el control del coste en algo manejable y predecible. De hecho, en proyectos que crecen, este control deja de ser una serie de trucos puntuales y se convierte en una disciplina continua de gestión del gasto en la nube, con metodologías específicas para medir, atribuir y optimizar los costes de forma sistemática.

**¿Qué es un grupo de seguridad y por qué importa?**
Un grupo de seguridad en AWS es, en esencia, un cortafuegos virtual asociado a un recurso, como una instancia de cómputo o una base de datos, que controla qué tráfico de red se permite entrar y salir de ese recurso, definiendo reglas sobre qué puertos están abiertos y desde qué orígenes se puede acceder. Su importancia es enorme desde el punto de vista de la seguridad, porque es la primera línea de defensa que determina quién puede alcanzar cada recurso y a través de qué puertos, y una mala configuración puede dejar servicios peligrosamente expuestos a todo internet. El principio que debe guiar su configuración es el de abrir únicamente lo estrictamente necesario. Por ejemplo, para una aplicación web es razonable permitir el tráfico entrante en los puertos correspondientes al tráfico web, tanto el estándar como el cifrado, desde cualquier origen, ya que se pretende que el público acceda a la web. Sin embargo, el puerto de administración remota mediante consola segura no debería abrirse a todo internet bajo ningún concepto, sino restringirse exclusivamente a la dirección o direcciones desde las que uno administra el servidor, ya que dejarlo abierto al mundo es una invitación a ataques automatizados de fuerza bruta que constantemente sondean internet en busca de este tipo de accesos. Un error muy común y peligroso de los principiantes es abrir puertos de par en par para conseguir rápidamente que algo funcione, dejando expuestos servicios internos, bases de datos o paneles de administración que jamás deberían ser accesibles desde el exterior. Otro principio clave relacionado es que recursos sensibles como las bases de datos no deben tener acceso público, sino ubicarse en una parte privada de la red y configurarse de modo que solo la aplicación pueda comunicarse con ellos, y no internet en general. En resumen, los grupos de seguridad importan porque son el mecanismo con el que se decide qué está expuesto y qué no, y aplicar con ellos el principio de mínima exposición, abriendo solo los puertos imprescindibles y restringiendo los accesos administrativos a orígenes de confianza, es una de las medidas de seguridad más básicas e importantes al desplegar en AWS.

**¿Puedo desplegar en AWS gratis para aprender?**
Sí, se puede empezar a desplegar en AWS de forma prácticamente gratuita para aprender, gracias a la capa gratuita que ofrece la plataforma, aunque conviene entender bien sus características y límites para no incurrir en cargos inesperados. La capa gratuita de AWS incluye distintos tipos de ofertas: algunos servicios ofrecen una cantidad de uso gratuita durante un periodo inicial tras crear la cuenta, otros ofrecen un nivel de uso gratuito de forma permanente hasta cierto límite mensual, y otros permiten probar el servicio de forma gratuita en determinadas condiciones. Esto permite, por ejemplo, mantener una instancia de cómputo pequeña, cierta capacidad de base de datos gestionada, una cantidad de almacenamiento de objetos y otros recursos en marcha sin coste, siempre dentro de los límites establecidos, lo cual es más que suficiente para montar y practicar el despliegue de una aplicación web sencilla y aprender cómo funcionan los servicios esenciales. Sin embargo, es fundamental tener presente que la capa gratuita tiene límites concretos de uso y de tiempo, y que superarlos, a veces sin un aviso muy visible, genera cargos; por ejemplo, usar un tipo de instancia mayor que el incluido, exceder las horas o la cantidad de datos previstas, o mantener recursos que no entran en la oferta gratuita. Por ello, para aprender de forma segura y sin sustos, la recomendación es combinar el uso de la capa gratuita con las buenas prácticas de control de coste: configurar desde el primer momento alertas de facturación o un presupuesto con avisos que notifiquen cualquier gasto, conocer qué recursos y qué cantidades están cubiertos por la capa gratuita, apagar o eliminar los recursos en cuanto se termine de practicar con ellos para que no sigan consumiendo, y revisar periódicamente el estado de la facturación. Con estas precauciones, AWS es una excelente plataforma para aprender a desplegar aplicaciones sin apenas coste, permitiendo experimentar con servicios reales de nivel profesional, siempre que se sea consciente de los límites de la capa gratuita y se mantenga la vigilancia sobre el gasto mediante las alertas correspondientes.

**¿Por qué crear la infraestructura con código en vez de a mano?**
Crear la infraestructura de AWS con código, en lugar de configurarla manualmente haciendo clics en la consola web, es una práctica muy recomendable conocida como infraestructura como código, y aporta beneficios importantes que justifican el esfuerzo de aprenderla, especialmente a medida que un proyecto crece o se repite. Cuando se monta la infraestructura a mano a través de la consola, el conocimiento de cómo está construido el sistema queda disperso y difícil de recuperar, ya que consiste en una serie de acciones puntuales que nadie recuerda con exactitud pasado un tiempo; si hay que recrear el entorno, montar uno idéntico para pruebas, o reconstruirlo tras un problema, hay que repetir laboriosamente todos los pasos confiando en la memoria, lo cual es lento y propenso a errores e inconsistencias. La infraestructura como código resuelve esto describiendo todos los recursos, como las instancias, las bases de datos, las redes, los grupos de seguridad o los permisos, en archivos de código que actúan como la fuente de verdad de cómo debe ser el sistema. Esto aporta varias ventajas. En primer lugar, la reproducibilidad, ya que a partir de esos archivos se puede crear el mismo entorno tantas veces como haga falta, garantizando que desarrollo, pruebas y producción sean coherentes. En segundo lugar, el versionado, porque al ser código se puede guardar en un sistema de control de versiones, viendo el historial de cambios, quién modificó qué y por qué, y pudiendo volver atrás si algo sale mal. En tercer lugar, la documentación implícita, dado que el propio código describe con precisión cómo está montada la infraestructura, sin depender de la memoria de nadie. En cuarto lugar, la posibilidad de revisar los cambios antes de aplicarlos y de automatizar los despliegues de infraestructura dentro de procesos controlados. Herramientas como las de infraestructura como código permiten definir la infraestructura de forma declarativa y aplicarla de manera repetible. Por todo ello, aunque para un primer aprendizaje o una prueba puntual montar algo a mano es aceptable, en cuanto la infraestructura tiene cierta entidad, debe mantenerse o se repite, describirla con código es la práctica correcta, que evita el caos de las configuraciones manuales no documentadas y hace la gestión mucho más fiable y profesional.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Dudas y pedidos generales](https://underc0de.org/foro/dudas-y-pedidos-generales/). Infraestructura y nube.
2. **Underc0de, foro.** [Sección GNU/Linux](https://underc0de.org/foro/gnu-linux/). Servidores y despliegue.

### Documentación oficial

1. **AWS.** [AWS Documentation](https://docs.aws.amazon.com/). Documentación oficial de los servicios.
2. **AWS.** [Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/). Buenas prácticas de arquitectura.
3. **AWS.** [AWS Free Tier](https://aws.amazon.com/free/). Qué entra en la capa gratuita.
4. **AWS.** [Overview of Amazon Web Services](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html). Panorama de servicios.

## Guías relacionadas

- [Nginx con HTTPS](../nginx-como-reverse-proxy-con-https/index.md)
- [Infrastructure as Code](../infrastructure-as-code-con-terraform/index.md)
- [FinOps: costos de cloud](../finops-controlar-y-reducir-costos-de-cloud/index.md)
- [Docker desde cero](../docker-desde-cero-imagenes-contenedores-y-volumenes/index.md)
- [Índice de DevOps y cloud](../index.md)