Como montar uma rede empresarial na AWS com instâncias EC2

Guia passo a passo: VPC segmentada, firewall com NAT e proxy, Active Directory com Samba 4 e intranet, usando o projeto fictício TPM Studio como exemplo.

Rober122

Published Oct 6, 2026

Last modified Oct 6, 2026

1. Introdução

Redes corporativas precisam ser estáveis, seguras e fáceis de expandir. A ausência de planejamento gera falhas de segurança, interrupções e vulnerabilidades internas. Neste artigo, você vai montar, passo a passo, uma rede empresarial completa dentro da AWS, usando apenas instâncias EC2 e os recursos de rede da VPC.

O exemplo é a TPM Studio, uma empresa fictícia de desenvolvimento de jogos, com dois setores: Administrativo (RH e contratos, com acesso à internet restrito via proxy) e TI (equipe técnica que mantém a infraestrutura e cria os jogos).

Ao final, você terá:

uma VPC com sub-redes isoladas por função;
uma instância de firewall que faz NAT, proxy e filtragem de conteúdo;
um servidor central com Active Directory (Samba 4), DNS e intranet (Apache);
um cliente Windows ingressado no domínio e obrigado a navegar pelo proxy;
testes de validação e boas práticas de segurança.

2. Arquitetura da solução

A topologia é uma estrela estendida lógica dentro de uma VPC. Todo o tráfego passa pelo firewall, o que centraliza o controle e facilita adicionar novas sub-redes sem interromper os serviços existentes.

1
2
3
4
5
6
7
8
9
10
Internet

   |

Internet Gateway (IGW)

   |

[ Sub-rede Segurança 10.0.1.0/24 ]  -> Firewall/Proxy (Ubuntu) 10.0.1.72

   |                      |

   |                      +-- rota padrão das sub-redes privadas

   |

[ Clientes/Adm 10.0.2.0/24 ]   -> Cliente Windows 10.0.2.206

[ Servidores   10.0.4.0/24 ]   -> Servidor central (Ubuntu) 10.0.4.154

Plano de endereçamento

Setor	Rede	Máscara	Host do projeto
Segurança/Firewall	10.0.1.0/24	255.255.255.0	10.0.1.72
Clientes/Adm	10.0.2.0/24	255.255.255.0	10.0.2.206
Servidores	10.0.4.0/24	255.255.255.0	10.0.4.154

A VPC usa o bloco 10.0.0.0/16, que comporta as três sub-redes e deixa espaço para crescer (por exemplo, 10.0.3.0/24 para um futuro setor financeiro).

Equipamentos

Função	Qtde	Instância EC2	Sistema
Firewall/Proxy	1	t3.micro	Ubuntu Server
Servidor central	1	família "flex" (o documento cita t7i-flex.large; o nome provável é m7i-flex.large)	Ubuntu Server
Cliente	1	t3.small	Windows Server

Confira os tipos disponíveis na sua região e conta antes de lançar as instâncias.

3. Passo 1: criar a VPC

No console da AWS, abra VPC > Your VPCs > Create VPC.
Escolha VPC only, nome vpc-tpm, IPv4 CIDR 10.0.0.0/16.
Crie a VPC.

O DHCP é fornecido pela própria VPC: cada instância recebe o IP automaticamente, e você pode fixar o IP privado no momento de lançar a instância (passos 5, 7 e 9).

4. Passo 2: criar as sub-redes

Em VPC > Subnets > Create subnet, selecione vpc-tpm e crie três sub-redes na mesma zona de disponibilidade:

Nome	CIDR
`sn-seguranca`	10.0.1.0/24
`sn-clientes`	10.0.2.0/24
`sn-servidores`	10.0.4.0/24

A AWS reserva 5 endereços de cada sub-rede (os quatro primeiros e o último), então o intervalo utilizável é um pouco menor que o 10.0.x.1 a 10.0.x.254 da tabela teórica.

5. Passo 3: Internet Gateway e tabelas de rota

Crie um Internet Gateway (igw-tpm) e anexe à vpc-tpm.
Crie a tabela de rotas rt-publica com a rota 0.0.0.0/0 apontando para o igw-tpm e associe-a somente à sn-seguranca.
Crie a tabela rt-privada e associe-a às sub-redes sn-clientes e sn-servidores. Por enquanto ela só tem a rota local; a rota de saída será adicionada no passo 7, depois que o firewall existir.

Assim, apenas a sub-rede de segurança enxerga a internet diretamente. As demais só saem pela instância de firewall.

6. Passo 4: criar os Security Groups

