Punti chiave
- Parti da un piano IP senza sovrapposizioni, dalla separazione delle subnet per finalità e zona e da un routing che controlla il traffico in uscita, per una crescita e una scalabilità prevedibili.
- Usa i Security Group come controlli di accesso principali e le Network ACL come protezione aggiuntiva, per applicare il privilegio minimo e ridurre il carico di lavoro legato alla risoluzione dei problemi.
- Implementa VPC Endpoint, Flow Log e Reachability Analyzer per mantenere privato il traffico dei servizi, monitorare l’attività e verificare la connettività senza esposizioni.
- Automatizza la distribuzione del VPC con Terraform o CloudFormation per mantenere la coerenza, accelerare il provisioning e supportare la preparazione agli audit.
- Applica l’hardening alle configurazioni per i carichi di lavoro regolamentati con firewall gestiti, PrivateLink per l’accesso ai servizi e rilevamento del configuration drift con AWS Config.
La configurazione di un Virtual Private Cloud (VPC) definisce i confini del tuo ambiente Amazon Web Services (AWS). Se impostata correttamente, può sostenere la crescita, nuove integrazioni e il livello di scrutinio che gli audit comportano.
Questa guida parte da una pianificazione pulita degli indirizzi, da confini chiari tra le subnet e da route che rispecchiano il funzionamento previsto della rete. Con la visibilità offerta da log e validazioni, costruisci una base che resta stabile anche quando l’ambiente cresce.
Come costruire una configurazione VPC Amazon sicura e scalabile
Prima di creare qualsiasi risorsa, verifica di avere coperto le basi.
📌 Prerequisiti generali:
- Regione di destinazione e almeno due zone di disponibilità individuate
- Un piano IP che eviti sovrapposizioni con le reti attuali e future
- Elenco dei servizi che richiedono traffico in uscita verso internet e accesso tra servizi AWS
- Ruoli IAM (gestione delle identità e degli accessi) con i permessi per le attività di rete e di logging
Passaggio 1: pianifica il VPC e lo spazio CIDR
Prima di creare risorse in AWS, definisci una strategia di indirizzamento IP chiara. In questo modo stabilisci lo spazio di indirizzi e la capacità del tuo ambiente, che potrà così scalare, restare sicuro e integrarsi in seguito con altre reti.
Ecco cosa fare, passo dopo passo:
- Scegli un blocco Classless Inter-Domain Routing (CIDR) dimensionato per la crescita. Ad esempio, 10.20.0.0/16 mette a disposizione 65.536 indirizzi IP, sufficienti per più subnet.
- Riserva intervalli IP aggiuntivi per future configurazioni di VPC peering o estensioni on-premises, così da evitare sovrapposizioni con reti aziendali o di partner.
- Distribuisci subnet pubbliche e private su almeno due zone di disponibilità per aumentare disponibilità e tolleranza ai guasti.
- Annota il blocco CIDR, l’assegnazione delle subnet e i dettagli di titolarità. Mantieni un registro delle modifiche per visibilità e governance.
Passaggio 2: crea il VPC e le subnet principali
Una volta definito il piano IP, configura il tuo VPC AWS e imposta la struttura delle subnet. È qui che stabilisci come i carichi di lavoro vengono isolati, instradati e scalati su AWS.
Segui questi passaggi per completare l’operazione:
- Crea il VPC usando il blocco CIDR pianificato. Abilita i nomi host DNS e la risoluzione DNS, così che istanze e servizi AWS possano comunicare tramite nomi di dominio interni.
- In ogni zona di disponibilità, crea tre subnet per garantire isolamento e alta disponibilità:
-
- Subnet pubblica: per le risorse che necessitano di accesso a internet, come Application Load Balancer (ALB), NAT Gateway e bastion host.
- Subnet privata per le applicazioni: per istanze EC2, container o servizi gestiti che avviano traffico in uscita attraverso un NAT Gateway.
- Subnet privata per i dati: per database e componenti stateful che non devono avviare traffico verso internet.
- Assegna a ogni risorsa tag relativi ad ambiente, proprietario e finalità, per supportare il controllo dei costi, l’automazione e gli audit di conformità.
Passaggio 3: definisci routing e confini verso internet
Il passo successivo è configurare come il traffico di rete si muove tra le tue risorse e le reti esterne. Questo passaggio definisce i punti di ingresso e di uscita del VPC, così che solo le subnet necessarie abbiano accesso a internet mentre quelle private restano isolate.
Vediamo insieme cosa devi fare:
- Collega un Internet Gateway (IGW) al VPC e associalo alla tabella di routing delle subnet pubbliche. Aggiungi una route predefinita (0.0.0.0/0) che indirizzi verso internet il traffico in uscita dalle risorse pubbliche.
- Distribuisci un NAT Gateway in ogni subnet pubblica per fornire accesso a internet in uscita ai carichi di lavoro privati. Indirizza il traffico predefinito di ciascuna subnet privata al NAT Gateway della stessa zona di disponibilità, così da mantenere l’alta disponibilità ed evitare trasferimenti di dati tra zone.
- Per il traffico IPv6 in sola uscita, usa un Egress-Only Internet Gateway (EIGW) sulle subnet private: consente le connessioni in uscita bloccando il traffico in ingresso non sollecitato.
- Mantieni le subnet private dei dati completamente isolate escludendo le route verso internet, a meno che non siano richieste per conformità o replica.
Passaggio 4: privilegia l’accesso privato ai servizi AWS
A questo punto, mantieni il traffico verso i servizi AWS all’interno della tua rete privata. I VPC Endpoint permettono alle istanze nelle subnet private di raggiungere servizi come S3, DynamoDB e Systems Manager senza passare da internet.
Ecco come procedere:
- Aggiungi VPC Endpoint per i servizi AWS che i tuoi carichi di lavoro utilizzano più spesso.
-
- Gateway Endpoint per i servizi ad alto volume come S3 e DynamoDB.
- Interface Endpoint per servizi come CloudWatch Logs, Systems Manager e altre API usate di frequente.
- Aggiorna le tabelle di routing delle subnet private per indirizzare il traffico dei servizi verso i nuovi endpoint invece che verso il NAT Gateway o l’Internet Gateway.
💡 Gli Interface Endpoint instradano automaticamente il traffico tramite DNS privato.
- Applica policy agli endpoint per limitare l’accesso per ruolo IAM o servizio AWS, seguendo il principio del minimo privilegio.
Passaggio 5: applica le policy di rete
Dopo aver configurato la connettività, applica le policy di rete per controllare come le risorse comunicano tra loro. Questo passaggio limita la comunicazione al solo traffico approvato all’interno del VPC.
Ecco le attività da svolgere:
- Usa i Security Group come controllo principale. Sono stateful, quindi il traffico di ritorno è consentito automaticamente, e definiscono le regole di traffico a livello di istanza o di interfaccia di rete.
Esempi di schema:
- Il Security Group dell’ALB consente il traffico HTTP e HTTPS in ingresso (80, 443) da internet e inoltra le richieste al SG dell’applicazione.
- Il Security Group dell’applicazione consente il traffico in ingresso solo dal Security Group dell’ALB e il traffico in uscita verso gli endpoint di servizio necessari.
- Il Security Group del database consente il traffico in ingresso sulla porta 1433 (SQL Server) o 3306 (MySQL) solo dal SG dell’applicazione.
- Usa le Network ACL (NACL) per il filtraggio a livello di subnet. Le NACL sono stateless e risultano utili per negazioni esplicite o protezioni aggiuntive tra subnet.
💡 Best practice: nega tutto per impostazione predefinita e consenti solo i flussi documentati.
- Mantieni un registro delle modifiche e annota la motivazione di ogni regola.
Passaggio 6: abilita visibilità e verifiche
Dopo aver applicato le policy di rete, rendi la rete osservabile e verificabile. Aggiungi logging, rilevamento delle minacce e validazione dei percorsi per confermare che il VPC si comporti come previsto.
Ecco come puoi farlo:
- Attiva i VPC Flow Log per il VPC, le subnet o specifiche ENI. Invia i log a CloudWatch Logs o S3 con una policy di conservazione che supporti la risoluzione dei problemi e gli audit.
- Abilita Amazon GuardDuty per rilevare anomalie e minacce utilizzando il traffico del VPC, l’attività di CloudTrail e la threat intelligence AWS. Esamina i risultati e intervieni con regolarità.
- Usa Reachability Analyzer o strumenti simili per verificare che i percorsi di rete previsti funzionino come atteso e che quelli non previsti restino bloccati.
Passaggio 7: collega o scala oltre un singolo VPC
A questo punto il VPC è sicuro, validato e pronto per espandersi. Molte architetture utilizzano più VPC per isolamento, configurazioni multi-account o connessioni ibride. Questo passaggio si concentra sulla scalabilità del progetto mantenendo il routing semplice e prevedibile.
Ecco cosa devi fare:
- Usa AWS Transit Gateway (TGW) per architetture hub-and-spoke che collegano più VPC, account AWS e reti on-premises. Il TGW centralizza il routing e scala insieme all’ambiente.
- Usa il VPC Peering per una connettività diretta punto-punto tra due VPC quando non servono routing transitivo o segmentazioni complesse.
💡 Il VPC Peering non supporta il routing transitivo.
- Documenta la propagazione delle route e le associazioni delle tabelle di routing. Verifica che le route si propaghino correttamente tra le reti collegate, per evitare black hole e accessi indesiderati.
Passaggio 8: variante con hardening per carichi di lavoro regolamentati
Per i carichi di lavoro con requisiti di conformità stringenti, applica controlli aggiuntivi per garantire isolamento, ispezione e monitoraggio continuo. Questa configurazione con hardening aiuta il VPC ad allinearsi agli standard normativi e a mantenere una postura di sicurezza stabile.
Esegui queste azioni:
- Elimina i percorsi diretti verso internet dalle subnet private. Instrada tutto il traffico in uscita attraverso NAT Gateway abbinati a un’ispezione centralizzata o a un firewall gestito come AWS Network Firewall.
- Usa PrivateLink o gli Interface VPC Endpoint per tutti gli accessi ai servizi AWS, dove disponibili. In questo modo le chiamate API e i trasferimenti di dati restano sulla dorsale AWS anziché passare da internet.
- Irrigidisci le policy di rete con riferimenti rigorosi ai Security Group e regole NACL a livello di subnet. Aggiungi negazioni esplicite per CIDR noti come malevoli o non attendibili.
- Abilita il rilevamento automatico del configuration drift su tabelle di routing e altri componenti di rete tramite le regole di AWS Config, così da mantenere le configurazioni allineate alle baseline approvate.
Passaggio 9: valida, documenta e passa in consegna
Prima di andare in produzione, valida la configurazione VPC e prepara la documentazione necessaria alla continuità operativa. Questo passaggio conferma che la connettività funziona come previsto, fornisce evidenze di conformità e agevola un passaggio di consegne fluido al team operativo.
Cosa devi fare?
- Esegui test di connettività da ogni livello applicativo verso le sue dipendenze. Verifica che ogni livello di rete (pubblico, applicativo e dati) possa raggiungere solo gli endpoint previsti. Registra i risultati per audit e risoluzione dei problemi.
💡 Suggerimento: usa AWS Reachability Analyzer per la validazione automatizzata dei percorsi.
- Esporta gli inventari di configurazione, inclusi subnet, tabelle di routing, Security Group e VPC Endpoint. Salvali come artefatti versionati per la conformità e per future consultazioni.
- Documenta il progetto di rete con diagrammi e mappe della topologia aggiornati. Includi l’assegnazione dei CIDR, le associazioni delle route, la posizione degli endpoint e le risorse condivise.
- Crea un runbook sintetico che descriva le attività operative di routine, come l’aggiunta di subnet, il collegamento di VPC o la rotazione delle policy degli endpoint. Conservalo in un repository condiviso e sotto controllo di versione, per averlo sempre a disposizione.
Tabella riepilogativa delle best practice
Queste best practice per il VPC racchiudono i principi fondamentali dei nove passaggi descritti sopra. Usale come riferimento rapido quando progetti o riesamini una qualsiasi configurazione VPC AWS.
| Pratica | Finalità | Valore ottenuto |
| Piano CIDR senza sovrapposizioni | Consente connettività futura ed espansione su più ambienti | Semplifica fusioni, peering e integrazione ibrida |
| Subnet pubbliche e private per ogni zona di disponibilità | Migliora isolamento dei guasti e disponibilità | Mantiene operativi i carichi di lavoro durante il guasto di una singola zona |
| NAT insieme ai VPC Endpoint | Controlla il traffico in uscita tramite percorsi privati | Riduce esposizione, latenza e costi dei NAT Gateway |
| Prima i Security Group, le NACL come protezione aggiuntiva | Applica l’accesso con privilegio minimo e regole coerenti | Riduce il rischio di configurazioni errate e problemi di rete |
| Flow Log e test di raggiungibilità | Aggiunge visibilità di rete e tracciabilità ai fini della conformità | Accelera la risoluzione dei problemi e migliora la preparazione agli audit |
Esempio di punto di contatto con l’automazione
L’automazione può garantire una distribuzione dell’infrastruttura di rete coerente, tracciabile e rapida. Il flusso di lavoro qui sotto mostra come costruire ogni ambiente nello stesso modo, validarlo dopo la distribuzione e documentarlo ai fini di audit e scalabilità.
Un template Terraform o CloudFormation esegue il provisioning di:
- VPC e subnet su più zone di disponibilità
- Internet Gateway, NAT Gateway e tabelle di routing
- VPC Endpoint per S3 e CloudWatch
- Security Group di base e Network ACL
- VPC Flow Log e un controllo con Reachability Analyzer tra il livello ALB e quello del database
Una pipeline CI esegue l’intero flusso di lavoro:
- Lancia un piano per esaminare le modifiche infrastrutturali in sospeso
- Applica le modifiche all’ambiente di sviluppo
- Esegue smoke test per verificare routing e connettività
- Esporta un inventario JSON di subnet, route ed endpoint
- Genera un diagramma di rete aggiornato per la documentazione
Integrazione con NinjaOne
Integrare NinjaOne con il tuo ambiente AWS estende la visibilità dal livello di rete fino al sistema operativo. Ti aiuta a gestire le baseline, verificare lo stato di salute e mantenere una documentazione pronta per gli audit dei clienti.
| Caratteristica NinjaOne | Azione |
| Gestione delle baseline del sistema operativo guest | Applica standard di patching e configurazione sulle istanze EC2 all’interno delle subnet private. |
| Automazione di script pianificati | Esegui script per controllare regolarmente lo stato del firewall dell’OS e la salute degli agenti ai fini della conformità. |
| Monitoraggio dell’agente CloudWatch | Verifica che gli agenti di monitoraggio siano in esecuzione e riportino le metriche in modo accurato. |
| Documentazione e reporting automatizzati | Includi nella documentazione per il cliente gli inventari esportati di subnet, route e security group, insieme ai risultati dei test di connettività. |
Guida rapida
NinjaOne può aiutarti a configurare un Amazon VPC per carichi di lavoro sicuri e scalabili grazie all’integrazione con AWS e con diversi strumenti di sicurezza. Ecco come:
Punti chiave:
- Configurazione VPC: NinjaOne supporta la distribuzione degli agenti e la gestione dei carichi di lavoro negli ambienti VPC di AWS, abilitando un’infrastruttura sicura e scalabile.
- Integrazione della sicurezza: NinjaOne si integra con strumenti come SentinelOne, CrowdStrike e Bitdefender per rafforzare la sicurezza all’interno dei VPC.
- Strategia multi-account: aiuta a gestire più account AWS, in linea con architetture VPC scalabili e sicure.
Un percorso sicuro e scalabile grazie a una configurazione VPC ben pianificata
Una configurazione VPC affidabile parte da una solida pianificazione IP, da ruoli chiari per le subnet e da un traffico in uscita controllato. Valida la tua configurazione con log e test di raggiungibilità. Usa l’automazione e un sistema di tag coerente per far scalare lo stesso progetto senza attriti, da un singolo carico di lavoro a molti, eliminando la necessità di rifare il lavoro. Imposta bene le fondamenta una volta e ogni distribuzione successiva resterà stabile e prevedibile.
Argomenti correlati:
