{"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

Introduzione<\/h2>\n\n\n\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).

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\n

Networking design<\/h2>\n\n\n\n

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.
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\n

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

Singola VPC con AWS RAM<\/h2>\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

Implementazione<\/h3>\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

\n
\"\"<\/figure><\/div>\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

\n
\"\"<\/figure><\/div>\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

Approccio multi-VPC<\/h2>\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

Se prima avevamo una sola VPC per tutti gli account ora invece avremo almeno una VPC per ogni account<\/strong>. Un approccio di questo tipo viene chiamato multi-VPC e, come la sua controparte, ha pregi e difetti che non sempre lo rendono la soluzione perfetta per noi. <\/p>\n\n\n\n

Quando parliamo di approcci multi-VPC la scelta molto spesso ricade sull\u2019utilizzo di AWS Transit Gateway oppure del VPC Peering.<\/p>\n\n\n\n

AWS Transit Gateway<\/h3>\n\n\n\n

Ormai sdoganato negli ultimi anni, l\u2019utilizzo del Transit Gateway \u00e8 lo \u201cstandard\u201d per quanto riguarda la progettazione di una landing zone. (Abbiamo parlato di AWS Transit Gateway in maniera dettagliata in alcuni nostri articoli<\/a>)<\/p>\n\n\n\n

Per la realizzazione di un’infrastruttura che sfrutti il Transit Gateway avremo bisogno soltanto di: un Transit gateway, Transit Gateway Route table e Transit Gateway Attachment.<\/p>\n\n\n\n

Il Transit Gateway possiamo immaginarlo come un router virtuale che mette in comunicazione tutte le VPC della nostra Landing Zone in maniera semplice ed efficace<\/strong>.<\/p>\n\n\n\n

Anche per adottare questa soluzione avremo bisogno del cosiddetto network-account su cui riesieder\u00e0 effettivamente il Transit Gateway. Essendo un approccio Multi-VPC ci serviranno anche almeno 2 VPC, una nell\u2019account A e una nell\u2019account B (anche il network account pu\u00f2 avere la sua VPC). A differenza della soluzione proposta precedentemente, in questo caso tutte le VPC saranno indipendenti dal punto di vista della loro configurazione e gestione mentre solo il Transit Gateway in s\u00e9 per s\u00e9 sar\u00e0 riservato agli amministratori di rete.<\/p>\n\n\n\n

Ricordiamo che, dovendo utilizzare numerose VPC, dovremo evitare il pi\u00f9 possibile di utilizzare CIDR sovrapposti tra di loro e soprattutto che vadano a coprire reindirizzamenti pubblici.<\/p>\n\n\n\n

Per agganciare una delle nostre VPC al Transit Gateway dovremo creare un Attachment<\/strong> sia che questa VPC si trovi nel network-account o che si trovi in uno degli altri account della landing zone. Anche in questa occasione ci avvarremo del servizio AWS RAM per poter condividere il nostro Transit Gateway appena creato con uno o pi\u00f9 account della nostra Landing Zone (ogni account avr\u00e0 il proprio attachment). Una volta che avremo accettato la condivisione potremo procedere, dal nostro account A, con la creazione del nostro Transit Gateway attachment per poi collegarlo alla nostra VPC. Cos\u00ec facendo avremo creato un collegamento \u201cvirtuale\u201d tra la nostra VPC e il Transit Gateway centralizzato.<\/strong> Se si desiderasse utilizzare l’Infrastructure-as-Code (IaC) potremmo automatizzare questi passaggi direttamente Tramite AWS CloudFormation.<\/p>\n\n\n\n

Allo stato attuale avremmo una o pi\u00f9 VPC che afferiscono allo stesso Transit Gateway, ma senza la possibilit\u00e0 di comunicare fra di loro.<\/p>\n\n\n\n

Come ogni router, per gestire il percorso dei nostri pacchetti di rete, bisogner\u00e0 configurare le rotte<\/strong> che nel nostro caso risiedono nelle Transit Gateway Route Table<\/strong>. In generale potremmo avere una routing table per ogni attachment cos\u00ec da poter meglio dividere le varie rotte e la segregazione delle VPC di account specifici e particolarmente critici.<\/p>\n\n\n\n

