AWS Elastic Beanstalk vs Azure App Service para .NET

Tanto o AWS Elastic Beanstalk quanto o Azure App Service são plataformas PaaS gerenciadas que executam uma aplicação .NET sem que você precise gerenciar servidores. No entanto, eles têm abordagens muito diferentes em relação à configuração, preços e experiência de implantação. Aqui está uma comparação direta entre os dois.

Complexidade de Configuração

Azure App Service

Três comandos para ter uma aplicação em execução:

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"

Implantação:

dotnet publish -c Release -o ./publish
# az webapp deploy quer um ARQUIVO zip — apontar --src-path para a pasta falha
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

Tempo total até a aplicação estar em execução: ~5 minutos — medido ao implantar o exemplo, e a maior parte é a fase de "Starting the site" após o upload do zip, não o upload em si:

AWS Elastic Beanstalk

Processo mais complexo — o EB gerencia instâncias EC2, balanceadores de carga e grupos de auto scaling:

# Instalar EB CLI
pip install awsebcli
 
# Inicializar projeto
eb init myapp \
  --platform "dotnet-core-on-al2023" \
  --region us-east-1
 
# Criar ambiente (provisiona EC2, LB, grupos de segurança)
eb create myapp-prod \
  --instance-type t3.small \
  --single  # Ignorar load balancer para apps de dev/pequenas

Implantação — o EB compacta seu diretório de projeto por padrão, então aponte-o para a saída do publish:

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

# .elasticbeanstalk/config.yml — implante o artefato, não a árvore de código-fonte
deploy:
  artifact: deploy.zip

eb deploy

Tempo total até a aplicação estar em execução: ~10-15 minutos (o provisionamento do EC2 leva mais tempo).

Veredicto: Azure App Service vence em simplicidade de configuração. O EB tem mais componentes envolvidos.

Preços

Azure App Service

Taxa fixa previsível — você paga pelo nível independentemente do uso real.

AWS Elastic Beanstalk

O EB em si é gratuito; você paga pelos recursos subjacentes:

Um ambiente EB de produção (t3.small + ALB): ~$36/mês.

Azure App Service S1 comparável: ~$69/mês, mas inclui mais recursos.

Veredicto: AWS vence no preço bruto para computação equivalente, mas o Azure inclui mais no preço base (slots de implantação, melhores ferramentas de DX).

Suporte de Runtime .NET

Azure App Service

• Suporte .NET nativo — a Microsoft mantém os runtimes
• Novas versões do .NET disponíveis no dia do lançamento no Linux/Windows
• Versões de runtime lado a lado por aplicação
• Suporte nativo para .NET Framework (plano Windows) e .NET Core/8+ (Linux ou Windows)

# Listar runtimes disponíveis
az webapp list-runtimes --os linux | grep DOTNET

AWS Elastic Beanstalk

• Suporte .NET via plataforma AL2023 (Amazon Linux 2023)
• Novas versões do .NET disponíveis semanas a meses após o lançamento (aguardando atualização da plataforma EB)
• Opção Windows Server disponível para .NET Framework
• A versão do runtime é atrelada ao branch de plataforma do EB que você escolhe no eb init — não há configuração de runtime por app; consulte o histórico de plataformas EB para ver o que cada branch inclui. A publicação self-contained (--self-contained) contorna a espera empacotando o runtime no seu artefato, ao custo de um zip muito maior.

Veredicto: Azure vence no suporte de runtime .NET. Lançamentos .NET no dia zero e integração mais profunda com a Microsoft.

Escalabilidade

Azure App Service

# Escalonamento manual horizontal (nível Básico)
az appservice plan update --name myapp-plan --resource-group myapp-rg --number-of-workers 3
 
# Auto scaling (Standard+)
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
 
# Regra de escalonamento — adicionar instância quando CPU > 70%
az monitor autoscale rule create \
  --resource-group myapp-rg \
  --autoscale-name myapp-autoscale \
  --condition "CpuPercentage > 70 avg 5m" \
  --scale out 1

