Lab 02 — A rede por baixo: por que o banco não tem rota para a internet

{
  "version": 2,
  "account-id": "111122223333",
  "interface-id": "eni-0abc1234def567890",
  "srcaddr": "203.0.113.47",
  "dstaddr": "10.0.32.14",
  "srcport": 54321,
  "dstport": 5432,
  "protocol": 6,
  "packets": 1,
  "bytes": 44,
  "start": 1754524800,
  "end": 1754524860,
  "action": "REJECT",
  "log-status": "OK"
}

lab02-rede/
├── rede.tf          # VPC, sub-redes, IGW, NAT, tabelas de rotas
├── banco.tf         # RDS sem endereço público
├── ecs.tf           # serviço nas sub-redes privadas
├── variaveis.tf     # região, CIDR base, quantidade de NAT
├── saidas.tf        # ids que os outros arquivos e os testes consomem
└── README.md        # o plano de endereçamento, por escrito

# Plano de endereçamento: /16 na VPC, /20 por sub-rede, /18 reservado.
# A escolha está no README porque quem lê o Terraform daqui a um ano precisa saber
# o que NÃO usar, e isso não está em nenhuma linha de código.

locals {
  azs = ["${var.regiao}a", "${var.regiao}b"]

  # Índices fixos, não calculados a partir de `count`. Reordenar a lista de AZs
  # com CIDR derivado do índice REATRIBUI sub-rede existente — o plano do
  # Terraform mostra destroy/create de sub-rede com recurso dentro.
  publicas = {
    "${var.regiao}a" = "10.0.0.0/20"
    "${var.regiao}b" = "10.0.16.0/20"
  }
  privadas = {
    "${var.regiao}a" = "10.0.32.0/20"
    "${var.regiao}b" = "10.0.48.0/20"
  }
}

resource "aws_vpc" "principal" {
  cidr_block = "10.0.0.0/16"

  # Os dois são necessários para o nome DNS do RDS resolver dentro da VPC.
  # Sem `enable_dns_hostnames`, a aplicação recebe o endpoint e não resolve —
  # e o sintoma é timeout de conexão, que manda todo mundo olhar security group.
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = { Name = "lab02", Projeto = "lab02" }
}

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.principal.id
  tags   = { Name = "lab02-igw" }
}

resource "aws_subnet" "publica" {
  for_each          = local.publicas
  vpc_id            = aws_vpc.principal.id
  cidr_block        = each.value
  availability_zone = each.key

  # `false` de propósito, e é o oposto do padrão da AWS quando a sub-rede é
  # criada pelo console. IP público automático é como recurso ganha endereço
  # sem ninguém pedir; aqui o ALB recebe o dele porque é `internet-facing`.
  map_public_ip_on_launch = false

  tags = { Name = "lab02-publica-${each.key}", Camada = "publica" }
}

resource "aws_subnet" "privada" {
  for_each          = local.privadas
  vpc_id            = aws_vpc.principal.id
  cidr_block        = each.value
  availability_zone = each.key
  tags              = { Name = "lab02-privada-${each.key}", Camada = "privada" }
}

# ─── O NAT, e as duas coisas que ele exige ──────────────────────────────────
#
# 1. Ele mora na sub-rede PÚBLICA. Criá-lo na privada produz um recurso que sobe
#    sem erro, cobra por hora e não roteia nada — o sintoma é timeout na saída.
# 2. Ele precisa do IGW existindo. `depends_on` explícito porque o Terraform não
#    infere essa ordem: não há referência de atributo entre os dois.

resource "aws_eip" "nat" {
  domain = "vpc"
  tags   = { Name = "lab02-nat-eip" }
}

resource "aws_nat_gateway" "nat" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.publica["${var.regiao}a"].id
  depends_on    = [aws_internet_gateway.igw]
  tags          = { Name = "lab02-nat-aza" }
}

# ─── As duas tabelas: a diferença entre elas é UMA linha ────────────────────

resource "aws_route_table" "publica" {
  vpc_id = aws_vpc.principal.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id   # ← esta linha faz a sub-rede ser pública
  }

  tags = { Name = "lab02-rt-publica" }
}

resource "aws_route_table" "privada" {
  vpc_id = aws_vpc.principal.id

  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.nat.id    # ← e esta faz ser privada
  }

  tags = { Name = "lab02-rt-privada" }
}

