# Migrar uma aplicação .NET para a AWS: do GitHub à EC2

> Como levar uma aplicação .NET que roda só na sua máquina para uma EC2: SSH, git clone, instalar o .NET SDK e rodar na porta 80, sem mexer no código.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Migração, Custos
- URL: https://pages.formacaoaws.com.br/blog/migrar-aplicacao-dotnet-para-ec2/
- Aula de origem: "Aula 02 - Curso AWS grátis: Migrando sua aplicação para a nuvem do zero absoluto." (https://www.youtube.com/watch?v=MD5lyZwWNPw)

A sua aplicação .NET Core roda só na sua máquina e você quer vê-la funcionando na AWS. Aqui eu levo uma aplicação assim para uma instância EC2, acessível pelo navegador na porta 80, sem mexer no código: SSH, `git clone`, .NET SDK e `dotnet run`.

O ponto de partida: o projeto já roda local, está publicado no GitHub e existe uma instância EC2 criada na AWS.

## A meta: primeiro levar, depois desacoplar

A proposta do minicurso é romper a barreira de levar a sua aplicação para a AWS. Quebrar a aplicação nos vários serviços da nuvem, o que eu chamo de desacoplamento, vem depois que ela já está lá dentro. Então o primeiro passo é copiar o que você tem para uma máquina na nuvem e fazer funcionar do jeito que já era.

Neste modelo a nuvem é só o **host**. A aplicação, o banco de dados e os serviços integrados ficam todos dentro da mesma EC2, parecido com o que você tem local. A diferença é que, estando na AWS, você passa a ter à disposição os serviços dela para ir tirando as peças dali, uma de cada vez.

## Antes de ligar: o que a instância custa parada

Deixei a instância parada de propósito, para mostrar um benefício natural da nuvem: o poder computacional só é cobrado enquanto a instância está ligada. Parada, o que continua cobrando é o disco de 10 GB que alocamos, em torno de 1 dólar por mês.

![O painel da instância no console da EC2 com Instance state em stopped: parada, só o disco de 10 GB continua cobrando](https://pages.formacaoaws.com.br/blog/assets/posts/migrar-aplicacao-dotnet-para-ec2/instancia-parada.webp)

Quando liguei a instância, a cobrança pelo processamento voltou a correr, e ela é fracionada: você paga pelo tempo de uso, por segundo. Por isso fica barato montar cases, ambientes de desenvolvimento e ambientes de homologação.

O valor do disco é o da gravação, em 2019. Confira o preço atual na página do Amazon EBS antes de planejar.

## Passo 1: conectar na instância por SSH

Com a instância ligada, copie o endereço público dela no console (o **Public DNS**). Eu já tinha colocado a chave PEM, baixada na aula anterior, na raiz do projeto, e conectei com `ssh`:

```bash
ssh -i "sua-chave.pem" ec2-user@<DNS público da instância>
```

Troque `sua-chave.pem` pelo nome do arquivo que você baixou e o endereço pelo da sua instância. A máquina que abre é um Amazon Linux 2. Eu trabalhei com privilégio de administrador (sudo) para instalar os pacotes.

> **Importante:** a chave PEM é a senha de acesso às suas instâncias. Nunca deixe ela dentro do repositório. Eu coloquei a exceção `*.pem` no `.gitignore` do projeto.

## Passo 2: instalar o Git e clonar o projeto

O projeto está no GitHub, então o caminho é clonar. Na instância, o Git não vem instalado. Instale com o gerenciador de pacotes:

```bash
yum install git
```

Eu estava com o sudo ativo na sessão, por isso rodei sem prefixo. Confirme a instalação e crie uma pasta para o projeto:

```bash
mkdir projeto
cd projeto
git clone <URL HTTPS do seu repositório>
```

Entre na pasta que o clone criou. No meu caso, `exemplo_migrando_para_aws`. Eu disse na aula que deixaria o projeto de exemplo disponível para quem quiser clonar e testar.

## Passo 3: instalar o .NET SDK

A aplicação é .NET Core, então a instância precisa do SDK. Na página de download da Microsoft, escolhi a distribuição **CentOS 7** e rodei os dois comandos que ela mostra: o primeiro registra o repositório de pacotes da Microsoft, o segundo instala o SDK.

![A página de download da Microsoft com CentOS 7 - x64 selecionado e os dois comandos: registrar o repositório e instalar o dotnet-sdk-3.0](https://pages.formacaoaws.com.br/blog/assets/posts/migrar-aplicacao-dotnet-para-ec2/instalar-dotnet.webp)

```bash
sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm
sudo yum install dotnet-sdk-3.0
```

Esses são os comandos da época da gravação, para o .NET Core 3.0. Pegue os da página da Microsoft para a versão e a tecnologia que você usa. A instalação na AWS é rápida. Com o SDK instalado, restaure as dependências dentro da pasta do projeto:

```bash
dotnet restore
```

## Passo 4: rodar na porta 80

Por padrão, o meu projeto sobe nas portas 5000 e 5001. Quero acessar pelo endereço da instância, na porta 80. O `dotnet run --help` mostra o parâmetro que resolve:

```bash
dotnet run --urls http://<DNS público da instância>
```

Eu passei o DNS público da instância, sem porta, e a aplicação respondeu que estava escutando na 80. Na primeira tentativa esqueci o `http://` na frente do endereço e o .NET recusou a URL como inválida; com o `http://`, subiu.

![No terminal, a primeira tentativa falha com Invalid url; com o http:// na frente, a aplicação sobe em Now listening on: http://[::]:80 (DNS público e nome da máquina borrados)](https://pages.formacaoaws.com.br/blog/assets/posts/migrar-aplicacao-dotnet-para-ec2/porta-80-no-ar.webp)

> **Importante:** antes de abrir no navegador, confirme no security group da instância que a porta 80 está aberta para entrada. Era a que eu precisava, e estava.

Abra `http://` seguido do DNS público da instância. A aplicação aparece, rodando na AWS.

![A aplicação de exemplo, com o título Seja bem-vindo, aberta no navegador pelo DNS público da EC2 (endereço borrado)](https://pages.formacaoaws.com.br/blog/assets/posts/migrar-aplicacao-dotnet-para-ec2/app-rodando.webp)

Para atualizar, o fluxo é o de sempre: faça a mudança, dê o push para o GitHub e, na instância, um pull no projeto.

## Onde você chegou e o que vem depois

Neste cenário, a sua aplicação inteira está numa instância EC2: o código, o banco de dados e os demais serviços integrados a ela. Você usa a nuvem como host, e isso não é o modelo ideal para a nuvem. É o ponto de partida, e a partir dele você desacopla aos poucos:

**Fluxo:** GitHub (código do projeto) → Amazon EC2 (Amazon Linux 2) → .NET SDK (dotnet run --urls) → Navegador (porta 80 aberta)

A ordem que eu sugeri para ir quebrando a aplicação:

- **Banco de dados.** Tire o banco de dentro da EC2 e use o serviço aderente ao seu banco, no caso o RDS.
- **Aplicação sem estado.** Transforme a aplicação em stateless, para que ela possa ter escalabilidade.
- **Balanceamento e escala.** Coloque um load balancer e o auto scaling na frente.

Cada um desses é assunto de outro tópico. A próxima aula do minicurso mostra um cenário simples para você ter uma prévia do custo que a sua aplicação teria na AWS, porque muita gente acha que a nuvem custa caro.

## Checklist

- A chave PEM está fora do repositório, com `*.pem` no `.gitignore`.
- A instância está ligada e você copiou o DNS público dela.
- Você conectou por SSH como `ec2-user`.
- O Git está instalado e o projeto foi clonado numa pasta da instância.
- O .NET SDK foi instalado com os comandos da página da Microsoft para a sua versão.
- O `dotnet restore` terminou sem erro.
- O security group libera a porta 80 de entrada.
- O `dotnet run --urls` com o DNS público sobe a aplicação e ela abre no navegador.

Levar a aplicação como ela está é o passo que destrava os outros. Só depois de rodar na AWS faz sentido decidir o que desacoplar primeiro.