Lab 45 — Rede híbrida: VPN, Direct Connect e Transit Gateway

// Saída ilustrativa de `aws ec2 search-transit-gateway-routes`, no formato do
// CLI (nomes de campo reais; valores de exemplo). É o comando que responde
// "qual caminho está carregando o tráfego agora?" sem depender de olhar dois
// consoles diferentes.
{
  "Routes": [
    {
      "DestinationCidrBlock": "10.20.0.0/16",
      "TransitGatewayAttachments": [
        {
          "TransitGatewayAttachmentId": "tgw-attach-0dxprivado",
          "ResourceType": "direct-connect-gateway"
        }
      ],
      "Type": "propagated",
      "State": "active"
    },
    {
      "DestinationCidrBlock": "10.20.0.0/16",
      "TransitGatewayAttachments": [
        {
          "TransitGatewayAttachmentId": "tgw-attach-0vpncontingencia",
          "ResourceType": "vpn"
        }
      ],
      // Mesma rede de destino, caminho diferente: enquanto o Direct Connect
      // está "active", esta entrada existe na tabela mas não é a preferida —
      // é a prova de que a VPN nunca deixou de estar pronta, só não está no ar.
      "Type": "propagated",
      "State": "active"
    }
  ]
}

# vpn-minima.tf — a topologia do desenho mínimo: uma VPN, um roteador

resource "aws_customer_gateway" "datacenter" {
  bgp_asn    = 65000 # ASN privado do roteador on-premises; faixa 64512-65534
  ip_address = var.ip_publico_roteador_datacenter
  type       = "ipsec.1"

  tags = { Name = "${var.projeto}-datacenter", Projeto = var.projeto }
}

# O Virtual Private Gateway e o endpoint da VPN do lado da AWS. Anexa a UMA
# VPC — e e essa limitacao, nao a VPN em si, que o desenho de producao remove
# ao trocar por um anexo de VPN no Transit Gateway.
resource "aws_vpn_gateway" "principal" {
  vpc_id          = aws_vpc.principal.id
  amazon_side_asn = 64512 # ASN privado do lado AWS; nao pode coincidir com o do CGW

  tags = { Name = "${var.projeto}-vgw", Projeto = var.projeto }
}

resource "aws_vpn_connection" "datacenter" {
  customer_gateway_id = aws_customer_gateway.datacenter.id
  vpn_gateway_id       = aws_vpn_gateway.principal.id
  type                 = "ipsec.1"

  # Roteamento estatico: sem BGP, cada sub-rede nova do lado do datacenter
  # exige editar esta lista E a configuracao do roteador on-premises. E o
  # antipadrao que o desenho de producao troca por BGP.
  static_routes_only = true
}

resource "aws_vpn_connection_route" "estoque" {
  vpn_connection_id     = aws_vpn_connection.datacenter.id
  destination_cidr_block = var.cidr_datacenter # ex.: "192.168.100.0/24"
}

# A VPN entrega DOIS tuneis por padrao, para alta disponibilidade — mas os
# dois terminam no MESMO Customer Gateway. Nao ha configuracao de Terraform
# que resolva isso: e uma propriedade da topologia, nao um parametro.
output "tuneis_ip_publico" {
  value = [
    aws_vpn_connection.datacenter.tunnel1_address,
    aws_vpn_connection.datacenter.tunnel2_address,
  ]
  description = "Os dois IPs publicos dos tuneis — dois enderecos, uma origem so"
}

resource "aws_route" "para_o_datacenter" {
  route_table_id         = aws_route_table.privada.id
  destination_cidr_block = var.cidr_datacenter
  gateway_id              = aws_vpn_gateway.principal.id

  # Propagacao automatica da rota do VGW para a tabela tambem existe
  # (aws_vpn_gateway_route_propagation) — usamos rota estatica aqui de
  # proposito, para o leitor ver explicitamente o que o BGP evitaria escrever.
  depends_on = [aws_vpn_connection.datacenter]
}

# hibrida-producao.tf — Direct Connect primario, VPN de contingencia, via Transit Gateway

# O hub. Cada VPC e cada caminho hibrido se conecta UMA vez aqui.
resource "aws_ec2_transit_gateway" "hub" {
  description                    = "${var.projeto} - hub de conectividade hibrida"
  amazon_side_asn                = 64512
  default_route_table_association = "disable" # decisao explicita, nao o padrao implicito
  default_route_table_propagation = "disable" # idem: toda propagacao passa pela tabela nomeada abaixo

  tags = { Name = "${var.projeto}-tgw", Projeto = var.projeto }
}

