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à.

Servizi globali

Oltre ai AWS servizi regionali e zonali, esiste un piccolo insieme di AWS servizi i cui piani di controllo e piani dati non esistono indipendentemente in ciascuna regione. Poiché le loro risorse non sono specifiche per regione, vengono comunemente definite globali. AWS I servizi globali seguono ancora lo schema di AWS progettazione convenzionale che prevede la separazione del piano di controllo dal piano dati per raggiungere la stabilità statica. La differenza significativa per la maggior parte dei servizi globali è che il piano di controllo è ospitato in un unico piano Regione AWS, mentre il piano dati è distribuito a livello globale. Esistono tre diversi tipi di servizi globali e un set di servizi che possono apparire globali in base alla configurazione selezionata.

Le sezioni seguenti identificheranno ogni tipo di servizio globale e il modo in cui i relativi piani di controllo e piani dati sono separati. È possibile utilizzare queste informazioni per guidare la creazione di meccanismi affidabili di alta disponibilità (HA) e disaster recovery (DR) senza dover dipendere da un piano di controllo del servizio globale. Questo approccio aiuta a rimuovere singoli punti di errore nell'architettura ed evita potenziali impatti interregionali, anche quando si opera in una regione diversa da quella in cui è ospitato il piano di controllo del servizio globale. Inoltre, consente di implementare in modo sicuro meccanismi di failover che non si basano su piani di controllo dei servizi globali.

Servizi globali unici per partizione

In ogni partizione sono presenti alcuni AWS servizi globali (denominati in questo paper servizi partizionali). I servizi partizionali forniscono il proprio piano di controllo in un unico piano. Regione AWS Alcuni servizi partizionali, come AWS Network Manager, sono disponibili solo sul piano di controllo e orchestrano il piano dati di altri servizi. Altri servizi partizionali, ad esempioIAM, dispongono di un proprio piano dati isolato e distribuito su tutti gli elementi della partizione. Regioni AWS Gli errori in un servizio partizionale non influiscono sulle altre partizioni. Nella aws partizione, il piano di controllo del IAM servizio si trova nella us-east-1 Regione, con piani dati isolati in ciascuna regione della partizione. I servizi partizionali dispongono inoltre di piani di controllo e piani dati indipendenti nelle partizioni e. aws-us-gov aws-cn La separazione tra piano di controllo e piano dati per IAM è illustrata nel diagramma seguente.

Di seguito sono riportati i servizi partizionali e la loro posizione del piano di controllo nella partizione: aws

Se uno di questi piani di controllo del servizio presenta un evento che influisce sulla disponibilità, potresti non essere in grado di utilizzare le operazioni di CRUDL tipo fornite da questi servizi. Pertanto, se la strategia di ripristino dipende da queste operazioni, un impatto sulla disponibilità sul piano di controllo o sulla regione che ospita il piano di controllo ridurrà le possibilità di successo del ripristino. Appendice A - Guida al servizio partizionalefornisce strategie per rimuovere le dipendenze dai piani di controllo dei servizi globali durante il ripristino.

Servizi globali nella rete perimetrale

Il prossimo set di AWS servizi globali prevede un piano di controllo nella aws partizione e ospita i relativi piani dati nell'infrastruttura dei punti di presenza globali (PoP) (e potenzialmente Regioni AWS anche). È PoPs possibile accedere ai piani dati ospitati dalle risorse di qualsiasi partizione e da Internet. Ad esempio, Route 53 utilizza il suo piano di controllo us-east-1 nella regione, ma il suo piano dati è distribuito su centinaia di piattaforme PoPs a livello globale, oltre a ciascuna Regione AWS (per supportare la Route 53 pubblica e privata DNS all'interno della regione). Anche i controlli dello stato di Route 53 fanno parte del piano dati e vengono eseguiti dalle otto Regioni AWS unità della aws partizione. I client possono risolvere i problemi DNS utilizzando le zone pubbliche ospitate di Route 53 da qualsiasi punto di Internet, incluse altre partizioni come GovCloud, o da un AWS Virtual Private Cloud ()VPC. Di seguito sono riportati i servizi di rete edge globali e la loro posizione del piano di controllo nella aws partizione:

