Topologia di rete flat a carico di lavoro singolo

Una rete flat è la topologia di rete più semplice Azure: una rete virtuale con più subnet che ospitano un singolo carico di lavoro. Questo articolo illustra quando usare questo modello e come implementarlo.

Informazioni su questo articolo

Questo articolo descrive la topologia di rete più semplice Azure: una singola rete virtuale con più subnet che ospitano un carico di lavoro. Usare questo modello quando si ha una singola applicazione gestita da un team e non sono necessari servizi condivisi come un firewall centrale o un gateway VPN.

Chi ha bisogno di questo articolo

Leggere questo articolo se:

  • Stai distribuendo il tuo primo carico di lavoro in Azure.
  • Un singolo team è proprietario e gestisce tutte le risorse.
  • Non sono necessari servizi di rete condivisi (firewall, Bastion, gateway) tra più carichi di lavoro.
  • Si vuole che la rete più semplice fornisca comunque l'isolamento e la sicurezza a livello di subnet.

Focus su lift-and-shift: una singola rete virtuale piatta con una subnet per ogni componente è spesso il primo passo giusto per il rehosting di un carico di lavoro in un'unica area geografica.

Ambito di modernizzazione: Usa una rete piatta per un progetto pilota PaaS iniziale o per un singolo carico di lavoro modernizzato e progettarne le subnet in modo che possa evolvere agevolmente verso un'architettura hub-and-spoke quando aggiungi servizi condivisi o una seconda regione.

Focus multi-cloud: usare una rete virtuale piatta come unico punto d’appoggio in Azure durante una migrazione multi-cloud: eseguire prima la migrazione del carico di lavoro, quindi pianificarne lo spazio di indirizzamento e la segmentazione in modo che possa essere integrato in un hub o in una rete WAN virtuale man mano che l’architettura si evolve.

Azure servizi e funzionalità

La topologia di rete flat usa questi servizi di base Azure:

Service Ruolo in questa topologia
Rete virtuale di Azure Fornisce uno spazio di indirizzi privato e isolato per il carico di lavoro. Una rete virtuale ha come ambito una singola area Azure.
Subnet e gruppi di sicurezza di rete Le subnet separano i livelli dell'applicazione. I gruppi di sicurezza di rete filtrano il traffico in ingresso e in uscita a ogni limite della subnet. I gruppi di sicurezza di rete sono con stato: il traffico di ritorno per le connessioni consentite è consentito automaticamente.
Zona Azure DNS privato Fornisce la risoluzione interna dei nomi per le risorse nella rete virtuale. Collegare la zona con la registrazione automatica abilitata in modo che le macchine virtuali ottengano automaticamente i record DNS.
Subnet del gateway(facoltativo) Ospita un gateway VPN o ExpressRoute se è necessaria una singola connessione a una rete locale.

Come scegliere: restare flat o passare a un modello hub-spoke?

Utilizzare la seguente tabella decisionale per determinare se la topologia flat è appropriata per il proprio ambiente o se invece conviene adottare una topologia hub-and-spoke.

Condition Raccomandazione
Carico di lavoro singolo, singolo team, nessun servizio condiviso Rimani in piano: questo articolo è valido
Un secondo carico di lavoro indipendente necessita del proprio isolamento di rete Passare a una topologia hub-spoke
È necessario un firewall condiviso, un gateway VPN o un Azure Bastion tra carichi di lavoro Passare a una topologia hub-spoke
I criteri di sicurezza devono essere gestiti centralmente tra più carichi di lavoro Passare a una topologia hub-spoke

Tip

Se prevedi di aggiungere un secondo workload entro un periodo compreso tra sei e 12 mesi, valuta di iniziare con un'architettura hub-and-spoke fin dal primo giorno. Il sovraccarico è minimo perché si aggiunge una sola rete virtuale aggiuntiva e una connessione di peering. Questo approccio evita una migrazione che causa un'interruzione in un secondo momento.

Considerazioni relative alla progettazione

Focus sulla progettazione di rete flat lift-and-shift

  • Usare una rete virtuale con una subnet per ogni componente dell'applicazione (Web, app, dati) per eseguire il mirroring di un layout tipico a tre livelli locale con riprogettazione minima.
  • Applica gli NSG tra le subnet per ricreare la segmentazione esistente e mantieni lo spazio di indirizzamento allineato agli intervalli dell'infrastruttura locale per evitare sovrapposizioni.
  • Mantenete una struttura piatta quando un singolo team gestisce il carico di lavoro e non servono firewall, gateway o servizi Bastion condivisi.
  • Pianifica il passaggio a un'architettura hub-and-spoke prima di aggiungere un secondo workload, in modo che i servizi condivisi finiscano in un hub anziché essere aggiunti in un secondo momento.

Focus sulla modernizzazione della progettazione di reti piatte

  • Usare una rete flat per un progetto pilota PaaS iniziale o un singolo carico di lavoro modernizzato: posizionare i livelli dell'app nelle subnet e raggiungere Azure PaaS tramite endpoint privati in una subnet dedicata.
  • Riservate in anticipo subnet dedicate per i servizi della piattaforma che aggiungerete, come Application Gateway ed endpoint privati, in modo che la rete possa crescere senza dover riassegnare gli indirizzi IP.
  • Applicare gli NSG e i gruppi di sicurezza per le applicazioni in base al livello, in modo che la segmentazione sia già in atto se il carico di lavoro successivamente diventa uno spoke in un'architettura hub-spoke.
  • Mantenere lo spazio di indirizzamento distinto da quello delle altre regioni e delle altre reti virtuali, in modo da poter configurare il peering o passare in seguito a un hub senza dover rinumerare.

