

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

# Controlli di resilienza per AWS services
<a name="resilience-checks"></a>

Questo capitolo fornisce i dettagli dei vari controlli di resilienza eseguiti dai AWS servizi supportati AWS Resilience Hub per garantire che i livelli di resilienza delle applicazioni non siano influenzati. Questi controlli stimano il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO) rispetto ai valori definiti nella politica di resilienza per ogni componente dell'applicazione (). AppComponent Le valutazioni comprendono diversi tipi di interruzioni, ovvero guasti delle applicazioni, dell'infrastruttura, interruzioni della zona AZ e guasti regionali. Tuttavia, per eseguire questi controlli devi fornire le autorizzazioni IAM pertinenti per consentirgli di accedere alle AWS Resilience Hub tue risorse. Per ulteriori informazioni sulle autorizzazioni IAM richieste per consentire l'accesso AWS Resilience Hub alle risorse ed eseguire i controlli di resilienza descritti in questo capitolo, consulta. [AWS politiche gestite per AWS Resilience Hub](security-iam-awsmanpol.md)

**Topics**
+ [Amazon Elastic File System](#resilience-check-efs)
+ [Amazon Relational Database Service e Amazon Aurora](#resilience-check-rds)
+ [Amazon Simple Storage Service](#resilience-check-s3)
+ [Amazon DynamoDB](#resilience-check-ddb)
+ [Amazon Elastic Compute Cloud](#resilience-checks-ec2)
+ [Amazon EBS](#resilience-checks-ebs)
+ [AWS Lambda](#resilience-checks-lambda)
+ [Amazon Elastic Kubernetes Service](#resilience-checks-eks)
+ [Amazon Simple Notification Service](#resilience-checks-sns)
+ [Amazon Simple Queue Service](#resilience-checks-sqs)
+ [Amazon Elastic Container Service](#resilience-checks-ecs)
+ [Elastic Load Balancing](#resilience-checks-elb)
+ [Gateway Amazon API](#resilience-checks-abp)
+ [Amazon DocumentDB](#resilience-checks-docdb)
+ [Gateway NAT](#resilience-checks-nat-gateway)
+ [Amazon Route 53](#resilience-checks-r53)
+ [Amazon Application Recovery Controller (ARC)](#resilience-checks-r53arc)
+ [Amazon FSx per Windows File Server](#resilience-checks-fsx)
+ [AWS Step Functions](#resilience-checks-step-func)
+ [Amazon ElastiCache (sistema operativo Redis)](#resilience-checks-elstc-cache-srvrless)

## Amazon Elastic File System
<a name="resilience-check-efs"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici per Amazon Elastic File System. Per ulteriori informazioni su Amazon Elastic File System, consulta la [documentazione di Amazon Elastic File System](https://docs.aws.amazon.com//efs).

### Tipo di file system
<a name="one-az-deployment"></a>

AWS Resilience Hub controlla il tipo di file system: Regionale o One Zone. Il tipo di file system influisce sulla sua resilienza in caso di interruzioni dell'infrastruttura o della zona di disponibilità. Per ulteriori informazioni sui tipi di file system, consulta [Disponibilità e durabilità dei file system Amazon EFS](https://docs.aws.amazon.com//efs/latest/ug/features.html#availability-durability).

### Backup del file system
<a name="filesystem-backup"></a>

AWS Resilience Hub verifica se è definito un AWS Backup piano per il filesystem distribuito. Inoltre, verifica se l'opzione di `Cross-Region` backup è abilitata, garantendo la copertura in caso di Region-level interruzioni, se richiesto dalla politica.

### Replica dei dati
<a name="data-replication"></a>

AWS Resilience Hub verifica se è definita una replica dei dati Amazon EFS a livello regionale o interregionale per il file system distribuito. La replica dei dati di Amazon EFS aiuta a migliorare l'RTO stimato e l'RPO stimato a livello di applicazione, infrastruttura, AZ e regione. Inoltre, AWS Resilience Hub verifica se è combinata con una soluzione In-Region AWS Backup per abilitare la resilienza del file system in caso di interruzione delle applicazioni.

## Amazon Relational Database Service e Amazon Aurora
<a name="resilience-check-rds"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici per Amazon Relational Database Service e Amazon Aurora. Per ulteriori informazioni su Amazon Relational Database Service e Amazon Aurora[, consulta la documentazione di Amazon Relational Database Service](https://docs.aws.amazon.com//rds/).

### Single-AZ distribuzione
<a name="one-az-deployment-rds"></a>

AWS Resilience Hub verifica se il database è distribuito come singola istanza e, se determinato, indica che non supporta istanze secondarie e repliche di lettura.

### Multi-AZ distribuzione
<a name="multi-az-deployment-rds"></a>

AWS Resilience Hub verifica se il database è distribuito con istanze secondarie o repliche di lettura. Se il database viene distribuito con una replica di lettura, AWS Resilience Hub convalida se è distribuito in una zona di disponibilità diversa per consentire il failover in caso di interruzione della zona di disponibilità. 

### Backup
<a name="rds-bckp"></a>

AWS Resilience Hub verifica se le seguenti funzionalità di backup sono applicate a un'istanza di database distribuita.
+ AWS Backup piano con opzione di backup automatico
+ AWS Backup pianifica con una copia di backup interregionale, se richiesto dalla tua politica
+ Istantanee manuali per sistemi di backup di terze parti

### Cross-Region failover
<a name="rds-cross-Region-failover"></a>

AWS Resilience Hub verifica gli obiettivi RTO e RPO definiti nella politica di resilienza per riprendersi dalle perturbazioni regionali. Inoltre, è in AWS Resilience Hub grado di identificare le seguenti architetture interregionali per far fronte alle interruzioni regionali:
+ Un backup interno alla regione con una copia di un'istantanea interregionale
+ Una replica di lettura in un'altra regione
+ Un database globale Amazon Aurora con un cluster secondario in un'altra regione
+ Un database globale Amazon Aurora con un cluster secondario headless in un'altra regione

### Failover più rapido all'interno della regione
<a name="rds-faster-in-Region-failover"></a>

AWS Resilience Hub verifica gli obiettivi RTO e RPO definiti nella politica di resilienza durante interruzioni dell'infrastruttura o della zona di disponibilità. Inoltre, AWS Resilience Hub è in grado di identificare le seguenti architetture regionali per far fronte alle interruzioni delle applicazioni, dell'infrastruttura e della zona di disponibilità: 
+ Un backup In-Region 
+ Una replica di lettura in una AZ diversa
+ Un cluster Aurora con una replica di lettura in un'altra AZ
+ Un' Multi-AZ istanza di Amazon Relational Database Service (Amazon RDS)
+ Un cluster Amazon RDS Multi-AZ 
+ Una singola istanza di Amazon RDS con una replica di lettura in un'altra zona

## Amazon Simple Storage Service
<a name="resilience-check-s3"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici per Amazon Simple Storage Service (Amazon S3). Per ulteriori informazioni su Amazon S3, consulta la documentazione di [Amazon S3](https://docs.aws.amazon.com//s3).

### Controllo delle versioni
<a name="versioning-s3"></a>

AWS Resilience Hub verifica se un bucket Amazon S3 è configurato con il controllo delle versioni abilitato.

### Backup pianificato
<a name="scheduled-bckp-s3"></a>

AWS Resilience Hub verifica se è definito un AWS Backup piano per il bucket Amazon Simple Storage Service (Amazon S3) distribuito. Inoltre, verifica anche se l'opzione di backup interregionale è abilitata se la tua politica richiede una copertura in caso di interruzioni. Region-level 

#### Point-in-time recupero
<a name="pitr-s3"></a>

AWS Resilience Hub verifica se il ripristino point-in-time (PITR) è richiesto dall'obiettivo RPO della politica di resilienza. Tuttavia, il backup interregionale non è supportato per PITR. Pertanto, è possibile utilizzare un AWS Backup piano pianificato esistente con l'opzione di backup interregionale abilitata o crearne uno nuovo.

### Replica dei dati
<a name="data-repilication-s3"></a>

AWS Resilience Hub verifica se per il bucket Amazon S3 distribuito sono state definite Same Region Replication (SRR) e Cross Region Replication (CRR). La replica dei dati di Amazon S3 migliora l'RTO stimato del carico di lavoro e l'RPO stimato del carico di lavoro a livello di applicazione, infrastruttura, AZ e regione. Inoltre, protegge anche dall'eliminazione fisica dell'oggetto, poiché l'eliminazione di una versione dell'oggetto non viene replicata nel bucket Amazon S3 di destinazione. Inoltre, in base agli obiettivi RTO definiti nella tua politica di resilienza, AWS Resilience Hub verifica se Amazon S3 Replication Time Control (S3 RTC) deve essere abilitato o meno. Questa funzionalità fatturabile replica il 99,99% degli oggetti bucket di origine entro 15 minuti.
+ AWS Backup piano con opzione di backup automatico
+ AWS Backup pianifica con una copia di backup interregionale, se richiesto dalla tua politica
+ Istantanee manuali per sistemi di backup di terze parti

## Amazon DynamoDB
<a name="resilience-check-ddb"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici per Amazon DynamoDB. Per ulteriori informazioni su Amazon DynamoDB, consulta la documentazione di Amazon [DynamoDB](https://docs.aws.amazon.com//dynamodb).

### Backup pianificato
<a name="scheduled-bckp-ddb"></a>

AWS Resilience Hub verifica se è già stato definito un backup per la tabella distribuita. Inoltre, verifica anche se il backup interregionale deve essere configurato per la vostra politica se richiede una copertura in caso di interruzioni. Region-level 

#### Point-in-time recupero
<a name="pitr-ddb"></a>

AWS Resilience Hub verifica se è necessario il ripristino point-in-time (PITR) in base all'obiettivo RPO della politica di resilienza. Tuttavia, il backup interregionale non è supportato per PITR. Pertanto, è possibile utilizzare un AWS Backup piano pianificato esistente con l'opzione di backup interregionale abilitata o crearne uno nuovo.

### Tabella globale
<a name="global-table-ddb"></a>

AWS Resilience Hub verifica se la tabella Amazon DynamoDB distribuita è definita come tabella globale con una o più repliche in altre regioni. La configurazione di Global Table migliora l'RTO del carico di lavoro stimato e l'RPO del carico di lavoro stimato a livello di regione e offre anche la possibilità di lavorare in modalità attiva-attiva o attiva-passiva multiregione. AWS Backup oppure Amazon DynamoDB PITR può essere utilizzato in una delle regioni per gestire le interruzioni delle applicazioni.

## Amazon Elastic Compute Cloud
<a name="resilience-checks-ec2"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici per Amazon Elastic Compute Cloud. Per ulteriori informazioni su Amazon Elastic Compute Cloud, consulta la documentazione di [Amazon Elastic Compute Cloud](https://docs.aws.amazon.com//ec2).

### Istanza con stato
<a name="stateful-instance-ec2"></a>

AWS Resilience Hub identifica un'istanza Amazon EC2 come istanza con stato se viene soddisfatto uno dei seguenti criteri:
+ Se `DeleteOnTermination` l'attributo è impostato su false per almeno un volume Amazon Elastic Block Store (Amazon EBS) collegato a questa istanza.
+ Se Amazon Data Lifecycle Manager o un AWS Backup piano sono collegati all'istanza Amazon EC2 o ad almeno un volume Amazon EBS.
+  AWS Elastic Disaster Recovery Viene utilizzato per replicare i volumi di storage delle istanze Amazon EC2.

**Nota**  
Se un'istanza Amazon EC2 non soddisfa nessuno dei criteri sopra indicati, la AWS Resilience Hub considera un'istanza Amazon EC2 stateless.

### Gruppi Auto Scaling
<a name="asg-ec2"></a>

AWS Resilience Hub verifica la presenza di un gruppo di istanze Amazon EC2 stateless. Se scoperto, si consiglia di orchestrare lo stesso utilizzando i gruppi di Auto Scaling (ASG) con configurazione. Multi-AZ Se viene identificato un ASG esistente, ARH verificherà se è configurato su più zone di disponibilità. Se ASG è definito anche utilizzando solo istanze Amazon EC2 spot, si consiglia di aumentarne la capacità con istanze Amazon EC2 on-demand per migliorare la resilienza quando le istanze spot Amazon EC2 non sono disponibili.

### Flotta Amazon EC2
<a name="fleet-ec2"></a>

AWS Resilience Hub identifica la flotta Amazon EC2 e verifica se è definita Multi-AZ come distribuzione e anche se utilizza solo istanze spot di Amazon EC2. La definizione di una flotta Amazon EC2 come Multi-AZ implementazione ne migliorerà la resilienza in caso di interruzione della zona di disponibilità. L'ampliamento di una flotta Amazon EC2 con istanze on demand ne migliorerà la resilienza quando le istanze spot non sono disponibili.

## Amazon EBS
<a name="resilience-checks-ebs"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici per Amazon EBS. Per ulteriori informazioni su Amazon EBS, consulta la documentazione di [Amazon EBS.](https://docs.aws.amazon.com//ebs/)

### Backup pianificato
<a name="scheduled-backup-ebs"></a>

AWS Resilience Hub verifica se uno o entrambi i seguenti elementi sono definiti per i tuoi volumi Amazon EBS.
+  Una regola di backup per un volume Amazon EBS specifico collegato alla tua istanza Amazon EC2. 
+  Una regola di backup per creare Amazon EBS-backed AMI sulla tua istanza Amazon EC2. 
+  Istantanee manuali per sistemi di backup di terze parti. 

Inoltre, se la tua politica richiede una copertura in caso di Region-level interruzioni, AWS Resilience Hub verifica se la regola di backup ha abilitato l'opzione di backup interregionale.

### Backup e replica dei dati
<a name="data-backup-replication-ebs"></a>

AWS Resilience Hub identifica che un volume Amazon EBS è considerato un volume con stato se viene soddisfatto uno dei seguenti criteri:
+  Se `DeleteOnTermination` l'attributo è impostato su false per questo volume Amazon EBS. 
+  Se Amazon Data Lifecycle Manager o un AWS Backup piano è associato a questo volume Amazon EBS o all'istanza Amazon EC2 a cui è collegato. 
+  AWS Elastic Disaster Recovery Viene utilizzato per replicare i volumi di storage delle istanze Amazon EC2.

## AWS Lambda
<a name="resilience-checks-lambda"></a>

Questa sezione elenca tutti i controlli e le raccomandazioni di resilienza specifici per. AWS Lambda Per ulteriori informazioni in merito AWS Lambda, consulta [AWS Lambda la documentazione](https://docs.aws.amazon.com//lambda/).

### Cliente Amazon VPC Access
<a name="customer-vpc-access-lambda"></a>

AWS Resilience Hub identifica una AWS Lambda funzione connessa al VPC. La connessione AWS Lambda a sottoreti in diverse AZ del tuo Amazon VPC consente la resilienza delle funzioni in caso di interruzione della zona di disponibilità. 

### Dead-letter coda
<a name="dlq-lambda"></a>

AWS Resilience Hub verifica se a una AWS Lambda funzione è associata una coda di lettere morte (DLQ) per archiviare le richieste non riuscite. Il collegamento di un DLQ alla AWS Lambda funzione consente di prevenire la perdita di dati delle richieste e di riprovare a elaborare le richieste non riuscite in una fase successiva.

## Amazon Elastic Kubernetes Service
<a name="resilience-checks-eks"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici per Amazon Elastic Kubernetes Service (Amazon EKS). Per ulteriori informazioni su Amazon EKS, consulta la [documentazione di Amazon EKS](https://docs.aws.amazon.com//eks/).

### Multi-AZ implementazione
<a name="multi-az-eks"></a>

AWS Resilience Hub identifica se la distribuzione dei pod è in esecuzione su più nodi di lavoro in più AZ. È necessario un cluster Amazon EKS aggiuntivo in un'altra regione se la politica di resilienza richiede una copertura in caso di interruzione regionale. Questo cluster Amazon EKS aggiuntivo è inoltre verificato per le implementazioni di pod distribuite tra più nodi di lavoro in più AZ.

### Distribuzione vs. ReplicaSet
<a name="deployment-replica-set-eks"></a>

AWS Resilience Hub verifica se si utilizzano oggetti ReplicaSets o pod anziché distribuirli. La sostituzione degli oggetti ReplicaSets o pod con la distribuzione semplifica gli aggiornamenti del pod a una nuova versione del software e include altre utili funzionalità.

### Installazione e manutenzione
<a name="deployment-maintenance-eks"></a>

AWS Resilience Hub verifica se per la distribuzione vengono utilizzate le seguenti best practice:
+ Utilizzo di Pod Disruption Budget (PDB): l'utilizzo di PDB consente di migliorare la disponibilità impostando un limite al numero di pod del carico di lavoro che possono essere interrotti in un dato momento.
+ Sostituzione dei gruppi di nodi autogestiti con gruppi di nodi gestiti da Amazon EKS: questa sostituzione semplifica gli aggiornamenti delle immagini dei nodi di lavoro durante la manutenzione.
+ Supporto di richieste dinamiche di CPU e memoria per implementazione: queste richieste aiutano Kubernetes a selezionare un nodo adatto alle esigenze di un pod.
+ Configurazione delle sonde di vivibilità e prontezza per tutti i contenitori: la configurazione delle sonde di vivibilità aiuta a migliorare la resilienza riavviando i pod non funzionanti. La configurazione delle sonde di prontezza consente di migliorare la disponibilità deviando il traffico dai pod occupati.
+ Configurazione di Karpenter, Cluster Autoscaler o: AWS Fargate queste configurazioni consentono all'infrastruttura del cluster Amazon EKS di crescere e soddisfare le richieste di carico di lavoro.
+ Configurazione di Horizontal Pod Autoscaler: questa configurazione aiuta il cluster Amazon EKS a scalare automaticamente il carico di lavoro per soddisfare la domanda di elaborazione delle richieste.

## Amazon Simple Notification Service
<a name="resilience-checks-sns"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici per Amazon Simple Notification Service (Amazon SNS). Per ulteriori informazioni su Amazon SNS, consulta la documentazione di [Amazon SNS](https://docs.aws.amazon.com//sns/).

### Abbonamenti tematici
<a name="topic-subscriptions-sns"></a>

AWS Resilience Hub verifica se all'argomento Amazon SNS è associato almeno un abbonamento per garantire che i messaggi in arrivo non vadano persi.

## Amazon Simple Queue Service
<a name="resilience-checks-sqs"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici per Amazon Simple Queue Service (Amazon SQS). Per ulteriori informazioni su Amazon SQS, consulta la documentazione di [Amazon SQS.](https://docs.aws.amazon.com//sqs/)

### Dead-letter coda
<a name="dlq-sqs"></a>

AWS Resilience Hub verifica se alla coda Amazon SQS è associato un DLQ per gestire i messaggi che non possono essere recapitati correttamente agli abbonati.

## Amazon Elastic Container Service
<a name="resilience-checks-ecs"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici di Amazon Elastic Container Service (Amazon ECS). Per ulteriori informazioni su Amazon ECS, consulta la documentazione di [Amazon ECS.](https://docs.aws.amazon.com//ecs/)

### Multi-AZ implementazione
<a name="multi-az-ecs"></a>

AWS Resilience Hub verifica se le attività o i servizi di Amazon ECS sono in esecuzione su più AZ in base ad Amazon EC2 AWS Fargate o ai tipi di avvio. È necessario un cluster Amazon ECS aggiuntivo in un'altra regione se la tua polizza richiede una copertura per le interruzioni regionali. Il cluster aggiuntivo viene inoltre verificato per l'esecuzione di attività o servizi in più AZ.

## Elastic Load Balancing
<a name="resilience-checks-elb"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici per Elastic Load Balancing. Per ulteriori informazioni su Elastic Load Balancing, consulta la documentazione di [Elastic Load](https://docs.aws.amazon.com//elasticloadbalancing/) Balancing.

### Multi-AZ distribuzione
<a name="multi-az-deployment-elb"></a>

AWS Resilience Hub verifica se Elastic Load Balancing è in esecuzione su più AZ. 

È necessario un Elastic Load Balancing aggiuntivo in un'altra regione se la tua polizza necessita di una copertura per le interruzioni regionali. L'Elastic Load Balancing aggiuntivo, situato in una regione diversa, viene inoltre verificato per la sua implementazione in più AZ.

## Gateway Amazon API
<a name="resilience-checks-abp"></a>

Questa sezione elenca tutti i controlli e i consigli di resilienza specifici per Amazon API Gateway. Per ulteriori informazioni su Amazon API Gateway, consulta la [documentazione di Amazon API Gateway](https://docs.aws.amazon.com//apigateway).

### Cross-Region implementazione
<a name="cross-region-deployment-abp"></a>

Se la tua politica deve prendere in considerazione l'interruzione regionale, AWS Resilience Hub verificherà se è presente un'ulteriore distribuzione della risorsa API Amazon API Gateway in un'altra regione.

### Implementazione di API Multi-AZ private
<a name="Private-api-multi-az-deployment-abp"></a>

AWS Resilience Hub verifica se la tua API è definita come privata all'interno di Amazon API Gateway. Le API private dovrebbero ricevere traffico tramite l'endpoint dell'interfaccia Amazon VPC distribuito su più AZ.

## Amazon DocumentDB
<a name="resilience-checks-docdb"></a>

Questa sezione elenca tutti i controlli e i consigli specifici di Amazon DocumentDB. Per ulteriori informazioni su Amazon DocumentDB, consulta la documentazione di [Amazon DocumentDB](https://docs.aws.amazon.com//documentdb/).

### Multi-AZ distribuzione
<a name="multi-az-deployment-ddb"></a>

AWS Resilience Hub verifica se il cluster Amazon DocumentDB è distribuito in più AZ. È necessario un cluster Amazon DocumentDB secondario aggiuntivo in una regione diversa se la politica richiede una copertura per le interruzioni regionali. Il cluster Amazon DocumentDB aggiuntivo, situato in una regione diversa, viene inoltre verificato per la sua esecuzione in più AZ.

### Cluster e distribuzione elastici Multi-AZ
<a name="elastic-cluster-multi-az-deployment-ddb"></a>

AWS Resilience Hub verifica se gli shard di cluster Elastic di Amazon DocumentDB utilizzano repliche di lettura distribuite in diverse AZ.

### Cluster elastico e istantanee manuali
<a name="elastic-cluster-manual-snapshots-ddb"></a>

AWS Resilience Hub verifica se vengono create regolarmente istantanee manuali per un cluster Amazon DocumentDB Elastic. Le istantanee manuali consentono una persistenza più lunga e offrono flessibilità nell'impostazione della frequenza delle istantanee in base alle esigenze aziendali.

## Gateway NAT
<a name="resilience-checks-nat-gateway"></a>

Questa sezione elenca tutti i controlli e i consigli specifici di NAT Gateway. [Per ulteriori informazioni sui gateway NAT, vedere NAT Gateways.](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-nat-gateway.html)

### Multi-AZ distribuzione
<a name="multi-az-deployment-nat"></a>

AWS Resilience Hub verifica se NAT Gateway è distribuito in più AZ. È necessaria un'ulteriore implementazione di NAT Gateway in una regione diversa se la politica richiede una copertura per le interruzioni regionali. Il gateway NAT aggiuntivo, situato in una regione diversa, viene inoltre verificato per la sua implementazione in più AZ.

## Amazon Route 53
<a name="resilience-checks-r53"></a>

Questa sezione elenca tutti i controlli e i consigli specifici di Amazon Route 53. Per ulteriori informazioni su Amazon Route 53, consulta la [documentazione di Amazon Route 53](https://docs.aws.amazon.com//route53/).

### Multi-AZ distribuzione
<a name="multi-az-deployment-r53"></a>

AWS Resilience Hub verifica se il record della zona ospitata di Amazon Route 53 è definito con più destinazioni nella stessa regione e se tali destinazioni sono distribuite in più AZ. Se la tua politica richiede una copertura per le interruzioni regionali, AWS Resilience Hub verifica se il record della zona ospitata di Amazon Route 53 è definito in più regioni con più destinazioni per regione e se tali destinazioni sono distribuite in più AZ.

## Amazon Application Recovery Controller (ARC)
<a name="resilience-checks-r53arc"></a>

Questa sezione elenca tutti i controlli e i consigli specifici di Amazon Application Recovery Controller (ARC) (ARC). Per ulteriori informazioni su ARC, consulta la [documentazione di ARC](https://docs.aws.amazon.com//amazonarc/).

### Multi-AZ distribuzione
<a name="multi-az-deployment-r53arc"></a>

AWS Resilience Hub verifica se risorse simili sono distribuite in più regioni e consiglia, come best practice, di definire controlli di preparazione ARC per aumentarne la disponibilità e la prontezza in caso di interruzioni regionali. Ti verrà comunicato che dovrai sostenere costi orari aggiuntivi.

## Amazon FSx per Windows File Server
<a name="resilience-checks-fsx"></a>

Questa sezione elenca tutti i controlli e i consigli specifici di Amazon FSx for Windows File Server. Per ulteriori informazioni su Amazon FSx for Windows File Server, consulta la documentazione di [Amazon FSx for Windows](https://docs.aws.amazon.com//fsx/) File Server.

### Tipo di file system
<a name="filesystem-type-fsx"></a>

AWS Resilience Hub controlla il tipo di filesystem: o. `Regional` `One Zone` Il tipo di file system influisce sulla sua resilienza in caso di interruzioni dell'infrastruttura o della zona di disponibilità. [Per ulteriori informazioni sui tipi di file system, consulta Amazon EFS.](https://docs.aws.amazon.com//efs/latest/ug/availability-durability.html)

### Backup del file system
<a name="filesystem-backup-fsx"></a>

AWS Resilience Hub controlla se AWS Backup è definito un file system per il filesystem distribuito. Inoltre, verifica anche se l'`cross-Region backup`opzione è abilitata se la polizza richiede una copertura in caso di interruzioni. Region-level 

### Replica dei dati
<a name="data-replication-fsx"></a>

AWS Resilience Hub verifica se per il file system distribuito è definita un'attività di replica AWS DataSync dei dati pianificata a livello regionale o interregionale.

AWS DataSync un'attività di replica dei dati pianificata può migliorare l'RTO stimato del carico di lavoro e l'RPO stimato del carico di lavoro a livello di infrastruttura, AZ e regione. Inoltre, potrebbe essere combinato con un'operazione In-Region AWS Backup per il ripristino in caso di interruzione dell'applicazione.

## AWS Step Functions
<a name="resilience-checks-step-func"></a>

Questa sezione elenca tutti i controlli e i consigli specifici per. AWS Step Functions Per ulteriori informazioni in merito AWS Step Functions, consulta [AWS Step Functions la documentazione](https://docs.aws.amazon.com//step-functions/).

### Controllo delle versioni e alias
<a name="versioning-alias-step-func"></a>

AWS Resilience Hub verifica se il AWS Step Functions flusso di lavoro utilizza il controllo delle versioni e l'alias per migliorare i tempi di ridistribuzione.

### Cross-Region distribuzione
<a name="cross-region-deployment-step-func"></a>

AWS Resilience Hub verifica se il AWS Step Functions flusso di lavoro dello stesso tipo di flusso di lavoro è distribuito in una regione diversa per il ripristino in caso di interruzione regionale.

## Amazon ElastiCache (sistema operativo Redis)
<a name="resilience-checks-elstc-cache-srvrless"></a>

Questa sezione elenca tutti i controlli e i consigli specifici di Amazon ElastiCache (Redis OSS).

Per ulteriori informazioni su Amazon ElastiCache (Redis OSS), consulta la [ ElastiCache documentazione di Amazon](https://docs.aws.amazon.com//elasticache/).

### Single-AZ distribuzione
<a name="single-az-elstc-cache-srvrless"></a>

AWS Resilience Hub verifica se il cluster Amazon ElastiCache (Redis OSS) è distribuito come nodo singolo o con tutti i suoi nodi in un'unica zona di disponibilità.

### Single-AZ implementazione
<a name="multi-az-elstc-cache-srvrless"></a>

AWS Resilience Hub verifica se il cluster Amazon ElastiCache (Redis OSS) è distribuito come gruppo di replica (sia per i cluster abilitati alla modalità cluster che per quelli con modalità cluster disabilitata) su più zone di disponibilità per consentire il failover in caso di interruzione della zona di disponibilità.

### Cross-Region failover
<a name="cross-region-flover-elstc-cache-srvrless"></a>

AWS Resilience Hub verifica gli obiettivi RTO e RPO definiti nella politica di resilienza per riprendersi da un'interruzione regionale. Inoltre, è in AWS Resilience Hub grado di identificare i cluster di datastore globali di Amazon ElastiCache (Redis OSS) distribuiti in più regioni.

### Backup
<a name="backup-elstc-cache-srvrless"></a>

AWS Resilience Hub verifica se le seguenti funzionalità di backup sono applicate su un Amazon ElastiCache (Redis OSS) distribuito o su un cluster progettato autonomamente:
+ Backup automatico
+ Backup manuale per sistemi di backup di terze parti

AWS Resilience Hub non consiglierà il backup come metodo di ripristino se non si utilizza il backup. Tuttavia, è possibile ripristinare il livello di cache in caso di incoerenza dei dati e ricreare i dati dallo storage principale. 

### Failover più rapido a livello regionale
<a name="faster-in-region-flover-elstc-cache-srvrless"></a>

AWS Resilience Hub verifica gli obiettivi RTO e RPO definiti nella politica di resilienza durante le interruzioni dell'infrastruttura o della zona di disponibilità. Inoltre, è in AWS Resilience Hub grado di identificare le seguenti architetture regionali per il ripristino in caso di interruzioni dell'infrastruttura e della zona di disponibilità: 
+ Istanza del nodo di standby secondario in una zona di disponibilità diversa per il tipo di cluster Amazon ElastiCache (Redis OSS) disattivato in modalità cluster.
+ Istanza del nodo di standby secondario in una zona di disponibilità diversa per ogni shard per il tipo di cluster Amazon ElastiCache (Redis OSS) abilitato alla modalità cluster. 