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

Appendice B - Guida all'assistenza globale della rete Edge

Per i servizi globali della rete edge, è necessario implementare la stabilità statica per mantenere la resilienza del carico di lavoro durante un deterioramento del piano di controllo del AWS servizio.

Route 53

Il piano di controllo di Route 53 è composto da tutte le API pubbliche di Route 53 che coprono funzionalità per zone ospitate, record, controlli di integrità, registri di query DNS, set di deleghe riutilizzabili, politiche di traffico e tag di allocazione dei costi. È ospitazione in us-east-1. Il piano dei dati è il servizio DNS autoritativo, che funziona in oltre 200 punti PoP e che risponde alle query DNS basate sulle tue zone ospitate e sui dati di controllo dell'integrità. Regione AWS Inoltre, Route 53 dispone di un piano dati per i controlli sanitari, che è anche un servizio distribuito a livello globale su più dispositivi. Regioni AWS Questo piano dei dati esegue i controlli dell'integrità, aggrega i risultati e li consegna ai piani dati di Route 53. Durante un guasto al piano di controllo, le operazioni di tipo CRUDL per la Route 53 potrebbero non funzionare, ma la risoluzione e i controlli di integrità del DNS e gli aggiornamenti del routing derivanti da modifiche nei controlli sanitari continueranno a funzionare.

Ciò significa che quando si pianificano dipendenze dalla Route 53, non è necessario fare affidamento sul piano di controllo della Route 53 nel percorso di ripristino. Ad esempio, una progettazione staticamente stabile consiste nell'utilizzare lo stato dei controlli sanitari per eseguire failover tra regioni o per evacuare una zona di disponibilità. È possibile utilizzare i controlli di routing ARC (Application Recovery Controller) di Route 53 per modificare manualmente lo stato dei controlli di integrità e modificare le risposte alle domande DNS. Esistono modelli simili a quelli forniti da ARC che è possibile implementare in base alle proprie esigenze. Alcuni di questi modelli sono descritti nella sezione Creazione di meccanismi di ripristino di emergenza utilizzando Route 53 e nella sezione sugli interruttori automatici di controllo dello stato di salute di Advanced Multi-AZ Resilience Patterns. Se hai scelto di utilizzare un piano di ripristino di emergenza multiregionale, predisponi le risorse che richiedono la creazione di record DNS, come le istanze ELB e RDS. Un non-statically-stable progetto potrebbe consistere nell'aggiornare il valore di un record di risorse Route 53 tramite l'ChangeResourceRecordSetsAPI, modificare il peso di un record ponderato o creare nuovi record per eseguire il failover. Questi approcci dipendono dal piano di controllo della Route 53.

Amazon CloudFront

Il piano di CloudFront controllo di Amazon è composto da tutte le CloudFront API pubbliche per la gestione delle distribuzioni ed è ospitato in us-east-1. Il piano dati è la distribuzione stessa fornita dalla PoPs rete perimetrale. Esegue la gestione delle richieste, il routing e la memorizzazione nella cache dei contenuti di origine. Durante un guasto al piano di controllo, le operazioni di tipo CRUDL CloudFront (comprese le richieste di annullamento della validità) potrebbero non funzionare, ma i tuoi contenuti continueranno a essere memorizzati nella cache e serviti e i failover di origine continueranno a funzionare.

Ciò significa che quando si pianificano le dipendenze daCloudFront, non è necessario fare affidamento sul piano di CloudFront controllo nel percorso di ripristino. Ad esempio, una progettazione staticamente stabile prevede l'utilizzo di failover di origine automatizzati per mitigare l'impatto di una lesione su una delle origini. Puoi anche scegliere di creare il bilanciamento del carico di origine o il failover utilizzando Lamda @Edge, fare riferimento a Tre modelli di progettazione avanzati per applicazioni ad alta disponibilità utilizzando Amazon CloudFront e Utilizzo di Amazon CloudFront e Amazon S3 per creare applicazioni di geo-prossimità attive e multiregionali per maggiori dettagli su tale modello. Un non-statically-stable progetto potrebbe consistere nell'aggiornare manualmente la configurazione della distribuzione in risposta a un errore di origine. Questo approccio dipenderebbe dal piano CloudFront di controllo.

