Contenido de este artículo
- Qué opciones tienes para ejecutar PHP en AWS
- Arquitectura mínima recomendada
- Paso 1: crear la instancia y proteger el acceso
- Paso 2: instalar Nginx y PHP-FPM
- Paso 3: base de datos en RDS
- Paso 4: HTTPS con Let's Encrypt
- Paso 5: desplegar la aplicación
- Seguridad y buenas prácticas
- Cómo controlar los costes
- Cuándo pasar a contenedores o a algo más gestionado
- Preguntas habituales
AWS ofrece muchas formas de ejecutar una aplicación PHP, y elegir mal complica el mantenimiento o encarece la factura. Esta guía compara las opciones más habituales y recorre paso a paso un despliegue clásico y sólido: EC2 con Nginx, PHP-FPM, base de datos en RDS y HTTPS, válido para Symfony, Laravel o PHP a medida.
Qué opciones tienes para ejecutar PHP en AWS
| Opción | Para quién | Ventaja | Contrapartida |
|---|---|---|---|
| Lightsail | Webs y proyectos pequeños | Precio fijo y panel sencillo | Menos flexibilidad y escalado limitado |
| EC2 (servidor virtual) | Aplicaciones a medida, control total | Flexible, predecible y muy documentado | Tú administras el sistema operativo |
| Elastic Beanstalk | Equipos que quieren despliegue gestionado | Automatiza balanceo y despliegue | Menos control y abstracciones propias |
| ECS con Fargate (contenedores) | Aplicaciones que ya usan Docker o necesitan escalar | Sin gestionar servidores, despliegues repetibles | Más piezas y más curva de aprendizaje |
Para la mayoría de aplicaciones de pymes, EC2 con una base de datos gestionada es el punto de equilibrio: es sencillo de entender, barato y permite crecer. Si ya trabajas con contenedores o esperas mucho tráfico, valora ECS con Fargate.
Arquitectura mínima recomendada
- EC2 con Ubuntu, Nginx y PHP-FPM ejecutando la aplicación.
- RDS (MySQL o PostgreSQL) para la base de datos, en una subred privada y accesible solo desde la instancia.
- S3 para archivos subidos por los usuarios y copias de seguridad.
- Route 53 para el DNS y una IP elástica asociada a la instancia.
- HTTPS con un certificado gratuito (Let's Encrypt en la instancia, o ACM si usas un balanceador).
- CloudFront delante, opcional, para cachear contenido estático y reducir carga.
Paso 1: crear la instancia y proteger el acceso
- Crea una instancia EC2 con Ubuntu Server LTS. Para empezar, un tipo pequeño de la familia
t(por ejemplot3.small) basta para una aplicación con tráfico moderado; se redimensiona después. - Configura el grupo de seguridad: puerto 80 y 443 abiertos al mundo, y el 22 (SSH) solo desde tu IP.
- Asocia una IP elástica para que la dirección no cambie al reiniciar.
- Accede por SSH con clave (no con contraseña) y no uses el usuario
rootpara el día a día.
Paso 2: instalar Nginx y PHP-FPM
En Ubuntu 24.04 la versión de PHP disponible es la 8.3. Instala el servidor web, PHP y las extensiones habituales:
sudo apt update
sudo apt install -y nginx php8.3-fpm php8.3-cli php8.3-mysql php8.3-xml \
php8.3-mbstring php8.3-curl php8.3-zip php8.3-intl unzip git
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
Configura el sitio de Nginx. Este ejemplo sirve una aplicación Symfony cuyo punto de entrada está en public/:
server {
listen 80;
server_name ejemplo.com www.ejemplo.com;
root /var/www/app/public;
location / {
try_files $uri /index.php$is_args$args;
}
location ~ ^/index\.php(/|$) {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
internal;
}
location ~ \.php$ {
return 404;
}
}
Guárdalo en /etc/nginx/sites-available/app, enlázalo en sites-enabled y recarga con sudo nginx -t && sudo systemctl reload nginx. Para Laravel, el esquema es el mismo con root apuntando a public/.
Paso 3: base de datos en RDS
- Crea una instancia RDS (MySQL o PostgreSQL) en la misma región y VPC que la instancia EC2.
- Márcala como no accesible públicamente y permite el tráfico solo desde el grupo de seguridad de la EC2 (no desde IPs).
- Activa las copias automáticas y define un periodo de retención.
- Guarda las credenciales fuera del repositorio: en variables de entorno del servidor, en un fichero
.env.localcon permisos restringidos o en AWS Secrets Manager.
Paso 4: HTTPS con Let's Encrypt
Con el dominio ya apuntando a la IP elástica desde Route 53 (o desde tu proveedor de DNS), instala Certbot y solicita el certificado:
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d ejemplo.com -d www.ejemplo.com
Certbot modifica Nginx para servir HTTPS y programa la renovación automática. Comprueba que funciona con sudo certbot renew --dry-run.
Paso 5: desplegar la aplicación
Clona el repositorio en /var/www/app con un usuario de despliegue y ejecuta este flujo en cada versión:
cd /var/www/app
git pull origin main
composer install --no-dev --optimize-autoloader
php bin/console doctrine:migrations:migrate --no-interaction
php bin/console cache:clear --env=prod
sudo systemctl reload php8.3-fpm
Con el tiempo conviene automatizarlo: un flujo de GitHub Actions que, al hacer push a main, se conecte por SSH, ejecute estos comandos y avise si algo falla. Así los despliegues son repetibles y no dependen de que alguien recuerde los pasos.
Seguridad y buenas prácticas
- Mínimo privilegio: roles de IAM con solo los permisos necesarios y sin claves de acceso en el código.
- Actualizaciones: aplica parches del sistema y de PHP de forma regular.
- Firewall y accesos: SSH restringido y, si es posible, sin puerto 22 abierto (Systems Manager Session Manager como alternativa).
- Copias de seguridad probadas: RDS automático más un volcado periódico a S3. Una copia que nunca se ha restaurado no es una copia.
- Monitorización: CloudWatch para CPU, memoria, disco y errores, con alarmas que te avisen antes de que falle.
- Aplicación en producción:
APP_ENV=prod, depuración desactivada y errores registrados en fichero, no mostrados al usuario.
Cómo controlar los costes
- Empieza con instancias pequeñas y redimensiona con datos reales de uso.
- Configura AWS Budgets con alertas para no llevarte sorpresas en la factura.
- Apaga o elimina lo que no uses: volúmenes sueltos, instantáneas antiguas, IPs elásticas sin asociar.
- Para cargas estables, estudia Savings Plans o instancias reservadas cuando ya conozcas el consumo.
Cuándo pasar a contenedores o a algo más gestionado
Este esquema funciona muy bien hasta cierto tamaño. Si necesitas escalar horizontalmente, desplegar sin cortes, tener entornos idénticos entre desarrollo y producción o gestionar varias aplicaciones, es el momento de dar el paso a contenedores con ECS/Fargate y a una base de datos con alta disponibilidad. No hace falta empezar ahí: migrar desde una EC2 bien montada es un paso natural.
Preguntas habituales
- ¿Cuánto cuesta alojar una aplicación PHP en AWS? Depende de la instancia, la base de datos y el tráfico. Una aplicación pequeña con EC2 y RDS básicos puede costar unas decenas de euros al mes, pero conviene calcularlo con la calculadora de precios de AWS y activar alertas de presupuesto.
- ¿Es mejor Lightsail o EC2? Lightsail es más simple y de precio fijo, ideal para proyectos pequeños. EC2 ofrece más flexibilidad y se integra mejor con el resto de servicios de AWS cuando la aplicación crece.
- ¿Sirve esta guía para Laravel? Sí. El esquema con Nginx, PHP-FPM, RDS y HTTPS es el mismo. Cambian los comandos de la aplicación (por ejemplo,
php artisan migrate --forcey las cachés de Laravel). - ¿Necesito un balanceador de carga? No para empezar. Con una sola instancia basta. Un balanceador (ALB) tiene sentido cuando quieres varias instancias, despliegues sin cortes o certificados gestionados con ACM.
- ¿Puedes encargarte del despliegue por mí? Sí. Diseño la infraestructura, configuro el servidor y dejo el despliegue automatizado, con copias de seguridad y monitorización.
¿Quieres verlo aplicado a tu caso?Cuéntame tu proyecto; respuesta en menos de 24 horas.
Cuéntame tu caso¿Lo aplicamos en tu caso?Consulta el servicio de despliegue e infraestructura en AWS o escríbeme y hablamos de tu proyecto.