Se utilizzi controlli di AGA integrità per EC2 istanze o indirizzi IP elastici, questi utilizzano i controlli di integrità di Route 53. La creazione o l'aggiornamento dei controlli AGA sanitari dipenderebbe dal piano di controllo della Route 53 in us-east-1 uso. L'esecuzione dei controlli AGA sanitari utilizza il piano dati per i controlli di integrità della Route 53.

In caso di guasto che influisce sulla regione che ospita i piani di controllo di questi servizi o di un guasto che influisce sul piano di controllo stesso, potrebbe non essere possibile utilizzare le operazioni di CRUDL tipo fornite da questi servizi. Se nella strategia di ripristino si è fatto affidamento su queste operazioni, è possibile che tale strategia abbia meno probabilità di successo rispetto a quando si fa affidamento solo sul piano dati di questi servizi.

Operazioni globali in una singola regione

L'ultima categoria è composta da specifiche operazioni sul piano di controllo nell'ambito di un servizio con un ambito di impatto globale, non da interi servizi come nelle categorie precedenti. Sebbene si interagisca con i servizi zonali e regionali nella regione specificata, alcune operazioni dipendono da una singola regione diversa da quella in cui si trova la risorsa. Si tratta di servizi diversi dai servizi forniti in una sola regione; Appendice C - Servizi per una singola regione per un elenco di tali servizi, consulta la sezione.

In caso di errore che influisce sulla dipendenza globale sottostante, potrebbe non essere possibile utilizzare le azioni di tipo «CRUDL-type» delle operazioni dipendenti. Se nella strategia di ripristino si è fatto affidamento su queste operazioni, è possibile che tale strategia abbia meno probabilità di successo rispetto a quando si fa affidamento solo sul piano dati di questi servizi. È necessario evitare di dipendere da queste operazioni per la strategia di ripristino.

Di seguito è riportato un elenco di servizi da cui altri servizi possono dipendere e che hanno una portata globale:

Servizi che utilizzano endpoint globali predefiniti

In alcuni casi, AWS i servizi forniscono un endpoint globale predefinito, come AWS Security Token Service () AWS STS. Altri servizi possono utilizzare questo endpoint globale predefinito nella loro configurazione predefinita. Ciò significa che un servizio regionale in uso potrebbe avere una dipendenza globale da un singolo servizio. Regione AWS I seguenti dettagli spiegano come rimuovere le dipendenze involontarie dagli endpoint globali predefiniti che ti aiuteranno a utilizzare il servizio in modo regionale.

AWS STS: STS è un servizio Web che consente di richiedere credenziali temporanee con privilegi limitati per IAM gli utenti o per gli utenti autenticati (utenti federati). STSl'utilizzo dal AWS software development kit (SDK) e dall'interfaccia a riga di comando () è impostato come impostazione predefinita su. CLI us-east-1 Il STS servizio fornisce anche endpoint regionali. Questi endpoint sono abilitati per impostazione predefinita nelle regioni che sono anch'esse abilitate per impostazione predefinita. Puoi trarne vantaggio in qualsiasi momento configurando SDK o CLI seguendo queste istruzioni: Endpoint AWS STSregionalizzati. L'utilizzo di SigV4a richiede anche credenziali temporanee richieste da un endpoint regionale. STS Non è possibile utilizzare l'endpoint globale per questa operazioneSTS.

Security Assertion Markup Language (SAML) Accesso: SAML i servizi esistono in tutti. Regioni AWS Per utilizzare questo servizio, scegli l'SAMLendpoint regionale appropriato, ad esempio https://us-west-2.signin.aws.amazon.com/saml. È necessario aggiornare le configurazioni nelle policy di fiducia e nell'Identity Provider (IdP) per utilizzare gli endpoint regionali. Per dettagli specifici, AWS SAMLconsulta la documentazione.

Se utilizzi un IdP che è anche ospitato su AWS, c'è il rischio che anche quest'ultimo venga compromesso durante un AWS evento di errore. Ciò potrebbe comportare l'impossibilità di aggiornare la configurazione IdP o la federazione completa. Dovresti predisporre gli utenti «break-glass» nel caso in cui il tuo IdP sia compromesso o non disponibile. Appendice A - Guida al servizio partizionalePer ulteriori informazioni su come creare utenti break-glass in modo staticamente stabile, consulta