Amazon Certificate Manager

Se utilizzi certificati personalizzati con la tua CloudFront distribuzione, dipendi anche da ACM. L'utilizzo dello CloudFront scudo di controllo nella regione us-east-1. Durante un guasto al piano di controllo, i certificati esistenti configurati nella distribuzione continueranno a funzionare così come i rinnovi automatici dei certificati. Non fare affidamento sulla modifica della configurazione della distribuzione o sulla creazione di nuovi certificati come parte del percorso di ripristino.

AWSWeb Application Firewall (WAF) e WAF Classic

Se lo utilizzi AWS WAF con la tua CloudFront distribuzione, dipendi dal piano di controllo WAF, anch'esso ospitato nella regione us-east-1. Durante un guasto al piano di controllo, gli elenchi di controllo degli accessi Web (ACL) configurati e le regole associate continuano a funzionare. Non fare affidamento sull'aggiornamento degli ACL Web WAF come parte del percorso di ripristino.

AWS Global Accelerator

Il piano di controllo AGA è composto da tutte le API AGA pubbliche ed è ospitato in us-west-2. Il piano dati è il routing di rete degli indirizzi IP anycast forniti da AGA agli endpoint registrati. AGA utilizza anche i controlli di integrità della Route 53 per determinare lo stato degli endpoint AGA, che fa parte del piano dati Route 53. Durante un guasto al piano di controllo, le operazioni di tipo CRUDL per AGA potrebbero non funzionare. L'instradamento verso gli endpoint esistenti, così come i controlli di integrità, le chiamate stradali e le configurazioni di peso degli endpoint esistenti utilizzate per indirizzare o spostare il traffico verso altri endpoint e gruppi di endpoint, continueranno a funzionare.

Ciò significa che quando si pianificano dipendenze da AGA, non è necessario fare affidamento sul piano di controllo AGA nel percorso di ripristino. Ad esempio, una progettazione staticamente stabile consiste nell'utilizzare lo stato dei controlli di integrità configurati per eliminare gli endpoint non integri. Per esempi di questa configurazione, consulta Implementazione di applicazioni multiregionali AWS utilizzando AWS Global Accelerator. Un non-statically-stable progetto potrebbe consistere nel modificare le percentuali di chiamata del traffico AGA, modificare i gruppi di endpoint o rimuovere un endpoint da un gruppo di endpoint durante un problema. Questi approcci dipenderebbero dal piano di controllo AGA.

Shield

Il piano di controllo Amazon Shield Advanced è composto da tutte le API Shield Advanced pubbliche ed è ospitato in us-east-1. Ciò include funzionalità come CreateProtectionCreateProtectionGroup,AssociateHealthCheck,DesribeDRTAccess, eListProtections. Il piano dati è la protezione DDoS fornita da Shield Advanced e la creazione di metriche Shield Advanced. Shield Advanced utilizza anche i controlli di integrità della Route 53 (che fanno parte del piano dati Route 53), se li hai configurati. Durante un guasto al piano di controllo, le operazioni di tipo CRUDL per Shield Advanced potrebbero non funzionare, ma la protezione DDoS configurata per le tue risorse, così come le risposte ai cambiamenti nei controlli sanitari, continueranno a funzionare.

Ciò significa che non è necessario fare affidamento sul piano di controllo Shield Advanced nel percorso di ripristino. Sebbene il piano di controllo Shield Advanced non fornisca funzionalità dirette che normalmente si utilizzano in una situazione di ripristino, in alcuni casi è possibile che ciò avvenga. Ad esempio, una progettazione staticamente stabile prevede che le risorse di ripristino di emergenza siano già configurate per far parte di un gruppo di protezione e che vengano associati controlli di integrità anziché configurare tale protezione dopo il verificarsi dell'errore. Ciò impedisce di dipendere dal piano di controllo Shield Advanced per il ripristino.