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à.
# Considerazioni sul tipo e sulla progettazione della connettività ibrida
Questa sezione del white paper illustra le considerazioni che influiscono sulle scelte effettuate nella scelta di una rete ibrida a cui connettere gli ambienti locali. AWS Segue un processo logico per supportarvi nella scelta di una soluzione di connettività ibrida ottimale. *Le considerazioni che influiscono sulla progettazione sono suddivise in considerazioni che influiscono sul *tipo di connettività* e considerazioni che influiscono sulla progettazione della connettività.* Le considerazioni sul tipo di connettività ti aiuteranno a decidere se utilizzare una VPN basata su Internet o Direct Connect. Le considerazioni sulla progettazione della connettività ti aiuteranno a decidere come configurare le connessioni.
Vengono trattate le seguenti considerazioni che influiscono sul *tipo di connettività*: tempi di implementazione, sicurezza, SLA, prestazioni e costi. Dopo aver esaminato queste considerazioni e il modo in cui influiscono sulle scelte di progettazione, sarete in grado di decidere se utilizzare una connessione basata su Internet o Direct Connect è consigliato per soddisfare i vostri requisiti.
Vengono trattate le seguenti considerazioni che influiscono sulla *progettazione della connettività*: scalabilità, modello di comunicazione, affidabilità e integrazione SD-WAN di terze parti. Dopo aver esaminato queste considerazioni e il modo in cui influiscono sulle scelte di progettazione, sarete in grado di decidere la progettazione logica ottimale consigliata per soddisfare i vostri requisiti.
La struttura seguente viene utilizzata per discutere e analizzare ciascuna delle considerazioni relative alla selezione e alla progettazione:
+ **Definizione** - Breve definizione di ciò che è la considerazione.
+ **Domande chiave**: fornisce una serie di domande che consentono di raccogliere i requisiti associati alla considerazione.
+ **Capacità da considerare**: soluzioni per soddisfare i requisiti associati alla considerazione.
+ **Albero decisionale**: per alcune considerazioni o un gruppo di considerazioni, viene fornito un albero decisionale per aiutarti a selezionare la soluzione di rete ibrida ottimale.
Le considerazioni relative alla progettazione della rete ibrida sono illustrate in un ordine in cui l'output di una considerazione fa parte dell'input per la considerazione successiva. Come illustrato nella Figura 2, il primo passaggio consiste nel decidere il tipo di connettività, per poi perfezionarlo con le considerazioni relative alla selezione del progetto.
La Figura 2 illustra le due categorie di considerazioni, le singole considerazioni e l'ordine logico in cui le considerazioni sono trattate nelle sottosezioni successive. Queste sono le considerazioni essenziali quando si prende una decisione sulla progettazione di una rete ibrida. Se la progettazione mirata non richiede tutte queste considerazioni, potete concentrarvi sulle considerazioni che si applicano ai vostri requisiti.
![\[Diagramma che mostra le categorie di considerazioni, le considerazioni individuali e l'ordine logico tra di esse\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/consideration-categories.png)
# Selezione del tipo di connettività
Questa sezione illustra le considerazioni che influiscono sul tipo di connettività selezionato per il carico di lavoro. Ciò include il tempo di implementazione, la sicurezzaSLA, le prestazioni e i costi.
**Topics**
+ [Tempo di implementazione](time-to-deploy.md)
+ [Sicurezza](security.md)
+ [Accordo sul livello di servizio () SLA](service-level-agreement-sla.md)
+ [Prestazioni](performance.md)
+ [Costo](cost.md)
# Tempo di implementazione
## Definizione
Il tempo di implementazione può essere un fattore importante nella scelta di un tipo di connettività adatto per un carico di lavoro. A seconda del tipo di connettività e delle ubicazioni locali, la connettività può essere stabilita in poche ore, tuttavia potrebbero essere necessarie settimane o mesi se è necessario installare circuiti aggiuntivi. Ciò influirà sulla decisione dell'utente di utilizzare una connessione basata su Internet, una connessione privata dedicata o una connessione privata ospitata fornita come servizio gestito da un partner. AWS Direct Connect
## Domande chiave
+ Qual è la tempistica richiesta per l'implementazione: ore, giorni, settimane o mesi?
+ Per quanto tempo sarà necessaria la connessione: si tratterà di un progetto di breve durata o di un'infrastruttura permanente?
## Capacità da considerare
Se è necessaria la AWS connettività entro poche ore o giorni, è molto probabile che sia necessario utilizzare una connessione di rete esistente. Ciò significa spesso stabilire una VPN connessione a AWS Internet pubblica. Se un partner AWS DX esistente ti fornisce AWS connettività privata, è possibile fornire una nuova connessione ospitata entro poche ore.
Quando hai giorni o settimane, puoi collaborare con un AWS Direct Connect partner per stabilire una connettività privata con. AWS AWS Direct Connect I partner ti aiutano a stabilire la connettività di rete tra AWS Direct Connect le sedi e il tuo data center, ufficio o ambiente di co-ubicazione. Alcuni [AWS Direct Connect partner](https://aws.amazon.com/directconnect/partners/) sono autorizzati a offrire [connessioni ospitate Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/hosted_connection.html). Le connessioni ospitate possono spesso essere fornite più velocemente delle connessioni dedicate. AWS Direct Connect Il partner fornirà ogni connessione ospitata utilizzando l'infrastruttura esistente collegata alla AWS spina dorsale.
Quando hai diverse settimane o mesi, puoi valutare la possibilità di stabilire una connessione privata dedicata con AWS. I fornitori di servizi e AWS Direct Connect i partner facilitano le connessioni AWS Direct Connect dedicate. È normale che i provider di servizi installino apparecchiature di rete presso la sede del cliente per facilitare una connessione dedicata Direct Connect. A seconda del fornitore di servizi, dell'ubicazione del sito e di altri fattori fisici, l'installazione di una connessione dedicata Direct Connect può richiedere da alcune settimane a qualche mese.
Se le apparecchiature di rete sono già installate nella stessa struttura di colocation in cui si trova la AWS Direct Connect sede, è possibile stabilire rapidamente una connessione AWS Direct Connect dedicata tramite una connessione incrociata presso il sito di co-ubicazione. Dopo aver richiesto la connessione, AWS mette a disposizione una Lettera di autorizzazione e assegnazione della struttura di collegamento (LOA-CFA) da scaricare o invia un'e-mail con una richiesta di ulteriori informazioni. Il LOA - CFA è l'autorizzazione alla AWS connessione ed è richiesta dal provider di rete per ordinare una connessione incrociata.
*Tabella 1 — Confronto tra costi ed efficacia*
| | Connettività basata su Internet | Connessione dedicata DX (apparecchiature esistenti all'interno della sede DX) | Connessione dedicata DX (nuova di zecca) | Connessione ospitata DX (porta esistente con DX Partner) | Connessione ospitata DX (nuova di zecca) |
| --- | --- | --- | --- | --- | --- |
| Durata del provisioning | Da ore a giorni | Giorni | Da diverse settimane a mesi | Da ore a giorni | Da diversi giorni a settimane o mesi |
**Nota**
Le linee guida fornite in materia di tempi di fornitura si basano sull'osservazione del mondo reale e servono solo a titolo illustrativo. Se si prendono in considerazione l'ubicazione del sito, la vicinanza ai punti di connessione diretta e l'infrastruttura preesistente, tutto ciò influirà sui tempi di approvvigionamento. Il tuo AWS Direct Connect partner ti consiglierà l'orario preciso di approvvigionamento.
# Sicurezza
## Definizione
I requisiti di sicurezza influenzeranno il tipo di connettività ibrida. Queste considerazioni includono:
+ Tipo di trasporto: connessione Internet o di rete privata
+ Requisiti di crittografia
## Domande chiave
+ I requisiti e le politiche di sicurezza consentono l'uso di connessioni crittografate su Internet a cui connettersi o impongono l'uso di connessioni di rete private? AWS
+ Quando si utilizzano connessioni di rete private, il livello di rete deve fornire la crittografia in transito?
## Soluzioni tecniche
I requisiti e le politiche di sicurezza potrebbero consentire l'uso di Internet o richiedere l'uso di una connessione di rete privata tra la rete aziendale AWS e quella aziendale. Influiscono anche sulla decisione se la rete deve fornire la crittografia in transito o se è accettabile eseguire la crittografia a livello di applicazione.
Se riesci a sfruttare Internet, AWS Site-to-Site VPN puoi utilizzarlo per creare tunnel crittografati tra la tua rete e Amazon VPCs o AWS Transit Gateway i tuoi account Amazon su Internet. L'estensione della WAN soluzione [SD-](https://en.wikipedia.org/wiki/SD-WAN) a AWS Internet è anche un'opzione se utilizzi una connessione basata su Internet. La sezione Gestita dal cliente VPN e SD- riportata WAN più avanti in questo white paper riporta le considerazioni specifiche relative a SD-. WAN
Se hai bisogno di una connessione di rete privata tra AWS e la tua rete aziendale, ti consigliamo di utilizzare AWS Direct Connect Connessioni dedicate o Connessioni AWS ospitate. Se è richiesta la crittografia in transito su una connessione di rete privata, è necessario stabilire una connessione VPN tramite Direct Connect (su rete pubblica VIF o in transitoVIF) oppure prendere in considerazione l'utilizzo MACsec su una connessione dedicata da 10 Gbps o 100 Gbps.
*Tabella 2 — Esempio di requisiti relativi al tipo di connettività di Automotive Corp.*
| | Site-to-Site VPN | Direct Connect |
| --- | --- | --- |
| Trasporto | Internet | Connessione di rete privata |
| Crittografia in transito | Sì | Richiede S2S VPN su DX, S2S su un transito o VPN su una connessione dedicata da 10 VIF Gbps o 100 MACsec Gbps |
# Accordo sul livello di servizio () SLA
## Definizione
Le organizzazioni aziendali spesso richiedono che un fornitore di servizi fornisca un servizio SLA per ogni servizio consumato dall'organizzazione. L'organizzazione a sua volta si basa sui propri servizi e può offrire ai propri consumatori un. SLA SLAÈ importante in quanto descrive come viene fornito e gestito il servizio e spesso include caratteristiche misurabili specifiche, come la disponibilità. Se il servizio non soddisfa i requisiti definitiSLA, un fornitore di servizi di solito offre la compensazione finanziaria specificata nell'accordo. An SLA definisce il tipo di misura, il requisito e il periodo di misurazione. Ad esempio, fai riferimento alla definizione dell'obiettivo di uptime sotto [AWS Direct Connect SLA](https://aws.amazon.com/directconnect/sla/).
## Domande chiave
+ È necessaria una connessione di connettività ibrida SLA con crediti di servizio?
+ L'intera rete ibrida deve rispettare un obiettivo di uptime?
## Funzionalità da considerare
**Tipo di connettività:** la connettività Internet può essere imprevedibile. Sebbene AWS venga prestata molta attenzione alla presenza di più collegamenti con una serie diversificata diISPs, l'amministrazione di Internet è semplicemente esterna al dominio amministrativo di un singolo provider AWS o al di fuori del dominio amministrativo di un singolo provider. Una volta che il traffico ha lasciato il confine della rete, un provider di servizi cloud può intervenire in misura limitata sulla progettazione degli itinerari e sull'influenza sul traffico. Detto questo, ce n'è uno [AWS Site-to-Site VPN SLA](https://aws.amazon.com/vpn/site-to-site-vpn-sla/)che fornisce obiettivi di disponibilità per gli AWS Site-to-Site VPN endpoint.
AWS [Direct Connect offre una](https://aws.amazon.com/directconnect/sla/) formula SLA con crediti di servizio calcolati come percentuale del totale delle tariffe AWS Direct Connect Port Hour pagate dall'utente per le connessioni applicabili che presentano indisponibilità per il ciclo di fatturazione mensile in cui non SLA è stata soddisfatta. Questo è il trasporto consigliato se SLA necessario. AWS Direct Connect elenca [i requisiti minimi di configurazione specifici](https://aws.amazon.com/directconnect/sla/) per ogni obiettivo di uptime, ad esempio il numero di AWS Direct Connect posizioni, connessioni e altri dettagli di configurazione. Il mancato rispetto dei requisiti significa che non è possibile offrire crediti di servizio nel caso in cui venga definita SLAs l'interruzione del servizio.
È importante sottolineare che, anche se il servizio selezionato per fornire la connettività ibrida è configurato per soddisfare i SLA requisiti, il resto della rete potrebbe non fornire lo stesso livello diSLA. La AWS responsabilità termina nel AWS Direct Connect luogo in cui si trova il AWS Direct Connect porto. Una volta AWS affidato il traffico alla rete dell'organizzazione, non è più responsabilità di AWS. Se utilizzi un provider di servizi tra AWS e la tua rete locale, la connettività tra te e il fornitore di servizi, se applicabile, è soggetta alla connettività SLA tra te e il fornitore di servizi. Tieni presente che l'intera rete ibrida è valida tanto quanto la parte più debole di essa durante la progettazione della connettività ibrida.
AWS Direct Connect i partner offrono AWS Direct Connect connettività. Il partner può offrire un servizio SLA con crediti di servizio in base alla propria offerta di prodotti fino al punto di demarcazione con. AWS L'opzione dovrebbe essere valutata e ulteriormente ricercata direttamente con i partner. APN AWS pubblica [un elenco di partner di consegna convalidati](https://aws.amazon.com/directconnect/partners/).
**Progettazione logica:** oltre al tipo di connettività, è necessario considerare anche altri elementi costitutivi come parte della progettazione generale. Ad esempio, [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/sla/)ha il suoSLA, così come [AWS S2S VPN](https://aws.amazon.com/vpn/site-to-site-vpn-sla/). Potresti utilizzare AWS Transit Gateway for scale e AWS S2S VPN per motivi di sicurezza, ma devi progettare entrambi in modo coerente per avere diritto SLAs a crediti di servizio per ogni rispettivo servizio.
[Consulta i [consigli sulla AWS Direct Connect resilienza](https://aws.amazon.com/directconnect/resiliency-recommendation/) e il kit di strumenti per la resilienza.](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html)
![\[Diagramma che mostra un albero decisionale relativo alle considerazioni SLA\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/sla-decision-tree.png)
# Prestazioni
## Definizione
Esistono diversi fattori che influenzano le prestazioni della rete, come la latenza, la perdita di pacchetti, il jitter e la larghezza di banda. A seconda dei requisiti dell'applicazione, l'importanza di ciascuno di questi fattori può variare.
## Domande chiave
In base ai requisiti dell'applicazione, è necessario identificare e dare priorità ai fattori prestazionali della rete che influiscono sul comportamento dell'applicazione e sull'esperienza utente.
### Larghezza di banda
La *larghezza di banda* si riferisce alla velocità di trasferimento dati di una connessione e viene generalmente misurata in bit al secondo (bps). I megabit al secondo (Mbps) e i gigabit al secondo (Gbps) sono sistemi di scalabilità comuni e sono di base 10 (1.000.000 di bit al secondo = 1 Mbps) rispetto alla base 2 (2^10) utilizzata altrove.
Nel valutare le esigenze di larghezza di banda delle applicazioni, tenete presente che i requisiti di larghezza di banda possono cambiare nel tempo. L'implementazione iniziale nel cloud, le normali operazioni, i nuovi carichi di lavoro e gli scenari di failover possono avere requisiti di larghezza di banda diversi.
Le applicazioni possono avere le proprie considerazioni sulla larghezza di banda. Alcune applicazioni potrebbero richiedere prestazioni deterministiche su una connessione a larghezza di banda elevata, mentre altre possono richiedere sia prestazioni deterministiche che larghezza di banda elevata. Un'applicazione può richiedere una configurazione speciale per utilizzare più flussi di traffico (a volte denominati stream o socket) in parallelo se raggiunge i limiti di larghezza di banda per flusso di traffico, consentendole di utilizzare una parte maggiore della larghezza di banda della connessione. VPNspuò limitare la velocità effettiva a causa dei costi generali di tunneling, dei limiti inferiori o delle limitazioni della larghezza di banda hardware. MTU
### Latenza
La *latenza* è il tempo necessario affinché un pacchetto passi dalla sorgente alla destinazione tramite una connessione di rete e viene generalmente misurata in millisecondi (ms), con requisiti di bassa latenza talvolta espressi in microsecondi (μs). La latenza è una funzione della velocità della luce, quindi la latenza aumenta con la distanza.
I requisiti di latenza delle applicazioni possono assumere forme diverse. Un'applicazione altamente interattiva, come un desktop virtuale, può avere un obiettivo di latenza misurato dal momento in cui un utente esegue un input fino a quando l'utente vede il desktop virtuale reagire a tale input. Le applicazioni Voice over IP (VoIP) possono avere requisiti simili. Un secondo tipo di carico di lavoro da prendere in considerazione sono quelli altamente transazionali, che richiedono una risposta dal server prima di poter continuare. I database o altre forme di archivi di chiave/valori possono essere fortemente influenzati dall'aumento della latenza di rete.
### Jitter
*Jitter* misura la coerenza della latenza di rete e, come la latenza, viene generalmente misurata in millisecondi (ms).
I requisiti di jitter delle applicazioni si trovano in genere nelle applicazioni di streaming in tempo reale, inclusa la distribuzione di video e voce. Queste applicazioni tendono a richiedere che il flusso di dati avvenga a una velocità e un ritardo costanti, con buffer di piccole dimensioni per correggere piccole quantità di jitter.
### Perdita di pacchetti
La *perdita di pacchetti* è la misurazione della percentuale di traffico di rete non erogata. Tutte le reti presentano a volte un certo grado di perdita di pacchetti a causa di forti picchi di traffico, riduzioni di capacità, guasti delle apparecchiature di rete e altri motivi. Pertanto, le applicazioni devono avere una certa tolleranza alla perdita di pacchetti, tuttavia, la quantità che possono tollerare può variare da applicazione a applicazione.
Le applicazioni utilizzate TCP per trasportare il proprio traffico hanno la capacità di correggere la perdita di pacchetti tramite ritrasmissione. Le applicazioni che utilizzano UDP i propri protocolli oltre all'IP devono implementare i propri strumenti per gestire la perdita di pacchetti e possono essere estremamente sensibili a tali sistemi. Un'applicazione Voice over IP può semplicemente inserire il silenzio nella parte della chiamata che ha causato la perdita di pacchetti, anziché tentare una ritrasmissione. Alcune VPN soluzioni includono meccanismi propri per il ripristino in caso di perdita di pacchetti sulla rete utilizzata per trasportare il traffico.
## Funzionalità da prendere in considerazione
Quando sono richieste latenza e velocità di trasmissione prevedibili, AWS Direct Connect è la scelta consigliata, in quanto fornisce prestazioni deterministiche. La larghezza di banda può essere selezionata in base ai requisiti di throughput. AWS se ne consiglia l'utilizzo AWS Direct Connect quando è necessaria un'esperienza di rete più coerente rispetto a quella fornita dalle connessioni basate su Internet. Private VIFs e Transit VIFs supportano i jumbo frame, che possono ridurre il numero di pacchetti attraverso la rete e migliorare la velocità effettiva grazie alla riduzione del sovraccarico. AWS Direct Connect [SiteLink](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-direct-connect-sitelink/)consente di utilizzare la AWS spina dorsale per fornire connettività tra le sedi e può essere abilitato su richiesta. La larghezza di banda utilizzata SiteLink deve essere presa in considerazione per la selezione della larghezza di banda di Direct Connect.
L'utilizzo di un VPN over AWS Direct Connect aggiunge la crittografia. Tuttavia, riduce le MTU dimensioni, il che potrebbe ridurre la produttività. AWS [le VPN funzionalità gestite Site-to-Site (S2S) sono disponibili nella documentazione.AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) Molte postazioni Direct Connection supportano MACsec se la crittografia sulla connessione è il requisito di crittografia principale. MACsecnon ha le stesse MTU o potenziali considerazioni in materia di throughput delle Site-to-Site VPN connessioni. AWS Transit Gateway consente ai clienti di scalare orizzontalmente il numero di VPN connessioni e aumentare la velocità di trasmissione di conseguenza con Equal-cost multi-path routing (). ECMP AWS Site-to-SiteVPNSupporti gestiti che utilizzano Direct Connect Transit VIFs per la connettività privata. AWS Direct Connect Per ulteriori dettagli, consulta la sezione [Private IP VPN con](https://docs.aws.amazon.com/vpn/latest/s2svpn/private-ip-dx.html).
Un'altra opzione è quella di utilizzare un Site-to-Site VPN servizio AWS gestito tramite Internet. Può essere un'opzione interessante grazie al basso costo ed è ampiamente disponibile. Tuttavia, tieni presente che le prestazioni su Internet sono le migliori. Gli eventi meteorologici su Internet, la congestione e l'aumento dei periodi di latenza possono essere imprevedibili. AWS offre una soluzione con [AWS Accelerated S2S VPN](https://aws.amazon.com/blogs/architecture/improve-vpn-network-performance-of-aws-hybrid-cloud-with-global-accelerator/), che può mitigare alcuni degli aspetti negativi dell'utilizzo di un percorso Internet. Accelerated S2S VPN utilizza AWS Global Accelerator, che consente al VPN traffico di entrare nella AWS rete il prima possibile e il più vicino possibile al dispositivo gateway del cliente. Ciò ottimizza il percorso di rete, utilizzando la rete AWS globale priva di congestione, per indirizzare il traffico verso l'endpoint che offre le migliori prestazioni. È possibile utilizzare VPN connessioni accelerate per evitare interruzioni di rete che possono verificarsi quando il traffico viene instradato sulla rete Internet pubblica.
# Costo
## Definizione
Nel cloud, il costo della connettività ibrida include il costo delle risorse fornite e dell'utilizzo. Il costo delle risorse assegnate viene misurato in unità di tempo, di solito ogni ora. L'utilizzo è per il trasferimento e l'elaborazione dei dati, di solito misurato in gigabyte (GB). Gli altri costi includono il costo della connettività al punto di presenza della AWS rete. Se la rete si trova all'interno della stessa struttura di colocation, il costo potrebbe essere inferiore a quello di una connessione incrociata. Se la rete si trova in una posizione diversa, saranno coinvolti i costi di un provider di servizi o di un partner APN Direct Connect.
## Domande chiave
+ Quanti dati prevedi di inviare AWS ogni mese dalla tua struttura e da Internet?
+ Quanti dati prevedi di inviare AWS ogni mese alla tua struttura e a Internet?
+ Con che frequenza cambieranno questi importi?
+ Cosa cambia in uno scenario di fallimento?
## Capacità da considerare
Se desideri eseguire carichi di lavoro che richiedono molta larghezza di banda AWS, AWS Direct Connect puoi ridurre i costi di AWS rete in due modi. Innanzitutto, trasferendo AWS direttamente i dati da e verso, è possibile ridurre i costi della larghezza di banda pagati al provider di servizi Internet. In secondo luogo, tutti i dati trasferiti tramite la connessione dedicata vengono addebitati alla velocità di trasferimento AWS Direct Connect dati ridotta, anziché alle tariffe di trasferimento dati Internet: consulta la [pagina dei prezzi di Direct Connect](https://aws.amazon.com/directconnect/pricing/) per i dettagli.
AWS Direct Connect consente l'utilizzo di AWS Direct Connect SiteLink per interconnettere i siti tramite la AWS backbone: consulta [il blog di SiteLink lancio](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-direct-connect-sitelink/) per ulteriori informazioni. L'utilizzo di questa funzionalità comporta i normali costi di trasferimento dati Direct Connect, oltre a una tariffa oraria SiteLink abilitata. È possibile abilitare e disabilitare SiteLink su richiesta e può essere una buona opzione per scenari di errore che coinvolgono Internet o la connettività di rete privata.
Se utilizzi un provider di servizi di rete per la connettività tra l'ambiente locale e una posizione Direct Connect, la tua capacità e il tempo necessari per modificare gli impegni relativi alla larghezza di banda dipendono dal contratto stipulato con il fornitore di servizi.
La AWS spina dorsale è in grado di distribuire il traffico verso qualsiasi destinazione, Regione AWS tranne la Cina, da qualsiasi punto di presenza AWS della rete. Questa funzionalità presenta molti vantaggi tecnici rispetto all'utilizzo di Internet per l'accesso remoto Regioni AWS, ma ha un costo: consulta la [pagina dei prezzi di EC2 Data Transfer](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer) per i dettagli. Se [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/pricing/)nel percorso di traffico è presente un elemento, ciò comporta un aumento del costo di elaborazione dei dati per GB, tuttavia, se si utilizza il peering interregionale tra due gateway di transito, l'elaborazione dei dati del Transit Gateway viene fatturata una sola volta.
Il design ottimale delle applicazioni mantiene l'elaborazione dei dati entro i limiti imposti AWS e riduce al minimo i costi non necessari in uscita. L'accesso ai dati è gratuito. AWS
**Nota**
Come parte della soluzione di connettività complessiva, oltre al costo della AWS connessione, è necessario considerare anche il costo della end-to-end connettività, compresi i costi del provider di servizi, le connessioni incrociate, i rack e le apparecchiature all'interno della sede DX (se necessario).
Se non sei sicuro di dover utilizzare Internet o una connessione privata, calcola un punto di pareggio che AWS Direct Connect diventi meno costoso rispetto all'utilizzo di Internet. Se il volume di dati significa che AWS Direct Connect è meno costoso e si richiede una connettività permanente, AWS Direct Connect è la scelta di connettività ottimale.
Se la connettività è temporanea e Internet soddisfa altri requisiti, può essere più economico utilizzare AWS S2S VPN su Internet a causa dell'elasticità di Internet. Tieni presente che ciò richiede una connettività Internet sufficiente dalla rete locale.
Se ti trovi all'interno di una struttura che dispone di AWS Direct Connect (l'elenco è [disponibile sul sito Web di Direct Connect](https://aws.amazon.com/directconnect/locations/)), puoi stabilire una connessione incrociata a AWS. Ciò significa utilizzare connessioni dedicate a 1,10 o 100 Gbps. AWS Direct Connect i partner offrono più opzioni di larghezza di banda e capacità inferiori, il che può ottimizzare i costi di connettività. Ad esempio, puoi iniziare con una connessione ospitata da 50 Mbps anziché da una connessione dedicata da 1 Gbps.
Con AWS Transit Gateway, puoi condividere le tue connessioni VPN e Direct Connect con moltiVPCs. I costi sono calcolati in base al numero di connessioni effettuate AWS Transit Gateway all'ora e alla quantità di traffico in entrata AWS Transit Gateway, ma semplifica la gestione e riduce il numero di VPN connessioni VIFs necessarie e necessarie. I vantaggi e i risparmi sui costi derivanti da un minore sovraccarico operativo possono facilmente superare i costi aggiuntivi dell'elaborazione dei dati. Facoltativamente, è possibile prendere in considerazione un progetto che AWS Transit Gateway si colloca lungo il percorso di traffico per la maggior parteVPCs, ma non per tutti. Questo approccio consente di evitare i costi di elaborazione dei AWS Transit Gateway dati nei casi d'uso in cui è necessario trasferire grandi quantità di dati. AWS Consultate la sezione Modelli di connettività per ulteriori dettagli su questo design. Un altro approccio consiste nell'utilizzare AWS Direct Connect come percorso principale AWS S2S VPN su Internet come percorso di backup/failover. Sebbene tecnicamente fattibile e molto conveniente, questa soluzione presenta degli svantaggi tecnici (discussi nella sezione Affidabilità di questo white paper) e può essere più difficile da gestire. AWS [non lo consiglia per carichi di lavoro altamente critici o critici](https://aws.amazon.com/directconnect/resiliency-recommendation/).
L'approccio finale è gestito dal cliente VPN o WAN distribuito tramite SD nelle EC2 istanze Amazon. Questo può essere più economico su larga scala se ci sono da decine a centinaia di siti rispetto a S2S. AWS VPN Tuttavia, è necessario prendere in considerazione i costi generali di gestione, i costi di licenza e il costo EC2 delle risorse per ogni appliance virtuale.
## Matrice decisionale
*Tabella 3 — Esempi di input per la progettazione della connettività automobilistica di Example Corp.*
| Categoria | Gestito dal cliente VPN o SD- WAN | AWS S2S VPN | AWS S2S accelerato VPN | AWS Direct Connect Connessione ospitata | AWS Direct Connect Connessione dedicata |
| --- | --- | --- | --- | --- | --- |
| Richiede una connessione a Internet | Sì | Sì | Sì | No | No |
| Costo delle risorse fornite | EC2licenze di istanze e software | [AWS S2S VPN](https://aws.amazon.com/vpn/pricing/) | [AWS[S2S e Global VPN Accelerator AWS](https://aws.amazon.com/global-accelerator/pricing/)](https://aws.amazon.com/vpn/pricing/) | [Parte del costo della porta in termini di capacità applicabile](https://aws.amazon.com/directconnect/pricing/) | [Costo della porta dedicata](https://aws.amazon.com/directconnect/pricing/) |
| Costo del trasferimento dei dati | Tariffa Internet | Tariffa Internet o tariffa Direct Connect | Internet con trasferimento dati premium | Tariffa Direct Connect | Tariffa Direct Connect |
| Gateway di transito | Facoltativo | Facoltativo | Richiesto | Facoltativo | Facoltativo |
| AWS Costo di elaborazione dei dati | N/D | Solo con AWS Transit Gateway | Sì | Solo con AWS Transit Gateway | Solo con AWS Transit Gateway |
| Può essere riutilizzato AWS Direct Connect? | Sì | Sì | No | N/D | N/D |
# Selezione del design della connettività
Questa sezione del white paper illustra le considerazioni che influiscono sulla scelta del design della connettività. La progettazione della connettività include gli aspetti logici e le modalità di progettazione e ottimizzazione dell'affidabilità della connettività ibrida.
Verranno trattate le seguenti considerazioni: scalabilità, modelli di connettività, affidabilità, gestione dal cliente VPN e SD-. WAN
**Topics**
+ [Scalabilità](scalability.md)
+ [Modelli di connettività](connectivity-models.md)
+ [Affidabilità](reliability.md)
+ [Gestito dal cliente VPN e SD- WAN](customer-managed-vpn-and-sd-wan.md)
# Scalabilità
## Definizione
La scalabilità si riferisce alla capacità della soluzione di connettività di crescere ed evolversi nel tempo al variare delle esigenze.
Quando si progetta una soluzione, è necessario considerare le dimensioni attuali e la crescita prevista. Questa crescita può essere una crescita organica o può essere correlata a una rapida espansione, ad esempio negli scenari di fusione e acquisizione.
Nota: a seconda dell'architettura della soluzione mirata, potrebbe non essere necessario prendere in considerazione tutti gli elementi precedenti. Tuttavia, possono fungere da elementi fondamentali per identificare i requisiti di scalabilità delle soluzioni di rete ibride più comuni. Questo white paper si concentra sulla selezione e sulla progettazione della connettività ibrida. Si consiglia di considerare anche la scala della connettività ibrida rispetto all'VPCarchitettura di rete. Per ulteriori informazioni, consulta il white [paper Creazione di un'infrastruttura VPC AWS multirete scalabile e sicura](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html).
## Domande chiave
+ Qual è il numero attuale e previsto di VPCs cui è necessaria la connettività al sito o ai siti locali?
+ Sono VPCs distribuiti in una Regione AWS o più regioni?
+ A quanti siti locali è necessario connettersi? AWS
+ Quanti dispositivi gateway per i clienti (in genere router o firewall) avete per sito a cui dovete connettervi? AWS
+ Quanti percorsi dovrebbero essere pubblicizzati su Amazon VPCs e qual è il numero di percorsi previsti che verranno ricevuti da Amazon AWS ?
+ È necessario aumentare la larghezza di banda AWS nel tempo?
## Capacità da considerare
La scalabilità è un fattore importante nella progettazione della connettività ibrida. A quel punto, la sezione successiva incorporerà la scala come parte della progettazione del modello di connettività mirato.
Di seguito sono riportate le best practice consigliate per ridurre al minimo la complessità di scala della progettazione della connettività di rete ibrida:
+ È necessario utilizzare il riepilogo dei percorsi per ridurre il numero di percorsi pubblicizzati e ricevuti da. AWS Pertanto, lo schema di indirizzamento IP deve essere progettato per massimizzare l'uso del riepilogo delle rotte. L'ingegneria del traffico è una considerazione generale fondamentale. Per ulteriori informazioni sull'ingegneria del traffico, consulta la sottosezione Ingegneria del traffico nella sezione [Affidabilità](reliability.md).
+ Riduci al minimo il numero di sessioni di BGP peering utilizzando DXGW with VGW or AWS Transit Gateway, laddove una singola BGP sessione può fornire connettività a più sessioni. VPCs
+ Prendi in considerazione il cloud WAN quando è necessario connettere più Regioni AWS siti locali.
# Modelli di connettività
## Definizione
Il modello di connettività si riferisce al modello di comunicazione tra le reti locali e le risorse cloud in. AWS Puoi distribuire risorse cloud all'interno di un Amazon VPC all'interno di una Regione AWS o più VPCs regioni, nonché AWS servizi che hanno un endpoint pubblico in una o più regioni Regioni AWS, come Amazon S3 e DynamoDB.
## Domande chiave
+ È necessaria l'VPCintercomunicazione all'interno di una regione e tra le regioni?
+ È necessario accedere agli endpoint AWS pubblici direttamente dall'ambiente locale?
+ È necessario accedere ai AWS servizi utilizzando gli VPC endpoint dall'ambiente locale?
## Funzionalità da considerare
Di seguito sono riportati alcuni degli scenari di modelli di connettività più comuni. Ogni modello di connettività copre requisiti, attributi e considerazioni.
Nota: come evidenziato in precedenza, questo white paper è incentrato sulla connettività ibrida tra reti locali e. AWS Per ulteriori dettagli sulla progettazione dell'interconnessioneVPCs, consulta il white paper [Costruire un'infrastruttura multirete scalabile e sicura](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html). VPC AWS
**Topics**
+ [Definizione](#definition-con)
+ [Domande chiave](#key-questions-con)
+ [Funzionalità da considerare](#capabilities-to-consider-con)
+ [AWS Accelerata: singola Site-to-Site VPN AWS Transit Gateway Regione AWS](aws-accelerated-site-to-site-vpn-aws-transit-gateway-single-aws-region.md)
+ [AWS DX: DXGW conVGW, Single Region](aws-dx-dxgw-with-vgw-single-region.md)
+ [AWS DX: DXGW con multiregioni VGW e peering pubblico AWS](aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.md)
+ [AWS DX: DXGW con multiregioni AWS Transit Gateway e peering pubblico AWS](aws-dx-dxgw-with-aws-transit-gateway-multi-regions-and-aws-public-peering.md)
+ [AWS DX: DXGW con AWS Transit Gateway più regioni (più di 3)](aws-dx-dxgw-with-aws-transit-gateway-multi-regions-more-than-3.md)
# AWS Accelerata: singola Site-to-Site VPN AWS Transit Gateway Regione AWS
**Questo modello è composto da:**
+ Singola Regione AWS.
+ AWS Site-to-SiteVPNConnessione gestita con AWS Transit Gateway.
+ Accelerata VPN abilitata.
![\[Diagramma che mostra AWS Managed VPN — AWS Transit Gateway, Single Regione AWS\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/managed-vpn-tg-single-region.png)
**Attributi del modello di connettività:**
+ Offri la possibilità di stabilire VPN connessioni ottimizzate sulla rete Internet pubblica utilizzando [ Site-to-SiteVPNconnessioni AWS accelerate](https://docs.aws.amazon.com/vpn/latest/s2svpn/accelerated-vpn.html).
+ Offri la possibilità di ottenere una maggiore larghezza di banda di VPN connessione configurando più VPN tunnel con. ECMP
+ Può essere utilizzato per la connessione da più siti remoti.
+ Offre un failover automatizzato con routing dinamico ()BGP.
+ Con AWS Transit Gateway connected toVPCs, tutte le persone connesse VPCs possono utilizzare le stesse VPN connessioni. Puoi anche controllare il modello di comunicazione desiderato tra i seguentiVPCs, per maggiori informazioni consulta [How Transit Gateway Work](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html).
+ Offre opzioni di progettazione flessibili per integrare dispositivi di sicurezza di terze parti e dispositivi WAN virtuali SD con AWS Transit Gateway. Vedi [Sicurezza di rete centralizzata per il VPC-to-VPC traffico e in locale](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-network-security-for-vpc-to-vpc-and-on-premises-to-vpc-traffic.html). VPC
**Considerazioni sulla scalabilità:**
+ Fino a 50 Gbps di larghezza di banda con più IPsec tunnel e ECMP configurati (ogni flusso di traffico sarà limitato alla larghezza di banda massima per tunnel). VPN
+ È VPCs possibile [collegarne migliaia](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-quotas.html) per. AWS Transit Gateway
+ Fai riferimento alle [Site-to-Site VPNquote](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-limits.html) per altri limiti di scala, come il numero di rotte.
**Altre considerazioni:**
+ I costi di AWS Transit Gateway elaborazione aggiuntivi per il trasferimento dei dati tra il data center locale e. AWS
+ Non è VPC possibile fare riferimento ai gruppi di sicurezza di un telecomando AWS Transit Gateway , ma ciò è supportato dal VPC peering.
# AWS DX: DXGW conVGW, Single Region
**Questo modello è composto da:**
+ Singola Regione AWS.
+ Doppie AWS Direct Connect connessioni a postazioni DX indipendenti.
+ AWS DXGWdirettamente collegato all'VPCsutilizzoVGW.
+ Utilizzo opzionale di AWS Transit Gateway per l'VPCintercomunicazione.
![\[Diagramma che mostra AWS DX — DXGW withVGW, Single Regione AWS\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/dxgw-with-vgw-single-region.png)
**Attributi del modello di connettività:**
+ Offre la possibilità di connettersi a VPCs connessioni DX in altre regioni in futuro.
+ Offre un failover automatizzato con routing dinamico (). BGP
+ Con AWS Transit Gateway puoi controllare il modello di comunicazione desiderato tra i. VPCs Per ulteriori informazioni, consulta [Come funzionano i gateway di transito](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html).
**Considerazioni sulla scalabilità:**
Fai riferimento alle [AWS Direct Connect quote](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html) per ulteriori informazioni su altri limiti di scala, come il numero di prefissi supportati, il numero VIFs per tipo di connessione DX (dedicata, ospitata). Alcune considerazioni chiave:
+ La BGP sessione privata VIF può pubblicizzare fino a 100 percorsi ciascuno per IPv4 e. IPv6
+ VPCsÈ possibile collegarne fino a 20 per DXGW singola BGP sessione. Se VPCs sono necessari più di 20, è DXGWs possibile aggiungerne altri per facilitare la connettività su larga scala oppure prendere in considerazione l'utilizzo dell'integrazione Transit Gateway.
+ Se necessario AWS Direct Connect, è possibile aggiungere altri messaggi.
**Altre considerazioni:**
+ Non comporta i AWS Transit Gateway relativi costi di elaborazione per il trasferimento di dati tra reti locali AWS e tra reti locali.
+ Non è VPC possibile fare riferimento ai gruppi di sicurezza di un telecomando AWS Transit Gateway (è necessario il peering). VPC
+ VPCil peering può essere utilizzato anziché AWS Transit Gateway per facilitare la comunicazione tra iVPCs, tuttavia ciò aggiunge complessità operativa per creare e gestire il VPC point-to-point peering di grandi numeri su larga scala.
+ Se non è richiesta l'VPCintercomunicazione, in questo modello di connettività non è necessario AWS Transit Gateway né il VPC peering né il peering.
# AWS DX: DXGW con multiregioni VGW e peering pubblico AWS
**Questo modello è composto da:**
+ Più data center locali con doppie connessioni a AWS.
+ Doppie AWS Direct Connect connessioni a postazioni DX indipendenti.
+ AWS DXGWcollegato direttamente a più di 10 VPCs utilizziVGW, fino a 20 VPCs utilizziVGW.
+ Utilizzo opzionale di AWS Transit Gateway per la comunicazione interregionale VPC e interregionale.
![\[Diagramma che mostra AWS DX: DXGW conVGW, Multi-Regioni e Pubblico VIF\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/dxgw-with-vgw-multi-region-public-vif.png)
**Attributi del modello di connettività:**
+ AWS DXGWcollegato direttamente a più di 10 VPCs VGW utilizzandone fino a 20 VPCsVGW.
+ AWS DX public VIF viene utilizzato per accedere a servizi AWS pubblici, come Amazon S3, direttamente tramite AWS le connessioni DX.
+ Offri la possibilità di connetterti a VPCs connessioni DX in altre regioni in futuro.
+ VPCComunicazione interregionale VPC e interregionale facilitata dal peering del Transit AWS Transit Gateway Gateway.
**Considerazioni sulla scala:**
Fai riferimento alle [AWS Direct Connect quote](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html) per ulteriori informazioni su altri limiti di scala, come il numero di prefissi supportati, il numero VIFs per tipo di connessione DX (dedicata, ospitata). Alcune considerazioni chiave:
+ La BGP sessione privata VIF può pubblicizzare fino a 100 percorsi ciascuno per IPv4 e. IPv6
+ VPCsÈ possibile connetterne fino a 20 per DXGW ogni BGP sessione privataVIF, fino a 30 VIFs per sessione privata. DXGW
+ Se lo desideri, puoi aggiungere altri AWS Direct Connect messaggi.
**Altre considerazioni:**
+ Non comporta i AWS Transit Gateway relativi costi di elaborazione per il trasferimento di dati tra reti locali AWS e tra reti locali.
+ I gruppi di sicurezza di un telecomando VPC non possono essere referenziati da AWS Transit Gateway (è necessario il peering). VPC
+ VPCil peering può essere utilizzato anziché AWS Transit Gateway per facilitare la comunicazione tra iVPCs, tuttavia ciò aggiungerà complessità operativa per creare e gestire il VPC point-to-point peering di grandi numeri su larga scala.
+ Se non è richiesta l'VPCintercomunicazione, in questo modello di connettività non è necessario AWS Transit Gateway né il VPC peering né il peering.
# AWS DX: DXGW con multiregioni AWS Transit Gateway e peering pubblico AWS
**Questo modello è composto da:**
+ Multiplo Regioni AWS.
+ Doppie AWS Direct Connect connessioni a postazioni DX indipendenti.
+ Singolo data center locale con doppie connessioni a. AWS
+ AWS DXGWcon AWS Transit Gateway.
+ Scala elevata VPCs per regione.
![\[Diagramma che mostra AWS DX: DXGW con AWS Transit Gateway, Multi-Regioni e Pubblico AWS VIF\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/dxgw-with-tg-multi-region-public-peering.png)
**Attributi del modello di connettività:**
+ AWS DX public VIF viene utilizzato per accedere a risorse AWS pubbliche come S3 direttamente tramite le connessioni AWS DX.
+ Offri la possibilità di connetterti VPCs e/o connessioni DX in altre regioni in futuro.
+ Con AWS Transit Gateway connected toVPCs, è possibile ottenere una connettività mesh totale o parziale tra. VPCs
+ VPCComunicazione interregionale VPC e interregionale facilitata dal peering. AWS Transit Gateway
+ Offre opzioni di progettazione flessibili con cui integrare dispositivi di sicurezza e SDWAN virtuali di terze parti. AWS Transit Gateway Vedi: [Sicurezza di rete centralizzata per il VPC-to-VPC traffico e in locale](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-network-security-for-vpc-to-vpc-and-on-premises-to-vpc-traffic.html). VPC
**Considerazioni sulla scalabilità:**
+ Il numero di rotte da e verso AWS Transit Gateway è limitato al numero massimo supportato di rotte su un transito VIF (i numeri in entrata e in uscita variano). Fai riferimento alle [AWS Direct Connect quote](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html) per ulteriori informazioni sui limiti di scala e sul numero di rotte supportato e. VIFs
+ Scalabilità fino a AWS Transit Gateway migliaia VPCs per BGP sessione singola.
+ Transito singolo VIF per AWS DX.
+ Se necessario, è possibile aggiungere ulteriori connessioni AWS DX.
**Altre considerazioni:**
+ Comporta costi di AWS Transit Gateway elaborazione aggiuntivi per il trasferimento dei dati tra AWS e il sito locale.
+ I gruppi di sicurezza di un telecomando VPC non possono essere referenziati da AWS Transit Gateway (è necessario VPC il peering).
+ VPCil peering può essere utilizzato anziché AWS Transit Gateway per facilitare la comunicazione tra iVPCs, tuttavia ciò aggiungerà complessità operativa per creare e gestire il VPC point-to-point peering di grandi numeri su larga scala.
# AWS DX: DXGW con AWS Transit Gateway più regioni (più di 3)
**Questo modello è composto da:**
+ Multiplo Regioni AWS (più di 3).
+ Due data center locali.
+ Doppie AWS Direct Connect connessioni verso sedi DX indipendenti per regione.
+ AWS DXGWcon AWS Transit Gateway.
+ Scala elevata VPCs per regione.
+ Maglia completa di scrutinio tra AWS Transit Gateway s.
![\[Diagramma che mostra AWS DX AWS Transit Gateway, DXGW con più regioni (più di tre)\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/dxgw-with-tg-multi-region.png)
**Attributi del modello di connettività:**
+ Sovraccarico operativo più basso.
+ AWS DX public VIF viene utilizzato per accedere a risorse AWS pubbliche, come S3, direttamente tramite le AWS connessioni DX.
+ Offri la possibilità di connetterti a VPCs connessioni DX in altre regioni in futuro.
+ Con AWS Transit Gateway connected toVPCs, è possibile ottenere una connettività mesh completa o parziale tra. VPCs
+ La VPC comunicazione interregionale è facilitata dal peering. AWS Transit Gateway
+ Offre opzioni di progettazione flessibili con cui integrare dispositivi di sicurezza e SDWAN virtuali di terze parti. AWS Transit Gateway Vedi: [Sicurezza di rete centralizzata per il VPC-to-VPC traffico e in locale](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-network-security-for-vpc-to-vpc-and-on-premises-to-vpc-traffic.html). VPC
**Considerazioni sulla scalabilità:**
+ Il numero di rotte da e verso AWS Transit Gateway è limitato al numero massimo supportato di rotte su un transito VIF (i numeri in entrata e in uscita variano). Fai riferimento alle [AWS Direct Connect quote](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html) per ulteriori informazioni sui limiti di scala. Se necessario, prendi in considerazione la possibilità di riepilogare i percorsi per ridurne il numero.
+ Scalabilità fino a AWS Transit Gateway migliaia VPCs per BGP sessione per sessione DXGW (supponendo che le prestazioni fornite dalle connessioni AWS DX fornite siano sufficienti).
+ È possibile connettere fino a sei AWS Transit Gateway secondi per volta. DXGW
+ Se è necessario collegare più di tre regioni utilizzando AWS Transit Gateway, ne DXGWs sono necessarie altre.
+ Transito singolo VIF per AWS DX.
+ Se necessario, è possibile aggiungere ulteriori connessioni AWS DX.
**Altre considerazioni:**
+ Comporta costi di AWS Transit Gateway elaborazione aggiuntivi per il trasferimento dei dati tra il sito locale e. AWS
+ I gruppi di sicurezza di un telecomando VPC non possono essere referenziati da AWS Transit Gateway (è necessario VPC il peering).
+ VPCil peering può essere utilizzato invece che AWS Transit Gateway per facilitare la comunicazione tra iVPCs, tuttavia ciò aggiungerà complessità operativa per creare e gestire il VPC point-to-point peering di grandi numeri su larga scala.
Il seguente albero decisionale copre le considerazioni sulla scalabilità e sul modello di comunicazione:
![\[Diagramma che mostra la scalabilità e l'albero decisionale del modello di comunicazione\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/scalability-communication-model-decision-tree.png)
**Nota**
Se il tipo di connessione selezionato èVPN, in genere, tenuto conto delle prestazioni, è necessario decidere se il punto di VPN terminazione sia una connessione AWS VGW AWS Transit Gateway AWS VPN S2S. Se non l'hai ancora fatto, puoi prendere in considerazione il modello di comunicazione richiesto tra i e il numero di connessioni necessarie VPC per il VPN collegamento alle connessioni per aiutarti a prendere la decisione. VPC
# Affidabilità
## Definizione
L'affidabilità si riferisce alla capacità di un servizio o di un sistema di svolgere la funzione prevista quando richiesto. L'affidabilità di un sistema può essere misurata in base al livello della sua qualità operativa entro un determinato periodo di tempo. Paragonalo alla resilienza, che si riferisce alla capacità di un sistema di riprendersi da interruzioni dell'infrastruttura o del servizio, in modo dinamico e affidabile.
Per maggiori dettagli su come la disponibilità e la resilienza vengono utilizzate per misurare l'affidabilità, consulta il Reliability [Pillar del Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) AWS Framework.
## Domande chiave
### Disponibilità
La disponibilità è la percentuale di tempo per cui un carico di lavoro è disponibile per l'uso. Gli obiettivi comuni includono il 99% (3,65 giorni di inattività consentiti all'anno), il 99,9% (8,77 ore) e il 99,99% (52,6 minuti), con un'abbreviazione del numero di nove nella percentuale («due nove» per il 99%, «tre nove» per il 99,9% e così via). La disponibilità della soluzione di rete tra AWS e il data center locale può essere diversa dalla disponibilità complessiva della soluzione o dell'applicazione.
Le domande chiave sulla disponibilità di una soluzione di rete includono:
+ Le mie AWS risorse possono continuare a funzionare se non riescono a comunicare con le mie risorse locali? Viceversa?
+ Devo considerare i tempi di inattività programmati per la manutenzione pianificata inclusi o esclusi dalla metrica di disponibilità?
+ Come posso misurare la disponibilità del livello di rete, indipendentemente dallo stato generale delle applicazioni?
La [sezione Availability](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) del Well-Architected Framework Reliability Pillar contiene suggerimenti e formule per la disponibilità dei calcoli.
### Resilienza
La resilienza è la capacità di un carico di lavoro di ripristinarsi a seguito di interruzioni dell'infrastruttura o del servizio, acquisire in modo dinamico le risorse di calcolo per soddisfare la domanda e mitigare le interruzioni, quali configurazioni errate o problemi di rete transitori. Se un componente di rete ridondante (collegamento, dispositivi di rete e così via) non dispone di una disponibilità sufficiente per fornire da solo la funzione prevista, ha una bassa resilienza ai guasti. La conseguenza è un'esperienza utente scadente e degradata.
Le domande chiave per la resilienza di una soluzione di rete includono:
+ Quanti guasti simultanei e discreti devo consentire?
+ Come posso ridurre i singoli punti di errore sia con le soluzioni di connettività che con la mia rete interna?
+ Qual è la mia vulnerabilità agli eventi Distributed Denial of Service (DDoS)?
## Soluzione tecnica
Innanzitutto, è importante notare che non tutte le soluzioni di connettività di rete ibrida richiedono un elevato livello di affidabilità e che livelli crescenti di affidabilità comportano un corrispondente aumento dei costi. In alcuni scenari, un sito primario può richiedere connessioni affidabili (ridondanti e resilienti) poiché i tempi di inattività hanno un impatto maggiore sull'attività, mentre i siti regionali potrebbero non richiedere lo stesso livello di affidabilità a causa del minore impatto sull'attività in caso di guasto. Si consiglia di fare riferimento alle [raccomandazioni sulla AWS Direct Connect resilienza](https://aws.amazon.com/directconnect/resiliency-recommendation/) in quanto spiegano le AWS migliori pratiche per garantire un'elevata resilienza in fase di progettazione. AWS Direct Connect
Per ottenere una soluzione di connettività di rete ibrida affidabile nel contesto della resilienza, la progettazione deve prendere in considerazione i seguenti aspetti:
+ **Ridondanza:** mira a eliminare ogni singolo punto di errore nel percorso di connettività di rete ibrida, inclusi, a titolo esemplificativo, le connessioni di rete, i dispositivi di rete periferici, la ridondanza tra le zone di disponibilità e le posizioni DX Regioni AWS, le fonti di alimentazione dei dispositivi, i percorsi in fibra e i sistemi operativi. Per lo scopo e l'ambito di questo white paper, la ridondanza si concentra sulle connessioni di rete, sui dispositivi periferici (ad esempio, i dispositivi gateway del cliente), sulla posizione AWS DX e Regioni AWS (per le architetture multiregionali).
+ **Componenti di failover affidabili:** in alcuni scenari, un sistema potrebbe funzionare, ma non svolgere le sue funzioni al livello richiesto. Una situazione di questo tipo è comune nel caso di un singolo evento di guasto, in cui si scopre che i componenti ridondanti pianificati funzionavano in modo non ridondante: il carico di rete non ha altro a cui rivolgersi a causa dell'utilizzo, il che si traduce in una capacità insufficiente per l'intera soluzione.
+ **Tempo di failover: il tempo** di failover è il tempo impiegato da un componente secondario per assumere completamente il ruolo di componente principale. Il tempo di failover è legato a diversi fattori: il tempo necessario per rilevare l'errore, il tempo necessario per abilitare la connettività secondaria e il tempo necessario per notificare la modifica al resto della rete. Il rilevamento degli errori può essere migliorato utilizzando Dead Peer Detection (DPD) per VPN i link e Bidirectional Forwarding Detection () per i link. BFD AWS Direct Connect Il tempo necessario per abilitare la connettività secondaria può essere molto breve (se queste connessioni sono sempre attive), può essere breve (se è necessario abilitare una VPN connessione preconfigurata) o più lungo (se è necessario spostare risorse fisiche o configurare nuove risorse). La notifica al resto della rete avviene in genere tramite protocolli di routing all'interno della rete del cliente, ognuno dei quali ha tempi di convergenza e opzioni di configurazione diversi: la configurazione di questi non rientra nell'ambito di questo white paper.
+ **Ingegneria del traffico:** l'ingegneria del traffico nel contesto della progettazione resiliente della connettività di rete ibrida mira a definire il modo in cui il traffico dovrebbe fluire su più connessioni disponibili in scenari normali e di guasto. Si consiglia di seguire il concetto di *progettazione in caso di errore*, in cui è necessario esaminare come funzionerà la soluzione in diversi scenari di errore e se sarà accettabile per l'azienda o meno. Questa sezione illustra alcuni dei casi d'uso più comuni di ingegneria del traffico che mirano a migliorare il livello di resilienza complessivo della soluzione di connettività di rete ibrida. La [AWS Direct Connect sezione dedicata al routing BGP](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html) illustra diverse opzioni di ingegneria del traffico per influenzare il flusso del traffico (comunità, preferenze BGP locali, lunghezza del percorso AS). Per progettare una soluzione di ingegneria del traffico efficace, è necessario avere una buona conoscenza di come ciascuno dei componenti di AWS rete gestisce il routing IP in termini di valutazione e selezione del percorso, nonché dei possibili meccanismi per influenzare la selezione del percorso. I dettagli in merito non rientrano nell'ambito di questo documento. Per ulteriori informazioni, consulta [Transit Gateway Route Evaluation Order](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html#tgw-route-evaluation-overview), [Site-to-Site VPNRoute Priority](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html#vpn-route-priority) e [Direct Connect Routing e BGP](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html) la documentazione necessaria.
**Nota**
Nella tabella delle VPC rotte, è possibile fare riferimento a un elenco di prefissi che contiene regole di selezione delle rotte aggiuntive. Per ulteriori informazioni su questo caso d'uso, consulta la [priorità delle rotte per gli elenchi di prefissi](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#route-tables-priority). AWS Transit Gateway Le tabelle di routing supportano anche gli elenchi di prefissi, ma una volta applicate vengono estese a voci di percorso specifiche.
## Esempio di Site-to-Site VPN connessioni doppie con percorsi più specifici
Questo scenario si basa su un piccolo sito locale che si connette a un unico Regione AWS sito tramite VPN connessioni ridondanti via Internet a. AWS Transit Gateway Il progetto di ingegneria del traffico illustrato nella Figura 10 mostra che con l'ingegneria del traffico è possibile influenzare la selezione del percorso che aumenta l'affidabilità della soluzione di connettività ibrida mediante:
+ Connettività ibrida resiliente: tutte VPN le connessioni ridondanti offrono la stessa capacità prestazionale, supportano il failover automatico utilizzando il protocollo di routing dinamico (BGP) e velocizzano il rilevamento degli errori di connessione utilizzando il rilevamento «dead peer». VPN
+ Efficienza delle prestazioni: la configurazione ECMP su entrambe le VPN connessioni AWS Transit Gateway aiuta a massimizzare la larghezza di banda complessiva della connessione. VPN In alternativa, pubblicizzando percorsi diversi e più specifici insieme al percorso di riepilogo del sito, è possibile gestire il carico in modo indipendente tra le due connessioni VPN
![\[Esempio di diagramma che mostra Site-to-Site VPN connessioni doppie con percorsi più specifici\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/dual-s2s-example.png)
## Esempio di due siti locali con più connessioni DX
Lo scenario illustrato nella Figura 11 mostra due siti di data center locali situati in diverse regioni geografiche e collegati tramite il modello di connettività Maximum Resiliency (descritto nelle Raccomandazioni sulla [AWS Direct Connect resilienza](https://aws.amazon.com/directconnect/resiliency-recommendation/)) AWS utilizzando with and. AWS Direct Connect DXGW VGW Questi due siti locali sono interconnessi tra loro tramite un collegamento di interconnessione del data center (). DCI I prefissi IP locali (192.168.0.0/16) che appartengono alle filiali remote vengono pubblicizzati da entrambi i siti dei data center locali. Il percorso principale per questo prefisso deve essere il data center 1. Il traffico da e verso le filiali remote verrà eseguito il failover verso il data center 2 in caso di guasto del data center 1 o di entrambe le sedi DX. Inoltre, esiste un prefisso IP specifico del sito per ogni data center. Questi prefissi devono essere raggiunti direttamente e tramite l'altro sito del data center in caso di guasto in entrambe le sedi DX.
Associando gli attributi BGP Community alle rotte pubblicizzate AWS DXGW, è possibile influenzare lateralmente la selezione del percorso di uscita. AWS DXGW Questi attributi comunitari controllano AWS l'attributo BGP Local Preference assegnato al percorso pubblicizzato. Per ulteriori informazioni, consulta le [politiche e le AWS community di DX Routing](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html). BGP
Per massimizzare l'affidabilità della connettività a Regione AWS livello, ogni coppia di connessioni AWS DX viene configurata in ECMP modo che entrambe possano essere utilizzate contemporaneamente per il trasferimento di dati tra ogni sito locale e. AWS
![\[Diagramma che mostra due siti locali con più connessioni DX\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/dual-dx-example.png)
Con questo design, i flussi di traffico destinati alle reti locali (con la stessa lunghezza del prefisso e la stessa BGP community pubblicizzati) verranno distribuiti tra le doppie connessioni DX utilizzate dal sito. ECMP Tuttavia, se non ECMP è richiesto attraverso la connessione DX, lo stesso concetto discusso in precedenza e descritto nella documentazione [BGPsulle politiche e le comunità di routing](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html) può essere utilizzato per progettare ulteriormente la selezione del percorso a livello di connessione DX.
Nota: se nel percorso all'interno dei data center locali sono presenti dispositivi di sicurezza, questi dispositivi devono essere configurati per consentire ai flussi di traffico in uscita da un collegamento DX e provenienti da un altro collegamento DX (entrambi i collegamenti utilizzatiECMP) all'interno dello stesso sito del data center.
## VPNconnessione come esempio di connessione di backup a DX AWS
VPNpuò essere selezionato per fornire una connessione di rete di backup a una AWS Direct Connect connessione. In genere, questo tipo di modello di connettività è determinato dal costo, in quanto offre un livello di affidabilità inferiore alla soluzione complessiva di connettività ibrida a causa delle prestazioni indeterministiche su Internet, e non SLA è possibile ottenere una connessione tramite la rete Internet pubblica. È un modello di connettività valido ed economico e deve essere utilizzato quando il costo è la priorità assoluta e il budget è limitato, o magari come soluzione provvisoria fino al provisioning di un DX secondario. La Figura 12 illustra la progettazione di questo modello di connettività. Una considerazione fondamentale di questa progettazione, in cui entrambe le connessioni VPN e DX terminano in corrispondenza del AWS Transit Gateway, è che la VPN connessione può annunciare un numero maggiore di rotte rispetto a quelle che possono essere pubblicizzate tramite una connessione DX a cui è connessa. AWS Transit Gateway Ciò può causare una situazione di routing non ottimale. Un'opzione per risolvere questo problema consiste nel configurare il filtraggio delle rotte sul dispositivo gateway del cliente (CGW) per le rotte ricevute dalla VPN connessione, consentendo l'accettazione solo delle rotte di riepilogo.
Nota: per creare il percorso di riepilogo su AWS Transit Gateway, è necessario specificare un percorso statico verso un allegato arbitrario nella tabella delle rotte in modo che il riepilogo venga inviato lungo il AWS Transit Gateway percorso più specifico.
Dal punto di vista della tabella di AWS Transit Gateway routing, le rotte per il prefisso locale vengono ricevute sia dalla connessione AWS DX (viaDXGW) che daVPN, con la stessa lunghezza del prefisso. Seguendo la [logica di priorità del percorso di AWS Transit Gateway, le rotte ricevute](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html#tgw-route-evaluation-overview) tramite Direct Connect hanno una preferenza maggiore rispetto a quelle ricevute su Site-to-SiteVPN, e quindi il percorso su di AWS Direct Connect sarà il preferito per raggiungere le reti locali.
![\[Diagramma che mostra una VPN connessione come esempio di connessione di backup a AWS DX\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/vpn-as-backup-to-dx.png)
Il seguente albero decisionale guida l'utente nel prendere la decisione desiderata per ottenere una connettività di rete ibrida resiliente (che si tradurrà in una connettività di rete ibrida affidabile). Per ulteriori informazioni, consulta [AWS Direct Connect Resiliency](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) Toolkit.
![\[Diagramma che mostra un albero decisionale sull'affidabilità\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/hybrid-connectivity/images/reliability-decision-tree.png)
# Gestito dal cliente VPN e SD- WAN
## Definizione
La connettività a Internet è un bene di prima necessità e la larghezza di banda disponibile continua ad aumentare ogni anno. Alcuni clienti scelgono di creare un sistema virtuale basato WAN su Internet invece di crearne e gestirne uno privato. WAN Una rete geografica definita dal software (SD-WAN) consente alle aziende di fornire e gestire in modo rapido e centralizzato questo ambiente virtuale WAN attraverso un uso intelligente del software. Altri clienti scelgono di adottare la tradizionale gestione autonoma da sito a sito. VPNs
## Impatto sulle decisioni di progettazione
La gestione SD WAN e quella gestita dal cliente VPNs possono essere eseguite su Internet o. AWS Direct Connect SD- WAN (o qualsiasi altro VPN overlay software) è affidabile quanto il trasporto di rete sottostante. Pertanto, l'affidabilità e SLA le considerazioni discusse in precedenza in questo white paper sono applicabili qui. Ad esempio, la creazione di un WAN overlay SD su Internet non offrirà la stessa affidabilità rispetto a una sovrapposizione basata su un. AWS Direct Connect
## Definizione dei requisiti
+ Utilizzi SD- WAN nella tua rete locale?
+ Sono necessarie funzionalità specifiche che sono disponibili solo su alcune appliance virtuali utilizzate per la VPN terminazione?
## Soluzioni tecniche
AWS consiglia l'integrazione di SD- WAN con AWS Transit Gateway e pubblica un elenco dei [fornitori che supportano l'](https://aws.amazon.com/transit-gateway/network-manager/)integrazione. AWS Transit Gateway AWS può fungere da hub per i WAN siti SD o da sito parlato. La AWS backbone può essere utilizzata per connettere diversi WAN hub SD distribuiti all'interno AWS di una rete altamente affidabile e performante. WANLe soluzioni SD supportano il failover automatizzato attraverso qualsiasi percorso disponibile, funzionalità aggiuntive di monitoraggio e osservabilità in un unico pannello di gestione. L'ampio uso della configurazione e dell'automazione automatiche consente un approvvigionamento e una visibilità rapidi rispetto ai sistemi tradizionaliWANs. Tuttavia, l'uso del tunneling e dei costi generali di crittografia non è paragonabile ai collegamenti in fibra dedicati e ad alta velocità utilizzati nella connettività privata.
In alcuni casi, è possibile scegliere di utilizzare un'appliance virtuale dotata di funzionalità. VPN I motivi per scegliere un'appliance virtuale autogestita includono caratteristiche tecniche e compatibilità con il resto della rete. Quando si seleziona una WAN soluzione autogestita VPN o SD che utilizza un'appliance virtuale distribuita in un'EC2istanza, l'utente è responsabile della gestione di tale appliance. L'utente è inoltre responsabile dell'elevata disponibilità e del failover tra le appliance virtuali. Tale progettazione aumenta la responsabilità operativa; tuttavia, potrebbe offrirvi maggiore flessibilità. Le caratteristiche e le funzionalità della soluzione dipendono dall'appliance virtuale selezionata.
Marketplace AWS contiene molte appliance VPN virtuali che i clienti possono implementare su AmazonEC2. AWS consiglia di iniziare con S2S AWS gestito VPN e di esaminare altre opzioni se non soddisfa i tuoi requisiti. Il sovraccarico di gestione delle appliance virtuali è responsabilità del cliente.