AWS Elastic Beanstalk vs Azure App Service para .NET

Tanto AWS Elastic Beanstalk como Azure App Service son plataformas PaaS administradas que toman una aplicación .NET y la ejecutan sin que tengas que gestionar servidores. Sin embargo, tienen enfoques muy diferentes en cuanto a configuración, precios y experiencia de despliegue. Aquí tienes una comparación cara a cara.

Complejidad de Configuración

Azure App Service

Tres comandos para tener una aplicación en ejecución:

az group create --name myapp-rg --location eastus
az appservice plan create --name myapp-plan --resource-group myapp-rg --sku B1 --is-linux
az webapp create --name myapp-12345 --resource-group myapp-rg --plan myapp-plan --runtime "DOTNETCORE:10.0"

Despliegue:

dotnet publish -c Release -o ./publish
# az webapp deploy quiere un ARCHIVO zip — apuntar --src-path a la carpeta falla
cd ./publish && zip -r ../app.zip . && cd ..   # Windows: tar.exe -a -cf app.zip -C publish *
az webapp deploy --resource-group myapp-rg --name myapp-12345 --src-path ./app.zip --type zip

Tiempo total hasta tener la aplicación en ejecución: ~5 minutos — medido al desplegar el ejemplo, y la mayor parte es la fase de "Starting the site" tras subir el zip, no la subida en sí:

AWS Elastic Beanstalk

Proceso más complejo — EB gestiona instancias EC2, balanceadores de carga y grupos de autoescalado:

# Instalar EB CLI
pip install awsebcli
 
# Inicializar proyecto
eb init myapp \
  --platform "dotnet-core-on-al2023" \
  --region us-east-1
 
# Crear entorno (aprovisiona EC2, LB, grupos de seguridad)
eb create myapp-prod \
  --instance-type t3.small \
  --single  # Omitir el balanceador de carga para apps de dev/pequeñas

Despliegue — EB comprime tu directorio de proyecto por defecto, así que apúntalo a la salida de publish:

dotnet publish -c Release -o ./publish
cd ./publish && zip -r ../deploy.zip . && cd ..

# .elasticbeanstalk/config.yml — despliega el artefacto, no el árbol de código fuente
deploy:
  artifact: deploy.zip

eb deploy

Tiempo total hasta tener la aplicación en ejecución: ~10-15 minutos (el aprovisionamiento de EC2 tarda más).

Veredicto: Azure App Service gana en simplicidad de configuración. EB tiene más componentes en juego.

Precios

Azure App Service

Tarifa plana predecible — pagas por el nivel independientemente del uso real.

AWS Elastic Beanstalk

EB en sí es gratuito; pagas por los recursos subyacentes:

Un entorno EB de producción (t3.small + ALB): ~$36/mes.

Azure App Service S1 comparable: ~$69/mes, pero incluye más funciones.

Veredicto: AWS gana en precio bruto por cómputo equivalente, pero Azure incluye más en el precio base (slots de despliegue, mejores herramientas de DX).

Soporte de Runtime .NET

Azure App Service

• Soporte .NET de primera mano — Microsoft mantiene los runtimes
• Nuevas versiones de .NET disponibles el día de su lanzamiento en Linux/Windows
• Versiones de runtime en paralelo por aplicación
• Soporte nativo para .NET Framework (plan Windows) y .NET Core/8+ (Linux o Windows)

# Listar runtimes disponibles
az webapp list-runtimes --os linux | grep DOTNET

AWS Elastic Beanstalk

• Soporte .NET a través de la plataforma AL2023 (Amazon Linux 2023)
• Nuevas versiones de .NET disponibles semanas o meses después del lanzamiento (a la espera de la actualización de la plataforma EB)
• Opción Windows Server disponible para .NET Framework
• La versión del runtime está ligada a la rama de plataforma de EB que eliges en eb init — no hay un ajuste de runtime por app; consulta el historial de plataformas EB para ver qué incluye cada rama. La publicación self-contained (--self-contained) evita la espera empaquetando el runtime en tu artefacto, a costa de un zip mucho más grande.

Veredicto: Azure gana en soporte de runtime .NET. Lanzamientos de .NET el día uno e integración más profunda con Microsoft.

Escalado

Azure App Service

# Escalar manualmente (nivel Básico)
az appservice plan update --name myapp-plan --resource-group myapp-rg --number-of-workers 3
 
# Autoescalado (Estándar+)
az monitor autoscale create \
  --resource-group myapp-rg \
  --resource myapp-plan \
  --resource-type Microsoft.Web/serverFarms \
  --name myapp-autoscale \
  --min-count 1 --max-count 5 --count 1
 
# Regla de escalado — agregar instancia cuando CPU > 70%
az monitor autoscale rule create \
  --resource-group myapp-rg \
  --autoscale-name myapp-autoscale \
  --condition "CpuPercentage > 70 avg 5m" \
  --scale out 1

• Tiempo de escalado horizontal: 3–5 minutos
• Máximo de instancias: hasta 30 (Estándar), más de 100 (Premium)
• Autoescalado basado en HTTP disponible (escalar según profundidad de la cola de solicitudes)

AWS Elastic Beanstalk