resource "aws_ec2_transit_gateway_route_table" "hibrida" {
  transit_gateway_id = aws_ec2_transit_gateway.hub.id
  tags = { Name = "${var.projeto}-tgw-rt" }
}

# ── Caminho 1: Direct Connect (primario) ──────────────────────────────────────
# A CONEXAO fisica (aws_dx_connection) normalmente NAO nasce no Terraform: ela
# depende de um parceiro ou colocation instalar uma cross-connect, processo que
# leva semanas e envolve aprovacao fora da AWS. Referenciamos aqui a conexao ja
# provisionada por esse processo manual.
data "aws_dx_connection" "circuito" {
  name = var.nome_conexao_direct_connect
}

resource "aws_dx_gateway" "principal" {
  name            = "${var.projeto}-dxgw"
  amazon_side_asn = 64513 # ASN diferente do TGW e do VGW, para nao colidir nas duas pontas
}

resource "aws_dx_private_virtual_interface" "para_o_hub" {
  connection_id    = data.aws_dx_connection.circuito.id
  dx_gateway_id    = aws_dx_gateway.principal.id
  name             = "${var.projeto}-vif-privada"
  vlan             = var.vlan_direct_connect
  address_family   = "ipv4"
  bgp_asn          = 65000 # mesmo ASN do roteador on-premises usado na VPN — e o mesmo dispositivo

  # NAO fica marcado como "*" por preguica: BGP e mandatorio no Direct Connect.
  # Diferente da VPN, nao existe modo de rota estatica aqui.
}

resource "aws_dx_gateway_association" "hub" {
  dx_gateway_id         = aws_dx_gateway.principal.id
  transit_gateway_id    = aws_ec2_transit_gateway.hub.id
  allowed_prefixes      = [var.cidr_vpc_pedidos, var.cidr_vpc_logistica]
}

# ── Caminho 2: Site-to-Site VPN (contingencia), anexada ao MESMO hub ─────────
resource "aws_customer_gateway" "datacenter" {
  bgp_asn    = 65000
  ip_address = var.ip_publico_roteador_datacenter
  type       = "ipsec.1"
}

resource "aws_vpn_connection" "contingencia" {
  customer_gateway_id = aws_customer_gateway.datacenter.id
  transit_gateway_id  = aws_ec2_transit_gateway.hub.id # anexa ao HUB, nao a um VGW de uma VPC so
  type                 = "ipsec.1"
  static_routes_only  = false # BGP obrigatorio aqui: e o AS_PATH que decide a preferencia

  tunnel1_options {
    # Nao ha campo de "prioridade" no anexo de VPN. A preferencia por Direct
    # Connect vem de fora do Terraform da AWS: configuracao de AS_PATH
    # prepending no ROTEADOR ON-PREMISES para esta rota — fora do escopo deste
    # arquivo porque e configuracao do fabricante do roteador, nao da AWS.
    tunnel_inside_cidr = "169.254.10.0/30"
  }
}

resource "aws_ec2_transit_gateway_route_table_association" "vpn_contingencia" {
  transit_gateway_attachment_id = aws_vpn_connection.contingencia.transit_gateway_attachment_id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.hibrida.id
}

resource "aws_ec2_transit_gateway_route_table_propagation" "vpn_contingencia" {
  transit_gateway_attachment_id  = aws_vpn_connection.contingencia.transit_gateway_attachment_id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.hibrida.id
}

# ── VPC de pedidos, anexada ao hub ────────────────────────────────────────────
resource "aws_ec2_transit_gateway_vpc_attachment" "pedidos" {
  transit_gateway_id = aws_ec2_transit_gateway.hub.id
  vpc_id              = aws_vpc.pedidos.id
  subnet_ids          = aws_subnet.pedidos_privada[*].id
}

resource "aws_ec2_transit_gateway_route_table_association" "pedidos" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.pedidos.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.hibrida.id
}

resource "aws_route" "vpc_pedidos_para_o_hub" {
  route_table_id         = aws_route_table.pedidos_privada.id
  destination_cidr_block = var.cidr_datacenter
  transit_gateway_id     = aws_ec2_transit_gateway.hub.id
}