Per agganciare una Route Table ad un Attachmen baster\u00e0 creare un association direttamente dalla console di AWS specificando i vari ID richiesti.<\/p>\n\n\n\n

<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

<\/p>\n\n\n\n

Segregazione delle rotte<\/h3>\n\n\n\n

Purtroppo, come per ogni altra soluzione multi-VPC, anche questa avr\u00e0 bisogno di molto effort a livello gestionale per assicurarsi che col proliferare delle VPC venga comunque mantenuto un buon isolamento a livello di sciruezza. Ricordiamo che, se pur dobbiamo mantenere un certo livello di sicurezza, dovremo anche permettere ai nostri applicativi di funzionare in maniera ottimale, senza andare ad impattare sui loro normali flussi operativi. Molto dell\u2019effort, infatti, sar\u00e0 da spendere nella configurazione precisa e puntuale delle rotte i ogni singola Routing Table. Una buona gestione di tutte le VPC afferenti al nostro Tranist Gateway ci permetter\u00e0 di essere tutelati anche qualora una delle nostre istanze venisse infettata da malintenzionati.<\/p>\n\n\n\n

VPC Peering<\/h3>\n\n\n\n

L\u2019approccio che meglio si contrappone a quello del Transit Gateway \u00e8 quello di utilizzare i VPC Peering. <\/p>\n\n\n\n

Il VPC Peering altro non \u00e8 che un \u201cponte\u201d virtuale creato per mettere in comunicazione due VPC diverse<\/strong>, sia che queste si trovino in un solo account, sia che siano dislocate in account differenti. <\/p>\n\n\n\n

Di solito questo \u00e8 un approccio che risulta valido quando si possiedono pochi account e non si vuole investire troppo effort nella gestione della rete.<\/p>\n\n\n\n

Avendo le VPC collegate potremo anche utilizzare i security group che non appartengono alla VPC di cui siamo i proprietari, aiutandoci a rendere pi\u00f9 sicura la nostra infrastruttura con regole ad hoc e ben mirate.<\/p>\n\n\n\n

Ricordiamo che se referenziamo un security group di un altra VPC questo non ci comparir\u00e0 come suggerimento direttamente dalla console ma dovremo inserirlo manualmente. Inoltre, nel caso in cui ci trovassimo cross-region non sarebbe possibile referenziare i security group delle varie VPC.
Una cosa molto importante da tenere a mente quando si utilizza il VPC peering \u00e8 che quest\u2019ultimo non \u00e8 transitivo<\/strong>. Se abiliteremo il Peering tra la VPC-A e la VPC-B e successivamente tra la VPC-B e la VPC-C, la VPC-B potr\u00e0 comunicare con tutte le altre VPC ma le altre VPC non potranno comunicare tra loro dato che la VPC-B non riesce a ruotare il traffico verso il \u201cnext hop\u201d. <\/p>\n\n\n\n

Questo ci fa subito capire che il numero di peering che dovremo creare crescer\u00e0 esponenzialmente mano a mano che creeremo nuove VPC.<\/p>\n\n\n\n

Conclusione<\/h2>\n\n\n\n

Come spesso ci si sente dire, la risposta a quale approccio sia il pi\u00f9 adatto alle nostre esigenze \u00e8 \u201cDipende\u201d.<\/p>\n\n\n\n

Tutto dipende da quale architettura abbiamo intenzione di adottare, quanto grande sar\u00e0 la nostra organizzazione e soprattutto quanto effort saremo in grado di sostenere nella sola gestione della rete.<\/p>\n\n\n\n

Ricordiamo sempre che una buona infrastruttura poggia le sue fondamenta su una rete ben progettata e scalabile, in grado di evolversi di pari passo con l’evoluzione e con la crescita della organization.<\/strong><\/p>\n\n\n\n

Per capire meglio vantaggi e svantaggi delle varie possibilit\u00e0 introdotte in questo articolo, entreremo nel dettaglio del loro utilizzo in un articolo dedicato. Prenderemo ad esempio alcuni degli use-case pi\u00f9 comuni delineando una mappa di soluzioni a seconda dal caso.<\/p>\n\n\n\n

