AWS Network: Sua intuição de Cisco pode te enganar na AWS
Artigo 1 da série: traduzindo o que você já sabe de rede pra AWS.
Series: AWS Network (3 articles)
- 1AWS Network: Sua intuição de Cisco pode te enganar na AWS This article
O problema que ninguém te avisa
Você passou anos configurando Catalyst, Nexus, ISR, e talvez para os mais antigos como eu uns 7200. Sabe de cabeça o que uma ACL faz, a quantidade de hosts em um /21, a relação que uma vlan tem com uma sub-interface, e até os detalhes escondidos na tabela de rotas do
show ip route. Ai entra na console da AWS pela primeira vez para montar (ou olhar) uma tal de VPC, e logo vem aquela sensação estranha, pois parece familiar (tem roteamento, tem subnet, tem até BGP), mas nada parece bater 100% com o que você conhece.O erro mais comum que vejo o cisco-boy cometer (assim como foi o que eu cometi) não é achar que a AWS é totalmente diferente, é achar que é igual o suficiente, para não precisar checar os detalhes, e foi esse ponto cego que me pegou na grande maioria das vezes.
Esse artigo não é um glossário Cisco-AWS. É um mapa que criei para tentar fazer correlações, para que toda a minha experiencia com redes fosse absorvida melhor na AWS.
Nivelando o jogo
Não da para falar de VPC/Networking sem entender (mesmo que superficial), algumas coisinhas que rolam 'por baixo' na AWS. Aqui é mais para todos ficarem na mesma página, pois não é a parte que importa no dia-a-dia de tshoot, mas explica por que as regras do jogo mudaram.
- Não existe camada 2 tradicional. Nada de STP (glória a Deus), nada de broadcast de ARP inundando a rede, nada de trunk 802.1Q. A rede física da AWS (o underlay), é roteada em layer3 desde a base, rodando sobre uma topologia spine-leaf sem bloqueio de caminho, o que é um dos componentes que garantem a escala de milhões de instâncias. No video de referencia o mestre Gustavo Santana explica detalhadamente sobre isso:
- O AWS Nitro System é quem faz o trabalho pesado. Esqueça a ideia de hypervisor de software tradicional processando pacote via CPU (como a VMWare ou o Hyper-V). O Nitro é um hardware dedicado (placas PCIe customizadas) que assume o processamento de rede, criptografia e avaliação do Security Group totalmente fora da CPU do host/instância. É por isso que em uma EC2 moderna entrega throughput de rede maior, podendo chegar a 600Gpbs em nitros otimizadas. Ali Saidi e Filippo Sironi explicam isso em:
- Não existe 'aprendizado' do caminho via protocolo dinâmico (não do jeito que imagina). Vou te dizer que isso me pegou na primeira vez que li. Achava que a AWS usaria um ISIS, ou um BGP para comunicação entre instancias. Contudo a placa Nitro de origem consulta em um banco de dados distribuído chamado Mapping Service: "Em qual host físico esta o IP virtual de destino?". Depois que recebe a resposta, encapsula o pacote lógico dentro de um pacote físico de underlay, despacha via unicast pela malha spine-leaf.
Inclusive existe um serviço interno na AWS chamado AWS Hyperplane usado em em serviços como nat gateway, NLB e PrivateLink que faz algo meio 'estranho' para um cara de redes: ele é capaz de conectar duas redes com CIDR iguais, abstraindo NATs no meio do caminho. (https://ngoyal16.medium.com/the-invisible-engine-how-aws-hyperplane-powers-privatelink-147c490d2ea9 )
(aqui se voce quer ativar o modo escovador de bit, e entender a fundo como o isolamento de tenant no hardware funciona, no re:Invent de 2025 teve uma sessão exclusiva para falar de como é realizado a verificação de forma matematica (via Isabelle/HOL) nas instâncias graviton5. Se as vezes voce precisa ligar o lado mais nerd/curioso como eu, vale assistir: https://www.youtube.com/watch?v=hqqKi3E-oG8&t=3s ).
Por fim, o que preciso que guarde aqui é: roteamento na AWS não é descoberto, é declarado. Isso vai ser o fio condutor de quase toda quebra de intuição daqui para frente.
Equivalências
Agora vamos para uma tabela de referencias rápidas. Veja que são equivalências, ou seja, a ideia é tentar deixar os conceitos que o cara de redes já tem familiaridade para absorver as coisas na AWS de forma mais rápida.
| Conceito AWS | Equivalênte Cisco | Onde a equivalência pode te pegar |
|---|---|---|
| Amazon VPC | VRF + Isolamento VDC (Nexus) | Fronteira é regional. Não Existe essa de uma VPC para America do Norte e Sul. Mesmo sendo totalmente possivel se pensarmos em VXLAN com L3VNI. |
| Subnet | VLAN + SVI L3 | Subnet é presa a uma única AZ, e não em broadcast ou ARP. Tudo é unicast controlado pelo hypervisor (SDN). |
| Route table | PBR + LPM | Rota local implícita e imutável. Sem roteamento dinamico por padrão, a rtb serve para voce declarar quem é o next-hop. Na prática ela não é uma PBR, pois escolhe rotas baseado em prefixos, mas também não cria uma tabela de roteamento isolada (veremos isso no lab). Algo bem importante: o route-table que você ve aqui é a FIB, e não a RIB. |
| Security Group | firewall statefull (zone-based) | SG Referencing: regra aponta para outro SG por ID, não por IP. |
| Network ACL | ACL stateless | sem pegadinha. Aqui é ACL raiz de verdade. |
| Route 53 / VPC Resolver | DNS padrão + forwarders | sem pegadinhas tbm. Aliais Route 53, sem sombra de dúvida é o melhor serviço da AWS. |
| Application Load Balancer | F5 BigIP, ou o finado Cisco ACE | A ideia é não ter limites, então as mágicas que se fazia com iRule, ou mesmo os limites de quantidade de sessões nos pools não existia (até o reInvent de 2025, quando o Target Optimizer foi lançado). |
| Cloud WAN "Segment" | VRF + MPLS + RD/RT | Não confundir com Segment Routing. A AWS deixa claro que aqui o "segment" é uma VRF mesmo. |
| Hyperplane | Sem equivalencia. Talvez o ASIC | Não confundir o Cisco APIC com AWS Hyperplane. O primeiro trabalha no ControlPlane, e o segundo no DataPlane. Por isso as placas ASICs podem ter uma equivalencia um pouco melhor (mesmo que na prática quem acabe fazendo isso sejam as placas Nitro) |
| VPC Lattice | Sem equivalente direto | Denso demais para uma linha. Merece um artigo só dele |
Deep-dives que não caberiam em uma tabela
VPC e Subnets
Correlacionar a VPC com uma topologia VXLAN EVPN Multi-Site (ou um fabric nexus para os mais antigos) funciona como analogia de isolamento, mas lembre-se sempre que VPC carrega implicações geográficas, o que em teoria uma VRF ou L3VNI podem não ter.
Outro ponto importante: Se para você, ter redundancia é garantir virtual PortChannel em switches fisicos diferentes com varios servidores espalhados, esqueça. Na AWS a primeira camada de redundácia é ter subnetes diferentes, pois significam na prática que são datacenter diferentes.
Route-tables
Sim não existe protocolo dinamico aqui, nada de OSPF, ISIS ou EIGRP, mas para consolo a decisão usada é o Longest Prefix Match. Na prática, se você esquece de colocar a rota default para sair pelo Nat, o caminho não vai funcionar, e ja adianto algo que me fez MUITA falta: O 'show ip route' é um comando dificil de decorar, e em uma rede grande fica quase inviável de se utilizar.
Utilizo a PBR como equivalencia aqui e não a VRF, pois a VPC esta mais para a VRF, uma vez que voce pode ter multiplas route-tables na VPC, multiplas subnetes, e apenas com o roteamento local, garantir que duas subnetes diferentes se comuniquem. Imagine aqui que a subnet é uma interface vlan em um switch-core, mas nela voce tem uma PBR (route-table) para definir o next-hop baseado na origem do trafego.
(ativando o modo escovador de bit novamente para uma curiosidade. Quando voce ativa um gateway endpoint do S3 ou do DyanamoDB, a AWS injeta automaticamente rotas baseadas em prefix-list direto na route-table, desviando o trafego para o backbone privado. É o equivalente técnico da rota estática especifica para desviar trafego.)
ALB
Até nov/25 o conceito do ALB era não ter limite para encaminhamento de conexão. Ou seja, se usava o round robin ou least request (e não connections) para decidir para qual servidor do target a conexão iria. Com o lançamento do target optimizer essa 'limitação' começou a existir, contudo ainda não é no ALB e sim (como o nome sugere) no target.
Na prática, é instalado um agente no destino, e ele fala com ALB por uma control port informando o tempo e capacidade que ele possui, e o ALB usa disso para limitar a conexão.
O importante aqui para lembrar é: Ainda não tem equivalencia para o 'connection limits' do BigIP. Então se sua aplicação não esta preparada para isso, refature antes de levar para AWS.
VPC Lattice
Aqui até pensei que inicialmente poderia fazer o paralelo entre o VPC Lattice e o Cisco Service Mesh ou até com o IBN. Mas o primeiro o foco é abstração, o segundo uma extenção do Istio e o ultimo esta mais para uma filosofia. Então o máximo que vou conseguir fazer aqui é dizer que pense no VPC Lattice como uma abstração total do roteamento, e falamos melhor sobre ele em um artigo exclusivo.
O show ip route da AWS
Agora vamos falar do comando predileto do analista de redes, juntando as peças até agora.
- VPC é de escopo regional, então antes de qualquer coisa garanta que esta na região correta;
- Ja está na região correta, e quer ver a 'tabela de rotas' completa (o que faria com um show ip route).
Aqui é igual Cisco mesmo. Como cada tabela de rotas é uma VRF, então ou voce da um show ip route vrf <[vrf]> para cada uma ou um show ip route vrf */all. Na AWS o comando é mais intragável:aws ec2 describe-route-tables --query "RouteTables[``].{RouteTableId: RouteTableId, VpcId: VpcId, Name: Tags[?Key=='Name'].Value[0], Routes: Routes[``].{Destination: DestinationCidrBlock, Target: GatewayId || TransitGatewayId || NatGatewayId || VpcPeeringConnectionId || InstanceId || LocalGatewayId, State: State}}" --output table
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
awscommunitybuilder $ aws ec2 describe-route-tables --query "RouteTables[*].{RouteTableId: RouteTableId, VpcId: VpcId, Name: Tags[?Key=='Name'].Value[0], Routes: Routes[*].{Destination: DestinationCidrBlock, Target: GatewayId || TransitGatewayId || NatGatewayId || VpcPeeringConnectionId || InstanceId || LocalGatewayId, State: State}}" --output table
------------------------------------------------------
| DescribeRouteTables |
+-------------------------+--------------------------+
| RouteTableId | VpcId |
+-------------------------+--------------------------+
| rtb-0bd81ffd5d64586ec | vpc-0723f3eac9e93f538 |
+-------------------------+--------------------------+
|| Routes ||
|+--------------------+--------------+--------------+|
|| Destination | State | Target ||
|+--------------------+--------------+--------------+|
|| 10.0.0.0/16 | active | local ||
|+--------------------+--------------+--------------+|
| DescribeRouteTables |
+-------------------------+--------------------------+
| RouteTableId | VpcId |
+-------------------------+--------------------------+
| rtb-0fa28d4f8ac142f35 | vpc-0723f3eac9e93f538 |
+-------------------------+--------------------------+
|| Routes ||
|+--------------+---------+-------------------------+|
|| Destination | State | Target ||
|+--------------+---------+-------------------------+|
|| 10.0.0.0/16 | active | local ||
|| 0.0.0.0/0 | active | igw-0dcda5a2bd336c5c6 ||
|+--------------+---------+-------------------------+|
awscommunitybuilder $ - e também gosto da versão com o 'nome' da tabela de roteamento:
aws ec2 describe-route-tables --output json | jq -r '.RouteTables[] | .RouteTableId as $id | (.Tags[]? | select(.Key=="Name") | .Value) as $name | .VpcId as $vpc | .Routes[] | "($id)\t($name)\t($vpc)\t(.DestinationCidrBlock)\t(.GatewayId // .TransitGatewayId // .NatGatewayId // .VpcPeeringConnectionId // .InstanceId // "local")\t(.State)"' | column -t -s $'\t' | sed '1i RTB_ID NAME VPC_ID DESTINATION TARGET STATE'
1
2
3
4
5
6
awscommunitybuilder $ aws ec2 describe-route-tables --output json | jq -r '.RouteTables[] | .RouteTableId as $id | (.Tags[]? | select(.Key=="Name") | .Value) as $name | .VpcId as $vpc | .Routes[] | "\($id)\t\($name)\t\($vpc)\t\(.DestinationCidrBlock)\t\(.GatewayId // .TransitGatewayId // .NatGatewayId // .VpcPeeringConnectionId // .InstanceId // "local")\t\(.State)"' | column -t -s $'\t' | sed '1i RTB_ID NAME VPC_ID DESTINATION TARGET STATE'
RTB_ID NAME VPC_ID DESTINATION TARGET STATE
rtb-0bd81ffd5d64586ec network-fundamentals-private-rt vpc-0723f3eac9e93f538 10.0.0.0/16 local active
rtb-0fa28d4f8ac142f35 network-fundamentals-public-rt vpc-0723f3eac9e93f538 10.0.0.0/16 local active
rtb-0fa28d4f8ac142f35 network-fundamentals-public-rt vpc-0723f3eac9e93f538 0.0.0.0/0 igw-0dcda5a2bd336c5c6 active
awscommunitybuilder $- A leitura é basicamente a mesma: para alcançar a rede 10.0.0.0/16 a interface de saida é a local.
Laboratório
Aqui vamos fazer montar a base do que será o laboratório para os próximos artigos. O cloudFormation vai criar uma VPC, duas route-tables, duas subnets, duas instancias na rede publica e uma na rede privada (ja com os pacotes de tcpdump, ping e telnet instalados).
A ideia é mais apresentar como o roteamento é visto na AWS.
- Faça o git clone e rode os cloudFormations:
1
2
3
4
5
6
7
8
9
10
11
12
13
git clone https://github.com/thiagosagara/awscommunitybuilder.git
cd awscommunitybuilder
aws cloudformation deploy \
--template-file "AWS Network/basic/vpc-base.yaml" \
--stack-name network-fundamentals-vpc \
--parameter-overrides ProjectPrefix=network-fundamentals
aws cloudformation deploy \
--template-file "AWS Network/basic/network-tools-instances.yaml" \
--stack-name network-fundamentals-tools \
--parameter-overrides ProjectPrefix=network-fundamentals \
--capabilities CAPABILITY_IAM- Como comentei a rtb é similar a uma PBR (e não uma VRF) por isso conseguimos ter conectividade entre vlans publicas e privadas por default.
- Agora vamos criar uma interface de loopback na instancia publica-b, para mostrar o comportamento do roteamento na AWS:
1
2
3
4
5
6
7
#Criando interface de loopback
sudo ip addr add 172.26.10.100/32 dev lo
sudo sysctl -w net.ipv4.ip_forward=1
sudo bash -c "echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-ip-forward.conf"
#habilitando o tcpdump:
sudo tcpdump -i any host 172.26.10.100 -nn &- observação: para o laboratório funcionar é preciso desabilitar o source/destination check na instancia publica-b:
- Agora quando executamos o ping 172.26.10.100 (e com o tcpdump (mesmo comando)) na instancia publica-a, notaremos que a comunicação não é concluida:
[ssm-user@ip-10-0-1-167 bin]$ ping 172.26.10.100PING 172.26.10.100 (172.26.10.100) 56(84) bytes of data.01:58:02.144363 ens5 Out IP 10.0.1.167 > 172.26.10.100: ICMP echo request, id 38715, seq 1, length 6401:58:03.202312 ens5 Out IP 10.0.1.167 > 172.26.10.100: ICMP echo request, id 38715, seq 2, length 6401:58:04.242365 ens5 Out IP 10.0.1.167 > 172.26.10.100: ICMP echo request, id 38715, seq 3, length 64 - Obviamente aqui falta rota, que colocamos com um simples:
sudo ip route add 172.26.0.0/16 via 10.0.1.237 - Como não queremos (e nem é escalável) colocar rota manualmente para tudo, basta adicionar a rota na route-table publica (e deletar a rota estática da instancia publica-a (sudo ip route del 172.26.0.0/16):
1
2
3
4
aws ec2 create-route \
--route-table-id rtb-049e28869ba16b8ff \
--destination-cidr-block 172.26.0.0/16 \
--instance-id i-0866fb5a8bdc93648O que precisa estar claro para você aqui é que os conceitos de redes não mudaram, contudo se você imaginar a rede AWS como uma rede Cisco, vai se confundir e pode atrasar a sua curva de absorção da estrutura.
Conclusão
Se o seu problema é troubleshoot de latência entre AZs, comportamento de BGP em Direct Connect, ou desenho de arquitetura multi-conta com Transit Gateway, esse artigo não é suficiente. Ele te dá vocabulário e os pontos de quebra mais comuns, não profundidade operacional.
Pra isso, os próximos artigos desta série resolvem: um deles vamos pegar um packet walk completo (do request HTTPS até o RDS, atravessando IGW, ALB, NACL, SG, Route Table) e transformar em metodologia de troubleshoot passo a passo. Depois disso, a série de BGP na AWS aprofunda o que acontece quando você sai do mundo de rota estática declarada e entra em roteamento dinâmico de verdade com Direct Connect e VPN.
Sua intuição de rede não está errada. Ela só foi treinada num mundo onde o caminho era descoberto por protocolo, e as vezes até por pacote. Na AWS, o caminho é declarado por você, e essa é a mudança de modelo mental que separa quem só sobe uma VPC de quem realmente sabe operar rede em produção na nuvem.
Series: AWS Network (3 articles)
- 1AWS Network: Sua intuição de Cisco pode te enganar na AWS This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article