VPC Origin: esporre un servizio privato su AWS
Obiettivo: esporre un servizio su internet senza avere nulla in ascolto su una subnet pubblica.
Utilizzando l’approccio classico, un ALB pubblico con security group ristretto al prefix list di CloudFront, resta bypassabile: chi scopre il DNS dell’ALB lo raggiunge direttamente, saltando CloudFront.
La soluzione è CloudFront VPC Origin. CloudFront raggiunge l’ALB direttamente dentro la VPC, senza bisogno di un load balancer pubblico e senza NAT in ingresso.
Il codice completo è su GitHub .
Architettura Link to heading
Tutte le risorse vivono in subnet private:
- ALB interno, senza IP pubblico e senza rotte verso l’internet gateway.
- ECS Fargate con un task nginx, anch’esso senza IP pubblico.
- EC2 (bastion), senza IP pubblico, per mostrare che il pattern non è legato a ECS.
- CloudFront, unico punto d’ingresso, che raggiunge l’ALB tramite VPC Origin.
Le subnet pubbliche esistono solo per ospitare i NAT Gateway, usati per il traffico in uscita. Non espongono nulla.
Due layer di protezione Link to heading
Anche con VPC Origin, l’ALB interno resta raggiungibile da chiunque abbia accesso alla VPC, ad esempio tramite peering o VPN. Per coprire questo caso ho aggiunto due controlli indipendenti.
Il primo è a livello di rete: un security group sull’ALB accetta traffico solo dal prefix list gestito da AWS di CloudFront.
Il secondo è a livello applicativo: un header HTTP, generato casualmente, viene iniettato da CloudFront su ogni richiesta e verificato da una regola sull’ALB. Le richieste che arrivano senza l’header corretto vengono scartate.
È il pattern raccomandato da AWS: il security group blocca chi non arriva dai range IP di CloudFront, l’header blocca chi prova a impersonare CloudFront da dentro quei range.
ECS Fargate Link to heading
Il task nginx gira su Fargate in subnet private, dietro il target group dell’ALB interno.
EC2 Link to heading
Ho aggiunto anche un’istanza EC2 (bastion) per dimostrare che il pattern funziona con qualsiasi risorsa in subnet privata, non solo con ECS.
L’istanza non ha IP pubblico e non ha nessuna porta SSH aperta. Ci si connette esclusivamente tramite SSM Session Manager, grazie a un IAM role dedicato. Il risultato è zero porte aperte in ingresso, zero chiavi SSH da gestire, e un accesso comunque tracciabile tramite CloudTrail.
Traffico di supporto Link to heading
Sia ECS che EC2 devono parlare con servizi AWS come ECR, CloudWatch Logs e SSM; per evitare di farli uscire tramite NAT ho usato dei VPC Endpoints. In questo modo il traffico verso i servizi AWS non lascia mai la VPC. Le subnet private hanno comunque una route di default verso un NAT Gateway, per il traffico in uscita non coperto dagli endpoint. Non è quindi un’infrastruttura a zero NAT.
Il punto però non è eliminare ogni traffico in uscita, ma eliminare ogni percorso in ingresso che non passi da CloudFront. Sono due problemi diversi, ed è il secondo quello che VPC Origin risolve.
Conclusioni Link to heading
VPC Origin è utile quando serve esporre un servizio interno con un solo punto d’ingresso ben controllato.
Benefici principali:
- Nessuna risorsa applicativa con IP pubblico o porta esposta.
- Doppio controllo, rete più applicazione, contro il bypass di CloudFront.
- Applicabile sia a container (ECS/Fargate) che a istanze EC2.
- Accesso amministrativo via SSM, senza SSH né chiavi da gestire.
Limitazioni:
- Il NAT Gateway resta necessario per il traffico in uscita non coperto dai VPC Endpoints.
- Costo aggiuntivo di VPC Origin e Interface Endpoint rispetto a un’esposizione pubblica diretta.