{"id":6353,"date":"2023-09-29T08:00:00","date_gmt":"2023-09-29T06:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=6353"},"modified":"2023-09-27T15:47:30","modified_gmt":"2023-09-27T13:47:30","slug":"vpc-shared-vs-multi-vpc-scegliere-la-migliore-infrastruttura-di-rete-per-la-tua-azienda","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/vpc-shared-vs-multi-vpc-scegliere-la-migliore-infrastruttura-di-rete-per-la-tua-azienda\/","title":{"rendered":"VPC shared VS multi-VPC: scegliere la migliore infrastruttura di rete per la tua azienda"},"content":{"rendered":"\n
Introduzione<\/h2>\n\n\n\n
Come abbiamo visto nello scorso articolo, ormai quando si parla di infrastrutture di rete per la nostra Landing zone non pensiamo pi\u00f9 soltanto al Transit Gateway ma a una gamma di possiblit\u00e0 pi\u00f9 ampia. La vera domanda che dobbiamo porci adesso \u00e8 capire quando utilizzare un opproccio a discapito di un altro, capendo quali benefici o svantaggi questa decisione porter\u00e0 con se.<\/p>\n\n\n\n
Nel corso di questo articolo cercheremo di esporvi i vantaggi e gli svantaggi di ognuna delle soluzioni e, successivamente, portarvi anche dei piccoli esempi di use-case per ognugna di queste soluzione.<\/p>\n\n\n\n
Use Cases<\/h2>\n\n\n\n
Dopo aver capito quali sono le varie possibilit\u00e0 che abbiamo per configurare la rete della nostra landing zone, capiamo quali potrebbero essere alcuni scenari possibili che ci aiuteranno a capire quale approccio fa al caso nostro e delle nostre esigenze. Di seguito proveremo a proporre 3 possibili scenari e insieme capiremo quale delle possibilit\u00e0 si adatta a quello descritto. Ricordiamo che magari potreste avere esigenze particolari non contemplate in questo articolo, quello che vi proponiamo noi sono solo delle linee guida per prendere le vostre decisioni senza imporre una vera e propria regola.<\/p>\n\n\n\n
Use case Singola VPC condivisa<\/h2>\n\n\n\n
Poniamoci nel caso pi\u00f9 popolare; un\u2019azienda che ha deciso di appoggiarsi al cloud per tutta la sua infrastruttura \u00e8 che molto probabile nell\u2019arco degli anni ha fatto proliferare il numero dei suoi account. Per la nostra azienda ipotetica, tematiche come la Landing Zone, la gestione dei costi e la centralizzazione dei servizi principlai \u00e8 orami pane cuotidiano. Purtroppo per\u00f2 l\u2019IT non \u00e8 cresciuto al pari passo degli applicativi e del buisiness quindi, spesso si trovano a combattere contro il troppo overhead per gestire la loro infrastruttura. In questo caso tra tutte le varie opzioni, la singola VPC condivisa potrebbe essere proprio quel tassello che dar\u00e0 una marcia in pi\u00f9 all\u2019operativit\u00e0 quotidiana del nostro IT, senza dover rinunciare a tutti i benefici di scalabilit\u00e0 e compliances che siamo abbiatuti a vedere in una Landing Zone ben strutturata. A differenza di come avremmo con un Transit Gateway, con questa soluzione potremo gestire la rete di tutti gli account direttamente da una console centralizzata nel nostro \u201cnetwork-account\u201d. Come spiegato nell\u2019articolo precedente, quando ci riferiamo a \u201cnetwork-account\u201d intendiamo un account AWS all\u2019interno della nostra Organization adibito alla creazione della VPC e di tutte le sue subnet che successivamente verranno condivise coi vari account. Poter modificare le rotte, creare nuove subnet e gestire il traffico cross-account direttamente da una console ci permetter\u00e0 di risparmiare moltissimo tempo che andrebbe \u201cspeso\u201d per cambiare account con l\u2019assumeRole o con il nostro portale di SSO qual\u2019ora fossimo federeati con il nostro IDP. Per quanto ormai la gestione multi-account sia diventata la quotidianit\u00e0 per questo genere di aziende, poter risparmiare del tempo significativo ci aiuterebbe meglio a concentrarci su tematiche pi\u00f9 importante come la security e la segregazione. Un altro punto a favore per questa soluzione sta nella segregazione dei permessi legati alle risorse di rete negli account applicativi. Gestendo l\u2019ownershi della VPC all\u2019interno del nostro account centralizzato, potremo limitare i permessi IAM legati agli utenti che lavorano sui vari account, cos\u00ec anche da assicurarci che configurazioni errate possano provocare dei buchi per la nostra sicurezza di rete. Se volessi aggiungere un altro tassello alla nostra ipotetica azienda potremmo dire che i vari applicativi, presenti sui nostri account, spesso devono comunicare tra loro per scambiarsi informazioni preziose e necessarie per fornire un servizio di qualit\u00e0 a dei possibili clienti.<\/p>\n\n\n\n
Se vi siete trovati gi\u00e0 in questa situazione sicuramente saprete che in questi casi i costi extra-VPC la fanno da padrone. Ricordiamoci che su AWS il traffico che rimane all\u2019interno di una VPC e il traffico che passa da una VPC ad una ltra (anche nella stessa region di AWS) hanno due costi significativamente diversi. Se poi immaginiamo che si trovi anche un Transit Gateway tra le due VPC i costi aumentano ancora.<\/p>\n\n\n\n
<\/figure>
\n
Anche in questo caso la singola VPC condivisa con AWS RAM ci permetter\u00e0 di abbatere tutti questi costi accessori. Il traffico dei nosti pacchetti pur spostandosi da una subnet ad un altra, o da un account ad un altro, rimarr\u00e0 sempre all\u2019interno della nostra singola VPC non andando ad incappare nei costi accessori menzionati poco fa.
Facendo una piccola postilla su questa situzione, se durante il nostro percorso su AWS avessimo deciso di implementare ABAC come metodologia di gestion accessi, questa decisione potrebbe non funzionare bene con questa architettura di rete. La soluzione pi\u00f9 semplice sarebbe taggare nuovamente le risorse una volta che le subnet saranno condivise.<\/p>\n<\/div><\/div>\n\n\n\n
Use case Transit Gateway<\/h2>\n\n\n\n
Se prima abbiamo parlato di un\u2019azienda di medie dimensioni che ha basato l\u2019infrastruttura sul cloud, opra parliamo di una grande multinazionale che sta compiendo la sua migrazione verso il cloud al fine di modernizzare i suoi applicativi. Rispetto all\u2019esempio di prima il numero dei dipendenti IT e di persone in grado di gestire la rete \u00e8 sicuramente maggiore. Immaginiamo anche che ogni azienda che comporr\u00e0 la nostra Company avr\u00e0 il suo IT dedicato e che tra loro abbiano anche differenti modi di lavorare. Sicuramente in questo caso la Singola VPC condivisa causerebbe soltanto problemi avendo troppi attori coinvolti nella sua configurazione. La secelta pi\u00f9 saggia ricade sull\u2019approccio Transit Gateway e sulla creazione di almeno una VPC in ognuno degli account della nostra Organization AWS. Come nell\u2019altro esempio, anche qui, avremo un account centrale dove risieder\u00e0 il Transit Gateway e a cui probabilmente avranno accesso soltanto alcuni responsabili IT o figure di particolare spicco tecnitco. Per tutti gli altri account invece, i singoli dipartimenti IT saranno liberi di creare rotte interne, dhcp reservetion, network ACl e quant\u2019altro per far si che l\u2019operativit\u00e0 cuotidiniana dell\u2019azienda contunui senza intoppi. Il Tranist Gateway risulta la scelta pi\u00f9 vantaggiosa in questo ambito dato che molto probabilmente per la nostra Landing Zone non avremo optato per una singola region ma bensi per svariate. Questa decisione magari sar\u00e0 stata presa per avvicinare le sedi sparse per il mondo ai datacenter dove risiedono effettivamente le VM, cos\u00ec da ridurre al pi\u00f9 possibile la latenza.<\/p>\n\n\n\n
Tale implementazione multi-region non sarebbe possibile utilizzando il metodo della VPC Shared dato che appoggiandosi su un servizio \u201cregionale\u201d come RAM, potremo adoperare le subnet condivise con i nostri account solo qualora ci trovassimo nella stessa Region originaria della VPC.<\/p>\n\n\n\n
Un\u2019altra situazione che ci spinge verso questa soluzione \u00e8 la possibilit\u00e0 di attestare sul Transit Gateway tutte le VPN S2S proveniente dalle nostre sedi on-premise verso il Cloud. Questa operazione \u00e8 necessaria per consentire ai gestori IT di operare al meglio sulle numerosissime Virtual Machine del loro parco macchine.<\/p>\n\n\n\n
Come descritto nella sezione del Transit Gateway dello scorso articolo, tutto il traffico e il routing potranno essere gestiti con la modifica delle routing table assegnate ad ogni Transit Gateway Attachment. Ci baster\u00e0 configurare le rotte in modo tale che ogni sede on-premise possa raggiungere soltanto il suo corrispettivo account AWS. Questo ci porterebbe anche ad un grado di sicurezza abbastanza elevato qual\u2019ora un malintenzionato cercasse di fare del \u201cLateral Moving\u201d all\u2019interno della nostra rete. Purtroppo se per questo approccio dovesse bastare tale configurazione delle routing table, per la VPC condivisa potrebbe risultare pi\u00f9 macchinoso restringere questo genere di problematiche. Essendo tutte le subnet comunicanti tra di loro e non potendo creare rotte (all\u2019iterno delle routing table) pi\u00f9 esclusive del nostro CIDR l\u2019unico modo per segregare ogni gruppo di subnet sarebbe adottare delle network ACL molto stringenti.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Use case VPC Peering<\/h2>\n\n\n\n
Dopo aver parlato di medie e grandi imprese, non ci resta che trattare lo scenario emergente ovvero piccole aziende o sturtup. Possiamo immaginarci questa azienda come ai suoi albora e che dopo i suoi primi passi sul cloud ha deciso di abbozzare una Landing Zone in formato ridotto. Quando pensiamo a questo genere di aziende non dobbiamo immaginarci sedi disparse per il mondo, smisurate quantit\u00e0 di account, particolare gestione per policy di compliance e sicuramente la presenza forte di un IT dedicato. Gli unici due aspetti che possiamo identificare come principali nella progettazione della nostra lanfing zone sono i costi e la facilit\u00e0 di gestione. Se parlaimo di infrastrutture di rete che rispecchino questi due principipi la scelta non pu\u00f2 che ricadere nel VPC Peering. La semplicit\u00e0 di questa funzionalit\u00e0, che molto spesso la esclude dalla pool di possibile soluzioni, in questo caso la rende la perfetta candidata per rispecchiare al meglio le nostre esigenze chiare e ben definite.<\/p>\n\n\n\n
<\/figure>
\n
In questo scenario la nostra Landing Zone sar\u00e0 composta da un numero davvero ridotto di account, lasciando perdere gli account spesso adibiti alla gestione della sceruty e all\u2019auditing. Anche per quanto riguarda il network-accont risulta superfluo e quindi tranquillamente trascurabile. <\/p>\n<\/div><\/div>\n\n\n\n
Con il VPC peering potremo mettere in comunicazione i nostri due applicativi che sono stati rilasciati su due account distinti (o che magari sono stati realizzati in due momenti diversi) semplicemente con pochi click. Sicuramente l\u2019utilizzo del peerign non ci permetter\u00f2 di adoperare funzionalit\u00e0 complesse e articolate come si potrebbe fare con un Transit Gateway, ma nel nostro caso non sar\u00e0 un problema dato che la gestione della rete non sar\u00e0 uno dei nostri principali interessi per questa fase del nostro sviluppo su AWS.<\/p>\n\n\n\n
Purtroppo il peering non sar\u00e0 una soluzine definitiva se intendiamo far creasce la nostra azienda, e di conseguenza la nostra AWS organization, nel arco dei prossimi anni. Il difetto principle di questa soluzione \u00e8 la sua scalabilit\u00e0 che, con il creascere degli account, perde il suo principio di semplicit\u00e0 e aggiunge moltissimo overhead di gestione. Comunque questa potrebbe essere una fase di transizione per consolidarci sul cloud, prima di adottare una soluzione pi\u00f9 strutturata come VPC Share o Transit Gateway<\/p>\n\n\n\n
Conclusione<\/h2>\n\n\n\n
Come ogni volta \u00e8 il momento di tirare delle conclusioni su quanto abbiamo trattato nel corso di questi due articoli sul networking centralizzato in una lading zone e le varie possibili infrastrutture.<\/p>\n\n\n\n
Abbiamo visto che ognuna delle varie possibilit\u00e0 che ci vengono messe a disposizione da AWS ha i suoi vantaggi e svantaggi non che particolari casi di utilizzo.<\/p>\n\n\n\n
Sarebbe difficile dire quale di queste soluzione sia la migliore perch\u00e8 come spesso accade la risposta \u00e8 \u201cdipende\u201d. Sicuramente il primo step \u00e8 capire quali sono le esigneze dalla nostra azienda e quali valori vogliamo portare avanti durante la creazione della Landing Zone. Come molto spesso \u00e8 stato spiegato su questo blog, la progettazione di una Landing Zone \u00e8 qualcosa che va studiato nei minimi dettagli e adattato alle richieste, come se fosse un vestito sartoriale su misura.<\/p>\n\n\n\n
Ricordiamoci anche che una infrastruttura ben progettata ci accompagner\u00e0 nel percorso di crescita della nostra azienda. Per questo, cerchiamo di progettare una soluzione che riesca a creascere di pari passo con le nostre esigenze e di conseguenza con la creascita della nostra Landing Zone su AWS<\/p>\n\n\n\n
Una volta capita quale struttura la nostra Landing Zone adotter\u00e0, sar\u00e0 necessario interfacciarsi con gli steackholder dei nostri applicativi per capire anche dal loro punto di vista che esigenze potremmo aver trascurato o non tenuto in considerazione. Ricordiamoci che un\u2019infrastruttura ad hoc e che permette a tutti di lavorare in maniera efficente e sicura \u00e8 sempre la starada da intraprendere in fase di progettazione e rinnovo.<\/p>\n\n\n\n<\/figure>\n\n\n\n\n\n\n\n
![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/09\/image2-1-668x1024.png\")
<\/figure>![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/09\/image1-1.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/09\/image3-2.png\")
<\/figure>![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/09\/Scherma-articolo-29-09-2023-1024x576.png\")
<\/figure>\n\n\n\n