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à.
# AWS tipi di servizio
AWS gestisce tre diverse categorie di servizi in base al relativo limite di isolamento dei guasti: zonale, regionale e globale. Questa sezione descriverà più dettagliatamente come sono stati progettati questi diversi tipi di servizi in modo da poter determinare in che modo gli errori all'interno di un servizio di un determinato tipo di servizio influiranno sul carico di lavoro su cui è in esecuzione. AWS Fornisce inoltre indicazioni di alto livello su come progettare i carichi di lavoro per utilizzare questi servizi in modo resiliente. Per quanto riguarda i servizi globali, questo documento fornisce anche linee guida prescrittive [Appendice B - Guida all'assistenza globale della rete Edge](appendix-b---edge-network-global-service-guidance.md) che possono aiutare a prevenire l'impatto sui carichi di lavoro derivanti da alterazioni del piano di controllo AWS dei servizi, aiutandovi a far fronte in modo sicuro alla dipendenza dai servizi globali e riducendo al minimo l'introduzione di singoli punti di errore. [Appendice A - Guida al servizio partizionale](appendix-a---partitional-service-guidance.md)
**Topics**
+ [Servizi zonali](zonal-services.md)
+ [Servizi regionali](regional-services.md)
+ [Servizi globali](global-services.md)
# Servizi zonali
[https://aws.amazon.com/builders-library/static-stability-using-availability-zones/](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) (AZI) AWS consente di offrire servizi zonali, come Amazon EC2 e AmazonEBS. Un servizio zonale è un servizio che offre la possibilità di specificare in quale zona di disponibilità vengono distribuite le risorse. Questi servizi operano in modo indipendente in ogni zona di disponibilità all'interno di una regione e, cosa ancora più importante, falliscono indipendentemente anche in ogni zona di disponibilità. Ciò significa che i componenti di un servizio in una zona di disponibilità non dipendono dai componenti di altre zone di disponibilità. Possiamo farlo perché un servizio zonale ha piani dati **zonali**. In alcuni casi, ad esempio withEC2, il servizio include anche piani di controllo zonali per operazioni allineate a zone, come l'avvio di un'istanza. EC2 Per tali servizi, fornisce AWS anche un endpoint del piano di controllo regionale per facilitare l'interazione con il servizio. Il piano di controllo regionale offre inoltre funzionalità con ambito regionale e funge da livello di aggregazione e routing in aggiunta ai piani di controllo zonali. Ciò è illustrato nella figura riportata di seguito.
![\[Questa immagine mostra un servizio zonale con piani di controllo e piani dati isolati a livello di zona\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-fault-isolation-boundaries/images/a-zonal-service-with-zonally-isolated-control-planes-and-data-planes.png)
Le zone di disponibilità offrono ai clienti la possibilità di gestire carichi di lavoro di produzione con maggiore disponibilità, tolleranza ai guasti e scalabilità rispetto a quanto sarebbe possibile con un singolo data center. Quando un carico di lavoro utilizza più zone di disponibilità, i clienti sono meglio isolati e protetti dai problemi che influiscono sull'infrastruttura fisica di una singola zona di disponibilità. Questo aiuta i clienti a creare servizi ridondanti tra le zone di disponibilità e, se progettati correttamente, a rimanere operativi anche in caso di guasti in una zona di disponibilità. I clienti possono trarre vantaggio dalla creazione di carichi di lavoro altamente AZI disponibili e resilienti. L'implementazione AZI nell'architettura consente di ripristinare rapidamente un guasto isolato in una zona di disponibilità, poiché le risorse in una zona di disponibilità riducono al minimo o eliminano l'interazione con le risorse in altre zone di disponibilità. Questo aiuta a rimuovere le dipendenze tra zone di disponibilità, semplificando così l'evacuazione delle zone di disponibilità. Consulta [Advanced Multi-AZ Resilience Patterns](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html) per maggiori dettagli sulla creazione di meccanismi di evacuazione delle zone di disponibilità. Inoltre, è possibile sfruttare ulteriormente le zone di disponibilità seguendo alcune delle stesse best practice AWS utilizzate per i propri servizi, ad esempio implementando le modifiche a una sola zona di disponibilità alla volta o rimuovendo una zona di disponibilità dal servizio se una modifica in quella zona di disponibilità va male.
La [stabilità statica](static-stability.md) è anche un concetto importante per le architetture Multi-Availability Zone. Una delle modalità di errore da pianificare con le architetture Multi-Availability Zone è la perdita di una zona di disponibilità, che può comportare la perdita della capacità di una zona di disponibilità. Se non è stata predisposta una capacità sufficiente per gestire la perdita di una zona di disponibilità, la capacità residua potrebbe essere sovraccaricata dal carico corrente. Inoltre, sarà necessario fare affidamento sui piani di controllo dei servizi zonali utilizzati per sostituire la capacità persa, che può essere meno affidabile di un design staticamente stabile. In questo caso, predisporre in anticipo una capacità aggiuntiva sufficiente può aiutarvi a mantenere la stabilità statica in caso di perdita di un dominio di errore, come una zona di disponibilità, grazie alla possibilità di continuare le normali operazioni senza la necessità di modifiche dinamiche.
Puoi scegliere di utilizzare un gruppo di EC2 istanze con scalabilità automatica distribuite su più zone di disponibilità per scalare dinamicamente in entrata e in uscita, in base alle esigenze del tuo carico di lavoro. La scalabilità automatica è ideale per cambiamenti di utilizzo graduali che si verificano nell'arco di minuti o decine di minuti. Tuttavia, l'avvio di nuove EC2 istanze richiede tempo, soprattutto se le istanze richiedono il bootstrap (ad esempio l'installazione di agenti, file binari delle applicazioni o file di configurazione). Durante questo periodo, la capacità residua potrebbe essere superata dal carico corrente. Inoltre, l'implementazione di nuove istanze tramite la scalabilità automatica si basa sul piano di controllo. EC2 Ciò presenta un compromesso: per rimanere staticamente stabili alla perdita di una singola zona di disponibilità, è necessario predisporre un numero sufficiente di EC2 istanze nelle altre zone di disponibilità per gestire il carico che è stato spostato dalla zona di disponibilità compromessa, invece di affidarsi alla scalabilità automatica per il provisioning di nuove istanze. Tuttavia, il pre-provisioning di capacità aggiuntiva può comportare costi aggiuntivi.
Ad esempio, durante il normale funzionamento, supponiamo che il carico di lavoro richieda sei istanze per servire il traffico dei clienti in tre zone di disponibilità. Per garantire la stabilità statica in caso di guasto di una singola zona di disponibilità, è necessario implementare tre istanze in ciascuna zona di disponibilità, per un totale di nove. Se in una singola zona di disponibilità si guastasse un numero di istanze pari a sei, ne resterebbero comunque sei e saresti in grado di continuare a servire il traffico dei clienti senza dover fornire e configurare nuove istanze in caso di guasto. Il raggiungimento della stabilità statica EC2 della capacità comporta costi aggiuntivi, poiché, in questo caso, si utilizzano istanze aggiuntive del 50%. Non tutti i servizi in cui è possibile effettuare il pre-provisioning delle risorse comportano costi aggiuntivi, come il pre-provisioning di un bucket S3 o di un utente. Dovrai valutare qualsiasi compromesso derivante dall'implementazione della stabilità statica rispetto al rischio di superare il tempo di ripristino desiderato per il tuo carico di lavoro.
AWS Local Zones and Outposts avvicinano il piano dati di AWS servizi selezionati agli utenti finali. I piani di controllo per questi servizi risiedono nella regione madre. L'istanza Local Zone o Outposts avrà dipendenze dal piano di controllo per i servizi zonali come EC2 e EBS sulla zona di disponibilità in cui è stata creata la zona locale o la sottorete Outposts. Inoltre, dipenderanno dai piani di controllo regionali per i servizi regionali come Elastic Load Balancing ELB (), i gruppi di sicurezza e il piano di controllo Kubernetes gestito da Amazon Elastic [Kubernetes EKS](https://docs.aws.amazon.com/eks/latest/userguide/local-zones.html) Service (Amazon) (se lo utilizzi). EKS Per ulteriori informazioni specifiche su Outposts, consulta la [documentazione](https://docs.aws.amazon.com/outposts/latest/userguide/disaster-recovery-resiliency.html) e l'[assistenza e](https://aws.amazon.com/outposts/rack/faqs/) la manutenzione. FAQ Implementa la stabilità statica quando usi Local Zones o Outposts per migliorare la resilienza al fine di controllare i problemi o le interruzioni del piano nella connettività di rete verso la regione madre.
# Servizi regionali
I servizi regionali sono servizi che AWS si basano su più zone di disponibilità in modo che i clienti non debbano capire come utilizzare al meglio i servizi zonali. Raggruppiamo logicamente il servizio distribuito in più zone di disponibilità per presentare ai clienti un unico endpoint regionale. Amazon SQS e [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) sono esempi di servizi regionali. Sfruttano l'indipendenza e la ridondanza delle zone di disponibilità per ridurre al minimo i guasti dell'infrastruttura come categoria di rischio di disponibilità e durabilità. Amazon S3, ad esempio, distribuisce richieste e dati su più zone di disponibilità ed è progettato per il ripristino automatico in caso di guasto di una zona di disponibilità. Tuttavia, interagisci solo con l'endpoint regionale del servizio.
AWS ritiene che la maggior parte dei clienti possa raggiungere i propri obiettivi di resilienza in una singola regione utilizzando servizi regionali o architetture Multi-AZ che si basano su servizi zonali. Tuttavia, alcuni carichi di lavoro potrebbero richiedere una ridondanza aggiuntiva ed è possibile utilizzare l'isolamento di Regioni AWS per creare architetture multiregionali per scopi di elevata disponibilità o continuità aziendale. La separazione fisica e logica tra di esse evita guasti correlati tra Regioni AWS di loro. In altre parole, come se fossi un EC2 cliente e potessi trarre vantaggio dall'isolamento delle zone di disponibilità distribuendole su di esse, puoi ottenere lo stesso vantaggio per i servizi regionali distribuendoli in più regioni. Ciò richiede l'implementazione di un'architettura multiregionale per la vostra applicazione, che può aiutarvi a resistere ai danni di un servizio regionale.
Tuttavia, ottenere i vantaggi di un'architettura multiregionale può essere difficile; richiede un lavoro accurato per sfruttare l'isolamento regionale senza annullare nulla a livello di applicazione. Ad esempio, se si esegue il failover di un'applicazione tra regioni, è necessario mantenere una netta separazione tra gli stack di applicazioni in ciascuna regione, tenere conto di tutte le dipendenze delle applicazioni ed eseguire il failover di tutte le parti dell'applicazione contemporaneamente. Per raggiungere questo obiettivo con un'architettura complessa basata su microservizi che presenta molte dipendenze tra le applicazioni, è necessario pianificare e coordinare diversi team di progettazione e business. Consentire ai singoli carichi di lavoro di prendere le proprie decisioni di failover rende il coordinamento meno complesso, ma introduce un comportamento modale grazie alla significativa differenza di latenza che si verifica tra le regioni rispetto a quella all'interno di una singola regione.
AWS al momento non fornisce una funzionalità di replica sincrona tra regioni. Quando si utilizza un datastore replicato in modo asincrono (fornito da AWS) tra regioni, esiste la possibilità di perdita o incoerenza dei dati in caso di failover dell'applicazione tra regioni. Per mitigare possibili incoerenze, è necessario un processo di riconciliazione dei dati affidabile in cui avere fiducia e che potrebbe essere necessario operare su più archivi di dati in tutto il portafoglio di carichi di lavoro, oppure è necessario essere disposti ad accettare la perdita di dati. Infine, devi fare pratica con il failover per sapere che funzionerà quando ne avrai bisogno. La rotazione regolare dell'applicazione da una regione all'altra per fare pratica con il failover è un notevole investimento in termini di tempo e risorse. Se si decide di utilizzare un datastore replicato in modo sincrono in più regioni per supportare le applicazioni eseguite contemporaneamente da più di una regione, le caratteristiche prestazionali e la latenza di un database di questo tipo che si estende per centinaia o migliaia di miglia sono molto diverse da quelle di un database che opera in una singola regione. Ciò richiede di pianificare lo stack di applicazioni da zero per tenere conto di questo comportamento. Inoltre, rende la disponibilità di entrambe le regioni una forte dipendenza, il che potrebbe comportare una riduzione della resilienza del carico di lavoro.
# 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.
![\[Questa immagine mostra che IAM ha un unico piano di controllo e un piano dati regionalizzato\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-fault-isolation-boundaries/images/iam-single-control-plane-and-regionalized-data-plane.png)
Di seguito sono riportati i servizi partizionali e la loro posizione del piano di controllo nella partizione: `aws`
+ AWS IAM (`us-east-1`)
+ AWS Organizations (`us-east-1`)
+ AWS Gestione dell'account () `us-east-1`
+ Route 53 Application Recovery Controller (ARC`us-west-2`) () - Questo servizio è presente solo nella `aws` partizione
+ AWS Gestore di rete () `us-west-2`
+ Route 53 Privata DNS (`us-east-1`)
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 partizionale](appendix-a---partitional-service-guidance.md)fornisce strategie per rimuovere le dipendenze dai piani di controllo dei servizi globali durante il ripristino.
****Raccomandazione****
Non fate affidamento sui piani di controllo dei servizi partizionali nel percorso di ripristino. Affidatevi invece alle operazioni del piano dati di questi servizi. [Appendice A - Guida al servizio partizionale](appendix-a---partitional-service-guidance.md)Per ulteriori dettagli su come progettare i servizi partizionali, consulta la sezione.
## 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](points-of-presence.md) 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:
+ Route 53 Pubblica DNS () `us-east-1`
+ Amazon CloudFront (`us-east-1`)
+ AWS WAF Classico per CloudFront (`us-east-1`)
+ AWS WAF per CloudFront (`us-east-1`)
+ Amazon Certificate Manager (ACM) per CloudFront (`us-east-1`)
+ AWSAcceleratore globale (AGA) (`us-west-2`)
+ AWS Shield Advanced (`us-east-1`)
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.
****Raccomandazione****
Non fare affidamento sul piano di controllo dei servizi di rete perimetrale nel percorso di ripristino. Affidati invece alle operazioni del piano dati di questi servizi. [Appendice B - Guida all'assistenza globale della rete Edge](appendix-b---edge-network-global-service-guidance.md)Per ulteriori dettagli su come progettare servizi globali nella rete perimetrale, vedi.
## 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](appendix-c---single-region-services.md) 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:
+ **Itinerario 53**
Diversi AWS servizi creano risorse che forniscono uno o più DNS nomi specifici della risorsa. Ad esempio, quando si effettua il provisioning di un Elastic Load Balancer (ELB), il servizio crea DNS registri pubblici e controlli di integrità in Route 53 per. ELB Ciò si basa sul piano di controllo della Route 53 in. `us-east-1` Gli altri servizi che utilizzi potrebbero inoltre richiedere il provisioningELB, la creazione di DNS record pubblici della Route 53 o la creazione di controlli di integrità della Route 53 come parte dei flussi di lavoro del piano di controllo. Ad esempio, il provisioning di una REST API risorsa Amazon API Gateway, di un database Amazon Relational Database Service (RDSAmazon) o di un dominio OpenSearch Amazon Service comporta la DNS creazione di record in Route 53. Di seguito è riportato un elenco di servizi il cui piano di controllo dipende dal piano di controllo di Route 53 `us-east-1` per creare, aggiornare o eliminare DNS record, zone ospitate e/o creare controlli di integrità di Route 53. Questo elenco non è esaustivo; ha lo scopo di evidenziare alcuni dei servizi più comunemente utilizzati le cui azioni del piano di controllo per la creazione, l'aggiornamento o l'eliminazione delle risorse dipendono dal piano di controllo della Route 53:
+ Amazon API Gateway REST e HTTP APIs
+ RDSIstanze Amazon
+ Database Amazon Aurora
+ Sistemi di ELB bilanciamento del carico Amazon
+ AWS PrivateLink VPCendpoint
+ AWS Lambda URLs
+ Amazon ElastiCache
+ OpenSearch Servizio Amazon
+ Amazon CloudFront
+ Amazon MemoryDB
+ Amazon Neptune
+ Amazon DynamoDB Accelerator () DAX
+ AGA
+ Amazon Elastic Container Service (AmazonECS) con Service Discovery DNS basato su base (che utilizza la Route 53 AWS Cloud Map API per gestire Route 53DNS)
+ Piano di controllo di Amazon EKS Kubernetes
È importante notare che il VPC DNS servizio, [EC2ad esempio i nomi host](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html), esiste indipendentemente in ciascuno di essi Regione AWS e non dipende dal piano di controllo della Route 53. I record AWS creati per EC2 le istanze del VPC DNS servizio, ad esempio,`ip-10-0-10.ec2.internal`, e `ip-10-0-1-5.compute.us-west-2.compute.internal` `i-0123456789abcdef.ec2.internal``i-0123456789abcdef.us-west-2.compute.internal`, non si basano sul piano di controllo di Route 53 in. `us-east-1`
****Raccomandazione****
Non fare affidamento sulla creazione, l'aggiornamento o l'eliminazione di risorse che richiedono la creazione, l'aggiornamento o l'eliminazione di record di risorse, zone ospitate o controlli dello stato di Route 53 nel percorso di ripristino. Effettua il pre-provisioning di queste risorseELBs, ad esempio, per evitare la dipendenza dal piano di controllo della Route 53 nel tuo percorso di ripristino.
+ **Amazon S3**
Le seguenti operazioni del piano di controllo di Amazon S3 dipendono da una partizione di base. `us-east-1` `aws` Un guasto che influisce su Amazon S3 o altri servizi potrebbe compromettere le azioni di questi piani di controllo `us-east-1` in altre regioni:
```
PutBucketCors
DeleteBucketCors
PutAccelerateConfiguration
PutBucketRequestPayment
PutBucketObjectLockConfiguration
PutBucketTagging
DeleteBucketTagging
PutBucketReplication
DeleteBucketReplication
PutBucketEncryption
DeleteBucketEncryption
PutBucketLifecycle
DeleteBucketLifecycle
PutBucketNotification
PutBucketLogging
DeleteBucketLogging
PutBucketVersioning
PutBucketPolicy
DeleteBucketPolicy
PutBucketOwnershipControls
DeleteBucketOwnershipControls
PutBucketAcl
PutBucketPublicAccessBlock
DeleteBucketPublicAccessBlock
```
Il piano di controllo per Amazon S3 Multi-Region Access Points (MRAP) è [ospitato solo in](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html) tale regione `us-west-2` e le richieste di creazione, aggiornamento o eliminazione MRAPs riguardano direttamente tale regione. Il piano di controllo di ha MRAP anche dipendenze sottostanti da AGA in`us-west-2`, Route 53 in e ACM in `us-east-1` ogni regione da cui MRAP è configurato per la distribuzione dei contenuti. Non dovresti dipendere dalla disponibilità del piano di MRAP controllo nel percorso di ripristino o nei piani dati dei tuoi sistemi. Questo è diverso dai [controlli di MRAP failover](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapFailover.html) utilizzati per specificare lo stato del routing attivo o passivo per ciascuno dei bucket presenti nel. MRAP Questi APIs sono ospitati su [cinque](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html#update-mrap-route-configuration) server Regioni AWS e possono essere utilizzati per spostare efficacemente il traffico utilizzando il piano dati del servizio.
Inoltre, [i nomi dei bucket Amazon S3 sono unici a livello globale](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) e tutte le chiamate verso `CreateBucket` e `DeleteBucket` APIs dipendono `us-east-1` dalla `aws` partizione per garantire l'unicità dei nomi, anche se la API chiamata è diretta alla regione specifica in cui si desidera creare il bucket. Infine, se hai flussi di lavoro critici per la creazione di bucket, non dovresti dipendere dalla disponibilità di alcuna ortografia specifica del nome di un bucket, in particolare quelli che seguono uno schema riconoscibile.
****Raccomandazione****
Non fare affidamento sull'eliminazione o sulla creazione di nuovi bucket S3 o sull'aggiornamento delle configurazioni dei bucket S3 come parte del percorso di ripristino. Predisponi tutti i bucket S3 richiesti con le configurazioni necessarie in modo da non dover apportare modifiche per il ripristino dopo un errore. Questo approccio si applica anche a. MRAPs
+ **CloudFront**
Amazon API Gateway fornisce endpoint [ottimizzati per l'edge API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html#api-gateway-api-endpoint-types-edge-optimized). La creazione di questi endpoint dipende dal piano di CloudFront controllo utilizzato `us-east-1` per creare la distribuzione davanti all'endpoint del gateway.
****Raccomandazione****
Non fate affidamento sulla creazione di nuovi endpoint API Gateway ottimizzati per l'edge come parte del vostro percorso di ripristino. Effettua il pre-provisioning di tutti gli endpoint Gateway richiesti. API
Tutte le dipendenze discusse in questa sezione sono azioni del piano di controllo, non azioni del piano dati. Se i carichi di lavoro sono configurati per essere staticamente stabili, queste dipendenze non dovrebbero influire sul percorso di ripristino, tenendo presente che la stabilità statica richiede lavoro o servizi aggiuntivi per l'implementazione.
## Servizi che utilizzano endpoint globali predefiniti
In alcuni casi, AWS i servizi forniscono un endpoint globale predefinito, come AWS Security Token Service () [AWS STS](https://docs.aws.amazon.com/general/latest/gr/sts.html). 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](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html). L'utilizzo di SigV4a [richiede anche credenziali temporanee richieste](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#signature-versions) da un endpoint regionale. STS Non è possibile utilizzare l'endpoint globale per questa operazioneSTS.
****Raccomandazione****
Aggiorna la tua CLI configurazione SDK e per utilizzare gli STS endpoint regionali.
**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](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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html).
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 partizionale](appendix-a---partitional-service-guidance.md)Per ulteriori informazioni su come creare utenti break-glass in modo staticamente stabile, consulta
****Raccomandazione****
Aggiorna le politiche di fiducia dei IAM ruoli per accettare accessi da più regioni. SAML In caso di errore, aggiorna la configurazione dell'IdP per utilizzare un endpoint regionale diverso se l'SAMLendpoint preferito è danneggiato. Crea uno o più utenti break-glass nel caso in cui il tuo IdP sia compromesso o non disponibile.
**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](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](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtopermrelaystate.html) da utilizzare lo stesso endpoint di console regionale utilizzato per la distribuzione dell'Identity Center. [Ad esempio, se hai distribuito Identity Center in`us-west-2`, dovresti aggiornare il relaystate dei tuoi set di autorizzazioni per utilizzare https://us-west-2.console.aws.amazon.com.](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 partizionale](appendix-a---partitional-service-guidance.md)Per ulteriori informazioni su come creare utenti break-glass in modo staticamente stabile, consulta
****Raccomandazione****
Imposta il relaystate URL dei tuoi set di autorizzazioni in IAM Identity Center in modo che corrisponda alla regione in cui hai distribuito il servizio. Crea uno o più utenti ineccepibili nel caso in cui la distribuzione dell'IAMIdentity Center non sia disponibile.
**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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html#storage_lens_basics_home_region) per la configurazione della dashboard e i dati delle metriche.
****Raccomandazione****
Se hai bisogno di dati dalla dashboard predefinita di S3 Storage Lens durante un guasto che influisce sul servizio`us-east-1`, crea una dashboard aggiuntiva in una regione di origine alternativa. Puoi anche duplicare qualsiasi altra dashboard personalizzata che hai creato in altre regioni.
## 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](appendix-b---edge-network-global-service-guidance.md) per rimuovere le dipendenze dal piano di controllo [Appendice A - Guida al servizio partizionale](appendix-a---partitional-service-guidance.md) 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](https://aws.amazon.com/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](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.html) 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'`DescribeCluster`APIoperazione.
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:
+ Apportare modifiche ai record della Route 53, ad esempio aggiornare il valore di un record A o modificare i pesi di un set di record ponderato, per eseguire il failover.
+ Creazione o aggiornamento di IAM risorse, inclusi IAM ruoli e policy, durante un failover. In genere non è intenzionale, ma potrebbe essere il risultato di un piano di failover non testato.
+ Affidarsi a IAM Identity Center per consentire agli operatori di accedere agli ambienti di produzione in caso di guasto.
+ Affidarsi alla configurazione predefinita di IAM Identity Center per utilizzare la console `us-east-1` quando Identity Center è stato distribuito in un'altra regione.
+ Apportare modifiche ai pesi dei AGA numeri di traffico per eseguire manualmente un failover regionale.
+ Aggiornamento della configurazione di origine di una CloudFront distribuzione per eliminare un'origine compromessa.
+ Fornitura di risorse di disaster recovery (DR), ad esempio ELBs e RDS istanze durante un evento di errore, che dipendono dalla creazione di DNS record in Route 53.
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.
****Riepilogo delle raccomandazioni****
Non fare affidamento sui piani di controllo dei servizi partizionali nel percorso di ripristino. Affidatevi invece alle operazioni del piano dati di questi servizi. [Appendice A - Guida al servizio partizionale](appendix-a---partitional-service-guidance.md)Per ulteriori dettagli su come progettare i servizi partizionali, consulta la sezione.
Non fate affidamento sul piano di controllo dei servizi di rete perimetrale nel vostro percorso di ripristino. Affidati invece alle operazioni del piano dati di questi servizi. [Appendice B - Guida all'assistenza globale della rete Edge](appendix-b---edge-network-global-service-guidance.md)Per ulteriori dettagli su come progettare servizi globali nella rete perimetrale, vedi.
Non fare affidamento sulla creazione, l'aggiornamento o l'eliminazione di risorse che richiedono la creazione, l'aggiornamento o l'eliminazione dei record di risorse, delle zone ospitate o dei controlli dello stato di Route 53 nel percorso di ripristino. Effettua il pre-provisioning di queste risorseELBs, ad esempio, per evitare la dipendenza dal piano di controllo della Route 53 nel tuo percorso di ripristino.
Non fare affidamento sull'eliminazione o sulla creazione di nuovi bucket S3 o sull'aggiornamento delle configurazioni dei bucket S3 come parte del percorso di ripristino. Predisponi tutti i bucket S3 richiesti con le configurazioni necessarie in modo da non dover apportare modifiche per il ripristino dopo un errore. Questo approccio si applica anche a. MRAPs
Non fate affidamento sulla creazione di nuovi endpoint API Gateway ottimizzati per l'edge come parte del vostro percorso di ripristino. Effettua il pre-provisioning di tutti gli endpoint Gateway richiesti. API
Aggiorna la tua CLI configurazione SDK e utilizza gli endpoint regionaliSTS.
Aggiorna le politiche di fiducia dei IAM ruoli per accettare SAML accessi da più regioni. In caso di errore, aggiorna la configurazione dell'IdP per utilizzare un endpoint regionale diverso se l'SAMLendpoint preferito è danneggiato. Crea utenti eccezionali nel caso in cui il tuo IdP sia compromesso o non disponibile.
Imposta lo stato URL di inoltro dei tuoi set di autorizzazioni in IAM Identity Center in modo che corrisponda alla regione in cui hai distribuito il servizio. Crea uno o più utenti ineccepibili nel caso in cui la distribuzione dell'Identity Center non sia disponibile.
Se hai bisogno di dati dal pannello di controllo predefinito di S3 Storage Lens in caso di guasto che influisce sul servizio in`us-east-1`, crea un pannello di controllo aggiuntivo in una regione alternativa. Puoi anche duplicare qualsiasi altra dashboard personalizzata che hai creato in altre regioni.