Security Groups funcionam como firewall de cada instância. Crie três, seguindo o princípio do menor privilégio.

sg-firewall (instância de firewall/proxy)

Entrada: SSH (22) apenas do seu IP público.
Entrada: proxy Squid (TCP 3128) de 10.0.2.0/24.
Entrada: todo o tráfego de 10.0.0.0/16 (necessário para o firewall encaminhar o tráfego das sub-redes privadas via NAT).
Saída: tudo.

sg-servidores (servidor central)

Entrada: SSH (22) apenas de sg-firewall.
Entrada: HTTP (80) de 10.0.2.0/24.
Entrada: serviços do Active Directory a partir de 10.0.2.0/24 e 10.0.1.0/24: DNS (53 TCP/UDP), Kerberos (88 TCP/UDP), RPC (135), NetBIOS (139), LDAP (389 TCP/UDP), SMB (445), kpasswd (464), LDAPS (636), catálogo global (3268 e 3269) e portas dinâmicas RPC (49152 a 65535 TCP).
Entrada: ICMP de 10.0.0.0/16, para testes de ping.

sg-clientes (cliente Windows)

Entrada: RDP (3389) apenas de sg-firewall.
Entrada: ICMP de 10.0.0.0/16.
Saída: libere somente o que o cliente precisa: o servidor central (AD/DNS), o firewall na porta 3128 (proxy) e o que mais for necessário. Isso ajuda a forçar o uso do proxy.

7. Passo 5: lançar e configurar o firewall (NAT)

7.1 Lançar a instância

Em EC2 > Launch instance, nome fw-tpm, AMI Ubuntu Server, tipo t3.micro.
Em Network settings, escolha vpc-tpm, sub-rede sn-seguranca, Auto-assign public IP habilitado e sg-firewall.
Em Advanced network configuration, defina o IP privado primário como 10.0.1.72.
Crie ou selecione um par de chaves e lance a instância.
Associe um Elastic IP a ela, para o endereço público não mudar.
Desative a verificação de origem/destino: selecione a instância, Actions > Networking > Change source/destination check > Stop. Sem isso, a AWS descarta o tráfego que a instância encaminha em nome de outras máquinas.

7.2 Habilitar encaminhamento e NAT

Conecte por SSH (ssh -i chave.pem ubuntu@IP_ELASTICO) e execute:

1
2
3
4
5
6
7
8
9
10
11
12
13
sudo sysctl -w net.ipv4.ip_forward=1

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-forward.conf



# descubra o nome da interface (em instâncias Nitro costuma ser ens5)

ip -br link



sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -o ens5 -j MASQUERADE

sudo iptables -A FORWARD -s 10.0.0.0/16 -j ACCEPT

sudo iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT



sudo apt update

sudo apt install -y iptables-persistent

sudo netfilter-persistent save

Substitua ens5 pelo nome real da interface, se for diferente.

7.3 Apontar as sub-redes privadas para o firewall

Em VPC > Route tables > rt-privada > Edit routes, adicione 0.0.0.0/0 com destino Network Interface da instância fw-tpm (ou a própria instância, conforme o console oferecer). A partir daqui, servidores e clientes saem para a internet pelo NAT do firewall.

8. Passo 6: lançar o servidor central e provisionar o Active Directory

8.1 Lançar a instância

Lance uma instância Ubuntu Server de porte médio na sn-servidores, sem IP público, com sg-servidores e IP privado primário 10.0.4.154. Para acessar por SSH, use o firewall como salto:

1
ssh -i chave.pem -J ubuntu@IP_ELASTICO ubuntu@10.0.4.154

(Para isso, copie a chave ou use o encaminhamento de agente com ssh-add chave.pem e a opção -A.)

8.2 Preparar o sistema

1
2
3
4
5
6
7
8
9
10
sudo hostnamectl set-hostname dc01

echo '10.0.4.154 dc01.tpm.intra dc01' | sudo tee -a /etc/hosts



sudo apt update

sudo DEBIAN_FRONTEND=noninteractive apt install -y samba krb5-user winbind smbclient dnsutils



# o resolvedor local ocupa a porta 53 e precisa sair do caminho

sudo systemctl disable --now systemd-resolved

sudo rm /etc/resolv.conf

echo -e 'nameserver 127.0.0.1\nsearch tpm.intra' | sudo tee /etc/resolv.conf

Se o instalador do Kerberos perguntar o realm, informe TPM.INTRA.

8.3 Provisionar o domínio `tpm.intra`

1
2
3
4
5
6
7
8
9
10
11
12
sudo systemctl disable --now smbd nmbd winbind

sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.orig



sudo samba-tool domain provision \

  --use-rfc2307 \

  --realm=TPM.INTRA \

  --domain=TPM \

  --server-role=dc \

  --dns-backend=SAMBA_INTERNAL \

  --adminpass='UmaSenhaForte#2026'



sudo cp /var/lib/samba/private/krb5.conf /etc/krb5.conf

Edite /etc/samba/smb.conf e, na seção [global], ajuste o encaminhador DNS para o resolvedor da VPC (o endereço base da rede mais 2, ou seja, 10.0.0.2):

1
dns forwarder = 10.0.0.2

Iniciar o serviço:

1
2
sudo systemctl unmask samba-ad-dc

sudo systemctl enable --now samba-ad-dc

8.4 Verificar o domínio

1
2
3
4
sudo samba-tool domain level show

host -t SRV _ldap._tcp.tpm.intra

kinit administrator@TPM.INTRA

klist

8.5 Criar usuários e grupos

1
2
3
4
5
sudo samba-tool group add Administrativo

sudo samba-tool group add TI

sudo samba-tool user create ana.rh 'Senha#Inicial1' --must-change-at-next-login

sudo samba-tool group addmembers Administrativo ana.rh

sudo samba-tool user list

O comando samba-tool user list também serve para auditar quem tem conta no domínio.

8.6 Fazer a VPC usar o DNS do domínio

Para que todas as máquinas resolvam tpm.intra, crie um DHCP options set em VPC > DHCP option sets com domain-name = tpm.intra e domain-name-servers = 10.0.4.154, e associe-o à vpc-tpm. Como o DNS do Samba encaminha o restante para 10.0.0.2, a resolução de nomes públicos continua funcionando. Se preferir não mexer na VPC, configure o DNS manualmente em cada cliente.

9. Passo 7: publicar a intranet com Apache

No servidor central:

1
2
3
sudo apt install -y apache2

echo '<h1>Intranet TPM Studio</h1>' | sudo tee /var/www/html/index.html

sudo systemctl enable --now apache2

Teste de dentro da rede: curl 10.0.4.154. O sg-servidores já libera a porta 80 para a sub-rede de clientes.

10. Passo 8: configurar o proxy Squid no firewall

O Squid concentra a navegação do setor administrativo, aplica filtros e gera logs de auditoria.

1
2
sudo apt install -y squid ldap-utils

sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.orig

Crie a lista de domínios bloqueados:

1
2
3
4
sudo tee /etc/squid/bloqueados.txt >/dev/null <<'EOF'

.exemplo-jogos-online.com

.exemplo-streaming.com

EOF

Substitua o conteúdo de /etc/squid/squid.conf por uma configuração mínima com autenticação no AD:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
http_port 3128



# autenticação por LDAP contra o Samba AD

auth_param basic program /usr/lib/squid/basic_ldap_auth -R -b "dc=tpm,dc=intra" -D "proxy@tpm.intra" -w "SenhaDoProxy#1" -f "sAMAccountName=%s" -h 10.0.4.154

auth_param basic realm Proxy TPM Studio

acl autenticados proxy_auth REQUIRED



acl rede_clientes src 10.0.2.0/24

acl bloqueados dstdomain "/etc/squid/bloqueados.txt"

acl portas_seguras port 80 443



http_access deny !portas_seguras

http_access deny bloqueados

http_access allow rede_clientes autenticados

http_access deny all

Crie a conta de serviço usada pelo proxy no servidor central (sudo samba-tool user create proxy 'SenhaDoProxy#1'), reinicie e acompanhe os logs:

1
2
sudo systemctl restart squid

sudo tail -f /var/log/squid/access.log

Segurança: o LDAP na porta 389 trafega a senha sem criptografia. Dentro de um laboratório isolado isso é aceitável; em produção, use LDAPS (636) ou a autenticação Kerberos/NTLM.

11. Passo 9: lançar o cliente Windows e ingressar no domínio

Lance uma instância Windows Server (t3.small) na sn-clientes, sem IP público, IP privado 10.0.2.206 e sg-clientes.
Para acessar por RDP sem expor a porta à internet, crie um túnel SSH pelo firewall:

1
ssh -i chave.pem -L 3389:10.0.2.206:3389 ubuntu@IP_ELASTICO

