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 perimetrale
Quando si progettano soluzioni che utilizzano un'infrastruttura AWS perimetrale, come AWS Outposts Local Zones, è necessario considerare attentamente la progettazione della rete. La rete costituisce la base della connettività per raggiungere i carichi di lavoro distribuiti in queste sedi periferiche ed è fondamentale per garantire una bassa latenza. Questa sezione descrive vari aspetti della connettività edge ibrida.
Architettura VPC
Un cloud privato virtuale (VPC) si estende su tutte le zone di disponibilità al suo interno. Regione AWS Puoi estendere senza problemi qualsiasi VPC nella regione a Outposts o Local Zones AWS utilizzando la console o () per aggiungere una sottorete Outpost AWS Command Line Interface o AWS CLI Local Zone. Gli esempi seguenti mostrano come creare sottoreti in AWS Outposts e Local Zones utilizzando: AWS CLI
-
AWS Outposts: per aggiungere una sottorete Outpost a un VPC, specifica l'Amazon Resource Name (ARN) dell'Outpost.
aws ec2 create-subnet --vpc-id vpc-081ec835f3EXAMPLE \ --cidr-block 10.0.0.0/24 \ --outpost-arn arn:aws:outposts:us-west-2:11111111111:outpost/op-0e32example1 \ --tag-specifications ResourceType=subnet,Tags=[{Key=Name,Value=my-ipv4-only-subnet}]Per ulteriori informazioni, consulta la documentazione relativa ad AWS Outposts.
-
Local Zones: per aggiungere una sottorete Local Zone a un VPC, seguite la stessa procedura che utilizzate con le zone di disponibilità, ma specificate l'ID della zona locale
<local-zone-name>(nell'esempio seguente).aws ec2 create-subnet --vpc-id vpc-081ec835f3EXAMPLE \ --cidr-block 10.0.1.0/24 \ --availability-zone <local-zone-name> \ --tag-specifications ResourceType=subnet,Tags=[{Key=Name,Value=my-ipv4-only-subnet}]Per ulteriori informazioni, consulta la documentazione di Local Zones.
Il diagramma seguente mostra un' AWS architettura che include le sottoreti Outpost e Local Zone.
Traffico da periferia a regione
Quando progetti un'architettura ibrida utilizzando servizi come Local Zones e AWS Outposts, prendi in considerazione sia i flussi di controllo che i flussi di traffico di dati tra le infrastrutture edge e Regioni AWS. A seconda del tipo di infrastruttura perimetrale, la responsabilità dell'utente può variare: alcune infrastrutture richiedono la gestione della connessione alla regione madre, mentre altre la gestiscono tramite l'infrastruttura AWS globale. Questa sezione esplora le implicazioni della connettività del piano di controllo e del piano dati per Local Zones e AWS Outposts.
AWS Outposts piano di controllo
AWS Outposts fornisce un costrutto di rete chiamato service link. Il collegamento al servizio è una connessione richiesta tra AWS Outposts e la regione selezionata Regione AWS o principale (denominata anche regione di origine). Consente la gestione dell'Avamposto e lo scambio di traffico tra l'Avamposto e. Regione AWS Il collegamento al servizio utilizza un set crittografato di connessioni VPN per comunicare con la regione d'origine. È necessario fornire la Regione AWS connettività tra AWS Outposts e tramite un collegamento Internet o un'interfaccia virtuale AWS Direct Connect pubblica (VIF pubblica) oppure tramite un'interfaccia virtuale AWS Direct Connect privata (VIF privata). Per un'esperienza e una resilienza ottimali, si AWS consiglia di utilizzare una connettività ridondante di almeno 500 Mbps (1 Gbps è preferibile) per la connessione del service link a. Regione AWS La connessione service link di almeno 500 Mbps consente di avviare EC2 istanze Amazon, collegare volumi Amazon EBS e accedere ad Servizi AWS esempio ad Amazon EKS, Amazon EMR e parametri Amazon. CloudWatch La rete deve supportare un'unità di trasmissione (MTU) massima di 1.500 byte tra Outpost e gli endpoint del service link del dispositivo principale. Regione AWSPer ulteriori informazioni, consulta la sezione AWS Outposts relativa alla connettività Regioni AWS nella documentazione di Outposts.
Per informazioni sulla creazione di architetture resilienti per i collegamenti di servizio che utilizzano AWS Direct Connect e la rete Internet pubblica, consulta la sezione sulla connettività di Anchor nel AWS white paper AWS Outposts High Availability Design and Architecture Considerations.
AWS Outposts piano dati
Il piano dati compreso tra AWS Outposts e Regione AWS è supportato dalla stessa architettura di service link utilizzata dal piano di controllo. La larghezza di banda del collegamento di servizio del piano dati tra AWS Outposts e Regione AWS deve essere correlata alla quantità di dati che devono essere scambiati: maggiore è la dipendenza dai dati, maggiore deve essere la larghezza di banda del collegamento.
I requisiti di larghezza di banda variano in base alle seguenti caratteristiche:
-
Il numero di AWS Outposts rack e le configurazioni di capacità
-
Caratteristiche del carico di lavoro come le dimensioni dell'AMI, l'elasticità delle applicazioni e le esigenze di velocità di burst
-
Traffico VPC verso la regione
Il traffico tra EC2 le istanze in AWS Outposts e le EC2 istanze in Regione AWS ha un MTU di 1.300 byte. Ti consigliamo di discutere questi requisiti con uno specialista del cloud AWS ibrido prima di proporre un'architettura che abbia co-dipendenze tra la regione e. AWS Outposts
Piano dati Local Zones
Il piano dati tra Local Zones e il Regione AWS è supportato dall'infrastruttura AWS globale. Il piano dati viene esteso tramite un VPC dalla zona Regione AWS a una zona locale. Le Local Zones forniscono anche una connessione sicura e ad alta larghezza di banda e consentono di connettersi senza problemi all'intera gamma di servizi regionali tramite lo stesso APIs set di strumenti. Regione AWS
La tabella seguente mostra le opzioni di connessione e quelle associate. MTUs
Da |
Per |
MTU |
|---|---|---|
Amazon EC2 nella regione |
Amazon EC2 nelle Local Zones |
1.300 byte |
AWS Direct Connect |
Zone locali |
1.468 byte |
Internet Gateway |
Zone locali |
1.500 byte |
Amazon EC2 nelle Local Zones |
Amazon EC2 nelle Local Zones |
9.001 byte |
Local Zones utilizzano l'infrastruttura AWS globale con cui connettersi Regioni AWS. L'infrastruttura è completamente gestita da AWS, quindi non è necessario configurare questa connettività. Ti consigliamo di discutere i requisiti e le considerazioni relative alle Local Zones con uno specialista del cloud AWS ibrido prima di progettare qualsiasi architettura che abbia co-dipendenze tra Region e Local Zones.
Traffico dall'edge all'ambiente locale
AWS i servizi cloud ibridi sono progettati per affrontare casi d'uso che richiedono bassa latenza, elaborazione locale dei dati o conformità alla residenza dei dati. L'architettura di rete per l'accesso a questi dati è importante e dipende dal fatto che il carico di lavoro sia in esecuzione nelle Local Zones AWS Outposts o nelle Local Zones. La connettività locale richiede anche un ambito ben definito, come illustrato nelle sezioni seguenti.
AWS Outposts gateway locale
Il gateway locale (LGW) è un componente fondamentale dell' AWS Outposts architettura. Il gateway locale stabilisce la connettività tra le sottoreti Outpost e la rete on-premise. Il ruolo principale di un LGW è fornire la connettività da un Outpost alla rete locale locale. Fornisce inoltre connettività a Internet tramite la rete locale tramite routing VPC diretto o indirizzi IP di proprietà del cliente.
-
Il routing VPC diretto utilizza l'indirizzo IP privato delle istanze nel tuo VPC per facilitare la comunicazione con la tua rete locale. Questi indirizzi vengono pubblicizzati sulla rete locale tramite Border Gateway Protocol (BGP). La propagazione su BGP riguarda solo gli indirizzi IP privati che appartengono alle sottoreti del rack Outpost. Questo tipo di routing è la modalità predefinita per. AWS Outposts In questa modalità, il gateway locale non esegue NAT per le istanze e non è necessario assegnare indirizzi IP elastici alle istanze. EC2 Il diagramma seguente mostra un gateway AWS Outposts locale che utilizza il routing VPC diretto.
-
Con gli indirizzi IP di proprietà del cliente, è possibile fornire un intervallo di indirizzi, noto come pool di indirizzi IP (CoIP) di proprietà del cliente, che supporta intervalli CIDR sovrapposti e altre topologie di rete. Quando si sceglie un CoIP, è necessario creare un pool di indirizzi, assegnarlo alla tabella di routing del gateway locale e ripubblicizzare questi indirizzi nella rete tramite BGP. Gli indirizzi CoIP forniscono connettività locale o esterna alle risorse della rete locale. Puoi assegnare questi indirizzi IP alle risorse di Outpost, come le EC2 istanze, allocando un nuovo indirizzo IP elastico dal CoIP e quindi assegnandolo alla tua risorsa. Il diagramma seguente mostra un AWS Outposts gateway locale che utilizza la modalità CoIP.
La connettività locale AWS Outposts da una rete locale richiede alcune configurazioni di parametri, come l'abilitazione del protocollo di routing BGP e dei prefissi pubblicitari tra i peer BGP. L'MTU che può essere supportato tra Outpost e il gateway locale è di 1.500 byte. Per ulteriori informazioni, contatta uno specialista del cloud AWS ibrido o consulta la documentazione.AWS Outposts
Local Zones e Internet
I settori che richiedono una bassa latenza o la residenza locale dei dati (ad esempio giochi, live streaming, servizi finanziari e pubblica amministrazione) possono utilizzare Local Zones per distribuire e fornire le proprie applicazioni agli utenti finali su Internet. Durante l'implementazione di una zona locale, è necessario allocare indirizzi IP pubblici da utilizzare in una zona locale. Quando si allocano indirizzi IP elastici, è possibile specificare la posizione da cui viene pubblicizzato l'indirizzo IP. Questa posizione è denominata gruppo di confine di rete. Un gruppo di confini di rete è una raccolta di Availability Zones, Local AWS Wavelength Zones o Zones da cui AWS pubblicizza un indirizzo IP pubblico. Questo aiuta a garantire una latenza o una distanza fisica minima tra la AWS rete e gli utenti che accedono alle risorse in queste zone. Per visualizzare tutti i gruppi di confine di rete per Local Zones, consulta Available Local Zones nella documentazione Local Zones.
Per esporre a Internet un carico EC2 di lavoro ospitato da Amazon in una zona locale, puoi abilitare l'opzione Assegna automaticamente un IP pubblico all'avvio dell'istanza. EC2 Se si utilizza un Application Load Balancer, è possibile definirlo come connesso a Internet in modo che gli indirizzi IP pubblici assegnati alla zona locale possano essere propagati dalla rete di confine associata alla zona locale. Inoltre, quando utilizzi indirizzi IP elastici, puoi associare una di queste risorse a un' EC2 istanza dopo il suo avvio. Quando si invia traffico tramite un gateway Internet in Local Zones, vengono applicate le stesse specifiche di larghezza di banda dell'istanza utilizzate dalla regione. Il traffico di rete della zona locale va direttamente a Internet o ai punti di presenza (PoPs) senza attraversare la regione madre della zona locale, per consentire l'accesso all'elaborazione a bassa latenza.
Le Local Zones offrono le seguenti opzioni di connettività su Internet:
-
Accesso pubblico: collega carichi di lavoro o dispositivi virtuali a Internet utilizzando indirizzi IP elastici tramite un gateway Internet.
-
Accesso a Internet in uscita: consente alle risorse di raggiungere gli endpoint pubblici tramite istanze NAT (Network Address Translation) o dispositivi virtuali con indirizzi IP elastici associati, senza esposizione diretta a Internet.
-
Connettività VPN: stabilisce connessioni private utilizzando Internet Protocol Security (IPsec) VPN tramite dispositivi virtuali con indirizzi IP elastici associati.
Per ulteriori informazioni, consulta Opzioni di connettività per Local Zones nella documentazione di Local Zones.
Local Zones e AWS Direct Connect
Supporta anche Local Zones AWS Direct Connect, che consente di indirizzare il traffico su una connessione di rete privata. Per ulteriori informazioni, consulta Direct Connect in Local Zones nella documentazione di Local Zones.
Local Zones e gateway di transito
AWS Transit Gateway non supporta gli allegati VPC diretti alle sottoreti della zona locale. Tuttavia, è possibile connettersi ai carichi di lavoro della zona locale creando allegati Transit Gateway nelle sottoreti della zona di disponibilità principale dello stesso VPC. Questa configurazione consente l'interconnettività tra più VPCs carichi di lavoro della zona locale e quelli della zona locale. Per ulteriori informazioni, consulta la sezione Transit gateway connection between Local Zones nella documentazione Local Zones.
Local Zones e peering VPC
È possibile estendere qualsiasi VPC da una regione principale a una zona locale creando una nuova sottorete e assegnandola alla zona locale. È possibile stabilire il peering VPC tra VPCs quelli estesi a Local Zones. Quando i peer si VPCs trovano nella stessa zona locale, il traffico rimane all'interno della zona locale e non attraversa la regione madre.