Focus sulla progettazione di reti flat tra cloud

  • Usare una VNet piatta come unico punto di presenza in Azure durante la migrazione tra cloud: distribuire prima il carico di lavoro, quindi aggiungere la connettività da un hub man mano che l’architettura si evolve.
  • Pianificare lo spazio di indirizzi della rete virtuale flat per evitare sovrapposizioni con le RETI VPN AWS e Google Cloud in modo da poter aggiungere IPsec o il routing di interconnessione in un secondo momento senza traduzione.
  • Mantenere la segmentazione per livelli con gli NSG, in modo che il profilo di sicurezza del carico di lavoro venga mantenuto quando diventa uno spoke dietro un hub protetto di rete WAN virtuale.
  • Standardizzare la denominazione e l'assegnazione di tag alle subnet in modo che corrispondano agli altri cloud, in modo che il carico di lavoro rimanga facile da correlare durante e dopo la migrazione.

Prerequisiti

Prima di implementare questa topologia:

  • Una sottoscrizione Azure con autorizzazioni per creare reti virtuali e gruppi di sicurezza di rete.
  • Spazio indirizzi IP pianificato. Uno spazio indirizzi /16 fornisce 65.536 indirizzi, un punto di partenza comune per un singolo carico di lavoro. Azure riserva 5 indirizzi per subnet per uso interno. Per indicazioni dettagliate, vedere Pianificare l'indirizzamento IP.
  • Conoscenza dei livelli dell'applicazione( ad esempio Web, applicazione e dati) in modo da poter eseguirne il mapping alle subnet. Per indicazioni sulla progettazione delle subnet, vedere Progettare reti virtuali e subnet.

Layout di rete

Diagramma che mostra una topologia di rete flat con subnet web, applicazione e livello dati, ognuna protetta da un gruppo di sicurezza di rete, all'interno di una singola rete virtuale.

Una topologia di rete flat segue questa struttura:

  • Una rete virtuale con un singolo spazio indirizzi (ad esempio, 10.0.0.0/16).
  • Più subnet: una per ogni livello dell'applicazione o componente:
    • Subnet del livello Web ,ad esempio 10.0.1.0/24.
    • Subnet del livello applicazione ,ad esempio 10.0.2.0/24.
    • Subnet del livello dati (ad esempio, 10.0.3.0/24).
    • Subnet del gateway (facoltativa, ad esempio 10.0.255.0/27).
  • NSG associati a ogni subnet con regole che consentono solo il traffico necessario per ciascun livello.
  • Una zona DNS privato collegata alla rete virtuale con registrazione automatica abilitata.

Note

Pianificare attentamente gli intervalli di indirizzi IP. Se in un secondo momento si esegue la migrazione a una topologia hub-spoke, le reti virtuali spoke devono avere intervalli CIDR non sovrapposti con l'hub. La scelta di uno schema di indirizzi ben strutturato impedisce ora conflitti durante la migrazione.

Considerazioni relative alla sicurezza

Applicare queste procedure di sicurezza alla rete flat:

  • NSG in ogni subnet. Partire da una configurazione di base che blocca tutto il traffico in ingresso e aggiungere regole specifiche che consentano il traffico legittimo tra i livelli. Ad esempio, consentire HTTPS dal livello Web al livello applicazione e consentire SQL dal livello applicazione al livello dati.
  • Nessun ip pubblico direttamente nelle macchine virtuali. Esporre i servizi tramite un bilanciatore del carico o gateway applicazione. Usare Azure Bastion per l'accesso amministrativo.
  • DNS privato per la risoluzione interna. DNS privato zone impediscono l'esposizione di nomi host interni tramite query DNS pubbliche.
  • Isolamento della subnet del gateway. Se si aggiunge un gateway VPN o ExpressRoute, inserirlo in una subnet dedicata (denominata GatewaySubnet). I gruppi di sicurezza di rete nella subnet del gateway non sono supportati. L'associazione di un gruppo di sicurezza di rete a questa subnet potrebbe causare il malfunzionamento del gateway di rete virtuale.

Importante

Quando si rimuove una regola del gruppo di sicurezza di rete che consente una connessione, le connessioni attive esistenti continuano senza interruzioni. Vengono bloccate solo le nuove connessioni che corrispondono alla regola rimossa.

Gli articoli seguenti forniscono indicazioni più approfondite sugli argomenti correlati:

Ulteriori informazioni

Per altre informazioni sui servizi di Azure usati in questa topologia, vedere:

Passaggi successivi

Tip

Esplorazione da sola? Tornare allo strumento di navigazione di panoramica per trovare l'articolo successivo in base alla funzionalità.

Successivamente, nel viaggio in modalità lift-and-shift:

Progetta la tua topologia hub-and-spoke: la maggior parte delle migrazioni lift-and-shift supera rapidamente i limiti di una rete piatta. Pianificare i servizi condivisi centralizzati fin dall'inizio.

Nel prossimo percorso di modernizzazione:

Progetta la tua topologia hub-and-spoke: i carichi di lavoro modernizzati con più servizi, controlli di sicurezza e team richiedono un'architettura hub-and-spoke fin dal primo giorno.

Il prossimo passo nel tuo percorso multicloud:

Pianificare l'architettura di connettività tra cloud: gli ambienti multi-cloud richiedono un'architettura di transito, non reti flat. Progettare il modello di connettività multicloud.

  • Last updated on