AWS IAMIdentity Center: Identity Center è un servizio basato sul cloud che semplifica la gestione centralizzata dell'accesso Single Sign-On alle applicazioni del cliente e al cloud. Account AWS Identity Center deve essere distribuito in un'unica regione di tua scelta. Tuttavia, il comportamento predefinito del servizio consiste nell'utilizzare l'SAMLendpoint globale (https://signin.aws.amazon.com/saml), che è ospitato in. us-east-1 Se è stato distribuito Identity Center in un altro Regione AWS, è necessario aggiornare lo stato di relè URL di ogni set di autorizzazioni in modo da utilizzare lo stesso endpoint di console regionale utilizzato per la distribuzione dell'Identity Center. Ad esempio, se hai distribuito Identity Center inus-west-2, dovresti aggiornare il relaystate dei tuoi set di autorizzazioni per utilizzare https://us-west-2.console.aws.amazon.com. Ciò eliminerà qualsiasi dipendenza dalla distribuzione di Identity us-east-1 Center.

Inoltre, poiché IAM Identity Center può essere distribuito solo in una singola regione, è necessario predisporre in anticipo gli utenti «break-glass» nel caso in cui la distribuzione sia compromessa. Appendice A - Guida al servizio partizionalePer ulteriori informazioni su come creare utenti break-glass in modo staticamente stabile, consulta

Amazon S3 Storage Lens: Storage Lens fornisce una dashboard predefinita chiamata. default-account-dashboard La configurazione del dashboard e le metriche associate vengono archiviate in. us-east-1 Puoi creare dashboard aggiuntivi in altre regioni specificando la regione principale per la configurazione della dashboard e i dati delle metriche.

Riepilogo dei servizi globali

I piani dati per i servizi globali applicano principi di isolamento e indipendenza simili a quelli AWS dei servizi regionali. Un guasto che influisce sul piano dati IAM di una regione non influisce sul funzionamento del piano IAM dati in un'altra Regione AWS. Analogamente, un guasto che influisce sul piano dati di Route 53 in un PoP non influisce sul funzionamento del piano dati Route 53 nel resto del. PoPs Pertanto, ciò che dobbiamo considerare sono gli eventi di disponibilità del servizio che influiscono sulla regione in cui opera il piano di controllo o influiscono sul piano di controllo stesso. Poiché esiste un solo piano di controllo per ogni servizio globale, un guasto che influisca su tale piano di controllo potrebbe avere effetti interregionali sulle operazioni di CRUDL tipo (che sono le operazioni di configurazione che vengono in genere utilizzate per impostare o configurare un servizio anziché l'uso diretto del servizio).

Il modo più efficace per progettare carichi di lavoro in modo da utilizzare i servizi globali in modo resiliente consiste nell'utilizzare la stabilità statica. In uno scenario di errore, progetta il carico di lavoro in modo da non dover apportare modifiche utilizzando un piano di controllo per mitigare l'impatto o il failover su una posizione diversa. Per informazioni prescrittive su come utilizzare questi tipi di servizi globali Appendice B - Guida all'assistenza globale della rete Edge per rimuovere le dipendenze dal piano di controllo Appendice A - Guida al servizio partizionale ed eliminare i singoli punti di errore, fate riferimento a e per ottenere indicazioni prescrittive su come utilizzare questi tipi di servizi globali. Se hai bisogno dei dati di un'operazione del piano di controllo per il ripristino, memorizzali nella cache in un data store a cui è possibile accedere tramite il relativo piano dati, come un parametro AWS Systems Manager Parameter Store (SSMParameter Store), una tabella DynamoDB o un bucket S3. Per motivi di ridondanza, puoi anche scegliere di archiviare i dati in una regione aggiuntiva. Ad esempio, seguendo le best practice per Route 53 Application Recovery Controller (ARC), è necessario codificare o aggiungere un segnalibro ai cinque endpoint del cluster regionale. Durante un evento di errore, potresti non essere in grado di accedere ad alcune API operazioni, incluse le operazioni di Route 53 che non sono ospitate sul cluster Data ARC API Plane estremamente affidabile. È possibile elencare gli endpoint per i ARC cluster Route 53 utilizzando l'DescribeClusterAPIoperazione.

Di seguito è riportato un riepilogo di alcune delle configurazioni errate o degli anti-pattern più comuni che introducono dipendenze dai piani di controllo dei servizi globali:

Di seguito è riportato un riepilogo dei consigli forniti in questa sezione per utilizzare i servizi globali in modo resiliente, in modo da prevenire i precedenti anti-pattern comuni.