Seguiteci dunque per non perdervi la seconda parte del nostro viaggio nella centralizzazione del networking in ambienti Cloud multi-account su AWS!<\/p>\n\n\n\n

\n\n\n\n

About Proud2beCloud<\/h4>\n\n\n\n

Proud2beCloud<\/strong> is a blog by beSharp<\/a>, an Italian APN Premier Consulting Partner expert in designing, implementing, and managing complex Cloud infrastructures and advanced services on AWS. Before being writers, we are Cloud Experts working daily with AWS services since 2007. We are hungry readers, innovative builders, and gem-seekers. On Proud2beCloud, we regularly share our best AWS pro tips, configuration insights, in-depth news, tips&tricks, how-tos, and many other resources. Join the discussion!<\/p>\n","protected":false},"excerpt":{"rendered":"

Introduzione Quando ci si trova a dover progettare una Landing Zone, uno dei temi pi\u00f9 salienti \u00e8 sicuramente la configurazione […]<\/p>\n","protected":false},"author":27,"featured_media":6288,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[469],"tags":[569,564,565,581,567],"yoast_head":"\nAWS Landing Zone e networking centralizzato: un matrimonio ben riuscito - Proud2beCloud Blog<\/title>\n<meta name=\"description\" content=\"Configurazioni di rete in una Landing Zone: networking centralizzato in ambienti Cloud multi-account su AWS.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/\" \/>\n<meta property=\"og:locale\" content=\"it_IT\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"AWS Landing Zone e networking centralizzato: un matrimonio ben riuscito\" \/>\n<meta property=\"og:description\" content=\"Configurazioni di rete in una Landing Zone: networking centralizzato in ambienti Cloud multi-account su AWS.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/\" \/>\n<meta property=\"og:site_name\" content=\"Proud2beCloud Blog\" \/>\n<meta property=\"article:published_time\" content=\"2023-09-15T07:00:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-09-15T08:05:24+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/09\/Copertina-blog-15-09-23_15-09-social-eng.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1199\" \/>\n\t<meta property=\"og:image:height\" content=\"627\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Riccardo Fragnelli\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:title\" content=\"AWS Landing Zone e networking centralizzato: un matrimonio ben riuscito\" \/>\n<meta name=\"twitter:description\" content=\"Configurazioni di rete in una Landing Zone: networking centralizzato in ambienti Cloud multi-account su AWS.\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/09\/Copertina-blog-15-09-23_15-09-social-eng.png\" \/>\n<meta name=\"twitter:label1\" content=\"Scritto da\" \/>\n\t<meta name=\"twitter:data1\" content=\"Riccardo Fragnelli\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tempo di lettura stimato\" \/>\n\t<meta name=\"twitter:data2\" content=\"9 minuti\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/\",\"url\":\"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/\",\"name\":\"AWS Landing Zone e networking centralizzato: un matrimonio ben riuscito - Proud2beCloud Blog\",\"isPartOf\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/#website\"},\"datePublished\":\"2023-09-15T07:00:00+00:00\",\"dateModified\":\"2023-09-15T08:05:24+00:00\",\"author\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/621a9271823d0abbc1096cd77da47ccc\"},\"description\":\"Configurazioni di rete in una Landing Zone: networking centralizzato in ambienti Cloud multi-account su AWS.\",\"breadcrumb\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/#breadcrumb\"},\"inLanguage\":\"it-IT\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/blog.besharp.it\/it\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"AWS Landing Zone e networking centralizzato: un matrimonio ben riuscito\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#website\",\"url\":\"https:\/\/blog.besharp.it\/it\/\",\"name\":\"Proud2beCloud Blog\",\"description\":\"il blog di beSharp\",\"alternateName\":\"Proud2beCloud Blog\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.besharp.it\/it\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"it-IT\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/621a9271823d0abbc1096cd77da47ccc\",\"name\":\"Riccardo Fragnelli\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"it-IT\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/be24f01e4e529597302dbbab4ad5504f?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/be24f01e4e529597302dbbab4ad5504f?s=96&d=mm&r=g\",\"caption\":\"Riccardo Fragnelli\"},\"description\":\"DevOps @ beSharp I was born on-prem as a Dev before landing on the \u201cCloud side of IT\u201d. With AWS I discovered a whole new branch of IT that fascinates me more and more; I\u2019m always ready for the next big thing! I\u2019m the fussiest man I know on earth and quite lazy. I like spending my free time jumping between video games and RPGs.\",\"url\":\"https:\/\/blog.besharp.it\/it\/author\/riccardo-fragnelli\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"AWS Landing Zone e networking centralizzato: un matrimonio ben riuscito - Proud2beCloud Blog","description":"Configurazioni di rete in una Landing Zone: networking centralizzato in ambienti Cloud multi-account su AWS.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/","og_locale":"it_IT","og_type":"article","og_title":"AWS Landing Zone e networking centralizzato: un matrimonio ben riuscito","og_description":"Configurazioni di rete in una Landing Zone: networking centralizzato in ambienti Cloud multi-account su AWS.","og_url":"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/","og_site_name":"Proud2beCloud Blog","article_published_time":"2023-09-15T07:00:00+00:00","article_modified_time":"2023-09-15T08:05:24+00:00","og_image":[{"width":1199,"height":627,"url":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/09\/Copertina-blog-15-09-23_15-09-social-eng.png","type":"image\/png"}],"author":"Riccardo Fragnelli","twitter_card":"summary_large_image","twitter_title":"AWS Landing Zone e networking centralizzato: un matrimonio ben riuscito","twitter_description":"Configurazioni di rete in una Landing Zone: networking centralizzato in ambienti Cloud multi-account su AWS.","twitter_image":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2023\/09\/Copertina-blog-15-09-23_15-09-social-eng.png","twitter_misc":{"Scritto da":"Riccardo Fragnelli","Tempo di lettura stimato":"9 minuti"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/","url":"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/","name":"AWS Landing Zone e networking centralizzato: un matrimonio ben riuscito - Proud2beCloud Blog","isPartOf":{"@id":"https:\/\/blog.besharp.it\/it\/#website"},"datePublished":"2023-09-15T07:00:00+00:00","dateModified":"2023-09-15T08:05:24+00:00","author":{"@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/621a9271823d0abbc1096cd77da47ccc"},"description":"Configurazioni di rete in una Landing Zone: networking centralizzato in ambienti Cloud multi-account su AWS.","breadcrumb":{"@id":"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/#breadcrumb"},"inLanguage":"it-IT","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/blog.besharp.it\/it\/aws-landing-zone-e-networking-centralizzato-un-matrimonio-ben-riuscito\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/blog.besharp.it\/it\/"},{"@type":"ListItem","position":2,"name":"AWS Landing Zone e networking centralizzato: un matrimonio ben riuscito"}]},{"@type":"WebSite","@id":"https:\/\/blog.besharp.it\/it\/#website","url":"https:\/\/blog.besharp.it\/it\/","name":"Proud2beCloud Blog","description":"il blog di beSharp","alternateName":"Proud2beCloud Blog","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.besharp.it\/it\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"it-IT"},{"@type":"Person","@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/621a9271823d0abbc1096cd77da47ccc","name":"Riccardo Fragnelli","image":{"@type":"ImageObject","inLanguage":"it-IT","@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/be24f01e4e529597302dbbab4ad5504f?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/be24f01e4e529597302dbbab4ad5504f?s=96&d=mm&r=g","caption":"Riccardo Fragnelli"},"description":"DevOps @ beSharp I was born on-prem as a Dev before landing on the \u201cCloud side of IT\u201d. With AWS I discovered a whole new branch of IT that fascinates me more and more; I\u2019m always ready for the next big thing! I\u2019m the fussiest man I know on earth and quite lazy. I like spending my free time jumping between video games and RPGs.","url":"https:\/\/blog.besharp.it\/it\/author\/riccardo-fragnelli\/"}]}},"_links":{"self":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts\/6262"}],"collection":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/comments?post=6262"}],"version-history":[{"count":0,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts\/6262\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/media\/6288"}],"wp:attachment":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/media?parent=6262"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/categories?post=6262"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/tags?post=6262"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}