{"id":6262,"date":"2023-09-15T09:00:00","date_gmt":"2023-09-15T07:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=6262"},"modified":"2023-09-15T10:05:24","modified_gmt":"2023-09-15T08:05:24","slug":"aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/","title":{"rendered":"AWS Landing Zone e networking centralizzato: un matrimonio ben riuscito"},"content":{"rendered":"\n
Quando ci si trova a dover progettare una Landing Zone, uno dei temi pi\u00f9 salienti \u00e8 sicuramente la configurazione del networking. (Se non sei familiare al concetto di Landing Zone parti dalla nostra serie di articoli<\/a> per saperne di pi\u00f9). Per quanto riguarda il networking della nostra organizzazione, AWS mette a disposizione diverse possibili soluzioni e approcci, ognuna con particolari benefici e use case specifici. La soluzione che decideremo di adottare potrebbe anche essere una versione aggiornata nella nostra attuale infrastruttura e non per forza una nuova configurazione: dovremo tenere in considerazione i nostri trascorsi per capire dove la soluzione si adattava alle nostre esigenze e dove invece c\u2019erano problematiche o margini di miglioramento.<\/p>\n\n\n\n Nel corso dell\u2019articolo vedremo quelle che vengono considerate le migliori soluzioni per la realizzazione di un\u2019infrastruttura di rete condivisa e centralizzata su AWS<\/strong>. Come avremo modo di vedere esistono due filoni principali quando si parla di infrastrutture di rete in un approccio multi-account: utilizzo di una singola VPC, oppure di molteplici VPC. Analizziamo entrambi gli approcci.<\/p>\n\n\n\n Se parliamo di singola VPC \u00e8 difficile riuscire ad adattarla ad un contesto multi-account, eppure, grazie al servizio AWS RAM<\/strong>, questa soluzione risulta sia efficiente, che molto funzionale.<\/p>\n\n\n\n Pur essendo uno degli approcci meno conosciuti, consiste nell\u2019utilizzo di una singola VPC centralizzata per erogare connettivit\u00e0 a tutta la nostra Organization su AWS<\/strong>. Come vedremo tra poco, questa soluzione fornisce moltissimi vantaggi spesso messi in secondo piano, ma che talvolta possono fare la differenza.<\/p>\n\n\n\n Prima di tutto, per\u00f2, cerchiamo di capire come realizzare una VPC centralizzata e come adattarla ai nostri requisiti. <\/p>\n\n\n\n Per la realizzazione di questa infrastruttura avremo bisogno di pochi servizi: una singola VPC e il servizio AWS RAM.<\/p>\n\n\n\n Come piccolo tip, consigliamo di utilizzare una VPC con un ampio indirizzamento CIDR<\/strong>. Questo ci permetter\u00e0 di creare numerose subnet senza dover ricorrere all’estensione dell’indirizzamento associato alla VPC.<\/p>\n\n\n\n Per cominciare baster\u00e0 configurare un account adibito alle gestione del networking<\/strong> dal quale successivamente condivideremo tutte le subnet verso gli account della nostra Organization (nel corso dell\u2019articolo lo chiameremo \u201cnetwork-account<\/em>\u201d). Una volta creata la nostra VPC e un piccolo sottoinsieme di subnet, potremo procedere con la loro condivisione tramite l’utilizzo di AWS RAM verso l\u2019account desiderato.<\/p>\n\n\n\n Come ultimo step baster\u00e0 collegarsi all\u2019account di destinazione e accettare la condivisione delle subnet.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n Per tutto quello che riguarda la condivisione, utilizzeremo il servizio di AWS RAM adibito proprio a questo genere di attivit\u00e0 e che ci permetter\u00e0 anche di configurare determinati parametri per differenziare come verranno condivise, e quindi utilizzate, le nostre risorse.<\/p>\n\n\n\n Se tutto sar\u00e0 andato per il verso giusto, nell\u2019account applicativo dovremmo vedere comparire le subnet che abbiamo appena condiviso e la loro VPC.<\/p>\n\n\n\n Non vi preoccupate se anche la VPC risulter\u00e0 visibile dato che, comunque, ogni account avr\u00e0 accesso solo alle subnet che si \u00e8 deciso di condividere.<\/p>\n\n\n\n Ora che abbiamo le subnet sull’account di destinazione sar\u00e0 possibile creare le risorse utilizzando network condiviso, pur non essendo gli owner della suddetta VPC. Ovviamente, non possedendo l\u2019ownership di queste subnet, non potremo creare rotte o eliminarne altre dato che non siamo i detentori delle varie routing tables. Per tutte queste attivit\u00e0 sar\u00e0 necessario avere un amministratore di rete con gli accessi al network-account<\/em>, facendoci anche intuire uno dei vantaggi che vedremo successivamente.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Nello schema possiamo vedere un esempio della struttura che potrebbe avere la nostra Organization. In questo esempio il Network-Account<\/em> condivider\u00e0 3 subnet di ogni tipo con i vari account (produzione e non produzione). L\u2019unica differenza che vediamo tra gli ambienti sar\u00e0 il numero di Nat Gateway. Se per l\u2019account di produzione sar\u00e0 necessario avere almeno 2 NAT cos\u00ec da mantenere l\u2019alta disponibilit\u00e0, per quello di non produzione ne avremo soltanto uno, cos\u00ec da ridurre i costi.<\/p>\n\n\n\n Per ottimizzare ulteriormente i costi si potrebbe pensare di creare 3 NAT Gateway centralizzati che verranno utilizzati da tutti gli account al posto di averne uno dedicato per ogni ambiente non di produzione.<\/p>\n\n\n\n Queste configurazioni ci fanno capire che la soluzione risulta davvero versatile per adattarsi al meglio alla nostra idea di Landing Zone e di Business.<\/p>\n\n\n\n Dopo aver compreso l\u2019impostazione che prender\u00e0 la nostra struttura di rete su AWS, sicuramente inizieremo a porci delle domande per quanto riguarda sicurezza<\/strong> e segregazione. Purtroppo la soluzione a singola VPC con AWS RAM non ci viene particolarmente in contro in questo ambito, bens\u00ec ci costringe ad utilizzare Security group e Network ACL in maniera molto puntuale per evitare spiacevoli eventi.<\/p>\n\n\n\n Tratteremo le questioni inerenti alla security in un successivo articolo pi\u00f9 tecnico e dettagliatto.<\/p>\n\n\n\n Dopo esserci focalizzati sull\u2019utilizzo di un unica VPC \u00e8 doveroso capire anche quali altre possibilit\u00e0 ci vengono messe a disposizione da AWS. <\/p>\n\n\n\n
La scelta di configurazione della rete che andremo a implementare sia in ambienti fully cloud, che in ambienti ibridi influir\u00e0 moltissimo su sicurezza e operativit\u00e0 aziendale, che sulla comunicazione tra il Cloud e l\u2019on-premise.<\/p>\n\n\n\nNetworking design<\/h2>\n\n\n\n
Dobbiamo sempre ricordarci che, anche se possediamo molteplici possibilit\u00e0 tra cui scegliere, non sempre tutte faranno al caso nostro, ma dovremo cercare di capire quale di queste si adatter\u00e0 meglio alle nostre esigenze, rispecchiando anche i pilastri portanti della nostra infrastruttura.<\/p>\n\n\n\nSingola VPC con AWS RAM<\/h2>\n\n\n\n
Implementazione<\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n
<\/figure><\/div>\n\n\n
Approccio multi-VPC<\/h2>\n\n\n\n