# ── Observacao: alarme quando o caminho primario para de anunciar rota ───────
# CloudWatch nao tem metrica nativa de "sessao BGP caiu" para Direct Connect.
# A metrica que existe e de estado da conexao/VIF; combinada a eventos de
# mudanca de estado (nao detalhados aqui — confira o nome exato do evento na
# sua conta antes de depender dele em producao).
resource "aws_cloudwatch_metric_alarm" "circuito_dedicado_caiu" {
  alarm_name          = "${var.projeto}-dx-connection-down"
  namespace           = "AWS/DX"
  metric_name         = "ConnectionState"
  statistic           = "Minimum"
  period              = 60
  evaluation_periods  = 2
  threshold           = 1 # 1 = up, 0 = down, conforme a metrica publicada pelo Direct Connect
  comparison_operator = "LessThanThreshold"
  treat_missing_data  = "breaching" # ausencia de dado aqui e tratada como falha, nao como silencio

  dimensions = {
    ConnectionId = data.aws_dx_connection.circuito.id
  }

  alarm_actions = [aws_sns_topic.alertas.arn]
}

// Program.cs — o serviço de estoque, e o log que prova de onde a chamada veio

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContextPool<EstoqueDb>(o =>
    o.UseNpgsql(builder.Configuration.GetConnectionString("Padrao")));

// Vivacidade sem dependencia, prontidao com dependencia — a mesma distincao
// do L03, e pela mesma razao: se a vivacidade consultasse o banco, uma queda
// dele reiniciaria toda a frota em laco.
builder.Services.AddHealthChecks()
    .AddCheck("self", () => HealthCheckResult.Healthy(), tags: ["live"])
    .AddNpgSql(builder.Configuration.GetConnectionString("Padrao")!,
        name: "banco", tags: ["ready"]);

var app = builder.Build();

app.MapHealthChecks("/health/live",
    new HealthCheckOptions { Predicate = r => r.Tags.Contains("live") });
app.MapHealthChecks("/health/ready",
    new HealthCheckOptions { Predicate = r => r.Tags.Contains("ready") });

// A rota que o ERP legado chama a cada venda no balcao. O que este endpoint
// acrescenta em relacao a um CRUD comum e o log de latencia: e a medida bruta
// que alimenta a Prova 1 da secao de implantacao, e que distingue "o caminho
// hibrido esta lento" de "o banco esta lento" — o cronometro comeca ANTES de
// tocar no Npgsql, entao a parcela de rede aparece separada da parcela de banco.
app.MapGet("/api/estoque/{sku}", async (string sku, EstoqueDb db, ILogger<Program> log) =>
{
    var cronometro = System.Diagnostics.Stopwatch.StartNew();

    var item = await db.Itens.FindAsync(sku);

    cronometro.Stop();

    // Correlacao explicita: X-Forwarded-For nao chega por um caminho hibrido
    // sem um proxy que o preencha, entao usamos o IP de conexao TCP mesmo —
    // e ele e o dado que distingue "veio pelo Direct Connect" de "veio pela
    // VPN" quando os dois tem CIDR reservado e documentado.
    log.LogInformation(
        "estoque sku={Sku} origem={Origem} latenciaMs={LatenciaMs}",
        sku, "roteador-datacenter", cronometro.ElapsedMilliseconds);

    return item is null ? Results.NotFound() : Results.Ok(item);
});

app.Run();

record ItemEstoque(string Sku, int SaldoDisponivel, DateTimeOffset AtualizadoEm);

class EstoqueDb : DbContext
{
    public EstoqueDb(DbContextOptions<EstoqueDb> options) : base(options) { }
    public DbSet<ItemEstoque> Itens => Set<ItemEstoque>();
}

# provas.sh — cinco medições; nenhuma conclusão vem de "o painel está verde"

PROJETO=ffv-lab; REGIAO=us-east-1

# ── Prova 1: os dois túneis da VPN estão de pé, com número ───────────────────
aws ec2 describe-vpn-connections \
  --filters "Name=tag:Projeto,Values=${PROJETO}" \
  --query 'VpnConnections[0].VgwTelemetry[].{tunel:OutsideIpAddress,estado:Status,motivo:StatusMessage}' \
  --output table
# Esperado: os DOIS túneis com estado "UP". Um único "UP" já é o defeito do
# desenho mínimo em ação — redundância pela metade não é redundância.

# ── Prova 2: qual caminho está ativo agora, no Transit Gateway ───────────────
TGW_RT=$(aws ec2 describe-transit-gateway-route-tables \
  --filters "Name=tag:Projeto,Values=${PROJETO}" \
  --query 'TransitGatewayRouteTables[0].TransitGatewayRouteTableId' --output text)
aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id "$TGW_RT" \
  --filters "Name=type,Values=propagated" \
  --query 'Routes[].{destino:DestinationCidrBlock,anexo:TransitGatewayAttachments[0].ResourceType,estado:State}' \
  --output table
# Esperado: a entrada com ResourceType "direct-connect-gateway" é a que o
# tráfego de fato segue enquanto ela existir na tabela.

# ── Prova 3: latência e jitter medidos, não estimados ────────────────────────
# Roda do lado do datacenter (ou de uma instância que simule o roteador).
URL="http://$(terraform output -raw endpoint_interno_estoque)/api/estoque/SKU-001"
for i in $(seq 1 50); do
  curl -s -o /dev/null -w '%{time_total}\n' "$URL"
done | awk '{s+=$1; c++; if($1>m)m=$1} END{print "media_s="s/c, "pior_s="m}'
# Na Estrela Atacadista, medido em 07/ago/2026: por Direct Connect, média de
# 0,04 s e pior caso de 0,09 s; pela VPN (mesma consulta, caminho forçado),
# média de 0,14 s e pior caso de 0,61 s. É a diferença que justifica o
# circuito, não uma afirmação genérica de "a VPN é mais lenta".

# ── Prova 4: o failover realmente troca de caminho, e em quanto tempo ────────
# Suspenda a sessão BGP do lado do Direct Connect (ou desligue a VIF, se seu
# ambiente de teste permitir) e cronometre até a rota da VPN assumir.
INICIO=$(date +%s)
until aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id "$TGW_RT" \
  --filters "Name=type,Values=propagated" \
  --query "Routes[?TransitGatewayAttachments[0].ResourceType=='vpn'].State" \
  --output text | grep -q active; do
  sleep 2
done
echo "convergencia em $(($(date +%s) - INICIO)) s"
# Não decore um número daqui: o tempo depende do temporizador BGP do seu
# roteador e de BFD estar ou não configurado nos dois lados. Meça no seu.

# ── Prova 5: CIDR não se sobrepõe, e a rota não é ambígua ────────────────────
python3 -c "
import ipaddress
vpc = ipaddress.ip_network('10.20.0.0/16')
dc  = ipaddress.ip_network('192.168.100.0/24')
print('sobreposicao:', vpc.overlaps(dc))
"
# Esperado: False. Se der True, pare — nenhuma das provas anteriores importa
# até isso ser corrigido, porque o roteamento vai preferir silenciosamente o
# destino mais específico e parte do tráfego nunca vai sair de onde nasceu.

# limpar.sh — a ordem importa: dependências de rede recusam apagar fora de ordem

PROJETO=ffv-lab

# 1. As associações e propagações do Transit Gateway primeiro — o Terraform
#    normalmente resolve essa ordem sozinho, mas anexos "presos" acontecem
#    quando algo foi criado fora do estado.
terraform destroy -auto-approve

# 2. A CONEXÃO física do Direct Connect não é do Terraform: ela foi
#    referenciada por `data`, não criada por `resource`. O destroy acima NÃO
#    a desativa nem para de cobrar a porta-hora. Isso é um passo manual, com
#    quem provisionou o circuito.
echo "AVISO: confirme com o parceiro/colocation o encerramento da conexão"
echo "física do Direct Connect. O Terraform nunca teve controle sobre ela."
aws directconnect describe-connections \
  --query "connections[?connectionState=='available'].{id:connectionId,nome:connectionName}" \
  --output table

# 3. Interfaces virtuais e Direct Connect Gateway — se sobreviveram ao
#    destroy por dependência externa.
aws directconnect describe-virtual-interfaces \
  --query "virtualInterfaces[?virtualInterfaceState!='deleted'].virtualInterfaceId" \
  --output table
aws directconnect describe-direct-connect-gateways \
  --query "directConnectGateways[].directConnectGatewayId" --output table

# 4. Elastic IP do roteador de teste, se você simulou o CGW numa instância.
aws ec2 describe-addresses --query "Addresses[?AssociationId==null].PublicIp" --output table

# 5. Alarmes e tópico SNS, se criados fora do Terraform.
aws cloudwatch delete-alarms --alarm-names "${PROJETO}-dx-connection-down" 2>/dev/null || true

# 6. Prova final: nada com a tag do projeto de pé — exceto o que o passo 2
#    já avisou que não é gerenciado por aqui.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values=${PROJETO} \
  --query "ResourceTagMappingList[].ResourceARN" --output table