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à.
# infrastruttura AWS
Questa sezione presenta un riepilogo dell'infrastruttura AWS globale e dei limiti di isolamento dei guasti che fornisce. Inoltre, questa sezione fornirà una panoramica del concetto di piani di controllo e piani dati, che sono distinzioni fondamentali nella AWS progettazione dei servizi. Queste informazioni forniscono la base per comprendere in che modo i limiti di isolamento dei guasti, il piano di controllo e il piano dati di un servizio si applicano ai tipi di AWS servizio descritti nella sezione successiva.
**Topics**
+ [Zone di disponibilità](availability-zones.md)
+ [Regioni](regions.md)
+ [AWSLocal Zones](aws-local-zones.md)
+ [AWS Outposts](aws-outposts.md)
+ [Punti di presenza](points-of-presence.md)
+ [Partizioni](partitions.md)
+ [Piani di controllo e piani dati](control-planes-and-data-planes.md)
+ [Stabilità statica](static-stability.md)
+ [Riepilogo](summary.md)
# Zone di disponibilità
AWSgestisce oltre 100 zone di disponibilità in diverse regioni del mondo (i numeri attuali sono disponibili qui: [AWSGlobal Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/)). Una zona di disponibilità è uno o più data center discreti con infrastruttura di alimentazione, rete e connettività indipendenti e ridondanti in un unico. Regione AWS Le zone di disponibilità in una regione sono significativamente distanti l'una dall'altra, fino a 60 miglia (\$1100 km) per prevenire guasti correlati, ma abbastanza vicine da utilizzare la replica sincrona con una latenza di un millisecondo. Sono progettate per non essere influenzate simultaneamente da uno scenario di destino condiviso, come l'alimentazione elettrica, l'interruzione delle risorse idriche, l'isolamento delle fibre, i terremoti, gli incendi, i tornado o le inondazioni. I punti di guasto più comuni, come i generatori e le apparecchiature di raffreddamento, non sono condivisi tra le zone di disponibilità e sono progettati per essere alimentati da sottostazioni elettriche indipendenti. Quando AWS distribuisce gli aggiornamenti ai propri servizi, le distribuzioni nelle zone di disponibilità della stessa regione vengono separate nel tempo per evitare guasti correlati.
Tutte le zone di disponibilità di una regione sono interconnesse con reti ad alta larghezza di banda e bassa latenza, tramite fibra metropolitana dedicata e completamente ridondante. *Ogni zona di disponibilità in una regione si connette a Internet attraverso due centri di transito in cui AWS si collegano più [provider Internet di primo](https://en.wikipedia.org/wiki/Tier_1_network) livello (per ulteriori informazioni, consulta [Overview of Amazon Web Services](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html?did=wp_card&trk=wp_card)).*
Queste funzionalità forniscono un forte isolamento delle zone di disponibilità l'una dall'altra, che chiamiamo Availability Zone Independence (AZI). Il costrutto logico delle zone di disponibilità e della loro connettività a Internet è illustrato nella figura seguente.
![\[Questa immagine mostra come le zone di disponibilità siano costituite da uno o più data center fisici collegati in modo ridondante tra loro e a Internet\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-fault-isolation-boundaries/images/availability-zones.png)
# Regioni
Ciascuna Regione AWS è composta da più zone di disponibilità indipendenti e fisicamente separate all'interno di un'area geografica. Tutte le regioni hanno attualmente tre o più zone di disponibilità. Le regioni stesse sono isolate e indipendenti dalle altre regioni con alcune eccezioni riportate più avanti in questo documento [(fare riferimento alle operazioni globali in una singola regione](global-services.md#global-single-region-operations)). Questa separazione tra le regioni limita gli errori del servizio, quando si verificano, a una singola regione. In questo caso le normali operazioni delle altre regioni non sono influenzate. Inoltre, le risorse e i dati creati in una regione non esistono in nessun'altra regione, a meno che non si utilizzi esplicitamente una funzionalità di replica o copia offerta da un AWS servizio o si replichi personalmente la risorsa.
![\[Questa immagine illustra le regioni AWS attuali e pianificate a dicembre 2022.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-fault-isolation-boundaries/images/current-and-planned-aws-regions.png)
# AWSLocal Zones
AWSLe [Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) sono un tipo di implementazione dell'infrastruttura che colloca servizi di elaborazione, storage, database e altri [AWSservizi selezionati](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/) vicino a grandi centri abitati e industriali. È possibile utilizzare AWS servizi, come i servizi di elaborazione e archiviazione, nella zona locale per eseguire applicazioni a bassa latenza all'edge o semplificare le migrazioni al cloud ibrido. Le Local Zones dispongono di ingressi e uscite Internet locali per ridurre la latenza, ma sono anche connesse alla regione madre tramite la rete privata ridondante e ad alta larghezza di banda di Amazon, che offre alle applicazioni in esecuzione nelle Local Zones AWS un accesso rapido, sicuro e senza interruzioni all'intera gamma di servizi.
# AWS Outposts
[AWS Outposts](https://aws.amazon.com/outposts/)è una famiglia di soluzioni completamente gestite che forniscono AWS infrastrutture e servizi praticamente a qualsiasi location locale o periferica per un'esperienza ibrida davvero coerente. Le soluzioni Outposts consentono di estendere ed eseguire AWS servizi nativi in locale e sono disponibili in una varietà di fattori di forma, dai server Outposts 1U e 2U ai rack Outposts 42U e implementazioni su più rack.
ConAWS Outposts, puoi eseguire [determinati AWS servizi localmente e connetterti a un'ampia gamma di servizi](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html#services) disponibili nella versione principale. Regione AWS AWS Outpostssono rack di elaborazione e archiviazione completamente gestiti e configurabili realizzati con hardware AWS progettato che consente ai clienti di eseguire elaborazione e archiviazione in locale, connettendosi senza problemi all'ampia gamma AWS di servizi nel cloud.
# Punti di presenza
Oltre alle zone di disponibilità, gestisce AWS anche una rete di punti di presenza (PoP) distribuita a livello globale. Regioni AWS Questi PoPs ospitano Amazon CloudFront, una rete di distribuzione dei contenuti (CDN); Amazon Route 53, un servizio di risoluzione DNS (Domain Name System) pubblico; e AWS Global Accelerator (AGA), un servizio di ottimizzazione della rete perimetrale. La rete edge globale è attualmente composta da oltre 410 PoPs, tra cui più di 400 edge location, e 13 cache regionali di livello medio in oltre 90 città in 48 paesi (lo stato attuale è disponibile qui: [Amazon CloudFront Key Features](https://aws.amazon.com/cloudfront/features/)).
![\[Questa immagine mostra la rete edge CloudFront globale di Amazon\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/aws-fault-isolation-boundaries/images/amazon-cloudfront.png)
Ogni PoP è isolato dagli altri, il che significa che un guasto che interessa un singolo PoP o un'area metropolitana non ha alcun impatto sul resto della rete globale. La AWS rete collabora con migliaia di operatori di telecomunicazioni Tier 1/2/3 a livello globale, è ben collegata a tutte le principali reti di accesso per prestazioni ottimali e dispone di centinaia di terabit di capacità implementata. Le edge location sono collegate alla Regioni AWS dorsale di AWS rete, una fibra parallela multipla da 100 GbE completamente ridondante che circola in tutto il mondo e si collega a decine di migliaia di reti per migliorare il recupero delle origini e l'accelerazione dinamica dei contenuti.
# Partizioni
AWS[raggruppa](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) le regioni in partizioni. Ogni regione si trova esattamente in una partizione e ogni partizione ha una o più regioni. Le partizioni hanno istanze indipendenti di AWS Identity and Access Management (IAM) e forniscono un confine rigido tra le regioni in partizioni diverse. AWSLe regioni commerciali sono nella `aws` partizione, le regioni in Cina sono nella partizione e AWS GovCloud le regioni sono nella `aws-cn` partizione. `aws-us-gov` Alcuni AWS servizi sono progettati per fornire funzionalità interregionali, come [Amazon S3 Cross-Region Replication o [AWSTransit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html) Inter-Region](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html#crr-scenario) Peering. Questi tipi di funzionalità sono supportati solo tra regioni della stessa partizione. Non è possibile utilizzare le credenziali IAM di una partizione per interagire con le risorse in una partizione diversa.
# Piani di controllo e piani dati
AWSsepara la maggior parte dei servizi nei concetti di piano di *controllo e piano* *dati*. Questi termini provengono dal mondo delle reti, in particolare dai router. Il piano dati del router, che è la sua funzionalità principale, sposta i pacchetti in base a regole. Ma le politiche di routing devono essere create e distribuite da qualche parte, ed è qui che entra in gioco il piano di controllo.
I piani di controllo forniscono le API amministrative utilizzate per creare, leggere/descrivere, aggiornare, eliminare ed elencare le risorse (CRUDL). Ad esempio, tutte le azioni del piano di controllo sono le seguenti: avvio di una nuova istanza [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2), creazione di un bucket [Amazon Simple Storage](https://aws.amazon.com/s3/) Service (Amazon S3) e descrizione di [una coda Amazon Simple Queue](https://aws.amazon.com/sqs/) Service (Amazon SQS). Quando avvii un'istanza EC2, il piano di controllo deve eseguire diverse attività come trovare un host fisico con capacità, allocare le interfacce di rete, preparare un volume Amazon [Elastic Block Store (Amazon](https://aws.amazon.com/ebs/) EBS), generare credenziali IAM, aggiungere le regole del Security Group e altro ancora. I piani di controllo tendono ad essere sistemi di orchestrazione e aggregazione complicati.
Il piano dati è ciò che fornisce la funzione principale del servizio. Ad esempio, le seguenti sono tutte le parti del piano dati per ciascuno dei servizi coinvolti: l'istanza EC2 in esecuzione stessa, che legge e scrive su un volume EBS, riceve e inserisce oggetti in un bucket S3 e Route 53 che risponde alle query DNS ed esegue controlli di integrità.
I piani dati sono intenzionalmente meno complicati, con meno parti mobili rispetto ai piani di controllo, che di solito implementano un sistema complesso di flussi di lavoro, logica aziendale e database. Ciò rende statisticamente meno probabile che si verifichino eventi di errore nel piano dati rispetto al piano di controllo. Sebbene sia il piano dati che quello di controllo contribuiscano al funzionamento e al successo complessivi del servizio, li AWS considera componenti distinti. Questa separazione offre vantaggi sia in termini di prestazioni che di disponibilità.
# Stabilità statica
Una delle caratteristiche di resilienza più importanti dei AWS servizi è la cosiddetta stabilità AWS statica. Ciò che significa questo termine è che i sistemi operano in uno stato statico e continuano a funzionare normalmente senza la necessità di apportare modifiche in caso di guasto o indisponibilità delle dipendenze. Un modo per farlo è prevenire le dipendenze circolari nei nostri servizi che potrebbero impedire il corretto ripristino di uno di tali servizi. Un altro modo per farlo è mantenere lo stato esistente. Riteniamo che i piani di controllo abbiano statisticamente maggiori probabilità di fallire rispetto ai piani dati. Sebbene il piano dati dipenda in genere dai dati che arrivano dal piano di controllo, il piano dati mantiene lo stato esistente e continua a funzionare anche in caso di compromissione del piano di controllo. L'accesso alle risorse dal piano dati, una volta effettuato il provisioning, non dipende dal piano di controllo e pertanto non è influenzato da alcuna compromissione del piano di controllo. In altre parole, anche se la capacità di creare, modificare o eliminare risorse è compromessa, le risorse esistenti rimangono disponibili. Ciò rende AWS i piani dati staticamente stabili rispetto a una compromissione del piano di controllo. È possibile implementare diversi modelli per essere staticamente stabili contro diversi tipi di errori di dipendenza.
Un esempio di stabilità statica è disponibile in Amazon EC2. Una volta lanciata, un'istanza EC2 è disponibile tanto quanto il server fisico in un data center. Non dipende da alcuna API del piano di controllo per rimanere in esecuzione o per riprendere a funzionare dopo un riavvio. La stessa proprietà vale per altre AWS risorse come VPC, bucket e oggetti Amazon S3 e volumi Amazon EBS.
La stabilità statica è un concetto profondamente radicato nella AWS progettazione dei suoi servizi, ma è anche un modello che può essere utilizzato dai clienti. In effetti, la maggior parte delle linee guida sulle migliori pratiche per utilizzare i diversi tipi di AWS servizi in modo resiliente consiste nell'implementare la stabilità statica per gli ambienti di produzione. I meccanismi di ripristino e mitigazione più affidabili sono quelli che richiedono il minor numero di modifiche per ottenere il ripristino. Invece di affidarsi al piano di controllo EC2 per lanciare nuove istanze EC2 da ripristinare in caso di guasto della zona di disponibilità, disporre di tale capacità aggiuntiva in anticipo aiuta a raggiungere la stabilità statica. Pertanto, l'eliminazione delle dipendenze dai piani di controllo (le API che implementano le modifiche alle risorse) nel percorso di ripristino aiuta a produrre carichi di lavoro più resilienti. Per ulteriori dettagli sulla stabilità statica, i piani di controllo e i piani dati, consulta l'articolo della Amazon Builders' Library sulla [stabilità statica con zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones).
# Riepilogo
AWSutilizza diversi contenitori di errore nella nostra infrastruttura per creare l'isolamento dei guasti. I contenitori di guasto dell'infrastruttura principale sono partizioni, regioni, zone di disponibilità, piani di controllo e piani dati. Successivamente, esamineremo diversi tipi di AWS servizi, come questi contenitori di guasti vengono utilizzati nella loro progettazione e come progettare i carichi di lavoro con essi per renderli resilienti.