# Associação EXPLÍCITA de cada sub-rede. Sem isto, a sub-rede usa a tabela
# principal da VPC — e "esqueci de associar" é indistinguível de "está associada
# ao lugar certo" quando se olha só a lista de sub-redes no console.

resource "aws_route_table_association" "publica" {
  for_each       = aws_subnet.publica
  subnet_id      = each.value.id
  route_table_id = aws_route_table.publica.id
}

resource "aws_route_table_association" "privada" {
  for_each       = aws_subnet.privada
  subnet_id      = each.value.id
  route_table_id = aws_route_table.privada.id
}

# A tabela principal fica SEM rota para o IGW. Assim, sub-rede criada no futuro
# sem associação explícita nasce sem saída — falha visível, em vez de sub-rede
# acidentalmente pública.
resource "aws_default_route_table" "principal" {
  default_route_table_id = aws_vpc.principal.default_route_table_id
  tags                   = { Name = "lab02-rt-principal-sem-saida" }
}

# ─── Registro do tráfego, para PROVAR o que o desenho afirma ────────────────
resource "aws_flow_log" "vpc" {
  vpc_id               = aws_vpc.principal.id
  traffic_type         = "ALL"
  log_destination_type = "cloud-watch-logs"
  log_destination      = aws_cloudwatch_log_group.flow.arn
  iam_role_arn         = aws_iam_role.flow.arn
}

resource "aws_cloudwatch_log_group" "flow" {
  name              = "/lab02/vpc/flow"
  retention_in_days = 7   # o destroy NÃO apaga log group sem isto; ver a limpeza
}

resource "aws_db_subnet_group" "privada" {
  name       = "lab02-privada"
  subnet_ids = [for s in aws_subnet.privada : s.id]

  # Duas AZs são exigência do grupo, mesmo sem Multi-AZ ligado: sem isso o RDS
  # recusa a criação. É o motivo de a sub-rede privada da AZ b existir desde já.
}

resource "aws_db_instance" "pg" {
  identifier     = "lab02-pg"
  engine         = "postgres"
  instance_class = "db.t4g.micro"

  allocated_storage = 20
  storage_encrypted = true

  db_subnet_group_name   = aws_db_subnet_group.privada.name
  vpc_security_group_ids = [aws_security_group.banco.id]

  # A metade da correção que aparece aqui. A outra metade é a ausência de rota,
  # e é ela que sustenta: com `false` mas em sub-rede pública, o banco continuaria
  # com caminho de entrada esperando um security group errado.
  publicly_accessible = false

  # Senha gerenciada: ela nunca passa pelo estado do Terraform.
  manage_master_user_password = true
  username                    = "lab02admin"

  backup_retention_period = 7
  skip_final_snapshot     = true   # laboratório. Em produção, `false` — ver a limpeza

  tags = { Name = "lab02-pg", Projeto = "lab02" }
}

# Security group que referencia OUTRO security group, não faixa de IP. A regra
# passa a ser "quem tem este papel", e continua valendo quando a task troca de IP.
resource "aws_security_group" "banco" {
  name   = "lab02-banco"
  vpc_id = aws_vpc.principal.id
}

resource "aws_vpc_security_group_ingress_rule" "banco_da_app" {
  security_group_id            = aws_security_group.banco.id
  referenced_security_group_id = aws_security_group.app.id
  from_port                    = 5432
  to_port                      = 5432
  ip_protocol                  = "tcp"
  description                  = "PostgreSQL somente das tasks da aplicacao"
}

# Sessão pela task que já roda na sub-rede privada. Não cria recurso, não abre
# porta, e cada sessão fica registrada no CloudTrail com o nome de quem abriu.

TASK=$(aws ecs list-tasks --cluster lab02 --service-name api \
        --query 'taskArns[0]' --output text)

# Encaminhamento de porta: a 5432 local passa a falar com o banco pela task.
aws ssm start-session \
  --target "ecs:lab02_${TASK##*/}_$(aws ecs describe-tasks --cluster lab02 \
      --tasks "$TASK" --query 'tasks[0].containers[0].runtimeId' --output text)" \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters "host=$(terraform output -raw endereco_banco),portNumber=5432,localPortNumber=5432"

# Em outro terminal, o psql fala com localhost e chega no banco privado.
psql -h localhost -p 5432 -U lab02admin -d postgres

