AWS para desenvolvedores .NET: por onde começar sem se perder
A AWS tem uma lista de serviços grande o bastante para parecer hostil para quem só quer colocar uma aplicação .NET no ar. O problema raramente é falta de opção. É excesso.
Dá para ignorar boa parte do catálogo no começo e focar num punhado de peças que realmente resolvem o problema de rodar código, guardar dado e falar com a AWS a partir de C#.
Onde o código roda
Existem, essencialmente, quatro caminhos comuns para hospedar uma aplicação .NET na AWS.
EC2 é uma máquina virtual: você controla o sistema operacional, instala o runtime, configura tudo. Máxima flexibilidade, máxima responsabilidade também.
Elastic Beanstalk empacota parte dessa complexidade: você sobe o código ou o artefato de build, e o serviço cuida do provisionamento por trás, incluindo balanceamento de carga e escalonamento básico.
ECS e Fargate rodam contêineres. ECS é o orquestrador da AWS; Fargate remove a necessidade de gerenciar as instâncias por trás dos contêineres, então a preocupação fica só com a imagem e a definição da tarefa.
AWS Lambda roda funções sem servidor dedicado, cobrando por execução. Faz sentido para cargas de trabalho orientadas a evento, não necessariamente para uma aplicação web tradicional rodando o tempo todo.
Onde o dado fica
Amazon S3 guarda arquivos e objetos: imagens, documentos, backups, artefatos de build. Não é um banco de dados relacional, é um armazenamento de objetos com API própria.
Amazon RDS é o serviço gerenciado de banco de dados relacional, com suporte a SQL Server, PostgreSQL, MySQL e outros. Ele cuida de backup, patch e failover, o que tira trabalho operacional real de cima de quem só quer manter a aplicação funcionando.
Como o C# conversa com tudo isso
O AWS SDK for .NET expõe clientes específicos para cada serviço, como AmazonS3Client e AmazonDynamoDBClient, com métodos que espelham a API de cada um. O AWS Toolkit for Visual Studio integra parte desse fluxo direto na IDE, incluindo publicação de projetos ASP.NET Core direto para Elastic Beanstalk ou contêineres.
Para infraestrutura descrita em código em vez de clicada manualmente no console, existe o AWS CDK, com suporte a C#, que permite declarar recursos AWS usando construções de linguagem familiares em vez de templates JSON ou YAML extensos.
O que fica de fora deste texto, de propósito
Tem um assunto que aparece assim que qualquer um desses serviços entra em produção: permissão. Quem pode criar o quê, qual papel a aplicação assume, o que ela realmente precisa acessar. Isso é IAM, e é denso o suficiente para merecer atenção própria em vez de um parágrafo apertado aqui no meio do resto.
Por onde faz sentido começar
Para conhecer os conceitos sem se comprometer com uma arquitetura complexa, Elastic Beanstalk ou um contêiner simples em Fargate tendem a exigir menos decisões de infraestrutura do que montar tudo em EC2 do zero. Isso não é regra fixa, é só o caminho que costuma exigir menos escolhas antes de existir alguma coisa rodando de fato.