Depois abra o cliente RDP em localhost:3389. A senha de Administrador vem do console (Connect > RDP client > Get password, com o arquivo .pem). 3. No Windows, confirme que o DNS aponta para 10.0.4.154 (automático se você usou o DHCP options set do passo 8.6). 4. Ingresse no domínio em Configurações > Sistema > Sobre > Domínio ou grupo de trabalho, informando tpm.intra e uma credencial com permissão, como administrator. Reinicie. 5. Entre com um usuário do domínio, por exemplo TPM\ana.rh.

Forçar o uso do proxy por política de grupo

Para que os usuários do setor administrativo naveguem apenas pelo proxy corporativo, use uma GPO com a configuração de proxy do navegador apontando para 10.0.1.72:3128. Para editar GPOs em um domínio Samba, instale o RSAT (Group Policy Management) no cliente Windows e abra o gpmc.msc conectado a tpm.intra. Combinado com o sg-clientes (que só libera saída para o firewall na 3128), o desvio do proxy deixa de funcionar.

12. Passo 10: testes de validação

Teste	Comando	Resultado esperado
Resolução do domínio	`ping tpm.intra`	Respostas do servidor central
Conectividade com o firewall	`ping 10.0.1.72`	100% de pacotes recebidos
Roteamento	`tracert tpm.intra`	Rota pelos saltos internos da VPC até o servidor
Intranet	abrir `10.0.4.154` no navegador	Página da intranet
Autenticação do AD	`samba-tool user list`	Lista de usuários do domínio
Proxy e filtro	acessar um domínio bloqueado	Acesso negado e registro no `access.log`
Saída pela NAT	`curl -I https://aws.amazon.com` a partir do servidor	Resposta HTTP

Se o ping falhar, revise primeiro os Security Groups (ICMP), as tabelas de rota e a verificação de origem/destino do firewall. Essas são as causas mais comuns.

13. Segurança e boas práticas

Security Groups enxutos: SSH restrito ao seu IP, apenas HTTP e DNS onde forem necessários, e nada aberto para 0.0.0.0/0 além do estritamente preciso.
Auditoria: acompanhe o proxy com sudo tail -f /var/log/squid/access.log e revise os usuários com samba-tool user list.
Sem IP público nas máquinas internas: apenas o firewall é exposto.
Senhas e chaves: troque as senhas de exemplo, proteja o arquivo .pem e evite deixar credenciais em arquivos de configuração acessíveis.
Backups: faça snapshots dos volumes EBC do servidor central, que guarda o banco do AD.
Alta disponibilidade: em produção, considere um segundo controlador de domínio e um firewall redundante, já que o firewall atual é um ponto único de falha.
Alternativas gerenciadas: para ambientes maiores, a AWS oferece NAT Gateway e AWS Directory Service, que reduzem a manutenção, com custo adicional.

14. Custos e limpeza

Instâncias EC2, Elastic IPs e volumes geram cobrança. Ao terminar o laboratório, pare ou encerre as instâncias, libere o Elastic IP e apague volumes e snapshots que não vai usar. Confira sempre os valores e os limites do nível gratuito vigentes na sua conta.

15. Conclusão

A segmentação por sub-redes, o firewall centralizando NAT e proxy, a autenticação única com Samba 4 e a intranet em Apache formam uma base sólida para uma rede corporativa na nuvem. O resultado é organizado, seguro e fácil de expandir: novos setores viram novas sub-redes, e as regras ficam concentradas em poucos pontos.

# amazon-ec2 # network

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Como montar uma rede empresarial na AWS com instâncias EC2

Rober122

1. Introdução

2. Arquitetura da solução

Plano de endereçamento

Equipamentos

3. Passo 1: criar a VPC

4. Passo 2: criar as sub-redes

5. Passo 3: Internet Gateway e tabelas de rota

6. Passo 4: criar os Security Groups

7. Passo 5: lançar e configurar o firewall (NAT)

7.1 Lançar a instância

7.2 Habilitar encaminhamento e NAT

7.3 Apontar as sub-redes privadas para o firewall

8. Passo 6: lançar o servidor central e provisionar o Active Directory

8.1 Lançar a instância

8.2 Preparar o sistema

8.3 Provisionar o domínio tpm.intra

8.4 Verificar o domínio

8.5 Criar usuários e grupos

8.6 Fazer a VPC usar o DNS do domínio

9. Passo 7: publicar a intranet com Apache

10. Passo 8: configurar o proxy Squid no firewall

11. Passo 9: lançar o cliente Windows e ingressar no domínio

Forçar o uso do proxy por política de grupo

12. Passo 10: testes de validação

13. Segurança e boas práticas

14. Custos e limpeza

15. Conclusão

8.3 Provisionar o domínio `tpm.intra`