Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Rete
Per il corretto funzionamento delle operazioni di gestione, monitoraggio e assistenza, l'implementazione di Outpost dipende da una connessione resiliente alla relativa area di riferimento AZ. È necessario effettuare il provisioning della rete locale per fornire connessioni di rete ridondanti per ogni rack Outpost e una connettività affidabile verso i punti di ancoraggio nel cloud. AWS Considera anche i percorsi di rete tra i carichi di lavoro delle applicazioni in esecuzione su Outpost e gli altri sistemi locali e cloud con cui comunicano: come indirizzerai questo traffico nella tua rete?
**Topics**
+ [Allegato di rete](network-attachment.md)
+ [Connettività Anchor](anchor-connectivity.md)
+ [Routing dell'applicazione/del carico di lavoro](applicationworkload-routing.md)
# Allegato di rete
Ogni AWS Outposts rack è configurato con top-of-rack switch ridondanti denominati Outpost Networking Devices (). ONDs I server di elaborazione e storage di ogni rack si connettono a entrambi. ONDs È necessario collegare ogni OND a uno switch separato chiamato Customer Networking Device (CND) nel data center per fornire percorsi fisici e logici diversi per ogni rack Outpost. ONDs connettetevi al vostro CNDs con una o più connessioni fisiche utilizzando cavi in fibra ottica e ricetrasmettitori ottici. Le [connessioni fisiche](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#physical-connectivity) sono configurate in collegamenti LAG (Logical [Link Aggregation Group)](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#link-aggregation).
![\[Diagramma che mostra Multi-rack Outpost con allegati di rete ridondanti\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/multi-rack-outpost.png)
I collegamenti da OND a CND sono sempre configurati in un LAG, anche se la connessione fisica è un singolo cavo in fibra ottica. La configurazione dei collegamenti come gruppi LAG consente di aumentare la larghezza di banda del collegamento aggiungendo ulteriori connessioni fisiche al gruppo logico. I link LAG sono configurati come trunk Ethernet IEEE 802.1q per consentire reti separate tra Outpost e la rete locale.
Ogni Outpost dispone di almeno due reti logicamente separate che devono comunicare con o attraverso la rete dei clienti:
+ **Service link network**: alloca gli indirizzi IP del service link ai server Outpost e facilita la comunicazione con la rete locale per consentire ai server di riconnettersi ai punti di ancoraggio Outpost nella regione. Quando si dispone di più implementazioni rack in un unico Outposts logico, è necessario assegnare un Service Link /26 CIDR per ogni rack.
+ **Rete Gateway locale**: consente la comunicazione tra le sottoreti VPC su Outpost e la rete locale tramite Outpost Local Gateway (LGW).
[Queste reti separate si collegano alla rete locale tramite una serie di connessioni IP tramite i collegamenti LAG. point-to-point ](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity) Ogni collegamento LAG da OND a CND è configurato con VLAN IDs, sottoreti IP point-to-point (/30 o /31) e peering eBGP per ogni rete separata (service link e LGW). È necessario considerare i collegamenti LAG, con le relative sottoreti, come connessioni di livello 2 segmentate e instradate di livello 3. point-to-point VLANs Le connessioni IP instradate forniscono percorsi logici ridondanti che facilitano la comunicazione tra le reti separate di Outpost e la rete locale.
![\[Diagramma che mostra il peering dei collegamenti di servizio\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/service-link-peering.png)
![\[Diagramma che mostra il peering del gateway locale\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/page-20-local-gateway-peering.png)
È necessario interrompere i collegamenti LAG di livello 2 (e i relativi VLANs) sugli switch CND collegati direttamente e configurare le interfacce IP e il peering BGP sugli switch CND. Non è necessario colmare il LAG tra gli switch del data center. VLANs Per ulteriori informazioni, consulta [Connettività a livello di rete](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity) nella Guida per l'*AWS Outposts utente*.
All'interno di un Outpost logico multirack, ONDs sono interconnessi in modo ridondante per fornire una connettività di rete ad alta disponibilità tra i rack e i carichi di lavoro in esecuzione sui server. AWS è responsabile della disponibilità della rete all'interno dell'Outpost.
## Pratiche consigliate per un collegamento di rete ad alta disponibilità senza ACE
+ Connect ogni Outpost Networking Device (OND) in un rack Outpost a un Customer Networking Device (CND) separato nel data center.
+ Interrompi i collegamenti di livello 2 VLANs, le sottoreti IP di livello 3 e il peering BGP sugli switch CND (Customer Networking Device) collegati direttamente. Non collegate l'OND al CND tra o attraverso la rete locale. VLANs CNDs
+ Aggiungi collegamenti ai Link Aggregation Groups (LAGs) per aumentare la larghezza di banda disponibile tra Outpost e il data center. Non fate affidamento sulla larghezza di banda aggregata dei diversi percorsi che li attraversano entrambi. ONDs
+ Utilizza i diversi percorsi attraverso la rete ridondante ONDs per fornire una connettività resiliente tra le reti Outpost e la rete locale.
+ Per ottenere una ridondanza ottimale e consentire una manutenzione OND senza interruzioni, consigliamo ai clienti di configurare gli annunci e le politiche BGP come segue:
+ Le apparecchiature di rete del cliente devono ricevere annunci BGP da Outpost senza modificare gli attributi BGP e abilitare BGP in caso di necessità di manutenzione. multipath/load-balancing to achieve optimal inbound traffic flows (from customer towards Outpost). AS-Path prepending is used for Outpost BGP prefixes to shift traffic away from a particular OND/uplink La rete di clienti dovrebbe preferire i percorsi provenienti da Outpost con lunghezza AS-Path 1 rispetto ai percorsi con AS-Path lunghezza 4, ovvero reagire alla prepending di AS-Path.
+ La rete di clienti dovrebbe pubblicizzare prefissi BGP uguali con gli stessi attributi per tutti in Outpost. ONDs Per impostazione predefinita, la rete Outpost bilancia il carico del traffico in uscita (verso il cliente) tra tutti gli uplink. Le politiche di routing vengono utilizzate sul lato Outpost per spostare il traffico lontano da un particolare OND nel caso in cui sia necessaria una manutenzione. Per effettuare questo spostamento del traffico ed eseguire la manutenzione senza interruzioni, ONDs sono necessari tutti gli stessi prefissi BGP da parte del cliente. Quando è necessaria la manutenzione della rete del cliente, consigliamo di utilizzare AS-Path Prepending per allontanare temporaneamente il traffico da un particolare uplink o dispositivo.
## Pratiche consigliate per un collegamento di rete ad alta disponibilità con ACE
Per un'implementazione multirack con quattro o più rack di elaborazione, è necessario utilizzare il rack Aggregation, Core, Edge (ACE), che fungerà da punto di aggregazione della rete per ridurre il numero di collegamenti in fibra verso i dispositivi di rete locali. Il rack ACE fornisce la connettività ONDs a ciascun rack Outposts, quindi AWS sarà responsabile dell'allocazione e della configurazione dell'interfaccia VLAN tra ONDs i dispositivi di rete ACE.
Sono comunque necessari livelli di rete isolati per le reti Service Link e Local Gateway indipendentemente dal fatto che venga utilizzato o meno un rack ACE, che mirano ad avere una sottorete IP VLAN point-to-point (/30 o /31) e una configurazione di peering eBGP per ogni rete separata. Le architetture proposte devono seguire una delle due architetture seguenti:
![\[Dispositivi di rete per due clienti\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/page-22-two-customer-networking-devices.png)
+ Con questa architettura, il cliente dovrebbe disporre di due dispositivi di rete (CND) per interconnettere i dispositivi di rete ACE, garantendo così la ridondanza.
+ Per ogni connessione fisica, è necessario abilitare un LAG (per aumentare la larghezza di banda disponibile tra Outpost e il data center), anche se si tratta di una singola porta fisica, e trasporterà due segmenti di rete, con configurazioni 2 point-to-point VLANs (/30 o /31) ed eBGP tra e. ACEs CNDs
+ In uno stato stazionario, il traffico viene bilanciato in base al pattern to/from the customer network from the ACE layer, 25% traffic distribution across the ACE to customer. In order to allow this behavior, the eBGP peering’s between ACEs and CNDs must have BGP multipath/load Equal-cost Multipath (ECMP), abilitato e sono stati annunciati i prefissi dei clienti con la stessa metrica BGP sulle 4 connessioni peering eBGP.
+ Per ottenere una ridondanza ottimale e consentire una manutenzione OND senza interruzioni, consigliamo ai clienti di seguire questi consigli:
+ Il dispositivo di rete del cliente deve pubblicizzare prefissi BGP uguali con gli stessi attributi per tutti in Outpost. ONDs
+ Il dispositivo di rete del cliente deve ricevere pubblicità BGP da Outpost senza modificare gli attributi BGP e deve abilitare il multipath/load-balancing BGP.
![\[Dispositivi di rete per quattro clienti\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/page-23-four-customer-networking-devices.png)
Con questa architettura, il cliente disporrà di quattro dispositivi di rete (CND) per interconnettere i dispositivi di rete ACE, garantendo ridondanza e la stessa logica di rete VLANs, tra cui eBGP ed ECMP applicabili a un'architettura a 2 CND.
# Connettività Anchor
Un [collegamento al servizio Outpost](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) si collega a punti di ancoraggio pubblici o privati (non entrambi) in una zona di disponibilità (AZ) specifica nella regione madre di Outpost. I server Outpost avviano le connessioni VPN di service link in uscita dai rispettivi indirizzi IP di service link ai punti di ancoraggio nell'anchor AZ. Queste connessioni utilizzano le porte UDP e TCP 443. AWS è responsabile della disponibilità dei punti di ancoraggio nella Regione.
È necessario assicurarsi che gli indirizzi IP del servizio Outpost siano in grado di connettersi attraverso la rete ai punti di ancoraggio dell'Anchor AZ. Gli indirizzi IP del service link non devono comunicare con altri host sulla rete locale.
I punti di ancoraggio pubblici risiedono negli [intervalli IP pubblici](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) della regione (nei blocchi CIDR del EC2 servizio) e sono accessibili tramite Internet o [AWS Direct Connect](https://aws.amazon.com/directconnect/)(DX) interfacce virtuali pubbliche (DX) (). VIFs L'uso di punti di ancoraggio pubblici consente una selezione più flessibile del percorso in quanto il traffico dei collegamenti di servizio può essere instradato su qualsiasi percorso disponibile in grado di raggiungere con successo i punti di ancoraggio sulla rete Internet pubblica.
I punti di ancoraggio privati consentono di utilizzare gli intervalli di indirizzi IP per la connettività di ancoraggio. I punti di ancoraggio privati vengono creati in una [sottorete privata all'interno di un VPC](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#private-connectivity) dedicato utilizzando indirizzi IP assegnati dal cliente. Il VPC viene creato nella risorsa proprietaria della risorsa Outpost e sei responsabile di garantire Account AWS che il VPC sia disponibile e configurato correttamente. [Utilizza una Security Control Policy (SCP) in AWSOrigamiServiceGateway Organizations per impedire agli utenti di eliminare quel Virtual Private Cloud (VPC). È necessario accedere ai punti di ancoraggio privati utilizzando Direct Connect private. VIFs](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-outposts-private-connectivity/)
È necessario fornire percorsi di rete ridondanti tra Outpost e i punti di ancoraggio nella regione con connessioni che terminino su dispositivi separati in più di una posizione. Il routing dinamico deve essere configurato per reindirizzare automaticamente il traffico verso percorsi alternativi in caso di guasto delle connessioni o dei dispositivi di rete. È necessario fornire una capacità di rete sufficiente per garantire che l'errore di un percorso WAN non sovraccarichi i percorsi rimanenti.
Il diagramma seguente mostra tre Outposts con percorsi di rete ridondanti verso il loro AZs ancoraggio e la connettività AWS Direct Connect Internet pubblica. L'Outpost A e l'Outpost B sono ancorati a diverse zone di disponibilità nella stessa regione. L'Outpost A si collega ai punti di ancoraggio privati nella zona AZ 1 della regione 1. L'avamposto B si collega ai punti di ancoraggio pubblici nella zona AZ 2 della regione 1. L'avamposto C si collega agli ancoraggi pubblici in AZ 1 della regione 2.
![\[Diagramma che mostra la connettività di ancoraggio ad alta disponibilità e l'accesso pubblico a Internet AWS Direct Connect\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/highly-available-anchor-connectivity.png)
Outpost A dispone di tre percorsi di rete ridondanti per raggiungere il punto di ancoraggio privato. Sono disponibili due percorsi tramite circuiti Direct Connect ridondanti in un'unica posizione Direct Connect. Il terzo percorso è disponibile tramite un circuito Direct Connect in una seconda posizione Direct Connect. Questo design mantiene il traffico dei collegamenti di servizio di Outpost A sulle reti private e fornisce una ridondanza dei percorsi che consente il guasto di uno qualsiasi dei circuiti Direct Connect o il guasto di un'intera posizione Direct Connect.
Outpost B dispone di quattro percorsi di rete ridondanti per raggiungere il punto di ancoraggio pubblico. Tre percorsi sono disponibili tramite la VIFs fornitura pubblica sui circuiti e le postazioni Direct Connect utilizzati da Outpost A. Il quarto percorso è disponibile tramite la WAN del cliente e la rete Internet pubblica. Il traffico dei link di servizio di Outpost B può essere instradato su qualsiasi percorso disponibile in grado di raggiungere con successo i punti di ancoraggio sulla rete Internet pubblica. L'utilizzo dei percorsi Direct Connect può fornire una latenza più costante e una maggiore disponibilità di larghezza di banda, mentre il percorso Internet pubblico può essere utilizzato per scenari di Disaster Recovery (DR) o di aumento della larghezza di banda.
Outpost C dispone di due percorsi di rete ridondanti per raggiungere il punto di ancoraggio pubblico. Outpost C è distribuito in un data center diverso da Outposts A e B. Il data center di Outpost C non dispone di circuiti dedicati che si collegano alla WAN del cliente. Il data center dispone invece di connessioni Internet ridondanti fornite da due diversi provider di servizi Internet (). ISPs Il traffico dei collegamenti di servizio di Outpost C può essere instradato su una delle reti ISP per raggiungere i punti di ancoraggio sulla rete Internet pubblica. Questo design consente la flessibilità necessaria per instradare il traffico dei collegamenti di servizio su qualsiasi connessione Internet pubblica disponibile. Tuttavia, il end-to-end percorso dipende dalle reti pubbliche di terze parti in cui la disponibilità della larghezza di banda e la latenza di rete variano.
Il percorso di rete tra un Outpost e i relativi punti di ancoraggio dei collegamenti di servizio deve soddisfare le seguenti specifiche di larghezza di banda:
+ 500 Mbps - 1 Gbps di larghezza di banda disponibile per rack Outpost (ad esempio, 3 rack: larghezza di banda disponibile da 1,5 a 3 Gbps)
## Pratiche consigliate per una connettività di ancoraggio ad alta disponibilità
+ Fornisci percorsi di rete ridondanti tra ogni avamposto e i relativi punti di ancoraggio nella regione.
+ Usa i percorsi Direct Connect (DX) per controllare la latenza e la disponibilità della larghezza di banda.
+ [Assicurati che le porte TCP e UDP 443 siano aperte (in uscita) dai blocchi CIDR di Outpost Service Link agli intervalli di indirizzi IP nella regione principale. EC2 ](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) Assicurati che le porte siano aperte su tutti i percorsi di rete.
+ Tieni traccia degli intervalli di indirizzi EC2 IP di Amazon sul tuo firewall se utilizzi un sottoinsieme di intervalli CIDR per la regione.
+ Assicurati che ogni percorso soddisfi i requisiti di disponibilità e latenza della larghezza di banda.
+ Utilizza il routing dinamico per automatizzare il reindirizzamento del traffico in caso di guasti di rete.
+ Prova a instradare il traffico del service link su ogni percorso di rete pianificato per garantire che il percorso funzioni come previsto.
# Routing dell'applicazione/del carico di lavoro
Esistono due percorsi di uscita da Outpost per i carichi di lavoro delle applicazioni:
+ Il percorso del collegamento al servizio: considera che il traffico delle applicazioni competerà con il traffico del piano di controllo Outposts, oltre a limitare l'[MTU](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#service-links) a 1300 byte.
+ Il percorso del gateway locale (LGW): si consideri che la rete locale del cliente consente l'accesso sia alle applicazioni locali che a quelle installate in. Regione AWS
È possibile configurare le tabelle di routing delle sottoreti di Outpost per controllare il percorso da seguire per raggiungere le reti di destinazione. Le rotte indirizzate alla LGW indirizzeranno il traffico fuori dal Local Gateway e verso la rete locale. I percorsi indirizzati ai servizi e alle risorse della Regione, come Internet Gateway, NAT Gateway, Virtual Private Gateway e TGW, utilizzeranno [service link](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) per raggiungere questi obiettivi. Se disponi di una connessione peering VPC con più connessioni VPCs sullo stesso Outpost, il traffico tra di esse VPCs rimane sull'Outpost e non utilizza il collegamento di servizio alla regione. *Per informazioni sul peering VPC, consulta Connect [using VPCs VPC peering nella Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html).*
![\[Diagramma che mostra una visualizzazione del collegamento al servizio Outpost e dei percorsi di rete LGW\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/outpost-service-link-and-lgw-network-paths.png)
Quando si pianifica il routing delle applicazioni, è necessario prestare attenzione a considerare sia il normale funzionamento che il routing limitato e la disponibilità del servizio in caso di guasti di rete. Il percorso Service Link non è disponibile quando un Outpost è disconnesso dalla regione.
È necessario fornire percorsi diversi e configurare il routing dinamico tra Outpost LGW e le applicazioni, i sistemi e gli utenti locali critici. I percorsi di rete ridondanti consentono alla rete di indirizzare il traffico in caso di guasti e garantiscono che le risorse locali siano in grado di comunicare con i carichi di lavoro in esecuzione su Outpost in caso di guasti parziali della rete.
Le configurazioni dei percorsi VPC di Outpost sono statiche. Le tabelle di routing delle subnet vengono configurate tramite Console di gestione AWS CLI e altri strumenti Infrastructure as Code (IaC); tuttavia, non sarà possibile modificare le tabelle di routing della sottorete durante un evento di disconnessione. APIs Dovrai ristabilire la connettività tra Outpost e Region per aggiornare le tabelle di routing. Utilizzate per le normali operazioni gli stessi percorsi che intendete utilizzare durante gli eventi di disconnessione.
Le risorse dell'Outpost possono accedere a Internet tramite il collegamento di servizio e un Internet Gateway (IGW) nella regione o tramite il percorso Local Gateway (LGW). L'instradamento del traffico Internet sul percorso LGW e sulla rete locale consente di utilizzare i punti di ingresso/uscita Internet esistenti in sede e può fornire una latenza inferiore, costi di uscita AWS dei dati più elevati MTUs e ridotti rispetto all'utilizzo del percorso di collegamento del servizio verso un IGW nella regione.
Se l'applicazione deve essere eseguita in locale e deve essere accessibile dalla rete Internet pubblica, è necessario indirizzare il traffico dell'applicazione tramite le connessioni Internet locali verso LGW per raggiungere le risorse su Outpost.
Sebbene sia possibile configurare le sottoreti su un Outpost come le sottoreti pubbliche nella regione, questa può essere una pratica indesiderabile per la maggior parte dei casi d'uso. Il traffico Internet in entrata arriverà attraverso il collegamento del servizio Regione AWS e verrà indirizzato alle risorse in esecuzione su Outpost tramite il collegamento di servizio.
Il traffico di risposta verrà a sua volta instradato tramite il collegamento del servizio e reindirizzato attraverso le connessioni Internet dell' Regione AWS utente. Questo andamento del traffico può aumentare la latenza e comporterà l'addebito di costi per i dati in uscita quando il traffico esce dalla regione per dirigersi verso l'avamposto e quando il traffico di ritorno attraversa la regione ed esce verso Internet. Se l'applicazione può essere eseguita nella regione, quest'ultima è il posto migliore per eseguirla.
Il traffico tra le risorse VPC (nello stesso VPC) seguirà sempre il percorso CIDR VPC locale e verrà instradato tra le sottoreti dai router VPC impliciti.
Ad esempio, il traffico tra un' EC2 istanza in esecuzione su Outpost e un endpoint VPC nella regione verrà sempre instradato tramite il collegamento al servizio.
![\[Diagramma che mostra il routing VPC locale attraverso i router impliciti\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-outposts-high-availability-design/images/local-vpc-routing-through-implicit-routers.png)
## Pratiche consigliate per il routing delle applicazioni e dei carichi di lavoro
+ Se possibile, utilizzate il percorso Local Gateway (LGW) anziché il percorso del collegamento al servizio.
+ Indirizza il traffico Internet sul percorso LGW.
+ Configura le tabelle di routing della sottorete Outpost con un set standard di rotte: verranno utilizzate sia per le normali operazioni che durante gli eventi di disconnessione.
+ Fornisci percorsi di rete ridondanti tra Outpost LGW e le risorse critiche delle applicazioni locali. Utilizza il routing dinamico per automatizzare il reindirizzamento del traffico in caso di guasti di rete locali.