# .ebextensions/autoscaling.config
option_settings:
  aws:autoscaling:asg:
    MinSize: 1
    MaxSize: 10
  aws:autoscaling:trigger:
    MeasureName: CPUUtilization
    Unit: Percent
    UpperThreshold: 70
    LowerThreshold: 30
    UpperBreachScaleIncrement: 1
    LowerBreachScaleIncrement: -1
    BreachDuration: 5
  aws:elasticbeanstalk:environment:
    EnvironmentType: LoadBalanced  # Requerido para autoescalado

• Tiempo de escalado horizontal: 3–7 minutos (aprovisionamiento de EC2)
• Más opciones de escalado mediante métricas de CloudWatch
• Escalado predictivo disponible con configuración adicional

Veredicto: Azure gana en DX de escalado. Las reglas de escalado de Azure son más sencillas de configurar. EB ofrece más flexibilidad pero mayor complejidad.

Integración CI/CD

Azure App Service

GitHub Actions: Integración de primer nivel con la action azure/webapps-deploy:

- name: Deploy to Azure App Service
  uses: azure/webapps-deploy@v3
  with:
    app-name: myapp-12345
    publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
    package: ./publish

Azure DevOps: Integración nativa, configuración de pipeline con un clic desde el portal.

Slots de despliegue: Despliegues azul/verde integrados — despliega en staging, intercambia a producción:

az webapp deployment slot swap --name myapp-12345 --resource-group myapp-rg --slot staging

AWS Elastic Beanstalk

GitHub Actions:

- name: Deploy to EB
  uses: einaregilsson/beanstalk-deploy@v21
  with:
    aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    application_name: myapp
    environment_name: myapp-prod
    version_label: ${{ github.sha }}
    region: us-east-1
    deployment_package: deploy.zip

CodePipeline: CI/CD nativo de AWS, más potente pero con más configuración.

Azul/verde: Más complejo en EB — requiere crear un nuevo entorno, intercambiar CNAMEs y luego terminar el entorno antiguo.

Veredicto: Azure gana en CI/CD. Los slots de despliegue hacen triviales los despliegues sin tiempo de inactividad. El azul/verde en EB es posible pero requiere más esfuerzo.

Monitoreo

Azure App Service

• Application Insights: Integración con un clic desde el portal. Trazado distribuido completo, monitoreo de rendimiento, excepciones y métricas personalizadas.
• Flujo de logs: az webapp log tail para logs en tiempo real
• Herramientas de diagnóstico: Perfilador integrado, volcados de memoria, perfilado de CPU desde el Portal
• Alertas: Integración nativa con Azure Monitor

// Program.cs — habilitar Application Insights
builder.Services.AddApplicationInsightsTelemetry();

AWS Elastic Beanstalk

• CloudWatch: Métricas y logs, requiere configuración
• X-Ray: Trazado distribuido (requiere integración del SDK y configuración de IAM)
• Panel de Salud de EB: Estado de instancias, historial de despliegues
• Transmisión de logs: Requiere habilitar la integración con CloudWatch Logs

// Agregar AWS X-Ray para trazado distribuido
dotnet add package AWSXRayRecorder.Handlers.AspNetCore
 
// Configuración de inicio
app.UseXRay("MyApp");

Veredicto: Azure gana en DX de monitoreo. Application Insights es significativamente más fácil de configurar y más amigable para el desarrollador que la combinación CloudWatch/X-Ray.

Configuración del Entorno

Azure App Service

# Configuración de aplicación (variables de entorno)
az webapp config appsettings set \
  --resource-group myapp-rg \
  --name myapp-12345 \
  --settings KEY=value
 
# Referenciar secretos de Key Vault
az webapp config appsettings set \
  --resource-group myapp-rg \
  --name myapp-12345 \
  --settings "Secret=@Microsoft.KeyVault(VaultName=myvault;SecretName=MySecret)"

AWS Elastic Beanstalk

# .ebextensions/env-vars.config
option_settings:
  aws:elasticbeanstalk:application:environment:
    ASPNETCORE_ENVIRONMENT: Production
    ConnectionString: "Server=..."
 
# O mediante EB CLI
eb setenv KEY=value ANOTHER_KEY=value2

Para secretos, usa AWS Systems Manager Parameter Store o Secrets Manager:

// Leer desde SSM Parameter Store
var config = new AmazonSimpleSystemsManagementClient();
var param = await config.GetParameterAsync(new GetParameterRequest
{
    Name = "/myapp/prod/database-password",
    WithDecryption = true
});
var password = param.Parameter.Value;

Resumen Comparativo

Veredicto

Elige Azure App Service si:

• Tu equipo está principalmente enfocado en .NET/Microsoft
• Quieres el mejor soporte de runtime .NET desde el día uno
• Necesitas despliegues sin tiempo de inactividad simples (slots)
• Quieres integración con Application Insights
• El monitoreo y la DX importan más que el costo bruto

Elige AWS Elastic Beanstalk si:

• Tu organización está profundamente integrada en AWS
• Necesitas una integración más estrecha con los servicios de AWS (RDS, ElastiCache, SQS)
• Quieres más control sobre la configuración subyacente de EC2
• La optimización de costos es crítica y estás dispuesto a invertir tiempo en la configuración

Para la mayoría de los proyectos .NET nuevos en 2026, Azure App Service ofrece una mejor experiencia de desarrollador a un costo comparable o ligeramente superior. Elastic Beanstalk tiene sentido cuando AWS ya es tu proveedor de nube principal.

Lecturas adicionales

• Azure App Service overview (Microsoft Learn)
• AWS Elastic Beanstalk Developer Guide