Security group, network ACL e route table

Ogni pacchetto in una VPC attraversa tre livelli di controllo ed è fondamentale sapere quale interviene per isolare un blocco. Il security group è stateful e agisce a livello di ENI: se consenti il traffico in ingresso, la risposta esce automaticamente senza una regola in uscita, e viceversa. Ammette solo regole di allow. La network ACL è stateless e agisce a livello di subnet: valuta ingresso e uscita in modo indipendente, quindi devi aprire esplicitamente le porte ephemeral (tipicamente 1024-65535) per il traffico di ritorno. Ammette allow e deny, valutati in ordine di numero di regola. La route table decide dove va il traffico in base al CIDR di destinazione: vince la regola più specifica (longest prefix match) e la route local verso il CIDR della VPC non è rimovibile.

NAT gateway, VPC endpoint e peering

Le istanze in una subnet privata non hanno IP pubblico: per l’egress verso Internet (patch, chiamate ad API esterne) usano un NAT gateway collocato in una subnet pubblica, con una route 0.0.0.0/0 che punta al NAT nella route table della subnet privata. Il NAT consente solo connessioni originate dall’interno, mai in ingresso; per l’alta disponibilità serve un NAT gateway per Availability Zone.

Per raggiungere Amazon S3 o DynamoDB senza passare da Internet si usa un VPC endpoint gateway, che aggiunge una route verso una prefix list nella route table: elimina i costi del NAT e tiene il traffico sulla rete AWS. Gli altri servizi usano interface endpoint (PrivateLink).

Il VPC peering connette due VPC ma non è transitivo: ogni VPC deve avere una route esplicita verso il CIDR dell’altra nella propria route table, e i CIDR non devono sovrapporsi.

Route 53 e CloudFront

Amazon Route 53 è il DNS gestito. Oltre ai record standard offre gli alias record (gratuiti, puntano a risorse AWS come ELB, CloudFront o S3) e le routing policy: simple, weighted, latency-based, geolocation e failover con health check. Un health check fallito rimuove il record dai risultati DNS, ma la propagazione dipende dal TTL, quindi TTL alti ritardano il failover.

Amazon CloudFront è la CDN: mette in cache i contenuti alle edge location riducendo latenza e carico sull’origin. Problemi frequenti: contenuti obsoleti (serve invalidazione o TTL corretti), errori 403 verso un origin S3 (Origin Access Control e bucket policy mancanti), header non inoltrati all’origin.

Diagnosi della connettività

Di fronte a “non riesco a connettermi” procedi a strati. VPC Reachability Analyzer traccia il percorso logico tra due risorse e indica il componente che blocca. VPC Flow Logs registrano ACCEPT/REJECT per ENI, subnet o VPC: un REJECT punta a security group o NACL, mentre un pacchetto in uscita senza risposta suggerisce route table assente o NACL asimmetrica. Verifica sempre nell’ordine: route table (esiste il percorso?), security group (allow presente?), network ACL (porte ephemeral aperte in entrambe le direzioni?).

Trappole tipiche d’esame

  • Connessione TCP che parte ma la risposta non torna → network ACL stateless: il security group lascia tornare la risposta perché stateful; se il ritorno è bloccato, quasi sempre mancano le porte ephemeral in una direzione della NACL.
  • Istanza in subnet privata che non scarica aggiornamenti → NAT gateway + route: serve un NAT gateway in subnet pubblica e la route 0.0.0.0/0 verso di esso; se la route manca o il NAT è nella subnet sbagliata, l’egress fallisce.
  • Traffico verso S3 da togliere dal NAT → VPC endpoint gateway: riduce i costi e tiene il traffico privato; ricorda che aggiunge una route via prefix list, non un indirizzo IP.
  • Due VPC in peering che non comunicano → route mancanti: il peering non è transitivo e non crea route automatiche; ogni VPC deve avere la route verso il CIDR dell’altra.
  • Failover Route 53 lento → TTL troppo alto: l’health check rileva il guasto, ma i resolver tengono in cache il vecchio record fino alla scadenza del TTL; abbassa il TTL sui record critici.
  • CloudFront che serve contenuti vecchi o 403 dall’origin S3 → invalidazione / OAC: per l’aggiornamento immediato serve un’invalidazione della cache; per il 403 verifica Origin Access Control e bucket policy.