• Tempo de escalonamento horizontal: 3–5 minutos
• Máximo de instâncias: até 30 (Standard), 100+ (Premium)
• Auto scaling baseado em HTTP disponível (escalar pela profundidade da fila de requisições)

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  # Obrigatório para auto scaling

• Tempo de escalonamento horizontal: 3–7 minutos (provisionamento do EC2)
• Mais opções de escalonamento via métricas do CloudWatch
• Escalonamento preditivo disponível com configuração adicional

Veredicto: Azure vence na DX de escalabilidade. As regras de escalonamento do Azure são mais simples de configurar. O EB oferece mais flexibilidade, mas com maior complexidade.

Integração CI/CD

Azure App Service

GitHub Actions: Integração de primeira classe com a 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: Integração nativa, configuração de pipeline com um clique pelo portal.

Slots de implantação: Deploys azul/verde nativos — implante no staging, troque para produção:

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 da AWS, mais poderoso mas com mais configuração.

Azul/verde: Mais complexo no EB — requer criação de um novo ambiente, troca de CNAMEs e encerramento do ambiente antigo.

Veredicto: Azure vence em CI/CD. Os slots de implantação tornam triviais os deploys sem downtime. O azul/verde no EB é viável, mas exige mais esforço.

Monitoramento

Azure App Service

• Application Insights: Integração com um clique pelo portal. Rastreamento distribuído completo, monitoramento de desempenho, exceções e métricas personalizadas.
• Stream de logs: az webapp log tail para logs em tempo real
• Ferramentas de diagnóstico: Profiler integrado, dumps de memória, perfilamento de CPU pelo Portal
• Alertas: Integração nativa com o Azure Monitor

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

AWS Elastic Beanstalk

• CloudWatch: Métricas e logs, requer configuração
• X-Ray: Rastreamento distribuído (requer integração do SDK e configuração de IAM)
• Painel de Saúde do EB: Saúde das instâncias, histórico de implantações
• Streaming de logs: Requer habilitar a integração com CloudWatch Logs

// Adicionar AWS X-Ray para rastreamento distribuído
dotnet add package AWSXRayRecorder.Handlers.AspNetCore
 
// Configuração de inicialização
app.UseXRay("MyApp");

Veredicto: Azure vence na DX de monitoramento. O Application Insights é significativamente mais fácil de configurar e mais amigável ao desenvolvedor do que a combinação CloudWatch/X-Ray.

Configuração de Ambiente

Azure App Service

# Configurações de aplicação (variáveis de ambiente)
az webapp config appsettings set \
  --resource-group myapp-rg \
  --name myapp-12345 \
  --settings KEY=value
 
# Referenciar segredos do 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=..."
 
# Ou via EB CLI
eb setenv KEY=value ANOTHER_KEY=value2

Para segredos, use o AWS Systems Manager Parameter Store ou o Secrets Manager:

// Ler do 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;

Resumo Comparativo

Veredicto

Escolha o Azure App Service se:

• Sua equipe é focada principalmente em .NET/Microsoft
• Você quer o melhor suporte de runtime .NET desde o dia zero
• Você precisa de deploys sem downtime simples (slots)
• Você quer integração com o Application Insights
• Monitoramento e DX importam mais do que o custo bruto

Escolha o AWS Elastic Beanstalk se:

• Sua organização está profundamente integrada na AWS
• Você precisa de integração mais estreita com serviços AWS (RDS, ElastiCache, SQS)
• Você quer mais controle sobre a configuração subjacente do EC2
• A otimização de custos é crítica e você está disposto a investir tempo em configuração

Para a maioria dos projetos .NET novos em 2026, o Azure App Service oferece uma experiência de desenvolvedor melhor a um custo comparável ou ligeiramente superior. O Elastic Beanstalk faz sentido quando a AWS já é seu provedor de nuvem principal.

Leituras adicionais

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