# Exige `enableExecuteCommand = true` na task e a permissão de SSM na task role.
# É a troca deste desenho: uma permissão a mais para não ter um endereço a mais.

terraform init
terraform plan -out=plano     # confira: 4 sub-redes, 2 tabelas, 4 associações
terraform apply plano         # NAT e RDS levam alguns minutos

# ── Prova 1: a tabela da sub-rede privada não tem rota para o IGW ──
aws ec2 describe-route-tables \
  --filters "Name=tag:Name,Values=lab02-rt-privada" \
  --query 'RouteTables[0].Routes[*].[DestinationCidrBlock,GatewayId,NatGatewayId]' \
  --output table
# Esperado: 0.0.0.0/0 com NatGatewayId preenchido e GatewayId vazio.
# Se aparecer `igw-` aqui, a sub-rede não é privada, independentemente do nome.

# ── Prova 2: TODA sub-rede tem associação explícita ──
aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=$(terraform output -raw vpc_id)" \
  --query 'RouteTables[*].Associations[?Main==`false`].SubnetId' --output text | wc -w
# Esperado: 4. Menos que isso significa sub-rede herdando a tabela principal.

# ── Prova 3: o banco não resolve para endereço público ──
dig +short "$(terraform output -raw endereco_banco)"
# Esperado: um 10.0.x.x. Qualquer endereço público aqui reprova o laboratório.

# ── Prova 4: a saída funciona, medida de dentro ──
aws ecs execute-command --cluster lab02 --task "$TASK" --container api \
  --interactive --command "curl -s -o /dev/null -w '%{http_code}' https://api.ecr.us-east-1.amazonaws.com"
# Esperado: 200 ou 400 — qualquer resposta HTTP prova que o NAT roteia.
# Timeout aqui é o sintoma de NAT na sub-rede errada.

terraform destroy

# ── O que o destroy NÃO leva, e cada um cobra ou atrapalha ──

# 1. Elastic IP órfão — cobra por hora quando NÃO está associado.
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].[PublicIp,AllocationId]' --output table
# aws ec2 release-address --allocation-id <id>

# 2. Snapshot final do RDS. Aqui `skip_final_snapshot = true`, então não há —
#    mas em produção o padrão é `false`, e o snapshot fica cobrando armazenamento.
aws rds describe-db-snapshots --snapshot-type manual \
  --query 'DBSnapshots[?starts_with(DBInstanceIdentifier,`lab02`)].DBSnapshotIdentifier'

# 3. Log group do Flow Log. Ele TEM `retention_in_days`, então é destruído —
#    sem esse atributo, o Terraform não o gerencia e o log fica para sempre.
aws logs describe-log-groups --log-group-name-prefix /lab02

# 4. Backups automáticos do RDS. Sobrevivem à instância pelo período de retenção.
aws rds describe-db-instance-automated-backups \
  --query 'DBInstanceAutomatedBackups[?starts_with(DBInstanceIdentifier,`lab02`)]'

# 5. Interfaces de rede órfãs. Elas impedem a VPC de ser apagada, e o erro do
#    destroy é "DependencyViolation" sem dizer qual dependência.
aws ec2 describe-network-interfaces \
  --filters "Name=vpc-id,Values=<vpc-id>" \
  --query 'NetworkInterfaces[*].[NetworkInterfaceId,Description,Status]' --output table

# 6. O segredo criado pelo `manage_master_user_password` fica em exclusão
#    agendada — não é apagado na hora, e ainda aparece na lista.
aws secretsmanager list-secrets --include-planned-deletion \
  --query 'SecretList[?starts_with(Name,`rds!`)].[Name,DeletedDate]' --output table

# 7. Application Load Balancer e target group. O destroy leva os dois quando estão
#    no mesmo Terraform — mas um Application Load Balancer criado à mão numa
#    tentativa anterior cobra por hora e por unidade de capacidade, igual ao NAT.
aws elbv2 describe-load-balancers \
  --query 'LoadBalancers[?starts_with(LoadBalancerName,`lab02`)].[LoadBalancerName,State.Code]' \
  --output table

# 8. NAT Gateway e Elastic IP, os dois mais caros de esquecer.
aws ec2 describe-nat-gateways --filter "Name=state,Values=available" \
  --query 'NatGateways[*].[NatGatewayId,SubnetId]' --output table