

# Appendice: domande e best practice
<a name="appendix"></a>

Questa appendice riassume tutte le domande e le best practice nel Framework AWS Well-Architected.

**Topics**
+ [Eccellenza operativa](a-operational-excellence.md)
+ [Sicurezza](a-security.md)
+ [Affidabilità](a-reliability.md)
+ [Efficienza delle prestazioni](a-performance-efficiency.md)
+ [Ottimizzazione dei costi](a-cost-optimization.md)
+ [Sostenibilità](a-sustainability.md)

# Eccellenza operativa
<a name="a-operational-excellence"></a>

Il principio dell'eccellenza operativa include la capacità di supportare lo sviluppo ed eseguire carichi di lavoro in modo efficace, ottenere informazioni approfondite sulle operazioni e migliorare continuamente i processi e le procedure di supporto per offrire valore commerciale. È possibile trovare linee guida prescrittive sull'implementazione nel [Whitepaper sul principio dell'eccellenza operativa](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html). 

**Topics**
+ [Organizzazione](a-organization.md)
+ [Preparazione](a-prepare.md)
+ [Operatività](a-operate.md)
+ [Evoluzione](a-evolve.md)

# Organizzazione
<a name="a-organization"></a>

**Topics**
+ [OPS 1. In che modo stabilisci quali sono le tue priorità?](ops-01.md)
+ [OPS 2. Come strutturare la tua organizzazione per supportare i risultati aziendali?](ops-02.md)
+ [OPS 3. In che modo la cultura aziendale supporta i risultati aziendali?](ops-03.md)

# OPS 1. In che modo stabilisci quali sono le tue priorità?
<a name="ops-01"></a>

 È necessario che ognuno comprenda il proprio ruolo per rendere possibile il successo aziendale. Devi disporre di obiettivi comuni al fine di stabilire le priorità per le risorse. Ciò massimizzerà i risultati dei tuoi sforzi. 

**Topics**
+ [OPS01-BP01 Valutazione delle esigenze dei clienti esterni](ops_priorities_ext_cust_needs.md)
+ [OPS01-BP02 Valutazione delle esigenze dei clienti interni](ops_priorities_int_cust_needs.md)
+ [OPS01-BP03 Valutazione dei requisiti di governance](ops_priorities_governance_reqs.md)
+ [OPS01-BP04 Valutazione dei requisiti di conformità](ops_priorities_compliance_reqs.md)
+ [OPS01-BP05 Valutazione del panorama delle minacce](ops_priorities_eval_threat_landscape.md)
+ [OPS01-BP06 Valutazione dei compromessi](ops_priorities_eval_tradeoffs.md)
+ [OPS01-BP07 Gestione dei vantaggi e dei rischi](ops_priorities_manage_risk_benefit.md)

# OPS01-BP01 Valutazione delle esigenze dei clienti esterni
<a name="ops_priorities_ext_cust_needs"></a>

 Coinvolgi i principali stakeholder, compresi i team aziendali, di sviluppo e operativi, per determinare dove concentrare gli sforzi in base alle esigenze dei clienti esterni. Questo ti garantirà una conoscenza approfondita del supporto operativo necessario per raggiungere i risultati aziendali desiderati. 

 **Anti-pattern comuni:** 
+  Hai deciso di non fornire il servizio clienti al di fuori degli orari di attività principali, ma non hai esaminato i dati cronologici riguardanti le richieste di supporto. Non sai se questo determinerà un impatto sui tuoi clienti. 
+  Stai sviluppando una nuova funzionalità, ma non hai coinvolto i tuoi clienti per capire se è desiderata e, se sì, in quale forma; inoltre non hai condotto attività di sperimentazione per convalidarne la necessità e il metodo di distribuzione. 

 **Vantaggi dell'adozione di questa best practice:** I clienti le cui esigenze sono soddisfatte hanno maggiori probabilità di rimanere clienti. Valutando e comprendendo le esigenze dei clienti esterni sarà possibile organizzare le attività in base a priorità e offrire valore aggiunto. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Comprendi le esigenze aziendali: il successo dell'azienda è reso possibile dalla condivisione di obiettivi e dalla comprensione tra gli stakeholder, compresi i team aziendali, di sviluppo e operativi. 
  +  Esamina gli obiettivi aziendali, le esigenze e le priorità dei clienti esterni: coinvolgi i principali stakeholder, compresi i team aziendali, di sviluppo e operativi, per discutere obiettivi, esigenze e priorità dei clienti esterni. In tal modo otterrai una conoscenza approfondita del supporto operativo necessario per raggiungere i risultati aziendali e del cliente. 
  +  Stabilisci una comprensione condivisa: stabilisci una comprensione condivisa delle funzioni aziendali del carico di lavoro, dei ruoli di ciascuno dei team nel gestire il carico di lavoro e di come questi supportino i tuoi obiettivi aziendali condivisi tra clienti interni ed esterni. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Concetti del Pilastro del Framework AWS Well-Architected – Ciclo di feedback](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) 

# OPS01-BP02 Valutazione delle esigenze dei clienti interni
<a name="ops_priorities_int_cust_needs"></a>

 Coinvolgi i principali stakeholder, compresi i team aziendali, di sviluppo e operativi, nel determinare dove concentrare le attività in base alle esigenze dei clienti interni. Questo ti garantirà una conoscenza approfondita del supporto operativo necessario per raggiungere i risultati aziendali. 

 Utilizza le priorità così definite per concentrare le tue iniziative di miglioramento delle operazioni laddove avranno il maggiore impatto (ad esempio, sviluppare le competenze dei team, migliorare le prestazioni del carico di lavoro, ridurre i costi, automatizzare le istruzioni o potenziare il monitoraggio). Aggiorna le tue priorità al mutare delle esigenze. 

 **Anti-pattern comuni:** 
+  Per semplificare la gestione della rete hai deciso di modificare l'assegnazione degli indirizzi IP per i team di prodotto senza consultarli. Non conosci l'impatto che questo avrà sui tuoi team di prodotto. 
+  Stai implementando un nuovo strumento di sviluppo, ma non hai coinvolto i clienti interni per scoprire se è necessario o se è compatibile con le loro pratiche esistenti. 
+  Stai implementando un nuovo sistema di monitoraggio, ma non hai contattato i clienti interni per scoprire se hanno esigenze di monitoraggio o reporting da tenere in considerazione. 

 **Vantaggi dell'adozione di questa best practice:** Valutando e comprendendo le esigenze dei clienti interni sarà possibile organizzare le attività in base a priorità e offrire valore aggiunto. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Comprendi le esigenze aziendali: il successo dell'azienda è reso possibile dalla condivisione di obiettivi e dalla comprensione tra gli stakeholder, compresi i team aziendali, di sviluppo e operativi. 
  +  Esamina gli obiettivi aziendali, le esigenze e le priorità dei clienti interni: coinvolgi i principali stakeholder, compresi i team aziendali, di sviluppo e operativi, per discutere obiettivi, esigenze e priorità dei clienti interni. In tal modo otterrai una conoscenza approfondita del supporto operativo necessario per raggiungere i risultati aziendali e del cliente. 
  +  Stabilisci una comprensione condivisa: stabilisci una comprensione condivisa delle funzioni aziendali del carico di lavoro, dei ruoli di ciascuno dei team nel gestire il carico di lavoro e di come questi supportino gli obiettivi aziendali condivisi tra clienti interni ed esterni. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Concetti del Pilastro del Framework AWS Well-Architected – Ciclo di feedback](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) 

# OPS01-BP03 Valutazione dei requisiti di governance
<a name="ops_priorities_governance_reqs"></a>

 Con governance si intende l'insieme di policy, regole o framework che un'azienda usa per raggiungere i propri obiettivi. I requisiti di governance vengono generati all'intero dell'organizzazione. Possono influire sui tipi di tecnologia che scegli o sul modo in cui sviluppi il tuo carico di lavoro. Integra i requisiti di governance della tua organizzazione nel tuo carico di lavoro. La conformità è la capacità di dimostrare che hai implementato i requisiti di governance. 

 **Risultato desiderato:** 
+  I requisiti di governance sono integrati nel progetto architetturale e nell'operatività del tuo carico di lavoro. 
+  Puoi dimostrare di aver seguito i requisiti di governance. 
+  I requisiti di governance vengono rivisti e aggiornati con regolarità. 

 **Anti-pattern comuni:** 
+ La tua azienda richiede che l'account root abbia l'autenticazione multi-fattore. Non sei riuscito a implementare questo requisito e l'account root è compromesso.
+ Durante la progettazione del carico di lavoro hai scelto un tipo di istanza non approvata dal dipartimento IT. Non riesci ad avviare il tuo carico di lavoro e devi procedere a una nuova progettazione.
+ Devi avere un piano di ripristino di emergenza. Non ne hai uno e il tuo carico di lavoro è vittima di un'interruzione prolungata.
+  Il tuo team vuole usare nuove istanze, ma i requisiti di governance non sono stati aggiornati e pertanto non sono consentite. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Rispettare i requisiti di governance permette di allineare il carico di lavoro a policy organizzative di più ampio respiro. 
+  I requisiti di governance si basano su standard e best practice di settore per la tua organizzazione. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Identifica il requisito di governance collaborando con le parti interessate e le organizzazioni preposte. Includi i requisiti di governance nel tuo carico di lavoro. Dimostra di aver seguito i requisiti di governance.

 **Esempio del cliente** 

 In AnyCompany Retail, il team operativo nell'ambiente cloud collabora con le parti interessate dell'organizzazione per sviluppare i requisiti di governance. Ad esempio, proibiscono l'accesso SSH alle istanze Amazon EC2. Se i team hanno necessità di accedere ai sistemi, devono usare AWS Systems Manager Session Manager. Il team operativo nell'ambiente cloud aggiorna con regolarità i requisiti di governance nel momento in cui vengono rilasciati nuovi servizi. 

 **Passaggi dell'implementazione** 

1.  Identifica le parti interessate per il tuo carico di lavoro, inclusi eventuali team centralizzati. 

1.  Collabora con le parti interessate per identificare i requisiti di governance. 

1.  Dopo aver generato un elenco, dai la priorità alle voci relative a migliorie e inizia a implementarle nel tuo carico di lavoro. 

   1.  Usa servizi come [AWS Config](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/) per creare governance-as-code e verificare che tali requisiti di governance siano rispettati. 

   1.  Se usi [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), puoi avvalerti di Policy di controllo dei servizi per implementare requisiti di governance. 

1.  Fornisci la documentazione che convalida l'implementazione. 

 **Livello di impegno per il piano di implementazione:** Medio. L'implementazione di requisiti di governance mancanti può causare la rielaborazione del tuo carico di lavoro. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS01-BP04 Valutazione dei requisiti di conformità](ops_priorities_compliance_reqs.md) - La conformità è come la governance, ma è esterna all'organizzazione. 

 **Documenti correlati:** 
+ [ Guida AWS sull'ambiente cloud di governance e gestione ](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/management-and-governance-cloud-environment-guide.html)
+ [ Best practice per le policy di controllo dei servizi di AWS Organizations in un ambiente multi-account ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ Governance nel Cloud AWS: il giusto equilibrio tra agilità e sicurezza ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
+ [ Cosa si intende per Governance, Rischio e Conformità (GRC)? ](https://aws.amazon.com/what-is/grc/)

 **Video correlati:** 
+ [ Gestione e governance AWS: configurazione, conformità e revisione - AWS Online Tech Talks ](https://www.youtube.com/watch?v=79ud1ZAaoj0)
+ [AWS re:Inforce 2019: Governance per l'età del cloud (DEM12-R1) ](https://www.youtube.com/watch?v=y3WmHnavuN8)
+ [AWS re:Invent 2020: Ottieni compliance as code con AWS Config](https://www.youtube.com/watch?v=m8vTwvbzOfw)
+ [AWS re:Invent 2020: Governance agile su AWS GovCloud (US)](https://www.youtube.com/watch?v=hv6B17eriHQ)

 **Esempi correlati:** 
+ [ Esempi di pacchetti di conformità AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/conformancepack-sample-templates.html)

 **Servizi correlati:** 
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Organizations - Policy di controllo dei servizi ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)

# OPS01-BP04 Valutazione dei requisiti di conformità
<a name="ops_priorities_compliance_reqs"></a>

I requisiti di conformità interna, di settore e normativa sono un fattore importante per la definizione delle priorità della tua organizzazione. L'assetto di conformità della tua azienda potrebbe impedirti di usare tecnologie specifiche o posizioni geografiche. Applica la due diligence in assenza di contesti di conformità esterni. Genera revisioni o report per convalidare la conformità.

 Se comunichi all'esterno che il tuo prodotto è in linea con standard specifici di conformità, devi avere un processo interno in grado di garantire costantemente che tale affermazione sia vera. Gli esempi di standard di conformità includono PCI DSS, FedRAMP e HIPAA. Gli standard di conformità applicabili vengono stabiliti in base a diversi fattori, come il tipo di dati che la soluzione archivia o trasmette e quali aree geografiche sono supportate dalla soluzione. 

 **Risultato desiderato:** 
+  Requisiti di conformità interni, di settore e normativi sono parte integrante della selezione dell'architettura. 
+  Puoi verificare la conformità e generare report di audit. 

 **Anti-pattern comuni:** 
+ Parti del tuo carico di lavoro rientrano nel framework Payment Card Industry Data Security Standard (PCI-DSS), ma il tuo carico di lavoro archivia dati di carte di credito non crittografati.
+ Gli architetti e gli sviluppatori software non conoscono il contesto di conformità che la tua organizzazione è tenuta a rispettare.
+  L'audit annuale Systems and Organizations Control (SOC2) Type II avrà luogo a breve e tu non sei in grado di verificare la presenza dei controlli richiesti. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Valutando e comprendendo i requisiti di conformità che si applicano al carico di lavoro sarà possibile organizzare le attività in base a priorità e offrire valore aggiunto. 
+  Scegli le sedi e le tecnologie corrette, in linea con il tuo contesto di integrità. 
+  La progettazione del tuo carico di lavoro ai fini dell'auditing ti consente di dimostrare la tua aderenza al modello di conformità. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Implementare questa best practice significa integrare requisiti di conformità nel processo di progettazione dell'architettura. I membri del tuo team sono a conoscenza del contesto di conformità richiesto. Convalidi la conformità in linea con il contesto. 

 **Esempio del cliente** 

 AnyCompany Retail archivia informazioni sulle carte di credito per i clienti. Gli sviluppatori del team di archiviazione delle carte sono al corrente della necessità di rispettare la conformità agli standard PCI-DSS. Hanno adottato misure per verificare che le informazioni sulle carte di credito siano archiviate e consultabili in totale sicurezza, in linea con quanto stabilito dagli standard PCI-DSS: Ogni anno collaborano con il team di sicurezza per confermare la conformità. 

 **Passaggi dell'implementazione** 

1.  Collabora con i team di sicurezza e governance per stabilire quali conformità interne, normative o di settore deve rispettare il tuo carico di lavoro. Integra gli standard di conformità nel tuo carico di lavoro. 

   1.  Convalida continuamente la conformità delle risorse AWS con servizi come [AWS Compute Optimizer](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) e [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html). 

1.  Comunica ai membri del tuo team i requisiti di conformità, in modo che possano gestire e far evolvere il carico di lavoro in linea con tali requisiti. I requisiti di conformità devono essere inclusi nelle scelte tecnologiche e architetturali. 

1.  A seconda del contesto di conformità, potresti dover generare un report di audit o conformità. Collabora con la tua organizzazione per automatizzare il più possibile questo processo. 

   1.  Usa servizi come [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) per convalidare la conformità e generare report di audit. 

   1.  Puoi scaricare documenti su conformità e sicurezza AWS con [AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html). 

 **Livello di impegno per il piano di implementazione:** Medio. Implementare i requisiti di conformità può essere complesso. Generare report di audit o documenti di conformità aggiunge altre complessità. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC01-BP03 Identificazione e convalida degli obiettivi di controllo](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) - Gli obiettivi di controllo della sicurezza sono una parte importante della conformità nel suo complesso. 
+  [SEC01-BP06 Automatizzazione dei test e della convalida dei controlli di sicurezza nelle pipeline](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_test_validate_pipeline.html) - Come parte delle tue pipeline, convalida i controlli di sicurezza. Puoi anche generare la documentazione di conformità per le nuove modifiche. 
+  [SEC07-BP02 Definizione dei controlli di protezione dei dati](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_define_protection.html) - Molti standard di conformità si basano su policy di gestione e di archiviazione dei dati. 
+  [SEC10-BP03 Preparazione di funzionalità forensi](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_prepare_forensic.html) - Le funzionalità forensi possono a volte essere usate nella conformità di auditing. 

 **Documenti correlati:** 
+ [AWS Compliance Center ](https://aws.amazon.com/financial-services/security-compliance/compliance-center/)
+ [ Risorse di conformità AWS](https://aws.amazon.com/compliance/resources/)
+ Whitepaper [Risk and Compliance AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html):
+ [ Modello di responsabilità condivisa AWS](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [ Servizi AWS inerenti secondo i programmi di conformità ](https://aws.amazon.com/compliance/services-in-scope/)

 **Video correlati:** 
+ [AWS re:Invent 2020: Ottieni compliance as code con AWS Compute Optimizer](https://www.youtube.com/watch?v=m8vTwvbzOfw)
+ [AWS re:Invent 2021 - Conformità, garanzia e auditing del cloud](https://www.youtube.com/watch?v=pdrYGVgb08Y)
+ [AWS Summit ATL 2022 - Implementare conformità, garanzia e auditing su AWS (COP202) ](https://www.youtube.com/watch?v=i7XrWimhqew)

 **Esempi correlati:** 
+ [ PCI DSS e best practice per la sicurezza di base di AWS su AWS](https://aws.amazon.com/solutions/partners/compliance-pci-fsbp-remediation/)

 **Servizi correlati:** 
+ [AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html)
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html)
+ [AWS Compute Optimizer](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)

# OPS01-BP05 Valutazione del panorama delle minacce
<a name="ops_priorities_eval_threat_landscape"></a>

 Valuta le minacce per l'azienda (ad esempio, concorrenza, rischi e responsabilità aziendali, rischi operativi e minacce per la sicurezza delle informazioni) e conserva le informazioni aggiornate in un registro dei rischi. Quando stabilisci dove concentrare gli sforzi, tieni in considerazione l'impatto dei rischi. 

 Il [Canone di architettura AWS](https://aws.amazon.com/architecture/well-architected/) enfatizza l'apprendimento, la misurazione e il miglioramento. Fornisce una strategia coerente per la valutazione delle architetture e l'implementazione di progetti in grado di ridimensionarsi nel corso del tempo. AWS mette a disposizione [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/) per aiutarti a rivedere il tuo approccio prima dello sviluppo e lo stato dei tuoi carichi di lavoro prima e durante la fase di produzione. Puoi confrontare il tuo approccio con le best practice architetturali AWS più recenti, monitorare lo stato complessivo dei carichi di lavoro e ottenere informazioni sui potenziali rischi. 

 I clienti AWS possono usufruire della revisione Well-Architected dei carichi di lavoro mission-critical per [valutare le loro architetture](https://aws.amazon.com/premiumsupport/programs/) rispetto alle best practice di AWS. I clienti con supporto Enterprise hanno diritto alla [revisione delle operazioni](https://aws.amazon.com/premiumsupport/programs/), ideata per agevolare l'identificazione delle eventuali lacune nel loro approccio al cloud. 

 Il coinvolgimento trasversale dei team per tali controlli aiuta a comprendere a livello comune i carichi di lavoro e come i ruoli del team contribuiscano al successo. Le esigenze identificate nel corso dell'analisi possono aiutarti a definire le tue priorità. 

 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) è uno strumento che fornisce l'accesso a una serie di controlli di base che propongono ottimizzazioni utili per la definizione delle tue priorità. [I clienti del supporto Business ed Enterprise](https://aws.amazon.com/premiumsupport/plans/) hanno accesso a ulteriori controlli a livello di sicurezza, affidabilità, prestazioni e ottimizzazione dei costi che possono essere utili per definire le loro priorità. 

 **Anti-pattern comuni:** 
+  Stai utilizzando una versione precedente di una libreria software nel tuo prodotto. Non sei a conoscenza di aggiornamenti di sicurezza alla libreria per problemi che potrebbero avere un impatto imprevisto sul carico di lavoro. 
+  Il tuo concorrente ha appena rilasciato una versione del proprio prodotto che risolve i reclami di molti dei tuoi clienti relativi al tuo prodotto. Non hai dato priorità alla risoluzione di questi problemi noti. 
+  Le autorità di regolamentazione hanno perseguito aziende come la tua che non sono conformi ai requisiti di conformità alla normativa legale. Non hai dato priorità ai requisiti di conformità in sospeso. 

 **Vantaggi dell'adozione di questa best practice:** Identificando e comprendendo le minacce alla tua organizzazione e al tuo carico di lavoro potrai determinare quali minacce affrontare, la loro priorità e le risorse necessarie per farlo. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Valuta il panorama delle minacce: valute le minacce per l'azienda (ad esempio, concorrenza, rischi e responsabilità aziendali, rischi operativi e minacce alla sicurezza delle informazioni), in modo da poterne includere l'impatto nel determinare dove concentrare le attività. 
  +  [Ultimi bollettini di sicurezza AWS](https://aws.amazon.com/security/security-bulletins/) 
  +  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
  +  Mantieni un modello delle minacce: definisci e mantieni un modello delle minacce che identifichi le potenziali minacce, le mitigazioni pianificate e predisposte e la loro priorità. Esamina la probabilità che le minacce si manifestino come incidenti, il costo del recupero da tali incidenti, il danno previsto causato e il costo per prevenire tali incidenti. Modifica le priorità man mano che i contenuti del modello di minaccia cambiano. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Conformità di Cloud AWS](https://aws.amazon.com/compliance/) 
+  [Ultimi bollettini di sicurezza AWS](https://aws.amazon.com/security/security-bulletins/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 

# OPS01-BP06 Valutazione dei compromessi
<a name="ops_priorities_eval_tradeoffs"></a>

 Valuta l'impatto dei compromessi tra interessi concorrenti o approcci alternativi, per aiutare a prendere decisioni informate quando si stabilisce dove concentrare le attività o scegliere una linea di azione. Ad esempio, accelerare l'introduzione sul mercato di nuove funzionalità può essere preferibile all'ottimizzazione dei costi. Oppure, è possibile scegliere un database relazionale per i dati non relazionali per semplificare la migrazione di un sistema, anziché migrare a un database ottimizzato per il tuo tipo di dati e aggiornare l'applicazione. 

 AWS può aiutarti a istruire i tuoi team su AWS e i suoi servizi, affinché comprendano meglio in che modo le loro scelte possono influire sul carico di lavoro. Per istruire i tuoi team, è consigliabile utilizzare le risorse fornite da [Supporto AWS](https://aws.amazon.com/premiumsupport/programs/) ([Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/), [forum di discussione di AWS](https://forums.aws.amazon.com/index.jspa)e [Supporto AWS Center](https://console.aws.amazon.com/support/home/)) e la [Documentazione di AWS](https://docs.aws.amazon.com/) . Se hai domande riguardanti AWS, contatta Supporto AWS tramite Supporto AWS Center. 

 AWS condivide inoltre le best practice e i modelli appresi attraverso la gestione di AWS nella [Amazon Builders' Library](https://aws.amazon.com/builders-library/). Un'ampia gamma di altre informazioni utili è disponibile tramite il [Blog AWS](https://aws.amazon.com/blogs/) e [il podcast ufficiale di AWS](https://aws.amazon.com/podcasts/aws-podcast/). 

 **Anti-pattern comuni:** 
+  Stai utilizzando un database relazionale per gestire serie temporali e dati non relazionali. Esistono opzioni di database ottimizzate per supportare i tipi di dati che stai utilizzando, ma non ne conosci i vantaggi perché non hai valutato i compromessi tra le soluzioni. 
+  I tuoi investitori richiedono di dimostrare la conformità agli standard PCI DSS (Payment Card Industry Data Security Standard). Non prendi in considerazione i compromessi tra soddisfare la loro richiesta e continuare con le attività di sviluppo già in corso. Al contrario, prosegui con il lavoro di sviluppo senza dimostrare la conformità. I tuoi investitori interrompono il supporto della tua azienda per i dubbi relativi alla sicurezza della tua piattaforma e ai loro investimenti. 

 **Vantaggi dell'adozione di questa best practice:** Comprendere le implicazioni e le conseguenze delle tue scelte ti consente di dare priorità alle tue opzioni. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Valuta i compromessi: valuta l'impatto dei compromessi tra interessi concorrenti, per aiutare a prendere decisioni informate nel determinare dove concentrare le attività. Ad esempio, è possibile accelerare la velocità di introduzione sul mercato di nuove funzionalità rispetto all'ottimizzazione dei costi. 
+  AWS può aiutarti a istruire i tuoi team su AWS e i suoi servizi, affinché comprendano meglio in che modo le loro scelte possono influire sul carico di lavoro. Per istruire i tuoi team, è consigliabile utilizzare le risorse fornite da Supporto AWS (AWS Knowledge Center, AWS Discussion Forms e Supporto AWS Center) e la documentazione AWS. Se hai domande riguardanti AWS, contatta Supporto AWS tramite Supporto AWS Center. 
+  AWS condivide inoltre le best practice e i modelli appresi attraverso la gestione di AWS nella Amazon Builders' Library. Un'ampia gamma di altre informazioni utili è disponibile tramite il blog AWS e il podcast ufficiale di AWS. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Blog AWS](https://aws.amazon.com/blogs/) 
+  [Conformità di Cloud AWS](https://aws.amazon.com/compliance/) 
+  [forum di discussione di AWS](https://forums.aws.amazon.com/index.jspa) 
+  [Documentazione di AWS](https://docs.aws.amazon.com/) 
+  [Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [Supporto AWS](https://aws.amazon.com/premiumsupport/) 
+  [Supporto AWS Center](https://console.aws.amazon.com/support/home/) 
+  [Amazon Builders' Library](https://aws.amazon.com/builders-library/) 
+  [il podcast ufficiale di AWS](https://aws.amazon.com/podcasts/aws-podcast/) 

# OPS01-BP07 Gestione dei vantaggi e dei rischi
<a name="ops_priorities_manage_risk_benefit"></a>

 Gestisci i vantaggi e i rischi per prendere decisioni informate nel determinare dove concentrare gli sforzi. Ad esempio, può essere vantaggioso distribuire un sistema con problemi irrisolti, in modo da mettere a disposizione dei clienti nuove funzionalità importanti. Può essere possibile ridurre i rischi associati o la presenza di un rischio potrebbe diventare inaccettabile, nel qual caso si intraprenderà un'azione per risolverlo. 

 Ad esempio, a un certo punto potresti realizzare che desideri dare maggiore risalto a un piccolo sottoinsieme delle tue priorità. Utilizza un approccio equilibrato nel lungo termine per garantire lo sviluppo delle capacità necessarie e la gestione del rischio. Aggiorna le tue priorità al mutare delle esigenze 

 **Anti-pattern comuni:** 
+  Hai deciso di includere una libreria che fa "tutto quello che ti serve" che uno dei tuoi sviluppatori "ha trovato su Internet". Non hai valutato i rischi di adottare questa libreria da un'origine sconosciuta e non sai se contiene vulnerabilità o codice dannoso. 
+  Hai deciso di sviluppare e distribuire una nuova funzionalità anziché risolvere un problema esistente. Non hai valutato i rischi posti dal fatto che il problema persiste finché la funzionalità non viene distribuita e non sai quale impatto avrà sui tuoi clienti. 
+  Hai deciso di non distribuire una funzionalità richiesta frequentemente dai clienti a causa di dubbi non specificati dal team di conformità. 

 **Vantaggi dell'adozione di questa best practice:** Identificare i vantaggi offerti dalle tue scelte e conoscere i rischi per la tua organizzazione ti consente di prendere decisioni informate. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Gestione dei vantaggi e dei rischi: bilancia i vantaggi delle decisioni rispetto ai rischi connessi. 
  +  Identificazione dei vantaggi: identifica i vantaggi in base agli obiettivi aziendali, alle esigenze e alle priorità. Gli esempi includono il time-to-market, la sicurezza, l'affidabilità, le prestazioni e il costo. 
  +  Identificazione dei rischi: identifica i rischi in base agli obiettivi aziendali, alle esigenze e alle priorità. Gli esempi includono il time-to-market, la sicurezza, l'affidabilità, le prestazioni e il costo. 
  +  Valutazione dei vantaggi rispetto ai rischi e decisioni informate: determina l'impatto dei vantaggi e dei rischi in base agli obiettivi, alle esigenze e alle priorità dei tuoi principali stakeholder, inclusi business, sviluppo e operazioni. Valuta il valore del vantaggio rispetto alla probabilità di realizzazione del rischio e al costo del suo impatto. Ad esempio, enfatizzare la velocità di accesso al mercato rispetto all'affidabilità potrebbe offrire un vantaggio competitivo. Tuttavia, potrebbe causare tempi di attività ridotti in presenza di problemi di affidabilità. 

# OPS 2. Come strutturare la tua organizzazione per supportare i risultati aziendali?
<a name="ops-02"></a>

 I tuoi team devono comprendere quale contributo offrono nel raggiungimento dei risultati aziendali. I team devono avere obiettivi condivisi e comprendere il proprio ruolo nel successo degli altri team. Comprendere la responsabilità, la proprietà, il modo in cui vengono prese le decisioni e chi ha l'autorità decisionale aiuterà a concentrare gli sforzi e a ottimizzare i contributi dei team. 

**Topics**
+ [OPS02-BP01 Associazione di proprietari identificati alle risorse](ops_ops_model_def_resource_owners.md)
+ [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md)
+ [OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni](ops_ops_model_def_activity_owners.md)
+ [OPS02-BP04 Conoscenza della propria responsabilità da parte dei membri del team](ops_ops_model_know_my_job.md)
+ [OPS02-BP05 Definizione di meccanismi per identificare responsabilità e proprietà](ops_ops_model_find_owner.md)
+ [OPS02-BP06 Definizione di meccanismi per richiedere aggiunte, modifiche ed eccezioni](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP07 Predefinizione o negoziazione delle responsabilità tra i team](ops_ops_model_def_neg_team_agreements.md)

# OPS02-BP01 Associazione di proprietari identificati alle risorse
<a name="ops_ops_model_def_resource_owners"></a>

Le risorse per il tuo carico di lavoro devono disporre di proprietari identificati per il controllo delle modifiche, la risoluzione dei problemi e altre funzioni. I titolari sono assegnati a carichi di lavoro, account, infrastrutture, piattaforme e applicazioni. La proprietà viene registrata tramite strumenti come un registro centrale o metadati collegati alle risorse. Il valore aziendale dei componenti è alla base dei processi e delle procedure applicate.

 **Risultato desiderato:** 
+  Le risorse hanno identificato i titolari tramite i metadati o un registro centrale. 
+  I membri del team possono identificare chi è il titolare delle risorse. 
+  Gli account hanno un solo proprietario, laddove possibile. 

 **Anti-pattern comuni:** 
+  I contatti alternativi per il tuo Account AWS non sono inseriti. 
+  Le risorse non hanno tag che identificano i team che le possiedono. 
+  Hai una coda ITSM senza una mappatura delle e-mail. 
+  Due team hanno entrambi la proprietà di una parte critica dell'infrastruttura. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Il controllo delle modifiche per le risorse è immediato con la proprietà assegnata. 
+  Puoi coinvolgere i proprietari corretti quando risolvi i problemi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Definisci qual è il significato della proprietà per i casi d'uso delle risorse nel tuo ambiente. Proprietà significa supervisionare le modifiche alla risorsa, supportare la risorsa durante la risoluzione dei problemi o essere finanziariamente affidabile. Specifica e registra i proprietari delle risorse, con nome, informazioni di contatto, organizzazione e team. 

 **Esempio del cliente** 

 AnyCompany Retail definisce il proprietario come il team o l'individuo responsabile delle modifiche e del supporto per le risorse. Si avvale di AWS Organizations per gestire gli Account AWS. Contatti alternativi degli account vengono configurati con caselle di posta di gruppo. Ogni coda ITSM è mappata su un alias e-mail. I tag identificano il proprietario delle risorse AWS. Per altre piattaforme e infrastrutture hanno una pagina wiki che identifica la proprietà e le informazioni di contatto. 

 **Passaggi dell'implementazione** 

1.  Inizia definendo la proprietà della tua organizzazione. La proprietà può significare essere proprietari del rischio collegato alla risorsa, essere proprietari delle modifiche alla risorsa o supportare la risorsa durante la risoluzione dei problemi. Proprietà può anche significare proprietà amministrativa o finanziaria della risorsa. 

1.  Usa [AWS Organizations](https://aws.amazon.com/organizations/) per gestire gli account. Puoi gestire centralmente i contatti alternativi per i tuoi account. 

   1.  Se usi indirizzi e-mail e numeri di telefono di proprietà dell'azienda come informazioni di contatto puoi accedervi anche se le persone a cui appartengono non sono più parte della tua organizzazione. Ad esempio, crea elenchi di distribuzione delle e-mail separati per fatturazione, operazioni e sicurezza e configurali come contatti per Fatturazione, Sicurezza e Operazioni in ogni Account AWS attivo. Molteplici persone riceveranno notifiche AWS e potranno rispondere, anche se qualcuno è in vacanza, ha cambiato ruolo o ha lasciato l'azienda. 

   1.  Se un account non è gestito da [AWS Organizations](https://aws.amazon.com/organizations/), i contatti alternativi degli account aiutano AWS a entrare in contatto con il personale richiesto, se necessario. Configura i contatti alternativi dell'account per indirizzare le persone a un gruppo invece che a un individuo. 

1.  Usa i tag per identificare i proprietari delle risorse AWS. Puoi specificare sia i proprietari sia le loro informazioni di contatto in tag separati. 

   1.  Puoi usare le regole [AWS Config](https://aws.amazon.com/config/) per avere la certezza che le risorse abbiano i tag di proprietà richiesti. 

   1.  Per linee guida dettagliate su come creare una strategia per l'applicazione di tag per la tua organizzazione, consulta [Whitepaper sulle best practice per l'applicazione di tag AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). 

1.  Per altre risorse, piattaforme e infrastrutture, crea la documentazione che identifica la proprietà. Tutti i membri del team devono poter accedere a queste informazioni. 

 **Livello di impegno per il piano di implementazione:** Basso. Sfrutta le informazioni di contatto e i tag degli account per assegnare la proprietà delle risorse AWS. Per altre risorse puoi usare qualcosa di semplice come una tabella in un wiki per registrare le informazioni su proprietà e contatti o usare uno strumento ITSM per mappare la proprietà. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md) - I processi e le procedure a supporto delle risorse dipendono dalla proprietà delle risorse stesse. 
+  [OPS02-BP04 Conoscenza della propria responsabilità da parte dei membri del team](ops_ops_model_know_my_job.md) - I membri del team devono sapere di quali risorse sono proprietari. 
+  [OPS02-BP05 Definizione di meccanismi per identificare responsabilità e proprietà](ops_ops_model_find_owner.md) - La proprietà deve essere identificata tramite meccanismi come tag o contatti di account.. 

 **Documenti correlati:** 
+ [ Gestione degli account AWS - Aggiornare le informazioni di contatto ](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html#manage-acct-update-contact-alternate-edit.html)
+ [ Regole AWS Config - Tag richiesti ](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)
+ [AWS Organizations - Aggiornare contatti alternativi nella tua organizzazione ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_contacts.html)
+  [Whitepaper Best practice per l'applicazione di tag AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) 

 **Esempi correlati:** 
+ [ Regole AWS Config - Amazon EC2 con tag richiesti e valori validi ](https://github.com/awslabs/aws-config-rules/blob/master/python/ec2_require_tags_with_valid_values.py)

 **Servizi correlati:** 
+  [AWS Config](https://aws.amazon.com/config/) 
+  [AWS Organizations](https://aws.amazon.com/organizations/) 

# OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure
<a name="ops_ops_model_def_proc_owners"></a>

 È utile comprendere chi ha la proprietà della definizione di singoli processi e procedure, perché tali processi e procedure specifici vengono utilizzati e perché tale proprietà esiste. Comprendere i motivi per cui vengono utilizzati processi e procedure specifici consente di identificare le opportunità di miglioramento. 

 **Vantaggi dell'adozione di questa best practice:** Capire a chi spetta la proprietà permette di identificare chi può approvare e/o implementare i miglioramenti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Assegnazione di proprietari identificati a processi e procedure: acquisisci i processi e le procedure utilizzati nel tuo ambiente e il singolo o il team responsabile della loro definizione. 
  +  Identificazione di processi e procedure: identifica le attività operative eseguite a supporto dei carichi di lavoro. Documenta queste attività in un percorso individuabile. 
  +  Definizione del proprietario della determinazione di un processo o di una procedura: identifica in modo univoco la persona o il team responsabile della specifica di un'attività. Questo soggetto deve assicurare che essa possa essere eseguita correttamente dal componente di un team adeguatamente qualificato, che disponga di autorizzazioni, accesso e strumenti adeguati. In caso di problemi nello svolgimento di tale attività, i membri del team che la eseguono sono responsabili di fornire il feedback dettagliato necessario per migliorarla. 
  +  Inclusione della proprietà nei metadati dell'artefatto dell'attività: le procedure automatizzate di servizi quali AWS Systems Manager, tramite documenti, e AWS Lambda, come funzioni, supportano l'acquisizione di informazioni sui metadati sotto forma di tag. Acquisisci la proprietà delle risorse utilizzando tag o gruppi di risorse, specificando proprietà e informazioni di contatto. Utilizza AWS Organizations per creare policy di tagging e garantire che vengano acquisite proprietà e informazioni di contatto. 

# OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni
<a name="ops_ops_model_def_activity_owners"></a>

 È utile comprendere chi ha la responsabilità di eseguire attività specifiche su carichi di lavoro definiti e perché tale responsabilità esiste. Comprendere chi ha la responsabilità di eseguire le attività fornisce indicazioni su eseguirà l'attività, su chi convaliderà il risultato e su chi fornirà feedback al proprietario dell'attività. 

 **Vantaggi dell'adozione di questa best practice:** Comprendere chi è responsabile di eseguire un'attività fornisce indicazioni su chi notificare quando è necessaria un'azione, su chi la eseguirà, su chi convaliderà il risultato e su chi fornirà un feedback al proprietario dell'attività. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni: acquisisci la responsabilità dell'esecuzione dei processi e delle procedure utilizzati nel tuo ambiente 
  +  Identificazione di processi e procedure: identifica le attività operative eseguite a supporto dei carichi di lavoro. Documenta queste attività in un percorso individuabile. 
  +  Definizione di chi è responsabile dell'esecuzione di ciascuna attività: identifica il team responsabile di un'attività. Assicurati che disponga dei dettagli dell'attività, delle competenze necessarie e di autorizzazioni, accesso e strumenti appropriati per svolgerla. Il team deve comprendere la condizione in cui deve essere eseguita (ad esempio, in un evento o in una pianificazione). Rendi queste informazioni individuabili in modo che i membri della tua organizzazione possano identificare chi contattare, team o individuale, per esigenze specifiche. 

# OPS02-BP04 Conoscenza della propria responsabilità da parte dei membri del team
<a name="ops_ops_model_know_my_job"></a>

 Comprendere le responsabilità del tuo ruolo e il modo in cui contribuisci ai risultati aziendali fornisce indicazioni sulle priorità delle tue attività e sul perché il tuo ruolo è importante. In questo modo i membri del team possono riconoscere le esigenze e rispondere in modo appropriato. 

 **Vantaggi dell'adozione di questa best practice:** comprendere le tue responsabilità fornisce indicazioni sulle decisioni che prendi, le azioni che intraprendi e le tue attività di distribuzione ai proprietari appropriati. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Comprensione da parte dei membri del team dei propri ruoli e responsabilità: identifica i ruoli e le responsabilità dei membri del team e assicurati che comprendano le aspettative del loro ruolo. Rendi queste informazioni individuabili in modo che i membri della tua organizzazione possano identificare chi contattare, team o individuale, per esigenze specifiche. 

# OPS02-BP05 Definizione di meccanismi per identificare responsabilità e proprietà
<a name="ops_ops_model_find_owner"></a>

 Quando non viene identificato alcun individuo o team, esistono percorsi di escalation definiti nei confronti di soggetti dotati dell'autorità per assegnare la proprietà o la pianificazione connesse al soddisfacimento dell'esigenza in questione. 

 **Vantaggi dell'adozione di questa best practice:** Comprendere chi ha la responsabilità o la proprietà ti permette di contattare il team o il componente del team appropriati per presentare una richiesta o trasferire un'attività. Avere una persona identificata che ha l'autorità di assegnare la responsabilità o la proprietà o che può pianificare il soddisfacimento delle esigenze riduce il rischio di inerzia e il pericolo che le esigenze non vengano affrontate. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Definizione di meccanismi per l'identificazione di responsabilità e proprietà: fornisci ai membri della tua organizzazione meccanismi accessibili per scoprire e identificare proprietà e responsabilità. Questo consentirà loro di identificare il team o l'individuo da contattare per esigenze specifiche. 

# OPS02-BP06 Definizione di meccanismi per richiedere aggiunte, modifiche ed eccezioni
<a name="ops_ops_model_req_add_chg_exception"></a>

È possibile effettuare richieste ai proprietari di processi, procedure e risorse. Tra le richieste figurano aggiunte, modifiche ed eccezioni. Tali richieste passano attraverso un processo di gestione delle modifiche Prendi decisioni informate per approvare le richieste quando vengono ritenute fattibili e appropriate dopo una valutazione dei vantaggi e dei rischi. 

 **Risultato desiderato:** 
+  Puoi effettuare richieste per modificare processi, procedure e risorse sulla base della titolarità assegnata. 
+  Le modifiche vengono eseguite in modo deliberato, valutando benefici e rischi. 

 **Anti-pattern comuni:** 
+  Devi aggiornare il modo di implementare la tua applicazione, ma non esiste un metodo per richiedere una modifica al processo di implementazione al team operativo. 
+  Il piano di ripristino di emergenza deve essere aggiornato, ma non è stato identificato il proprietario a cui richiedere le modifiche. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Processi, procedure e risorse possono evolvere mentre cambiano i requisiti. 
+  I titolati possono prendere decisioni mirate su quando effettuare le modifiche. 
+  Le modifiche vengono eseguite deliberatamente. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per implementare questa best practice devi essere in grado di richiedere modifiche a processi, procedure e risorse. Il processo di gestione delle modifiche può essere semplice. Documenta il processo di gestione delle modifiche. 

 **Esempio del cliente** 

 AnyCompany Retail usa una matrice di assegnazione delle responsabilità (RACI) per identificare il proprietario delle modifiche per processi, procedure e risorse. L'azienda dispone di un processo documentato di gestione delle modifiche, semplice e facile da seguire. Tramite il processo e la matrice RACI, tutti possono inviare richieste di modifiche. 

 **Passaggi dell'implementazione** 

1.  Identifica i processi, le procedure e le risorse per il tuo carico di lavoro e i proprietari di ciascun elemento. Documentali nel tuo sistema di gestione delle conoscenze. 

   1.  Se non hai implementato [OPS02-BP01 Associazione di proprietari identificati alle risorse](ops_ops_model_def_resource_owners.md), [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md) o [OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni](ops_ops_model_def_activity_owners.md), comincia per prima cosa da questi. 

1.  Collabora con le parti interessate all'interno della tua azienda per sviluppare un processo di gestione delle modifiche. Il processo deve includere aggiunte, modifiche ed eccezioni per risorse, processi e procedure. 

   1.  Puoi utilizzare [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html) come piattaforma di gestione delle modifiche per le risorse dei carichi di lavoro. 

1.  Documenta il processo di gestione delle modifiche nel tuo sistema di gestione delle conoscenze. 

 **Livello di impegno per il piano di implementazione:** Medio. Sviluppare un processo di gestione delle modifiche significa garantire un allineamento con più parti interessate all'interno dell'organizzazione. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS02-BP01 Associazione di proprietari identificati alle risorse](ops_ops_model_def_resource_owners.md) - I titolari delle risorse devono essere identificati prima di definire un processo di gestione delle modifiche. 
+  [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md) - I titolari dei processi devono essere identificati prima di definire un processo di gestione delle modifiche. 
+  [OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni](ops_ops_model_def_activity_owners.md) - I titolari delle attività operative devono essere identificati prima di definire un processo di gestione delle modifiche. 

 **Documenti correlati:** 
+ [ Prontuario AWS - Playbook di base per grandi migrazioni AWS: creazione di matrici RACI ](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html#raci)
+ [ Whitepaper sulla Gestione delle modifiche nel cloud](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)

 **Servizi correlati:** 
+ [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)

# OPS02-BP07 Predefinizione o negoziazione delle responsabilità tra i team
<a name="ops_ops_model_def_neg_team_agreements"></a>

Fai in modo che esistano accordi definiti o negoziati tra i team che descrivono come funzionano e si supportano reciprocamente (ad esempio, tempi di risposta, obiettivi o contratti relativi al livello di servizio). I canali di comunicazione tra team sono documentati. Comprendere l'impatto del lavoro dei team sui risultati aziendali e sui risultati di altri team e organizzazioni fornisce indicazioni in merito alla priorità dei loro compiti e consente loro di rispondere in modo appropriato. 

 Quando la responsabilità e la proprietà sono indefinite o sconosciute, rischi sia di non affrontare le attività necessarie in modo tempestivo sia di impiegare sforzi ridondanti e potenzialmente conflittuali per rispondere a tali esigenze. 

 **Risultato desiderato:** 
+  Il lavoro tra team o gli accordi di assistenza vengono concordati e documentati. 
+  I team che supportano o lavorano con altri hanno definito i canali di comunicazione e le aspettative in termini di risposte. 

 **Anti-pattern comuni:** 
+  In produzione si verifica un problema e due team separati iniziano a cercare la soluzione senza confrontarsi. Il loro impegno separato prolunga l'interruzione. 
+  Il team operativo ha bisogno di assistenza dal team di sviluppo, ma non c'è un accordo sui tempi di risposta. La richiesta si blocca nel backlog. 

 **Vantaggi dell'adozione di questa best practice:** 
+  I team sanno come interagire e supportarsi a vicenda. 
+  Le aspettative relative ai tempi di risposta sono note. 
+  I canali di comunicazione sono definiti in modo chiaro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Se si implementa questa best practice non ci saranno dubbi sulla collaborazione tra team. Gli accordi formali codificano il modo di collaborare o di assistersi a vicenda dei team. I canali di comunicazione tra team sono documentati. 

 **Esempio del cliente** 

 Il team SRE di AnyCompany Retail ha un contratto sul livello di servizio (SLA) con il team di sviluppo. Ogni volta che il team di sviluppo effettua una richiesta nel sistema di ticketing, riceverà una risposta entro 15 minuti. Se si verifica un malfunzionamento presso la sede, il team SRE assume il comando delle indagini con il supporto del team di sviluppo. 

 **Passaggi dell'implementazione** 

1.  Collaborando con le parti interessate all'interno dell'organizzazione, sviluppa accordi tra team basati su processi e procedure. 

   1.  Se i due team condividono un processo o una procedura, crea un runbook su come i team devono collaborare. 

   1.  Se esistono dipendenze tra i team, concorda uno SLA per le risposte alle richieste. 

1.  Inserisci le responsabilità nel tuo sistema di gestione delle conoscenze. 

 **Livello di impegno per il piano di implementazione:** Medio. Se non esistono accordi tra i team, può essere impegnativo raggiungere un accordo con le parti interessate all'interno dell'organizzazione. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md) - La titolarità dei processi deve essere stabilita prima di definire gli accordi tra i team. 
+  [OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni](ops_ops_model_def_activity_owners.md) - La titolarità delle attività operative deve essere stabilita prima di definire gli accordi tra i team. 

 **Documenti correlati:** 
+ [AWS Executive Insights - Promuovere l'innovazione con i team da due pizze ](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [ Introduzione a DevOps su AWS - I team da due pizze ](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)

# OPS 3. In che modo la cultura aziendale supporta i risultati aziendali?
<a name="ops-03"></a>

 Fornisci supporto ai membri del team in modo che possano essere più efficaci nell'azione e nel supporto dei risultati aziendali. 

**Topics**
+ [OPS03-BP01 Sponsorizzazione esecutiva](ops_org_culture_executive_sponsor.md)
+ [OPS03-BP02 Potere di intervento dei membri del team quando i risultati sono a rischio](ops_org_culture_team_emp_take_action.md)
+ [OPS03-BP03 Incoraggiamento all'escalation](ops_org_culture_team_enc_escalation.md)
+ [OPS03-BP04 Comunicazioni tempestive, chiare e fruibili](ops_org_culture_effective_comms.md)
+ [OPS03-BP05 Incoraggiamento alla sperimentazione](ops_org_culture_team_enc_experiment.md)
+ [OPS03-BP06 Autorizzazione e incoraggiamento ai membri del team a mantenere e ampliare le proprie competenze](ops_org_culture_team_enc_learn.md)
+ [OPS03-BP07 Fornitura di risorse appropriate ai team](ops_org_culture_team_res_appro.md)
+ [OPS03-BP08 Incoraggiamento e ricerca di opinioni diverse all'interno e tra i team](ops_org_culture_diverse_inc_access.md)

# OPS03-BP01 Sponsorizzazione esecutiva
<a name="ops_org_culture_executive_sponsor"></a>

 Gli alti dirigenti stabiliscono chiaramente le aspettative per l'organizzazione e valutano il successo. Gli alti dirigenti sono promotori, sostenitori e motori per l'adozione delle best practice e l'evoluzione dell'organizzazione. 

 **Vantaggi dell'adozione di questa best practice:** Dirigenti coinvolti, aspettative chiare e obiettivi condivisi sono gli elementi necessari per far sì che i membri del team sappiano cosa ci si aspetta da loro. La valutazione del successo consente di identificare gli ostacoli che ne impediscono la riuscita e di superarli tramite l'intervento dei sostenitori promotori dell'iniziativa in questione o dei loro delegati. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Sponsorizzazione esecutiva: gli alti dirigenti stabiliscono chiaramente le aspettative per l'organizzazione e valutano il successo. Gli alti dirigenti sono promotori, sostenitori e motori per l'adozione delle best practice e l'evoluzione dell'organizzazione. 
  +  Definizione delle aspettative: definisci e pubblica gli obiettivi per le tue organizzazioni, incluso il modo in cui verranno misurati. 
  +  Monitoraggio del raggiungimento degli obiettivi: misura regolarmente il raggiungimento incrementale degli obiettivi e condividi i risultati in modo che si possa intraprendere un'azione appropriata se i risultati sono a rischio. 
  +  Disponibilità delle risorse necessarie per raggiungere gli obiettivi stabiliti: verifica regolarmente se le risorse sono ancora appropriate, se sono necessarie risorse aggiuntive in base a nuove informazioni o cambiamenti degli obiettivi, delle responsabilità o dell'ambiente aziendale. 
  +  Sostegno ai team: mantieni un coinvolgimento attivo con i tuoi team in modo da comprendere come stanno e se ci sono fattori esterni che li influenzano. Quando i team sono influenzati da fattori esterni, rivaluta gli obiettivi e modifica i target in base alle esigenze. Individua gli ostacoli che impediscono l'avanzamento dei team. Agisci per conto dei tuoi team per superare gli ostacoli e rimuovere gli oneri superflui. 
  +  Adozione delle best practice: riconosci le best practice che offrono vantaggi quantificabili e identifica creatori e destinatari. Incoraggia ulteriormente l'adozione per amplificare i vantaggi ottenuti. 
  +  Evoluzione dei team: crea una cultura di costante miglioramento. Incoraggia la crescita e lo sviluppo sia personale sia organizzativo. Fornisci validi obiettivi a lungo termine da raggiungere in modo incrementale nel tempo. Adatta questa visione per soddisfare le tue esigenze, gli obiettivi aziendali e l'ambiente aziendale man mano che cambiano. 

# OPS03-BP02 Potere di intervento dei membri del team quando i risultati sono a rischio
<a name="ops_org_culture_team_emp_take_action"></a>

 Il proprietario del carico di lavoro definisce le linee guida e l'ambito consentendo ai membri del team di rispondere quando i risultati sono a rischio. I meccanismi di escalation vengono utilizzati ai fini dell'orientamento quando gli eventi sono al di fuori dell'ambito definito. 

 **Vantaggi dell'adozione di questa best practice:** Testando e convalidando le modifiche in anticipo, puoi risolvere i problemi con costi ridotti al minimo e limitare l'impatto sui clienti. Eseguendo il test prima della distribuzione, riduci al minimo la possibilità di errore. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Garantisci il potere di Intervento dei membri del team quando i risultati sono a rischio: fornisci ai membri del team le autorizzazioni, gli strumenti e l'opportunità per mettere in pratica le competenze necessarie per rispondere in modo efficace. 
  +  Offri ai membri del team l'opportunità di mettere in pratica le competenze necessarie per rispondere: fornisci ambienti sicuri alternativi in cui testare i processi e sottoporre i membri del team alla dovuta formazione in modo sicuro. Esegui le giornate di simulazione per consentire ai membri del team di acquisire esperienza nel rispondere agli incidenti del mondo reale in ambienti simulati e sicuri. 
  +  Definisci e riconosci l'autorità di intervento dei membri del team: definisci in modo specifico l'autorità di intervento dei membri del team assegnando le autorizzazioni e l'accesso ai carichi di lavoro e ai componenti supportati. Riconosci che i membri del team sono autorizzati a intervenire quando i risultati sono a rischio. 

# OPS03-BP03 Incoraggiamento all'escalation
<a name="ops_org_culture_team_enc_escalation"></a>

 I membri del team dispongono di meccanismi e sono incoraggiati a segnalare le preoccupazioni ai responsabili delle decisioni e agli stakeholder se ritengono che i risultati sono a rischio. L'escalation deve essere eseguita in anticipo e di frequente, in modo che i rischi possano essere identificati e limitati prima che provochino incidenti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Incoraggia l'escalation anticipata e frequente: riconosci a livello organizzativo che l'escalation anticipata e frequente è la best practice. Riconosci a livello organizzativo e accetta che le escalation possono rivelarsi infondate e che è meglio avere l'opportunità di prevenire un incidente piuttosto che privarsi di quell'opportunità senza escalation. 
  +  Predisponi un meccanismo per l'escalation: è opportuno disporre di procedure documentate che definiscano quando e come deve verificarsi l'escalation. Documenta la serie di persone in ordine di autorità, cui è consentito intervenire o approvare un'azione e le relative informazioni di contatto. L'escalation deve continuare finché il membro del team non è soddisfatto di aver trasferito il rischio a una persona in grado di risolverlo o di aver contattato la persona che possiede il rischio e la responsabilità per il funzionamento del carico di lavoro. È quella persona che alla fine prende tutte le decisioni in relazione al carico di lavoro. Le escalation devono includere la natura del rischio, la criticità del carico di lavoro, le persone interessate, il grado di impatto e di urgenza, ovvero quando è previsto l'impatto. 
  +  Proteggi i dipendenti coinvolti nell'escalation: è necessario disporre di una policy che protegga i membri del team da eventuali penalizzazioni qualora si trovassero nelle condizioni di scavalcare un decisore non reattivo o uno stakeholder. Metti in atto dei meccanismi per identificare se ciò si verifica e rispondere in modo appropriato. 

# OPS03-BP04 Comunicazioni tempestive, chiare e fruibili
<a name="ops_org_culture_effective_comms"></a>

 Esistono meccanismi che vengono utilizzati per fornire tempestivamente notifiche ai membri del team in merito a rischi noti ed eventi pianificati. Laddove è possibile, vengono forniti contesto, dettagli e tempo per determinare se è necessario intervenire, in che modo e con quali tempistiche. Ad esempio, si può essere emettere un avviso di vulnerabilità del software in modo che le patch vengano applicate rapidamente, oppure si può fornire un avviso sulle promozioni di vendita pianificate al fine di bloccare le modifiche per evitare il rischio di interruzione del servizio. Gli eventi pianificati possono essere registrati in un calendario delle modifiche o in un programma di manutenzione, in modo che i membri del team possano identificare quali attività sono in sospeso. 

 **Risultato desiderato:** 
+  Le comunicazioni offrono contesto, dettagli e aspettative in termini di tempo. 
+  I membri del team hanno una visione chiara rispetto a quando e come agire in risposta alle comunicazioni. 
+  Sfrutta i calendari delle modifiche per comunicare le variazioni attese. 

 **Anti-pattern comuni:** 
+  Più volte a settimana accade che un allarme sia un falso positivo. Elimini il sonoro delle notifica ogni volta che si attiva. 
+  Ti viene chiesto di apportare una modifica ai tuoi gruppi di sicurezza, ma senza aspettative relative ai tempi di rilascio. 
+  Ricevi notifiche frequenti nelle chat quando i sistemi aumentano, ma non è necessaria alcuna azione. Eviti il canale chat e non vedi una notifica importante. 
+  Viene apportata una modifica alla produzione senza informare il team operativo. La modifica attiva un allarme e viene attivato il team di turno. 

 **Vantaggi dell'adozione di questa best practice:** 
+  La tua organizzazione evita l'affaticamento dagli avvisi ("alert fatigue"). 
+  I membri del team possono agire con il contesto e le aspettative richiesti. 
+  Le modifiche possono essere effettuate durante le sessioni previste, riducendo così i rischi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per implementare questa best practice devi collaborare con le parti interessate presenti nell'organizzazione per concordare gli standard di comunicazione. Comunica tali standard alla tua organizzazione. Individua e rimuovi gli allarmi che sono falsi positivi o che sono sempre attivi. Utilizza il calendario delle modifiche in modo che i membri del team sappiano quando intraprendere le azioni e quali sono le attività in sospeso. Verifica se le comunicazioni generano azioni chiare con il contesto necessario. 

 **Esempio del cliente** 

 AnyCompany Retail usa la chat come il proprio mezzo di comunicazione principale. Allarmi e altre informazioni popolano canali specifici. Quando qualcuno deve agire, il risultato desiderato viene definito in modo chiaro e, in molti casi, la persona riceve un runbook o un playbook da usare. Si usa un calendario delle modifiche per pianificare i cambiamenti più importanti ai sistemi di produzione. 

 **Passaggi dell'implementazione** 

1.  Analizza i tuoi allarmi per evidenziare i falsi positivi o gli allarmi che vengono attivati frequentemente. Eliminali o modificali in modo che vengano attivati quando è richiesto l'intervento umano. Se viene attivato un allarme, fornisci un runbook o un playbook. 

   1.  Puoi usare [AWS Systems Manager Documents](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html) per creare playbook e runbook per gli allarmi. 

1.  2Sono stati attivati meccanismi per fornire notifiche in merito ai rischi o agli eventi pianificati in modo chiaro e fruibile al fine di consentire risposte appropriate con tempi di preavviso ragionevoli. Usa elenchi di indirizzi e-mail o canali di chat per inviare le notifiche di preavviso rispetto agli eventi pianificati. 

   1.  [Amazon Q Developer in chat applications](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) può essere utilizzato per inviare allarmi e rispondere agli eventi all'interno della piattaforma di messaggistica della tua organizzazione. 

1.  Fornisci un'origine di informazioni accessibile dove è possibile rilevare gli eventi pianificati. Fornisci notifiche di eventi pianificati dallo stesso sistema. 

   1.  [Il calendario delle modifiche di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) può essere usato per creare sessioni in cui possono verificarsi le variazioni. In questo modo i membri del team ricevono un preavviso su quando poter effettuare la modifica in modo sicuro. 

1.  Monitora le notifiche di vulnerabilità e le informazioni sulle patch per comprendere le vulnerabilità nell'ambiente sregolato e i potenziali rischi associati ai componenti del carico di lavoro. Invia notifiche ai membri del team in modo che possano intervenire. 

   1.  Puoi sottoscrivere [Bollettini sulla sicurezza AWS](https://aws.amazon.com/security/security-bulletins/) per ricevere notifiche sulla vulnerabilità di AWS. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS07-BP03 Utilizzo di runbook per eseguire le procedure](ops_ready_to_support_use_runbooks.md) - Rendi le comunicazioni fruibili fornendo un runbook quando l'esito è noto. 
+  [OPS07-BP04 Utilizzo dei playbook per analizzare i problemi](ops_ready_to_support_use_playbooks.md) - nel caso in cui l'esito non sia noto, i playbook possono essere utili per rendere le comunicazioni fruibili. 

 **Documenti correlati:** 
+ [ Bollettini sulla sicurezza AWS](https://aws.amazon.com/security/security-bulletins)
+ [ Apri CVE ](https://www.opencve.io/welcome)

 **Esempi correlati:** 
+ [ Well-Architected Labs: Inventario e gestione delle patch (Livello 100) ](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)

 **Servizi correlati:** 
+ [Amazon Q Developer in chat applications](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html)
+ [Il calendario delle modifiche di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html)
+ [Documenti di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)

# OPS03-BP05 Incoraggiamento alla sperimentazione
<a name="ops_org_culture_team_enc_experiment"></a>

La sperimentazione è un catalizzatore per trasformare nuove idee in prodotti e funzionalità. La sperimentazione accelera l'apprendimento e mantiene acceso l'interesse e il coinvolgimento dei membri del team. I membri del team sono incoraggiati a sperimentare spesso per promuovere l'innovazione. Anche quando si verifica un risultato indesiderato, è comunque utile sapere quello che non bisogna fare. I membri del team non vengono puniti per gli esperimenti riusciti con risultati indesiderati. 

 **Risultato desiderato:** 
+  La tua organizzazione incoraggia la sperimentazione per promuovere l'innovazione. 
+  Gli esperimenti sono utilizzati come un'opportunità per imparare. 

 **Anti-pattern comuni:** 
+  Vuoi eseguire un test A/B, ma non esiste un meccanismo per eseguire l'esperimento. Distribuisci una modifica all'interfaccia utente senza la possibilità di testarla. Questo comporta un'esperienza cliente negativa. 
+  La tua azienda ha solo un ambiente di test e uno di produzione. Non esiste un ambiente di sperimentazione (sandbox) in cui provare nuove funzionalità o prodotti, per cui le sperimentazioni vengono effettuate all'interno dell'ambiente di produzione. 

 **Vantaggi dell'adozione di questa best practice:** 
+  La sperimentazione incoraggia l'innovazione. 
+  Grazie alla sperimentazione puoi reagire più velocemente al feedback degli utenti. 
+  La tua organizzazione sviluppa una cultura dell'apprendimento. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Le sperimentazioni devono essere eseguite in modo sicuro. Sfrutta più ambienti per sperimentare senza mettere a rischio le risorse di produzione. Usa il test A/B e le flag delle funzionalità per testare gli esperimenti. Offri ai membri del team la possibilità di eseguire esperimenti in un ambiente di sperimentazione (sandbox). 

 **Esempio del cliente** 

 AnyCompany Retail incoraggia la sperimentazione. I membri del team possono dedicare il 20% della propria settimana lavorativa alla sperimentazione o all'apprendimento di nuove tecnologie. Hanno a disposizione un ambiente di sperimentazione (sandbox) in cui possono innovare. Il test A/B viene utilizzato per nuove funzionalità che possono essere così convalidate con il feedback di utenti reali. 

 **Passaggi dell'implementazione** 

1.  Lavora con la direzione della tua organizzazione per supportare la sperimentazione. I membri del team devono essere incoraggiati a eseguire esperimenti in modo sicuro. 

1.  Offri ai membri del team un ambiente in cui possono sperimentare in modo sicuro. Devono avere accesso a un ambiente simile alla produzione. 

   1.  Puoi usare un Account AWS separato per creare un ambiente di sperimentazione (sandbox). [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) può essere usato per eseguire il provisioning di questi account. 

1.  Usa flag delle funzionalità e test A/B per sperimentare in modo sicuro e raccogliere il feedback degli utenti. 

   1.  [AWS AppConfig Feature Flags](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) offre la possibilità di creare flag delle funzionalità. 

   1.  [Amazon CloudWatch Evidently](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html) può essere utilizzato per eseguire test A/B per un'implementazione limitata. 

   1.  Puoi usare le [versioni AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) per implementare una nuova versione di una funzionalità per il test beta. 

 **Livello di impegno per il piano di implementazione:** alto Offrire ai membri del team un ambiente in cui sperimentare in modo sicuro può richiedere investimenti significativi. Potresti anche aver bisogno di modificare il codice dell'applicazione per usare flag di funzionalità o supportare il test A/B. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS11-BP02 Esecuzione di analisi post-incidente](ops_evolve_ops_perform_rca_process.md) - Imparare dagli incidenti è un fattore importante di innovazione e sperimentazione. 
+  [OPS11-BP03 Implementazione di cicli di feedback](ops_evolve_ops_feedback_loops.md) - I cicli di feedback sono una parte importante della sperimentazione. 

 **Documenti correlati:** 
+ [ Uno sguardo approfondito alla cultura di Amazon: Sperimentazione, Fallimento e Ossessione per il cliente ](https://aws.amazon.com/blogs/industries/an-inside-look-at-the-amazon-culture-experimentation-failure-and-customer-obsession/)
+ [ Best practice per creare e gestire account per un ambiente di sperimentazione (sandbox) in AWS](https://aws.amazon.com/blogs/mt/best-practices-creating-managing-sandbox-accounts-aws/)
+ [ Creare una cultura della sperimentazione abilitata dal Cloud ](https://aws.amazon.com/blogs/enterprise-strategy/create-a-culture-of-experimentation-enabled-by-the-cloud/)
+ [ Promuovere sperimentazione e innovazione nel cloud presso SulAmérica Seguros ](https://aws.amazon.com/blogs/mt/enabling-experimentation-and-innovation-in-the-cloud-at-sulamerica-seguros/)
+ [ Sperimenta con più frequenza, sbaglia di meno ](https://aws.amazon.com/blogs/enterprise-strategy/experiment-more-fail-less/)
+ [ Organizzazione dell'ambiente AWS con l'utilizzo di account multipli - OU Sandbox ](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/sandbox-ou.html)
+ [ Usare AWS AppConfig Feature Flags ](https://aws.amazon.com/blogs/mt/using-aws-appconfig-feature-flags/)

 **Video correlati:** 
+ [AWS On Air con Amazon CloudWatch Evidently \$1 Eventi AWS](https://www.youtube.com/watch?v=ydX7lRNKAOo)
+ [AWS On Air San Fran Summit 2022 con integrazione di AWS AppConfig Feature Flags con Jira ](https://www.youtube.com/watch?v=miAkZPtjqHg)
+ [AWS re:Invent 2022 - Un'implementazione non è un rilascio: controlla i tuoi rilasci con flag di funzionalità (BOA305-R) ](https://www.youtube.com/watch?v=uouw9QxVrE8)
+ [ Creazione programmatica di un Account AWS con AWS Control Tower](https://www.youtube.com/watch?v=LxxQTPdSFgw)
+ [ Impostazione di un ambiente AWS multi-account che utilizzi le best practice di AWS Organizations](https://www.youtube.com/watch?v=uOrq8ZUuaAQ)

 **Esempi correlati:** 
+ [AWS Innovation Sandbox ](https://aws.amazon.com/solutions/implementations/aws-innovation-sandbox/)
+ [ Personalizzazione end-to-end 101 per l'e-commerce ](https://catalog.workshops.aws/personalize-101-ecommerce/en-US/labs/ab-testing)

 **Servizi correlati:** 
+  [Amazon CloudWatch Evidently](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html) 
+  [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 

# OPS03-BP06 Autorizzazione e incoraggiamento ai membri del team a mantenere e ampliare le proprie competenze
<a name="ops_org_culture_team_enc_learn"></a>

 I team devono aumentare le proprie competenze per adottare nuove tecnologie e supportare i cambiamenti di domanda e responsabilità a supporto dei carichi di lavoro. L'ampliamento delle competenze nelle nuove tecnologie è spesso fonte di soddisfazione per i membri del team e supporta l'innovazione. Incoraggia i membri del team a perseguire e mantenere le certificazioni di settore in modo da convalidare e riconoscere le loro crescenti competenze. Pratica la formazione trasversale per promuovere il trasferimento di conoscenze e ridurre il rischio di impatto significativo in caso di perdita di membri del team qualificati ed esperti con competenze a livello istituzionale. Fornisci tempo strutturato dedicato per l'apprendimento. 

 AWS fornisce delle risorse, tra cui il [Centro risorse per le nozioni di base di AWS](https://aws.amazon.com/getting-started/), [i Blog AWS](https://aws.amazon.com/blogs/), [gli AWS OnlineTech Talks](https://aws.amazon.com/getting-started/), [Eventi e webinar AWS](https://aws.amazon.com/events/)e gli [AWS Well-Architected Labs](https://wellarchitectedlabs.com/), che forniscono indicazioni, esempi e procedure guidate dettagliate per formare i team. 

 AWS condivide inoltre le best practice e i modelli appresi attraverso la gestione di AWS nella [Amazon Builders' Library](https://aws.amazon.com/builders-library/) e un'ampia gamma di altri utili materiali didattici tramite il [Blog AWS](https://aws.amazon.com/blogs/) e [il podcast ufficiale di AWS](https://aws.amazon.com/podcasts/aws-podcast/). 

 Per formare i team, è consigliabile utilizzare le risorse fornite da AWS, ad esempio i corsi Well-Architected, [Supporto AWS](https://aws.amazon.com/premiumsupport/programs/) ([Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/), [forum di discussione AWS](https://forums.aws.amazon.com/index.jspa)e [Supporto AWS Center](https://console.aws.amazon.com/support/home/)) e la [Documentazione di AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) . Se hai domande riguardanti AWS, contatta Supporto AWS tramite Supporto AWS Center. 

 [AWS Training and Certification](https://aws.amazon.com/training/) offre risorse di formazione gratuite tramite corsi digitali gestiti dall'utente sulle nozioni di base di AWS. Per supportare ulteriormente lo sviluppo delle competenze AWS del tuo team, è anche possibile iscriversi a corsi di formazione con istruttore. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  I membri del team sono autorizzati e incoraggiati a mantenere e ampliare le proprie competenze: la formazione continua è indispensabile per adottare nuove tecnologie, favorire l'innovazione e supportare i cambiamenti della domanda e delle nuove responsabilità a supporto dei carichi di lavoro. 
  +  Metti a disposizione le risorse per la formazione: metti a disposizione del tempo in modo strutturato, accesso ai materiali di formazione, risorse di laboratorio e supporto alla partecipazione a conferenze e organizzazioni professionali che offrono opportunità di apprendimento da docenti e colleghi. Fornisci ai membri del team di primo livello l'accesso ai membri del team senior affinché questi fungano da mentori o possano mostrare loro come lavorano trasmettendo metodi e competenze consolidati. Incoraggia l'apprendimento dei contenuti non direttamente correlati al lavoro per avere una prospettiva più ampia. 
  +  Formazione del team e coinvolgimento tra team: pianifica le esigenze di formazione continua dei membri del tuo team. Offri ai membri del team l'opportunità di unirsi ad altri team (temporaneamente o definitivamente) per condividere competenze e best practice a beneficio dell'intera organizzazione. 
  +  Supporta il perseguimento e il mantenimento delle certificazioni di settore: favorisci l'acquisizione e il mantenimento da parte dei membri del tuo team di certificazioni di settore che convalidano le loro conoscenze e riconoscono i loro risultati. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Centro risorse per le nozioni di base di AWS](https://aws.amazon.com/getting-started/) 
+  [i Blog AWS](https://aws.amazon.com/blogs/) 
+  [Conformità di Cloud AWS](https://aws.amazon.com/compliance/) 
+  [forum di discussione AWS](https://forums.aws.amazon.com/index.jspa) 
+  [Documentazione di AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+  [gli AWS OnlineTech Talks](https://aws.amazon.com/getting-started/) 
+  [Eventi e webinar AWS](https://aws.amazon.com/events/) 
+  [Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [Supporto AWS](https://aws.amazon.com/premiumsupport/programs/) 
+  [AWS Training and Certification](https://aws.amazon.com/training/) 
+  [AWS Well-Architected Labs](https://wellarchitectedlabs.com/), 
+  [Amazon Builders' Library](https://aws.amazon.com/builders-library/) 
+  [il podcast ufficiale di AWS](https://aws.amazon.com/podcasts/aws-podcast/). 

# OPS03-BP07 Fornitura di risorse appropriate ai team
<a name="ops_org_culture_team_res_appro"></a>

 Mantieni la capacità dei membri del team e fornisci strumenti e risorse per supportare le esigenze del carico di lavoro. I membri del team con troppe mansioni aumentano il rischio di incidenti causati da errori umani. Gli investimenti in strumenti e risorse (ad esempio, fornendo automazione per le attività eseguite di frequente) possono ricalibrare l'efficacia del team, consentendogli di supportare attività aggiuntive. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Risorse appropriate ai team: assicurati di comprendere i risultati dei tuoi team e i fattori che contribuiscono al loro successo o insuccesso. Agisci in modo da supportare i team con risorse appropriate. 
  +  Comprensione delle prestazioni del team: misura i risultati operativi raggiunti e lo sviluppo degli asset da parte dei tuoi team. Monitora le modifiche nell'output e nella percentuale di errori nel corso del tempo. Interagisci con i team per comprendere le sfide correlate al lavoro che li riguardano, come l'aumento delle responsabilità, i cambiamenti tecnologici, la perdita di personale o l'aumento dei clienti supportati. 
  +  Comprensione degli effetti sulle prestazioni del team: mantieni un coinvolgimento attivo con i tuoi team in modo da comprendere come stanno e se ci sono fattori esterni che li influenzano. Quando i team sono influenzati da fattori esterni, rivaluta gli obiettivi e modifica i target in base alle esigenze. Individua gli ostacoli che impediscono l'avanzamento dei team. Agisci per conto dei tuoi team per superare gli ostacoli e rimuovere gli oneri superflui. 
  +  Disponibilità delle risorse necessarie per il successo dei team: verifica regolarmente se le risorse sono ancora appropriate, o se sono necessarie risorse aggiuntive, e modifica di conseguenza i team di supporto. 

# OPS03-BP08 Incoraggiamento e ricerca di opinioni diverse all'interno e tra i team
<a name="ops_org_culture_diverse_inc_access"></a>

 Sfrutta la diversità tra organizzazioni per cercare più prospettive uniche. Usa questa prospettiva per incrementare l'innovazione, mettere in discussione le tue ipotesi e ridurre il rischio di conferme parziali. Aumenta l'inclusione, la diversità e l'accessibilità all'interno dei team per ottenere prospettive vantaggiose. 

 La cultura organizzativa influisce direttamente sulla soddisfazione sul lavoro e sulla conservazione dei membri del team. Sostieni il coinvolgimento e le capacità dei membri del tuo team per ottenere il successo della tua attività. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Cerca opinioni e prospettive diverse: incoraggia la condivisione dei contributi da parte di tutti. Dai voce ai gruppi sottorappresentati. Distribuisci a rotazione i ruoli e responsabilità nelle riunioni. 
  +  Amplia ruoli e responsabilità: offri ai membri del team l'opportunità di assumere ruoli che altrimenti potrebbero altrimenti non ricoprire mai. Ciò consentirà loro di acquisire esperienza e nuove prospettive grazie anche alle interazioni con i nuovi membri del team, con i quali potrebbero non interagire altrimenti. Un mutuo scambio di esperienze e punti di vista vantaggioso per tutti Con l'aumento della prospettiva, possono emergere ulteriori opportunità di business o possono essere identificate nuove opportunità di miglioramento. Fai in modo che i membri di un team svolgano a turno attività comuni eseguite normalmente da altri affinché comprendano le richieste e l'impatto delle loro prestazioni. 
  +  Garantisci un ambiente sicuro e ospitale: adotta policy e controlli che consentano di proteggere la sicurezza fisica e mentale dei membri del team all'interno dell'organizzazione. I membri del team devono essere in grado di interagire senza alcun timore. Quando i membri del team si sentono al sicuro e ben accolti, è più probabile che siano coinvolti e produttivi. Più è diversificata la tua organizzazione, migliore sarà la comprensione nei confronti delle persone supportate, inclusi i clienti. Quando i membri del team si sentono a loro agio, sono liberi di parlare e sono sicuri che verranno ascoltati, con maggiori probabilità condivideranno informazioni preziose (ad esempio, opportunità di marketing, esigenze di accessibilità, segmenti di mercato non serviti, rischi non riconosciuti nel tuo ambiente). 
  +  Consenti la totale partecipazione dei membri del team: fornisci le risorse necessarie ai dipendenti affinché partecipino appieno a tutte le attività correlate al lavoro. I membri del team che affrontano sfide quotidiane hanno sviluppato competenze per superarle. Queste competenze esclusive possono offrire vantaggi significativi alla tua organizzazione. Grazie al supporto di strutture adeguate, i membri del team possono portare in azienda contributi vantaggiosi. 

# Preparazione
<a name="a-prepare"></a>

**Topics**
+ [OPS 4. Come si implementa l'osservabilità nel carico di lavoro?](ops-04.md)
+ [OPS 5. In che modo riduci i difetti, favorisci la correzione e migliori il flusso nella produzione?](ops-05.md)
+ [OPS 6. In che modo mitighi i rischi della distribuzione?](ops-06.md)
+ [OPS 7. Come fai a sapere se hai tutto pronto per supportare un carico di lavoro?](ops-07.md)

# OPS 4. Come si implementa l'osservabilità nel carico di lavoro?
<a name="ops-04"></a>

Implementare l'osservabilità nel carico di lavoro ti permette di comprendere lo stato di quest'ultimo e di adottare decisioni basate sui dati e che riflettono i requisiti aziendali.

**Topics**
+ [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md)
+ [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md)
+ [OPS04-BP03 Implementazione della telemetria dell'esperienza utente](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 Implementazione della telemetria delle dipendenze](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md)

# OPS04-BP01 Identificazione degli indicatori chiave di prestazione
<a name="ops_observability_identify_kpis"></a>

 L'implementazione dell'osservabilità nel carico di lavoro inizia con la comprensione del suo stato e l'adozione di decisioni basate sui dati che riflettono i requisiti aziendali. Uno dei modi più efficaci per garantire l'allineamento tra le attività di monitoraggio e gli obiettivi aziendali è definire e monitorare gli indicatori chiave di prestazione (KPI). 

 **Risultato desiderato:** Pratiche di osservabilità efficienti e strettamente allineate agli obiettivi aziendali garantiscono che le attività di monitoraggio siano sempre al servizio di risultati aziendali tangibili. 

 **Anti-pattern comuni:** 
+  KPI non definiti: lavorare senza KPI chiari può portare ad attività di monitoraggio eccessive o insufficienti e alla perdita di segnali vitali. 
+  KPI statici: non riesaminare od ottimizzare i KPI man mano che il carico di lavoro o gli obiettivi aziendali si evolvono. 
+  Disallineamento: concentrarsi su metriche tecniche non direttamente correlate ai risultati aziendali o che sono più difficili da correlare ai problemi del mondo reale. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Facilità di identificazione dei problemi: i KPI aziendali spesso evidenziano i problemi in modo più chiaro rispetto alle metriche tecniche. Un valore di un KPI aziendale che diminuisce permette di individuare un problema in modo più efficace rispetto alla valutazione di numerose metriche tecniche. 
+  Allineamento aziendale: assicura che le attività di monitoraggio supportino direttamente gli obiettivi aziendali. 
+  Efficienza: viene data la priorità alle risorse di monitoraggio e al focus sulle metriche che contano. 
+  Proattività: riconoscere e risolvere i problemi prima che abbiano implicazioni aziendali più ampie. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per definire in modo efficace i KPI del carico di lavoro: 

1.  **Inizia con i risultati aziendali:** prima di approfondire le metriche, comprendi i risultati aziendali desiderati. È stato rilevato un aumento delle vendite, un maggiore coinvolgimento degli utenti o tempi di risposta più rapidi? 

1.  **Correla le metriche tecniche con gli obiettivi aziendali:** non tutte le metriche tecniche hanno un impatto diretto sui risultati aziendali. Identifica quelli che hanno un impatto, anche se spesso è più immediato individuare un problema utilizzando un KPI aziendale. 

1.  **Utilizza [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html):** Utilizza CloudWatch per definire e monitorare le metriche che rappresentano i tuoi KPI. 

1.  **Rivedi e aggiorna regolarmente i KPI:** man mano che il carico di lavoro e la tua attività si evolvono, mantieni la pertinenza dei tuoi KPI. 

1.  **Coinvolgi gli stakeholder:** coinvolgi i team tecnici e aziendali nella definizione e revisione dei KPI. 

 **Livello di impegno per il piano di implementazione:** Medio 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md)
+ [OPS04-BP03 Implementazione della telemetria dell'esperienza utente](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 Implementazione della telemetria delle dipendenze](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md)

 **Documenti correlati:** 
+ [AWS Observability Best Practices ](https://aws-observability.github.io/observability-best-practices/)
+ [ CloudWatch User Guide ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS Observability Skill Builder Course ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)

 **Video correlati:** 
+ [ Developing an observability strategy ](https://www.youtube.com/watch?v=Ub3ATriFapQ)

 **Esempi correlati:** 
+  [One Observability Workshop](https://catalog.workshops.aws/observability/en-US) 

# OPS04-BP02 Implementazione della telemetria dell'applicazione
<a name="ops_observability_application_telemetry"></a>

 La telemetria dell'applicazione è la base su cui si fonda l'osservabilità del carico di lavoro. È fondamentale emettere dati di telemetria che offrano approfondimenti utili sullo stato dell'applicazione e sul raggiungimento degli obiettivi sia tecnici sia aziendali. Dalla risoluzione dei problemi alla misurazione dell'impatto di una nuova funzionalità fino all'allineamento con gli indicatori di prestazione chiave (KPI), la telemetria dell'applicazione garantisce informazioni su cui basare la creazione, il funzionamento e l'evoluzione del carico di lavoro. 

 Metriche, log e tracce costituiscono i tre pilastri principali dell'osservabilità. Questi operano come strumenti diagnostici che descrivono lo stato dell'applicazione. Nel tempo, aiutano a creare criteri di base e a identificare le anomalie. Tuttavia, per garantire l'allineamento tra le attività di monitoraggio e gli obiettivi aziendali, è fondamentale definire e monitorare i KPI. I KPI aziendali spesso facilitano l'identificazione dei problemi rispetto alle sole metriche tecniche. 

 Altri tipi di telemetria, come il monitoraggio degli utenti reali (RUM) e le transazioni sintetiche, completano queste origini dati primarie. Il RUM offre informazioni sulle interazioni degli utenti in tempo reale, mentre le transazioni sintetiche simulano i potenziali comportamenti degli utenti, aiutando a rilevare i colli di bottiglia prima che vengano riscontrati dagli utenti reali. 

 **Risultato desiderato:** Ottieni approfondimenti utili sulle prestazioni del tuo carico di lavoro. Questi approfondimenti consentono di prendere decisioni proattive sull'ottimizzazione delle prestazioni, ottenere una maggiore stabilità del carico di lavoro, semplificare i processi CI/CD e utilizzare le risorse in modo efficace. 

 **Anti-pattern comuni:** 
+  Osservabilità incompleta: trascurare di incorporare l'osservabilità a ogni livello del carico di lavoro, con conseguenti punti ciechi che possono nascondere le prestazioni vitali del sistema e gli approfondimenti sul comportamento. 
+  Visualizzazione frammentata dei dati: quando i dati sono sparsi su più strumenti e sistemi, diventa difficile mantenere una visione olistica dello stato e delle prestazioni del carico di lavoro. 
+  Problemi segnalati dagli utenti: un segno della mancanza di un rilevamento proattivo dei problemi tramite telemetria e monitoraggio dei KPI aziendali. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Processo decisionale informato: con gli approfondimenti ricavati dalla telemetria e dai KPI aziendali, puoi prendere decisioni basate sui dati. 
+  Migliore efficienza operativa: l'utilizzo delle risorse basato sui dati porta a un miglioramento dell'efficienza risparmiando sui costi. 
+  Maggiore stabilità del carico di lavoro: rilevamento e risoluzione più rapidi dei problemi con conseguente aumento dei tempi di attività. 
+  Processi CI/CD semplificati: gli approfondimenti ricavati dai dati di telemetria facilitano il perfezionamento dei processi e la distribuzione affidabile del codice. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per implementare la telemetria delle applicazioni per il tuo carico di lavoro, utilizza servizi AWS come [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) e [AWS X-Ray](https://aws.amazon.com/xray/). Amazon CloudWatch fornisce una suite completa di strumenti di monitoraggio, che consente di osservare le risorse e le applicazioni in ambienti AWS e on-premise. Raccoglie, tiene traccia e analizza le metriche, consolida e monitora i dati di log e risponde alle modifiche che interessano le risorse, migliorando la comprensione del funzionamento del carico di lavoro. Integrato con altri servizi, AWS X-Ray consente di tenere traccia, analizzare ed eseguire il debug delle applicazioni, offrendoti una comprensione approfondita del comportamento del tuo carico di lavoro. Grazie a funzionalità come mappe dei servizi, distribuzioni di latenza e tempistiche di tracciamento, X-Ray fornisce informazioni dettagliate sulle prestazioni del carico di lavoro e sui colli di bottiglia che lo interessano. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  **Identifica quali dati raccogliere:** definisci le metriche, i log e le tracce essenziali che potrebbero offrire importanti informazioni dettagliate sullo stato, le prestazioni e il comportamento del tuo carico di lavoro. 

1.  **Implementa l'agente [CloudWatch](https://aws.amazon.com/cloudwatch/) :** l'agente CloudWatch è fondamentale nel fornire metriche di sistema e dell'applicazione e log dal carico di lavoro e dall'infrastruttura sottostante. L'agente CloudWatch può essere utilizzato anche per raccogliere tracce OpenTelemetry o X-Ray e inviarle a X-Ray. 

1.  **Definisci e monitora i KPI aziendali:** abilita [metriche personalizzate](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) in linea con i tuoi [risultati aziendali](https://aws-observability.github.io/observability-best-practices/guides/operational/business/monitoring-for-business-outcomes/). 

1.  **Fornisci AWS X-Ray alla tua applicazione:** Oltre a implementare l'agente CloudWatch, è fondamentale [dotare la tua applicazione di strumenti](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html) per emettere dati di tracciamento. Questo processo può fornire ulteriori approfondimenti sul comportamento e sulle prestazioni del carico di lavoro. 

1.  **Standardizza la raccolta dei dati in tutta l'applicazione:** standardizza le pratiche di raccolta dei dati in tutta l'applicazione. L'uniformità aiuta a correlare e analizzare i dati, fornendo una visione completa del comportamento dell'applicazione. 

1.  **Analizza e agisci sui dati:** una volta completata la raccolta e la normalizzazione dei dati, utilizza [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) per l'analisi delle metriche e dei log, e [AWS X-Ray](https://aws.amazon.com/xray/features/) per l'analisi delle tracce. Tale analisi può fornire approfondimenti cruciali sullo stato, le prestazioni e il comportamento del carico di lavoro, guidando il processo decisionale. 

 **Livello di impegno per il piano di implementazione:** alto 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md) 
+  [OPS04-BP03 Implementazione della telemetria dell'esperienza utente](ops_observability_customer_telemetry.md) 
+  [OPS04-BP04 Implementazione della telemetria delle dipendenze](ops_observability_dependency_telemetry.md) 
+  [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md) 

 **Documenti correlati:** 
+ [AWS Observability Best Practices ](https://aws-observability.github.io/observability-best-practices/)
+ [ CloudWatch User Guide ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ Guida per gli sviluppatori AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Strumentazione di sistemi distribuiti per visibilità operativa ](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility)
+ [AWS Observability Skill Builder Course ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
+ [ Novità di Amazon CloudWatch ](https://aws.amazon.com/about-aws/whats-new/management-and-governance/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23amazon-cloudwatch)
+ [ Novità di AWS X-Ray](https://aws.amazon.com/about-aws/whats-new/developer-tools/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23aws-x-ray)

 **Video correlati:** 
+ [AWS re:Invent 2022 - Observability best practices at Amazon ](https://youtu.be/zZPzXEBW4P8)
+ [AWS re:Invent 2022 - Developing an observability strategy ](https://youtu.be/Ub3ATriFapQ)

 **Esempi correlati:** 
+  [One Observability Workshop](https://catalog.workshops.aws/observability/en-US) 
+ [ Biblioteca di soluzioni AWS: Monitoraggio delle applicazioni con Amazon CloudWatch ](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch)

# OPS04-BP03 Implementazione della telemetria dell'esperienza utente
<a name="ops_observability_customer_telemetry"></a>

 Acquisire informazioni approfondite sulle esperienze dei clienti e sulle interazioni con la tua applicazione è fondamentale. Il monitoraggio dell'utente reale (RUM) e le transazioni sintetiche sono strumenti molto efficaci per questo scopo. RUM fornisce dati sulle interazioni degli utenti reali, garantendo una prospettiva non filtrata della soddisfazione degli utenti, mentre le transazioni sintetiche simulano le interazioni degli utenti, aiutando a rilevare potenziali problemi prima che essi abbiano un impatto sugli utenti reali. 

 **Risultato desiderato:** Una visione olistica dell'esperienza del cliente, il rilevamento proattivo dei problemi e l'ottimizzazione delle interazioni degli utenti per offrire esperienze digitali fluide. 

 **Anti-pattern comuni:** 
+  Applicazioni senza monitoraggio dell'utente reale (RUM): 
  +  rilevamento ritardato dei problemi: senza RUM, potresti non accorgerti di rallentamenti o problemi di prestazioni fino a quando non ricevi lamentele da parte degli utenti. Questo approccio reattivo può causare insoddisfazione nei clienti. 
  +  Mancanza di informazioni sull'esperienza utente: non utilizzare RUM significa perdere dati cruciali che mostrano come gli utenti reali interagiscono con l'applicazione, il che limita la tua capacità di ottimizzare l'esperienza utente. 
+  Applicazioni senza transazioni sintetiche: 
  +  Casi limite trascurati: le transazioni sintetiche consentono di testare percorsi e funzioni che potrebbero non essere utilizzati frequentemente dagli utenti tipici, ma che sono fondamentali per determinate funzioni aziendali. Senza di esse, questi percorsi potrebbero non funzionare correttamente e passare inosservati. 
  +  Verifica della presenza di problemi quando l'applicazione non viene utilizzata: i test sintetici regolari possono simulare situazioni in cui gli utenti reali non interagiscono attivamente con l'applicazione, garantendo che il sistema funzioni sempre correttamente. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Rilevamento proattivo dei problemi: identifica e risolvi i problemi potenziali prima che abbiano un impatto sugli utenti reali. 
+  Esperienza utente ottimizzata: grazie al suo feedback continuo, RUM aiuta a perfezionare e migliorare l'esperienza utente complessiva. 
+  Informazioni approfondite sulle prestazioni del dispositivo e del browser: scopri come si comporta la tua applicazione in vari dispositivi e browser e implementa ulteriori ottimizzazioni. 
+  Flussi di lavoro aziendali convalidati: transazioni sintetiche regolari assicurano che le funzionalità principali e i percorsi critici siano operativi ed efficienti in maniera costante. 
+  Prestazioni delle applicazioni migliorate: sfrutta le informazioni approfondite raccolte dai dati degli utenti reali per migliorare la reattività e l'affidabilità delle applicazioni. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per eseguire la telemetria delle attività degli utenti sfruttando RUM e le transazioni sintetiche, AWS offre servizi come [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) e [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html). Metriche, log e tracce, insieme ai dati sulle attività degli utenti, forniscono una visione completa dello stato operativo dell'applicazione e dell'esperienza utente. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  **Implementa Amazon CloudWatch RUM:** integra la tua applicazione con CloudWatch RUM per raccogliere, analizzare e presentare dati relativi agli utenti reali. 

   1.  Utilizza [la libreria JavaScript CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) per integrare RUM con la tua applicazione. 

   1.  Configura dashboard per visualizzare e monitorare i dati relativi agli utenti reali. 

1.  **Configura CloudWatch Synthetics:** crea canary o routine con script che simulano le interazioni degli utenti con la tua applicazione. 

   1.  Definisci i flussi di lavoro e i percorsi critici delle applicazioni. 

   1.  Progetta canary utilizzando [script di CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) per simulare le interazioni degli utenti per questi percorsi. 

   1.  Pianifica e monitora i canary affinché si attivino a intervalli specifici, in modo da garantire controlli costanti delle prestazioni. 

1.  **Analizza e intervieni sui dati:** Utilizza i dati provenienti da RUM e transazioni sintetiche per ottenere informazioni e adottare misure correttive quando vengono rilevate anomalie. Usa dashboard CloudWatch e allarmi per ottenere informazioni costanti. 

 **Livello di impegno per il piano di implementazione:** Medio 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md) 
+  [OPS04-BP04 Implementazione della telemetria delle dipendenze](ops_observability_dependency_telemetry.md) 
+  [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md) 

 **Documenti correlati:** 
+ [ Amazon CloudWatch RUM Guide ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [ Amazon CloudWatch Synthetics Guide ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)

 **Video correlati:** 
+ [ Optimize applications through end user insights with Amazon CloudWatch RUM ](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [AWS on Air ft. Real-User Monitoring for Amazon CloudWatch ](https://www.youtube.com/watch?v=r6wFtozsiVE)

 **Esempi correlati:** 
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Repository Git per client Web Amazon CloudWatch RUM ](https://github.com/aws-observability/aws-rum-web)
+ [ Using Amazon CloudWatch Synthetics to measure page load time ](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance)

# OPS04-BP04 Implementazione della telemetria delle dipendenze
<a name="ops_observability_dependency_telemetry"></a>

 La telemetria delle dipendenze è essenziale per monitorare lo stato e le prestazioni dei servizi e dei componenti esterni su cui si basa il carico di lavoro. Fornisce preziose informazioni dettagliate su reperibilità, timeout e altri eventi critici correlati alle dipendenze come DNS, database o API di terze parti. Dotando l'applicazione di strumenti per generare metriche, log e tracce relative a queste dipendenze, acquisisci una comprensione più chiara dei potenziali colli di bottiglia, problemi di prestazioni o errori che potrebbero influire sul carico di lavoro. 

 **Risultato desiderato:** Le dipendenze su cui si basa il carico di lavoro funzionano come previsto, consentendo di gestire i problemi in modo proattivo e garantendo prestazioni ottimali del carico di lavoro. 

 **Anti-pattern comuni:** 
+  Scarsa attenzione alle dipendenze esterne: il focus è rivolto esclusivamente alle metriche interne dell'applicazione, trascurando quelle legate alle dipendenze esterne. 
+  Mancanza di monitoraggio proattivo: si attende che si verifichino problemi anziché monitorare costantemente lo stato e le prestazioni delle dipendenze. 
+  Monitoraggio isolato in comparti: utilizzo di strumenti di monitoraggio multipli ed eterogenei che possono portare a visioni dello stato delle dipendenze frammentate e incoerenti. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Maggiore affidabilità del carico di lavoro: viene garantito che le dipendenze esterne siano costantemente disponibili e funzionino in modo ottimale. 
+  Rilevamento e risoluzione dei problemi più rapidi: identificazione e risoluzione proattiva dei problemi relativi alle dipendenze prima che influiscano sul carico di lavoro. 
+  Visione completa: acquisizione di una visione olistica dei componenti interni ed esterni che influenzano lo stato del carico di lavoro. 
+  Scalabilità del carico di lavoro migliorata grazie alla comprensione dei limiti di scalabilità e delle caratteristiche prestazionali delle dipendenze esterne. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Implementa la telemetria delle dipendenze iniziando con l'identificazione dei servizi, dell'infrastruttura e dei processi da cui dipende il carico di lavoro. Esegui una valutazione quantitativa delle condizioni ottimali nelle quali tali dipendenze funzionano come previsto e poi determina quali dati sono necessari per misurarle. Con queste informazioni, puoi creare dashboard e avvisi che forniscono informazioni dettagliate ai tuoi team operativi sullo stato di tali dipendenze. Usa gli strumenti AWS per scoprire e quantificare gli impatti quando le dipendenze non riescono a fornire le prestazioni necessarie. Rivedi costantemente la tua strategia per tenere conto dei cambiamenti relativi a priorità, obiettivi e alle informazioni dettagliate acquisite. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Per implementare efficacemente la telemetria delle dipendenze: 

1.  **Identifica le dipendenze esterne:** collabora con gli stakeholder per individuare le dipendenze esterne sulle quali si basa il tuo carico di lavoro. Le dipendenze esterne possono comprendere servizi come database esterni, API di terze parti, percorsi di connettività di rete verso altri ambienti e servizi DNS. Il primo passo verso un'efficace telemetria delle dipendenze è acquisire una comprensione totale di quali esse siano. 

1.  **Sviluppa una strategia di monitoraggio:** una volta acquisito un quadro chiaro delle dipendenze esterne, progetta una strategia di monitoraggio ad hoc per esse. Trovare la strategia giusta implica comprendere le criticità di tutte le dipendenze, il loro comportamento previsto e gli eventuali accordi od obiettivi sul livello di servizio associato (SLA o SLT). Imposta avvisi proattivi che ti informino riguardo a cambiamenti di stato o deviazioni delle prestazioni. 

1.  **Sfrutta [Monitor Internet Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html):** fornisce approfondimenti sull'Internet globale, aiutandoti a comprendere interruzioni o perturbazioni che potrebbero influire sulle dipendenze esterne. 

1.  **Non perdere alcun aggiornamento con [Dashboard AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/):** fornisce avvisi e indicazioni per la correzione qualora AWS sia interessato da eventi che potrebbero influire sui servizi. 

1.  **Potenzia la tua applicazione con [AWS X-Ray](https://aws.amazon.com/xray/):** AWS X-Ray fornisce informazioni dettagliate sulle prestazioni delle applicazioni e delle relative dipendenze sottostanti. La tracciatura delle richieste dall'inizio alla fine ti permette di identificare colli di bottiglia o guasti nei servizi o nei componenti esterni su cui si basa l'applicazione. 

1.  **Utilizza [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/):** questo servizio basato sul machine learning identifica i problemi operativi, prevede quando potrebbero verificarsi problemi critici e consiglia azioni specifiche da intraprendere. Fornisce un supporto prezioso per acquisire informazioni dettagliate sulle dipendenze e determinare che queste non siano la fonte di problemi operativi. 

1.  **Monitora regolarmente:** monitora le metriche e i log relativi alle dipendenze esterne in maniera costante. Imposta avvisi per comportamenti imprevisti o prestazioni ridotte. 

1.  **Convalida dopo le modifiche:** ogni volta che una dipendenza esterna è interessata da un aggiornamento o una modifica, convalidane le prestazioni e verifica che queste siano in linea con i requisiti dell'applicazione. 

 **Livello di impegno per il piano di implementazione:** Medio 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md) 
+  [OPS04-BP03 Implementazione della telemetria dell'esperienza utente](ops_observability_customer_telemetry.md) 
+  [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md) 

 **Documenti correlati:** 
+ [ What is AWS Health? ](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [ Using Amazon CloudWatch Internet Monitor ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html)
+ [Guida per gli sviluppatori AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Amazon DevOps Guru User Guide ](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)

 **Video correlati:** 
+ [ Visibility into how internet issues impact app performance ](https://www.youtube.com/watch?v=Kuc_SG_aBgQ)
+ [ Introduction to Amazon DevOps Guru ](https://www.youtube.com/watch?v=2uA8q-8mTZY)

 **Esempi correlati:** 
+ [ Gaining operational insights with AIOps using Amazon DevOps Guru ](https://catalog.us-east-1.prod.workshops.aws/workshops/f92df379-6add-4101-8b4b-38b788e1222b/en-US)
+ [AWS Health Aware ](https://github.com/aws-samples/aws-health-aware/)

# OPS04-BP05 Implementazione del tracciamento distribuito
<a name="ops_observability_dist_trace"></a>

 Il tracciamento distribuito offre un modo per monitorare e visualizzare le richieste mentre attraversano vari componenti di un sistema distribuito. Acquisendo i dati di tracciamento da più fonti e analizzandoli in una vista unificata, i team possono comprendere meglio il flusso delle richieste, in quali punti sono presenti colli di bottiglia e dove devono concentrare gli sforzi di ottimizzazione. 

 **Risultato desiderato:** Una visione olistica del flusso delle richieste nel tuo sistema distribuito, che ti permette di ottenere un debug preciso, prestazioni ottimizzate e migliori esperienze utente. 

 **Anti-pattern comuni:** 
+  Strumentazione incoerente: non tutti i servizi in un sistema distribuito sono dotati di strumentazione per il monitoraggio. 
+  Ignorare la latenza: concentrarsi solo sugli errori e non considerare la latenza o il graduale deterioramento delle prestazioni. 

 **Vantaggi dell'adozione di questa best practice:** 
+ Panoramica completa del sistema: visualizzazione dell'intero percorso delle richieste, dall'ingresso all'uscita.
+  Debug avanzato: identificazione rapida dei punti in cui si verificano guasti o problemi di prestazioni. 
+  Esperienza utente migliorata: monitoraggio e ottimizzazione in base ai dati effettivi dell'utente, garantendo che il sistema soddisfi le esigenze del mondo reale. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Inizia identificando tutti gli elementi del carico di lavoro che richiedono strumentazione. Una volta presi in considerazione tutti i componenti, sfrutta strumenti come AWS X-Ray e OpenTelemetry per raccogliere dati di tracciamento da analizzare con strumenti come X-Ray e Amazon CloudWatchServiceLens Map. Effettua revisioni periodiche insieme agli sviluppatori e integra queste discussioni con strumenti come Amazon DevOps Guru, X-Ray Analytics e X-Ray Insights per ottenere risultati più approfonditi. Imposta avvisi basati sui dati di tracciamento per notificare quando i risultati sono a rischio, come definito nel piano di monitoraggio del carico di lavoro. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Per implementare il tracciamento distribuito in modo efficace: 

1.  **Adotta [AWS X-Ray](https://aws.amazon.com/xray/):** implementa X-Ray nella tua applicazione per ottenere informazioni dettagliate sul suo comportamento, comprenderne le prestazioni e individuare i punti critici. Utilizza X-Ray Insights per l'analisi automatica dei tracciamenti. 

1.  **Dota i tuoi servizi di strumenti:** verifica che tutti i servizi, dalle funzioni [AWS Lambda](https://aws.amazon.com/lambda/) alle [istanze EC2](https://aws.amazon.com/ec2/), siano in grado di inviare dati di tracciamento. Più servizi doti di strumentazione, più chiara sarà la visione end-to-end. 

1.  **Incorpora [il monitoraggio dell'utente reale tramite CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) e [il monitoraggio sintetico](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html):** integra il monitoraggio dell'utente reale (RUM) e il monitoraggio sintetico con X-Ray. Ciò ti consente di acquisire esperienze utenti del mondo reale e simulare le interazioni degli utenti per identificare potenziali problemi. 

1.  **Utilizza [l'agente CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html):** l'agente può inviare dati di tracciamento da X-Ray o da OpenTelemetry, permettendoti di raccogliere informazioni più approfondite. 

1.  **Utilizza [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/):** DevOps Guru utilizza dati provenienti da X-Ray, CloudWatch, AWS Config e AWS CloudTrail per fornire suggerimenti fruibili. 

1.  **Analizza le tracce:** esamina regolarmente i dati di tracciamento per individuare schemi, anomalie o colli di bottiglia che possono influire sulle prestazioni dell'applicazione. 

1.  **Imposta avvisi:** configura avvisi in [CloudWatch](https://aws.amazon.com/cloudwatch/) per segnalare schemi insoliti o latenze prolungate, il che ti permette di effettuare una risoluzione proattiva dei problemi. 

1.  **Miglioramento continuo:** riesamina la tua strategia di tracciamento man mano che aggiungi o modifichi servizi per acquisire tutti i punti dati pertinenti. 

 **Livello di impegno per il piano di implementazione:** Medio 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md) 
+  [OPS04-BP03 Implementazione della telemetria dell'esperienza utente](ops_observability_customer_telemetry.md) 
+  [OPS04-BP04 Implementazione della telemetria delle dipendenze](ops_observability_dependency_telemetry.md) 

 **Documenti correlati:** 
+ [ Guida per gli sviluppatori AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Amazon CloudWatch agent User Guide ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [ Amazon DevOps Guru User Guide ](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)

 **Video correlati:** 
+ [ Use AWS X-Ray Insights ](https://www.youtube.com/watch?v=tl8OWHl6jxw)
+ [AWS on Air ft. Observability: Amazon CloudWatch and AWS X-Ray](https://www.youtube.com/watch?v=qBDBnPkZ-KI)

 **Esempi correlati:** 
+ [ Instrumenting your Application with AWS X-Ray](https://aws.amazon.com/getting-started/hands-on/distributed-tracing-with-xray/)

# OPS 5. In che modo riduci i difetti, favorisci la correzione e migliori il flusso nella produzione?
<a name="ops-05"></a>

 Adotta prassi che migliorino il flusso delle modifiche nella produzione, che attivino la rifattorizzazione e il feedback veloce su qualità e correzione di errori. Tali prassi accelerano l'ingresso in produzione delle modifiche vantaggiose, contengono i problemi che si sono diffusi e permettono di ottenere una rapida identificazione e risoluzione dei problemi introdotti attraverso le attività di implementazione. 

**Topics**
+ [OPS05-BP01 Utilizzo del controllo delle versioni](ops_dev_integ_version_control.md)
+ [OPS05-BP02 Test e convalida delle modifiche](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP03 Utilizzo di sistemi di gestione delle configurazioni](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 Utilizzo di sistemi di gestione della compilazione e implementazione](ops_dev_integ_build_mgmt_sys.md)
+ [OPS05-BP05 Esecuzione della gestione delle patch](ops_dev_integ_patch_mgmt.md)
+ [OPS05-BP06 Condivisione degli standard di progettazione](ops_dev_integ_share_design_stds.md)
+ [OPS05-BP07 Implementazione di prassi per migliorare la qualità del codice](ops_dev_integ_code_quality.md)
+ [OPS05-BP08 Utilizzo di più ambienti](ops_dev_integ_multi_env.md)
+ [OPS05-BP09 Applicazione di modifiche frequenti, minime e reversibili](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 Automazione completa dell'integrazione e della distribuzione](ops_dev_integ_auto_integ_deploy.md)

# OPS05-BP01 Utilizzo del controllo delle versioni
<a name="ops_dev_integ_version_control"></a>

 Utilizza il controllo delle versioni per attivare il monitoraggio di modifiche e rilasci. 

 Molti servizi AWS offrono funzionalità di controllo delle versioni. Utilizza una revisione o un sistema di controllo del codice sorgente come [AWS CodeCommit](https://aws.amazon.com/codecommit/) per gestire il codice e altri artefatti, come i modelli [AWS CloudFormation](https://aws.amazon.com/cloudformation/) controllati dalla versione della tua infrastruttura. 

 **Risultato desiderato:** I tuoi team collaborano alla gestione del codice. Una volta unito, il codice è coerente e nessuna modifica viene persa. Gli errori possono essere facilmente ripristinati mediante il corretto controllo delle versioni. 

 **Anti-pattern comuni:** 
+  Hai sviluppato e archiviato il codice sulla workstation. Si è verificato un errore di archiviazione non recuperabile sulla workstation e il codice è andato perso. 
+  Dopo aver sovrascritto il codice esistente con le modifiche, riavvii l'applicazione e non è più utilizzabile. Non è possibile ripristinare la modifica. 
+  Hai un blocco di scrittura su un file di report che deve essere modificato da altri utenti. Ti contattano per chiederti di smettere di utilizzarlo in modo che possano completare le loro attività. 
+  Il team di ricerca ha lavorato a un'analisi dettagliata che definisce il tuo lavoro futuro. Qualcuno ha salvato accidentalmente la lista della spesa nel report finale. Non puoi ripristinare la modifica e devi ricreare il report. 

 **Vantaggi dell'adozione di questa best practice:** Grazie alle funzionalità di controllo delle versioni, puoi ripristinare facilmente gli stati validi noti e le versioni precedenti e limitare il rischio di perdita degli asset. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Mantieni gli asset in repository con controllo delle versioni. In questo modo si supporta il monitoraggio delle modifiche, la distribuzione di nuove versioni, il rilevamento delle modifiche apportate alle versioni esistenti e il ripristino delle versioni precedenti, ad esempio il rollback a uno stato corretto noto in caso di errore. Integra nelle tue procedure le funzionalità di controllo delle versioni dei sistemi di gestione delle configurazioni. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS05-BP04 Utilizzo di sistemi di gestione della compilazione e implementazione](ops_dev_integ_build_mgmt_sys.md) 

 **Documenti correlati:** 
+  [Che cos'è AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

 **Video correlati:** 
+  [Introduzione ad AWS CodeCommit](https://youtu.be/46PRLMW8otg) 

# OPS05-BP02 Test e convalida delle modifiche
<a name="ops_dev_integ_test_val_chg"></a>

 Ogni modifica apportata deve essere testata per evitare errori in produzione. Questa best practice si concentra sulla verifica delle modifiche dal controllo di versione alla creazione dell'artefatto. Oltre alle modifiche al codice dell'applicazione, i test dovrebbero includere l'infrastruttura, la configurazione, i controlli di sicurezza e le procedure operative. I test assumono molte forme, dai test unitari all'analisi dei componenti software (SCA). Spostando i test più a sinistra nel processo di integrazione e consegna del software ottieni una maggiore certezza della qualità degli artefatti. 

 L'organizzazione deve sviluppare standard di test per tutti gli artefatti software. I test automatizzati riducono la fatica ed evitano gli errori dei test manuali. I test manuali potrebbero essere necessari in alcuni casi. Gli sviluppatori devono avere accesso ai risultati dei test automatizzati per creare cicli di feedback che migliorino la qualità del software. 

 **Risultato desiderato:** Le modifiche software vengono testate prima del rilascio. Gli sviluppatori hanno accesso ai risultati dei test e alle convalide. La tua organizzazione ha uno standard per i test che applica a tutte le modifiche software. 

 **Anti-pattern comuni:** 
+ Implementi una nuova modifica software senza test. Non funziona in produzione e genera un'interruzione.
+ I nuovi gruppi di sicurezza vengono distribuiti con CloudFormation senza essere testati in un ambiente di pre-produzione. I gruppi di sicurezza rendono la tua app irraggiungibile per i clienti.
+ Un metodo viene modificato, ma non ci sono test di unità. Il software ha esito negativo quando viene distribuito in produzione.

 **Vantaggi dell'adozione di questa best practice:** Ridotto tasso di fallimento delle implementazioni software. La qualità del software viene migliorata. Gli sviluppatori hanno una maggiore consapevolezza della fattibilità del loro codice. Le policy di sicurezza possono essere implementate in maniera affidabile per supportare la conformità dell'organizzazione. Le modifiche all'infrastruttura, come gli aggiornamenti automatici delle politiche di scaling, vengono testate in anticipo per soddisfare le esigenze del traffico. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I test vengono eseguiti su tutte le modifiche, dal codice dell'applicazione all'infrastruttura, come parte della pratica di integrazione continua. I risultati dei test vengono pubblicati in modo che gli sviluppatori abbiano un feedback rapido. La tua organizzazione ha uno standard per i test che applica a tutte le modifiche software. 

 **Esempio del cliente** 

 Nell'ambito della pipeline di integrazione continua, AnyCompany Retail esegue diversi tipi di test su tutti gli artefatti software. Praticano lo sviluppo guidato dai test, per cui tutto il software è dotato di test unitari. Una volta creato l'artefatto, eseguono test end-to-end. Al termine di questa prima serie di test, viene eseguita una scansione statica della sicurezza dell'applicazione, alla ricerca di vulnerabilità note. Gli sviluppatori ricevono messaggi al superamento di ciascun gate di test. Una volta completati tutti i test, l'artefatto software viene archiviato in un repository di artefatti. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Collaborare con le parti interessate dell'organizzazione per sviluppare uno standard di test per gli artefatti software. Quali test standard devono superare tutti gli artefatti? Ci sono requisiti di conformità o di governance che devono essere inclusi nella copertura dei test? Devi condurre test di qualità del codice? Quando i test sono terminati, chi deve esserne a conoscenza? 

   1.  Il comando [L'architettura di riferimento per pipeline di implementazione AWS](https://pipelines.devops.aws.dev/) contiene un elenco autorevole dei tipi di test che possono essere condotti su artefatti software come parte di una pipeline di integrazione. 

1.  Fornisci la tua applicazione dei test necessari in base allo standard di test del software. Ogni set di test deve essere completato in meno di dieci minuti. I test devono essere eseguiti come parte della pipeline di integrazione. 

   1.  [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) può testare il codice dell'applicazione per trovare eventuali difetti. 

   1.  Puoi utilizzare [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) per condurre i test su artefatti software. 

   1.  [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) può organizzare i test software in una pipeline. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS05-BP01 Utilizzo del controllo delle versioni](ops_dev_integ_version_control.md) 
+  [OPS05-BP06 Condivisione degli standard di progettazione](ops_dev_integ_share_design_stds.md) 
+  [OPS05-BP10 Automazione completa dell'integrazione e della distribuzione](ops_dev_integ_auto_integ_deploy.md) 

 **Documenti correlati:** 
+ [ Adotta un approccio allo sviluppo basato sul test ](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [ Automated CloudFormation Testing Pipeline with TaskCat and CodePipeline ](https://aws.amazon.com/blogs/devops/automated-cloudformation-testing-pipeline-with-taskcat-and-codepipeline/)
+ [ Building end-to-end AWS DevSecOps CI/CD pipeline with open source SCA, SAST, and DAST tools ](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
+ [ Iniziare a usare applicazioni serverless di test ](https://aws.amazon.com/blogs/compute/getting-started-with-testing-serverless-applications/)
+ [ La mia pipeline CI/CD è la mia release captain ](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [ Practicing Continuous Integration and Continuous Delivery on AWS Whitepaper ](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)

 **Video correlati:** 
+ [AWS re:Invent 2020: Testable infrastructure: Integration testing on AWS](https://www.youtube.com/watch?v=KJC380Juo2w)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development ](https://www.youtube.com/watch?v=1R7G_wcyd3s)
+ [ Testare l'infrastruttura come codice con AWS CDK ](https://www.youtube.com/watch?v=fWtuwGSoSOU)

 **Risorse correlate:** 
+ [AWS Deployment Pipeline Reference Architecture - Application ](https://pipelines.devops.aws.dev/application-pipeline/index.html)
+ [AWS Kubernetes DevSecOps Pipeline ](https://github.com/aws-samples/devsecops-cicd-containers)
+ [ Policy come codice - Workshop – Sviluppo incentrato sui test ](https://catalog.us-east-1.prod.workshops.aws/workshops/9da471a0-266a-4d36-8596-e5934aeedd1f/en-US/pac-tools/cfn-guard/tdd)
+ [ Run unit tests for a Node.js application from GitHub by using AWS CodeBuild](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.html)
+ [ Usa Serverspec per lo sviluppo incentrato sul test del codice dell'infrastruttura ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/use-serverspec-for-test-driven-development-of-infrastructure-code.html)

 **Servizi correlati:** 
+  [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 
+  [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
+  [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 

# OPS05-BP03 Utilizzo di sistemi di gestione delle configurazioni
<a name="ops_dev_integ_conf_mgmt_sys"></a>

 L'utilizzo di sistemi di gestione delle configurazioni permette di effettuare modifiche alle stesse e tenerne traccia. Questi sistemi riducono gli errori causati dai processi manuali e il livello di impegno richiesto per la distribuzione delle modifiche. 

 Durante l'inizializzazione di una risorsa, la gestione delle configurazioni statiche consente di impostare valori che dovrebbero rimanere coerenti per tutta la vita utile della risorsa. Ne sono alcuni esempi l'azione di configurare un server web o applicativo su un'istanza oppure di definire la configurazione di un servizio AWS nella [Console di gestione AWS](https://docs.aws.amazon.com/awsconsolehelpdocs/index.html) o tramite la [AWS CLI](https://aws.amazon.com/cli/). 

 Al momento dell'inizializzazione, la gestione delle configurazioni dinamiche consente di impostare valori che possono cambiare nel corso della vita utile di una risorsa. Ad esempio è possibile impostare un interruttore funzionale in grado di attivare una funzionalità nel codice tramite una modifica della configurazione, oppure modificare il livello di dettaglio del log durante un incidente per acquisire un maggior numero di dati e cambiarlo in seguito per tornare al livello di dettaglio precedente, risparmiando così in numero di log e nei relativi costi. 

 In AWS, è possibile utilizzare [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) per monitorare in modo continuo le configurazioni delle risorse AWS [tra i diversi account e regioni](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html). Questa soluzione aiuta a tenere traccia della cronologia delle configurazioni, a capire che effetto avrebbe la modifica di una configurazione sulle altre risorse e a verificarle rispetto alle configurazioni previste o desiderate tramite [Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) e [pacchetti di conformità AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html). 

 Se sulle applicazioni in esecuzione su istanze Amazon EC2, AWS Lambda, container, funzioni serverless, applicazioni mobili o dispositivi IoT sono attive configurazioni dinamiche, è possibile utilizzare [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) per configurarle, convalidarle, implementarle e monitorarle nei tuoi ambienti. 

 In AWS, puoi creare pipeline di integrazione continua/distribuzione continua (CI/CD) utilizzando servizi come gli [Strumenti per sviluppatori in AWS](https://aws.amazon.com/products/developer-tools/) (ad esempio: [AWS CodeCommit](https://aws.amazon.com/codecommit/), [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodePipeline](https://aws.amazon.com/codepipeline/), [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)e [AWS CodeStar](https://aws.amazon.com/codestar/)). 

 **Risultato desiderato:** Puoi configurare, convalidare e implementare come parte della tua pipeline di integrazione continua e di distribuzione continua (CI/CD). Esegui il monitoraggio per verificare che le configurazioni siano corrette. Ciò riduce al minimo l'impatto sugli utenti finali e sui clienti. 

 **Anti-pattern comuni:** 
+  Aggiorni manualmente la configurazione del server Web all'interno del parco istanze e un certo numero di server non risponde a causa di errori di aggiornamento. 
+  Aggiorni manualmente il parco istanze del server applicazioni nel corso di molte ore. L'incoerenza nella configurazione durante la modifica causa comportamenti imprevisti. 
+  Qualcuno ha aggiornato i tuoi gruppi di sicurezza e i server Web non sono più accessibili. Senza sapere cosa è stato modificato, dedichi molto tempo a esaminare il problema prolungando il tempo necessario per il ripristino. 
+  Avvii una configurazione di preproduzione in produzione tramite CI/CD senza una convalida. Esponi utenti e clienti a dati e servizi errati. 

 **Vantaggi dell'adozione di questa best practice:** L'adozione di sistemi di gestione della configurazione riduce il livello di impegno necessario per apportare e tenere traccia delle modifiche e la frequenza degli errori causati dalle procedure manuali. I sistemi di gestione della configurazione forniscono garanzie per quanto riguarda la governance, la conformità e i requisiti normativi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I sistemi di gestione della configurazione vengono utilizzati per tenere traccia e implementare le modifiche nelle configurazioni delle applicazioni e degli ambienti. I sistemi di gestione della configurazione vengono utilizzati anche per ridurre gli errori causati dai processi manuali, rendere le modifiche alla configurazione ripetibili e verificabili e per ridurre il livello di impegno. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Identifica i proprietari della configurazione. 

   1.  Metti a conoscenza i proprietari delle configurazioni di qualsiasi esigenza di conformità, governance o normativa. 

1.  Identifica gli elementi e i risultati della configurazione. 

   1.  Gli elementi di configurazione sono tutte le configurazioni ambientali e dell'applicazione interessate da un'implementazione all'interno della pipeline CI/CD. 

   1.  I risultati finali includono criteri di successo, convalide e aspetti da monitorare. 

1.  Seleziona gli strumenti per la gestione della configurazione in base ai requisiti aziendali e alla pipeline di distribuzione. 

1.  Per modifiche significative alla configurazione, prendi in considerazione le implementazioni ponderate, ad esempio le implementazioni canary, per ridurre al minimo l'impatto di configurazioni errate. 

1.  Integra la gestione della configurazione nella tua pipeline CI/CD. 

1.  Convalida tutte le modifiche inserite. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) 
+  [OPS06-BP02 Implementazioni dei test](ops_mit_deploy_risks_test_val_chg.md) 
+  [OPS06-BP03 Utilizza strategie di deployment sicure](ops_mit_deploy_risks_deploy_mgmt_sys.md) 
+  [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documenti correlati:** 
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Landing Zone Accelerator ](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [ What is AWS Config? ](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+  [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 
+ [ What is AWS CloudFormation? ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+  [Strumenti per sviluppatori in AWS](https://aws.amazon.com/products/developer-tools/) 

 **Video correlati:** 
+ [AWS re:Invent 2022 - Proactive governance and compliance for AWS workloads ](https://youtu.be/PpUnH9Y52X0?si=82wff87KHXcc6nbT)
+ [AWS re:Invent 2020: Achieve compliance as code using AWS Config](https://youtu.be/m8vTwvbzOfw?si=my4DP0FLq1zwKjho)
+ [ Manage and Deploy Application Configurations with AWS AppConfig](https://youtu.be/ztIxMY3IIu0?si=ovYGsxWOBysyQrg0)

# OPS05-BP04 Utilizzo di sistemi di gestione della compilazione e implementazione
<a name="ops_dev_integ_build_mgmt_sys"></a>

 Utilizza sistemi di gestione della creazione e distribuzione Questi sistemi riducono gli errori causati dai processi manuali e il livello di impegno richiesto per la distribuzione delle modifiche. 

 In AWS, puoi compilare pipeline di integrazione continua/implementazione continua (CI/CD) utilizzando servizi come gli [Strumenti per sviluppatori in AWS](https://aws.amazon.com/products/developer-tools/) (ad esempio, AWS CodeCommit, [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodePipeline](https://aws.amazon.com/codepipeline/), [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)e [AWS CodeStar](https://aws.amazon.com/codestar/)). 

 **Risultato desiderato:** I sistemi di gestione della costruzione e dell'implementazione supportano il sistema di distribuzione e integrazione continua (CI/CD) dell'organizzazione, che fornisce funzionalità per automatizzare rollout sicuri con le configurazioni corrette. 

 **Anti-pattern comuni:** 
+  Dopo aver compilato il codice nel sistema di sviluppo, copi il file eseguibile nei sistemi di produzione e questo non si avvia. I file di log locali indicano che l'operazione è risultata impossibile a causa della mancanza di dipendenze. 
+  Hai creato l'applicazione con nuove funzionalità nel tuo ambiente di sviluppo e fornisci il codice per eseguire il controllo qualità (QA). Il controllo qualità non riesce perché mancano asset statici. 
+  Venerdì, dopo un notevole sforzo, hai creato l'applicazione manualmente nel tuo ambiente di sviluppo, incluse le nuove funzionalità codificate. Lunedì non sei in grado di ripetere le fasi che ti hanno consentito di creare correttamente la tua applicazione. 
+  Esegui i test creati per la nuova versione. Quindi passi la settimana successiva a configurare un ambiente di test ed eseguire tutti i test di integrazione esistenti seguiti dai test delle prestazioni. Il nuovo codice ha un impatto inaccettabile sulle prestazioni e deve essere risviluppato e quindi ritestato. 

 **Vantaggi dell'adozione di questa best practice:** Fornendo meccanismi per gestire le attività di compilazione e distribuzione, riduci il livello di impegno necessario per eseguire attività ripetitive, consenti ai membri del team di concentrarsi liberamente sulle loro attività creative di valore elevato e limiti l'introduzione di errori derivanti da procedure manuali. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I sistemi di gestione della creazione e implementazione vengono utilizzati per tenere traccia e implementare le modifiche, ridurre gli errori causati dai processi manuali e diminuire il livello di impegno richiesto per le implementazioni sicure. Automatizza completamente la pipeline di integrazione e distribuzione dal check-in del codice fino alle fasi di creazione, test, distribuzione e convalida. Ciò riduce il lead time e i costi, incoraggia una maggiore frequenza delle modifiche, riduce il livello di impegno e aumenta la collaborazione. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

![\[Diagramma che mostra una pipeline CI/CD che utilizza AWS CodePipeline e servizi correlati\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deployment-pipeline-tooling.png)


 

1.  Utilizza AWS CodeCommit per verificare la versione, archiviare e gestire risorse come documenti, codice sorgente e file binari. 

1.  Utilizza CodeBuild per compilare il codice sorgente, eseguire test delle unità e produrre artefatti pronti per l'implementazione. 

1.  Utilizza CodeDeploy come servizio di implementazione per automatizzare l'implementazione delle applicazioni su istanze [Amazon EC2](https://aws.amazon.com/ec2/) , istanze on-premise, [funzioni AWS Lambda serverless](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)o [Amazon ECS](https://aws.amazon.com/ecs/). 

1.  Monitora le tue implementazioni. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documenti correlati:** 
+  [Strumenti per sviluppatori in AWS](https://aws.amazon.com/products/developer-tools/) 
+ [ Che cos'è AWS CodeCommit? ](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
+  [Che cos'è AWS CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/)
+  [Che cos'è AWS CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 

 **Video correlati:** 
+ [AWS re:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS](https://youtu.be/hfXokRAyorA)

# OPS05-BP05 Esecuzione della gestione delle patch
<a name="ops_dev_integ_patch_mgmt"></a>

 La gestione delle patch consente di ottenere funzionalità, risolvere problemi e rispettare i requisiti di governance. Automatizza la gestione delle patch per ridurre gli errori causati dai processi manuali, dimensionare e ridurre il livello di impegno richiesto per applicare le patch. 

 La gestione delle patch e delle vulnerabilità fa parte delle attività di gestione dei rischi e dei vantaggi. È preferibile disporre di infrastrutture immutabili e distribuire carichi di lavoro in stati noti verificati. Se ciò non è realizzabile, l'applicazione di patch sul posto è l'alternativa. 

 [Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) fornisce pipeline per l'aggiornamento di immagini AMI. Come parte della gestione delle patch, prendi in considerazione l'utilizzo di [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html       ) (AMI) con una [pipeline di immagini AMI](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html) o immagini del container con una [pipeline di immagini Docker](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html). Inoltre, puoi utilizzare AWS Lambda, che fornisce modelli per [runtime personalizzati e librerie aggiuntive](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html) per eliminare le vulnerabilità. 

 È consigliabile gestire gli aggiornamenti alle [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) per immagini Linux o Windows Server utilizzando [Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/). Puoi utilizzare [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) con la pipeline esistente per gestire le immagini Amazon ECS ed Amazon EKS. Lambda include [funzionalità di gestione delle versioni](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html). 

 L'applicazione di patch non deve essere eseguita sui sistemi di produzione senza prima eseguire test in un ambiente sicuro. Le patch devono essere applicate solo se supportano risultati operativi o aziendali. In AWS, è possibile utilizzare [Gestione patch di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) per automatizzare il processo di applicazione di patch ai sistemi gestiti e pianificare l'attività utilizzando le [finestre di manutenzione di Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html). 

 **Risultato desiderato:** Le immagini AMI e dei container sono aggiornate, dotate di patch e pronte per il lancio. È possibile tenere traccia dello stato di tutte le immagini implementate e conoscere la conformità delle patch. Puoi eseguire report sullo stato attuale e disporre di un processo per soddisfare le tue esigenze di conformità. 

 **Anti-pattern comuni:** 
+  Ti viene assegnato il compito di applicare tutte le nuove patch di sicurezza entro 2 ore, il che provoca più interruzioni a causa dell'incompatibilità dell'applicazione con le patch. 
+  Una libreria senza patch comporta conseguenze indesiderate in quanto parti sconosciute utilizzano vulnerabilità al suo interno per accedere al carico di lavoro. 
+  L'applicazione di patch agli ambienti per sviluppatori viene eseguita automaticamente senza avvisare gli sviluppatori. Gli sviluppatori ti inviano più reclami perché il loro ambiente non funziona come previsto. 
+  Non hai applicato patch al software pronto all'uso commerciale su un'istanza persistente. Quando hai problemi con il software e contatti il fornitore, questo ti informa che la versione non è supportata e che devi applicare le patch a un livello specifico per ricevere assistenza. 
+  Una patch rilasciata di recente per il software di crittografia utilizzato offre miglioramenti significativi in termini di prestazioni. Il sistema privo di patch presenta problemi di prestazioni che rimangono in vigore a causa della mancata applicazione di patch. 
+  Ricevi una notifica di una vulnerabilità zero-day che richiede una correzione di emergenza; quindi devi applicare manualmente le patch a tutti i tuoi ambienti. 

 **Vantaggi dell'adozione di questa best practice:** Stabilendo un processo di gestione delle patch, inclusi i criteri per l'applicazione di patch e la metodologia di distribuzione tra gli ambienti, sarai in grado di dimensionare e generare report sui livelli di patch. Ciò fornisce garanzie sull'applicazione delle patch di sicurezza e una chiara visibilità sullo stato delle correzioni note in atto. Ciò incoraggia l'adozione delle caratteristiche e funzionalità desiderate, aiuta a eliminare rapidamente i problemi e a mantenere la conformità alla governance. Implementa sistemi di gestione delle patch e automazione per ridurre il livello di impegno per distribuire le patch e limitare gli errori causati dai processi manuali. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Applica patch ai sistemi per correggere gli errori, ottenere le funzionalità o le capacità desiderate e assicurare la conformità alle policy di governance e ai requisiti di supporto del vendor. Nei sistemi immutabili, distribuisci con il set di patch appropriato per raggiungere il risultato desiderato. Automatizza il meccanismo di gestione delle patch per ridurre il tempo necessario per applicare le patch, evitare gli errori causati dai processi manuali e diminuire il livello di impegno richiesto per applicare le patch. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Per Amazon EC2 Image Builder: 

1.  specifica i dettagli della pipeline utilizzando Amazon EC2 Image Builder: 

   1.  Crea una pipeline di immagini e assegnale un nome 

   1.  Definisci la pianificazione e il fuso orario della pipeline 

   1.  Configura eventuali dipendenze 

1.  Scegli una ricetta: 

   1.  Seleziona una ricetta esistente o creane una nuova 

   1.  Seleziona il tipo di immagine 

   1.  Assegna un nome e una versione alla tua ricetta 

   1.  Seleziona l'immagine di base 

   1.  Aggiungi componenti di compilazione e inseriscili nel registro di destinazione 

1.  Facoltativo: definisci la configurazione dell'infrastruttura. 

1.  Facoltativo: definisci le impostazioni di configurazione. 

1.  Revisiona le impostazioni. 

1.  Mantieni il livello di igiene delle ricette a livelli ottimali. 

 Per Gestione patch di Systems Manager: 

1.  Crea una patch di base. 

1.  Seleziona un metodo per le operazioni di definizione del percorso. 

1.  Abilita il report e la scansione della conformità. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documenti correlati:** 
+ [ What is Amazon EC2 Image Builder ](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html)
+ [ Create an image pipeline using the Amazon EC2 Image Builder ](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)
+ [ Create a container image pipeline ](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html)
+  [Gestione patch di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
+ [ Working with Patch Manager ](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-console.html)
+ [ Working with patch compliance reports ](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-compliance-reports.html)
+ [ Strumenti per sviluppatori in AWS](https://aws.amazon.com/products/developer-tools)

 **Video correlati:** 
+  [CI/CD per applicazioni serverless su AWS](https://www.youtube.com/watch?v=tEpx5VaW4WE) 
+  [Progettare nell'ottica Ops](https://youtu.be/uh19jfW7hw4) 

   **Esempi correlati:** 
+ [ Well-Architected Labs: Inventario e gestione delle patch ](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management)
+ [AWS Systems Manager Patch Manager tutorials ](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-tutorials.html)

# OPS05-BP06 Condivisione degli standard di progettazione
<a name="ops_dev_integ_share_design_stds"></a>

 Condividi le best practice con i team per incrementare la consapevolezza e potenziare al massimo i vantaggi delle attività di sviluppo. Documentale e mantienile aggiornate di pari passo con l'evoluzione dell'architettura. Se nella tua organizzazione vengono applicati standard condivisi, è fondamentale che esistano meccanismi per richiedere aggiunte, modifiche ed eccezioni agli standard. Senza questa opzione, gli standard diventano un ostacolo per l'innovazione. 

 **Risultato desiderato:** Gli standard di progettazione vengono condivisi fra team nelle organizzazioni. Vengono documentati e tenuti aggiornati in base all'evoluzione delle best practice. 

 **Anti-pattern comuni:** 
+ Due team di sviluppo hanno creato ciascuno un servizio di autenticazione utente. Gli utenti devono mantenere un set separato di credenziali per ogni parte del sistema a cui vogliono accedere. 
+ Ogni team gestisce la propria infrastruttura. Un nuovo requisito di conformità impone una modifica all'infrastruttura e ogni team la implementa in modo diverso.

 **Vantaggi dell'adozione di questa best practice:** L'uso di standard condivisi incoraggia l'applicazione di best practice e permette di ottenere i massimi vantaggi dalle attività di sviluppo. La documentazione e l'aggiornamento degli standard di progettazione tengono l'organizzazione al passo con le best practice e i requisiti di sicurezza e conformità. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Condividi le best practice, gli standard di progettazione, gli elenchi di controllo, le procedure operative, le linee guida e i requisiti di governance esistenti tra team diversi. Definisci procedure per richiedere modifiche, aggiunte ed eccezioni agli standard di progettazione per supportare il miglioramento e l'innovazione. Rendi noto ai team il contenuto pubblicato. Predisponi un meccanismo per mantenere aggiornati gli standard di progettazione in base all'emergere di nuove best practice. 

 **Esempio del cliente** 

 AnyCompany Retail ha un team interfunzionale che crea modelli di architettura software. Questo team crea l'architettura con conformità e governance integrate. I team che adottano gli standard condivisi traggono vantaggio dall'integrazione di conformità e governance. Possono creare rapidamente soluzioni sulla base degli standard di progettazione. Il team responsabile dell'architettura si incontra ogni trimestre per valutare i modelli architetturali e aggiornarli, se necessario. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Identifica un team interfunzionale responsabile dello sviluppo e dell'aggiornamento degli standard di progettazione. Questo team collaborerà con gli stakeholder in tutta l'organizzazione per sviluppare standard di progettazione, procedure operative, elenchi di controllo, linee guida e requisiti di governance. Documenta gli standard di progettazione e condividili internamente all'organizzazione. 

   1.  [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) può aiutarti a creare portfolio che rappresentano gli standard di progettazione usando il modello Infrastruttura come codice (IaC). Puoi condividere portfolio tra più account. 

1.  Predisponi un meccanismo per mantenere aggiornati gli standard di progettazione man mano che vengono identificate nuove best practice. 

1.  Se gli standard di progettazione vengono applicati a livello centrale, definisci un processo per richiedere modifiche, aggiornamenti ed eccezioni. 

 **Livello di impegno per il piano di implementazione:** medio. Lo sviluppo di un processo per creare e condividere standard di progettazione può richiedere il coordinamento e la cooperazione con gli stakeholder in tutta l'organizzazione. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS01-BP03 Valutazione dei requisiti di governance](ops_priorities_governance_reqs.md) – I requisiti di governance influiscono sugli standard di progettazione. 
+  [OPS01-BP04 Valutazione dei requisiti di conformità](ops_priorities_compliance_reqs.md) – La conformità è un fattore essenziale nella creazione di standard di progettazione. 
+  [OPS07-BP02 Revisione costante della prontezza operativa](ops_ready_to_support_const_orr.md) – Gli elenchi di controllo della prontezza operativa sono un meccanismo per implementare standard di progettazione durante la progettazione del carico di lavoro. 
+  [OPS11-BP01 Definizione di un processo per il miglioramento continuo](ops_evolve_ops_process_cont_imp.md) – L'aggiornamento degli standard di progettazione contribuisce a un miglioramento continuo. 
+  [OPS11-BP04 Gestione delle informazioni](ops_evolve_ops_knowledge_management.md) – Nell’ambito della procedura di gestione delle informazioni, documenta e condividi gli standard di progettazione. 

 **Documenti correlati:** 
+ [ Automate AWS Backups with AWS Service Catalog](https://aws.amazon.com/blogs/mt/automate-aws-backups-with-aws-service-catalog/)
+ [AWS Service Catalog Account Factory-Enhanced ](https://aws.amazon.com/blogs/mt/aws-service-catalog-account-factory-enhanced/)
+ [ Expedia Group crea un'offerta Database as a Service (DBaaS) usando il AWS Service Catalog](https://aws.amazon.com/blogs/mt/how-expedia-group-built-database-as-a-service-dbaas-offering-using-aws-service-catalog/)
+ [ Mantenimento della visibilità sull'uso di modelli architetturali cloud ](https://aws.amazon.com/blogs/architecture/maintain-visibility-over-the-use-of-cloud-architecture-patterns/)
+ [ Simplify sharing your AWS Service Catalog portfolios in an AWS Organizations setup ](https://aws.amazon.com/blogs/mt/simplify-sharing-your-aws-service-catalog-portfolios-in-an-aws-organizations-setup/)

 **Video correlati:** 
+ [AWS Service Catalog – Getting Started ](https://www.youtube.com/watch?v=A9kKy6WhqVA)
+ [AWS re:Invent 2020: Manage your AWS Service Catalog portfolios like an expert ](https://www.youtube.com/watch?v=lVfXkWHAtR8)

 **Esempi correlati:** 
+ [AWS Service Catalog Reference Architecture ](https://github.com/aws-samples/aws-service-catalog-reference-architectures)
+ [AWS Service Catalog Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/d40750d7-a330-49be-9945-cde864610de9/en-US)

 **Servizi correlati:** 
+  [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) 

# OPS05-BP07 Implementazione di prassi per migliorare la qualità del codice
<a name="ops_dev_integ_code_quality"></a>

Implementa prassi per migliorare la qualità del codice e ridurre al minimo i difetti. Alcuni esempi includono sviluppo basato su test, revisioni del codice, adozione degli standard e programmazione in coppia. Inserisci queste prassi nel processo di integrazione continua e distribuzione continua. 

 **Risultato desiderato:** L'organizzazione usa best practice come le revisioni del codice e la programmazione in coppia per migliorare la qualità del codice. Sviluppatori e operatori adottano le best practice per la qualità del codice nell'ambito del ciclo di vita di sviluppo del software. 

 **Anti-pattern comuni:** 
+ Commit del codice nel ramo principale dell'applicazione senza alcuna revisione. In questo modo, la modifica viene automaticamente implementata nell'ambiente di produzione e causa un'interruzione.
+  Sviluppo di una nuova applicazione senza unit test, test end-to-end o test di integrazione. Non è possibile in alcun modo testare l'applicazione prima dell'implementazione. 
+  I team apportano modifiche manuali nell'ambiente di produzione per gestire gli errori. Le modifiche non vengono sottoposte a test o revisioni del codice, né vengono acquisite o registrate durante i processi di integrazione continua e distribuzione continua. 

 **Vantaggi dell'adozione di questa best practice:** L'adozione di pratiche per migliorare la qualità del codice ti consente di ridurre al minimo i problemi di produzione. La qualità del codice aumenta se vengono usate best practice come la programmazione in coppia e le revisioni del codice. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Implementa prassi per migliorare la qualità del codice in modo da ridurre gli errori prima dell'implementazione. Usa prassi come lo sviluppo basato su test, le revisioni del codice e la programmazione in coppia per migliorare la qualità dello sviluppo. 

 **Esempio del cliente** 

 AnyCompany Retail adotta diverse prassi per migliorare la qualità del codice. L'azienda ha adottato lo sviluppo basato su test come standard per la scrittura di applicazioni. Per alcune nuove funzionalità, gli sviluppatori eseguono la programmazione in coppia durante uno sprint. Ogni richiesta pull viene sottoposta a una revisione del codice da parte di uno sviluppatore senior prima di essere integrata e implementata. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Adotta prassi per la qualità del codice come lo sviluppo basato su test, le revisioni del codice e la programmazione in coppia nel processo di integrazione continua e distribuzione continua. Usa queste tecniche per migliorare la qualità del software. 

   1.  [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) può fornire suggerimenti di programmazione per il codice Java e Python tramite il machine learning. 

   1.  Con [AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) puoi creare ambienti di sviluppo condivisi nei quali collaborare allo sviluppo del codice. 

 **Livello di impegno per il piano di implementazione:** medio. Esistono molti modi per implementare questa best practice, ma la realizzazione dell'adozione da parte dell'organizzazione può essere problematica. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS05-BP06 Condivisione degli standard di progettazione](ops_dev_integ_share_design_stds.md) - Puoi condividere gli standard di progettazione nell'ambito della prassi per la qualità del codice. 

 **Documenti correlati:** 
+ [ Agile Software Guide ](https://martinfowler.com/agile.html)
+ [La mia pipeline CI/CD è la mia release captain](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [ Automazione delle revisioni del codice con il Amazon CodeGuru Reviewer ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [ Adotta un approccio allo sviluppo basato sul test ](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [ DevFactory crea applicazioni migliori con Amazon CodeGuru ](https://aws.amazon.com/blogs/machine-learning/how-devfactory-builds-better-applications-with-amazon-codeguru/)
+ [ On Pair Programming ](https://martinfowler.com/articles/on-pair-programming.html)
+ [ RENGA Inc. automatizza le revisioni del codice con Amazon CodeGuru ](https://aws.amazon.com/blogs/machine-learning/renga-inc-automates-code-reviews-with-amazon-codeguru/)
+ [ The Art of Agile Development: Test-Driven Development ](http://www.jamesshore.com/v2/books/aoad1/test_driven_development)
+ [ Why code reviews matter (and actually save time\$1) ](https://www.atlassian.com/agile/software-development/code-reviews)

 **Video correlati:** 
+ [AWS re:Invent 2020: Continuous improvement of code quality with Amazon CodeGuru ](https://www.youtube.com/watch?v=iX1i35H1OVw)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development ](https://www.youtube.com/watch?v=1R7G_wcyd3s)

 **Servizi correlati:** 
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Amazon CodeGuru Profiler ](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+  [AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) 

# OPS05-BP08 Utilizzo di più ambienti
<a name="ops_dev_integ_multi_env"></a>

 Utilizza ambienti multipli per sperimentare, sviluppare e testare il carico di lavoro. Applica livelli crescenti di controlli man mano che gli ambienti si avvicinano alla fase di produzione per avere la certezza che il carico di lavoro funzioni come previsto una volta implementato. 

 **Risultato desiderato:** Disponi di più ambienti che riflettono le tue esigenze di conformità e governance. Testi e promuovi il codice negli ambienti lungo il tuo percorso verso la produzione. 

 **Anti-pattern comuni:** 
+  Stai sviluppando in un ambiente di sviluppo condiviso e un altro sviluppatore sovrascrive le tue modifiche al codice. 
+  I controlli di sicurezza restrittivi nell'ambiente di sviluppo condiviso impediscono di sperimentare nuovi servizi e funzionalità. 
+  Esegui test di carico sui tuoi sistemi di produzione e causa un'interruzione per i tuoi utenti. 
+  Si è verificato un errore critico che ha causato la perdita di dati nella produzione. Nel tuo ambiente di produzione tenti di ricreare le condizioni che portano alla perdita di dati in modo da poter identificare come si è verificata e impedire che si ripeta. Per evitare un'ulteriore perdita di dati durante il test, devi rendere l'applicazione non disponibile per i tuoi utenti. 
+  Stai operando un servizio multi-tenant e non sei in grado di supportare la richiesta di un cliente per un ambiente dedicato. 
+  Ogni volta che esegui un test, lo fai nel tuo ambiente di produzione. 
+  Ritieni che la semplicità di un singolo ambiente prevalga sulla portata dell'impatto che possono avere modifiche all'interno dell'ambiente. 

 **Vantaggi dell'adozione di questa best practice:** puoi supportare più ambienti di sviluppo, test e produzione simultanei senza creare conflitti tra sviluppatori o community di utenti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Utilizza più ambienti e fornisci agli sviluppatori ambienti di sperimentazione (sandbox) con controlli minimi per incoraggiare la sperimentazione. Fornisci ambienti di sviluppo individuali per facilitare il lavoro in parallelo, incrementando l'agilità dello sviluppo. Implementa controlli più rigorosi negli ambienti che si avvicinano alla produzione per consentire agli sviluppatori di innovare. Utilizza l'approccio Infrastructure-as-Code e sistemi di gestione delle configurazioni per distribuire ambienti configurati in modo coerente con i controlli presenti in produzione per assicurare che i sistemi funzionino nel modo previsto quando vengono distribuiti. Quando gli ambienti non vengono utilizzati, disattivali per evitare costi associati alle risorse inattive, ad esempio i sistemi di sviluppo nelle ore serali e nei fine settimana. Durante i test di carico, è necessario implementare ambienti equivalenti a quelli di produzione per migliorare la validità dei risultati. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Pianificatore di istanze su AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
+  [Che cos'è AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 

# OPS05-BP09 Applicazione di modifiche frequenti, minime e reversibili
<a name="ops_dev_integ_freq_sm_rev_chg"></a>

 Le modifiche frequenti, minime e reversibili riducono la portata e l'impatto di una modifica. Le modifiche frequenti, minime e reversibili, se effettuate utilizzando congiuntamente sistemi di gestione delle modifiche, di gestione della configurazione e di compilazione e distribuzione, riducono la portata e l'impatto di una modifica. Questo si traduce in una risoluzione dei problemi più efficace, accelerando la correzione e mantenendo la possibilità di rollback delle modifiche. 

 **Anti-pattern comuni:** 
+  Distribuisci una nuova versione della tua applicazione ogni trimestre con una finestra di modifica, il che comporta la disattivazione di un servizio di base. 
+  Spesso apporti modifiche allo schema del database senza che ne venga tenuta traccia nei sistemi di gestione. 
+  Esegui aggiornamenti manuali sul posto, sovrascrivendo le installazioni e le configurazioni esistenti, senza avere un chiaro piano di rollback. 

 **Vantaggi dell'adozione di questa best practice:** Le attività di sviluppo sono più rapide grazie all'implementazione frequente di modifiche minime. Quando le modifiche sono minime, è molto più semplice identificare se hanno conseguenze indesiderate e, in tal caso, ripristinare la condizione precedente. Quando le modifiche sono reversibili, il rischio di implementare le modifiche è minore in quanto il ripristino è semplificato. Il processo di modifica comporta un rischio ridotto e l'impatto di una modifica non corretta è ridotto. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Applica modifiche frequenti, minime e reversibili per ridurre la portata e l'impatto di una modifica. In questo modo si semplifica la risoluzione dei problemi, si velocizza la correzione ed è possibile eseguire il rollback di una modifica. Inoltre, aggiunge più rapidamente valore al business. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS05-BP03 Utilizzo di sistemi di gestione delle configurazioni](ops_dev_integ_conf_mgmt_sys.md) 
+  [OPS05-BP04 Utilizzo di sistemi di gestione della compilazione e implementazione](ops_dev_integ_build_mgmt_sys.md) 
+  [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documenti correlati:** 
+ [ Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Microservices - Observability ](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/observability.html)

# OPS05-BP10 Automazione completa dell'integrazione e della distribuzione
<a name="ops_dev_integ_auto_integ_deploy"></a>

 Automatizza la creazione, la distribuzione e il test del carico di lavoro. Questo riduce gli errori causati dai processi manuali e l'impegno necessario per distribuire le modifiche. 

 Applica i metadati utilizzando i [tag delle risorse](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) e [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html) seguendo una [strategia di applicazione dei tag](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) per agevolare l'identificazione delle risorse. Applica tag alle risorse per organizzare, monitorare i costi e controllare gli accessi e ottimizza l'esecuzione delle attività operative automatizzate. 

 **Risultato desiderato:** Chi si occupa di sviluppo utilizza strumenti per distribuire codice ed effettuare la promozione a produzione. Gli sviluppatori non devono effettuare il login alla Console di gestione AWS per fornire gli aggiornamenti. Esiste un audit trail completo di modifiche e configurazioni che soddisfa le esigenze di governance e conformità. I processi sono ripetibili e standardizzati tra i team. Gli sviluppatori sono liberi di concentrarsi sullo sviluppo e sui rilasci del codice, aumentando la produttività. 

 **Anti-pattern comuni:** 
+  Venerdì termini la creazione del nuovo codice per il ramo delle funzionalità. Lunedì, dopo aver eseguito gli script di test di qualità del codice e tutti gli script dei test di unità, effettui il check-in del codice per il prossimo rilascio programmato. 
+  Ti verrà assegnato di codificare una correzione per un problema critico che interessa un numero elevato di clienti nella produzione. Dopo aver testato la correzione, esegui il commit del codice e richiedi via e-mail alla gestione delle modifiche l'approvazione per implementarlo in produzione. 
+  In qualità di sviluppatore, accedi alla Console di gestione AWS per creare un nuovo ambiente di sviluppo utilizzando metodi e sistemi non standard. 

 **Vantaggi dell'adozione di questa best practice:** Implementando sistemi di gestione automatizzati di compilazione e implementazione, si riduce il numero di errori causati dai processi manuali e lo sforzo di distribuire le modifiche aiutando i membri del team a concentrarsi sull'offerta di valore aggiunto. Maggiore velocità di consegna man mano che procedi verso la promozione a produzione. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Utilizza i sistemi di gestione della compilazione e implementazione per tenere traccia e implementare le modifiche, ridurre gli errori causati dai processi manuali e ridurre il livello di impegno richiesto. Automatizza completamente la pipeline di integrazione e distribuzione dal check-in del codice fino alle fasi di creazione, test, distribuzione e convalida. In questo modo è possibile diminuire il lead time, incoraggiare una maggiore frequenza di modifica, ridurre il livello di impegno e accelerare il time-to-market, il che si traduce in una maggiore produttività e in un aumento della sicurezza del codice man mano che procedi con la promozione verso la produzione. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS05-BP03 Utilizzo di sistemi di gestione delle configurazioni](ops_dev_integ_conf_mgmt_sys.md) 
+  [OPS05-BP04 Utilizzo di sistemi di gestione della compilazione e implementazione](ops_dev_integ_build_mgmt_sys.md) 

 **Documenti correlati:** 
+  [Che cos'è AWS CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
+  [Che cos'è AWS CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 

 **Video correlati:** 
+ [AWS re\$1:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS](https://youtu.be/hfXokRAyorA)

# OPS 6. In che modo mitighi i rischi della distribuzione?
<a name="ops-06"></a>

 Adotta prassi per fornire un feedback rapido sulla qualità e che permettano un ripristino veloce dalle modifiche che non hanno i risultati previsti. L'uso di queste prassi consente di mitigare l'impatto dei problemi introdotti attraverso la distribuzione delle modifiche. 

**Topics**
+ [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Implementazioni dei test](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 Utilizza strategie di deployment sicure](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)

# OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche
<a name="ops_mit_deploy_risks_plan_for_unsucessful_changes"></a>

Pianifica il ripristino di uno stato corretto noto o la correzione nell'ambiente di produzione nel caso in cui l'implementazione generi un risultato indesiderato. Disporre di una politica per stabilire un piano di questo tipo aiuta tutti i team a sviluppare strategie di ripristino dalle modifiche con esito negativo. Alcune strategie di esempio sono le fasi di deployment e rollback, le politiche di modifica, i flag di funzionalità, l'isolamento del traffico e lo spostamento del traffico. Una singola release può includere più modifiche ai componenti correlati. La strategia dovrebbe fornire la capacità di resistere o ripristinare in caso di guasto generato da qualsiasi modifica dei componenti.

 **Risultato desiderato:** hai preparato un piano di ripristino dettagliato per la modifica in caso di fallimento. Inoltre, hai ridotto le dimensioni della release per ridurre al minimo il potenziale impatto su altri componenti del carico di lavoro. Di conseguenza, hai ridotto l'impatto aziendale abbreviando i potenziali tempi di inattività causati da una modifica non riuscita e aumentando la flessibilità e l'efficienza dei tempi di ripristino. 

 **Anti-pattern comuni:** 
+  Hai eseguito un deployment e l'applicazione è diventata instabile, ma sembra che ci siano utenti attivi sul sistema. Devi decidere se eseguire il rollback della modifica e influire sugli utenti attivi o aspettare di eseguire il rollback della modifica, sapendo che gli utenti potranno essere comunque influenzati. 
+  Dopo aver apportato una modifica di routine, i nuovi ambienti sono accessibili, ma una delle sottoreti è diventata irraggiungibile. Devi decidere se eseguire il rollback di tutto o provare a correggere il problema della sottorete inaccessibile. Mentre prendi tale decisione, la sottorete rimane irraggiungibile. 
+  I tuoi sistemi non sono progettati in modo da consentire loro di essere aggiornati con release più piccole. Di conseguenza, è difficile annullare tali modifiche di massa (bulk changes) durante un deployment conclusosi con esito negativo. 
+  Non utilizzi l'Infrastruttura come codice (IaC) e hai apportato aggiornamenti manuali all'infrastruttura che hanno portato a configurazioni indesiderate. Non è possibile tracciare e ripristinare in modo efficace le modifiche manuali. 
+  Poiché non hai misurato l'aumento della frequenza dei deployment, il tuo team non è incentivato a ridurre le dimensioni delle modifiche e a migliorare i piani di rollback per ogni modifica, con conseguente aumento dei rischi e dei tassi di fallimento. 
+  Non misura la durata totale di un'interruzione causata da modifiche con esito negativo. Il tuo team non è in grado di stabilire le priorità e migliorare il processo di deployment e l'efficacia del piano di ripristino. 

 **Vantaggi dell'adozione di questa best practice:** Avere un piano per il ripristino dopo le modifiche non riuscite riduce al minimo il tempo medio di ripristino (MTTR) e riduce l'impatto sull'azienda. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Una politica e una pratica coerenti e documentate adottate dai team di rilascio consentono a un'organizzazione di pianificare cosa dovrebbe succedere in caso di modifiche con esito negativo. In circostanze specifiche la politica dovrebbe consentire la possibilità di apportare correzioni per garantire la prosecuzione del processo. In entrambe le situazioni, un piano di correzione (fix forward) o ripristino (rollback) deve essere ben documentato e testato prima dell'implementazione nei sistemi di produzione live, in modo da ridurre al minimo il tempo necessario per ripristinare una modifica. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Documenta le politiche che richiedono ai team di disporre di piani efficaci per invertire le modifiche entro un periodo di tempo specificato. 

   1.  Le politiche devono specificare quando è consentita una situazione di applicazione di correzioni per garantire la prosecuzione del processo. 

   1.  Richiedi un piano di rollback documentato che sia accessibile a tutti i soggetti coinvolti. 

   1.  Specifica i requisiti per il rollback (ad esempio, quando si rileva che sono state implementate modifiche non autorizzate). 

1.  Analizza il livello di impatto di tutte le modifiche relative a ciascun componente di un carico di lavoro. 

   1.  Consenti che le modifiche ripetibili siano standardizzate, basate su modelli e preautorizzate se seguono un flusso di lavoro coerente che applica le politiche di modifica. 

   1.  Riduci il potenziale impatto di qualsiasi modifica riducendone le dimensioni, in modo che il ripristino richieda meno tempo e abbia un impatto minore sulle attività aziendali. 

   1.  Assicurati che le procedure di rollback riportino il codice allo stato corretto noto per evitare incidenti, ove possibile. 

1.  Integra strumenti e flussi di lavoro per applicare le tue politiche in modo programmatico. 

1.  Rendi visibili i dati sulle modifiche agli altri responsabili di carichi di lavoro per migliorare la velocità di diagnosi di eventuali modifiche con esito negativo che non possono essere ripristinate. 

   1.  Misura il successo di questa pratica utilizzando dati di modifica visibili e identifica miglioramenti iterativi. 

1.  Utilizza gli strumenti di monitoraggio per verificare il successo o il fallimento di un deployment per accelerare il processo decisionale sul rollback. 

1.  Misura la durata dell'interruzione durante una modifica con esito negativo per migliorare continuamente i tuoi piani di ripristino. 

 **Livello di impegno per il piano di implementazione:** Medio 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md) 

 **Documenti correlati:** 
+ [AWS Builders Library \$1 Ensuring Rollback Safety During Deployments ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS Whitepaper \$1 Change Management in the Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)

 **Video correlati:** 
+ [ re:Invent 2019 \$1 Amazon’s approach to high-availability deployment ](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)

# OPS06-BP02 Implementazioni dei test
<a name="ops_mit_deploy_risks_test_val_chg"></a>

 Testa le procedure di rilascio in pre-produzione utilizzando la stessa configurazione di deployment, i controlli di sicurezza, i passaggi e le procedure utilizzati nell'ambiente di produzione. Verifica che tutte le fasi implementate siano state completate come previsto, ad esempio l'ispezione di file, configurazioni e servizi. Verifica ulteriormente tutte le modifiche con test funzionali, di integrazione e di carico, oltre ad attivare tutte le attività di monitoraggio come i controlli dell'integrità. Eseguendo questi test, è possibile identificare tempestivamente i problemi di deployment con l'opportunità di pianificarli e mitigarli prima del passaggio nell'ambiente di produzione. 

 Puoi creare ambienti paralleli temporanei per testare ogni modifica. Automatizza il deployment degli ambienti di test utilizzando l'Infrastruttura come codice (IaC) per ridurre la quantità di lavoro necessaria e garantire stabilità, coerenza e una distribuzione più rapida delle funzionalità. 

 **Risultato desiderato:** La tua organizzazione adotta una cultura di sviluppo che include il test delle implementazioni. Ciò garantisce che i team siano concentrati sulla realizzazione di valore aziendale anziché sulla gestione delle release. I team vengono coinvolti fin dall'identificazione dei rischi di deployment per determinare il percorso di mitigazione appropriato. 

 **Anti-pattern comuni:** 
+  Durante le release di produzione, le implementazioni non testate causano problemi frequenti che richiedono una risoluzione mirata e l'escalation. 
+  La tua release contiene porzioni di Infrastruttura come codice (IaC) che aggiornano le risorse esistenti. Non sei sicuro che l'IaC funzionerà correttamente e non avrà un impatto sulle risorse. 
+  Viene implementata una nuova funzionalità interessante nella tua applicazione. Non funziona come previsto e non c'è visibilità finché non viene segnalata dagli utenti interessati. 
+  I certificati vengono aggiornati. Si installano accidentalmente i certificati sui componenti sbagliati, il che non viene rilevato e influisce sui visitatori poiché non è possibile stabilire una connessione sicura al sito web. 

 **Vantaggi dell'adozione di questa best practice:** Test approfonditi in fase di pre-produzione delle procedure di implementazione e delle modifiche da queste introdotte riducono al minimo il potenziale impatto sulla produzione causato dalle fasi di implementazione. Ciò aumenta la fiducia durante il rilascio in produzione e riduce al minimo la necessità di supporto operativo senza rallentare la velocità di distribuzione delle modifiche apportate. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Testare il processo di deployment è importante quanto testare le modifiche derivanti dal deployment. Ciò può essere ottenuto testando le fasi di deployment in un ambiente di pre-produzione che rispecchi il più fedelmente possibile quello di produzione. I problemi più comuni, come fasi di deployment incomplete o contenenti errori o configurazioni errate, possono essere individuati di conseguenza prima di passare all'ambiente di produzione. Inoltre, è possibile testare le fasi di ripristino. 

 **Esempio del cliente** 

 Nell'ambito della sua pipeline di integrazione continua e distribuzione continua (CI/CD), AnyCompany Retail esegue i passaggi definiti necessari per rilasciare aggiornamenti dell'infrastruttura e del software per i propri clienti in un ambiente simile a quello di produzione. La pipeline comprende controlli preliminari per rilevare il “drift” (il rilevamento delle modifiche alle risorse eseguite al di fuori dell'IaC) nelle risorse prima del deployment, nonché per convalidare le azioni che l'IaC intraprende al suo avvio. Convalida le fasi di deployment, ad esempio la verifica che determinati file e configurazioni siano presenti e che i servizi siano in esecuzione e rispondano correttamente ai controlli di integrità sull'host locale, prima di effettuare nuovamente la registrazione sul sistema di bilanciamento del carico. Inoltre, tutte le modifiche attivano una serie di test automatici, come test funzionali, di sicurezza, di regressione, di integrazione e di carico. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Esegui controlli di pre-installazione per rispecchiare l'ambiente di pre-produzione in produzione. 

   1.  utilizza [il rilevamento della deviazione](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) per rilevare quando le risorse sono state modificate all'esterno di CloudFormation. 

   1.  utilizza [i set di modifiche](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) per verificare che l'intento dell'aggiornamento dello stack corrisponda alle azioni intraprese da CloudFormation quando viene avviato il set di modifiche. 

1.  Ciò attiva una fase di approvazione manuale in [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) per autorizzare l'implementazione nell'ambiente di preproduzione. 

1.  Utilizza configurazioni di implementazione come [file AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html) per definire le fasi di implementazione e convalida. 

1.  Ove applicabile, [integra AWS CodeDeploy con altri servizi AWS](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) o [integra AWS CodeDeploy con prodotti e servizi dei partner](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html). 

1.  [Monitora le implementazioni](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) usando le notifiche di eventi Amazon CloudWatch, AWS CloudTrail e Amazon SNS. 

1.  Esegui test automatici post-deployment, inclusi test funzionali, di sicurezza, di regressione, di integrazione e di carico. 

1.  [Risoluzione dei problemi](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) di implementazione. 

1.  La corretta convalida dei passaggi precedenti dovrebbe attivare un flusso di lavoro di approvazione manuale per autorizzare l'implementazione nell'ambiente di produzione. 

 **Livello di impegno per il piano di implementazione:** alto 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS05-BP02 Test e convalida delle modifiche](ops_dev_integ_test_val_chg.md) 

 **Documenti correlati:** 
+ [AWS Builders' Library \$1 Automating safe, hands-off deployments \$1 Test Deployments ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [AWS Whitepaper \$1 Practicing Continuous Integration and Continuous Delivery on AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [ The Story of Apollo - Amazon's Deployment Engine ](https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html)
+  [Come eseguire test e debug con AWS CodeDeploy in locale prima di distribuire il codice](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/) 
+ [ Integrating Network Connectivity Testing with Infrastructure Deployment ](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-network-connectivity-testing-with-infrastructure-deployment/)

 **Video correlati:** 
+ [ re:Invent 2020 \$1 Testing software and systems at Amazon ](https://www.youtube.com/watch?v=o1sc3cK9bMU)

 **Esempi correlati:** 
+ [ Tutorial \$1 Deploy and Amazon ECS service with a validation test ](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)

# OPS06-BP03 Utilizza strategie di deployment sicure
<a name="ops_mit_deploy_risks_deploy_mgmt_sys"></a>

 I roll-out sicuri della produzione controllano il flusso di modifiche vantaggiose con l'obiettivo di ridurre al minimo l'impatto percepito di tali modifiche sui clienti. I controlli di sicurezza forniscono meccanismi di ispezione per convalidare i risultati desiderati e limitare l'ambito di impatto derivante da eventuali difetti introdotti dalle modifiche o da errori di deployment. I roll-out sicuri possono includere strategie come feature-flags, one-box, roll-out (release canary), immutabili, suddivisioni del traffico e deployment blu/verdi. 

 **Risultato desiderato:** l'organizzazione utilizza un sistema di distribuzione e integrazione continua (CI/CD) che fornisce funzionalità per automatizzare roll-out sicuri. I team sono tenuti a utilizzare strategie di roll-out sicure appropriate. 

 **Anti-pattern comuni:** 
+  Distribuisci una modifica non riuscita a tutta la produzione contemporaneamente. Di conseguenza, tutti i clienti vengono colpiti contemporaneamente. 
+  Un difetto introdotto in un deployment simultaneo su tutti i sistemi richiede una release di emergenza. La correzione per tutti i clienti richiede diversi giorni. 
+  La gestione della release di produzione richiede la pianificazione e la partecipazione di diversi team. Ciò limita la tua capacità di aggiornare frequentemente le funzionalità per i tuoi clienti. 
+  Esegui un deployment variabile modificando i sistemi esistenti. Dopo aver scoperto che la modifica non è andata a buon fine, devi modificare nuovamente i sistemi per ripristinare la versione precedente estendendo il tempo di ripristino. 

 **Vantaggi dell'adozione di questa best practice:** Le implementazioni automatizzate bilanciano la velocità dei roll-out con la fornitura costante di modifiche vantaggiose per i clienti. La limitazione dell'impatto previene costosi errori di deployment e massimizza la capacità dei team di rispondere in modo efficiente ai guasti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Gli errori della distribuzione continua possono portare a una ridotta disponibilità del servizio e a esperienze dei clienti negative. Per massimizzare il tasso di deployment di successo, implementa i controlli di sicurezza nel processo di rilascio end-to-end per ridurre al minimo gli errori di deployment, con l'obiettivo di raggiungere il traguardo di zero errori. 

 **Esempio del cliente** 

 La missione di AnyCompany Retail è raggiungere deployment con tempi di inattività minimi o pari a zero, il che significa che non vi deve essere alcun impatto percepibile dagli utenti durante i deployment. A tal fine, l'azienda ha stabilito modelli di deployment (vedere il seguente diagramma del flusso di lavoro) come roll-out e deployment blu/verdi. Tutti i team adottano uno o più di questi modelli nella loro pipeline CI/CD. 


| flusso di lavoro CodeDeploy per Amazon EC2 | flusso di lavoro CodeDeploy per Amazon ECS | flusso di lavoro CodeDeploy per Lambda | 
| --- | --- | --- | 
|  ![\[Flusso del processo di implementazione per Amazon EC2\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deployment-process-ec2.png)  |  ![\[Flusso del processo di implementazione per Amazon ECS\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deployment-process-ecs.png)  |  ![\[Flusso del processo di implementazione per Lambda\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deployment-process-lambda.png)  | 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Utilizza un flusso di lavoro di approvazione per avviare la sequenza delle fasi di roll-out della produzione al momento della promozione alla produzione. 

1.  Utilizza un sistema di implementazione automatizzato come [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html). AWS CodeDeploy [opzioni di implementazione](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html) include le implementazioni locali (in-place) per EC2/on-premise e le implementazioni blu/verdi per EC2/on-premise AWS Lambda e Amazon ECS (vedi il diagramma del flusso di lavoro precedente). 

   1.  Ove applicabile, [integra AWS CodeDeploy con altri servizi AWS](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) o [integra AWS CodeDeploy con prodotti e servizi dei partner](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html). 

1.  Utilizza implementazioni blu/verdi per database come [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) e [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html). 

1.  [Monitora le implementazioni](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) usando le notifiche di eventi Amazon CloudWatch, AWS CloudTrail e Amazon SNS. 

1.  Esegui test automatici post-implementazione, inclusi test funzionali, di sicurezza, di regressione, di integrazione e di carico. 

1.  [Risoluzione dei problemi](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) di implementazione. 

 **Livello di impegno per il piano di implementazione:** Medio 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS05-BP02 Test e convalida delle modifiche](ops_dev_integ_test_val_chg.md) 
+  [OPS05-BP09 Applicazione di modifiche frequenti, minime e reversibili](ops_dev_integ_freq_sm_rev_chg.md) 
+  [OPS05-BP10 Automazione completa dell'integrazione e della distribuzione](ops_dev_integ_auto_integ_deploy.md) 

 **Documenti correlati:** 
+ [AWS Builders Library \$1 Automating safe, hands-off deployments \$1 Production deployments ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS Builders Library \$1 My CI/CD pipeline is my release captain \$1 Safe, automatic production releases](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [AWS Whitepaper \$1 Practicing Continuous Integration and Continuous Delivery on AWS \$1 Deployment methods](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [Guida per l'utente di AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [Utilizzo di configurazioni di distribuzione in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [Configurazione della distribuzione di una release Canary di API Gateway ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Amazon ECS Deployment Types](https://docs.aws.amazon.com/)
+ [Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS](https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/)
+ [Distribuzioni blu/verde con AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)

 **Video correlati:** 
+ [re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon's Approach to high-availability deployment](https://www.youtube.com/watch?v=bCgD2bX1LI4)

 **Esempi correlati:** 
+ [Prova un'implementazione blu/verde di esempio in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [Workshop \$1 Buiding CI/CD pipelines for Lambda canary deployments using AWS CDK](https://catalog.us-east-1.prod.workshops.aws/workshops/5195ab7c-5ded-4ee2-a1c5-775300717f42/en-US)
+ [Workshop \$1 Blue/Green and Canary Deployment for EKS and ECS](https://catalog.us-east-1.prod.workshops.aws/workshops/2175d94a-cd79-4ed2-8e7e-1f0dd1956a3a/en-US)
+ [Workshop \$1 Building a Cross-account CI/CD Pipeline](https://catalog.us-east-1.prod.workshops.aws/workshops/00bc829e-fd7c-4204-9da1-faea3cf8bd88/en-US)

# OPS06-BP04 Automazione dei test e del rollback
<a name="ops_mit_deploy_risks_auto_testing_and_rollback"></a>

 Per aumentare la velocità, l'affidabilità e la sicurezza del processo di deployment, rendi disponibile una strategia per le funzionalità di test e rollback automatizzate negli ambienti di pre-produzione e produzione. Automatizza i test durante il deployment in produzione per simulare le interazioni umane e di sistema che verificano le modifiche implementate. Automatizza il rollback per tornare rapidamente allo stato precedente corretto noto. Il rollback deve essere avviato automaticamente in condizioni predefinite, ad esempio quando il risultato desiderato della modifica non viene raggiunto o quando il test automatico fallisce. L'automazione di queste due attività migliora la percentuale di successo dei deployment, riduce al minimo i tempi di ripristino e riduce il potenziale impatto sulle attività aziendali. 

 **Risultato desiderato:** I test automatici e le strategie di rollback sono integrati nella pipeline di integrazione continua e distribuzione continua (CI/CD). Il monitoraggio è in grado di eseguire la convalida in base ai criteri di successo e avviare il rollback automatico in caso di errore. Ciò riduce al minimo l'impatto sugli utenti finali e sui clienti. Ad esempio, quando tutti i risultati dei test sono stati soddisfatti, promuovi il codice nell'ambiente di produzione in cui vengono avviati i test di regressione automatizzati, sfruttando gli stessi casi di test. Se i risultati dei test di regressione non corrispondono alle aspettative, viene avviato il rollback automatico nel flusso di lavoro della pipeline. 

 **Anti-pattern comuni:** 
+  I tuoi sistemi non sono progettati in modo da consentire loro di essere aggiornati con release più piccole. Di conseguenza, è difficile annullare tali modifiche di massa (bulk changes) durante un deployment conclusosi con esito negativo. 
+  Il processo di deployment consiste in una serie di passaggi manuali. Dopo aver distribuito le modifiche al carico di lavoro, inizi i test post-deployment. Dopo il test, ti rendi conto che il tuo carico di lavoro è inutilizzabile e i clienti sono disconnessi. Inizi quindi a eseguire il rollback alla versione precedente. Tutti questi passaggi manuali ritardano il ripristino complessivo del sistema e provocano un impatto prolungato sui clienti. 
+  Hai impiegato del tempo a sviluppare casi di test automatizzati per funzionalità che non vengono utilizzate frequentemente nella tua applicazione, riducendo al minimo il ritorno sull'investimento nella tua capacità di eseguire test automatizzati. 
+  La versione è composta da applicazioni, infrastrutture, patch e aggiornamenti di configurazione indipendenti l'uno dall'altro. Tuttavia, è disponibile un'unica pipeline CI/CD che fornisce tutte le modifiche contemporaneamente. Un guasto in un componente obbliga a ripristinare tutte le modifiche, rendendo il rollback complesso e inefficiente. 
+  Il tuo team completa il lavoro di codifica nello sprint uno e inizia il lavoro dello sprint due, ma il tuo piano non includeva i test fino allo sprint tre. Come conseguenza, i test automatici hanno rivelato difetti dello sprint uno che dovevano essere risolti prima di poter avviare il test dei deliverable dello sprint due e l'intera release viene ritardata, rendendo inutili i test automatizzati. 
+  I casi di test di regressione automatizzati per la release di produzione sono completi, ma non stai monitorando lo stato del carico di lavoro. Poiché non è possibile verificare se il servizio è stato riavviato o meno, non sei sicuro se il rollback sia necessario o se sia già avvenuto. 

 **Vantaggi dell'adozione di questa best practice:** I test automatizzati aumentano la trasparenza del processo di verifica e la capacità di coprire più funzionalità in un periodo di tempo più breve. Testando e convalidando le modifiche nella produzione, è possibile identificare immediatamente i problemi. Il miglioramento della coerenza con strumenti di test automatizzati consente una migliore rilevazione dei difetti. Effettuando automaticamente il rollback alla versione precedente, l'impatto sui clienti viene ridotto al minimo. In ultima analisi, il rollback automatizzato ispira maggiore fiducia nelle capacità di deployment riducendo l'impatto sulle attività aziendali. Nel complesso, queste funzionalità riducono i tempi di consegna garantendo al contempo la qualità. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Automatizza i test degli ambienti distribuiti per verificare che i risultati siano quelli desiderati. Automatizza il rollback a uno stato corretto noto quando non vengono raggiunti i risultati previsti, per ridurre al minimo il tempo di ripristino e gli errori causati dai processi manuali. Integra gli strumenti di test con il flusso di lavoro della pipeline per testare in modo coerente e ridurre al minimo gli input manuali. Dai priorità all'automazione dei casi di test, come quelli che mitigano i rischi maggiori e devono essere testati frequentemente a ogni modifica. Inoltre, automatizza il rollback in base a condizioni specifiche predefinite nel tuo piano di test. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Stabilisci un ciclo di vita di test per il tuo ciclo di vita di sviluppo che definisca ogni fase del processo di test, dalla pianificazione dei requisiti allo sviluppo dei test case, alla configurazione degli strumenti, ai test automatizzati e alla chiusura dei test case. 

   1.  Crea un approccio di test specifico per il carico di lavoro partendo dalla tua strategia di test complessiva. 

   1.  Prendi in considerazione una strategia di test continuo, laddove appropriato, durante tutto il ciclo di vita dello sviluppo. 

1.  Seleziona strumenti automatizzati per il test e il rollback in base ai requisiti aziendali e agli investimenti nella pipeline. 

1.  Decidi quali casi di test desideri automatizzare e quali devono essere eseguiti manualmente. Questi possono essere definiti in base alla priorità del valore aziendale della funzionalità testata. Allinea tutti i membri del team su questo piano e verifica la responsabilità per l'esecuzione di test manuali. 

   1.  Applica le funzionalità di test automatico a casi di test specifici che è opportuno automatizzare, come i casi ripetibili o eseguiti di frequente, quelli che richiedono attività ripetitive o quelli che sono necessari per più configurazioni. 

   1.  Definisci gli script di automazione dei test e i criteri di successo nello strumento di automazione in modo da poter avviare l'automazione continua del flusso di lavoro quando casi specifici falliscono. 

   1.  Definisci criteri di errore specifici per il rollback automatico. 

1.  Dai priorità all'automazione dei test per ottenere risultati coerenti con lo sviluppo accurato e completo di casi di test in cui la complessità e l'interazione umana hanno un rischio maggiore di fallimento. 

1.  Integra i tuoi strumenti di test e rollback automatizzati nella tua pipeline CI/CD. 

   1.  Sviluppa criteri di successo chiari per le tue modifiche. 

   1.  Monitora e osserva per rilevare questi criteri e annullare automaticamente le modifiche quando vengono soddisfatti criteri di rollback specifici. 

1.  Esegui diversi tipi di test di produzione automatizzati, come: 

   1.  Test A/B, per mostrare i risultati rispetto alla versione corrente tra due gruppi di utenti di test. 

   1.  Test Canary, che consente di distribuire la modifica a un sottoinsieme di utenti prima di rilasciarla a tutti. 

   1.  Test con flag delle funzionalità, che consente di attivare e disattivare una singola funzionalità della nuova versione alla volta dall'esterno dell'applicazione, in modo che ogni nuova funzionalità possa essere convalidata una alla volta. 

   1.  Test di regressione, per verificare nuove funzionalità con componenti correlati esistenti. 

1.  Monitora gli aspetti operativi dell'applicazione, delle transazioni e delle interazioni con altre applicazioni e componenti. Sviluppa report per mostrare il successo delle modifiche in base al carico di lavoro in modo da poter identificare quali parti dell'automazione e del flusso di lavoro possono essere ulteriormente ottimizzate. 

   1.  Sviluppa report sui risultati dei test che ti aiutino a prendere decisioni rapide sull'opportunità o meno di richiamare o meno le procedure di rollback. 

   1.  Implementa una strategia che consenta il rollback automatico basato su condizioni di errore predefinite derivanti da uno o più metodi di test. 

1.  Sviluppa i tuoi casi di test automatizzati per consentire la riutilizzabilità in caso di modifiche ripetibili future. 

 **Livello di impegno per il piano di implementazione:** Medio 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) 
+  [OPS06-BP02 Implementazioni dei test](ops_mit_deploy_risks_test_val_chg.md) 

 **Documenti correlati:** 
+ [AWS Builders Library \$1 Ensuring rollback safety during deployments ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+  [Redeploy and rollback a deployment with AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html) 
+ [ 8 best practices when automating your deployments with AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)

 **Esempi correlati:** 
+ [ Serverless UI testing using Selenium, AWS Lambda, AWS Fargate, and AWS Developer Tools ](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)

 **Video correlati:** 
+ [ re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon ](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [ re:Invent 2019 \$1 Amazon's Approach to high-availability deployment ](https://www.youtube.com/watch?v=bCgD2bX1LI4)

# OPS 7. Come fai a sapere se hai tutto pronto per supportare un carico di lavoro?
<a name="ops-07"></a>

 Valuta la disponibilità operativa del carico di lavoro, dei processi e delle procedure, nonché del personale per comprendere i rischi operativi correlati al carico di lavoro. 

**Topics**
+ [OPS07-BP01 Verifica della capacità del personale](ops_ready_to_support_personnel_capability.md)
+ [OPS07-BP02 Revisione costante della prontezza operativa](ops_ready_to_support_const_orr.md)
+ [OPS07-BP03 Utilizzo di runbook per eseguire le procedure](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 Utilizzo dei playbook per analizzare i problemi](ops_ready_to_support_use_playbooks.md)
+ [OPS07-BP05 Adozione di decisioni informate per implementare sistemi e modifiche](ops_ready_to_support_informed_deploy_decisions.md)
+ [OPS07-BP06 Abilitazione dei piani di supporto per i carichi di lavoro di produzione](ops_ready_to_support_enable_support_plans.md)

# OPS07-BP01 Verifica della capacità del personale
<a name="ops_ready_to_support_personnel_capability"></a>

Predisponi un meccanismo per stabilire se possiedi il numero appropriato di risorse del personale qualificate per supportare il carico di lavoro. Le risorse devono essere state formate sulla piattaforma e sui servizi che costituiscono il tuo carico di lavoro. Fornisci loro le informazioni necessarie per eseguire il carico di lavoro. Devi avere a disposizione personale qualificato sufficiente per supportare il normale funzionamento del carico di lavoro e gestire gli eventuali incidenti. Predisponi personale sufficiente per la rotazione durante la reperibilità e le ferie per evitare motivi di frustrazione. 

 **Risultato desiderato:** 
+  Presenza di personale qualificato sufficiente per supportare il carico di lavoro nei momenti in cui è disponibile. 
+  Capacità di fornire al personale formazione sul software e sui servizi che costituiscono il carico di lavoro. 

 **Anti-pattern comuni:** 
+ Implementazione di un carico di lavoro senza membri del team qualificati per l'esecuzione della piattaforma e dei servizi in uso. 
+  Mancanza di personale sufficiente per supportare la reperibilità a rotazione o le richieste di permesso del personale. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Membri del team qualificati costituiscono un supporto efficace al carico di lavoro. 
+  Con un numero sufficiente di membri del team, puoi supportare il carico di lavoro e la reperibilità a rotazione, riducendo il rischio di frustrazione. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Verifica che sia disponibile personale qualificato sufficiente per supportare il carico di lavoro. Assicurati che il numero di membri del team di cui disponi sia sufficiente a coprire le normali attività operative, inclusa la reperibilità a rotazione. 

 **Esempio del cliente** 

 AnyCompany Retail si assicura che i team che supportano il carico di lavoro includano personale qualificato sufficiente. L'azienda ha al suo interno un numero sufficiente di tecnici per supportare la reperibilità a rotazione. Il personale riceve formazione sul software e sulla piattaforma su cui è basato il carico di lavoro e viene incoraggiato a conseguire certificazioni. Vi è personale sufficiente per permettere alle persone di richiedere permessi di assenza, continuando a supportare il carico di lavoro durante la reperibilità a rotazione. 

 **Passaggi dell'implementazione** 

1.  Assegna un numero adeguato di risorse del personale per eseguire e supportare il carico di lavoro, tenendo conto della reperibilità. 

1.  Forma il personale sul software e sulle piattaforme che costituiscono il carico di lavoro. 

   1.  [AWS Training and Certification](https://aws.amazon.com/training/) offre una raccolta di corsi su AWS. Sono disponibili corsi gratuiti e a pagamento, online e di persona. 

   1.  [AWS organizza eventi e webinar](https://aws.amazon.com/events/) in cui puoi apprendere da esperti AWS. 

1.  Valuta regolarmente le dimensioni e le competenze del team in base al mutare delle condizioni operative e del carico di lavoro. Adegua le dimensioni e le competenze del team ai requisiti operativi. 

 **Livello di impegno per il piano di implementazione:** elevato L'assunzione e la formazione di un team per supportare il carico di lavoro possono richiedere un impegno significativo, ma assicurano solidi vantaggi a lungo termine. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS11-BP04 Gestione delle informazioni](ops_evolve_ops_knowledge_management.md) – I membri del team devono disporre delle informazioni necessarie per eseguire e supportare il carico di lavoro. La gestione delle informazioni è il fattore chiave a questo scopo. 

 **Documenti correlati:** 
+  [Eventi e webinar AWS](https://aws.amazon.com/events/) 
+  [AWS Training and Certification](https://aws.amazon.com/training/) 

# OPS07-BP02 Revisione costante della prontezza operativa
<a name="ops_ready_to_support_const_orr"></a>

Usa le revisioni della prontezza operativa (ORR) per verificare che puoi utilizzare il carico di lavoro. ORR è un meccanismo sviluppato da Amazon per verificare che i team possano utilizzare in sicurezza i propri carichi di lavoro. ORR è un processo di revisione e ispezione che utilizza un elenco di controllo per i requisiti. È un'esperienza self-service che i team utilizzano per certificare i propri carichi di lavoro. Le ORR includono le best practice delle lezioni apprese durante gli anni dedicati alla creazione di software. 

 Un elenco di controllo ORR è composto da suggerimenti sull'architettura, processo operativo, gestione degli eventi e qualità del rilascio. Il nostro processo di correzione dell'errore (CoE, Correction of Error) è uno dei principali fattori trainanti di questi elementi. L'analisi post-incidente deve guidare l'evoluzione della ORR. Una ORR non riguarda solo l'adozione delle best practice, ma anche la prevenzione del ripetersi di eventi già visti. Infine, in una ORR possono essere inclusi anche i requisiti di sicurezza, governance e conformità. 

 Esegui le ORR prima che un carico di lavoro venga lanciato nella disponibilità generale e quindi durante tutto il ciclo di vita dello sviluppo software. L'esecuzione della ORR prima del lancio aumenta la tua capacità di utilizzare il carico di lavoro in sicurezza. Riesegui periodicamente la ORR sul carico di lavoro per cogliere eventuali scostamenti dalle best practice. Puoi usare gli elenchi di controllo ORR per il lancio di nuovi servizi e le ORR per le revisioni periodiche. In tal modo puoi tenerti aggiornato sulle nuove best practice che emergono e incorporare le lezioni apprese dall'analisi post-incidente. Man mano che l'utilizzo del cloud cresce, puoi creare i requisiti di ORR nella tua architettura come valori predefiniti. 

 **Risultato desiderato:**  hai un elenco di controllo ORR con le best practice per la tua organizzazione. Le ORR vengono eseguite prima dell'avvio dei carichi di lavoro. Le ORR vengono eseguite periodicamente nel corso del ciclo di vita del carico di lavoro. 

 **Anti-pattern comuni:** 
+ Avvii un carico di lavoro senza sapere se puoi utilizzarlo. 
+ I requisiti di governance e sicurezza non sono inclusi nella certificazione di un carico di lavoro per l'avvio. 
+ I carichi di lavoro non vengono rivalutati periodicamente. 
+ I carichi di lavoro vengono avviati senza le procedure richieste. 
+ Si osserva la ripetizione di errori con la stessa causa principale in più carichi di lavoro. 

 **Vantaggi dell'adozione di questa best practice:** 
+  I tuoi carichi di lavoro includono le best practice di architettura, processo e gestione. 
+  Le lezioni apprese sono incorporate nel processo ORR. 
+  Le procedure richieste sono in atto all'avvio dei carichi di lavoro. 
+  Le ORR vengono eseguite durante l'intero ciclo di vita del software dei carichi di lavoro. 

 **Livello di rischio se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Una ORR è composta da un processo e un elenco di controllo. Il processo ORR deve essere adottato dall'organizzazione e supportato da uno sponsor esecutivo. Come minimo, le ORR devono essere eseguite prima che il carico di lavoro venga lanciato nella disponibilità generale. Esegui la ORR durante tutto il ciclo di vita dello sviluppo software per mantenerlo aggiornato con le best practice o i nuovi requisiti. L'elenco di controllo ORR deve includere elementi di configurazione, requisiti di sicurezza e governance e best practice dell'organizzazione. Nel tempo, puoi utilizzare i servizi, come [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html), [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)e [AWS Control Tower Guardrails](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)per creare le best practice dalla ORR nei guardrail per il rilevamento automatico delle best practice. 

 **Esempio del cliente** 

 Dopo diversi incidenti di produzione, AnyCompany Retail ha deciso di implementare un processo ORR. Ha creato un elenco di controllo composto da best practice, requisiti di governance e conformità e lezioni apprese dalle interruzioni. I nuovi carichi di lavoro conducono le ORR prima dell'avvio. Ogni carico di lavoro esegue una ORR annuale con un sottoinsieme di best practice per incorporare nuove best practice e requisiti che vengono aggiunti all'elenco di controllo ORR. Nel tempo, AnyCompany Retail ha utilizzato [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) per individuare le best practices, accelerando il processo ORR. 

 **Passaggi dell'implementazione** 

 Per ulteriori informazioni sulle ORR, consulta il [whitepaper Operational Readiness Reviews (ORR) (Revisioni della prontezza operativa (ORR))](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html). Fornisce informazioni dettagliate sulla cronologia del processo ORR, su come creare la procedura ORR e su come sviluppare il proprio elenco di controllo ORR. I passaggi seguenti costituiscono una versione abbreviata di quel documento. Per una comprensione approfondita di cosa sono le ORR e di come crearne una, ti consigliamo di leggere il whitepaper. 

1. Riunisci gli stakeholder importanti, inclusi i rappresentanti della sicurezza, delle operazioni e dello sviluppo. 

1. Chiedi a ogni stakeholder di indicare almeno un requisito. Per la prima iterazione, prova a limitare il numero di elementi a trenta al massimo. 
   +  [Appendix B: Example ORR questions (Appendice B: Domande ORR di esempio)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) del whitepaper Operational Readiness Reviews (ORR) (Revisioni della prontezza operativa (ORR)) contiene domande di esempio che puoi utilizzare per iniziare. 

1. Raccogli i tuoi requisiti in un foglio di calcolo. 
   + Puoi utilizzare [gli obiettivi personalizzati](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) nella funzione [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) per sviluppare la ORR e condividerla tra i tuoi account e l'organizzazione AWS. 

1. Identifica un carico di lavoro su cui condurre la ORR. L'ideale è un carico di lavoro pre-lancio o un carico di lavoro interno. 

1. Scorri l'elenco di controllo ORR e prendi nota di tutti i rilevamenti fatti. I rilevamenti potrebbero non essere validi se è in atto una mitigazione. Aggiungi qualsiasi rilevamento privo di mitigazione al tuo backlog di elementi e implementalo prima del lancio. 

1. Continua ad aggiungere le best practice e i requisiti all'elenco di controllo ORR nel corso del tempo. 

 I clienti di Supporto con supporto Enterprise possono richiedere il [workshop Operational Readiness Review (Revisione sulla prontezza operativa)](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) al proprio Technical Account Manager (TAM). Il workshop è una sessione interattiva *di lavoro a ritroso* per sviluppare il tuo elenco di controllo ORR. 

 **Livello di impegno per il piano di implementazione:** alto. L'adozione di una procedura ORR nella tua organizzazione richiede la sponsorizzazione dell'esecutivo e l'adesione degli stakeholder. Crea e aggiorna l'elenco di controllo con input provenienti da tutta l'organizzazione. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [OPS01-BP03 Valutazione dei requisiti di governance](ops_priorities_governance_reqs.md) - I requisiti di governance sono una scelta naturale per un elenco di controllo ORR. 
+ [OPS01-BP04 Valutazione dei requisiti di conformità](ops_priorities_compliance_reqs.md) - I requisiti di conformità sono talvolta inclusi in un elenco di controllo ORR. Altre volte costituiscono un processo separato. 
+ [OPS03-BP07 Fornitura di risorse appropriate ai team](ops_org_culture_team_res_appro.md) - La capacità del team è un buon requisito ORR. 
+ [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) - Prima di avviare il carico di lavoro, è necessario stabilire un piano di rollback o rollforward. 
+ [OPS07-BP01 Verifica della capacità del personale](ops_ready_to_support_personnel_capability.md) - Per supportare un carico di lavoro è necessario disporre del personale necessario. 
+ [SEC01-BP03 Identificazione e convalida degli obiettivi di controllo](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) - Gli obiettivi di controllo della sicurezza costituiscono eccellenti requisiti ORR. 
+ [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) - I piani di ripristino di emergenza sono un buon requisito ORR. 
+ [COST02-BP01 Sviluppo di politiche basate sui requisiti dell'organizzazione](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) - Le policy di gestione dei costi sono utili da includere nell'elenco di controllo ORR. 

 **Documenti correlati:** 
+  [AWS Control Tower - Guardrails in AWS Control Tower (Guardrail in AWS Control Tower)](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 
+  [AWS Well-Architected Tool - Custom Lenses (Obiettivi personalizzati)](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) 
+  [Operational Readiness Review Template by Adrian Hornsby (Modello di revisione della prontezza operativa di Adrian Hornsby)](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79) 
+  [Whitepaper Operational Readiness Reviews (ORR) (Revisioni della prontezza operativa (ORR))](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 

 **Video correlati:** 
+  [Supporto AWSs You \$1 Building an Effective Operational Readiness Review (ORR) (AWS ti supporta \$1 Creazione di un'efficace revisione della prontezza operativa (ORR))](https://www.youtube.com/watch?v=Keo6zWMQqS8) 

 **Esempi correlati:** 
+  [Sample Operational Readiness Review (ORR) Lens (Esempio di obiettivi per la revisione della prontezza operativa (ORR))](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens) 

 **Servizi correlati:** 
+  [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 
+  [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 
+  [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html) 

# OPS07-BP03 Utilizzo di runbook per eseguire le procedure
<a name="ops_ready_to_support_use_runbooks"></a>

 Un *runbook* è un processo documentato finalizzato al raggiungimento di un determinato risultato. I runbook sono composti da una serie di passaggi che è necessario eseguire per conseguire un obiettivo. L'uso dei runbook può essere fatto risalire agli albori dell'aviazione. Nelle operazioni cloud, è possibile utilizzare i runbook per ridurre i rischi e ottenere i risultati desiderati. In estrema sintesi, un runbook è un elenco di controllo da seguire per completare un'attività. 

 I runbook costituiscono una parte essenziale del funzionamento dei carichi di lavoro. Dall'inserimento di un nuovo membro in un team all'implementazione di una versione principale, i runbook sono processi codificati che garantiscono risultati coerenti indipendentemente da chi li utilizza. I runbook devono essere pubblicati a livello centralizzato e aggiornati in base all'evoluzione del processo. L'aggiornamento dei runbook rappresenta infatti un elemento chiave dell'intero processo di gestione delle modifiche. Devono inoltre includere le linee guida relative a gestione degli errori, strumenti, autorizzazioni, eccezioni ed escalation in caso di problemi. 

 A mano a mano che l'organizzazione cresce, è consigliabile automatizzare i runbook. Inizia con runbook concisi e di frequente utilizzo. Utilizza un linguaggio di scripting per automatizzare le procedure o semplificarne l'esecuzione. Dopo aver automatizzato i primi runbook, potrai dedicare altro tempo all'automazione dei runbook più complessi. Gradualmente dovrai automatizzare la maggior parte dei runbook. 

 **Risultato desiderato:** il team dispone di una raccolta di linee guida dettagliate per l'esecuzione delle attività relative ai carichi di lavoro. I runbook contengono il risultato desiderato, gli strumenti e le autorizzazioni necessari e le istruzioni per la gestione degli errori. Vengono archiviati in una posizione centralizzata e aggiornati di frequente. 

 **Anti-pattern comuni:** 
+  Ricorso alla memoria per completare i singoli passaggi di un processo. 
+  Implementazione manuale delle modifiche senza utilizzare un elenco di controllo. 
+  Vari membri dei team eseguono lo stesso processo con procedure o risultati diversi. 
+  Mancato aggiornamento dei runbook in base alle modifiche o ai processi di automazione del sistema. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Riduzione della percentuale degli errori per le attività manuali. 
+  Le operazioni vengono eseguite in modo coerente. 
+  I nuovi membri dei team possono essere operativi da subito. 
+  I runbook possono essere automatizzati per semplificare le operazioni più impegnative. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I runbook possono avere vari formati, a seconda del livello di "maturità" dell'organizzazione. Nella loro formulazione minima, devono essere un documento di testo in cui sono dettagliate le procedure. Il risultato desiderato deve essere indicato in modo chiaro e preciso. Devono inoltre documentare in modo chiaro le autorizzazioni e gli strumenti speciali necessari. Devono includere linee guida dettagliate relative alle gestione degli errori e ai livelli di escalation nel caso in cui si verifichino problemi o errori. I runbook devono riportare il nome del proprietario ed essere pubblicati in una posizione centralizzata. Dopo averlo compilato, un runbook deve essere convalidato. A tale scopo, devi far eseguire il runbook da un membro diverso del tuo team. A mano a mano che la procedura si evolve, aggiorna i runbook in base al processo di gestione delle modifiche. 

 I runbook in formato testuale devono essere automatizzati a seconda dell'evoluzione dell'organizzazione. Utilizzando servizi come [Automazioni AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), puoi trasformare un testo non formattato in automazioni che possono essere eseguite nell'ambito di un carico di lavoro. Queste automazioni possono essere eseguite in risposta a eventi, per ridurre il carico operativo a salvaguardia del carico di lavoro. 

 **Esempio del cliente** 

 AnyCompany Retail deve eseguire aggiornamenti dello schema del database durante le implementazioni del software. Il team responsabile delle operazioni cloud ha lavorato assieme al team addetto all'amministrazione del database per redigere un runbook per l'implementazione manuale di queste modifiche. Nel runbook sono incluse le procedure dettagliate sotto forma di elenco di controllo. È presente anche una sezione sulla gestione degli errori in caso di problemi. Il runbook è stato pubblicato assieme ad altri runbook sul wiki interno. Il team responsabile delle operazioni cloud pensa di pianificare l'automazione del runbook in futuro. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Se non è presente un repository di documenti, è consigliabile creare una libreria di runbook utilizzando un repository per il controllo delle versioni. Puoi creare i runbook utilizzando Markdown. Di seguito è riportato un modello di runbook di esempio che è possibile utilizzare come riferimento per la creazione dei runbook. 

```
# Titolo runbook ## Informazioni runbook | ID runbook | Descrizione | Strumenti utilizzati | Autorizzazioni speciali | Autore runbook | Data ultimo aggiornamento | POC escalation | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | Argomento runbook Risultato desiderato | Strumenti | Autorizzazioni | Nome e cognome | 21-09-2022 | Nome escalation | ## Passaggi 1. Passaggio 1 2. Passaggio 2
```

1.  Se non disponi di un repository o di un wiki per la documentazione, crea un repository per il controllo delle versioni nel sistema di controllo delle versioni in uso. 

1.  Individua un processo che non ha un runbook. Un processo ideale è un processo eseguito a cadenza più o meno regolare, con un numero limitato di passaggi e con errori a basso impatto. 

1.  Nel repository di documenti, crea una nuova bozza di documento Markdown utilizzando il modello. Compila il campo `Titolo runbook` e i campi obbligatori nell'area `Informazioni runbook`. 

1.  Partendo dal primo passaggio, compila l'area `Passaggi` del runbook. 

1.  Associa il runbook a un membro del team. Chiedi a tale membro di utilizzare il runbook per convalidare i passaggi. In caso di informazioni mancanti o poca chiarezza, aggiorna il runbook. 

1.  Pubblica il runbook nell'archivio della documentazione interna. Comunica l'avvenuta pubblicazione al team e alle altre parti interessate. 

1.  In questo modo, nel corso del tempo creerai una libreria di runbook. A mano a mano che la libreria cresce, comincia a pensare di automatizzare i runbook. 

 **Livello di impegno per il piano di implementazione:** basso Lo standard minimo previsto per i runbook è una guida dettagliata in formato testo. L'automazione dei runbook può aumentare l'impegno a livello di implementazione. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md): i runbook devono avere un proprietario responsabile della loro manutenzione. 
+  [OPS07-BP04 Utilizzo dei playbook per analizzare i problemi](ops_ready_to_support_use_playbooks.md): i runbook e i playbook sono pressoché simili, con un'unica differenza, ovvero in un runbook è previsto un risultato desiderato. In molti casi, i runbook vengono attivati dopo che un playbook ha individuato una causa principale. 
+  [OPS10-BP01 Utilizzo di un processo per la gestione di eventi, incidenti e problemi](ops_event_response_event_incident_problem_process.md): i runbook costituiscono una best practice per la gestione di eventi, incidenti e problemi. 
+  [OPS10-BP02 Definizione di un processo per ogni avviso](ops_event_response_process_per_alert.md): i runbook e i playbook devono essere utilizzati in risposta agli avvisi. Nel corso del tempo queste reazioni devono essere automatizzate. 
+  [OPS11-BP04 Gestione delle informazioni](ops_evolve_ops_knowledge_management.md): la gestione dei runbook è un elemento fondamentale della gestione delle conoscenze. 

 **Documenti correlati:** 
+ [Achieving Operational Excellence using automated playbook and runbook (Eccellenza operativa mediante playbook e runbook automatizzati)](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/) 
+ [AWS Systems Manager: Working with runbooks (AWS Systems Manager: Utilizzo dei runbook)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 
+ [Migration playbook for AWS large migrations - Task 4: Improving your migration runbooks (Playbook per la migrazione per migrazioni AWS di grandi dimensioni - Attività 4: Ottimizzazione dei runbook per la migrazione)](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html) 
+ [Use AWS Systems Manager Automation runbooks to resolve operational tasks (Utilizzo dei runbook di Automazione AWS Systems Manager per la risoluzione delle attività operative)](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/) 

 **Video correlati:** 
+  [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1) (Guida fai da te per runbook, report e risposte relativi agli incidenti [SEC318-R1])](https://www.youtube.com/watch?v=E1NaYN_fJUo) 
+  [How to automate IT Operations on AWS \$1 Amazon Web Services (Procedure di automazione delle operazioni IT in AWS \$1 Amazon Web Services)](https://www.youtube.com/watch?v=GuWj_mlyTug) 
+  [Integrate Scripts into AWS Systems Manager (Integrazione di script in AWS Systems Manager)](https://www.youtube.com/watch?v=Seh1RbnF-uE) 

 **Esempi correlati:** 
+  [AWS Systems Manager: Automation walkthroughs (Procedure di automazione dettagliate)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html) 
+  [AWS Systems Manager: Restore a root volume from the latest snapshot runbook (Runbook per il ripristino di un volume root volume dallo snapshot più recente)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+  [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake (Creazione di un runbook per le risposte agli incidenti AWS mediante notebook Jupyter e data lake CloudTrail)](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US) 
+  [Gitlab - Runbooks (Runbook)](https://gitlab.com/gitlab-com/runbooks) 
+  [Rubix - A Python library for building runbooks in Jupyter Notebooks (Rubix - Libreria Python per la creazione di runbook in notebook Jupyter)](https://github.com/Nurtch/rubix) 
+  [Using Document Builder to create a custom runbook (Utilizzo di Document Builder per creare un runbook personalizzato)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html) 
+  [Well-Architected Labs: Automating operations with Playbooks and Runbooks (Automazione delle operazioni con playbook e runbook)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

 **Servizi correlati:** 
+  [AWS Systems Manager Automation (Automazione AWS Systems Manager)](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 

# OPS07-BP04 Utilizzo dei playbook per analizzare i problemi
<a name="ops_ready_to_support_use_playbooks"></a>

 I playbook sono guide dettagliate che vengono utilizzate quando si verificano incidenti per analizzare, valutare l'impatto e identificare la causa principale del problema. I playbook sono utili in molti scenari diversi, dalle implementazioni non riuscite agli incidenti di sicurezza. In molti casi, i playbook identificano la causa principale che viene poi mitigata tramite un runbook. I playbook costituiscono un componente essenziale dei piani di risposta agli incidenti di ogni organizzazione. 

 Un buon playbook include diverse funzionalità chiave che guidano l'utente, passo dopo passo, nel processo di rilevamento. Ma quali passaggi deve eseguire l'utente per diagnosticare un incidente? Illustra chiaramente nel playbook se sono necessari strumenti speciali o autorizzazioni elevate. È essenziale predisporre un piano di comunicazione per aggiornare gli stakeholder sullo stato dell'analisi. Nelle situazioni in cui non è possibile identificare la causa principale, il playbook deve prevedere un piano di escalation. Se viene identificata la causa principale, il playbook deve includere il riferimento di un runbook che descrive come risolvere il problema. I playbook devono essere archiviati centralmente e aggiornati regolarmente. Se i playbook vengono utilizzati per avvisi specifici, fornisci al team i riferimenti dei playbook all'interno degli avvisi. 

 Man mano che l'organizzazione acquisisce maturità, puoi automatizzare i playbook. Inizia con i playbook che trattano incidenti a basso rischio. Utilizza gli script per automatizzare i passaggi di rilevamento. Assicurati di avere i relativi runbook per mitigare le cause principali più comuni. 

 **Risultato desiderato:** l'organizzazione dispone dei playbook per gli incidenti comuni. I playbook sono archiviati in una posizione centrale e disponibili per i membri del team. I playbook vengono aggiornati frequentemente. Per qualsiasi causa principale nota, vengono creati i relativi runbook. 

 **Anti-pattern comuni:** 
+  Non esiste un modo standard per analizzare un incidente. 
+  I membri del team confidano nella "memoria muscolare" o nelle conoscenze istituzionali per risolvere i problemi di un'implementazione non riuscita. 
+  I nuovi membri del team apprendono come analizzare i problemi attraverso tentativi ed errori. 
+  Le best practice per l'analisi dei problemi non sono condivise tra i team. 

 **Vantaggi dell'adozione di questa best practice:** 
+  I playbook rendono più efficaci le tue attività per mitigare gli incidenti. 
+  Uno stesso playbook può essere utilizzato da diversi membri del team in modo da identificare la causa principale in modo coerente. 
+  Le cause principali note possono già disporre di runbook appositamente sviluppati, accelerando i tempi di ripristino. 
+  I playbook accelerano la collaborazione tra i membri del team. 
+  I team possono applicare i processi su vasta scala tramite i playbook ripetibili. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Il modo in cui crei e utilizzi i playbook dipende dalla maturità della tua organizzazione. Se non hai familiarità con il cloud, crea i playbook in formato testo in un repository per i documenti centrale. Man mano che l'organizzazione acquisisce maturità, i playbook possono diventare semi automatizzati tramite script scritti in linguaggi come Python. Questi script possono essere eseguiti all'interno di un notebook Jupyter per accelerare il rilevamento. Le organizzazioni avanzate dispongono di playbook completamente automatizzati per i problemi comuni che vengono risolti automaticamente con i runbook. 

 Inizia a creare i playbook elencando gli incidenti comuni che si verificano nel tuo carico di lavoro. Scegli i playbook per gli incidenti a basso rischio e in cui la causa principale è riconducibile a pochi problemi. Una volta creati i playbook per gli scenari più semplici, passa agli scenari a rischio più elevato o in cui la causa principale non è ancora nota. 

 I playbook in formato testo vengono automatizzati man mano che l'organizzazione acquisisce maturità. Utilizzando servizi come [Automazione AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), il testo normale può essere trasformato in automazioni che possono essere eseguite sul carico di lavoro per accelerare le analisi. Queste automazioni possono essere attivate in risposta agli eventi, riducendo il tempo medio per rilevare e risolvere gli incidenti. 

 I clienti possono utilizzare [Strumento di gestione degli incidenti AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) per rispondere agli incidenti. Questo servizio fornisce un'unica interfaccia per valutare gli incidenti, informare gli stakeholder circa il rilevamento e la mitigazione e collaborare per tutta la durata dell'incidente. Utilizza Automazione AWS Systems Manager per accelerare il rilevamento e il ripristino. 

 **Esempio del cliente** 

 Si è verificato un incidente che ha avuto un impatto sulla produzione della società AnyCompany Retail. L'ingegnere di turno utilizza un playbook per analizzare il problema e man mano che esegue i passaggi, mantiene aggiornati gli stakeholder indicati nel playbook. L'ingegnere identifica la causa principale come una race condition di un servizio di back-end. Utilizzando un runbook, l'ingegnere riavvia il servizio e riporta quindi AnyCompany Retail online. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Se non è già presente, è consigliabile creare un repository per i documenti con il controllo delle versioni per la libreria di playbook. Puoi creare i tuoi playbook utilizzando Markdown, che è compatibile con la maggior parte dei sistemi di automazione dei playbook. Se parti da zero, utilizza il seguente modello di playbook come esempio. 

```
# Titolo del playbook ## Informazioni sul playbook | ID playbook | Descrizione | Strumenti utilizzati | Autorizzazioni speciali | Autore del playbook | Ultimo aggiornamento | POC di escalation | Stakeholder | Piano di comunicazione | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | A cosa serve questo playbook? Per quale incidente viene utilizzato? | Strumenti | Autorizzazioni | Il tuo nome | 21-09-2022 | Nome dell'escalation | Nome dello stakeholder | Come vengono comunicati gli aggiornamenti durante l'analisi? | ## Passaggi 1. Passaggio 1 2. Passaggio 2
```

1.  Se non disponi di un repository o di un wiki per i documenti, crea nel sistema di controllo delle versioni in uso un nuovo repository con il controllo delle versioni per i tuoi playbook. 

1.  Identifica un problema comune che richieda un'analisi, vale a dire uno scenario in cui la causa principale è riconducibile a pochi problemi e la risoluzione è a basso rischio. 

1.  Utilizzando il modello Markdown, compila la sezione `Titolo del playbook` e i campi in `Informazioni sul playbook`. 

1.  Includi i passaggi per la risoluzione dei problemi. Illustra nel modo più chiaro possibile le azioni da eseguire o le aree da analizzare. 

1.  Chiedi a un membro del team di esaminare e convalidare il tuo playbook. Se manca un'informazione o è necessario un chiarimento, aggiorna il playbook. 

1.  Pubblica il tuo playbook nel repository per i documenti e informa il tuo team e tutti gli stakeholder. 

1.  Questa libreria diventerà sempre più ricca man mano che aggiungi altri playbook. Una volta che sono disponibili diversi playbook, inizia ad automatizzarli con strumenti come Automazione AWS Systems Manager per mantenere sincronizzati l'automazione e i playbook. 

 **Livello di impegno per il piano di implementazione:** basso. I playbook sono documenti di testo archiviati in una posizione centrale. Le organizzazioni che hanno acquisito maturità applicano l'automazione dei playbook. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md): i playbook devono avere un proprietario responsabile della manutenzione. 
+  [OPS07-BP03 Utilizzo di runbook per eseguire le procedure](ops_ready_to_support_use_runbooks.md): i runbook e i playbook sono praticamente simili con un'unica differenza, ovvero in un runbook è previsto un risultato desiderato. In molti casi, i runbook vengono utilizzati dopo che un playbook ha individuato la causa principale. 
+  [OPS10-BP01 Utilizzo di un processo per la gestione di eventi, incidenti e problemi](ops_event_response_event_incident_problem_process.md): i playbook costituiscono una best practice per la gestione di eventi, incidenti e problemi. 
+  [OPS10-BP02 Definizione di un processo per ogni avviso](ops_event_response_process_per_alert.md): i runbook e i playbook devono essere utilizzati in risposta agli avvisi. Nel corso del tempo queste reazioni devono essere automatizzate. 
+  [OPS11-BP04 Gestione delle informazioni](ops_evolve_ops_knowledge_management.md): la manutenzione dei playbook è un elemento chiave della gestione delle conoscenze. 

 **Documenti correlati:** 
+ [ Achieving Operational Excellence using automated playbook and runbook (Eccellenza operativa mediante playbook e runbook automatizzati) ](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+  [AWS Systems Manager: Utilizzo di runbook](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 
+ [ Use AWS Systems Manager Automation runbooks to resolve operational tasks (Utilizzo dei runbook di Automazione AWS Systems Manager per la risoluzione delle attività operative) ](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)

 **Video correlati:** 
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1) (Guida fai da te per runbook, report e risposte relativi agli incidenti (SEC318-R1)) ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [Strumento di gestione degli incidenti AWS Systems Manager - AWS Virtual Workshops (Workshop virtuali AWS) ](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [ Integrate Scripts into AWS Systems Manager (Integrazione di script in AWS Systems Manager) ](https://www.youtube.com/watch?v=Seh1RbnF-uE)

 **Esempi correlati:** 
+ [AWS Customer Playbook Framework (Framework di playbook del cliente AWS) ](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager: Automation walkthroughs (Procedure di automazione dettagliate) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [ Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake (Creazione di un runbook per le risposte agli incidenti AWS mediante notebook Jupyter e data lake CloudTrail) ](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [ Rubix - A Python library for building runbooks in Jupyter Notebooks (Rubix - Libreria Python per la creazione di runbook in notebook Jupyter) ](https://github.com/Nurtch/rubix)
+ [ Using Document Builder to create a custom runbook (Utilizzo di Document Builder per creare un runbook personalizzato) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [ Well-Architected Labs: Automating operations with Playbooks and Runbooks (Automazione delle operazioni con playbook e runbook) ](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [ Well-Architected Labs: Incident response playbook with Jupyter (Well-Architected Labs: playbook di risposta agli incidenti con Jupyter) ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)

 **Servizi correlati:** 
+ [ Automazione AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Strumento di gestione degli incidenti AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)

# OPS07-BP05 Adozione di decisioni informate per implementare sistemi e modifiche
<a name="ops_ready_to_support_informed_deploy_decisions"></a>

Predisponi processi per la gestione delle modifiche efficaci e infruttuose al carico di lavoro. Si definisce "pre-mortem" un esercizio in cui il team simula un errore per sviluppare strategie di mitigazione. Utilizza questo esercizio per prevedere errori e creare procedure ove opportuno. Valuta i vantaggi e i rischi dell'implementazione di modifiche nel carico di lavoro. Verifica che tutte le modifiche siano conformi ai requisiti di governance. 

 **Risultato desiderato:** 
+  Adozione di decisioni informate durante l'implementazione di modifiche nel carico di lavoro. 
+  Le modifiche sono conformi ai requisiti di governance. 

 **Anti-pattern comuni:** 
+ Implementazione di una modifica nel carico di lavoro senza un processo per la gestione di un'implementazione errata.
+ Applicazione di modifiche all'ambiente di produzione che non sono conformi ai requisiti di governance.
+ Implementazione di una nuova versione del carico di lavoro senza stabilire valori di riferimento per l'utilizzo delle risorse.

 **Vantaggi dell'adozione di questa best practice:** 
+  L'azienda è preparata all'effetto di modifiche infruttuose al carico di lavoro. 
+  Le modifiche apportate al carico di lavoro sono conformi ai criteri di governance. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Usa esercizi pre-mortem per sviluppare processi per la gestione di modifiche infruttuose. Documenta i processi di gestione delle modifiche infruttuose. Verifica che tutte le modifiche siano conformi ai requisiti di governance. Valuta i vantaggi e i rischi dell'implementazione di modifiche nel carico di lavoro. 

 **Esempio del cliente** 

 AnyCompany Retail svolge regolarmente esercizi pre-mortem per convalidare i propri processi di gestione delle modifiche infruttuose. L'azienda documenta i propri processi in un Wiki condiviso che aggiorna spesso. Tutte le modifiche sono conformi ai requisiti di governance. 

 **Passaggi dell'implementazione** 

1.  Prendi decisioni informate durante l'implementazione di modifiche nel carico di lavoro. Definisci ed esamina i criteri per un'implementazione corretta. Sviluppa scenari o criteri che attiverebbero il ripristino dello stato precedente a una modifica. Soppesa i vantaggi dell'implementazione di modifiche rispetto ai rischi di una modifica infruttuosa. 

1.  Verifica che tutte le modifiche siano conformi ai requisiti di governance. 

1.  Usa esercizi pre-mortem per pianificare la gestione delle modifiche infruttuose e documentare le strategie di mitigazione. Esegui un esercizio di simulazione di un'emergenza per modellare una modifica infruttuosa e convalidare le procedure di ripristino dello stato precedente. 

 **Livello di impegno per il piano di implementazione:** moderato. L'implementazione di una procedura di pre-mortem richiede il coordinamento e l'impegno degli stakeholder in tutta l'organizzazione 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS01-BP03 Valutazione dei requisiti di governance](ops_priorities_governance_reqs.md) – I requisiti di governance sono un fattore chiave per determinare se implementare una modifica. 
+  [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – Predisponi piani per mitigare un'implementazione non riuscita e usa esercizi di pre-mortem per convalidarli. 
+  [OPS06-BP02 Implementazioni dei test](ops_mit_deploy_risks_test_val_chg.md) – Ogni modifica software deve essere testata nel modo adeguato prima dell'implementazione per ridurre gli errori nell'ambiente di produzione. 
+  [OPS07-BP01 Verifica della capacità del personale](ops_ready_to_support_personnel_capability.md) – La presenza di personale qualificato sufficiente per supportare il carico di lavoro è essenziale per prendere una decisione informata riguardo all'implementazione di una modifica di sistema. 

 **Documenti correlati:** 
+ [Amazon Web Services: rischio e conformità](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [ Modello di responsabilità condivisa AWS](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [ Governance nel Cloud AWS: il giusto equilibrio tra agilità e sicurezza ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)

# OPS07-BP06 Abilitazione dei piani di supporto per i carichi di lavoro di produzione
<a name="ops_ready_to_support_enable_support_plans"></a>

 Abilita il supporto per qualsiasi software e servizio a cui si affida il tuo carico di lavoro di produzione. Seleziona un livello di supporto adeguato per soddisfare le esigenze di assistenza della produzione. I piani di supporto per queste dipendenze sono necessari nel caso si verifichi un'interruzione del servizio o un problema di software. Documenta i piani di supporto e come chiedere assistenza per tutti i servizi e i fornitori di software. Implementa meccanismi di verifica per controllare che i riferimenti del supporto siano aggiornati. 

 **Risultato desiderato:** 
+  Implementa piani di supporto per software e servizi a cui si affidano i carichi di lavoro di produzione. 
+  Scegli un piano di supporto adeguato in base alle esigenze di assistenza. 
+  Documenta i piani e i livelli di supporto e come richiedere assistenza. 

 **Anti-pattern comuni:** 
+  Non hai piani di supporto per un fornitore software strategico. Il tuo carico di lavoro è coinvolto e non puoi fare nulla per accelerare un intervento risolutivo o per ricevere aggiornamenti tempestivi dal fornitore. 
+  Uno sviluppatore, che era il punto di contatto primario di un fornitore di software, ha lasciato l'azienda. Non puoi contattare direttamente l'assistenza del fornitore. Devi investire il tuo tempo per cercare le informazioni e orientarti tra sistemi di contatto generici, aumentando così il livello di impegno richiesto per intervenire quando necessario. 
+  Si verifica un'interruzione della produzione con un fornitore di software. Non esiste una documentazione su come inserire una richiesta di assistenza. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Con il livello di supporto adeguato, puoi ottenere una risposta nei tempi previsti per soddisfare le esigenze in termini di livelli di servizio. 
+  In caso di problemi in produzione, puoi inoltrare il problema se sei un cliente assistito. 
+  Fornitori di software e servizi possono essere di aiuto per la risoluzione dei problemi durante un incidente. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Abilita i piani di supporto per qualsiasi fornitore di software e servizi a cui si affida il tuo carico di lavoro di produzione. Configura piani di supporto adeguati per soddisfare le esigenze di assistenza. Per i clienti AWS, questo significa abilitare il supporto Business di AWS o superiore su qualsiasi account su cui hai carichi di lavoro di produzione. Incontra con regolarità i fornitori del servizio di assistenza per ricevere aggiornamenti sulle offerte di supporto, sui processi e sui contatti. Documenta come richiedere assistenza ai fornitori di software e servizi, incluso come inoltrare il problema in caso si verificasse un'interruzione. Implementa meccanismi di aggiornamento dei contatti del supporto. 

 **Esempio del cliente** 

 In AnyCompany Retail, tutte le dipendenze di servizi e software commerciali hanno piani di supporto. Ad esempio, hanno il supporto Enterprise di AWS abilitato su tutti gli account con carichi di lavoro di produzione. In caso di problemi, qualsiasi sviluppatore può inserire una richiesta di assistenza. Esiste una pagina wiki con informazioni su come richiedere assistenza, chi contattare e quali best practice seguire per accelerare il processo di risoluzione. 

 **Passaggi dell'implementazione** 

1.  Lavora con le parti interessate all'interno della tua organizzazione per identificare i fornitori di software e servizi su cui si basa il tuo carico di lavoro. Documenta queste dipendenze. 

1.  Stabilisci le esigenze in termini di assistenza del tuo carico di lavoro. Seleziona un piano di supporto in linea con tali esigenze. 

1.  Per software e servizi commerciali definisci un piano di supporto con i fornitori. 

   1.  Sottoscrivere il supporto Business di AWS o un livello superiore per tutti gli account di produzione garantisce tempi di risposta più rapidi da Supporto AWS ed è una scelta fortemente consigliata. Se non hai il supporto premium, devi avere un piano di azione per gestire i problemi, che richiede l’aiuto di Supporto AWS. Supporto AWS offre un mix di strumenti e tecnologie, persone e programmi progettati per aiutarti in modo proattivo a ottimizzare le performance, ridurre i costi e innovare più rapidamente. Il supporto Business di AWS offre vantaggi aggiuntivi, tra cui l'accesso a AWS Trusted Advisor e ad AWS Personal Health Dashboard, nonché tempi di risposta più rapidi. 

1.  Documenta il tuo piano di supporto nello strumento di gestione delle conoscenze. Includi come richiedere assistenza, chi avvertire se viene inviata una richiesta di assistenza e come inoltrare il problema durante un incidente. Un wiki è un buon meccanismo che consente a tutti di apportare gli aggiornamenti necessari alla documentazione, nel momento in cui vengono a conoscenza di modifiche a processi o contatti del supporto. 

 **Livello di impegno per il piano di implementazione:** Basso. La maggior parte di fornitori di servizi e software offre piani di supporto da attivare. Documentando e condividendo le best practice di supporto sul tuo sistema di gestione delle conoscenze puoi verificare che il tuo team sappia cosa fare quando si verifica un problema in produzione. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md) 

 **Documenti correlati:** 
+ [ Piani Supporto AWS](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)

 **Servizi correlati:** 
+ [ Supporto del Business AWS](https://aws.amazon.com/premiumsupport/plans/business/)
+ [ Supporto Enterprise AWS](https://aws.amazon.com/premiumsupport/plans/enterprise/)

# Operatività
<a name="a-operate"></a>

**Topics**
+ [OPS 8. Come utilizzi l'osservabilità del carico di lavoro nella tua organizzazione?](ops-08.md)
+ [OPS 9. Come fai a comprendere lo stato delle operazioni?](ops-09.md)
+ [OPS 10. In che modo gestisci gli eventi del carico di lavoro e delle operazioni?](ops-10.md)

# OPS 8. Come utilizzi l'osservabilità del carico di lavoro nella tua organizzazione?
<a name="ops-08"></a>

Garantisci l'integrità del carico di lavoro sfruttando l'osservabilità. Utilizza metriche, log e tracce pertinenti per ottenere una visione completa delle prestazioni del carico di lavoro e risolvere i problemi in modo efficiente.

**Topics**
+ [OPS08-BP01 Analisi delle metriche del carico di lavoro](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 Analizza i log relativi ai carichi di lavoro](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 Analisi delle tracce del carico di lavoro](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 Creare avvisi fruibili](ops_workload_observability_create_alerts.md)
+ [OPS08-BP05 Creare dashboard](ops_workload_observability_create_dashboards.md)

# OPS08-BP01 Analisi delle metriche del carico di lavoro
<a name="ops_workload_observability_analyze_workload_metrics"></a>

 Dopo aver implementato la telemetria dell'applicazione, analizza regolarmente le metriche raccolte. Sebbene latenza, richieste, errori e capacità (o quote) forniscano informazioni dettagliate sulle prestazioni del sistema, è fondamentale dare priorità alla revisione delle metriche relative ai risultati aziendali. Ciò ti assicura di prendere decisioni basate sui dati in linea con i tuoi obiettivi aziendali. 

 **Risultato desiderato:** Informazioni dettagliate sulle prestazioni del carico di lavoro che guidano decisioni basate sui dati, garantendo l'allineamento con gli obiettivi aziendali. 

 **Anti-pattern comuni:** 
+  Analisi isolata delle metriche senza considerare il loro impatto sui risultati aziendali. 
+  Eccessiva dipendenza dalle metriche tecniche trascurando quelle aziendali. 
+  Revisione poco frequente delle metriche, perdita di opportunità di prendere decisioni in tempo reale. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Comprensione migliorata della correlazione tra prestazioni tecniche e risultati aziendali. 
+  Processo decisionale migliorato basato su dati in tempo reale. 
+  Identificazione e mitigazione proattive dei problemi prima che influiscano sui risultati aziendali. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Sfrutta strumenti come Amazon CloudWatch per l'esecuzione di analisi delle metriche. Utilizza servizi AWS come AWS Cost Anomaly Detection e Amazon DevOps Guru per rilevare anomalie, soprattutto quando le soglie statiche non sono conosciute o quando i modelli di comportamento evidenziano possibili anomalie. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  **Analizza e revisiona:** revisiona e interpreta regolarmente le metriche relative al carico di lavoro. 

   1.  Dai priorità alle metriche relative ai risultati aziendali rispetto a quelle puramente tecniche. 

   1.  Comprendi l'importanza di picchi, cali o schemi nei dati. 

1.  **Utilizza Amazon CloudWatch:** utilizza Amazon CloudWatch per una visualizzazione centralizzata e un'analisi approfondita. 

   1.  Configura dashboard CloudWatch per visualizzare le tue metriche e confrontarle nel tempo. 

   1.  Utilizza [percentili in CloudWatch](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/) per avere una visione chiara della distribuzione delle metriche, il che può aiutarti a definire gli SLA e a identificare valori anomali. 

   1.  Configura [AWS Cost Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) per identificare modelli insoliti senza fare affidamento su soglie statiche. 

   1.  Implementa [l'osservabilità CloudWatch tra account](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html) per monitorare e risolvere i problemi delle applicazioni che si estendono su più account all'interno di una regione. 

   1.  Utilizza [gli approfondimenti sulle metriche CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) per interrogare e analizzare i dati delle metriche tra account e regioni, identificando tendenze e anomalie. 

   1.  Applica [Metrica matematica CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) per trasformare, aggregare o eseguire calcoli sulle metriche per ottenere informazioni più approfondite. 

1.  **Impiega Amazon DevOps Guru:** incorpora [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) per il rilevamento delle anomalie basato sul machine learning, che consente di identificare i primi segnali di problemi operativi che riguardano le applicazioni serverless e di correggerli prima che abbiano un impatto sui clienti. 

1.  **Ottimizza in base agli approfondimenti: ** prendi decisioni informate sulla base dell'analisi delle metriche per adeguare e migliorare i carichi di lavoro. 

 **Livello di impegno per il piano di implementazione:** medio 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md) 

 **Documenti correlati:** 
+ [ The Wheel Blog - Emphasizing the importance of continually reviewing metrics ](https://aws.amazon.com/blogs/opensource/the-wheel/)
+ [ Percentile are important ](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)
+ [ Utilizzo di AWS Cost Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ CloudWatch cross-account observability ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)
+ [ Query your metrics with CloudWatch Metrics Insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)

 **Video correlati:** 
+ [ Enable Cross-Account Observability in Amazon CloudWatch ](https://www.youtube.com/watch?v=lUaDO9dqISc)
+ [ Introduction to Amazon DevOps Guru ](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [ Continuously Analyze Metrics using AWS Cost Anomaly Detection](https://www.youtube.com/watch?v=IpQYBuay5OE)

 **Esempi correlati:** 
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Gaining operation insights with AIOps using Amazon DevOps Guru ](https://catalog.us-east-1.prod.workshops.aws/workshops/f92df379-6add-4101-8b4b-38b788e1222b/en-US)

# OPS08-BP02 Analizza i log relativi ai carichi di lavoro
<a name="ops_workload_observability_analyze_workload_logs"></a>

 L'analisi regolare dei log dei carichi di lavoro è essenziale per acquisire una comprensione più approfondita degli aspetti operativi dell'applicazione. Attraverso l'analisi, la consultazione e l'interpretazione efficiente dei dati di log, è possibile ottimizzare continuamente le prestazioni e la sicurezza delle applicazioni. 

 **Risultato desiderato:** Informazioni dettagliate sul comportamento dell'applicazione e sulle operazioni derivanti da un'analisi completa dei log, che garantisce la rilevazione e la mitigazione proattiva dei problemi. 

 **Anti-pattern comuni:** 
+ Trascurare l'analisi dei log fino a quando non si verifica un problema critico.
+ Il mancato utilizzo della suite completa degli strumenti disponibili per l'analisi dei log comporta la perdita di approfondimenti importanti.
+  Fare affidamento esclusivamente sulla revisione manuale dei log senza sfruttare le funzionalità di automazione e di interrogazione. 

 **Vantaggi dell'adozione di questa best practice:** 
+ Identificazione proattiva dei colli di bottiglia operativi, delle minacce alla sicurezza e di altri problemi potenziali.
+ Utilizzo efficiente dei dati di log per l'ottimizzazione continua dell'applicazione.
+  Comprensione migliorata del comportamento dell'applicazione, facilitando il debug e la risoluzione dei problemi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) è un potente strumento per l'analisi dei log. Le funzionalità integrate come CloudWatch Logs Insights e Contributor Insights rendono il processo di derivazione di approfondimenti significativi dai log intuitivo ed efficiente. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  **Configura CloudWatch Logs:** configura applicazioni e servizi per inviare log a CloudWatch Logs. 

1.  **Configura CloudWatch Logs Insights:** Utilizza [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) per cercare e analizzare in modo interattivo i dati di log. 

   1.  Crea query per estrarre modelli, visualizzare i dati di log e ricavare approfondimenti utili. 

1.  **Sfrutta Contributor Insights** Utilizza [Contributor Insights di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) per identificare i top talkers in dimensioni ad alta cardinalità come gli indirizzi IP o gli utenti-agenti. 

1.  **Implementa filtri di metriche per CloudWatch Logs:** configura [filtri di metriche per log di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) per convertire i dati di log in metriche fruibili. Ciò consente di impostare allarmi o analizzare ulteriormente i modelli. 

1.  **Revisione e ottimizzazione regolari:** rivedi periodicamente le tue strategie di analisi dei log per acquisire tutte le informazioni pertinenti e ottimizzare continuamente le prestazioni delle applicazioni. 

 **Livello di impegno per il piano di implementazione:** medio. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md) 
+  [OPS08-BP01 Analisi delle metriche del carico di lavoro](ops_workload_observability_analyze_workload_metrics.md) 

 **Documenti correlati:** 
+ [ Analisi dei dati di log con CloudWatch Logs Insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [ Using CloudWatch Contributor Insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)
+ [ Creazione e gestione di filtri di metriche per log di CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)

 **Video correlati:** 
+ [ Analyze Log Data with CloudWatch Logs Insights ](https://www.youtube.com/watch?v=2s2xcwm8QrM)
+ [ Use CloudWatch Contributor Insights to Analyze High-Cardinality Data ](https://www.youtube.com/watch?v=ErWRBLFkjGI)

 **Esempi correlati:** 
+ [ Query di esempio di CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)

# OPS08-BP03 Analisi delle tracce del carico di lavoro
<a name="ops_workload_observability_analyze_workload_traces"></a>

 L'analisi dei dati di tracciamento è fondamentale per ottenere una visione completa del percorso operativo di un'applicazione. Visualizzando e comprendendo le interazioni tra i vari componenti, è possibile ottimizzare le prestazioni, identificare i colli di bottiglia e migliorare l'esperienza utente. 

 **Risultato desiderato:** Ottieni una chiara visibilità sulle operazioni distribuite della tua applicazione, che si traduce in una risoluzione più rapida dei problemi e in un'esperienza utente migliorata. 

 **Anti-pattern comuni:** 
+  I dati di tracciamento vengono trascurati e ci si affida esclusivamente a log e metriche. 
+  I dati di tracciamento non sono correlati ai log associati. 
+  Vengono ignorate le metriche derivate dalle tracce, come la latenza e i tassi di errore. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Miglioramento della risoluzione dei problemi e riduzione del tempo medio di risoluzione (MTTR). 
+  Informazioni dettagliate sulle dipendenze e sul loro impatto. 
+  Identificazione e correzione rapide dei problemi di prestazione. 
+  Vengono sfruttate le metriche derivate dalle tracce per un processo decisionale informato. 
+  Esperienze utente migliorate attraverso interazioni con i componenti ottimizzate. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) offre una suite completa per l'analisi dei dati di tracciamento, fornendo una visione olistica delle interazioni con i servizi, monitorando le attività degli utenti e rilevando i problemi di prestazioni. Funzionalità come ServiceLens, X-Ray Insights, X-Ray Analytics e Amazon DevOps Guru permettono di ottenere informazioni fruibili più approfondite derivate dai dati di tracciamento. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 I seguenti passaggi offrono un approccio strutturato per implementare efficacemente l'analisi dei dati di tracciamento utilizzando i servizi AWS: 

1.  **Integra AWS X-Ray:** Assicurati che X-Ray sia integrato con le tue applicazioni per acquisire dati di tracciamento. 

1.  **Analizza le metriche X-Ray:** analizza le metriche derivate dalle tracce di X-Ray, quali latenza, tassi di richiesta, percentuali di errore e distribuzioni dei tempi di risposta utilizzando [la mappa dei servizi](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html#xray-console-servicemap-view) per monitorare l'integrità delle applicazioni. 

1.  **Usa ServiceLens:** sfrutta la [mappa di ServiceLens](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_service_map.html) per una maggiore osservabilità dei tuoi servizi e applicazioni. Ciò consente la visualizzazione integrata di tracce, metriche, log, allarmi e altre informazioni correlate all'integrità. 

1.  **Abilita X-Ray Insights:** 

   1.  Attiva [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html) per il rilevamento automatico delle anomalie nelle tracce. 

   1.  Esamina le informazioni dettagliate per individuare i modelli e determinare le cause ultime, come l'aumento dei tassi di errore o delle latenze. 

   1.  Consulta la cronologia delle informazioni dettagliate per un'analisi cronologica dei problemi rilevati. 

1.  **Usa X-Ray Analytics:** [X-Ray Analytics](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html) consente di esplorare a fondo i dati di tracciamento, individuare modelli ed estrarre informazioni dettagliate. 

1.  **Usa i gruppi inX-Ray:** crea gruppi X-Ray per filtrare le tracce in base a criteri come l'elevata latenza, per un'analisi più mirata. 

1.  **Incorpora Amazon DevOps Guru:** Integra [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) per trarre vantaggio dai modelli di machine learning che individuano le anomalie operative nelle tracce. 

1.  **Usa CloudWatch Synthetics:** utilizza [CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html) per creare canary per il monitoraggio continuo degli endpoint e dei flussi di lavoro. Questi canary possono integrarsi con X-Ray per fornire dati di tracciamento per un'analisi approfondita delle applicazioni testate. 

1.  **Usa Real User Monitoring (RUM):** con [AWS X-Ray e CloudWatch RUM](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-RUM.html)è possibile analizzare ed eseguire il debug del percorso della richiesta a partire dagli utenti finali dell'applicazione tramite servizi AWS gestiti a valle. Ciò ti aiuta a identificare le tendenze e gli errori di latenza che hanno un impatto sugli utenti. 

1.  **Esegui correlazioni con i log:** esegui correlazioni [tra i dati di tracciamento e i relativi log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_troubleshooting.html#servicelens_troubleshooting_Nologs) all'interno della vista tracce di X-Ray per una prospettiva granulare sul comportamento delle applicazioni. Ciò consente di visualizzare gli eventi di log associati direttamente alle transazioni tracciate. 

 **Livello di impegno per il piano di implementazione:** medio. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS08-BP01 Analisi delle metriche del carico di lavoro](ops_workload_observability_analyze_workload_metrics.md) 
+  [OPS08-BP02 Analizza i log relativi ai carichi di lavoro](ops_workload_observability_analyze_workload_logs.md) 

 **Documenti correlati:** 
+ [ Using ServiceLens to Monitor Application Health ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html)
+ [ Exploring Trace Data with X-Ray Analytics ](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html)
+ [ Detecting Anomalies in Traces with X-Ray Insights ](https://docs.aws.amazon.com/xray/latest/devguide/xray-insights.html)
+ [ Continuous Monitoring with CloudWatch Synthetics ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)

 **Video correlati:** 
+ [ Analyze and Debug Applications Using Amazon CloudWatch Synthetics and AWS X-Ray](https://www.youtube.com/watch?v=s2WvaV2eDO4)
+ [ Use AWS X-Ray Insights ](https://www.youtube.com/watch?v=tl8OWHl6jxw)

 **Esempi correlati:** 
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Implementing X-Ray with AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html)
+ [ CloudWatch Synthetics Canary Templates ](https://github.com/aws-samples/cloudwatch-synthetics-canary-terraform)

# OPS08-BP04 Creare avvisi fruibili
<a name="ops_workload_observability_create_alerts"></a>

 Rilevare e rispondere tempestivamente alle deviazioni di comportamento dell'applicazione è fondamentale. È importante riconoscere quando i risultati basati sugli indicatori chiave di prestazione (KPI) sono a rischio o quando si verificano anomalie impreviste. Basare gli avvisi sui KPI garantisce che i segnali ricevuti siano direttamente correlati all'impatto aziendale od operativo. Questo approccio verso avvisi fruibili promuove risposte proattive e aiuta a mantenere le prestazioni e l'affidabilità del sistema. 

 **Risultato desiderato:** Si ricevono avvisi tempestivi, pertinenti e fruibili per l'identificazione e la mitigazione rapida di potenziali problemi, soprattutto quando i risultati dei KPI sono a rischio. 

 **Anti-pattern comuni:** 
+  Impostazione di troppi avvisi non critici, con conseguente affaticamento da avvisi ("alert fatigue"). 
+  Non viene data priorità agli avvisi in base ai KPI, il che rende difficile comprendere l'impatto dei problemi sull'azienda. 
+  Non affrontare le cause profonde porta a ricevere avvisi ripetuti per lo stesso problema. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Riduzione dell'affaticamento da avvisi ("alert fatigue") concentrandosi su avvisi pertinenti e fruibili. 
+  Maggiore operatività e affidabilità del sistema grazie al rilevamento e alla mitigazione proattiva dei problemi. 
+  Migliore collaborazione tra team e risoluzione più rapida dei problemi grazie all'integrazione con i più diffusi strumenti di avviso e comunicazione. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per creare un meccanismo di avviso efficace, è fondamentale utilizzare metriche, log e dati di tracciamento che segnalino quando i risultati basati sui KPI sono a rischio o vengono rilevate anomalie. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  **Definisci gli indicatori chiave di prestazione (KPI):** identifica i KPI della tua applicazione. Gli avvisi devono essere correlati a questi KPI per riflettere accuratamente l'impatto aziendale. 

1.  **Implementa il rilevamento delle anomalie:** 
   +  **Utilizza AWS Cost Anomaly Detection:** Configura [AWS Cost Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) per rilevare automaticamente schemi insoliti, garantendo che gli avvisi vengano generati solo per anomalie autentiche. 
   +  **Utilizza X-Ray Insights:** 

     1.  Configura [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html) per rilevare anomalie nei dati di tracciamento. 

     1.  Configura [notifiche per X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications) per ricevere avvisi quando si rilevano problemi. 
   +  **Esegui l'integrazione conDevOps Guru:** 

     1.  sfrutta [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) e le sue capacità di machine learning nel rilevare anomalie operative con i dati esistenti. 

     1.  Passa alle [impostazioni di notifica](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html#navigate-to-notification-settings) in DevOps Guru per impostare avvisi di anomalie. 

1.  **Implementa avvisi fruibili:** progetta avvisi che forniscano informazioni adeguate per intraprendere un'azione immediata. 

1.  **Riduci l'affaticamento da avvisi:** riduci al minimo gli avvisi non critici. Sovraccaricare i team con numerosi avvisi insignificanti può portare a trascurare problemi critici e a ridurre l'efficacia complessiva del meccanismo di avviso. 

1.  **Configura allarmi compositi:** utilizza [gli allarmi compositi di Amazon CloudWatch](https://aws.amazon.com/blogs/mt/improve-monitoring-efficiency-using-amazon-cloudwatch-composite-alarms-2/) per raggruppare più allarmi. 

1.  **Esegui l'integrazione con strumenti di avviso:** incorpora strumenti come [Ops Genie](https://www.atlassian.com/software/opsgenie) e [PagerDuty](https://www.pagerduty.com/). 

1.  **Integra Amazon Q Developer in chat applications** Integra [Amazon Q Developer in chat applications](https://aws.amazon.com/chatbot/)per inoltrare avvisi a Chime, Microsoft Teams e Slack. 

1.  **Avviso basato sui log:** utilizza [filtri di metriche per log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) in CloudWatch per creare allarmi basati su eventi di log specifici. 

1.  **Revisiona e itera:** riesamina e ottimizza regolarmente le configurazioni degli avvisi. 

 **Livello di impegno per il piano di implementazione:** medio. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md) 
+  [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md) 
+  [OPS04-BP03 Implementazione della telemetria dell'esperienza utente](ops_observability_customer_telemetry.md) 
+  [OPS04-BP04 Implementazione della telemetria delle dipendenze](ops_observability_dependency_telemetry.md) 
+  [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md) 
+  [OPS08-BP01 Analisi delle metriche del carico di lavoro](ops_workload_observability_analyze_workload_metrics.md) 
+  [OPS08-BP02 Analizza i log relativi ai carichi di lavoro](ops_workload_observability_analyze_workload_logs.md) 
+  [OPS08-BP03 Analisi delle tracce del carico di lavoro](ops_workload_observability_analyze_workload_traces.md) 

 **Documenti correlati:** 
+ [ Utilizzo degli allarmi di Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [ Create a composite alarm ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [ Create a CloudWatch alarm based on anomaly detection ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)
+ [ DevOps Guru Notifications ](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html)
+ [ X-Ray Insights notifications ](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)
+ [ Monitora, gestisci e risolvi i problemi delle tue risorse AWS con ChatOps interattive ](https://aws.amazon.com/chatbot/)
+ [ Amazon CloudWatch Integration Guide \$1 PagerDuty ](https://support.pagerduty.com/docs/amazon-cloudwatch-integration-guide)
+ [ Integrate OpsGenie with Amazon CloudWatch ](https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-amazon-cloudwatch/)

 **Video correlati:** 
+ [ Create Composite Alarms in Amazon CloudWatch ](https://www.youtube.com/watch?v=0LMQ-Mu-ZCY)
+ [ Amazon Q Developer in chat applications Overview ](https://www.youtube.com/watch?v=0jUSEfHbTYk)
+ [AWS on Air ft. Mutative Commands in Amazon Q Developer in chat applications ](https://www.youtube.com/watch?v=u2pkw2vxrtk)

 **Esempi correlati:** 
+ [ Alarms, incident management, and remediation in the cloud with Amazon CloudWatch ](https://aws.amazon.com/blogs/mt/alarms-incident-management-and-remediation-in-the-cloud-with-amazon-cloudwatch/)
+ [ Tutorial: Creating an Amazon EventBridge rule that sends notifications to Amazon Q Developer in chat applications ](https://docs.aws.amazon.com/chatbot/latest/adminguide/create-eventbridge-rule.html)
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)

# OPS08-BP05 Creare dashboard
<a name="ops_workload_observability_create_dashboards"></a>

 Le dashboard rappresentano la visualizzazione incentrata sull'utente dei dati di telemetria dei carichi di lavoro. Sebbene forniscano un'interfaccia visiva fondamentale, non dovrebbero sostituire i meccanismi di allarme, ma integrarli. Se realizzate con cura, sono in grado di fornire approfondimenti rapidi sullo stato e sulle prestazioni del sistema e possono informare gli stakeholder in tempo reale riguardo ai risultati aziendali e all'impatto dei problemi. 

 **Risultato desiderato:** Informazioni chiare e fruibili sullo stato del sistema e dell'azienda attraverso rappresentazioni visive. 

 **Anti-pattern comuni:** 
+  Dashboard eccessivamente complicate con troppe metriche. 
+  Affidarsi a dashboard senza avvisi per il rilevamento delle anomalie. 
+  Non aggiornare le dashboard man mano che i carichi di lavoro si evolvono. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Visibilità immediata delle metriche e dei KPI critici di sistema. 
+  Miglioramento della comunicazione e della comprensione con gli stakeholder. 
+  Informazioni dettagliate rapide sull'impatto dei problemi operativi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 **Dashboard incentrate sul business** 

 Le dashboard personalizzate in base ai KPI aziendali coinvolgono una gamma più ampia di stakeholder. Anche se queste persone potrebbero non essere interessate alle metriche di sistema, desiderano comprendere le implicazioni aziendali di questi numeri. Una dashboard incentrata sul business garantisce che tutte le metriche tecniche e operative monitorate e analizzate siano allineate con gli obiettivi aziendali generali. Questo allineamento fornisce chiarezza, garantendo che tutti siano sulla stessa lunghezza d'onda per quanto riguarda ciò che è essenziale e ciò che non lo è. Inoltre, le dashboard che mettono in evidenza i KPI aziendali tendono ad essere più fruibili. Gli stakeholder possono comprendere rapidamente lo stato delle operazioni, le aree che richiedono attenzione e il potenziale impatto sui risultati aziendali. 

 Con questo in mente, al momento di creare una dashboard, assicurati che ci sia un equilibrio tra metriche tecniche e KPI aziendali. Entrambi sono fondamentali, ma si rivolgono a un pubblico diverso. Idealmente, dovresti disporre di dashboard che forniscano una visione olistica dello stato e delle prestazioni del sistema, mettendo in evidenza al contempo i principali risultati aziendali e le loro implicazioni. 

 Le dashboard di Amazon CloudWatch sono home page personalizzabili nella console CloudWatch che puoi utilizzare per monitorare le tue risorse in un'unica visualizzazione, anche quelle distribuite tra Regioni AWS e account diversi. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  **Crea una dashboard di base:** [crea una nuova dashboard in CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)assegnandole un nome descrittivo. 

1.  **Usa i widget Markdown:** prima di iniziare a lavorare con le metriche, usa [widget Markdown](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_text_dashboard.html) per aggiungere un contesto testuale nella parte superiore della dashboard. Esso dovrebbe specificare cosa riguarda la dashboard, qual è l'importanza delle metriche rappresentate e può contenere anche link ad altri dashboard e strumenti di risoluzione dei problemi. 

1.  **Crea variabili della dashboard:** [incorpora le variabili della dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html) ove appropriato per consentire una visualizzazione dinamica e flessibile. 

1.  **Crea widget relativi alle metriche:** [aggiungi widget relativi alle metriche](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html) per visualizzare varie metriche emesse dall'applicazione e personalizza questi widget in modo che rappresentino efficacemente lo stato del sistema e i risultati aziendali. 

1.  **Richieste di informazioni sui log:** Utilizza [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) per ricavare metriche utilizzabili dai log e visualizzare queste informazioni sulla tua dashboard. 

1.  **Imposta allarmi:** integra [avvisi CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_alarm_dashboard.html) nella tua dashboard per una rapida visualizzazione di tutte le metriche che superano le soglie prestabilite. 

1.  **Usa Contributor Insights:** incorpora [Contributor Insights di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-ViewReports.html) per analizzare i campi ad alta cardinalità e comprendere meglio i principali fattori di contribuzione della tua risorsa. 

1.  **Progetta widget personalizzati:** per esigenze specifiche non soddisfatte dai widget standard, valuta la possibilità di creare [widget personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html). Questi possono attingere da varie origini dati o rappresentare i dati in modi unici. 

1.  **Itera e perfeziona:** man mano che la tua applicazione si evolve, riesamina regolarmente la dashboard per assicurarne la pertinenza. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md) 
+  [OPS08-BP01 Analisi delle metriche del carico di lavoro](ops_workload_observability_analyze_workload_metrics.md) 
+  [OPS08-BP02 Analizza i log relativi ai carichi di lavoro](ops_workload_observability_analyze_workload_logs.md) 
+  [OPS08-BP03 Analisi delle tracce del carico di lavoro](ops_workload_observability_analyze_workload_traces.md) 
+  [OPS08-BP04 Creare avvisi fruibili](ops_workload_observability_create_alerts.md) 

 **Documenti correlati:** 
+ [ Creazione di pannelli di controllo per visibilità operativa ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [ Utilizzo dei pannelli di controllo Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)

 **Video correlati:** 
+ [ Create Cross Account & Cross Region CloudWatch Dashboards ](https://www.youtube.com/watch?v=eIUZdaqColg)
+ [AWS re:Invent 2021 - Gain enterprise visibility with Cloud AWS operation dashboards ](https://www.youtube.com/watch?v=NfMpYiGwPGo)

 **Esempi correlati:** 
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Monitoraggio delle applicazioni con Amazon CloudWatch ](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch/)

# OPS 9. Come fai a comprendere lo stato delle operazioni?
<a name="ops-09"></a>

 Definisci, acquisisci e analizza i parametri delle operazioni per ottenere visibilità sugli eventi delle operazioni, in modo da intraprendere le azioni appropriate. 

**Topics**
+ [OPS09-BP01 Misura gli obiettivi operativi e i KPI con le metriche](ops_operations_health_measure_ops_goals_kpis.md)
+ [OPS09-BP02 Comunicare lo stato e le tendenze per garantire la visibilità delle operazioni](ops_operations_health_communicate_status_trends.md)
+ [OPS09-BP03 Revisione delle metriche operative e assegnazione delle priorità per favorire il miglioramento](ops_operations_health_review_ops_metrics_prioritize_improvement.md)

# OPS09-BP01 Misura gli obiettivi operativi e i KPI con le metriche
<a name="ops_operations_health_measure_ops_goals_kpis"></a>

 Ottieni obiettivi e KPI dalla tua organizzazione che definiscano il successo delle operazioni e stabilisci metriche che li riflettano. Definisci previsioni da utilizzare come riferimento e rivalutale regolarmente. Sviluppa meccanismi per raccogliere queste metriche dai team per la valutazione. 

 **Risultato desiderato:** 
+  Gli obiettivi e i KPI per i team operativi dell'organizzazione sono stati pubblicati e condivisi. 
+  Vengono stabilite metriche che riflettono questi KPI. Gli esempi possono includere: 
  +  Lunghezza della coda dei ticket o età media del ticket 
  +  Numero di ticket raggruppati per tipo di problema 
  +  Tempo impiegato per lavorare ai problemi con o senza una procedura operativa standardizzata (SOP) 
  +  Tempo impiegato per il ripristino dopo un push di codice non riuscito 
  +  Volume delle chiamate 

 **Anti-pattern comuni:** 
+  Le scadenze di implementazione non vengono rispettate perché gli sviluppatori sono costretti a dedicarsi alle attività di risoluzione dei problemi. I team di sviluppo chiedono più personale, ma non possono quantificarne il numero perché il tempo impiegato non può essere misurato. 
+  È stato installato un desk di livello 1 per gestire le chiamate degli utenti. Nel corso del tempo, sono aumentati i carichi di lavoro ma non il personale assegnato al desk di livello 1. La soddisfazione dei clienti ne risente a causa dell'aumento dei tempi di chiamata e di quelli per arrivare a una soluzione, ma il team manageriale non vede indicatori di questo problema e non intraprende azioni. 
+  Un carico di lavoro problematico è stato affidato a un team operativo separato per la gestione. A differenza di altri carichi di lavoro, questo non è accompagnato dalla documentazione e dai runbook adeguati. Pertanto, i team dedicano più tempo alla risoluzione dei problemi e alla gestione degli errori. Tuttavia, non esistono metriche che lo documentino, il che rende difficile comprendere le responsabilità. 

 **Vantaggi dell'adozione di questa best practice:** Quando il monitoraggio del carico di lavoro mostra lo stato delle nostre applicazioni e servizi, i team operativi dedicati al monitoraggio forniscono ai proprietari informazioni dettagliate sui cambiamenti avvenuti tra i consumatori di tali carichi di lavoro, come le mutate esigenze aziendali. Misura l'efficacia di questi team e valutali rispetto agli obiettivi aziendali creando metriche in grado di riflettere lo stato delle operazioni. Le metriche possono evidenziare problemi relativi al supporto o identificare quando si verificano deviazioni rispetto a un obiettivo di livello di servizio. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Fissa un appuntamento per parlare con i leader aziendali e gli stakeholder per stabilire gli obiettivi generali del servizio. Stabilisci quali devono essere i compiti dei vari team operativi e quali sfide potrebbero affrontare. Utilizza queste informazioni per un'attività di brainstorming sugli indicatori chiave di prestazione (KPI) che potrebbero riflettere questi obiettivi operativi. Questi potrebbero essere la soddisfazione del cliente, il tempo trascorso dall'ideazione della funzionalità alla sua implementazione, il tempo medio di risoluzione dei problemi e altro. 

 Partendo dai KPI, identifica le metriche e le origini di dati che potrebbero rispecchiare al meglio questi obiettivi. La soddisfazione del cliente può essere una combinazione di diverse metriche, come i tempi di attesa o di risposta durante le chiamate, i punteggi di soddisfazione e i tipi di problemi sollevati. I tempi di implementazione possono essere la somma del tempo necessario per il test e l'implementazione, con l'aggiunta di eventuali correzioni post-implementazione. Le statistiche che mostrano il tempo dedicato a diversi tipi di problemi (o il numero di tali problemi) possono fornire indicazioni su dove è necessario un impegno mirato. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Quick - Using KPIs ](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html)
+ [ Amazon CloudWatch - Using Metrics ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [ Creazione di pannelli di controllo ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [ How to track your cost optimization KPIs with KPI Dashboard ](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)

# OPS09-BP02 Comunicare lo stato e le tendenze per garantire la visibilità delle operazioni
<a name="ops_operations_health_communicate_status_trends"></a>

 Conoscere lo stato delle operazioni e la direzione verso la quale tendono a muoversi è necessario per identificare quando i risultati possono essere a rischio, se è possibile supportare o meno carichi di lavoro aggiuntivi o per verificare gli effetti che le modifiche hanno avuto sui team. Durante gli eventi operativi, disporre di pagine di stato a cui gli utenti e i team operativi possono fare riferimento per ottenere informazioni può ridurre la pressione sui canali di comunicazione e diffondere informazioni in modo proattivo. 

 **Risultato desiderato:** 
+  I responsabili delle operazioni hanno a disposizione informazioni dettagliate per conoscere il volume di chiamate che i loro team stanno gestendo e quali operazioni sono in corso, ad esempio le implementazioni. 
+  Quando si verificano eventi che possono compromettere le normali operazioni, vengono inviati avvisi agli stakeholder e alle comunità di utenti. 
+  Quando ricevono un avviso o si verifica un problema, la leadership dell'organizzazione e gli stakeholder possono controllare una pagina di stato e ottenere informazioni relative a un evento operativo, come punti di contatto, informazioni sui ticket e tempi di ripristino stimati. 
+  I report messi a disposizione della leadership e degli stakeholder contengono statistiche operative come il volume delle chiamate in un periodo di tempo, i punteggi di soddisfazione degli utenti, il numero e l'età di ticket in sospeso. 

 **Anti-pattern comuni:** 
+  Se un carico di lavoro si interrompe, il servizio diventa non disponibile. Il volume delle chiamate aumenta quando gli utenti chiedono di sapere cosa sta succedendo. Le richieste dei manager di sapere chi sta risolvendo un problema comportano un ulteriore aumento del volume. Vari team operativi duplicano gli sforzi mentre effettuano indagini. 
+  La volontà di acquisire una nuova capacità porta a riassegnare gli sforzi di alcuni membri del personale verso compiti di tipo tecnico. Non viene fornito alcun backfill e i tempi di risoluzione dei problemi aumentano. Queste informazioni non vengono acquisite e i manager vengono a conoscenza del problema solo dopo diverse settimane o quando viene ricevuto il feedback negativo degli utenti. 

 **Vantaggi dell'adozione di questa best practice:** A volte, durante eventi operativi che hanno un impatto sull'azienda, si spreca molto tempo ed energia in query per ottenere informazioni da vari team nel tentativo di comprendere la situazione. Grazie alla creazione di pagine di stato e dashboard ampiamente diffuse, gli stakeholder possono ottenere rapidamente informazioni, ad esempio, se è stato rilevato o meno un problema, chi è a capo delle attività di risoluzione o quando è previsto un ritorno alle normali operazioni. Ciò permette ai membri del team di avere più tempo per affrontare i problemi, perché non devono dilungarsi a comunicare lo stato agli altri. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Crea dashboard che mostrino le metriche fondamentali attuali per i tuoi team operativi e rendile facilmente accessibili ai responsabili operativi e ai manager. 

 Crea pagine di stato aggiornabili rapidamente per diffondere informazioni relative a un incidente o un evento, come chi ne è responsabile e chi coordina la risposta. Condividi in questa pagina eventuali passaggi o soluzioni alternative che gli utenti dovrebbero prendere in considerazione e divulga ampiamente la posizione della pagina. Incoraggia gli utenti a controllare prima questa pagina quando si trovano di fronte a un problema sconosciuto. 

 Raccogli e fornisci report che mostrino lo stato di salute delle operazioni nel tempo e distribuiscili a leader e responsabili decisionali per illustrare il lavoro dei team operativi e le loro sfide ed esigenze. 

 Condividi con i team le metriche e i report che meglio riflettono gli obiettivi e i KPI e come hanno influito nel guidare il cambiamento. Dedica del tempo a queste attività per aumentare l'importanza delle operazioni nei e tra i team. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Measure Progress ](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/measure-progress.html)
+ [ Creazione di pannelli di controllo per visibilità operativa ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)

 **Soluzioni correlate:** 
+ [ Data Operations ](https://aws.amazon.com/solutions/app-development/data-operations)

# OPS09-BP03 Revisione delle metriche operative e assegnazione delle priorità per favorire il miglioramento
<a name="ops_operations_health_review_ops_metrics_prioritize_improvement"></a>

 L'assegnazione di tempo e risorse per la revisione dello stato delle operazioni garantisce che servire il settore d'attività rimanga una priorità quotidiana. Effettua regolarmente riunioni con i responsabili operativi e gli stakeholder per rivedere le metriche, riconfermare o modificare traguardi e obiettivi e dare priorità ai miglioramenti. 

 **Risultato desiderato:** 
+  I responsabili operativi e il personale si incontrano regolarmente per esaminare le metriche in un determinato periodo di riferimento. Si comunicano le sfide, si celebrano le vittorie e si condividono le lezioni apprese. 
+  Gli stakeholder e i leader aziendali vengono regolarmente informati sullo stato delle operazioni e sollecitati a fornire input su obiettivi, KPI e iniziative future. Vengono discusse e contestualizzate le scelte tra erogazione dei servizi, operazioni e manutenzione. 

 **Anti-pattern comuni:** 
+  Viene lanciato un nuovo prodotto, ma i team operativi di livello 1 e 2 non sono adeguatamente formati per fornire supporto oppure non dispongono di personale aggiuntivo. I leader non vedono le metriche che mostrano la diminuzione dei tempi di risoluzione dei ticket e l'aumento del volume degli incidenti. Si agisce settimane dopo, quando i numeri delle sottoscrizioni iniziano a diminuire a causa di utenti scontenti che abbandonano la piattaforma. 
+  Da molto tempo esiste un processo manuale per eseguire la manutenzione su un carico di lavoro. La volontà di automatizzare, seppur presente, costituiva una priorità bassa data la scarsa importanza del sistema. Nel corso del tempo, tuttavia, l'importanza del sistema è cresciuta e ora i team operativi sono impegnati per la maggior parte del tempo in questi processi manuali. Non sono previste risorse per fornire una maggiore strumentazione ai team operativi oberati dall'aumento dei carichi di lavoro, con rischi di burnout per il personale. La leadership viene a conoscenza del problema una volta che viene segnalato da un membro del personale che lascia l'azienda per un concorrente. 

 **Vantaggi dell'adozione di questa best practice:** In alcune organizzazioni, può diventare difficile dedicare lo stesso tempo e la stessa attenzione alla fornitura di servizi e a nuovi prodotti od offerte. Quando ciò si verifica, il settore d'attività può risentirne a causa del lento deterioramento del livello di servizio atteso. Questo perché le operazioni non cambiano e non si evolvono di pari passo con la crescita del business e possono diventare presto obsolete. Senza una revisione regolare delle informazioni raccolte dai team operativi, il rischio che l'azienda corre potrebbe diventare visibile solo quando è troppo tardi. Dedicare tempo alla revisione delle metriche e delle procedure insieme al personale operativo e alla leadership, permette di mettere in luce il ruolo cruciale svolto dai team operativi nell'identificare i rischi molto prima che raggiungano livelli critici. I team operativi ottengono una visione migliore dei cambiamenti e delle iniziative aziendali imminenti, il che permette di intraprendere azioni proattive. Grazie alla visibilità delle metriche operative, la leadership è consapevole del ruolo che i team operativi svolgono nel garantire la soddisfazione dei clienti, sia interni che esterni, ed è in grado di valutare meglio le scelte in base alle priorità o di garantire che ci sia sufficiente tempo per modificare e fare evolvere operazioni e risorse attraverso nuove iniziative aziendali e di carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Dedica del tempo alla revisione delle metriche operative con gli stakeholder e i team operativi e alla revisione dei dati dei report. Inserisci questi report nel contesto degli scopi e degli obiettivi dell'organizzazione per stabilire se vengono raggiunti. Identifica le cause di ambiguità quando gli obiettivi non sono chiari o possono esserci conflitti tra ciò che viene chiesto e ciò che viene fornito. 

 Identifica come il tempo, le persone e gli strumenti possono contribuire agli esiti delle operazioni. Stabilisci quali KPI ne verrebbero influenzati e quali devono essere gli obiettivi di successo. Effettua regolarmente una revisione per assicurarti che i team operativi dispongano di risorse sufficienti per supportare il settore d'attività. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Amazon Athena ](https://aws.amazon.com/athena/)
+ [ Documentazione di riferimento su parametri e dimensioni di Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [ Amazon Quick ](https://aws.amazon.com/quicksight/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [ Collect metrics and logs from Amazon EC2 instances and on-premises servers with the Amazon CloudWatch Agent ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [ Utilizzare i parametri Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)

# OPS 10. In che modo gestisci gli eventi del carico di lavoro e delle operazioni?
<a name="ops-10"></a>

 Prepara e convalida le procedure in risposta agli eventi per ridurre al minimo il loro impatto sul tuo carico di lavoro. 

**Topics**
+ [OPS10-BP01 Utilizzo di un processo per la gestione di eventi, incidenti e problemi](ops_event_response_event_incident_problem_process.md)
+ [OPS10-BP02 Definizione di un processo per ogni avviso](ops_event_response_process_per_alert.md)
+ [OPS10-BP03 Definizione della priorità degli eventi operativi in base agli effetti sul business](ops_event_response_prioritize_events.md)
+ [OPS10-BP04 Definizione dei percorsi di escalation](ops_event_response_define_escalation_paths.md)
+ [OPS10-BP05 Definizione di un piano di comunicazione con i clienti per le interruzioni](ops_event_response_push_notify.md)
+ [OPS10-BP06 Comunicazione dello stato tramite pannelli di controllo](ops_event_response_dashboards.md)
+ [OPS10-BP07 Automazione delle risposte agli eventi](ops_event_response_auto_event_response.md)

# OPS10-BP01 Utilizzo di un processo per la gestione di eventi, incidenti e problemi
<a name="ops_event_response_event_incident_problem_process"></a>

L'organizzazione dispone di processi per gestire eventi, incidenti e problemi. *Gli eventi* sono costituiti da quanto accade nel carico di lavoro che non necessita di un intervento umano. *Gli incidenti* sono invece eventi che richiedono un intervento. *I problemi* sono eventi ricorrenti che richiedono un intervento o che non possono essere risolti. È necessario disporre di processi per ridurre l'impatto degli eventi sull'azienda e accertarsi di reagire in modo tempestivo e appropriato.

Quando nel carico di lavoro si verificano problemi o incidenti, è necessario utilizzare i processi per gestirli. In che modo puoi comunicare lo stato dell'evento alle parti coinvolte? Chi supervisiona la gestione delle risposte? Quali sono gli strumenti da utilizzare per ridurre l'impatto dell'evento? Questi sono solo alcuni esempi delle domande a cui devi rispondere per creare un processo di risposta affidabile. 

I processi devono essere documentati in una posizione centralizzata, nonché essere disponibili a chiunque sia coinvolto nel carico di lavoro. Se non è presente un wiki o un archivio di documenti centralizzato, è possibile utilizzare un repository per il controllo delle versioni. In questo modo sarà possibile mantenere aggiornati i piani in modo conforme all'evoluzione dei processi. 

I problemi possono essere automatizzati. Il tempo richiesto per la gestione di questo tipo di eventi potrebbe essere altrimenti destinato all'innovazione. Comincia a creare un processo ripetibile per ridurre il più possibile l'impatto del problema. Gradualmente cerca di concentrarti sull'automazione della riduzione o risoluzione del problema sottostante. In questo modo il tempo risparmiato potrà essere dedicato a migliorare il carico di lavoro. 

**Risultato desiderato:** l'organizzazione dispone di un processo per gestire eventi, incidenti e problemi. Questi processi sono documentati e archiviati in una posizione centralizzata e vengono aggiornati in base alle modifiche apportate. 

**Anti-pattern comuni:** 
+  Un incidente si verifica durante il fine settimana e il tecnico di turno non sa cosa fare. 
+  Un cliente invia un messaggio e-mail indicando che l'applicazione non è disponibile. Riavvii il server per correggere il problema. Questo incidente si verifica di frequente. 
+  Si verifica un incidente e più team si mettono a lavorare in modo indipendente per risolvere il problema. 
+  Le implementazioni vengono eseguite nel carico di lavoro senza essere documentate. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Nel carico di lavoro è presente un itinerario di audit degli eventi. 
+  Viene ridotto il tempo necessario per il ripristino in seguito a un incidente. 
+  I membri dei team riescono a risolvere incidenti e problemi in modo coerente. 
+  Durante l'analisi di un incidente, l'approccio è condiviso e più consolidato. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

L'implementazione di questa best practice prevede la registrazione degli eventi dei carichi di lavoro. Per la gestione di incidenti e problemi, è necessario ricorrere ai processi. I processi sono documentati, condivisi e aggiornati con frequenza. I problemi vengono identificati, classificati in base alla priorità e corretti. 

 **Esempio del cliente** 

AnyCompany Retail ha dedicato una parte del proprio wiki interno ai processi destinati alla gestione di eventi, incidenti e problemi. Tutti gli eventi vengono inviati ad [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html). I problemi vengono classificati come OpsItems (elementi di lavoro operativi) in [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) e classificati in base alla loro priorità al fine della loro risoluzione, in modo da ridurre eventuali attività indifferenziate. Quando i processi subiscono variazioni, vengono aggiornati nel wiki interno. Viene utilizzato [Strumento di gestione degli incidenti AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) per gestire gli incidenti e coordinare le attività di riduzione dell'impatto. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Eventi 
   +  Tieni traccia degli eventi che si verificano nel carico di lavoro, anche se non è richiesto alcun intervento umano. 
   +  Collabora con le parti coinvolte a livello di piano di lavoro per redigere un elenco di eventi di cui tenere traccia, ad esempio implementazioni completate o applicazioni di patch riuscite. 
   +  Puoi utilizzare servizi come [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) oppure [Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) per generare eventi personalizzati per il monitoraggio. 

1.  Incidenti 
   +  Per prima cosa, definisci il piano di comunicazione per gli incidenti. Quali parti coinvolte devono essere informate? In che modo le tieni costantemente aggiornate? Chi supervisiona il coordinamento di tutte queste attività? È consigliabile creare un canale di chat per le comunicazioni e il coordinamento. 
   +  Definisci un percorso di escalation per i team di supporto del carico di lavoro, soprattutto se il team non dispone di turni di rotazione della disponibilità. A seconda del livello di supporto, è possibile segnalare un caso anche mediante il Supporto. 
   +  Crea un playbook per l'analisi dell'incidente. È necessario includere il piano di comunicazione e, in dettaglio, i passaggi del processo di indagine. Includi il controllo del [Dashboard AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) nel processo di indagine. 
   +  Documenta il piano di risposta agli incidenti. Comunica il piano di gestione degli incidenti in modo che i clienti esterni siano consapevoli delle regole da seguire e dei comportamenti richiesti previsti. Fornisci formazione ai membri dei team su come utilizzare tale piano di gestione. 
   +  I clienti possono utilizzare [Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) per configurare e gestire il piano di risposta agli incidenti. 
   +  I clienti del supporto Enterprise possono richiedere di seguire il [workshop relativo alla gestione degli incidenti](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) al proprio Technical Account Manager (TAM). Questo workshop guidato consente di verificare il piano di risposta agli incidenti esistente e ti aiuta a individuare eventuali aree da migliorare. 

1.  Problemi 
   +  I problemi devono essere identificati e registrati nel sistema ITSM in uso. 
   +  Identifica tutti i problemi noti ed eseguine una catalogazione in base all'impegno necessario per correggerli e al relativo impatto sul carico di lavoro.   
![\[Matrice delle priorità delle operazioni per la catalogazione dei problemi.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/impact-effort-chart.png)
   +  Per prima cosa risolvi i problemi caratterizzati dall'impatto più alto e dal minore impegno. Dopodiché, passa alla risoluzione dei problemi che rientrano nel quadrante basso impatto/basso impegno. 
   +  Puoi utilizzare [Systems Manager OpsCenter](systems-manager/latest/userguide/OpsCenter.html) per identificare i problemi, associarvi runbook e tenerne traccia. 

**Livello di impegno per il piano di implementazione:** medio. Devi disporre sia di un processo che degli strumenti per implementare questa best practice. Documenta i processi e rendili disponibili a chiunque sia coinvolto nel carico di lavoro. Aggiornali con frequenza. È disponibile un processo per la gestione e la migrazione o la risoluzione dei problemi. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS07-BP03 Utilizzo di runbook per eseguire le procedure](ops_ready_to_support_use_runbooks.md): i problemi noti necessitano di un runbook associato in modo tale che le attività di attenuazione dell'impatto siano coerenti.
+  [OPS07-BP04 Utilizzo dei playbook per analizzare i problemi](ops_ready_to_support_use_playbooks.md): gli incidenti devono essere analizzati con il supporto di playbook. 
+  [OPS11-BP02 Esecuzione di analisi post-incidente](ops_evolve_ops_perform_rca_process.md): esegui sempre un post-mortem dopo aver eseguito un ripristino in seguito a un incidente. 

 **Documenti correlati:** 
+  [Atlassian - Incident management in the age of DevOps (Atlassian - Gestione degli incidenti nell'era di DevOps)](https://www.atlassian.com/incident-management/devops) 
+  [AWS Security Incident Response Guide (Guida alle risposte agli incidenti di sicurezza di AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+  [Incident Management in the Age of DevOps and SRE (Gestione degli incidenti nell'era di DevOps e SRE)](https://www.infoq.com/presentations/incident-management-devops-sre/) 
+  [PagerDuty - What is Incident Management? (PagerDuty - Che cos'è la gestione degli incidenti?)](https://www.pagerduty.com/resources/learn/what-is-incident-management/) 

 **Video correlati:** 
+  [AWS re:Invent 2020: Incident management in a distributed organization (Gestione degli incidenti in un'organizzazione distribuita)](https://www.youtube.com/watch?v=tyS1YDhMVos) 
+  [AWS re:Invent 2021 - Building next-gen applications with event-driven architectures (Sviluppo di applicazioni di nuova generazione con architetture basate su eventi)](https://www.youtube.com/watch?v=U5GZNt0iMZY) 
+  [AWS Supports You \$1 Exploring the Incident Management Tabletop Exercise (Esplorazione degli esercizi di simulazione relativi alla gestione degli incidenti)](https://www.youtube.com/watch?v=0m8sGDx-pRM) 
+  [Strumento di gestione degli incidenti AWS Systems Manager - AWS Virtual Workshops (Workshop virtuali AWS)](https://www.youtube.com/watch?v=KNOc0DxuBSY) 
+  [AWS What's Next ft. Incident Manager \$1 AWS Events (Novità di AWS e Incident Manager \$1 Eventi AWS)](https://www.youtube.com/watch?v=uZL-z7cII3k) 

 **Esempi correlati:** 
+  [AWS Management and Governance Tools Workshop - OpsCenter (Workshop sugli strumenti di gestione e governance AWS - OpsCenter)](https://mng.workshop.aws/ssm/capability_hands-on_labs/opscenter.html) 
+  [AWS Proactive Services – Incident Management Workshop (Servizi AWS proattivi – Workshop relativo alla gestione degli incidenti)](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) 
+  [Building an event-driven application with Amazon EventBridge (Sviluppo di un'applicazione basata su eventi con Amazon EventBridge)](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/) 
+  [Building event-driven architectures on AWS (Sviluppo di architetture basate su eventi in AWS)](https://catalog.us-east-1.prod.workshops.aws/workshops/63320e83-6abc-493d-83d8-f822584fb3cb/en-US/) 

 **Servizi correlati:** 
+  [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 
+  [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 
+  [Dashboard AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 
+  [Strumento di gestione degli incidenti AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 

# OPS10-BP02 Definizione di un processo per ogni avviso
<a name="ops_event_response_process_per_alert"></a>

 Predisponi una risposta specifica (runbook o playbook), con un proprietario espressamente identificato, per ogni evento per cui viene generato un avviso. Questo consente di rispondere agli eventi operativi in modo rapido ed efficace, evitando che gli eventi che richiedono un'azione vengano oscurati da notifiche meno importanti. 

 **Anti-pattern comuni:** 
+  Il sistema di monitoraggio presenta un flusso di connessioni approvate insieme ad altri messaggi. Il volume di messaggi è così grande che vengono ignorati dei messaggi di errore periodici che richiedono il tuo intervento. 
+  Ricevi un avviso che informa che il sito Web è inattivo. Non esiste un processo definito per quando ciò si verifica. Sei costretto ad adottare un approccio ad hoc per diagnosticare e risolvere il problema. Lo sviluppo di questo processo durante l'esecuzione prolunga il tempo di ripristino. 

 **Vantaggi dell'adozione di questa best practice:** Generando avvisi solo quando è necessaria un'operazione, eviti che gli avvisi di basso valore nascondano quelli più importanti. Creando un processo per ogni avviso che richiede un'azione, puoi attivare una risposta coerente e immediata agli eventi nel tuo ambiente. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Un processo per ogni avviso: a ogni evento per cui viene generato un avviso deve corrispondere una risposta specifica (runbook o playbook) con un responsabile specificatamente identificato (ad esempio, una persona, un team o un ruolo) a cui spetta il compito di completare correttamente l'azione. L'esecuzione della risposta può essere automatizzata o condotta da un altro team, ma il proprietario è tenuto ad assicurarsi che il processo produca i risultati previsti. Questi processi consentono di rispondere agli eventi operativi in modo rapido ed efficace, evitando che gli eventi che richiedono un'azione vengano oscurati da notifiche meno importanti. Ad esempio, è possibile applicare l'auto scaling per ridimensionare un front-end Web, ma il team operativo può essere tenuto a garantire che le regole e i limiti di auto scaling siano appropriati per le esigenze del carico di lavoro. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Funzionalità di Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) 
+  [Che cos'è Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 

 **Video correlati:** 
+  [Creazione di un piano di monitoraggio](https://www.youtube.com/watch?v=OMmiGETJpfU) 

# OPS10-BP03 Definizione della priorità degli eventi operativi in base agli effetti sul business
<a name="ops_event_response_prioritize_events"></a>

 Quando più eventi richiedono un intervento, assicurati che quelli più significativi per il business vengano affrontati per primi. Sono esempi di effetti il decesso o l'infortunio, le perdite finanziarie o i danni alla reputazione o alla fiducia. 

 **Anti-pattern comuni:** 
+  Ricevi una richiesta di supporto per aggiungere una configurazione della stampante per un utente. Durante la risoluzione del problema, ricevi una richiesta di supporto per sito di vendita al dettaglio non disponibile. Dopo aver completato la configurazione della stampante per l'utente, inizi a lavorare sul problema del sito Web. 
+  Ti viene segnalato che il sito Web di vendita al dettaglio e il sistema delle buste paga non sono disponibili. Non sai quale deve avere la priorità. 

 **Vantaggi dell'adozione di questa best practice:** Dare priorità alle risposte agli incidenti che determinano il maggiore impatto sull'azienda consente di gestire tale impatto. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Definizione della priorità degli eventi operativi in base agli effetti sul business: assicurati che quando più eventi richiedono un intervento, quelli più significativi per l'azienda vengano affrontati per primi. Sono esempi di effetti il decesso o l'infortunio, le perdite finanziarie, le violazioni alle normative o i danni alla reputazione o alla fiducia. 

# OPS10-BP04 Definizione dei percorsi di escalation
<a name="ops_event_response_define_escalation_paths"></a>

 Definisci percorsi di escalation nei tuoi runbook e playbook, compresi gli eventi che attivano l'escalation e le procedure di escalation. In particolare, identifica i proprietari per ogni azione per assicurare risposte rapide ed efficaci agli eventi operativi. 

 Stabilisci in quali circostanze serve una decisione umana prima che venga intrapresa un'azione. Collabora con i responsabili delle decisioni affinché questa decisione venga presa in anticipo e l'operazione sia preapprovata, in modo che la MTTR non si prolunghi in attesa di una risposta. 

 **Anti-pattern comuni:** 
+  Il sito di vendita al dettaglio non è disponibile. Il runbook per il ripristino del sito non è chiaramente comprensibile. Inizi a chiamare i colleghi sperando che qualcuno possa aiutarti. 
+  Ricevi un caso di supporto per un'applicazione irraggiungibile. Non disponi delle autorizzazioni per amministrare il sistema. Non sai a chi compete questo compito. Tenti di contattare il proprietario del sistema che ha aperto il caso ma non ricevi risposta. Né tu né i tuoi colleghi sapete chi bisogna contattare per il sistema. 

 **Vantaggi dell'adozione di questa best practice:** Definendo le escalation e i trigger e le procedure per l'escalation, abiliti l'aggiunta sistematica di risorse a un incidente con una rapidità adeguata all'impatto. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Definizione di percorsi di escalation: definisci percorsi di escalation nei tuoi runbook e playbook, compresi gli eventi che attivano l'escalation e le relative procedure. Ad esempio, l'escalation di un problema dai tecnici del supporto ai tecnici del supporto senior quando i runbook non riescono a risolvere il problema o quando è trascorso un determinato periodo di tempo. Un altro esempio di percorso di escalation appropriato è l'inoltro dai tecnici del supporto senior al team di sviluppo per un carico di lavoro quando i playbook non sono in grado di identificare un percorso di correzione o quando è trascorso un determinato periodo di tempo. In particolare, identifica i proprietari per ogni azione per assicurare risposte rapide ed efficaci agli eventi operativi. Le escalation possono includere terze parti, ad esempio un provider di connettività di rete o un produttore di software. Possono anche includere i responsabili decisionali autorizzati identificati per i sistemi interessati. 

# OPS10-BP05 Definizione di un piano di comunicazione con i clienti per le interruzioni
<a name="ops_event_response_push_notify"></a>

 Definisci e testa un piano di comunicazione affidabile per le interruzioni del sistema in modo da tenere informati clienti e stakeholder durante le interruzioni. Comunica direttamente con gli utenti sia quando i servizi che usano subiscono un'interruzione sia quando tornano alla normalità. 

 **Risultato desiderato:** 
+  Presenza di un piano di comunicazione per situazioni che includono dalla manutenzione pianificata a errori imprevisti di grande entità, inclusa l'attivazione di piani di ripristino di emergenza. 
+  Disponibilità di informazioni chiare e trasparenti sui problemi relativi ai sistemi, in modo che i clienti non siano costretti a congetture sulle prestazioni dei propri sistemi. 
+  Uso di pagine di stato e messaggi di errore personalizzati per ridurre i picchi nelle richieste all'help desk e tenere informati gli utenti. 
+  Esecuzione regolare di test del piano di comunicazione per verificarne il funzionamento nel modo previsto quando si verifica realmente un'interruzione. 

 **Anti-pattern comuni:** 
+ Si verifica un'interruzione del carico di lavoro, ma non è disponibile un piano di comunicazione. Gli utenti sovraccaricano di richieste il sistema di gestione dei ticket di assistenza perché non hanno informazioni sull'interruzione.
+ Durante un'interruzione, invii una notifica tramite e-mail agli utenti. Il messaggio non contiene informazioni sulle tempistiche per il ripristino del servizio e gli utenti non possono pianificare le proprie attività durante l'interruzione.
+ Esiste un piano di comunicazione per le interruzioni, ma non è mai stato testato. Si verifica un'interruzione e il piano di comunicazione non riesce perché non include un passaggio critico che avrebbe potuto essere identificato tramite test.
+  Durante un'interruzione, invii una notifica agli utenti con troppi dettagli tecnici e informazioni rispetto a quanto indicato nell'accordo di non divulgazione AWS. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Il mantenimento della comunicazione durante le interruzioni fornisce ai clienti la visibilità sullo stato dei problemi e sul tempo stimato per la risoluzione. 
+  Lo sviluppo di un piano di comunicazione ben definito permette di verificare che clienti e utenti finali vengano correttamente informati in modo da poter adottare i passaggi aggiuntivi necessari per attenuare l'impatto delle interruzioni. 
+  Con comunicazioni appropriate e una maggiore consapevolezza delle interruzioni pianificate e impreviste, puoi migliorare la soddisfazione dei clienti, limitare le reazioni involontarie e favorire la fidelizzazione dei clienti. 
+  Comunicazioni tempestive e trasparenti sulle interruzioni del sistema creano la fiducia necessaria per mantenere le relazioni con i clienti. 
+  Una strategia di comunicazione collaudata durante un'interruzione o una crisi riduce congetture e dicerie che potrebbero ostacolare la tua capacità di ripristinare il sistema. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I piani di comunicazione che tengono informati i clienti durante le interruzioni sono olistici e includono più interfacce, tra cui le pagine di errore destinate ai clienti, i messaggi di errore delle API personalizzati, i banner sullo stato del sistema e le pagine di stato sull'integrità. Se il sistema include utenti registrati, puoi comunicare attraverso canali di messaggistica come e-mail, SMS o notifiche push per inviare messaggi con contenuti personalizzati ai clienti. 

 **Strumenti di comunicazione con i clienti** 

 Come prima linea di difesa, le applicazioni Web e per dispositivi mobili devono fornire messaggi di errore intuitivi e informativi durante un'interruzione ed essere in grado di reindirizzare il traffico a una pagina di stato. [Amazon CloudFront](https://aws.amazon.com/cloudfront/) è una rete di distribuzione di contenuti (CDN) completamente gestita che include funzionalità per definire e distribuire contenuti personalizzati sugli errori. Le pagine di errore personalizzate in CloudFront sono un ottimo tipo iniziale di messaggistica ai clienti per le interruzioni a livello di componente. CloudFront può anche semplificare la gestione e l'attivazione di una pagina di stato per intercettare tutte le richieste durante interruzioni pianificate o impreviste. 

 Messaggi di errore personalizzati sulle API possono aiutare a identificare e ridurre l'impatto quando le interruzioni sono separate in servizi dedicati. [Amazon API Gateway](https://aws.amazon.com/api-gateway/) permette di configurare risposte personalizzate per le REST API. In questo modo, puoi fornire messaggi chiari e significativi agli utenti di API quando API Gateway non è in grado di raggiungere i servizi back-end. Puoi usare messaggi personalizzati anche per supportare contenuti e notifiche dei banner sulle interruzioni quando una determinata funzionalità del sistema risulta danneggiata a causa di interruzioni a livello di servizio. 

 La messaggistica diretta è il tipo più personalizzato di messaggistica per i clienti. [Amazon Pinpoint](https://aws.amazon.com/pinpoint/) è un servizio gestito per comunicazioni multicanale scalabili. Amazon Pinpoint ti permette di creare campagne per la trasmissione di messaggi a tutta la clientela interessata tramite SMS, e-mail, messaggi vocali, notifiche push o canali personalizzati da te definiti. Quando gestisci la messaggistica con Amazon Pinpoint, le campagne di messaggi sono ben definite, verificabili e possono essere applicate in modo intelligente ai segmenti di clientela desiderati. Una volta create, le campagne possono essere pianificate o attivate da eventi e testate facilmente. 

 **Esempio del cliente** 

 Quando il carico di lavoro risulta danneggiato, AnyCompany Retail invia una notifica tramite e-mail ai propri utenti. L'e-mail specifica le funzionalità aziendali interessate e fornisce una stima realistica delle tempistiche per il ripristino del servizio. Inoltre, l'azienda ha una pagina di stato che mostra informazioni in tempo reali sull'integrità del carico di lavoro. Il piano di comunicazione viene testato in un ambiente di sviluppo due volte all'anno per convalidarne l'efficienza. 

 **Passaggi dell'implementazione** 

1.  Determina i canali di comunicazione per la strategia di messaggistica. Tieni conto degli aspetti architetturali dell'applicazione e determina la migliore strategia per fornire feedback ai clienti. Possono essere incluse una o più delle strategie definite per le linee guida, tra cui pagine di errore e di stato, risposte personalizzate agli errori delle API o messaggistica diretta. 

1.  Progetta pagine di stato per l'applicazione. Se hai deciso che le pagine personalizzate di errore o di stato sono l'opzione più adatta per i clienti, dovrai progettarne il contenuto e la messaggistica. Le pagine di errore spiegano agli utenti perché un'applicazione non è disponibile, quando potrebbe tornare disponibile e che cosa possono fare gli utenti nel frattempo. Se l'applicazione usa Amazon CloudFront, puoi distribuire [risposte personalizzate agli errori](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GeneratingCustomErrorResponses.html) o usare Lambda in posizioni edge per [tradurre gli errori](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-update-error-status-examples) e riscrivere il contenuto delle pagine. CloudFront permette anche di scambiare le destinazioni dal contenuto dell'applicazione a un'origine di contenuto [Amazon S3](https://aws.amazon.com/s3/) statica che include la pagina di stato sulla manutenzione o sull'interruzione. 

1.  Progetta il set corretto di stati di errore delle API per il servizio. I messaggi di errore generati da API Gateway quando non riesce a raggiungere i servizi back-end, nonché le eccezioni a livello di servizio, potrebbero contenere messaggi non intuitivi e inadatti per la visualizzazione agli utenti finali. Anziché apportare modifiche di codice ai servizi back-end, puoi configurare [risposte personalizzate agli errori](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html) in API Gateway per mappare codici di risposta HTTP a messaggi di errore delle API selezionati. 

1.  Progetta la messaggistica da un punto di vista commerciale in modo che sia pertinente per gli utenti finali del sistema e non contenga dettagli tecnici. Esamina i destinatari e allinea la messaggistica di conseguenza. Ad esempio, potresti indirizzare gli utenti interni a una soluzione alternativa o a un processo manuale che utilizza un sistema alternativo. Potresti richiedere agli utenti esterni di attendere il ripristino del sistema o di iscriversi agli aggiornamenti per ricevere una notifica quando il sistema viene ripristinato. Definisci una messaggistica approvata per più scenari, tra cui interruzioni impreviste, manutenzione pianificata ed errori parziali del sistema in cui una funzionalità specifica potrebbe essere danneggiata o non disponibile. 

1.  Crea modelli per la messaggistica ai clienti e automatizzane la gestione. Dopo aver definito il contenuto dei messaggi, puoi usare [Amazon Pinpoint](https://docs.aws.amazon.com/pinpoint/latest/developerguide/welcome.html) o altri strumenti per automatizzare la campagna di messaggistica. Con Amazon Pinpoint puoi creare segmenti di clientela di destinazione per utenti interessati specifici e trasformare i messaggi in modelli. Consulta il [tutorial su Amazon Pinpoint](https://docs.aws.amazon.com/pinpoint/latest/developerguide/tutorials.html) per informazioni su come configurare una campagna di messaggistica. 

1.  Evita l'accoppiamento stretto di funzionalità di messaggistica con il sistema rivolto ai clienti. La strategia di messaggistica non deve avere rigide dipendenze dai servizi e dagli archivi di dati del sistema, in modo da permettere l'invio corretto di messaggi quando riscontri interruzioni. Valuta se introdurre la possibilità di inviare messaggi da più di [una zona di disponibilità o regione](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_multiaz_region_system.html) ai fini della disponibilità della messaggistica. Se usi servizi AWS per inviare messaggi, utilizza operazioni del piano dati anziché [operazioni del piano di controllo (control-plane)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html) per richiamare la messaggistica. 

 **Livello di impegno per il piano di implementazione:** elevato Lo sviluppo di un piano di comunicazione e del suo meccanismo di invio può richiedere un impegno significativo. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS07-BP03 Utilizzo di runbook per eseguire le procedure](ops_ready_to_support_use_runbooks.md) – Al piano di comunicazione deve essere associato un runbook, in modo che il personale sappia come rispondere. 
+  [OPS11-BP02 Esecuzione di analisi post-incidente](ops_evolve_ops_perform_rca_process.md) – Dopo un'interruzione, esegui un'analisi post-incidente per evitarne altre. 

 **Documenti correlati:** 
+ [ Modelli di gestione degli errori in Amazon API Gateway e AWS Lambda](https://aws.amazon.com/blogs/compute/error-handling-patterns-in-amazon-api-gateway-and-aws-lambda/)
+ [ Risposte di Amazon API Gateway ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html#supported-gateway-response-types)

 **Esempi correlati:** 
+ [ Dashboard AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/)
+ [ Riepilogo dell'evento di assistenza AWS nella regione della Virginia settentrionale (US-EAST-1) ](https://aws.amazon.com/message/12721/)

 **Servizi correlati:** 
+ [Supporto AWS](https://aws.amazon.com/premiumsupport/)
+ [ Accordo cliente AWS](https://aws.amazon.com/agreement/)
+ [ Amazon CloudFront ](https://aws.amazon.com/cloudfront/)
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [ Amazon Pinpoint ](https://aws.amazon.com/pinpoint/)
+ [ Amazon S3 ](https://aws.amazon.com/s3/)

# OPS10-BP06 Comunicazione dello stato tramite pannelli di controllo
<a name="ops_event_response_dashboards"></a>

 Fornisci pannelli di controllo personalizzati in base ai destinatari, ad esempio i team tecnici interni, la dirigenza e i clienti, per comunicare lo stato operativo corrente del business e fornire i parametri desiderati. 

 Puoi creare pannelli di controllo utilizzando [Amazon CloudWatch Dashboards](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) sulle home page personalizzabili nella console di CloudWatch. Utilizzando servizi di business intelligence come [Quick](https://aws.amazon.com/quicksight/) è possibile creare e pubblicare pannelli di controllo interattivi sullo stato del carico di lavoro e delle operazioni (ad esempio tassi di ordinazione, utenti connessi e tempi di transazione). Crea pannelli di controllo che mostrino visualizzazioni dei parametri a livello di sistema e a livello di azienda. 

 **Anti-pattern comuni:** 
+  Su richiesta, esegui un report sull'utilizzo corrente dell'applicazione per la gestione. 
+  Durante un incidente, vieni contattato ogni 20 minuti da un responsabile di sistema preoccupato, che desidera sapere se il problema è stato risolto. 

 **Vantaggi dell'adozione di questa best practice:** Creando pannelli di controllo, abiliti l'accesso self-service alle informazioni consentendo ai clienti di informarsi autonomamente e decidere se devono intervenire. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Comunicazione dello stato tramite pannelli di controllo: fornisci pannelli di controllo personalizzati in base ai destinatari, ad esempio i team tecnici, la leadership e i clienti, per comunicare l'attuale stato operativo del business e fornire i parametri rilevanti. Offrire un'opzione self-service per le informazioni di stato riduce le interruzioni derivanti dalla gestione delle richieste di stato da parte dei team operativi. Ne sono esempi i pannelli di controllo di Amazon CloudWatch e Dashboard AWS Health. 
  +  [I pannelli di controllo di CloudWatch creano e utilizzano visualizzazioni dei parametri personalizzate](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Quick](https://aws.amazon.com/quicksight/) 
+  [I pannelli di controllo di CloudWatch creano e utilizzano visualizzazioni dei parametri personalizzate](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 

# OPS10-BP07 Automazione delle risposte agli eventi
<a name="ops_event_response_auto_event_response"></a>

 Automatizza le risposte agli eventi per ridurre gli errori causati dai processi manuali e assicurare risposte rapide e coerenti. 

 I modi per automatizzare le azioni di runbook o playbook su AWS sono molteplici. Per rispondere a un evento dovuto a una modifica dello stato nelle risorse AWS o a eventi personalizzati, è necessario creare [regole CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) per attivare risposte tramite destinazioni CloudWatch (ad esempio funzioni Lambda, argomenti Amazon Simple Notification Service (Amazon SNS), attività Amazon ECS e AWS Systems Manager Automation). 

 Per rispondere a un determinato parametro che supera una soglia per una certa risorsa (ad es. il tempo di attesa), è consigliabile creare [avvisi CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) per eseguire una o più azioni utilizzando azioni Amazon EC2 e azioni Auto Scaling o per inviare una notifica a un argomento Amazon SNS. Se è necessario eseguire azioni personalizzate in risposta a un avviso, richiama Lambda con una notifica Amazon SNS. Utilizza Amazon SNS per pubblicare notifiche di eventi e messaggi di escalation, in modo tale che le persone ne siano informate. 

 AWS supporta, inoltre, sistemi di terze parti attraverso API e SDK del servizio AWS. Esistono numerosi strumenti forniti da partner AWS e da terze parti che consentono di monitorare e inviare notifiche e risposte. Alcuni di questi strumenti sono New Relic, Splunk, Loggly, SumoLogic e Datadog. 

 Rendi disponibili le procedure manuali cruciali in modo tale che possano essere utilizzate quando le procedure automatiche non riescono. 

 **Anti-pattern comuni:** 
+  Uno sviluppatore controlla il proprio codice. Questo evento avrebbe potuto essere utilizzato per avviare una compilazione e quindi eseguire il test, ma non accade nulla. 
+  L'applicazione registra un errore specifico prima di smettere di funzionare. La procedura per riavviare l'applicazione è ben nota e può essere creata con script. Puoi utilizzare l'evento di log per richiamare uno script e riavviare l'applicazione. Ricevi, invece, una chiamata alle 3 di domenica mattina, quando si verifica l'errore, perché sei reperibile come risorsa responsabile della correzione del sistema. 

 **Vantaggi dell'adozione di questa best practice:** Utilizzando le risposte automatizzate agli eventi, riduci il tempo necessario per rispondere e limiti l'introduzione di errori da attività manuali. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Bassa 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Automazione delle risposte agli eventi: automatizza le risposte agli eventi per ridurre gli errori causati dai processi manuali e per assicurare risposte rapide e coerenti. 
  +  [Che cos'è Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 
  +  [Creazione di una regola di CloudWatch Events che si attiva al verificarsi di un evento](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html) 
  +  [Creazione di una regola di CloudWatch Events che si attiva con una chiamata API AWS tramite AWS CloudTrail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html) 
  +  [Esempi di eventi CloudWatch Events dai servizi supportati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Funzionalità di Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) 
+  [Esempi di eventi CloudWatch Events dai servizi supportati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html) 
+  [Creazione di una regola di CloudWatch Events che si attiva con una chiamata API AWS tramite AWS CloudTrail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html) 
+  [Creazione di una regola di CloudWatch Events che si attiva al verificarsi di un evento](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html) 
+  [Che cos'è Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 

 **Video correlati:** 
+  [Creazione di un piano di monitoraggio](https://www.youtube.com/watch?v=OMmiGETJpfU) 

 **Esempi correlati:** 

# Evoluzione
<a name="a-evolve"></a>

**Topics**
+ [OPS 11. In che modo fai evolvere le operazioni?](ops-11.md)

# OPS 11. In che modo fai evolvere le operazioni?
<a name="ops-11"></a>

 Dedica tempo e risorse per ottenere un miglioramento incrementale pressoché continuo, per far evolvere l'efficacia e l'efficienza delle tue operazioni. 

**Topics**
+ [OPS11-BP01 Definizione di un processo per il miglioramento continuo](ops_evolve_ops_process_cont_imp.md)
+ [OPS11-BP02 Esecuzione di analisi post-incidente](ops_evolve_ops_perform_rca_process.md)
+ [OPS11-BP03 Implementazione di cicli di feedback](ops_evolve_ops_feedback_loops.md)
+ [OPS11-BP04 Gestione delle informazioni](ops_evolve_ops_knowledge_management.md)
+ [OPS11-BP05 Definizione dei fattori che promuovono il miglioramento](ops_evolve_ops_drivers_for_imp.md)
+ [OPS11-BP06 Convalida delle informazioni](ops_evolve_ops_validate_insights.md)
+ [OPS11-BP07 Revisione dei parametri delle operazioni](ops_evolve_ops_metrics_review.md)
+ [OPS11-BP08 Documentazione e condivisione delle conoscenze acquisite](ops_evolve_ops_share_lessons_learned.md)
+ [OPS11-BP09 Allocazione di tempo per i miglioramenti](ops_evolve_ops_allocate_time_for_imp.md)

# OPS11-BP01 Definizione di un processo per il miglioramento continuo
<a name="ops_evolve_ops_process_cont_imp"></a>

Valuta il carico di lavoro rispetto alle best practice dell'architettura interna ed esterna. Effettua revisioni del carico di lavoro almeno una volta all'anno. Dai priorità alle opportunità di miglioramento nella cadenza di sviluppo del software. 

 **Risultato desiderato:** 
+  Analizza il carico di lavoro rispetto alle best practice dell'architettura almeno una volta all'anno. 
+  Le opportunità di miglioramento hanno la stessa priorità nel processo di sviluppo del software. 

 **Anti-pattern comuni:** 
+ Non hai condotto una revisione dell'architettura del carico di lavoro da quando è stato distribuito diversi anni fa.
+ Le opportunità di miglioramento hanno una priorità inferiore e rimangono nel backlog.
+  Non esiste uno standard per l'implementazione delle modifiche alle best practice per l'organizzazione. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Il carico di lavoro è aggiornato sulla base delle best practice di architettura. 
+  L'evoluzione del carico di lavoro avviene in modo deliberato. 
+  Si possono sfruttare le best practice dell'organizzazione per migliorare tutti i carichi di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Almeno una volta all'anno, si effettua una revisione architettonica del proprio carico di lavoro. Utilizzando le best practice interne ed esterne, valuta il carico di lavoro e identifica le opportunità di miglioramento. Dai priorità alle opportunità di miglioramento nella cadenza di sviluppo del software. 

 **Esempio del cliente** 

 Tutti i carichi di lavoro di AnyCompany Retail sono sottoposti a un processo di revisione dell'architettura annuale. Hanno sviluppato una checklist di best practice che applicano a tutti i carichi di lavoro. Con la funzionalità Obiettivo personalizzato di AWS Well-Architected Tool eseguono le revisioni usando lo strumento e i propri obiettivi personalizzati delle best practice. Alle opportunità di miglioramento generate dalle revisioni viene data priorità nei loro sprint software. 

 **Passaggi dell'implementazione** 

1.  Esegui almeno una volta all'anno una revisione periodica dell'architettura del carico di lavoro di produzione. Utilizza uno standard architettonico documentato che includa best practice specifiche di AWS. 

   1.  Per queste revisioni ti consigliamo di usare standard definiti internamente. Se non hai standard interni ti consigliamo di usare AWS Well-Architected Framework. 

   1.  È possibile usare AWS Well-Architected Tool per creare un Obiettivo personalizzato delle best practice interne e condurre la revisione dell'architettura. 

   1.  I clienti possono contattare il proprio Solutions Architect AWS per effettuare una revisione guidata Well-Architected Framework del proprio carico di lavoro. 

1.  Dai priorità alle opportunità di miglioramento identificate durante la revisione nel processo di sviluppo del software. 

 **Livello di impegno per il piano di implementazione:** Basso. Si può usare AWS Well-Architected Framework per eseguire la revisione annuale dell'architettura. 

### Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS11-BP02 Esecuzione di analisi post-incidente](ops_evolve_ops_perform_rca_process.md) - Analisi post-incidente è un altro generatore di elementi di miglioramento. Inserisci le lezioni apprese nell'elenco interno di best practice per l'architettura. 
+  [OPS11-BP08 Documentazione e condivisione delle conoscenze acquisite](ops_evolve_ops_share_lessons_learned.md) - Quando sviluppi le ibest practice di architettura, condividile con l'organizzazione. 

 **Documenti correlati:** 
+ [AWS Well-Architected Tool - Obiettivi personalizzati ](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [ Whitepaper AWS Well-Architected - Il processo di revisione ](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-review-process.html)
+ [ Personalizza le revisioni Well-Architected con obiettivi personalizzati e AWS Well-Architected Tool](https://aws.amazon.com/blogs/mt/customize-well-architected-reviews-using-custom-lenses-and-the-aws-well-architected-tool/)
+ [ Implementazione del ciclo di vita dell'obiettivo personalizzato AWS Well-Architected nella tua organizzazione ](https://aws.amazon.com/blogs/architecture/implementing-the-aws-well-architected-custom-lens-lifecycle-in-your-organization/)

 **Video correlati:** 
+ [ Well-Architected Labs - Level 100: obiettivo personalizzato su AWS Well-Architected Tool](https://www.wellarchitectedlabs.com/well-architectedtool/100_labs/100_custom_lenses_on_watool/)

 **Esempi correlati:** 
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)

# OPS11-BP02 Esecuzione di analisi post-incidente
<a name="ops_evolve_ops_perform_rca_process"></a>

 Esamina gli eventi che influiscono sui clienti e identifica i fattori che contribuiscono e le azioni preventive. Utilizza queste informazioni per sviluppare modi per limitare o prevenire il ripetersi degli incidenti. Sviluppa procedure per attivare risposte rapide ed efficaci. Comunica i fattori che hanno contribuito al presentarsi dell'imprevisto e le azioni correttive secondo necessità, specificamente mirate per il pubblico di destinazione. 

 **Anti-pattern comuni:** 
+  Sei amministratore di un server di applicazioni. Circa ogni 23 ore e 55 minuti tutte le sessioni attive vengono terminate. Hai tentato di identificare ciò che non va a buon fine sul server di applicazioni. Sospetti che potrebbe trattarsi di un problema di rete, ma non riesci a ottenere la collaborazione dal team di rete perché i suoi membri sono troppo occupati per supportarti. Ti manca un processo predefinito da seguire per ottenere supporto e raccogliere le informazioni necessarie per stabilire che cosa sta accadendo. 
+  Si è verificata una perdita di dati all'interno del carico di lavoro. Questa è la prima volta che si è verificata e la causa non è immediatamente identificabile. Decidi che non è importante perché puoi ricreare i dati. La perdita di dati inizia a verificarsi con maggiore frequenza e influisce sui clienti. Questo comporta inoltre un ulteriore onere operativo quando ripristini i dati mancanti. 

 **Vantaggi dell'adozione di questa best practice:** Avere un processo predefinito per determinare i componenti, le condizioni, le azioni e gli eventi che hanno contribuito a un incidente consente di identificare le opportunità di miglioramento. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Utilizzo di un processo per determinare i fattori che contribuiscono al verificarsi di un incidente: esamina tutti gli incidenti che influiscono sul cliente. Predisponi un processo per identificare e documentare i fattori che contribuiscono a un incidente, in modo da sviluppare azioni di mitigazione in grado di limitare o impedire il suo ripetersi e per sviluppare procedure che consentano risposte rapide ed efficaci. Condividi la causa principale nel modo appropriato, personalizzando la comunicazione in base ai destinatari. 

# OPS11-BP03 Implementazione di cicli di feedback
<a name="ops_evolve_ops_feedback_loops"></a>

I cicli di feedback forniscono informazioni fruibili che guidano il processo decisionale. Vanno creati nelle procedure e nei carichi di lavoro per identificare i problemi e le aree che necessitano di miglioramenti. Inoltre, convalidano gli investimenti effettuati nei miglioramenti. Questi cicli di feedback sono la base per migliorare continuamente il carico di lavoro.

 I cicli di feedback si dividono in due categorie: *feedback immediato* e *analisi retrospettiva*. Il feedback immediato viene raccolto con la revisione delle prestazioni e dei risultati delle attività operative. Questo feedback proviene dai membri del team, dai clienti o dall'output automatizzato dell'attività. Il feedback immediato viene ricevuto ad esempio dal test A/B e dall'offerta di nuove funzionalità, ed è essenziale per anticipare l'errore (fail fast). 

 L'analisi retrospettiva viene eseguita regolarmente per acquisire il feedback della revisione dei risultati operativi e dei parametri nel tempo. Queste retrospettive si svolgono alla fine di uno sprint, in base a una cadenza o dopo importanti rilasci o eventi. Questo tipo di ciclo di feedback convalida gli investimenti nelle operazioni o nel carico di lavoro, consente di misurare il successo e comprova la tua strategia. 

 **Risultato desiderato:** l'uso del feedback immediato e dell'analisi retrospettiva per guidare i miglioramenti. L'applicazione di un meccanismo per acquisire il feedback di utenti e membri del team. L'uso dell'analisi retrospettiva per identificare le tendenze che guidano i miglioramenti. 

 **Anti-pattern comuni:** 
+ Lanci una nuova funzionalità ma non hai modo di ricevere il feedback dei clienti.
+ Dopo aver investito in miglioramenti delle operazioni, non conduci una retrospettiva per convalidare gli investimenti.
+ Raccogli il feedback dei clienti ma non lo esamini regolarmente.
+ I cicli di feedback portano alla proposta di elementi di azione non sono inclusi nel processo di sviluppo software.
+  I clienti non ricevono un feedback sui miglioramenti che hanno proposto. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Puoi lavorare a ritroso con il cliente per promuovere nuove funzionalità. 
+  La cultura della tua organizzazione può reagire più rapidamente ai cambiamenti. 
+  Le tendenze vengono utilizzate per identificare le opportunità di miglioramento. 
+  Le retrospettive convalidano gli investimenti effettuati per il carico di lavoro e le operazioni. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 L'implementazione di questa best practice comporta l'utilizzo del feedback immediato e dell'analisi retrospettiva. Questi cicli di feedback guidano i miglioramenti. Esistono molti meccanismi per il feedback immediato, inclusi questionari, sondaggi dei clienti o moduli di feedback. La tua organizzazione utilizza anche le retrospettive per identificare le opportunità di miglioramento e convalidare le iniziative. 

 **Esempio del cliente** 

 AnyCompany Retail crea un modulo Web in cui i clienti possono fornire il feedback o segnalare problemi. Durante lo Scrum settimanale, il feedback degli utenti viene valutato dal team di sviluppo software. Il feedback viene regolarmente utilizzato per guidare l'evoluzione della piattaforma. Viene eseguita una retrospettiva alla fine di ogni sprint per identificare gli elementi che devono essere migliorati. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

1. Feedback immediato
   +  Hai bisogno di un meccanismo per ricevere il feedback dai clienti e dai membri del team. Le attività operative possono anche essere configurate per fornire un feedback automatizzato. 
   +  L'organizzazione ha bisogno di un processo per rivedere il feedback, determinare cosa migliorare e pianificare il miglioramento. 
   +  Il feedback deve essere aggiunto al processo di sviluppo software. 
   +  Quando apporti miglioramenti, contatta l'autore del feedback. 
     +  Puoi utilizzare [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) per creare e monitorare questi miglioramenti come [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-working-with-OpsItems.html).

1.  Analisi retrospettiva 
   +  Conduci le retrospettive alla fine di un ciclo di sviluppo, a una cadenza prestabilita o dopo un rilascio importante. 
   +  Riunisci gli stakeholder coinvolti nel carico di lavoro per la riunione retrospettiva. 
   +  Crea tre colonne sulla lavagna o in un foglio di lavoro: Fine, Inizio e Mantenimento. 
     +  *Fine* è per tutto ciò che vuoi che il team smetta di fare. 
     +  *Inizio* è per le idee che vuoi iniziare ad applicare. 
     +  *Mantenimento* è per ciò che vuoi continuare a fare. 
   +  Raccogli il feedback dagli stakeholder. 
   +  Dai priorità al feedback. Assegna le azioni e gli stakeholder a qualsiasi elemento nelle colonne Inizio e Mantenimento. 
   +  Aggiungi le azioni al processo di sviluppo software e comunica gli aggiornamenti sullo stato agli stakeholder mentre apporti i miglioramenti. 

 **Livello di impegno per il piano di implementazione:** medio. Per implementare questa best practice è necessario un modo per ricevere il feedback immediato e analizzarlo. Inoltre, è necessario stabilire un processo di analisi retrospettiva. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS01-BP01 Valutazione delle esigenze dei clienti esterni](ops_priorities_ext_cust_needs.md): i cicli di feedback sono un meccanismo per raccogliere le esigenze dei clienti esterni. 
+  [OPS01-BP02 Valutazione delle esigenze dei clienti interni](ops_priorities_int_cust_needs.md): gli stakeholder interni possono utilizzare i cicli di feedback per comunicare necessità e requisiti. 
+  [OPS11-BP02 Esecuzione di analisi post-incidente](ops_evolve_ops_perform_rca_process.md): le analisi successive agli incidenti sono una forma importante di analisi retrospettiva da condurre dopo gli incidenti. 
+  [OPS11-BP07 Revisione dei parametri delle operazioni](ops_evolve_ops_metrics_review.md): le revisioni dei parametri operativi identificano tendenze e aree di miglioramento. 

 **Documenti correlati:** 
+  [7 Pitfalls to Avoid When Building CCOE (7 errori da evitare durante la creazione di un Centro di eccellenza del Cloud (CCoE))](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/) 
+  [Atlassian Team Playbook - Retrospectives (Playbook Atlassian Team - Retrospettive)](https://www.atlassian.com/team-playbook/plays/retrospective) 
+  [Email Definitions: Feedback Loops (Definizioni di e-mail: cicli di feedback)](https://aws.amazon.com/blogs/messaging-and-targeting/email-definitions-feedback-loops/) 
+  [Establishing Feedback Loops Based on the AWS Well-Architected Framework Review (Applicazione dei cicli di feedback in base alla revisione di Framework AWS Well-Architected)](https://aws.amazon.com/blogs/architecture/establishing-feedback-loops-based-on-the-aws-well-architected-framework-review/) 
+  [IBM Garage Methodology - Hold a retrospective (Metodologia IBM Garage - Condurre una retrospettiva)](https://www.ibm.com/garage/method/practices/learn/practice_retrospective_analysis/) 
+  [Investopedia - The PDCS Cycle (Investopedia - Il ciclo PDCA)](https://www.investopedia.com/terms/p/pdca-cycle.asp) 
+  [Maximizing Developer Effectiveness by Tim Cochran (Massimizzazione dell'efficacia degli sviluppatori di Tim Cochran)](https://martinfowler.com/articles/developer-effectiveness.html) 
+  [Operations Readiness Reviews (ORR) Whitepaper - Iteration (Whitepaper per le revisioni della preparazione delle operazioni - Iterazione)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html) 
+  [TIL CSI - Continual Service Improvement (TIL CSI - Miglioramento continuo del servizio)](https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement)
+  [When Toyota met e-commerce: Lean at Amazon (Toyota incontra l'e-commerce: semplificazione con Amazon)](https://www.mckinsey.com/capabilities/operations/our-insights/when-toyota-met-e-commerce-lean-at-amazon) 

 **Video correlati:** 
+  [Building Effective Customer Feedback Loops (Creazione di efficaci cicli di feedback dei clienti)](https://www.youtube.com/watch?v=zz_VImJRZ3U) 

 **Esempi correlati: ** 
+  [Astuto - Open source customer feedback tool (Astuto - Strumento di feedback dei clienti open source)](https://github.com/riggraz/astuto) 
+  [AWS Solutions - QnABot on AWS (Soluzioni AWS - QnABot in AWS)](https://aws.amazon.com/solutions/implementations/qnabot-on-aws/) 
+  [Fider - A platform to organize customer feedback (Fider - Una piattaforma per organizzare il feedback dei clienti)](https://github.com/getfider/fider) 

 **Servizi correlati:** 
+  [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 

# OPS11-BP04 Gestione delle informazioni
<a name="ops_evolve_ops_knowledge_management"></a>

La gestione delle informazioni permette ai membri del team di trovare le informazioni necessarie per svolgere il proprio lavoro. Nella organizzazioni che promuovono la formazione dei propri dipendenti, le informazioni vengono liberamente condivise, migliorando le competenze personali. Le informazioni possono essere vagliate o cercate. Le informazioni sono accurate e aggiornate. Esistono meccanismi per creare nuove informazioni, aggiornare quelle esistenti e archiviare quelle obsolete. L'esempio più comune di una piattaforma di gestione delle informazioni è un sistema di gestione dei contenuti come un Wiki. 

 **Risultato desiderato:** 
+  Accesso per i membri del team a informazioni tempestive e accurate. 
+  Possibilità di eseguire ricerche nelle informazioni. 
+  Presenza di un meccanismo per aggiungere, aggiornare e archiviare le informazioni. 

 **Anti-pattern comuni:** 
+ Assenza di un sistema di archiviazione centrale delle informazioni. I membri del team gestiscono i propri appunti su computer locali.
+  Presenza di un Wiki self-hosted, ma senza alcun meccanismo per la gestione delle informazioni, con informazioni non aggiornate di conseguenza. 
+  Le informazioni mancanti vengono identificate da qualcuno, ma non esiste un processo per richiederne l'aggiunta nel Wiki del team. I dipendenti le aggiungono manualmente ma omettono un passaggio importante, causando un'interruzione. 

 **Vantaggi dell'adozione di questa best practice:** 
+  I membri del team acquisiscono le competenze necessarie perché le informazioni vengono condivise liberamente. 
+  Nuovi membri del team vengono integrati più facilmente perché la documentazione è aggiornata e può essere oggetto di ricerche. 
+  Le informazioni sono tempestive, accurate e di utilità pratica. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 La gestione delle informazioni è un aspetto importante delle aziende che promuovono la formazione dei propri dipendenti. Per iniziare, è necessario un repository centrale in cui archiviare le informazioni, un esempio comune del quale è un Wiki self-hosted. Devi sviluppare processi per l'aggiunta, l'aggiornamento e l'archiviazione delle informazioni. Sviluppa standard per gli aspetti da documentare e permetti a ciascuno di contribuire. 

 **Esempio del cliente** 

 AnyCompany Retail ospita un Wiki interno in cui vengono archiviate tutte le informazioni. I membri del team sono incoraggiati ad aggiungere il proprio input nella knowledge base durante lo svolgimento delle proprie mansioni quotidiane. Ogni trimestre un team interfunzionale valuta le pagine obsolete e determina se devono essere archiviate o aggiornate. 

 **Passaggi dell'implementazione** 

1.  Per iniziare, identifica il sistema di gestione dei contenuti in cui verranno archiviate le informazioni. Ottieni il consenso degli stakeholder in tutta l'organizzazione. 

   1.  Se non possiedi un sistema di gestione dei contenuti, valuta se eseguire un Wiki self-hosted o usare un repository con controllo delle versioni come punto di partenza. 

1.  Sviluppa runbook per l'aggiunta, l'aggiornamento e l'archiviazione delle informazioni. Fornisci ai team la formazione necessaria su questi processi. 

1.  Identifica le informazioni che devono essere archiviate nel sistema di gestione dei contenuti. Inizia dalle attività quotidiane (runbook e playbook) svolte dai membri del team. Collabora con gli stakeholder per classificare in ordine di priorità le informazioni aggiunte. 

1.  Collabora periodicamente con gli stakeholder per identificare le informazioni obsolete e archiviarle o aggiornarle. 

 **Livello di impegno per il piano di implementazione:** medio. Se non possiedi un sistema di gestione dei contenuti, puoi configurare un Wiki self-hosted o un repository di documenti con controllo delle versioni. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [OPS11-BP08 Documentazione e condivisione delle conoscenze acquisite](ops_evolve_ops_share_lessons_learned.md) – La gestione delle informazioni semplifica la condivisione delle conclusioni sulle lezioni apprese. 

 **Documenti correlati:** 
+ [ Atlassian - Knowledge Management ](https://www.atlassian.com/itsm/knowledge-management)

 **Esempi correlati:** 
+ [ DokuWiki ](https://www.dokuwiki.org/dokuwiki)
+ [ Gollum ](https://github.com/gollum/gollum)
+ [ MediaWiki ](https://www.mediawiki.org/wiki/MediaWiki)
+ [ Wiki.js ](https://github.com/Requarks/wiki)

# OPS11-BP05 Definizione dei fattori che promuovono il miglioramento
<a name="ops_evolve_ops_drivers_for_imp"></a>

 Identifica i fattori che promuovono il miglioramento, in modo da valutare e dare priorità alle opportunità. 

 Su AWS, è possibile aggregare i registri di tutte le tue attività operative, i tuoi carichi di lavoro e le tue infrastrutture per creare una cronologia dettagliata dell'attività. Puoi quindi utilizzare gli strumenti AWS per analizzare lo stato delle tue operazioni e del carico di lavoro nel tempo (ad esempio identificare le tendenze, correlare eventi e attività ai risultati, nonché confrontare ed evidenziare le differenze tra ambienti e all'interno di sistemi) per rilevare le opportunità di miglioramento in base ai fattori che hai definito. 

 Potresti utilizzare CloudTrail per tracciare l'attività API (attraverso la Console di gestione AWS, CLI, SDK e API) per scoprire cosa sta succedendo nei tuoi account. Traccia le tue attività di distribuzione degli Strumenti per sviluppatori AWS con CloudTrail e CloudWatch. In questo modo sarà aggiunta ai dati di log di CloudWatch Logs una cronologia dettagliata delle attività delle distribuzioni e dei loro risultati. 

 [Esporta i dati di log in Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) per lo storage a lungo termine. Utilizzando [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc), puoi individuare e preparare i dati di log in Amazon S3 per l'analisi. Utilizzo [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc), attraverso l'integrazione nativa con AWS Glue, per analizzare i dati di registro. Utilizza uno strumento di business intelligence come [Quick](https://aws.amazon.com/quicksight/) per visualizzare, esplorare e analizzare i dati. 

 **Anti-pattern comuni:** 
+  Hai uno script che funziona ma non è scritto nel modo migliore. Dedichi del tempo alla sua riscrittura. Ora è un'opera d'arte. 
+  La tua start-up sta cercando di ottenere un'altra serie di finanziamenti da un investitore in capitali di rischio. Ti viene richiesto di dimostrare la conformità allo standard PCI DSS. Per documentare la conformità non riesci a rispettare una data di consegna e, di conseguenza, perdi un cliente. Non era una scelta sbagliata ma ora ti chiedi se fosse la cosa giusta da fare. 

 **Vantaggi dell'adozione di questa best practice:** Stabilendo quali criteri desideri utilizzare per migliorare, puoi ridurre al minimo l'impatto delle motivazioni basate sugli eventi o degli investimenti influenzati da fattori emotivi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Comprensione dei fattori che promuovono il miglioramento: è consigliabile apportare modifiche a un sistema solo quando un risultato desiderato è supportato. 
  +  Funzionalità desiderate: prendi in considerazione le funzionalità e le capacità desiderate quando valuti le opportunità di miglioramento. 
    +  [Novità di AWS](https://aws.amazon.com/new/) 
  +  Problemi inaccettabili: tieni in considerazione i problemi, i bug e le vulnerabilità inaccettabili quando valuti le opportunità di miglioramento. 
    +  [Ultimi bollettini di sicurezza AWS](https://aws.amazon.com/security/security-bulletins/) 
    +  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
  +  Requisiti di conformità: quando esamini le opportunità di miglioramento, prendi in considerazione gli aggiornamenti e le modifiche necessarie per mantenere la conformità a normative e policy o per avere diritto al supporto di terze parti. 
    +  [Conformità di AWS](https://aws.amazon.com/compliance/) 
    +  [Programmi per la conformità di AWS](https://aws.amazon.com/compliance/programs/) 
    +  [Ultime novità sulla conformità di AWS](https://aws.amazon.com/compliance/compliance-latest-news/) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) 
+  [Quick](https://aws.amazon.com/quicksight/) 
+  [Conformità di AWS](https://aws.amazon.com/compliance/) 
+  [Ultime novità sulla conformità di AWS](https://aws.amazon.com/compliance/compliance-latest-news/) 
+  [Programmi per la conformità di AWS](https://aws.amazon.com/compliance/programs/) 
+  [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) 
+  [Ultimi bollettini di sicurezza AWS](https://aws.amazon.com/security/security-bulletins/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [Esporta i dati di log in Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 
+  [Novità di AWS](https://aws.amazon.com/new/) 

# OPS11-BP06 Convalida delle informazioni
<a name="ops_evolve_ops_validate_insights"></a>

 Rivedi i risultati dell'analisi e le risposte con i team trasversali e i proprietari dell'azienda. Utilizza queste revisioni per definire una visione comune, identificare ulteriori impatti e stabilire le linee d'azione. Adatta le risposte, se necessario. 

 **Anti-pattern comuni:** 
+  Noti che su un sistema l'utilizzo della CPU è al 95% e decidi che è prioritario trovare un modo per ridurre il carico sul sistema. Stabilisci che la soluzione migliore è dimensionare verso l'alto. Il sistema, un transcodificatore, è stato calibrato per funzionare con un utilizzo costante della CPU al 95%. Se l'avessi contattato, il responsabile del sistema avrebbe potuto spiegarti la situazione. Hai sprecato il tuo tempo. 
+  Il responsabile di un sistema ritiene che il sistema sia mission critical. Il sistema non è stato inserito in un ambiente a sicurezza elevata. Per migliorare la sicurezza, adotti i controlli di rilevazione e prevenzione aggiuntivi necessari per i sistemi mission critical. Comunichi al proprietario del sistema che il lavoro è completo e che gli verranno addebitati i costi per le risorse aggiuntive. Nella discussione che segue a questa notifica, il responsabile del sistema apprende che esiste una definizione formale di mission critical che il suo sistema non soddisfa. 

 **Vantaggi dell'adozione di questa best practice:** Convalidando le informazioni con i responsabili aziendali e con gli esperti in materia, è possibile stabilire una comprensione comune e gestire il miglioramento in modo più efficace. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Convalida delle informazioni: interagisci con i responsabili aziendali e gli esperti in materia per garantire la comprensione e l'accordo comuni sul significato dei dati raccolti. Individua ulteriori problemi e impatti potenziali e stabilisci le azioni da intraprendere. 

# OPS11-BP07 Revisione dei parametri delle operazioni
<a name="ops_evolve_ops_metrics_review"></a>

 Esegui regolarmente un'analisi retrospettiva dei parametri operativi con i partecipanti di vari team da diverse aree del business. Utilizza queste revisioni per identificare opportunità di miglioramento e potenziali linee d'azione e per condividere le conoscenze acquisite. 

 Cerca opportunità di miglioramento in tutti i tuoi ambienti (per esempio sviluppo, test e produzione). 

 **Anti-pattern comuni:** 
+  Un'importante promozione al dettaglio è stata interrotta da uno dei tuoi interventi di manutenzione. L'azienda non è al corrente del fatto che i normali interventi di manutenzione possono essere rimandati nel caso vi siano altri eventi di particolare rilievo per l'azienda. 
+  Per l'uso di una libreria contenente degli errori comunemente utilizzata nella tua organizzazione si è verificata una prolungata interruzione del servizio. Successivamente hai eseguito la migrazione a una libreria affidabile. Gli altri team della tua organizzazione non sanno di essere a rischio. Se si svolgessero incontri periodici durante i quali esaminare questo incidente, anch'essi sarebbero al corrente del rischio. 
+  Le prestazioni del transcodificatore hanno avuto un peggioramento, con conseguenti problemi prolungati per il team multimediale. Il problema non è ancora grave e non lo diventerà finché non sarà tanto avanzato da provocare un incidente. Se esaminassi i parametri operativi con il team multimediale, ci sarebbe l'occasione di modificare i parametri, riconoscendo l'esperienza dei tuoi interlocutori e affrontando il problema. 
+  Non stai tenendo sotto controllo i contratti sul livello di servizio (SLA) che misurano la soddisfazione dei clienti. Le tendenze indicano un andamento negativo per quanto riguarda il rispetto degli SLA. In caso di mancato rispetto degli SLA, sono previste sanzioni economiche. Se si tenessero incontri periodici per esaminare i parametri di questi Accordi sul livello di servizio (SLA), ci sarebbe l'opportunità riconoscere e risolvere il problema. 

 **Vantaggi dell'adozione di questa best practice:** riunendosi regolarmente per esaminare i parametri operativi, gli eventi e gli incidenti, si mantiene una comprensione comune tra i team e si condividono i risultati ottenuti, assegnando priorità e indirizzando i miglioramenti in modo più preciso. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Revisioni dei parametri operativi: esegui regolarmente un'analisi retrospettiva dei parametri operativi con i partecipanti di vari team da diverse aree del business. Coinvolgi i soggetti interessati, compresi i team che si occupano di business, sviluppo e operazioni, per convalidare ciò che è emerso dal feedback immediato e dall'analisi retrospettiva e per condividere le conoscenze acquisite. Utilizza le informazioni di cui dispongono per identificare opportunità di miglioramento e possibili linee d'azione. 
  +  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 
  +  [Utilizzare i parametri Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
  +  [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
  +  [Documentazione di riferimento su parametri e dimensioni di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [Documentazione di riferimento su parametri e dimensioni di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
+  [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Utilizzare i parametri Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 

# OPS11-BP08 Documentazione e condivisione delle conoscenze acquisite
<a name="ops_evolve_ops_share_lessons_learned"></a>

 Documenta e condividi le conoscenze acquisite durante le attività operative per metterle a frutto internamente e nei vari team. 

 La condivisione di quanto appreso dai team comporta maggiori vantaggi all'interno dell'organizzazione. Dovrai condividere informazioni e risorse per impedire che si verifichino errori evitabili, nonché semplificare le attività di sviluppo. In questo modo potrai concentrarti sulla distribuzione delle funzionalità desiderate. 

 Utilizza AWS Identity and Access Management (IAM) per definire i permessi che consentono un accesso controllato alle risorse che desideri condividere all'interno e tra i vari account. Dovrai utilizzare repository AWS CodeCommit dotati di controllo versione per condividere librerie dell'applicazione, procedure di scripting, documentazione di procedure e altra documentazione di sistema. Metti a disposizione i tuoi standard di elaborazione condividendo l'accesso ai tuoi AMI e fornendo l'autorizzazione a utilizzare le tue funzioni Lambda nei vari account. È consigliabile condividere i tuoi standard infrastrutturali come modelli AWS CloudFormation. 

 Grazie ad API e SDK di AWS, hai modo di integrare strumenti e repository esterni e di parti terze (ad es. GitHub, BitBucket e SourceForge). Quando condividi ciò che hai appreso e sviluppato, fai attenzione a strutturare i permessi in modo tale da garantire l'integrità dei repository condivisi. 

 **Anti-pattern comuni:** 
+  Per l'uso di una libreria contenente degli errori comunemente utilizzata nella tua organizzazione si è verificata una prolungata interruzione del servizio. Successivamente hai eseguito la migrazione a una libreria affidabile. Gli altri team della tua organizzazione non sanno di essere a rischio. Se tu documentassi e condividessi la tua esperienza con questa libreria, sarebbero al corrente del rischio. 
+  Hai identificato un caso limite in un microservizio condiviso internamente che causa l'interruzione delle sessioni. Hai aggiornato le chiamate al servizio per evitare questo caso limite. Gli altri team della tua organizzazione non sanno di essere a rischio. Se tu documentassi e condividessi la tua esperienza con questa libreria, sarebbero al corrente del rischio. 
+  Hai trovato un modo per ridurre in modo significativo i requisiti di utilizzo della CPU per uno dei tuoi microservizi. Non sai se altri team potrebbero sfruttare questa tecnica. Se tu documentassi e condividessi la tua esperienza con questa libreria, avrebbero l'opportunità di farlo. 

 **Vantaggi dell'adozione di questa best practice:** condividere le lezioni apprese a supporto del miglioramento e per trarre il massimo vantaggio dall'esperienza. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Documentazione e condivisione delle conoscenze acquisite: predisponi procedure per documentare le conoscenze acquisite dall'esecuzione delle attività operative e dalle analisi retrospettive affinché tali informazioni possano essere utilizzate dal altri team. 
  +  Condividi le conoscenze acquisite: predisponi procedure per condividere con tutti i team le conoscenze acquisite e gli artefatti associati. Ad esempio condividi le procedure, le istruzioni, la governance e le best practice aggiornate tramite un wiki accessibile. Condividi script, codice e librerie tramite un repository comune. 
    +  [Delega dell'accesso all'ambiente AWS](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s) 
    +  [Condivisione di un repository AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html) 
    +  [Autorizzazione semplificata delle funzioni AWS Lambda](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/) 
    +  [Condivisione di un'AMI con account AWS specifici](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) 
    +  [Condivisione più rapida dei modelli con un URL di AWS CloudFormation Designer](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/) 
    +  [Utilizzo di AWS Lambda con Amazon SNS](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Autorizzazione semplificata delle funzioni AWS Lambda](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/) 
+  [Condivisione di un repository AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html) 
+  [Condivisione di un'AMI con account AWS specifici](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) 
+  [Condivisione più rapida dei modelli con un URL di AWS CloudFormation Designer](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/) 
+  [Utilizzo di AWS Lambda con Amazon SNS](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html) 

 **Video correlati:** 
+  [Delega dell'accesso all'ambiente AWS](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s) 

# OPS11-BP09 Allocazione di tempo per i miglioramenti
<a name="ops_evolve_ops_allocate_time_for_imp"></a>

 Dedica tempo e risorse all'interno dei processi per rendere possibile il miglioramento incrementale continuo. 

 Su AWS puoi creare duplicati temporanei paralleli di ambienti per ridurre il rischio, lo sforzo e il costo della sperimentazione e dell'esecuzione di test. Questi ambienti duplicati possono essere utilizzati per testare le conclusioni di analisi ed esperimenti, ma anche per sviluppare e testare i miglioramenti pianificati. 

 **Anti-pattern comuni:** 
+  Si è verificato un problema di prestazioni noto nel server di applicazioni. Il problema viene aggiunto al backlog, dopo l'implementazione prevista delle varie funzionalità. Se la velocità con cui vengono aggiunte le funzionalità pianificate rimane costante, il problema di prestazioni non verrà mai risolto. 
+  Per supportare il miglioramento continuo, autorizzi amministratori e sviluppatori a utilizzare tutto il loro tempo aggiuntivo per selezionare e implementare miglioramenti. I miglioramenti non vengono mai completati. 

 **Vantaggi dell'adozione di questa best practice:** Dedicando tempo e risorse all'interno dei processi, renderai possibile il miglioramento incrementale continuo. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Bassa 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Allocazione di tempo per apportare miglioramenti: dedica tempo e risorse all'interno dei processi per rendere possibili miglioramenti graduali e continui. Implementa modifiche per migliorare e valutare i risultati per favorire il successo. Se i risultati non sono in linea con gli obiettivi e il miglioramento resta prioritario, valuta linee d'azione alternative. 

# Sicurezza
<a name="a-security"></a>

Il pilastro della sicurezza contempla la capacità di proteggere dati, sistemi e asset per sfruttare le tecnologie cloud in modo da migliorare la sicurezza. È possibile trovare linee guida prescrittive sull'implementazione nel [Whitepaper sul principio della sicurezza](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html?ref=wellarchitected-wp). 

**Topics**
+ [Nozioni di base sulla sicurezza](a-sec-security.md)
+ [Gestione di identità e accessi](a-identity-and-access-management.md)
+ [Rilevamento](a-detective-controls.md)
+ [Protezione dell’infrastruttura](a-infrastructure-protection.md)
+ [Protezione dei dati](a-data-protection.md)
+ [Risposta agli imprevisti](a-incident-response.md)
+ [Sicurezza delle applicazioni](a-appsec.md)

# Nozioni di base sulla sicurezza
<a name="a-sec-security"></a>

**Topics**
+ [SEC 1. Come gestire un carico di lavoro in sicurezza?](sec-01.md)

# SEC 1. Come gestire un carico di lavoro in sicurezza?
<a name="sec-01"></a>

 Per gestire il carico di lavoro in modo sicuro, è necessario applicare le best practice globali a ogni area di sicurezza. Segui i requisiti e i processi definiti in termini di eccellenza operativa a livello organizzativo e di carico di lavoro e applicali a tutte le aree. Rimanere aggiornati con le raccomandazioni di AWS e del settore nonché con l'intelligence sulle minacce aiuta a sviluppare il modello di rischio e gli obiettivi di controllo. L'automazione dei processi di sicurezza, i test e la convalida permettono di dimensionare le operazioni di sicurezza. 

**Topics**
+ [SEC01-BP01 Separazione dei carichi di lavoro tramite account](sec_securely_operate_multi_accounts.md)
+ [SEC01-BP02 Utente root e proprietà dell'account sicuro](sec_securely_operate_aws_account.md)
+ [SEC01-BP03 Identificazione e convalida degli obiettivi di controllo](sec_securely_operate_control_objectives.md)
+ [SEC01-BP04 Aggiornamento costante sulle minacce alla sicurezza](sec_securely_operate_updated_threats.md)
+ [SEC01-BP05 Aggiornamento costante sulle raccomandazioni di sicurezza](sec_securely_operate_updated_recommendations.md)
+ [SEC01-BP06 Automatizzazione dei test e della convalida dei controlli di sicurezza nelle pipeline](sec_securely_operate_test_validate_pipeline.md)
+ [SEC01-BP07 Identificare le minacce e dare priorità alle mitigazioni utilizzando un modello di minaccia.](sec_securely_operate_threat_model.md)
+ [SEC01-BP08 Valutazione e implementazione periodiche di nuovi servizi e funzionalità di sicurezza](sec_securely_operate_implement_services_features.md)

# SEC01-BP01 Separazione dei carichi di lavoro tramite account
<a name="sec_securely_operate_multi_accounts"></a>

 Definisci guardrail e isolamento comuni tra ambienti (ad esempio quelli di produzione, sviluppo e test) e carichi di lavoro attraverso una strategia multi-account. La separazione a livello di account è fortemente consigliata, in quanto fornisce un solido margine di isolamento per la sicurezza, la fatturazione e l'accesso. 

**Risultato desiderato:** una struttura di account che isola le operazioni cloud, i carichi di lavoro non correlati e gli ambienti in account separati, aumentando la sicurezza dell'infrastruttura cloud.

**Anti-pattern comuni:**
+  Inserimento di più carichi di lavoro non correlati con diversi livelli di sensibilità dei dati nello stesso account.
+  Struttura dell'unità organizzativa (UO) scarsamente definita.

**Vantaggi dell'adozione di questa best practice:**
+  Riduzione dell'impatto in caso di accesso involontario a un carico di lavoro.
+  Governance centralizzata dell'accesso a risorse, regioni e servizi AWS.
+  Garanzia di sicurezza dell'infrastruttura cloud con policy e amministrazione centralizzata dei servizi di sicurezza.
+  Processo automatizzato di creazione e mantenimento dell'account.
+  Audit centralizzato della tua infrastruttura per la conformità e i requisiti normativi.

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Gli Account AWS offrono un confine di isolamento della sicurezza tra carichi di lavoro o risorse che operano a livelli di sensibilità diversi. AWS fornisce strumenti per gestire i carichi di lavoro del cloud su larga scala attraverso una strategia multi-account per sfruttare questo margine di isolamento. Per avere una guida su concetti, modelli e implementazione di una strategia multi-account su AWS, consulta [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) (Organizzazione dell'ambiente AWS con l'utilizzo di account multipli). 

 Se si dispone di più Account AWS, gli account devono essere organizzati in una gerarchia definita da livelli di unità organizzative (UO). I controlli di sicurezza possono quindi essere organizzati e applicati alle unità organizzative e agli account membri, stabilendo controlli preventivi coerenti sugli account membri dell'organizzazione. I controlli di sicurezza sono ereditati e consentono di filtrare le autorizzazioni disponibili per gli account membro situati ai livelli inferiori di una gerarchia di unità organizzative. Un buon progetto sfrutta questa ereditarietà per ridurre il numero e la complessità delle policy di sicurezza necessarie per ottenere i controlli desiderati per ogni account membro. 

 [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) e [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) sono due servizi che possono essere utilizzati per implementare e gestire questa struttura multi-account nel proprio ambiente AWS. AWS Organizations consente di organizzare gli account in una gerarchia definita da uno o più livelli di unità organizzative, ognuna delle quali contiene una serie di account membri. Le [policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) consentono all'amministratore dell'organizzazione di stabilire controlli preventivi granulari sugli account dei membri, mentre [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html) può essere utilizzato per stabilire controlli proattivi e investigativi sugli account dei membri. Molti servizi AWS [si integrano con AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html) per fornire controlli amministrativi delegati e per eseguire attività specifiche del servizio su tutti gli account dei membri dell'organizzazione. 

 Posizionato sopra AWS Organizations, [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) fornisce un'impostazione delle best practice in un solo clic per un ambiente AWS multi-account con una [zona di destinazione](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html). La zona di destinazione è il punto di ingresso nell'ambiente multi-account stabilito da Control Tower. Control Tower offre diversi [vantaggi](https://aws.amazon.com/blogs/architecture/fast-and-secure-account-governance-with-customizations-for-aws-control-tower/) rispetto a AWS Organizations. Tre sono i vantaggi che consentono di migliorare la governance degli account: 
+  Guardrail di sicurezza obbligatori integrati che vengono applicati automaticamente agli account ammessi nell'organizzazione. 
+  Guardrail opzionali che possono essere attivati o disattivati per un determinato insieme di unità organizzative. 
+  [AWS Control Tower Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) fornisce l'implementazione automatica di account contenenti linee di base e opzioni di configurazione pre-approvate all'interno dell'organizzazione. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  **Progettazione di una struttura organizzativa unitaria:** una struttura di unità organizzative opportunamente studiata riduce l'onere di gestione necessario per creare e mantenere le policy di controllo dei servizi e gli altri controlli di sicurezza. La struttura delle unità organizzative deve essere [allineata alle esigenze aziendali, alla sensibilità dei dati e alla struttura del carico di lavoro.](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/). 

1.  **Creazione di una zona di destinazione per l'ambiente multi-account:** una zona di destinazione fornisce una base di sicurezza e infrastruttura coerente da cui l'organizzazione può sviluppare, lanciare e implementare rapidamente i carichi di lavoro. Puoi utilizzare una [zona di destinazione personalizzata o AWS Control Tower](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/building-landing-zones.html) per orchestrare il tuo ambiente. 

1.  **Realizzazione di guardrail:** implementa guardrail di sicurezza coerenti per il tuo ambiente attraverso la zona di destinazione. AWS Control Tower offre un elenco di controlli implementabili [obbligatori](https://docs.aws.amazon.com/controltower/latest/userguide/mandatory-controls.html) e [facoltativi](https://docs.aws.amazon.com/controltower/latest/userguide/optional-controls.html). I controlli obbligatori vengono implementati automaticamente quando si utilizza Control Tower. Esamina l'elenco dei controlli altamente consigliati e facoltativi e adotta quelli più adatti alle tue esigenze. 

1.  **Accesso limitato a Regioni aggiunte di recente:** per le nuove Regioni AWS, le risorse IAM, ad esempio utenti e ruoli, verranno propagate solo alle Regioni specificate. Questa azione può essere eseguita tramite la [console quando si utilizza Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html) oppure regolando le [policy di autorizzazione IAM in AWS Organizations](https://aws.amazon.com/blogs/security/setting-permissions-to-enable-accounts-for-upcoming-aws-regions/). 

1.  **Presa in esame di AWS [CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)**: StackSets consente di implementare risorse, tra cui policy, ruoli e gruppi IAM in Account AWS e Regioni differenti a partire da un modello approvato. 

## Risorse
<a name="resources"></a>

**Best practice correlate:** 
+ [SEC02-BP04 Fai affidamento su un provider di identità centralizzato](sec_identities_identity_provider.md)

**Documenti correlati:** 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 
+  [Linee guida sugli audit di sicurezza AWS](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+  [IAM Best Practices](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html)(Best Practice IAM) 
+  [Use CloudFormation StackSets to provision resources across multiple Account AWS and regions](https://aws.amazon.com/blogs/aws/use-cloudformation-stacksets-to-provision-resources-across-multiple-aws-accounts-and-regions/) (Utilizzo di StackSet CloudFormation per il provisioning delle risorse su più account e regioni AWS) 
+  [Organizations FAQ](https://aws.amazon.com/organizations/faqs/) (Domande frequenti sulle organizzazioni) 
+  [AWS Organizations Concetti e terminologia](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) 
+  [Best Practices for Service Control Policies in an AWS Organizations Multi-Account Environment (Best practice per le policy di controllo dei servizi di AWS Organizations in un ambiente multi-account)](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/) 
+  [Guida di riferimento per la gestione degli account AWS](https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html) 
+  [Organizzazione dell'ambiente AWS con l'utilizzo di account multipli](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 

**Video correlati:** 
+  [Enable AWS adoption at scale with automation and governance](https://youtu.be/GUMSgdB-l6s) (Consentire l'adozione di AWS su larga scala con l'automazione e la governance) 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) 
+  [Building and Governing Multiple Accounts using AWS Control Tower](https://www.youtube.com/watch?v=agpyuvRv5oo) (Creazione e gestione di account multipli con AWS Control Tower) 
+  [Enable Control Tower for Existing Organizations](https://www.youtube.com/watch?v=CwRy0t8nfgM) (Abilitare la Control Tower per le organizzazioni esistenti) 

**Workshop correlati:** 
+  [Control Tower Immersion Day](https://controltower.aws-management.tools/immersionday/) (Giornata di approfondimento su Control Tower) 

# SEC01-BP02 Utente root e proprietà dell'account sicuro
<a name="sec_securely_operate_aws_account"></a>

 L'utente root è la figura più privilegiata di un Account AWS, ha pieno accesso amministrativo a tutte le risorse dell'account e, in alcuni casi, non può essere limitato dalle policy di sicurezza. Disabilitare l'accesso programmatico all'utente root, stabilire controlli appropriati per l'utente root ed evitare l'uso di routine dell'utente root aiuta a ridurre il rischio di esposizione involontaria delle credenziali root e la conseguente compromissione dell'ambiente cloud. 

**Risultato desiderato: **la sicurezza dell'utente root contribuisce a ridurre la possibilità che si verifichino danni accidentali o intenzionali a causa dell'uso improprio delle credenziali dell'utente root. La creazione di controlli investigativi può anche permettere di avvisare il personale appropriato quando vengono eseguite azioni utilizzando l'utente root.

**Anti-pattern comuni:**
+  Utilizzo dell'utente root per attività diverse da quelle che richiedono le proprie credenziali.  
+  Nessun test dei piani di emergenza su base regolare per verificare il funzionamento delle infrastrutture critiche, dei processi e del personale durante un'emergenza. 
+  Analisi limitata al tipico flusso di accesso all'account, trascurando di considerare o testare metodi alternativi di ripristino dell'account. 
+  Nessuna gestione di DNS, server di posta elettronica e provider telefonici come parte del perimetro di sicurezza critico, in quanto utilizzati nel flusso di recupero degli account. 

 **Vantaggi derivanti dall'adozione di questa best practice:** proteggere l'accesso all'utente root crea la certezza che le azioni del proprio account siano controllate e sottoposte a audit. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 AWS offre molti strumenti per proteggere gli account. Tuttavia, poiché alcune di queste misure non sono abilitate per impostazione predefinita, è necessario intervenire direttamente per implementarle. Queste raccomandazioni sono i passi fondamentali per mettere in sicurezza il proprio Account AWS. Durante l'implementazione di questi passaggi, è importante creare un processo di valutazione e monitoraggio continuo dei controlli di sicurezza. 

 Quando si crea un Account AWS per la prima volta, si inizia con una singola identità che ha accesso completo a tutti i servizi e risorse AWS presenti nell'account. Questa identità è chiamata utente root dell'Account AWS. È possibile accedere come utente root mediante l'indirizzo e-mail e la password usati per creare l'account. A causa dei livelli elevati di accesso concessi all'utente root AWS, è necessario limitare l'uso dell'utente root AWS all'esecuzione di attività che [lo richiedono specificamente](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html). Le credenziali di accesso dell'utente root devono essere tenute sotto stretta sorveglianza e l'autenticazione a più fattori (MFA) deve essere sempre abilitata per l'utente root dell'Account AWS. 

 Oltre al normale flusso di autenticazione per accedere all'utente root utilizzando un nome utente, una password e un dispositivo di autenticazione a più fattori (MFA), esistono flussi di recupero dell'account che consentono di accedere all'utente root dell'Account AWS grazie all'accesso all'indirizzo e-mail e al numero di telefono associati all'account. Pertanto, è altrettanto importante proteggere l'account e-mail dell'utente root a cui vengono inviati l'e-mail di recupero e il numero di telefono associato all'account. Considerare anche le potenziali dipendenze circolari, quando l'indirizzo e-mail associato all'utente root è ospitato su server di posta elettronica o su risorse del servizio dei nomi di dominio (DNS) dello stesso Account AWS. 

 Quando si utilizza AWS Organizations, esistono più Account AWS, ognuno dei quali ha un utente root. Un account è designato come account di gestione e sotto l'account di gestione possono essere aggiunti diversi livelli di account membri. La priorità è proteggere l'utente root dell'account di gestione, quindi occuparsi degli utenti root degli account membri. La strategia per la protezione dell'utente root dell'account di gestione può essere diversa da quella degli utenti root degli account membri ed è possibile effettuare controlli di sicurezza preventivi sugli utenti root degli account membri. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Per stabilire i controlli per l'utente root si consigliano le seguenti fasi di implementazione. Eventuali raccomandazioni sono collegate a [CIS AWS Foundations benchmark versione 1.4.0](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls-1.4.0.html). Oltre a questi passaggi, consulta le [AWS best practice guidelines](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) (Linee guida sulle best practice AWS) per la protezione delle risorse e degli Account AWS. 

 **Controlli preventivi** 

1.  Imposta [informazioni di contatto](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html) accurate per l'account. 

   1.  Queste informazioni vengono utilizzate per il flusso di recupero della password persa, per il flusso di recupero dell'account del dispositivo MFA perso e per le comunicazioni critiche relative alla sicurezza con il team. 

   1.  Utilizza un indirizzo e-mail ospitato dal dominio aziendale, preferibilmente una lista di distribuzione, come indirizzo e-mail dell'utente root. L'utilizzo di una lista di distribuzione piuttosto che dell'account di e-mail di un singolo individuo offre una maggiore ridondanza e continuità di accesso all'account root per lunghi periodi di tempo. 

   1.  Il numero di telefono indicato nelle informazioni di contatto deve essere dedicato e sicuro per questo scopo. Il numero di telefono non deve essere indicato o condiviso con nessuno. 

1.  Non creare chiavi di accesso per l'utente root. Se sono presenti chiavi di accesso, rimuovile (CIS 1.4). 

   1.  Elimina le credenziali programmatiche a lunga durata (chiavi di accesso e segrete) per l'utente root. 

   1.  Se esistono già chiavi di accesso per l'utente root, è necessario passare i processi che utilizzano tali chiavi all'uso di chiavi di accesso temporanee di un ruolo AWS Identity and Access Management (IAM), quindi [eliminare le chiavi di accesso per l'utente root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-access-key.html#root-user-delete-access-key). 

1.  Stabilisci se è necessario memorizzare le credenziali per l'utente root. 

   1.  Se utilizzi AWS Organizations per creare nuovi account membro, la password iniziale dell'utente root sui nuovi account membro è impostata su un valore casuale che non è visibile a te. Considera l'utilizzo del flusso di ripristino della password dal tuo account di gestione di AWS Organization per [ottenere l'accesso all'account membro](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_access-as-root), se necessario. 

   1.  Per gli Account AWS standalone o per l'account di gestione di AWS Organization, considera la creazione e l'archiviazione sicura delle credenziali per l'utente root. Abilita la MFA per l'utente root. 

1.  Abilita i controlli preventivi per gli utenti root degli account membri in ambienti multi-account AWS. 

   1.  Considera di attivare il guardrail preventivo [Disallow Creation of Root Access Keys for the Root User](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-access-keys) (Disabilitare la creazione di chiavi di accesso root per l'utente root) per gli account dei membri. 

   1.  Considera di attivare il guardrail preventivo [Disallow Actions as a Root User](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-auser-actions) (Disabilitare le azioni come utente root) per gli account dei membri. 

1.  Se sono necessarie le credenziali per l'utente root: 

   1.  Utilizza una password complessa. 

   1.  Abilita l'autenticazione a più fattori (MFA) per l'utente root, in particolare per gli account dei manager (paganti) AWS Organizations (CIS 1.5). 

   1.  Considera i dispositivi MFA hardware per la resilienza e la sicurezza, in quanto i dispositivi monouso possono ridurre le possibilità che i dispositivi contenenti i codici MFA vengano riutilizzati per altri scopi. Verifica che i dispositivi hardware MFA alimentati da una batteria siano sostituiti regolarmente. (CIS 1.6) 
      +  Per configurare l'MFA per l'utente root, segui le istruzioni per abilitare un [dispositivo MFA](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_mfa_enable_virtual.html#enable-virt-mfa-for-root) o [virtuale o hardware](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_mfa_enable_physical.html#enable-hw-mfa-for-root). 

   1.  Considera la possibilità di iscrivere più dispositivi MFA per il backup. [Sono consentiti fino a 8 dispositivi MFA per account](https://aws.amazon.com/blogs/security/you-can-now-assign-multiple-mfa-devices-in-iam/). 
      +  Tieni presente che l'iscrizione di più di un dispositivo MFA per l'utente root disabilita automaticamente il [flusso per il recupero dell'account in caso di perdita del dispositivo MFA.](https://aws.amazon.com/premiumsupport/knowledge-center/reset-root-user-mfa/). 

   1.  Conserva la password in modo sicuro e considera le dipendenze circolari se la password viene conservata elettronicamente. Non memorizzare la password in modo tale da richiedere l'accesso allo stesso Account AWS per ottenerla. 

1.  Facoltativo: valuta la possibilità di stabilire un programma di rotazione periodica delle password per l'utente root. 
   +  Le best practice per la gestione delle credenziali dipendono dai requisiti normativi e di policy. Gli utenti root protetti da MFA non dipendono dalla password come unico fattore di autenticazione. 
   +  [La modifica della password dell'utente root](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_passwords_change-root.html) su base periodica riduce il rischio che una password esposta inavvertitamente possa essere utilizzata in modo improprio. 

### Controlli di rilevamento
<a name="detective-controls"></a>
+  Crea allarmi per rilevare l'uso delle credenziali root (CIS 1.7). [L'abilitazione di Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html) monitorerà e segnalerà l'uso delle credenziali API dell'utente root attraverso il rilevamento [RootCredentialUsage](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage). 
+  Valuta e implementa i controlli investigativi inclusi in [AWS Well-Architected Security Pillar conformance pack for AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-wa-Security-Pillar.html) (Pacchetto di conformità del pilastro di sicurezza well-architected di AWS per AWS Conﬁg) oppure, se si utilizza AWS Control Tower, i [controlli fortemente consigliati](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html) disponibili in Control Tower. 

### Guida operativa
<a name="operational-guidance"></a>
+  Stabilisci chi nell'organizzazione deve avere accesso alle credenziali dell'utente root. 
  +  Utilizza una regola a due persone, in modo che nessun individuo abbia accesso a tutte le credenziali necessarie e all'MFA per ottenere l'accesso come utente root. 
  +  Verifica che l'organizzazione, e non un singolo individuo, mantenga il controllo sul numero di telefono e sull'alias e-mail associati all'account (utilizzati per il ripristino della password e il flusso di ripristino MFA). 
+  Utilizza l'utente root solo in via eccezionale (CIS 1.7). 
  +  L'utente root dell’account AWS non deve essere utilizzato per le attività giornaliere e nemmeno per quelle amministrative. Effettua il login come utente root solo per eseguire [attività AWS che lo richiedono](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html). Tutte le altre azioni devono essere eseguite da altri utenti che assumono i ruoli appropriati. 
+  Verifica periodicamente che l'accesso all'utente root sia funzionante, in modo da testare le procedure prima di una situazione di emergenza che richieda l'uso delle credenziali dell'utente root. 
+  Verifica periodicamente che l'indirizzo e-mail associato all'account e quelli elencati in [Alternate Contacts](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html) (Contatti alternativi) funzionino. Monitora queste caselle di posta elettronica per le notifiche di sicurezza che potresti ricevere da abuse@amazon.com. Assicurati inoltre che i numeri di telefono associati all'account siano attivi. 
+  Prepara procedure di risposta agli incidenti per rispondere all'uso improprio dell'account root. Consulta la [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) (Guida alla risposta agli incidenti di sicurezza AWS) e alle best practice riportate nella [sezione Incident Response (Risposta agli incidenti) del whitepaper Security Pillar (Pilastro di sicurezza)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) per ulteriori informazioni sulla creazione di una strategia di risposta agli incidenti del tuo Account AWS. 

## Risorse
<a name="resources"></a>

**Best practice correlate:** 
+ [SEC01-BP01 Separazione dei carichi di lavoro tramite account](sec_securely_operate_multi_accounts.md)
+ [SEC02-BP01 Utilizzo meccanismi di accesso efficaci](sec_identities_enforce_mechanisms.md)
+ [SEC03-BP02 Concessione dell'accesso con privilegio minimo](sec_permissions_least_privileges.md)
+ [SEC03-BP03 Determinazione di un processo per l'accesso di emergenza](sec_permissions_emergency_process.md)
+ [SEC10-BP05 Preassegnazione dell'accesso](sec_incident_response_pre_provision_access.md)

**Documenti correlati:** 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 
+  [Linee guida sugli audit di sicurezza AWS](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+  [IAM Best Practices](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html)(Best Practice IAM) 
+  [Amazon GuardDuty – root credential usage alert](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage) (Amazon GuardDuty – Avviso sull'utilizzo delle credenziali root) 
+  [Step-by-step guidance on monitoring for root credential use through CloudTrail](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls-1.4.0.html#securityhub-cis1.4-controls-1.7) (Guida passo-passo sul monitoraggio dell'uso delle credenziali root tramite CloudTrail) 
+  [Token MFA approvati per l'uso con AWS](https://aws.amazon.com/iam/features/mfa/) 
+  Implementazione di funzionalità di [break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) (accesso di emergenza) su AWS 
+  [Top 10 security items to improve in your Account AWS](https://aws.amazon.com/blogs/security/top-10-security-items-to-improve-in-your-aws-account/) (I 10 principali elementi di sicurezza da migliorare nel proprio account AWS) 
+  [Che cosa devo fare se noto un'attività non autorizzata nel mio Account AWS?](https://aws.amazon.com/premiumsupport/knowledge-center/potential-account-compromise/) 

**Video correlati:** 
+  [Enable AWS adoption at scale with automation and governance](https://youtu.be/GUMSgdB-l6s) (Consentire l'adozione di AWS su larga scala con l'automazione e la governance) 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) 
+  [Limiting use of AWS root credentials](https://youtu.be/SMjvtxXOXdU?t=979) (Restrizioni nell'uso delle credenziali AWS) da AWS re:inforce 2022 – Security best practices with AWS IAM (Best practice di sicurezza con AWS IAM)

**Esempi e laboratori correlati:** 
+  [Laboratorio: Account AWS e utente root](https://www.wellarchitectedlabs.com/security/100_labs/100_aws_account_and_root_user/) 

# SEC01-BP03 Identificazione e convalida degli obiettivi di controllo
<a name="sec_securely_operate_control_objectives"></a>

 In base ai requisiti di conformità e ai rischi identificati dal modello di rischio, deriva e convalida gli obiettivi di controllo e i controlli da applicare al carico di lavoro. La convalida continua degli obiettivi di controllo e dei controlli aiuta a misurare l'efficacia della mitigazione dei rischi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Identifica i requisiti di conformità. Scopri i requisiti organizzativi, legali e di conformità perché il tuo carico di lavoro risulti conforme. 
+  Identifica le risorse di conformità AWS: identifica le risorse che AWS mette a disposizione per aiutarti nei processi di conformità. 
  +  [https://aws.amazon.com/compliance/ ](https://aws.amazon.com/compliance/)
  + [ https://aws.amazon.com/artifact/](https://aws.amazon.com/artifact/) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [AWS Security Audit Guidelines](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+ [ Bollettini sulla sicurezza](https://aws.amazon.com/security/security-bulletins/) 

 **Video correlati:** 
+  [AWS Security Hub CSPM: gestire gli avvisi di sicurezza e automatizzare la conformità](https://youtu.be/HsWtPG_rTak) 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP04 Aggiornamento costante sulle minacce alla sicurezza
<a name="sec_securely_operate_updated_threats"></a>

 Per definire e implementare controlli appropriati, riconosci i vettori di attacco rimanendo aggiornato sulle minacce alla sicurezza più recenti. Usa AWS Managed Services per semplificare la ricezione di notifiche in seguito a comportamenti inaspettati o inusuali nei tuoi account AWS. Esegui delle indagini avvalendoti degli strumenti AWS Partner o di feed di informazioni sulle minacce di terze parti come parte del tuo flusso di informazioni di sicurezza. Al [CVE (Common Vulnerabilities and Exposures) ](https://cve.mitre.org/) contiene vulnerabilità di sicurezza informatica pubbliche che puoi utilizzare come aggiornamento. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Iscrizione alle fonti di informazione sulle minacce: consulta regolarmente le informazioni sulle minacce da varie fonti attinenti alle tecnologie che utilizzi per il tuo carico di lavoro. 
  +  [Elenco CVE (Common Vulnerabilities and Exposures) ](https://cve.mitre.org/)
+  Considera il servizio [AWS Shield Advanced](https://aws.amazon.com/shield/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) : fornisce visibilità quasi in tempo reale sulle fonti di intelligence, se il tuo carico di lavoro è accessibile da Internet. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [AWS Security Audit Guidelines](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html) 
+  [AWS Shield](https://aws.amazon.com/shield/) 
+ [ Bollettini sulla sicurezza](https://aws.amazon.com/security/security-bulletins/) 

 **Video correlati:** 
+ [Security Best Practices the Well-Architected Way ](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP05 Aggiornamento costante sulle raccomandazioni di sicurezza
<a name="sec_securely_operate_updated_recommendations"></a>

 Tieniti aggiornato sulle raccomandazioni di sicurezza di AWS e del settore, così da revisionare l'assetto di sicurezza del tuo carico di lavoro. [Bollettini sulla sicurezza AWS](https://aws.amazon.com/security/security-bulletins/?card-body.sort-by=item.additionalFields.bulletinDateSort&card-body.sort-order=desc&awsf.bulletins-year=year%232009) contengono informazioni importanti sulla sicurezza e notifiche relative alla privacy. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Segui gli aggiornamenti di AWS: segui o verifica regolarmente la presenza di nuovi consigli, suggerimenti e trucchi. 
  +  [AWS Well-Architected Labs](https://wellarchitectedlabs.com/?ref=wellarchitected) 
  +  [Blog sulla sicurezza AWS](https://aws.amazon.com/blogs/security/?ref=wellarchitected) 
  +  [Documentazione del servizio AWS](https://aws.amazon.com/documentation/?ref=wellarchitected) 
+  Sottoscrivi gli aggiornamenti di settore: consulta regolarmente le notizie da varie fonti attinenti alle tecnologie impiegate nel tuo carico di lavoro. 
  +  [Esempio: Elenco CVE (Common Vulnerabilities and Exposures)](https://cve.mitre.org/cve/?ref=wellarchitected) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Bollettini sulla sicurezza](https://aws.amazon.com/security/security-bulletins/) 

 **Video correlati:** 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP06 Automatizzazione dei test e della convalida dei controlli di sicurezza nelle pipeline
<a name="sec_securely_operate_test_validate_pipeline"></a>

 Stabilisci previsioni e modelli sicuri per i meccanismi di sicurezza testati e convalidati come parte della compilazione, delle pipeline e dei processi. Utilizza strumenti e l'automazione per testare e convalidare tutti i controlli di sicurezza in modo continuo. Ad esempio, scansiona elementi quali immagini di macchine e modelli di infrastrutture come codice per individuare vulnerabilità di sicurezza, irregolarità e deviazioni da una previsione stabilita in ogni fase. AWS CloudFormation Guard può aiutarti a verificare la sicurezza dei modelli CloudFormation, a risparmiare tempo e a ridurre il rischio che si verifichino errori di configurazione. 

È fondamentale ridurre il numero di errori di sicurezza introdotti in un ambiente di produzione, quindi più operazioni di controllo di qualità e riduzione dei difetti è possibile eseguire nel processo di compilazione, più efficace sarà il risultato. Progetta pipeline di integrazione e distribuzione continue (CI/CD) per testare eventuali problemi di sicurezza quando possibile. Le pipeline CI/CD offrono l'opportunità di migliorare la sicurezza in ogni fase della compilazione e della distribuzione. Anche gli strumenti di sicurezza CI/CD devono essere mantenuti aggiornati per mitigare le minacce in continua evoluzione.

Monitora le modifiche alla configurazione del tuo carico di lavoro per facilitare gli audit di conformità, la gestione delle modifiche e le indagini che possono essere applicate al tuo caso. Puoi usare AWS Config per registrare e valutare le tue risorse AWS e di terze parti. Consente di eseguire audit costanti e di valutare la conformità generale a regole e pacchetti di conformità, ossia raccolte di regole con azioni di correzione.

Nel monitoraggio delle modifiche sono incluse modifiche pianificate, parte del processo di controllo delle modifiche della tua organizzazione (a cui a volte si fa riferimento con l'acronimo MACD: Move, Add, Change, Delete), le modifiche non pianificate e le modifiche inaspettate, come gli incidenti. Le modifiche possono avvenire a livello di infrastruttura, ma essere relative anche ad altre categorie, come le modifiche nei repository di codice, le modifiche delle immagini di macchine e degli inventari di applicazioni, le modifiche di processi e policy o le modifiche alla documentazione.

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Automazione della gestione della configurazione: applica e convalida in automatico configurazioni sicure sfruttando un apposito servizio o strumento di gestione. 
  +  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
  +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
  +  [Configurazione di una pipeline CI/CD in AWS](https://aws.amazon.com/getting-started/projects/set-up-ci-cd-pipeline/)

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Come usare le policy di controllo dei servizi per impostare guardrail di permessi negli account della tua AWS Organization](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/) 

 **Video correlati:** 
+  [Gestire ambienti AWS multi-account tramite AWS Organizations](https://youtu.be/fxo67UeeN1A) 
+  [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM) 

# SEC01-BP07 Identificare le minacce e dare priorità alle mitigazioni utilizzando un modello di minaccia.
<a name="sec_securely_operate_threat_model"></a>

 Effettua la modellazione delle minacce per identificare e mantenere un registro aggiornato delle minacce potenziali e delle relative mitigazioni per il carico di lavoro. Definisci le priorità delle minacce e adatta le mitigazioni dei controlli di sicurezza per prevenire, intercettare e rispondere. Rivedi e mantieni questo aspetto nel contesto del tuo carico di lavoro e dell'evoluzione del panorama della sicurezza. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 **Che cos'è la modellazione delle minacce?** 

 "La modellazione delle minacce ha lo scopo di identificare, comunicare e comprendere le minacce e le mitigazioni nel contesto della protezione di qualcosa di valore." – [The Open Web Application Security Project (OWASP) Application Threat Modeling](https://owasp.org/www-community/Threat_Modeling) 

 **Perché realizzare un modello di minaccia?** 

 I sistemi sono complessi e nel tempo diventano sempre più complessi e capaci di fornire un maggiore valore aziendale e una maggiore soddisfazione e coinvolgimento dei clienti. Ciò significa che le decisioni di progettazione IT devono tenere conto di un numero sempre maggiore di casi d'uso. Questa complessità e il numero di combinazioni di casi d'uso rendono in genere gli approcci non strutturati inefficaci per individuare e mitigare le minacce. È invece necessario un approccio sistematico per enumerare le potenziali minacce al sistema e per elaborare le mitigazioni e stabilirne le priorità per assicurarsi che le risorse limitate dell'organizzazione abbiano il massimo impatto nel migliorare lo stato di sicurezza complessiva del sistema. 

 La modellazione delle minacce è progettata per fornire questo approccio sistematico, con l'obiettivo di trovare e affrontare i problemi nelle prime fasi del processo di progettazione, quando le mitigazioni hanno un costo e un impegno relativi bassi rispetto alle fasi successive del ciclo di vita. Questo approccio è in linea con il principio di [sicurezza *shift-left* del settore](https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview). In definitiva, la modellazione delle minacce si integra con il processo di gestione del rischio di un'organizzazione e aiuta a prendere decisioni sui controlli da implementare utilizzando un approccio orientato alle minacce. 

 **Quando è necessario eseguire la modellazione delle minacce?** 

 La modellazione delle minacce deve essere avviata il più presto possibile nel ciclo di vita del carico di lavoro, in modo da avere una maggiore flessibilità di intervento sulle minacce identificate. Come per i bug del software, prima si identificano le minacce, più è conveniente affrontarle. Un modello di minacce è un documento vivo e deve continuare a evolvere in base ai cambiamenti dei carichi di lavoro. I modelli di minaccia vanno rivisti nel tempo, anche in caso di modifiche importanti, di cambiamenti nel panorama delle minacce o di adozione di nuove funzionalità o servizi. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 **Come possiamo eseguire la modellazione delle minacce?** 

 Esistono diversi modi per eseguire la modellazione delle minacce. Come per i linguaggi di programmazione, anche in questo caso ci sono vantaggi e svantaggi e bisogna scegliere il metodo più adatto alle proprie esigenze. Un approccio possibile è iniziare con [Shostack’s 4 Question Frame for Threat Modeling](https://github.com/adamshostack/4QuestionFrame), che pone domande aperte per strutturare l'esercizio di modellazione delle minacce: 

1.  **A cosa si sta lavorando?** 

    Questa domanda ha lo scopo di aiutare a comprendere e concordare il sistema che si sta costruendo e i dettagli di tale sistema che sono rilevanti per la sicurezza. La creazione di un modello o di un diagramma è il modo più diffuso per rispondere a questa domanda, in quanto aiuta a visualizzare ciò che si sta costruendo, ad esempio utilizzando un [diagramma di flusso dei dati](https://en.wikipedia.org/wiki/Data-flow_diagram). Scrivere le ipotesi e i dettagli importanti del sistema aiuta anche a definire l'ambito di applicazione. In questo modo, tutti coloro che contribuiscono alla modellazione delle minacce possono concentrarsi sullo stesso aspetto, evitando deviazioni dispendiose in termini di tempo su argomenti fuori portata (comprese le versioni non aggiornate del sistema). Ad esempio, se si sta costruendo un'applicazione web, probabilmente non vale la pena procedere alla modellazione per la sequenza di avvio attendibile del sistema operativo per i browser client, poiché non si ha la possibilità di influire su questo aspetto con il proprio progetto. 

1.  **Cosa può andare storto?** 

    In questa fase si identificano le minacce al sistema. Le minacce sono azioni o eventi accidentali o intenzionali che hanno impatti indesiderati e potrebbero compromettere la sicurezza del sistema. Senza una visione chiara di ciò che potrebbe andare storto, non è possibile fare nulla per evitarlo. 

    Non esiste un elenco canonico di ciò che può andare storto. La creazione di questo elenco richiede un brainstorming e la collaborazione di tutti i componenti del team e dei [soggetti coinvolti](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/#tips) nell'esercizio di modellazione delle minacce. Per facilitare il brainstorming si può utilizzare un modello per l'identificazione delle minacce, ad esempio [STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security)), che suggerisce diverse categorie da valutare: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of privilege (spoofing, manomissione, ripudio, divulgazione di informazioni, negazione del servizio ed elevazione dei privilegi). Inoltre, per facilitare il brainstorming, si possono consultare gli elenchi e le ricerche esistenti per trarne ispirazione, come ad esempio [OWASP Top 10](https://owasp.org/www-project-top-ten/), [HiTrust Threat Catalog](https://hitrustalliance.net/hitrust-threat-catalogue/) e il catalogo delle minacce della propria organizzazione. 

1.  **Che cosa faremo a questo proposito?** 

    Come nel caso della domanda precedente, non esiste un elenco canonico di tutte le possibili mitigazioni. Gli input di questa fase sono le minacce, gli attori e le aree di miglioramento identificate nella fase precedente. 

    La sicurezza e la conformità sono una [responsabilità condivisa da AWS e dal cliente](https://aws.amazon.com/compliance/shared-responsibility-model/). È importante capire che quando si chiede "Che cosa faremo?", si chiede anche "Chi è responsabile? Chi ha la responsabilità di fare qualcosa?" Comprendere l'equilibrio delle responsabilità tra utente e AWS consente di limitare l'esercizio di modellazione delle minacce alle mitigazioni sotto il proprio controllo, che di solito sono una combinazione di opzioni di configurazione del servizio AWS e di mitigazioni specifiche del proprio sistema. 

    Per la parte AWS relativa alla responsabilità condivisa, si scoprirà che i [servizi AWS rientrano nell'ambito di molti programmi di conformità](https://aws.amazon.com/compliance/services-in-scope/). Questi programmi aiutano a comprendere i solidi controlli in atto presso AWS per mantenere la sicurezza e la conformità del cloud. I report di audit di questi programmi sono disponibili per il download per i clienti AWS da [AWS Artifact](https://aws.amazon.com/artifact/). 

    Indipendentemente dai servizi AWS utilizzati, c'è sempre una responsabilità del cliente e le mitigazioni allineate a tale responsabilità devono essere incluse nel modello di minaccia. Per quanto riguarda le mitigazioni dei controlli di sicurezza per i servizi AWS stessi, è necessario considerare l'implementazione dei controlli di sicurezza in tutti i domini, compresi quelli quali la gestione delle identità e degli accessi (autenticazione e autorizzazione), la protezione dei dati (a riposo e in transito), la sicurezza dell'infrastruttura, la registrazione e il monitoraggio. La documentazione di ogni servizio AWS ha un [capitolo sulla sicurezza dedicato](https://docs.aws.amazon.com/security/) che fornisce indicazioni sui controlli di sicurezza da considerare come mitigazioni. È importante considerare il codice che si sta scrivendo e le sue dipendenze e pensare ai controlli che si possono mettere in atto per affrontare queste minacce. Questi controlli possono essere elementi come la [convalida degli input](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), la [gestione delle sessioni](https://owasp.org/www-project-mobile-top-10/2014-risks/m9-improper-session-handling) e la [gestione dei limiti](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow). Spesso la maggior parte delle vulnerabilità viene introdotta nel codice personalizzato, quindi è bene concentrarsi su quest'area. 

1.  **Abbiamo fatto un buon lavoro?** 

    L'obiettivo è che il team e l'organizzazione migliorino sia la qualità dei modelli di minacce sia la velocità con cui vengono eseguiti nel tempo. Questi miglioramenti derivano da una combinazione di pratica, apprendimento, insegnamento e revisione. Per approfondire e mettere mano alla situazione, è consigliabile completare il corso di formazione [Threat modeling the right way for builders](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop) (Come modellare le minacce nel modo giusto per gli sviluppatori) o il [workshop](https://catalog.workshops.aws/threatmodel/en-US) insieme al team. Inoltre, se si desidera una guida su come integrare la modellazione delle minacce nel ciclo di vita dello sviluppo dell'applicazione della propria organizzazione, invitiamo a consultare il post [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (Come affrontare la modellazione delle minacce) su AWS Security Blog (Blog sulla sicurezza AWS). 

 **Threat Composer** 

 Come ausilio nella modellazione delle minacce, puoi utilizzare lo strumento [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer), il cui scopo è ridurre il time-to-value di questa attività. Lo strumento consente di eseguire le seguenti operazioni: 
+  Scrivere dichiarazioni sulle minacce in linea con la [sintassi delle minacce](https://catalog.workshops.aws/threatmodel/en-US/what-can-go-wrong/threat-grammar) che funzionino in un flusso di lavoro naturale non lineare 
+  Generare un modello di minaccia leggibile dall'uomo 
+  Generare un modello di minaccia leggibile dal computer per consentire la gestione dei modelli di minaccia come codice 
+  Velocizzare l'individuazione delle aree di miglioramento della qualità e della copertura utilizzando l'area del pannello di controllo contenente le informazioni dettagliate 

 Per ulteriori riferimenti, visita la pagina relativa allo strumento Threat Composer e passa all'**area di lavoro di esempio** definita dal sistema. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC01-BP03 Identificazione e convalida degli obiettivi di controllo](sec_securely_operate_control_objectives.md) 
+  [SEC01-BP04 Aggiornamento costante sulle minacce alla sicurezza](sec_securely_operate_updated_threats.md) 
+  [SEC01-BP05 Aggiornamento costante sulle raccomandazioni di sicurezza](sec_securely_operate_updated_recommendations.md) 
+  [SEC01-BP08 Valutazione e implementazione periodiche di nuovi servizi e funzionalità di sicurezza](sec_securely_operate_implement_services_features.md) 

 **Documenti correlati:** 
+  [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (AWS Security Blog) 
+ [ NIST: Guide to Data-Centric System Threat Modelling ](https://csrc.nist.gov/publications/detail/sp/800-154/draft)

 **Video correlati:** 
+ [AWS Summit ANZ 2021 – How to approach threat modelling](https://www.youtube.com/watch?v=GuhIefIGeuA) (Summit ANZ 2021 – Come affrontare la modellazione delle minacce)
+ [AWS Summit ANZ 2022 - Scaling security – Optimise for fast and secure delivery ](https://www.youtube.com/watch?v=DjNPihdWHeA) (Summit ANZ 2022 - Scalare la sicurezza - Ottimizzare la consegna rapida e sicura)

 **Training correlati:** 
+ [ Threat modeling the right way for builders – AWS Skill Builder virtual self-paced training ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop) (La corretta modellazione delle minacce per gli sviluppatori – Formazione virtuale autogestita Skill Builder)
+ [ Threat modeling the right way for builders – AWS Workshop ](https://catalog.workshops.aws/threatmodel) (La corretta modellazione delle minacce per gli sviluppatori – Workshop)

 **Strumenti correlati:** 
+  [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer) 

# SEC01-BP08 Valutazione e implementazione periodiche di nuovi servizi e funzionalità di sicurezza
<a name="sec_securely_operate_implement_services_features"></a>

 Valuta e implementa servizi e funzionalità di sicurezza di AWS e partner AWS che consentano di sviluppare l'assetto di sicurezza del carico di lavoro. Il blog sulla sicurezza AWS evidenzia nuovi servizi e funzionalità AWS, guide all'implementazione e linee guida generali sulla sicurezza. [Novità di AWS](https://aws.amazon.com/new) è un'ottima scelta per essere aggiornati su tutte le nuove funzionalità, i servizi e gli annunci AWS. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Pianificazione di revisioni regolari: crea un calendario di attività di revisione che preveda requisiti di conformità, valutazione delle nuove funzionalità e dei nuovi servizi di sicurezza AWS e l'aggiornamento costante rispetto alle novità del settore. 
+  Funzionalità e servizi AWS: scopri le funzionalità di sicurezza disponibili per i servizi che utilizzi e approfondisci le nuove caratteristiche al momento del rilascio. 
  + [ Blog sulla sicurezza AWS](https://aws.amazon.com/blogs/security/) 
  + [ Bollettini sulla sicurezza AWS](https://aws.amazon.com/security/security-bulletins/)
  +  [Documentazione del servizio AWS](https://aws.amazon.com/documentation/)
+  Definizione del processo di onboarding del servizio AWS: definisci i processi per l'onboarding di nuovi servizi AWS. Includi il modo in cui valuti la funzionalità dei nuovi servizi AWS e i requisiti di conformità per il tuo carico di lavoro. 
+  Test di nuovi servizi e funzionalità: testa nuovi servizi e funzionalità al momento del rilascio in un ambiente non di produzione che replica in maniera fedele quello di produzione. 
+  Implementazione di altri meccanismi di difesa: implementa meccanismi automatizzati per difendere il carico di lavoro, esplora le opzioni disponibili. 
  +  [Correzione di risorse AWS non conformi in base alle regole di Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)

## Risorse
<a name="resources"></a>

 **Video correlati:** 
+  [Security Best Practices the Well-Architected Way ](https://youtu.be/u6BCVkXkPnM)

# Gestione di identità e accessi
<a name="a-identity-and-access-management"></a>

**Topics**
+ [SEC 2. Come si gestisce l'autenticazione per persone e macchine?](sec-02.md)
+ [SEC 3. Come si gestisce l'autenticazione per persone e macchine?](sec-03.md)

# SEC 2. Come si gestisce l'autenticazione per persone e macchine?
<a name="sec-02"></a>

 Ci sono due tipi di identità da gestire quando inizi a utilizzare carichi di lavoro AWS sicuri. Comprendere il tipo di identità necessaria per gestire e concedere l'accesso ti aiuta a verificare che le identità corrette abbiano accesso alle risorse giuste nelle condizioni adeguate. 

Identità umane: amministratori, sviluppatori, operatori e utenti finali necessitano di un'identità per accedere agli ambienti e alle applicazioni AWS. Si tratta di membri dell'organizzazione o di utenti esterni con cui collabori e che interagiscono con le risorse AWS tramite Web browser, applicazioni client o strumenti a riga di comando interattivi. 

Identità di macchine: le applicazioni di servizio, gli strumenti operativi e i carichi di lavoro necessitano di un'identità per effettuare richieste ai servizi AWS, ad esempio per leggere i dati. Queste identità includono macchine in esecuzione nell'ambiente AWS, ad esempio istanze Amazon EC2 o funzioni AWS Lambda. Puoi gestire le identità di macchine anche per soggetti esterni che necessitano dell'accesso. Inoltre, potresti disporre di macchine al di fuori di AWS che devono accedere al tuo ambiente AWS. 

**Topics**
+ [SEC02-BP01 Utilizzo meccanismi di accesso efficaci](sec_identities_enforce_mechanisms.md)
+ [SEC02-BP02 Utilizzo di credenziali temporanee](sec_identities_unique.md)
+ [SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro](sec_identities_secrets.md)
+ [SEC02-BP04 Fai affidamento su un provider di identità centralizzato](sec_identities_identity_provider.md)
+ [SEC02-BP05 Verifica e rotazione periodica delle credenziali](sec_identities_audit.md)
+ [SEC02-BP06 Utilizzo dei gruppi di utenti e degli attributi](sec_identities_groups_attributes.md)

# SEC02-BP01 Utilizzo meccanismi di accesso efficaci
<a name="sec_identities_enforce_mechanisms"></a>

I sign-in (autenticazione tramite credenziali di accesso) possono presentare dei rischi se non si utilizzano meccanismi come l'autenticazione a più fattori (MFA), soprattutto in situazioni in cui le credenziali di accesso sono state inavvertitamente divulgate o sono facilmente identificabili. Utilizza meccanismi di accesso efficaci per ridurre questi rischi, richiedendo l'MFA e policy sulle password sicure. 

 **Risultato desiderato:** ridurre i rischi di accesso involontario alle credenziali in AWS utilizzando meccanismi di accesso efficaci per gli utenti [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), l'[utente root Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html), [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) (successore di AWS Single Sign-On) e i provider di identità di terze parti. Ciò significa richiedere l'MFA, applicare policy sulle password efficaci e rilevare comportamenti di accesso anomali. 

 **Anti-pattern comuni:** 
+  Nessuna applicazione di policy sulle password efficaci per le proprie identità, comprese password complesse e MFA. 
+  Condivisione delle stesse credenziali tra utenti diversi. 
+  Nessun utilizzo di controlli investigativi per gli accessi sospetti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Ci sono molti modi in cui le identità umane possono accedere ad AWS. È una best practice di AWS affidarsi a un provider di identità centralizzato che si avvale della federazione (federazione diretta o utilizzo di AWS IAM Identity Center) per l’autenticazione ad AWS. In questo caso, è necessario stabilire un processo di accesso sicuro con il provider di identità o con Microsoft Active Directory. 

 Quando apri un Account AWS, inizi con un utente root Account AWS. L'account utente root deve essere utilizzato solo per impostare l'accesso per gli utenti e per le [attività che richiedono l'utente root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)). È importante abilitare l'MFA per l'utente root dell'account subito dopo l'apertura di Account AWS e proteggere l'utente root usando la guida AWS alle [best practice](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html). 

 Se crei utenti in AWS IAM Identity Center, proteggi il processo di accesso in quel servizio. Per le identità dei consumatori, puoi usare [Amazon Cognito user pools](https://docs.aws.amazon.com/cognito/index.html) e proteggere il processo di accesso in tale servizio oppure puoi utilizzare uno dei fornitori di identità supportato da Amazon Cognito user pools. 

 Se si utilizzano gli utenti [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/), è opportuno proteggere il processo di accesso mediante IAM. 

 Indipendentemente dal metodo di accesso, è fondamentale applicare una policy di accesso efficace. 

 **Passaggi dell'implementazione** 

 Le seguenti sono raccomandazioni generali per l'accesso sicuro. Le impostazioni effettive da configurare devono essere stabilite dalla policy aziendale o utilizzare uno standard come [NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html). 
+  Richiedere l'MFA. [Richiedere l'MFA è una best practice IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) per le identità e i carichi di lavoro umani. L'abilitazione dell'MFA fornisce un ulteriore livello di sicurezza che richiede agli utenti di fornire le credenziali di accesso e un codice OTP (One-Time Password) o una stringa verificata e generata crittograficamente da un dispositivo hardware. 
+  Applicare una lunghezza minima della password, che è un fattore primario nella forza della password. 
+  Applicare la complessità delle password in modo che sia più difficile individuarle. 
+  Consentire agli utenti di modificare le proprie password. 
+  Creare identità individuali invece di credenziali condivise. Creando identità individuali, è possibile assegnare a ciascun utente un set unico di credenziali di sicurezza. I singoli utenti consentono di sottoporre a audit l'attività di ciascuno. 

 Suggerimenti IAM Identity Center: 
+  IAM Identity Center fornisce una [policy sulla password](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) prestabilita quando si utilizza la directory predefinita che stabilisce i requisiti di lunghezza, complessità e riutilizzo delle password. 
+  [Abilitare l'MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html) e configurare l'impostazione "Compatibile con il contesto" o "Sempre attivo" per l'MFA quando l'origine dell'identità è la directory predefinita, AWS Managed Microsoft AD o AD Connector. 
+  Consenti agli utenti di [registrare i propri dispositivi MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/how-to-allow-user-registration.html). 

 Suggerimenti sulla directory Amazon Cognito user pools: 
+  Configura le impostazioni di [forza della password](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html). 
+  [Richiedi l'MFA](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html) per gli utenti. 
+  Utilizza le Amazon Cognito user pools [impostazioni di sicurezza avanzate](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html) per le funzionalità quali l'[autenticazione adattiva](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html) che può bloccare sign-in sospetti. 

 Suggerimenti per l'utente IAM: 
+  Idealmente stai utilizzando IAM Identity Center o la federazione diretta. Tuttavia, potrebbero essere necessari utenti IAM. In tal caso, [imposta una policy sulla password](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) per gli utenti IAM. Puoi utilizzare la policy sulla password per definire requisiti quali la lunghezza minima o la necessità che la password richieda caratteri non alfabetici. 
+  Crea una policy IAM per [applicare l'accesso MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1) in modo che gli utenti possano gestire le proprie password e i dispositivi MFA. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro](sec_identities_secrets.md) 
+  [SEC02-BP04 Fai affidamento su un provider di identità centralizzato](sec_identities_identity_provider.md) 
+  [SEC03-BP08 Condivisione delle risorse in modo sicuro all'interno dell'organizzazione](sec_permissions_share_securely.md) 

 **Documenti correlati:** 
+ [AWS IAM Identity Center (successor to AWS Single Sign-On) Password Policy ](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) Policy sulle password AWS IAM Identity Center (successore di AWS Single Sign-On)
+ [ IAM user password policy ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)(Policy sulle password degli utenti IAM)
+ [ Setting the Account AWS root user password ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)(Impostazione della password dell'utente root dell'account AWS)
+ [ Amazon Cognito password policy ](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html) (Policy sulla password di Amazon Cognito)
+ [AWS credentials ](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)(Credenziali AWS)
+ [ IAM security best practices ](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)(Best Practice di sicurezza IAM)

 **Video correlati:** 
+  [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) (Gestire le autorizzazioni degli utenti su larga scala con AWS SSO) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP02 Utilizzo di credenziali temporanee
<a name="sec_identities_unique"></a>

 Quando si esegue qualsiasi tipo di autenticazione, è preferibile utilizzare credenziali temporanee invece di credenziali a lungo termine per ridurre o eliminare i rischi, come la divulgazione, la condivisione o il furto involontario delle credenziali. 

**Risultato desiderato:** per ridurre il rischio legato alle credenziali a lungo termine, utilizza credenziali temporanee ogni qualvolta sia possibile sia per le identità umane che per le identità macchina. Le credenziali a lungo termine creano molti rischi, ad esempio possono essere caricate in codice su repository GitHub pubblici. Utilizzando credenziali temporanee, riduci notevolmente le possibilità di compromissione delle credenziali. 

**Anti-pattern comuni:**
+  Sviluppatori che utilizzano chiavi di accesso a lungo termine dagli IAM users anziché ottenere credenziali temporanee dalla CLI utilizzando la federazione. 
+  Sviluppatori che inseriscono chiavi di accesso a lungo termine nel loro codice e caricano tale codice su repository Git pubblici. 
+  Sviluppatori che inseriscono chiavi di accesso a lungo termine nelle applicazioni mobili che vengono poi rese disponibili negli app store. 
+  Utenti che condividono le chiavi di accesso a lungo termine con altri utenti o dipendenti che lasciano l'azienda con chiavi di accesso a lungo termine ancora in loro possesso. 
+  Utilizzo di chiavi di accesso a lungo termine per le identità macchina quando è possibile utilizzare credenziali temporanee. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Utilizza credenziali di sicurezza temporanee invece di credenziali a lungo termine per tutte le richieste API e CLI AWS. Le richieste API e CLI ai servizi AWS devono, in quasi tutti i casi, essere firmate utilizzando le [chiavi di accesso AWS](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html). Queste richieste possono essere firmate con credenziali temporanee o a lungo termine. L'unico caso in cui si devono utilizzare credenziali a lungo termine, note anche come chiavi di accesso a lungo termine, è qualora si stia utilizzando un [utente IAM](https://docs.aws.amazon.com//latest/UserGuide/id_users.html) o un [utente root Account AWS](https://docs.aws.amazon.com//latest/UserGuide/id_root-user.html). Al momento della federazione ad AWS o dell'assunzione di un [ruolo IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles.html) attraverso altri metodi, vengono generate delle credenziali temporanee. Anche quando accedi a Console di gestione AWS utilizzando le credenziali di accesso, vengono generate credenziali temporanee per effettuare chiamate ai servizi AWS. Sono poche le situazioni in cui è necessario disporre di credenziali a lungo termine ed è possibile svolgere quasi tutte le attività utilizzando credenziali temporanee. 

 Evitare l'uso di credenziali a lungo termine a favore di credenziali temporanee dovrebbe andare di pari passo con una strategia di riduzione dell'uso degli utenti IAM a favore della federazione e dei ruoli IAM. Sebbene in passato gli utenti IAM siano stati utilizzati sia per le identità umane che per quelle macchina, ora si consiglia di non utilizzarli per evitare i rischi legati all'uso di chiavi di accesso a lungo termine. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Per le identità umane come dipendenti, amministratori, sviluppatori, operatori e clienti: 
+  Devi [affidarti a un fornitore di identità centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) e [richiedere agli utenti umani di utilizzare la federazione con un fornitore di identità per accedere ad AWS utilizzando credenziali temporanee](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#bp-users-federation-idp). La federazione degli utenti può essere effettuata con [la federazione diretta a ciascun Account AWS](https://aws.amazon.com/identity/federation/) o utilizzando [AWS IAM Identity Center (successore di AWS IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) e un provider di identità a scelta. La federazione offre una serie di vantaggi rispetto all'utilizzo degli utenti IAM, oltre all'eliminazione delle credenziali a lungo termine. Gli utenti possono anche richiedere credenziali temporanee dalla riga di comando per la [federazione diretta](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/) o utilizzare [IAM Identity Center](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html). Ciò significa che i casi d'uso che richiedono utenti IAM o credenziali a lungo termine per gli utenti sono pochi.  
+  Quando concedi a terzi, come ad esempio ai fornitori di software come servizio (SaaS), l'accesso alle risorse del tuo Account AWS, puoi utilizzare [ruoli multi-account](https://docs.aws.amazon.com//latest/UserGuide/tutorial_cross-account-with-roles.html) e [policy basate sulle risorse](https://docs.aws.amazon.com//latest/UserGuide/access_policies_identity-vs-resource.html). 
+  Se devi concedere l'accesso alle tue risorse alle applicazioni per i consumatori o per i clientiAWS, puoi utilizzare i [pool di identità Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) o [Amazon Cognito user pools](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) per fornire le credenziali temporanee. Le autorizzazioni per le credenziali sono configurate tramite i ruoli IAM. Puoi anche definire un ruolo IAM separato con autorizzazioni limitate per gli utenti guest non autenticati. 

 Per le identità macchina, potrebbero essere necessarie credenziali a lungo termine. In questi casi, devi [richiedere ai carichi di lavoro di utilizzare credenziali temporanee con ruoli IAM per accedere ad AWS](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#bp-workloads-use-roles). 
+  Per [Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/) (Amazon EC2), puoi utilizzare [ruoli per Amazon EC2](https://docs.aws.amazon.com//latest/UserGuide/id_roles_use_switch-role-ec2.html). 
+  [AWS Lambda](https://aws.amazon.com/lambda/) ti consente di configurare un [ruolo di esecuzione Lambda per concedere le autorizzazioni al servizio](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) per eseguire azioni AWS utilizzando credenziali temporanee. Per i servizi AWS esistono molti altri modelli simili per concedere credenziali temporanee utilizzando i ruoli IAM. 
+  Per i dispositivi IoT, puoi utilizzare il [provider di credenziali AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) per richiedere credenziali temporanee. 
+  Per i sistemi on-premise o per i sistemi che vengono eseguiti al di fuori di AWS che richiedono accesso alle risorse AWS, puoi utilizzare [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html). 

 Esistono scenari in cui le credenziali temporanee non sono un'opzione e potrebbe essere necessario utilizzare credenziali a lungo termine. In queste situazioni, [sottoponi a audit e ruota periodicamente le credenziali](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) e [ruota regolarmente le chiavi di accesso per i casi d'uso che richiedono credenziali a lungo termine.](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#rotate-credentials). Alcuni esempi che potrebbero richiedere credenziali a lungo termine sono i plugin di WordPress e i client AWS di terze parti. Quando è necessario utilizzare credenziali a lungo termine o per credenziali diverse dalle chiavi di accesso AWS, come ad esempio i login ai database, puoi utilizzare un servizio progettato per gestire i segreti, ad esempio [Gestione dei segreti AWS](https://aws.amazon.com/secrets-manager/). Secrets Manager consente di gestire, ruotare e archiviare in modo semplice e sicuro i segreti crittografati usando [servizi supportati](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html). Per ulteriori informazioni sulla rotazione delle credenziali a lungo termine, consulta [Rotating Access Keys](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) (Rotazione delle chiavi di accesso). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro](sec_identities_secrets.md) 
+ [SEC02-BP04 Fai affidamento su un provider di identità centralizzato](sec_identities_identity_provider.md) 
+ [SEC03-BP08 Condivisione delle risorse in modo sicuro all'interno dell'organizzazione](sec_permissions_share_securely.md) 

 **Documenti correlati:** 
+  [Credenziali di sicurezza temporanee](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html) 
+  [AWS Credentials](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html) (Credenziali AWS) 
+  [IAM Security Best Practices](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html) (Best practice per la sicurezza IAM) 
+  [Ruoli IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles.html) 
+  [IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 
+  [Provider di identità e federazione](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Rotating Access Keys](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) 
+  [Soluzioni dei partner per la sicurezza: accesso e controllo degli accessi](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [L'utente root dell'account AWS](https://docs.aws.amazon.com//latest/UserGuide/id_root-user.html) 

 **Video correlati:** 
+  [Managing user permissions at scale with AWS IAM Identity Center (Gestire le autorizzazioni degli utenti su larga scala con AWS SSO), successore di AWS IAM Identity Center)](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro
<a name="sec_identities_secrets"></a>

 Un carico di lavoro richiede una capacità automatizzata di dimostrare la propria identità a database, risorse e servizi di terze parti. A tal fine si utilizzano credenziali di accesso segrete, come chiavi di accesso API, password e token OAuth. L'utilizzo di un servizio appositamente creato per archiviare, gestire e ruotare queste credenziali aiuta a ridurre la probabilità che queste vengano compromesse. 

**Risultato desiderato:** implementare un meccanismo per la gestione sicura delle credenziali delle applicazioni che raggiunga i seguenti obiettivi: 
+  Identificare i segreti necessari per il carico di lavoro. 
+  Ridurre il numero di credenziali a lungo termine sostituendole con credenziali a breve termine, quando possibile. 
+  Stabilire l'archiviazione sicura e la rotazione automatica delle rimanenti credenziali a lungo termine. 
+  Sottoporre a audit l'accesso ai segreti esistenti nel carico di lavoro. 
+  Eseguire il monitoraggio continuo per verificare che nessun segreto sia incorporato nel codice sorgente durante il processo di sviluppo. 
+  Ridurre la probabilità che le credenziali vengano divulgate inavvertitamente. 

**Anti-pattern comuni:**
+  Nessuna rotazione delle credenziali. 
+  Memorizzazione di credenziali a lungo termine nel codice sorgente o nei file di configurazione. 
+  Memorizzazione delle credenziali a riposo non criptate. 

 **Vantaggi dell'adozione di questa best practice:**
+  I segreti sono conservati in modo criptato a riposo e in transito. 
+  L'accesso alle credenziali è regolato da un'API (si pensi a un *distributore automatico di credenziali*). 
+  L'accesso a una credenziale (sia in lettura che in scrittura) viene sottoposto a audit e registrato. 
+  Separazione delle preoccupazioni: la rotazione delle credenziali viene eseguita da un componente distinto, che può essere separato dal resto dell'architettura. 
+  I segreti vengono distribuiti automaticamente su richiesta ai componenti software e la rotazione avviene in una posizione centrale. 
+  L'accesso alle credenziali può essere controllato in modo granulare. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 In passato, le credenziali utilizzate per l'autenticazione ai database, alle API di terze parti, ai token e ad altri segreti potevano essere incorporate nel codice sorgente o nei file di ambiente. AWS fornisce diversi meccanismi per memorizzare queste credenziali in modo sicuro, ruotarle automaticamente e sottoporre a audit il loro utilizzo. 

 Il modo migliore per affrontare la gestione dei segreti è seguire le indicazioni di rimuovere, sostituire e ruotare. La credenziale più sicura è quella che non si deve memorizzare, gestire o trattare. Possono esserci credenziali che non sono più necessarie per il funzionamento del carico di lavoro e che possono essere rimosse in modo sicuro. 

 Per le credenziali che sono ancora necessarie per il corretto funzionamento del carico di lavoro, potrebbe esserci l'opportunità di sostituire una credenziale a lungo termine con una credenziale temporanea o a breve termine. Ad esempio, invece di una codifica fissa di una chiave di accesso segreta AWS, si può pensare di sostituire la credenziale a lungo termine con una credenziale temporanea utilizzando i ruoli IAM. 

 Alcuni segreti di lunga durata potrebbero non poter essere rimossi o sostituiti. Questi segreti possono essere memorizzati in un servizio come [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), dove possono essere archiviati, gestiti e ruotati regolarmente a livello centrale. 

 Un audit del codice sorgente e dei file di configurazione del carico di lavoro può rivelare molti tipi di credenziali. La tabella seguente riassume le strategie per gestire i tipi più comuni di credenziali: 


|  Credential type  |  Description  |  Suggested strategy  | 
| --- | --- | --- | 
|  IAM access keys  |  AWS IAM access and secret keys used to assume IAM roles inside of a workload  |  Replace: Use [Ruoli IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios.html) assigned to the compute instances (such as [Amazon EC2](https://docs.aws.amazon.com//latest/UserGuide/id_roles_use_switch-role-ec2.html) or [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)) instead. For interoperability with third parties that require access to resources in your Account AWS, ask if they support [AWS cross-account access](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios_third-party.html) (Accesso multi-account AWS). For mobile apps, consider using temporary credentials through [Pool di identità di Amazon Cognito (identità federate)](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html). For workloads running outside of AWS, consider [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) or [Attivazioni ibride AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html).  | 
|  SSH keys  |  Secure Shell private keys used to log into Linux EC2 instances, manually or as part of an automated process  |  Replace: Use [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) or [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) to provide programmatic and human access to EC2 instances using IAM roles.  | 
|  Application and database credentials  |  Passwords – plain text string  |  Rotate: Store credentials in [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and establish automated rotation if possible.  | 
|  Amazon RDS and Aurora Admin Database credentials  |  Passwords – plain text string  |  Replace: Use the [Secrets Manager integration with Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html) (Integrazione di Secrets Manager con Amazon RDS) or [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html). In addition, some RDS database types can use IAM roles instead of passwords for some use cases (for more detail, see [IAM database authentication](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.DBAuth.html) (Autenticazione del database IAM)).  | 
|  OAuth tokens  |  Secret tokens – plain text string  |  Rotate: Store tokens in [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and configure automated rotation.  | 
|  API tokens and keys  |  Secret tokens – plain text string  |  Rotate: Store in [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) and establish automated rotation if possible.  | 

 Un anti-pattern comune è quello di incorporare le chiavi di accesso IAM all'interno del codice sorgente, dei file di configurazione o delle applicazioni mobili. Quando è richiesta una chiave di accesso IAM per comunicare con un servizio AWS, utilizza le [credenziali di sicurezza temporanee (a breve termine)](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html). Queste credenziali a breve termine possono essere fornite attraverso [ruoli IAM per istanze EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), [ruoli di esecuzione](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) per funzioni Lambda, [ruoli Cognito IAM](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) per l'accesso degli utenti di dispositivi mobili e [policy IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html) per i dispositivi IoT. Quando ci si interfaccia con terze parti, è preferibile [delegare l'accesso a un ruolo IAM](https://docs.aws.amazon.com//latest/UserGuide/id_roles_common-scenarios_third-party.html) con l'accesso necessario alle risorse del proprio account, piuttosto che configurare un utente IAM e inviare alla terza parte la chiave di accesso segreta per quell'utente. 

 In molti casi il carico di lavoro richiede la memorizzazione di segreti necessari per l'interoperabilità con altri servizi e risorse. [Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) è costruito appositamente per gestire in modo sicuro queste credenziali, nonché l'archiviazione, l'uso e la rotazione di token API, password e altre credenziali. 

 Gestione dei segreti AWS fornisce cinque funzionalità chiave per garantire l'archiviazione e la gestione sicura delle credenziali sensibili: [crittografia a riposo](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html), [crittografia in transito](https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html), [audit completo](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html), [controllo degli accessi granulare](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html) e [rotazione estensibile delle credenziali](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html). Sono accettabili anche altri servizi di gestione dei segreti dei partner AWS o soluzioni sviluppate localmente che forniscano funzionalità e garanzie simili. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Individuare i percorsi di codice contenenti credenziali hard-coded utilizzando strumenti automatizzati come [Amazon CodeGuru](https://aws.amazon.com/codeguru/features/). 
   +  Utilizzare Amazon CodeGuru per eseguire la scansione dei repository di codice. Una volta completata la revisione, filtrare `Type=Secrets` in CodeGuru per trovare le linee di codice problematiche. 

1.  Identificare le credenziali che possono essere rimosse o sostituite. 

   1.  Identificare le credenziali non più necessarie e contrassegnarle per la rimozione. 

   1.  Le chiavi segrete AWS incorporate nel codice sorgente devono essere sostituite con ruoli IAM associati alle risorse necessarie. Se una parte del carico di lavoro è al di fuori di AWS ma richiede le credenziali IAM per accedere alle risorse AWS, considerare [IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) o [Attivazioni ibride AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html). 

1.  Per altri segreti di terze parti a lunga durata che richiedono l'uso della strategia di rotazione, integrare Secrets Manager nel codice per recuperare i segreti di terze parti in fase di esecuzione. 

   1.  La console CodeGuru può [creare un segreto in Secrets Manager](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) automaticamente utilizzando le credenziali individuate. 

   1.  Integrare il recupero dei segreti da Secrets Manager nel codice dell'applicazione. 
      +  Le funzioni Lambda serverless possono utilizzare un'[estensione Lambda](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html) indipendente dal linguaggio. 
      +  Per le istanze o i container EC2, AWS fornisce esempi di [codice lato client per il recupero dei segreti da Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) in diversi linguaggi di programmazione popolari. 

1.  Esaminare periodicamente la base di codice e ripetere la scansione per verificare che non siano stati aggiunti nuovi segreti al codice. 
   +  Valutare l'utilizzo di uno strumento come [git-secrets](https://github.com/awslabs/git-secrets) per impedire il commit di nuovi segreti nel repository del codice sorgente. 

1.  [Monitorare l'attività di Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html) per rilevare indicazioni di utilizzo inatteso, accesso inappropriato ai segreti o tentativi di cancellazione dei segreti. 

1.  Ridurre l'esposizione umana alle credenziali. Limitare l'accesso alle credenziali di lettura, scrittura e modifica a un ruolo IAM dedicato a questo scopo e fornire l'accesso per assumere il ruolo solo a un piccolo sottoinsieme di utenti operativi. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [SEC02-BP02 Utilizzo di credenziali temporanee](sec_identities_unique.md)
+ [SEC02-BP05 Verifica e rotazione periodica delle credenziali](sec_identities_audit.md)

 **Documenti correlati:** 
+  [Nozioni di base su Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [Provider di identità e federazione](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Amazon CodeGuru Introduces Secrets Detector](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) (Amazon CodeGuru introduce il rivelatore di segreti) 
+  [How Gestione dei segreti AWS uses AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html)(In che modo AWS Secrets Manager utilizza AWS Key Management Service) 
+  [Crittografia e decrittografia del segreto in Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html) 
+  [Articoli del blog su Secrets Manager](https://aws.amazon.com/blogs/security/tag/aws-secrets-manager/) 
+  [Amazon RDS announces integration with Gestione dei segreti AWS](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-rds-integration-aws-secrets-manager/) (Amazon RDS announces integration with AWS Secrets Manager) 

 **Video correlati:** 
+  [Best practice per la gestione, il recupero e la rotazione di segreti su scala](https://youtu.be/qoxxRlwJKZ4) 
+  [Find Hard-Coded Secrets Using Amazon CodeGuru Secrets Detector](https://www.youtube.com/watch?v=ryK3PN--oJs) (Trovare i segreti codificati usando il rilevatore di segreti di Amazon CodeGuru) 
+  [Securing Secrets for Hybrid Workloads Using Gestione dei segreti AWS](https://www.youtube.com/watch?v=k1YWhogGVF8) (Trovare i segreti codificati usando il rilevatore di segreti di Amazon CodeGuru) 

 **Workshop correlati:** 
+  [Store, retrieve, and manage sensitive credentials in Gestione dei segreti AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/497b4908-169f-4e6f-b80d-ef10be3038d3/en-US) (Memorizzare, recuperare e gestire le credenziali sensibili in AWS Secrets Manager) 
+  [Attivazioni ibride AWS Systems Manager](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html) 

# SEC02-BP04 Fai affidamento su un provider di identità centralizzato
<a name="sec_identities_identity_provider"></a>

 Per le identità della forza lavoro (dipendenti e collaboratori) affidati a un provider di identità digitale che ti consenta di gestire le identità in un luogo centralizzato. In questo modo è più semplice gestire l'accesso tra più applicazioni e sistemi, perché crei, assegni, gestisci, revochi e verifichi gli accessi da una singola posizione. 

 **Risultato desiderato:** Hai un provider di identità centralizzato dal quale gestisci centralmente gli utenti della forza lavoro, le policy di autenticazione (come le richieste di autenticazione a più fattori o MFA) e le autorizzazioni per sistemi e applicazioni, come l'assegnazione dell'accesso in base all'appartenenza o agli attributi di un utente. Gli utenti che fanno parte della tua forza lavoro accedono al provider di identità centrale ed effettuano l'accesso federato (autenticazione unica) alle applicazioni interne ed esterne, il che elimina la necessità per gli utenti di ricordare più credenziali. Il provider di identità è integrato con i tuoi sistemi di risorse umane (HR), in modo che le modifiche relative al personale vengano sincronizzate automaticamente con il provider di identità. Ad esempio, se qualcuno lascia l'organizzazione, puoi revocare automaticamente l'accesso alle applicazioni e ai sistemi federati (incluso AWS). Hai abilitato la verifica dettagliata dei log nel tuo provider di identità e stai monitorando questi log per rilevare comportamenti degli utenti insoliti. 

 **Anti-pattern comuni:** 
+  Non utilizzi la federazione e l'autenticazione unica. Gli utenti che appartengono alla tua forza lavoro creano account utente e credenziali separati in più applicazioni e sistemi. 
+  Non hai automatizzato il ciclo di vita delle identità degli utenti che fanno parte della tua forza lavoro, ad esempio integrando il provider di identità con i tuoi sistemi HR. Quando un utente lascia l'organizzazione o cambia ruolo, segui una procedura manuale per eliminare o aggiornare i suoi record in più applicazioni e sistemi. 

 **Vantaggi dell'adozione di questa best practice:** Utilizzare un provider di identità centralizzato ti fornisce un unico posto per gestire le identità e le policy degli utenti che fanno parte della tua forza lavoro, la possibilità di assegnare l'accesso alle applicazioni a utenti e gruppi e la possibilità di monitorare l'attività di accesso degli utenti. Grazie all'integrazione con i sistemi di risorse umane (HR), quando un utente cambia ruolo, queste modifiche vengono sincronizzate con il provider di identità e le applicazioni e le autorizzazioni assegnate vengono aggiornate automaticamente. Quando un utente lascia l'organizzazione, la sua identità viene automaticamente disabilitata nel provider di identità e l'accesso alle applicazioni e ai sistemi federati viene revocato. 

 **Livello di rischio associato se questa best practice non fosse adottata**: elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 **Linee guida per l'accesso ad AWS degli utenti che fanno parte della forza lavoro** 

 Gli utenti che fanno parte della forza lavoro, come dipendenti e collaboratori dell'organizzazione, potrebbero richiedere l'accesso ad AWS per utilizzare la Console di gestione AWS o la AWS Command Line Interface (AWS CLI) per svolgere le proprie mansioni lavorative. Puoi concedere l'accesso ad AWS a tali utenti federando il tuo provider di identità centralizzato AWS a due livelli: federazione diretta a ciascun Account AWS o federazione a più account della tua [organizzazione AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html). 
+  Per federare gli utenti della tua forza lavoro direttamente con ciascuno Account AWS, utilizza un provider di identità centralizzato per federare l'accesso a [AWS Identity and Access Management](https://aws.amazon.com/iam/) in quell'account. Grazie alla sua flessibilità, IAM ti permette di abilitare un [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) o un [Open ID Connect (OIDC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) Identity Provider per ciascun Account AWS e di utilizzare attributi utente federati per il controllo degli accessi. Gli utenti della tua forza lavoro utilizzano il proprio browser Web per accedere al provider di identità e forniscono le proprie credenziali (come password e codici token MFA). Il provider di identità rilascia un'asserzione SAML nel browser che viene inviata all'URL di accesso della Console di gestione AWS, così da consentire all'utente di accedere mediante l'autenticazione unica alla [Console di gestione AWS tramite l'assunzione di un ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html). Gli utenti possono anche ottenere credenziali API AWS temporanee da utilizzare nella [AWS CLI](https://aws.amazon.com/cli/) o [AWS SDK](https://aws.amazon.com/developer/tools/) da [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) tramite [l'assunzione del ruolo IAM utilizzando un'asserzione SAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) ottenuta dal provider di identità. 
+  Per federare gli utenti della tua forza lavoro con più account all'interno dell'organizzazione AWS, puoi usare [https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/) per gestire centralmente l'accesso degli utenti agli Account AWS e alle applicazioni. Attiva Centro di identità per la tua organizzazione e configura la tua origine di identità. IAM Identity Center fornisce una directory di origine delle identità predefinita, che puoi utilizzare per gestire utenti e gruppi. In alternativa, puoi scegliere un'origine di identità esterna [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) tramite SAML 2.0 ed [effettuando il provisioning automatico](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) di utenti e gruppi che utilizzano SCIM, oppure [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html) utilizzando [Directory Service](https://aws.amazon.com/directoryservice/). Una volta configurata un'origine di identità, puoi assegnare l'accesso agli Account AWS a utenti e gruppi, definendo policy di privilegio minimo nel tuo [set di autorizzazioni](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html). Gli utenti della tua forza lavoro possono autenticarsi tramite il provider di identità centrale per accedere al [portale di accesso AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html) ed effettuare l'autenticazione unica per ottenere l'accesso agli Account AWS e alle applicazioni cloud a loro assegnate. Gli utenti possono configurare [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) per autenticarsi con Centro di identità e ottenere le credenziali per eseguire comandi della AWS CLI. Centro di identità consente inoltre l'accesso tramite autenticazione unica ad applicazioni AWS come [Amazon SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) e [ai portali AWS IoT Sitewise Monitor](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html). 

 Dopo aver seguito le indicazioni precedenti, gli utenti della forza lavoro non avranno più bisogno di utilizzare IAM users e gruppi per le normali operazioni quando gestiscono i carichi di lavoro su AWS. Al contrario, gli utenti e i gruppi sono gestiti all'esterno di AWS e gli utenti possono accedere alle risorse AWS come *identità federata*. Le identità federate utilizzano i gruppi definiti dal provider di identità centralizzato. Devi identificare e rimuovere i gruppi IAM, gli IAM users e le credenziali utente di lunga durata (password e chiavi di accesso) che non sono più necessarie nei tuoi Account AWS. Puoi [trovare credenziali inutilizzate](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) utilizzando [il report sulle credenziali IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html), [eliminare gli IAM users interessati](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html) e [rimuovere i gruppi IAM.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html) Puoi applicare una [policy di controllo dei servizi (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) alla tua organizzazione per prevenire la creazione di nuovi IAM users e gruppi, applicando l'accesso ad AWS tramite identità federate. 

 **Linee guida per gli utenti delle tue applicazioni** 

 Puoi gestire le identità degli utenti delle applicazioni, ad esempio un'app per dispositivi mobili, utilizzando [https://aws.amazon.com/cognito/](https://aws.amazon.com/cognito/) come provider di identità centralizzato. Amazon Cognito consente l'autenticazione, l'autorizzazione e la gestione degli utenti per le app Web e mobili. Amazon Cognito fornisce un archivio di identità dimensionabile fino a milioni di utenti, supporta la federazione delle identità sociali e aziendali e offre funzionalità di sicurezza avanzate per proteggere gli utenti e l'azienda. Puoi integrare la tua applicazione Web o mobile personalizzata con Amazon Cognito per aggiungere l'autenticazione degli utenti e il controllo degli accessi alle applicazioni in pochi minuti. Amazon Cognito si fonda su standard di identità aperti come SAML e Open ID Connect (OIDC), supporta varie normative di conformità e si integra con le risorse di sviluppo frontend e backend. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 **Procedure per l'accesso ad AWS degli utenti che fanno parte della forza lavoro** 
+  Federa l'accesso ad AWS degli utenti della tua forza lavoro tramite un provider di identità centralizzato seguendo uno dei seguenti approcci: 
  +  Utilizza IAM Identity Center per abilitare l'autenticazione unica negli Account AWS per più utenti della tua organizzazione AWS tramite la federazione con il provider di identità. 
  +  Utilizza IAM per connettere il provider di identità direttamente a ciascun Account AWS, abilitando un accesso federato e granulare. 
+  Identifica e rimuovi gli IAM users e i gruppi che vengono sostituiti da identità federate. 

 **Passaggi per gli utenti delle tue applicazioni** 
+  Utilizza Amazon Cognito come provider di identità centralizzato per le tue applicazioni. 
+  Integra le applicazioni personalizzate con Amazon Cognito utilizzando OpenID Connect e OAuth. Puoi sviluppare applicazioni personalizzate utilizzando le librerie Amplify, che forniscono interfacce semplici da integrare con una varietà di servizi AWS per l'autenticazione, come Amazon Cognito. 

## Risorse
<a name="resources"></a>

 **Best practice Well-Architected correlate:** 
+  [SEC02-BP06 Utilizzo dei gruppi di utenti e degli attributi](sec_identities_groups_attributes.md) 
+  [SEC03-BP02 Concessione dell'accesso con privilegio minimo](sec_permissions_least_privileges.md) 
+  [SEC03-BP06 Gestione degli accessi in base al ciclo di vita](sec_permissions_lifecycle.md) 

 **Documenti correlati:** 
+  [Identity federation in AWS](https://aws.amazon.com/identity/federation/) 
+  [Best practice per la sicurezza in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [AWS Identity and Access Management Best practices](https://aws.amazon.com/iam/resources/best-practices/) 
+  [Getting started with IAM Identity Center delegated administration](https://aws.amazon.com/blogs/security/getting-started-with-aws-sso-delegated-administration/) 
+  [How to use customer managed policies in IAM Identity Center for advanced use cases](https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanced-use-cases/) 
+  [AWS CLI v2: IAM Identity Center credential provider](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html) 

 **Video correlati:** 
+  [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI) 
+  [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y) 
+  [AWS re:Invent 2018: Mastering Identity at Every Layer of the Cake](https://youtu.be/vbjFjMNVEpc) 

 **Esempi correlati:** 
+  [Workshop: Using AWS IAM Identity Center to achieve strong identity management](https://catalog.us-east-1.prod.workshops.aws/workshops/590f8439-42c7-46a1-8e70-28ee41498b3a/en-US) 
+  [Workshop: Serverless identity](https://identity-round-robin.awssecworkshops.com/serverless/) 

 **Strumenti correlati:** 
+  [Partner AWS con competenze nella sicurezza: gestione di identità e accessi](https://aws.amazon.com/security/partner-solutions/) 
+  [saml2aws](https://github.com/Versent/saml2aws) 

# SEC02-BP05 Verifica e rotazione periodica delle credenziali
<a name="sec_identities_audit"></a>

Sottoponi a audit e ruota periodicamente le credenziali per limitarne il tempo di utilizzo per accedere alle risorse. Le credenziali a lungo termine espongono a molti rischi che possono essere ridotti ruotandole regolarmente.

 **Risultato desiderato:** implementare la rotazione delle credenziali per ridurre i rischi associati all'utilizzo a lungo termine. Esegui regolarmente l'audit e rimedia alla non conformità con le policy di rotazione delle credenziali. 

 **Anti-pattern comuni:** 
+  Nessun audit dell'uso delle credenziali. 
+  Utilizzo non necessario di credenziali a lungo termine. 
+  Utilizzo di credenziali a lungo termine e mancata rotazione regolare. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Quando non si può fare affidamento sulle credenziali temporanee e sono necessarie credenziali a lungo termine, sottoponile a audit per assicurarti che siano applicati i controlli prestabiliti, ad esempio l'autenticazione a più fattori (MFA), che siano soggette a regolare rotazione e dispongano di un livello di accesso appropriato. 

 La convalida periodica, preferibilmente tramite uno strumento automatizzato, è necessaria per verificare che vengano applicati i controlli corretti. Per le identità umane, è necessario richiedere agli utenti di modificare periodicamente le password e ritirare le chiavi di accesso a favore delle credenziali temporanee. Quando passi da utenti AWS Identity and Access Management (IAM) a identità centralizzate, puoi [generare un report delle credenziali](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) per effettuare l'audit degli utenti. 

 Ti consigliamo inoltre di monitorare l'MFA nel tuo provider di identità. Puoi configurare [Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) o utilizzare gli [standard di sicurezza AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-iam-3) per verificare se gli utenti hanno l'MFA abilitata. Considera la possibilità di utilizzare IAM Roles Anywhere per fornire credenziali temporanee per le identità macchina. Nelle situazioni in cui l'utilizzo di credenziali temporanee e ruoli IAM non è possibile, è necessario un audit frequente e la rotazione delle chiavi di accesso. 

 **Passaggi dell'implementazione** 
+  **Eseguire regolarmente l'audit delle credenziali:** l'audit delle identità configurate nel provider di identità e in IAM aiuta a verificare che solo le identità autorizzate abbiano accesso al carico di lavoro. Tali identità possono includere, a titolo esemplificativo ma non esaustivo, utenti IAM, utenti AWS IAM Identity Center, utenti Active Directory o utenti in un diverso provider di identità a monte. Ad esempio, eliminare le persone che lasciano l'organizzazione e i ruoli multi-account che non sono più necessari. Disporre di un processo per sottoporre periodicamente a audit le autorizzazioni ai servizi a cui accede un'entità IAM. Questo aiuta a identificare le policy da modificare per rimuovere le autorizzazioni non utilizzate. Utilizza i report delle credenziali e [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) per eseguire l'audit di autorizzazioni e credenziali IAM. Puoi utilizzare [Amazon CloudWatch per configurare allarmi per chiamate API specifiche](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) effettuate nell'ambiente AWS. [Amazon GuardDuty può anche avvisare di attività impreviste](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html), che potrebbero indicare un accesso estremamente permissivo o un accesso non intenzionale alle credenziali IAM. 
+  **Ruota regolarmente le credenziali:** quando non è possibile utilizzare le credenziali temporanee, ruotare regolarmente le chiavi di accesso IAM a lungo termine, al massimo ogni 90 giorni. Se una chiave di accesso viene involontariamente divulgata a propria insaputa, questo limita la durata di utilizzo delle credenziali per accedere alle risorse. Per informazioni sulla rotazione delle chiavi di accesso per gli utenti IAM, consulta [Rotating access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey). 
+  **Rivedi le autorizzazioni IAM:** per migliorare la sicurezza dell'Account AWS, rivedere e monitorare regolarmente ogni policy IAM. Verifica che le policy rispettino il principio del privilegio minimo. 
+  **Considera la possibilità di automatizzare la creazione e gli aggiornamenti delle risorse IAM:** IAM Identity Center automatizza molte attività IAM, come la gestione dei ruoli e delle policy. In alternativa, AWS CloudFormation può essere utilizzato per automatizzare l'implementazione delle risorse IAM, compresi ruoli e policy, per ridurre la possibilità di errore umano, poiché i modelli possono essere verificati e controllati in versione. 
+  **Utilizza IAM Roles Anywhere per sostituire gli utenti IAM per le identità macchina:** IAM Roles Anywhere consente di utilizzare i ruoli in aree tradizionalmente non accessibili, come i server on-premise. IAM Roles Anywhere utilizza un certificato X.509 affidabile per autenticarsi ad AWS e ricevere credenziali temporanee. L'utilizzo di IAM Roles Anywhere evita la necessità di ruotare queste credenziali, poiché le credenziali a lungo termine non vengono più memorizzate nell'ambiente on-premise. È necessario monitorare e ruotare il certificato X.509 quando si avvicina alla scadenza. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC02-BP02 Utilizzo di credenziali temporanee](sec_identities_unique.md) 
+  [SEC02-BP03 Archiviazione e utilizzo dei segreti in modo sicuro](sec_identities_secrets.md) 

 **Documenti correlati:** 
+  [Nozioni di base su Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [IAM Best Practices](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html)(Best Practice IAM) 
+  [Provider di identità e federazione](https://docs.aws.amazon.com//latest/UserGuide/id_roles_providers.html) 
+  [Soluzioni dei partner per la sicurezza: accesso e controllo degli accessi](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [Credenziali di sicurezza temporanee](https://docs.aws.amazon.com//latest/UserGuide/id_credentials_temp.html) 
+ [ Recupero dei report delle credenziali per l'Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)

 **Video correlati:** 
+  [Best practice per la gestione, il recupero e la rotazione di segreti su scala](https://youtu.be/qoxxRlwJKZ4) 
+  [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) (Gestire le autorizzazioni degli utenti su larga scala con AWS SSO) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

 **Esempi correlati:** 
+ [ Well-Architected Lab - Automated IAM User Cleanup ](https://wellarchitectedlabs.com/security/200_labs/200_automated_iam_user_cleanup/)(Well-Architected Lab - Pulizia automatica degli utenti IAM)
+ [ Well-Architected Lab - Automated Deployment of IAM Groups and Roles ](https://wellarchitectedlabs.com/security/200_labs/200_automated_deployment_of_iam_groups_and_roles/)(Well-Architected Lab - Distribuzione automatica di gruppi e ruoli IAM)

# SEC02-BP06 Utilizzo dei gruppi di utenti e degli attributi
<a name="sec_identities_groups_attributes"></a>

 Man mano che il numero di utenti gestiti cresce, sarà necessario determinare i modi per organizzarli in modo da poterli gestire su vasta scala. Inserisci gli utenti con requisiti di sicurezza comuni in gruppi definiti dal provider di identità e metti in atto meccanismi per garantire che gli attributi utente che potrebbero essere utilizzati per il controllo degli accessi (ad esempio, reparto o posizione) siano corretti e aggiornati. Utilizza questi gruppi e attributi, anziché i singoli utenti, per controllare l'accesso. In questo modo puoi gestire l'accesso centralmente, modificando una volta sola l'appartenenza o gli attributi di un gruppo utente con un [set di autorizzazioni](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsets.html), anziché aggiornare numerose policy individuali quando le esigenze di accesso di un utente cambiano. Puoi utilizzare AWS IAM Identity Center (IAM Identity Center) per gestire gruppi di utenti e attributi. IAM Identity Center supporta la maggior parte degli attributi utilizzati, indipendentemente dal fatto che vengano inseriti manualmente durante la creazione dell'utente o assegnati automaticamente utilizzando un motore di sincronizzazione, come definito nella specifica System for Cross-Domain Identity Management (SCIM). 

Inserisci gli utenti con requisiti di sicurezza comuni in gruppi definiti dal provider di identità e metti in atto meccanismi per garantire che gli attributi utente che potrebbero essere utilizzati per il controllo degli accessi (ad esempio, reparto o posizione) siano corretti e aggiornati. Utilizza questi gruppi e attributi, anziché i singoli utenti, per controllare l'accesso. In questo modo è possibile gestire l'accesso centralmente, modificando una volta sola l'appartenenza o gli attributi di un gruppo utente, anziché aggiornare numerose policy individuali quando le esigenze di accesso di un utente cambiano.

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Se stai utilizzando AWS IAM Identity Center (IAM Identity Center), configura i gruppi: IAM Identity Center offre la possibilità di configurare gruppi di utenti e di assegnare ai gruppi il livello di autorizzazione desiderato. 
  +  [AWS Single Sign-On - Gestione delle identità](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) 
+  Scopri il controllo degli accessi basato su attributi (ABAC): ABAC è una strategia di autorizzazione che definisce i permessi in base agli attributi. 
  +  [Che cos'è ABAC per AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
  +  [Laboratorio: controllo degli accessi basato su tag IAM per EC2](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Nozioni di base su AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [Best practice IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [Provider di identità e federazione](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  [L'utente root dell'account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 

 **Video correlati:** 
+  [Best practice per la gestione, il recupero e la rotazione di segreti su scala](https://youtu.be/qoxxRlwJKZ4) 
+  [Gestione delle autorizzazioni utente su scala con AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

 **Esempi correlati:** 
+  [Laboratorio: controllo degli accessi basato su tag IAM per EC2](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) 

# SEC 3. Come si gestisce l'autenticazione per persone e macchine?
<a name="sec-03"></a>

 Gestisci le autorizzazioni per controllare l'accesso alle identità di persone e macchine che richiedono l'accesso ad AWS e al tuo carico di lavoro. Le autorizzazioni controllano chi può accedere a cosa e a quali condizioni. 

**Topics**
+ [SEC03-BP01 Definizione dei requisiti di accesso](sec_permissions_define.md)
+ [SEC03-BP02 Concessione dell'accesso con privilegio minimo](sec_permissions_least_privileges.md)
+ [SEC03-BP03 Determinazione di un processo per l'accesso di emergenza](sec_permissions_emergency_process.md)
+ [SEC03-BP04 Riduzione delle autorizzazioni in modo continuo](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 Definizione dei guardrail per le autorizzazioni dell'organizzazione](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 Gestione degli accessi in base al ciclo di vita](sec_permissions_lifecycle.md)
+ [SEC03-BP07 Analisi dell'accesso pubblico e multi-account](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 Condivisione delle risorse in modo sicuro all'interno dell'organizzazione](sec_permissions_share_securely.md)
+ [SEC03-BP09 Condivisione sicura delle risorse con terze parti](sec_permissions_share_securely_third_party.md)

# SEC03-BP01 Definizione dei requisiti di accesso
<a name="sec_permissions_define"></a>

Ogni componente o risorsa del carico di lavoro deve essere accessibile da amministratori, utenti finali o altri componenti. Individua una definizione chiara di chi o cosa deve avere accesso a ciascun componente, quindi scegli il tipo di identità e il metodo di autenticazione e autorizzazione appropriati.

 **Anti-pattern comuni:** 
+ Codifica fissa o archiviazione dei segreti nell'applicazione. 
+ Concessione di autorizzazioni personalizzate per ogni utente. 
+ Utilizzo di credenziali di lunga durata. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Ogni componente o risorsa del carico di lavoro deve essere accessibile da amministratori, utenti finali o altri componenti. Individua una definizione chiara di chi o cosa deve avere accesso a ciascun componente, quindi scegli il tipo di identità e il metodo di autenticazione e autorizzazione appropriati.

L'accesso regolare agli Account AWS dell'organizzazione viene fornito utilizzando [l'accesso federato](https://aws.amazon.com/identity/federation/) o un gestore dell'identità centralizzato. Occorre anche centralizzare la gestione delle identità e garantire la presenza di una procedura consolidata per integrare l'accesso ad AWS nel ciclo di vita dell'accesso dei dipendenti. Ad esempio, quando un dipendente passa a un ruolo lavorativo con un livello di accesso diverso, anche la sua appartenenza al gruppo deve cambiare per riflettere i nuovi requisiti di accesso.

 Quando si definiscono i requisiti di accesso per le identità non umane, determina quali applicazioni e componenti devono accedere e come vengono concesse le autorizzazioni. L'utilizzo di ruoli IAM creati con il modello di accesso con privilegi minimi è un approccio consigliato. [Le policy gestite da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) forniscono le policy IAM predefinite che coprono la maggior parte dei casi d'uso comuni.

I servizi AWS, come [Gestione dei segreti AWS](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) e [Archivio dei parametri AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)ti consentono di scollegare i segreti dall'applicazione o dal carico di lavoro in modo sicuro nei casi in cui non è possibile utilizzare i ruoli IAM. In Secrets Manager puoi adottare la rotazione automatica delle credenziali. Puoi usare Systems Manager per fare riferimento a parametri negli script, comandi, documenti SSM, configurazione e flussi di lavoro di automazione utilizzando il nome univoco specificato al momento della creazione del parametro.

Puoi usare AWS Identity and Access Management Roles Anywhere per ottenere [credenziali di sicurezza temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) per i carichi di lavoro eseguiti all'esterno di AWS. I tuoi carichi di lavoro possono utilizzare le stesse [policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) e [ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che usi con le applicazioni AWS per accedere alle risorse AWS. 

 Ove possibile, prediligi le credenziali temporanee a breve termine rispetto a quelle statiche a lungo termine. Per gli scenari in cui gli utenti IAM devono avere l'accesso programmatico e credenziali a lungo termine, utilizza [le ultime informazioni usate per la chiave di accesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) per ruotare e rimuovere le chiavi di accesso. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Il controllo dell'accesso basato su attributi (Attribute-Based Access Control, ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 
+  [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 
+  [AWS Managed policies for IAM Identity Center (Policy gestite da AWS per IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) 
+  [AWS IAM policy conditions (Condizioni delle policy AWS IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) 
+  [Casi d'uso IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html) 
+  [Rimozione di credenziali non necessarie](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+  [Lavorare con le policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 
+  [How to control access to AWS resources based on Account AWS, OU, or organization (Come controllare l'accesso alle risorse AWS in base all'account, all'unità organizzativa o all'organizzazione AWS)](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/) 
+  [Identify, arrange, and manage secrets easily using enhanced search in Gestione dei segreti AWS (Identificazione, organizzazione e gestione semplificate dei segreti con la ricerca avanzata di Gestione dei segreti AWS)](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) 

 **Video correlati:** 
+  [Become an IAM Policy Master in 60 Minutes or Less (Diventa un IAM Policy Master in 60 minuti)](https://youtu.be/YQsK4MtsELU) 
+  [Separation of Duties, Least Privilege, Delegation, and CI/CD (Separazione dei compiti, privilegio minimo, delega e integrazione e distribuzione continua (CI/CD)](https://youtu.be/3H0i7VyTu70) 
+  [Streamlining identity and access management for innovation (Semplificazione della gestione delle identità e degli accessi per l'innovazione)](https://www.youtube.com/watch?v=3qK0b1UkaE8) 

# SEC03-BP02 Concessione dell'accesso con privilegio minimo
<a name="sec_permissions_least_privileges"></a>

 È una best practice concedere alle identità soltanto il livello di accesso di cui hanno bisogno, specificando le operazioni che possono effettuare, le risorse su cui possono operare e a quali condizioni. Affidati ai gruppi e agli attributi di identità per impostare dinamicamente le autorizzazioni su vasta scala, anziché definire le autorizzazioni per i singoli utenti. Ad esempio, puoi concedere a un gruppo di sviluppatori le autorizzazioni per gestire solo le risorse del loro progetto. In questo modo, se uno sviluppatore lascia il progetto, il suo accesso viene automaticamente revocato senza modificare le policy di accesso sottostanti. 

**Risultato desiderato:** gli utenti devono avere solo le autorizzazioni necessarie per portare a termine la loro attività. Gli utenti dovrebbero avere accesso solo agli ambienti di produzione per eseguire un'attività specifica in un intervallo temporale limitato e l'accesso dovrebbe essere revocato una volta completata l'attività. Le autorizzazioni devono essere revocate quando non sono più necessarie, incluso quando un utente passa a un progetto o a un ruolo professionale diversi. I privilegi di amministratore devono essere riservati a un piccolo gruppo di amministratori fidati. Le autorizzazioni devono essere riviste con regolarità per evitare che si accumulino. Account di sistemi o di macchine devono avere il numero minimo di autorizzazioni necessarie per portare a termine un'attività. 

**Anti-pattern comuni:**
+  L'impostazione predefinita è la concessione delle autorizzazioni di amministratore agli utenti. 
+  L'utilizzo dell'utente root per le attività quotidiane. 
+  Creazione di policy eccessivamente permissive, ma senza privilegi completi di amministratore. 
+  La mancata revisione delle autorizzazioni per capire se consentono l'accesso privilegio minimo. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Secondo il principio del [privilegio minimo](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html#grant-least-privilege) le identità dovrebbero essere consentite solo per eseguire il numero minimo di azioni necessarie per completare un'attività specifica. In questo modo usabilità, efficienza e sicurezza sono bilanciate. Seguendo questo principio si limitano gli accessi indesiderati e si può monitorare chi accede a quali risorse. Gli utenti e i ruoli IAM non hanno autorizzazioni per impostazione predefinita. L'utente root ha accesso completo per impostazione predefinita e dovrebbe essere controllato e monitorato con zelo, nonché usato solo per le [attività che richiedono l'accesso root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). 

 Le policy IAM sono utilizzate in modo esplicito per concedere le autorizzazioni ai ruoli IAM o a risorse specifiche. Ad esempio, le policy basate su identità possono essere collegate ai gruppi IAM, mentre i bucket S3 possono essere controllati da policy basate su risorse. 

 Quando crei e colleghi una policy IAM, puoi specificare le azioni del servizio, le risorse e le condizioni che devono essere vere affinché AWS consenta o neghi l'accesso. AWS supporta una varietà di condizioni che contribuiscono a ridurre l'accesso. Ad esempio, se usi la [chiave di condizione](https://docs.aws.amazon.com//latest/UserGuide/reference_policies_condition-keys.html) `PrincipalOrgID`, puoi non autorizzare le operazioni se il richiedente non è parte della tua AWS Organization. 

 Puoi anche controllare le richieste effettuate dai servizi AWS per tuo conto, ad esempio AWS CloudFormation per la creazione di una funzione AWS Lambda, utilizzando la chiave di condizione `CalledVia`. Dovresti avere tipi diversi di policy su più livelli per definire un livello di difesa ben radicato e limitare le autorizzazioni complessive dei tuoi utenti. Puoi anche limitare le autorizzazioni che possono essere concesse e a quali condizioni. Ad esempio, puoi consentire ai team delle applicazioni di creare le proprie policy IAM per i sistemi che creano, ma devi anche applicare un [limite delle autorizzazioni](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) per impostare un limite massimo di autorizzazioni che il sistema può ricevere. 

 **Passaggi dell'implementazione** 
+  **Implementazione di policy con privilegi minimi**: assegna policy di accesso con privilegi minimi a gruppi e ruoli IAM in modo da rispecchiare il ruolo o la funzione dell'utente che hai definito. 
  +  **Policy di base sull'uso delle API**: un modo per stabilire le autorizzazioni necessarie consiste nell'analisi dei log AWS CloudTrail. Questa revisione consente di creare autorizzazioni personalizzate in base alle azioni che l'utente deve realmente eseguire in AWS. [IAM Access Analyzer può generare automaticamente una policy IAM basata](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) [su attività](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/). Puoi usare IAM Access Advisor a livello di account o di organizzazione per [monitorare](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html) [le ultime informazioni consultate per una policy specifica](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html). 
+  **Prendi in considerazione l'uso di [policy gestite da AWS per le funzioni dell'attività](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html).** Quando inizi a creare policy di autorizzazioni dettagliate, può essere difficile sapere da dove iniziare. AWS ha policy gestite per ruoli professionali comuni, ad esempio contabili, amministratori di database e data scientist. Queste policy possono contribuire a limitare l'accesso degli utenti e, al contempo, definiscono come implementare le policy di privilegio minimo. 
+  **Rimuovi le autorizzazioni superflue:** rimuovi le autorizzazioni non necessarie e rivedi quelle eccessivamente permissive. La [generazione di policy di IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/access-analyzer-policy-generation.html) può essere utile per perfezionare le policy relative alle autorizzazioni. 
+  **Verifica che gli utenti abbiano un accesso limitato agli ambienti di produzione:** gli utenti possono accedere agli ambienti di produzione solo se hanno un caso d'uso valido. Una volta eseguite le attività specifiche che richiedono l'accesso alla produzione, l'accesso dell'utente deve essere revocato. Limitare l'accesso agli ambienti di produzione contribuisce a evitare eventi indesiderati con impatto sulla produzione e contiene gli effetti di accessi involontari. 
+ **Considerazioni sui limiti delle autorizzazioni:** un limite delle autorizzazioni è una caratteristica avanzata per utilizzare una policy gestita che imposta il numero massimo di autorizzazioni che una policy basata su identità può concedere a un'entità IAM. Il limite delle autorizzazioni di un'entità le permette di eseguire solo le operazioni consentite dalle policy basate su identità e dai limiti delle autorizzazioni.  
+  **Prendi in considerazione i [tag delle risorse](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) per le autorizzazioni:** un modello di controllo degli accessi basato su attributi che usa tag delle risorse ti consente di concedere l'accesso in base a scopo delle risorse, proprietario, ambiente e altri criteri. Ad esempio, puoi usare tag di risorse per diversificare gli ambienti di produzione e sviluppo. Tramite questi tag puoi limitare gli sviluppatori all'ambiente di sviluppo. Abbinando policy su tag e autorizzazioni, puoi ottenere l'accesso a risorse dettagliate senza dover definire policy personalizzate e complesse per ogni funzione professionale. 
+  **Usa [policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) per AWS Organizations.** Le policy di controllo dei servizi monitorano centralmente il numero massimo di autorizzazioni disponibili per gli account membri della tua organizzazione. È importante notare che le policy di controllo dei servizi consentono di limitare le autorizzazioni dell'utente root negli account membri. Considera anche la possibilità di usare AWS Control Tower, che offre controlli gestiti prescrittivi che arricchiscono AWS Organizations. Puoi anche definire i tuoi controlli in Control Tower. 
+  **Stabilisci una policy del ciclo di vita dell'utente per la tua organizzazione:** le policy del ciclo di vita dell'utente definiscono attività da eseguire quando gli utenti eseguono l'onboarding su AWS, cambiano ruolo o ambito professionale o non hanno più bisogno di accedere a AWS. Le revisioni delle autorizzazioni devono essere eseguite in ogni fase del ciclo di vita di un utente per verificare che siano sufficientemente restrittive e per evitare che si accumulino. 
+  **Stabilisci un piano per analizzare le autorizzazioni con regolarità ed eventualmente rimuovere quelle non necessarie:** dovresti periodicamente analizzare l'accesso degli utenti per verificare che non abbiano autorizzazioni troppo permissive. [AWS Config](https://aws.amazon.com/config/) e IAM Access Analyzer può essere utile in fase di audit delle autorizzazioni utente. 
+ **Definisci una matrice dei ruoli professionali:** una matrice dei ruoli professionali mostra i diversi ruoli e livelli di accesso richiesti all'interno della tua presenza in AWS. Tramite una matrice dei ruoli professionali puoi definire e separare le autorizzazioni in base alle responsabilità degli utenti all'interno dell'organizzazione. Usa i gruppi invece di applicare le autorizzazioni direttamente ai singoli utenti o ruoli.**  **

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Assegnare il privilegio minimo](https://docs.aws.amazon.com//latest/UserGuide/best-practices.html?ref=wellarchitected#grant-least-privilege) 
+  [Limiti delle autorizzazioni per le entità IAM](https://docs.aws.amazon.com//latest/UserGuide/access_policies_boundaries.html) 
+  [Tecniche per la scrittura di policy IAM con privilegio minimo](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/) 
+  [IAM Access Analyzer semplifica l'implementazione delle autorizzazioni con privilegio minimo generando IAM](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/) [policy basate sull'attività di accesso](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/) 
+  [Delegare la gestione delle autorizzazioni agli sviluppatori tramite i limiti delle autorizzazioni IAM](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) 
+  [Perfezionamento delle autorizzazioni in AWS utilizzando le informazioni sull'ultimo accesso](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html) 
+  [Tipi di policy IAM e quando utilizzarle](https://docs.aws.amazon.com//latest/UserGuide/access_policies.html) 
+  [Test delle policy IAM con il simulatore di policy IAM](https://docs.aws.amazon.com//latest/UserGuide/access_policies_testing-policies.html) 
+  [Guardrail in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 
+  [Architetture Zero Trust: una prospettiva AWS](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/) 
+  [Come implementare il principio del privilegio minimo con CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/) 
+  [Il controllo dell'accesso basato su attributi (Attribute-Based Access Control, ABAC)](https://docs.aws.amazon.com//latest/UserGuide/introduction_attribute-based-access-control.html?ref=wellarchitected) 
+ [Riduzione dell'ambito di applicazione della policy mediante visualizzazione dell'attività dell'utente](https://docs.aws.amazon.com//latest/UserGuide/access_policies_access-advisor.html?ref=wellarchitected) 
+  [Visualizzazione dell'accesso al ruolo](https://docs.aws.amazon.com//latest/UserGuide/id_roles_manage_delete.html?ref=wellarchitected#roles-delete_prerequisites) 
+  [Utilizza l'applicazione di tag per organizzare il tuo ambiente e per promuovere la responsabilità](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html?ref=wellarchitected) 
+  [Strategie di applicazione di tag AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/?ref=wellarchitected) 
+  [Applicazione di tag alle risorse AWS](https://aws.amazon.com/premiumsupport/knowledge-center/quicksight-iam-identity-center/) 

 **Video correlati:** 
+  [Next-generation permissions management (Gestione delle autorizzazioni di ultima generazione)](https://www.youtube.com/watch?v=8vsD_aTtuTo) 
+  [Zero Trust: una prospettiva AWS](https://www.youtube.com/watch?v=1p5G1-4s1r0) 
+  [Come posso utilizzare i limiti delle autorizzazioni per limitare utenti e ruoli e impedire l'escalation dei privilegi?](https://www.youtube.com/watch?v=omwq3r7poek) 

 **Esempi correlati:** 
+  [Laboratorio: limiti delle autorizzazioni IAM per delegare la creazione di ruoli](https://wellarchitectedlabs.com/Security/300__Permission_Boundaries_Delegating_Role_Creation/README.html) 
+  [Laboratorio: controllo degli accessi basato su tag IAM per EC2](https://wellarchitectedlabs.com/Security/300__Tag_Based_Access_Control_for_EC2/README.html?ref=wellarchitected) 

# SEC03-BP03 Determinazione di un processo per l'accesso di emergenza
<a name="sec_permissions_emergency_process"></a>

 Crea un processo che consenta l'accesso di emergenza ai tuoi carichi di lavoro nell'improbabile eventualità che si verifichi un problema con il tuo provider di identità centralizzato. 

 È necessario progettare processi per diverse modalità di guasto che possono causare un evento di emergenza. Ad esempio, in circostanze normali, gli utenti della tua forza lavoro si federano nel cloud utilizzando un provider di identità centralizzato ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)) per gestire i propri carichi di lavoro. Tuttavia, se il tuo provider di identità centralizzato genera un errore o la configurazione per la federazione nel cloud viene modificata, gli utenti della tua forza lavoro potrebbero non essere in grado di federarsi nel cloud. Un processo di accesso di emergenza consente agli amministratori autorizzati di accedere alle risorse cloud tramite mezzi alternativi (come una forma alternativa di federazione o l'accesso diretto degli utenti) per risolvere problemi relativi alla configurazione della federazione o ai carichi di lavoro. Il processo di accesso di emergenza viene utilizzato fino al ripristino del normale meccanismo di federazione. 

 **Risultato desiderato:** 
+  Hai definito e documentato le modalità di guasto che costituiscono un'emergenza: considera le circostanze normali e i sistemi da cui dipendono gli utenti per gestire i loro carichi di lavoro. Considera quali guasti possono interessare ognuna di queste dipendenze e causare una situazione di emergenza. Puoi trovare le domande e le best practice nel [Principio di base dell'affidabilità](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html) , utile per identificare le modalità di errore e progettare sistemi più resilienti per ridurre al minimo la probabilità di guasti. 
+  Hai documentato i passaggi da seguire per confermare che un guasto costituisce un'emergenza. Ad esempio, puoi richiedere agli amministratori di identità di controllare lo stato dei provider di identità primari e di standby e, se entrambi non sono disponibili, dichiarare un evento di emergenza per guasto del provider di identità. 
+  È stato definito un processo di accesso di emergenza specifico per ogni tipo di modalità di emergenza o di guasto. Essere specifici può ridurre la tentazione da parte degli utenti di abusare di un processo generale per tutti i tipi di emergenze. I processi di accesso di emergenza descrivono le circostanze in cui ogni processo deve essere o non deve essere utilizzato e indicano processi alternativi che possono essere applicati. 
+  I tuoi processi sono ben documentati con istruzioni e playbook dettagliati che possono essere seguiti in modo rapido ed efficiente. Ricorda che un evento di emergenza può essere un momento stressante per i tuoi utenti, che potrebbero essere sotto pressione per motivi di tempo, quindi progetta il tuo processo in modo che sia il più semplice possibile. 

 **Anti-pattern comuni:** 
+  Non si dispone di procedure di accesso di emergenza ben documentate e collaudate. Gli utenti non sono preparati per un'emergenza e seguono processi improvvisati quando si verifica un evento di emergenza. 
+  I processi di accesso di emergenza dipendono dagli stessi sistemi (come un provider di identità centralizzato) dei normali meccanismi di accesso. Ciò significa che il guasto di un sistema di questo tipo può influire sui normali meccanismi di accesso e di emergenza e compromettere la capacità di ripristino dall'errore. 
+  I processi di accesso di emergenza vengono utilizzati in situazioni non di emergenza. Ad esempio, gli utenti utilizzano spesso in modo improprio i processi di accesso di emergenza poiché trovano più facile apportare modifiche direttamente piuttosto che inviarle tramite una pipeline. 
+  I processi di accesso di emergenza non generano log sufficienti per controllare i processi oppure i log non vengono monitorati per segnalare un potenziale uso improprio dei processi. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Grazie a processi di accesso di emergenza ben documentati e collaudati, puoi ridurre il tempo impiegato dagli utenti per rispondere a un evento di emergenza e risolverlo. Ciò può comportare una riduzione dei tempi di inattività e una maggiore disponibilità dei servizi forniti ai clienti. 
+  È possibile tenere traccia di ogni richiesta di accesso di emergenza e rilevare e avvisare in caso di tentativi non autorizzati di uso improprio del processo per eventi non di emergenza. 

 **Livello di rischio associato se questa best practice non fosse adottata**: medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Questa sezione fornisce indicazioni per la creazione di processi di accesso di emergenza per diverse modalità di errore relative ai carichi di lavoro distribuiti su AWS, a partire da linee guida comuni che si applicano a tutte le modalità di errore fino a linee guida specifiche in base al tipo di errore. 

 **Linee guida comuni per tutte le modalità di errore** 

 Nella progettazione di un processo di accesso di emergenza per una modalità di errore, tieni presente quanto segue: 
+  Documenta i prerequisiti e i presupposti del processo: quando il processo deve e non deve essere utilizzato. Aiuta a descrivere in dettaglio la modalità di errore e a documentare le ipotesi, come lo stato di altri sistemi correlati. Ad esempio, il processo per la modalità di errore 2 presuppone che il provider di identità sia disponibile, ma la configurazione in AWS è stata modificata o è scaduta. 
+  Crea preliminarmente le risorse necessarie per il processo di accesso di emergenza ([SEC10-BP05](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html)). Ad esempio, crea preliminarmente l'accesso di emergenza a un Account AWS con ruoli e IAM users e in tutti gli account del carico di lavoro creando ruoli IAM multi-account. Ciò assicura che queste risorse siano pronte e disponibili quando si verifica un evento di emergenza. Creando preliminarmente le risorse, non si ha alcuna dipendenza dalle API del piano di controllo di AWS [(](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) utilizzate per creare e modificare risorse AWS), che potrebbero non essere disponibili in caso di emergenza. Inoltre, creando preliminarmente le risorse IAM, non è necessario tenere conto di [potenziali ritardi dovuti alla coerenza finale.](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency) 
+  Includi i processi di accesso di emergenza nei tuoi piani di gestione degli incidenti ([SEC10-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html)). Documenta in che modo viene tenuta traccia degli eventi di emergenza e come essi vengono comunicati ad altri membri dell'organizzazione, come i team di pari livello, la leadership e, se applicabile, esternamente ai clienti e ai partner aziendali. 
+  Definisci il processo di richiesta di accesso di emergenza nel tuo sistema di flusso di lavoro esistente, se ne hai uno, per le richieste di assistenza. In genere, tali sistemi di flusso di lavoro consentono di creare moduli di acquisizione per raccogliere informazioni sulla richiesta, tenere traccia della richiesta in ogni fase del flusso di lavoro e aggiungere passaggi di approvazione automatici e manuali. Collega ogni richiesta a un evento di emergenza corrispondente tracciato nel tuo sistema di gestione degli incidenti. Disporre di un sistema uniforme per gli accessi di emergenza consente di tenere traccia di tali richieste in un unico sistema, analizzare le tendenze di utilizzo e migliorare i processi. 
+  Verifica che i processi di accesso di emergenza possano essere avviati solo da utenti autorizzati e richiedano l'approvazione dei colleghi o dei manager dell'utente, a seconda dei casi. Il processo di approvazione deve funzionare efficacemente sia all'interno che al di fuori dell'orario lavorativo. Definisci in che modo le richieste di approvazione possono essere eseguite da approvatori secondari, qualora gli approvatori principali non fossero disponibili, e come vengono inoltrate lungo la catena di gestione fino all'approvazione. 
+  Verifica che il processo generi log di controllo ed eventi dettagliati per i tentativi riusciti e falliti di ottenere l'accesso di emergenza. Monitora sia il processo di richiesta sia il meccanismo di accesso di emergenza per rilevare usi impropri o accessi non autorizzati. Metti in correlazione l'attività con gli eventi di emergenza in corso dal tuo sistema di gestione degli incidenti e avvisa quando le azioni si verificano al di fuori dei periodi di tempo previsti. Ad esempio, devi monitorare e inviare avvisi in merito ad attività nell'Account AWS di accesso di emergenza, poiché non dovrebbe mai essere utilizzato per le normali operazioni. 
+  Testa periodicamente i processi di accesso di emergenza per verificare che i passaggi siano chiari e garantire il livello di accesso corretto in modo rapido ed efficiente. I processi di accesso di emergenza devono essere testati nell'ambito delle simulazioni di risposta agli incidenti ([SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)) e test di ripristino di emergenza ([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)). 

 **Modalità di errore 1: il provider di identità utilizzato per la federazione dell'accesso ad AWS non è disponibile** 

 Come descritto in [SEC02-BP04 Fai affidamento su un provider di identità centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), ti consigliamo di affidarti a un provider di identità centralizzato per federare gli utenti della tua forza lavoro e garantire loro l'accesso agli Account AWS. È possibile federare l'accesso agli Account AWS a più utenti AWS all'interno dell'organizzazione utilizzando IAM Identity Center, oppure federare l'accesso individuale agli Account AWS utilizzando IAM. In entrambi i casi, gli utenti della forza lavoro si autenticano con il provider di identità centralizzato prima di essere reindirizzati a un endpoint di accesso AWS per l'autenticazione unica. 

 Nell'improbabile eventualità che il provider di identità centralizzato non sia disponibile, gli utenti della tua forza lavoro non possono federarsi per accedere agli Account AWS o gestire i propri carichi di lavoro. In questo caso critico, puoi fornire un processo di accesso di emergenza a cui un piccolo gruppo di amministratori può accedere agli Account AWS per eseguire attività urgenti per le quali non è possibile attendere che i tuoi provider di identità centralizzati tornino online. Ad esempio, il tuo provider di identità non è disponibile per 4 ore e durante quel periodo devi modificare i limiti massimi di un gruppo Amazon EC2 Auto Scaling in un account di produzione per gestire un picco imprevisto nel traffico dei clienti. Gli amministratori di emergenza devono seguire la procedura di accesso di emergenza per accedere a un Account AWS di produzione specifico e apportare le modifiche necessarie. 

 Il processo di accesso di emergenza si basa su un accesso di emergenza a un Account AWS creato preliminarmente, che viene utilizzato esclusivamente per questo tipo di accessi e dispone di risorse AWS (come ruoli IAM e IAM users) per supportare il processo di accesso di emergenza. Durante le normali operazioni, nessuno deve accedere all'account di accesso di emergenza ed è necessario monitorare e fornire avvisi riguardo a usi impropri di questo account (per maggiori dettagli, vedi la sezione precedente Linee guida comuni). 

 L'account di accesso di emergenza dispone di ruoli di accesso di emergenza IAM con autorizzazioni per assumere ruoli multi-account negli Account AWS che richiedono l'accesso di emergenza. Questi ruoli IAM sono creati preliminarmente e configurati con policy di attendibilità che valutano i ruoli IAM dell'account di emergenza come attendibili. 

 Per il processo di accesso di emergenza è possibile utilizzare uno dei seguenti approcci: 
+  Creare preliminarmente un set di [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) per gli amministratori di emergenza nell'account di accesso di emergenza con password complesse e token MFA associati. Questi IAM users dispongono delle autorizzazioni per assumere i ruoli IAM che consentono l'accesso multi-account all'Account AWS per cui è richiesto l'accesso di emergenza. Ti consigliamo di creare il minor numero possibile di utenti di questo tipo e di assegnare ogni utente a un unico amministratore di emergenza. Durante un'emergenza, un utente amministratore di emergenza accede all'account di accesso di emergenza utilizzando la propria password e il codice token MFA, passa al ruolo IAM di accesso di emergenza nell'account di emergenza e infine passa al ruolo IAM di accesso di emergenza nell'account del carico di lavoro per eseguire l'azione di modifica di emergenza. Il vantaggio di questo approccio è che ogni IAM user è assegnato a un amministratore di emergenza e puoi sapere quale utente ha effettuato l'accesso esaminando gli eventi CloudTrail. Lo svantaggio è che è necessario mantenere più IAM users con le relative password di lunga durata e i token MFA associati. 
+  È possibile utilizzare l'accesso di emergenza come [utente root dell'Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) per accedere all'account di emergenza, assumere il ruolo IAM per l'accesso di emergenza e poi il ruolo multi-account nell'account del carico di lavoro. È consigliabile impostare una password sicura e più token MFA per l'utente root. Consigliamo inoltre di archiviare la password e i token MFA in un archivio di credenziali aziendali sicuro, che applichi policy di autenticazione e autorizzazione avanzate. Proteggi i fattori di reimpostazione della password e del token MFA: imposta l'indirizzo e-mail dell'account su una lista di distribuzione e-mail monitorata dagli amministratori della sicurezza del cloud e il numero di telefono dell'account su un numero di telefono condiviso anch'esso monitorato dagli amministratori della sicurezza. Il vantaggio di questo approccio è che esiste un solo set di credenziali utente root da gestire. Lo svantaggio è che, trattandosi di un utente condiviso, più amministratori hanno la possibilità di accedere come utente root. Controlla il log eventi della tua vault aziendale per identificare quale amministratore ha utilizzato la password dell'utente root. 

 **Modalità di errore 2: la configurazione del provider di identità su AWS è stata modificata o è scaduta** 

 Per consentire agli utenti della tua forza lavoro di effettuare l'accesso federato agli Account AWS, puoi configurare il IAM Identity Center con un provider di identità esterno o creare un provider di identità IAM ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)). In genere, la configurazione viene effettuata importando un documento XML di metadati SAML fornito dal provider di identità. Il documento XML di metadati include un certificato X.509 corrispondente a una chiave privata utilizzata dal provider di identità per firmare le sue asserzioni SAML. 

 Queste configurazioni lato AWS possono essere modificate o eliminate per errore da un amministratore. In un altro scenario, può accadere che il certificato X.509 importato in AWS sia scaduto e che un nuovo XML di metadati con un nuovo certificato non sia ancora stato importato in AWS. In entrambi gli scenari, la federazione degli utenti della forza lavoro per accedere ad AWS può essere interrotta, costituendo una situazione di emergenza. 

 In un caso di emergenza di questo tipo, puoi fornire agli amministratori di identità l'accesso ad AWS per risolvere i problemi di federazione. Ad esempio, l'amministratore delle identità utilizza la procedura di accesso di emergenza per accedere a un Account AWS, passa a un ruolo nell'account amministratore del Centro di identità e riattiva la federazione aggiornando la configurazione del provider di identità esterno e importando l'ultimo documento XML di metadati SAML rilasciato dal provider di identità. Una volta ristabilita la federazione, gli utenti della forza lavoro continuano a utilizzare il normale processo operativo per federare l'accesso ai propri account di carico di lavoro. 

 È possibile seguire gli approcci descritti nella sezione precedente Modalità di errore 1 per creare un processo di accesso di emergenza. Puoi concedere le autorizzazioni con il privilegio minimo agli amministratori di identità per accedere solo all'account amministratore di Centro di identità ed eseguire azioni sul Centro di identità in quell'account. 

 **Modalità di errore 3: blocco del Centro di identità** 

 Nell'improbabile eventualità di un blocco di IAM Identity Center o di una Regione AWS, ti consigliamo di eseguire una configurazione per fornire l'accesso temporaneo alla Console di gestione AWS. 

 Il processo di accesso di emergenza utilizza la federazione diretta rilasciata dal provider di identità a un ruolo IAM per accedere a un account di emergenza. Per informazioni dettagliate sulle considerazioni relative al processo e alla progettazione, consulta [Configurare l'accesso di emergenza alla Console di gestione AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html). 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 **Passaggi comuni per tutte le modalità di errore** 
+  Crea un Account AWS dedicato per gli accessi di emergenza. Crea preliminarmente le risorse IAM necessarie nell'account, come i ruoli IAM o gli utenti IAM users, e, in modo facoltativo, i provider di identità IAM. Inoltre, crea preliminarmente ruoli IAM mutli-account negli Account AWS del carico di lavoro dotati di relazioni di fiducia con i ruoli IAM corrispondenti nell'account di accesso di emergenza. Puoi utilizzare [CloudFormation StackSets con AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) per creare tali risorse negli account dei membri della tua organizzazione. 
+  Crea Policy di controllo dei servizi AWS Organizations [(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) per negare l'eliminazione e la modifica dei ruoli IAM multi-account negli Account AWS dei membri. 
+  Abilita CloudTrail per l'accesso di emergenza a un Account AWS e invia gli eventi di trail a un bucket S3 centrale nella raccolta di log relativa all'Account AWS. Se utilizzi AWS Control Tower per configurare e gestire il tuo ambiente AWS multi-account, ogni account che crei utilizzando AWS Control Tower o a cui ti iscrivi in AWS Control Tower ha CloudTrail abilitato per impostazione predefinita e viene inviato a un bucket S3 in un Account AWS con archivio di log dedicato. 
+  Monitora l'attività dell'account di accesso di emergenza creando regole EventBridge coerenti con l'accesso alla console e all'attività dell'API da parte dei ruoli IAM di emergenza. Invia notifiche al tuo centro operativo di sicurezza quando si verificano attività al di fuori di un evento di emergenza in corso e di cui hai traccia nel tuo sistema di gestione degli incidenti. 

 **Passaggi aggiuntivi per la Modalità di errore 1: il provider di identità utilizzato per la federazione dell'accesso ad AWS non è disponibile; per la Modalità di errore 2: la configurazione del provider di identità su AWS è stata modificata o è scaduta** 
+  Crea preliminarmente le risorse in base al meccanismo scelto per l'accesso di emergenza: 
  +  **Utilizza IAM users:** crea preliminarmente IAM users con password complesse e dispositivi MFA associati. 
  +  **Usa l'utente root dell'account di emergenza:** configura l'utente root con una password sicura e archivia la password nel tuo archivio di credenziali aziendali. Associa più dispositivi MFA fisici all'utente root e archivia i dispositivi in posizioni a cui i membri del team di amministrazione delle emergenze possono accedere rapidamente. 

 **Passaggi aggiuntivi per la Modalità di errore 3: blocco del Centro di identità** 
+  Come spiegato nei dettagli in [Configurare l'accesso di emergenza alla Console di gestione AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html), per l'accesso di emergenza a un Account AWS, crea un provider di identità IAM per abilitare la federazione SAML diretta dal tuo provider di identità. 
+  Crea gruppi operativi di emergenza nel tuo IdP senza membri. 
+  Crea ruoli IAM corrispondenti ai gruppi operativi di emergenza nell'account di accesso di emergenza. 

## Risorse
<a name="resources"></a>

 **Best practice Well-Architected correlate:** 
+  [SEC02-BP04 Fai affidamento su un provider di identità centralizzato](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html) 
+  [SEC03-BP02 Concessione dell'accesso con privilegio minimo](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html) 
+  [SEC10-BP02 Sviluppo di piani di gestione degli incidenti](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html) 
+  [SEC10-BP07 Esecuzione di giornate di gioco](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html) 

 **Documenti correlati:** 
+  [Set up emergency access to the Console di gestione AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html) 
+  [Abilitazione degli utenti federati SAML 2.0 per accedere a Console di gestione AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html) 
+  [Break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) 

 **Video correlati:** 
+  [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y) 
+  [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI) 

 **Esempi correlati:** 
+  [AWS Break Glass Role](https://github.com/awslabs/aws-break-glass-role) 
+  [AWS customer playbook framework](https://github.com/aws-samples/aws-customer-playbook-framework) 
+  [AWS incident response playbook samples](https://github.com/aws-samples/aws-incident-response-playbooks) 

# SEC03-BP04 Riduzione delle autorizzazioni in modo continuo
<a name="sec_permissions_continuous_reduction"></a>

Man mano che i team determinano gli accessi necessari, rimuovi i permessi non necessari e stabilisci processi di revisione per ottenere i permessi del privilegio minimo. Monitora costantemente e rimuovi le identità e le autorizzazioni inutilizzate per l'accesso sia umano che automatico.

 **Risultato desiderato:** le policy di autorizzazione devono attenersi al principio del privilegio minimo. Man mano che le mansioni e i ruoli vengono definiti meglio, è necessario rivedere le policy di autorizzazione per eliminare le autorizzazioni non necessarie. Questo approccio riduce la portata dell'impatto nel caso in cui le credenziali vengano inavvertitamente esposte o si acceda in altro modo senza autorizzazione. 

 **Anti-pattern comuni:** 
+  L'impostazione predefinita è la concessione delle autorizzazioni di amministratore agli utenti. 
+  Creazione di policy eccessivamente permissive, ma senza privilegi completi di amministratore. 
+  Mantenimento delle policy di autorizzazione anche quando non sono più necessarie. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Quando i team e i progetti sono in fase iniziale, le policy di autorizzazione permissiva possono essere utilizzate per stimolare l'innovazione e l'agilità. Ad esempio, in un ambiente di sviluppo o di test, gli sviluppatori possono avere accesso a un'ampia gamma di servizi AWS. Si consiglia di valutare costantemente gli accessi e di limitare l'accesso solo ai servizi e alle azioni di servizio necessari per completare il lavoro in corso. Raccomandiamo questa valutazione sia per l'identità umana che per quella macchina. Le identità macchina, talvolta chiamate account di sistema o di servizio, sono identità che consentono ad AWS di accedere ad applicazioni o server. Questo accesso è particolarmente importante in un ambiente di produzione, dove autorizzazioni troppo permissive possono avere un ampio impatto e potenzialmente esporre i dati dei clienti. 

 AWS offre diversi metodi per identificare utenti, ruoli, autorizzazioni e credenziali non utilizzati. AWS può anche aiutare ad analizzare l'attività di accesso degli utenti e dei ruoli IAM, comprese le chiavi di accesso associate, e l'accesso alle risorse AWS, come gli oggetti nei bucket Amazon S3. La generazione di policy di AWS Identity and Access Management Access Analyzer può aiutare a creare policy di autorizzazione restrittive in base ai servizi e alle azioni effettive con cui interagisce un principale. [Controllo dell'accesso basato sugli attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) può aiutare a semplificare la gestione delle autorizzazioni, in quanto è possibile fornire autorizzazioni agli utenti utilizzando i loro attributi invece di allegare le policy di autorizzazione direttamente a ciascun utente. 

 **Passaggi dell'implementazione** 
+  **Utilizza [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html):** IAM Access Analyzer aiuta a identificare le risorse nell'organizzazione e negli account, come ad esempio bucket Amazon Simple Storage Service (Amazon S3) o ruoli IAM che sono [condivisi con un'entità esterna](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html). 
+  **Utilizza la [generazione della policy IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html): la** generazione della policy IAM Access Analyzer aiuta a [creare policy di autorizzazione granulari basate su un utente IAM o su un'attività di accesso del ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks). 
+  **Stabilisci una tempistica accettabile e una policy di utilizzo per gli utenti e i ruoli IAM:** utilizza il [timestamp dell'ultimo accesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) per [identificare gli utenti e i ruoli inutilizzati](https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/) e rimuoverli. Rivedi le informazioni sull'ultimo accesso al servizio e sull'ultima azione per identificare e [delimitare le autorizzazioni per specifici utenti e ruoli](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). Ad esempio, puoi utilizzare le informazioni sull'ultimo accesso per identificare le azioni specifiche di Amazon S3 richieste dal ruolo dell'applicazione e delimitare l'accesso del ruolo solo a tali azioni. Le funzionalità relative alle informazioni sull'ultimo accesso sono disponibili nella Console di gestione AWS e consentono di incorporarle in modo programmatico nei flussi di lavoro dell'infrastruttura e negli strumenti automatizzati. 
+  **Considera la [registrazione degli eventi di dati in AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html):** per impostazione predefinita, CloudTrail non registra eventi di dati come le attività a livello di oggetto Amazon S3 (ad esempio, `GetObject` e `DeleteObject`) o le attività della tabella Amazon DynamoDB (ad esempio, `PutItem` e `DeleteItem`). Considera la possibilità di abilitare la registrazione di questi eventi per stabilire quali utenti e ruoli devono accedere a specifici oggetti Amazon S3 o elementi di tabelle DynamoDB. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Assegnare il privilegio minimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+  [Rimozione di credenziali non necessarie](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+ [ Cosa è AWS CloudTrail? ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+  [Working with Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) (Gestire le policy) 
+ [ Registrazione e monitoraggio in DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [ Abilitazione della registrazione di eventi CloudTrail per bucket e oggetti Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)
+ [ Recupero dei report delle credenziali per l'Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)

 **Video correlati:** 
+  [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU) (Diventa un IAM Policy Master in 60 minuti) 
+  [Separation of Duties, Least Privilege, Delegation, and CI/CD (Separazione dei compiti, privilegio minimo, delega e integrazione e distribuzione continua (CI/CD)](https://youtu.be/3H0i7VyTu70) 
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive ](https://www.youtube.com/watch?v=YMj33ToS8cI) [AWS re:Inforce 2022 - Approfondimento su AWS Identity and Access Management (IAM)]

# SEC03-BP05 Definizione dei guardrail per le autorizzazioni dell'organizzazione
<a name="sec_permissions_define_guardrails"></a>

 Stabilisci controlli comuni che limitano l'accesso a tutte le identità nella tua organizzazione. Ad esempio, puoi limitare l'accesso a Regioni AWS specifiche o impedire agli operatori di eliminare risorse comuni, come ad esempio un ruolo IAM utilizzato per il team di sicurezza centrale. 

 **Anti-pattern comuni:** 
+ Esecuzione di carichi di lavoro nell'account di amministratore dell'organizzazione. 
+ Esecuzione di carichi di lavoro di produzione e non di produzione nello stesso account. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Man mano che aumenti e gestisci carichi di lavoro aggiuntivi in AWS, devi separarli utilizzando gli account e gestire questi ultimi utilizzando AWS Organizations. Ti consigliamo di stabilire limiti di autorizzazione comuni che limitano l'accesso a tutte le identità nella tua organizzazione. Ad esempio, puoi limitare l'accesso a Regioni AWS specifiche o impedire al tuo team di eliminare risorse comuni, come ad esempio un ruolo IAM utilizzato dal team di sicurezza centrale. 

 Puoi iniziare implementando delle policy di controllo dei servizi di esempio, come una policy che impedisce agli utenti di disabilitare i servizi chiave. Le policy di controllo dei servizi utilizzano il linguaggio di policy IAM e consentono di stabilire i controlli a cui aderiscono tutti i principali IAM (utenti e ruoli). Puoi limitare l'accesso a specifiche azioni del servizio, risorse e in base a condizioni specifiche per soddisfare le esigenze di controllo degli accessi della tua organizzazione. Se necessario, puoi definire eccezioni ai limiti definiti. Ad esempio, puoi limitare le azioni del servizio per tutte le entità IAM nell'account tranne per un ruolo amministratore specifico. 

 Ti consigliamo di evitare di eseguire carichi di lavoro nell'account di gestione. L'account di gestione deve essere utilizzato per governare e distribuire i guardrail di sicurezza che influiscono sugli account membri. Alcuni servizi AWS supportano l'uso di un account amministratore delegato. Se è disponibile, devi utilizzare questo account delegato anziché l'account di gestione. È necessario limitare scrupolosamente l'accesso all'account dell'amministratore dell'organizzazione. 

L'utilizzo di una strategia multi-account ti consente di avere una maggiore flessibilità nell'applicazione di guardrail ai tuoi carichi di lavoro. L'architettura di riferimento per la sicurezza AWS fornisce le indicazioni prescrittive su come progettare la struttura del tuo account. I servizi AWS come AWS Control Tower forniscono le funzionalità per gestire centralmente i controlli preventivi e investigativi all'interno dell'organizzazione. Definisci uno scopo chiaro per ogni account o unità organizzativa all'interno della tua organizzazione e limita i controlli in linea con tale scopo. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [AWS Organizations](https://aws.amazon.com/organizations/) 
+ [Policy di controllo dei servizi (Service Control Policies, SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 
+ [Get more out of service control policies in a multi-account environment (Ottieni di più dalle policy di controllo dei servizi in un ambiente multi-account)](https://aws.amazon.com/blogs/security/get-more-out-of-service-control-policies-in-a-multi-account-environment/) 
+ [AWS Security Reference Architecture (AWS SRA) (Architettura di riferimento per la sicurezza AWS (AWS SRA))](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html) 

 **Video correlati:** 
+ [Enforce Preventive Guardrails using Service Control Policies (Applicazione di guardrail preventivi utilizzando le policy di controllo dei servizi)](https://www.youtube.com/watch?v=mEO05mmbSms) 
+  [Building governance at scale with AWS Control Tower (Creazione di una governance su vasta scala con AWS Control Tower)](https://www.youtube.com/watch?v=Zxrs6YXMidk) 
+  [AWS Identity and Access Management deep dive (Approfondimenti su AWS Identity and Access Management)](https://www.youtube.com/watch?v=YMj33ToS8cI) 

# SEC03-BP06 Gestione degli accessi in base al ciclo di vita
<a name="sec_permissions_lifecycle"></a>

 Integra i controlli degli accessi con il ciclo di vita degli operatori e delle applicazioni e con il tuo provider di federazione centralizzata. Ad esempio, rimuovi l'accesso di un utente quando lascia l'organizzazione o cambia ruolo. 

Quando gestisci i carichi di lavoro utilizzando account separati, in alcuni casi sarà necessario condividere le risorse tra tali account. Ti consigliamo di condividere le risorse utilizzando [AWS Resource Access Manager (AWS RAM)](http://aws.amazon.com/ram/). Questo servizio ti consente di condividere in modo semplice e sicuro le risorse AWS all'interno della tua organizzazione AWS Organizations e delle unità organizzative. Con AWS RAM, l'accesso alle risorse condivise viene automaticamente concesso o revocato quando gli account vengono spostati da e verso l'organizzazione o l'unità organizzativa con cui sono condivisi. In questo modo puoi garantire che le risorse vengano condivise solo con gli account desiderati.

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Ciclo di vita degli accessi utente: implementa una policy per il ciclo di vita degli accessi utente per i nuovi entranti, le modifiche alle funzioni lavorative e gli uscenti per garantire l'accesso solo agli utenti attuali. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Controllo dell'accesso basato su attributi (Attribute-Based Access Control, ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [Assegnare il privilegio minimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+  [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 
+  [Rimozione di credenziali non necessarie](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+  [Lavorare con le policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 

 **Video correlati:** 
+  [Become an IAM Policy Master in 60 Minutes or Less (Diventa un IAM Policy Master in 60 minuti)](https://youtu.be/YQsK4MtsELU) 
+  [Separation of Duties, Least Privilege, Delegation, and CI/CD (Separazione dei compiti, privilegio minimo, delega e integrazione e distribuzione continua (CI/CD)](https://youtu.be/3H0i7VyTu70) 

# SEC03-BP07 Analisi dell'accesso pubblico e multi-account
<a name="sec_permissions_analyze_cross_account"></a>

Monitora continuamente i risultati che evidenziano l'accesso pubblico e multi-account. Limita l'accesso pubblico e multi-account alle risorse che lo richiedono.

 **Risultato desiderato:** sapere quali risorse AWS sono condivise e con chi. Monitora e sottoponi costantemente a audit le risorse condivise per verificare che siano condivise solo con i principali autorizzati. 

 **Anti-pattern comuni:** 
+  Assenza di un inventario delle risorse condivise. 
+  Mancanza di un processo di approvazione dell'accesso multi-account e dell'accesso pubblico alle risorse. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Se l'account è in AWS Organizations, puoi concedere l'accesso alle risorse all'intera organizzazione, a specifiche unità organizzative o a singoli account. Se l'account non è membro di un'organizzazione, puoi condividere le risorse con account individuali. Puoi concedere l'accesso multi-account diretto utilizzando policy collegate a risorse, ad esempio [policy di bucket Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) o consentendo a un principale in un altro account di assumere un ruolo IAM nel tuo account. Quando utilizzi le policy sulle risorse, verifica che l'accesso sia concesso solo ai principali autorizzati. Definisci un processo per approvare tutte le risorse che devono essere pubblicamente disponibili. 

 [AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) utilizza la [sicurezza comprovabile](https://aws.amazon.com/security/provable-security/) per identificare tutti i percorsi di accesso a una risorsa dall'esterno del suo account. Esamina continuamente le policy delle risorse e segnala i risultati dell'accesso pubblico e multi-account per semplificare l'analisi di accessi potenzialmente estesi. Considera di configurare IAM Access Analyzer con AWS Organizations per assicurarti di avere visibilità su tutti gli account. IAM Access Analyzer consente inoltre di [vedere in anteprima i risultati](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html) prima di implementare le autorizzazioni della risorsa. Questo consente di convalidare che le modifiche alla policy concedono solo l'accesso multi-account e pubblico autorizzati alle risorse. Quando progetti l'accesso multi-account, puoi utilizzare le [policy di attendibilità](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) per controllare in quali casi un ruolo può essere assunto. Ad esempio, puoi utilizzare la chiave di condizione [`PrincipalOrgId` per respingere il tentativo di assumere un ruolo al di fuori di AWS Organizations](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/). 

 [AWS Config può segnalare le risorse](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) che non sono configurate correttamente e, attraverso i controlli delle policy AWS Config, può rilevare le risorse con accesso pubblico configurato. Servizi quali [AWS Control Tower](https://aws.amazon.com/controltower/) e [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) semplificano l'implementazione dei controlli e guardrail investigativi su AWS Organizations per identificare e correggere le risorse esposte pubblicamente. Ad esempio, AWS Control Tower ha un guardrail gestito in grado di rilevare l'eventuale presenza di [snapshot Amazon EBS ripristinabili da Account AWS](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html). 

 **Passaggi dell'implementazione** 
+  **Considera di abilitare [AWS Config per AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html):** AWS Config consente di aggregare i risultati di più account all'interno di un AWS Organizations a un account amministratore delegato. In questo modo si ottiene una visione completa che consente di [implementare Regole di AWS Config su più account per rilevare le risorse accessibili pubblicamente](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html). 
+  **Configura AWS Identity and Access Management Access Analyzer.** IAM Access Analyzer ti aiuta a identificare le risorse nell'organizzazione e negli account, come ad esempio bucket Amazon S3 o ruoli IAMche sono [condivisi con un'entità esterna](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html). 
+  **Utilizza la riparazione automatica in AWS Config per rispondere alle modifiche della configurazione di accesso pubblico dei bucket Amazon S3:** [puoi riattivare automaticamente le impostazioni di blocco dell'accesso pubblico per i bucket Amazon S3](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/). 
+  **Implementa il monitoraggio e gli avvisi per stabilire se i bucket Amazon S3 sono diventati pubblici:** devi disporre di [monitoraggio e avvisi](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/) per stabilire quando Amazon S3 Block Public Access è disabilitato e se i bucket Amazon S3 diventano pubblici. Inoltre, se stai utilizzando AWS Organizations, puoi creare una [policy di controllo del servizio](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) che impedisce di modificare le policy Amazon S3 di accesso pubblico. AWS Trusted Advisor controlla i bucket Amazon S3 che hanno autorizzazioni di accesso aperte. Le autorizzazioni bucket che concedono, caricano o eliminano l'accesso per chiunque danno origine a potenziali problemi di sicurezza, consentendo a chiunque di aggiungere, modificare o rimuovere elementi in un bucket. Il controllo di Trusted Advisor esamina le autorizzazioni bucket esplicite e le policy associate che possono prevalere sulle autorizzazioni bucket. Puoi anche utilizzare AWS Config per monitorare l'accesso pubblico ai bucket Amazon S3. Per ulteriori informazioni, consulta [How to Use AWS Config to Monitor for and Respond to Amazon S3 Buckets Allowing Public Access](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/) (Come utilizzare AWS Config per monitorare e gestire i bucket Amazon S3 che consentono l'accesso pubblico). Durante la revisione degli accessi, è importante considerare quali tipi di dati sono contenuti nei bucket Amazon S3. [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) aiuta a scoprire e a proteggere i dati sensibili, come PII, PHI, e le credenziali, come le chiavi private o quelle AWS. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Utilizzo di AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [AWS Control Tower controls library ](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html) (Libreria di controlli di AWS Control Tower)
+  [AWS Foundational Security Best Practices standard](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) (Standard AWS Foundational Security Best Practices)
+  [AWS Config Managed Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html) (Regole gestite di AWS Config) 
+  [Riferimento dei controlli AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html) 
+ [ Monitoraggio dei risultati dei controlli AWS Trusted Advisor con Amazon EventBridge ](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html)
+ [ Managing AWS Config Rules Across All Accounts in Your Organization](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html) (Gestire le regole di configurazione AWS tra tutti gli account dell'organizzazione)
+ [AWS Config e AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)

 **Video correlati:** 
+ [Best Practices for securing your multi-account environment (Best practice per la protezione dell'ambiente multi-account)](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [Dive Deep into IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0) (Approfondire l'analisi degli accessi IAM)

# SEC03-BP08 Condivisione delle risorse in modo sicuro all'interno dell'organizzazione
<a name="sec_permissions_share_securely"></a>

Con l'aumento del numero di carichi di lavoro, è possibile che sia necessario condividere l'accesso alle risorse in tali carichi di lavoro o eseguire il provisioning delle risorse più volte su più account. Possono esistere costrutti per segmentare il proprio l'ambiente, come ad esempio ambienti di sviluppo, di test e di produzione. Tuttavia, la presenza di costrutti di separazione non limita la possibilità di condividere in modo sicuro. La condivisione di componenti che si sovrappongono consente di ridurre i costi operativi e di garantire un'esperienza coerente, senza dover intuire cosa potrebbe sfuggire durante la creazione della stessa risorsa più volte. 

 **Risultato desiderato:** ridurre al minimo gli accessi indesiderati utilizzando metodi sicuri per condividere le risorse all'interno dell'organizzazione e contribuire all'iniziativa di prevenzione della perdita di dati. Ridurre i costi operativi rispetto alla gestione dei singoli componenti, ridurre gli errori dovuti alla creazione manuale dello stesso componente più volte e aumentare la scalabilità dei carichi di lavoro. I tempi di risoluzione in caso di guasti multipli sono ridotti e la sicurezza nel determinare quando un componente non è più necessario è aumentata. Per una guida prescrittiva sull'analisi delle risorse condivise dall'esterno, consulta [SEC03-BP07 Analisi dell'accesso pubblico e multi-account](sec_permissions_analyze_cross_account.md). 

 **Anti-pattern comuni:** 
+  Mancanza di un processo per il monitoraggio continuo e segnalazione automatica di azioni esterne inaspettate. 
+  Mancanza di una linea di base su ciò che deve e ciò che non deve essere condiviso. 
+  Scelta di una policy di ampia apertura piuttosto che di una condivisione esplicita quando richiesto. 
+  Creazione manuale di risorse fondamentali che si sovrappongono quando necessario. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Progetta i controlli e i modelli di accesso per gestire il consumo di risorse condivise in modo sicuro e solo con entità fidate. Monitora le risorse condivise e controllane costantemente l'accesso ricevendo un avviso in caso di condivisione inappropriata o inaspettata. Consulta [Analisi dell'accesso pubblico e multi-account](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html) come supporto per stabilire una governance che riduca l'accesso esterno alle sole risorse che lo richiedono e per definire un processo di monitoraggio continuo e di avviso automatico. 

 La condivisione multi-account in AWS Organizations è supportata da [una serie di servizi AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html), come [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html), [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html) e [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html). Questi servizi permettono di condividere i dati con un account centrale, di accedere a un account centrale o di gestire risorse e dati da un account centrale. Ad esempio, AWS Security Hub CSPM può trasferire i risultati dai singoli account a un account centrale in cui è possibile visualizzare tutti i risultati. AWS Backup può eseguire un backup di una risorsa e condividerlo tra gli account. Puoi utilizzare [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) per condividere altre risorse comuni, quali [sottoreti VPC e allegati Transit Gateway](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc), [AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) o [pipeline Amazon SageMaker AI](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker). 

 Per limitare l'account alla condivisione di risorse solo all'interno dell'organizzazione, utilizza le [policy di controllo dei servizi](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) (Service Control Policies, SCP) per impedire l'accesso ai principali esterni. Quando condividi le risorse, combina controlli basati sull'identità e controlli di rete per [creare un perimetro di dati per l'organizzazione](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) in modo da proteggere dall'accesso non intenzionale. Un perimetro di dati è un insieme di guardrail preventivi che aiutano a verificare che solo le identità fidate accedano a risorse fidate dalle reti previste. Questi controlli pongono limiti adeguati alle risorse che possono essere condivise e impediscono la condivisione o l'esposizione di risorse che non sono consentite. Ad esempio, nell'ambito del perimetro dei dati, è possibile utilizzare le policy degli endpoint VPC e la condizione `AWS:PrincipalOrgId` per assicurarsi che le identità che accedono ai bucket Amazon S3 appartengano alla propria organizzazione. È importante notare che le [policy di controllo dei servizi non si applicano ai ruoli correlati ai servizi (Service-Linked Roles, LSR) o ai principali del servizio AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions). 

 Quando utilizzi Amazon S3, [disabilita le ACL per il bucket Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) e utilizza le policy IAM per definire il controllo degli accessi. Per [delimitare un accesso a un'origine Amazon S3](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) da [Amazon CloudFront](https://aws.amazon.com/cloudfront/), migra dall'identità di accesso origine (OAI) al controllo di accesso origine (OAC) che supporta funzionalità aggiuntive, inclusa la crittografia lato server con [AWS Key Management Service](https://aws.amazon.com/kms/). 

 In alcuni casi, può essere necessario condividere le risorse al di fuori dell'organizzazione o concedere a terzi l'accesso alle risorse stesse. Per una guida prescrittiva sulla gestione delle autorizzazioni per la condivisione di risorse all'esterno, consulta [Gestione delle autorizzazioni](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html). 

 **Passaggi dell'implementazione** 

1.  **Utilizzo di AWS Organizations.** 

    AWS Organizations è un servizio di gestione degli account che consente di consolidare più Account AWS in un'organizzazione creata e gestita centralmente. È possibile raggruppare gli account in unità organizzative (OU) e associare policy diverse a ciascuna di esse per soddisfare le esigenze di bilancio, sicurezza e conformità. È inoltre possibile controllare il modo in cui i servizi di Intelligenza Artificiale (IA) e di machine learning (ML) di AWS possono raccogliere e archiviare i dati e utilizzare la gestione multi-account dei servizi AWS integrati nelle Organizations. 

1.  **Integrazione delle AWS Organizations con i servizi AWS.** 

    Quando si abilita un servizio AWS a svolgere attività per conto dell'utente negli account membri dell'organizzazione, AWS Organizations crea un ruolo IAM collegato al servizio in ogni account membro. L'accesso attendibile deve essere gestito tramite la Console di gestione AWS, le API AWS o la AWS CLI. Per una guida prescrittiva sull'abilitazione dell'accesso attendibile, consulta [Uso di AWS Organizations con altri servizi AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html) e [Servizi AWS che puoi utilizzare con Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html). 

1.  **Definizione di un perimetro di dati.** 

    Il perimetro AWS è tipicamente rappresentato come un'organizzazione gestita da AWS Organizations. Insieme alle reti e ai sistemi on-premise, l'accesso alle risorse AWS è ciò che molti considerano il perimetro di My AWS. L'obiettivo del perimetro è verificare che l'accesso sia consentito se l'identità è attendibile, la risorsa è attendibile e la rete è conforme. 

   1.  Definizione e implementazione dei perimetri. 

       Segui i passaggi descritti in [Perimeter implementation](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html) (Implementazione del perimetro) nel whitepaper Building a Perimeter on AWS (Costruire un perimetro su AWS) per qualsiasi condizione di autorizzazione. Per una guida prescrittiva sulla protezione del livello di rete, consulta [Protezione delle reti](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-networks.html). 

   1.  Monitoraggio e segnalazione continui. 

       [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) aiuta a identificare le risorse dell'organizzazione e gli account condivisi con entità esterne. Puoi integrare [IAM Access Analyzer con AWS Security Hub CSPM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-securityhub-integration.html) per inviare e aggregare i risultati di una risorsa da IAM Access Analyzer a Security Hub CSPM per analizzare la sicurezza dell'ambiente. Per abilitare l'integrazione, abilita sia IAM Access Analyzer che Security Hub CSPM in ogni Regione per ogni account. Puoi anche utilizzare Regole di AWS Config per eseguire l'audit della configurazione e avvisare la parte interessata mediante [Amazon Q Developer in chat applications con AWS Security Hub CSPM](https://aws.amazon.com/blogs/security/enabling-aws-security-hub-integration-with-aws-chatbot/). Puoi quindi utilizzare i [Documenti di AWS Systems Manager](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) per adottare i provvedimenti correttivi alle risorse non conformi. 

   1.  Per una guida prescrittiva sul monitoraggio e sull'avviso continuo delle risorse condivise esternamente, consulta [Analisi dell'accesso pubblico e multi-account](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html). 

1.  **Utilizza la condivisione delle risorse nei servizi AWS e delimitale di conseguenza.** 

    Molti servizi AWS consentono di condividere le risorse con un altro account o di puntare a una risorsa di un altro account, come [Amazon Machine Image (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) e [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html). Delimita l'API `ModifyImageAttribute` per specificare gli account affidabili con cui condividere l'AMI. Specifica la condizione `ram:RequestedAllowsExternalPrincipals` quando si utilizza AWS RAM per limitare la condivisione solo alla propria organizzazione, per evitare l'accesso da parte di identità non affidabili. Per indicazioni e considerazioni prescrittive [Resource sharing and external targets](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html) (Condivisione delle risorse e target esterni). 

1.  **Utilizzare AWS RAM per condivisioni sicure con un account o con altri Account AWS.** 

    [AWS RAM](https://aws.amazon.com/ram/) consente di condividere in modo sicuro le risorse create con i ruoli e gli utenti del proprio account e con altri utenti Account AWS. In un ambiente multi-account, AWS RAM consente di creare una risorsa una sola volta e di condividerla con altri account. Questo approccio contribuisce a ridurre i costi operativi, fornendo al contempo coerenza, visibilità e verificabilità grazie alle integrazioni con Amazon CloudWatch e AWS CloudTrail, che non si ottengono quando si utilizza l'accesso multi-account. 

    Se si dispone di risorse condivise in precedenza utilizzando una policy basata sulle risorse, è possibile utilizzare l'API [https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) o un'API equivalente per promuovere il passaggio da una condivisione di risorse a una condivisione completa di risorse AWS RAM. 

    In alcuni casi, potrebbe essere necessario adottare ulteriori misure per condividere le risorse. Ad esempio, per condividere un'istantanea crittografata è necessario [condividere una chiave AWS KMS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC03-BP07 Analisi dell'accesso pubblico e multi-account](sec_permissions_analyze_cross_account.md) 
+  [SEC03-BP09 Condivisione sicura delle risorse con terze parti](sec_permissions_share_securely_third_party.md) 
+  [SEC05-BP01 Creazione di livelli di rete](sec_network_protection_create_layers.md) 

 **Documenti correlati:** 
+ [Il proprietario del bucket concede autorizzazioni multi-account per gli oggetti che non sono di sua proprietà](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use Trust Policies with IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) (Come utilizzare le policy di attendibilità con IAM)
+ [Building Data Perimeter on AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) (Creazione del perimetro dei dati in AWS)
+ [How to use an external ID when granting a third party access to your AWS resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) (Come utilizzare un ID esterno quando si concede a una terza parte l'accesso alle risorse AWS)
+ [Servizi AWS che puoi utilizzare con AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [ Establishing a data perimeter on AWS: Allow only trusted identities to access company data ](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)(Applicazione di un perimetro dei dati in AWS: consentire l'accesso ai dati aziendali solo alle identità attendibili)

 **Video correlati:** 
+ [Granular Access with AWS Resource Access Manager](https://www.youtube.com/watch?v=X3HskbPqR2s) (Accesso granulare con Gestione degli accessi alle risorse AWS)
+ [Securing your data perimeter with VPC endpoints (Protezione del perimetro dei dati con gli endpoint VPC)](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [ Establishing a data perimeter on AWS](https://www.youtube.com/watch?v=SMi5OBjp1fI)(Applicazione di un perimetro dei dati in AWS)

 **Strumenti correlati:** 
+ [ Esempi di policy sul perimetro dei dati ](https://github.com/aws-samples/data-perimeter-policy-examples)

# SEC03-BP09 Condivisione sicura delle risorse con terze parti
<a name="sec_permissions_share_securely_third_party"></a>

 La sicurezza dell'ambiente cloud non si ferma alla tua organizzazione. L'organizzazione potrebbe affidare a terzi la gestione di una parte dei dati. La gestione dei permessi per il sistema gestito da terzi deve seguire la pratica dell'accesso just-in-time utilizzando il principio del privilegio minimo con credenziali temporanee. Lavorando a stretto contatto con una terza parte, puoi ridurre congiuntamente la portata dell'impatto e il rischio di accesso non intenzionale. 

 **Risultato desiderato:** le credenziali AWS Identity and Access Management (IAM) a lungo termine, le chiavi di accesso IAM e le chiavi segrete associate a un utente possono essere utilizzate da chiunque, purché le credenziali siano valide e attive. L'utilizzo di credenziali temporanee e di un ruolo IAM consente di migliorare la sicurezza generale riducendo l'impegno per la manutenzione delle credenziali a lungo termine, compresi i costi di gestione e di funzionamento di questi dati sensibili. Utilizzando un identificatore univoco universale (UUID) per l'ID esterno nella policy di attendibilità IAM e mantenendo sotto il proprio controllo le policy IAM collegate al ruolo IAM, puoi sottoporre a audit e verificare che l'accesso concesso a terzi non sia troppo permissivo. Per una guida prescrittiva sull'analisi delle risorse condivise dall'esterno, consulta [SEC03-BP07 Analisi dell'accesso pubblico e multi-account](sec_permissions_analyze_cross_account.md). 

 **Anti-pattern comuni:** 
+  Utilizzo della policy di attendibilità IAM predefinita senza alcuna condizione. 
+  Utilizzo di credenziali IAM e chiavi di accesso a lungo termine. 
+  Riutilizzo di ID esterni. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 In alcuni casi, può essere necessario condividere le risorse al di fuori di AWS Organizations o concedere a terzi l'accesso alle risorse stesse. Ad esempio, una terza parte potrebbe fornire una soluzione di monitoraggio che necessita di accedere alle risorse del tuo account. In questi casi, devi creare un ruolo IAM multi-account con i soli privilegi necessari alla terza parte. Inoltre, devi definire una policy di attendibilità utilizzando la [condizione di ID esterno](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). L'utilizzo di un ID esterno da parte tua o della terza parte può comportare la generazione di un ID univoco per ogni cliente, terza parte o tenancy. Una volta creato, l'ID univoco non deve essere controllato da nessuno, se non da te. La terza parte deve implementare un processo per collegare l'ID esterno al cliente in modo sicuro, verificabile e riproducibile. 

 Puoi anche utilizzare [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) per gestire ruoli IAM per le applicazioni esterne ad AWS che utilizzano le API AWS. 

 Se la terza parte non ha più bisogno di accedere al tuo ambiente, rimuovi il ruolo. Evita di fornire a terze parti credenziali a lungo termine. Mantieni la visibilità degli altri servizi AWS che supportano la condivisione. Ad esempio, AWS Well-Architected Tool consente la [condivisione di un carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) con altri Account AWS e [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) ti aiuta a condividere in modo sicuro una risorsa AWS di tua proprietà con altri account. 

 **Passaggi dell'implementazione** 

1.  **Utilizzare i ruoli multi-account per fornire l'accesso agli account esterni.** 

    I [ruoli multi-account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) riducono la quantità di informazioni sensibili archiviate da account esterni e da terze parti per l'assistenza ai propri clienti. I ruoli multi-account consentono di concedere l'accesso alle risorse AWS del proprio account in modo sicuro a terzi, come i AWS Partner o altri account dell'organizzazione, mantenendo la possibilità di gestire e sottoporre a audit tale accesso. 

    La terza parte può fornire il servizio da un'infrastruttura ibrida o, in alternativa, estrarre i dati in una sede esterna. [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) consente ai carichi di lavoro di terze parti di interagire in modo sicuro con i carichi di lavoro AWS e di ridurre ulteriormente la necessità di credenziali a lungo termine. 

    Non devi utilizzare credenziali a lungo termine o chiavi di accesso associate agli utenti per fornire accesso ad account esterni. Per fornire l'accesso multi-account invece, occorre utilizzare i ruoli multi-account. 

1.  **Utilizzare un ID esterno con terze parti.** 

    L'utilizzo di un [ID esterno](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) consente di designare chi può assumere un ruolo in una policy di attendibilità IAM. La policy di attendibilità può richiedere che l'utente che assume il ruolo dichiari la condizione e l'obiettivo in cui sta operando. Inoltre, il proprietario dell'account può consentire l'assunzione del ruolo solo in determinate circostanze. La funzione principale dell'ID esterno è quella di affrontare e prevenire il problema del [confused deputy](https://docs.aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/). 

    Utilizza un ID esterno se sei il proprietario di un Account AWS e hai configurato un ruolo per una terza parte che accede ad altri Account AWS oltre al tuo, oppure quando ti trovi nella posizione di assumere ruoli per conto di diversi clienti. Collabora con la terza parte o con il AWS Partner per stabilire una condizione di ID esterno da includere nelle policy di attendibilità IAM. 

1.  **Utilizzare ID esterni universalmente univoci.** 

    Implementa un processo che generi un valore univoco casuale per un ID esterno, ad esempio un identificatore univoco universale (UUID). Una terza parte che riutilizza gli ID esterni tra diversi clienti non risolve il problema del confused deputy, perché il cliente A potrebbe essere in grado di visualizzare i dati del cliente B utilizzando l'ARN del ruolo del cliente B insieme all'ID esterno duplicato. In un ambiente multi-tenant, in cui una terza parte supporta più clienti con diversi Account AWS, la terza parte deve utilizzare un ID univoco diverso come ID esterno per ogni Account AWS. La terza parte è responsabile del rilevamento di ID esterni duplicati e della mappatura sicura di ciascun cliente al rispettivo ID esterno. La terza parte deve verificare di poter assumere il ruolo solo quando specifica l'ID esterno. La terza parte deve astenersi dal memorizzare l'ARN del ruolo del cliente e l'ID esterno fino a quando non è richiesto l'ID esterno. 

    L'ID esterno non viene trattato come un segreto, ma non deve essere un valore facilmente individuabile, come un numero di telefono, un nome o un ID di account. Rendi l'ID esterno un campo di sola lettura, in modo che non possa essere modificato per rappresentare la configurazione. 

    L'ID esterno può essere generato da te o dalla terza parte. Definisci un processo per stabilire chi è responsabile della generazione dell'ID. Indipendentemente dall'entità che crea l'ID esterno, la terza parte fa rispettare l'unicità e i formati in modo coerente tra i clienti. 

1.  **Rendere obsolete le credenziali a lungo termine fornite dal cliente.** 

    Rendi obsoleto l'uso di credenziali a lungo termine e utilizza ruoli multi-account oppure IAM Roles Anywhere. Se devi utilizzare credenziali a lungo termine, stabilisci un piano per migrare verso l'accesso basato sui ruoli. Per dettagli sulla gestione delle chiavi, consulta [Identity Management](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) (Gestione dell'identità). Collaborare inoltre con il team dell'Account AWS e con la terza parte per stabilire un runbook di mitigazione dei rischi. Per una guida prescrittiva sulla risposta e la mitigazione dell'impatto potenziale di un incidente di sicurezza, consulta [Incident response](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) (Risposta agli incidenti). 

1.  **Verifica che l'impostazione abbia una guida prescrittiva o sia automatizzata.** 

    La policy creata per l'accesso multi-account deve seguire il [principio del privilegio minimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). La terza parte deve fornire un documento sulla policy del ruolo o un meccanismo di configurazione automatica che utilizzi un modello AWS CloudFormation o un equivalente per l'utente. In questo modo si riduce la possibilità di errori associati alla creazione manuale della policy e si offre una traccia verificabile. Per ulteriori informazioni sull'utilizzo di un modello CloudFormation per creare ruoli trasversali agli account, consulta [Cross-Account Roles](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/) (Ruoli multi-account). 

    La terza parte deve fornire un meccanismo di configurazione automatizzato e verificabile. Tuttavia, utilizzando il documento della policy sui ruoli che delinea gli accessi necessari, è possibile automatizzare l'impostazione del ruolo. Con un modello CloudFormation o equivalente, è necessario monitorare le modifiche con il rilevamento delle derive come parte della pratica di audit. 

1.  **Account per le modifiche.** 

    La struttura del tuo account, la tua necessità di una terza parte o l'offerta di servizi che ti viene fornita possono cambiare. Occorre anticipare i cambiamenti e i fallimenti e pianificare di conseguenza con le persone, i processi e le tecnologie adeguati. Sottoponi periodicamente a audit il livello di accesso fornito e implementa metodi di rilevamento per avvisare l'utente di cambiamenti inattesi. Monitora e sottoponi a audit l'uso del ruolo e del datastore degli ID esterni. Devi essere pronto a revocare l'accesso a terzi, in modo temporaneo o permanente, in seguito a modifiche o modelli di accesso imprevisti. Inoltre, valuta l'impatto dell'operazione di revoca, compreso il tempo necessario per eseguirla, le persone coinvolte, il costo e l'impatto su altre risorse. 

    Per una guida prescrittiva sui metodi di rilevamento, consulta [Best practice di rilevamento](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC02-BP02 Utilizzo di credenziali temporanee](sec_identities_unique.md) 
+  [SEC03-BP05 Definizione dei guardrail per le autorizzazioni dell'organizzazione](sec_permissions_define_guardrails.md) 
+  [SEC03-BP06 Gestione degli accessi in base al ciclo di vita](sec_permissions_lifecycle.md) 
+  [SEC03-BP07 Analisi dell'accesso pubblico e multi-account](sec_permissions_analyze_cross_account.md) 
+ [ SEC04 Rilevamento ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)

 **Documenti correlati:** 
+ [Il proprietario del bucket concede autorizzazioni multi-account per gli oggetti che non sono di sua proprietà](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [ How to use trust policies with IAM roles ](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) (Come utilizzare le policy di attendibilità con i ruoli IAM)
+ [ Delega dell'accesso tra Account AWS tramite i ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [ How do I access resources in another Account AWS using IAM? ](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/) (Come faccio ad accedere alle risorse di un altro account AWS utilizzando IAM?)
+ [ Best practice per la sicurezza in IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [ Logica di valutazione della policy multiaccount ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [ Come utilizzare un ID esterno quando si concede a una terza parte l'accesso alle proprie risorse AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [ Collecting Information from AWS CloudFormation Resources Created in External Accounts with Custom Resources ](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)(Raccolta di informazioni dalle risorse AWS CloudFormation create in account esterni con risorse personalizzate)
+ [ Securely Using External ID for Accessing AWS Accounts Owned by Others ](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)(Utilizzo sicuro dell'ID esterno per l'accesso agli account AWS di proprietà di altri)
+ [ Extend IAM roles to workloads outside of IAM with IAM Roles Anywhere ](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)(Estendere i ruoli IAM a carichi di lavoro esterni a IAM con IAM Roles Anywhere)

 **Video correlati:** 
+ [ How do I allow users or roles in a separate Account AWS access to my Account AWS? ](https://www.youtube.com/watch?v=20tr9gUY4i0)(Come posso consentire agli utenti o ai ruoli di un account AWS separato di accedere al mio account AWS?)
+ [AWS re:Invent 2018: Become an IAM Policy Master in 60 Minutes or Less ](https://www.youtube.com/watch?v=YQsK4MtsELU)(Diventa un IAM Policy Master in 60 minuti)
+ [AWS Knowledge Center Live: IAM Best Practices and Design Decisions ](https://www.youtube.com/watch?v=xzDFPIQy4Ks) (Knowledge Center AWS in diretta: best practice e decisioni di progettazione IAM)

 **Esempi correlati:** 
+ [ Well-Architected Lab - Lambda cross account IAM role assumption (Level 300) ](https://www.wellarchitectedlabs.com/security/300_labs/300_lambda_cross_account_iam_role_assumption/)[Well-Architected Lab: Assunzione di ruoli IAM per account incrociati Lambda (livello 300)]
+ [ Configure cross-account access to Amazon DynamoDB ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)(Configurare l'accesso multi-account ad Amazon DynamoDB)
+ [AWS STS Network Query Tool ](https://github.com/aws-samples/aws-sts-network-query-tool) (Strumento di consultazione della rete AWS STS)

# Rilevamento
<a name="a-detective-controls"></a>

**Topics**
+ [SEC 4. In che modo individui ed esamini gli eventi di sicurezza?](sec-04.md)

# SEC 4. In che modo individui ed esamini gli eventi di sicurezza?
<a name="sec-04"></a>

Acquisisci ed analizza gli eventi a partire da log e parametri per acquistare visibilità. Agisci su eventi di sicurezza e potenziali minacce per contribuire a rendere sicuro il carico di lavoro.

**Topics**
+ [SEC04-BP01 Configurazione dei registri di servizi e applicazioni](sec_detect_investigate_events_app_service_logging.md)
+ [SEC04-BP02 Analisi di log, risultati e parametri a livello centrale](sec_detect_investigate_events_analyze_all.md)
+ [SEC04-BP03 Automazione delle risposte agli eventi](sec_detect_investigate_events_auto_response.md)
+ [SEC04-BP04 Implementazione di eventi di sicurezza fruibili](sec_detect_investigate_events_actionable_events.md)

# SEC04-BP01 Configurazione dei registri di servizi e applicazioni
<a name="sec_detect_investigate_events_app_service_logging"></a>

Mantieni i log degli eventi di sicurezza dei servizi e delle applicazioni. Si tratta di un principio fondamentale di sicurezza per i casi d'uso di audit, indagini e operazioni, nonché di un requisito di sicurezza comune guidato da standard, policy e procedure di governance, rischio e conformità (GRC).

 **Risultato desiderato:** un'organizzazione deve essere in grado di recuperare in modo affidabile e coerente i log degli eventi di sicurezza dei servizi e delle applicazioni AWS in modo tempestivo, quando è necessario soddisfare un processo o un obbligo interno, come la risposta a un incidente di sicurezza. Considera la possibilità di centralizzare i log per ottenere migliori risultati operativi. 

 **Anti-pattern comuni:** 
+  Log archiviati in modo perpetuo o cancellati troppo presto. 
+  Tutti possono accedere ai log. 
+  Affidarsi interamente a processi manuali per la governance e l'utilizzo dei log. 
+  Archiviazione di ogni singolo tipo di log nel caso in cui sia necessario. 
+  Controllo dell'integrità del log solo quando è necessario. 

 **Vantaggi della definizione di questa best practice:** implementare un meccanismo di root cause analysis (RCA) per gli incidenti di sicurezza e una fonte di prove per gli obblighi di governance, rischio e conformità. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Durante un'indagine di sicurezza o in altri casi d'uso basati sui tuoi requisiti, devi essere in grado di esaminare i log pertinenti per registrare e comprendere l'intera portata e la tempistica dell'incidente. I log sono necessari anche per la generazione di avvisi, che indicano che sono avvenute determinate azioni di interesse. È fondamentale selezionare, attivare, memorizzare e impostare i meccanismi di interrogazione e recupero e gli avvisi. 

 **Passaggi dell'implementazione** 
+  **Selezionare e abilitare le origini dei log.** Prima di un'indagine di sicurezza, devi acquisire i log rilevanti per ricostruire retroattivamente l'attività in un Account AWS. Seleziona e attiva le origini dei log rilevanti per i carichi di lavoro. 

   I criteri di selezione delle origini dei log devono essere basati sui casi d'uso richiesti dall'azienda. Stabilisci un percorso per ogni Account AWS utilizzando AWS CloudTrail o un percorso AWS Organizations e configura per esso un bucket Amazon S3. 

   AWS CloudTrail è un servizio di registrazione che tiene traccia delle chiamate API effettuate su un Account AWS, catturando l'attività del servizio AWS. È abilitato per impostazione predefinita e prevede una conservazione di 90 giorni degli eventi di gestione che possono essere [recuperati attraverso la cronologia degli eventi CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) utilizzando la Console di gestione AWS, la AWS CLI o un AWS SDK. Per una conservazione e una visibilità più lunghe degli eventi di dati, [crea un percorso CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) e associalo a un bucket Amazon S3 e, facoltativamente, a un gruppo di log Amazon CloudWatch. In alternativa, puoi creare un [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html), che mantiene i log di CloudTrail per un massimo di sette anni e fornisce una funzionalità di query basata su SQL 

   AWS consiglia ai clienti che utilizzano un VPC di abilitare i log del traffico di rete e del DNS utilizzando rispettivamente i [log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) e i [log delle query del resolver Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html) e di inviarli in streaming a un bucket Amazon S3 o a un gruppo di log CloudWatch. Il log di flusso VPC può essere creato per un VPC, una sottorete o un'interfaccia di rete. Per i log di flusso VPC, puoi scegliere come e dove utilizzarli per ridurre i costi. 

   I log AWS CloudTrail, i log di flusso VPC e i log delle query del resolver Route 53 sono le origini dei log di base per supportare le indagini sulla sicurezza in AWS. Puoi anche utilizzare [Amazon Security Lake](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html) per raccogliere, normalizzare e archiviare questi dati di log in formato Apache Parquet e Open Cybersecurity Schema Framework (OCSF), pronti per essere interrogati. Security Lake supporta anche altri log AWS e log provenienti da origini di terze parti. 

   I servizi AWS possono generare log non acquisiti dalle origini di log di base, come log di Elastic Load Balancing, log di AWS WAF, log di AWS Config, risultati di Amazon GuardDuty, log di audit di Amazon Elastic Kubernetes Service (Amazon EKS) e log del sistema operativo e delle applicazioni delle istanze Amazon EC2. Per un elenco completo delle opzioni di registrazione e monitoraggio, consulta [Appendix A: Cloud capability deﬁnitions – Logging and Events](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/logging-and-events.html) (Appendice A: Definizioni delle capacità del cloud - Registrazione ed eventi) della [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/detection.html) (Guida alla risposta agli incidenti di sicurezza di AWS). 
+  **Ricercare le funzionalità di log per ogni servizio e applicazioneAWS:** ogni servizio e applicazione AWS offre opzioni per l'archiviazione dei log, ognuna con capacità di conservazione e ciclo di vita proprie. I due servizi di archiviazione dei log più comuni sono Amazon Simple Storage Service (Amazon S3) e Amazon CloudWatch. Per lunghi periodi di conservazione, è consigliabile utilizzare Amazon S3 per la sua economicità e per la flessibilità del ciclo di vita. Se l'opzione principale di registrazione è Amazon CloudWatch Logs, puoi prendere in considerazione l'archiviazione dei log ad accesso meno frequente su Amazon S3. 
+  **Selezionare l'archiviazione dei log:** la scelta dell'archiviazione dei log è generalmente legata allo strumento di query utilizzato, alle capacità di conservazione, alla familiarità e al costo. Le opzioni principali per l'archiviazione dei log sono un bucket Amazon S3 o un gruppo CloudWatch Log. 

   Un bucket Amazon S3 offre a possibilità di un'archiviazione economica e duratura, con una policy opzionale per il ciclo di vita. I log archiviati nei bucket Amazon S3 possono essere interrogati utilizzando servizi come Amazon Athena. 

   Un gruppo di log di CloudWatch offre un'archiviazione durevole e una funzione di interrogazione integrata attraverso CloudWatch Logs Insights. 
+  **Identificare la conservazione appropriata dei log:** quando utilizzi un bucket Amazon S3 o un gruppo di log CloudWatch per archiviare i log, è necessario stabilire cicli di vita adeguati per ogni origine di log per ottimizzare i costi di archiviazione e recupero. In genere i clienti hanno a disposizione da tre mesi a un anno di log per le query, con una conservazione fino a sette anni. La scelta della disponibilità e della conservazione deve essere in linea con i requisiti di sicurezza e con un insieme di mandati statutari, normativi e aziendali. 
+  **Abilitare la registrazione per ogni servizio e applicazione AWS con policy di conservazione e ciclo di vita adeguate:** per ogni servizio o applicazione AWS nell'organizzazione, cerca le indicazioni specifiche per la configurazione della registrazione: 
  + [ Configure AWS CloudTrail Trail ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)(Configurazione di un percorso AWS CloudTrail)
  + [ Configure VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) (Configurazione di VPC Flow Logs)
  + [ Configure Amazon GuardDuty Finding Export ](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_exportfindings.html)(Configurazione dell'esportazione di risultati Amazon GuardDuty)
  + [ Configure AWS Config recording ](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-config.html) (Configurazione della registrazione di AWS Config)
  + [ Configure AWS WAF web ACL traffic ](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html)(Configurazione del traffico ACL web di AWS WAF)
  + [ Configure AWS Network Firewall network traffic logs ](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-logging.html)(Configurazione dei log del traffico di rete del firewall di rete AWS)
  + [ Configure Elastic Load Balancing access logs ](https://docs.aws.amazon.com/)(Configurazione dei log di accesso di Elastic Load Balancing)
  + [ Configure Amazon Route 53 resolver query logs ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html)(Configurazione dei log delle query del resolver di Amazon Route 53)
  + [ Configure Amazon RDS logs ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.html)(Configurazione dei log di Amazon RDS)
  + [ Configure Amazon EKS Control Plane logs ](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)(Configurazione dei log del piano di controllo di Amazon EKS)
  + [ Configure Amazon CloudWatch agent for Amazon EC2 instances and on-premises servers ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)(Configurazione dell'agente Amazon CloudWatch per istanze Amazon EC2 e server on-premise)
+  **Selezionare e implementare i meccanismi di interrogazione dei log:** per le query sui log, puoi utilizzare [CloudWatch Logs Insight](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)s per i dati archiviati nei gruppi di log di CloudWatch e [Amazon Athena](https://aws.amazon.com/athena/) e [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) per i dati archiviati in Amazon S3. Inoltre, puoi utilizzare strumenti di interrogazione di terze parti, come un servizio di gestione delle informazioni e degli eventi di sicurezza (SIEM). 

   Il processo di selezione di uno strumento di interrogazione dei log deve considerare gli aspetti relativi a persone, processi e tecnologia delle operazioni di sicurezza. Occorre scegliere uno strumento che soddisfi i requisiti operativi, aziendali e di sicurezza e che sia accessibile e manutenibile a lungo termine. Tieni presente che gli strumenti di interrogazione dei log funzionano in modo ottimale quando il numero di log da analizzare è mantenuto entro i limiti dello strumento. Non è raro avere più strumenti di interrogazione a causa di vincoli tecnici o di costo. 

   Ad esempio, puoi ricorrere a uno strumento di gestione delle informazioni e degli eventi di sicurezza (SIEM) di terze parti per eseguire query sugli ultimi 90 giorni di dati, ma utilizzare Athena per eseguire query oltre i 90 giorni a causa dei costi di importazione dei log di un SIEM. Indipendentemente dall'implementazione, verifica che il tuo approccio riduca al minimo il numero di strumenti necessari per massimizzare l'efficienza operativa, soprattutto durante le indagini su un evento di sicurezza. 
+  **Utilizzare i log per gli avvisi:** AWS fornisce avvisi attraverso diversi servizi di sicurezza: 
  +  [AWS Config](https://aws.amazon.com/config/) monitora e registra le configurazioni delle risorse AWS e consente di automatizzare la valutazione e la correzione delle configurazioni desiderate. 
  +  [Amazon GuardDuty](https://aws.amazon.com/guardduty/) è un servizio di rilevamento delle minacce che monitora costantemente la presenza di attività dannose e di comportamenti non autorizzati per proteggere gli Account AWS e i carichi di lavoro. GuardDuty acquisisce, aggrega e analizza le informazioni provenienti da origini, come ad esempio gestione AWS CloudTrail ed eventi di dati, log DNS, log di flusso VPC e log di audit Amazon EKS. GuardDuty estrae flussi di dati indipendenti direttamente da CloudTrail, log di flusso VPC, log di query DNS ed Amazon EKS. Non è necessario gestire le policy del bucket Amazon S3 o modificare le modalità di raccolta e archiviazione dei log. È comunque consigliabile mantenere questi registri a fini investigativi e di conformità. 
  +  [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) offre un unico luogo che aggrega, organizza e definisce le priorità degli avvisi di sicurezza o delle scoperte provenienti da più servizi AWS e da prodotti opzionali di terze parti, per fornire una visione completa degli avvisi di sicurezza e dello stato di conformità. 

   Esistono anche motori di generazione di avvisi personalizzati per gli avvisi di sicurezza non coperti da questi servizi o per gli avvisi specifici relativi al tuo ambiente. Per informazioni sulla creazione di questi avvisi e rilevamenti, consulta [Detection (Rilevamento) nella AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/detection.html) (Guida alla risposta agli incidenti di sicurezza di AWS). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC04-BP02 Analisi di log, risultati e parametri a livello centrale](sec_detect_investigate_events_analyze_all.md) 
+  [SEC07-BP04 Definizione della gestione del ciclo di vita dei dati](sec_data_classification_lifecycle_management.md) 
+  [SEC10-BP06 Distribuzione anticipata degli strumenti](sec_incident_response_pre_deploy_tools.md) 

 **Documenti correlati:** 
+ [AWS Security Incident Response Guide ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
+ [ Nozioni di base su Amazon Security Lake ](https://aws.amazon.com/security-lake/getting-started/)
+ [ Nozioni di base su: Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)
+  [Soluzione dei partner per la sicurezza: registrazione e monitoraggio](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 

 **Video correlati:** 
+ [AWS re:Invent 2022 - Introducing Amazon Security Lake ](https://www.youtube.com/watch?v=V7XwbPPjXSY)(re:Invent 2022 - Introduzione ad Amazon Security Lake)

 **Esempi correlati:** 
+ [ Assisted Log Enabler for AWS](https://github.com/awslabs/assisted-log-enabler-for-aws/)(Abilitatore di log assistito per AWS)
+ [AWS Security Hub CSPM Findings Historical Export ](https://github.com/aws-samples/aws-security-hub-findings-historical-export)(Esportazione cronologica dei risultati di AWS Security Hub)

 **Strumenti correlati:** 
+ [ Snowflake for Cybersecurity ](https://www.snowflake.com/en/data-cloud/workloads/cybersecurity/)

# SEC04-BP02 Analisi di log, risultati e parametri a livello centrale
<a name="sec_detect_investigate_events_analyze_all"></a>

 i team delle operazioni di sicurezza confidano nella raccolta di log e nell'utilizzo di strumenti di ricerca per scoprire potenziali eventi di interesse, che potrebbero indicare attività non autorizzate o modifiche involontarie. Tuttavia, la semplice analisi dei dati raccolti e l'elaborazione manuale delle informazioni non sono sufficienti per tenere il passo con il volume di informazioni provenienti da architetture complesse. Le sole analisi e i soli resoconti non facilitano l'assegnazione delle risorse giuste per lavorare a un evento in modo adeguato e nei tempi giusti. 

Una best practice per creare un team per le operazioni di sicurezza preparato è integrare profondamente il flusso degli eventi di sicurezza e le scoperte in un sistema di notifica e flusso di lavoro, come un sistema di ticketing, un sistema di bug o altri sistemi riguardanti le informazioni di sicurezza o la gestione degli eventi (SIEM). Ciò elimina il flusso di lavoro da e-mail e report statici e consente di instradare, inoltrare e gestire eventi o risultati. Molte organizzazioni integrano anche gli avvisi di sicurezza nelle loro piattaforme di chat, collaborazione e di produttività per sviluppatori. Per le aziende che intraprendono la strada dell'automazione, un sistema di ticketing basato su API a bassa latenza offre una notevole flessibilità quando si pianifica "cosa automatizzare prima".

Questa best practice si applica non solo agli eventi di sicurezza generati dai messaggi di log che illustrano l'attività degli utenti o gli eventi di rete, ma anche a quelli generati dalle modifiche rilevate nell'infrastruttura stessa. La possibilità di rilevare le modifiche, determinare se una modifica è appropriata e quindi instradare tali informazioni al flusso di lavoro di correzione adatto è essenziale per mantenere e convalidare un'architettura sicura, in un contesto di modifiche difficili da individuare come indesiderabili per impedirne l'esecuzione tramite una combinazione di configurazioni AWS Identity and Access Management(IAM) e AWS Organizations.

Amazon GuardDuty e AWS Security Hub CSPM forniscono meccanismi di aggregazione, deduplicazione e analisi per i record di log che vengono resi disponibili anche tramite altri servizi AWS. GuardDuty acquisisce, aggrega e analizza le informazioni da origini come AWS CloudTrail management and data events, log di VPC DNS e log di flusso VPC. Security Hub CSPM può acquisire, aggregare e analizzare output di GuardDuty, AWS Config, Amazon Inspector, Amazon Macie, AWS Firewall Manager e un numero significativo di prodotti di sicurezza di terze parti disponibili in Marketplace AWS, nonché il codice proprietario, se è stato compilato in modo adeguato. Sia GuardDuty sia Security Hub CSPM hanno un modello membro-amministratore che può aggregare risultati e informazioni su più account. Inoltre, Security Hub CSPM viene spesso utilizzato dai clienti che dispongono di un sistema SIEM on-premise, come un preprocessore e aggregatore di avvisi e log lato AWS, da cui possono quindi acquisire Amazon EventBridge tramite un processore e un server di inoltro basati su AWS Lambda.

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Valuta le opzioni per l'elaborazione dei log: valuta le opzioni disponibili per l'elaborazione dei log. 
  +  [Utilizza Amazon OpenSearch Service per registrare e monitorare (quasi) tutto ](https://d1.awsstatic.com/whitepapers/whitepaper-use-amazon-elasticsearch-to-log-and-monitor-almost-everything.pdf)
  +  [Individuazione di un partner specializzato in soluzioni di registrazione e monitoraggio ](https://aws.amazon.com/security/partner-solutions/#Logging_and_Monitoring)
+  Come inizio per analizzare i log CloudTrail, testa Amazon Athena. 
  + [ Configurazione di Athena per analizzare i log CloudTrail. ](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html)
+  Implementa la registrazione centralizzata in AWS: guarda la soluzione di esempio AWS seguente per centralizzare le registrazioni da più origini. 
  +  [Centralize logging solution ](https://aws.amazon.com/solutions/centralized-logging/https://aws.amazon.com/solutions/centralized-logging/)
+  Implementa la registrazione centralizzata con il partner: i partner APN hanno soluzioni per aiutarti ad analizzare i log centralmente. 
  + [ Registrazione e Monitoraggio ](https://aws.amazon.com/security/partner-solutions/#Logging_and_Monitoring)

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [AWS Answers: Centralized Logging (AWS Answers: registrazione centralizzata) ](https://aws.amazon.com/answers/logging/centralized-logging/)
+  [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+  [Amazon EventBridge ](https://aws.amazon.com/eventbridge)
+ [ Nozioni di base: Amazon CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)
+  [Soluzione dei partner per la sicurezza: registrazione e monitoraggio](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 

 **Video correlati:** 
+ [ Centrally Monitoring Resource Configuration & Compliance ](https://youtu.be/kErRv4YB_T4)
+  [Remediating Amazon GuardDuty and AWS Security Hub CSPM Findings ](https://youtu.be/nyh4imv8zuk)
+ [ Threat management in the cloud: Amazon GuardDuty and AWS Security Hub CSPM](https://youtu.be/vhYsm5gq9jE)

# SEC04-BP03 Automazione delle risposte agli eventi
<a name="sec_detect_investigate_events_auto_response"></a>

 L'utilizzo dell'automazione per analizzare e correggere gli eventi riduce l'impegno e il rischio di errori umani e consente di dimensionare le capacità di analisi. Le revisioni periodiche ti aiuteranno a ottimizzare gli strumenti di automazione e a effettuare un'iterazione costante. 

In AWS, è possibile analizzare gli eventi di interesse e le informazioni relative alle modifiche potenzialmente impreviste in un flusso di lavoro automatizzato utilizzando Amazon EventBridge. Questo servizio fornisce un motore di regole scalabile progettato per gestire sia i formati di eventi AWS nativi (ad esempio eventi AWS CloudTrail), sia gli eventi personalizzati che puoi generare dalla tua applicazione. Amazon GuardDuty consente inoltre di instradare gli eventi a un sistema di flusso di lavoro per i sistemi di risposta agli incidenti (AWS Step Functions), a un account di sicurezza centrale o a un bucket per ulteriori analisi.

È inoltre possibile rilevare le modifiche e instradare queste informazioni al flusso di lavoro corretto utilizzando Regole di AWS Config e [Pacchetti di conformità](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html). AWS Config individua le modifiche ai servizi coperti (con una latenza maggiore rispetto a EventBridge) e genera eventi che possono essere analizzati tramite le regole di Regole di AWS Config per il rollback, per rafforzare le policy di conformità e per inviare le informazioni ai sistemi, ad esempio le piattaforme di gestione delle modifiche e i sistemi di ticketing operativi. Oltre a scrivere funzioni Lambda personalizzate per rispondere agli eventi di AWS Config, puoi utilizzare il [kit per lo sviluppo di regole di Regole di AWS Config](https://github.com/awslabs/aws-config-rdk)e una [libreria di](https://github.com/awslabs/aws-config-rules) Regole di AWS Config open source. I pacchetti di conformità sono una raccolta di Regole di AWS Config e di azioni di correzione che distribuisci come entità singola creata come modello YAML. Un [modello di pacchetto di conformità di esempio](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-wa-Security-Pillar.html) è disponibile per il Well-Architected Security Pillar.

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Implementa un avviso automatizzato con GuardDuty: GuardDuty è un servizio di rilevamento delle minacce che esegue un monitoraggio continuo per individuare attività dannose e comportamenti non autorizzati al fine di proteggere carichi di lavoro e Account AWS. Abilita GuardDuty e configura gli avvisi automatici. 
+  Automatizza i processi di indagine: sviluppa processi automatizzati per indagare su un evento e riferire informazioni a un amministratore per risparmiare tempo. 
  + [ Laboratorio: Amazon GuardDuty hands on ](https://hands-on-guardduty.awssecworkshops.com/)

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [AWS Answers: Centralized Logging (AWS Answers: registrazione centralizzata) ](https://aws.amazon.com/answers/logging/centralized-logging/)
+  [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+  [Amazon EventBridge ](https://aws.amazon.com/eventbridge)
+ [ Nozioni di base: Amazon CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)
+  [Soluzione dei partner per la sicurezza: registrazione e monitoraggio](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 
+ [ Configurazione di Amazon GuardDuty ](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html)

 **Video correlati:** 
+ [ Centrally Monitoring Resource Configuration & Compliance ](https://youtu.be/kErRv4YB_T4)
+  [Remediating Amazon GuardDuty and AWS Security Hub CSPM Findings ](https://youtu.be/nyh4imv8zuk)
+ [ Threat management in the cloud: Amazon GuardDuty and AWS Security Hub CSPM](https://youtu.be/vhYsm5gq9jE)

 **Esempi correlati:** 
+  [Laboratorio: Distribuzione automatizzata di controlli di rilevamento ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Detective_Controls/README.html)

# SEC04-BP04 Implementazione di eventi di sicurezza fruibili
<a name="sec_detect_investigate_events_actionable_events"></a>

 Crea e invia al tuo team avvisi fruibili. Assicurati che includano informazioni pertinenti affinché il team possa intervenire. per ogni meccanismo di rilevamento di cui disponi, devi disporre anche di un processo, sotto forma di [runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html) oppure [playbook](https://wa.aws.amazon.com/wat.concept.playbook.en.html), da analizzare. Ad esempio, quando abiliti [Amazon GuardDuty](http://aws.amazon.com/guardduty), vengono generati [risultati diversi](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings.html). È necessario disporre di una voce runbook per ogni tipo di risultato; ad esempio, se viene rilevato un [trojan](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_trojan.html) , il runbook contiene istruzioni semplici che indicano come eseguire l'analisi e correggere il problema. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Identificazione delle metriche disponibili per i servizi AWS: scopri le metriche a disposizione attraverso Amazon CloudWatch per i servizi in uso. 
  +  [Documentazione del servizio AWS](https://aws.amazon.com/documentation/) 
  +  [Utilizzare i parametri Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
+  Configurazione degli avvisi Amazon CloudWatch. 
  +  [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+  [Amazon EventBridge ](https://aws.amazon.com/eventbridge)
+  [Soluzione dei partner per la sicurezza: registrazione e monitoraggio](https://aws.amazon.com/security/partner-solutions/#logging-monitoring) 

 **Video correlati:** 
+ [ Centrally Monitoring Resource Configuration & Compliance (Monitoraggio centrale della configurazione e della conformità delle risorse) ](https://youtu.be/kErRv4YB_T4)
+  [Remediating Amazon GuardDuty and AWS Security Hub CSPM Findings (Correzione Amazon GuardDuty e risultati AWS Security Hub) ](https://youtu.be/nyh4imv8zuk)
+ [ Threat management in the cloud: Amazon GuardDuty and AWS Security Hub CSPM (Gestione delle minacce nel cloud: Amazon GuardDuty e AWS Security Hub) ](https://youtu.be/vhYsm5gq9jE)

# Protezione dell’infrastruttura
<a name="a-infrastructure-protection"></a>

**Topics**
+ [SEC 5. In che modo proteggi le risorse di rete?](sec-05.md)
+ [SEC 6. In che modo proteggi le risorse di calcolo?](sec-06.md)

# SEC 5. In che modo proteggi le risorse di rete?
<a name="sec-05"></a>

Qualsiasi carico di lavoro che abbia una qualche forma di connettività di rete, che si tratti di Internet o di una rete privata, richiede più livelli di difesa per proteggere da minacce esterne e interne basate sulla rete.

**Topics**
+ [SEC05-BP01 Creazione di livelli di rete](sec_network_protection_create_layers.md)
+ [SEC05-BP02 Controllo del traffico a tutti i livelli](sec_network_protection_layered.md)
+ [SEC05-BP03 Automatizzazione della protezione di rete](sec_network_protection_auto_protect.md)
+ [SEC05-BP04 Implementazione di funzioni di ispezione e protezione](sec_network_protection_inspection.md)

# SEC05-BP01 Creazione di livelli di rete
<a name="sec_network_protection_create_layers"></a>

Raggruppa i componenti che condividono requisiti di sensibilità in livelli per ridurre al minimo la portata potenziale dell'impatto di un accesso non autorizzato. Ad esempio, un cluster di database in un senza necessità di accesso a Internet deve essere posizionato in sottoreti senza routing da o verso Internet. Il traffico deve provenire solo dalla risorsa adiacente meno sensibile. Considera un'applicazione web che si trova dietro un sistema di bilanciamento del carico. Il tuo database non deve essere accessibile direttamente dal sistema di bilanciamento del carico. Solo il sistema logico aziendale o il server web devono avere accesso diretto al database. 

 **Risultato desiderato:** creare una rete stratificata. Le reti a livelli aiutano a raggruppare logicamente componenti di rete simili. Inoltre, riducono la portata potenziale dell'impatto di un accesso non autorizzato alla rete. Una rete adeguatamente stratificata rende più difficile l'accesso a risorse aggiuntive all'interno dell'ambiente AWS da parte di utenti non autorizzati. Oltre a proteggere i percorsi di rete interni, è necessario proteggere anche gli edge di rete, come le applicazioni web e gli endpoint API. 

 **Anti-pattern comuni:** 
+  Creazione di tutte le risorse in un singolo VPC o una singola sottorete. 
+  Utilizzo di gruppi di sicurezza troppo permissivi. 
+  Mancato utilizzo di sottoreti. 
+  Accesso diretto agli archivi di dati, come i database. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Componenti come istanze Amazon Elastic Compute Cloud (Amazon EC2), cluster di database Amazon Relational Database Service (Amazon RDS) e funzioni AWS Lambda che condividono i requisiti di raggiungibilità possono essere segmentati in livelli formati da sottoreti. Considera la possibilità di implementare carichi di lavoro serverless, come le funzioni di [Lambda](https://docs.aws.amazon.com/lambda/index.html), all'interno di un VPC o dietro un [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html). Le attività di [AWS Fargate](https://aws.amazon.com/fargate/getting-started/) che non necessitano di accesso a Internet devono essere collocate in sottoreti prive di percorsi da o verso Internet. Questo approccio a più livelli attenua l'impatto di una configurazione a un solo livello errata che può consentire un accesso non intenzionale. Per AWS Lambda è possibile eseguire le funzioni nel proprio VPC per sfruttare i controlli basati sul VPC. 

 Per una connettività di rete che può includere migliaia di VPC, Account AWS e reti on-premise, è necessario utilizzare [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/). Transit Gateway agisce come un hub che controlla l'instradamento del traffico tra tutte le reti collegate, che agiscono come raggi. Il traffico tra Amazon Virtual Private Cloud (Amazon VPC) e Transit Gateway rimane sulla rete privata AWS, riducendo così l'esposizione esterna a utenti non autorizzati e a potenziali problemi di sicurezza. Il peering tra regioni di Transit Gateway cripta anche il traffico interregionale, senza un singolo punto di errore o un collo di bottiglia della larghezza di banda. 

 **Passaggi dell'implementazione** 
+  **Utilizzare [Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html) per analizzare il percorso tra un'origine e una destinazione in base alla configurazione:** Reachability Analyzer consente di automatizzare la verifica della connettività da e verso le risorse collegate al VPC. La presente analisi viene eseguita esaminando la configurazione (non vengono inviati pacchetti di rete per condurre l'analisi). 
+  **Utilizzare lo [Strumento di analisi degli accessi alla rete Amazon VPC](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html) per identificare l'accesso di rete non intenzionale alle risorse:** lo Strumento di analisi degli accessi alla rete Amazon VPC consente di specificare i requisiti di accesso alla rete e di identificare i potenziali percorsi di rete. 
+  **Valutare se le risorse devono trovarsi in una sottorete pubblica:** non collocare le risorse nelle sottoreti pubbliche del VPC a meno che non debbano assolutamente ricevere traffico di rete in entrata da origini pubbliche. 
+  **Creare [ sottoreti nel VPC](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html):** crea sottoreti per ogni livello di rete (in gruppi che includono più zone di disponibilità) per migliorare la microsegmentazione. Verifica inoltre di aver associato le [tabelle di instradamento](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html) corrette alle sottoreti per controllare l'instradamento e la connettività Internet. 
+  **Utilizzare [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/security-group-policies.html) per gestire i gruppi di sicurezza VPC:** AWS Firewall Manager contribuisce a ridurre l'onere di gestione derivante dall'uso di più gruppi di sicurezza. 
+  **Utilizzare [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) per la protezione contro le più comuni vulnerabilità del web:** AWS WAF può contribuire a migliorare la sicurezza degli edge ispezionando il traffico alla ricerca di vulnerabilità web comuni, come l'iniezione SQL. Consente inoltre di limitare il traffico da indirizzi IP provenienti da determinati Paesi o aree geografiche. 
+  **Utilizzare [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) come rete di distribuzione di contenuti (CDN):** Amazon CloudFront può contribuire a velocizzare l'applicazione web memorizzando i dati più vicino agli utenti. Può anche migliorare la sicurezza degli edge applicando HTTPS, limitando l'accesso ad aree geografiche e garantendo che il traffico di rete possa accedere alle risorse solo quando viene instradato attraverso CloudFront. 
+  **Utilizzare [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) per la creazione di interfacce di programmazione delle applicazioni (API):** Amazon API Gateway aiuta a pubblicare, monitorare e proteggere le API REST, HTTPS e WebSocket. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html) 
+ [ Amazon Inspector ](https://aws.amazon.com/inspector)
+  [Amazon VPC Security](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html) (Sicurezza di Amazon VPC) 
+ [ Reachability Analyzer ](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)
+ [Strumento di analisi degli accessi alla rete Amazon VPC](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/getting-started.html#run-analysis)

 **Video correlati:** 
+  [AWS Transit Gateway reference architectures for many VPCs ](https://youtu.be/9Nikqn_02Oc)(Architetture di riferimento di AWS Transit Gateway per molte VPC)
+  [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield](https://youtu.be/0xlwLEccRe0)(Accelerazione e protezione delle applicazioni con Amazon CloudFront, AWS WAF e AWS Shield) 
+ [AWS re:Inforce 2022 - Validate effective network access controls on AWS](https://www.youtube.com/watch?v=aN2P2zeQek0) (re:Inforce 2022: Convalida di controlli di accesso alla rete efficaci su AWS)
+ [AWS re:Inforce 2022 - Advanced protections against bots using AWS WAF](https://www.youtube.com/watch?v=pZ2eftlwZns)(AWS re:Inforce 2022 - Protezioni avanzate contro i bot utilizzando AWS WAF)

 **Esempi correlati:** 
+  [Well-Architected Lab - Automated Deployment of VPC ](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html)(Well-Architected Lab: Implementazione automatica di VPC) 
+ [ Workshop: Amazon VPC Network Access Analyzer](https://catalog.us-east-1.prod.workshops.aws/workshops/cf2ecaa4-e4be-4f40-b93f-e9fe3b1c1f64) (Workshop: Strumento di analisi degli accessi alla rete Amazon VPC)

# SEC05-BP02 Controllo del traffico a tutti i livelli
<a name="sec_network_protection_layered"></a>

  durante la progettazione della topologia di rete, è necessario esaminare i requisiti di connettività di ciascun componente. Ad esempio, va esaminato se un componente richiede accessibilità a Internet (in entrata e in uscita), connettività a VPC, servizi edge e data center esterni. 

 Un VPC consente di definire la topologia di rete che si estende su una regione Regione AWS con un intervallo di indirizzi IPv4 privati impostato dall'utente o un intervallo di indirizzi IPv6 selezionato da AWS. È necessario applicare più controlli con un approccio di difesa avanzata sia per il traffico in entrata che per quello in uscita, tra cui l'uso di gruppi di sicurezza (firewall di ispezione stateful), liste di controllo degli accessi di rete, sottoreti e tabelle di routing. All'interno di un VPC, puoi creare sottoreti in una zona di disponibilità. Ogni sottorete può avere una tabella di routing associata che definisce le regole di instradamento per la gestione dei percorsi del traffico all'interno della sottorete. Puoi definire una sottorete Internet instradabile tramite un percorso che va a un gateway Internet o NAT collegato al VPC o attraverso un altro VPC. 

 Un'istanza, un database Amazon Relational Database Service(Amazon RDS) o un altro servizio che viene avviato all'interno di un VPC ha un proprio gruppo di sicurezza per interfaccia di rete. Questo firewall è esterno al livello del sistema operativo e può essere utilizzato per definire le regole per il traffico consentito in entrata e in uscita. Puoi anche definire le relazioni tra i gruppi di sicurezza. Ad esempio, le istanze all'interno di un gruppo di sicurezza a livello di database accettano solo il traffico dalle istanze all'interno del livello dell'applicazione, in riferimento ai gruppi di sicurezza applicati alle istanze coinvolte. A meno che non utilizzi protocolli non TCP, non dovrebbe essere necessario disporre di un'istanza Amazon Elastic Compute Cloud(Amazon EC2) accessibile direttamente da internet (anche con porte limitate da gruppi di sicurezza) senza un sistema di bilanciamento del carico o [CloudFront](https://aws.amazon.com/cloudfront). Questo aiuta a proteggerla da accessi non intenzionali dovuti a un problema del sistema operativo o dell'applicazione. Una sottorete può anche avere una lista di controllo degli accessi di rete collegata, che funge da firewall stateless. È necessario configurare la lista di controllo degli accessi di rete per limitare l'ambito del traffico consentito tra i livelli; tieni presente che è necessario definire le regole sia in entrata che in uscita. 

 Alcuni servizi AWS richiedono dei componenti per accedere a internet per le chiamate API, in cui [si trovano gli endpoint API AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html) . Altri servizi AWS usano [Endpoint VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html) all'interno dei Amazon VPC. Molti servizi AWS, tra cui Amazon S3 e Amazon DynamoDB, supportano gli endpoint VPC e questa tecnologia è stata generalizzata in [AWS PrivateLink](https://aws.amazon.com/privatelink/). Ti consigliamo di usare questo approccio per accedere ai servizi AWS, ai servizi di terze parti e ai servizi proprietari ospitati in sicurezza in altri VPC. Tutto il traffico di rete su AWS PrivateLink rimane sul backbone AWS globale e non attraversa mai internet. La connettività può solo essere avviata dal consumatore del servizio e non dal provider del servizio. Usando l'accesso AWS PrivateLink per i servizi esterni è possibile creare VPC isolati senza accesso a internet e proteggere i VPC da vettori di minacce esterni. I servizi di terze parti possono usare AWS PrivateLink per consentire ai propri clienti di connettersi ai servizi dai propri VPC su indirizzi IP privati. Per gli asset del VPC che devono effettuare connessioni in uscita a Internet, queste possono essere effettuate solo in uscita (unidirezionale) tramite un gateway NAT gestito da AWS, un gateway Internet per connessioni solo in uscita o proxy Web creati e gestiti dall'utente. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Controlla il traffico di rete in un VPC: implementa le best practice di VPC per controllare il traffico. 
  +  [Sicurezza Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html) 
  +  [Endpoint VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) 
  +  [Gruppo di sicurezza Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) 
  +  [ACL di rete](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) 
+  Controlla il traffico a livello di edge: implementa servizi edge, come Amazon CloudFront, per fornire un ulteriore livello di protezione e altre funzionalità. 
  +  [Casi d'uso Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/IntroductionUseCases.html) 
  +  [AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
  +  [AWS Web Application Firewall (AWS WAF)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-section.html) 
  +  [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
  +  [Amazon VPC Ingress Routing](https://aws.amazon.com/about-aws/whats-new/2019/12/amazon-vpc-ingress-routing-insert-virtual-appliances-forwarding-path-vpc-traffic/) 
+  Controlla il traffico di rete privato: implementa servizi in grado di proteggere il traffico privato per il carico di lavoro. 
  +  [Amazon VPC Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) 
  +  [Amazon VPC Endpoint Services (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) 
  +  [Amazon VPC Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
  +  [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) 
  +  [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) 
  +  [AWS Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/user-getting-started.html) 
  +  [Amazon S3 Access Points](https://docs.aws.amazon.com/AmazonS3/latest/dev/access-points.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) 
+  [Amazon Inspector](https://aws.amazon.com/inspector) 
+  [Nozioni di base su AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) 

 **Video correlati:** 
+  [AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc) 
+  [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield](https://youtu.be/0xlwLEccRe0)

 **Esempi correlati:** 
+  [Laboratorio: Distribuzione automatizzata di VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 

# SEC05-BP03 Automatizzazione della protezione di rete
<a name="sec_network_protection_auto_protect"></a>

 Automatizza i meccanismi di protezione per creare una rete in grado di difendersi da sola grazie alle informazioni sulle minacce e al rilevamento delle anomalie. Ad esempio, strumenti di rilevamento e prevenzione delle intrusioni in grado di adattarsi alle minacce attuali e di ridurre il loro impatto. Un firewall per applicazioni Web è un esempio di dove è possibile automatizzare la protezione della rete, ad esempio utilizzando la soluzione Automatismi di sicurezza di AWS WAF ([https://github.com/awslabs/aws-waf-security-automations](https://github.com/awslabs/aws-waf-security-automations)) per bloccare automaticamente le richieste provenienti da indirizzi IP associati a noti attori di minacce. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Automatizza la protezione per il traffico basato sul Web: AWS offre una soluzione che usa AWS CloudFormation per distribuire automaticamente una serie di regole AWS WAF progettate per filtrare gli attacchi comuni basati sul Web. Gli utenti hanno la possibilità di scegliere tra caratteristiche di protezione preconfigurate che definiscono le regole incluse in una lista di controllo accessi Web (ACL Web) di AWS WAF. 
  +  [Automazioni di sicurezza AWS WAF](https://aws.amazon.com/solutions/aws-waf-security-automations/) 
+  Considera le soluzioni AWS Partner: i partner AWS offrono centinaia di prodotti leader nel settore che sono equivalenti, identici o si integrano ai controlli esistenti negli ambienti on-premise. Questi prodotti integrano i servizi AWS esistenti per permettere di distribuire un'architettura di sicurezza completa e un'esperienza più fluida nel cloud e negli ambienti on-premise. 
  +  [Sicurezza dell'infrastruttura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) 
+  [Amazon Inspector](https://aws.amazon.com/inspector) 
+ [Sicurezza di Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html)
+  [Nozioni di base su AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) 

 **Video correlati:** 
+  [AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc) 
+  [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield](https://youtu.be/0xlwLEccRe0)

 **Esempi correlati:** 
+  [Laboratorio: Distribuzione automatizzata di VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 

# SEC05-BP04 Implementazione di funzioni di ispezione e protezione
<a name="sec_network_protection_inspection"></a>

 Ispeziona e filtra il traffico a ogni livello. Puoi ispezionare le configurazioni VPC per rilevare potenziali accessi indesiderati con [VPC Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html). Puoi specificare i requisiti di accesso alla rete e individuare percorsi di rete potenziali che non li soddisfano. Per i componenti che eseguono transazioni tramite protocolli basati su HTTP, un firewall per applicazioni Web può aiutare a proteggere dagli attacchi comuni. [AWS WAF](https://aws.amazon.com/waf) è un firewall per applicazioni Web che consente di monitorare e bloccare le richieste HTTP che corrispondono alle regole configurabili inoltrate a un'API di Amazon API Gateway, ad Amazon CloudFront o a un Application Load Balancer. Per iniziare a usare AWS WAF, puoi utilizzare [Regole gestite da AWS](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group) in combinazione con le tue oppure puoi utilizzare [integrazioni dei partner esistenti](https://aws.amazon.com/waf/partners/). 

 Per gestire le protezioni di AWS WAF, AWS Shield Advanced e i gruppi di sicurezza di Amazon VPC in AWS Organizations, puoi utilizzare AWS Firewall Manager. Questo consente di configurare e gestire centralmente le regole del firewall tra gli account e le applicazioni, rendendo più semplice il dimensionamento dell'applicazione delle regole comuni. Consente inoltre di rispondere rapidamente agli attacchi utilizzando [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-responding.html)o [soluzioni](https://aws.amazon.com/solutions/aws-waf-security-automations/) che bloccano automaticamente le richieste indesiderate alle applicazioni Web. Firewall Manager funziona anche con [AWS Network Firewall](https://aws.amazon.com/network-firewall/). AWS Network Firewall è un servizio gestito che usa un motore di regole per garantire un controllo granulare sul traffico di rete stateful e stateless. Supporta le specifiche [dell'intrusion prevention system (IPS)](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html) open source compatibile con Suricata per le regole che contribuiscono alla protezione del carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Configura Amazon GuardDuty: GuardDuty è un servizio di rilevamento delle minacce che esegue un monitoraggio continuo per individuare attività dannose e comportamenti non autorizzati al fine di proteggere carichi di lavoro e account Account AWS. Abilita GuardDuty e configura gli avvisi automatici. 
  +  [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) 
  +  [Laboratorio: Distribuzione automatizzata di controlli di rilevamento](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Detective_Controls/README.html) 
+  Configura i log di flusso del cloud privato virtuale (VPC): Log di flusso VPC è una funzione che ti permette di acquisire informazioni sul traffico IP in entrata e in uscita dalle interfacce di rete nel tuo VPC. I dati del log di flusso possono essere pubblicati su Amazon CloudWatch Logs e Amazon Simple Storage Service (Amazon S3). Dopo aver creato un log di flusso, puoi recuperarne e visualizzarne i dati nella destinazione scelta. 
+  Considera il mirroring del traffico VPC: il mirroring del traffico è una caratteristica di Amazon VPC che puoi utilizzare per copiare il traffico di rete da un'interfaccia di rete elastica di istanze Amazon Elastic Compute Cloud (Amazon EC2) e quindi inviarlo ad appliance di sicurezza e monitoraggio fuori banda per l'ispezione dei contenuti, il monitoraggio delle minacce e la risoluzione dei problemi. 
  +  [Mirroring del traffico del VPC](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-section.html) 
+  [Amazon Inspector](https://aws.amazon.com/inspector) 
+  [Sicurezza Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html) 
+  [Nozioni di base su AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) 

 **Video correlati:** 
+  [AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc) 
+  [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield](https://youtu.be/0xlwLEccRe0) 

 **Esempi correlati:** 
+  [Laboratorio: Distribuzione automatizzata di VPC](https://www.wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 

# SEC 6. In che modo proteggi le risorse di calcolo?
<a name="sec-06"></a>

Le risorse di calcolo nel carico di lavoro richiedono più livelli di difesa per contribuire alla protezione da minacce esterne ed interne. Le risorse di calcolo includono istanze EC2, container, funzioni di AWS Lambda, servizi di database, dispositivi IoT e altro.

**Topics**
+ [SEC06-BP01 Gestione delle vulnerabilità](sec_protect_compute_vulnerability_management.md)
+ [SEC06-BP02 Riduzione della superficie d'attacco](sec_protect_compute_reduce_surface.md)
+ [SEC06-BP03 Implementazione di servizi gestiti](sec_protect_compute_implement_managed_services.md)
+ [SEC06-BP04 Automatizzazione della protezione delle risorse di calcolo](sec_protect_compute_auto_protection.md)
+ [SEC06-BP05 Concessione del permesso di eseguire azioni a distanza](sec_protect_compute_actions_distance.md)
+ [SEC06-BP06 Convalida dell'integrità del software](sec_protect_compute_validate_software_integrity.md)

# SEC06-BP01 Gestione delle vulnerabilità
<a name="sec_protect_compute_vulnerability_management"></a>

Scansiona e correggi frequentemente le vulnerabilità del codice, delle dipendenze e dell'infrastruttura per proteggere da nuove minacce.

 **Risultato desiderato:** creare e mantenere un programma di gestione delle vulnerabilità. Esegui regolarmente scansioni e patch su risorse quali istanze Amazon EC2, container Amazon Elastic Container Service (Amazon ECS) e carichi di lavoro Amazon Elastic Kubernetes Service (Amazon EKS). Configura finestre di manutenzione per le risorse gestite da AWS, come i database Amazon Relational Database Service (Amazon RDS). Utilizza la scansione statica del codice per ispezionare il codice sorgente delle applicazioni alla ricerca di problemi comuni. Considera la possibilità di effettuare test di penetrazione (pen-test) delle applicazioni web se l'organizzazione dispone delle competenze necessarie o se può avvalersi di un'assistenza esterna. 

 **Anti-pattern comuni:** 
+  Assenza di un programma di gestione delle vulnerabilità. 
+  Esecuzione di patch di sistema senza considerare la gravità o la prevenzione del rischio. 
+  Utilizzo di software che ha superato la data di fine vita (EOL) prevista dal fornitore. 
+  Implementazione del codice in produzione prima di aver analizzato i problemi di sicurezza. 

 **Vantaggi dell'adozione di questa best practice:** 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Un programma di gestione delle vulnerabilità comprende la valutazione della sicurezza, l'identificazione dei problemi, la definizione delle priorità e l'esecuzione di operazioni di patch per risolvere i problemi. L'automazione è la chiave per la scansione continua dei carichi di lavoro alla ricerca di problemi e di esposizioni di rete non intenzionali e per l'esecuzione di interventi correttivi. L'automazione della creazione e dell'aggiornamento delle risorse fa risparmiare tempo e riduce il rischio che gli errori di configurazione creino ulteriori problemi. Un programma di gestione delle vulnerabilità ben progettato dovrebbe considerare anche la verifica delle vulnerabilità durante le fasi di sviluppo e implementazione del ciclo di vita del software. L'implementazione della gestione delle vulnerabilità durante lo sviluppo e la distribuzione aiuta a ridurre le possibilità che una vulnerabilità si diffonda nell'ambiente di produzione. 

 L'implementazione di un programma di gestione delle vulnerabilità richiede una buona conoscenza del [Modello di responsabilità condivisa di AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) e del suo rapporto con i carichi di lavoro specifici. Secondo tale modello, AWS è responsabile della protezione dell'infrastruttura del Cloud AWS. Questa infrastruttura è composta da hardware, software, reti e strutture che eseguono i servizi Cloud AWS. La responsabilità della sicurezza nel cloud spetta a te, ad esempio per quanto riguarda i dati effettivi, la configurazione della sicurezza, le attività di gestione delle istanze Amazon EC2 e la verifica che gli oggetti Amazon S3 siano classificati e configurati correttamente. L'approccio alla gestione delle vulnerabilità può variare anche in base ai servizi utilizzati. Ad esempio, AWS gestisce l'applicazione di patch per il nostro servizio di database relazionale gestito Amazon RDS, ma tu sei responsabile dell'applicazione di patch dei database autogestiti. 

 AWS offre una serie di servizi per la gestione delle vulnerabilità [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) esegue continuamente la scansione dei carichi di lavoro AWS alla ricerca di problemi software e di accessi di rete non intenzionali. [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) supporta la gestione dell'applicazione di patch sulle istanze Amazon EC2. Amazon Inspector e Systems Manager possono essere visualizzati in [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html), un servizio di gestione della postura di sicurezza del cloud che aiuta ad automatizzare i controlli di sicurezza AWS e a centralizzare gli avvisi di sicurezza. 

 [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) può aiutare a identificare potenziali problemi nelle applicazioni Java e Python utilizzando l'analisi statica del codice. 

 **Passaggi dell'implementazione** 
+  **Configurare [Amazon Inspector](https://docs.aws.amazon.com/inspector/v1/userguide/inspector_introduction.html):** Amazon Inspector rileva automaticamente le istanze Amazon EC2 appena lanciate, le funzioni Lambda e le immagini di container idonee inviate ad Amazon ECR e le analizza immediatamente alla ricerca di problemi di software, potenziali difetti ed esposizione di rete non intenzionale. 
+  **Eseguire la scansione del codice sorgente:** esegui la scansione delle librerie e delle dipendenze alla ricerca di problemi e difetti. [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) può scansionare e fornire consigli per risolvere i [problemi di sicurezza più comuni](https://docs.aws.amazon.com/codeguru/detector-library/index.html) per le applicazioni Java e Python. [OWASP Foundation](https://owasp.org/www-community/Source_Code_Analysis_Tools) pubblica un elenco di strumenti per l'analisi del codice sorgente (noti anche come strumenti SAST). 
+  **Implementare un processo che consenta di eseguire la scansione dell'ambiente e di applicarvi le patch, nonché di eseguire la scansione come parte di un processo di compilazione di una pipeline CI/CD:** implementa un processo per la scansione e l'applicazione di patch per i problemi delle dipendenze e dei sistemi operativi per proteggerti dalle nuove minacce. Tale processo deve essere eseguito regolarmente. La gestione delle vulnerabilità del software è essenziale per capire dove è necessario applicare le patch o risolvere i problemi del software. Stabilisci le priorità per la correzione di potenziali problemi di sicurezza incorporando le valutazioni di vulnerabilità nelle fasi iniziali della pipeline di integrazione continua/consegna continua (CI/ CD). L'approccio può variare in base ai servizi AWS utilizzati. Per verificare la presenza di potenziali problemi nel software in esecuzione nelle istanze Amazon EC2, aggiungi [Amazon Inspector](https://aws.amazon.com/inspector/) alla pipeline per avvisare l'utente e interrompere il processo di creazione se vengono rilevati problemi o potenziali difetti. Amazon Inspector monitora le risorse in modo continuo. Puoi anche utilizzare i prodotti open source come [OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/), [Snyk](https://snyk.io/product/open-source-security-management/), [OpenVAS](https://www.openvas.org/), i sistemi di gestione dei pacchetti e gli strumenti AWS Partner per la gestione delle vulnerabilità. 
+  **Utilizza [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html):** sei responsabile della gestione delle patch per le risorse AWS, incluse le istanze Amazon Elastic Compute Cloud (Amazon EC2), le Amazon Machine Image (AMI) e le altre risorse di calcolo. [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) automatizza il processo di patch delle istanze gestite con aggiornamenti di sicurezza e di altro tipo. Patch Manager può essere utilizzato per applicare le patch alle istanze Amazon EC2 sia per i sistemi operativi che per le applicazioni, inclusi applicazioni Microsoft, service pack di Windows e aggiornamenti di versione minori per le istanze basate su Linux. Oltre a Amazon EC2, Patch Manager può essere utilizzato anche per applicare patch ai server on-premise. 

   Per avere un elenco dei sistemi operativi supportati, consulta [Sistemi operativi supportati](https://docs.aws.amazon.com/systems-manager/latest/userguide/prereqs-operating-systems.html) nella Guida per l'utente di Systems Manager. Puoi eseguire la scansione delle istanze per visualizzare solo un report delle patch mancanti oppure puoi eseguire la scansione e installare automaticamente tutte le patch mancanti. 
+  **Utilizzare [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html):** Security Hub CSPM offre una visione completa dello stato di sicurezza in AWS. Raccoglie i dati di sicurezza su [più servizi AWS](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-internal-providers.html) e fornisce tali risultati in un formato standardizzato, consentendo di dare priorità ai risultati della sicurezza tra i servizi AWS. 
+  **Utilizzare [AWS CloudFormation](https://aws.amazon.com/cloudformation/):** [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) è un servizio Infrastruttura come codice (IaC) che può essere d'aiuto nella gestione delle vulnerabilità, automatizzando l'implementazione delle risorse e standardizzando l'architettura delle risorse tra più account e ambienti. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Security Overview of AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS--Security.pdf) (Panoramica sulla sicurezza di AWS Lambda) 
+ [ Amazon CodeGuru ](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [Improved, Automated Vulnerability Management for Cloud Workloads with a New Amazon Inspector ](https://aws.amazon.com/blogs/aws/improved-automated-vulnerability-management-for-cloud-workloads-with-a-new-amazon-inspector/)(Gestione delle vulnerabilità migliorata e automatizzata per i carichi di lavoro cloud con un nuovo Amazon Inspector)
+ [ Automate vulnerability management and remediation in AWS using Amazon Inspector and AWS Systems Manager – Part 1 ](https://aws.amazon.com/blogs/mt/automate-vulnerability-management-and-remediation-in-aws-using-amazon-inspector-and-aws-systems-manager-part-1/)(Automatizzare la gestione delle vulnerabilità e la bonifica in AWS utilizzando Amazon Inspector e AWS Systems Manager - Parte 1)

 **Video correlati:** 
+  [Securing Serverless and Container Services](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI) (Best practice di sicurezza per il servizio di metadati dell'istanza Amazon EC2) 

# SEC06-BP02 Riduzione della superficie d'attacco
<a name="sec_protect_compute_reduce_surface"></a>

 Riduci la superficie di attacco ad accessi non intenzionali attraverso la protezione avanzata dei sistemi operativi e riducendo al minimo i componenti, le librerie e i servizi di consumo esterni in uso. lnizia riducendo i componenti inutilizzati, siano essi pacchetti del sistema operativo o applicazioni per carichi di lavoro basati su Amazon Elastic Compute Cloud (Amazon EC2) o moduli software esterni nel codice (per tutti i carichi di lavoro). Esistono molte guide per la configurazione della protezione avanzata e della sicurezza dei sistemi operativi e dei software dei server comuni. Ad esempio, puoi iniziare dal [Center for Internet Security](https://www.cisecurity.org/) e iterare.

 In Amazon EC2 puoi creare Amazon Machine Image (AMI), con patch e rafforzamento, per soddisfare i requisiti di sicurezza specifici della tua organizzazione. Le patch e altri controlli di sicurezza che applichi sulle AMI diventano effettivi nel momento in cui vengono creati: non sono dinamici, a meno che tu non decida di modificarli subito dopo l'avvio, ad es. con AWS Systems Manager. 

 Puoi semplificare il processo di creazione di AMI sicure con EC2 Image Builder. EC2 Image Builder riduce in modo significativo l'impegno richiesto per creare e mantenere immagini "golden" senza scrivere e aggiornare la manutenzione. Quando sono disponibili gli aggiornamenti software, Image Builder produce automaticamente una nuova immagine senza richiedere agli utenti di iniziare una creazione manuale. EC2 Image Builder consente di convalidare con facilità la funzionalità e la sicurezza delle immagini prima di usarle in produzione con test tuoi e forniti da AWS. Puoi anche applicare impostazioni di sicurezza fornite da AWS per proteggere ulteriormente le immagine e rispettare i criteri di sicurezza interni, Ad esempio, puoi produrre immagini conformi allo standard Security Technical Implementation Guide (STIG) con modelli forniti da AWS. 

 Con l'utilizzo di strumenti di analisi del codice statico di terze parti puoi identificare problemi di sicurezza comuni, ad esempio limiti di input delle funzioni non controllati e CVE applicabili. Puoi utilizzare [Amazon CodeGuru](https://aws.amazon.com/codeguru/) per le lingue supportate. Possono anche essere utilizzati strumenti di controllo delle dipendenze per stabilire se le librerie a cui si collega il codice sono le versioni più recenti, se le stesse sono prive di CVE e se le condizioni di licenza soddisfano i requisiti delle policy del software. 

 Con Amazon Inspector puoi eseguire valutazioni della configurazione a fronte delle istanze per CVE note, confrontare i valori rispetto a benchmark di sicurezza e automatizzare la notifica dei difetti. Amazon Inspector viene eseguito sulle istanze di produzione o in una pipeline di compilazione e invia una notifica agli sviluppatori e agli ingegneri quando sono disponibili nuovi risultati. Puoi accedere in modo programmatico ai risultati e indirizzare i tuoi team ai sistemi di backlog e rilevamento dei bug. [EC2 Image Builder](https://aws.amazon.com/image-builder/) può essere utilizzato per mantenere le immagini del server (AMI) tramite l'applicazione di patch automatizzata, l'applicazione di policy di sicurezza fornite da AWS e altre personalizzazioni. Quando utilizzi i container, implementa la [scansione delle immagini ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html) nella pipeline di compilazione regolarmente confrontandola con il repository di immagini per cercare le CVE nei container. 

 Anche se Amazon Inspector e altri strumenti sono efficaci per identificare configurazioni ed eventuali CVE presenti, sono necessari altri metodi per testare il carico di lavoro a livello di applicazione. [Il fuzzing](https://owasp.org/www-community/Fuzzing) è un metodo noto di individuazione dei bug mediante l'automazione per inserire dati malformati nei campi di input e in altre aree dell'applicazione. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Rafforzamento del sistema operativo: configura i sistemi operativi per adeguarli alle best practice. 
  +  [Protezione di Amazon Linux](https://www.cisecurity.org/benchmark/amazon_linux/) 
  +  [Protezione di Microsoft Windows Server](https://www.cisecurity.org/benchmark/microsoft_windows_server/) 
+  Rafforzamento delle risorse containerizzate: configura le risorse containerizzate per la conformità alle best practice in materia di sicurezza. 
+  Implementa le best practice AWS Lambda. 
  +  [Best practice di AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Sostituzione di un host bastione con Amazon EC2 Systems Manager](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Panoramica sulla sicurezza di AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Video correlati:** 
+  [Esecuzione di carichi di lavoro con livello di sicurezza elevato su Amazon EKS](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services](https://youtu.be/kmSdyN9qiXY) 
+  [Best practice di sicurezza per il servizio di metadati dell'istanza Amazon EC2](https://youtu.be/2B5bhZzayjI) 

 **Esempi correlati:** 
+  [Laboratorio: Distribuzione automatizzata di firewall per applicazioni Web](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 

# SEC06-BP03 Implementazione di servizi gestiti
<a name="sec_protect_compute_implement_managed_services"></a>

 Implementa servizi che gestiscono le risorse, ad esempio Amazon Relational Database Service (Amazon RDS), AWS Lambda e Amazon Elastic Container Service (Amazon ECS), per ridurre le attività di manutenzione della sicurezza nell'ambito del modello di responsabilità condivisa. Ad esempio, Amazon RDS aiuta a configurare, gestire e dimensionare un database relazionale e automatizza le attività di amministrazione quali provisioning di hardware, configurazione di database, applicazione di patch e backup. Ciò significa che hai più tempo libero per concentrarti sulla protezione dell'applicazione in altri modi descritti nel Framework AWS Well-Architected. Lambda consente di eseguire il codice senza dover effettuare il provisioning o gestire server, perciò è sufficiente focalizzarsi su connettività, invocazione e sicurezza a livello di codice, anziché sull'infrastruttura o sul sistema operativo. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Identificazione dei servizi disponibili: esplora, testa e implementa servizi che gestiscono le risorse, come Amazon RDS, AWS Lambda e Amazon ECS. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Sito Web AWS](https://aws.amazon.com/)
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Sostituzione di un host bastione con Amazon EC2 Systems Manager](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Panoramica sulla sicurezza di AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Video correlati:** 
+  [Esecuzione di carichi di lavoro con livello di sicurezza elevato su Amazon EKS](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services](https://youtu.be/kmSdyN9qiXY) 
+  [Best practice di sicurezza per il servizio di metadati dell'istanza Amazon EC2](https://youtu.be/2B5bhZzayjI) 

 **Esempi correlati:** 
+ [Laboratorio: Richiesta di certificati pubblichi da parte di Gestione certificati AWS](https://wellarchitectedlabs.com/security/200_labs/200_certificate_manager_request_public_certificate/)

# SEC06-BP04 Automatizzazione della protezione delle risorse di calcolo
<a name="sec_protect_compute_auto_protection"></a>

 Automatizza i meccanismi di protezione delle risorse di calcolo, tra cui la gestione delle vulnerabilità, la riduzione della superficie di attacco e la gestione delle risorse. L'automazione ti consentirà di investire tempo nella protezione di altri aspetti del carico di lavoro e di ridurre il rischio di errori umani. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Automazione della gestione della configurazione: applica e convalida in automatico configurazioni sicure sfruttando un apposito servizio o strumento di gestione. 
  +  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
  +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
  +  [Laboratorio: Implementazione automatizzata di VPC](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_VPC/README.html) 
  +  [Laboratorio: Implementazione automatizzata di applicazioni Web EC2](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_EC2_Web_Application/README.html) 
+  Automazione dell'applicazione delle patch alle istanze Amazon Elastic Compute Cloud (Amazon EC2): AWS Systems Manager Patch Manager automatizza il processo di applicazione di patch alle istanze gestite con aggiornamenti correlati alla sicurezza e di altro tipo. Puoi utilizzare il gestore patch per applicare patch sia per i sistemi operativi sia per le applicazioni. 
  +  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
  +  [Applicazione di patch centralizzata multi-regione e muli-account con AWS Systems Manager Automation.](https://https://aws.amazon.com/blogs/mt/centralized-multi-account-and-multi-region-patching-with-aws-systems-manager-automation/) 
+  Implementazione della prevenzione e del rilevamento delle intrusioni: implementa uno strumento di rilevamento e prevenzione delle intrusioni per monitorare e bloccare le attività sospette sulle istanze. 
+  Considerazione delle soluzioni AWS Partner: i partner AWS offrono centinaia di prodotti leader nel settore che sono equivalenti, identici o si integrano ai controlli esistenti negli ambienti on-premise. Questi prodotti integrano i servizi AWS esistenti per permettere di implementare un'architettura di sicurezza completa e un'esperienza più fluida nel cloud e negli ambienti on-premise. 
  +  [Sicurezza dell'infrastruttura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
+  [Applicazione di patch centralizzata multi-regione e muli-account con AWS Systems Manager Automation.](https://aws.amazon.com/blogs/mt/centralized-multi-account-and-multi-region-patching-with-aws-systems-manager-automation/) 
+  [Sicurezza dell'infrastruttura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 
+  [Sostituzione di un host bastione con Amazon EC2 Systems Manager](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Panoramica sulla sicurezza di AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Video correlati:** 
+  [Esecuzione di carichi di lavoro con livello di sicurezza elevato su Amazon EKS](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services](https://youtu.be/kmSdyN9qiXY) 
+  [Best practice di sicurezza per il servizio di metadati dell'istanza Amazon EC2](https://youtu.be/2B5bhZzayjI) 

 **Esempi correlati:** 
+  [Laboratorio: Implementazione automatizzata di firewall per applicazioni Web](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 
+  [Laboratorio: Implementazione automatizzata di applicazioni Web EC2](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_EC2_Web_Application/README.html) 

# SEC06-BP05 Concessione del permesso di eseguire azioni a distanza
<a name="sec_protect_compute_actions_distance"></a>

 Eliminare la possibilità di accesso interattivo riduce il rischio di errore umano e la potenziale configurazione o gestione manuale. Ad esempio, utilizza un flusso di lavoro per la gestione delle modifiche per distribuire le istanze Amazon Elastic Compute Cloud (Amazon EC2) tramite infrastructure-as-code, quindi gestire le istanze Amazon EC2 utilizzando strumenti come AWS Systems Manager invece di consentire l'accesso diretto o tramite un host bastione. AWS Systems Manager può automatizzare un'ampia gamma di attività di manutenzione e distribuzione utilizzando funzionalità quali [automazione](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) [di automazione](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), [documenti](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) (playbook) e il [Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html). Gli stack di AWS CloudFormation si basano su pipeline e possono automatizzare le attività di distribuzione e gestione dell'infrastruttura senza utilizzare direttamente la Console di gestione AWS o le API. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Sostituisci l'accesso della console: sostituisci l'accesso via console (SSH o RDP) alle istanze con AWS Systems Manager Run Command per automatizzare le attività di gestione. 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
+  [Sostituzione di un host bastione con Amazon EC2 Systems Manager](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/) 
+  [Panoramica sulla sicurezza di AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 

 **Video correlati:** 
+  [Esecuzione di carichi di lavoro con livello di sicurezza elevato su Amazon EKS](https://youtu.be/OWRWDXszR-4) 
+  [Securing Serverless and Container Services](https://youtu.be/kmSdyN9qiXY) 
+  [Best practice di sicurezza per il servizio di metadati dell'istanza Amazon EC2](https://youtu.be/2B5bhZzayjI) 

 **Esempi correlati:** 
+  [Laboratorio: Distribuzione automatizzata di firewall per applicazioni Web](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_Web_Application_Firewall/README.html) 

# SEC06-BP06 Convalida dell'integrità del software
<a name="sec_protect_compute_validate_software_integrity"></a>

 Implementa meccanismi (ad esempio la firma del codice) per verificare che il software, il codice e le librerie utilizzati nel carico di lavoro provengano da origini attendibili e non siano stati manomessi. Ad esempio, devi verificare il certificato di firma del codice dei file binari e degli script per confermare l'autore e accertarti che non sia stato manomesso da quando è stato creato dall'autore. [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) può aiutare a garantire l'affidabilità e l'integrità del tuo codice tramite una sua gestione centralizzata, registrando il ciclo di vita, incluso la registrazione delle certificazioni e delle chiavi pubbliche e private. Puoi imparare come usare modelli avanzati e best practice per la registrazione del codice con [AWS Lambda](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/). Inoltre, un confronto tra il checksum del software scaricato e quello del provider può garantire che non sia stato manomesso. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Analizza i meccanismi: la firma del codice è uno dei meccanismi utili per convalidare l'integrità del software. 
  +  [NIST: considerazioni sulla sicurezza per la registrazione del codice](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01262018.pdf) 

## Risorse
<a name="resources"></a>

**Documenti correlati:** 
+ [AWS Signer](https://docs.aws.amazon.com/signer/index.html)
+ [Nuovo – Code Signing, a Trust and Integrity Control for AWS Lambda](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/) 

# Protezione dei dati
<a name="a-data-protection"></a>

**Topics**
+ [SEC 7. In che modo classifichi i dati?](sec-07.md)
+ [SEC 8. In che modo proteggi i dati inattivi?](sec-08.md)
+ [SEC 9. In che modo proteggi i dati in transito?](sec-09.md)

# SEC 7. In che modo classifichi i dati?
<a name="sec-07"></a>

La classificazione fornisce un modo per categorizzare i dati in base ai livelli di criticità e sensibilità, in modo da aiutarti a determinare i controlli di protezione e conservazione appropriati.

**Topics**
+ [SEC07-BP01 Identificazione dei dati all'interno del carico di lavoro](sec_data_classification_identify_data.md)
+ [SEC07-BP02 Definizione dei controlli di protezione dei dati](sec_data_classification_define_protection.md)
+ [SEC07-BP03 Automazione dell'identificazione e della classificazione](sec_data_classification_auto_classification.md)
+ [SEC07-BP04 Definizione della gestione del ciclo di vita dei dati](sec_data_classification_lifecycle_management.md)

# SEC07-BP01 Identificazione dei dati all'interno del carico di lavoro
<a name="sec_data_classification_identify_data"></a>

Comprendere il tipo e la classificazione dei dati che il carico di lavoro elabora, i processi aziendali associati, il luogo in cui i dati sono archiviati e chi è il proprietario dei dati è fondamentale. Occorre inoltre conoscere i requisiti legali e di conformità applicabili al proprio carico di lavoro e i controlli sui dati che devono essere applicati. L'identificazione dei dati è il primo passo nel percorso della classificazione dei dati. 

**Vantaggi dell'adozione di questa best practice:**

 La classificazione dei dati consente ai proprietari dei carichi di lavoro di identificare le posizioni in cui sono memorizzati i dati sensibili e di determinare le modalità di accesso e condivisione di tali dati. 

 La classificazione dei dati mira a rispondere alle seguenti domande: 
+ **Che tipo di dati abbiamo?**

  Si può trattare di dati quali: 
  +  Proprietà intellettuale (IP) come segreti commerciali, brevetti o accordi contrattuali. 
  +  Informazioni sanitarie protette (PHI), come le cartelle cliniche che contengono informazioni sulla storia medica di un individuo. 
  +  Informazioni di identificazione personale (PII), quali nome, indirizzo, data di nascita e numero di identificazione o registrazione nazionale. 
  +  Dati della carta di credito, come il numero di conto primario (PAN), il nome del titolare della carta, la data di scadenza e il numero del codice di servizio. 
  +  Dove sono archiviati i dati sensibili? 
  +  Chi può accedervi, modificarli e cancellarli? 
  +  Comprendere le autorizzazioni degli utenti è essenziale per prevenire una potenziale gestione errata dei dati. 
+ **Chi può eseguire operazioni di creazione, lettura, aggiornamento e cancellazione (CRUD)? **
  +  Considerare la potenziale escalation di privilegi comprendendo chi può gestire le autorizzazioni per i dati. 
+ **Quale impatto aziendale può verificarsi se i dati vengono divulgati involontariamente, alterati o cancellati? **
  +  Comprendere le conseguenze del rischio in caso di modifica, cancellazione o divulgazione involontaria dei dati. 

Conoscendo le risposte a queste domande, puoi intraprendere le seguenti azioni: 
+  Ridurre la portata dei dati sensibili (ad esempio il numero di posizioni dei dati sensibili) e limitare l'accesso ai dati sensibili solo agli utenti autorizzati. 
+  Acquisire consapevolezza dei diversi tipi di dati in modo da poter implementare meccanismi e tecniche di protezione dei dati appropriati, come la crittografia, la prevenzione della perdita di dati e la gestione dell'identità e degli accessi. 
+  Ottimizzare i costi fornendo i giusti obiettivi di controllo per i dati. 
+  Rispondere con sicurezza alle domande delle autorità di regolamentazione e dei revisori in merito ai tipi e alla quantità di dati e al modo in cui i dati di diversa sensibilità vengono isolati l'uno dall'altro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 La classificazione dei dati è l'atto di identificare la sensibilità dei dati. Può essere necessaria l'applicazione di tag per rendere i dati facilmente ricercabili e rintracciabili. La classificazione dei dati riduce anche la loro duplicazione, contribuendo a ridurre i costi di archiviazione e di backup e accelerando il processo di ricerca. 

 Utilizza servizi come Amazon Macie per automatizzare su larga scala sia la scoperta che la classificazione dei dati sensibili. Altri servizi, quali Amazon EventBridge e AWS Config, possono essere utilizzati per automatizzare la correzione dei problemi di sicurezza dei dati, ad esempio i bucket Amazon Simple Storage Service (Amazon S3) e i volumi EBS Amazon EC2 non crittografati o le risorse di dati prive di tag. Per un elenco completo di integrazioni del servizio AWS, consulta la [Documentazione di EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/event-types.html). 

 Il [rilevamento di PII](https://docs.aws.amazon.com/comprehend/latest/dg/how-pii.html) nei dati non strutturati, come le e-mail dei clienti, i ticket di assistenza, le recensioni dei prodotti e i social media è possibile [mediante Amazon Comprehend](https://aws.amazon.com/blogs/machine-learning/detecting-and-redacting-pii-using-amazon-comprehend/), che è un servizio di elaborazione del linguaggio naturale (NLP) che utilizza il machine learning per trovare approfondimenti e relazioni come persone, luoghi, sentimenti e argomenti in testi non strutturati. Per l'elenco di servizi AWS che possono aiutare nell'identificazione dei dati, consulta [Common techniques to detect PHI and PII data using AWS services](https://aws.amazon.com/blogs/industries/common-techniques-to-detect-phi-and-pii-data-using-aws-services/) (Tecniche comuni per rilevare i dati PHI e PII utilizzando i servizi AWS). 

 Un altro metodo che supporta la classificazione e la protezione dei dati è l'[applicazione di tag alle risorse AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html). L'applicazione di tag consente di assegnare metadati alle risorse AWS che possono essere utilizzati per gestire, identificare, organizzare, cercare e filtrare le risorse. 

 In alcuni casi, puoi scegliere di applicare tag a intere risorse (come un bucket S3), soprattutto quando è previsto che un carico di lavoro o un servizio specifico memorizzi processi o trasmissioni di dati di classificazione già nota. 

 Se necessario, è possibile applicare tag a un bucket S3 anziché i singoli oggetti per semplificare l'amministrazione e la manutenzione della sicurezza. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

**Rilevare i dati sensibili all'interno di Amazon S3: **

1.  Prima di iniziare, verifica di disporre delle autorizzazioni appropriate per accedere alla console Amazon Macie e alle operazioni API. Per dettagli aggiuntivi, consulta [Getting started with Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) (Nozioni di base su Amazon Macie). 

1.  Utilizza Amazon Macie per eseguire il rilevamento automatico dei dati quando i dati sensibili risiedono in [Amazon S3](https://aws.amazon.com/s3/). 
   +  Utilizza la guida [Getting Started with Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) per configurare un repository per i risultati del rilevamento dei dati sensibili e creare un lavoro di rilevamento per i dati sensibili. 
   +  [How to use Amazon Macie to preview sensitive data in S3 buckets](https://aws.amazon.com/blogs/security/how-to-use-amazon-macie-to-preview-sensitive-data-in-s3-buckets/) (Come utilizzare Amazon Macie per visualizzare in anteprima i dati sensibili nei bucket S3). 

      Per impostazione predefinita, Macie analizza gli oggetti utilizzando il set di identificatori di dati gestiti che raccomandiamo per il rilevamento automatico dei dati sensibili. Puoi personalizzare l'analisi configurando Macie in modo che utilizzi specifici identificatori di dati gestiti, identificatori di dati personalizzati ed elenchi di permessi quando esegue il rilevamento automatico di dati sensibili per l'account o l'organizzazione. Puoi regolare l'ambito dell'analisi escludendo bucket specifici (ad esempio, i bucket S3 che di solito memorizzano i dati di registrazione AWS). 

1.  Per configurare e utilizzare l'individuazione automatica dei dati sensibili, consulta [Performing automated sensitive data discovery with Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/discovery-asdd-account-manage.html) (Eseguire un rilevamento automatizzato dei dati sensibili con Amazon Macie). 

1.  Puoi anche considerare [Automated Data Discovery for Amazon Macie](https://aws.amazon.com/blogs/aws/automated-data-discovery-for-amazon-macie/) (Rilevamento automatizzato dei dati per Amazon Macie). 

**Rilevare i dati sensibili all'interno di Amazon RDS: **

 Per ulteriori informazioni sul rilevamento dei dati nei database [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/), consulta [Enabling data classification for Amazon RDS database with Macie](https://aws.amazon.com/blogs/security/enabling-data-classification-for-amazon-rds-database-with-amazon-macie/) (Abilitazione della classificazione dei dati per il database Amazon RDS con Macie). 

**Rilevare i dati sensibili all'interno di DynamoDB: **
+  [Detecting sensitive data in DynamoDB with Macie](https://aws.amazon.com/blogs/security/detecting-sensitive-data-in-dynamodb-with-macie/) (Rilevare i dati sensibili in DynamoDB con Macie) spiega come utilizzare Amazon Macie per rilevare i dati sensibili nelle tabelle [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) esportando i dati in Amazon S3 per la scansione. 

**Soluzioni dei partner AWS: **
+  Considera la possibilità di utilizzare la nostra ampia rete di partner AWS Partner Network. I partner AWS dispongono di ampi strumenti e framework di conformità che si integrano direttamente con i servizi AWS. I partner possono fornirti una soluzione di governance e conformità su misura per aiutarti a soddisfare le esigenze organizzative. 
+  Per soluzioni personalizzate nella classificazione dei dati, consulta [Data governance in the age of regulation and compliance requirements](https://aws.amazon.com/big-data/featured-partner-solutions-data-governance-compliance/) (La governance dei dati nell'era delle normative e dei requisiti di conformità). 

 Gli standard di applicazione di tag adottati dall'organizzazione possono essere applicati automaticamente mediante la creazione e l'implementazione di policy con l'aiuto di AWS Organizations. Le policy sui tag consentono di specificare le regole che definiscono i nomi validi delle chiavi e i valori validi per ciascuna chiave. Puoi scegliere di effettuare solo il monitoraggio, il che ti offre l'opportunità di valutare e ripulire i tag esistenti. Una volta che i tag sono conformi agli standard scelti, puoi attivare l'applicazione nelle policy sui tag per impedire la creazione di tag non conformi. Per maggiori dettagli, consulta [Securing resource tags used for authorization using a service control policy in AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) (Proteggere i tag delle risorse utilizzati per l'autorizzazione mediante una policy di controllo dei servizi in AWS Organizations) e la policy di esempio su [come prevenire la modifica dei tag da parte di principali non autorizzati](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin). 
+  Per iniziare utilizzando le policy sui tag in [AWS Organizations](https://aws.amazon.com/organizations/), è fortemente consigliabile seguire il flusso di lavoro descritto in [Nozioni di base sulle policy di tag](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-getting-started.html) prima di passare a policy sui tag più avanzate. La comprensione degli effetti dell'applicazione di una semplice policy sui tag a un singolo account prima di estenderla a un'intera unità organizzativa (OU) o organizzazione consente di vedere gli effetti di una policy sui tag prima di applicare la conformità alla policy stessa. [Nozioni di base sulle policy di tag](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-getting-started.html) fornisce link a istruzioni per attività più avanzate relative alle policy. 
+  Considera di valutare altri [servizi e funzionalità di AWS](https://docs.aws.amazon.com/whitepapers/latest/data-classification/using-aws-cloud-to-support-data-classification.html#aws-services-and-features) che supportino la classificazione dei dati, che sono elencati nel whitepaper [Data Classification](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) (Classificazione dei dati). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Getting Started with Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html)(Nozioni di base) 
+  [Automated data discovery with Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/discovery-asdd.html) (Ricerca automatica di dati con Amazon Macie) 
+  [Getting started with tag policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-getting-started.html) (Nozioni di base sulle policy di tag) 
+  [Detecting PII entities](https://docs.aws.amazon.com/comprehend/latest/dg/how-pii.html) (Rilevamento di entità PII) 

 **Blog correlati:** 
+  [How to use Amazon Macie to preview sensitive data in S3 buckets](https://aws.amazon.com/blogs/security/how-to-use-amazon-macie-to-preview-sensitive-data-in-s3-buckets/) (Come utilizzare Amazon Macie per visualizzare in anteprima i dati sensibili nei bucket S3). 
+  [Performing automated sensitive data discovery with Amazon Macie.](https://aws.amazon.com/blogs/aws/automated-data-discovery-for-amazon-macie/) (Esecuzione del rilevamento automatizzato di dati sensibili con Amazon Macie). 
+  [Common techniques to detect PHI and PII data using AWS Services](https://aws.amazon.com/blogs/industries/common-techniques-to-detect-phi-and-pii-data-using-aws-services/) (Rilevamento e correzione di PII con Amazon AWS) 
+  [Detecting and redacting PII using Amazon Comprehend](https://aws.amazon.com/blogs/machine-learning/detecting-and-redacting-pii-using-amazon-comprehend/) (Rilevamento e correzione delle PII con Amazon Comprehend) 
+  [Securing resource tags used for authorization using a service control policy in AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) (Protezione dei tag delle risorse utilizzati per l'autorizzazione tramite una policy di controllo dei servizi in AWS Organizations) 
+  [Enabling data classification for Amazon RDS database with Macie](https://aws.amazon.com/blogs/security/enabling-data-classification-for-amazon-rds-database-with-amazon-macie/) (Consentire la classificazione dei dati per il database Amazon RDS con Macie) 
+  [Detecting sensitive data in DynamoDB with Macie](https://aws.amazon.com/blogs/security/detecting-sensitive-data-in-dynamodb-with-macie/) (Rilevamento di dati sensibili in DynamoDB con Macie) 

 **Video correlati:** 
+  [Event-driven data security using Amazon Macie](https://www.youtube.com/watch?v=onqA7MJssoU) (Sicurezza dei dati guidata dagli eventi con Amazon Macie) 
+  [Amazon Macie for data protection and governance](https://www.youtube.com/watch?v=SmMSt0n6a4k) (Amazon Macie per la protezione e la governance dei dati) 
+  [Fine-tune sensitive data findings with allow lists](https://www.youtube.com/watch?v=JmQ_Hybh2KI) (Perfezionare i risultati dei dati sensibili con gli elenchi di permessi) 

# SEC07-BP02 Definizione dei controlli di protezione dei dati
<a name="sec_data_classification_define_protection"></a>

 Proteggi i dati in base al livello di classificazione. Ad esempio, puoi mettere in sicurezza le informazioni classificate come pubbliche utilizzando raccomandazioni pertinenti e allo stesso tempo proteggere i dati sensibili con controlli aggiuntivi. 

Utilizzando tag di risorse, account AWS separati per livelli di sensibilità (e potenzialmente anche per avvertimento/enclave/community di interesse), policy IAM, SCP di AWS Organizations, AWS Key Management Service (AWS KMS) e AWS CloudHSM, puoi definire e implementare le policy per la classificazione e la protezione dei dati tramite la crittografia. Ad esempio, se in un progetto sono presenti bucket S3 che contengono dati estremamente critici o istanze Amazon Elastic Compute Cloud (Amazon EC2) che elaborano dati riservati, essi possono essere contrassegnati con un tag `Project=ABC` . Solo il team ristretto conosce il significato del codice del progetto e rappresenta un modo per utilizzare il controllo degli accessi basato su attributi. Puoi definire i livelli di accesso alle chiavi di crittografia AWS KMS tramite policy e concessioni delle chiavi per garantire che solo i servizi appropriati abbiano accesso ai contenuti sensibili tramite un meccanismo sicuro. Se prendi decisioni in merito alle autorizzazioni in base ai tag, devi assicurarti che le autorizzazioni sui tag siano definite in modo appropriato utilizzando le policy dei tag in AWS Organizations.

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Definizione dello schema di identificazione e classificazione dei dati: l'identificazione e la classificazione dei dati è utile a valutare l'impatto potenziale e il tipo di dati archiviati e a stabilire chi può accedervi. 
  +  [Documentazione di AWS](https://docs.aws.amazon.com/) 
+  Identificazione dei controlli AWS disponibili: scopri i controlli di sicurezza per i servizi AWS che stai utilizzando o che intendi utilizzare. Molti servizi dispongono di una sezione sulla sicurezza nella documentazione. 
  +  [Documentazione di AWS](https://docs.aws.amazon.com/) 
+  Identificazione delle risorse di conformità AWS: identifica le risorse che AWS mette a disposizione per facilitare i processi di conformità. 
  +  [https://aws.amazon.com/compliance/](https://aws.amazon.com/compliance/?ref=wellarchitected) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Documentazione di AWS](https://docs.aws.amazon.com/) 
+  [Whitepaper sulla classificazione dei dati](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) 
+  [Nozioni di base su Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) 
+  [Testo mancante](https://aws.amazon.com/compliance/) 

 **Video correlati:** 
+  [Introducing the New Amazon Macie (Presentazione del nuovo Amazon Macie)](https://youtu.be/I-ewoQekdXE) 

# SEC07-BP03 Automazione dell'identificazione e della classificazione
<a name="sec_data_classification_auto_classification"></a>

 automatizzare l'identificazione e la classificazione dei dati può aiutarti a implementare i controlli corretti. L'utilizzo dell'automazione per queste operazioni invece dell'accesso diretto da parte di una persona riduce il rischio di errori umani e di esposizione delle persone. È consigliabile valutare l'utilizzo di uno strumento, ad esempio [Amazon Macie](https://aws.amazon.com/macie/), che utilizza il machine learning per rilevare, classificare e proteggere automaticamente i dati sensibili in AWS. Amazon Macie riconosce i dati sensibili, quali informazioni personali di identificazione (PII) o di proprietà intellettuale e fornisce pannelli di controllo e allarmi che offrono visibilità su come viene effettuato l'accesso a tali dati o come vengono spostati. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Utilizzo di Amazon Simple Storage Service (Amazon S3) Inventory: Amazon S3 Inventory è uno degli strumenti che utilizzabili per eseguire audit e segnalare lo stato di replica e crittografia degli oggetti. 
  +  [Amazon S3 Inventory](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html) 
+  Considerazione di Amazon Macie: Amazon Macie sfrutta il machine learning per scoprire e classificare automaticamente i dati archiviati in Amazon S3.
  +  [Amazon Macie](https://aws.amazon.com/macie/) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Amazon Macie](https://aws.amazon.com/macie/) 
+  [Amazon S3 Inventory](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html) 
+  [Whitepaper sulla classificazione dei dati](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) 
+  [Nozioni di base su Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) 

 **Video correlati:** 
+  [Introducing the New Amazon Macie (Presentazione del nuovo Amazon Macie)](https://youtu.be/I-ewoQekdXE) 

# SEC07-BP04 Definizione della gestione del ciclo di vita dei dati
<a name="sec_data_classification_lifecycle_management"></a>

 la strategia del ciclo di vita definita deve basarsi sul livello di sensibilità e sui requisiti legali e aziendali. Gli aspetti da considerare includono la durata di conservazione dei dati, i processi di distruzione dei dati, la gestione degli accessi ai dati, la trasformazione dei dati e la condivisione dei dati. Nella scelta di una metodologia di classificazione dei dati, è necessario valutare l'usabilità rispetto all'accesso. Devi inoltre gestire vari livelli di accesso e particolarità per implementare un approccio sicuro e utilizzabile per ogni livello. Utilizza sempre un approccio di difesa avanzata e riduci l'accesso umano ai dati e ai meccanismi per trasformare, eliminare o copiare i dati. Ad esempio, richiedi agli utenti di effettuare l'autenticazione in un'applicazione e fornisci all'applicazione, anziché agli utenti, l'autorizzazione di accesso necessaria per eseguire "operazioni a distanza". Inoltre, assicurati che gli utenti provengano da un percorso di rete sicuro e richiedi l'accesso alle chiavi di decrittografia. Utilizza strumenti, pannelli di controllo e generazione di report automatizzata, per fornire agli utenti informazioni ricavate dai dati piuttosto che concedere loro l'accesso diretto ai dati. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Identifica i tipi di dati: identifica i tipi di dati che stai archiviando o elaborando nel carico di lavoro. Questi potrebbero consistere in testo, immagini, database binari e così via. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Whitepaper sulla classificazione dei dati](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) 
+  [Nozioni di base su Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html) 

 **Video correlati:** 
+  [Introducing the New Amazon Macie](https://youtu.be/I-ewoQekdXE) 

# SEC 8. In che modo proteggi i dati inattivi?
<a name="sec-08"></a>

Proteggi i dati inattivi implementando più controlli, per ridurre il rischio di accessi non autorizzati o altri comportamenti impropri.

**Topics**
+ [SEC08-BP01 Implementazione della gestione sicura delle chiavi](sec_protect_data_rest_key_mgmt.md)
+ [SEC08-BP02 Applicazione della crittografia dei dati inattivi](sec_protect_data_rest_encrypt.md)
+ [SEC08-BP03 Automatizzazione della protezione dei dati a riposo](sec_protect_data_rest_automate_protection.md)
+ [SEC08-BP04 Applicazione del controllo degli accessi](sec_protect_data_rest_access_control.md)
+ [SEC08-BP05 Utilizzo di meccanismi per tenere le persone a distanza dai dati](sec_protect_data_rest_use_people_away.md)

# SEC08-BP01 Implementazione della gestione sicura delle chiavi
<a name="sec_protect_data_rest_key_mgmt"></a>

 La gestione sicura delle chiavi include l'archiviazione, la rotazione, il controllo degli accessi e il monitoraggio del materiale relativo alla chiave necessario per proteggere i dati a riposo per il carico di lavoro. 

 **Risultato desiderato:** Un meccanismo di gestione delle chiavi dimensionabile, ripetibile e automatizzato. Il meccanismo dovrebbe fornire la possibilità di applicare l'accesso con il privilegio minimo al materiale relativo alla chiave e offrire il giusto equilibrio tra disponibilità, riservatezza e integrità delle chiavi. L'accesso alle chiavi deve essere monitorato e il materiale relativo alla chiave deve essere ruotato utilizzando un processo automatizzato. Il materiale relativo alla chiave non dovrebbe mai essere accessibile alle identità umane. 

**Anti-pattern comuni:** 
+  Accesso umano a materiale relativo alla chiave non crittografato. 
+  Creazione di algoritmi crittografici personalizzati. 
+  Autorizzazioni di accesso al materiale relativo alla chiave troppo ampie. 

 **Vantaggi dell'adozione di questa best practice:** Attraverso un meccanismo di gestione delle chiavi sicuro per il tuo carico di lavoro, puoi contribuire a proteggere i contenuti dagli accessi non autorizzati. Inoltre, la crittografia dei dati potrebbe essere prevista da requisiti normativi per la tua organizzazione. Un'efficace soluzione di gestione delle chiavi può fornire meccanismi tecnici finalizzati alla protezione del materiale relativo alle chiavi in linea con tali normative. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Molti requisiti normativi e best practice includono la crittografia dei dati a riposo come controllo di sicurezza fondamentale. Per garantire la conformità, il carico di lavoro necessita di un meccanismo per archiviare e gestire in modo sicuro il materiale relativo alla chiave utilizzato per crittografare i dati a riposo. 

 AWS offre AWS Key Management Service (AWS KMS) per fornire uno spazio di archiviazione durevole, sicuro e ridondante per le chiavi AWS KMS. [Molti servizi AWS si integrano con AWS KMS](https://aws.amazon.com/kms/features/#integration) per supportare la crittografia dei dati. AWS KMS utilizza moduli di sicurezza hardware conformi allo standard FIPS 140-2 di livello 3 per proteggere le chiavi. Non esiste un meccanismo per esportare le chiavi AWS KMS convertendole in testo semplice. 

 Quando si distribuiscono carichi di lavoro utilizzando una strategia multi-account, una [best practice](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/application.html#app-kms) è quella di mantenere le chiavi AWS KMS nello stesso account del carico di lavoro che le utilizza. In questo modello distribuito, la responsabilità della gestione delle chiavi AWS KMS spetta al team applicativo. In altri casi d'uso, le organizzazioni possono scegliere di archiviare le chiavi AWS KMS in un account centralizzato. Questa struttura centralizzata richiede policy aggiuntive per consentire l'accesso multi-account richiesto affinché l'account del carico di lavoro possa accedere alle chiavi archiviate nell'account centralizzato, ma può essere più applicabile nei casi d'uso in cui una singola chiave è condivisa tra Account AWS multipli. 

 Indipendentemente dalla posizione in cui è archiviato il materiale relativo alla chiave, l'accesso alla chiave deve essere strettamente controllato mediante l'uso di [policy delle chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) e policy IAM. Le policy delle chiavi costituiscono la modalità principale per controllare l'accesso a una chiave AWS KMS. Inoltre, AWS KMS garantisce che le chiavi possano fornire l'accesso ai servizi AWS per crittografare e decrittografare i dati per conto dell'utente. Prenditi del tempo per rivedere le [best practice per il controllo degli accessi alle chiavi AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies-best-practices.html). 

 Una best practice è quella di monitorare l'uso delle chiavi di crittografia per rilevare modelli di accesso insoliti. Le operazioni eseguite utilizzando chiavi gestite da AWS e chiavi gestite dal cliente archiviate in AWS KMS, possono essere registrate in AWS CloudTrail e devono essere riviste periodicamente. Occorre prestare particolare attenzione al monitoraggio dei principali eventi di eliminazione delle chiavi. Per ridurre le probabilità di distruzione accidentale o dolosa del materiale relativo alla chiave, gli eventi di eliminazione delle chiavi non hanno efficacia immediata. I tentativi di eliminare le chiavi in AWS KMS sono soggetti a [un periodo di attesa](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html#deleting-keys-how-it-works), che per impostazione predefinita è di 30 giorni, dando agli amministratori il tempo di rivedere queste azioni e annullare la richiesta, se necessario. 

 La maggior parte dei servizi AWS utilizza AWS KMS secondo una modalità chiara per te: il tuo unico requisito è decidere se utilizzare una chiave gestita da AWS o dal cliente. Se il carico di lavoro richiede l'uso diretto di AWS KMS per crittografare o decrittografare i dati, la best practice è utilizzare la [crittografia a busta](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) per proteggere i dati. Il comando [SDK di crittografia AWS](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) è in grado di fornire alle applicazioni primitive crittografiche lato client per implementare la crittografia a busta e integrarle con AWS KMS. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Determina le [opzioni di gestione della chiave appropriate](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt) (gestita da AWS o gestita dal cliente). 
   +  Per facilitare l'uso, AWS offre chiavi AWS di proprietà e gestite da AWS per la maggior parte dei servizi, fornendo funzionalità di crittografia a riposo senza la necessità di gestire il materiale o le policy delle chiavi. 
   +  Quando utilizzi chiavi gestite dal cliente, prendi in considerazione il keystore predefinito per fornire il miglior equilibrio tra agilità, sicurezza, sovranità dei dati e disponibilità. Per altri casi d'uso può essere richiesto l'uso di archivi di chiavi personalizzati con [AWS CloudHSM](https://aws.amazon.com/cloudhsm/) o [di un archivio chiavi esterno](https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html). 

1.  Consulta l'elenco dei servizi che stai utilizzando per il tuo carico di lavoro per capire come AWS KMS si integra con il servizio. Ad esempio, le istanze EC2 possono utilizzare volumi EBS crittografati; verifica che anche le snapshot Amazon EBS create da tali volumi siano crittografate utilizzando una chiave gestita dal cliente e mitigando la divulgazione accidentale di dati di snapshot non crittografati. 
   +  [Come i servizi AWS utilizzano AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/service-integration.html) 
   +  Per informazioni dettagliate sulle opzioni di crittografia offerte da un servizio AWS, consulta l'argomento Crittografia a riposo nella guida per l'utente o nella guida per sviluppatori del servizio. 

1.  Implementa AWS KMS: AWS KMS semplifica la creazione e la gestione delle chiavi e controlla l'uso della crittografia in un'ampia gamma di servizi AWS e nelle tue applicazioni. 
   +  [Nozioni di base: AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html) 
   +  Consulta le [best practice per il controllo degli accessi alle chiavi AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies-best-practices.html). 

1.  Considera AWS Encryption SDK: utilizza l'AWS Encryption SDK con l'integrazione di AWS KMS quando la tua applicazione deve crittografare i dati lato client. 
   +  [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) 

1.  Abilita [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) per rivedere e inviare notifiche automaticamente se esistono policy delle chiavi AWS KMS eccessivamente permissive. 

1.  Abilita [Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html) per ricevere notifiche in caso di policy delle chiavi configurate in modo errato, chiavi programmate per essere eliminate o chiavi senza la rotazione automatica abilitata. 

1.  Determina il livello di log appropriato per le tue chiavi AWS KMS. Poiché le chiamate a AWS KMS, inclusi gli eventi di sola lettura, vengono registrate, i log CloudTrail associati a AWS KMS possono diventare voluminosi. 
   +  Alcune organizzazioni preferiscono separare l'attività di log di AWS KMS in un percorso separato. Per ulteriori informazioni, consulta la sezione [Log delle chiamate API AWS KMS con CloudTrail](https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html) della guida per gli sviluppatori AWS KMS. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) 
+  [Servizi e strumenti di crittografia di AWS](https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-overview.html) 
+  [Protezione dei dati Amazon S3 tramite la crittografia](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) 
+  [Envelope encryption](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) 
+  [Digital sovereignty pledge](https://aws.amazon.com/blogs/security/aws-digital-sovereignty-pledge-control-without-compromise/) 
+  [Demystifying AWS KMS key operations, bring your own key, custom key store, and ciphertext portability](https://aws.amazon.com/blogs/security/demystifying-kms-keys-operations-bring-your-own-key-byok-custom-key-store-and-ciphertext-portability/) 
+  [Dettagli di crittografia di AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 

 **Video correlati:** 
+  [Come funziona la crittografia in AWS](https://youtu.be/plv7PQZICCM) 
+  [Securing Your Block Storage on AWS (Protezione dello storage a blocchi in AWS).](https://youtu.be/Y1hE1Nkcxs8) 
+  [AWS data protection: Using locks, keys, signatures, and certificates](https://www.youtube.com/watch?v=lD34wbc7KNA) 

 **Esempi correlati:** 
+  [Implement advanced access control mechanisms using AWS KMS](https://catalog.workshops.aws/advkmsaccess/en-US/introduction) 

# SEC08-BP02 Applicazione della crittografia dei dati inattivi
<a name="sec_protect_data_rest_encrypt"></a>

 Per i dati a riposo è necessario applicare la crittografia. La crittografia mantiene la riservatezza dei dati sensibili in caso di accesso non autorizzato o di divulgazione accidentale. 

 **Risultato desiderato:** la crittografia dei dati privati a riposo deve essere predefinita. La crittografia aiuta a mantenere la riservatezza dei dati e fornisce un ulteriore livello di protezione contro la divulgazione o esfiltrazione intenzionale o involontaria dei dati. I dati crittografati non possono essere letti o consultati senza che siano stati prima decrittografati. Tutti i dati archiviati in modo non crittografato devono essere inventariati e controllati. 

 **Anti-pattern comuni:** 
+  Mancato utilizzo di configurazioni con crittografia predefinita. 
+  Accesso estremamente permissivo alle chiavi di decrittografia. 
+  Mancato monitoraggio dell'uso delle chiavi di crittografia e decrittografia. 
+  Memorizzazione di dati non crittografati. 
+  Utilizzo della stessa chiave di crittografia per tutti i dati, indipendentemente dall'uso, dal tipo e dalla classificazione dei dati stessi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Mappa le chiavi di crittografia alle classificazioni dei dati all'interno dei carichi di lavoro. Questo approccio aiuta a proteggere dall'accesso estremamente permissivo quando si utilizza un'unica chiave di crittografia o un numero molto ridotto di chiavi di crittografia per i dati (consulta [SEC07-BP01 Identificazione dei dati all'interno del carico di lavoro](sec_data_classification_identify_data.md)). 

 AWS Key Management Service (AWS KMS) si integra con molti servizi AWS per semplificare la crittografia dei dati a riposo. Ad esempio, in Amazon Simple Storage Service (Amazon S3), puoi impostare la [crittografia predefinita](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html) su un bucket in modo che i nuovi oggetti vengano automaticamente crittografati. Quando utilizzi AWS KMS, devi considerare il livello di restrizione dei dati. Le chiavi AWS KMS predefinite e controllate dal servizio sono gestite e utilizzate da AWS per tuo conto. Per i dati sensibili che richiedono un accesso granulare alla chiave di crittografia sottostante, è opportuno considerare le chiavi gestite dal cliente (CMK). L'utente ha il pieno controllo sulle CMK, anche per quanto riguarda la rotazione e la gestione degli accessi attraverso l'uso di policy sulle chiavi. 

 Inoltre, [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) e [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) applicano la crittografia impostandone un tipo predefinito. Puoi servirti della [Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) per verificare automaticamente l'utilizzo della crittografia, ad esempio, per [volumi Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html), [istanze Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html) e [bucket Amazon S3](https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html). 

 AWS offre anche soluzioni per la crittografia lato client, consentendo di crittografare i dati prima di caricarli nel cloud. AWS Encryption SDK offre un metodo per crittografare i dati utilizzando la [crittografia a busta](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping). L'utente fornisce la chiave di wrapping e AWS Encryption SDK genera una chiave dati unica per ogni oggetto di dati che crittografa. Considera AWS CloudHSM se hai bisogno di un modulo di sicurezza hardware (HSM) gestito single-tenant. AWS CloudHSM consente di generare, importare e gestire le chiavi crittografiche su un HSM convalidato FIPS 140-2 di livello 3. Alcuni casi d'uso di AWS CloudHSM includono la protezione delle chiavi private per il rilascio di un'autorità di certificazione (CA) e l'abilitazione della crittografia trasparente dei dati (TDE) per i database Oracle. Il client SDK AWS CloudHSM fornisce un software che consente di crittografare i dati sul lato client utilizzando le chiavi memorizzate all'interno di AWS CloudHSM prima di caricare i dati in AWS. La Amazon DynamoDB Encryption Client consente inoltre di crittografare e firmare gli elementi prima del caricamento in una tabella DynamoDB. 

 **Passaggi dell'implementazione** 
+  **Applicazione della crittografia a riposo per Amazon S3:** implementa [la crittografia predefinita del bucket Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html). 

   **Configura [la crittografia predefinita per i nuovi volumi Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html):** specifica se desideri che tutti i nuovi volumi Amazon EBS vengano creati in forma crittografata, con la possibilità di utilizzare la chiave predefinita fornita da AWS o una chiave creata dall'utente. 

   **Configura Amazon Machine Image (AMI) crittografate:** copiando un'AMI esistente con crittografia abilitata verrà eseguita la crittografia automatica di volumi root e delle snapshot. 

   **Configura la [crittografia Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html):** configura la crittografia per i cluster di database Amazon RDS e le snapshot a riposo utilizzando l'opzione di crittografia. 

   **Crea e configura le chiavi AWS KMS con policy che limitino l'accesso ai principali appropriati per ogni classificazione di dati:** ad esempio, crea una chiave AWS KMS per la crittografia dei dati di produzione e una chiave diversa per la crittografia dei dati di sviluppo o di test. Puoi anche fornire l'accesso alle chiavi ad altri Account AWS. Considera la possibilità di avere account diversi per gli ambienti di sviluppo e di produzione. Qualora il tuo ambiente di produzione richieda la decodifica degli artefatti nell'account di sviluppo, puoi modificare la policy CMK utilizzata per crittografare gli artefatti di sviluppo per dare all'account di produzione la possibilità di decrittografare tali artefatti. L'ambiente di produzione può quindi importare i dati decrittografati per utilizzarli nella produzione. 

   **Configura la crittografia in altri servizi AWS:** per gli altri servizi AWS utilizzati, consulta la [documentazione sulla sicurezza](https://docs.aws.amazon.com/security/) del servizio per individuare le opzioni di crittografia del servizio. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Crypto Tools](https://docs.aws.amazon.com/aws-crypto-tools) 
+  [Documentazione di AWS](https://docs.aws.amazon.com/) 
+  [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) 
+  [AWS KMS Cryptographic Details Whitepaper](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) (Whitepaper sui dettagli crittografici di AWS KMS) 
+  [AWS Key Management Service](https://aws.amazon.com/kms) 
+  [AWS cryptographic services and tools](https://docs.aws.amazon.com/crypto/latest/userguide/awscryp-overview.html) (servizi e strumenti di crittografia AWS) 
+  [Crittografia Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) 
+  [Default encryption for Amazon EBS volumes](https://aws.amazon.com/blogs/aws/new-opt-in-to-default-encryption-for-new-ebs-volumes/) (Crittografia predefinita per i volumi Amazon EBS) 
+  [Crittografia delle risorse Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) 
+  [How do I enable default encryption for an Amazon S3 bucket?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/default-bucket-encryption.html) (Come si attiva la crittografia predefinita per un bucket Amazon S3?) 
+  [Protecting Amazon S3 Data Using Encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) (Protezione dei dati Amazon S3 mediante crittografia) 

 **Video correlati:** 
+  [How Encryption Works in AWS](https://youtu.be/plv7PQZICCM) (Come funziona la crittografia in AWS) 
+  [Securing Your Block Storage on AWS](https://youtu.be/Y1hE1Nkcxs8) (Protezione dello storage a blocchi in AWS) 

# SEC08-BP03 Automatizzazione della protezione dei dati a riposo
<a name="sec_protect_data_rest_automate_protection"></a>

 utilizza strumenti automatizzati per convalidare e applicare la protezione dei dati a riposo in modo continuo; ad esempio verifica che siano presenti solo risorse di storage crittografate. Puoi [automatizzare la convalida della crittografia di tutti i volumi EBS](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html) utilizzando [Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html). [AWS Security Hub CSPM](http://aws.amazon.com/security-hub/) può anche verificare una serie di controlli diversi tramite verifiche automatiche a fronte di standard di sicurezza. Inoltre, le Regole di AWS Config possono correggere automaticamente [le risorse non conformi](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html#setup-autoremediation). 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation_guidance"></a>

 *I dati a riposo* rappresentano tutti i dati conservati nello storage non volatile per qualsiasi durata del carico di lavoro. Sono inclusi storage a blocchi, storage di oggetti, database, archivi, dispositivi IoT e qualsiasi altro supporto di storage su cui sono conservati i dati. La protezione dei dati a riposo riduce il rischio di accesso non autorizzato quando vengono implementati crittografia e controlli degli accessi adeguati. 

 Applica la crittografia dei dati a riposo: devi accertarti che l'unico modo per archiviare i dati sia l'utilizzo della crittografia. AWS KMS si integra perfettamente con molti servizi AWS per semplificare la crittografia di tutti i dati inattivi. Ad esempio, in Amazon Simple Storage Service (Amazon S3) puoi impostare [la crittografia predefinita](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html) su un bucket in modo che tutti i nuovi oggetti vengano crittografati automaticamente. Inoltre, [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) e [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) supportano l'applicazione della crittografia impostando la crittografia predefinita. Puoi utilizzare [AWS Managed Config Rules](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) per verificare automaticamente che stai utilizzando la crittografia, ad esempio, per i [volumi EBS](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html), [le istanze Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html)e [bucket Amazon S3](https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Crypto Tools](https://docs.aws.amazon.com/aws-crypto-tools) 
+  [SDK di crittografia AWS](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) 

 **Video correlati:** 
+  [How Encryption Works in AWS (Come funziona la crittografia in AWS)](https://youtu.be/plv7PQZICCM) 
+  [Securing Your Block Storage on AWS](https://youtu.be/Y1hE1Nkcxs8) 

# SEC08-BP04 Applicazione del controllo degli accessi
<a name="sec_protect_data_rest_access_control"></a>

 Per proteggere i dati a riposo, applica il controllo degli accessi utilizzando meccanismi come l'isolamento e il controllo delle versioni, quindi applica il principio del privilegio minimo. Impedisci l'accesso pubblico ai dati. 

**Risultato desiderato:** verifica che solo gli utenti autorizzati possano accedere ai dati in base al principio "Need-to-Know" (necessità di sapere). La protezione dei dati è assicurata da backup regolari e dal controllo delle versioni, per evitare che i dati vengano modificati o eliminati intenzionalmente o inavvertitamente. L'isolamento dei dati critici dagli altri dati ne protegge la riservatezza e l'integrità. 

**Anti-pattern comuni:**
+  Archiviazione dei dati con requisiti di sensibilità o classificazione diversi. 
+  Utilizzo di autorizzazioni troppo permissive sulle chiavi di decrittografia. 
+  Classificazione impropria dei dati. 
+  Nessun mantenimento di backup dettagliati dei dati importanti. 
+  Accesso persistente ai dati di produzione. 
+  Nessun audit dell'accesso ai dati o revisione periodica delle autorizzazioni. 

**Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 La protezione dei dati a riposo può essere garantita da diversi controlli, tra cui l'accesso (utilizzando il privilegio minimo), l'isolamento e il controllo delle versioni. L'accesso ai dati deve essere soggetto a audit mediante meccanismi di rilevazione, come AWS CloudTrail e log sul livello di servizio, come i log di accesso di Amazon Simple Storage Service (Amazon S3). Per ridurre nel tempo la quantità di dati disponibili pubblicamente, è necessario fare un inventario dei dati accessibili pubblicamente e creare un piano. 

 Amazon Glacier Vault Lock e Amazon S3 Object Lock forniscono un controllo di accesso obbligatorio per gli oggetti in Amazon S3: una volta bloccata con l'opzione di conformità, una policy Vault non può essere modificata nemmeno dall'utente root fino alla scadenza del blocco. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Applica il controllo degli accessi:** applica il controllo degli accessi con privilegio minimo, incluso l'accesso alle chiavi di crittografia. 
+  **Separa i dati in base a diversi livelli di classificazione:** utilizza diversi Account AWS per i livelli di classificazione dei dati e gestisci tali account utilizzando [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). 
+  **Rivedi le policy di AWS Key Management Service (AWS KMS)**: [rivedi il livello di accesso](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) concesso nelle policy di AWS KMS. 
+  **Rivedi le autorizzazioni dei bucket e degli oggetti di Amazon S3**: rivedi regolarmente il livello di accesso concesso nelle policy dei bucket S3. La best practice è evitare di utilizzare bucket leggibili o scrivibili pubblicamente. Valuta l'utilizzo di [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) per rilevare i bucket disponibili pubblicamente e di Amazon CloudFront per fornire contenuti provenienti da Amazon S3. Verifica che i bucket che non consentono l'accesso pubblico siano configurati correttamente per impedirlo. Per impostazione predefinita, tutti i bucket S3 sono privati e possono accedervi soltanto gli utenti a cui è stato esplicitamente accordato l'accesso. 
+  **Abilita [AWS IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/what-is-access-analyzer.html):** IAM Access Analyzer analizza i bucket Amazon S3 e genera un risultato quando [una policy S3 concede l'accesso a un'entità esterna.](https://docs.aws.amazon.com//latest/UserGuide/access-analyzer-resources.html#access-analyzer-s3) 
+  **Abilita il [controllo delle versioni Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html) e del [blocco degli oggetti](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html)** laddove appropriato. 
+  **Utilizza[Amazon S3 Inventory](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html)**: Amazon S3 Inventory può essere utilizzato per effettuare audit e report sullo stato di replica e crittografia degli oggetti S3. 
+  **Rivedi le autorizzazioni di [condivisione Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html) e [AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharing-amis.html)**: le autorizzazioni di condivisione possono consentire la condivisione di immagini e volumi con Account AWS esterni al carico di lavoro. 
+  **Rivedi periodicamente le condivisioni di [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) per stabilire se le risorse devono continuare ad essere condivise.** Resource Access Manager consente di condividere risorse, come le policy del firewall di rete AWS, le regole del resolver Amazon Route 53 e le sottoreti, all'interno dei Amazon VPC. Sottoponi regolarmente a audit le risorse condivise e interrompi la condivisione delle risorse che non devono più essere condivise. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [SEC03-BP01 Definizione dei requisiti di accesso](sec_permissions_define.md) 
+  [SEC03-BP02 Concessione dell'accesso con privilegio minimo](sec_permissions_least_privileges.md) 

 **Documenti correlati:** 
+  [AWS KMS Cryptographic Details Whitepaper](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) (Whitepaper sui dettagli crittografici di AWS KMS) 
+  [Introduction to Managing Access Permissions to Your Amazon S3 Resources](https://docs.aws.amazon.com/AmazonS3/latest/dev/intro-managing-access-s3-resources.html) (Introduzione alla gestione delle autorizzazioni di accesso alle risorse di Amazon S3) 
+  [Overview of managing access to your AWS KMS resources](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html) (Panoramica della gestione dell'accesso alle risorse AWS KMS) 
+  [Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) (Regole AWS Config) 
+  [Amazon S3 \$1 Amazon CloudFront: A Match Made in the Cloud](https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/) (Amazon S3 \$1 Amazon CloudFront: un abbinamento perfetto nel cloud) 
+  [Utilizzo del controllo delle versioni](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html) 
+  [Utilizzo del blocco oggetti Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lock.html) 
+  [Condivisione di uno snapshot Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html) 
+  [AMI condivise](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharing-amis.html) 
+  [Hosting a single-page application on Amazon S3](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html) (Ospitare un'applicazione a pagina singola su Amazon S3) 

 **Video correlati:** 
+  [Securing Your Block Storage on AWS](https://youtu.be/Y1hE1Nkcxs8) (Protezione dello storage a blocchi in AWS) 

# SEC08-BP05 Utilizzo di meccanismi per tenere le persone a distanza dai dati
<a name="sec_protect_data_rest_use_people_away"></a>

 Evita a tutti gli utenti di accedere direttamente a dati e sistemi sensibili in circostanze operative normali. Ad esempio, usa un flusso di lavoro per la gestione delle modifiche per gestire le istanze Amazon Elastic Compute Cloud (Amazon EC2) tramite strumenti, invece di consentire l'accesso diretto o tramite un host bastione. A tal fine puoi utilizzare [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), che utilizza [documenti di automazione](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) che contengono le fasi utilizzate per eseguire le attività. Questi documenti possono essere archiviati nel controllo sorgente, revisionati in peering prima dell'esecuzione e testati accuratamente per ridurre al minimo i rischi rispetto all'accesso alla shell. Gli utenti aziendali possono utilizzare un pannello di controllo anziché accedere direttamente a un datastore per eseguire query. Se non vengono utilizzate le pipeline CI/CD, determina quali controlli e processi sono necessari per fornire in modo adeguato un meccanismo di accesso di tipo break-glass normalmente disabilitato. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Implementazione di meccanismi per tenere le persone lontane dai dati: i meccanismi includono l'utilizzo di pannelli di controllo, ad esempio Quick, per mostrare i dati agli utenti anziché eseguire query direttamente. 
  +  [Quick](https://aws.amazon.com/quicksight/) 
+  Automazione della gestione della configurazione: esegui azioni a distanza, applica e convalida in automatico configurazioni sicure sfruttando un apposito servizio o strumento di gestione. Evita l'uso di bastion host o l'accesso diretto alle istanze EC2. 
  +  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
  +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
  +  [Pipeline CI/CD per modelli AWS CloudFormation su AWS](https://aws.amazon.com/quickstart/architecture/cicd-taskcat/) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Whitepaper per i dettagli della crittografia di AWS KMS](https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html) 

 **Video correlati:** 
+  [Come funziona la crittografia in AWS](https://youtu.be/plv7PQZICCM) 
+  [Securing Your Block Storage on AWS (Protezione dello storage a blocchi in AWS).](https://youtu.be/Y1hE1Nkcxs8) 

# SEC 9. In che modo proteggi i dati in transito?
<a name="sec-09"></a>

Proteggi i dati in transito implementando più controlli, per ridurre il rischio di accessi non autorizzati o perdita.

**Topics**
+ [SEC09-BP01 Implementazione della gestione sicura delle chiavi e dei certificati](sec_protect_data_transit_key_cert_mgmt.md)
+ [SEC09-BP02 Applicazione della crittografia dei dati in transito](sec_protect_data_transit_encrypt.md)
+ [SEC09-BP03 Automatizzazione del rilevamento degli accessi indesiderati ai dati](sec_protect_data_transit_auto_unintended_access.md)
+ [SEC09-BP04 Autenticazione delle comunicazioni di rete](sec_protect_data_transit_authentication.md)

# SEC09-BP01 Implementazione della gestione sicura delle chiavi e dei certificati
<a name="sec_protect_data_transit_key_cert_mgmt"></a>

 I certificati Transport Layer Security (TLS) vengono utilizzati per proteggere le comunicazioni di rete e stabilire l'identità di siti web, risorse e carichi di lavoro su Internet, nonché sulle reti private. 

 **Risultato desiderato:** un sistema di gestione dei certificati sicuro in grado di fornire, implementare, archiviare e rinnovare i certificati in un'infrastruttura a chiave pubblica (PKI). Un meccanismo sicuro di gestione delle chiavi e dei certificati impedisce la divulgazione del materiale relativo alle chiavi private dei certificati e rinnova automaticamente il certificato su base periodica. Si integra inoltre con altri servizi per fornire comunicazioni di rete e identità sicure per le risorse delle macchine all'interno del carico di lavoro. Il materiale relativo alla chiave non dovrebbe mai essere accessibile alle identità umane. 

 **Anti-pattern comuni:** 
+  Esecuzione di passaggi manuali durante i processi di distribuzione, implementazione o rinnovo dei certificati. 
+  Attenzione insufficiente alla gerarchia delle autorità di certificazione (CA) durante la progettazione di una CA privata. 
+  Utilizzo di certificati autofirmati per risorse pubbliche. 

 **Vantaggi dell'adozione di questa best practice: **
+  Semplificazione della gestione dei certificati attraverso la distribuzione, l'implementazione e il rinnovo automatizzati 
+  Incoraggiamento dell'utilizzo della crittografia dei dati in transito con l'utilizzo di certificati TLS 
+  Maggiore sicurezza e verificabilità delle operazioni di certificazione intraprese dall'autorità di certificazione 
+  Organizzazione delle mansioni di gestione ai diversi livelli della gerarchia della CA 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I carichi di lavoro moderni fanno ampio uso di comunicazioni di rete crittografate utilizzando protocolli PKI come TLS. La gestione dei certificati PKI può essere complessa, ma la fornitura, la distribuzione, l'implementazione e il rinnovo automatizzati dei certificati possono ridurre l'attrito associato alla loro gestione. 

 AWS fornisce due servizi per gestire i certificati PKI generici: [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) e [AWS Autorità di certificazione privata (AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html). ACM è il servizio principale utilizzato dai clienti per fornire, gestire e implementare certificati da utilizzare sia in carichi di lavoro di AWS pubblici che privati. ACM emette certificati utilizzando AWS Private CA e [si integra](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) con molti altri servizi AWS gestiti per fornire certificati TLS sicuri per i carichi di lavoro. 

 AWS Private CA consente di stabilire la propria autorità di certificazione principale o subordinata e di emettere certificati TLS tramite un'API. È possibile utilizzare questo tipo di certificati in scenari in cui si mantengono il controllo e la gestione della catena di fiducia sul lato client della connessione TLS. Oltre ai casi d'uso TLS, AWS Private CA può essere utilizzato per emettere certificati per i pod Kubernetes, gli attestati dei prodotti dei dispositivi Matter, la firma del codice e altri casi d'uso che prevedono un [modello personalizzato](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html). Puoi anche utilizzare la strategia di [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) per fornire credenziali temporanee IAM ai carichi di lavoro on-premise ai quali sono stati assegnati certificati X.509 firmati dalla tua CA privata. 

 Oltre a ACM e AWS Private CA, [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html) fornisce supporto specializzato per il provisioning, la gestione e l'implementazione di certificati PKI su dispositivi IoT. AWS IoT Core fornisce meccanismi specializzati per [l’onboarding di dispositivi IoT](https://docs.aws.amazon.com/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.html) nella tua infrastruttura a chiave pubblica su larga scala. 

**Considerazioni sulla creazione di una gerarchia CA privata **

 Quando è necessario stabilire una CA privata, è importante prestare particolare attenzione a progettare correttamente la gerarchia della CA fin dall'inizio. Quando si crea una gerarchia CA privata è consigliabile distribuire ogni livello della gerarchia CA su Account AWS separati. Questo passaggio intenzionale riduce l'estensione di ogni livello della gerarchia della CA, semplificando l'individuazione delle anomalie nei dati di log di CloudTrail e riducendo l'ambito di accesso o l'impatto in caso di accesso non autorizzato a uno degli account. La CA principale deve risiedere in un account separato e deve essere utilizzata solo per emettere uno o più certificati CA intermedi. 

 Quindi, crea una o più CA intermedie in account separati dall'account della CA principale per emettere certificati per utenti finali, dispositivi o altri carichi di lavoro. Infine, emetti certificati della tua CA principale a uso delle CA intermedie, che a loro volta emetteranno certificati per gli utenti finali o i dispositivi. Per ulteriori informazioni sulla pianificazione dell'implementazione della CA e sulla progettazione della gerarchia delle CA, inclusa la pianificazione della resilienza, la replica tra regioni, la condivisione delle CA all'interno dell'organizzazione e altro ancora, consulta [Pianificazione dell'implementazione di AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html). 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Determina i servizi AWS pertinenti richiesti per il tuo caso d'uso: 
   +  Molti casi d'uso possono sfruttare l'infrastruttura a chiave pubblica AWS esistente utilizzando [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html). ACM può essere utilizzato per implementare certificati TLS per server Web, sistemi di bilanciamento del carico o altri usi per certificati pubblicamente affidabili. 
   +  Considera il servizio [AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) quando è necessario stabilire una gerarchia di autorità di certificazione privata o accedere a certificati esportabili. ACM può quindi essere utilizzato per emettere [molti tipi di certificati dell'entità finale](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html) utilizzando AWS Private CA. 
   +  Per i casi d'uso in cui i certificati devono essere forniti su larga scala per dispositivi Internet delle cose (IoT) integrati, prendi in considerazione l'uso di [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html). 

1.  Implementa il rinnovo automatico dei certificati quando possibile: 
   +  utilizza [rinnovo gestito di ACM](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) per i certificati emessi da ACM insieme ai servizi AWS gestiti integrati. 

1.  Stabilisci percorsi di registrazione e controllo: 
   +  Abilita [log CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html) per tenere traccia degli accessi agli account che detengono le autorità di certificazione. Prendi in considerazione la possibilità di configurare la convalida dell'integrità dei file di log in CloudTrail per verificarne l'autenticità dei dati. 
   +  Genera e rivedi periodicamente [rapporti di audit](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html) che elencano i certificati che la tua CA privata ha emesso o revocato. Questi report possono essere esportati in un bucket S3. 
   +  Quando si implementa una CA privata, è inoltre necessario creare un bucket S3 per archiviare l'elenco di revoche dei certificati (CRL). Per indicazioni sulla configurazione di questo bucket S3 in base ai requisiti del carico di lavoro, consulta [Pianificazione di un elenco di revoche di certificati (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC02-BP02 Utilizzo di credenziali temporanee](sec_identities_unique.md) 
+ [SEC08-BP01 Implementazione della gestione sicura delle chiavi](sec_protect_data_rest_key_mgmt.md)
+  [SEC09-BP04 Autenticazione delle comunicazioni di rete](sec_protect_data_transit_authentication.md) 

 **Documenti correlati:** 
+  [Come ospitare e gestire un'intera infrastruttura di certificati privata in AWS](https://aws.amazon.com/blogs/security/how-to-host-and-manage-an-entire-private-certificate-infrastructure-in-aws/) 
+  [How to secure an enterprise scale ACM Private CA hierarchy for automotive and manufacturing](https://aws.amazon.com/blogs/security/how-to-secure-an-enterprise-scale-acm-private-ca-hierarchy-for-automotive-and-manufacturing/) 
+  [Private CA best practices](https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html) 
+  [How to use AWS RAM to share your ACM Private CA cross-account](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/) 

 **Video correlati:** 
+  [Activating AWS Certificate Manager Private CA (workshop)](https://www.youtube.com/watch?v=XrrdyplT3PE) 

 **Esempi correlati:** 
+  [Private CA workshop](https://catalog.workshops.aws/certificatemanager/en-US/introduction) 
+  [Workshop sulla gestione dei dispositivi IOT](https://iot-device-management.workshop.aws/en/) (incluso il provisioning dei dispositivi) 

 **Strumenti correlati:** 
+  [Plugin to Kubernetes cert-manager to use AWS Private CA](https://github.com/cert-manager/aws-privateca-issuer) 

# SEC09-BP02 Applicazione della crittografia dei dati in transito
<a name="sec_protect_data_transit_encrypt"></a>

Applica i requisiti di crittografia definiti in base alle policy, agli obblighi normativi e agli standard dell'organizzazione per contribuire a soddisfare i requisiti organizzativi, legali e di conformità. Utilizza solo protocolli con crittografia quando trasmetti dati sensibili al di fuori del tuo cloud privato virtuale (VPC). La crittografia aiuta a mantenere la riservatezza dei dati anche quando questi transitano su reti non affidabili.

 **Risultato desiderato:** tutti i dati devono essere crittografati in transito utilizzando protocolli e suite di crittografia TLS sicuri. Il traffico di rete tra le tue risorse e Internet deve essere crittografato per evitare l'accesso non autorizzato ai dati. Il traffico di rete esclusivamente all'interno dell'ambiente AWS deve essere crittografato utilizzando TLS, ove possibile. La rete interna di AWS è crittografata per impostazione predefinita e il traffico di rete all'interno di un VPC non può essere sottoposto a spoofing o sniffing, a meno che una parte non autorizzata non abbia ottenuto l'accesso alla risorsa che sta generando il traffico (come le istanze Amazon EC2 e i container Amazon ECS). Considera la possibilità di proteggere il traffico da rete a rete con una rete privata virtuale (VPN) IPsec. 

 **Anti-pattern comuni:** 
+  Utilizzo di versioni obsolete di SSL, TLS e componenti della suite di crittografia (ad esempio, SSL v3.0, chiavi RSA a 1024 bit e crittografia RC4). 
+  Autorizzazione del traffico non criptato (HTTP) verso o da risorse pubbliche. 
+  Monitoraggio e sostituzione mancati dei certificati X.509 prima della scadenza. 
+  Utilizzo di certificati X.509 autofirmati per TLS. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I servizi AWS forniscono endpoint HTTPS utilizzando TLS per le comunicazioni e forniscono crittografia in transito quando comunicano con le API AWS. I protocolli non sicuri, come HTTP, possono essere sottoposti a audit e bloccati in un VPC tramite l'uso di gruppi di sicurezza. Le richieste HTTP possono essere [reindirizzate automaticamente a HTTPS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) in Amazon CloudFront o su un [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions). Hai il controllo completo sulle tue risorse informatiche per implementare la crittografia in transito nei tuoi servizi. Inoltre, puoi utilizzare la connettività VPN nel VPC da una rete esterna o [AWS Direct Connect](https://aws.amazon.com/directconnect/) per facilitare la crittografia del traffico. Verifica che i tuoi client effettuino chiamate alle API AWS utilizzando almeno TLS 1.2, poiché [AWS considererà obsoleto l'utilizzo di TLS 1.0 e 1.1 da giugno 2023](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/). Per requisiti particolari, in Marketplace AWS sono disponibili soluzioni di terze parti. 

 **Passaggi dell'implementazione** 
+  **Applicazione della crittografia in transito:** i requisiti di crittografia definiti devono essere basati sugli standard e sulle best practice più recenti e consentire solo protocolli sicuri. Ad esempio, configura un gruppo di sicurezza per consentire solo il protocollo HTTPS a un Application Load Balancer o a un'istanza Amazon EC2. 
+  **Configura i protocolli sicuri nei servizi edge:** [configura HTTPS con Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html) e utilizza un [profilo di sicurezza appropriato per la postura di sicurezza e il caso d'uso](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-supported-ciphers). 
+  **Utilizza una [VPN per la connettività esterna](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html): **valuta l'impiego di una VPN IPsec per la protezione delle connessioni punto a punto o rete a rete al fine di garantire la riservatezza e l'integrità dei dati. 
+  **Configura protocolli sicuri nei sistemi di bilanciamento del carico:** seleziona una policy di sicurezza che fornisca le suite di crittografia più efficaci supportate dai client che si connetteranno all'ascoltatore. [Configurazione di un ascoltatore HTTPS per Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html). 
+  **Configura protocolli sicuri in Amazon Redshift:** configura il cluster per richiedere una [connessione Secure Socket Layer (SSL) o Transport Layer Security (TLS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html). 
+  **Configura protocolli sicuri:** analizza la documentazione relativa al servizio AWS per determinare le capacità di crittografia in transito. 
+  **Configura l'accesso sicuro durante il caricamento di bucket Amazon S3:** utilizza i controlli delle policy del bucket Amazon S3 per [applicare l'accesso sicuro](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) ai dati. 
+  **Valuta l'utilizzo di [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/):** ACM consente di fornire, gestire e implementare certificati TLS pubblici da utilizzare con i servizi AWS. 
+  **Valuta l'utilizzo di [AWS Autorità di certificazione privata](https://aws.amazon.com/private-ca/) per esigenze di PKI private:** AWS Private CA consente di creare gerarchie di autorità di certificazione (CA) private per emettere certificati X.509 end-entity che possono essere usati per creare canali TLS crittografati. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Documentazione di AWS](https://docs.aws.amazon.com/index.html)
+ [Utilizzo di HTTPS con CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html)
+ [Connetti il tuo VPC a reti remote utilizzando AWS Virtual Private Network](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html)
+ [ Configurazione di un ascoltatore HTTPS per Application Load Balancer ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)
+ [Tutorial: configurazione di SSL/TLS su Amazon Linux 2 Amazon Linux 2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html)
+ [Utilizzo di SSL/TLS per crittografare una connessione a un'istanza database](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)
+ [Configurazione delle opzioni di sicurezza per le connessioni ](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html)

# SEC09-BP03 Automatizzazione del rilevamento degli accessi indesiderati ai dati
<a name="sec_protect_data_transit_auto_unintended_access"></a>

 Usa strumenti come Amazon GuardDuty per rilevare in automatico attività o tentativi sospetti di trasferire i dati al di fuori di limiti predefiniti. Ad esempio, GuardDuty può rilevare attività di lettura di Amazon Simple Storage Service (Amazon S3) inusuale con [Exfiltration:S3/AnomalousBehavior finding](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-s3.html#exfiltration-s3-objectreadunusual). Oltre a GuardDuty, si possono utilizzare i [Registri di flusso Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html), che acquisiscono informazioni sul traffico di rete, con Amazon EventBridge per attivare il rilevamento di connessioni anomale, riuscite e negate. [Amazon S3 Access Analyzer](http://aws.amazon.com/blogs/storage/protect-amazon-s3-buckets-using-access-analyzer-for-s3) aiuta a valutare quali dati sono accessibili a chi nei bucket Amazon S3. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Automazione del rilevamento di accessi ai dati non intenzionali: utilizza uno strumento o un meccanismo di rilevamento per rilevare automaticamente i tentativi di spostamento dei dati all'esterno dei confini definiti, ad esempio, per individuare un sistema di database che copia i dati su un host sconosciuto. 
  + [ Log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 
+  Valutazione di Amazon Macie: Amazon Macie è un servizio di sicurezza e privacy dei dati completamente gestito che utilizza il machine learning e il pattern matching per rilevare e proteggere i dati sensibili all'interno di AWS. 
  + [ Amazon Macie ](https://aws.amazon.com/macie/)

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 
+ [ Amazon Macie ](https://aws.amazon.com/macie/)

# SEC09-BP04 Autenticazione delle comunicazioni di rete
<a name="sec_protect_data_transit_authentication"></a>

 Verifica l'identità delle comunicazioni utilizzando protocolli che supportano l'autenticazione, ad esempio Transport Layer Security (TLS) o IPsec. 

 Progetta il carico di lavoro in modo da utilizzare protocolli di rete sicuri e autenticati per le comunicazioni tra servizi, applicazioni o utenti. L'utilizzo di protocolli di rete che supportano l'autenticazione e l'autorizzazione offre un controllo più rigido sui flussi di rete e riduce l'impatto di eventuali accessi non autorizzati. 

 **Risultato desiderato:** un carico di lavoro con flussi di traffico del piano dati e del piano di controllo (control-plane) ben definiti tra i servizi. I flussi di traffico utilizzano protocolli di rete autenticati e crittografati laddove tecnicamente fattibile. 

 **Anti-pattern comuni:** 
+  Flussi di traffico non crittografati o non autenticati all'interno del carico di lavoro. 
+  Riutilizzo delle credenziali di autenticazione tra più utenti o entità. 
+  Uso esclusivo di controlli di rete come meccanismo di controllo degli accessi. 
+  Creazione di un meccanismo di autenticazione personalizzato anziché usare meccanismi di autenticazione standard del settore. 
+  Flussi di traffico eccessivamente permissivi tra i componenti del servizio o altre risorse nel VPC. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Limita l'ambito dell'impatto di eventuali accessi non autorizzati a una parte del carico di lavoro. 
+  Fornisce un livello più elevato di sicurezza affinché le azioni vengano eseguite solo da entità autenticate. 
+  Migliora il disaccoppiamento dei servizi definendo e applicando chiaramente le interfacce di trasferimento dei dati previste. 
+  Migliora il monitoraggio, la registrazione in log e la risposta agli incidenti tramite l'attribuzione delle richieste e interfacce di comunicazione ben definite. 
+  Fornisce un livello elevatissimo di difesa ai carichi di lavoro combinando i controlli di rete con i controlli di autenticazione e autorizzazione. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I modelli di traffico di rete del carico di lavoro possono essere suddivisi in due categorie: 
+  Il *traffico orizzontale (sinistra-destra)* rappresenta i flussi di traffico tra servizi che costituiscono un carico di lavoro. 
+  Il *traffico verticale (alto-basso)* rappresenta i flussi di traffico tra il carico di lavoro e i consumatori. 

 Mentre crittografare il traffico verticale (alto-basso) è prassi comune, proteggere il traffico orizzontale (sinistra-destra) mediante protocolli autenticati non è così frequente. Le moderne best practice di sicurezza raccomandano che la progettazione della rete non sia l'unico elemento in grado di garantire una relazione affidabile tra due entità. Quando due servizi possono trovarsi all'interno di una rete comune, è comunque consigliabile crittografare, autenticare e autorizzare le comunicazioni tra tali servizi. 

 Ad esempio, le API del servizio AWS utilizzano il protocollo di firma [AWS Signature Version 4 (SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) per autenticare il chiamante, indipendentemente dalla rete da cui proviene la richiesta. Questa autenticazione garantisce che le API AWS possano verificare l'identità che ha richiesto l'azione e che tale identità possa quindi essere combinata con le policy per decidere se autorizzare o meno l'azione. 

 Servizi come [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/access-management-overview.html) e [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) consentono di utilizzare lo stesso protocollo di firma SigV4 per aggiungere funzionalità di autenticazione e autorizzazione al traffico orizzontale (sinistra-destra) ai carichi di lavoro. Se le risorse esterne all'ambiente AWS devono comunicare con servizi che richiedono l'autenticazione e l'autorizzazione basate su SigV4, è possibile utilizzare [AWS Identity and Access Management (IAM) Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) sulla risorsa AWS per acquisire credenziali AWS temporanee. Queste credenziali possono essere utilizzate per firmare richieste ai servizi che utilizzano SigV4 per autorizzare l'accesso. 

 Un altro meccanismo comune per l'autenticazione del traffico orizzontale (sinistra-destra) è l'autenticazione reciproca TLS (mTLS). Molte applicazioni Internet delle cose (IoT), business-to-business (B2B) e microservizi utilizzano mTLS per convalidare l'identità di entrambi i lati di una comunicazione TLS mediante l'uso di certificati X.509 lato client e lato server. Questi certificati possono essere emessi da AWS Autorità di certificazione privata (AWS Private CA). È possibile utilizzare servizi come [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) e [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html) per fornire l'autenticazione mTLS per la comunicazione tra carichi di lavoro a tutti i livelli. Sebbene fornisca informazioni di autenticazione per entrambi i lati di una comunicazione TLS, mTLS non fornisce un meccanismo di autorizzazione. 

 Infine, OAuth 2.0 e OpenID Connect (OIDC) sono due protocolli generalmente utilizzati per controllare l'accesso ai servizi da parte degli utenti, ma stanno diventando popolari anche per il traffico a livello di servizi. API Gateway fornisce un [sistema di autorizzazione JSON Web Token (JWT)](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html), che consente ai carichi di lavoro di limitare l'accesso alle route API utilizzando JWT emessi da gestori dell'identità digitale OIDC o OAuth 2.0. Gli ambiti OAuth2 possono essere utilizzati come base per decisioni di autorizzazione essenziali, ma i controlli di autorizzazione devono comunque essere implementati a livello di applicazione. Gli ambiti OAuth2 da soli non possono supportare requisiti di autorizzazione più complessi. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Definisci e documenta i flussi di rete del carico di lavoro:** il primo passo per implementare una strategia di difesa di alto profilo è definire i flussi di traffico del carico di lavoro. 
  +  Crea un diagramma del flusso di dati che definisca chiaramente come vengono trasmessi i dati tra i diversi servizi che costituiscono il carico di lavoro. Questo diagramma è il primo passo per autorizzare tali flussi nei canali di rete autenticati. 
  +  Nelle fasi di sviluppo e test dota il carico di lavoro di strumenti per controllare che il diagramma del flusso dei dati rifletta accuratamente il comportamento del carico di lavoro in fase di esecuzione. 
  +  Un diagramma del flusso dei dati può essere utile anche quando si esegue un esercizio di modellazione delle minacce, come descritto in [SEC01-BP07 Identificare le minacce e dare priorità alle mitigazioni utilizzando un modello di minaccia](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html). 
+  **Definisci i controlli di rete:** considera le funzionalità AWS per stabilire controlli di rete allineati ai flussi di dati. Sebbene i confini della rete non debbano costituire l'unico elemento di controllo della sicurezza, essi forniscono un livello nella strategia di difesa di alto profilo a protezione del carico di lavoro. 
  +  Utilizza i [gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html) per stabilire, definire e limitare i flussi di dati tra risorse. 
  +  Valuta l'utilizzo di [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) per comunicare sia con AWS che con i servizi di terze parti che supportano AWS PrivateLink. I dati inviati tramite un endpoint di interfaccia AWS PrivateLink rimangono all'interno della dorsale della rete AWS e non attraversano la rete Internet pubblica. 
+  **Implementa l'autenticazione e l'autorizzazione tra i servizi del carico di lavoro:** scegli il set di servizi AWS più appropriato per fornire flussi di traffico autenticati e crittografati nel carico di lavoro. 
  +  Valuta l'ipotesi di utilizzare [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) per la sicurezza della comunicazione tra servizi. VPC Lattice può utilizzare l'[autenticazione SigV4 combinata con le policy di autenticazione](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html) per controllare l'accesso a livello di servizi. 
  +  Per la comunicazione tra servizi tramite mTLS, valuta l'ipotesi di utilizzare [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) o [App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html). [AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) può essere utilizzato per stabilire una gerarchia di autorità di certificazione (CA) private in grado di emettere certificati da utilizzare con mTLS. 
  +  Quando esegui l'integrazione con servizi che utilizzano OAuth 2.0 o OIDC, considera [l'utilizzo del sistema di autorizzazione JWT da parte di API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html). 
  +  Per la comunicazione tra il carico di lavoro e i dispositivi IoT, considera l'utilizzo di [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html), che offre diverse opzioni per la crittografia e l'autenticazione del traffico di rete. 
+  **Monitora gli accessi non autorizzati:** monitora continuamente i canali di comunicazione non intenzionali, i responsabili non autorizzati che tentano di accedere alle risorse protette e altri schemi di accesso impropri. 
  +  In caso di utilizzo di VPC Lattice per gestire l'accesso ai servizi, valuta la possibilità di abilitare e monitorare i [log di accesso di VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html). Questi log di accesso includono informazioni sull'entità richiedente, informazioni di rete tra cui VPC di origine e destinazione e metadati della richiesta. 
  +  Valuta la possibilità di abilitare i [log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) per acquisire i metadati sui flussi di rete e verificare periodicamente la presenza di anomalie. 
  +  Consulta il manuale [AWSSecurity Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) e la [sezione relativa alle risposte agli incidenti](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) del Pilastro di sicurezza del Framework AWS Well-Architected per ulteriori indicazioni su pianificazione, simulazione e risposte agli incidenti di sicurezza. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [SEC03-BP07 Analisi dell'accesso pubblico e multi-account](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC02-BP02 Utilizzo di credenziali temporanee](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC01-BP07 Identificare le minacce e dare priorità alle mitigazioni utilizzando un modello di minaccia.](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)

 **Documenti correlati:** 
+ [Valutazione dei metodi di controllo degli accessi per proteggere le API Amazon API Gateway](https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/)
+ [Configurazione dell'autenticazione TLS reciproca per una REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)
+ [Come proteggere gli endpoint HTTP API Gateway con il sistema di autorizzazione JWT](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)
+ [Autorizzazione delle chiamate dirette ai servizi AWS mediante il provider di credenziali AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)
+ [AWS Security Incident Response Guide ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)

 **Video correlati:** 
+ [AWS re:invent 2022: Introducing VPC Lattice ](https://www.youtube.com/watch?v=fRjD1JI0H5w)
+ [AWS re:invent 2020: Serverless API authentication for HTTP APIs on AWS](https://www.youtube.com/watch?v=AW4kvUkUKZ0)

 **Esempi correlati:** 
+ [ Workshop Amazon VPC Lattice](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [ Zero-Trust Episode 1 – The Phantom Service Perimeter workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)

# Risposta agli imprevisti
<a name="a-incident-response"></a>

**Topics**
+ [SEC 10. In che modo è possibile prevedere gli eventi, rispondere ad essi e risolverli?](sec-10.md)

# SEC 10. In che modo è possibile prevedere gli eventi, rispondere ad essi e risolverli?
<a name="sec-10"></a>

 Anche se dispone di controlli preventivi e di rilevamento maturi, l'organizzazione deve ancora implementare meccanismi per rispondere e mitigare il potenziale impatto degli incidenti di sicurezza. La tua preparazione influisce fortemente sulla capacità dei team di operare in modo efficace durante un incidente, isolare, contenere ed eseguire indagini sui problemi e ripristinare le operazioni a uno stato valido noto. La messa in atto degli strumenti e l'accesso prima di un incidente di sicurezza, quindi la pratica sistematica della risposta agli incidenti durante le giornate di gioco, aiuterà a garantire il ripristino, riducendo al minimo le interruzioni dell'attività. 

**Topics**
+ [SEC10-BP01 Identificazione del personale chiave e delle risorse esterne](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 Sviluppo di piani di gestione degli incidenti](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 Preparazione di funzionalità forensi](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 Sviluppo e test di playbook di risposta agli incidenti di sicurezza](sec_incident_response_playbooks.md)
+ [SEC10-BP05 Preassegnazione dell'accesso](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 Distribuzione anticipata degli strumenti](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 Esecuzione di simulazioni](sec_incident_response_run_game_days.md)
+ [SEC10-BP08 Definizione di un framework per apprendere dagli incidenti](sec_incident_response_establish_incident_framework.md)

# SEC10-BP01 Identificazione del personale chiave e delle risorse esterne
<a name="sec_incident_response_identify_personnel"></a>

 Identifica personale, risorse e requisiti legali interni ed esterni che potrebbero aiutare l'organizzazione a rispondere a un incidente. 

Quando definisci come affrontare la risposta agli incidenti nel cloud, insieme ad altri team (ad esempio il consulente legale, la leadership dell'organizzazione, le parti interessate, i servizi AWS Support e altri), devi identificare il personale chiave, le parti interessate e i contatti pertinenti. Per ridurre le dipendenze e i tempi di risposta, assicurati che il personale, i team di sicurezza specializzati e i team che rispondono agli incidenti ricevano informazioni sui servizi che utilizzi e abbiano l'opportunità di esercitarsi direttamente.

Ti invitiamo a identificare i partner di sicurezza AWS esterni in grado di fornirti competenze e una prospettiva diversa per potenziare le tue capacità di risposta. I partner di sicurezza affidabili possono aiutarti a identificare potenziali rischi o minacce che potresti non conoscere.

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  **Identificazione del personale chiave all'interno dell'organizzazione:** Conserva un elenco di contatti del personale interno alla tua organizzazione che potrebbe essere necessario coinvolgere per rispondere a un incidente ed effettuare il ripristino. 
+  **Identificazione dei partner esterni:** Se necessario, coinvolgi partner esterni che possano aiutarti a rispondere a un incidente e a effettuare il ripristino. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Incident Response Guide (Guida alle risposte agli incidenti)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **Video correlati:** 
+  [Prepare for and respond to security incidents in your AWS environment ](https://youtu.be/8uiO0Z5meCs)

 **Esempi correlati:** 

# SEC10-BP02 Sviluppo di piani di gestione degli incidenti
<a name="sec_incident_response_develop_management_plans"></a>

Il primo documento da sviluppare per la risposta agli incidenti è il piano di risposta agli incidenti. Lo scopo del piano di risposta agli incidenti è costituire la base del programma e della strategia di risposta agli incidenti. 

 **Vantaggi dell'adozione di questa best practice:** Lo sviluppo di processi di risposta agli incidenti completi e chiaramente definiti è fondamentale per un programma di risposta agli incidenti efficace e scalabile. Quando si verifica un evento di sicurezza, passaggi e flussi di lavoro ben definiti ti aiuteranno a rispondere in modo tempestivo. Potrebbero essere già presenti processi di risposta agli incidenti. Indipendentemente dallo stato attuale, è importante aggiornare, iterare e testare regolarmente i processi di risposta agli incidenti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Un piano di gestione degli incidenti è fondamentale per rispondere, mitigare e ripristinare lo stato a seguito del potenziale impatto degli incidenti di sicurezza. Un piano di gestione degli incidenti è un processo strutturato per identificare, correggere e rispondere tempestivamente agli incidenti di sicurezza.

 Il cloud ha molti degli stessi ruoli e requisiti operativi che si trovano in un ambiente on-premise. Quando si crea un piano di gestione degli incidenti è importante tenere conto delle strategie di risposta e ripristino che meglio si allineano ai risultati aziendali e ai requisiti di conformità. Ad esempio, se gestisci carichi di lavoro in AWS conformi a FedRAMP negli Stati Uniti, è utile attenersi a [NIST SP 800-61 Computer Security Handling Guide (NIST SP 800-61 Guida alla gestione della sicurezza informatica)](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf). Analogamente, quando gestisci carichi di lavoro con informazioni di identificazione personale (PII) europee, considera ad esempio come potresti proteggere e rispondere a problemi relativi alla residenza dei dati come richiesto dalle [normative del Regolamento generale sulla protezione dei dati (GDPR) dell'Unione europea](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en). 

 Quando crei un piano di gestione degli incidenti per i carichi di lavoro in AWS, inizia con il [modello di responsabilità condivisa AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) per creare un approccio di difesa in profondità in risposta agli incidenti. In questo modello, AWS gestisce la sicurezza del cloud e tu sei responsabile della sicurezza nel cloud. Ciò significa che mantieni il controllo e sei responsabile dei controlli di sicurezza che scegli di implementare. La [AWS Security Incident Response Guide (Guida alle risposte agli incidenti di sicurezza di AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) illustra i concetti chiave e le linee guida di base per la creazione di un piano di gestione degli incidenti incentrato sul cloud.

 Un piano di gestione degli incidenti efficace deve essere continuamente iterato per rimanere in linea con l'obiettivo delle operazioni cloud. Prendi in considerazione l'utilizzo dei piani di implementazione descritti di seguito durante la creazione e l'evoluzione del tuo piano di gestione degli incidenti. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

 **Definizione di ruoli e responsabilità** 

 La gestione degli eventi di sicurezza richiede disciplina interorganizzativa e propensione all'azione. All'interno della struttura organizzativa, dovrebbero esserci molte persone da considerarsi responsabili, affidabili, consultabili o informate durante un incidente, come i rappresentanti delle risorse umane (HR), i membri del team esecutivo e quelli dell'ufficio legale. Considera questi ruoli e queste responsabilità e se è necessario coinvolgere terze parti. Si noti che molte aree geografiche hanno leggi locali che regolano cosa dovrebbe e non dovrebbe essere fatto. Sebbene possa sembrare burocratico creare una tabella delle persone responsabili, affidabili, consultabili e informate (RACI) per i piani di risposta relativi alla sicurezza, ciò facilita una comunicazione rapida e diretta e delinea chiaramente la leadership nelle diverse fasi dell'evento. 

 Durante un incidente, includere i proprietari e gli sviluppatori delle applicazioni e delle risorse interessate è fondamentale perché sono esperti in materia (PMI) che possono fornire informazioni e contesto per aiutare a valutare l'impatto. Assicurati di fare pratica e instaurare relazioni con gli sviluppatori e i proprietari delle applicazioni prima di affidarti alla loro esperienza per la gestione della risposta agli incidenti. I proprietari di applicazioni o le PMI, come gli amministratori o gli ingegneri del cloud, potrebbero dover intervenire in situazioni in cui l'ambiente non è noto oppure è complesso o chi risponde non ha accesso all'ambiente interessato. 

 Infine, nell'indagine o nella risposta potrebbero essere coinvolti partner affidabili perché possono fornire competenze aggiuntive e capacità analitiche strategiche. Quando non disponi di queste competenze nel tuo team, potresti voler assumere una persona esterna per assistenza. 

 **Analisi del team di risposta di AWS e del supporto** 
+  **Supporto AWS** 
  +  [Supporto](https://aws.amazon.com/premiumsupport/) offre un'ampia gamma di piani che forniscono accesso agli strumenti e alla competenza che genera successo e stato operativo delle soluzioni AWS. Se hai bisogno di supporto tecnico e di ulteriori risorse per pianificare, implementare e ottimizzare il tuo ambiente AWS, puoi selezionare il piano di supporto più adatto al tuo caso d'uso AWS. 
  +  Valuta l'ipotesi di utilizzare il [Centro di supporto](https://console.aws.amazon.com/support) in Console di gestione AWS (è richiesto l'accesso) come punto di contatto centralizzato per ottenere assistenza per problemi che riguardano le tue risorse AWS. L'accesso a Supporto è controllato da AWS Identity and Access Management. Per ulteriori informazioni sull'accesso alle funzionalità Supporto, consulta la sezione [Nozioni di base su Supporto](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support). 
+  **Team di risposta agli incidenti dei clienti AWS (CIRT)** 
  +  Il Team di risposta agli incidenti dei clienti AWS (CIRT) è un team AWS globale specializzato disponibile 24 ore su 24, 7 giorni su 7, che fornisce supporto ai clienti durante eventi di sicurezza attivi sul lato cliente del [modello di responsabilità condivisa AWS](https://aws.amazon.com/compliance/shared-responsibility-model/). 
  +  Quando il team AWS CIRT ti supporta, fornisce assistenza nella valutazione e nel ripristino di un evento di sicurezza attivo AWS. Può aiutare nell'analisi delle cause principali con l'uso dei log dei servizi AWS e fornire suggerimenti per il ripristino. Può anche fornire consigli e best practice sulla sicurezza per aiutarti a evitare eventi di sicurezza in futuro. 
  +  I clienti AWS possono coinvolgere il team AWS CIRT attraverso un [caso Supporto](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html). 
+  **Supporto per la risposta agli attacchi DDoS** 
  +  AWS offre [AWS Shield](https://aws.amazon.com/shield/), che fornisce un servizio di protezione DDoS (Distributed Denial of Service) gestito che protegge le applicazioni Web in esecuzione su AWS. Shield fornisce un rilevamento sempre attivo e mitigazioni automatiche in linea che possono ridurre al minimo i tempi di inattività e la latenza delle applicazioni, quindi non è necessario utilizzare Supporto per avvalersi della protezione dagli attacchi DDoS. Esistono due livelli di Shield: AWS Shield Standard e AWS Shield Advanced. Per maggiori informazioni sulle differenze tra questi due livelli, consulta la [documentazione delle funzionalità di Shield](https://aws.amazon.com/shield/features/). 
+  **AWS Managed Services (AMS)** 
  +  [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) offre gestione continua dell'infrastruttura AWS, così potrai occuparti a tempo pieno delle tue applicazioni. Grazie all'implementazione delle best practice per la gestione dell'infrastruttura, AMS riduce il sovraccarico operativo e il livello di rischio. AMS automatizza attività frequenti quali richieste di modifica, monitoraggio, gestione di patch, sicurezza e backup, nonché fornisce servizi completi per il ciclo di vita per gestire provisioning, esecuzione e supporto dell'infrastruttura. 
  +  AMS è responsabile dell'implementazione di una suite di controlli di sicurezza e fornisce una risposta di prima linea agli avvisi 24 ore su 24, 7 giorni su 7. Quando viene avviato un avviso, AMS segue una serie standard di playbook automatici e manuali per verificare una risposta coerente. Questi playbook vengono condivisi con i clienti AMS durante l'onboarding in modo che possano sviluppare e coordinare una risposta con AMS. 

 **Sviluppo di piani di risposta agli incidenti** 

 Lo scopo del piano di risposta agli incidenti è costituire la base del programma e della strategia di risposta agli incidenti. Il piano di risposta agli incidenti deve essere contenuto in un documento formale. Un piano di risposta agli incidenti include in genere le seguenti sezioni: 
+  **Una panoramica del team di risposta agli incidenti:** delinea gli obiettivi e le funzioni del team di risposta agli incidenti. 
+  **Ruoli e responsabilità:** elenca le parti interessate alla risposta agli incidenti e descrive in dettaglio i loro ruoli quando si verifica un incidente. 
+  **Un piano di comunicazione:** dettagli sulle informazioni di contatto e su come comunichi durante un incidente. 
+  **Metodi di comunicazione di backup:** è consigliabile utilizzare la comunicazione fuori banda come backup in caso di incidente. Un esempio di applicazione che fornisce un canale di comunicazione fuori banda sicuro è AWS Wickr. 
+  **Fasi di risposta agli incidenti e azioni da intraprendere:** enumera le fasi della risposta agli incidenti (ad esempio, rilevamento, analisi, eliminazione, contenimento e ripristino), comprese le azioni di alto livello da intraprendere all'interno di tali fasi. 
+  **Definizioni di gravità e prioritizzazione degli incidenti:** descrive in dettaglio come classificare la gravità di un incidente, come assegnare la priorità all'incidente e, quindi, in che modo le definizioni di gravità influiscono sulle procedure di escalation. 

 Sebbene queste sezioni siano comuni a società di diverse dimensioni e settori, il piano di risposta agli incidenti di ciascuna organizzazione è unico. Devi creare un piano di risposta agli incidenti che funzioni al meglio per la tua organizzazione. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC 4 (In che modo individui ed esamini gli eventi di sicurezza?)](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) 

 **Documenti correlati:** 
+  [AWS Security Incident Response Guide (Guida alle risposte agli incidenti di sicurezza di AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [ NIST: Guida alla gestione degli incidenti di sicurezza informatica ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)

# SEC10-BP03 Preparazione di funzionalità forensi
<a name="sec_incident_response_prepare_forensic"></a>

Prima che si verifichi un incidente di sicurezza, puoi sviluppare le funzionalità forensi per supportare le indagini sugli eventi di sicurezza. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

 Il concetto della tradizionale analisi forense on-premise si applica ad AWS. Per informazioni chiave su come iniziare a sviluppare funzionalità forensi in Cloud AWS, consulta [Forensic investigation environment strategies in the Cloud AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/). 

 Una volta configurati l'ambiente e la struttura di Account AWS per le funzionalità forensi, definisci le tecnologie necessarie in modo da eseguire efficacemente le metodologie forensi in quattro fasi: 
+  **Raccolta:** acquisisci i log AWS pertinenti, come quelli di AWS CloudTrail, AWS Config, del flusso VPC e dell'host. Raccogli snapshot, backup e dump di memoria delle risorse AWS interessate, se disponibili. 
+  **Esame:** rivedi i dati raccolti estraendo e valutando le informazioni pertinenti. 
+  **Analisi:** studia i dati raccolti per comprendere l'incidente e trarre le conclusioni. 
+  **Segnalazione:** presenta le informazioni risultanti dalla fase di analisi. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

 **Preparazione dell'ambiente per le funzionalità forensi** 

 [AWS Organizations](https://aws.amazon.com/organizations/) ti aiuta a gestire e governare centralmente un ambiente AWS mentre le risorse AWS crescono e si dimensionano. Un'organizzazione AWS consolida gli Account AWS in modo da poterli amministrare come una singola unità. È possibile utilizzare le unità organizzative per raggruppare gli account e amministrarli come singola unità. 

 Per rispondere agli incidenti è utile disporre di una struttura di Account AWS che supporti le funzioni di risposta agli incidenti e includa una *Unità organizzativa di sicurezza* e una *Unità organizzativa forense*. All'interno dell'unità organizzativa di sicurezza, è necessario disporre degli account per: 
+  **Archiviazione dei log:** aggrega i log in un Account AWS di archiviazione dei log con autorizzazioni limitate. 
+  **Strumenti di sicurezza:** centralizza i servizi di sicurezza in un Account AWS dello strumento di sicurezza. Questo account funge da amministratore delegato per i servizi di sicurezza. 

 Nell'unità organizzativa di funzionalità forensi, hai la possibilità di implementare uno o più account di funzionalità forensi per ogni regione in cui operi, a seconda di quale è più adatta all'azienda e al modello operativo. Se crei un account di funzionalità forensi per regione, puoi bloccare la creazione di risorse AWS al di fuori della regione e ridurre il rischio che le risorse vengano copiate in una regione indesiderata. Ad esempio, se operi solo in US East (N. Virginia) Region (`us-east-1`) e US West (Oregon) (`us-west-2`), allora avresti due account nell'unità organizzativa forense: uno per `us-east-1` e uno per `us-west-2`. 

 Puoi creare un Account AWS di funzionalità forensi per più regioni. Quando si copiano le risorse AWS nell'account occorre prestare attenzione a rispettare i requisiti di sovranità dei dati. Poiché la creazione di nuovi account richiede tempo, è fondamentale creare e strumentare gli account di funzionalità forensi con largo anticipo rispetto agli incidenti, in modo che gli addetti siano preparati a utilizzarli efficacemente per la risposta. 

 Il diagramma seguente mostra una struttura degli account di esempio che include un'unità organizzativa di funzionalità forensi con gli account di funzionalità forensi per regione: 

![\[Diagramma di flusso che mostra la struttura degli account per regione per la risposta agli incidenti, suddivisa nelle unità organizzative di sicurezza e funzionalità forensi.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/region-account-structure.png)


 **Acquisizione di backup e snapshot** 

 La configurazione dei backup dei sistemi e dei database importanti è fondamentale per il ripristino da un incidente di sicurezza e per scopi forensi. Con i backup puoi ripristinare i tuoi sistemi allo stato di sicurezza precedente. In AWS puoi acquisire snapshot di varie risorse. Gli snapshot forniscono i backup point-in-time delle risorse. Esistono molti servizi AWS che possono supportarti nelle operazioni di backup e ripristino. Per informazioni dettagliate su questi servizi e approcci per il backup e il ripristino, consultare [Guida prescrittiva per il backup e il ripristino](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html) e [Usa i backup per il ripristino in seguito a incidenti di sicurezza](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/). 

 Soprattutto in situazioni come un attacco ransomware, è fondamentale che i backup siano ben protetti. Per indicazioni sulla protezione dei backup, consultare [Le 10 migliori pratiche di sicurezza per proteggere i backup in AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/). Oltre a proteggere, è necessario eseguire regolarmente i test dei processi di backup e ripristino per verificare che la tecnologia e le procedure in uso funzionino come previsto. 

 **Automazione delle funzionalità forensi** 

 Durante un evento di sicurezza, il team addetto a rispondere agli incidenti deve essere in grado di raccogliere e analizzare rapidamente le prove, mantenendo la precisione per il periodo di tempo relativo all'evento (ad esempio acquisendo i log relativi a una risorsa o un evento specifico o raccogliendo il dump della memoria di un'istanza Amazon EC2). Per il team addetto a rispondere agli incidenti è difficile e dispendioso in termini di tempo raccogliere manualmente le prove pertinenti, soprattutto se le istanze e gli account sono numerosi. Inoltre, la raccolta manuale può essere soggetta all'errore umano. Per questi motivi, è necessario sviluppare e implementare il più possibile l'automazione per le funzionalità forensi. 

 AWS offre una serie di risorse di automazione per le funzionalità forensi, elencate nella sezione Risorse di seguito. Queste risorse sono esempi di modelli di funzionalità forensi che abbiamo sviluppato e che i clienti hanno implementato. Costituiscono un'utile architettura di riferimento per iniziare, ma prendi in considerazione la possibilità di modificarli o creare nuovi modelli di automazione per le funzionalità forensi in base all'ambiente, ai requisiti, agli strumenti e ai processi forensi. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [AWS Security Incident Response Guide - Develop Forensics Capabilities ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/develop-forensics-capabilities.html)
+ [AWS Security Incident Response Guide - Forensics Resources ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-b-incident-response-resources.html#forensic-resources)
+ [Forensic investigation environment strategies in the Cloud AWS](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)
+  [How to automate forensic disk collection in AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) 
+ [AWS Prescriptive Guidance - Automate incident response and forensics ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html)

 **Video correlati:** 
+ [ Automatizzazione delle indagini e della risposta agli incidenti ](https://www.youtube.com/watch?v=f_EcwmmXkXk)

 **Esempi correlati:** 
+ [ Automated Incident Response and Forensics Framework ](https://github.com/awslabs/aws-automated-incident-response-and-forensics)
+ [ Automated Forensics Orchestrator for Amazon EC2 ](https://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/welcome.html)

# SEC10-BP04 Sviluppo e test di playbook di risposta agli incidenti di sicurezza
<a name="sec_incident_response_playbooks"></a>

 Una parte fondamentale della preparazione dei processi di risposta agli incidenti è costituita dallo sviluppo di playbook. I playbook di risposta agli incidenti forniscono una serie di indicazioni prescrittive e di passaggi da seguire quando si verifica un evento di sicurezza. Avere una struttura e passaggi chiari semplifica la risposta e riduce la probabilità di errore umano. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 È necessario creare i playbook per scenari di incidenti come: 
+  **Incidenti previsti**: i playbook devono essere creati per gli incidenti previsti. tra cui minacce come il Denial of Service (DoS), il ransomware e la compromissione delle credenziali. 
+  **Avvisi o esiti di sicurezza noti**: i playbook devono essere creati per gli esiti e gli avvisi di sicurezza noti, ad esempio gli esiti GuardDuty. Potresti ricevere un risultato di GuardDuty e non sapere cosa fare. Per evitare di mal gestire o ignorare un risultato di GuardDuty, crea un playbook per ogni potenziale risultato di GuardDuty. I dettagli e le indicazioni sulla correzione sono disponibili nella [documentazione di GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html). Vale la pena notare che GuardDuty non è abilitato per impostazione predefinita e comporta costi. Per maggiori dettagli su GuardDuty, consulta [Appendice A: Definizioni delle capacità del cloud - Visibilità e avvisi](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/visibility-and-alerting.html). 

 I playbook devono contenere i passaggi tecnici che un analista deve completare per indagare e rispondere adeguatamente a un potenziale incidente di sicurezza. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Gli elementi da includere in un playbook sono: 
+  **Panoramica del playbook**: quale scenario di rischio o incidente affronta questo playbook? Qual è l'obiettivo del playbook? 
+  **Prerequisiti**: quali log, meccanismi di rilevamento e strumenti automatizzati sono necessari per questo scenario di incidente? Qual è la notifica prevista? 
+  **Informazioni sulla comunicazione e sull'escalation**: chi è coinvolto e quali sono le loro informazioni di contatto? Quali sono le responsabilità di ogni stakeholder? 
+  **Fasi di risposta**: in tutti i passaggi per la risposta agli incidenti, quali misure tattiche devono essere prese? Quali query deve eseguire l'analista? Quale codice deve essere eseguito per ottenere il risultato desiderato? 
  +  **Individuazione**: come verrà rilevato l'incidente? 
  +  **Analisi**: come verrà determinato l'ambito dell'impatto? 
  +  **Contenimento**: come verrà isolato l'incidente per limitarne la portata? 
  +  **Sradicamento**: come verrà rimossa la minaccia dall'ambiente? 
  +  **Recupero**: in che modo il sistema o la risorsa interessati verranno riportati in produzione? 
+  **Risultati attesi**: dopo l'esecuzione delle query e del codice, qual è il risultato previsto del playbook? 

## Risorse
<a name="resources"></a>

 **Best practice Well-Architected correlate:** 
+  [SEC10-BP02 Sviluppo di piani di gestione degli incidenti](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html) 

 **Documenti correlati:** 
+  [Framework for Incident Response Playbooks](https://github.com/aws-samples/aws-customer-playbook-framework)  
+  [Develop your own Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks-workshop)  
+  [Incident Response Playbook Samples](https://github.com/aws-samples/aws-incident-response-playbooks)  
+  [Building an AWS incident response runbook using Jupyter playbooks and CloudTrail Lake](https://catalog.workshops.aws/incident-response-jupyter/en-US)  

 

# SEC10-BP05 Preassegnazione dell'accesso
<a name="sec_incident_response_pre_provision_access"></a>

Verifica che il team di risposta agli incidenti disponga degli opportuni diritti di accesso allocati in AWS per ridurre i tempi necessari per l'analisi e il ripristino.

 **Anti-pattern comuni:** 
+  L'utilizzo dell'account root per la risposta agli incidenti. 
+  La modifica degli account utente esistenti. 
+  La manipolazione diretta delle autorizzazioni IAM quando si fornisce l'elevazione dei privilegi just-in-time. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

AWS raccomanda di ridurre o eliminare, ove possibile, la dipendenza da credenziali di lunga durata, a favore delle credenziali temporanee e dei meccanismi di escalation dei privilegi *just-in-time* . Le credenziali di lunga durata sono soggette a rischi per la sicurezza e aumentano il sovraccarico operativo. Per la maggior parte delle attività di gestione, nonché per le attività di risposta agli incidenti, consigliamo di implementare [la federazione delle identità](https://docs.aws.amazon.com/identity/federation/) insieme [all'escalation temporanea per l'accesso amministrativo](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/). In questo modello, un utente richiede l'elevazione a un livello di privilegio superiore (come un ruolo di risposta agli incidenti) e, se è idoneo all'elevazione, la richiesta viene inviata al responsabile dell'approvazione. Se la richiesta viene approvata, l'utente riceve un set di credenziali [AWS temporanee](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) che può utilizzare per eseguire le sue attività. Alla scadenza di queste credenziali, l'utente deve inviare una nuova richiesta di elevazione.

 Si consiglia l'uso dell'escalation temporanea dei privilegi nella maggior parte degli scenari di risposta agli incidenti. Il modo corretto per farlo è utilizzare [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) e [le policy di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) per definire l'ambito di accesso. 

 Esistono scenari in cui le identità federate non sono disponibili, come nei casi di: 
+  Interruzione correlata a un gestore dell'identità digitale (IdP) compromesso. 
+  Configurazione errata o errore umano che causa l'interruzione del sistema di gestione dell'accesso federato. 
+  Attività dannose come un evento DDoS (Distributed Denial of Service) o indisponibilità del sistema. 

 Nei casi precedenti, si deve configurare un accesso di emergenza *di tipo break-glass* per consentire l'analisi e la tempestiva risoluzione degli incidenti. Ti consigliamo di utilizzare [un utente IAM con le autorizzazioni appropriate](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) per eseguire le attività e accedere alle risorse AWS. Utilizza le credenziali root solo per le [attività che richiedono l'accesso come utente root](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Per verificare che i team di risposta agli incidenti dispongano del corretto livello di accesso ad AWS e ad altri sistemi pertinenti, ti consigliamo di eseguire la pre-assegnazione di account utente dedicati. Gli account utente richiedono l'accesso con privilegi e devono essere rigorosamente controllati e monitorati. Gli account devono essere creati con il minor numero di privilegi richiesti per eseguire le attività e il livello di accesso deve essere basato sui playbook inclusi nel piano di gestione degli incidenti. 

 Utilizza utenti e ruoli specifici e dedicati come best practice. L'escalation temporanea dell'accesso di utenti o ruoli tramite l'aggiunta di policy IAM rende poco chiaro quale fosse l'accesso degli utenti durante l'incidente e rischia di non revocare i privilegi oggetto di escalation. 

 È importante rimuovere il maggior numero possibile di dipendenze per verificare che sia possibile ottenere l'accesso nel maggior numero possibile di scenari di errore. Per supportare questa esigenza, crea un playbook per verificare che gli utenti dei team di risposta agli incidenti vengano creati come utenti AWS Identity and Access Management in un account di sicurezza dedicato e non gestiti tramite una federazione esistente o una soluzione di autenticazione unica (SSO). Ogni singolo utente dei team di risposta deve avere il proprio account denominato. La configurazione dell'account deve applicare [una policy di password complesse](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) e l'autenticazione a più fattori (MFA). Se i playbook di risposta agli incidenti richiedono solo l'accesso alla Console di gestione AWS, non è necessario che l'utente disponga di chiavi di accesso configurate né che sia esplicitamente autorizzato a creare chiavi di accesso. A tale scopo è possibile configurare le policy IAM o le policy di controllo dei servizi come menzionato in AWS Security Best Practices (Best practice di sicurezza AWS) per [le policy di controllo dei servizi AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Gli utenti non devono avere privilegi oltre la capacità di assumere i ruoli di risposta agli incidenti in altri account. 

 Durante un incidente potrebbe essere necessario concedere l'accesso ad altre persone interne o esterne per supportare le attività di analisi, correzione o ripristino. In questo caso, utilizza il meccanismo del playbook menzionato in precedenza e un processo per verificare che qualsiasi accesso aggiuntivo venga revocato immediatamente dopo il completamento dell'incidente. 

 Per verificare che l'uso dei ruoli di risposta agli incidenti possa essere adeguatamente monitorato e controllato, è essenziale che gli account utente IAM creati a tale scopo non siano condivisi tra le persone e che l'utente root Account AWS non venga utilizzato se [non per un'attività specifica](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html). Se è richiesto l'utente root (ad esempio, l'accesso IAM a un account specifico non è disponibile), utilizza un processo separato con un playbook disponibile per verificare la disponibilità della password dell'utente root e del token MFA. 

 Per configurare le policy IAM per i ruoli di risposta agli incidenti, prendi in considerazione di usare [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) per generare le policy sulla base dei log AWS CloudTrail. In questo caso, concedi l'accesso come amministratore al ruolo di risposta agli incidenti per un account non di produzione ed esegui i playbook. Al termine, potrà essere creata una policy che consenta solo le azioni da intraprendere. Questa policy può quindi essere applicata a tutti i ruoli di risposta agli incidenti in tutti gli account. Puoi anche creare una policy IAM separata per ogni playbook per avere una gestione e un controllo più semplici. Esempi di playbook possono essere piani di risposta per ransomware, violazioni dei dati, perdita dell'accesso alla produzione e altri scenari. 

 Utilizza gli account utente di risposta agli incidenti per assumere i ruoli di risposta [IAM dedicati in altri Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html). Questi ruoli devono essere configurati in modo che possano essere assunti solo dagli utenti nell'account di sicurezza e la relazione di trust deve richiedere che il principale chiamante sia autenticato tramite MFA. I ruoli devono utilizzare policy IAM con ambito limitato per controllare l'accesso. Assicurati che tutte le richieste `AssumeRole` per questi ruoli vengano registrate in CloudTrail e notificate e che tutte le azioni intraprese utilizzando questi ruoli vengano registrate. 

 Ti consigliamo vivamente di nominare chiaramente gli account utente IAM e i ruoli IAM per trovarli facilmente nei log CloudTrail. Un esempio potrebbe essere quello di nominare gli account IAM `<ID_UTENTE>-BREAK-GLASS` e i ruoli IAM `RUOLO-BREAK-GLASS`. 

 [CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) viene utilizzato per registrare l'attività API negli account AWS e deve essere utilizzato per [configurare gli avvisi sull'utilizzo dei ruoli di risposta agli incidenti](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/). Fai riferimento al post del blog sulla configurazione degli avvisi quando vengono utilizzate le chiavi root. Le istruzioni possono essere modificate per configurare il parametro [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) da filtro a filtro negli eventi `AssumeRole` correlati al ruolo IAM di risposta agli incidenti: 

```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<ARN_RUOLO_DI_RISPOSTA_AGLI_INCIDENTI>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```

 Poiché è probabile che i ruoli di risposta agli incidenti abbiano un livello di accesso elevato, è importante che questi avvisi vengano inviati a un gruppo ampio e vengano gestiti tempestivamente. 

 Durante un incidente, è possibile che un membro del team di risposta richieda l'accesso a sistemi che non sono direttamente protetti da IAM, ad esempio istanze Amazon Elastic Compute Cloud, database Amazon Relational Database Service o piattaforme Software-as-a-service (SaaS). Anziché i protocolli nativi come SSH o RDP, ti consigliamo vivamente di utilizzare [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) per l'accesso amministrativo completo alle istanze Amazon EC2. Questo accesso può essere monitorato utilizzando IAM, che è sicuro e controllato. Puoi anche automatizzare parti dei tuoi playbook utilizzando i documenti di [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)che possono ridurre gli errori dell'utente e migliorare i tempi di ripristino. Per l'accesso a database e strumenti di terze parti, ti consigliamo di archiviare le credenziali di accesso in Gestione dei segreti AWS e di concedere l'accesso ai ruoli degli utenti dei team di risposta agli incidenti. 

 Infine, la gestione degli account utente IAM di risposta agli incidenti deve essere aggiunta ai processi [degli utenti che si uniscono, si spostano o lasciano l'organizzazione](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) e deve rivista e testata periodicamente per verificare che sia consentito solo l'accesso previsto. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Managing temporary elevated access to your AWS environment (Gestione dell'accesso temporaneo con privilegi elevati all'ambiente AWS)](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) 
+  [AWS Security Incident Response Guide (Guida alle risposte agli incidenti di sicurezza di AWS) ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+  [Ripristino di emergenza di elastico di AWS](https://aws.amazon.com/disaster-recovery/) 
+  [Strumento di gestione degli incidenti AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [Impostazione di una policy delle password dell'account per utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 
+  [Utilizzo dell'autenticazione a più fattori (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) 
+ [ Configuring Cross-Account Access with MFA (Configurazione dell'accesso multi-account con MFA) ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ Using IAM Access Analyzer to generate IAM policies (Utilizzo di IAM Access Analyzer per generare policy IAM) ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [ Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment (Best practice per le policy di controllo dei servizi di AWS Organizations in un ambiente multi-account) ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ How to Receive Notifications When Your AWS Account’s Root Access Keys Are Used (Come ricevere le notifiche quando vengono utilizzate le chiavi di accesso root dell'account AWS) ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ Create fine-grained session permissions using IAM managed policies (Creazione di autorizzazioni di sessione dettagliate utilizzando le policy gestite da IAM) ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)

 **Video correlati:** 
+ [ Automating Incident Response and ForensicsAWS](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+  [DIY guide to runbooks, incident reports, and incident response](https://youtu.be/E1NaYN_fJUo) 
+ [ Prepare for and respond to security incidents in your AWS environment ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **Esempi correlati:** 
+ [ Lab: AWS Account Setup and Root User (Laboratorio: configurazione dell'account AWS e dell'utente root) ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ Lab: Incident Response with AWS Console and CLI (Laboratorio: risposta agli incidenti con la Console AWS e l'interfaccia della riga di comando) ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP06 Distribuzione anticipata degli strumenti
<a name="sec_incident_response_pre_deploy_tools"></a>

Verifica che il team addetto alla sicurezza disponga degli strumenti giusti pre-distribuiti per ridurre i tempi di indagine fino al ripristino.

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per automatizzare le funzioni delle operazioni e la risposta di sicurezza, puoi utilizzare un set completo di API e strumenti AWS. Puoi automatizzare completamente le funzionalità di gestione delle identità, sicurezza della rete, protezione dei dati e monitoraggio e distribuirle utilizzando metodi di sviluppo software comuni già esistenti. Quando crei l'automazione della sicurezza, il sistema può monitorare, rivedere e avviare una risposta, invece di far monitorare alle persone il comportamento di sicurezza e reagire manualmente agli eventi. 

 Se i team di risposta agli incidenti continuano a rispondere agli avvisi nello stesso modo, rischiano il cosiddetto affaticamento dagli avvisi ("alert fatigue"). Ciò significa che, nel corso del tempo, il team può diventare desensibilizzato agli avvisi e può commettere errori nella gestione di situazioni ordinarie o farsi sfuggire avvisi insoliti. L'automazione aiuta a evitare l'affaticamento dagli avvisi utilizzando funzioni che elaborano gli avvisi ripetitivi e ordinari, lasciando alle persone la gestione degli incidenti sensibili e univoci. Se si integrano sistemi di rilevamento delle anomalie, come Amazon GuardDuty, AWS CloudTrail Insights e Amazon CloudWatch Anomaly Detection, è possibile ridurre l'impatto di avvisi frequenti basati su soglie. 

 Puoi migliorare i processi manuali automatizzando le fasi del processo a livello di programmazione. Dopo aver definito il modello di correzione di un evento, puoi decomporre tale modello in una logica fruibile e scrivere il codice per eseguire tale logica. Il team addetto alla risposta può quindi eseguire il codice per risolvere il problema. Nel corso del tempo, puoi automatizzare più fasi e, infine, gestire automaticamente intere classi di incidenti comuni. 

 Durante un'indagine di sicurezza, devi essere in grado di esaminare i log pertinenti per registrare e comprendere l'intera portata e la tempistica dell'incidente. I log sono necessari anche per la generazione di avvisi, che indicano che sono avvenute determinate azioni di interesse. È fondamentale selezionare, attivare, memorizzare e impostare i meccanismi di query e recupero e impostare gli avvisi. Inoltre, un modo efficace per fornire gli strumenti per la ricerca nei dati di log è [Amazon Detective](https://aws.amazon.com/detective/). 

 AWS offre oltre 200 servizi cloud e migliaia di funzionalità. Ti consigliamo di esaminare i servizi che possono supportare e semplificare la tua strategia di risposta agli incidenti. 

 Oltre ai log, è necessario sviluppare e implementare una [strategia di applicazione dei tag](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). L'applicazione dei tag può aiutare a fornire il contesto per lo scopo di una risorsa AWS. I tag può essere utilizzati anche per l'automazione. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 **Seleziona e configura i log per l'analisi e gli avvisi** 

 Consulta la seguente documentazione sulla configurazione dei log per la risposta agli incidenti: 
+ [ Logging strategies for security incident response ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+  [SEC04-BP01 Configurazione dei registri di servizi e applicazioni](sec_detect_investigate_events_app_service_logging.md) 

 **Abilitazione dei servizi di sicurezza per supportare il rilevamento e la risposta** 

 AWS offre funzionalità investigative, preventive e reattive native e altri servizi che possono essere utilizzati per progettare soluzioni di sicurezza personalizzate. Per un elenco dei servizi più pertinenti per la risposta agli incidenti di sicurezza, consulta [Definizioni delle capacità del cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html). 

 **Sviluppa e implementa una strategia di tag** 

 Ottenere informazioni contestuali sul caso d'uso aziendale e sugli stakeholder interni pertinenti relativi a una risorsa AWS può essere difficile. Un modo per farlo è rappresentato dai tag che assegnano i metadati alle risorse AWS e sono composti da una chiave e un valore definiti dall'utente. Puoi creare i tag per classificare le risorse per scopo, proprietario, ambiente, tipo di dati elaborati e altri criteri di tua scelta. 

 Avere una strategia di tag coerente può accelerare le risposta e ridurre al minimo il tempo dedicato al contesto organizzativo, consentendo di identificare e discernere rapidamente le informazioni contestuali su una risorsa AWS. I tag possono anche fungere da meccanismo per avviare le automazioni di risposta. Per maggiori dettagli su cosa etichettare, consulta [Etichettare le tue risorse AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). Dovrai prima definire i tag nella tua organizzazione e quindi implementare e applicare questa strategia di tag. Per maggiori dettagli sull'implementazione e l'applicazione, consulta [Implementa una strategia di etichettatura delle risorse AWS utilizzando AWS Tag Policies and Service Control Policies (SCPs)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/). 

## Risorse
<a name="resources"></a>

 **Best practice Well-Architected correlate:** 
+  [SEC04-BP01 Configurazione dei registri di servizi e applicazioni](sec_detect_investigate_events_app_service_logging.md) 
+  [SEC04-BP02 Analisi di log, risultati e parametri a livello centrale](sec_detect_investigate_events_analyze_all.md) 

 **Documenti correlati:** 
+ [ Logging strategies for security incident response ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [ Incident response cloud capability definitions ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html)

 **Esempi correlati:** 
+ [ Threat Detection and Response with Amazon GuardDuty and Amazon Detective ](https://catalog.workshops.aws/guardduty/en-US)
+ [ Security Hub Workshop ](https://catalog.workshops.aws/security-hub/en-US)
+ [ Vulnerability Management with Amazon Inspector ](https://catalog.workshops.aws/inspector/en-US)

# SEC10-BP07 Esecuzione di simulazioni
<a name="sec_incident_response_run_game_days"></a>

 Man mano che le organizzazioni crescono e si evolvono nel tempo, aumentano anche le tipologie di minacce. Per questo motivo, è importante rivedere continuamente le capacità di risposta agli incidenti. L'esecuzione di simulazioni (note anche come giornate di gioco) è un metodo che può essere utilizzato per eseguire questa valutazione. Le simulazioni utilizzano scenari di eventi di sicurezza reali progettati per simulare le tattiche, le tecniche e le procedure (TTP) di un autore di minacce e consentire a un'organizzazione di esercitarsi e valutare le proprie capacità di risposta agli incidenti rispondendo a questi finti eventi informatici così come potrebbero verificarsi nella realtà.

 **Vantaggi dell'adozione di questa best practice:** le simulazioni offrono una serie di vantaggi: 
+  Convalida della preparazione informatica e sviluppo della fiducia dei team di risposta agli incidenti. 
+  Verifica della precisione e dell'efficienza di strumenti e flussi di lavoro. 
+  Perfezionamento dei metodi di comunicazione ed escalation in linea con il piano di risposta agli incidenti. 
+  Opportunità di rispondere per i vettori meno comuni. 

**Livello di rischio associato alla mancata adozione di questa best practice:** medio

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Esistono tre tipi principali di simulazioni: 
+  **Simulazioni di situazioni di emergenza:** le simulazioni di situazioni di emergenza sono sessioni basate sulla discussione che coinvolgono le varie parti interessate alla risposta agli incidenti per mettere in pratica ruoli e responsabilità e utilizzare strumenti e playbook di comunicazione consolidati. Lo svolgimento dell'esercitazione può in genere essere eseguito in un'intera giornata in un luogo virtuale, in un luogo fisico o in una combinazione di questi tipi di luogo. Poiché è basato sulla discussione, questo tipo di esercitazione si concentra su processi, persone e collaborazione. La tecnologia è parte integrante della discussione, ma l'uso effettivo di strumenti o script di risposta agli incidenti in genere non rientra in questo tipo di simulazione. 
+  **Esercizi del team viola:** questo tipo di esercitazioni aumenta il livello di collaborazione tra i team di risposta agli incidenti (team blu) e gli attori delle minacce simulate (team rosso). Il team blu è composto da membri del Security Operations Center (SOC), ma può includere anche altre parti interessate che sarebbero coinvolte durante un vero e proprio evento informatico. Il team rosso è composto da un team responsabile dei test di penetrazione (pen-test) o da parti interessate chiave esperte in materia di sicurezza informatica. Il team rosso lavora assieme ai coordinatori dell'esercitazione durante la progettazione di uno scenario in modo che lo scenario sia accurato e fattibile. Durante le esercitazioni del team viola, l'attenzione è rivolta principalmente ai meccanismi di rilevamento, agli strumenti e alle procedure operative standard (SOP) a supporto della risposta agli incidenti. 
+  **Esercizi del team rosso:** durante un'esercitazione con il team rosso, l'attacco (team rosso) effettua una simulazione per raggiungere un determinato obiettivo o una serie di obiettivi da un ambito predeterminato. I difensori (team blu) non saranno necessariamente a conoscenza della portata e della durata dell'esercitazione, il che fornisce una valutazione più realistica di come risponderebbero a un incidente reale. Poiché le esercitazioni del team rosso possono basarsi su test invasivi, sii cauto e implementa controlli per verificare che l'esercitazione non causi danni effettivi all'ambiente. 

 Prendi in considerazione la possibilità di svolgere simulazioni informatiche a intervalli regolari. Ogni tipo di esercitazione può offrire vantaggi unici ai partecipanti e all'organizzazione nel suo insieme; potresti, quindi, scegliere di iniziare con tipi di simulazione meno complessi (come le simulazioni di situazioni di emergenza) e passare a tipi di simulazione più complessi (esercitazioni del team rosso). È necessario selezionare un tipo di simulazione in base alla maturità, alle risorse e ai risultati desiderati a livello di sicurezza. Alcuni clienti potrebbero scegliere di non eseguire le esercitazioni del team rosso a causa della loro complessità e dei loro costi. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Indipendentemente dal tipo di simulazione scelto, le simulazioni sono in genere caratterizzate dai seguenti passaggi di implementazione: 

1.  **Definisci gli elementi principali dell'esercizio:** definisci lo scenario di simulazione e gli obiettivi della simulazione. Lo scenario e gli obiettivi dovrebbero essere entrambi accettati dalla leadership. 

1.  **Identifica le principali parti interessate:** come minimo, un esercizio richiede la presenza di facilitatori e partecipanti. A seconda dello scenario, potrebbero essere coinvolte altre parti interessate come la leadership legale, delle comunicazioni o esecutiva. 

1.  **Crea ed esegui il test dello scenario:** potrebbe essere necessario ridefinire lo scenario durante la creazione se risulta impossibile implementare elementi specifici. Come risultato di questa fase è previsto uno scenario definitivo. 

1.  **Facilita la simulazione:** il tipo di simulazione determina il tipo di svolgimento usato (uno scenario basato su supporto cartaceo o uno scenario con simulazione altamente tecnologica). I coordinatori dovrebbero allineare le loro tattiche di svolgimento agli oggetti dell'esercitazione e dovrebbero coinvolgere tutti i partecipanti ove possibile per ottimizzare i benefici. 

1.  **Sviluppa il report post-azione (AAR):** individua le aree che sono andate bene, quelle che possono essere migliorate e le potenziali lacune. Il report AAR dovrebbe misurare l'efficacia della simulazione e la risposta del team all'evento simulato in modo che i progressi possano essere monitorati nel tempo con simulazioni future. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [AWS Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **Video correlati:** 
+ [AWS GameDay - Security Edition](https://www.youtube.com/watch?v=XnfDWID_OQs)

# SEC10-BP08 Definizione di un framework per apprendere dagli incidenti
<a name="sec_incident_response_establish_incident_framework"></a>

 L'implementazione di un *framework basato sulle lezioni apprese* e di una capacità di analisi delle cause principali non solo contribuisce a migliorare le capacità di risposta agli incidenti, ma aiuta anche a prevenire il ripetersi dell'incidente. Imparando da ogni incidente, puoi evitare di ripetere gli errori, i rischi o le configurazioni non valide, non solo migliorando il tuo livello di sicurezza, ma anche riducendo al minimo il tempo speso in situazioni evitabili. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 È importante implementare un *framework basato sulle lezioni apprese* che stabilisce e raggiunge, ad alto livello, i seguenti punti: 
+  Quando si tiene un framework basato sulle lezioni apprese? 
+  Cosa comporta il processo basato sulle lezioni apprese? 
+  Come viene eseguito un framework basato sulle lezioni apprese? 
+  Chi è coinvolto nel processo e in che modo? 
+  Come vengono identificate le aree di miglioramento? 
+  In che modo garantisci che i miglioramenti vengano monitorati e implementati in modo efficace? 

 Il framework non deve concentrarsi sugli individui, ma sul miglioramento di strumenti e processi. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 A parte i risultati di alto livello sopra elencati, è importante porsi le domande giuste per trarre il massimo valore (informazioni che portano a miglioramenti attuabili) dal processo. Considera queste domande per iniziare a promuovere le discussioni sulle lezioni apprese: 
+  Qual è stato l'incidente? 
+  Quando è stato identificato per la prima volta l'incidente? 
+  Come è stato identificato? 
+  Quali sistemi hanno avvisato dell'attività? 
+  Quali sistemi, servizi e dati sono stati coinvolti? 
+  Cosa è successo nello specifico? 
+  Cosa ha funzionato bene? 
+  Cosa non ha funzionato bene? 
+  Quale processo o quali procedure non sono riusciti a dimensionare per rispondere all'incidente? 
+  Cosa può essere migliorato nelle seguenti aree: 
  +  **Persone** 
    +  Le persone da contattare erano effettivamente disponibili e l'elenco dei contatti era aggiornato? 
    +  Il personale presentava lacune nella formazione o nelle capacità necessarie per rispondere e indagare efficacemente sull'incidente? 
    +  Le risorse appropriate erano pronte e disponibili? 
  +  **Elaborazione** 
    +  Sono stati seguiti i processi e le procedure? 
    +  I processi e le procedure erano documentati e disponibili per questo tipo di incidente? 
    +  Mancavano i processi e le procedure richiesti? 
    +  Il team di risposta è stato in grado di accedere tempestivamente alle informazioni necessarie per rispondere al problema? 
  +  **Tecnologia** 
    +  I sistemi di avviso esistenti hanno identificato e segnalato efficacemente l'attività? 
    +  Come si sarebbe potuto ridurre il tempo di rilevamento del 50%? 
    +  Gli avvisi esistenti devono essere migliorati o è necessario creare nuovi avvisi per questo tipo di incidente? 
    +  Gli strumenti esistenti hanno consentito un'indagine efficace (ricerca/analisi) dell'incidente? 
    +  Cosa si può fare per identificare prima questo tipo di incidente? 
    +  Cosa si può fare per evitare che questo tipo di incidente si ripeta? 
    +  A chi appartiene il piano di miglioramento e come verifichi che sia stato implementato? 
    +  Qual è la tempistica per l'implementazione e il test del monitoraggio aggiuntivo o dei controlli e dei processi preventivi? 

 Questo elenco non è esaustivo, ma può fungere da punto di partenza per individuare quali sono le esigenze dell'organizzazione e dell'attività e come analizzarle per imparare in modo più efficace dagli incidenti e migliorare costantemente il proprio livello di sicurezza. La cosa più importante è iniziare incorporando le lezioni apprese come parte standard del processo di risposta agli incidenti, della documentazione e delle aspettative di tutti gli stakeholder. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Security Incident Response Guide - Establish a framework for learning from incidents](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/establish-framework-for-learning.html) 
+  [NCSC CAF guidance - Lessons learned](https://www.ncsc.gov.uk/collection/caf/caf-principles-and-guidance/d-2-lessons-learned) 

# Sicurezza delle applicazioni
<a name="a-appsec"></a>

**Topics**
+ [SEC 11. Come si incorporano e convalidano le proprietà di sicurezza delle applicazioni nell'intero ciclo di vita di progettazione, sviluppo e implementazione?](sec-11.md)

# SEC 11. Come si incorporano e convalidano le proprietà di sicurezza delle applicazioni nell'intero ciclo di vita di progettazione, sviluppo e implementazione?
<a name="sec-11"></a>

La formazione del personale, l'esecuzione di test tramite automazione, l'identificazione delle dipendenze e la convalida delle proprietà di sicurezza di strumenti e applicazioni riducono la probabilità del verificarsi di problemi di sicurezza nei carichi di lavoro di produzione.

**Topics**
+ [SEC11-BP01 Formazione per la sicurezza delle applicazioni](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md)
+ [SEC11-BP03 Esecuzione di test di penetrazione (pen-test) a intervalli regolari](sec_appsec_perform_regular_penetration_testing.md)
+ [SEC11-BP04 Revisioni manuali del codice](sec_appsec_manual_code_reviews.md)
+ [SEC11-BP05 Centralizzazione dei servizi per pacchetti e dipendenze](sec_appsec_centralize_services_for_packages_and_dependencies.md)
+ [SEC11-BP06 Implementazione programmatica del software](sec_appsec_deploy_software_programmatically.md)
+ [SEC11-BP07 Valutazione regolare delle proprietà di sicurezza delle pipeline](sec_appsec_regularly_assess_security_properties_of_pipelines.md)
+ [SEC11-BP08 Creazione di un programma per l'integrazione della titolarità della sicurezza nei team responsabili del carico di lavoro](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md)

# SEC11-BP01 Formazione per la sicurezza delle applicazioni
<a name="sec_appsec_train_for_application_security"></a>

 Fornisci formazione sulle procedure comuni agli sviluppatori nell'organizzazione in modo da garantire la sicurezza dello sviluppo e del funzionamento delle applicazioni. L'adozione di procedure di sviluppo incentrate sulla sicurezza riduce la probabilità di riscontrare problemi solo nella fase di revisione della sicurezza. 

**Risultato desiderato:** progettazione del software tenendo conto della sicurezza. Quando gli sviluppatori in un'organizzazione ricevono formazione su procedure di sviluppo sicure iniziando con un modello di rischio, la qualità e la sicurezza complessive del software prodotto sono migliori. Questo approccio può ridurre il tempo necessario per distribuire il software o le funzionalità, in quanto saranno necessarie meno correzioni dopo la fase di revisione della sicurezza. 

 Ai fini di questa best practice, il concetto di *sviluppo sicuro* si riferisce al software scritto e agli strumenti o ai sistemi che supportano il ciclo di vita di sviluppo del software. 

**Anti-pattern comuni:**
+  Valutazione delle proprietà di sicurezza di un sistema solo in fase di revisione della sicurezza. 
+  Assegnazione di tutte le decisioni in materia di sicurezza al team responsabile della sicurezza. 
+  Mancata comunicazione della correlazione tra le decisioni adottate durante il ciclo di vita di sviluppo del software e le aspettative o policy complessive dell'organizzazione. 
+  Svolgimento del processo di revisione della sicurezza in una fase troppo tardiva. 

**Vantaggi dell'adozione di questa best practice:**
+  Migliore identificazione dei requisiti aziendali per la sicurezza all'inizio del ciclo di sviluppo. 
+  Capacità di identificare e correggere più rapidamente possibili problemi di sicurezza, per una distribuzione più rapida delle funzionalità. 
+  Migliore qualità del software e dei sistemi. 

**Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Fornisci formazione agli sviluppatori nell'organizzazione. Un corso iniziale sulla [modellazione delle minacce](https://catalog.workshops.aws/threatmodel/en-US) è un'ottima base per la formazione sulla sicurezza. Idealmente, gli sviluppatori devono poter accedere in modalità self-service a informazioni pertinenti ai propri carichi di lavoro. Questo accesso può aiutarli a prendere decisioni informate sulle proprietà di sicurezza dei sistemi sviluppati senza dover chiedere a un altro team. Il processo di coinvolgimento del team responsabile della sicurezza nelle revisioni deve essere definito chiaramente e facile da seguire. Le fasi del processo di revisione devono essere incluse nella formazione sulla sicurezza. Quando sono disponibili modelli o schemi di implementazione noti, devono essere facili da trovare e collegare ai requisiti complessivi per la sicurezza. Valuta se usare [AWS CloudFormation,](https://aws.amazon.com/cloudformation/) [costrutti del AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html), il [Service Catalog](https://aws.amazon.com/servicecatalog/) o altri strumenti di creazione di modelli per ridurre la necessità di configurazioni personalizzate. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Per iniziare, presenta agli sviluppatori un corso sulla [modellazione delle minacce](https://catalog.workshops.aws/threatmodel/en-US) per creare ottime basi e abituarli a riflettere sulla sicurezza. 
+  Fornisci accesso a risorse di formazione [AWS Training and Certification](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult), per i diversi settori o per partner AWS. 
+  Fornisci formazione sul processo di revisione della sicurezza dell'organizzazione, che spieghi la suddivisione delle responsabilità tra il team responsabile della sicurezza, i team del carico di lavoro e altri stakeholder. 
+  Pubblica linee guida self-service su come soddisfare i requisiti di sicurezza, inclusi esempi e modelli di codice, se disponibili. 
+  Richiedi regolarmente ai team di sviluppo feedback sull'esperienza durante il processo di revisione della sicurezza e la formazione correlata e usalo per migliorare le procedure. 
+  Usa campagne di simulazione o bug bash per ridurre il numero di problemi e migliorare le competenze degli sviluppatori. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC11-BP08 Creazione di un programma per l'integrazione della titolarità della sicurezza nei team responsabili del carico di lavoro](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md) 

 **Documenti correlati:** 
+  [AWS Training and Certification](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult) 
+  [Come riflettere sulla governance della sicurezza nel cloud](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) 
+  [Come accostarsi alla modellazione delle minacce](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) 
+  [Accelerazione della formazione – AWS Skills Guild](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/accelerating-training-the-aws-skills-guild.html) 

 **Video correlati:** 
+  [Sicurezza proattiva: considerazioni e approcci](https://www.youtube.com/watch?v=CBrUE6Qwfag) 

 **Esempi correlati:** 
+  [Workshop sulla modellazione delle minacce](https://catalog.workshops.aws/threatmodel) 
+  [Industry awareness for developers](https://owasp.org/www-project-top-ten/) 

 **Servizi correlati:** 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
+  [Costrutti del AWS Cloud Development Kit (AWS CDK) (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html) 
+  [Service Catalog](https://aws.amazon.com/servicecatalog/) 
+  [AWS BugBust](https://docs.aws.amazon.com/codeguru/latest/bugbust-ug/what-is-aws-bugbust.html) 

# SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test
<a name="sec_appsec_automate_testing_throughout_lifecycle"></a>

 Automatizza i test per le proprietà di sicurezza lungo il ciclo di vita di sviluppo e test. L'automazione semplifica l'identificazione coerente e ripetibile dei potenziali problemi nel software prima del rilascio, riducendo il rischio di riscontrare problemi di sicurezza nel software fornito. 

**Risultato desiderato: **l'obiettivo dei test automatici è fornire un metodo programmatico per rilevare inizialmente e regolarmente i potenziali problemi lungo l'intero ciclo di vita di sviluppo. Automatizzando i test di regressione, puoi ripetere l'esecuzione di test funzionali e non funzionali per verificare che il software testato in precedenza continui ad avere le prestazioni previste dopo una modifica. Quando definisci unit test di sicurezza per verificare la presenza di configurazioni errate comuni, come autorizzazioni non corrette o mancanti, puoi identificare e correggere i problemi all'inizio del processo di sviluppo. 

 Per l'automazione dei test vengono usati test case dedicati per la convalida delle applicazioni, in base ai requisiti e alle funzionalità desiderate. Il risultato dei test automatici è basato sul confronto dell'output di test generato con quello previsto, che accelera l'intero ciclo di vita dei test. Metodologie di test come i test di regressione e le suite di unit test sono le più adatte per l'automazione. L'automazione dei test delle proprietà di sicurezza permette agli sviluppatori di ricevere automaticamente feedback senza attendere una revisione della sicurezza. I test automatici sotto forma di analisi statica o dinamica del codice possono migliorare la qualità del codice e semplificare il rilevamento dei potenziali problemi software all'inizio del ciclo di vita di sviluppo. 

**Anti-pattern comuni:**
+  Mancata comunicazione dei test case e dei risultati dei test automatici. 
+  Esecuzione dei test solo immediatamente prima di un rilascio. 
+  Automazione dei test case con requisiti che cambiano spesso. 
+  Assenza di linee guida su come gestire i risultati dei test di sicurezza. 

**Vantaggi dell'adozione di questa best practice:**
+  Riduzione della dipendenza da valutazioni personali delle proprietà di sicurezza dei sistemi. 
+  Migliore coerenza grazie a risultati uniformi tra più flussi di lavoro. 
+  Minore probabilità di introdurre problemi di sicurezza nel software di produzione. 
+  Intervallo di tempo più breve tra il rilevamento e la correzione grazie all'identificazione più tempestiva dei problemi software. 
+  Maggiore visibilità su comportamenti sistematici o ripetuti tra più flussi di lavoro, che può essere usata per favorire miglioramenti in tutta l'organizzazione. 

**Livello di rischio associato alla mancata adozione di questa best practice: **medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Durante lo sviluppo del software, adotta diversi meccanismi di test in modo da avere la certezza di testare l'applicazione per requisiti funzionali, basati sulla logica di business, e non funzionali, incentrati sull'affidabilità, sulle prestazioni e sulla sicurezza dell'applicazione. 

 I test di sicurezza statici dell'applicazione analizzano il codice sorgente in cerca di modelli di sicurezza anomali e forniscono indicazioni per un codice privo di errori. I test di sicurezza statici dell'applicazione si basano su input statici, come la documentazione (definizione dei requisiti, documentazione sulla progettazione e specifiche di progettazione) e il codice sorgente dell'applicazione, per testare un'ampia gamma di problemi di sicurezza noti. Gli analizzatori di codice statici possono contribuire ad accelerare l'analisi di volumi elevati di codice. Il [NIST Quality Group](https://www.nist.gov/itl/ssd/software-quality-group) offre un confronto tra gli [analizzatori della sicurezza del codice sorgente](https://www.nist.gov/itl/ssd/software-quality-group/source-code-security-analyzers), con strumenti open source per la [scansione del codice byte](https://samate.nist.gov/index.php/Byte_Code_Scanners.html) e la [scansione del codice binario](https://samate.nist.gov/index.php/Binary_Code_Scanners.html).

 Integra i test statici con metodologie di test della sicurezza tramite analisi dinamica, che eseguono test sull'applicazione in esecuzione per identificare potenziali comportamenti imprevisti. I test dinamici possono essere usati per individuare potenziali problemi non rilevabili tramite l'analisi statica. L'esecuzione di test nelle fasi di repository, compilazione e pipeline del codice permette di verificare potenziali problemi di tipi diversi, evitandone la presenza nel codice. [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) fornisce suggerimenti per il codice, tra cui analisi della sicurezza, nell'ambiente di sviluppo integrato (IDE) dello sviluppatore. Il [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) può identificare problemi critici e di sicurezza e bug difficili da individuare durante lo sviluppo delle applicazioni e fornisce suggerimenti per migliorare la qualità del codice. 

 Il [workshop sulla sicurezza per gli sviluppatori](https://catalog.workshops.aws/sec4devs) usa strumenti di sviluppo AWS come [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodeCommit](https://aws.amazon.com/codecommit/) e[AWS CodePipeline](https://aws.amazon.com/codepipeline/) per l'automazione della pipeline di rilascio, che include metodologie di test tramite analisi statiche e dinamiche. 

 Lungo il ciclo di vita di sviluppo del software definisci un processo iterativo che includa revisioni periodiche dell'applicazione con il team responsabile della sicurezza. Il feedback raccolto da queste revisioni della sicurezza deve essere affrontato e convalidato come parte della revisione dell'idoneità per il rilascio. Queste revisioni permettono di stabilire una solida posizione di sicurezza per l'applicazione e forniscono agli sviluppatori feedback di utilità pratica per affrontare i potenziali problemi. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Implementa un ambiente IDE, una revisione del codice e strumenti CI/CD coerenti che includano test di sicurezza. 
+  Determina le fasi del ciclo di vita di sviluppo del software in cui è appropriato bloccare le pipeline anziché informare semplicemente gli sviluppatori riguardo alla necessità di risolvere i problemi. 
+  Il [workshop sulla sicurezza per gli sviluppatori](https://catalog.workshops.aws/sec4devs) fornisce un esempio di integrazione di test statici e dinamici in una pipeline di rilascio. 
+  L'esecuzione di test o di analisi del codice tramite strumenti automatici, come [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) integrato con gli ambienti IDE degli sviluppatori e il [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) per l'analisi del codice in fase di commit, permette agli sviluppatori di ottenere feedback tempestivo. 
+  Se sviluppi soluzioni usando AWS Lambda, puoi usare [Amazon Inspector](https://aws.amazon.com/about-aws/whats-new/2023/02/code-scans-lambda-functions-amazon-inspector-preview/) per analizzare il codice dell'applicazione nelle funzioni. 
+  Il [workshop sull'integrazione continua e sulla distribuzione continua in AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) fornisce un punto di partenza per la creazione di pipeline CI/CD in AWS. 
+  Quando le pipeline CI/CD includono test automatici, devi usare un sistema di gestione dei ticket per tenere traccia della notifica e della correzione dei problemi software. 
+  Per test di sicurezza che possono generare risultati, il collegamento a linee guida per la correzione permette agli sviluppatori di migliorare la qualità del codice. 
+  Analizza regolarmente i risultati ottenuti dagli strumenti automatici per definire le priorità delle successive iniziative di automazione, formazione degli sviluppatori o creazione di campagne di sensibilizzazione. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Distribuzione e implementazione continue](https://aws.amazon.com/devops/continuous-delivery/) 
+  [Partner con competenze in AWS DevOps](https://aws.amazon.com/devops/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=partner-type%23technology&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-location=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&awsm.page-partner-solutions-cards=1) 
+  [Partner con competenze nella sicurezza AWS](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=use-case%23app-security&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc) per la sicurezza delle applicazioni 
+  [Scelta di un approccio CI/CD Well-Architected](https://aws.amazon.com/blogs/devops/choosing-well-architected-ci-cd-open-source-software-aws-services/) 
+  [Monitoraggio di eventi CodeCommit in Amazon EventBridge e Amazon CloudWatch Events](https://docs.aws.amazon.com/codecommit/latest/userguide/monitoring-events.html) 
+  [Rilevamento dei segreti nel revisore Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/recommendations.html#secrets-detection) 
+  [Accelerazione delle implementazioni su AWS con una governance efficace](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Approccio di AWS all'automazione di implementazioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 

 **Video correlati:**
+  [Informazioni pratiche: automazione di pipeline di distribuzione continua in Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) 
+  [Automazione di pipeline CI/CD tra account](https://www.youtube.com/watch?v=AF-pSRSGNks) 

 **Esempi correlati:**
+  [Industry awareness for developers](https://owasp.org/www-project-top-ten/) 
+  [AWS CodePipeline Governance](https://github.com/awslabs/aws-codepipeline-governance) (GitHub) 
+  [Workshop sulla sicurezza per gli sviluppatori](https://catalog.us-east-1.prod.workshops.aws/workshops/66275888-6bab-4872-8c6e-ed2fe132a362/en-US) 
+  [Workshop sull'integrazione continua e sulla distribuzione continua in AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) 

# SEC11-BP03 Esecuzione di test di penetrazione (pen-test) a intervalli regolari
<a name="sec_appsec_perform_regular_penetration_testing"></a>

Esegui regolarmente test di penetrazione (pen-test) sul software. Questo meccanismo permette di identificare i potenziali problemi che non possono essere rilevati tramite test automatici o la revisione manuale del codice. Può anche aiutarti a determinare l'efficacia dei controlli di rilevamento. I test di penetrazione (pen-test) devono determinare se il software può funzionare in modi imprevisti, ad esempio esponendo dati che devono essere protetti o concedendo autorizzazioni più elevate del previsto.

 

**Risultato desiderato:** uso di test di penetrazione (pen-test) per rilevare, correggere e convalidare le proprietà di sicurezza dell'applicazione. È necessario eseguire test di penetrazione (pen-test) regolari e pianificati come parte del ciclo di vita di sviluppo del software. I risultati ottenuti dai test di penetrazione (pen-test) devono essere affrontati prima del rilascio del software. Devi analizzare i risultati dei test di penetrazione (pen-test) per identificare se vi siano problemi che possono essere identificati con l'automazione. Un processo di esecuzione di test di penetrazione (pen-test) regolare e ripetibile che includa un meccanismo di feedback attivo aiuta a stabilire linee guida per gli sviluppatori e migliora la qualità del software. 

**Anti-pattern comuni:**
+  Esecuzione di test di penetrazione (pen-test) solo per problemi di sicurezza noti o comuni. 
+  Esecuzione di test di penetrazione (pen-test) delle applicazioni senza gli strumenti e le librerie di terze parti dipendenti. 
+  Esecuzione di test di penetrazione (pen-test) solo per i problemi di sicurezza relativi ai pacchetti, senza valutare la logica di business implementata. 

**Vantaggi dell'adozione di questa best practice:**
+  Maggiore certezza riguardo alle proprietà di sicurezza del software prima del rilascio. 
+  Opportunità di identificare i modelli comportamentali preferiti delle applicazioni, per una migliore qualità del software. 
+  Presenza di un ciclo di feedback che identifica all'inizio del ciclo di sviluppo i punti in cui l'automazione o una formazione aggiuntiva possono migliorare le proprietà di sicurezza del software. 

**Livello di rischio associato alla mancata adozione di questa best practice: ** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I test di penetrazione (pen-test) sono un esercizio strutturato per l'esecuzione di test di sicurezza in cui vengono eseguiti scenari di violazione della sicurezza pianificati per rilevare, correggere e convalidare i controlli di sicurezza. I test di penetrazione (pen-test) iniziano dalla ricognizione, durante la quale vengono raccolti dati in base all'attuale progettazione dell'applicazione e alle sue dipendenze. Viene creato ed eseguito un elenco selezionato di scenari di test specifici per la sicurezza. Lo scopo principale di questi test è rivelare i problemi di sicurezza nell'applicazione che potrebbero essere sfruttati per ottenere accesso accidentale all'ambiente o accesso non autorizzato ai dati. Devi eseguire test di penetrazione (pen-test) quando avvii nuove funzionalità o ogni volta che l'applicazione viene sottoposta a modifiche importanti durante l'implementazione tecnica o di funzioni. 

 Devi identificare la fase più appropriata del ciclo di vita di sviluppo in cui eseguire i test di penetrazione (pen-test). Questi test devono essere eseguiti nelle fasi finali, in modo che la funzionalità del sistema sia vicina allo stato di rilascio previsto, ma con tempo sufficiente per la correzione di eventuali problemi. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Prepara un processo strutturato per definire l'ambito dei test di penetrazione (pen-test). Un ottimo metodo per mantenere il contesto consiste nel basare questo processo sul [modello di rischio](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/). 
+  Identifica la fase più appropriata del ciclo di vita di sviluppo in cui eseguire test di penetrazione (pen-test). Questi devono avvenire quando sono previste modifiche minime nell'applicazione, ma quando vi è ancora tempo sufficiente per apportare eventuali correzioni. 
+  Prepara gli sviluppatori su cosa aspettarsi dai risultati dei test di penetrazione (pen-test) e su come ottenere informazioni sulla correzione. 
+  Usa strumenti per accelerare il processo di esecuzione dei test di penetrazione (pen-test) automatizzando test comuni o ripetibili. 
+  Analizza i risultati dei test di penetrazione (pen-test) per identificare problemi di sicurezza sistematici e usa questi dati per definire altri test automatici e formazione continua per gli sviluppatori. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC11-BP01 Formazione per la sicurezza delle applicazioni](sec_appsec_train_for_application_security.md) 
+ [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md)

 **Documenti correlati:** 
+  La pagina [Test di penetrazione (pen-test) AWS](https://aws.amazon.com/security/penetration-testing/) fornisce linee guida dettagliate per l'esecuzione di test di penetrazione (pen-test) in AWS 
+  [Accelerazione delle implementazioni su AWS con una governance efficace](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Partner con competenze nella sicurezza AWS](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc) 
+  [Modernizzazione dell'architettura dei test di penetrazione (pen-test) su AWS Fargate](https://aws.amazon.com/blogs/architecture/modernize-your-penetration-testing-architecture-on-aws-fargate/) 
+  [Simulatore di iniezione guasti AWS](https://aws.amazon.com/fis/) 

 **Esempi correlati:** 
+  [Automate API testing with AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-codebuild-with-postman) (GitHub) 
+  [Automated security helper](https://github.com/aws-samples/automated-security-helper) (GitHub) 

# SEC11-BP04 Revisioni manuali del codice
<a name="sec_appsec_manual_code_reviews"></a>

Esegui una revisione manuale del codice del software che produci. Attraverso questo processo puoi assicurarti che chi ha scritto il codice non sia l'unica persona a controllarne la qualità.

**Risultato desiderato:** l'aggiunta di una fase di revisione manuale del codice durante lo sviluppo migliora la qualità del software scritto, permette di affinare le competenze dei membri meno esperti del team e fornisce un'opportunità per identificare i punti in cui può essere usata l'automazione. Le revisioni manuali del codice possono essere supportate da strumenti e test automatici. 

**Anti-pattern comuni:**
+  Non viene eseguita alcuna revisione del codice prima dell'implementazione. 
+  La scrittura e la revisione del codice vengono effettuate dalla stessa persona. 
+  Non viene usata l'automazione per semplificare o orchestrare le revisioni del codice. 
+  Gli sviluppatori non ricevono formazione sulla sicurezza dell'applicazione prima di eseguire la revisione del codice. 

**Vantaggi dell'adozione di questa best practice:**
+  Migliore qualità del codice. 
+  Maggiore coerenza dello sviluppo del codice attraverso il riutilizzo di approcci comuni. 
+  Riduzione del numero di problemi riscontrati durante i test di penetrazione e nelle fasi successive. 
+  Migliore circolazione delle informazioni all'interno del team. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 La fase di revisione deve essere implementata come parte del flusso complessivo di gestione del codice. Le specifiche dipendono dall'approccio usato per la diramazione, le richieste pull e l'unione. Puoi usare AWS CodeCommit o soluzioni di terze parti come GitHub, GitLab o Bitbucket. Qualunque sia il metodo usato, è importante verificare che i processi richiedano la revisione del codice prima che venga implementato in un ambiente di produzione. L'uso di strumenti come il [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) può semplificare l'orchestrazione del processo di revisione del codice. 

### Passaggi dell'implementazione
<a name="implementation-steps-required-field"></a>
+  Implementa una fase di revisione manuale come parte del flusso di gestione del codice ed esegui la revisione prima di continuare. 
+  Prendi in considerazione il [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) per la gestione e la semplificazione delle revisioni del codice. 
+  Implementa un flusso di approvazione che richieda il completamento di una revisione prima che il codice possa passare alla fase successiva. 
+  Verifica che sia stato definito un processo per identificare i problemi riscontrati durante le revisioni manuali del codice che potrebbero essere rilevati automaticamente. 
+  Integra la fase di revisione manuale del codice in modo che sia allineata alla procedure di sviluppo del codice. 

## Risorse
<a name="resources-required-field"></a>

 **Best practice correlate:**
+  [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documenti correlati:**
+  [Uso di richieste pull in repository AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/pull-requests.html) 
+  [Uso di modelli per le regole di approvazione in AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/approval-rule-templates.html) 
+  [GitHub: About pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) 
+  [Automazione delle revisioni del codice con il Amazon CodeGuru Reviewer ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/) 
+  [Automazione del rilevamento di bug e vulnerabilità della sicurezza in pipeline CI/CD usando l'interfaccia della riga di comando del Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automating-detection-of-security-vulnerabilities-and-bugs-in-ci-cd-pipelines-using-amazon-codeguru-reviewer-cli/) 

 **Video correlati:**
+  [Miglioramento continuo della qualità del codice con Amazon CodeGuru](https://www.youtube.com/watch?v=iX1i35H1OVw) 

 **Esempi correlati:** 
+  [Workshop sulla sicurezza per gli sviluppatori](https://catalog.workshops.aws/sec4devs) 

# SEC11-BP05 Centralizzazione dei servizi per pacchetti e dipendenze
<a name="sec_appsec_centralize_services_for_packages_and_dependencies"></a>

Fornisci servizi centralizzati per permettere ai team di sviluppo di ottenere pacchetti software e altre dipendenze. Questo approccio permette la convalida dei pacchetti prima di includerli nel software scritto e fornisce un'origine dati per l'analisi del software usato nell'organizzazione.

**Risultato desiderato:** il software include una serie di altri pacchetti software oltre al codice scritto. In questo modo, è più facile utilizzare implementazioni di funzionalità usate ripetutamente, come un parser JSON o una libreria di crittografia. La centralizzazione logica delle origini per questi pacchetti e dipendenze fornisce un meccanismo tramite il quale i team responsabili della sicurezza possono convalidare le proprietà dei pacchetti prima che vengano usati. Questo approccio riduce anche il rischio di un problema imprevisto causato da una modifica in un pacchetto esistente o dall'aggiunta da parte dei team di sviluppo di pacchetti arbitrari direttamente da Internet. Usa questo approccio insieme ai flussi di test manuali e automatici per garantire ulteriormente la qualità del software sviluppato. 

**Anti-pattern comuni:**
+  Recupero di pacchetti da repository arbitrari su Internet. 
+  Mancata esecuzione di test sui nuovi pacchetti prima di renderli disponibili agli sviluppatori. 

**Vantaggi dell'adozione di questa best practice:**
+  Migliore comprensione dei pacchetti usati nel software sviluppato. 
+  Capacità di informare i team responsabili del carico di lavoro quando un pacchetto deve essere aggiornato in base alle informazioni su chi usa cosa. 
+  Minor rischio di includere nel software un pacchetto con problemi. 

 **Livello di rischio associato alla mancata adozione di questa best practice: **medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Fornisci servizi centralizzati per i pacchetti e le dipendenze in modo da semplificarne l'uso per gli sviluppatori. La centralizzazione dei servizi può essere eseguita in modo logico anziché implementarli come sistema monolitico. Questo approccio permette di fornire servizi in modo da soddisfare le esigenze degli sviluppatori. Ti consigliamo di implementare un metodo efficiente per aggiungere pacchetti al repository quando sono necessari aggiornamenti o emergono nuovi requisiti. Servizi AWS come [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) o soluzioni simili di partner AWS forniscono alcuni strumenti utili per questo scopo. 

### Passaggi dell'implementazione:
<a name="implementation-steps"></a>
+ Implementa un servizio di repository centralizzato in modo logico che sia disponibile in tutti gli ambienti in cui viene sviluppato il software. 
+ Includi l'accesso al repository come parte del processo di provisioning automatico dell'Account AWS.
+ Crea automazione per testare i pacchetti prima che vengano pubblicati in un repository.
+ Gestisci le metriche dei pacchetti, dei linguaggi e dei team usati più comunemente e con la maggiore quantità di modifiche.
+  Offri ai team di sviluppo un meccanismo automatico per richiedere nuovi pacchetti e fornire feedback. 
+  Analizza regolarmente i pacchetti nel repository per identificare il possibile impatto di nuovi problemi riscontrati. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documenti correlati:** 
+  [Accelerazione delle implementazioni su AWS con una governance efficace](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Potenziamento della sicurezza dei pacchetti con il toolkit per il controllo delle origini dei pacchetti CodeArtifact](https://aws.amazon.com/blogs/devops/tighten-your-package-security-with-codeartifact-package-origin-control-toolkit/) 
+  [Rilevamento dei problemi di sicurezza nella registrazione con il Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/detecting-security-issues-in-logging-with-amazon-codeguru-reviewer/) 
+  [Supply chain Levels for Software Artifacts (SLSA)](https://slsa.dev/) 

 **Video correlati:** 
+  [Sicurezza proattiva: considerazioni e approcci](https://www.youtube.com/watch?v=CBrUE6Qwfag) 
+  [La filosofia di AWS per la sicurezza (re:Invent 2017)](https://www.youtube.com/watch?v=KJiCfPXOW-U) 
+  [Quando sicurezza, protezione e urgenza sono tutte importanti: gestione di Log4Shell](https://www.youtube.com/watch?v=pkPkm7W6rGg) 

 **Esempi correlati:** 
+  [Multi Region Package Publishing Pipeline](https://github.com/aws-samples/multi-region-python-package-publishing-pipeline) (GitHub) 
+  [Publishing Node.js Modules on AWS CodeArtifact using AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-publish-nodejs-modules) (GitHub) 
+  [AWS CDK Java CodeArtifact Pipeline Sample](https://github.com/aws-samples/aws-cdk-codeartifact-pipeline-sample) (GitHub) 
+  [Distribute private .NET NuGet packages with AWS CodeArtifact](https://github.com/aws-samples/aws-codeartifact-nuget-dotnet-pipelines) (GitHub) 

# SEC11-BP06 Implementazione programmatica del software
<a name="sec_appsec_deploy_software_programmatically"></a>

Esegui implementazioni programmatiche del software laddove possibile. Questo approccio riduce la probabilità che un'implementazione non riesca o che si verifichi un problema imprevisto a causa dell'errore umano.

**Risultato desiderato: **un intervento minimo sui dati da parte delle persone è un principio chiave dello sviluppo sicuro nel Cloud AWS. Questo principio include anche il modo in cui viene implementato il software. 

 I vantaggi legati alla scelta di non affidare a persone l'implementazione del software è la migliore garanzia che la soluzione implementata sia esattamente identica a quella testata e che l'implementazione verrà eseguita in modo coerente ogni volta. Il software non deve essere modificato in modo da funzionare in ambienti diversi. Usando i principi dello sviluppo di applicazioni a dodici fattori, in particolare l'esternalizzazione della configurazione, puoi implementare lo stesso codice in più ambienti senza richiedere modifiche. La firma crittografica dei pacchetti software è un ottimo metodo per verificare che non vengano apportate modifiche tra ambienti. Il risultato complessivo di questo approccio è la riduzione dei rischi nel processo di modifica e il miglioramento della coerenza delle versioni del software. 

**Anti-pattern comuni:**
+  Implementazione manuale del software nell'ambiente di produzione. 
+  Applicazione manuale di modifiche al software per soddisfare i requisiti di ambienti diversi. 

**Vantaggi dell'adozione di questa best practice:**
+  Maggiore affidabilità del processo di rilascio del software. 
+  Riduzione dei rischi legati a modifiche errate che hanno impatto sulla funzionalità aziendale. 
+  Processi di rilascio più frequenti grazie a un rischio di modifica minimo. 
+  Funzionalità di ripristino automatico dello stato precedente in caso di eventi imprevisti durante l'implementazione. 
+  Possibilità di usare la crittografia per dimostrare che il software implementato è esattamente identico a quello testato. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Crea la struttura di Account AWS per eliminare l'accesso umano frequente dagli ambienti e usa strumenti CI/CD per eseguire le implementazioni. Progetta le applicazioni in modo da ottenere i dati di configurazione specifici dell'ambiente da un'origine esterna, ad esempio l'[Archivio dei parametri AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). Firma i pacchetti dopo che vengono testati e convalida le firme durante l'implementazione. Configura le pipeline CI/CD per il push del codice delle applicazioni e usa valori Canary per confermare la corretta esecuzione dell'implementazione. Usa strumenti come [AWS CloudFormation](https://aws.amazon.com/cloudformation/) o il [AWS CDK](https://aws.amazon.com/cdk/) per definire l'infrastruttura, quindi [AWS CodeBuild](https://aws.amazon.com/codebuild/) e [AWS CodePipeline](https://aws.amazon.com/codepipeline/) per eseguire operazioni CI/CD. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Crea pipeline CI/CD ben definite per semplificare il processo di implementazione. 
+  L'uso di [AWS CodeBuild](https://aws.amazon.com/codebuild/) e [AWS Code Pipeline](https://aws.amazon.com/codepipeline/) per fornire funzionalità CI/CD semplifica l'integrazione di test di sicurezza nelle pipeline. 
+  Segui le linee guida sulla separazione degli ambienti nel whitepaper sull'[organizzazione dell'ambiente AWS usando più account](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html). 
+  Verifica che non si verifichi accesso umano frequente agli ambienti in cui sono in esecuzione carichi di lavoro di produzione. 
+  Progetta le applicazioni in modo che supportino l'esternalizzazione dei dati di configurazione. 
+  Valuta se eseguire l'implementazione usando un modello di implementazione blu/verde. 
+  Implementa valori Canary per convalidare la corretta implementazione del software. 
+  Usa strumenti di crittografia come [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) o [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) per firmare e verificare i pacchetti software implementati. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documenti correlati:** 
+  [Workshop sull'integrazione continua e sulla distribuzione continua in AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) 
+  [Accelerazione delle implementazioni su AWS con una governance efficace](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) 
+  [Automazione di implementazioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 
+  [Firma del codice usando l'Autorità privata per la gestione del certificato AWS (ACM CA privata/ACM PCA) e chiavi asimmetriche AWS Key Management Service](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/) 
+  [Firma del codice, un controllo di attendibilità e integrità per AWS Lambda](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/) 

 **Video correlati:** 
+  [Informazioni pratiche: automazione di pipeline di distribuzione continua in Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) 

 **Esempi correlati:** 
+  [Implementazioni blu/verde con AWS Fargate](https://catalog.us-east-1.prod.workshops.aws/workshops/954a35ee-c878-4c22-93ce-b30b25918d89/en-US) 

# SEC11-BP07 Valutazione regolare delle proprietà di sicurezza delle pipeline
<a name="sec_appsec_regularly_assess_security_properties_of_pipelines"></a>

 Applica i principi della sicurezza Well-Architected alle pipeline, con particolare attenzione alla separazione delle autorizzazioni. Valuta regolarmente le proprietà di sicurezza dell'infrastruttura di pipeline. Una gestione efficace della sicurezza *delle* pipeline assicura la protezione del software che passa *attraverso* le pipeline. 

**Risultato desiderato: **le pipeline usate per sviluppare e implementare il software devono seguire le stesse procedure consigliate di qualsiasi altro carico di lavoro nell'ambiente. I test implementati nelle pipeline non devono essere modificabili dagli sviluppatori che li usano. Le pipeline devono avere solo le autorizzazioni necessarie per le implementazioni eseguite e devono applicare misure di protezione per evitare l'implementazione negli ambienti errati. Le pipeline non devono basarsi su credenziali a lungo termine e devono essere configurate in modo da emettere lo stato, per permettere la convalida dell'integrità degli ambienti di sviluppo. 

**Anti-pattern comuni:**
+  Test di sicurezza che possono essere ignorati dagli sviluppatori. 
+  Autorizzazioni eccessivamente elevate per le pipeline di implementazione. 
+  Pipeline non configurate per la convalida degli input. 
+  Nessuna revisione periodica delle autorizzazioni associate all'infrastruttura CI/CD. 
+  Uso di credenziali a lungo termine o hardcoded. 

**Vantaggi dell'adozione di questa best practice:**
+  Maggiore garanzia di integrità del software sviluppato e implementato attraverso le pipeline. 
+  Possibilità di arrestare un'implementazione in caso di attività sospetta. 

**Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Iniziando con servizi CI/CD gestiti che supportano ruoli IAM, puoi ridurre il rischio di perdita di credenziali. L'applicazione dei principi della sicurezza all'infrastruttura di pipeline CI/CD può aiutarti a determinare i punti in cui apportare miglioramenti per la sicurezza. Un ottimo punto di partenza per la creazione degli ambienti CI/CD è l'[architettura di riferimento per le pipeline di implementazione AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/). La revisione periodica dell'implementazione delle pipeline e l'analisi dei log per identificare comportamenti imprevisti può semplificare la comprensione dei modelli di utilizzo delle pipeline usate per implementare il software. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Inizia dall'[architettura di riferimento per le pipeline di implementazione AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/). 
+  Valuta se usare il [AWS IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/what-is-access-analyzer.html) per generare in modo programmatico policy IAM con privilegi minimi per le pipeline. 
+  Integra le pipeline con monitoraggio e generazione di avvisi in modo da ricevere notifiche in caso di attività imprevista o anomala, in quanto [Amazon EventBridge](https://aws.amazon.com/eventbridge/) per servizi gestiti AWS permette di instradare dati a destinazioni come [AWS Lambda](https://aws.amazon.com/lambda/) o [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Architettura di riferimento per pipeline di implementazione AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/) 
+  [Monitoraggio di AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html) 
+  [Best practice per la sicurezza per AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html) 

 **Esempi correlati:** 
+  [DevOps monitoring dashboard](https://github.com/aws-solutions/aws-devops-monitoring-dashboard) (GitHub) 

# SEC11-BP08 Creazione di un programma per l'integrazione della titolarità della sicurezza nei team responsabili del carico di lavoro
<a name="sec_appsec_build_program_that_embeds_security_ownership_in_teams"></a>

Crea un programma o un meccanismo che permetta ai team di sviluppo di prendere decisioni sulla sicurezza del software che creano. Il team responsabile della sicurezza dovrà convalidare queste decisioni durante una revisione, ma l'integrazione della titolarità della sicurezza nei team di sviluppo permette di creare carichi di lavoro più veloci e sicuri. Questo meccanismo promuove anche una cultura della responsabilità che ha un impatto positivo sul funzionamento dei sistemi che crei.

 

**Risultato desiderato: **per integrare la titolarità della sicurezza e il processo decisionale nei team di sviluppo, puoi insegnare agli sviluppatori come riflettere sulla sicurezza o puoi migliorarne la formazione attraverso l'integrazione o l'associazione di responsabili della sicurezza nei team di sviluppo. Entrambi gli approcci sono validi e permettono al team di prendere decisioni di qualità migliore sulla sicurezza nelle fasi iniziali del ciclo di sviluppo. Questo modello di titolarità è basato sulla formazione per la sicurezza delle applicazioni. Iniziando dal modello di rischio per il carico di lavoro specifico, puoi concentrarti sul design thinking nel contesto appropriato. Un altro vantaggio della presenza di una comunità di sviluppatori attenti alla sicurezza o di un gruppo di tecnici della sicurezza che collabora con i team di sviluppo è la possibilità di comprendere a pieno il modo in cui è compilato il codice. Questa comprensione permette di determinare le aree di miglioramento successive per l'automazione. 

**Anti-pattern comuni:**
+  Assegnazione di tutte le decisioni in materia di sicurezza al team responsabile della sicurezza. 
+  Gestione dei requisiti di sicurezza in fasi tardive del processo di sviluppo. 
+  Assenza di feedback di sviluppatori e responsabili della sicurezza sul funzionamento del programma. 

**Vantaggi dell'adozione di questa best practice:**
+  Riduzione del tempo necessario per completare le revisioni della sicurezza. 
+  Riduzione dei problemi di sicurezza rilevati solo in fase di revisione della sicurezza. 
+  Miglioramento della qualità complessiva del software scritto. 
+  Opportunità di identificare e comprendere i problemi sistematici o le aree di miglioramento a valore elevato. 
+  Riduzione della quantità di attività di correzione dovute ai risultati delle revisioni della sicurezza. 
+  Migliore percezione della funzione della sicurezza. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per iniziare, segui le linee guida fornite in [SEC11-BP01 Formazione per la sicurezza delle applicazioni](sec_appsec_train_for_application_security.md). Identifica quindi il modello operativo per il programma che ritieni più efficace per l'organizzazione. I due modelli principali consistono nel formare gli sviluppatori o nell'integrare responsabili della sicurezza nei team di sviluppo. Una volta scelto l'approccio iniziale, devi eseguire un progetto pilota con un singolo team o un piccolo gruppo di team del carico di lavoro per dimostrare il funzionamento del modello per l'organizzazione. Il supporto autorevole da parte dello sviluppatore e di altre parti responsabili della sicurezza dell'organizzazione semplifica l'implementazione e il successo del programma. Durante la creazione del programma è importante scegliere metriche da usare per dimostrarne il valore. Per un'ottima esperienza formativa, puoi documentarti sul modo in cui AWS ha affrontato questo problema. Questa best practice è per lo più incentrata sulla trasformazione e sulla cultura aziendali. Gli strumenti usati devono supportare la collaborazione tra lo sviluppatore e le comunità responsabili della sicurezza. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Per iniziare, fornisci formazione sulla sicurezza delle applicazioni agli sviluppatori. 
+  Crea una comunità e un programma di onboarding per preparare gli sviluppatori. 
+  Scegli un nome per il programma. Alcuni termini comunemente usati sono Responsabilità, Supporto o Promozione. 
+  Identifica il modello da usare: formazione per gli sviluppatori, integrazione di tecnici della sicurezza o ruoli di sicurezza per affinità. 
+  Identifica alcuni sponsor del progetto tra responsabili della sicurezza, sviluppatori e altri gruppi potenzialmente rilevanti. 
+  Tieni traccia delle metriche per il numero di persone coinvolte nel programma, il tempo impiegato per le revisioni e il feedback ottenuto da sviluppatori e responsabili della sicurezza. Usa queste metriche per apportare miglioramenti. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [SEC11-BP01 Formazione per la sicurezza delle applicazioni](sec_appsec_train_for_application_security.md) 
+  [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md) 

 **Documenti correlati:** 
+  [Come accostarsi alla modellazione delle minacce](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) 
+  [Come riflettere sulla governance della sicurezza nel cloud](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) 

 **Video correlati:** 
+  [Sicurezza proattiva: considerazioni e approcci](https://www.youtube.com/watch?v=CBrUE6Qwfag) 

# Affidabilità
<a name="a-reliability"></a>

Il principio dell'affidabilità comprende la capacità di un carico di lavoro di eseguire la funzione attesa in modo corretto e coerente quando previsto. È possibile trovare linee guida prescrittive sull'implementazione nel [Whitepaper sul principio dell'affidabilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp).

**Topics**
+ [Fondamenti](a-foundations.md)
+ [Architettura del carico di lavoro](a-workload-architecture.md)
+ [Gestione delle modifiche](a-change-management.md)
+ [Gestione degli errori](a-failure-management.md)

# Fondamenti
<a name="a-foundations"></a>

**Topics**
+ [REL 1. Come si gestiscono quote e vincoli di servizio?](rel-01.md)
+ [REL 2. Come si pianifica la topologia di rete?](rel-02.md)

# REL 1. Come si gestiscono quote e vincoli di servizio?
<a name="rel-01"></a>

Per le architetture di carichi di lavoro basate sul cloud, esistono quote di servizio (definite anche come restrizioni dei servizi). Queste quote sono presenti per evitare di effettuare accidentalmente il provisioning di più risorse di quelle necessarie e limitare i tassi di richiesta sulle operazioni API in modo da proteggere i servizi da un uso illecito. Esistono anche vincoli di risorse, ad esempio la velocità con cui è possibile trasferire i bit su un cavo in fibra ottica o la quantità di storage su un disco fisico. 

**Topics**
+ [REL01-BP01 Consapevolezza su quote e vincoli di servizio](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 Gestione delle quote di servizio in più account e regioni](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 Adattamento di quote e vincoli di servizio fissi mediante l'architettura](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 Monitoraggio e gestione delle quote](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Automazione della gestione delle quote](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Creazione di un divario sufficiente tra le quote attuali e l'utilizzo massimo per consentire eventuali failover](rel_manage_service_limits_suff_buffer_limits.md)

# REL01-BP01 Consapevolezza su quote e vincoli di servizio
<a name="rel_manage_service_limits_aware_quotas_and_constraints"></a>

 Conosci le quote predefinite e gestisci le richieste di aumento delle quote per l'architettura del carico di lavoro. Sai quali vincoli delle risorse cloud, ad esempio disco o rete, sono potenzialmente influenti. 

 **Risultato desiderato:** i clienti possono evitare il degrado dei servizi o l'interruzione in Account AWS implementando linee guida appropriate per il monitoraggio di metriche chiave, revisioni dell'infrastruttura e fasi di correzione dell'automazione per verificare che non vengano raggiunte quote e vincoli dei servizi che potrebbero causare degrado o interruzione del servizio. 

 **Anti-pattern comuni:** 
+ Distribuzione di un carico di lavoro senza comprendere le quote hard o soft e i relativi limiti per i servizi utilizzati. 
+ Distribuzione di un carico di lavoro sostitutivo senza analizzare e riconfigurare le quote necessarie o contattare preventivamente l'assistenza. 
+ Supposizione che i servizi cloud non abbiano limiti e che i servizi possano essere utilizzati senza tener conto di tariffe, limiti, conteggi, quantità.
+  Supposizione che le quote verranno aumentate automaticamente. 
+  Mancata conoscenza del processo e della scadenza delle richieste di quote. 
+  Supposizione che la quota predefinita del servizio cloud sia identica per ogni servizio rispetto alle varie regioni. 
+  Supposizione che i vincoli del servizio possano essere violati e che i sistemi si autoscalino o aumentino il limite oltre i vincoli della risorsa 
+  Nessun test dell'applicazione nei momenti di picco del traffico, per stressare l'utilizzo delle sue risorse. 
+  Provisioning della risorsa senza analisi della dimensione della risorsa richiesta. 
+  Provisioning in eccesso di capacità scegliendo tipi di risorse che vanno ben oltre il fabbisogno effettivo o i picchi previsti. 
+  Nessuna valutazione dei requisiti di capacità per nuovi livelli di traffico prima di un nuovo evento cliente o dell'implementazione di una nuova tecnologia. 

 **Vantaggi derivanti dall'adozione di questa best practice:** monitoraggio e gestione automatizzata delle quote di servizio e limiti delle risorse possono ridurre i guasti in modo proattivo. I cambiamenti nei modelli di traffico per il servizio di un cliente possono causare un'interruzione o un degrado se non si seguono le best practice. Monitorando e gestendo questi valori in tutte le regioni e in tutti gli account, le applicazioni possono avere una maggiore resilienza in caso di eventi avversi o non pianificati. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Service Quotas è un servizio AWS che ti aiuta a gestire le quote per oltre 250 servizi AWS da un'unica posizione. Oltre a cercare i valori delle quote, si possono anche richiedere e monitorare gli aumenti delle quote stesse tramite la console Service Quotas o tramite l'SDK AWS. AWS Trusted Advisor offre un controllo delle quote di servizio che mostra l'utilizzo e le quote per alcuni aspetti di determinati servizi. Le quote di servizio predefinite per servizio sono indicate anche nella documentazione AWS di ciascun servizio (ad esempio vedi [Quote di Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html)). 

 Alcuni limiti dei servizi, come i limiti di velocità sulle API con throttling vengono impostati all'interno di Amazon API Gateway stesso configurando un piano di utilizzo. Altri limiti impostati come configurazione per i rispettivi servizi includono capacità di IOPS allocata, archiviazione Amazon RDS allocato e allocazioni di volumi Amazon EBS. Amazon Elastic Compute Cloud dispone di un proprio pannello di controllo sui limiti del servizio che consente di gestire l'istanza, Amazon Elastic Block Store e i limiti degli indirizzi IP elastici. Se hai un caso d'uso in cui le quote di servizio influiscono sulle prestazioni della tua applicazione e non sono adattabili alle tue esigenze, contatta Supporto per vedere se sono possibili riduzioni. 

 Le quote di servizio possono essere specifiche per ogni regione o di natura globale. L'uso di un servizio AWS che raggiunge la sua quota non si comporterà come previsto nell'uso normale e potrebbe causare interruzioni o degrado del servizio. Ad esempio, una quota di servizio limita il numero di DL Amazon EC2 che può essere usato in una Regione e tale limite può essere raggiunto durante un evento di dimensionamento del traffico tramite gruppi Auto Scaling (ASG). 

 Le quote di servizio per ogni account devono essere valutate regolarmente per determinare quali siano i limiti di servizio appropriati per quell'account. Queste quote di servizio esistono come guardrail operativi, per evitare di fornire accidentalmente più risorse di quelle necessarie. Servono anche a limitare i tassi di richiesta delle operazioni API per proteggere i servizi dagli abusi. 

 I limiti dei servizi sono diversi dalle quote dei servizi. I vincoli di servizio rappresentano i limiti di una particolare risorsa, definiti da quel tipo di risorsa. Questi possono essere la capacità di archiviazione (ad esempio, gp2 ha un limite di dimensione di 1 GB - 16 TB) o il throughput del disco (10.0000 iops). È essenziale che il vincolo di un tipo di risorsa sia progettato e valutato costantemente per l'utilizzo che potrebbe raggiungere il suo limite. Se un vincolo viene raggiunto inaspettatamente, le applicazioni o i servizi dell'account possono essere degradati o interrotti. 

 Se hai un caso d'uso in cui le quote di servizio influiscono sulle prestazioni della tua applicazione e non sono adattabili alle tue esigenze, contatta Supporto per vedere se sono possibili mitigazioni. Per maggiori dettagli su come modificare le quote fisse vedi [REL01-BP03 Adattamento di quote e vincoli di servizio fissi mediante l'architettura](rel_manage_service_limits_aware_fixed_limits.md). 

 Esistono alcuni servizi e strumenti AWS per monitorare e gestire Service Quotas. Il servizio e gli strumenti devono essere sfruttati per fornire controlli automatici o manuali dei livelli di quota. 
+  AWS Trusted Advisor offre un controllo delle quote di servizio che mostra l'utilizzo e le quote per alcuni aspetti di alcuni servizi. Può aiutare a identificare i servizi vicini alle quote. 
+  Console di gestione AWS fornisce metodi per visualizzare i valori delle quote dei servizi, gestire, richiedere nuove quote, monitorare lo stato delle richieste di quote e visualizzare la cronologia delle quote. 
+  AWS CLI e CDK offrono metodi programmatici per gestire e monitorare automaticamente l'utilizzo e i livelli delle quote di servizio. 

 **Passaggi dell'implementazione** 

 Per Service Quotas: 
+ [ Revisione di AWS Service Quotas. ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+  Per essere certo delle quote di servizio esistenti, stabilisci i servizi (come IAM Access Analyzer) usati. Esistono circa 250 servizi AWS controllati da quote di servizio. Quindi stabilisci il nome della quota di servizio specifica che potrebbe essere usata all'interno di ogni account e regione. Esistono circa 3000 nomi di quote di servizio per regione. 
+  Aumenta questa analisi delle quote con AWS Config per trovare tutte le [risorse AWS](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html) usate nei tuoi Account AWS. 
+  Utilizza i [dati AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html) per stabilire le risorse AWS utilizzate. Esamina le risorse create in Console di gestione AWS o con il comando [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html) AWS CLI. È anche possibile vedere le risorse configurate da distribuire nel modello stesso. 
+  Stabilisci tutti i servizi necessari per il tuo carico di lavoro analizzando il codice di implementazione. 
+  Determina le quote di servizio applicabili. Utilizza le informazioni accessibili in modo programmatico da Trusted Advisor e Service Quotas. 
+  Stabilisci un metodo di monitoraggio automatizzato (vedi [REL01-BP02 Gestione delle quote di servizio in più account e regioni](rel_manage_service_limits_limits_considered.md) e [REL01-BP04 Monitoraggio e gestione delle quote](rel_manage_service_limits_monitor_manage_limits.md)) per avvisare e informare se le quote di servizio sono vicine o hanno raggiunto il limite. 
+  Stabilisci un metodo automatico e programmatico per verificare se una quota di servizio è stata modificata in una regione ma non in altre regioni dello stesso account. (consulta [REL01-BP02 Gestione delle quote di servizio in più account e regioni](rel_manage_service_limits_limits_considered.md) e [REL01-BP04 Monitoraggio e gestione delle quote](rel_manage_service_limits_monitor_manage_limits.md)). 
+  Automatizza la scansione dei log e delle metriche delle applicazioni per determinare se ci sono errori di quota o di vincoli di servizio. Se sono presenti errori, invia gli allarmi al sistema di monitoraggio. 
+  Stabilisci procedure di progettazione per calcolare la modifica richiesta nella quota (vedi [REL01-BP05 Automazione della gestione delle quote](rel_manage_service_limits_automated_monitor_limits.md)) una volta stabilito che per alcuni servizi specifici sono richieste quote maggiori. 
+  Crea un flusso di lavoro di provisioning e di approvazione per richiedere modifiche alla quota di servizio. Questo dovrebbe includere un flusso di lavoro di eccezione in caso di rifiuto della richiesta o di approvazione parziale. 
+  Crea un metodo ingegneristico per rivedere le quote dei servizi prima del provisioning e dell'utilizzo di nuovi servizi AWS prima del roll-out in ambienti di produzione o carichi (ad esempio, account di test di carico). 

 Per i vincoli dei servizi: 
+  Stabilisci metodi di monitoraggio e metrica per avvisare se le risorse si avvicinano ai loro limiti. Sfrutta CloudWatch in base alle necessità per le metriche o il monitoraggio dei log. 
+  Stabilisci soglie di allarme per ogni risorsa che ha un vincolo significativo per l'applicazione o il sistema. 
+  Crea procedure di gestione del flusso di lavoro e dell'infrastruttura per cambiare il tipo di risorsa se il vincolo è prossimo all'utilizzo. Questo flusso di lavoro dovrebbe includere test di carico come best practice per verificare che quello nuovo sia il tipo di risorsa corretto in base ai nuovi vincoli. 
+  Migra la risorsa identificata al nuovo tipo di risorsa consigliato, utilizzando le procedure e i processi esistenti. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL01-BP02 Gestione delle quote di servizio in più account e regioni](rel_manage_service_limits_limits_considered.md) 
+  [REL01-BP03 Adattamento di quote e vincoli di servizio fissi mediante l'architettura](rel_manage_service_limits_aware_fixed_limits.md) 
+  [REL01-BP04 Monitoraggio e gestione delle quote](rel_manage_service_limits_monitor_manage_limits.md) 
+  [REL01-BP05 Automazione della gestione delle quote](rel_manage_service_limits_automated_monitor_limits.md) 
+  [REL01-BP06 Creazione di un divario sufficiente tra le quote attuali e l'utilizzo massimo per consentire eventuali failover](rel_manage_service_limits_suff_buffer_limits.md) 
+  [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos](rel_testing_resiliency_failure_injection_resiliency.md) 

 **Documenti correlati:** 
+ [ Principio dell'affidabilità di AWS Well-Architected Framework: disponibilità ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Controlli delle best practice AWS Trusted Advisor (consulta la sezione Restrizioni dei servizi)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [ Monitoraggio limite su AWS su risposte AWS](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Quote di servizio Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Che cos'è Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Come richiedere un aumento delle quote ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [ Endpoint e quote dei servizi ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+  [Guida per l'utente di Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Monitoraggio delle quote per AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [ Limiti di isolamento dei guasti di AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Disponibilità con ridondanza ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS for Data ](https://aws.amazon.com/data/)
+ [ In cosa consiste l'Integrazione continua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ In cosa consiste la Distribuzione continua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Partner APN: partner per la gestione della configurazione](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Gestione del ciclo di vita dell'account in ambienti SaaS account-per-tenant su AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [ Gestione e monitoraggio della limitazione delle API nei carichi di lavoro ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Visualizza i suggerimenti di AWS Trusted Advisor su scala con AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [ Automazione dell'aumento dei limiti di servizio e supporto aziendale con AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)

 **Video correlati:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ Visualizza e gestisci quote per i servizi AWS con Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [ Demo delle quote AWS IAM](https://www.youtube.com/watch?v=srJ4jr6M9YQ)

 **Strumenti correlati:** 
+ [ Amazon CodeGuru Reviewer ](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [Marketplace AWS](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP02 Gestione delle quote di servizio in più account e regioni
<a name="rel_manage_service_limits_limits_considered"></a>

 Se utilizzi più account o Regioni, assicurati di richiedere le quote appropriate in tutti gli ambienti in cui vengono eseguiti i carichi di lavoro di produzione. 

 **Risultato desiderato:** i servizi e le applicazioni non dovrebbero essere interessati dall'esaurimento delle quote di servizio per le configurazioni che si estendono su account o Regioni o con progetti di resilienza che utilizzano il failover di zona, Regione o account. 

 **Anti-pattern comuni:** 
+ Consentire l'aumento dell'utilizzo delle risorse in una Regione di isolamento senza alcun meccanismo per mantenere la capacità nelle altre. 
+  Impostare manualmente tutte le quote in modo indipendente nelle Regioni di isolamento. 
+  Non considerare l'effetto delle architetture di resilienza (come quelle attive o passive) nelle future esigenze di quote durante un degrado nella Regione non primaria. 
+  Non valutare regolarmente le quote e apportare le modifiche necessarie in ogni Regione e account in cui viene gestito il carico di lavoro. 
+  Non sfruttare [modelli di richiesta delle quote](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html) per richiedere incrementi su più Regioni e account. 
+  Non aggiornare le quote dei servizi, perché si pensa erroneamente che l'aumento delle quote abbia implicazioni di costo, come le richieste di prenotazione di calcolo. 

 **Vantaggi derivanti dall'adozione di questa best practice:** verificare che sia possibile gestire il proprio carico attuale in Regioni o account secondari in caso di mancata disponibilità dei servizi regionali. Questo consente di ridurre il numero di errori o livelli di degrado che si verificano durante la perdita di Regioni. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Le quote di servizio vengono monitorate per account. Salvo diversa indicazione, ogni quota è specifica della Regione AWS. Oltre agli ambienti di produzione, gestisci anche le quote in tutti gli ambienti non di produzione applicabili, in modo che i test e lo sviluppo non siano ostacolati. Il mantenimento di un elevato grado di resilienza richiede una valutazione continua delle quote di servizio (sia automatica che manuale). 

 Con più carichi di lavoro in diverse Regioni a causa dell'implementazione di progetti che usano approcci *Active/Active*, *Active/Passive – Hot*, *Active/Passive-Cold* e *Active/Passive-Pilot Light*, è fondamentale comprendere tutti i livelli di quote di account e Regioni. I modelli di traffico passati non sono sempre un buon indicatore per stabilire se la quota di servizio è impostata correttamente. 

 Altrettanto importante è il fatto che il limite di nome della quota di servizio non è sempre lo stesso per ogni Regione. In una Regione il valore potrebbe essere cinque, in un'altra potrebbe essere dieci. La gestione di queste quote deve riguardare tutti gli stessi servizi, account e Regioni per garantire una resilienza costante sotto carico. 

 Riconciliare tutte le differenze di quota di servizio tra le diverse Regioni (Regione attiva o passiva) e creare processi per riconciliare continuamente queste differenze. I piani di test dei failover passivi delle Regioni sono raramente scalati in base alla capacità attiva di picco, il che significa che gli esercizi di game day o table top possono non riuscire a trovare le differenze nelle quote di servizio tra le Regioni e a mantenere i limiti corretti. 

 *Deviazione delle quote di servizio*, è molto importante da monitorare e valutare la condizione in cui i limiti delle quote di servizio per una specifica quota nominata vengono modificati in una Regione e non in tutte le Regioni. Si dovrebbe prendere in considerazione la possibilità di modificare la quota nelle Regioni con traffico o potenzialmente in grado di trasportare traffico. 
+  Seleziona gli account e le regioni pertinenti in base ai tuoi requisiti di servizio, di latenza, normativi e di ripristino di emergenza. 
+  Identifica le quote dei servizi per tutti gli account, le regioni e le zone di disponibilità pertinenti. Le restrizioni si riferiscono ad account e regione. Questi valori devono essere confrontati per far emergere le differenze. 

 **Passaggi dell'implementazione** 
+  Rivedi i valori Service Quotas che potrebbero aver superato il livello di rischio di utilizzo. AWS Trusted Advisor offre allarmi per la violazione di soglie dell'80% e del 90%. 
+  Rivedi i valori per le quote di servizio in qualsiasi Regione Passiva (in un progetto Attivo/Passivo). Verifica che il carico venga eseguito correttamente nelle Regioni secondarie in caso di guasto nella Regione primaria. 
+  Valuta automaticamente se si è verificata una deviazione delle quote di servizio tra le Regioni dello stesso account e agisci di conseguenza per modificare i limiti. 
+  Se le Unità Organizzative (UO) del cliente sono strutturate nel modo supportato, i modelli di quote di servizio devono essere aggiornati per riflettere le modifiche alle quote da applicare a più Regioni e account. 
  +  Crea un modello e associa le Regioni alla modifica della quota. 
  +  Rivedi tutti i modelli delle quote di servizio esistenti per qualsiasi modifica richiesta (Regione, limiti e account). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL01-BP01 Consapevolezza su quote e vincoli di servizio](rel_manage_service_limits_aware_quotas_and_constraints.md) 
+  [REL01-BP03 Adattamento di quote e vincoli di servizio fissi mediante l'architettura](rel_manage_service_limits_aware_fixed_limits.md) 
+  [REL01-BP04 Monitoraggio e gestione delle quote](rel_manage_service_limits_monitor_manage_limits.md) 
+  [REL01-BP05 Automazione della gestione delle quote](rel_manage_service_limits_automated_monitor_limits.md) 
+  [REL01-BP06 Creazione di un divario sufficiente tra le quote attuali e l'utilizzo massimo per consentire eventuali failover](rel_manage_service_limits_suff_buffer_limits.md) 
+  [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos](rel_testing_resiliency_failure_injection_resiliency.md) 

 **Documenti correlati:** 
+ [ Principio dell'affidabilità di AWS Well-Architected Framework: disponibilità ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Controlli delle best practice AWS Trusted Advisor (consulta la sezione Restrizioni dei servizi)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [ Monitoraggio limite su AWS su risposte AWS](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Quote di servizio Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Che cos'è Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Come richiedere un aumento delle quote ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [ Endpoint e quote dei servizi ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+  [Guida per l'utente di Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Monitoraggio delle quote per AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [ Limiti di isolamento dei guasti di AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Disponibilità con ridondanza ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS for Data ](https://aws.amazon.com/data/)
+ [ In cosa consiste l'Integrazione continua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ In cosa consiste la Distribuzione continua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Partner APN: partner per la gestione della configurazione](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Gestione del ciclo di vita dell'account in ambienti SaaS account-per-tenant su AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [ Gestione e monitoraggio della limitazione delle API nei carichi di lavoro ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Visualizza i suggerimenti di AWS Trusted Advisor su scala con AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [ Automazione dell'aumento dei limiti di servizio e supporto aziendale con AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)

 **Video correlati:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ Visualizza e gestisci quote per i servizi AWS con Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [ Demo delle quote AWS IAM](https://www.youtube.com/watch?v=srJ4jr6M9YQ)

 **Servizi correlati:** 
+ [ Amazon CodeGuru Reviewer ](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [Marketplace AWS](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP03 Adattamento di quote e vincoli di servizio fissi mediante l'architettura
<a name="rel_manage_service_limits_aware_fixed_limits"></a>

Identifica attentamente quote di servizio, vincoli del servizio e limiti delle risorse fisiche che non possono essere modificati. Progetta architetture per le applicazioni e i servizi in modo da impedire che questi limiti abbiano impatto sull'affidabilità.

Alcuni esempi includono la larghezza di banda di rete, le dimensioni di payload delle chiamate di funzioni serverless, il tasso di espansione dei limiti per un gateway API e le connessioni utente simultanee a un database.

 **Risultato desiderato:** l'applicazione o il servizio ha le prestazioni previste in condizioni di traffico normale ed elevato. L'applicazione o il servizio è stato progettato per operare entro i limiti dei vincoli o delle quote di servizio fissi della risorsa. 

 **Anti-pattern comuni:** 
+ Scelta di una progettazione che usa una risorsa di un servizio, senza essere al corrente della presenza di vincoli che causeranno errori di progettazione durante il dimensionamento.
+ Esecuzione di benchmark poco realistici e che raggiungono le quote di servizio fisse durante i test. Ad esempio, l'esecuzione di test a un limite di espansione per un periodo di tempo prolungato.
+  Scelta di una progettazione che non può essere dimensionata o modificata in caso di superamento delle quote di servizio fisse. Ad esempio, dimensioni dei payload SQS di 256 KB. 
+  Mancata progettazione e implementazione della visibilità per monitorare e segnalare le soglie per le quote di servizio a rischio durante eventi di traffico elevato. 

 **Vantaggi dell'adozione di questa best practice:** possibilità di verificare che l'applicazione verrà eseguita a tutti i livelli di carico dei servizi previsti senza interruzioni o errori. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Diversamente dalle risorse e dalle quote di servizio flessibili che possono essere sostituite con unità di capacità maggiori, le quote di servizio fisse in AWS non possono essere modificate. Di conseguenza, tutti i servizi AWS di questo tipo devono essere valutati per identificare i possibili limiti fissi di capacità quando vengono usati per la progettazione di un'applicazione. 

 I limiti fissi vengono mostrati nella console Service Quotas. Se le colonne indicano `REGOLABILE = No`, il servizio ha un limite fisso. I limiti fissi vengono mostrati anche in alcune pagine di configurazione delle risorse. Ad esempio, per Lambda è previsto un limite fisso specifico che non può essere modificato. 

 Ad esempio, durante la progettazione di un'applicazione Python da eseguire in una funzione Lambda, l'applicazione deve essere valutata per determinare la probabilità che Lambda venga eseguito per più di 15 minuti. Se il codice potrebbe restare in esecuzione oltre questo limite della quota di servizio, devi prendere in considerazione tecnologie o progettazioni alternative. Se il limite viene raggiunto dopo l'implementazione nell'ambiente di produzione, l'applicazione sarà soggetta a errori o interruzioni finché non viene corretta. Diversamente dalle quote flessibili, non esiste alcun metodo per modificare i limiti, anche in caso di eventi di emergenza con livello di gravità 1. 

 Dopo aver implementato l'applicazione in un ambiente di test, è necessario adottare una strategia per determinare se vi sia la probabilità di raggiungere i limiti fissi. I test di stress, di carico e di chaos engineering devono fare parte del piano di test iniziale. 

 **Passaggi dell'implementazione** 
+  Esamina l'elenco completo dei servizi AWS che possono essere usati nella fase di progettazione dell'applicazione. 
+  Esamina i limiti di quota flessibili e fissi per tutti i servizi. Non tutti i limiti vengono indicati nella console Service Quotas. Alcuni servizi [descrivono questi limiti in posizioni diverse](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html). 
+  Nel progettare l'applicazione, esamina i principali fattori commerciali e tecnologici del carico di lavoro, come risultati aziendali, casi d'uso, sistemi dipendenti, obiettivi di disponibilità e oggetti di ripristino di emergenza. Fai in modo che siano questi fattori commerciali e tecnologici a orientare il processo di identificazione del sistema distribuito corretto per il carico di lavoro. 
+  Analizza il carico dei servizi tra regioni e account. Molti limiti fissi per i servizi variano a seconda della regione. Tuttavia, alcuni limiti dipendono dagli account. 
+  Analizza le architetture di resilienza per l'utilizzo delle risorse durante un guasto a livello di zona e di regione. Nel corso dello sviluppo di progettazioni multi-regione che usano approcci attivo/attivo, attivo/passivo con standby a caldo, attivo/passivo con standby a freddo e attivo/passivo con Pilot Light i casi di errore determineranno un utilizzo più elevato. Questo comportamento crea un possibile caso d'uso per il raggiungimento dei limiti fissi. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL01-BP01 Consapevolezza su quote e vincoli di servizio](rel_manage_service_limits_aware_quotas_and_constraints.md) 
+  [REL01-BP02 Gestione delle quote di servizio in più account e regioni](rel_manage_service_limits_limits_considered.md) 
+  [REL01-BP04 Monitoraggio e gestione delle quote](rel_manage_service_limits_monitor_manage_limits.md) 
+  [REL01-BP05 Automazione della gestione delle quote](rel_manage_service_limits_automated_monitor_limits.md) 
+  [REL01-BP06 Creazione di un divario sufficiente tra le quote attuali e l'utilizzo massimo per consentire eventuali failover](rel_manage_service_limits_suff_buffer_limits.md) 
+  [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos](rel_testing_resiliency_failure_injection_resiliency.md) 

 **Documenti correlati:** 
+ [ Principio dell'affidabilità di AWS Well-Architected Framework: disponibilità ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Controlli delle best practice AWS Trusted Advisor (consulta la sezione Restrizioni dei servizi)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [ Monitoraggio limite su AWS su risposte AWS](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Quote di servizio Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Che cos'è Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Come richiedere un aumento delle quote ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [ Endpoint e quote dei servizi ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+  [Guida per l'utente di Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Monitoraggio delle quote per AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [ Limiti di isolamento dei guasti di AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Disponibilità con ridondanza ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS for Data ](https://aws.amazon.com/data/)
+ [ In cosa consiste l'Integrazione continua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ In cosa consiste la Distribuzione continua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Partner APN: partner per la gestione della configurazione](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Gestione del ciclo di vita dell'account in ambienti SaaS account-per-tenant su AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [ Gestione e monitoraggio della limitazione delle API nei carichi di lavoro ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Visualizza i suggerimenti di AWS Trusted Advisor su scala con AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [ Automazione dell'aumento dei limiti di servizio e supporto aziendale con AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)
+ [Operazioni, risorse e chiavi di condizione per Service Quotas](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)

 **Video correlati:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ Visualizza e gestisci quote per i servizi AWS con Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [ Demo delle quote AWS IAM](https://www.youtube.com/watch?v=srJ4jr6M9YQ)
+ [AWS re:Invent 2018: Cicli chiusi e menti aperte: come assumere il controllo di sistemi grandi e piccoli ](https://www.youtube.com/watch?v=O8xLxNje30M)

 **Strumenti correlati:** 
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [Marketplace AWS](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP04 Monitoraggio e gestione delle quote
<a name="rel_manage_service_limits_monitor_manage_limits"></a>

 Valuta il tuo utilizzo potenziale e aumenta le quote in modo appropriato per una crescita pianificata dell'utilizzo. 

 **Risultato desiderato:** implementazione di sistemi attivi e automatici per la gestione e il monitoraggio. Queste soluzioni operative indicano che le soglie di utilizzo delle quote stanno per essere raggiunte. Questo problema può essere risolto in modo proattivo tramite modifiche alle quote richieste. 

 **Anti-pattern comuni:** 
+ Mancata configurazione del monitoraggio per verificare le soglie delle quote di servizio.
+ Mancata configurazione del monitoraggio dei limiti fissi, anche se i valori non possono essere modificati.
+  Valutazione errata della quantità di tempo necessaria per richiedere e ottenere la modifica di una quota flessibile, supponendo che sia immediata o rapida. 
+  Configurazione di allarmi per l'avvicinamento alle quote di servizio, ma senza alcun processo di risposta a un avviso. 
+  Configurazione di allarmi solo per i servizi supportati da AWS Service Quotas, senza monitorare altri servizi AWS. 
+  Valutazione errata della gestione delle quote per progettazioni di resilienza in più regioni, come gli approcci attivo/attivo, attivo/passivo con standby a caldo, attivo/passivo con standby a freddo e attivo/passivo con Pilot Light. 
+  Mancata valutazione delle differenze di quota tra regioni. 
+  Mancata valutazione delle esigenze in ogni regione per una richiesta di aumento di quota specifica. 
+  Mancato utilizzo di [modelli per la gestione delle quote in più regioni](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html). 

 **Vantaggi dell'adozione di questa best practice:** il monitoraggio automatico di AWS Service Quotas e il monitoraggio dell'utilizzo rispetto alle quote permettono di identificare l'avvicinamento a un limite di quota. Puoi usare questi dati di monitoraggio per limitare eventuali errori dovuti all'esaurimento della quota. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per i servizi supportati, puoi monitorare le quote configurando servizi diversi in grado di eseguire una valutazione e quindi inviare avvisi o allarmi. In questo modo, il monitoraggio dell'utilizzo è più semplice e puoi ricevere avvisi all'avvicinamento delle quote. Gli allarmi possono essere attivati da AWS Config, funzioni Lambda, Amazon CloudWatch o AWS Trusted Advisor. Puoi anche usare filtri delle metriche in file di log CloudWatch per cercare ed estrarre modelli nei log, in modo da determinare se l'utilizzo si avvicina alle soglie delle quote. 

 **Passaggi dell'implementazione** 

 Per il monitoraggio: 
+  Acquisisci informazioni sull'attuale consumo di risorse, ad esempio bucket o istanze. Usa operazioni API dei servizi come l'API Amazon EC2 `DescribeInstances` per raccogliere informazioni sull'attuale consumo di risorse. 
+  Acquisisci le attuali quote essenziali e valide per i servizi usando: 
  +  AWS Service Quotas 
  +  AWS Trusted Advisor 
  +  Documentazione di AWS 
  +  Pagine specifiche dei servizi AWS 
  +  AWS Command Line Interface (AWS CLI) 
  +  AWS Cloud Development Kit (AWS CDK) 
+  Usa AWS Service Quotas, un servizio AWS che semplifica la gestione delle quote per oltre 250 servizi AWS da un'unica posizione. 
+  Usa i limiti del servizio Trusted Advisor per monitorare gli attuali limiti del servizio a soglie diverse. 
+  Usa la cronologia delle quote di servizio (console o AWS CLI) per verificare gli aumenti regionali. 
+  Confronta la modifica delle quote di servizio in ogni regione e ogni account per creare equivalenze, se necessario. 

 Per la gestione: 
+  Automatica: configura una regola AWS Config personalizzata per analizzare le quote di servizio tra regioni e confrontarle per individuare le differenze. 
+  Automatica: configura una regola Lambda personalizzata per analizzare le quote di servizio tra regioni e confrontarle per individuare le differenze. 
+  Manuale: analizza le quote di servizio tramite l'AWS CLI, l'API o la console AWS per esaminare le quote nelle diverse regioni e confrontarle per individuare le differenze. Segnala le differenze. 
+  Se vengono identificate differenze nelle quote tra regioni, richiedi una modifica della quota, se necessario. 
+  Esamina il risultato di tutte le richieste. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL01-BP01 Consapevolezza su quote e vincoli di servizio](rel_manage_service_limits_aware_quotas_and_constraints.md) 
+  [REL01-BP02 Gestione delle quote di servizio in più account e regioni](rel_manage_service_limits_limits_considered.md) 
+  [REL01-BP03 Adattamento di quote e vincoli di servizio fissi mediante l'architettura](rel_manage_service_limits_aware_fixed_limits.md) 
+  [REL01-BP05 Automazione della gestione delle quote](rel_manage_service_limits_automated_monitor_limits.md) 
+  [REL01-BP06 Creazione di un divario sufficiente tra le quote attuali e l'utilizzo massimo per consentire eventuali failover](rel_manage_service_limits_suff_buffer_limits.md) 
+  [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos](rel_testing_resiliency_failure_injection_resiliency.md) 

 **Documenti correlati:** 
+ [ Principio dell'affidabilità di AWS Well-Architected Framework: disponibilità ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Controlli delle best practice AWS Trusted Advisor (consulta la sezione Restrizioni dei servizi)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [ Monitoraggio limite su AWS su risposte AWS](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Quote di servizio Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Che cos'è Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Come richiedere un aumento delle quote ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [ Endpoint e quote dei servizi ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+  [Guida per l'utente di Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Monitoraggio delle quote per AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [ Limiti di isolamento dei guasti di AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Disponibilità con ridondanza ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS for Data ](https://aws.amazon.com/data/)
+ [ In cosa consiste l'Integrazione continua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ In cosa consiste la Distribuzione continua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Partner APN: partner per la gestione della configurazione](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Gestione del ciclo di vita dell'account in ambienti SaaS account-per-tenant su AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [ Gestione e monitoraggio della limitazione delle API nei carichi di lavoro ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Visualizza i suggerimenti di AWS Trusted Advisor su scala con AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [ Automazione dell'aumento dei limiti di servizio e supporto aziendale con AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)
+ [Operazioni, risorse e chiavi di condizione per Service Quotas](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)

 **Video correlati:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ Visualizza e gestisci quote per i servizi AWS con Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [ Demo delle quote AWS IAM](https://www.youtube.com/watch?v=srJ4jr6M9YQ)
+ [AWS re:Invent 2018: Cicli chiusi e menti aperte: come assumere il controllo di sistemi grandi e piccoli ](https://www.youtube.com/watch?v=O8xLxNje30M)

 **Strumenti correlati:** 
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [Marketplace AWS](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL01-BP05 Automazione della gestione delle quote
<a name="rel_manage_service_limits_automated_monitor_limits"></a>

 Implementa strumenti per ricevere avvisi quando le soglie stanno per essere raggiunte. Puoi automatizzare le richieste di aumento delle quote utilizzando le API AWS Service Quotas. 

 Se integri il tuo database di gestione della configurazione (CMDB) o il sistema di ticketing con le Service Quotas, puoi automatizzare il monitoraggio delle richieste di aumento delle quote e delle quote correnti. Oltre all'SDK AWS, Service Quotas offre automazione utilizzando AWS Command Line Interface (AWS CLI). 

 **Anti-pattern comuni:** 
+  Monitoraggio delle quote e dell'utilizzo nei fogli di calcolo. 
+  Esecuzione di report sull'utilizzo giornaliero, settimanale o mensile e successivo confronto dell'utilizzo con le quote. 

 **Vantaggi dell'adozione di questa best practice:** Il monitoraggio automatico delle quote di servizio AWS e il monitoraggio dell'utilizzo rispetto a tale quota ti consentiranno di sapere quando stai per raggiungere una quota. Puoi configurare l'automazione affinché ti aiuti a richiedere un aumento della quota quando necessario. Puoi decidere di ridurre alcune quote quando il tuo utilizzo tende alla direzione opposta per ottenere i vantaggi di riduzione del rischio (in caso di credenziali compromesse) e dei costi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Impostazione del monitoraggio automatico: implementa strumenti utilizzando gli SDK per ricevere avvisi quando le soglie stanno per essere raggiunte. 
  +  Utilizza Service Quotas e potenzia il servizio con una soluzione di monitoraggio automatico delle quote come AWS Limit Monitor o un'offerta di Marketplace AWS. 
    +  [What is Service Quotas? (Che cos'è Service Quotas?)](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
    +  [Monitoraggio delle quota su AWS – Soluzione AWS](https://aws.amazon.com/answers/account-management/limit-monitor/) 
  +  Impostazione di risposte attivate in base alle soglie delle quote tramite l'utilizzo delle API di Amazon SNS e AWS Service Quotas. 
  +  Automazione dei test. 
    +  Configura le soglie delle restrizioni. 
    +  Integrazione con eventi di modifica di AWS Config, pipeline di implementazione, Amazon EventBridge o terze parti. 
    +  Imposta artificialmente soglie basse per le quote in modo da testare le risposte. 
    +  Configura i trigger per eseguire azioni adeguate in seguito alle notifiche e contatta Supporto AWS se necessario. 
    +  Attiva manualmente gli eventi di modifica. 
    +  Esegui una giornata di gioco per testare il processo di modifica dell'aumento delle quote. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner per la gestione della configurazione](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management) 
+  [Marketplace AWS: prodotti CMDB per il monitoraggio delle restrizioni](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Elenco di controllo delle best practice di AWS Trusted Advisor (consulta la sezione Restrizioni dei servizi)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [Monitoraggio delle quota su AWS – Soluzione AWS](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Quote di servizio di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [What is Service Quotas? (Che cos'è Service Quotas?)](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **Video correlati:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP06 Creazione di un divario sufficiente tra le quote attuali e l'utilizzo massimo per consentire eventuali failover
<a name="rel_manage_service_limits_suff_buffer_limits"></a>

Quando una risorsa restituisce un errore o è inaccessibile, può comunque essere conteggiata rispetto a una quota finché non viene terminata. Verifica che le quote tengano conto della sovrapposizione di risorse in errore o inaccessibili e della rispettiva sostituzione. Nel calcolare questo divario, devi considerare casi d'uso come errori di rete, regionali o delle zone di disponibilità.

 **Risultato desiderato:** possibilità di gestire errori di piccola o grande entità relativi alle risorse o all'accessibilità delle risorse all'interno delle attuali soglie di servizio, tenendo conto degli errori delle zone, di rete o addirittura regionali nella pianificazione delle risorse. 

 **Anti-pattern comuni:** 
+  Impostazione delle quote di servizio in base alle esigenze attuali senza tenere conto degli scenari di failover. 
+  Calcolo della quota massima per un servizio senza tenere conto dei principali aspetti della stabilità statica. 
+  Calcolo della quota totale necessaria per ogni regione senza tenere conto delle potenziali risorse inaccessibili. 
+  Valutazione errata dei limiti di isolamento degli errori per alcuni servizi AWS e dei possibili modelli di utilizzo anomalo. 

 **Vantaggi dell'adozione di questa best practice:** quando eventi di interruzione dei servizi hanno impatto sulla disponibilità delle applicazioni, il cloud permette di implementare strategie per mitigare questi eventi o ripristinare i servizi. Queste strategie spesso includono la creazione di risorse aggiuntive per sostituire quelle in errore o inaccessibili. La strategia di gestione delle quote soddisferebbe queste condizioni di failover senza aggiungere altri fattori negativi dovuti al raggiungimento dei limiti dei servizi. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Nel valutare i limiti di quota, tieni conto dei casi di failover che possono verificarsi a causa di un peggioramento della situazione. È bene considerare i tipi di casi di failover seguenti: 
+  Un VPC interrotto o inaccessibile. 
+  Una sottorete inaccessibile. 
+  Una zona di disponibilità sufficientemente compromessa da avere impatto sull'accessibilità di molte risorse. 
+  Diverse route di rete o punti di ingresso e uscita bloccati o che sono stati modificati. 
+  Una regione sufficientemente compromessa da avere impatto sull'accessibilità di molte risorse. 
+  Presenza di più risorse, ma non tutte interessate da un errore in una regione o in una zona di disponibilità. 

 Errori come quelli elencati sopra possono essere il fattore scatenante dell'avvio di un evento di failover. La decisione relativa all'avvio del failover è unica per ogni situazione e cliente, in quanto l'impatto aziendale può variare notevolmente. Tuttavia, nel decidere operativamente l'avvio del failover dell'applicazione o dei servizi, la pianificazione della capacità delle risorse nella posizione di failover e delle quote correlate deve essere gestita prima dell'evento. 

 Esamina le quote per ogni servizio tenendo conto di possibili picchi più elevati del previsto. Questi picchi possono essere correlati a risorse ancora attive raggiungibili a causa di reti o autorizzazioni. Le risorse attive non terminate continuano a essere conteggiate rispetto al limite di quota del servizio. 

 **Passaggi dell'implementazione** 
+  Assicurati che vi sia una differenza sufficiente tra la quota di servizio e l'utilizzo massimo in modo da gestire un failover o la perdita di accessibilità. 
+  Determina le quote di servizio, specificando i pattern di implementazione, i requisiti di disponibilità e la crescita dei consumi. 
+  Richiedi aumenti delle quote, se necessario. Pianifica tenendo conto del tempo necessario affinché le richieste di aumento delle quote siano soddisfatte. 
+  Determina i requisiti di affidabilità, noti anche come numero di 9. 
+  Determina gli scenari di errore (ad esempio, perdita di un componente, una zona di disponibilità o una regione). 
+  Stabilisci la metodologia di implementazione (ad esempio, canary, blu/verde, rosso/nero o rolling). 
+  Includi un buffer appropriato (ad esempio, 15%) rispetto alla restrizione attuale. 
+  Includi calcoli per la stabilità statica (zonale e regionale) laddove appropriato. 
+  Pianifica la crescita dei consumi (ad esempio, monitora le tendenze dei consumi). 
+  Tieni conto dell'impatto della stabilità statica per i carichi di lavoro più critici. Valuta la conformità delle risorse a un sistema statisticamente stabile in tutte le regioni e le zone di disponibilità. 
+  Valuta se usare prenotazioni della capacità on demand per pianificare la capacità in anticipo rispetto a qualsiasi failover. Questa strategia può essere utile durante le pianificazioni aziendali più critiche per ridurre i possibili rischi legati all'ottenimento della quantità e del tipo di risorse corretti durante il failover. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL01-BP01 Consapevolezza su quote e vincoli di servizio](rel_manage_service_limits_aware_quotas_and_constraints.md) 
+  [REL01-BP02 Gestione delle quote di servizio in più account e regioni](rel_manage_service_limits_limits_considered.md) 
+  [REL01-BP03 Adattamento di quote e vincoli di servizio fissi mediante l'architettura](rel_manage_service_limits_aware_fixed_limits.md) 
+  [REL01-BP04 Monitoraggio e gestione delle quote](rel_manage_service_limits_monitor_manage_limits.md) 
+  [REL01-BP05 Automazione della gestione delle quote](rel_manage_service_limits_automated_monitor_limits.md) 
+  [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos](rel_testing_resiliency_failure_injection_resiliency.md) 

 **Documenti correlati:** 
+ [ Principio dell'affidabilità di AWS Well-Architected Framework: disponibilità ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+  [AWS Service Quotas (precedentemente note come restrizioni dei servizi)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [Controlli delle best practice AWS Trusted Advisor (consulta la sezione Restrizioni dei servizi)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [ Monitoraggio limite su AWS su risposte AWS](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Quote di servizio Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Che cos'è Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Come richiedere un aumento delle quote ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [ Endpoint e quote dei servizi ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+  [Guida per l'utente di Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+ [ Monitoraggio delle quote per AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [ Limiti di isolamento dei guasti di AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Disponibilità con ridondanza ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [AWS for Data ](https://aws.amazon.com/data/)
+ [ In cosa consiste l'Integrazione continua? ](https://aws.amazon.com/devops/continuous-integration/)
+ [ In cosa consiste la Distribuzione continua? ](https://aws.amazon.com/devops/continuous-delivery/)
+ [Partner APN: partner per la gestione della configurazione](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Gestione del ciclo di vita dell'account in ambienti SaaS account-per-tenant su AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)
+ [ Gestione e monitoraggio della limitazione delle API nei carichi di lavoro ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Visualizza i suggerimenti di AWS Trusted Advisor su scala con AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)
+ [ Automazione dell'aumento dei limiti di servizio e supporto aziendale con AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)
+ [Operazioni, risorse e chiavi di condizione per Service Quotas](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html)

 **Video correlati:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 
+ [ Visualizza e gestisci quote per i servizi AWS con Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)
+ [ Demo delle quote AWS IAM](https://www.youtube.com/watch?v=srJ4jr6M9YQ)
+ [AWS re:Invent 2018: Cicli chiusi e menti aperte: come assumere il controllo di sistemi grandi e piccoli ](https://www.youtube.com/watch?v=O8xLxNje30M)

 **Strumenti correlati:** 
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [Marketplace AWS](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)

# REL 2. Come si pianifica la topologia di rete?
<a name="rel-02"></a>

I carichi di lavoro sono spesso presenti in più ambienti. Questi includono più ambienti cloud (sia pubblicamente accessibili sia privati) e, possibilmente, l'infrastruttura del data center esistente. I piani devono includere considerazioni di rete, ad esempio connettività intrasistema e intersistema, gestione di indirizzi IP pubblici, gestione di indirizzi IP privati e risoluzione dei nomi di dominio.

**Topics**
+ [REL02-BP01 Utilizzo di una connettività di rete a disponibilità elevata per gli endpoint pubblici del carico di lavoro](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 Esecuzione del provisioning di connettività ridondante tra reti private nel cloud e negli ambienti on-premise.](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 Verifica che l'allocazione delle sottoreti IP consenta l'espansione e la disponibilità:](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 Preferire topologie hub-and-spoke rispetto a mesh da-molti-a-molti](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 Applicazione di intervalli di indirizzi IP privati non sovrapposti in tutti gli spazi con indirizzi privati a cui sono connessi](rel_planning_network_topology_non_overlap_ip.md)

# REL02-BP01 Utilizzo di una connettività di rete a disponibilità elevata per gli endpoint pubblici del carico di lavoro
<a name="rel_planning_network_topology_ha_conn_users"></a>

 La creazione di connettività di rete a disponibilità elevata agli endpoint pubblici dei carichi di lavoro può ridurre i tempi di inattività dovuti a perdita di connettività e migliorare la disponibilità e il contratto sul livello di servizio del carico di lavoro. Per ottenere questo risultato, usa un servizio DNS a disponibilità elevata, reti di distribuzione di contenuti (CDN), API Gateway, bilanciamento del carico o proxy inversi. 

 **Risultato desiderato:** è essenziale pianificare, creare e rendere operativa una connettività di rete ad alta disponibilità per gli endpoint pubblici. Se il carico di lavoro diventa irraggiungibile a causa della perdita di connettività, il sistema apparirà ai clienti come arrestato, anche se il carico di lavoro è in esecuzione e disponibile. Combinando connettività di rete a disponibilità elevata e resiliente per gli endpoint pubblici del carico di lavoro, insieme a un'architettura resiliente per il carico di lavoro stesso, puoi offrire ai clienti la disponibilità e il livello di servizio migliori possibile. 

 AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway, funzioni URL AWS Lambda, API AWS AppSync e Elastic Load Balancing (ELB) forniscono tutti endpoint pubblici a disponibilità elevata. Amazon Route 53 offre un servizio DNS altamente disponibile per la risoluzione dei nomi di dominio che permette di verificare che gli indirizzi degli endpoint pubblici possano essere risolti. 

 Puoi anche valutare applicazioni software Marketplace AWS per il bilanciamento del carico e l'esecuzione di proxy. 

 **Anti-pattern comuni:** 
+ Progettazione di un carico di lavoro a disponibilità elevata senza pianificare connettività DNS e di rete per la disponibilità elevata.
+  Uso di indirizzi Internet pubblici su singoli container o istanze e gestione della connettività tramite DNS.
+  Uso di indirizzi IP anziché nomi di dominio per l'individuazione dei servizi.
+  Mancata esecuzione di test su scenari con perdita di connettività agli endpoint pubblici. 
+  Mancata analisi delle esigenze di velocità di trasmissione effettiva della rete e dei modelli di distribuzione. 
+  Nessuna attività di test e pianificazione per scenari di possibile interruzione della connettività di rete Internet agli endpoint pubblici del carico di lavoro. 
+  Distribuzione di contenuti (pagine Web, asset statici o file multimediali) in un'area geografica di grandi dimensioni senza usare una rete di distribuzione di contenuti. 
+  Nessuna pianificazione per la prevenzione di attacchi DDoS (Distributed Denial of Service). Gli attacchi DDoS rischiano di arrestare il traffico legittimo e di ridurre la disponibilità per gli utenti. 

 **Vantaggi dell'adozione di questa best practice:** la progettazione di connettività di rete altamente disponibile e resiliente garantisce che il carico di lavoro sia accessibile e disponibile per gli utenti. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Alla base della creazione di connettività di rete a disponibilità elevata agli endpoint pubblici vi è l'instradamento del traffico. Per verificare che il traffico possa raggiungere gli endpoint, il servizio DNS deve essere in grado di risolvere i nomi di dominio negli indirizzi IP corrispondenti. Usa un [sistema dei nomi di dominio (DNS)](https://aws.amazon.com/route53/what-is-dns/) altamente disponibile e scalabile come Amazon Route 53 per gestire i record DNS del dominio. Puoi usare anche i controlli dell'integrità forniti da Amazon Route 53. I controlli dell'integrità verificano che l'applicazione sia raggiungibile, disponibile e funzionale e possono essere configurati in modo da simulare il comportamento degli utenti, come la richiesta di una pagina Web o un URL specifico. In caso di errore, Amazon Route 53 risponde alle richieste di risoluzione DNS e indirizza il traffico solo agli endpoint integri. Puoi anche valutare se usare le funzionalità di instradamento basato sulla latenza e GeoDNS offerte da Amazon Route 53. 

 Per verificare che il carico di lavoro stesso abbia disponibilità elevata, usa Elastic Load Balancing (ELB). Puoi usare Amazon Route 53 per indirizzare il traffico a ELB, che lo distribuisce alle istanze di calcolo di destinazione. Puoi anche usare Amazon API Gateway insieme a AWS Lambda per una soluzione serverless. I clienti possono anche eseguire carichi di lavoro in più Regioni AWS. Con il [modello attivo/attivo multisito](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/), il carico di lavoro può distribuire il traffico da più regioni. Con un modello attivo/passivo multisito, il carico di lavoro distribuisce il traffico dalla regione attiva, mentre i dati vengono replicati nella regione secondaria e diventano attivi in caso di errore nella regione primaria. Puoi usare i controlli dell'integrità in Route 53 per controllare il failover DNS da qualsiasi endpoint in una regione primaria a un endpoint in una regione secondaria, verificando che il carico di lavoro sia raggiungibile e disponibile per gli utenti. 

 Amazon CloudFront offre una semplice API per la distribuzione di contenuti con bassa latenza e velocità di trasferimento dati elevate gestendo le richieste tramite una rete di posizioni edge in tutto il mondo. Le reti di distribuzione di contenuti (CDN) operano per i clienti distribuendo i contenuti situati o memorizzati nella cache in una posizione vicina all'utente. In questo modo, la disponibilità dell'applicazione migliora, in quanto il carico del contenuto viene allontanato dai server verso [posizioni edge](https://aws.amazon.com/products/networking/edge-networking/) di CloudFront. Le posizioni edge e le cache edge regionali includono copie memorizzate nella cache del contenuto vicino agli utenti, per il recupero rapido e una raggiungibilità e una disponibilità maggiori del carico di lavoro. 

 Per i carichi di lavoro con utenti distribuiti in più aree geografiche, AWS Global Accelerator contribuisce a migliorare la disponibilità e le prestazioni delle applicazioni. AWS Global Accelerator fornisce indirizzi IP statici anycast che operano come punto di ingresso statico alle applicazioni ospitate in una o più Regioni AWS. In questo modo, il traffico può entrare nella rete globale AWS il più vicino possibile agli utenti, migliorando la raggiungibilità e la disponibilità del carico di lavoro. AWS Global Accelerator monitora anche l'integrità degli endpoint dell'applicazione usando controlli dell'integrità TCP, HTTP e HTTPS. Eventuali variazioni dell'integrità o della configurazione degli endpoint attivano il reindirizzamento del traffico degli utenti a endpoint integri che offrono le prestazioni e la disponibilità migliori agli utenti. Inoltre, AWS Global Accelerator ha una progettazione di isolamento degli errori che usa due indirizzi IPv4 statici gestiti da zone di rete indipendenti, migliorando la disponibilità delle applicazioni. 

 Per contribuire alla protezione dei clienti da attacchi DDoS, AWS offre AWS Shield Standard. Shield Standard è abilitato per impostazione predefinita e protegge da attacchi comuni contro l'infrastruttura (livelli 3 e 4), come i flood SYN/UDP e gli attacchi di riflessione, in modo da supportare la disponibilità elevata delle applicazioni in AWS. Per altre soluzioni di protezione da attacchi più sofisticati e di maggiore entità (come i flood UDP) e di tipo state-exhaustion (come i flood TCP SYN) e per proteggere le applicazioni in esecuzione su Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator e Route 53, puoi valutare se usare AWS Shield Advanced. Per la protezione da attacchi a livello di applicazione come i flood HTTP POST o GET, usa AWS WAF. AWS WAF può usare indirizzi IP, intestazioni HTTP, corpo HTTP, stringhe URI, iniezione SQL e condizioni di scripting cross-site per determinare se una richiesta debba essere bloccata o consentita. 

 **Passaggi dell'implementazione** 

1.  Configura un sistema DNS a disponibilità elevata: Amazon Route 53 è un servizio Web altamente disponibile e scalabile che opera come [sistema dei nomi di dominio (DNS)](https://aws.amazon.com/route53/what-is-dns/). Route 53 connette le richieste utente ad applicazioni Internet in esecuzione in AWS o on-premise. Per ulteriori informazioni, consulta [Configurazione di Amazon Route 53 come servizio DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html). 

1.  Configura controlli dell'integrità: quando usi Route 53, verifica che solo le destinazioni integre siano risolvibili. Per iniziare, [crea controlli dell'integrità in Route 53 e configura il failover DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html). Nel configurare controlli dell'integrità, è importante tenere conto degli aspetti seguenti: 

   1. [ Modo in cui Amazon Route 53 determina se un controllo dell'integrità ha esito positivo ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html)

   1. [ Creazione, aggiornamento ed eliminazione di controlli dell'integrità ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html)

   1. [ Monitoraggio dello stato dei controlli dell'integrità e ricezione di notifiche ](https://docs.aws.amazon.com/)

   1. [ Best practice per DNS in Amazon Route 53 ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html)

1. [ Connessione del servizio DNS agli endpoint. ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html)

   1.  Quando usi Elastic Load Balancing come destinazione per il traffico, usa Amazon Route 53 per creare un [record alias](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) che punti all'endpoint regionale del sistema di bilanciamento del carico. Durante la creazione del record alias, imposta l'opzione Valutazione dello stato target su Sì. 

   1.  Per carichi di lavoro serverless o API private con API Gateway, usa [Route 53 per indirizzare il traffico ad API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html). 

1.  Opta per una rete di distribuzione di contenuti (CDN). 

   1.  Per distribuire contenuti usando posizioni edge più vicine all'utente, inizia acquisendo familiarità con il [modo in cui CloudFront distribuisce contenuti](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html). 

   1.  Inizia con una [distribuzione semplice di CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.SimpleDistribution.html). CloudFront sa quindi determinare dove vuoi distribuire i contenuti e come monitorare e gestire la distribuzione di contenuti. Nel configurare la distribuzione di CloudFront, è importante tenere conto degli aspetti seguenti: 

      1. [ Funzionamento della memorizzazione nella cache con posizioni edge CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio-explained.html)

      1. [ Aumento della proporzione di richieste gestite direttamente dalle cache CloudFront (tasso di riscontri nella cache) ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html)

      1. [ Uso di Amazon CloudFront Origin Shield ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html)

      1. [ Ottimizzazione della disponibilità elevata con il failover delle origini in CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)

1.  Configura la protezione a livello di applicazione: AWS WAF semplifica la protezione da exploit Web e bot comuni che possono compromettere la disponibilità e la sicurezza o consumare risorse eccessive. Per approfondire questi concetti, consulta [Funzionamento di AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html) e prima di implementare protezioni da flood HTTP POST e GET a livello di applicazione, consulta [Nozioni di base su AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html). Puoi anche usare AWS WAF con CloudFront. Consulta la documentazione sul [funzionamento di AWS WAF con funzionalità di Amazon CloudFront](https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html). 

1.  Configura protezione aggiuntiva da attacchi DDoS: per impostazione predefinita, tutti i clienti AWS ricevono protezione gratuita dagli attacchi DDoS comuni e più frequenti a livello di rete e di trasporto che prendono di mira il sito Web o l'applicazione con AWS Shield Standard. Per una protezione aggiuntiva delle applicazioni con connessione Internet su Amazon EC2, Elastic Load Balancing, Amazon CloudFront, AWS Global Accelerator e Amazon Route 53, puoi prendere in considerazione [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html) e consultare gli [esempi di architetture resilienti ad attacchi DDoS](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-resiliency.html). Per proteggere il carico di lavoro e gli endpoint pubblici da attacchi DDoS, consulta [Nozioni di base su AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-ddos.html). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md) 
+  [REL10-BP02 Selezione delle posizioni appropriate per la tua implementazione multiposizione](rel_fault_isolation_select_location.md) 
+  [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md) 
+  [REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità](rel_withstand_component_failures_notifications_sent_system.md) 

 **Documenti correlati:** 
+  [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [Marketplace AWS per l'infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Che cos'è AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [Che cos'è Amazon CloudFront?](https://docs.aws.amazon.com/Amazon/latest/DeveloperGuide/Introduction.html) 
+  [Che cos'è Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
+  [Che cos'è Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
+ [ Funzionalità di connettività di rete – Come definire gli aspetti di base del cloud ](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/network-connectivity-capability.html)
+ [ Che cos'è Amazon API Gateway? ](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
+ [ Che cosa sono AWS WAF, AWS Shield e AWS Firewall Manager? ](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html)
+ [ Che cos'è il Sistema di controllo Amazon Route 53 per il ripristino di applicazioni? ](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [ Configurazione di controlli dell'integrità personalizzati per il failover DNS ](https://docs.aws.amazon.com/apigateway/latest/developerguide/dns-failover.html)

 **Video correlati:** 
+ [AWS re:Invent 2022: Miglioramento delle prestazioni e della disponibilità con AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)
+ [AWS re:Invent 2020: Gestione del traffico globale con Amazon Route 53 ](https://www.youtube.com/watch?v=E33dA6n9O7I)
+ [AWS re:Invent 2022: Esecuzione di applicazioni multi-AZ a disponibilità elevata ](https://www.youtube.com/watch?v=mwUV5skJJ0s)
+ [AWS re:Invent 2022: Approfondimento dell'infrastruttura di rete AWS](https://www.youtube.com/watch?v=HJNR_dX8g8c)
+ [AWS re:Invent 2022: Creazione di reti resilienti ](https://www.youtube.com/watch?v=u-qamiNgH7Q)

 **Esempi correlati:** 
+ [ Ripristino di emergenza con il Sistema di controllo Amazon Route 53 per il ripristino di applicazioni (ARC) ](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [ Workshop sull'affidabilità ](https://wellarchitectedlabs.com/reliability/)
+ [ Workshop su AWS Global Accelerator](https://catalog.us-east-1.prod.workshops.aws/workshops/effb1517-b193-4c59-8da5-ce2abdb0b656/en-US)

# REL02-BP02 Esecuzione del provisioning di connettività ridondante tra reti private nel cloud e negli ambienti on-premise.
<a name="rel_planning_network_topology_ha_conn_private_networks"></a>

 Utilizza più connessioni AWS Direct Connect o tunnel VPN tra reti private implementate separatamente. Utilizza più ubicazioni Direct Connect per un'elevata disponibilità. Se utilizzi più Regioni AWS, garantisci la ridondanza in almeno due di esse. È possibile valutare le appliance Marketplace AWS che terminano le VPN. Se utilizzi appliance di Marketplace AWS, distribuisci le istanze ridondanti per la disponibilità elevata in diverse zone di disponibilità. 

 AWS Direct Connect è un servizio cloud che semplifica la creazione di una connessione di rete dedicata dall'ambiente on-premise ad AWS. Utilizzando il gateway Direct Connect, il data center on-premise può essere collegato a più VPC AWS distribuiti in più Regioni AWS. 

 Questa ridondanza risolve possibili errori che condizionano la resilienza della connettività: 
+  Come pensi di essere resiliente ai fallimenti nella topologia? 
+  Cosa succede se configuri qualcosa in modo errato e rimuovi la connettività? 
+  Sarai in grado di gestire un inaspettato aumento del traffico o dell'utilizzo dei tuoi servizi? 
+  Sarai in grado di assorbire un tentativo di attacco DDoS (Distributed Denial of Service)? 

 Quando si connette il VPC al data center in locale tramite VPN, si devono considerare i requisiti di resilienza e larghezza di banda necessari quando si seleziona la dimensione del fornitore e dell'istanza su cui è necessario eseguire l'appliance. Se si utilizza un'appliance VPN non resiliente nella sua implementazione, è necessario disporre di una connessione ridondante tramite una seconda appliance. Per tutti questi scenari, è necessario definire un orario accettabile per il ripristino e il test per garantire che sia possibile soddisfare tali requisiti. 

 Se scegli di connettere il VPC al data center utilizzando una connessione Direct Connect e hai bisogno che questa connessione sia altamente disponibile, predisponi connessioni Direct Connect ridondanti da ogni data center. La connessione ridondante dovrebbe utilizzare una seconda connessione Direct Connect da una posizione diversa rispetto alla prima. Se disponi di più data center, assicurati che le connessioni terminino in posizioni diverse. Utilizza il [Kit di strumenti di resilienza Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) come ausilio per la configurazione. 

 Se scegli di eseguire il failover sul VPN su Internet utilizzando Site-to-Site VPN, è importante capire che supporta fino a 1,25 Gbps di velocità di trasmissione effettiva per tunnel VPN, ma non supporta Equal Cost Multi Path (ECMP) per il traffico in uscita nel caso di più tunnel VPN gestiti da AWS che terminano sullo stesso gateway privato virtuale (VGW). Non è consigliabile utilizzare VPN gestite da AWS come backup per le connessioni Direct Connect, a meno che non sia possibile tollerare velocità inferiori a 1 Gbps durante il failover. 

 Puoi anche utilizzare gli endpoint VPC per connettere privatamente il tuo VPC ai servizi AWS supportati e ai servizi endpoint VPC basati su AWS PrivateLink senza dover attraversare la rete Internet pubblica. Gli endpoint sono dispositivi virtuali. Sono componenti VPC a scalabilità orizzontale, ridondanti e ad alta disponibilità. Consentono la comunicazione tra le istanze nel VPC e i servizi senza imporre rischi di disponibilità o vincoli di larghezza di banda sul traffico di rete. 

 **Anti-pattern comuni:** 
+  Avere un solo provider di connettività tra la rete in locale e AWS. 
+  Utilizzare le funzionalità di connettività della connessione AWS Direct Connect, ma con una sola connessione. 
+  Disporre di un solo percorso per la connettività VPN. 

 **Vantaggi dell'adozione di questa best practice:** implementando una connettività ridondante tra il tuo ambiente cloud e l'ambiente aziendale/on-premise, puoi garantire che i servizi dipendenti tra i due ambienti possano comunicare in maniera affidabile. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Garantire una connettività altamente disponibile tra AWS e l'ambiente on-premise. Utilizza più connessioni AWS Direct Connect o tunnel VPN tra reti private implementate separatamente. Utilizza più ubicazioni Direct Connect per un'elevata disponibilità. Se utilizzi più Regioni AWS, garantisci la ridondanza in almeno due di esse. È possibile valutare le appliance Marketplace AWS che terminano le VPN. Se utilizzi appliance di Marketplace AWS, distribuisci le istanze ridondanti per la disponibilità elevata in diverse zone di disponibilità. 
  +  Assicurati di avere una connessione ridondante con l'ambiente on-premise Potresti aver bisogno di connessioni ridondanti a più Regioni AWS per soddisfare le tue esigenze di disponibilità. 
    +  [Suggerimenti sulla resilienza di AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/) 
    +  [Utilizzo di connessioni VPN da sito a sito ridondanti per fornire il failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) 
      +  Utilizza le operazioni delle API di servizi per identificare l'utilizzo corretto dei circuiti Direct Connect. 
        +  [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html) 
        +  [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html) 
        +  [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html) 
        +  [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll) 
        +  [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html) 
        +  [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html) 
        +  [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html) 
      +  Se esiste una sola connessione Direct Connect o se non ne hai nessuna, crea dei tunnel VPN ridondanti verso i tuoi gateway privati virtuali (VGW). 
        +  [Cos'è VPN sito-sito AWS?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html) 
  +  Acquisisci la tua attuale connettività (ad esempio, Direct Connect, gateway privati virtuali, appliance Marketplace AWS). 
    +  Utilizza le operazioni delle API di servizi per eseguire la query della configurazione delle connessioni Direct Connect. 
      +  [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html) 
      +  [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html) 
      +  [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html) 
      +  [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll) 
      +  [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html) 
      +  [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html) 
      +  [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html) 
    +  Utilizza le operazioni delle API di servizi per raccogliere i gateway privati virtuali (VGW) dove vengono utilizzati dalle tabelle di instradamento. 
      +  [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html) 
      +  [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) 
    +  Utilizza le operazioni delle API di servizi per raccogliere le applicazioni di Marketplace AWS dove vengono utilizzate dalle tabelle di instradamento. 
      +  [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [Suggerimenti sulla resilienza di AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/) 
+  [Marketplace AWS per l'infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Whitepaper: Opzioni di connettività di Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Connettività di rete di elevata disponibilità in più data center](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Utilizzo di connessioni VPN da sito a sito ridondanti per fornire il failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) 
+  [Utilizzo del kit di strumenti di resilienza di Direct Connect per iniziare](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) 
+  [Endpoint VPC e servizi di endpoint VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 
+  [Che cos'è Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [Che cos'è un Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
+  [Cos'è VPN sito-sito AWS?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html) 
+  [Lavorare con gateway Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) 

 **Video correlati:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (Progettazione avanzata di VPC e nuove funzionalità per Amazon VPC) (NET303) ](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (Architetture di riferimento del Gateway di transito AWS per molte VPC) (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP03 Verifica che l'allocazione delle sottoreti IP consenta l'espansione e la disponibilità:
<a name="rel_planning_network_topology_ip_subnet_allocation"></a>

 Gli intervalli di indirizzi IP dei Amazon VPC devono essere sufficientemente ampi per soddisfare i requisiti del carico di lavoro, tenendo conto anche dell'espansione futura e dell'allocazione degli indirizzi IP alle sottoreti nelle zone di disponibilità. Sono inclusi sistemi di bilanciamento del carico, istanze EC2 e applicazioni basate su container. 

 Quando si pianifica la topologia di rete, il primo passo è definire lo spazio stesso degli indirizzi IP. Gli intervalli di indirizzi IP privati (secondo le linee guida RFC 1918) dovrebbero essere allocati per ogni VPC. Nell'ambito di questo processo, soddisfa i seguenti requisiti: 
+  Lascia spazi per indirizzi IP per più di un VPC per Regione. 
+  All'interno di un VPC, lascia spazio per più sottoreti che coprono più zone di disponibilità. 
+  Lascia sempre spazio per un blocco CIDR inutilizzato all'interno di un VPC per un'espansione futura. 
+  Assicurati che sia disponibile spazio per gli indirizzi IP, al fine di soddisfare le esigenze di qualsiasi parco istanze EC2 transitorio che puoi utilizzare, ad esempio parchi istanze Spot per il machine learning, cluster Amazon EMR o cluster Amazon Redshift. 
+  Tieni presente che i primi quattro indirizzi IP e l'ultimo indirizzo IP in ogni blocco CIDR della sottorete sono riservati e non disponibili per l'uso. 
+  È consigliabile pianificare la distribuzione di blocchi CIDR VPC di grandi dimensioni. Tieni presente che il blocco CIDR VPC iniziale allocato al VPC non può essere modificato o eliminato, ma puoi aggiungere ulteriori blocchi CIDR non sovrapposti al VPC. I CIDR IPv4 della sottorete non possono essere modificati, mentre ciò è possibile con i CIDR IPv6. Tieni presente che la distribuzione del VPC più grande possibile (/16) genera oltre 65.000 indirizzi IP. Solo nello spazio degli indirizzi IP di base 10.x.x.x potresti effettuare il provisioning di 255 VPC di questo tipo. Pertanto, dovresti peccare per eccesso piuttosto che per difetto per semplificare la gestione dei VPC. 

 **Anti-pattern comuni:** 
+  Creazione di VPC di piccole dimensioni. 
+  Creare sottoreti di piccole dimensioni e dover quindi aggiungere sottoreti alle configurazioni man mano che cresci. 
+  Stima erronea del numero di indirizzi IP che un elastic load balancer può utilizzare. 
+  Distribuzione di numerosi sistemi di bilanciamento del carico a traffico elevato nelle stesse sottoreti. 

 **Vantaggi dell'adozione di questa best practice:** In questo modo puoi consentire la crescita dei carichi di lavoro e continuare a fornire disponibilità man mano che incrementi le dimensioni. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Pianificazione della rete in base a crescita, compliance normativa e integrazione con altre reti. Senza una pianificazione adeguata, la crescita può essere sottovalutata, la compliance normativa può cambiare e l'implementazione di acquisizioni o di connessioni a reti private può rivelarsi difficile. 
  +  Seleziona gli Account AWS e le Regioni pertinenti in base ai tuoi requisiti di servizio, di latenza, normativi e di ripristino di emergenza. 
  +  Identifica le esigenze delle implementazioni di VPC regionali. 
  +  Identifica le dimensioni dei VPC. 
    +  Stabilisci se intendi implementare connettività multi-VPC. 
      +  [Che cos'è un Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
      +  [Connettività multi-VPC a singola Regione](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) 
    +  Stabilisci se hai bisogno di reti separate a causa di requisiti normativi. 
    +  Fai in modo che i VPC abbiano le dimensioni maggiori possibili. Il blocco CIDR VPC iniziale allocato al VPC non può essere modificato o eliminato, ma puoi aggiungere ulteriori blocchi CIDR non sovrapposti al VPC. Tuttavia, questo potrebbe frammentare gli intervalli degli indirizzi. 
    +  Fai in modo che i VPC abbiano le dimensioni maggiori possibili. Il blocco CIDR VPC iniziale allocato al VPC non può essere modificato o eliminato, ma puoi aggiungere ulteriori blocchi CIDR non sovrapposti al VPC. Tuttavia, questo potrebbe frammentare gli intervalli degli indirizzi. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [Marketplace AWS per l'infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Whitepaper: Opzioni di connettività di Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Connettività di rete di elevata disponibilità in più data center](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Connettività multi-VPC a singola Regione](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) 
+  [Che cos'è Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 

 **Video correlati:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (Progettazione avanzata di VPC e nuove funzionalità per Amazon VPC) (NET303) ](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (Architetture di riferimento del Gateway di transito AWS per molte VPC) (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP04 Preferire topologie hub-and-spoke rispetto a mesh da-molti-a-molti
<a name="rel_planning_network_topology_prefer_hub_and_spoke"></a>

 Se più di due spazi di indirizzi di rete (ad esempio, VPC e reti on-premise) sono connessi tramite peering VPC, AWS Direct Connect o VPN, utilizza un modello hub-and-spoke, come quello fornito da AWS Transit Gateway. 

 Se disponi solo di due reti di questo tipo, puoi semplicemente connetterle tra loro, tuttavia, man mano che il numero di reti cresce, la complessità di tali connessioni mesh diventa insostenibile. AWS Transit Gateway offre un modello hub-and-spoke di facile manutenzione, consentendo l'instradamento del traffico su più reti. 

![\[Diagramma che mostra il non utilizzo di AWS Transit Gateway\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/without-transit-gateway.png)


![\[Diagramma che mostra l'utilizzo di AWS Transit Gateway\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/with-transit-gateway.png)


 **Anti-pattern comuni:** 
+  Utilizzo del peering VPC per connettere più di due VPC. 
+  Creazione di più sessioni BGP per ogni VPC per stabilire una connettività che si estende su cloud privati virtuali (VPC, Virtual Private Cloud) distribuiti in più Regioni AWS. 

 **Vantaggi dell'adozione di questa best practice:** Man mano che il numero di reti cresce, la complessità di tali connessioni mesh diventa insostenibile. AWS Transit Gateway offre un modello hub-and-spoke di facile manutenzione, consentendo l'instradamento del traffico su più reti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Preferire topologie hub-and-spoke rispetto a mesh da-molti-a-molti. Se più di due spazi di indirizzi di rete (VPC, reti on-premise) sono connessi tramite peering VPC, AWS Direct Connect o VPN, utilizza un modello hub-and-spoke, come quello fornito da AWS Transit Gateway. 
  +  Se disponi solo di due reti di questo tipo, puoi semplicemente connetterle tra loro, tuttavia, man mano che il numero di reti cresce, la complessità di tali connessioni mesh diventa insostenibile. AWS Transit Gateway offre un modello hub-and-spoke di facile manutenzione, consentendo l'instradamento del traffico su più reti. 
    +  [Che cos'è un Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [Marketplace AWS per l'infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Connettività di rete di elevata disponibilità in più data center](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Endpoint VPC e servizi di endpoint VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 
+  [Che cos'è Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [Che cos'è un Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 

 **Video correlati:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (Progettazione avanzata di VPC e nuove funzionalità per Amazon VPC) (NET303) ](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (Architetture di riferimento del Gateway di transito AWS per molte VPC) (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP05 Applicazione di intervalli di indirizzi IP privati non sovrapposti in tutti gli spazi con indirizzi privati a cui sono connessi
<a name="rel_planning_network_topology_non_overlap_ip"></a>

 Gli intervalli di indirizzi IP di ogni VPC non devono sovrapporsi quando collegati in peering o connessi tramite VPN. Analogamente, è necessario evitare conflitti di indirizzi IP tra un VPC e ambienti in locale o con altri provider di servizi cloud utilizzati. Bisogna inoltre disporre di un modo per allocare gli intervalli di indirizzi IP privati quando necessario. 

 Un sistema di gestione degli indirizzi IP (IPAM) può aiutarti in questo. Su Marketplace AWS sono disponibili diversi IPAM. 

 **Anti-pattern comuni:** 
+  Utilizzo nel VPC dello stesso intervallo IP utilizzato in locale o nella rete aziendale. 
+  Non tenere traccia degli intervalli IP dei VPC utilizzati per distribuire i carichi di lavoro. 

 **Vantaggi dell'adozione di questa best practice:** La pianificazione attiva della rete garantisce di non avere più occorrenze dello stesso indirizzo IP nelle reti interconnesse. In questo modo si evitano problemi di instradamento in parti del carico di lavoro che utilizzano le diverse applicazioni. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Monitora e gestisci l'uso di CIDR. Valuta il tuo utilizzo potenziale su AWS, aggiungi intervalli CIDR ai VPC esistenti e crea i VPC per consentire la crescita pianificata dell'utilizzo. 
  +  Acquisisci il consumo attuale di CIDR (ad esempio, VPC e sottoreti) 
    +  Utilizza le operazioni delle API di servizi per raccogliere il consumo attuale di CIDR. 
  +  Acquisisci l'utilizzo attuale delle sottoreti. 
    +  Utilizza le operazioni delle API di servizio per raccogliere le sottoreti per VPC in ogni Regione. 
      +  [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html) 
    +  Registra l'uso attuale. 
    +  Verifica se hai creato intervalli di indirizzi IP sovrapposti. 
    +  Calcola la capacità inutilizzata. 
    +  Individua gli intervalli di indirizzi IP sovrapposti. Puoi eseguire la migrazione a un nuovo intervallo di indirizzi o utilizzare le appliance NAT (Network and Port Translation) di Marketplace AWS se hai l'esigenza di connettere gli intervalli sovrapposti. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [Marketplace AWS per l'infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Whitepaper: Opzioni di connettività di Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Connettività di rete di elevata disponibilità in più data center](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Che cos'è Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [Che cos'è IPAM?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) 

 **Video correlati:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (Progettazione avanzata di VPC e nuove funzionalità per Amazon VPC) (NET303) ](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (Architetture di riferimento del Gateway di transito AWS per molte VPC) (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# Architettura del carico di lavoro
<a name="a-workload-architecture"></a>

**Topics**
+ [REL 3. Come si progetta l'architettura del servizio di carico di lavoro?](rel-03.md)
+ [REL 4. Come si progettano le interazioni in un sistema distribuito per evitare errori?](rel-04.md)
+ [REL 5. Come si progettano le interazioni in un sistema distribuito per mitigare o affrontare gli errori?](rel-05.md)

# REL 3. Come si progetta l'architettura del servizio di carico di lavoro?
<a name="rel-03"></a>

Creazione di carichi di lavoro altamente scalabili e affidabili utilizzando un'architettura orientata ai servizi (SOA) o un'architettura di microservizi. L'architettura orientata ai servizi (SOA) è la pratica di rendere i componenti software riutilizzabili tramite interfacce di servizio. L'architettura dei microservizi va oltre, per rendere i componenti più piccoli e semplici.

**Topics**
+ [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornitura di contratti di servizio per API](rel_service_architecture_api_contracts.md)

# REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro
<a name="rel_service_architecture_monolith_soa_microservice"></a>

 La segmentazione del carico di lavoro è importante quando vengono determinati i requisiti di resilienza dell'applicazione. L'architettura monolitica deve essere evitata se possibile. Valuta invece con particolare attenzione quali componenti dell'applicazione possono essere suddivisi in microservizi. A seconda dei requisiti dell'applicazione, ciò potrebbe risultare in una combinazione di architettura orientata ai servizi (SOA) e microservizi, laddove possibile. I carichi di lavoro stateless sono maggiormente idonei a essere implementati come microservizi. 

 **Risultato desiderato:** i carichi di lavoro devono essere supportabili, scalabili e devono essere caratterizzati dalla minore interdipendenza possibile. 

 Quando scegli come segmentare il carico di lavoro, trova il giusto compromesso tra i vantaggi e le complessità. Ciò che è giusto per un nuovo prodotto al primo lancio è diverso dai requisiti di un carico di lavoro creato per ridimensionare le risorse. Durante la rifattorizzazione (riprogettazione) di un monolito, dovrai considerare la capacità dell'applicazione di supportare la suddivisione in servizi stateless. La suddivisione dei servizi in elementi più piccoli consente a team ristretti e ben definiti di svilupparli e gestirli. Tuttavia, servizi di piccole dimensioni possono introdurre complessità, che includono un eventuale aumento della latenza, un debug più complesso e un maggiore carico operativo. 

 **Anti-pattern comuni:** 
+  Il [microservizio *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) rappresenta una situazione in cui i componenti atomici diventano così interdipendenti che un errore verificatosi in un componente genera un errore molto più grande, rendendo i componenti rigidi e fragili se considerati come monolito. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Segmenti più specifici comportano maggiore agilità, flessibilità organizzativa e scalabilità. 
+  Riduzione dell'impatto derivante dall'interruzione dei servizi. 
+  I componenti dell'applicazione possono avere requisiti di disponibilità diversi, che a loro volta possono essere supportati da una segmentazione più atomica. 
+  Responsabilità ben definite per i team che supportano il carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Scegli il tipo di architettura in base al tipo di segmentazione del carico di lavoro. Scegli una SOA o un'architettura di microservizi (o, in alcuni rari casi, un'architettura monolitica). Anche se scegli di iniziare con un'architettura monolitica, devi assicurarti che sia modulare e possa evolvere in SOA o microservizi man mano che il prodotto si dimensiona con l'adozione da parte degli utenti. La SOA e i microservizi offrono rispettivamente una segmentazione più piccola, preferita come architettura moderna scalabile e affidabile, ma ci sono compromessi da considerare soprattutto quando si distribuisce un'architettura di microservizi. 

 Uno dei principali compromessi è che ora disponi di un'architettura di calcolo distribuita che può rendere più difficile il raggiungimento dei requisiti di latenza degli utenti ed è presente un'ulteriore complessità nel debug e nel tracciamento delle interazioni degli utenti. Puoi utilizzare AWS X-Ray per risolvere questo problema. Un altro effetto da considerare è l'aumento della complessità operativa man mano che aumenta il numero di applicazioni che gestisci, che richiede la distribuzione di più componenti di indipendenza. 

![\[Diagramma che illustra il confronto tra architettura monolitica, orientata ai servizi e di microservizi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/monolith-soa-microservices-comparison.png)


## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Determina l'architettura più appropriata per rifattorizzare (riprogettare) o creare l'applicazione. SOA e microservizi offrono segmentazione rispettivamente di dimensioni minori, preferita in quanto architettura moderna, scalabile e affidabile. SOA può essere un buon compromesso per ottenere una segmentazione di dimensioni minori, evitando al contempo alcune delle complessità dei microservizi. Per ulteriori dettagli, consulta [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html). 
+  Se il carico di lavoro è adatto e la tua organizzazione può supportarla, è consigliabile utilizzare un'architettura di microservizi per ottenere la massima agilità e affidabilità. Per ulteriori dettagli, consulta [Implementing Microservices on AWS (Implementazione di microservizi in AWS).](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  Considera l'ipotesi di attenerti al modello [*Strangler* Fig](https://martinfowler.com/bliki/StranglerFigApplication.html) per eseguire la rifattorizzazione (riprogettazione) di un monolito in componenti più piccoli. Ciò comporta la graduale sostituzione di componenti specifici dell'applicazione con nuove applicazioni e nuovi servizi. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) funge da punto di partenza per la rifattorizzazione incrementale. Per ulteriori dettagli, consulta [Seamlessly migrate on-premises legacy workloads using a strangler pattern (Migrazione senza problemi di carichi di lavoro legacy on-premise mediante un modello Strangler)](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/). 
+  L'implementazione di microservizi può richiedere un meccanismo di individuazione dei servizi per consentire ai servizi distribuiti di comunicare tra loro. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) può essere utilizzato con architetture orientate ai servizi per offrire rilevamento e accesso affidabili ai servizi. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) può inoltre essere utilizzato per il rilevamento dinamico dei servizi basato su DNS. 
+  In caso di migrazione da un monolito a una SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) può aiutare a colmare il divario come bus del servizio durante la riprogettazione delle applicazioni legacy nel cloud.
+  Per i monoliti esistenti con un unico database condiviso, scegli come riorganizzare i dati in segmenti più piccoli. Questa riorganizzazione può avvenire per unità aziendale, schema di accesso o struttura dei dati. A questo punto del processo di rifattorizzazione (riprogettazione), deve orientare la scelta verso un database di tipo relazionale o non relazionale (NoSQL). Per ulteriori dettagli, consulta [From SQL to NoSQL (Da SQL a NoSQL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html). 

 **Livello di impegno per il piano di implementazione:** alto 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md) 

 **Documenti correlati:** 
+  [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [Cosa si intende per architettura orientata ai servizi?](https://aws.amazon.com/what-is/service-oriented-architecture/) 
+  [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html) 
+  [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html) 
+  [Microservizi: una definizione di questo nuovo termine di architettura](https://www.martinfowler.com/articles/microservices.html) 
+  [Implementazione di microservizi in AWS](https://aws.amazon.com/microservices/) 
+  [What is AWS App Mesh? (Che cos'è AWS App Mesh?)](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) 

 **Esempi correlati:** 
+  [Iterative App Modernization Workshop (Workshop sulla modernizzazione delle applicazioni interattive)](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro) 

 **Video correlati:** 
+  [Delivering Excellence with Microservices on AWS (Implementazione dell'eccellenza con i microservizi in AWS)](https://www.youtube.com/watch?v=otADkIyugzY) 

# REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici
<a name="rel_service_architecture_business_domains"></a>

L'architettura orientata ai servizi (SOA) definisce servizi con funzioni ben delineate determinate dalle esigenze aziendali. I microservizi utilizzano modelli di dominio e contesto delimitato per tracciare i limiti dei servizi lungo i confini del contesto aziendale. Concentrarsi sui domini e sulle funzionalità aziendali aiuta i team a definire requisiti di affidabilità indipendenti per i propri servizi. I contesti delimitati isolano e incapsulano la logica aziendale, consentendo ai team di ragionare meglio su come gestire gli errori.

 **Risultato desiderato:** ingegneri e parti interessate aziendali definiscono congiuntamente contesti delimitati e li utilizzano per progettare sistemi come servizi che soddisfano funzioni aziendali specifiche. Questi team utilizzano pratiche consolidate come l'event storming per definire i requisiti. Le nuove applicazioni sono concepite come servizi con confini ben definiti e con accoppiamento debole. I monoliti esistenti vengono scomposti in [contesti delimitati](https://martinfowler.com/bliki/BoundedContext.html) e la progettazione dei sistemi si sposta verso architetture SOA o microservizi. Quando i monoliti vengono rifattorizzati, vengono applicati approcci consolidati come contesti a bolle e schemi di decomposizione dei monoliti. 

 I servizi orientati al dominio vengono eseguiti come uno o più processi che non condividono lo stato. Rispondono in modo indipendente alle fluttuazioni della domanda e gestiscono gli scenari di errore alla luce dei requisiti specifici del dominio. 

 **Anti-pattern comuni:** 
+  I team sono formati su domini tecnici specifici come UI e UX, middleware o database anziché su domini aziendali specifici. 
+  Le applicazioni coprono le responsabilità di dominio. I servizi che coprono contesti delimitati possono essere più difficili da gestire, richiedere maggiori sforzi di test ed esigere la partecipazione di più team di dominio agli aggiornamenti software. 
+  Le dipendenze a livello di dominio, come le librerie di entità di dominio, sono condivise tra i servizi, in modo che le modifiche per il dominio di un servizio richiedano modifiche ad altri domini dei servizi. 
+  I contratti di servizio e la logica aziendale non esprimono le entità in un linguaggio di dominio comune e coerente, con il risultato di livelli di traduzione che complicano i sistemi e aumentano le attività di debug. 

 **Vantaggi dell'adozione di questa best practice:** le applicazioni sono progettate come servizi indipendenti limitati da domini aziendali e utilizzano un linguaggio aziendale comune. I servizi sono testabili e implementabili in modo indipendente. I servizi soddisfano i requisiti di resilienza specifici del dominio implementato. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 La decisione basata sul dominio (DDD) costituisce l'approccio fondamentale alla progettazione e alla creazione di software attorno ai domini aziendali. È utile utilizzare un framework esistente quando si creano servizi incentrati sui domini aziendali. Quando si utilizzano applicazioni monolitiche esistenti, è possibile sfruttare i modelli di decomposizione che forniscono tecniche consolidate per modernizzare le applicazioni in servizi. 

![\[Diagramma di flusso che illustra l'approccio incentrato sulla decisione basata sul dominio.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/domain-driven-decision.png)


 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  I team possono organizzare eventi di [event storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming) per identificare rapidamente eventi, comandi, aggregati e domini. 
+  Una volta che le entità e le funzioni di dominio sono state definite in un contesto di dominio, puoi dividere il tuo dominio in servizi utilizzando il [contesto delimitato](https://martinfowler.com/bliki/BoundedContext.html), dove le entità che condividono caratteristiche e attributi simili vengono raggruppate insieme. Con il modello diviso in contesti, emerge un modello su come delimitare i microservizi. 
  +  Ad esempio, le entità del sito Web Amazon.com possono includere elementi quali pacchetti, distribuzione, pianificazione, prezzo, sconto e valuta. 
  +  Il pacchetto, la distribuzione e la pianificazione sono raggruppati nel contesto di spedizione, mentre il prezzo, lo sconto e la valuta sono raggruppati nel contesto dei prezzi. 
+  [Scomporre i monoliti in microservizi](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) delinea i modelli per la rifattorizzazione dei microservizi. L'utilizzo di modelli per la decomposizione in base a capacità aziendale, sottodominio o transazione si allinea bene agli approcci basati sul dominio. 
+  Tecniche di strategia come il [contesto a bolle](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) consentono di introdurre la decisione basata sul dominio (DDD) in applicazioni esistenti o precedenti senza riscritture anticipate e impegni completi nei confronti di DDD. In un approccio basato sul contesto a bolle, viene stabilito un contesto delimitato utilizzando una mappatura e un coordinamento dei servizi, oppure il [livello anti-danneggiamento (ACL)](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context), che protegge il modello di dominio appena definito dalle influenze esterne. 

 Dopo aver eseguito l'analisi del dominio e definito le entità e i contratti di servizio, i team possono utilizzare i servizi AWS per implementare la progettazione basata sul dominio come servizi basati sul cloud. 
+  Inizia a sviluppare definendo test che applichino le regole aziendali del tuo dominio. Lo sviluppo basato sui test (TDD) e lo sviluppo basato sul comportamento (BDD) aiutano i team a focalizzare i servizi sulla risoluzione dei problemi aziendali. 
+  Seleziona i [servizi AWS](https://aws.amazon.com/microservices/) che soddisfano al meglio i requisiti del tuo dominio aziendale e l' [architettura di microservizi](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html): 
  +  [AWS Serverless](https://aws.amazon.com/serverless/) consente al team di concentrarsi su una logica di dominio specifica anziché sulla gestione di server e infrastrutture. 
  +  [I container in AWS](https://aws.amazon.com/containers/) semplificano la gestione della tua infrastruttura, in modo da poterti concentrare sui requisiti del tuo dominio. 
  +  [I database dedicati](https://aws.amazon.com/products/databases/) ti aiutano ad adattare i requisiti del tuo dominio al tipo di database più idoneo. 
+  [La creazione di architetture esagonali su AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) delinea un framework per integrare la logica aziendale nei servizi che funzionano a ritroso da un dominio aziendale per soddisfare i requisiti funzionali e, quindi, per collegare adattatori di integrazione. I modelli che separano i dettagli dell'interfaccia dalla logica aziendale con i servizi AWS aiutano i team a concentrarsi sulla funzionalità del dominio e a migliorare la qualità del software. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL03-BP03 Fornitura di contratti di servizio per API](rel_service_architecture_api_contracts.md) 

 **Documenti correlati:** 
+ [Microservizi AWS](https://aws.amazon.com/microservices/)
+  [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [How to break a Monolith into Microservices (Come trasformare un monolite in microservizi)](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
+  [Getting Started with DDD when Surrounded by Legacy Systems (Iniziare con il DDD quando si è circondati da sistemi legacy)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
+ [ Domain-Driven Design: Tackling Complexity in the Heart of Software (Progettazione basata sul dominio: affrontare la complessità al cuore del software) ](https://www.amazon.com/gp/product/0321125215)
+ [ La creazione di architetture esagonali su AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Scomporre i monoliti in microservizi ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [ Event Storming ](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [ Messaggi tra contesti limitati ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Microservizi ](https://www.martinfowler.com/articles/microservices.html)
+ [ Sviluppo basato su test ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Sviluppo basato sul comportamento ](https://en.wikipedia.org/wiki/Behavior-driven_development)

 **Esempi correlati:** 
+ [ Workshop sul cloud aziendale nativo ](https://catalog.us-east-1.prod.workshops.aws/workshops/0466c70e-4216-4352-98d9-5a8af59c86b2/en-US)
+ [ Progettazione di microservizi cloud nativi su AWS (da DDD/EventStormingWorkshop) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)

 **Strumenti correlati:** 
+ [ Database su Cloud AWS](https://aws.amazon.com/products/databases/)
+ [ Serverless su AWS](https://aws.amazon.com/serverless/)
+ [ Container in AWS](https://aws.amazon.com/containers/)

# REL03-BP03 Fornitura di contratti di servizio per API
<a name="rel_service_architecture_api_contracts"></a>

I contratti di assistenza sono accordi documentati tra produttori di API e utenti definiti in una definizione di API leggibile dal computer. Una strategia di controllo delle versioni dei contratti consente agli utenti di continuare a utilizzare l'API esistente e migrare le applicazioni a un'API più recente quando sono pronte. L'implementazione da parte del produttore può avvenire in qualsiasi momento, purché il processo sia conforme al contratto. Il team dei servizi può utilizzare lo stack tecnologico scelto per soddisfare il contratto API. 

 **Risultato desiderato:** 

 **Anti-pattern comuni:** Le applicazioni realizzate con architetture orientate ai servizi o con architetture di microservizi sono in grado di funzionare in modo indipendente pur essendo caratterizzate da una dipendenza dal runtime integrata. Le modifiche apportate a un utente o produttore di API non pregiudicano la stabilità dell'intero sistema quando entrambe le parti sono conformi a un contratto API comune. I componenti che comunicano tramite le API di servizio possono eseguire release funzionali indipendenti, aggiornamenti delle dipendenze di runtime o eseguire il failover su un sito di ripristino di emergenza con un impatto reciproco minimo o nullo. Inoltre, i servizi discreti sono in grado di eseguire il dimensionamento in modo indipendente assorbendo la richiesta di risorse senza che gli altri servizi debbano ridimensionarsi di conseguenza. 
+  Creazione di API di servizio senza schemi fortemente tipizzati. Ciò si traduce in API che non possono essere utilizzate per generare collegamenti API e payload che non possono essere convalidati a livello di codice. 
+  Non adottare una strategia di controllo delle versioni, che costringa gli utenti delle API all'aggiornamento e rilascio o all'esito negativo dell'operazione al variare dei contratti di servizio. 
+  Messaggi di errore che divulgano dettagli sull'implementazione del servizio sottostante anziché descrivere errori di integrazione nel contesto e nel linguaggio del dominio. 
+  Non utilizzare contratti API per sviluppare casi di test e simulare implementazioni API per consentire test indipendenti dei componenti del servizio. 

 **Vantaggi dell'adozione di questa best practice:** i sistemi distribuiti composti da componenti che comunicano tramite contratti di servizio API possono migliorare l'affidabilità. Gli sviluppatori possono rilevare potenziali problemi nelle prime fasi del processo di sviluppo con il controllo del tipo durante la compilazione per verificare che le richieste e le risposte siano conformi al contratto API e che i campi obbligatori siano presenti. I contratti API forniscono una chiara interfaccia di documentazione automatica per le API e garantiscono una migliore interoperabilità tra sistemi e linguaggi di programmazione diversi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Dopo aver individuato i domini aziendali e determinato la segmentazione del carico di lavoro, puoi sviluppare le API dei tuoi servizi. Innanzitutto, definisci contratti di servizio leggibili dal computer per le API, quindi implementa una strategia di controllo delle versioni delle API. Quando sei pronto per integrare servizi su protocolli comuni come REST, GraphQL o eventi asincroni, puoi incorporare servizi AWS nell'architettura per integrare i componenti con contratti API fortemente tipizzati. 

 **I servizi AWS per i contratti API di servizio** 

 includono servizi AWS come [Amazon API Gateway](https://aws.amazon.com/api-gateway/), [AWS AppSync](https://aws.amazon.com/appsync/)e [Amazon EventBridge](https://aws.amazon.com/eventbridge/) nell'architettura per utilizzare i contratti di servizio API nell'applicazione. Amazon API Gateway è un valido supporto per l'integrazione con i servizi AWS direttamente nativi e altri servizi Web. API Gateway supporta la [specifica OpenAPI](https://github.com/OAI/OpenAPI-Specification) e il controllo delle versioni. AWS AppSync è un endpoint [gestito da GraphQL](https://graphql.org/) configurato definendo uno schema GraphQL per definire un'interfaccia di servizio per query, mutazioni e sottoscrizioni. Amazon EventBridge utilizza schemi di eventi per definire eventi e generare associazioni di codice per gli eventi. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Definisci innanzitutto un contratto per la tua API. Un contratto esprimerà le capacità di un'API e definirà oggetti e campi di dati fortemente tipizzati per l'input e l'output dell'API. 
+  Quando configuri le API in API Gateway, puoi importare ed esportare le specifiche OpenAPI per gli endpoint. 
  +  [L'importazione di una definizione OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) semplifica la creazione dell'API e può essere integrata con l'infrastruttura AWS come strumenti di codice come [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) e [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/). 
  +  [L'esportazione di una definizione API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) semplifica l'integrazione con gli strumenti di test delle API e fornisce agli utenti di servizi una specifica di integrazione. 
+  Puoi definire e gestire le API GraphQL con AWS AppSync [mediante la definizione di un file di schema GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) per generare l'interfaccia del contratto e semplificare l'interazione con modelli REST complessi, più tabelle di database o servizi legacy. 
+  [I progetti AWS Amplify](https://aws.amazon.com/amplify/) integrati con AWS AppSync generano file di query JavaScript fortemente tipizzati da utilizzare nell'applicazione, nonché una libreria client GraphQL AWS AppSync per le tabelle [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) . 
+  Quando si utilizzano eventi di servizio da Amazon EventBridge, gli eventi sono conformi agli schemi già esistenti nel registro degli schemi o definiti con la specifica OpenAPI. Con uno schema definito nel registro, puoi anche generare associazioni client dal contratto dello schema per integrare il codice con gli eventi. 
+  Estensione o definizione della versione dell'API. L'estensione di un'API è un'opzione più semplice quando si aggiungono campi che possono essere configurati con campi facoltativi o valori predefiniti per i campi obbligatori. 
  +  I contratti basati su JSON per protocolli come REST e GraphQL possono essere adatti per l'estensione del contratto. 
  +  I contratti basati su XML per protocolli come SOAP devono essere testati con gli utenti dei servizi per determinare se l'estensione del contratto è possibile. 
+  Quando esegui il controllo delle versioni di un'API, valuta la possibilità di implementare il controllo delle versioni proxy laddove un lato viene usato per supportare le versioni in modo che la logica possa essere gestita in un'unica base di codice. 
  +  Con API Gateway puoi usare [mappature di richieste e risposte](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) per semplificare l'inclusione delle modifiche del contratto stabilendo un lato per fornire valori predefiniti per i nuovi campi o per eliminare i campi rimossi da una richiesta o una risposta. Con questo approccio, il servizio sottostante può avere un'unica base di codice. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md) 
+  [REL04-BP02 Implementazione di dipendenze "loosely coupled"](rel_prevent_interaction_failure_loosely_coupled_system.md) 
+  [REL05-BP03 Controllo e limitazione delle chiamate di ripetizione](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL05-BP05 Impostazione dei timeout dei client](rel_mitigate_interaction_failure_client_timeouts.md) 

 **Documenti correlati:** 
+ [ Cos'è un'interfaccia di programmazione dell'applicazione (API)? ](https://aws.amazon.com/what-is/api/)
+ [ Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ I compromessi dei microservizi ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [ Microservizi: una definizione di questo nuovo termine di architettura ](https://www.martinfowler.com/articles/microservices.html)
+ [ Microservizi in AWS](https://aws.amazon.com/microservices/)
+ [ Utilizzo delle estensioni API Gateway di OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [ Specifica OpenAPI ](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL: schemi e tipi ](https:/graphql.org/learn/schema)
+ [ Associazioni di codice Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)

 **Esempi correlati:** 
+ [ Amazon API Gateway: configurazione di una REST API mediante OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [ Applicazione CRUD da Amazon API Gatewaya Amazon DynamoDB utilizzando OpenAPI ](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [ Modelli di integrazione di applicazioni moderne in un'era serverless: integrazione dei servizi API Gateway ](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [ Implementazione del controllo delle versioni API Gateway basato sull'intestazione con Amazon CloudFront ](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: creazione di un'applicazione client ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)

 **Video correlati:** 
+ [ Utilizzo di OpenAPI AWS SAM per la gestione di API Gateway ](https://www.youtube.com/watch?v=fet3bh0QA80)

 **Strumenti correlati:** 
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)

# REL 4. Come si progettano le interazioni in un sistema distribuito per evitare errori?
<a name="rel-04"></a>

I sistemi distribuiti si basano sulle reti di comunicazione per interconnettere i componenti (ad esempio server o servizi). Il carico di lavoro deve funzionare in modo affidabile nonostante la perdita o la latenza dei dati in queste reti. I componenti del sistema distribuito devono funzionare in modo da non influire negativamente su altri componenti o sul carico di lavoro. Queste best practice prevengono gli errori e migliorano il tempo medio tra errori (MTBF).

**Topics**
+ [REL04-BP01 Identificazione del tipo di sistema distribuito necessario](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementazione di dipendenze "loosely coupled"](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Esecuzione di un lavoro costante](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Rendere tutte le risposte idempotenti](rel_prevent_interaction_failure_idempotent.md)

# REL04-BP01 Identificazione del tipo di sistema distribuito necessario
<a name="rel_prevent_interaction_failure_identify"></a>

 I sistemi distribuiti hard real-time richiedono risposte che devono essere fornite in modo sincrono e rapido, mentre i sistemi soft real-time hanno una finestra temporale più generosa di minuti o più per la risposta. I sistemi offline gestiscono le risposte tramite elaborazione in batch o asincrona. I sistemi distribuiti hard real-time hanno i requisiti di affidabilità più severi. 

 Le difficoltà maggiori [con i sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) riguardano i sistemi distribuiti hard real-time, noti anche come servizi di richiesta/risposta. La difficoltà sta nel fatto che le richieste arrivino in modo imprevedibile e le risposte debbano essere fornite rapidamente (ad esempio, il cliente è attivamente in attesa della risposta). Alcuni esempi includono server Web front-end, pipeline degli ordini, transazioni con carte di credito, ogni API AWS e telefonia. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Identifica il tipo di sistema distribuito necessario. Le sfide nell'ambito dei sistemi distribuiti includevano la latenza, il dimensionamento, la comprensione delle API di rete, i dati di marshalling e non-marshalling e la complessità di algoritmi come Paxos. Man mano che i sistemi diventano più grandi e più distribuiti, quelli che erano casi teorici limite diventano eventi regolari. 
  +  [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
    +  I sistemi distribuiti hard real-time richiedono risposte da fornire in modo sincrono e rapido. 
    +  I sistemi soft real-time hanno una finestra temporale più generosa di minuti o più per la risposta. 
    +  I sistemi offline gestiscono le risposte tramite elaborazione in batch o asincrona. 
    +  I sistemi distribuiti hard real-time hanno i requisiti di affidabilità più severi. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Amazon EC2: Ensuring Idempotency (EC2: garantire l'idempotenza)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+  [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [Che cos'è Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) 

 **Video correlati:** 
+  [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (AWS New York Summit 2019: Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli) (sono inclusi accoppiamento debole, lavoro costante e stabilità statica) (ARC337)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://youtu.be/h46IquqjF3E) 

# REL04-BP02 Implementazione di dipendenze "loosely coupled"
<a name="rel_prevent_interaction_failure_loosely_coupled_system"></a>

 Le dipendenze come sistemi di accodamento, sistemi di streaming, flussi di lavoro e sistemi di bilanciamento del carico sono "loosely coupled" (con accoppiamento debole). L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità. 

 Nei sistemi con accoppiamento stretto, le modifiche a un componente possono richiedere modifiche agli altri componenti basati su di esso, con conseguente riduzione delle prestazioni di tutti i componenti. L'accoppiamento debole interrompe questa dipendenza, in modo che i componenti dipendenti debbano conoscere solo l'interfaccia con versione e pubblicata. L'implementazione di un accoppiamento debole tra dipendenze isola un errore all'interno di una dipendenza affinché non influenzi l'altra. 

 L'accoppiamento debole consente di modificare il codice o aggiungere funzionalità a un componente riducendo al minimo il rischio per gli altri componenti che dipendono da esso. Consente inoltre una resilienza granulare a livello di componente in cui è possibile impiegare la scalabilità orizzontale o persino modificare l'implementazione sottostante della dipendenza. 

 Per migliorare ulteriormente la resilienza tramite accoppiamento debole, rendi le interazioni dei componenti asincrone laddove possibile. Questo modello è idoneo a qualsiasi interazione che non richieda una risposta immediata e laddove la conferma della registrazione di una richiesta sia sufficiente. Include un componente che genera eventi e un altro che li utilizza. I due componenti non si integrano tramite un'interazione diretta point-to-point, ma in genere attraverso un livello di archiviazione intermedio durevole, come una coda Amazon SQS o una piattaforma di dati in streaming come Amazon Kinesis o AWS Step Functions. 

![\[Diagram showing dependencies such as queuing systems and load balancers are loosely coupled\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/loosely-coupled-dependencies.png)


 Le code Amazon SQS ed Elastic Load Balancer sono solo due modi per aggiungere un livello intermedio per l'accoppiamento debole. Le architetture basate su eventi possono anche essere create in Cloud AWS utilizzando Amazon EventBridge, che può astrarre i client (produttori di eventi) dai servizi a cui fanno affidamento (consumatori di eventi). Amazon Simple Notification Service (Amazon SNS) è una soluzione efficace quando hai bisogno di messaggistica da-molti-a-molti, dalla velocità di trasmissione effettiva elevata e basata su push. Utilizzando gli argomenti di Amazon SNS, i sistemi di pubblicazione possono inviare messaggi a un numero elevato di endpoint sottoscrittori per l'elaborazione parallela. 

 Mentre le code offrono diversi vantaggi, nella maggior parte dei sistemi hard real-time, le richieste più vecchie di una soglia temporale (spesso secondi) dovrebbero essere considerate obsolete (il client ha abbandonato e non è più in attesa di una risposta) e non elaborate. In questo modo, è possibile elaborare invece le richieste più recenti (e probabilmente ancora valide). 

 **Risultato desiderato:** l'implementazione di dipendenze con accoppiamento debole consente di ridurre al minimo l'area esposta ai guasti a livello di componente e ciò aiuta a diagnosticare e risolvere i problemi. Inoltre, semplifica i cicli di sviluppo, consentendo ai team di implementare le modifiche a livello modulare senza pregiudicare le prestazioni di altri componenti che dipendono da esso. Questo approccio offre la possibilità di impiegare la scalabilità orizzontale a livello di componente in base al fabbisogno di risorse, nonché di utilizzare un componente che contribuisce alla competitività in termini di costi. 

 **Anti-pattern comuni:** 
+  Implementazione di un carico di lavoro monolitico. 
+  Invocazione diretta di API tra livelli di carico di lavoro senza funzionalità di failover o elaborazione asincrona della richiesta. 
+  Accoppiamento stretto utilizzando dati condivisi. I sistemi con accoppiamento debole dovrebbero evitare di condividere i dati tramite database condivisi o altre forme di archiviazione dei dati con accoppiamento stretto, che possono reintrodurre l'accoppiamento stretto e compromettere la scalabilità. 
+  Ignorare la contropressione. Il carico di lavoro dovrebbe essere in grado di rallentare o arrestare i dati in arrivo quando un componente non è in grado di elaborarli alla stessa velocità. 

 **Vantaggi dell'adozione di questa best practice:** l'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità. L'errore in un componente è isolato dagli altri. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Implementazione di dipendenze "loosely coupled". Esistono varie soluzioni che consentono di creare applicazioni con accoppiamento debole. Queste includono, ad esempio, servizi per l'implementazione di code completamente gestite, flussi di lavoro automatizzati, reazione agli eventi e API, che possono aiutare a isolare il comportamento dei componenti dagli altri componenti e, di conseguenza, aumentare la resilienza e l'agilità. 
+  **Crea architetture basate su eventi:** [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) ti aiuta a creare architetture basate sugli eventi con accoppiamento debole e distribuite. 
+  **Implementazione di code nei sistemi distribuiti:** è possibile utilizzare [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) per integrare e disaccoppiare i sistemi distribuiti. 
+  **Containerizza i componenti come microservizi:** i [microservizi](https://aws.amazon.com/microservices/) consentono ai team di creare applicazioni composte da piccoli componenti indipendenti che comunicano tramite API ben definite. [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) e [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) possono aiutarti a iniziare a utilizzare più rapidamente i container. 
+  **Gestisci i flussi di lavoro con Step Functions:** [Step Functions](https://aws.amazon.com/step-functions/getting-started/) semplifica il coordinamento di più servizi AWS in flussi di lavoro flessibili. 
+  **Sfrutta le architetture di messaggistica publish-subscribe (pub/sub): ** [Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) fornisce il servizio di consegna dei messaggi dagli editori agli abbonati (noti anche come produttori e consumatori). 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  I componenti in un'architettura basata su eventi vengono avviati dagli eventi. Gli eventi sono azioni che si verificano in un sistema, ad esempio un utente che aggiunge un articolo a un carrello. Quando un'azione ha successo, viene generato un evento che attiva il successivo componente del sistema. 
  + [Creazione di applicazioni basate su eventi con Amazon EventBridge](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
  + [AWS re:Invent 2022 - Designing Event-Driven Integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+  I sistemi di messaggistica distribuiti sono composti da tre parti principali che devono essere implementate per un'architettura basata su code. Includono i componenti del sistema distribuito, la coda utilizzata per il disaccoppiamento (distribuita su server Amazon SQS) e i messaggi in coda. Un sistema tipico prevede produttori che inviano il messaggio alla coda e il consumatore che riceve il messaggio dalla coda. La coda archivia i messaggi su più server Amazon SQS per garantire la ridondanza. 
  + [Architettura Amazon SQS di base](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
  + [Invia messaggi tra applicazioni distribuite con Amazon Simple Queue Service](https://aws.amazon.com/getting-started/hands-on/send-messages-distributed-applications/)
+  I microservizi, se ben utilizzati, migliorano la manutenibilità e aumentano la scalabilità, poiché i componenti ad accoppiamento debole sono gestiti da team indipendenti. Consentono inoltre l'isolamento dei comportamenti in un unico componente in caso di modifiche. 
  + [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
  + [Let's Architect\$1 Architecting microservices with containers ](https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/)
+  Con AWS Step Functions è possibile eseguire moltissime operazioni, ad esempio creare applicazioni distribuite, automatizzare i processi e orchestrare microservizi. L'orchestrazione di più componenti in un flusso di lavoro automatizzato consente di disaccoppiare le dipendenze nell'applicazione. 
  + [ Create a Serverless Workflow with AWS Step Functions and AWS Lambda](https://aws.amazon.com/tutorials/create-a-serverless-workflow-step-functions-lambda/)
  + [Nozioni di base su AWS Step Functions](https://aws.amazon.com/step-functions/getting-started/)

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Amazon EC2: Ensuring Idempotency](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+  [What is Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [What is Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) 
+ [ Break up with your monolith ](https://pages.awscloud.com/break-up-your-monolith.html)
+ [ Orchestrate Queue-based Microservices with AWS Step Functions and Amazon SQS ](https://aws.amazon.com/tutorials/orchestrate-microservices-with-message-queues-on-step-functions/)
+ [Architettura Amazon SQS di base](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [Architettura basata su code](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/queue-based-architecture.html)

 **Video correlati:** 
+  [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E) 
+  [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q) 
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda ](https://www.youtube.com/watch?v=2rikdPIFc_Q)
+ [AWS re:Invent 2022 - Designing event-driven integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ [AWS re:Invent 2017: Elastic Load Balancing Deep Dive and Best Practices ](https://www.youtube.com/watch?v=9TwkMMogojY)

# REL04-BP03 Esecuzione di un lavoro costante
<a name="rel_prevent_interaction_failure_constant_work"></a>

 I sistemi possono fallire quando si verificano modifiche rapide e di grandi dimensioni nel carico. Ad esempio, se il carico di lavoro effettua un controllo dell'integrità di migliaia di server deve inviare ogni volta lo stesso payload delle dimensioni (uno snapshot completo dello stato corrente). Indipendentemente dal fatto che non ci siano server guasti, o che lo siano tutti, il sistema di controllo dello stato esegue un lavoro costante con modifiche rapide e di piccole dimensioni. 

 Ad esempio, se il sistema di controllo dello stato monitora 100.000 server, il carico su di esso è nominale al di sotto del tasso di errore normalmente basso del server. Tuttavia, se un evento importante rendesse la metà di questi server non integra, il sistema di controllo dello stato sarebbe sovraccarico nel tentativo di aggiornare i sistemi di notifica e comunicare lo stato con i client. Pertanto, il sistema di controllo dello stato dovrebbe ogni volta inviare lo snapshot completo dello stato corrente. 100.000 stati di integrità del server, ciascuno rappresentato da un bit, sarebbero solo un payload di 12,5 KB. Indipendentemente dal fatto che non ci siano server guasti, o che lo siano tutti, il sistema di controllo dello stato esegue un lavoro costante e le modifiche rapide e di grandi dimensioni non rappresentano una minaccia per la stabilità del sistema. Questo è in realtà il modo in cui Amazon Route 53 gestisce i controlli dell'integrità degli endpoint (come gli indirizzi IP) per stabilire come gli utenti finali vengono instradati verso di loro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Bassa 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Esegui un lavoro costante in modo che i sistemi non falliscano quando si verificano cambiamenti rapidi e significativi nel carico. 
+  Implementazione di dipendenze "loosely coupled". Le dipendenze come sistemi di accodamento, sistemi di streaming, flussi di lavoro e sistemi di bilanciamento del carico sono "loosely coupled" (con accoppiamento debole). L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità. 
  +  [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
  +  [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli), include lavoro costante (ARC337)](https://youtu.be/O8xLxNje30M?t=2482) 
    +  Per l'esempio di un sistema di controllo dell'integrità che monitora 100.000 server, progetta i carichi di lavoro in modo che le dimensioni dei payload rimangano costanti indipendentemente dal numero di successi o di fallimenti. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Amazon EC2: garantire l'idempotenza](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 

 **Video correlati:** 
+  [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli), include lavoro costante (ARC337)](https://youtu.be/O8xLxNje30M?t=2482) 
+  [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli), sono inclusi accoppiamento debole, lavoro costante e stabilità statica (ARC337)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: passare alle architetture basate sugli eventi (SVS308)](https://youtu.be/h46IquqjF3E) 

# REL04-BP04 Rendere tutte le risposte idempotenti
<a name="rel_prevent_interaction_failure_idempotent"></a>

 Un servizio idempotente promette il completamento di ogni richiesta esattamente una volta, in modo tale che effettuare più richieste identiche abbia lo stesso effetto di effettuare una singola richiesta. Un servizio idempotente semplifica ad un client l'implementazione di nuovi tentativi senza temere che una richiesta venga elaborata erroneamente più volte. Per eseguire questa operazione, i client possono inviare richieste API con un token di idempotenza: viene utilizzato lo stesso token ogni volta che si ripete la richiesta. Un'API del servizio idempotente utilizza il token per restituire una risposta identica a quella restituita la prima volta che la richiesta è stata completata. 

 In un sistema distribuito, è facile eseguire un'operazione al massimo una volta (il client effettua una sola richiesta) o almeno una volta (la richiesta continua finché il client non ottiene la conferma dell'esito positivo). Tuttavia, è difficile garantire che un'operazione sia idempotente, il che significa che viene eseguita *esattamente* una volta, in modo tale che effettuare più richieste identiche abbia lo stesso effetto di effettuare una singola richiesta. Utilizzando i token di idempotenza nelle API, i servizi possono ricevere una richiesta di mutazione una o più volte senza creare record duplicati o effetti collaterali. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Rendi tutte le risposte idempotenti. Un servizio idempotente promette il completamento di ogni richiesta esattamente una volta, in modo tale che effettuare più richieste identiche abbia lo stesso effetto di effettuare una singola richiesta. 
  +  I client possono inviare richieste API con un token di idempotenza: viene utilizzato lo stesso token ogni volta che si ripete la richiesta. Un'API del servizio idempotente utilizza il token per restituire una risposta identica a quella restituita la prima volta che la richiesta è stata completata. 
    +  [Amazon EC2: Ensuring Idempotency (EC2: garantire l'idempotenza)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Amazon EC2: Ensuring Idempotency (EC2: garantire l'idempotenza)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) 
+  [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 
+  [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 

 **Video correlati:** 
+  [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (AWS New York Summit 2019: Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU) 
+  [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli) (sono inclusi accoppiamento debole, lavoro costante e stabilità statica) (ARC337)](https://youtu.be/O8xLxNje30M) 
+  [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://youtu.be/h46IquqjF3E) 

# REL 5. Come si progettano le interazioni in un sistema distribuito per mitigare o affrontare gli errori?
<a name="rel-05"></a>

I sistemi distribuiti si basano sulle reti di comunicazione per interconnettere i componenti (ad esempio server o servizi). Il carico di lavoro deve funzionare in modo affidabile nonostante la perdita o la latenza dei dati su queste reti. I componenti del sistema distribuito devono funzionare in modo da non influire negativamente su altri componenti o sul carico di lavoro. Queste best practice permettono ai carichi di lavoro di tollerare le sollecitazioni o i guasti, recuperare più rapidamente e mitigare l'impatto di tali problemi. Il risultato è un miglioramento del tempo medio di ripristino (MTTR).

**Topics**
+ [REL05-BP01 Implementazione della normale riduzione delle prestazioni per trasformare le dipendenze forti applicabili in dipendenze deboli](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controllo e limitazione delle chiamate di ripetizione](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Anticipazione degli errori e limitazione delle code](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Impostazione dei timeout dei client](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Rendere i servizi stateless laddove possibile](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementazione di leve di emergenza](rel_mitigate_interaction_failure_emergency_levers.md)

# REL05-BP01 Implementazione della normale riduzione delle prestazioni per trasformare le dipendenze forti applicabili in dipendenze deboli
<a name="rel_mitigate_interaction_failure_graceful_degradation"></a>

I componenti dell'applicazione devono continuare a svolgere la loro funzione principale anche se le dipendenze non sono disponibili. Potrebbero fornire dati leggermente obsoleti, dati alternativi o addirittura nessun dato. Ciò garantisce che la funzionalità complessiva del sistema sia ostacolata solo in minima parte da errori localizzati, garantendo al contempo il valore aziendale intrinseco.

 **Risultato desiderato:** quando le dipendenze di un componente non sono integre, il componente stesso può comunque funzionare, anche se non in modo ottimale. Le modalità di errore dei componenti devono essere considerate come funzionamenti normali. I flussi di lavoro devono essere progettati in modo tale che questi errori non conducano a un fallimento completo o almeno a stati prevedibili e recuperabili. 

 **Anti-pattern comuni:** 
+  Mancata identificazione della funzionalità aziendale di base necessaria. Mancata verifica del funzionamento dei componenti anche in caso di errori di dipendenza. 
+  Mancata restituzione di dati sugli errori o quando solo una delle dipendenze non è disponibile e possono comunque essere restituiti risultati parziali. 
+  Creazione di uno stato incoerente quando una transazione fallisce parzialmente. 
+  Mancata disponibilità di alternative per accedere a un archivio di parametri centralizzato. 
+  Invalidare o svuotare lo stato locale a seguito di un aggiornamento non riuscito senza considerare le conseguenze di tale operazione. 

 **Vantaggi dell'adozione di questa best practice:** la normale riduzione delle prestazioni migliora la disponibilità del sistema nel suo complesso e conserva la funzionalità delle funzioni più importanti anche in caso di errori. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 L'implementazione di una normale riduzione delle prestazioni aiuta a ridurre al minimo l'impatto degli errori di dipendenza sul funzionamento dei componenti. Idealmente, un componente rileva gli errori nelle dipendenze e trova soluzioni alternative in modo da avere un impatto minimo sugli altri componenti o clienti. 

 Progettare per una normale riduzione delle prestazioni significa considerare le potenziali modalità di errore durante la progettazione delle dipendenze. Per ogni modalità di errore, disponi di un modo per fornire la maggior parte delle funzionalità o almeno quelle più critiche del componente a chiamanti o clienti. Queste considerazioni possono diventare requisiti aggiuntivi testabili e verificabili. Idealmente, un componente è in grado di svolgere la sua funzione principale in modo accettabile anche in caso di errore di una o più dipendenze. 

 Questa è una discussione di carattere tanto commerciale quanto tecnico. Tutti i requisiti aziendali sono importanti e devono essere soddisfatti, se possibile. Tuttavia, ha ancora senso chiedersi cosa dovrebbe succedere quando non tutti i requisiti possono essere soddisfatti. Un sistema può essere progettato per essere disponibile e coerente, ma nelle circostanze in cui è necessario eliminare un requisito, qual è quello più importante? Per l'elaborazione dei pagamenti, potrebbe essere la coerenza. Per un'applicazione in tempo reale, potrebbe essere la disponibilità. Per un sito Web rivolto ai clienti, la risposta può dipendere dalle aspettative dei clienti. 

 Il significato di ciò dipende dai requisiti del componente e da ciò che dovrebbe essere considerato la sua funzione principale. Ad esempio: 
+  un sito di e-commerce potrebbe visualizzare dati provenienti da più sistemi diversi, come consigli personalizzati, prodotti con il punteggio più alto e lo stato degli ordini dei clienti sulla pagina di destinazione. Quando in un sistema upstream si verifica un errore, ha comunque senso mostrare tutto il resto, invece di mostrare una pagina di errore a un cliente. 
+  Un componente che esegue la scrittura in batch può continuare a elaborare un batch se una delle singole operazioni fallisce. Dovrebbe essere semplice implementare un meccanismo di ripetizione dei tentativi. A tale scopo, è sufficiente restituire al chiamante informazioni su quali operazioni hanno avuto successo, quali e perché non sono riuscite, oppure inserendo le richieste non riuscite in una coda DLQ per implementare nuovi tentativi asincroni. Anche le informazioni sulle operazioni non riuscite devono essere registrate. 
+  Un sistema che elabora le transazioni deve verificare che vengano eseguiti tutti gli aggiornamenti o nessun aggiornamento. Per le transazioni distribuite, il modello Saga può essere utilizzato per ripristinare le operazioni precedenti nel caso in cui fallisca un'operazione successiva della stessa transazione. Qui, la funzione principale è mantenere la coerenza. 
+  I sistemi critici dal punto di vista temporale dovrebbero essere in grado di gestire le dipendenze che non rispondono in modo tempestivo. In questi casi, è possibile utilizzare lo schema dell'interruttore. Quando inizia a verificarsi il timeout delle risposte di una dipendenza, il sistema può passare a uno stato chiuso in cui non vengono effettuate chiamate aggiuntive. 
+  Un'applicazione può leggere i parametri da un archivio di parametri. Può essere utile creare immagini di container con un set di parametri predefinito e utilizzarli nel caso in cui l'archivio dei parametri non sia disponibile. 

 Si noti che i percorsi seguiti in caso di errore dei componenti devono essere testati e devono essere significativamente più semplici del percorso primario. In genere, [è consigliabile evitare il fallback](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/). 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Identifica le dipendenze esterne e interne. Considera i tipi di errore che si possono verificare nelle dipendenze. Considera i modi per ridurre al minimo l'impatto negativo sui sistemi upstream e downstream e sui clienti durante questi errori. 

 Di seguito è riportato un elenco di dipendenze e di come ridurre normalmente le prestazioni quando si verifica un errore a livello di dipendenze: 

1.  **Errore parziale delle dipendenze:** un componente può effettuare più richieste ai sistemi downstream, sia come richieste multiple a un sistema sia come richiesta a più sistemi. A seconda del contesto aziendale, possono essere appropriate diverse modalità di gestione (per maggiori dettagli, consulta gli esempi precedenti nella Guida all'implementazione). 

1.  **Un sistema downstream non è in grado di elaborare le richieste a causa del carico elevato:** se le richieste a un sistema downstream hanno costantemente esito negativo, non ha senso continuare a riprovare. Ciò può creare un carico aggiuntivo su un sistema già sovraccarico e rendere più difficile il ripristino. Qui è possibile utilizzare lo schema dell'interruttore, che monitora le chiamate non riuscite a un sistema downstream. Se un numero elevato di chiamate ha esito negativo, interromperà l'invio di altre richieste al sistema downstream e solo occasionalmente lascerà passare le chiamate per verificare se il sistema downstream è nuovamente disponibile. 

1.  **Un archivio di parametri non è disponibile:** per trasformare un archivio di parametri, è possibile utilizzare la cache delle dipendenze a protezione debole o i valori predefiniti integri inclusi nelle immagini del container o del computer. Tieni presente che queste impostazioni predefinite devono essere costantemente aggiornate e incluse nelle suite di test. 

1.  **Un servizio di monitoraggio o altra dipendenza non funzionale non è disponibile:** se un componente non è in grado di inviare a intermittenza log, metriche o tracce a un servizio di monitoraggio centralizzato, spesso è meglio continuare a eseguire le funzioni aziendali come al solito. Non registrare o eseguire il push delle metriche in modo invisibile all'utente per un lungo periodo di tempo spesso non è una procedura accettabile. Inoltre, in alcuni casi d'uso potrebbero essere necessari dati di controllo completi per soddisfare i requisiti di conformità. 

1.  **Un'istanza primaria di un database relazionale potrebbe non essere disponibile:** Amazon Relational Database Service, come quasi tutti i database relazionali, può avere solo un'istanza di scrittura primaria. Questo crea un unico punto di errore per i carichi di lavoro di scrittura e rende più difficile il dimensionamento. Questo problema può essere parzialmente mitigato utilizzando una configurazione Multi-AZ per una disponibilità elevata o Amazon Aurora Serverless per un migliore dimensionamento. Per requisiti di disponibilità molto elevati, può essere logico non fare affatto affidamento sull'istanza di scrittura primaria. Per le query che si limitano a leggere, è possibile utilizzare repliche di lettura, che forniscono ridondanza e la possibilità di dimensionare non solo verticalmente, ma anche orizzontalmente. Le operazioni di scrittura possono essere memorizzate nel buffer, ad esempio in una coda Amazon Simple Queue Service, in modo che le richieste di scrittura dei clienti possano comunque essere accettate anche se l'istanza primaria non è temporaneamente disponibile. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Amazon API Gateway: throttling delle richieste API per migliorare la velocità di trasmissione effettiva](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+  [CircuitBreaker (riepilogo dal libro Circuit Breaker da "Release It\$1")](https://martinfowler.com/bliki/CircuitBreaker.html) 
+  [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [Michael Nygard "Release It\$1 Design and Deploy Production-Ready Software"](https://pragprog.com/titles/mnee2/release-it-second-edition/) 
+  [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) 
+  [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 
+  [The Amazon Builders' Library: Sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 
+  [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 

 **Video correlati:** 
+  [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

 **Esempi correlati:** 
+  [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) 

# REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)
<a name="rel_mitigate_interaction_failure_throttle_requests"></a>

Limita le richieste per mitigare l'esaurimento delle risorse dovuto ad aumenti imprevisti della domanda. Le richieste inferiori alla percentuale di limitazione (della larghezza di banda della rete) vengono elaborate mentre quelle che superano il limite definito vengono rifiutate con un messaggio che indica che la richiesta è stata limitata. 

 **Risultato desiderato:** i picchi di volume di grandi dimensioni dovuti a improvvisi aumenti del traffico dei clienti, attacchi di flooding o tempeste di ripetizioni dei tentativi sono mitigati dalla limitazione (della larghezza di banda della rete) delle richieste, che consente ai carichi di lavoro di continuare la normale elaborazione del volume di richieste supportato. 

 **Anti-pattern comuni:** 
+  Le accelerazioni degli endpoint API non sono implementate o vengono implementate in base ai valori predefiniti senza considerare i volumi previsti. 
+  Gli endpoint delle API non sono sottoposti a test di carico né i limiti relativi alla limitazione (della larghezza di banda della rete) vengono testati. 
+  Limitazione delle tariffe delle richieste senza considerare le dimensioni o la complessità delle richieste. 
+  Verifica delle percentuali massime di richieste o delle dimensioni massime delle richieste, senza però testarle congiuntamente. 
+  Le risorse non vengono fornite entro gli stessi limiti stabiliti durante i test. 
+  I piani di utilizzo non sono stati configurati o considerati per gli utenti di API Application to Application (A2A). 
+  Gli utenti di code con dimensionamento orizzontale non hanno configurato le impostazioni di simultaneità massima. 
+  La limitazione della velocità per indirizzo IP non è stata implementata. 

 **Vantaggi dell'adozione di questa best practice:** i carichi di lavoro che stabiliscono limiti di accelerazione sono in grado di funzionare normalmente ed elaborare correttamente il caricamento delle richieste accettate in presenza di picchi di volume imprevisti. I picchi improvvisi o prolungati di richieste alle API e alle code vengono limitati e non esauriscono le risorse di elaborazione delle richieste. I limiti tariffari vincolano i richiedenti in modo che elevati volumi di traffico provenienti da un utente di un indirizzo IP o API specifico non esauriscano le risorse e influiscano sugli altri utenti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I servizi devono essere progettati per elaborare una capacità nota di richieste; tale capacità può essere stabilita mediante test di carico. Se le percentuali di arrivo delle richieste superano i limiti, la risposta appropriata segnala che una richiesta è stata limitata. Ciò consente all'utente di gestire l'errore e riprovare in un secondo momento. 

 Quando il servizio richiede un'implementazione della limitazione (della larghezza di banda della rete), prendi in considerazione l'implementazione dell'algoritmo token bucket, in cui un token conta come una richiesta. I token vengono alimentati a una specifica velocità di throttling al secondo e svuotati in modo asincrono in base a un token per richiesta. 

![\[Diagramma che descrive l'algoritmo token bucket.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/token-bucket-algorithm.png)


 

 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) implementa l'algoritmo token bucket in base ai limiti dell'account e della regione e può essere configurato per cliente con piani di utilizzo. Inoltre, [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) e [Amazon Kinesis](https://aws.amazon.com/kinesis/) possono memorizzare le richieste nel buffer per livellare la frequenza delle richieste e consentire percentuali di limitazione più elevati per le richieste che possono essere soddisfatte. Infine, puoi implementare la limitazione della velocità con [AWS WAF](https://aws.amazon.com/waf/) per limitare utenti di API specifici che generano carichi insolitamente elevati. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Puoi configurare API Gateway con limiti di limitazione (della larghezza di banda della rete) per le tue API e restituire errori `429 - Troppe richieste` in caso di superamento dei limiti. Puoi utilizzare AWS WAF con gli endpoint API Gateway e AWS AppSync per abilitare la limitazione della velocità per indirizzo IP. Inoltre, laddove il sistema può tollerare l'elaborazione asincrona, è possibile inserire i messaggi in una coda o in un flusso per velocizzare le risposte ai client del servizio, il che consente di aumentare le velocità. 

 Con l'elaborazione asincrona, una volta configurato Amazon SQS come origine degli eventi per AWS Lambda, è possibile [configurare la simultaneità massima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) per evitare che percentuali elevate di eventi consumino la quota di esecuzione simultanea disponibile dell'account necessaria per altri servizi nel carico di lavoro o nell'account. 

 Sebbene API Gateway fornisca un'implementazione gestita dell'algoritmo token bucket, nei casi in cui non sia possibile utilizzare API Gateway, puoi sfruttare le implementazioni open source specifiche del linguaggio (consulta gli esempi correlati nella sezione Risorse) dell'algoritmo token bucket per i tuoi servizi. 
+  Analizza e configura [i valori di limitazione (della larghezza di banda della rete) API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) a livello di account per regione, API per fase e chiave API per livelli del piano di utilizzo. 
+  Applica le [regole di limitazione (della larghezza di banda della rete) AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) sugli endpoint API Gateway e AWS AppSync come prevenzione degli attacchi flood e per bloccare gli IP pericolosi. Le regole di limitazione (della larghezza di banda della rete) possono anche essere configurate su chiavi API AWS AppSync per gli utenti A2A. 
+  Valuta se hai bisogno di più controllo sulla limitazione della larghezza di banda della rete rispetto al controllo sulla limitazione della velocità per le API AWS AppSync e, in tal caso, configura un API Gateway davanti all'endpoint AWS AppSync. 
+  Quando le code Amazon SQS sono impostate come trigger per gli utenti della coda Lambda, imposta [la simultaneità massima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) su un valore che elabora in misura sufficiente a soddisfare gli obiettivi dei livelli di servizio ma non consuma i limiti di simultaneità che influiscono su altre funzioni Lambda. Valuta la possibilità di impostare la simultaneità riservata su altre funzioni Lambda nello stesso account e nella stessa regione quando utilizzi le code con Lambda. 
+  Utilizza API Gateway con integrazioni di servizi native per Amazon SQS o Kinesis per memorizzare le richieste nel buffer. 
+  Se non puoi utilizzare API Gateway, consulta le librerie specifiche della lingua per implementare l'algoritmo token bucket per il tuo carico di lavoro. Controlla la sezione degli esempi e cerca una libreria adatta. 
+  Verifica i limiti che intendi impostare o che prevedi di incrementare e documenta i limiti testati. 
+  Non aumentare i limiti oltre i valori stabiliti durante i test. Quando si aumenta un limite, verifica che le risorse assegnate siano equivalenti o superiori a quelle degli scenari di test prima di applicare l'aumento. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL04-BP03 Esecuzione di un lavoro costante](rel_prevent_interaction_failure_constant_work.md) 
+  [REL05-BP03 Controllo e limitazione delle chiamate di ripetizione](rel_mitigate_interaction_failure_limit_retries.md) 

 **Documenti correlati:** 
+  [Amazon API Gateway: throttling delle richieste API per migliorare la velocità di trasmissione effettiva](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+ [AWS WAF: istruzione delle regole basate sulla frequenza ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Introduzione alla simultaneità massima di AWS Lambda in caso di utilizzo Amazon SQS come origine degli eventi ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda: simultaneità massima ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)

 **Esempi correlati:** 
+ [ Le tre regole AWS WAF più importanti basate sulla velocità ](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Java Bucket4j ](https://github.com/bucket4j/bucket4j)
+ [ Algoritmo token bucket per Python ](https://pypi.org/project/token-bucket/)
+ [ Algoritmo token bucket a livello di nodo ](https://www.npmjs.com/package/tokenbucket)
+ [ Limitazione della velocità di threading del sistema .NET ](https://www.nuget.org/packages/System.Threading.RateLimiting)

 **Video correlati:** 
+ [ Implementazione delle best practice di sicurezza dell'API GraphQL con AWS AppSync](https://www.youtube.com/watch?v=1ASMLeJ_15U)

 **Strumenti correlati:** 
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)

# REL05-BP03 Controllo e limitazione delle chiamate di ripetizione
<a name="rel_mitigate_interaction_failure_limit_retries"></a>

Utilizza il backoff esponenziale per rieseguire le richieste a intervalli progressivamente più lunghi tra i singoli nuovi tentativi. Introduci il jitter tra i tentativi per randomizzare gli intervalli di ripetizione. Limita il numero massimo di tentativi.

 **Risultato desiderato:** I componenti tipici di un sistema software distribuito includono server, sistemi di bilanciamento del carico, database e server DNS. Durante il normale funzionamento, questi componenti possono rispondere alle richieste con errori temporanei o limitati e anche errori che sarebbero persistenti indipendentemente dai nuovi tentativi. Quando i client effettuano richieste ai servizi, le richieste consumano risorse tra cui memoria, thread, connessioni, porte o altre risorse limitate. Controllare e limitare i nuovi tentativi è una strategia per liberare risorse e ridurne al minimo il consumo in modo che i componenti del sistema sottoposti a stress non vengano sovraccaricati. 

 Quando vanno in timeout o ricevono risposte di errore, le richieste client devono decidere se eseguire o meno nuovi tentativi. Se vengono eseguiti nuovi tentativi, questi verranno eseguiti con un backoff esponenziale con jitter e un numero massimo di tentativi. Di conseguenza, i servizi e i processi back-end riducono il carico e i tempi di riparazione automatica, con un conseguente ripristino più rapido e una corretta gestione delle richieste. 

 **Anti-pattern comuni:** 
+  Implementazione di nuovi tentativi senza aggiungere il backoff esponenziale, il jitter e il numero massimo di tentativi. Il backoff e il jitter aiutano a evitare picchi di traffico artificiali dovuti a tentativi involontariamente coordinati a intervalli standard. 
+  Implementazione di nuovi tentativi senza testarne gli effetti o assunzione che i nuovi tentativi siano già integrati in un SDK senza testare gli scenari di ripetizione dei tentativi. 
+  La mancata comprensione dei codici di errore pubblicati nelle dipendenze porta a ritentare tutti gli errori, compresi quelli la cui causa è chiara e indica la mancanza di autorizzazione, un errore di configurazione o un'altra condizione che prevedibilmente non si risolverà senza un intervento manuale. 
+  Mancata gestione delle best practice di osservabilità, compresi il monitoraggio e la segnalazione di ripetuti guasti del servizio, in modo che i problemi sottostanti siano resi noti e possano essere risolti. 
+  Sviluppo di meccanismi di ripetizione personalizzati quando le funzionalità di ripetizione dei tentativi integrate o di terze parti sono sufficienti. 
+  Riprovare su più livelli dello stack di applicazioni in modo da accrescere in modo significativo i nuovi tentativi e pertanto da consumare ulteriormente le risorse in una tempesta di ripetizioni dei tentativi. Assicurati di comprendere in che modo questi errori influiscono sulla tua applicazione e sulle dipendenze su cui fai affidamento, quindi implementa i nuovi tentativi a un solo livello. 
+  Riesecuzione delle chiamate dei servizi non idempotenti, con effetti collaterali imprevisti come risultati duplicati. 

 **Vantaggi dell'adozione di questa best practice:** i nuovi tentativi aiutano i client a ottenere i risultati desiderati quando le richieste non riescono, ma consumano più tempo del server per ottenere le risposte corrette desiderate. Quando gli errori sono rari o transitori, i nuovi tentativi funzionano correttamente. Quando gli errori sono causati da un sovraccarico di risorse, i nuovi tentativi possono peggiorare le cose. L'aggiunta di un backoff esponenziale con jitter ai tentativi dei client consente ai server di recuperare risorse quando gli errori sono causati dal sovraccarico delle risorse. Il jitter evita l'allineamento delle richieste in picchi e il backoff riduce l'aumento del carico causato dall'aggiunta di nuovi tentativi al normale carico delle richieste. Infine, è importante configurare un numero massimo di tentativi o il tempo trascorso per evitare la creazione di backlog che producono errori metastabili. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Controlla e limita le chiamate riproposte. Utilizza il backoff esponenziale per eseguire nuovi tentativi dopo intervalli progressivamente più lunghi. Introduci il jitter per randomizzare gli intervalli di ripetizione e limitare il numero massimo di tentativi. 

 Alcuni AWS SDK implementano i nuovi tentativi e il backoff esponenziale per impostazione predefinita. Usa queste implementazioni AWS integrate laddove applicabile nel tuo carico di lavoro. Implementa una logica simile nel tuo carico di lavoro quando chiami servizi idempotenti e i cui tentativi migliorano la disponibilità dei client. Potrai decidere quali sono i timeout e quando cessare i tentativi in base al tuo caso d'uso. Crea ed esegui scenari di test per quei casi d'uso relativi ai nuovi tentativi. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Determina il livello ottimale nello stack di applicazioni per implementare nuovi tentativi per i servizi su cui si basa l'applicazione. 
+  Presta attenzione agli SDK esistenti che implementano strategie collaudate di ripetizione dei tentativi con backoff esponenziale e jitter per la lingua prescelta, e preferisci queste soluzioni anziché scrivere implementazioni personalizzate. 
+  Verifica che [i servizi siano idempotenti](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) prima di implementare nuovi tentativi. Una volta implementati i nuovi tentativi, assicurati che siano testati e che vengano regolarmente eseguiti in produzione. 
+  Quando chiami le API del servizio AWS, utilizza gli [AWS SDK](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) e [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html) e analizza le opzioni di configurazione dei nuovi tentativi. Determina se le impostazioni predefinite sono adatte al tuo caso d'uso, esegui i test e regola i valori secondo necessità. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL04-BP04 Rendere tutte le risposte idempotenti](rel_prevent_interaction_failure_idempotent.md) 
+  [REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)](rel_mitigate_interaction_failure_throttle_requests.md) 
+  [REL05-BP04 Anticipazione degli errori e limitazione delle code](rel_mitigate_interaction_failure_fail_fast.md) 
+  [REL05-BP05 Impostazione dei timeout dei client](rel_mitigate_interaction_failure_client_timeouts.md) 
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md) 

 **Documenti correlati:** 
+  [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 
+ [ Exponential Backoff and Jitter (Jitter e backoff esponenziale) ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [ Rendere sicuri i tentativi con API idempotenti ](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

 **Esempi correlati:** 
+ [ Spring Retry ](https://github.com/spring-projects/spring-retry)
+ [ Resilience4j Retry ](https://resilience4j.readme.io/docs/retry)

 **Video correlati:** 
+  [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

 **Strumenti correlati:** 
+ [AWS SDKs and Tools: Retry behavior (AWS SDK e strumenti: comportamento dei tentativi) ](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: tentativi AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)

# REL05-BP04 Anticipazione degli errori e limitazione delle code
<a name="rel_mitigate_interaction_failure_fail_fast"></a>

Se un servizio non è in grado di rispondere correttamente a una richiesta, anticipa l'errore (fail fast). Ciò consente il rilascio delle risorse associate a una richiesta e permette al servizio di recuperare le risorse se queste sono in esaurimento. L'anticipazione degli errori (fail fast) è un modello di progettazione software consolidato che può essere usato per creare carichi di lavoro altamente affidabili nel cloud. Anche l'accodamento è un modello di integrazione aziendale consolidato che può semplificare il carico e consentire ai client di rilasciare risorse quando l'elaborazione asincrona può essere tollerata. Quando un servizio è in grado di rispondere correttamente in condizioni normali ma fallisce quando la frequenza delle richieste è troppo alta, utilizza una coda per memorizzare le richieste nel buffer. Tuttavia, non consentire la creazione di backlog di code lunghe che possono comportare l'elaborazione di richieste obsolete già dismesse dal client.

 **Risultato desiderato:** Quando i sistemi rilevano conflitti a livello di risorse, timeout, eccezioni o errori che rendono irraggiungibili gli obiettivi dei livelli di servizio, le strategie di anticipazione degli errori (fail fast) consentono un ripristino più rapido del sistema. I sistemi che devono assorbire i picchi di traffico e sono in grado di gestire l'elaborazione asincrona possono migliorare l'affidabilità consentendo ai client di rilasciare rapidamente le richieste utilizzando le code per archiviare le richieste nei servizi di back-end. Quando le richieste vengono memorizzate nei buffer delle code, vengono implementate strategie di gestione delle code per evitare backlog ingestibili. 

 **Anti-pattern comuni:** 
+  Implementazione delle code di messaggi ma non la configurazione delle code DLQ o degli allarmi nei volumi DLQ per rilevare quando un sistema è in errore. 
+  Mancata misurazione dell'età dei messaggi in una coda, misurazione della latenza per capire quando gli utenti della coda sono in ritardo o generano errori che causano un nuovo tentativo. 
+  Mancata cancellazione dei messaggi nel backlog da una coda quando non è più necessario elaborare questi messaggi se l'azienda non lo richiede più. 
+  La configurazione delle code First in First Out (FIFO) quando le code Last In First Out (LIFO) soddisferebbe meglio le esigenze dei client, ad esempio quando non sono richiesti ordini rigorosi e l'elaborazione dei backlog sta ritardando tutte le richieste nuove e urgenti, con conseguente violazione dei livelli di servizio per tutti i client. 
+  Esposizione delle code interne ai client, invece dell'esposizione delle API che gestiscono l'acquisizione del lavoro e l'inserimento delle richieste in code interne. 
+  Combinazione di un numero eccessivo di tipi di richieste di lavoro in un'unica coda; ciò può aggravare le condizioni dei backlog in seguito alla distribuzione delle richieste di risorse tra i tipi di richiesta. 
+  Elaborazione di richieste complesse e semplici nella stessa coda, nonostante siano necessari monitoraggio, timeout e allocazioni di risorse diversi. 
+  Mancata convalida degli input o utilizzo di asserzioni per implementare meccanismi di anticipazione degli errori (fail fast) nel software che generano eccezioni a componenti di livello superiore in grado di gestire normalmente gli errori. 
+  Mancata rimozione delle risorse in errore dall'instradamento delle richieste, soprattutto quando gli errori generano risultati sia positivi che negativi dovuti ad arresti anomali e riavvii, errori intermittenti a livello di dipendenze, capacità ridotta o perdita di pacchetti di rete. 

 **Vantaggi dell'adozione di questa best practice:** I sistemi con anticipazione degli errori sono più facili da sottoporre al debug e alla correzione degli errori e spesso presentano problemi di codifica e configurazione prima che le versioni vengano pubblicate in produzione. I sistemi che incorporano strategie di accodamento efficaci forniscono maggiore resilienza e affidabilità in caso di picchi di traffico e di condizioni intermittenti di errore del sistema. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Le strategie di anticipazione degli errori possono essere codificate in soluzioni software e configurate nell'infrastruttura. Oltre all'anticipazione degli errori (fail fast), le code sono una tecnica semplice ma affidabile di definizione dell'architettura che consente il caricamento senza problemi di componenti disaccoppiati del sistema. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) fornisce funzionalità per il monitoraggio e la segnalazione di guasti. Una volta accertato il malfunzionamento di un sistema, è possibile ricorrere a strategie di mitigazione, ad esempio per evitare problemi dovuti a risorse danneggiate. Quando i sistemi implementano le code con [Amazon SQS](https://aws.amazon.com/sqs/) e altre tecnologie di accodamento, per semplificare il caricamento, devono valutare come gestire i backlog e gli errori di utilizzo dei messaggi. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Implementa asserzioni programmatiche o metriche specifiche nel tuo software e utilizzale per avvisare esplicitamente in caso di problemi a livello di sistema. Amazon CloudWatch ti aiuta a creare metriche e allarmi in base al modello di log delle applicazioni e alla strumentazione SDK. 
+  Usa le metriche CloudWatch e gli allarmi per eseguire il failover per le risorse danneggiate responsabili dell'incremento della latenza dell'elaborazione o che ripetutamente non riescono a elaborare le richieste. 
+  Utilizza l'elaborazione asincrona. A tale scopo, progetta API in grado di accettare le richieste e aggiungere richieste alle code interne mediante Amazon SQS e, quindi, rispondere al client che genera il messaggio con un messaggio di successo, in modo che il client possa rilasciare risorse e passare ad altre attività mentre gli utenti nella coda di back-end elaborano le richieste. 
+  Misura e monitora la latenza di elaborazione delle code generando una metrica CloudWatch ogni volta che escludi un messaggio da una coda confrontandolo con il timestamp del messaggio. 
+  Quando gli errori impediscono la corretta elaborazione dei messaggi o il traffico aumenta a livelli tali da impedirne l'elaborazione in base agli accordi sul livello di servizio, escludi il traffico obsoleto o in eccesso indirizzandolo a una coda per il traffico eccedente. Ciò consente l'elaborazione prioritaria del nuovo processo e del processo più vecchio quando si rende disponibile nuova capacità. Questa tecnica è un'approssimazione dell'elaborazione LIFO e consente la normale elaborazione del sistema per tutti i nuovi processi. 
+  Usa le code DLQ o le code di reindirizzamento per spostare i messaggi che non possono essere elaborati dal backlog in una posizione che può essere ricercata e risolta in un secondo momento. 
+  Riprova o, se possibile, elimina i vecchi messaggi confrontandoli con il timestamp del messaggio ed eliminando i messaggi che non sono più rilevanti per il client richiedente. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL04-BP02 Implementazione di dipendenze "loosely coupled"](rel_prevent_interaction_failure_loosely_coupled_system.md) 
+  [REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)](rel_mitigate_interaction_failure_throttle_requests.md) 
+  [REL05-BP03 Controllo e limitazione delle chiamate di ripetizione](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL06-BP02 Definizione e calcolo dei parametri (aggregazione)](rel_monitor_aws_resources_notification_aggregation.md) 
+  [REL06-BP07 Monitoraggio del tracciamento end-to-end delle richieste attraverso il sistema](rel_monitor_aws_resources_end_to_end.md) 

 **Documenti correlati:** 
+ [ Evitare backlog di coda insormontabili ](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+  [Anticipazione degli errori (fail fast)](https://www.martinfowler.com/ieeeSoftware/failFast.pdf) 
+ [ Come posso prevenire un aumento del backlog dei messaggi nella mia coda Amazon SQS? ](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [ Elastic Load Balancing: spostamento zonale ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [ Sistema di controllo Amazon Route 53 per il ripristino di applicazioni: controllo dell'instradamento per il failover del traffico ](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)

 **Esempi correlati:** 
+ [ Modelli di integrazione aziendale: canale DLQ ](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)

 **Video correlati:** 
+  [AWS re:Invent 2022 - Operating highly available Multi-AZ applications (Esecuzione di applicazioni multi-AZ a disponibilità elevata)](https://www.youtube.com/watch?v=mwUV5skJJ0s) 

 **Strumenti correlati:** 
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon MQ ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)

# REL05-BP05 Impostazione dei timeout dei client
<a name="rel_mitigate_interaction_failure_client_timeouts"></a>

Imposta i timeout in modo appropriato per connessioni e richieste, verificali sistematicamente e non fare affidamento sui valori predefiniti perché non fanno riferimento alle specifiche del carico di lavoro.

 **Risultato desiderato:** I timeout dei client devono considerare il costo per client, server e carico di lavoro associato all'attesa di richieste il cui completamento richiede una quantità di tempo anomala. Poiché non è possibile conoscere la causa esatta di un timeout, i client devono fare riferimento ai servizi per sviluppare ipotesi sulle cause probabili e sui timeout appropriati. 

 Il timeout delle connessioni client si verifica in base ai valori configurati. Dopo aver rilevato un timeout, i client decidono di riprovare o aprire un [interruttore](https://martinfowler.com/bliki/CircuitBreaker.html). Questi modelli evitano la generazione di richieste che potrebbero aggravare una condizione di errore sottostante. 

 **Anti-pattern comuni:** 
+  Non essere a conoscenza dei timeout di sistema o dei timeout predefiniti. 
+  Non essere a conoscenza dei normali tempi di completamento delle richieste. 
+  Non essere a conoscenza delle possibili cause dei tempi anomali necessari per il completamento delle richieste o dei costi in termini di prestazioni di client, servizio o carico di lavoro associati all'attesa di tali completamenti. 
+  Non essere consapevoli della probabilità che una rete danneggiata causi un errore di esecuzione della richiesta solo al raggiungimento del timeout, nonché dei costi in termini di prestazioni del client e del carico di lavoro derivanti dalla mancata adozione di un timeout più breve. 
+  Non testare gli scenari di timeout sia per le connessioni che per le richieste. 
+  Impostazione di timeout troppo elevati, che può comportare lunghi tempi di attesa e aumentare l'utilizzo delle risorse. 
+  Impostazione di timeout troppo bassi, con conseguenti errori artificiali. 
+  Mancata verifica degli schemi per gestire gli errori di timeout per chiamate remote come interruttori e nuovi tentativi. 
+  Non considerare il monitoraggio delle percentuali di errore delle chiamate dei servizi, degli obiettivi del livello di servizio per la latenza e dei valori anomali della latenza. Queste metriche possono fornire informazioni sui timeout restrittivi o permissivi. 

 **Vantaggi dell'adozione di questa best practice:** I timeout delle chiamate remote sono configurati e i sistemi sono progettati per gestirli correttamente, in modo da preservare le risorse quando le chiamate remote rispondono in modo eccessivamente lento e gli errori di timeout vengono gestiti correttamente dai client di servizio. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Imposta sia un timeout di connessione che un timeout della richiesta su qualsiasi chiamata della dipendenza del servizio e, generalmente, su qualsiasi chiamata tra i processi. Molti framework offrono funzionalità di timeout integrate, ma è necessario prestare attenzione perché alcuni sono caratterizzati da valori predefiniti infiniti o superiori a quelli accettabili per gli obiettivi dei tuoi servizi. Un valore troppo elevato riduce l'utilità del timeout perché le risorse continuano a essere consumate mentre il client attende che si verifichi il timeout. Un valore troppo basso può generare un aumento del traffico sul back-end e una maggiore latenza perché vengono ritentate troppe richieste. In alcuni casi, questo può portare a interruzioni vere e proprie perché tutte le richieste vengono ritentate. 

 Considera quanto segue per determinare le strategie di timeout: 
+  L'elaborazione delle richieste può richiedere più tempo del normale a causa del loro contenuto, di problemi nel servizio di destinazione o di un errore nella partizione della rete. 
+  Le richieste con contenuti troppo costosi potrebbero consumare risorse server e client non necessarie. In questo caso, forzare il timeout di queste richieste e non eseguire nuovi tentativi possono preservare le risorse. I servizi dovrebbero, inoltre, proteggersi da contenuti eccessivamente costosi con limitazioni e timeout lato server. 
+  Per le richieste con tempi di elaborazione eccessivamente lunghi a causa di un'interruzione del servizio è possibile forzare il timeout e, quindi, eseguire un nuovo tentativo. È necessario considerare i costi del servizio per la richiesta e il nuovo tentativo, ma se la causa è un problema localizzato, è probabile che un nuovo tentativo non sia costoso e riduca il consumo di risorse del client. Il timeout può anche liberare risorse del server a seconda della natura del problema. 
+  Per le richieste il cui completamento richiede troppo tempo o per risposte non distribuite dalla rete è possibile forzare il timeout e, quindi, eseguire un nuovo tentativo. Poiché la richiesta o la risposta non è stata distribuita, viene comunque restituito un errore indipendentemente dalla durata del timeout. Il timeout in questo caso non rilascerà le risorse del server, ma le risorse del client, con il conseguente miglioramento delle prestazioni del carico di lavoro. 

 Sfrutta modelli di progettazione consolidati come i nuovi tentativi e interruttori per gestire normalmente i timeout e supportare l'approccio all'anticipazione degli errori (fail fast). [AWS SDK](https://docs.aws.amazon.com/index.html#sdks) e la [AWS CLI](https://aws.amazon.com/cli/) consentono la configurazione dei timeout per connessioni e richieste dei nuovi tentativi con backoff esponenziale e jitter. [Le funzioni AWS Lambda](https://aws.amazon.com/lambda/) supportano la configurazione dei timeout e con [AWS Step Functions](https://aws.amazon.com/step-functions/)puoi creare interruttori a uso limitato di codice che sfruttano le integrazioni predefinite con i servizi e gli SDK AWS. [AWS App Mesh](https://aws.amazon.com/app-mesh/) Envoy fornisce funzionalità di tipo timeout e interruttore. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Configura i timeout per le chiamate remote dei servizi e sfrutta le funzionalità di timeout integrate o le librerie di timeout open source. 
+  Quando il carico di lavoro esegue chiamate con un SDK AWS, consulta la documentazione per la configurazione del timeout specifica della lingua. 
  + [ Python ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
  + [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
  + [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
  + [ Ruby ](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
  + [ Java ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
  + [ Go ](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
  + [ Node.js ](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
  + [ C\$1\$1 ](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+  Quando usi SDK AWS o comandi AWS CLI nel carico di lavoro, configura i valori di timeout predefiniti impostando i valori di configurazione AWS [predefiniti](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) per `connectTimeoutInMillis` e `tlsNegotiationTimeoutInMillis`. 
+  Applica le [opzioni della riga di comando](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout` e `cli-read-timeout` per controllare i comandi AWS CLI occasionali nei servizi AWS. 
+  Monitora le chiamate remote dei servizi per i timeout e imposta gli allarmi sugli errori persistenti in modo da poter gestire in modo proattivo gli scenari di errore. 
+  Implementa [le metriche CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) e [il rilevamento delle anomalie CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) per le percentuali di errore nelle chiamate, gli obiettivi dei livelli di servizio per la latenza e i valori anomali della latenza per ottenere informazioni sulla gestione dei timeout eccessivamente restrittivi o permissivi. 
+  Configura i timeout per [le funzioni Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console). 
+  I client API Gateway devono implementare nuovi tentativi specifici durante la gestione dei timeout. API Gateway supporta un [timeout di integrazione da 50 millisecondi a 29 secondi](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) per le integrazioni downstream e non effettua nuovi tentativi quando l'integrazione richiede il timeout. 
+  Implementa lo schema basato sull' [interruttore](https://martinfowler.com/bliki/CircuitBreaker.html) per evitare di effettuare chiamate remote quando si è verificato il timeout. Apri l'interruttore per evitare chiamate non riuscite e chiudi l'interruttore quando le chiamate rispondono normalmente. 
+  Per i carichi di lavoro basati su container, verifica le funzioni [App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) per usare i timeout e gli interruttori integrati. 
+  Utilizza AWS Step Functions per creare interruttori a uso limitato di codice per le chiamate remote dei servizi, in particolare quando vengono richiamati gli SDK AWS nativi e le integrazioni Step Functions supportate per semplificare il carico di lavoro. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL05-BP03 Controllo e limitazione delle chiamate di ripetizione](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL05-BP04 Anticipazione degli errori e limitazione delle code](rel_mitigate_interaction_failure_fail_fast.md) 
+  [REL06-BP07 Monitoraggio del tracciamento end-to-end delle richieste attraverso il sistema](rel_monitor_aws_resources_end_to_end.md) 

 **Documenti correlati:** 
+  [AWS SDK: Retries and Timeouts (SDK AWS: nuovi tentativi e timeout)](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) 
+  [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 
+ [ Quote Amazon API Gateway e note importanti ](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface: opzioni della riga di comando ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: configurazione dei timeout delle API ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS Botocore mediante l'oggetto config e informazioni di riferimento sulla configurazione ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK per .NET: nuovi tentativi e timeout ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda: configurazione delle opzioni della funzione Lambda ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)

 **Esempi correlati:** 
+ [ Utilizzo dello schema dell'interruttore con AWS Step Functions e Amazon DynamoDB ](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [ Martin Fowler: CircuitBreaker ](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)

 **Strumenti correlati:** 
+ [AWS SDK ](https://docs.aws.amazon.com/index.html#sdks)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)

# REL05-BP06 Rendere i servizi stateless laddove possibile
<a name="rel_mitigate_interaction_failure_stateless"></a>

 I servizi non devono richiedere lo stato oppure devono eseguire l'offload dello stato in modo tale che, tra diverse richieste client, non vi sia alcuna dipendenza dai dati archiviati localmente su disco o in memoria. In questo modo i server possono essere sostituiti a piacimento senza compromettere la disponibilità. Amazon ElastiCache o Amazon DynamoDB sono ottime destinazioni per lo stato di offload. 

![\[In questa applicazione Web stateless, viene eseguito l'offload dello stato della sessione in Amazon ElastiCache.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/stateless-webapp.png)


 Quando gli utenti o i servizi interagiscono con un'applicazione, spesso eseguono una serie di interazioni che formano una sessione. Una sessione è un dato univoco per gli utenti che persistono tra le richieste mentre utilizzano l'applicazione. Un'applicazione stateless è un'applicazione che non richiede la conoscenza delle interazioni precedenti e non memorizza le informazioni sulla sessione. 

 Una volta progettata per essere stateless, puoi utilizzare servizi di elaborazione serverless, come AWS Lambda o AWS Fargate. 

 Oltre alla sostituzione del server, un altro vantaggio delle applicazioni stateless è che possono ricalibrare orizzontalmente perché qualsiasi risorsa di calcolo disponibile (ad esempio istanze EC2 e funzioni AWS Lambda) può soddisfare ogni richiesta. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Trasforma le applicazioni in stateless. Applicazioni stateless consentono un dimensionamento orizzontale e sono tolleranti al guasto di un singolo nodo. 
  +  Eliminazione dello stato che potrebbe effettivamente essere memorizzato nei parametri di richiesta. 
  +  Dopo aver esaminato se lo stato è necessario, sposta qualsiasi tracciamento dello stato in una cache multizona resiliente o in un archivio di dati come Amazon ElastiCache, Amazon RDS, Amazon DynamoDB o una soluzione di dati distribuiti di terze parti. Memorizza uno stato impossibile da spostare in datastore resilienti. 
    +  Alcuni dati (come i cookie) possono passare nei titoli o nei parametri di query. 
    +  Effettua il refactoring per rimuovere uno stato che può essere passato velocemente nelle richieste. 
    +  È possibile che alcuni dati non siano effettivamente necessari per richiesta e possano essere recuperati on demand. 
    +  Rimuovi i dati recuperabili in modo asincrono. 
    +  Scegli un datastore che soddisfi i requisiti per uno stato necessario. 
    +  Valuta l'utilizzo di un database NoSQL per dati non relazionali. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) 
+  [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 
+  [The Amazon Builders' Library: Sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 

# REL05-BP07 Implementazione di leve di emergenza
<a name="rel_mitigate_interaction_failure_emergency_levers"></a>

 Le leve di emergenza sono processi rapidi che possono mitigare l'impatto sulla disponibilità sul carico di lavoro. 

 Le leve di emergenza disabilitano, limitano o modificano il comportamento di componenti o dipendenze mediante meccanismi noti e testati. Ciò può ridurre i danni causati al carico di lavoro dall'esaurimento delle risorse dovuto ad aumenti imprevisti della domanda e l'impatto dei guasti nei componenti non critici all'interno del carico di lavoro. 

 **Risultato desiderato:** implementando le leve di emergenza, è possibile stabilire processi validi noti per garantire la disponibilità dei componenti critici nel carico di lavoro. Il carico di lavoro dovrebbe diminuire gradualmente e continuare a svolgere le sue funzioni aziendali critiche durante l'attivazione di una leva di emergenza. Per ulteriori informazioni sulla parziale riduzione delle prestazioni, consulta [REL05-BP01 Implementazione della normale riduzione delle prestazioni per trasformare le dipendenze forti applicabili in dipendenze deboli](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html). 

 **Anti-pattern comuni:** 
+  L'errore a livello di dipendenze non critiche influisce sulla disponibilità del carico di lavoro principale. 
+  Mancato test o mancata verifica del comportamento dei componenti critici durante il deterioramento delle prestazioni dei componenti non critici. 
+  Mancata definizione di criteri chiari e deterministici per l'attivazione o la disattivazione di una leva di emergenza. 

 **Vantaggi dell'adozione di questa best practice:** l'implementazione delle leve di emergenza può migliorare la disponibilità dei componenti critici del carico di lavoro fornendo ai risolutori processi consolidati per rispondere a picchi di domanda imprevisti o errori a livello di dipendenze non critiche. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Identifica i componenti critici del tuo carico di lavoro. 
+  Progetta e definisci l'architettura dei componenti critici del tuo carico di lavoro in modo che sia in grado di sostenere i guasti dei componenti non critici. 
+  Esegui i test per convalidare il comportamento dei componenti critici in caso di guasti dei componenti non critici. 
+  Definisci e monitora le metriche o i trigger pertinenti per avviare le procedure relative alle leve di emergenza. 
+  Definisci le procedure (manuali o automatiche) che includono la leva di emergenza. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Identifica i componenti business-critical nel tuo carico di lavoro. 
  +  Ogni componente tecnico del carico di lavoro deve essere mappato alla funzione aziendale pertinente e classificato come critico o non critico. Per esempi di funzionalità critiche e non critiche in Amazon, consulta [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering) (informazioni in lingua inglese). 
  +  Si tratta di una decisione sia tecnica che aziendale e varia in base all'organizzazione e al carico di lavoro. 
+  Progetta e definisci l'architettura dei componenti critici del tuo carico di lavoro in modo che sia in grado di sostenere i guasti dei componenti non critici. 
  +  Durante l'analisi delle dipendenze, valuta tutte le potenziali modalità di guasto e verifica che i meccanismi basati su leve di emergenza forniscano le funzionalità critiche ai componenti a valle. 
+  Esegui i test per convalidare il comportamento dei componenti critici durante l'attivazione delle leve di emergenza. 
  +  Evita il comportamento bimodale. Per maggiori dettagli, consulta [REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html). 
+  Definisci, monitora e attiva gli avvisi per le metriche pertinenti per avviare la procedura relative alla leva di emergenza. 
  +  L'individuazione delle metriche da monitorare dipende dal carico di lavoro. Alcuni esempi di metrica sono la latenza o il numero di richieste non riuscite nei confronti di una dipendenza. 
+  Definisci le procedure (manuali o automatiche) che includono la leva di emergenza. 
  +  Ciò può includere meccanismi come la [riduzione del carico](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), le [richieste di limitazione della larghezza di banda della rete (throttling)](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) o l'implementazione di una [parziale riduzione delle prestazioni](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL05-BP01 Implementazione della normale riduzione delle prestazioni per trasformare le dipendenze forti applicabili in dipendenze deboli](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html) 
+  [REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) 
+  [REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html) 

 **Documenti correlati:** 
+ [Automazione di implementazioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+  [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering) (informazioni in lingua inglese) 

 **Video correlati:** 
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability](https://www.youtube.com/watch?v=jUSYnRztttY)

# Gestione delle modifiche
<a name="a-change-management"></a>

**Topics**
+ [REL 6. Come monitorare le risorse del carico di lavoro?](rel-06.md)
+ [REL 7. Come si progetta il carico di lavoro per adattarsi ai cambiamenti della domanda?](rel-07.md)
+ [REL 8. In che modo implementare le modifiche?](rel-08.md)

# REL 6. Come monitorare le risorse del carico di lavoro?
<a name="rel-06"></a>

I log e i parametri sono strumenti molto efficaci per ottenere informazioni sullo stato del tuo carico di lavoro. È possibile configurare il carico di lavoro in modo da monitorare i log e i parametri e inviare notifiche quando vengono superate le soglie o si verificano eventi significativi. Il monitoraggio permette al carico di lavoro di riconoscere quando vengono superate le soglie di prestazioni basse o si verificano errori, in modo che possa essere ripristinato automaticamente di rimando.

**Topics**
+ [REL06-BP01 Monitoraggio di tutti i componenti per il carico di lavoro (generazione)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Definizione e calcolo dei parametri (aggregazione)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 Invio di notifiche (elaborazione e avvisi in tempo reale)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 Automatizzazione delle risposte (elaborazione e avvisi in tempo reale)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 Analisi](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 Esecuzione di revisioni periodiche](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 Monitoraggio del tracciamento end-to-end delle richieste attraverso il sistema](rel_monitor_aws_resources_end_to_end.md)

# REL06-BP01 Monitoraggio di tutti i componenti per il carico di lavoro (generazione)
<a name="rel_monitor_aws_resources_monitor_resources"></a>

 monitora i componenti del carico di lavoro con Amazon CloudWatch o con strumenti di terze parti. Monitora i servizi AWS con il pannello di controllo AWS Health. 

 Occorre monitorare tutti i componenti del carico di lavoro, inclusi front-end, logica aziendale e livelli di storage. Definisci i parametri chiave e come estrarli dai registri, se necessario, e imposta soglie per l'attivazione degli eventi di allarme corrispondenti. Assicurati che i parametri siano pertinenti agli indicatori chiave di prestazione (KPI) del tuo carico di lavoro e utilizza i parametri e i registri per identificare i primi segnali di degrado del servizio. Ad esempio, un parametro legato ai risultati aziendali, come il numero di ordini elaborati con successo al minuto, può indicare problemi di carico di lavoro più rapidamente di un parametro tecnico, come l'utilizzo della CPU. Utilizza il pannello di controllo AWS Health per una visualizzazione personalizzata delle prestazioni e della disponibilità dei servizi AWS sottostanti alle risorse AWS. 

 Il monitoraggio nel cloud offre nuove opportunità. La maggior parte dei provider cloud ha sviluppato hook personalizzabili e può fornire approfondimenti per aiutarti a monitorare più livelli del carico di lavoro. I servizi AWS come Amazon CloudWatch applicano algoritmi statistici e di apprendimento automatico per analizzare continuamente i parametri di sistemi e applicazioni, determinare le normali linee di base e far emergere le anomalie con un intervento minimo da parte dell'utente. Gli algoritmi di rilevamento delle anomalie tengono conto della stagionalità e delle variazioni di tendenza dei parametri. 

 AWS mette a disposizione una grande quantità di informazioni di monitoraggio e di registro che possono essere utilizzate per definire parametri specifici per i carichi di lavoro, processi di variazione della domanda e per l'adozione di tecniche di apprendimento automatico indipendentemente dalle competenze di ML. 

 Inoltre, monitora tutti gli endpoint esterni per avere la certezza che siano indipendenti dall'implementazione di base. Questo monitoraggio attivo può essere effettuato con transazioni sintetiche (talvolta indicate come *canary utente,*ma da non confondere con le implementazioni canary) che eseguono periodicamente una serie di attività comuni che corrispondono alle azioni eseguite dai client del carico di lavoro. Mantieni queste attività di breve durata e assicurati di non sovraccaricare il carico di lavoro durante il test. Amazon CloudWatch Synthetics ti consente di [creare canary sintetici](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) per monitorare gli endpoint e le API. Puoi anche combinare i nodi client sintetici Canary con la console AWS X-Ray per individuare quali Canary sintetiche stanno riscontrando problemi con errori, guasti o velocità di throttling per l'intervallo di tempo selezionato. 

 **Risultato desiderato: ** 

 raccogliere e utilizzare i parametri critici di tutti i componenti del carico di lavoro per garantire l'affidabilità del carico di lavoro e un'esperienza utente ottimale. Rilevare che un carico di lavoro non sta raggiungendo i risultati aziendali consente di dichiarare rapidamente un disastro e di riprendersi da un incidente. 

 **Anti-pattern comuni:** 
+  Solo monitoraggio delle interfacce esterne per il carico di lavoro. 
+  Non generare parametri specifici per il carico di lavoro e affidati solo ai parametri forniti dai servizi AWS utilizzati dal carico di lavoro. 
+  Utilizzare solo parametri tecnici nel carico di lavoro e non monitorare i parametri relativi agli indicatori chiave di prestazione (KPI) non tecnici a cui il carico di lavoro contribuisce. 
+  Affidarsi al traffico di produzione e a semplici controlli di integrità per monitorare e valutare lo stato del carico di lavoro. 

 **Vantaggi dell'adozione di questa best practice:** il monitoraggio a tutti i livelli del carico di lavoro consente di prevedere e risolvere più rapidamente i problemi dei componenti che costituiscono il carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>

1.  **Abilitazione della registrazione ove disponibile.** I dati di monitoraggio devono essere ottenuti da tutti i componenti dei carichi di lavoro. Attiva ulteriori registri, come i registri di accesso S3, e abilita il carico di lavoro per registrare i dati specifici del carico di lavoro. Raccogli i parametri per le medie di CPU, I/O di rete e I/O su disco da servizi come Amazon ECS, Amazon EKS, Amazon EC2, Elastic Load Balancing, AWS Auto Scaling ed Amazon EMR. Consulta [Servizi AWS che pubblicano parametri CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) Servizi AWS che pubblicano parametri su CloudWatch. 

1.  **Esamina tutti i parametri predefiniti ed esplora eventuali lacune nella raccolta dei dati.** Tutti i servizi generano parametri predefiniti. La raccolta di parametri predefiniti consente di comprendere meglio le dipendenze tra i componenti del carico di lavoro e il modo in cui l'affidabilità e le prestazioni dei componenti influiscono sul carico di lavoro. Puoi anche creare e [pubblicare parametri propri](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) affinché CloudWatch utilizzi la AWS CLI o un'API. Questo 

1.  **valuta tutti i parametri per decidere quelli a cui inviare avvisi per ogni servizio AWS nel carico di lavoro.** Puoi scegliere di selezionare un sottoinsieme di parametri che hanno un impatto importante sull'affidabilità del carico di lavoro. La focalizzazione su soglie e parametri critici consente di affinare il numero di avvisi [informativi](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) e può contribuire a ridurre al minimo i falsi positivi. 

1.  **Definisci gli avvisi e il processo di recupero del carico di lavoro dopo l'attivazione dell'avviso.** La definizione degli avvisi consente di notificare, intensificare e seguire rapidamente le fasi necessarie per il ripristino da un incidente e il rispetto dell'obiettivo di tempo di ripristino (RTO) prescritto. Puoi utilizzare [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) per invocare flussi di lavoro automatici e avviare procedure di ripristino in base a soglie definite. 

1.  **Esplora l'uso di transazioni sintetiche per raccogliere dati rilevanti sullo stato dei carichi di lavoro.** Il monitoraggio sintetico segue gli stessi percorsi ed esegue le stesse azioni di un cliente, il che consente di verificare continuamente l'esperienza del cliente anche quando non c'è traffico di clienti sui carichi di lavoro. Utilizzando [le transazioni sintetiche,](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)puoi individuare i problemi prima dei clienti. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md)

 **Documenti correlati:** 
+  [Getting started with your AWS Health Dashboard – Your account health (Nozioni di base su AWS HealthDashboard: stato del tuo account)](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) 
+  [Servizi AWS che pubblicano parametri CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
+  [Log di accesso per Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html) 
+  [Log di accesso per Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html) 
+  [Accesso a Amazon CloudWatch Logs per AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html) 
+  [Registrazione delle richieste con registrazione dell'accesso al server Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html) 
+  [Abilita i log di accesso per Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html) 
+  [Esportazione di dati di registro in Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 
+  [Installazione dell'agente CloudWatch su un'istanza Amazon EC2](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html) 
+  [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Utilizzo dei pannelli di controllo Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Utilizzare i parametri Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
+  [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [Cosa sono i Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 

   **Guide per l'utente:** 
+  [Creazione di un trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) 
+  [Monitoraggio dei parametri di memoria e del disco per le istanze Amazon EC2 Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html) 
+  [Utilizzo di CloudWatch Logs con istanze di container](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
+  [Log di flusso VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html) 
+  [Che cos'è Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  [Che cos'è AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 

 **Blog correlati:** 
+  [Effettuare il debug con Amazon CloudWatch Synthetics e AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 

 **Esempi e workshop correlati:** 
+  [AWS Well-Architected Labs: Operational Excellence - Dependency Monitoring (Laboratori ben strutturati AWS: Eccellenza operativa - Monitoraggio delle dipendenze)](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/) 
+  [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Workshop sull'osservabilità](https://catalog.workshops.aws/observability/en-US) 

# REL06-BP02 Definizione e calcolo dei parametri (aggregazione)
<a name="rel_monitor_aws_resources_notification_aggregation"></a>

 Archivia i dati di registro e applica i filtri, laddove necessari, per calcolare i parametri, ad esempio i conteggi di un evento di registro specifico o la latenza calcolata dai timestamp del registro eventi. 

 Amazon CloudWatch e Amazon S3 fungono da principali livelli di aggregazione e storage. Per alcuni servizi, come AWS Auto Scaling e Elastic Load Balancing, i parametri predefiniti vengono forniti per impostazione predefinita per il carico della CPU o la latenza media delle richieste in un cluster o in un'istanza. Per i servizi di streaming, come i registri di flusso VPC e AWS CloudTrail, i dati degli eventi vengono inoltrati a CloudWatch Logs ed è necessario definire e applicare filtri di parametri per estrarre i parametri dai dati dell'evento. In questo modo vengono forniti dati di serie temporali, che possono fungere da input per gli allarmi CloudWatch definiti dall'utente per attivare gli avvisi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Aggregazione: definisci e calcola i parametri. Archivia i dati di log e applica filtri, se necessario, per calcolare i parametri, ad esempio i conteggi di un evento di log specifico o la latenza calcolata dai timestamp degli eventi di log 
  +  I filtri dei parametri definiscono i termini e i modelli da ricercare nei dati di registro inviati a CloudWatch Logs. CloudWatch Logs utilizza questi filtri di parametri per trasformare i dati di registro in parametri CloudWatch numerici che è possibile rappresentare su un grafico o un avviso. 
    +  [Ricerca e filtraggio dei dati di log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 
  +  Utilizza una terza parte affidabile per aggregare i registri. 
    +  Segui le istruzioni che ti vengono fornite dalle terze parti. La maggior parte dei prodotti di terze parti si integra con CloudWatch e Amazon S3. 
  +  Alcuni servizi AWS possono pubblicare registri direttamente in Amazon S3. Se il requisito principale per i registri è l'archiviazione in Amazon S3, si può facilmente fare in modo che il servizio che produce i registri li invii direttamente a Amazon S3, senza dover creare un'infrastruttura aggiuntiva. 
    +  [Invio di registri direttamente a Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Query di esempio di Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Effettuare il debug con Amazon CloudWatch Synthetics e AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [One Observability Workshop](https://observability.workshop.aws/) 
+  [Ricerca e filtraggio dei dati di log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 
+  [Invio di registri direttamente a Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 
+  [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 

# REL06-BP03 Invio di notifiche (elaborazione e avvisi in tempo reale)
<a name="rel_monitor_aws_resources_notification_monitor"></a>

Quando le organizzazioni rilevano potenziali problemi, inviano notifiche e avvisi in tempo reale ai team e ai sistemi appropriati per rispondere rapidamente ed efficacemente alle difficoltà.

 **Risultato desiderato:** è possibile rispondere rapidamente agli eventi operativi attraverso la configurazione di allarmi pertinenti in base ai parametri del servizio e dell'applicazione. Quando la soglia degli allarmi viene superata, i team e i sistemi appropriati vengono informati in modo che possano risolvere i problemi sottostanti. 

 **Anti-pattern comuni:** 
+ Configuri gli allarmi con una soglia eccessivamente alta, con conseguente mancato invio di notifiche importanti.
+ Configuri gli allarmi con una soglia troppo bassa, con il risultato che gli avvisi importanti non vengono presi in considerazione a causa del numero eccessivo di notifiche generate.
+  Non aggiorni gli allarmi e la relativa soglia quando cambia l'utilizzo. 
+  Per gli allarmi gestiti meglio tramite le azioni automatizzate, l'invio della notifica ai team anziché l'attivazione dell'azione automatizzata comporta la generazione di un numero eccessivo di notifiche. 

 **Vantaggi dell'adozione di questa best practice:** l'invio di notifiche e avvisi in tempo reale ai team e ai sistemi appropriati consente di individuare tempestivamente i problemi e di rispondere rapidamente agli incidenti operativi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I carichi di lavoro devono essere dotati di sistemi di elaborazione e allarme in tempo reale per migliorare l'identificazione dei problemi che possono influire sulla disponibilità dell'applicazione e fungere da trigger per la risposta automatizzata. Le organizzazioni possono eseguire un sistema di elaborazione e allarme in tempo reale creando avvisi con parametri definiti in modo da ricevere le notifiche ogni volta che si verificano eventi significativi o un parametro supera una determinata soglia. 

 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) ti permette di creare [allarmi](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) compositi e di parametri utilizzando gli allarmi CloudWatch basati su soglie statiche, rilevamento di anomalie e altri criteri. Per maggiori dettagli sui tipi di allarmi che puoi configurare utilizzando CloudWatch, consulta la [sezione allarmi della documentazione CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). 

 Puoi creare per i tuoi team visualizzazioni personalizzate dei parametri e degli avvisi delle risorse AWS utilizzando le [dashboard CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). Le home page personalizzabili nella console di CloudWatch consentono di monitorare le risorse di più regioni in un'unica visualizzazione. 

 Gli allarmi possono eseguire una o più azioni, come inviare una notifica a un [argomento Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), eseguendo un'azione su [Amazon EC2](https://aws.amazon.com/ec2/) o un'azione su [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) oppure [creando un OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) o [a](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) in AWS Systems Manager. 

 Amazon CloudWatch utilizza [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) per inviare le notifiche quando l'allarme cambia stato, con la distribuzione dei messaggi degli editori (produttori) agli abbonati (consumatori). Per maggiori dettagli sull'impostazione delle notifiche Amazon SNS, consulta [Configurazione di Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html). 

 CloudWatch invia [EventBridge](https://aws.amazon.com/eventrbridge/) [della sicurezza](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html) ogni volta che un allarme CloudWatch viene creato, aggiornato, eliminato o cambia stato. Puoi usare EventBridge con questi eventi per creare le regole che eseguono le azioni, come avvisare ogni volta che lo stato di un allarme cambia o attivare automaticamente gli eventi nel tuo account tramite [l'automazione Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html). 

** Quando si usa EventBridge rispetto ad Amazon SNS? **

 EventBridge e Amazon SNS possono entrambi essere utilizzati per sviluppare applicazioni basate su eventi e la scelta dipende dalle tue esigenze specifiche. 

 Amazon EventBridge è consigliato quando desideri creare un'applicazione che reagisca agli eventi delle tue applicazioni, delle applicazioni SaaS e dei servizi AWS. EventBridge è l'unico servizio basato su eventi che si integra direttamente con i partner SaaS di terze parti. EventBridge inoltre acquisisce automaticamente eventi da oltre 200 servizi AWS senza richiedere agli sviluppatori di creare risorse negli account. 

 EventBridge utilizza una struttura definita basata su JSON per gli eventi e consente di creare regole applicate all'intero corpo dell'evento per selezionare gli eventi da inoltrare alle [destinazioni](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html). EventBridge attualmente supporta oltre 20 servizi AWS come destinazioni, tra cui [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html), [Amazon SQS](https://aws.amazon.com/sqs/), Amazon SNS, [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/)e [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/). 

 Amazon SNS è consigliato per le applicazioni che richiedono un fan-out elevato (migliaia o milioni di endpoint). Di solito i clienti utilizzano Amazon SNS come destinazione della regola per filtrare gli eventi di cui hanno bisogno e sottoporli al fan-out su più endpoint. 

 I messaggi non sono strutturati e possono essere in qualsiasi formato. Amazon SNS supporta l'inoltro dei messaggi a sei diversi tipi di destinazioni, tra cui Lambda, Amazon SQS, endpoint HTTP/S, SMS, push mobile ed e-mail. La latenza tipica di Amazon SNS [è inferiore a 30 millisecondi](https://aws.amazon.com/sns/faqs/). Un'ampia gamma di servizi AWS invia i messaggi Amazon SNS definendo la configurazione appropriata (più di 30, inclusi Amazon EC2, [Amazon S3](https://aws.amazon.com/s3/)e [Amazon RDS](https://aws.amazon.com/rds/)). 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Crea un allarme usando gli [avvisi Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). 

   1.  Un allarme di parametri monitora un singolo parametro CloudWatch o un'espressione dipendente dai parametri CloudWatch. L'allarme avvia una o più azioni in base al valore del parametro o dell'espressione rispetto a una soglia, per un determinato numero di intervalli di tempo. L'azione può consistere nell'inviare una notifica a un [argomento Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), eseguendo un'azione su [Amazon EC2](https://aws.amazon.com/ec2/) o un'azione su [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) oppure [creando un OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) o [a](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) in AWS Systems Manager. 

   1.  Un allarme composito è costituito da un'espressione di regola che considera le condizioni di altri allarmi che hai creato. L'allarme composito entra in stato di allarme solo se tutte le condizioni della regola sono soddisfatte. Gli allarmi specificati nell'espressione di regola di un allarme composito possono includere allarmi di parametri e allarmi compositi aggiuntivi. Gli allarmi compositi possono inviare notifiche Amazon SNS quando il loro stato cambia e possono creare Systems Manager [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) o [incidenti](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) quando entrano nello stato di allarme, ma non possono eseguire azioni Amazon EC2 o Auto Scaling. 

1.  Configura [le notifiche Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html). Quando si crea un allarme CloudWatch, è possibile includere un argomento Amazon SNS per inviare una notifica quando l'allarme cambia stato. 

1.  [Crea regole in EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) che corrisponde agli allarmi CloudWatch specificati. Ogni regola supporta più destinazioni, incluse le funzioni Lambda. Ad esempio, è possibile definire un allarme che si attiva quando lo spazio disponibile su disco si sta esaurendo e che esegue una funzione Lambda tramite una regola EventBridge per ripulire lo spazio. Per maggiori dettagli sulle destinazioni EventBridge, consulta [Destinazioni EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html). 

## Risorse
<a name="resources"></a>

 **Best practice Well-Architected correlate:** 
+  [REL06-BP01 Monitoraggio di tutti i componenti per il carico di lavoro (generazione)](rel_monitor_aws_resources_monitor_resources.md) 
+  [REL06-BP02 Definizione e calcolo dei parametri (aggregazione)](rel_monitor_aws_resources_notification_aggregation.md) 
+  [REL12-BP01 Utilizzo dei playbook per analizzare gli errori](rel_testing_resiliency_playbook_resiliency.md) 

 **Documenti correlati:** 
+ [ Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ CloudWatch Logs insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+  [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Utilizzo dei pannelli di controllo Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Utilizzare i parametri Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
+ [ Setting up Amazon SNS notifications ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [ il rilevamento delle anomalie CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ Protezione dei dati CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/protect-sensitive-log-data-types.html)
+ [ Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [ Amazon Simple Notification Service ](https://aws.amazon.com/sns/)

 **Video correlati:** 
+ [ Video sull'osservabilità di reinvent 2022 ](https://www.youtube.com/results?search_query=reinvent+2022+observability)
+ [AWS re:Invent 2022 - Observability best practices at Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8)

 **Esempi correlati:** 
+  [One Observability Workshop](https://observability.workshop.aws/) 
+ [ Amazon EventBridge to AWS Lambda with feedback control by Amazon CloudWatch Alarms ](https://serverlessland.com/patterns/cdk-closed-loop-serverless-control-pattern)

# REL06-BP04 Automatizzazione delle risposte (elaborazione e avvisi in tempo reale)
<a name="rel_monitor_aws_resources_automate_response_monitor"></a>

 utilizza l'automazione per agire quando viene rilevato un evento; ad esempio, per sostituire i componenti guasti. 

 L'elaborazione automatizzata in tempo reale degli allarmi è implementata in modo che i sistemi possano effettuare azioni correttive rapide e tentare di prevenire guasti o danni al servizio quando vengono attivati gli allarmi. Le risposte automatiche agli allarmi potrebbero includere la sostituzione dei componenti guasti, la regolazione della capacità di calcolo, il reindirizzamento del traffico verso host integri, zone di disponibilità o altre regioni e la notifica agli operatori. 

 **Risultato desiderato:** vengono identificati gli allarmi in tempo reale e viene impostata l'elaborazione automatizzata degli allarmi per richiamare le azioni appropriate per mantenere gli obiettivi dei livelli di servizio e gli accordi sul livello di servizio (SLA). L'automazione può interessare un ambito che va dalle attività di autoriparazione dei singoli componenti al failover dell'intero sito. 

 **Anti-pattern comuni:** 
+  Non disporre di un inventario o un catalogo dettagliato dei principali allarmi in tempo reale. 
+  Nessuna risposta automatica in caso di allarmi critici (ad esempio, quando le risorse di calcolo stanno per esaurirsi, viene implementato il dimensionamento automatico). 
+  Azioni di risposta agli allarmi contraddittorie. 
+  Nessuna procedura operativa standard (SOP) da seguire per gli operatori quando ricevono notifiche di avviso. 
+  Non monitorare le modifiche apportate alla configurazione, poiché le modifiche della configurazione non rilevate possono causare tempi di inattività per i carichi di lavoro. 
+  Non avere una strategia per annullare le modifiche involontarie alla configurazione. 

 **Vantaggi dell'adozione di questa best practice:** l'automazione dell'elaborazione degli allarmi può migliorare la resilienza del sistema. Il sistema implementa automaticamente azioni correttive, riducendo le attività manuali che possono comportare interventi umani soggetti a errori. L'operatività del carico di lavoro soddisfa gli obiettivi di disponibilità e riduce le interruzioni del servizio. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per gestire in modo efficiente gli avvisi e automatizzarne la risposta, classifica gli avvisi in base alla loro criticità e al loro impatto, documenta le procedure di risposta e pianifica le risposte prima di classificare le attività. 

 Identifica le attività che richiedono azioni specifiche (spesso dettagliate nei runbook) ed esamina tutti i runbook e i playbook per determinare quali attività possono essere automatizzate. Se è possibile definire delle azioni, significa che esse spesso possono essere automatizzate. Se le azioni non possono essere automatizzate, documenta le fasi manuali in una procedura operativa standard (SOP) e forma gli operatori su tali procedure. Continua ad analizzare dettagliatamente i processi manuali alla ricerca di opportunità di automazione in cui puoi stabilire e mantenere un piano per automatizzare le risposte agli avvisi. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  **Crea un inventario degli allarmi:** per ottenere un elenco di tutti gli allarmi, nella [AWS CLI](https://aws.amazon.com/cli/) puoi utilizzare il comando [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) `[describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html)`. A seconda del numero di allarmi configurati, potrebbe essere necessario utilizzare la paginazione per recuperare un sottoinsieme di allarmi per ogni chiamata o, in alternativa, è possibile utilizzare AWS SDK per recuperare gli allarmi mediante una [chiamata API](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-describing-alarms.html). 

1.  **Documenta tutte le azioni degli allarmi:** aggiorna un runbook con tutti gli allarmi e le relative azioni, indipendentemente dal fatto che siano manuali o automatiche. [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html) fornisce runbook predefiniti. Per ulteriori informazioni sui runbook, consulta [Working with runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html). Per informazioni dettagliate su come visualizzare il contenuto del runbook, consulta [View runbook content](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html#view-automation-json). 

1.  **Configura e gestisci le azioni associate agli allarmi:** per tutti gli allarmi che richiedono un'azione, specifica l'[azione automatizzata mediante CloudWatch SDK](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html). Ad esempio, puoi modificare automaticamente lo stato delle tue istanze Amazon EC2 in base a un allarme CloudWatch creando e abilitando o disabilitando le azioni associate a un allarme. 

    Puoi anche utilizzare [Amazon EventBridge](https://aws.amazon.com/eventbridge/) per rispondere automaticamente agli eventi di sistema, come problemi di disponibilità delle applicazioni o modifiche delle risorse. Puoi creare regole per indicare quali eventi ti interessano e le azioni da eseguire quando un evento soddisfa una regola. Le azioni che possono essere avviate automaticamente includono il richiamo di una funzione [AWS Lambda](https://aws.amazon.com/lambda/), il richiamo della funzionalità [Amazon EC2](https://aws.amazon.com/ec2/) `Run Command`, l'inoltro dell'evento a [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) e la visualizzazione del comando [Automate Amazon EC2 mediante EventBridge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html). 

1.  **Procedure operative standard (SOP):** in base ai componenti dell'applicazione, [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) consiglia più [modelli SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/sops.html). È possibile utilizzare queste SOP per documentare tutti i processi che un operatore deve seguire nel caso in cui venga generato un avviso. Puoi anche [creare una SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/building-sops.html) basata su raccomandazioni Resilience Hub, laddove sia necessaria un'applicazione Resilience Hubcon una policy di resilienza associata, nonché una valutazione cronologica della resilienza rispetto a tale applicazione. Le raccomandazioni per la SOP sono prodotte dalla valutazione della resilienza. 

    Resilience Hub in combinazione con Systems Manager consente di automatizzare le fasi delle SOP fornendo una serie di [documenti SSM](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-custom-ssm-doc.html) che è possibile utilizzare come base per tali SOP. Ad esempio, Resilience Hub può consigliare una SOP per aggiungere spazio su disco in base a un documento SSM di automazione esistente. 

1.  **Esegui azioni automatizzate utilizzando Amazon DevOps Guru:** puoi utilizzare [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) per monitorare automaticamente le risorse dell'applicazione per rilevare comportamenti anomali e fornire raccomandazioni mirate per accelerare i tempi di identificazione e riparazione dei problemi. Con DevOps Guru, puoi monitorare flussi di dati operativi quasi in tempo reale da più origini, tra cui metriche Amazon CloudWatch, [AWS Config](https://aws.amazon.com/config/), [AWS CloudFormation](https://aws.amazon.com/cloudformation/) e [AWS X-Ray](https://aws.amazon.com/xray/). È inoltre possibile utilizzare DevOps Guru per creare automaticamente [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) in OpsCenter e inviare eventi a [EventBridge per un'automazione aggiuntiva](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-eventbridge.html). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL06-BP01 Monitoraggio di tutti i componenti per il carico di lavoro (generazione)](rel_monitor_aws_resources_monitor_resources.md) 
+  [REL06-BP02 Definizione e calcolo dei parametri (aggregazione)](rel_monitor_aws_resources_notification_aggregation.md) 
+  [REL06-BP03 Invio di notifiche (elaborazione e avvisi in tempo reale)](rel_monitor_aws_resources_notification_monitor.md) 
+  [REL08-BP01 Utilizzo di runbook per attività standard come l'implementazione](rel_tracking_change_management_planned_changemgmt.md) 

 **Documenti correlati:** 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [Creating an EventBridge Rule That Triggers on an Event from an AWS Resource](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html) 
+  [One Observability Workshop](https://observability.workshop.aws/) 
+  [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [What is Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  [Gestione dei documenti di automazione (playbook)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 

 **Video correlati:** 
+ [AWS re:Invent 2022 - Best practice di visibilità in Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8)
+ [AWS re:Invent 2020: Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [ Introduction to AWS Resilience Hub](https://www.youtube.com/watch?v=_OTTCOjWqPo)
+ [ Create Custom Ticket Systems for Amazon DevOps Guru Notifications ](https://www.youtube.com/watch?v=Mu8IqWVGUfg)
+ [ Enable Multi-Account Insight Aggregation with Amazon DevOps Guru ](https://www.youtube.com/watch?v=MHezNcTSTbI)

 **Esempi correlati:** 
+ [ Workshop sull'affidabilità ](https://wellarchitectedlabs.com/reliability/)
+ [Workshop su Amazon CloudWatch e Systems Manager](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US)

# REL06-BP05 Analisi
<a name="rel_monitor_aws_resources_storage_analytics"></a>

 raccogli i file di log e le cronologie dei parametri e analizzali per ottenere informazioni più ampie sulle tendenze e sui carichi di lavoro. 

 Amazon CloudWatch Logs Insights supporta un [linguaggio di query semplice ma potente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) che puoi utilizzare per analizzare i dati di log. Amazon CloudWatch Logs supporta anche le sottoscrizioni che consentono ai dati di fluire in modo ottimale verso Amazon S3, dove puoi utilizzare o Amazon Athena per eseguire query sui dati. Supporta, inoltre, le query su un'ampia gamma di formati. Consulta [SerDe e formati di dati supportati](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) nella Guida per l'utente Amazon Athena per ulteriori informazioni. Per l'analisi di enormi set di file di log, puoi eseguire un cluster Amazon EMR per effettuare analisi con capacità nell'ordine dei petabyte. 

 Esistono numerosi strumenti forniti da Partner AWS e terze parti che consentono aggregazione, elaborazione, archiviazione e analisi. Questi strumenti includono New Relic, Splunk, Loggly, Logstash, CloudHealth e Nagios. Tuttavia, la generazione esterna di log di sistema e applicazioni è univoca per ciascun provider di servizi cloud e spesso per ciascun servizio. 

 Una parte spesso trascurata del processo di monitoraggio è la gestione dei dati. È necessario determinare i requisiti di conservazione per il monitoraggio dei dati, quindi applicare le policy del ciclo di vita di conseguenza. Amazon S3 supporta la gestione del ciclo di vita a livello di bucket S3. Questa gestione del ciclo di vita può essere applicata in modo diverso ai diversi percorsi nel bucket. Verso la fine del ciclo di vita è possibile trasferire i dati su Amazon Glacier per l'archiviazione a lungo termine fino alla scadenza, al termine del periodo di conservazione. La classe di storage S3 Intelligent-Tiering è progettata per ottimizzare i costi trasferendo automaticamente i dati nel livello di accesso più conveniente, senza impatto sulle prestazioni o sovraccarico operativo. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Gli approfondimenti CloudWatch Logs consentono di cercare e analizzare in modo interattivo i dati di registro in Amazon CloudWatch Logs. 
  +  [Analisi dei dati di registro con gli approfondimenti CloudWatch Logs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
  +  [Query di esempio di Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 
+  Utilizza Amazon CloudWatch Logs per inviare registri a Amazon S3 dove puoi utilizzare Amazon Athena per le query dei dati. 
  +  [Come faccio ad analizzare i miei registri di accesso al server Amazon S3 utilizzando Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) 
    +  Crea una policy del ciclo di vita di S3 per il bucket dei log di accesso al server. Configura la policy del ciclo di vita per rimuovere periodicamente i file di log. In questo modo si riduce la quantità di dati che Athena deve analizzare per ogni query. 
      +  [Come faccio a creare una policy del ciclo di vita per un bucket S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Query di esempio di Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Analisi dei dati di registro con gli approfondimenti CloudWatch Logs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html) 
+  [Effettuare il debug con Amazon CloudWatch Synthetics e AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [Come faccio a creare una policy del ciclo di vita per un bucket S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) 
+  [Come faccio ad analizzare i miei registri di accesso al server Amazon S3 utilizzando Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) 
+  [One Observability Workshop](https://observability.workshop.aws/) 
+  [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 

# REL06-BP06 Esecuzione di revisioni periodiche
<a name="rel_monitor_aws_resources_review_monitoring"></a>

 Esegui verifiche frequenti delle modalità di implementazione del monitoraggio del carico di lavoro e aggiornalo in base a eventi e modifiche significativi. 

 Il monitoraggio efficace è basato su parametri aziendali chiave. Assicurati che questi parametri siano presenti nel carico di lavoro man mano che le priorità aziendali cambiano. 

 L'audit del monitoraggio consente di sapere quando un'applicazione sta raggiungendo gli obiettivi di disponibilità. L'analisi delle cause principali richiede la capacità di scoprire cosa è successo in caso di errori. AWS consente di monitorare lo stato dei tuoi servizi durante un incidente: 
+  **Amazon CloudWatch Logs:** è possibile archiviare i log in questo servizio e controllarne i contenuti. 
+  **Amazon CloudWatch Logs Insights**: è un servizio completamente gestito che consente di eseguire analisi di registri di grandi dimensioni in pochi secondi. Offre query e visualizzazioni rapide e interattive.  
+  **AWS Config:** è possibile vedere quale infrastruttura AWS era in uso in momenti differenti. 
+  **AWS CloudTrail:** è possibile vedere quali API AWS sono state richiamate, a che ora e da quale principale. 

 In AWS, conduciamo meeting settimanali per [esaminare le prestazioni operative](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) e condividere quanto appreso tra i team. Dato l'elevato numero di team presenti in AWS, abbiamo creato [La ruota](https://aws.amazon.com/blogs/opensource/the-wheel/) per scegliere casualmente un carico di lavoro da esaminare. Stabilire una cadenza regolare per le revisioni delle prestazioni operative e la condivisione delle conoscenze migliora la capacità di ottenere prestazioni più elevate dai team operativi. 

 **Anti-pattern comuni:** 
+  Raccolta dei soli parametri predefiniti. 
+  Impostazione di una strategia di monitoraggio senza alcuna revisione. 
+  Nessuna discussione sul monitoraggio quando vengono distribuite modifiche importanti. 

 **Vantaggi dell'adozione di questa best practice:** la verifica periodica del monitoraggio consente di prevedere potenziali problemi, invece di rispondere alle notifiche quando un problema previsto si verifica effettivamente. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Crea più pannelli di controllo per il carico di lavoro. È necessario disporre di un pannello di controllo di primo livello contenente i parametri aziendali chiave, nonché i parametri tecnici che hai identificato come i più rilevanti per lo stato previsto del carico di lavoro al variare dell'utilizzo. È inoltre importante disporre di pannelli di controllo per vari livelli di applicazione e dipendenze che è possibile ispezionare. 
  +  [Utilizzo dei pannelli di controllo Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  Pianifica ed effettua revisioni periodiche dei pannelli di controllo del carico di lavoro. Effettua un'ispezione regolare dei pannelli di controllo. La frequenza può essere diversa a seconda di quanto l'ispezione sia approfondita. 
  +  Ispeziona l'andamento nei parametri. Confronta i valori dei parametri con i valori storici per vedere se ci sono tendenze che potrebbero suggerire l'esame di un particolare aspetto. Riportiamo alcuni esempi: aumento della latenza, riduzione della funzione aziendale primaria e aumento delle risposte all'errore. 
  +  Identificazione di outlier/anomalie nei parametri. Le medie o mediane possono nascondere outlier e anomalie. Osserva i valori più alti e più bassi nell'intervallo di tempo e analizza le cause dei risultati estremi. Man mano che continui a eliminare tali cause, la riduzione del numero di valori estremi ti consente di continuare a migliorare la coerenza delle prestazioni del carico di lavoro. 
  +  Ricerca di bruschi cambiamenti nel comportamento. Un cambiamento repentino della quantità o della direzione di un parametro può indicare un cambiamento nell'applicazione o fattori esterni che potrebbero richiedere l'aggiunta di ulteriori parametri da monitorare. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Query di esempio di Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html) 
+  [Effettuare il debug con Amazon CloudWatch Synthetics e AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [One Observability Workshop](https://observability.workshop.aws/) 
+  [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [Utilizzo dei pannelli di controllo Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 

# REL06-BP07 Monitoraggio del tracciamento end-to-end delle richieste attraverso il sistema
<a name="rel_monitor_aws_resources_end_to_end"></a>

Tieni traccia delle richieste durante l'elaborazione dei componenti del servizio in modo che i team del prodotto possano analizzare i problemi, semplificarne il debug e migliorare le prestazioni.

 **Risultato desiderato:** I carichi di lavoro con tracciabilità completa di tutti i componenti sono caratterizzati da processi di debug più semplici e ciò migliora il [tempo medio di risoluzione](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html) (MTTR) degli errori e la latenza grazie alla semplificazione dell'individuazione delle cause principali. La tracciabilità end-to-end riduce il tempo necessario per individuare i componenti interessati e approfondire in dettaglio le cause principali degli errori o della latenza. 

 **Anti-pattern comuni:** 
+  Il tracciamento viene utilizzato per alcuni componenti ma non per tutti. Ad esempio, senza il tracciamento AWS Lambda, i team potrebbero non avere una chiara comprensione della latenza causata dagli avviamenti a freddo in un periodo di picco del carico di lavoro. 
+  I canary Synthetics o le metriche RUM (Real-User Monitoring) non sono configurati con il tracciamento. Senza canary o metriche RUM, la telemetria delle interazioni dei clienti viene omessa dall'analisi dei tracciamenti e ciò rende incompleto il profilo delle prestazioni. 
+  I carichi di lavoro ibridi includono strumenti di tracciamento nativi del cloud e di terze parti, ma non sono state prese misure specifiche per selezionare e integrare completamente un'unica soluzione di tracciamento. In base alla soluzione di tracciamento scelta, gli SDK di tracciamento nativi del cloud devono essere utilizzati per instrumentare i componenti non nativi del cloud oppure è necessario configurare strumenti di terze parti per acquisire i dati telemetrici delle tracce nativi del cloud. 

 **Vantaggi dell'adozione di questa best practice:** Quando vengono avvisati della presenza di problemi, i team di sviluppo possono visualizzare un quadro completo delle interazioni tra i componenti del sistema, inclusa la correlazione componente per componente con registrazione, prestazioni e guasti. Poiché il tracciamento semplifica l'identificazione visiva delle cause principali, viene dedicato meno tempo all'individuazione di tali cause. I team che hanno una visione dettagliata delle interazioni tra i componenti prendono decisioni migliori e più rapide durante la fase di risoluzione dei problemi. Le decisioni, ad esempio quando attivare il failover del ripristino di emergenza o dove implementare in modo più efficace le strategie di riparazione automatica, possono essere migliorate analizzando le tracce dei sistemi; ciò ottimizza in ultima analisi la soddisfazione dei clienti nei confronti dei servizi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I team che gestiscono le applicazioni distribuite possono utilizzare strumenti di tracciamento per definire un identificatore di correlazione, raccogliere le tracce delle richieste e creare mappe di servizio dei componenti connessi. Tutti i componenti dell'applicazione devono essere inclusi nelle tracce delle richieste, inclusi client di servizio, gateway middleware e router di eventi, componenti di elaborazione e archiviazione, tra cui gli archivi e i database dei valori chiave. Includi canary Synthetics o metriche RUM (Real-User Monitoring) nella configurazione del tracciamento end-to-end per misurare le interazioni e la latenza dei client remoti in modo da poter valutare con precisione le prestazioni dei tuoi sistemi rispetto agli accordi sul livello di servizio (SLA) e agli obiettivi corrispondenti. 

 Puoi utilizzare [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) e i servizi di strumentazione di [Monitoraggio delle applicazioni Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) per avere una visione completa delle richieste man mano che vengono inviate all'applicazione. X-Ray raccoglie la telemetria delle applicazioni e consente di visualizzare e filtrare i dati corrispondenti tra payload, funzioni, tracce, servizi e API. L'acquisizione dei dati telemetrici può essere attivata per i componenti di sistema senza codice o a uso limitato di codice. Monitoraggio delle applicazioni CloudWatch include ServiceLens per integrare le tracce con metriche, log e allarmi. La funzionalità Monitoraggio delle applicazioni CloudWatch include anche elementi Synthetics per monitorare gli endpoint e le API, oltre alle metriche RUM (Real-User Monitoring) per instrumentare i client delle applicazioni Web. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Utilizza AWS X-Ray su tutti i servizi nativi supportati come [Amazon S3, AWS Lambda e Amazon API Gateway](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html). Questi servizi AWS consentono a X-Ray di attivare opzioni di configurazione utilizzando l'infrastruttura come codice, AWS SDK o la Console di gestione AWS. 
+  Esegui l'instrumentazione delle applicazioni [AWS Distro per Open Telemetry e X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html) o degli agenti di raccolta di terze parti. 
+ Consulta la [Guida per gli sviluppatori AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) per l'implementazione di linguaggi di programmazione specifici. Queste sezioni della documentazione descrivono come instrumentare le richieste HTTP, le query SQL e altri processi specifici del linguaggio di programmazione delle applicazioni.
+  Usa il tracciamento X-Ray per [i canary Synthetics di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) e le metriche [RUM Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) per analizzare il percorso delle richiesta dal client dell'utente finale attraverso l'infrastruttura AWS downstream. 
+  Configura le metriche CloudWatch e gli allarmi in base allo stato delle risorse e alla telemetria dei canary in modo che i team siano avvisati tempestivamente in merito ai problemi e possano, quindi, analizzare in dettaglio le tracce e le mappe dei servizi con ServiceLens. 
+  Abilita l'integrazione X-Ray per gli strumenti di tracciamento di terze parti come [Datadog](https://docs.datadoghq.com/tracing/guide/serverless_enable_aws_xray/), [New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-x-ray-monitoring-integration/)o [Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-service-metrics) se utilizzi strumenti di terze parti per la tua soluzione di tracciamento principale. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL06-BP01 Monitoraggio di tutti i componenti per il carico di lavoro (generazione)](rel_monitor_aws_resources_monitor_resources.md) 
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md) 

 **Documenti correlati:** 
+  [Che cos'è AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+ [ Amazon CloudWatch: monitoraggio delle applicazioni ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)
+  [Effettuare il debug con Amazon CloudWatch Synthetics e AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/) 
+  [The Amazon Builders' Library: Dotazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+ [ Integrazione AWS X-Ray con altri servizi AWS](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)
+ [AWS Distro per OpenTelemetry e AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)
+ [ Amazon CloudWatch: utilizzo del monitoraggio sintetico ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [ Amazon CloudWatch: utilizzo di CloudWatch RUM ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [ Installare i canary Amazon CloudWatch Synthetics e gli allarmi Amazon CloudWatch ](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/set-up-amazon-cloudwatch-synthetics-canary-and-amazon-cloudwatch-alarm.html)
+ [ Oltre la disponibilità: comprendere e migliorare la resilienza dei sistemi distribuiti su AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)

 **Esempi correlati:** 
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US)

 **Video correlati:** 
+ [AWS re:Invent 2022 - How to monitor applications across multiple accounts (Come monitorare le applicazioni su più account) ](https://www.youtube.com/watch?v=kFGOkywu-rw)
+ [ Come monitorare le tue applicazioni AWS](https://www.youtube.com/watch?v=UxWU9mrSbmA)

 **Strumenti correlati:** 
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/pm/cloudwatch/)
+ [ Amazon Route 53 ](https://aws.amazon.com/route53/)

# REL 7. Come si progetta il carico di lavoro per adattarsi ai cambiamenti della domanda?
<a name="rel-07"></a>

Un carico di lavoro scalabile fornisce elasticità per aggiungere o rimuovere risorse automaticamente, in modo che vi sia una stretta corrispondenza con la domanda attuale in un dato momento.

**Topics**
+ [REL07-BP01 Utilizzo dell'automazione per l'acquisizione o il dimensionamento delle risorse](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 Ottenimento di risorse quando viene rilevata la compromissione di un carico di lavoro](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 Ottenimento di risorse dopo aver rilevato che sono necessarie più risorse per un carico di lavoro](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 Esecuzione di un test di carico sul carico di lavoro](rel_adapt_to_changes_load_tested_adapt.md)

# REL07-BP01 Utilizzo dell'automazione per l'acquisizione o il dimensionamento delle risorse
<a name="rel_adapt_to_changes_autoscale_adapt"></a>

 Quando sostituisci risorse danneggiate o esegui il dimensionamento del carico di lavoro, puoi automatizzare il processo utilizzando servizi AWS gestiti, come Amazon S3 e AWS Auto Scaling. Puoi anche utilizzare strumenti di terze parti e SDK AWS per automatizzare il dimensionamento. 

 I servizi gestiti AWS includono Amazon S3, Amazon CloudFront, AWS Auto Scaling, AWS Lambda, Amazon DynamoDB, AWS Fargate e Amazon Route 53. 

 AWS Auto Scaling consente di rilevare e sostituire le istanze danneggiate. Inoltre, permette di creare piani di dimensionamento per le risorse, tra cui istanze e parchi istanze [Amazon EC2](https://aws.amazon.com/ec2/) , attività [Amazon ECS](https://aws.amazon.com/ecs/) , tabelle e indici [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) e repliche di [Amazon Aurora](https://aws.amazon.com/aurora/) . 

 Durante il dimensionamento di istanze EC2, assicurati di utilizzare più zone di disponibilità (preferibilmente almeno tre) e di aggiungere o rimuovere capacità per mantenere il bilanciamento tra queste zone. Anche le attività ECS o i pod Kubernetes (quando si utilizza Amazon Elastic Kubernetes Service) devono essere distribuiti su più zone di disponibilità. 

 Quando utilizzi AWS Lambda, le istanze subiscono un dimensionamento automatico. Ogni volta che viene ricevuta una notifica di evento per la funzione, AWS Lambda individua rapidamente la capacità libera all'interno del parco istanze di calcolo ed esegue il codice fino alla simultaneità allocata. Devi assicurarti che la simultaneità necessaria sia configurata sulla Lambda specifica e nelle tue Service Quotas. 

 Amazon S3 ricalibra automaticamente le risorse per gestire elevati tassi di richiesta. Ad esempio, l'applicazione può ottenere almeno 3.500 richieste PUT/COPY/POST/DELETE o 5.500 richieste GET /HEAD al secondo per prefisso in un bucket. Non ci sono limiti al numero di prefissi in un bucket. Puoi aumentare le prestazioni di lettura o scrittura parallelizzando le letture. Ad esempio, se crei 10 prefissi in un bucket Amazon S3 per parallelizzare le letture, potresti dimensionare le prestazioni di lettura a 55.000 richieste al secondo. 

 Configura e utilizza Amazon CloudFront o una rete di distribuzione di contenuti (CDN) attendibile. Una CDN può fornire tempi di risposta più rapidi agli utenti finali e può servire le richieste di contenuti dalla cache, riducendo così la necessità di dimensionare il carico di lavoro. 

 **Anti-pattern comuni:** 
+  Implementare gruppi Auto Scaling per la correzione automatica, ma senza elasticità. 
+  Utilizzare l'auto scaling per rispondere a grandi aumenti di traffico. 
+  Distribuire applicazioni altamente stateful, eliminando l'opzione di elasticità. 

 **Vantaggi dell'adozione di questa best practice:** L'automazione elimina il potenziale di errori manuali nella distribuzione e nella disattivazione delle risorse. L'automazione elimina il rischio di superamento dei costi e di rifiuto del servizio a causa della risposta lenta alle esigenze di distribuzione o disattivazione. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Configura e utilizza AWS Auto Scaling. In questo modo è possibile monitorare le applicazioni e regolare automaticamente la capacità per mantenere prestazioni stabili e prevedibili al minor costo possibile. Grazie ad AWS Auto Scaling, puoi configurare il dimensionamento delle applicazioni per più risorse in vari servizi. 
  +  [Che cos'è AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) 
    +  Configura il dimensionamento automatico su serie di istanze Spot e istanze Amazon EC2, attività Amazon ECS, indici e tabelle Amazon DynamoDB, repliche Amazon Aurora e applicazioni Marketplace AWS, come applicabile. 
      +  [Gestione automatica della capacità di throughput con DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
        +  Utilizza le operazioni delle API di servizi per specificare gli avvisi, le policy di ridimensionamento e i tempi di riscaldamento e raffreddamento. 
+  Utilizza Elastic Load Balancing. I sistemi di bilanciamento del carico possono distribuire il carico in base al percorso o alla connettività di rete. 
  +  [Che cos'è Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
    +  Application Load Balancers può distribuire il carico per percorso. 
      +  [What is an Application Load Balancer? (Che cos'è un Application Load Balancer?)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
        +  Configura un Application Load Balancer per distribuire il traffico su diversi carichi di lavoro in base a un percorso nello stesso nome di dominio. 
        +  Gli Application Load Balancers possono essere utilizzati per distribuire i carichi in modo da gestire la domanda attraverso l'integrazione con AWS Auto Scaling. 
          +  [Uso di un sistema di bilanciamento del carico con un gruppo Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 
    +  I Network Load Balancer possono distribuire il carico in base alla connessione. 
      +  [Che cos'è un Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
        +  Configura un Network Load Balancer per distribuire il traffico su diversi carichi di lavoro tramite TCP o per disporre di un set costante di indirizzi IP per il carico di lavoro. 
        +  I Network Load Balancer possono essere utilizzati per distribuire i carichi in modo da gestire la domanda attraverso l'integrazione con AWS Auto Scaling. 
+  Uso di un provider DNS altamente disponibile I nomi DNS consentono agli utenti di accedere ai carichi di lavoro utilizzando nomi anziché indirizzi IP e distribuire queste informazioni in un ambito definito, solitamente a livello globale per gli utenti del carico di lavoro. 
  +  Utilizza Amazon Route 53 o un provider DNS affidabile. 
    +  [Che cos'è Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
  +  Utilizza Route 53 per gestire le distribuzioni CloudFront e i load balancer. 
    +  Individua i domini e i sottodomini da gestire. 
    +  Crea set di record appropriati utilizzando record ALIAS o CNAME. 
      +  [Uso dei record](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) 
+  Utilizza la rete globale AWS per ottimizzare il percorso dagli utenti alle applicazioni. AWS Global Accelerator monitora costantemente l'integrità degli endpoint delle applicazioni e reindirizza il traffico verso endpoint integri in meno di 30 secondi. 
  +  AWS Global Accelerator è un servizio che migliora la disponibilità e le prestazioni delle applicazioni con utenti locali o globali, fornendo indirizzi IP statici che fungono da punto di ingresso fisso agli endpoint delle applicazioni in una o più regioni Regioni AWS, ad esempio Application Load Balancers, Network Load Balancer o istanze Amazon EC2. 
    +  [Che cos'è AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  Configura e utilizza Amazon CloudFront o una rete di distribuzione di contenuti (CDN) attendibile. Una rete di distribuzione di contenuti (CDN) può fornire tempi di risposta più rapidi agli utenti finali e soddisfare richieste di contenuti che possono causare un dimensionamento non necessario dei carichi di lavoro. 
  +  [Che cos'è Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 
    +  Configura le distribuzioni di Amazon CloudFront per i carichi di lavoro oppure utilizza una CDN di terze parti. 
      +  Puoi limitare l'accesso ai tuoi carichi di lavoro in modo che siano accessibili solo da CloudFront utilizzando gli intervalli di indirizzi IP per CloudFront nelle policy di accesso o nei gruppi di sicurezza degli endpoint. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner per la creazione di soluzioni di elaborazione automatizzate](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27) 
+  [AWS Auto Scaling: come funzionano i piani di dimensionamento](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [Marketplace AWS: prodotti che possono essere utilizzati con Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [Gestione automatica della capacità di throughput con DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [Uso di un sistema di bilanciamento del carico con un gruppo Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 
+  [Che cos'è AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [Che cos'è Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
+  [Che cos'è AWS Auto Scaling?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) 
+  [Che cos'è Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected) 
+  [Che cos'è Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
+  [Che cos'è Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
+  [Che cos'è un Network Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
+  [What is an Application Load Balancer? (Che cos'è un Application Load Balancer?)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
+  [Uso dei record](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) 

# REL07-BP02 Ottenimento di risorse quando viene rilevata la compromissione di un carico di lavoro
<a name="rel_adapt_to_changes_reactive_adapt_auto"></a>

 All'occorrenza, ridimensiona le risorse in modo reattivo se la disponibilità è influenzata per ripristinare la disponibilità del carico di lavoro. 

 Devi prima configurare i controlli dello stato e i criteri su questi controlli per indicare quando la disponibilità è influenzata dalla mancanza di risorse. Quindi invita il personale appropriato a dimensionare manualmente la risorsa o attivare l'automazione per dimensionarla automaticamente. 

 Il dimensionamento può essere regolato manualmente in base al carico di lavoro, ad esempio modificando il numero di istanze EC2 in un gruppo Auto Scaling o modificando la velocità di trasmissione effettiva di una tabella DynamoDB tramite la Console di gestione AWS o la AWS CLI. Tuttavia, l'automazione deve essere utilizzata ogni volta che è possibile (consulta **Utilizzo dell'automazione per l'acquisizione o il dimensionamento delle risorse**). 

 **Risultato desiderato:** le attività di dimensionamento (automatico o manuale) vengono avviate per ripristinare la disponibilità al rilevamento di un guasto o di un'esperienza degradata del cliente. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Implementa l'osservabilità e il monitoraggio su tutti i componenti del carico di lavoro, per monitorare l'esperienza del cliente e rilevare i guasti. Definisci le procedure (manuali o automatiche) che dimensionano le risorse richieste. Per ulteriori informazioni, consulta [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html). 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Definisci le procedure (manuali o automatiche) che dimensionano le risorse richieste. 
  +  Le procedure di dimensionamento dipendono da come sono progettati i diversi componenti del carico di lavoro. 
  +  Le procedure di dimensionamento variano anche a seconda della tecnologia sottostante utilizzata. 
    +  I componenti che utilizzano AWS Auto Scaling possono impiegare piani di dimensionamento per configurare una serie di istruzioni per dimensionare le risorse. Se utilizzi AWS CloudFormation o aggiungi tag alle risorse AWS, puoi impostare piani di dimensionamento per diversi set di risorse, per ogni applicazione. Auto Scaling fornisce raccomandazioni per strategie di dimensionamento personalizzate per ogni risorsa. Dopo aver creato il piano, Auto Scaling combina i metodi di dimensionamento dinamico e predittivo per supportare la tua strategia di dimensionamento. Per maggiori dettagli, consulta [Come funzionano i piani di dimensionamento](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html). 
    +  Amazon EC2 Auto Scaling garantisce che sia disponibile il numero corretto di istanze Amazon EC2 per gestire il carico dell'applicazione. È possibile creare raccolte di istanze EC2, denominate gruppi Auto Scaling. Puoi specificare il numero minimo e massimo di istanze in ogni gruppo Auto Scaling; Amazon EC2 Auto Scaling garantisce che il gruppo non superi mai questi limiti. Per maggiori dettagli, vedi [What is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
    +  Il dimensionamento automatico Amazon DynamoDB utilizza il servizio Application Auto Scaling per regolare dinamicamente la capacità effettiva di trasmissione allocata per tuo conto, in risposta ai modelli di traffico effettivi. Ciò consente a una tabella o a un indice secondario globale di aumentare la capacità di lettura e scrittura assegnata per gestire aumenti di traffico improvvisi, senza limitazione della larghezza di banda della rete. Per maggiori dettagli, consulta [Gestione automatica della capacità effettiva di trasmissione con il dimensionamento automatico di DynamoDB.](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [REL07-BP01 Utilizzo dell'automazione per l'acquisizione o il dimensionamento delle risorse](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_autoscale_adapt.html)
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_monitoring_health.html) 

 **Documenti correlati:** 
+  [AWS Auto Scaling: Come funzionano i piani di dimensionamento](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [Gestione automatica della capacità effettiva di trasmissione con il dimensionamento automatico di DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [What is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 

# REL07-BP03 Ottenimento di risorse dopo aver rilevato che sono necessarie più risorse per un carico di lavoro
<a name="rel_adapt_to_changes_proactive_adapt_auto"></a>

 Dimensiona le risorse in modo proattivo per soddisfare la domanda ed evitare l'impatto sulla disponibilità. 

 Molti servizi AWS dimensionano automaticamente le risorse per soddisfare la domanda. Se si utilizzano istanze Amazon EC2 o cluster Amazon ECS, puoi configurare la scalabilità automatica di tali istanze in base ai parametri di utilizzo corrispondenti alla richiesta del carico di lavoro. Per Amazon EC2, è possibile impiegare l'utilizzo medio della CPU, il conteggio delle richieste del sistema di bilanciamento del carico o la larghezza di banda di rete per aumentare (o ridurre) le istanze EC2. Per Amazon ECS, è possibile impiegare l'utilizzo medio della CPU, il conteggio delle richieste del load balancer e l'utilizzo della memoria per aumentare orizzontalmente (o ridurre orizzontalmente) le attività ECS. Utilizzando il dimensionamento automatico di destinazione su AWS, l'autoscaler si comporta come un termostato domestico, aggiungendo o rimuovendo risorse per mantenere il valore di destinazione (ad esempio, il 70% di utilizzo della CPU) specificato. 

 AWS Auto Scaling può anche eseguire l' [Auto Scaling predittivo](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/), che utilizza il machine learning per analizzare il carico di lavoro cronologico di ciascuna risorsa e prevede regolarmente il carico futuro per i due giorni successivi. 

 La legge di Little aiuta a calcolare il numero di istanze di calcolo (istanze EC2, funzioni Lambda simultanee, ecc.) necessarie. 

 *L* = *λW* 

 L = numero di istanze (o simultaneità media nel sistema) 

 λ = velocità media alla quale arrivano le richieste (richieste/sec) 

 W = tempo medio trascorso da ogni richiesta nel sistema (sec) 

 Ad esempio, a 100 rps, se ogni richiesta impiega 0,5 secondi per l'elaborazione, avrai bisogno di 50 istanze per tenere il passo con la domanda. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Ottieni risorse dopo aver rilevato che sono necessarie più risorse per un carico di lavoro Dimensiona le risorse in modo proattivo per soddisfare la domanda ed evitare l'impatto sulla disponibilità. 
  +  Valuta quante risorse di calcolo sono necessarie (simultaneità di calcolo) per gestire un determinato tasso di richiesta 
    +  [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html) 
  +  Quando disponi di un modello cronologico per l'utilizzo, imposta il dimensionamento programmato per il dimensionamento automatico Amazon EC2. 
    +  [Dimensionamento programmato per Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
  +  Utilizza il dimensionamento predittivo di AWS. 
    +  [Dimensionamento predittivo per EC2, alimentato dal machine learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Auto Scaling: come funzionano i piani di dimensionamento](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [Marketplace AWS: prodotti che possono essere utilizzati con Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [Gestione automatica della capacità di throughput con DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [Dimensionamento predittivo per EC2, alimentato dal machine learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 
+  [Dimensionamento programmato per Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
+  [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html) 
+  [Che cos'è Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 

# REL07-BP04 Esecuzione di un test di carico sul carico di lavoro
<a name="rel_adapt_to_changes_load_tested_adapt"></a>

 Adotta un metodo di test del carico per misurare se l'attività di dimensionamento soddisfa i requisiti del carico di lavoro. 

 È importante eseguire test di carico prolungati. I test di carico devono rilevare il punto di rottura e testare le prestazioni del carico di lavoro. AWS consente di creare facilmente ambienti di test temporanei che riproducono la scala del carico di lavoro di produzione. Nel cloud, puoi creare un ambiente di test su scala produttiva on demand, completare i test e disattivare le risorse. Poiché paghi per l'ambiente di test solo quando è in esecuzione, puoi simulare un ambiente live a un costo notevolmente inferiore rispetti ai test in locale. 

 I test di carico in produzione dovrebbero anche essere considerati come parte dei game day in cui il sistema di produzione viene messo alla prova, durante le ore di utilizzo inferiore del cliente, con tutto il personale a disposizione per interpretare i risultati e risolvere eventuali problemi che si presentano. 

 **Anti-pattern comuni:** 
+  Eseguire test di carico su distribuzioni che non presentano la stessa configurazione della tua produzione. 
+  Eseguire test di carico solo su singole parti del carico di lavoro e non sulla sua interezza. 
+  Eseguire test di carico con un sottoinsieme di richieste e non con un set rappresentativo delle richieste effettive. 
+  Eseguire test di carico su un fattore di sicurezza di poco superiore al carico previsto. 

 **Vantaggi dell'adozione di questa best practice:** Saprai quali sono i componenti dell'architettura che non funzionano sotto carico e potrai identificare per tempo i parametri che indicano l'avvicinamento al carico in questione, così da affrontare il problema e prevenire l'impatto dell'esito negativo. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Esegui test di carico per identificare quali aspetti del carico di lavoro indicano la necessità di aggiungere o rimuovere capacità. Il test di carico deve avere un traffico rappresentativo simile a quello che ricevi nella produzione. Aumenta il carico mentre osservi i parametri implementati per stabilire quale di questi indica quando è necessario aggiungere o rimuovere risorse. 
  +  [Distributed Load Testing on AWS (Test di carico distribuito su AWS): simula migliaia di utenti connessi](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
    +  Identifica la combinazione di richieste. Potresti avere diverse combinazioni di richieste, quindi dovresti esaminare vari intervalli di tempo per identificare la combinazione di traffico. 
    +  Implementa un driver di caricamento. Puoi utilizzare codice personalizzato, software open source o software commerciale per implementare un driver di carico. 
    +  Esegui un test di carico iniziale con una capacità ridotta. Puoi vedere alcuni effetti immediati applicando il carico su una capacità inferiore, possibilmente pari a un'istanza o a un container. 
    +  Esegui un test di carico con una capacità maggiore. Gli effetti saranno diversi su un carico distribuito, quindi è necessario eseguire il test in condizioni quanto più simili possibili all'ambiente del prodotto. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Distributed Load Testing on AWS (Test di carico distribuito su AWS): simula migliaia di utenti connessi](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 

# REL 8. In che modo implementare le modifiche?
<a name="rel-08"></a>

Per implementare nuove funzionalità e verificare che i carichi di lavoro e l'ambiente operativo eseguano software noti e che sia possibile applicare patch o sostituirli in modo prevedibile, sono necessarie modifiche controllate. Se invece non sono controllate, risulta difficile prevederne l'effetto o risolvere eventuali problemi che causano. 

**Topics**
+ [REL08-BP01 Utilizzo di runbook per attività standard come l'implementazione](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 Esecuzione di test funzionali come parte integrante dell'implementazione](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 Esecuzione di test di resilienza come parte integrante dell'implementazione](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 Esecuzione dell'implementazione utilizzando un'infrastruttura immutabile](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 Implementazione delle modifiche tramite automazione](rel_tracking_change_management_automated_changemgmt.md)

# REL08-BP01 Utilizzo di runbook per attività standard come l'implementazione
<a name="rel_tracking_change_management_planned_changemgmt"></a>

 I runbook sono le procedure predefinite per ottenere risultati specifici. Utilizza i runbook per eseguire attività standard, o manualmente o automaticamente. Alcuni esempi includono l'implementazione di un carico di lavoro, l'applicazione di patch a un carico di lavoro o la realizzazione di modifiche DNS. 

 Ad esempio, metti in atto processi per [garantire la sicurezza del rollback durante le distribuzioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). Garantire la possibilità di eseguire il rollback di una distribuzione senza interruzioni per i clienti è fondamentale per rendere un servizio affidabile. 

 Per le procedure di runbook, inizia da un processo manuale valido ed efficace, implementalo nel codice e attivalo per l'esecuzione automatica, se necessario. 

 Anche per carichi di lavoro sofisticati e altamente automatizzati, i runbook rimangono utili per [eseguire game day](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) o soddisfare rigorosi requisiti di reportistica e audit. 

 Tieni presente che i playbook vengono utilizzati in risposta a incidenti specifici e i runbook vengono utilizzati per ottenere risultati specifici. Spesso, i runbook sono per attività di routine, mentre i playbook vengono utilizzati per rispondere a eventi non di routine. 

 **Anti-pattern comuni:** 
+  Eseguire modifiche impreviste alla configurazione nella produzione. 
+  Ignorare le fasi del piano per velocizzare l'implementazione, compromettendone la riuscita. 
+  Apportare modifiche senza testarne l'annullamento. 

 **Vantaggi dell'adozione di questa best practice:** Una pianificazione efficace aumenta la capacità di eseguire correttamente la modifica, perché sei a conoscenza di tutti i sistemi interessati. Convalidare la modifica negli ambienti di test aumenta la sicurezza. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Abilita risposte coerenti e tempestive agli eventi noti documentando le procedure nei runbook. 
  +  [Framework AWS Well-Architected – Concetti – Runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html) 
+  Uso del principio di infrastruttura come codice per definire l'infrastruttura Utilizzando AWS CloudFormation o una terza parte affidabile per definire la tua infrastruttura, puoi utilizzare un software per il controllo delle versioni per gestire le versioni e tenere traccia delle modifiche. 
  +  Utilizza AWS CloudFormation o un provider di terze parti affidabile per definire l'infrastruttura. 
    +  [Che cos'è AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
  +  Crea modelli unici e disaccoppiati, utilizzando solidi principi di progettazione del software. 
    +  Stabilisci le autorizzazioni, i modelli e le parti responsabili dell'implementazione 
      + [ Controllo degli accessi con AWS Identity and Access Management](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
    +  Utilizza un controllo sorgente come AWS CodeCommit o uno strumento di terze parti affidabili per il controllo delle versioni. 
      +  [Che cos'è AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner per la creazione di soluzioni di distribuzione automatizzate](https://aws.amazon.com/partners/find/results/?keyword=devops) 
+  [Marketplace AWS: prodotti per l'automazione delle distribuzioni](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) 
+  [Framework AWS Well-Architected – Concetti – Runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html) 
+  [Che cos'è AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
+  [Che cos'è AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

   **Esempi correlati:** 
+  [Automating operations with Playbooks and Runbooks (Automazione delle operazioni con Playbook e Runbook)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

# REL08-BP02 Esecuzione di test funzionali come parte integrante dell'implementazione
<a name="rel_tracking_change_management_functional_testing"></a>

 I test funzionali vengono eseguiti come parte integrante della distribuzione automatizzata. Se non vengono soddisfatti i criteri di esito positivo, la pipeline viene arrestata o ripresa dall'inizio. 

 Questi test vengono eseguiti in un ambiente di pre-produzione, gestito per fasi prima della produzione nella pipeline. Idealmente, questa operazione viene eseguita come parte di una pipeline di distribuzione. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Esegui test funzionali come parte integrante dell'implementazione. I test funzionali vengono eseguiti come parte integrante della distribuzione automatizzata. Se non vengono soddisfatti i criteri di esito positivo, la pipeline viene arrestata o ripresa dall'inizio. 
  +  Richiama AWS CodeBuild durante l'azione di test delle pipeline di rilascio di software modellate in AWS CodePipeline. Questa funzionalità consente di eseguire facilmente un'ampia gamma di test sul codice, tra cui test delle unità, analisi del codice statico e test di integrazione. 
    +  [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) 
  +  Utilizza le soluzioni Marketplace AWS per eseguire test automatizzati come parte integrante della tua pipeline di distribuzione di software. 
    +  [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) 
+  [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 
+  [Che cos'è AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 

# REL08-BP03 Esecuzione di test di resilienza come parte integrante dell'implementazione
<a name="rel_tracking_change_management_resiliency_testing"></a>

 I test di resilienza (eseguiti utilizzando i [Principles of Chaos Engineering](https://principlesofchaos.org/)) vengono svolti nell'ambito della pipeline di implementazione automatizzata in un ambiente di pre-produzione. 

 Questi test vengono gestiti per fasi ed eseguiti nella pipeline di pre-produzione. Devono anche essere eseguiti in produzione, ma come parte di [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays). 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Esegui test di resilienza come parte integrante della distribuzione Utilizza l'ingegneria del caos, la disciplina che consiste nello sperimentare su un carico di lavoro per aumentare la fiducia nella capacità del carico di lavoro di resistere a condizioni turbolente in produzione. 
  +  I test di resilienza inseriscono errori o causano un degrado delle risorse per valutare se il carico di lavoro risponde con la resilienza progettata 
    +  [Corso Well-Architected: Level 300: Testing for Resiliency of EC2 RDS and S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html) 
  +  Questi test possono essere eseguiti regolarmente in ambienti di pre-produzione nelle pipeline di distribuzione automatizzate. 
  +  È opportuno eseguirli anche in produzione, nell'ambito delle giornate di gioco pianificate. 
  +  A partire dai principi di ingegneristica del caos, avanza ipotesi sulle prestazioni del carico di lavoro in caso di vari problemi, quindi mettile alla prova utilizzando i test di resilienza. 
    +  [Principles of Chaos Engineering](https://principlesofchaos.org/) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Principles of Chaos Engineering](https://principlesofchaos.org/) 
+  [Che cos'è AWS Fault Injection Simulator?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 

 **Esempi correlati:** 
+  [Corso Well-Architected: Level 300: Testing for Resiliency of EC2 RDS and S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html) 

# REL08-BP04 Esecuzione dell'implementazione utilizzando un'infrastruttura immutabile
<a name="rel_tracking_change_management_immutable_infrastructure"></a>

 L'infrastruttura immutabile è un modello che richiede che non vengano applicati aggiornamenti, patch di sicurezza o modifiche di configurazione sui carichi di lavoro di produzione. Quando è necessaria una modifica, l'architettura viene costruita su una nuova infrastruttura e distribuita alla produzione. 

 Segui una strategia di implementazione dell'infrastruttura immutabile per aumentare l'affidabilità, la coerenza e la riproducibilità nelle implementazioni dei carichi di lavoro. 

 **Risultato desiderato:** con un'infrastruttura immutabile, non sono consentite [modifiche locali (in-place)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/in-place-deployments.html) per l'esecuzione delle risorse dell'infrastruttura all'interno di un carico di lavoro. Invece, quando è necessaria una modifica, un nuovo set di risorse infrastrutturali aggiornate contenente tutte le modifiche necessarie viene implementato in parallelo alle risorse esistenti. Questa implementazione viene convalidata automaticamente e, in caso di successo, il traffico viene gradualmente trasferito al nuovo set di risorse. 

 Questa strategia di implementazione si applica, ad esempio, agli aggiornamenti software, alle patch di sicurezza, alle modifiche apportate all'infrastruttura, agli aggiornamenti della configurazione e agli aggiornamenti delle applicazioni. 

 **Anti-pattern comuni:** 
+  Implementazione locale (in-place) di modifiche alle risorse dell'infrastruttura in esecuzione. 

 **Vantaggi dell'adozione di questa best practice:** 
+  **Maggiore coerenza tra ambienti:** poiché non vi sono differenze nelle risorse dell'infrastruttura tra ambienti, la coerenza aumenta e i test risultano semplificati. 
+  **Riduzione delle deviazioni di configurazione:** sostituendo le risorse dell'infrastruttura con una configurazione nota e controllata dalla versione, l'infrastruttura viene reimpostata a uno stato noto, testato e attendibile, evitando in questo modo deviazioni di configurazione. 
+  **Implementazioni atomiche affidabili:** le implementazioni vengono completate correttamente o, in caso contrario, non generano alcun cambiamento, aumentando così la coerenza e l'affidabilità nel processo di implementazione. 
+  **Implementazioni semplificate:** le implementazioni sono semplificate perché non devono supportare gli aggiornamenti. Gli aggiornamenti sono solo nuove distribuzioni. 
+  **Implementazioni più sicure con processi di rollback e ripristino rapidi:** le implementazioni sono più sicure perché la versione funzionante precedente non viene modificata. Puoi eseguire il rollback se vengono rilevati errori. 
+  **Potenziamento del profilo di sicurezza:** non consentendo modifiche all'infrastruttura, i meccanismi di accesso remoto (come SSH) possono essere disabilitati. Questo riduce il vettore di attacco, migliorando il profilo di sicurezza dell'organizzazione. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 **Automazione** 

 Quando si definisce una strategia di implementazione immutabile dell'infrastruttura, si consiglia di utilizzare l'[automazione](https://aws.amazon.com/iam/) il più possibile per aumentare la riproducibilità e ridurre al minimo i potenziali errori umani. Per maggiori dettagli, consulta [REL08-BP05 Implementazione delle modifiche tramite automazione](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html) e [Automazione di implementazioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/). 

 Con il modello [Infrastructure as code (IaC)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html), le fasi di provisioning, orchestrazione e implementazione dell'infrastruttura sono definite in modo programmatico, descrittivo e dichiarativo e archiviate in un sistema di controllo del codice sorgente. L'utilizzo del modello Infrastructure as code (IaC) semplifica l'automazione dell'implementazione dell'infrastruttura e aiuta a raggiungere l'immutabilità dell'infrastruttura. 

 **Schemi di implementazione** 

 Quando è richiesta una modifica del carico di lavoro, la strategia di implementazione immutabile dell'infrastruttura impone l'implementazione di un nuovo set di risorse dell'infrastruttura, comprese tutte le modifiche necessarie. È importante che questo nuovo set di risorse si basi su un modello di implementazione che riduca al minimo l'impatto sugli utenti. Esistono due strategie principali per questa implementazione: 

 [https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html): pratica di indirizzare un piccolo numero di clienti alla nuova versione, in genere in esecuzione su una singola istanza di servizio (la release Canary). Quindi analizzerai in modo approfondito le modifiche di comportamento o gli errori generati. Puoi rimuovere il traffico dalla release Canary in caso di problemi critici e reindirizzare gli utenti alla versione precedente. Se l'implementazione viene completata correttamente, puoi continuare l'implementazione alla velocità desiderata, monitorando le modifiche alla ricerca di errori, fino al completamento dell'implementazione. AWS CodeDeploy può essere configurato con una [configurazione di implementazione](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) che abilita un'implementazione Canary. 

 [https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html): simile all'implementazione Canary, tranne per il fatto che viene implementato in parallelo un intero parco istanze dell'applicazione. Puoi alternare le distribuzioni tra i due stack (blue e green). Ancora una volta, puoi inviare il traffico alla nuova versione e tornare alla versione precedente in caso di problemi con la distribuzione. Generalmente, tutto il traffico viene trasferito contemporaneamente, tuttavia puoi anche utilizzare frazioni del traffico verso ciascuna versione per comporre l'adozione della nuova versione utilizzando le funzionalità di indirizzamento DNS ponderato di Amazon Route 53. AWS CodeDeploy e [AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2020-05-18-ts-deploy.html) possono essere configurati con una configurazione di distribuzione che abilita un'implementazione blu/verde. 

![\[Diagram showing blue/green deployment with AWS Elastic Beanstalk and Amazon Route 53\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/blue-green-deployment.png)


 **Rilevamento della deviazione** 

 La *deviazione* è definita come qualsiasi modifica che fa sì che una risorsa dell'infrastruttura abbia uno stato o una configurazione diversi dal previsto. Qualsiasi tipo di modifica non gestita della configurazione è contraria al concetto di infrastruttura immutabile e tale modifica dovrebbe essere individuata e corretta per implementare con successo l'infrastruttura immutabile. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Non autorizzare la modifica locale (in-place) delle risorse dell'infrastruttura in esecuzione. 
  +  Puoi usare [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) per specificare chi o cosa può accedere a servizi e risorse in AWS, gestire centralmente le autorizzazioni a elevata granularità e analizzare l'accesso per perfezionare le autorizzazioni in AWS. 
+  Automatizza l'implementazione delle risorse dell'infrastruttura per aumentare la riproducibilità e ridurre al minimo i potenziali errori umani. 
  +  Come descritto nel whitepaper [Introduzione a DevOps in AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html), l'automazione è un elemento fondamentale per i servizi AWS ed è supportata internamente in tutti i servizi, le funzionalità e le offerte. 
  +  La *[preparazione preliminare](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/prebaking-vs.-bootstrapping-amis.html)* delle Amazon Machine Image (AMI) può velocizzare i tempi di avvio. [EC2 Image Builder](https://aws.amazon.com/image-builder/) è un servizio AWS completamente gestito che consente di automatizzare la creazione, la manutenzione, la convalida, la condivisione e l'implementazione di AMI personalizzate, sicure e aggiornate per Linux o Windows. 
  +  Alcuni dei servizi che supportano l'automazione sono: 
    +  [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) è un servizio per implementare e dimensionare rapidamente applicazioni Web sviluppate con Java, .NET, PHP, Node.js, Python, Ruby, Go e Docker su server tradizionali come Apache, NGINX, Passenger e IIS. 
    +  [AWS Proton](https://aws.amazon.com/proton/) aiuta i team della piattaforma a connettere e coordinare tutti i diversi strumenti di cui i team di sviluppo hanno bisogno per il provisioning dell'infrastruttura, le implementazioni del codice, il monitoraggio e gli aggiornamenti. AWS Proton abilita il provisioning e l'implementazione basati sul modello IaC di applicazioni serverless e basate su container. 
  +  L'utilizzo del modello Infrastructure as code (IaC) semplifica l'automazione dell'implementazione dell'infrastruttura e aiuta a raggiungere l'immutabilità dell'infrastruttura. AWS fornisce servizi che consentono la creazione, l'implementazione e la manutenzione dell'infrastruttura in modo programmatico, descrittivo e dichiarativo. 
    +  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) aiuta gli sviluppatori a creare risorse AWS in modo ordinato e prevedibile. Le risorse sono scritte in file di testo utilizzando il formato JSON o YAML. I modelli richiedono una sintassi e una struttura specifiche che dipendono dai tipi di risorse create e gestite. Crei le tue risorse in formato JSON o YAML con qualsiasi editor di codice, ad esempio AWS Cloud9, e le inserisci in un sistema di controllo delle versioni. A questo punto, CloudFormation crea i servizi specificati in modo sicuro e ripetibile. 
    +  [AWS Serverless Application Model (AWS SAM)](https://aws.amazon.com/serverless/sam/) è un framework open source che puoi utilizzare per creare applicazioni serverless in AWS. AWS SAM si integra con altri servizi AWS ed è un'estensione di CloudFormation. 
    +  [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) è un framework di sviluppo di software open source per modellare ed effettuare il provisioning delle risorse delle applicazioni cloud utilizzando linguaggi di programmazione noti. È possibile utilizzare AWS CDK per modellare l'infrastruttura dell'applicazione mediante TypeScript, Python, Java e.NET. AWS CDK utilizza CloudFormation in background per fornire risorse in modo sicuro e ripetibile. 
    +  [AWS Cloud Control API](https://aws.amazon.com/cloudcontrolapi/) introduce un set comune di API Create, Read, Update, Delete and List (CRUDL) per aiutare gli sviluppatori a gestire la propria infrastruttura cloud in modo semplice e coerente. Le API Cloud Control API comuni consentono agli sviluppatori di gestire in modo uniforme il ciclo di vita di AWS e i servizi di terze parti. 
+  Applica modelli di implementazione che riducano al minimo l'impatto sugli utenti. 
  +  Implementazioni canary: 
    + [Configura un'implementazione di una release canary API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
    + [Crea una pipeline con implementazioni canary per Amazon ECS mediante AWS App Mesh](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/)
  +  Implementazioni blu/verdi: il whitepaper relativo alle [implementazioni blu/verdi in AWS](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html)descrive [esempi di tecniche](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/implementation-techniques.html) per applicare le strategie di implementazione blu/verde. 
+  Rileva le deviazioni a livello di configurazione o stato. Per maggiori dettagli, consulta [Rilevamento di modifiche non gestite della configurazione di stack e risorse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [REL08-BP05 Implementazione delle modifiche tramite automazione](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_automated_changemgmt.html)

 **Documenti correlati:** 
+ [Automazione di implementazioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Utilizzo di AWS CloudFormation per creare un'infrastruttura immutabile presso Nubank](https://aws.amazon.com/blogs/mt/leveraging-immutable-infrastructure-nubank/)
+ [Scrittura dell’infrastruttura come codice](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+ [Implementazione di un allarme per rilevare automaticamente la deviazione negli stack AWS CloudFormation](https://docs.aws.amazon.com/blogs/mt/implementing-an-alarm-to-automatically-detect-drift-in-aws-cloudformation-stacks/)

 **Video correlati:** 
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability ](https://www.youtube.com/watch?v=jUSYnRztttY)

# REL08-BP05 Implementazione delle modifiche tramite automazione
<a name="rel_tracking_change_management_automated_changemgmt"></a>

 Le distribuzioni e l'applicazione di patch sono automatizzate per eliminare l'impatto negativo. 

 Apportare modifiche ai sistemi produttivi è una delle maggiori aree di rischio per molte organizzazioni. Riteniamo che le distribuzioni siano un problema prioritario da risolvere insieme ai problemi aziendali affrontati dal software. Oggi, ciò significa l'uso dell'automazione ovunque sia pratica nelle operazioni, inclusi test e distribuzione di modifiche, aggiunta o rimozione di capacità e migrazione dei dati. AWS CodePipeline consente di gestire le fasi necessarie per rilasciare il carico di lavoro. Questo include uno stato di distribuzione che utilizza AWS CodeDeploy per automatizzare la distribuzione del codice dell'applicazione su istanze Amazon EC2, istanze in locale, funzioni Lambda serverless o servizi Amazon ECS. 

**Consiglio**  
 Anche se la prassi comune suggerisce di includere le persone nelle procedure operative più difficili, suggeriamo di automatizzare le procedure più difficili proprio per questo motivo. 

 **Anti-pattern comuni:** 
+  Eseguire le modifiche manualmente. 
+  Ignorare le fasi dell'automazione attraverso i flussi di lavoro di emergenza. 
+  Non seguire i piani. 

 **Vantaggi dell'adozione di questa best practice:** L'utilizzo dell'automazione per distribuire tutte le modifiche scongiura il rischio di introdurre errori umani e consente di effettuare test prima di modificare la produzione, così da garantire che i piani siano completi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Automatizzazione della pipeline di distribuzione Le pipeline di distribuzione permettono di richiamare test automatici, rilevare le anomalie e interrompere la pipeline a una determinata fase prima della distribuzione in produzione o eseguire automaticamente il ripristino di una modifica. 
  +  [The Amazon Builders' Library: Garantire la sicurezza del rollback durante le distribuzioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) 
  +  [The Amazon Builders' Library: Più velocità con una consegna continua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/) 
    +  Utilizza AWS CodePipeline (o un prodotto di terze parti affidabile) per definire ed eseguire le tue pipeline. 
      +  Configura la pipeline in modo che inizi quando si effettua il commit di una modifica al repository del codice. 
        +  [Che cos'è AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 
      +  Utilizza Amazon Simple Notification Service (Amazon SNS) e Amazon Simple Email Service (Amazon SES) per inviare notifiche sui problemi nella pipeline o integrarti utilizzando uno strumento di chat per team, ad esempio Amazon Chime. 
        +  [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 
        +  [Che cos'è Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) 
        +  [Che cos'è Amazon Chime?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html) 
        +  [Automatizza i messaggi delle chat con webhook.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner per la creazione di soluzioni di distribuzione automatizzate](https://aws.amazon.com/partners/find/results/?keyword=devops) 
+  [Marketplace AWS: prodotti per l'automazione delle distribuzioni](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps) 
+  [Automatizza i messaggi delle chat con webhook.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html) 
+  [The Amazon Builders' Library: Garantire la sicurezza del rollback durante le distribuzioni](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments) 
+  [The Amazon Builders' Library: Più velocità con una consegna continua](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/) 
+  [Che cos'è AWS CodePipeline?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 
+  [Che cos'è CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 
+  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 
+  [Che cos'è Amazon SES?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html) 
+  [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 

 **Video correlati:** 
+  [AWS Summit 2019: CI/CD su AWS (AWS Summit: CI/CD su AWS)](https://youtu.be/tQcF6SqWCoY) 

# Gestione degli errori
<a name="a-failure-management"></a>

**Topics**
+ [REL 9. In che modo eseguire il backup dei dati?](rel-09.md)
+ [REL 10. Come si utilizza l'isolamento dei guasti per proteggere il carico di lavoro?](rel-10.md)
+ [REL 11. Come si progetta il carico di lavoro affinché resista ai guasti dei componenti?](rel-11.md)
+ [REL 12. Come si testa l'affidabilità?](rel-12.md)
+ [REL 13. Come si pianifica il disaster recovery o ripristino di emergenza?](rel-13.md)

# REL 9. In che modo eseguire il backup dei dati?
<a name="rel-09"></a>

Esegui il backup dei dati, delle applicazioni e della configurazione per soddisfare i tuoi requisiti relativi agli obiettivi di tempo di ripristino (recovery time objective, RTO) e agli obiettivi di punto di ripristino (recovery point objective, RPO).

**Topics**
+ [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 Protezione e crittografia dei backup](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Esecuzione del backup dei dati in automatico](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 Ripristino periodico dei dati per verificare l'integrità e i processi di backup:](rel_backing_up_data_periodic_recovery_testing_data.md)

# REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini
<a name="rel_backing_up_data_identified_backups_data"></a>

Scopri e usa le funzionalità di backup dei servizi per i dati e delle risorse utilizzati dal carico di lavoro. La maggior parte dei servizi offre funzionalità per eseguire il backup dei dati del carico di lavoro. 

 **Risultato desiderato:** capacità di identificare e classificare le origini dati in base alla criticità. Quindi, stabilisci una strategia per il recupero dei dati in base all'RPO. Questa strategia prevede il backup di queste origini dei dati o la possibilità di riprodurre i dati da altre origini. In caso di perdita di dati, la strategia implementata consente il recupero o la riproduzione dei dati entro i termini RPO e RTO definiti. 

 **Fase di maturità del cloud:** di base 

 **Anti-pattern comuni:** 
+  Mancata conoscenza di tutte le origini dei dati per il carico di lavoro e della loro criticità. 
+  Non si eseguono backup delle origini dei dati critiche. 
+  Esecuzione di backup solo di alcune origini dei dati senza utilizzare la criticità come criterio. 
+  Non esiste un RPO definito o la frequenza di backup non può soddisfare l'RPO. 
+  Nessuna valutazione della necessità di un backup o della possibilità di riprodurre i dati da altre origini. 

 **Vantaggi dell'adozione di questa best practice:** l'identificazione dei punti in cui sono necessari backup e l'implementazione di un meccanismo per la creazione di backup, o la riproduzione dei dati da un'origine esterna, migliorano la capacità di ripristinare e recuperare dati durante un'interruzione. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Tutti i data store AWS offrono funzionalità di backup. Servizi come Amazon RDS e Amazon DynamoDB supportano inoltre il backup automatico che consente il ripristino point-in-time (PITR), grazie al quale è possibile ripristinare un backup in qualsiasi momento fino a cinque minuti o meno rispetto all'ora corrente. Molti servizi AWS permettono di copiare backup in un'altra Regione AWS. AWS Backup è uno strumento che permette di centralizzare e automatizzare la protezione dei dati tra vari servizi AWS. [Ripristino di emergenza di elastico di AWS](https://aws.amazon.com/disaster-recovery/) permette di copiare carichi di lavoro server completi e mantenere una protezione continua dei dati on-premise, tra zone di disponibilità o tra regioni con un obiettivo del punto di ripristino (RPO) misurato in secondi. 

 Amazon S3 può essere utilizzato come destinazione di backup per le origini dei dati gestite dal cliente e gestite da AWS. I servizi AWS come Amazon EBS, Amazon RDS e Amazon DynamoDB hanno funzionalità incorporate per creare i backup. È anche possibile utilizzare software di backup di terze parti. 

 È possibile eseguire il backup di dati on-premise nel Cloud AWS usando [Gateway di archiviazione AWS](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) o [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). È possibile usare bucket Amazon S3 per archiviare questi dati in AWS. Amazon S3 offre più livelli di archiviazione, come [Amazon Glacier o Deep Archive Amazon Glacier](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html), per ridurre i costi di archiviazione dei dati. 

 Potresti essere in grado di soddisfare le esigenze di recupero dei dati riproducendo i dati da altre origini. Ad esempio, potresti usare [nodi di replica Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) o [repliche di lettura Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) per riprodurre i dati in caso di perdita del nodo primario. Nei casi in cui origini come questa possono essere usate per soddisfare l'[obiettivo del punto di ripristino (RPO) e l'obiettivo del tempo di ripristino (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html), un backup può non essere necessario. Come esempio aggiuntivo, se usi Amazon EMR, il backup del datastore HDFS può non essere necessario, purché sia possibile [riprodurre i dati in Amazon EMR da Amazon S3](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/). 

 Quando scegli una strategia di backup, devi considerare il tempo necessario per il ripristino dei dati. Il tempo necessario per il ripristino dei dati dipende dal tipo di backup (nel caso di una strategia di backup) o dalla complessità del meccanismo di riproduzione dei dati. Questo tempo deve rientrare nell'RTO per il carico di lavoro. 

 **Passaggi dell'implementazione** 

1.  **Identifica tutte le origini dati per il carico di lavoro**. I dati possono essere archiviati in diverse risorse, come [database](https://aws.amazon.com/products/databases/), [volumi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [file system](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [sistemi di registrazione](https://docs.aws.amazon.com/Amazon/latest/logs/WhatIsLogs.html) e [risorse di archiviazione di oggetti](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Consulta la sezione **Risorse** per trovare i **documenti correlati** su diversi servizi AWS che offrono l'archiviazione di dati e sulle funzionalità offerte da questi servizi. 

1.  **Classifica le origini dati in base alla criticità**. I diversi set di dati avranno diversi livelli di criticità per un carico di lavoro e quindi diversi requisiti di resilienza. Ad esempio, alcuni dati possono essere critici e richiedere un RPO prossimo allo zero, mentre altri dati possono essere meno critici e tollerare un RPO più elevato e una certa perdita di dati. Allo stesso modo, anche i diversi set di dati possono avere requisiti RTO diversi. 

1.  **Usa AWS o servizi di terze parti per creare backup dei dati**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) è un servizio gestito che permette la creazione di backup di origini dati diverse in AWS. [Ripristino di emergenza di elastico di AWS](https://aws.amazon.com/disaster-recovery/) gestisce la replica automatica dei dati in una Regione AWS con tempi inferiori al secondo. La maggior parte dei servizi AWS include anche funzionalità native per la creazione di backup. Marketplace AWS ha molte soluzioni che offrono anche queste funzionalità. Consulta la sezione **Risorse** di seguito per informazioni su come creare backup di dati da diversi servizi AWS. 

1.  **Per i dati non sottoposti a backup, definisci un meccanismo di riproduzione dei dati**. Puoi decidere di non eseguire il backup di dati riproducibili da altre origini per vari motivi. Potrebbe essere più conveniente riprodurre i dati dalle origini, quando necessario, piuttosto che creare un backup, dato che l'archiviazione dei backup può comportare dei costi. Un altro esempio è quello in cui il ripristino da un backup richiede più tempo rispetto alla riproduzione dei dati dalle origini, con conseguente violazione dell'RTO. In queste situazioni, è necessario considerare i compromessi e stabilire un processo ben definito per la riproduzione dei dati da queste origini quando è necessario il ripristino dei dati. Ad esempio, se hai caricato dati da Amazon S3 su un data warehouse (come Amazon Redshift) o su un cluster MapReduce (come Amazon EMR) per compiere analisi, ottieni un esempio pratico di riproduzione dati da oltre origini. Finché i risultati di queste analisi vengono archiviati o sono riproducibili, non subirai una perdita di dati a causa di un guasto nel data warehouse o nel cluster MapReduce. Altri esempi che possono essere riprodotti dalle origini includono le cache (ad esempio Amazon ElastiCache) o le repliche di lettura RDS. 

1.  **Definisci una cadenza per il backup dei dati**. La creazione di backup delle origini dei dati è un processo periodico e la frequenza deve dipendere dall'RPO. 

 **Livello di impegno per il piano di implementazione:** moderato. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 

[REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md) 

[REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md) 

 **Documenti correlati:** 
+  [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [Che cos'è AWS DataSync?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) 
+  [What is Volume Gateway? (Che cos'è il Gateway di volumi?)](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) 
+  [Partner APN: partner per il backup](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [Marketplace AWS: prodotti che possono essere usati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [Snapshot Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html) 
+  [Backup in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html) 
+  [Backup in Amazon FSx per Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html) 
+  [Backup e ripristino di ElastiCache for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html) 
+  [Creazione di shapshot di cluster di database in Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html) 
+  [Creazione di uno snapshot DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) 
+  [Creazione di una regola EventBridge attivata in base a una pianificazione](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) 
+  [Replica tra regioni](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) con Amazon S3 
+  [AWS Backup da EFS a EFS](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/) 
+  [Esportazione di dati di log in Amazon S3](https://docs.aws.amazon.com/Amazon/latest/logs/S3Export.html) 
+  [Gestione del ciclo di vita dell'applicazione](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html) 
+  [Backup e ripristino on demand per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html) 
+  [Ripristino point-in-time (PITR) per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html) 
+  [Uso di snapshot di indici Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html) 
+ [ Che cos'è Ripristino di emergenza di elastico di AWS? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

 **Video correlati:** 
+  [AWS re:Invent 2021: Backup, ripristino di emergenza e protezione da ransomware con AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc) 
+  [Demo su AWS Backup: Backup tra account e tra regioni](https://www.youtube.com/watch?v=dCy7ixko3tE) 
+  [AWS re:Invent 2019: Approfondimento su AWS Backup, con Rackspace (STG341)](https://youtu.be/av8DpL0uFjc) 

 **Esempi correlati:** 
+  [Well-Architected Lab: Implementazione della replica bidirezionale tra regioni per Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) 
+  [Well-Architected Lab: Esecuzione di test del backup e del ripristino di dati](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 
+  [Well-Architected Lab: Backup e ripristino con failback per un carico di lavoro di analisi](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/) 
+  [Well-Architected Lab: Ripristino di emergenza – Backup e ripristino](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/) 

# REL09-BP02 Protezione e crittografia dei backup
<a name="rel_backing_up_data_secured_backups_data"></a>

Controlla e rileva l'accesso ai backup tramite l'autenticazione e l'autorizzazione. Previeni e rileva se l'integrità dei dati dei backup è compromessa utilizzando la crittografia.

 **Anti-pattern comuni:** 
+  Disporre di un accesso identico sia per i backup e l'automazione del ripristino sia per i dati. 
+  Non codificare i backup. 

 **Vantaggi dell'adozione di questa best practice:** la protezione dei backup previene la manomissione dei dati, mentre la crittografia dei dati impedisce l'accesso ai dati se questi vengono accidentalmente esposti. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Controlla e rileva l'accesso ai backup tramite l'autenticazione e l'autorizzazione, ad esempio con AWS Identity and Access Management (IAM). Previeni e rileva se l'integrità dei dati dei backup è compromessa utilizzando la crittografia. 

 Amazon S3 supporta diversi metodi di crittografia dei dati archiviati. Utilizzando la crittografia lato server, Amazon S3 accetta anche dati non crittografati e li crittografa man mano che vengono memorizzati. Utilizzando la crittografia lato client, l'applicazione del carico di lavoro è responsabile della crittografia dei dati prima che vengano inviati a Amazon S3. Entrambi i metodi ti consentono di utilizzare AWS Key Management Service (AWS KMS) per creare ed archiviare la chiave di crittografia dei dati, oppure di utilizzarne una personalizzata (della quale sarai responsabile). Tramite AWS KMS puoi impostare delle policy utilizzando IAM per regolare l'accesso alle chiavi dei dati, oltre che ai dati privi di crittografia. 

 Per Amazon RDS, se hai scelto di crittografare i database, anche i backup verranno crittografati. I backup di DynamoDB sono sempre crittografati. Quando usi Ripristino di emergenza di elastico di AWS, vengono crittografati tutti i dati in transito e a riposo. Con Elastic Disaster Recovery i dati a riposo possono essere crittografati tramite la chiave di crittografia dei volumi della crittografia predefinita in Amazon EBS o una chiave gestita dal cliente personalizzata. 

 **Passaggi dell'implementazione** 

1.  Utilizzo della crittografia su ciascuno dei datastore. Se i dati di origine sono crittografati, lo sarà anche il backup. 
   + [Usa la crittografia in Amazon RDS.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html). Puoi configurare la crittografia dei dati a riposo utilizzando AWS Key Management Service al momento della creazione di un'istanza RDS. 
   + [Usa la crittografia su volumi Amazon EBS.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html). Puoi configurare la crittografia predefinita o specificare una chiave univoca al momento della creazione del volume. 
   +  Usa la [crittografia Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) necessaria. DynamoDB esegue la crittografia di tutti i dati a riposo. Puoi utilizzare una chiave AWS KMS di proprietà di AWS o una chiave KMS gestita da AWS specificando una chiave archiviata nel tuo account. 
   + [Esegui la crittografia dei dati archiviati in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html). Configura la crittografia al momento della creazione del file system. 
   +  Configura la crittografia nelle regioni di origine e di destinazione. Puoi configurare la crittografia dei dati a riposo in Amazon S3 utilizzando le chiavi archiviate in KMS, ma le chiavi sono specifiche per regione. Puoi specificare le chiavi di destinazione quando configuri la replica. 
   +  Scegli se usare la [crittografia Amazon EBS predefinita o personalizzata per Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/volumes-drs.html#ebs-encryption). Questa opzione esegue la crittografia dei dati a riposo replicati nei dischi della sottorete dell'area di staging e nei dischi replicati. 

1.  Implementazione delle autorizzazioni con privilegi minimi per accedere ai backup. Segui le best practice per limitare l'accesso a backup, snapshot e repliche in linea con le [best practice per la sicurezza](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Marketplace AWS: prodotti che possono essere usati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [Crittografia in Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) 
+  [Amazon S3: protezione dei dati tramite crittografia](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) 
+  [Configurazione aggiuntiva della replica tra regioni: replica di oggetti creati con la crittografia lato server (SSE) usando chiavi di crittografia archiviate in AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html) 
+  [Crittografia dei dati a riposo in DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) 
+  [Crittografia di risorse Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) 
+  [Crittografia di dati e metadati in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) 
+  [Crittografia per i backup in AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html) 
+  [Gestione di tabelle crittografate](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html) 
+  [Principio della sicurezza: Framework AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) 
+ [ Che cos'è Ripristino di emergenza di elastico di AWS? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

 **Esempi correlati:** 
+  [Well-Architected Lab: Implementazione della replica bidirezionale tra regioni per Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) 

# REL09-BP03 Esecuzione del backup dei dati in automatico
<a name="rel_backing_up_data_automated_backups_data"></a>

Configura i backup in modo che vengano eseguiti automaticamente in base a una pianificazione periodica informata dall'Obiettivo del punto di ripristino (RPO) o dalle modifiche apportate al set di dati. I set di dati critici con bassi requisiti di perdita di dati devono essere sottoposti a backup automatico su base frequente, mentre i dati meno critici, per i quali è accettabile una certa perdita, possono essere sottoposti a backup meno frequenti.

 **Risultato desiderato:** un processo di backup automatico che crea backup delle origini dati a una cadenza prestabilita. 

 **Anti-pattern comuni:** 
+  Eseguire i backup manualmente. 
+  Utilizzare risorse che dispongono di funzionalità di backup, ma non includere il backup nell'automazione. 

 **Vantaggi dell'adozione di questa best practice:** l'automazione dei backup verifica che i backup vengano eseguiti regolarmente in base all'RPO e invia avvisi in caso contrario. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 AWS Backup può essere utilizzato per creare backup automatici di varie origini dei dati AWS. Il backup delle istanze Amazon RDS può essere eseguito quasi ininterrottamente ogni cinque minuti e quello degli oggetti Amazon S3 quasi ininterrottamente ogni quindici minuti, consentendo il ripristino point-in-time (PITR) a un punto specifico della cronologia di backup. Per altre origini dei dati AWS, come volumi Amazon EBS, tabelle Amazon DynamoDB o file system Amazon FSx, AWS Backup può eseguire il backup automatico con una frequenza di un'ora. Questi servizi offrono anche funzionalità di backup native. I servizi AWS che offrono il backup automatico con ripristino point-in-time (PITR) includono [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) e [Amazon Keyspaces (per Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html). Questi servizi permettono il ripristino temporizzato in base a un momento specifico all'interno della cronologia dei backup. La maggior parte degli altri servizi di archiviazione di dati AWS offre la possibilità di programmare backup periodici, anche ogni ora. 

 Amazon RDS e Amazon DynamoDB offrono il backup continuo con ripristino point-in-time (PITR). Una volta abilitato, il controllo delle versioni in Amazon S3 è automatico. Puoi usare [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) per automatizzare la creazione, la copia e l'eliminazione di shapshot Amazon EBS. Può anche automatizzare la creazione, la copia, la rimozione e la cancellazione di Amazon Machine Images (AMI) con backup Amazon EBS e dei relativi snapshot Amazon EBS sottostanti. 

 Ripristino di emergenza di elastico di AWS offre la replica a livello di blocco continua dall'ambiente di origine (on-premise o AWS) alla regione di ripristino di destinazione. Gli snapshot Amazon EBS point-in-time vengono creati e gestiti automaticamente dal servizio. 

 Per una visualizzazione centralizzata dell'automazione e della cronologia dei backup, AWS Backup fornisce una soluzione di backup completamente gestita basata su policy. Centralizza e automatizza il backup dei dati su più servizi AWS nel cloud e on-premise utilizzando Gateway di archiviazione AWS. 

 Oltre a quella di controllo delle versioni, Amazon S3 offre tutte le funzioni di replica. L'intero bucket S3 può essere replicato automaticamente in un altro bucket in una Regione AWS diversa. 

 **Passaggi dell'implementazione** 

1.  **Identifica le origini dati** di cui al momento viene eseguito manualmente il backup. Per ulteriori informazioni, consulta [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md). 

1.  **Determina l'RPO** per il carico di lavoro. Per ulteriori informazioni, consulta [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md). 

1.  **Usa una soluzione di backup automatica o un servizio gestito**. AWS Backup è un servizio completamente gestito che semplifica la [centralizzazione e l'automazione della protezione dei dati tra diversi servizi AWS, nel cloud e on-premise](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). Usando piani di backup in AWS Backup, crea regole che definiscano le risorse di cui eseguire il backup e la frequenza di creazione dei backup. Questa frequenza deve essere informata dall'RPO stabilito al punto 2. Per linee guida pratiche su come creare backup automatici con AWS Backup, consulta [Well-Architected Lab: Test del backup e del ripristino di dati](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/). La maggior parte dei servizi AWS di archiviazione dei dati offre funzionalità di backup native. Ad esempio, RDS può essere sfruttato per backup automatici con ripristino point-in-time (PITR). 

1.  **Per le origini dati non supportate** da una soluzione di backup automatica o da un servizio gestito, come le code di messaggi o le origini dati on-premise, valuta se usare una soluzione di terze parti affidabile per creare backup automatici. In alternativa, puoi creare un'automazione utilizzando la AWS CLI o gli SDK. Puoi usare funzioni AWS Lambda o AWS Step Functions per definire la logica necessaria per la creazione di un backup di dati e Amazon EventBridge per eseguirla in base a una frequenza determinata dall'RPO. 

 **Livello di impegno per il piano di implementazione:** basso. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner per il backup](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [Marketplace AWS: prodotti che possono essere usati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [Creazione di una regola EventBridge attivata in base a una pianificazione](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) 
+  [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [Che cos'è AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 
+ [ Che cos'è Ripristino di emergenza di elastico di AWS? ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

 **Video correlati:** 
+  [AWS re:Invent 2019: Approfondimento su AWS Backup, con Rackspace (STG341)](https://youtu.be/av8DpL0uFjc) 

 **Esempi correlati:** 
+  [Well-Architected Lab: Esecuzione di test del backup e del ripristino di dati](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 

# REL09-BP04 Ripristino periodico dei dati per verificare l'integrità e i processi di backup:
<a name="rel_backing_up_data_periodic_recovery_testing_data"></a>

Verifica che l'implementazione del processo di backup soddisfi gli obiettivi del tempo di ripristino (RTO) e gli obiettivi del punto di ripristino (RPO) eseguendo un test del ripristino.

 **Risultato desiderato:** ripristino periodico dei dati dai backup tramite meccanismi ben definiti per garantire che il ripristino sia possibile entro l'obiettivo del tempo di ripristino (RTO) stabilito per il carico di lavoro. Verifica che il ripristino da un backup porti a una risorsa che contiene i dati originali senza che questi siano danneggiati o inaccessibili e con una perdita di dati entro l'Obiettivo del punto di ripristino (RPO). 

 **Anti-pattern comuni:** 
+  Ripristino di un backup, ma senza eseguire query sui dati o recuperarli per verificare di poter usare il ripristino. 
+  Presupporre l'esistenza di un backup. 
+  Presupporre che il backup di un sistema sia pienamente operativo e che i dati possano essere recuperati da esso. 
+  Presupporre che il tempo di ripristino o di recupero dei dati da un backup rientri nell'RTO del carico di lavoro. 
+  Presupporre che i dati contenuti nel backup rientrino nell'RPO del carico di lavoro. 
+  Ripristino in base alle esigenze, senza usare un runbook o seguire una procedura automatica prestabilita. 

 **Vantaggi dell'adozione di questa best practice:** i test del ripristino dei backup permettono di verificare che i dati possano essere ripristinati senza timore che siano mancanti o danneggiati, che il ripristino e il recupero siano possibili in base all'RTO per il carico di lavoro e che un'eventuale perdita di dati rientri nell'RPO per il carico di lavoro. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 La verifica delle capacità di backup e ripristino aumenta la fiducia nella capacità di eseguire queste azioni durante un'interruzione. Ripristina periodicamente i backup in una nuova posizione ed esegui test per verificare l'integrità dei dati. Alcuni test comuni che devono essere eseguiti sono la verifica che tutti i dati siano disponibili, non siano danneggiati e siano accessibili e che un'eventuale perdita di dati rientri nell'RPO per il carico di lavoro. Questi test possono anche aiutare a verificare se i meccanismi di ripristino sono sufficientemente veloci per soddisfare l'RTO del carico di lavoro. 

 Con AWS, puoi creare un ambiente di test e ripristinare i backup per valutare le funzionalità RTO e RPO ed eseguire test sul contenuto e l'integrità dei dati. 

 Inoltre, Amazon RDS e Amazon DynamoDB consentono il ripristino point-in-time (PITR). Utilizzando il backup continuo, puoi ripristinare il set di dati allo stato in cui si trovava in una data e un'ora specificate. 

 tutti i dati siano disponibili, non siano danneggiati, siano accessibili e che qualsiasi perdita di dati rientri nell'RPO del carico di lavoro. Questi test possono anche aiutare a verificare se i meccanismi di ripristino sono sufficientemente veloci per soddisfare l'RTO del carico di lavoro. 

 Ripristino di emergenza di elastico di AWS offre snapshot di ripristino point-in-time (RPIT) continui di volumi Amazon EBS. Durante la replica dei server di origine, vengono registrati gli stati point-in-time nel corso del tempo in base alla policy configurata. Elastic Disaster Recovery permette di verificare l'integrità di questi snapshot avviando istanze per scopi di test ed esercitazione senza reindirizzare il traffico. 

 **Passaggi dell'implementazione** 

1.  **Identifica le origini dati** di cui viene attualmente eseguito il backup e le posizioni in cui vengono archiviati i backup. Per le linee guida di implementazione, consulta [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md). 

1.  **Definisci i criteri per la convalida dei dati** per ogni origine dati. Tipi di dati differenti avranno proprietà diverse che potrebbero richiedere meccanismi di convalida diversi. Considera il modo in cui potrebbero essere convalidati questi dati prima di poterli utilizzare in produzione. Alcuni modi comuni per convalidare i dati sono l'uso delle loro proprietà dei dati e del backup, come il tipo di dati, il formato, la somma di controllo, la dimensione o la combinazione di questi elementi con una logica di convalida personalizzata. Ad esempio, può trattarsi di un confronto dei valori di checksum tra la risorsa ripristinata e l'origine dei dati al momento della creazione del backup. 

1.  **Definisci l'RTO e l'RPO** per il ripristino dei dati in base alle criticità dei dati. Per le linee guida di implementazione, consulta [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md). 

1.  **Valuta la capacità di ripristino**. Rivedi la strategia di backup e ripristino per capire se è in grado di soddisfare RTO e RPO e modifica la strategia se necessario. Usando la [Centrale di resilienza AWS](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html), puoi eseguire una valutazione del carico di lavoro. La valutazione esamina la configurazione dell'applicazione rispetto alle policy sulla resilienza e indica se gli obiettivi RTO e RPO possono essere raggiunti. 

1.  **Esegui un ripristino di test** usando i processi attualmente definiti nell'ambiente di produzione per il ripristino dei dati. Questi processi dipendono dal modo in cui è stato eseguito il backup dell'origine dei dati iniziale, dal formato e dalla posizione di archiviazione del backup stesso o dalla riproduzione dei dati da altre fonti. Ad esempio, se usi un servizio gestito come [AWS Backup, può trattarsi di un semplice ripristino del backup in una nuova risorsa](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). Se hai usato Ripristino di emergenza di elastico di AWS, puoi [avviare un'esercitazione di ripristino](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html). 

1.  **Convalida il ripristino dei dati** dalla risorsa ripristinata in base ai criteri definiti in precedenza per la convalida dei dati. I dati ripristinati e recuperati contengono il record o la voce più recente al momento del backup? Questi dati rientrano nell'RPO per il carico di lavoro? 

1.  **Misura il tempo necessario** per il ripristino e il recupero e confrontalo con l'RTO definito. Questo tempo deve rientrare nell'RTO per il carico di lavoro? Ad esempio, confronta i timestamp dell'inizio del processo di ripristino e del completamento della convalida del ripristino per calcolare la durata del processo. Tutte le chiamate API AWS includono un timestamp e queste informazioni sono disponibili in [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Sebbene queste informazioni possano fornire dettagli sull'inizio del processo di ripristino, la logica di convalida dovrebbe registrare il timestamp finale del completamento della convalida. Se usi un processo automatico, servizi come [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) possono essere utili per archiviare queste informazioni. Inoltre, molti servizi AWS offrono una cronologia degli eventi che fornisce informazioni con data e ora in cui si sono verificate determinate azioni. In AWS Backup le attività di backup e ripristino sono note come *processi* e tali processi possono contenere informazioni sul timestamp come parte dei metadati, che possono essere usate per misurare il tempo necessario per il ripristino e il recupero. 

1.  **Comunica agli stakeholder** se la convalida dei dati non riesce o se il tempo necessario per il ripristino e il recupero supera l'RTO definito per il carico di lavoro. Nell'implementare l'automazione a questo scopo, [come in questo lab](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/), puoi usare servizi come Amazon Simple Notification Service (Amazon SNS) per inviare notifiche push come e-mail o SMS agli stakeholder. [Questi messaggi possono anche essere pubblicati in applicazioni di messaggistica come Amazon Chime, Slack o Microsoft Teams](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) o usati per [creare attività come OpsItem usando OpsCenter di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html). 

1.  **Automatizza questo processo in modo che venga eseguito periodicamente** Ad esempio, per automatizzare i processi di ripristino e recupero si possono utilizzare servizi come AWS Lambda o una State Machine in AWS Step Functions, mentre Amazon EventBridge può essere utilizzato per attivare periodicamente questo flusso di lavoro di automazione, come mostrato nel diagramma di architettura sottostante. Per altre informazioni, consulta [Automazione della convalida del ripristino di dati con AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). Inoltre, [questo Well-Architected Lab](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) permette di acquisire esperienza pratica su un modo per implementare l'automazione per diverse fasi presentate qui. 

![\[Diagramma che mostra un processo di backup e ripristino automatizzato\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/automated-backup-restore-process.png)


 **Livello di impegno per il piano di implementazione:** da moderato a elevato, a seconda della complessità dei criteri di convalida. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Automazione della convalida del ripristino di dati con AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/) 
+  [Partner APN: partner per il backup](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [Marketplace AWS: prodotti che possono essere usati per il backup](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [Creazione di una regola EventBridge attivata in base a una pianificazione](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) 
+  [Backup e ripristino on demand per DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html) 
+  [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [Che cos'è AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 
+  [Che cos'è Ripristino di emergenza di elastico di AWS?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 
+  [Ripristino di emergenza di elastico di AWS](https://aws.amazon.com/disaster-recovery/) 

 **Esempi correlati:** 
+  [Well-Architected Lab: Esecuzione di test del backup e del ripristino di dati](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 

# REL 10. Come si utilizza l'isolamento dei guasti per proteggere il carico di lavoro?
<a name="rel-10"></a>

Le barriere per l'isolamento dei guasti limitano l'effetto di un errore all'interno di un carico di lavoro a un numero limitato di componenti. I componenti al di fuori della barriera non subiscono gli effetti del guasto. Utilizzando più barriere per l'isolamento dei guasti, puoi limitare l'impatto sul carico di lavoro.

**Topics**
+ [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Selezione delle posizioni appropriate per la tua implementazione multiposizione](rel_fault_isolation_select_location.md)
+ [REL10-BP03 Ripristino automatico dei componenti vincolati a una singola posizione](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 Utilizzo di architetture a scomparti per limitare la portata dell'impatto](rel_fault_isolation_use_bulkhead.md)

# REL10-BP01 Implementazione del carico di lavoro in diversi luoghi
<a name="rel_fault_isolation_multiaz_region_system"></a>

 Distribuisci i dati e le risorse del carico di lavoro su più zone di disponibilità o, se necessario, su diverse Regioni AWS. Questi luoghi possono essere diversi a seconda delle necessità. 

 Uno dei principi fondamentali per la progettazione di servizi su AWS è l'eliminazione di singoli punti di errore nell'infrastruttura fisica sottostante. Questo ci spinge a creare software e sistemi che utilizzano più zone di disponibilità e sono resistenti al fallimento di una singola zona. Allo stesso modo, i sistemi sono costruiti per resistere ai guasti di un singolo nodo di calcolo, singolo volume di archiviazione o singola istanza di un database. Quando si costruisce un sistema che si basa su componenti ridondanti, è importante garantire che i componenti funzionino in modo indipendente e, nel caso delle Regioni AWS, in modo autonomo. I vantaggi ottenuti dai calcoli di disponibilità teorica con componenti ridondanti sono validi solo se questo continua a essere vero. 

 **Zone di disponibilità (AZ)** 

 Le Regioni AWS sono composte da almeno due zone di disponibilità progettate per essere indipendenti. Ogni zona di disponibilità è separata da una distanza fisica significativa da altre zone per evitare scenari di guasto correlati, dovuti a rischi ambientali come incendi, inondazioni e tornado. Ogni zona di disponibilità ha anche un'infrastruttura fisica indipendente: connessioni dedicate di alimentazione di rete, fonti di alimentazione di backup autonome, servizi meccanici indipendenti e connettività di rete indipendente all'interno e all'esterno della zona di disponibilità. Questa struttura limita gli errori di uno qualsiasi di questi sistemi alla sola AZ interessata. Nonostante siano geograficamente separate, le zone di disponibilità sono situate nella stessa area regionale, il che consente una rete a velocità di trasmissione effettiva elevata e bassa latenza. L'intera Regione AWS (in tutte le zone di disponibilità, costituite da più data center fisicamente indipendenti) può essere trattata come un unico obiettivo logico di implementazione per il carico di lavoro, compresa la possibilità di replicare i dati in modo sincrono (ad esempio, tra i database). Ciò ti consente di utilizzare le zone di disponibilità in una configurazione attiva/attiva o attiva/standby. 

 Le zone di disponibilità sono indipendenti e pertanto la disponibilità del carico di lavoro aumenta quando il carico di lavoro è progettato per utilizzare più zone di disponibilità. Alcuni servizi AWS (tra cui il piano dati dell'istanza Amazon EC2) sono implementati come servizi strettamente zonali nei quali hanno un destino condiviso con la zona di disponibilità in cui si trovano. Le istanze Amazon EC2 nelle altre AZ non saranno, tuttavia, interessate e continueranno a funzionare. Allo stesso modo, se un errore in una zona di disponibilità causa l'errore di un database Amazon Aurora, un'istanza Aurora di lettura-replica in una AZ non interessata può essere automaticamente promossa a primaria. I servizi regionali AWS, ad esempio Amazon DynamoDB, utilizzano internamente più zone di disponibilità in una configurazione attiva/attiva per raggiungere gli obiettivi di progettazione della disponibilità per quel servizio, senza che sia necessario configurare il posizionamento delle AZ. 

![\[Diagramma che mostra un'architettura multi-livello implementata su tre zone di disponibilità. Tieni presente che Amazon S3 e Amazon DynamoDB sono sempre Multi-AZ automaticamente. L'ELB viene inoltre distribuito in tutte e tre le zone.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/multi-tier-architecture.png)


 Mentre i piani di controllo AWS in genere offrono la possibilità di gestire le risorse all'interno dell'intera Regione (più zone di disponibilità), alcuni piani di controllo (inclusi Amazon EC2 ed Amazon EBS) hanno la capacità di filtrare i risultati per una singola zona di disponibilità. Con questo approccio, la richiesta viene elaborata solo nella zona di disponibilità specificata, riducendo l'esposizione all'interruzione in altre zone di disponibilità. Questo esempio di AWS CLI illustra come ottenere informazioni su un'istanza Amazon EC2 dalla sola zona di disponibilità us-east-2c: 

```
 AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```

 *Zone locali AWS* 

 Le Zone locali AWS agiscono in modo simile alle zone di disponibilità nella rispettiva Regione AWS, in quanto possono essere selezionate come ubicazione di posizionamento per le risorse AWS zonali come le sottoreti e le istanze EC2. Ciò che le rende speciali è che non si trovano nella Regione AWS associata, ma vicino a grandi popolazioni, settori e centri IT in cui al momento non esiste alcuna Regione AWS. Tuttavia, mantengono una connessione sicura e a larghezza di banda elevata tra i carichi di lavoro locali nella zona locale e quelli in esecuzione nella Regione AWS. È consigliabile utilizzare le Zone locali AWS per implementare i carichi di lavoro più vicini agli utenti per requisiti a bassa latenza. 

 **Amazon Global Edge Network** 

 Amazon Global Edge Network è costituito da posizioni edge in città di tutto il mondo. Amazon CloudFront utilizza questa rete per fornire contenuti agli utenti finali con una latenza inferiore. AWS Global Accelerator consente di creare gli endpoint del carico di lavoro in queste posizioni edge per fornire l'onboarding alla rete globale AWS vicino agli utenti. Amazon API Gateway permette agli endpoint API ottimizzati per l'edge che utilizzano una distribuzione CloudFront di facilitare l'accesso dei clienti attraverso la posizione edge più vicina. 

 *Regioni AWS* 

 Le Regioni AWS sono progettate per essere autonome; pertanto, per utilizzare un approccio multi-regione, puoi implementare copie dedicate dei servizi in ciascuna Regione. 

 Un approccio multi-regione è comune per *le strategie di ripristino di emergenza* per raggiungere gli obiettivi di ripristino quando si verificano eventi unici su larga scala. Consulta [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) per ulteriori informazioni su queste strategie. Qui, tuttavia, si focalizza l'attenzione sulla *disponibilità*, che cerca di fornire un obiettivo medio di operatività nel tempo. Per gli obiettivi di alta disponibilità, un'architettura multi-regione sarà generalmente progettata per essere attiva/attiva, dove ogni copia del servizio (nelle rispettive Regioni) è attiva (serve le richieste). 

**Consiglio**  
 Gli obiettivi di disponibilità per la maggior parte dei carichi di lavoro possono essere soddisfatti utilizzando una strategia multi-AZ all'interno di una singola Regione AWS. Considera le architetture multi-regione solo quando i carichi di lavoro hanno requisiti di disponibilità estremi o altri obiettivi aziendali che richiedono un'architettura multi-regione. 

 AWS offre ai clienti la possibilità di gestire servizi in più Regioni. Ad esempio, AWS fornisce una replica continua e asincrona dei dati utilizzando la replica Amazon Simple Storage Service (Amazon S3), le repliche di lettura Amazon RDS (incluse le repliche di lettura Aurora) e le tabelle globali Amazon DynamoDB. Con la replica continua, le versioni dei dati sono disponibili per un uso quasi immediato in ogni Regione attiva. 

 Utilizzando AWS CloudFormation, puoi definire l'infrastruttura e implementarla in modo coerente sugli Account AWS e sulle Regioni AWS. Invece, AWS CloudFormation StackSets estende questa funzionalità consentendo di creare, aggiornare o eliminare stack AWS CloudFormation su più account e regioni con un'unica operazione. Per le implementazioni di istanza Amazon EC2, si utilizza un'immagine AMI (Amazon Machine Image) per fornire informazioni quali la configurazione hardware e il software installato. È possibile implementare una pipeline di Amazon EC2 Image Builder che crea le AMI necessarie e le copia nelle regioni attive. Ciò garantisce che *le Golden AMI* abbiano tutto ciò che serve per implementare e dimensionare il carico di lavoro in ogni nuova regione. 

 Per instradare il traffico, sia Amazon Route 53 sia AWS Global Accelerator abilitano la definizione di criteri che determinano quali utenti indirizzare a ogni endpoint regionale attivo. Con Global Accelerator imposti un valore di traffico per controllare la percentuale di traffico diretta a ciascun endpoint dell'applicazione. Route 53 supporta questo approccio percentuale e anche diverse altre policy disponibili, tra cui quelle basate sulla geoprossimità e sulla latenza. Global Accelerator sfrutta automaticamente la vasta rete di server edge AWS per convogliare il traffico verso la dorsale di rete AWS il prima possibile, con conseguente riduzione delle latenze delle richieste. 

 Tutte queste capacità operano in modo da preservare l'autonomia di ogni Regione. Ci sono pochissime eccezioni a questo approccio, inclusi i nostri servizi che forniscono distribuzione edge globale (ad esempio Amazon CloudFront e Amazon Route 53), insieme al piano di controllo per il servizio AWS Identity and Access Management (IAM). La maggior parte dei servizi opera interamente all'interno di una singola Regione. 

 **Data center in locale** 

 Per i carichi di lavoro eseguiti in un data center on-premise, puoi progettare un'esperienza ibrida quando possibile. AWS Direct Connect fornisce una connessione di rete dedicata dalla tua sede ad AWS che consente l'esecuzione in entrambi. 

 Un'altra opzione è quella di eseguire l'infrastruttura AWS e i servizi on-premise utilizzando AWS Outposts. AWS Outposts è un servizio completamente gestito che estende l'infrastruttura AWS, i servizi AWS, le API e gli strumenti al tuo data center. La stessa infrastruttura hardware utilizzata nel Cloud AWS viene installata nel data center. AWS Outposts è, quindi, connesso alla Regione AWS più vicina. Puoi quindi utilizzare AWS Outposts per supportare i carichi di lavoro che hanno requisiti di bassa latenza o di elaborazione dei dati locali. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Utilizza zone di disponibilità multiple e Regioni AWS. Distribuisci i dati e le risorse del carico di lavoro su più zone di disponibilità o, se necessario, su diverse Regioni AWS. Questi luoghi possono essere diversi a seconda delle necessità. 
  +  I servizi regionali sono distribuiti intrinsecamente in zone di disponibilità. 
    +  Sono inclusi Amazon S3, Amazon DynamoDB e AWS Lambda (se non collegati a un VPC) 
  +  Distribuisci il tuo container, istanza e carichi di lavoro basati su funzioni in più zone di disponibilità. Utilizza datastore multi-zona, inclusi sistemi di cache. Utilizza le funzionalità di dimensionamento automatico EC2, posizionamento di attività ECS, configurazione della funzione AWS Lambda in esecuzione nel tuo VPC e i cluster ElastiCache. 
    +  Utilizza sottoreti che sono in zone di disponibilità separate nella distribuzione di gruppi Auto Scaling. 
      +  [Esempio: distribuzione di istanze in più zone di disponibilità](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) 
      +  [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) 
      +  [Configurazione di una funzione AWS Lambda per accedere alle risorse in un Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html) 
      +  [Scelta di regioni e zone di disponibilità](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html) 
    +  Utilizza sottoreti in zone di disponibilità separate quando distribuisci gruppi Auto Scaling. 
      +  [Esempio: distribuzione di istanze in più zone di disponibilità](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) 
    +  Utilizza parametri di posizionamento attività ECS, specificando i gruppi di sottorete DB. 
      +  [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) 
    +  Utilizza sottoreti in più zone di disponibilità quando configuri una funzione da eseguire nel tuo VPC. 
      +  [Configurazione di una funzione AWS Lambda per accedere alle risorse in un Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html) 
    +  Utilizza più zone di disponibilità con cluster ElastiCache. 
      +  [Scelta di regioni e zone di disponibilità](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html) 
+  Se il carico di lavoro deve essere implementato in più Regioni, scegli una strategia multi-regione. La maggior parte delle esigenze di affidabilità può essere soddisfatta all'interno di una singola Regione AWS utilizzando una strategia a più zone di disponibilità. Quando necessario, utilizza una strategia multi-Regione per soddisfare le tue esigenze aziendali. 
  +  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
    +  Il backup in un'altra Regione AWS può garantire ulteriormente che i dati saranno disponibili quando necessario. 
    +  Alcuni carichi di lavoro hanno requisiti normativi che prevedono l'utilizzo di una strategia multi-regione. 
+  Valuta AWS Outposts per il tuo carico di lavoro. Se il carico di lavoro richiede bassa latenza nel data center locale o ha requisiti di elaborazione dei dati locali. In tal caso esegui l'infrastruttura e i servizi AWS on-premise utilizzando AWS Outposts. 
  +  [Che cos'è AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) 
+  Stabilisci se le Zone locali AWS ti aiutano a fornire il servizio ai tuoi utenti. Se hai requisiti di bassa latenza, verifica se le Zone locali AWS si trovano vicino ai tuoi utenti. Se sì, utilizzale per implementare carichi di lavoro più vicini a tali utenti. 
  +  [Domande frequenti sulle Zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure) 
+  [Domande frequenti sulle Zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/) 
+  [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html) 
+  [Scelta di regioni e zone di disponibilità](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html) 
+  [Esempio: distribuzione di istanze in più zone di disponibilità](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) 
+  [Tabelle globali: replica multi-regione con DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html) 
+  [Using Amazon Aurora global databases (Utilizzo di database Amazon Aurora globali)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) 
+  [Creating a Multi-Region Application with AWS Services blog series (Creazione di un'applicazione multi-regione con la serie di blog sui servizi AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) 
+  [Che cos'è AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) 

 **Video correlati:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
+  [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (Innovazione e gestione dell'infrastruttura di rete globale AWS) (NET339)](https://youtu.be/UObQZ3R9_4c) 

# REL10-BP02 Selezione delle posizioni appropriate per la tua implementazione multiposizione
<a name="rel_fault_isolation_select_location"></a>

## Risultato desiderato
<a name="desired-outcome"></a>

 Per ottenere un'elevata disponibilità, distribuisci sempre (quando possibile) i componenti del carico di lavoro in più zone di disponibilità (AZ), come illustrato nella Figura 10. Per i carichi di lavoro con requisiti di resilienza estremi, valuta attentamente le opzioni per un'architettura multiregione. 

![\[Diagramma che mostra un'implementazione resiliente di database multi-AZ con backup in un'altra regione AWS\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/multi-az-architecture.png)


## Anti-pattern comuni
<a name="common-anti-patterns"></a>
+  Scelta di progettare un'architettura multi-regione quando un'architettura multi-AZ soddisferebbe i requisiti. 
+  Non si tiene conto delle dipendenze tra i componenti dell'applicazione se i requisiti di resilienza e multi-sede differiscono tra questi componenti. 

## Vantaggi dell'adozione di questa best practice
<a name="benefits-of-establishing-this-best-practice"></a>

 Per la resilienza, devi utilizzare un approccio che costruisca livelli di difesa. Un livello protegge dalle interruzioni più piccole e più comuni costruendo un'architettura ad alta disponibilità utilizzando più AZ. Un altro livello di difesa è destinato a proteggere da eventi rari come disastri naturali diffusi e interruzioni a livello regionale. Questo secondo livello implica l'architettura dell'applicazione in modo che si estenda su più Regioni AWS. 
+  La differenza tra una disponibilità del 99,5% e una del 99,99% è di oltre 3,5 ore al mese. La disponibilità prevista di un carico di lavoro può raggiungere i "quattro nove" solo se si trova in più AZ. 
+  Eseguendo il carico di lavoro in più AZ, puoi isolare gli errori di alimentazione, raffreddamento e rete e la maggior parte dei disastri naturali come incendi e inondazioni. 
+  L'implementazione di una strategia multi-regione per il tuo carico di lavoro aiuta a proteggerlo da disastri naturali diffusi che colpiscono un'ampia regione geografica di un paese o da guasti tecnici di portata regionale. Tieni presente che l'implementazione di un'architettura multi-regione può essere molto complessa e di solito non è necessaria per la maggior parte dei carichi di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per un evento disastroso basato sull'interruzione o la perdita parziale di una zona di disponibilità, l'implementazione di un carico di lavoro a disponibilità elevata in più zone di disponibilità all'interno di una singola Regione AWS aiuta a mitigare i disastri naturali e tecnici. Ogni Regione AWS è composta da più zone di disponibilità, ciascuna isolata dagli errori nelle altre zone e separate da una distanza significativa. Tuttavia, per un evento di disastro che include il rischio di perdere più componenti della zona di disponibilità, che si trovano a una distanza significativa l'uno dall'altro, è necessario implementare opzioni di ripristino di emergenza per mitigare gli errori di portata regionale. Per i carichi di lavoro che richiedono un'estrema resilienza (infrastrutture critiche, applicazioni sanitarie, infrastrutture di sistemi finanziari e così via), può essere necessaria una strategia multi-regione. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Valutare il carico di lavoro e determinare se le esigenze di resilienza possono essere soddisfatte da un approccio multi-AZ (Regione AWS singola) o se richiedono un approccio multi-regione. L'implementazione di un'architettura multi-regione per soddisfare questi requisiti introdurrà un'ulteriore complessità, quindi considera attentamente il tuo caso d'uso e i suoi requisiti. I requisiti di resilienza possono quasi sempre essere soddisfatti utilizzando un singolo Regione AWS. Per stabilire se è necessario utilizzare più Regioni, considera i seguenti possibili requisiti: 

   1.  **Ripristino di emergenza**: per un evento disastroso basato sull'interruzione o la perdita parziale di una zona di disponibilità, l'implementazione di un carico di lavoro a disponibilità elevata in più zone di disponibilità all'interno di una singola Regione AWS aiuta a mitigare i disastri naturali e tecnici. In caso di eventi disastrosi che comportano il rischio di perdere più componenti della zone di disponibilità, che si trovano a una distanza significativa l'uno dall'altro, è necessario implementare il ripristino di emergenza in più regioni per mitigare i disastri naturali o gli errori tecnici di portata regionale. 

   1.  **Alta disponibilità**: è possibile utilizzare un'architettura multi-regione (utilizzando più AZ in ogni regione) per ottenere una disponibilità superiore a quattro 9 (> 99,99%). 

   1.  **Localizzazione delle risorse**: quando si distribuisce un carico di lavoro a un pubblico globale, è possibile distribuire stack localizzati in diverse Regioni AWS per servire il pubblico di quelle regioni. La localizzazione può includere la lingua, la valuta e i tipi di dati memorizzati. 

   1.  **Prossimità agli utenti:** quando si distribuisce un carico di lavoro a un pubblico globale, è possibile ridurre la latenza distribuendo gli stack alle regioni Regioni AWS in prossimità degli utenti finali. 

   1.  **Posizione fisica dei dati**: alcuni carichi di lavoro sono soggetti a requisiti di residenza dei dati, in base ai quali i dati di determinati utenti devono rimanere all'interno dei confini di un determinato Paese. In base alla normativa in questione, è possibile scegliere di distribuire un intero stack o solo i dati nella Regione AWS all'interno di tali confini. 

1.  Ecco alcuni esempi di funzionalità multi-AZ fornite dai servizi AWS: 

   1.  Per proteggere i carichi di lavoro che utilizzano EC2 o ECS, è necessario distribuire un Elastic Load Balancer davanti alle risorse di calcolo. Elastic Load Balancing quindi fornisce la soluzione per rilevare le istanze nelle zone non integre e instradare il traffico verso quelle integre. 

      1.  [Nozioni di base su Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html) 

      1.  [Nozioni di base su Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html) 

   1.  Nel caso di istanze EC2 che eseguono software commerciale pronto all'uso e che non supportano il bilanciamento del carico, puoi ottenere una forma di tolleranza ai guasti implementando una metodologia di ripristino di emergenza multi-AZ. 

      1. [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md)

   1.  Per le attività Amazon ECS, distribuire il servizio in modo uniforme su tre AZ per ottenere un equilibrio tra disponibilità e costi. 

      1.  [Amazon ECS availability best practices \$1 Containers (Best practice di disponibilità ECS \$1 Container)](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/) 

   1.  Per non Aurora Amazon RDS, puoi scegliere multi-AZ come opzione di configurazione. In caso di errore dell'istanza del database primario, Amazon RDS promuove automaticamente un database standby per ricevere il traffico in un'altra zona di disponibilità. Puoi inoltre creare repliche di lettura multi-regione per migliorare la resilienza. 

      1.  [Implementazioni Multi-AZ Amazon RDS](https://aws.amazon.com/rds/features/multi-az/) 

      1.  [Creazione di una replica di lettura in un'altra Regione AWS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html) 

1.  Ecco alcuni esempi di funzionalità multi-AZ fornite dai servizi AWS: 

   1.  Per i carichi di lavoro Amazon S3 in cui la disponibilità multi-AZ è fornita automaticamente dal servizio, considera i punti di accesso multi-regione se è necessaria un'implementazione multi-regione. 

      1.  [Punti di accesso multi-regione in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html) 

   1.  Per le tabelle DynamoDB in cui la disponibilità multi-AZ è fornita automaticamente dal servizio, è possibile convertire facilmente le tabelle esistenti in tabelle globali per sfruttare più regioni. 

      1.  [Convert Your Single-Region Amazon DynamoDB Tables to Global Tables (Convertire le tabelle Amazon DynamoDB di una singola regione in tabelle globali)](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/) 

   1.  Se il carico di lavoro è gestito da Application Load Balancers o da Network Load Balancer, utilizza AWS Global Accelerator per migliorare la disponibilità dell'applicazione indirizzando il traffico verso più regioni che contengono endpoint integri. 

      1.  [Endpoints for standard accelerators in AWS Global Accelerator - AWS Global Accelerator (Endpoint per acceleratori standard in AWS Global Accelerator) (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html) 

   1.  Per le applicazioni che sfruttano AWS EventBridge, considera i bus tre regioni per inoltrare gli eventi ad altre regioni selezionate. 

      1.  [Sending and receiving Amazon EventBridge events between Regioni AWS (Invio e ricezione di eventi Amazon EventBridge tra regioni AWS)](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html) 

   1.  Per i database Amazon Aurora, considera i database globali Aurora, che si estendono su più regioni AWS. I cluster esistenti possono essere modificati per aggiungere anche nuove Regioni. 

      1.  [Nozioni di base sui database globali Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html) 

   1.  Se il carico di lavoro include chiavi di crittografia AWS Key Management Service (AWS KMS), valuta se le chiavi multi-regione sono adatte all'applicazione. 

      1.  [Chiavi multi-regione in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) 

   1.  Per altre funzionalità del servizio AWS, vedi questa serie di blog su [Creating a Multi-Region Application with AWS Services series (Creazione di un'applicazione multi-regione con la serie di servizi AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) 

 **Livello di impegno per il piano di implementazione: **da moderato ad alto 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Creating a Multi-Region Application with AWS Services series (Creazione di un'applicazione multi-regione con la serie di servizi AWS)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) 
+  [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active (Architettura di ripristino di emergenza su AWS, parte IV: attiva/attiva multi-sito)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/) 
+  [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure) 
+  [Domande frequenti su AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/) 
+  [Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud (Architettura di ripristino di emergenza su AWS parte I: strategie per il ripristino nel cloud)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) 
+  [Il ripristino di emergenza è differente nel cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html) 
+  [Tabelle globali: replica multi-regione con DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html) 

 **Video correlati:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli di architettura per applicazioni attive-attive multiregione) (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
+  [Auth0: architettura ad alta disponibilità multi-Regione che raggiunge più di 1,5 miliardi di accessi al mese con failover automatico](https://www.youtube.com/watch?v=vGywoYc_sA8) 

   **Esempi correlati:** 
+  [Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud (Architettura di ripristino di emergenza su AWS parte I: strategie per il ripristino nel cloud)](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) 
+  [DTCC raggiunge livelli di resilienza superiori a quelli che raggiunge on-premise](https://aws.amazon.com/solutions/case-studies/DTCC/) 
+  [Expedia Group utilizza un'architettura multi-regione, a più zone di disponibilità con un servizio DNS proprietario per aggiungere resilienza alle applicazioni](https://aws.amazon.com/solutions/case-studies/expedia/) 
+  [Uber: ripristino di emergenza per Kafka multi-Regione](https://eng.uber.com/kafka/) 
+  [Netflix: attivo-attivo per la resilienza multi-regione](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b) 
+  [Come costruiamo la posizione fisica dei dati per Atlassian Cloud](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud) 
+  [Intuit TurboTax funziona in due regioni](https://www.youtube.com/watch?v=286XyWx5xdQ) 

# REL10-BP03 Ripristino automatico dei componenti vincolati a una singola posizione
<a name="rel_fault_isolation_single_az_system"></a>

Se i componenti del carico di lavoro possono essere eseguiti in una sola zona di disponibilità o in un data center on-premise, devi rendere possibile la ricostruzione completa del carico di lavoro in base agli obiettivi di ripristino definiti.

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Se, a causa di vincoli tecnologici, non è possibile seguire le linee guida per distribuire il carico di lavoro in più posizioni, è necessario implementare un percorso alternativo mirato alla resilienza. È necessario automatizzare la possibilità di ricreare l'infrastruttura necessaria, ridistribuire le applicazioni e ricreare i dati necessari per questi casi. 

 Ad esempio, Amazon EMR lancia tutti i nodi per un determinato cluster nella stessa zona di disponibilità: eseguire un cluster nella stessa zona migliora le prestazioni dei flussi di lavoro poiché fornisce una velocità di accesso ai dati più elevata. Se questo componente è necessario per la resilienza del carico di lavoro, è necessario disporre di un modo per implementare nuovamente il cluster e i relativi dati. Inoltre, per Amazon EMR è necessario effettuare il provisioning della ridondanza in modi diversi dall'utilizzo di Multi-AZ. Puoi effettuare il provisioning di [più nodi](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Usando il [file system EMR (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), i dati in EMR possono essere ripristinati in Amazon S3, che a sua volta può essere replicato tra più zone di disponibilità o Regioni AWS. 

 Analogamente, Amazon Redshift per impostazione predefinita effettua il provisioning del cluster in una zona di disponibilità casuale all'interno della Regione AWS selezionata. Tutti i nodi del cluster vengono assegnati nella stessa zona. 

 Per carichi di lavoro basati su server stateful implementati in un data center on-premise, puoi usare Ripristino di emergenza di elastico di AWS per proteggerli in AWS. Se il carico di lavoro è già ospitato in AWS, puoi usare Elastic Disaster Recovery per proteggerlo in una zona di disponibilità o regione alternativa. Elastic Disaster Recovery usa la replica a livello di blocco continua in un'area di staging leggera per fornire il ripristino rapido e affidabile di applicazioni on-premise e basate sul cloud. 

 **Passaggi dell'implementazione** 

1.  Implementa l'autoriparazione. Distribuisci le tue istanze o container utilizzando, quando possibile, il ridimensionamento automatico. Se non è possibile utilizzare il ridimensionamento automatico, utilizza il ripristino automatico per istanze EC2 o implementa l'automazione di autoriparazione in base agli eventi del ciclo di vita di container Amazon EC2 o ECS. 
   +  Usa [gruppi con Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) per carichi di lavoro in istanze e container che non abbiano requisiti di un singolo indirizzo IP, indirizzo IP privato o indirizzo IP elastico per le istanze e di metadati delle istanze. 
     +  È possibile usare i dati utente del modello di avvio per implementare l'automazione per la riparazione automatica della maggior parte dei carichi di lavoro. 
   +  Usa il [ripristino automatico di istanze Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) per i carichi di lavoro che richiedono un singolo indirizzo IP, indirizzo IP privato o indirizzo IP elastico per le istanze e metadati delle istanze. 
     +  Il ripristino automatico invierà avvisi sullo stato del ripristino a un argomento SNS quando viene rilevato l'errore dell'istanza. 
   +  Usa [eventi del ciclo di vita delle istanze Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) o [eventi Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) per automatizzare la riparazione automatica quando il dimensionamento automatico o il recupero in EC2 non sono opzioni valide. 
     +  Utilizza gli eventi per invocare l'automazione che riparerà il tuo componente secondo la logica di processo richiesta. 
   +  Proteggi i carichi di lavoro stateful limitati a una singola posizione usando [Ripristino di emergenza di elastico di AWS](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Eventi Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) 
+  [Hook del ciclo di vita Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) 
+  [Recover your instance.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) 
+  [Scalabilità automatica del servizio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) 
+  [Che cos'è Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
+ [Ripristino di emergenza di elastico di AWS](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

# REL10-BP04 Utilizzo di architetture a scomparti per limitare la portata dell'impatto
<a name="rel_fault_isolation_use_bulkhead"></a>

Implementa architetture a scomparti (note anche come architetture basate su celle) per limitare l'effetto di un guasto all'interno di un carico di lavoro a un numero ridotto di componenti.

 **Risultato desiderato:** un'architettura basata su celle usa più istanze isolate di un carico di lavoro, in cui ogni istanza è nota come cella. Ogni cella è indipendente, non condivide lo stato con altre celle e gestisce un sottoinsieme delle richieste complessive del carico di lavoro. Questo approccio riduce il possibile impatto di un errore, ad esempio un aggiornamento software non valido, a una singola cella e alle richieste elaborate. Se un carico di lavoro usa 10 celle per gestire 100 richieste e si verifica un errore, il 90% delle richieste complessive non sarà interessato dall'errore. 

 **Anti-pattern comuni:** 
+  Aumento illimitato delle celle. 
+  Applicazione di aggiornamenti o implementazioni del codice in tutte le celle contemporaneamente. 
+  Condivisione dello stato dei componenti tra celle (con l'eccezione del livello di instradamento). 
+  Aggiunta di logica di business o instradamento complessa al livello di instradamento. 
+  Le interazioni tra celle non sono ridotte al minimo. 

 **Vantaggi dell'adozione di questa best practice:** con un'architettura basata su celle, molti tipi comuni di errore sono limitati alla cella stessa, per un ulteriore isolamento degli errori. Queste limitazioni possono fornire resilienza a determinati tipi di errore altrimenti difficili da contenere, tra cui implementazioni del codice non riuscite o richieste compromesse o che attivano una modalità di errore specifica, note anche come *richieste poison pill*. 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Su una nave gli scomparti permettono di limitare la falla di uno scafo a una sola sezione dello scafo. In sistemi complessi questo modello viene spesso replicato per consentire l'isolamento degli errori. Le limitazioni per l'isolamento degli errori riducono l'effetto di un errore all'interno di un carico di lavoro a un numero limitato di componenti. I componenti al di fuori della barriera non subiscono gli effetti del guasto. Utilizzando più barriere per l'isolamento dei guasti, puoi limitare l'impatto sul carico di lavoro. In AWS i clienti possono usare più zone di disponibilità e regioni per fornire l'isolamento degli errori, ma questo concetto può essere esteso anche all'architettura del carico di lavoro. 

 Il carico di lavoro complessivo viene partizionato in celle tramite una chiave di partizione. Questa chiave deve essere allineata alla *granularità* del servizio o al modo naturale in cui il carico di lavoro del servizio può essere suddiviso con interazioni minime tra celle. Esempi di chiavi di partizione sono un ID cliente, un ID risorsa o qualsiasi altro parametro facilmente accessibile nella maggior parte delle chiamate API. Un livello di instradamento alle celle distribuisce le richieste a singole celle in base alla chiave di partizione e presenta un unico endpoint ai client. 

![\[Diagramma che mostra un'architettura basata su celle\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/cell-based-architecture.png)


 **Passaggi dell'implementazione** 

 Nel progettare un'architettura basata su celle, devi tenere conto di diversi aspetti della progettazione: 

1.  **Chiave di partizione**: la scelta della chiave di partizione impone alcune considerazioni speciali. 
   +  Questa chiave deve essere allineata alla granularità del servizio o al modo naturale in cui il carico di lavoro del servizio può essere suddiviso con interazioni minime tra celle. Alcuni esempi: `ID cliente` oppure `ID risorsa`. 
   +  La chiave di partizione deve essere disponibile in tutte le richieste, direttamente o in modo da poter essere facilmente dedotta in modo deterministico da altri parametri. 

1.  **Mappatura persistente delle celle**: i servizi a monte devono interagire solo con un'unica cella per l'intero ciclo di vita delle risorse correlate. 
   +  A seconda del carico di lavoro, può essere necessaria una strategia di migrazione delle celle per la migrazione dei dati da una cella a un'altra. Un possibile scenario in cui è necessaria la migrazione delle celle è quando una risorsa o un utente specifico nel carico di lavoro diventa troppo grande e richiede una cella dedicata. 
   +  Le celle non devono condividere lo stato o i componenti. 
   +  Di conseguenza, l'interazione tra celle deve essere evitata o mantenuta al minimo, in quanto le interazioni creano dipendenze tra le celle e riducono quindi i vantaggi forniti dall'isolamento degli errori. 

1.  **Livello di instradamento**: è un componente condiviso tra celle e di conseguenza non può seguire la stessa strategia di compartimentazione applicata alle celle. 
   +  È consigliabile che il livello di instradamento distribuisca richieste a singole celle usando un algoritmo di mappatura delle partizioni efficiente in termini di risorse di calcolo, ad esempio combinando funzioni hash crittografiche e aritmetica modulare per mappare le chiavi di partizione alle celle. 
   +  Per evitare l'impatto su più celle, il livello di instradamento deve restare il più semplice e orizzontalmente scalabile possibile, evitando logica di business complessa in questo livello. Questo approccio offre il vantaggio aggiuntivo di semplificare la comprensione del suo comportamento previsto in ogni momento, permettendo test esaustivi. Come spiegato da Colm MacCárthaigh in [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/), progettazioni semplici e modelli di lavoro costanti producono sistemi affidabili e riducono l'antifragilità. 

1.  **Dimensione delle celle**: le celle devono avere una dimensione massima che non deve essere superata. 
   +  La dimensione massima deve essere identificata attraverso l'esecuzione di test completi, fino a raggiungere i punti di rottura e definire i margini operativi. Per ulteriori informazioni su come implementare procedure di test, consulta [REL07-BP04 Esecuzione di un test di carico sul carico di lavoro](rel_adapt_to_changes_load_tested_adapt.md) 
   +  L'aumento del carico di lavoro complessivo deve essere gestito tramite l'aggiunta di celle, in modo da poterlo dimensionare in base al crescere della domanda. 

1.  **Strategie multi-Az e multi-regione**: è consigliabile utilizzare più livelli di resilienza a tipi di errore diversi. 
   +  Per la resilienza, devi utilizzare un approccio che costruisca livelli di difesa. Un livello protegge dalle interruzioni minime e più comuni attraverso la creazione di un'architettura a disponibilità elevata tramite più zone di disponibilità. Un altro livello di difesa è destinato a proteggere da eventi rari come disastri naturali diffusi e interruzioni a livello regionale. Questo secondo livello implica l'architettura dell'applicazione in modo che si estenda su più Regioni AWS. L'implementazione di una strategia multi-regione per il tuo carico di lavoro aiuta a proteggerlo da disastri naturali diffusi che colpiscono un'ampia regione geografica di un paese o da guasti tecnici di portata regionale. Tieni presente che l'implementazione di un'architettura multi-regione può essere molto complessa e di solito non è necessaria per la maggior parte dei carichi di lavoro. Per ulteriori informazioni, consulta [REL10-BP02 Selezione delle posizioni appropriate per la tua implementazione multiposizione](rel_fault_isolation_select_location.md). 

1.  **Implementazione del codice**: una strategia di implementazione scaglionata del codice è preferibile rispetto all'implementazione di modifiche del codice a tutte le celle contemporaneamente. 
   +  In questo modo, è possibile ridurre al minimo eventuali errori in più celle a causa di un'implementazione non corretta o dell'errore umano. Per ulteriori informazioni, consulta [Automatizzazione di implementazioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/). 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL07-BP04 Esecuzione di un test di carico sul carico di lavoro](rel_adapt_to_changes_load_tested_adapt.md) 
+  [REL10-BP02 Selezione delle posizioni appropriate per la tua implementazione multiposizione](rel_fault_isolation_select_location.md) 

 **Documenti correlati:** 
+  [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+ [AWS e compartimentazione ](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [Isolamento del carico di lavoro tramite sharding casuale](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+  [Automatizzazione di implementazioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 

 **Video correlati:** 
+ [AWS re:Invent 2018: Cicli chiusi e menti aperte: come assumere il controllo di sistemi grandi e piccoli ](https://www.youtube.com/watch?v=O8xLxNje30M)
+  [AWS re:Invent 2018: AWS riduce al minimo il raggio di esplosione degli errori (ARC338)](https://youtu.be/swQbA4zub20) 
+  [Partizionamento casuale: AWS re:Invent 2019: Introduzione alla Libreria dei costruttori di Amazon (DOP328)](https://youtu.be/sKRdemSirDM?t=1373) 
+ [AWS Summit ANZ 2021:Gli errori si verificano sempre e ovunque: una progettazione per la resilienza ](https://www.youtube.com/watch?v=wUzSeSfu1XA)

 **Esempi correlati:** 
+  [Well-Architected Lab: Isolamento degli errori con il partizionamento casuale](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/) 

# REL 11. Come si progetta il carico di lavoro affinché resista ai guasti dei componenti?
<a name="rel-11"></a>

I carichi di lavoro con requisiti di disponibilità elevata e MTTR (Mean Time To Recovery) basso devono essere progettati per garantire la resilienza.

**Topics**
+ [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Failover e passaggio a risorse integre](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità](rel_withstand_component_failures_notifications_sent_system.md)
+ [REL11-BP07 Progettazione del prodotto in modo da soddisfare gli obiettivi di disponibilità e i contratti sul livello di servizio per i tempi di attività](rel_withstand_component_failures_service_level_agreements.md)

# REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti
<a name="rel_withstand_component_failures_monitoring_health"></a>

 Monitora costantemente lo stato del carico di lavoro, in modo che tu e i tuoi sistemi automatizzati siate consapevoli di errori o guasti non appena si verificano. Monitora gli indicatori chiave di prestazioni (KPI) in base al valore aziendale. 

 Tutti i meccanismi di ripristino e correzione devono essere in grado di rilevare rapidamente i problemi. I guasti tecnici devono essere rilevati prima in modo che possano essere risolti. Tuttavia, la disponibilità si basa sulla capacità del carico di lavoro di fornire valore aziendale, quindi gli indicatori chiave di prestazione (KPI) che misurano questo aspetto devono far parte della strategia di rilevamento e correzione. 

 **Risultato desiderato:** I componenti essenziali di un carico di lavoro vengono monitorati in modo indipendente per rilevare guasti e fornire avvisi quando e dove si verificano. 

 **Anti-pattern comuni:** 
+  Non sono stati configurati allarmi, pertanto le interruzioni si verificano senza notifica. 
+  Gli allarmi esistono, ma a soglie che non forniscono tempo adeguato per reagire. 
+  I parametri non vengono raccolti abbastanza spesso da soddisfare l'obiettivo di tempo di ripristino (RTO, recovery time objective). 
+  Solo le interfacce del carico di lavoro rivolte al cliente vengono monitorate attivamente. 
+  Viene effettuata solo la raccolta di parametri tecnici, senza includere quelli delle funzioni aziendali. 
+  Non è presente alcun parametro che misuri l'esperienza utente del carico di lavoro. 
+  Vengono creati troppi monitoraggi. 

 **Vantaggi dell'adozione di questa best practice:** Eseguire un monitoraggio appropriato a tutti i livelli consente di ridurre i tempi di rilevamento, velocizzando quindi il ripristino. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Identifica tutti i carichi di lavoro che verranno esaminati per il monitoraggio. Dopo aver identificato tutti i componenti del carico di lavoro da monitorare, devi determinare l'intervallo di monitoraggio. L'intervallo di monitoraggio ha un impatto diretto sulla velocità con cui il ripristino viene avviato, che dipende dal tempo impiegato per rilevare un errore. Il tempo medio di rilevamento (MTTD) è il tempo che intercorre tra il verificarsi di un guasto e l'inizio delle operazioni di riparazione. L'elenco dei servizi deve essere ampio e completo. 

 Il monitoraggio deve includere tutti i livelli dello stack applicativo, come applicazione, piattaforma, infrastruttura e rete. 

 La strategia di monitoraggio deve tenere in considerazione l'impatto di *guasti nell'area grigia*. Per ulteriori dettagli sui guasti nell'area grigia, consulta [ il whitepaper Gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) in the Advanced Multi-AZ Resilience Patterns 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  L'intervallo di monitoraggio dipende dalla velocità con cui è necessario ripristinare Il tempo di ripristino dipende dal tempo necessario a ripristinare, perciò è necessario determinare la frequenza della raccolta considerando tale tempo e l'obiettivo di tempo di ripristino (RTO, recovery time objective). 
+  Configura il monitoraggio dettagliato per componenti e servizi gestiti. 
  +  Determina se [il monitoraggio dettagliato per le istanze EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) e [Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) è necessario. Il monitoraggio dettagliato fornisce metriche a intervalli di un minuto, mentre il monitoraggio predefinito fornisce metriche a intervalli di cinque minuti. 
  +  Determina se [il monitoraggio avanzato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) per RDS è necessario. Il monitoraggio avanzato utilizza un agente sulle istanze RDS per ottenere informazioni utili su diversi processi o thread. 
  +  Determina i requisiti di monitoraggio dei componenti serverless critici per [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html), [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html), [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html), [Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs)e tutti i tipi di [sistema di bilanciamento del carico](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html). 
  +  Determina i requisiti di monitoraggio dei componenti di archiviazione per [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html), [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html), [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html)e [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html). 
+  Crea [metriche personalizzate](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) per misurare gli indicatori di prestazione (KPI) fondamentali per il tuo business. I carichi di lavoro implementano funzioni aziendali fondamentali, che devono essere utilizzate come KPI che aiutano a identificare quando si verifica un problema indiretto. 
+  Monitoraggio della presenza di errori nell'esperienza utente tramite le canary degli utenti [Test delle transazioni sintetiche](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (noto anche come test canary, ma da non confondere con l'implementazione canary) è uno dei processi di test più importanti in quanto è in grado di eseguire e simulare il comportamento dei clienti. Esegui questi test costantemente sugli endpoint del carico di lavoro da diverse posizioni remote. 
+  Crea [metriche personalizzate](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) che monitorino l'esperienza dell'utente. Dotare l'esperienza del cliente di strumenti consente di determinare quando essa peggiora. 
+  [Imposta allarmi](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) per rilevare quando una qualsiasi parte del carico di lavoro non funziona correttamente e per indicare quando dimensionare automaticamente le risorse. È possibile mostrare visivamente gli allarmi sulle dashboard, inviarli tramite Amazon SNS o e-mail e utilizzarli con Auto Scaling per aumentare o ridurre le risorse del carico di lavoro. 
+  Crea [dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) per visualizzare le metriche. Utilizza le dashboard per visualizzare tendenze, valori anomali e altri indicatori di potenziali problemi, oppure per fornire un'indicazione dei problemi che potresti voler approfondire. 
+  Crea [il monitoraggio del tracciamento distribuito](https://aws.amazon.com/xray/faqs/) per i tuoi servizi. Con il monitoraggio distribuito puoi comprendere le prestazioni della tua applicazione e dei relativi servizi sottostanti per identificare e risolvere la causa ultima di problemi ed errori riguardanti le prestazioni. 
+  Utilizza [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) oppure [X-Ray](https://aws.amazon.com/xray/faqs/)per creare dashboard di sistemi di monitoraggio e di raccolta dati in una regione e in un account separati. 
+  Crea l'integrazione per [Amazon Health Aware](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) per consentire il monitoraggio della visibilità sulle risorse AWS che potrebbero presentare un deterioramento. Per i carichi di lavoro aziendali essenziali, questa soluzione fornisce l'accesso ad avvisi proattivi e in tempo reale per i servizi AWS. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [Definizione di disponibilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 

 **Documenti correlati:** 
+  [Amazon CloudWatch Synthetics consente di creare i Canary dell'utente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [Abilitare o disabilitare il monitoraggio dettagliato della propria istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) 
+  [Monitoraggio avanzato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) 
+  [Monitoring Your Auto Scaling Groups and Instances Using Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) 
+  [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Using CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Using Cross Region Cross Account CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) 
+  [Using Cross Region Cross Account X-Ray Tracing](https://aws.amazon.com/xray/faqs/) 
+  [Understanding availability](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html) 
+  [Implementing Amazon Health Aware (AHA)](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) 

 **Video correlati:** 
+  [Mitigating gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) 

 **Esempi correlati:** 
+  [Well-Architected Lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html) 
+  [One Observability Workshop: Explore X-Ray](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray) 

 **Strumenti correlati:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP02 Failover e passaggio a risorse integre
<a name="rel_withstand_component_failures_failover2good"></a>

 Se si verifica un errore in una risorsa, le risorse integre dovrebbero continuare a soddisfare le richieste. Per posizioni compromesse (ad esempio una zona di disponibilità o una Regione AWS), assicurati di disporre di sistemi che possano eseguire il failover e passare a risorse integre in posizioni non danneggiate. 

 Durante la progettazione di un servizio, distribuisci il carico tra risorse, zone di disponibilità o regioni. Pertanto, il guasto o la compromissione di una singola risorsa può essere mitigato spostando il traffico sulle risorse integre rimanenti. Considera come vengono rilevati e indirizzati i servizi in caso di guasto. 

 Progetta i tuoi servizi tenendo a mente il recupero dai guasti. In AWS, progettiamo servizi per ridurre al minimo i tempi di recupero da guasti e l'impatto sui dati. I nostri servizi utilizzano principalmente archivi di dati che riconoscono le richieste solo dopo che queste sono state archiviate in modo duraturo su più repliche in una Regione. Sono costruiti con il criterio dell'isolamento basato sulle celle ed utilizzano l'isolamento dei guasti fornito dalle zone di disponibilità. Facciamo ampio uso dell'automazione nelle nostre procedure operative. Ottimizziamo anche la nostra funzionalità di sostituzione e riavvio per un ripristino rapidamente dalle interruzioni. 

 I modelli e i progetti che consentono il failover variano a seconda dei servizi della AWS. Molti servizi AWS gestiti nativi si trovano in più zone di disponibilità (come Lambda oAPI Gateway) in modo nativo. Altri servizi AWS (come EC2 ed EKS) richiedono procedure ottimali specifiche per supportare il failover delle risorse o l'archiviazione di dati tra le zone di disponibilità. 

 Il monitoraggio deve essere impostato per verificare che la risorsa di failover sia integra, tenere traccia dell'avanzamento del failover delle risorse e monitorare il ripristino dei processi aziendali. 

 **Risultato desiderato:** I sistemi sono in grado di utilizzare automaticamente o manualmente nuove risorse per il ripristino dopo un evento di deterioramento. 

 **Anti-pattern comuni:** 
+  La pianificazione degli errori non fa parte della fase di pianificazione e progettazione. 
+  L'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO) non sono stabiliti. 
+  Monitoraggio insufficiente per rilevare risorse difettose. 
+  Isolamento adeguato dei domini di errore. 
+  Il failover multi-regione non è considerato. 
+  Il rilevamento dei guasti è troppo sensibile o aggressivo quando si decide di eseguire il failover. 
+  Non è possibile testare o convalidare il progetto di failover. 
+  Esecuzione dell'automazione del risanamento automatico, ma senza la notifica della necessità di una correzione. 
+  Mancanza di un periodo di mitigazione per evitare che l'errore si ripresenti troppo presto. 

 **Vantaggi dell'adozione di questa best practice:** È possibile creare sistemi più resilienti che mantengano l'affidabilità in caso di guasti eseguendo prima un deterioramento lento e poi un ripristino rapido. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I servizi AWS, come [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) e [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html), aiutano a distribuire il carico tra risorse e zone di disponibilità. Pertanto, il guasto di una singola risorsa (come un'istanza EC2) o la compromissione di una zona di disponibilità possono essere mitigati spostando il traffico sulle risorse integre rimanenti. 

 Per i carichi di lavoro multi-regione, i progetti sono più complicati. Ad esempio, le repliche di lettura multi-regione consentono di implementare i dati su Regioni AWS multiple. Tuttavia, il failover è ancora necessario per promuovere la replica di lettura a principale e quindi indirizzare il traffico verso il nuovo endpoint. Amazon Route 53, Route 53 ARC, CloudFront e AWS Global Accelerator possono aiutare a instradare il traffico tra le Regioni AWS. 

 Servizi AWS come Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge o Amazon DynamoDB vengono implementati automaticamente in più zone di disponibilità da AWS. In caso di guasto, questi servizi AWS instradano automaticamente il traffico verso posizioni integre. I dati sono archiviati in modo ridondante in più zone di disponibilità e rimangono disponibili. 

 Per Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon EKS o Amazon ECS, l'implementazione Multi-AZ è un'opzione di configurazione. AWS può indirizzare il traffico verso l'istanza integra se viene avviato il failover. Questa azione di failover può essere intrapresa direttamente da AWS o su richiesta del cliente. 

 Per istanze Amazon EC2, Amazon Redshift, attività Amazon ECS o pod Amazon EKS, sei tu a scegliere in quali zone di disponibilità eseguire la distribuzione. Per alcuni progetti, Elastic Load Balancing fornisce la soluzione per rilevare istanze in zone corrotte e instradare il traffico verso quelle integre. Elastic Load Balancing può anche indirizzare il traffico verso i componenti del data center on-premise. 

 Per il failover del traffico multi-regione, il reindirizzamento può sfruttare Amazon Route 53, ARC, AWS Global Accelerator, Route 53 Private DNS for VPCs o CloudFront per fornire una modalità per definire domini Internet e assegnare policy di routing, compresi i controlli dell'integrità, per instradare il traffico verso regioni integre. AWS Global Accelerator fornisce indirizzi IP statici che operano come punto di ingresso fisso all'applicazione, che indirizzano il traffico verso gli endpoint delle Regioni AWS di tua scelta utilizzando la rete AWS globale anziché Internet per prestazioni e affidabilità migliori. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Crea progetti di failover per tutte le applicazioni e i servizi appropriati. Isola ogni componente dell'architettura e crea progetti di failover che soddisfino l'RTO e l'RPO per ogni componente. 
+  Configura ambienti inferiori (come sviluppo o test) con tutti i servizi necessari per disporre di un piano di failover. Implementa le soluzioni utilizzando l'infrastruttura come codice (IaC) per garantire la ripetibilità. 
+  Configura un sito di ripristino, ad esempio una seconda regione, per implementare e testare i progetti di failover. Se necessario, le risorse per i test possono essere configurate temporaneamente per limitare i costi aggiuntivi. 
+  Determina quali piani di failover sono automatizzati da AWS, quali possono essere automatizzati da un processo DevOps e quali possono essere manuali. Documenta e misura l'RTO e l'RPO di ogni servizio. 
+  Crea un playbook per il failover e includi tutti i passaggi necessari per eseguire il failover di ogni risorsa, applicazione e servizio. 
+  Crea un playbook di failback e includi tutti i passaggi per eseguire il failback (con tempistiche) di ogni risorsa, applicazione e servizio. 
+  Crea un piano per avviare e testare il playbook. Usa simulazioni e test del caos per testare i passaggi e l'automazione del playbook. 
+  Per posizioni compromesse (ad esempio una zona di disponibilità o una Regione AWS), assicurati di disporre di sistemi che possano eseguire il failover e passare a risorse integre in posizioni non danneggiate. Verifica la quota, i livelli di dimensionamento automatico e le risorse in esecuzione prima dei test di failover. 

## Risorse
<a name="resources"></a>

 **Best practice Well-Architected correlate:** 
+  [REL13- Pianificazione per il disaster recovery (DR)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) 
+  [REL10 - Utilizzo dell'isolamento dei guasti per proteggere il carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) 

 **Documenti correlati:** 
+  [Setting RTO and RPO Targets](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/) 
+  [Set up ARC with application loadbalancers](https://www.wellarchitectedlabs.com/reliability/disaster-recovery/workshop_5/) 
+  [Failover using Route 53 Weighted routing](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack) 
+  [DR with ARC](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/) 
+  [EC2 with autoscaling](https://github.com/adriaanbd/aws-asg-ecs-starter) 
+  [EC2 Deployments - Multi-AZ](https://github.com/awsdocs/amazon-ec2-auto-scaling-user-) 
+  [ECS Deployments - Multi-AZ](https://github.com/aws-samples/ecs-refarch-cloudformation) 
+  [Switch traffic using ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.failover-different-accounts.html) 
+  [Lambda with an Application Load Balancer and Failover](https://docs.aws.amazon.com/lambda/latest/dg/services-alb.html) 
+  [ACM Replication and Failover](https://github.com/aws-samples/amazon-ecr-cross-region-replication) 
+  [Parameter Store Replication and Failover](https://medium.com/devops-techable/how-to-design-an-ssm-parameter-store-for-multi-region-replication-support-aws-infrastructure-db7388be454d) 
+  [ECR cross region replication and Failover](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-settings-configure.html) 
+  [Secrets manager cross region replication configuration](https://disaster-recovery.workshop.aws/en/labs/basics/secrets-manager.html) 
+  [Enable cross region replication for EFS and Failover](https://aws.amazon.com/blogs/aws/new-replication-for-amazon-elastic-file-system-efs/) 
+  [EFS Cross Region Replication and Failover](https://aws.amazon.com/blogs/storage/transferring-file-data-across-aws-regions-and-accounts-using-aws-datasync/) 
+  [Networking Failover](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/aws-dx-dxgw-with-vgw-multi-regions-and-aws-public-peering.html) 
+  [S3 Endpoint failover using MRAP](https://catalog.workshops.aws/s3multiregionaccesspoints/en-US/0-setup/1-review-mrap) 
+  [Crea una replica tra regioni per S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) 
+  [Failover Regional API Gateway with ARC](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjat_TNvev_AhVLlokEHaUeDSUQFnoECAYQAQ&url=https%3A%2F%2Fd1.awsstatic.com%2Fsolutions%2Fguidance%2Farchitecture-diagrams%2Fcross-region-failover-and-graceful-failback-on-aws.pdf&usg=AOvVaw0czthdzWiGlN9I-Dt0lAu3&opi=89978449) 
+  [Failover using multi-region global accelerator](https://aws.amazon.com/blogs/networking-and-content-delivery/deploying-multi-region-applications-in-aws-using-aws-global-accelerator/) 
+  [Failover with DRS](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html) 
+  [Creating Disaster Recovery Mechanisms Using Amazon Route 53](https://amazon.awsapps.com/workdocs/index.html#/document/2501b1ab648225c2d50ab420c4626ef143834fd0d646978629e5ea4e9b8f014b) 

 **Esempi correlati:** 
+  [Disaster Recovery on AWS](https://disaster-recovery.workshop.aws/en/) 
+  [Elastic Disaster Recovery on AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/080af3a5-623d-4147-934d-c8d17daba346/en-US) 

# REL11-BP03 Automatizzazione della riparazione a tutti i livelli
<a name="rel_withstand_component_failures_auto_healing_system"></a>

 Al rilevamento di un guasto, utilizza funzionalità automatizzate per eseguire azioni da correggere. I guasti possono essere riparati automaticamente tramite meccanismi di servizio interni oppure riavviando o rimuovendo le risorse tramite azioni correttive. 

 Per applicazioni gestite dal cliente e per il ripristino tra regioni, è possibile attingere a modelli di ripristino e processi di riparazione automatizzati dalle [best practice esistenti](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/). 

 La possibilità di riavviare o rimuovere una risorsa è uno strumento importante per risolvere i guasti. Una best practice consiste nel rendere i servizi stateless, ove possibile. In questo modo si evita la perdita di dati o di disponibilità durante il riavvio della risorsa. Nel cloud è possibile, e in genere si dovrebbe, sostituire l'intera risorsa (ad esempio, un'istanza di calcolo o una funzione serverless) come parte del riavvio. Il riavvio stesso è un modo semplice e affidabile per eseguire il ripristino in caso di guasto. Molti tipi diversi di guasto si verificano nei carichi di lavoro. Possono verificarsi guasti a livello di hardware, software, comunicazione e operazioni. 

 Il riavvio o i nuovi tentativi come pratiche risolutive si applicano anche alle richieste di rete. Adotta lo stesso approccio di ripristino sia a un timeout di rete sia a un guasto di dipendenza in cui la dipendenza restituisce un guasto. Entrambi gli eventi hanno un effetto simile sul sistema, quindi piuttosto che tentare di trasformare entrambi gli eventi in un caso speciale, adotta una strategia analoga di nuovi tentativi limitati con un backoff e un jitter esponenziali. La capacità di riavvio è un meccanismo di ripristino presente nelle architetture di cluster ROC (Recovery-oriented computing) e ad alta disponibilità. 

 **Risultato desiderato:** Vengono eseguite azioni automatiche di risoluzione a seguito del rilevamento di un errore. 

 **Anti-pattern comuni:** 
+  Provisioning di risorse senza dimensionamento automatico. 
+  Implementazione individuale di applicazioni in istanze/container. 
+  Distribuzione di applicazioni che non possono essere distribuite in più posizioni senza utilizzare il ripristino automatico. 
+  Riparazione manuale delle applicazioni che il dimensionamento e il ripristino automatici non sono stati in grado di riparare. 
+  Nessuna automazione dei database di failover. 
+  Mancanza di metodi automatizzati per reinstradare il traffico verso nuovi endpoint. 
+  Nessuna replica dell'archiviazione. 

 **Vantaggi dell'adozione di questa best practice:** La riparazione automatica può ridurre il tempo medio di ripristino e migliorare la disponibilità. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I progetti per Amazon EKS o altri servizi Kubernetes devono includere il numero minimo e massimo di repliche o di stateful set e la dimensione minima dei cluster e dei gruppi di nodi. Questi meccanismi forniscono una quantità minima di risorse di elaborazione continuamente disponibili mentre riparano automaticamente eventuali guasti utilizzando il piano di controllo Kubernetes. 

 I modelli di progettazione a cui si accede tramite un sistema di bilanciamento del carico che utilizza cluster di calcolo dovrebbero sfruttare i gruppi Auto Scaling. Elastic Load Balancing (ELB) distribuisce automaticamente il traffico delle applicazioni in entrata su più destinazioni e applicazioni virtuali in una o più zone di disponibilità (AZ). 

 I progetti basati su cluster computing che non utilizzano il bilanciamento del carico devono avere dimensioni progettate per la perdita di almeno un nodo. Ciò consentirà al servizio di rimanere in esecuzione con una capacità potenzialmente ridotta durante il ripristino di un nuovo nodo. Servizi di esempio sono Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK e Amazon OpenSearch Service. Molti di questi servizi possono essere progettati con funzionalità di riparazione automatica aggiuntive. Alcune tecnologie di cluster devono generare un avviso in caso di perdita di un nodo attivando un flusso di lavoro automatico o manuale per creare un nuovo nodo. È possibile automatizzare questo flusso di lavoro utilizzando AWS Systems Manager per risolvere rapidamente i problemi. 

 Amazon EventBridge può essere utilizzato per monitorare e filtrare eventi come allarmi CloudWatch o cambiamenti di stato in altri servizi AWS. In base alle informazioni sugli eventi, può quindi richiamare AWS Lambda, Systems Manager Automation o altre destinazioni per eseguire una logica di riparazione personalizzata sul carico di lavoro. È possibile configurare Amazon EC2 Auto Scaling per verificare lo stato delle istanze EC2. Se l'istanza è in uno stato diverso da quello in esecuzione o se lo stato del sistema è danneggiato, Amazon EC2 Auto Scaling considera l'istanza come non integra e ne avvia una sostitutiva. Per le sostituzioni su larga scala (ad esempio la perdita di un'intera zona di disponibilità), è preferibile adottare la stabilità statica per ottenere un'elevata disponibilità. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Utilizza gruppi di Auto Scaling per distribuire livelli in un carico di lavoro. [Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) è in grado di eseguire il risanamento automatico sulle applicazioni stateless e aggiungere o rimuovere capacità. 
+  Per le istanze di calcolo indicate in precedenza, usa [il bilanciamento del carico](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) e scegli il tipo di sistema di bilanciamento del carico appropriato. 
+  Considera l'opzione della riparazione per Amazon RDS. Con le istanze di standby, configura il [failover automatico](https://repost.aws/questions/QU4DYhqh2yQGGmjE_x0ylBYg/what-happens-after-failover-in-rds) verso l'istanza di standby. Per le repliche in lettura Amazon RDS, è necessario un flusso di lavoro automatizzato per rendere primaria una replica di lettura. 
+  Implementa [il ripristino automatico su istanze EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) che includono applicazioni distribuite non implementabili in più sedi e che possono tollerare il riavvio in caso di guasto. Il ripristino automatico può essere utilizzato per sostituire l'hardware guasto e riavviare l'istanza quando l'applicazione non è in grado di essere distribuita in più posizioni. I metadati dell'istanza e gli indirizzi IP associati vengono conservati, così come i [volumi EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) e i punti di montaggio su [Amazon Elastic File System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) o [i file system per Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) e [Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html). Utilizzando [AWS OpsWorks](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)puoi configurare la riparazione automatica delle istanze EC2 a livello del layer. 
+  Implementa il ripristino automatico utilizzando [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) e [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) quando non è possibile utilizzare il dimensionamento automatico o il ripristino automatico o quando il ripristino automatico non va a buon fine. Quando non puoi utilizzare il dimensionamento automatico né il ripristino automatico o il ripristino automatico non riesce, puoi automatizzare la riparazione utilizzando AWS Step Functions e AWS Lambda. 
+  [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) può essere usato per monitorare e filtrare eventi come [avvisi CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) o cambiamenti di stato in altri servizi AWS. In base alle informazioni sugli eventi, può quindi richiamare AWS Lambda (o altre destinazioni) per eseguire una logica di riparazione personalizzata sul tuo carico di lavoro. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [Definizione di disponibilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 

 **Documenti correlati:** 
+  [Come funziona AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [Ripristino automatico Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) 
+  [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) 
+  [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html) 
+  [What is Amazon FSx for Lustre?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) 
+  [What is Amazon FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) 
+  [AWS OpsWorks: utilizzare il ripristino automatico per sostituire le istanze in errore](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html) 
+  [Che cos'è AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 
+  [Che cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 
+  [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Amazon RDS Failover](https://d1.awsstatic.com/rdsImages/IG1_RDS1_AvailabilityDurability_Final.pdf) 
+  [SSM - Systems Manager Automation](https://docs.aws.amazon.com/resilience-hub/latest/userguide/integrate-ssm.html) 
+  [Resilient Architecture Best Practices](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/) 

 **Video correlati:** 
+  [Automatically Provision and Scale OpenSearch Service](https://www.youtube.com/watch?v=GPQKetORzmE) 
+  [Amazon RDS Failover Automatically](https://www.youtube.com/watch?v=Mu7fgHOzOn0) 

 **Esempi correlati:** 
+  [Workshop su Auto Scaling](https://catalog.workshops.aws/general-immersionday/en-US/advanced-modules/compute/auto-scaling) 
+  [Workshop su Amazon RDS Failover](https://catalog.workshops.aws/resilient-apps/en-US/rds-multi-availability-zone/failover-db-instance) 

 **Strumenti correlati:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino
<a name="rel_withstand_component_failures_avoid_control_plane"></a>

 I piani di controllo forniscono le API amministrative utilizzate per creare, leggere e descrivere, aggiornare, eliminare ed elencare (CRUDL) risorse, mentre i piani di dati gestiscono il traffico quotidiano del servizio. Durante l'implementazione di risposte di ripristino o mitigazione a eventi che possono influire sulla resilienza, concentrati sull'utilizzo di un numero minimo di operazioni del piano di controllo per ripristinare, ridimensionare, ristabilire, riparare il servizio o eseguirne il failover. Le operazioni del piano dati dovrebbero avere la precedenza su qualsiasi attività durante questi eventi che causano deterioramento. 

 Ad esempio, le seguenti sono tutte azioni del piano di controllo: avvio di una nuova istanza di calcolo, creazione di storage a blocchi e descrizione dei servizi di coda. Quando avvii istanze di calcolo, il piano di controllo deve eseguire diverse attività, come trovare un host fisico con capacità, allocare interfacce di rete, preparare volumi di storage a blocchi locali, generare credenziali e aggiungere regole di sicurezza. I piani di controllo tendono ad avere un'orchestrazione complicata. 

 **Risultato desiderato:** Quando lo stato di risorsa viene compromesso, il sistema è in grado di ripristinarsi automaticamente o manualmente spostando il traffico da risorse danneggiate a risorse integre. 

 **Anti-pattern comuni:** 
+  Dipendenza dalla modifica dei record DNS per reindirizzare il traffico. 
+  Dipendenza dalle operazioni di dimensionamento del piano di controllo per sostituire i componenti danneggiati a causa di un provisioning delle risorse insufficiente. 
+  Affidarsi ad azioni intense, multiservizio e multi-API del piano di controllo per porre rimedio a qualsiasi categoria di deterioramento. 

 **Vantaggi dell'adozione di questa best practice:** Una maggiore percentuale di successo in termini di riparazione automatica può ridurre il tempo medio di ripristino e migliorare la disponibilità del carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio: per determinati tipi di deterioramento del servizio, vengono compromessi i piani di controllo. Le dipendenze dall'uso intenso del piano di controllo per la riparazione possono aumentare il tempo di ripristino (RTO) e il tempo medio di ripristino (MTTR). 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per limitare le azioni del piano dati, esegui una valutazione servizio per servizio per determinare le azioni necessarie per ripristinarlo. 

 Sfrutta Amazon Application Recovery Controller (ARC) per spostare il traffico DNS. Queste funzionalità monitorano continuamente la capacità dell'applicazione di ristabilirsi dai guasti e consentono di controllarne il ripristino su più Regioni AWS, zone di disponibilità e on-premise. 

 Le policy di instradamento di Route 53 utilizzano il piano di controllo, quindi non fare affidamento su di esso per il ripristino. I piani dati di Route 53 rispondono alle query DNS ed eseguono e valutano i controlli di integrità. Sono distribuiti a livello globale e progettati per un [accordo sul livello di servizio (SLA) con disponibilità al 100%](https://aws.amazon.com/route53/sla/). 

 Le API e la console di gestione di Route 53, dove si creano, aggiornano ed eliminano le risorse di Route 53, funzionano su piani di controllo progettati per privilegiare la forte coerenza e la durata necessarie per la gestione del DNS. A tal fine, i piani di controllo sono situati in un'unica regione: Stati Uniti orientali (Virginia settentrionale). Sebbene entrambi i sistemi siano costruiti per essere molto affidabili, i piani di controllo non sono inclusi nello SLA. Possono verificarsi eventi rari in cui la progettazione resiliente del piano dati consente di mantenere la disponibilità mentre i piani di controllo non lo fanno. Per i meccanismi di ripristino di emergenza e failover, utilizzare le funzioni del piano dati per garantire la migliore affidabilità possibile. 

 Per Amazon EC2, utilizzare progetti di stabilità statica per limitare le azioni del piano di controllo. Le azioni del piano di controllo includono l'aumento delle risorse, in maniera individuale o utilizzando gruppi Auto Scaling (ASG). Per ottenere i massimi livelli di resilienza, è necessario fornire una capacità sufficiente nel cluster utilizzato per il failover. Se è necessario limitare questa soglia di capacità, imposta acceleratori sull'intero sistema end-to-end per limitare in modo sicuro il traffico totale che raggiunge il set limitato di risorse. 

 L'utilizzo di servizi come Amazon DynamoDB, Amazon API Gateway, sistemi di bilanciamento del carico e AWS Lambda serverless avviene sfruttando il piano dati. Tuttavia, la creazione di nuove funzioni, sistemi di bilanciamento del carico, gateway API o tabelle DynamoDB è un'azione del piano di controllo e deve essere completata prima del deterioramento come preparazione a un evento e test delle azioni di failover. Per Amazon RDS, le azioni del piano dati consentono l'accesso ai dati. 

 Per ulteriori informazioni sui piani dati, sui piani di controllo e su come AWS costruisce i servizi per soddisfare gli obiettivi di alta disponibilità, consulta [Stabilità statica utilizzando le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/). 

 Capire quali operazioni sono sul piano dati e quali sul piano di controllo. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Per ogni carico di lavoro che deve essere ripristinato dopo un evento di deterioramento, valuta il runbook di failover, il design ad alta disponibilità, il progetto di riparazione automatica o il piano di ripristino delle risorse HA. Identifica ogni azione che potrebbe essere considerata un'azione del piano di controllo. 

 Prendi in considerazione la possibilità di modificare l'azione di controllo in un'azione del piano dati: 
+  Auto Scaling (piano di controllo) rispetto alle risorse Amazon EC2 predimensionate (piano dati) 
+  Esegui la migrazione verso Lambda e i relativi metodi di dimensionamento (piano dati) oppure verso Amazon EC2 e ASG (piano di controllo) 
+  Valuta qualsiasi progetto utilizzando Kubernetes e considerando la natura delle azioni del piano di controllo. L'aggiunta di pod è un'azione del piano dati in Kubernetes. Le azioni devono limitarsi all'aggiunta di pod e non all'aggiunta di nodi. L'utilizzo [di nodi con provisioning eccessivo](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) è il metodo preferibile per limitare le azioni del piano di controllo 

 Prendi in considerazione approcci alternativi che consentano alle azioni del piano dati di incidere sulla stessa correzione. 
+  Modifica del record di Route 53 (piano di controllo) o ARC (piano dati) 
+ [ Controlli dell'integrità di Route 53 per aggiornamenti più automatizzati ](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)

 Se il servizio è mission critical, prendi in considerazione alcuni servizi in una regione secondaria per consentire più azioni del piano di controllo e del piano dati in una regione non interessata dal problema. 
+  Amazon EC2 Auto Scaling o Amazon EKS in una regione primaria rispetto a Amazon EC2 Auto Scaling o Amazon EKS in una regione secondaria e instradamento del traffico verso una regione secondaria (azione del piano di controllo) 
+  Crea una replica di lettura nella regione secondaria o tenta la stessa azione nella regione principale (azione del piano di controllo) 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [Definizione di disponibilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 

 **Documenti correlati:** 
+  [Partner APN: partner che possono essere d'aiuto con l'automazione della tua tolleranza ai guasti](https://aws.amazon.com/partners/find/results/?keyword=automation) 
+  [Marketplace AWS: prodotti utilizzabili per la tolleranza ai guasti](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) 
+  [The Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) 
+  [API Amazon DynamoDB (piano di controllo e piano dati)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html) 
+  [AWS Lambda Executions](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (suddivise in piano di controllo e piano dati) 
+  [Piano dati di AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html) 
+  [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) 
+  [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) 
+  [Creating Disaster Recovery Mechanisms Using Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) 
+  [Che cos'è il Sistema di controllo Route 53 per il ripristino di applicazioni](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+ [ Piano di controllo e piano dati di Kubernetes ](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)

 **Video correlati:** 
+ [ Back to Basics - Using Static Stability ](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [ Building resilient multi-site workloads using AWS global services ](https://www.youtube.com/watch?v=62ZQHTruBnk)

 **Esempi correlati:** 
+  [Introducing Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/) 
+ [ The Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control ](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [ Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack ](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [ Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack ](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [ Stabilità statica utilizzando le zone di disponibilità ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)

 **Strumenti correlati:** 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)

# REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale
<a name="rel_withstand_component_failures_static_stability"></a>

 I carichi di lavoro devono essere staticamente stabili e funzionare in una singola modalità normale. Il comportamento bimodale si verifica quando il carico di lavoro presenta un comportamento diverso in modalità normale e in modalità di guasto. 

 Ad esempio, ciò potrebbe accadere nel momento in cui si prova a ripristinare un guasto nella zona di disponibilità avviando nuove istanze in una zona di disponibilità diversa. Questo approccio può comportare una risposta bimodale durante una modalità di guasto. È invece necessario creare carichi di lavoro che siano staticamente stabili e operino in una sola modalità. In questo esempio, le nuove istanze avrebbero dovuto essere rese disponibili nella seconda zona di disponibilità già prima del guasto. Questo design staticamente stabile verifica che il carico di lavoro funzioni in una sola modalità. 

 **Risultato desiderato:** i carichi di lavoro non presentano un comportamento bimodale in modalità normale e in modalità di guasto. 

 **Anti-pattern comuni:** 
+  Supporre che le risorse possano sempre essere rese disponibili indipendentemente dall'ambito del guasto. 
+  Tentare di acquisire risorse in modo dinamico durante un guasto. 
+  Non rendere disponibili risorse adeguate tra zone o regioni diverse fino a quando non si verifica un guasto. 
+  Considerare i progetti staticamente stabili solo per risorse di calcolo. 

 **Vantaggi dell'adozione di questa best practice:** I carichi di lavoro eseguiti con progetti staticamente stabili sono in grado di avere risultati prevedibili durante eventi normali e di guasto. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Il comportamento bimodale ha luogo quando il carico di lavoro mostra un comportamento diverso in modalità normale e di guasto, ad esempio facendo affidamento sull'avvio di nuove istanze se una zona di disponibilità presenta un malfunzionamento. Un esempio di comportamento bimodale è quello che si verifica quando design stabili di Amazon EC2 rendono disponibili un numero sufficiente di istanze in ciascuna zona di disponibilità per gestire il carico di lavoro in caso di rimozione di una di tali zone. Elastic Load Balancing o Amazon Route 53 possono effettuare un controllo di integrità per spostare un carico lontano dalle istanze danneggiate. Dopo il trasferimento del traffico, è possibile utilizzare AWS Auto Scaling per sostituire in modo asincrono le istanze della zona interessata dal guasto avviandole nelle zone integre. La stabilità statica per il deployment delle risorse di calcolo (ad esempio istanze EC2 o container) determinerà la massima affidabilità. 

![\[Diagramma che mostra la stabilità statica delle istanze EC2 nelle varie zone di disponibilità\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/static-stability.png)


 Questo approccio deve essere valutato rispetto al costo associato al modello e al valore aziendale attribuito al mantenimento della disponibilità del carico di lavoro in tutti i casi di resilienza. Fornire una minore capacità di elaborazione e affidarsi all'avvio di nuove istanze in caso di guasto è meno costoso. Tuttavia, in caso di guasti su larga scala, come una zona di disponibilità o un problema a livello regionale, tale approccio è meno efficace, perché si basa su un piano operativo e sulla disponibilità di risorse sufficienti nelle zone o nelle regioni non interessate dal problema. 

 La soluzione deve inoltre valutare l'affidabilità rispetto ai costi necessari per il carico di lavoro. Gli approcci che garantiscono la stabilità statica si applicano a una varietà di architetture, tra cui istanze di calcolo distribuite tra zone di disponibilità, progetti di repliche di lettura di database, progetti di cluster Kubernetes (Amazon EKS) e architetture di failover multiregione. 

 È anche possibile implementare un progetto staticamente più stabile utilizzando più risorse in ciascuna zona. Aggiungendo più zone, si riduce la quantità di elaborazione aggiuntiva necessaria per la stabilità statica. 

 Un altro esempio di comportamento bimodale potrebbe derivare da un timeout di rete in grado di causare un tentativo di aggiornamento dello stato di configurazione dell'intero sistema. Ciò potrebbe aggiungere un carico imprevisto su un altro componente che potrebbe quindi generare un errore, innescando ulteriori conseguenze impreviste. Questo loop di feedback negativo influisce sulla disponibilità del carico di lavoro. Al contrario, è possibile creare sistemi che siano staticamente stabili e funzionino in una sola modalità. Un progetto staticamente stabile potrebbe eseguire con continuità un'attività e aggiornare sempre, con cadenza regolare, lo stato della configurazione. Quando una chiamata fallisce, il carico di lavoro può utilizzare il valore precedentemente memorizzato nella cache e segnalare un allarme. 

 Un altro esempio di comportamento bimodale è consentire ai client di bypassare la cache del carico di lavoro quando si verificano dei guasti. Potrebbe sembrare una soluzione che soddisfa le esigenze del client, ma non dovrebbe essere consentita perché modifica in modo significativo le richieste sul carico di lavoro e potrebbe causare dei guasti. 

 Valuta i carichi di lavoro critici per determinare quali carichi di lavoro richiedono questo tipo di progettazione di resilienza. Per quelli considerati critici, deve essere esaminato ogni componente dell'applicazione. Alcuni tipi di servizi che richiedono valutazioni di stabilità statica sono: 
+  **Calcolo**: Amazon EC2, EKS-EC2, ECS-EC2, EMR-EC2 
+  **Database**: Amazon Redshift, Amazon RDS, Amazon Aurora 
+  **Storage**: Amazon S3 (Zona singola), Amazon EFS (supporti), Amazon FSx (supporti) 
+  **Sistemi di bilanciamento del carico:** In base a determinati modelli 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Realizzare sistemi che siano staticamente stabili e operino in una sola modalità. In questo caso, effettuare il provisioning di un numero sufficiente di istanze in ogni zona o regione di disponibilità per gestire la capacità del carico di lavoro qualora venga rimossa una zona o regione di disponibilità. Per l'indirizzamento verso risorse integre è possibile utilizzare una varietà di servizi, come: 
  +  [Cross Region DNS Routinge](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) 
  +  [Routing Amazon S3 multiregionale MRAP](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) 
  +  [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) 
  +  [Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  Configura [repliche di lettura del database](https://aws.amazon.com/rds/features/multi-az/) per tenere conto della perdita di una singola istanza primaria o di una replica di lettura. Se il traffico viene servito da repliche di lettura, la quantità in ogni zona di disponibilità e in ogni regione deve corrispondere al fabbisogno complessivo in caso di guasto della zona o della regione. 
+  Configurare i dati critici nel sistema di archiviazione Amazon S3 progettato per essere staticamente stabile rispetto ai dati archiviati in caso di guasto della zona di disponibilità. Se si verifica un [Se viene utilizzata la classe di archiviazione Amazon S3 One Zone-IA](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) questa non deve essere considerata staticamente stabile, poiché la perdita di tale zona riduce al minimo l'accesso ai dati archiviati. 
+  [I sistemi di bilanciamento del carico](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) sono a volte configurati in modo errato o sono progettati per servire una zona di disponibilità specifica. In questo caso, il progetto staticamente stabile potrebbe consistere nel distribuire un carico di lavoro su più zone di disponibilità seguendo un design più complesso. Il design originale potrebbe essere utilizzato per ridurre il traffico tra zone per motivi di sicurezza, latenza o costi. 

## Risorse
<a name="resources"></a>

 **Best practice Well-Architected correlate:** 
+  [Definizione di disponibilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) 
+  [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html) 

 **Documenti correlati:** 
+  [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) 
+  [The Amazon Builders' Library: Stabilità statica con le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 
+  [Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/appendix-a---partitional-service-guidance.html) 
+  [Stabilità statica utilizzando le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 
+  [Multi-Zone RDS](https://aws.amazon.com/rds/features/multi-az/) 
+  [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/) 
+  [Cross Region DNS Routinge](https://docs.aws.amazon.com/whitepapers/latest/real-time-communication-on-aws/cross-region-dns-based-load-balancing-and-failover.html) 
+  [Routing Amazon S3 multiregionale MRAP](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRequestRouting.html) 
+  [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) 
+  [ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [Amazon S3 a singola zona](https://aws.amazon.com/about-aws/whats-new/2018/04/announcing-s3-one-zone-infrequent-access-a-new-amazon-s3-storage-class/) 
+  [Cross Zone Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html) 

 **Video correlati:** 
+  [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704) 

 **Esempi correlati:** 
+  [The Amazon Builders' Library: Stabilità statica con le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 

# REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità
<a name="rel_withstand_component_failures_notifications_sent_system"></a>

 Le notifiche vengono inviate al rilevamento del superamento delle soglie, anche se l'evento causato dal problema è stato risolto automaticamente. 

 Il ripristino automatizzato consente al carico di lavoro di risultare affidabile. Tuttavia, potrebbe anche nascondere problemi sottostanti che devono essere risolti. Implementa il monitoraggio e gli eventi appropriati in modo da poter rilevare i modelli di problemi, inclusi quelli risolti dalla diagnostica automatica e risolvere così i problemi della causa principale. 

 I sistemi resilienti sono progettati in modo che gli eventi di degrado vengano immediatamente comunicati ai team appropriati. Queste notifiche devono essere inviate tramite uno o più canali di comunicazione. 

 **Risultato desiderato: **Gli avvisi vengono inviati immediatamente ai team operativi quando vengono superate soglie come i tassi di errore, la latenza o altri parametri critici degli indicatori chiave di prestazione (KPI), in modo che questi problemi vengano risolti il prima possibile e l'impatto sugli utenti sia evitato o ridotto al minimo. 

 **Anti-pattern comuni:** 
+  Invio di un numero eccessivo di avvisi. 
+  Invio di avvisi non utilizzabili. 
+  Impostazione di soglie di allarme troppo alte (troppo sensibili) o troppo basse (troppo poco sensibili). 
+  Mancato invio di avvisi per dipendenze esterne. 
+  Non considerando [guasti nell'area grigia](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html) nella progettazione di sistemi di monitoraggio e allarmi. 
+  Eseguire l'automazione del risanamento, ma senza avvisare il team competente che era necessario un intervento di ripristino. 

 **Vantaggi dell'adozione di questa best practice:** Le notifiche di ripristino rendono i team operativi e aziendali consapevoli dei peggioramenti del servizio in modo che possano reagire immediatamente per ridurre al minimo sia il tempo medio di rilevamento (MTTD) che il tempo medio di riparazione (MTTR). Le notifiche degli eventi di ripristino consentono anche di non ignorare i problemi che si verificano di rado. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio. La mancata implementazione di meccanismi di monitoraggio e notifica degli eventi appropriati può comportare l'impossibilità di rilevare i modelli di problemi, compresi quelli risolti mediante la correzione automatica. Un team verrà informato del degrado del sistema solo nel momento in cui gli utenti contattano il servizio clienti o per caso. 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Quando si definisce una strategia di monitoraggio, un allarme attivato è un evento comune. Questo evento dovrebbe contenere un identificatore dell'allarme, lo stato dell'allarme (ad esempio `IN ALLARME` o `OK`) e dettagli su cosa l'ha innescato. In molti casi, è necessario rilevare un evento di allarme e inviare una notifica tramite e-mail. Questo è un esempio di azione su un allarme. La notifica degli allarmi è fondamentale per l'osservabilità, in quanto informa le persone giuste della presenza di un problema. Tuttavia, quando le operazioni eseguite sulla base degli eventi raggiungono un certo grado di maturità nella soluzione di osservabilità, è possibile risolvere automaticamente il problema senza la necessità dell'intervento umano. 

 Una volta stabiliti gli allarmi di monitoraggio dei KPI, è necessario inviare avvisi ai team appropriati quando vengono superate le soglie. Tali avvisi possono essere utilizzati anche per attivare processi automatizzati che tenteranno di porre rimedio al danno o alla compromissione. 

 Per un monitoraggio delle soglie più complesso, è necessario prendere in considerazione gli allarmi compositi. Gli allarmi compositi utilizzano una serie di allarmi di monitoraggio dei KPI per creare un avviso basato sulla logica di business operativa. Gli allarmi CloudWatch possono essere configurati per l'invio di e-mail o per la registrazione di file di log nei sistemi di monitoraggio di terze parti tramite l'integrazione con Amazon SNS o Amazon EventBridge. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 Crea vari tipi di allarmi in base al modo in cui vengono monitorati i carichi di lavoro, ad esempio: 
+  Gli allarmi applicativi vengono utilizzati per rilevare quando una parte del carico di lavoro non funziona correttamente. 
+  [Allarmi infrastrutturali](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) indicano quando dimensionare le risorse. Gli allarmi possono essere visualizzati visivamente sui pannelli di controllo, essere inviati tramite Amazon SNS o tramite e-mail e utilizzati con Auto Scaling per aumentare o diminuire le risorse del carico di lavoro. 
+  Semplice [allarmi statici](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) per monitorare quando una metrica supera una soglia statica per un numero specificato di periodi di valutazione. 
+  [Gli allarmi compositi](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) possono tenere conto di allarmi complessi provenienti da più fonti. 
+  Una volta creato l'allarme è possibile generare eventi di notifica appropriati. Puoi richiamare direttamente una [API Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) per inviare notifiche e collegare qualsiasi automazione per la correzione o la comunicazione. 
+  integra [Amazon Health Aware](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) per consentire il monitoraggio della visibilità sulle risorse AWS che potrebbero presentare un deterioramento. Per i carichi di lavoro aziendali essenziali, questa soluzione fornisce l'accesso ad avvisi proattivi e in tempo reale per i servizi AWS. 

## Risorse
<a name="resources"></a>

 **Best practice Well-Architected correlate:** 
+  [Definizione di disponibilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 

 **Documenti correlati:** 
+  [Creare un allarme CloudWatch basato su una soglia statica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) 
+  [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 
+  [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Amazon Health Aware (AHA)](https://aws.amazon.com/blogs/mt/aws-health-aware-customize-aws-health-alerts-for-organizational-and-personal-aws-accounts/) 
+  [Configurazione degli allarmi compositi di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) 
+  [Cosa c'è di nuovo in AWS Observability at re:Invent 2022](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2022/) 

 **Strumenti correlati:** 
+  [CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html) 

# REL11-BP07 Progettazione del prodotto in modo da soddisfare gli obiettivi di disponibilità e i contratti sul livello di servizio per i tempi di attività
<a name="rel_withstand_component_failures_service_level_agreements"></a>

Progetta il tuo prodotto in modo da soddisfare gli obiettivi di disponibilità e i contratti sul livello di servizio per i tempi di attività. Se pubblichi o accetti privatamente obiettivi di disponibilità o contratti sul livello di servizio per i tempi di attività, verifica che l'architettura e i processi operativi siano progettati in modo da supportarli. 

 **Risultato desiderato:** definizione per ogni applicazione di un obiettivo definito per la disponibilità e di un contratto sul livello di servizio per le metriche di prestazioni, che possono essere monitorati e gestiti per realizzare i risultati aziendali. 

 **Anti-pattern comuni:** 
+  Progettazione e implementazione di carichi di lavoro senza impostare alcun contratto sul livello di servizio. 
+  Impostazione di metriche elevate per il contratto sul livello di servizio senza fondamento logico o requisiti aziendali. 
+  Impostazione di contratti sul livello di servizio senza tenere conto delle dipendenze e dei relativi contratti sul livello di servizio sottostanti. 
+  Progettazione delle applicazioni senza tenere conto del Modello di responsabilità condivisa per la resilienza. 

 **Vantaggi dell'adozione di questa best practice:** la progettazione di applicazioni in base ai principali obiettivi di resilienza ti aiuta a realizzare gli obiettivi aziendali e a soddisfare le aspettative dei clienti. Questi obiettivi orientano un processo di progettazione delle applicazioni in grado di valutare diverse tecnologie e tenere conto di vari compromessi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 La progettazione delle applicazioni deve tenere conto di una serie eterogenea di requisiti derivati da obiettivi aziendali, operativi e finanziari. Nell'ambito dei requisiti operativi, i carichi di lavoro devono avere obiettivi specifici in termini di metriche di resilienza, in modo da poter essere monitorati e supportati correttamente. Le metriche di resilienza non devono essere impostate o derivate dopo l'implementazione del carico di lavoro. Devono invece essere definite durante la fase di progettazione e contribuire a determinare i diversi compromessi e decisioni. 
+  Ogni carico di lavoro deve avere una serie di metriche di resilienza propria. Le metriche possono essere diverse da quelle di altre applicazioni aziendali. 
+  La riduzione delle dipendenze può avere un impatto positivo sulla disponibilità. Per ogni carico di lavoro è necessario considerare le dipendenze e i relativi contratti sul livello di servizio. In generale, seleziona dipendenze con obiettivi di disponibilità uguali o maggiori rispetto agli obiettivi del carico di lavoro. 
+  Prendi in considerazione progettazioni senza integrazioni serrate in modo che il carico di lavoro possa funzionare correttamente anche in caso di dipendenze compromesse, se possibile. 
+  Riduci le dipendenze del piano di controllo (control-plane), in particolare durante un ripristino o un peggioramento delle prestazioni. Valuta le progettazioni staticamente stabili per carichi di lavoro mission critical. Usa il contenimento delle risorse per aumentare la disponibilità delle dipendenze in un carico di lavoro. 
+  La visibilità e la strumentazione sono essenziali per soddisfare i contratti sul livello di servizio attraverso la riduzione del tempo medio di rilevamento (MTTD) e del tempo medio di ripristino (MTTR). 
+  Errori meno frequenti (tempo medio tra guasti, o MTBF, più lungo), tempi di rilevamento degli errori più brevi (MTTD minore) e tempi di riparazione più brevi (MTTR minore) sono i tre fattori usati per migliorare la disponibilità in sistemi distribuiti. 
+  La definizione e l'applicazione di metriche di resilienza per un carico di lavoro sono essenziali per qualsiasi progettazione efficace. Queste progettazioni devono tenere conto dei compromessi introdotti dalla complessità di progettazione, delle dipendenze dei servizi, delle prestazioni, del dimensionamento e dei costi. 

 **Passaggi dell'implementazione** 
+  Esamina e documenta la progettazione del carico di lavoro cercando di rispondere alle domande seguenti: 
  +  Dove vengono usati piani di controllo (control-plane) nel carico di lavoro? 
  +  Come viene implementata la tolleranza ai guasti nel carico di lavoro? 
  +  Quali sono i modelli di progettazione per dimensionamento, scalabilità automatica, ridondanza e componenti a disponibilità elevata? 
  +  Quali sono i requisiti per la coerenza e la disponibilità dei dati? 
  +  Vi sono aspetti da considerare in fatto di contenimento delle risorse o stabilità statica delle risorse? 
  +  Quali sono le dipendenze dei servizi? 
+  Definisci insieme agli stakeholder le metriche per il contratto sul livello di servizio in base all'architettura del carico di lavoro. Tieni conto dei contratti sul livello di servizio di tutte le dipendenze usate dal carico di lavoro. 
+  Una volta definiti gli obiettivi del contratto sul livello di servizio, ottimizza l'architettura in modo da soddisfare il contratto. 
+  Una volta impostata una progettazione che soddisfa il contratto sul livello di servizio, implementa modifiche operative, automazione dei processi e runbook anch'essi incentrati sulla riduzione dell'MTTD e dell'MTTR. 
+  Dopo aver implementato il contratto sul livello di servizio, devi monitorarlo e documentarlo. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos](rel_testing_resiliency_failure_injection_resiliency.md) 
+  [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md) 
+ [Comprendere lo stato del carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)

 **Documenti correlati:** 
+ [ Disponibilità con ridondanza ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [ Principio dell'affidabilità: disponibilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [ Misurazione della disponibilità ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)
+ [ Limiti di isolamento dei guasti di AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [ Modello di responsabilità condivisa per la resilienza ](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [stabilità statica utilizzando le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [ Contratti sul livello di servizio AWS](https://aws.amazon.com/legal/service-level-agreements/)
+ [ Linee guida per le architetture basate su celle su AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)
+ [ Infrastruttura AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [ Whitepaper sui modelli di resilienza multi-AZ avanzati ](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)

 **Servizi correlati:** 
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)

# REL 12. Come si testa l'affidabilità?
<a name="rel-12"></a>

Dopo aver progettato il carico di lavoro in modo da essere resiliente alle sollecitazioni della produzione, i test sono l'unico modo per verificare il funzionamento corretto e offrire la resilienza prevista.

**Topics**
+ [REL12-BP01 Utilizzo dei playbook per analizzare gli errori](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Esecuzione di analisi post-incidente](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Test dei requisiti funzionali](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 Test dei requisiti di dimensionamento e prestazioni](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 Esecuzione regolare di giornate di gioco](rel_testing_resiliency_game_days_resiliency.md)

# REL12-BP01 Utilizzo dei playbook per analizzare gli errori
<a name="rel_testing_resiliency_playbook_resiliency"></a>

 Abilita risposte coerenti e tempestive a scenari di guasto che non sono ben compresi, documentando il processo di analisi nei playbook. I playbook sono le fasi predefinite eseguite per identificare i fattori che contribuiscono a uno scenario di guasto. I risultati provenienti da un passaggio del processo vengono utilizzati per stabilire i passaggi successivi da intraprendere fino all'identificazione o alla risoluzione del problema. 

 Il playbook è una pianificazione proattiva che è necessario eseguire, in modo da potere intraprendere azioni reattive in modo efficace. Quando durante la produzione si verificano scenari di guasto non coperti dal playbook, risolvi innanzitutto il problema (spegni l'incendio). Quindi torna indietro e osserva le fasi intraprese per risolvere il problema e utilizzale per aggiungere una nuova voce al playbook. 

 Tieni presente che i playbook vengono utilizzati in risposta a specifici incidenti, mentre i runbook vengono utilizzati per ottenere esiti specifici. Spesso, i runbook vengono utilizzati per le attività di routine e i playbook vengono utilizzati per rispondere a eventi non di routine. 

 **Anti-pattern comuni:** 
+  Pianificare la distribuzione di un carico di lavoro senza conoscere i processi per diagnosticare i problemi o rispondere agli incidenti. 
+  Decisioni non pianificate sui sistemi da cui raccogliere log e parametri durante l'analisi di un evento. 
+  Non conservare parametri e eventi abbastanza a lungo da poter recuperare i dati. 

 **Vantaggi dell'adozione di questa best practice:** L'acquisizione di playbook garantisce l'esecuzione coerente dei processi. La codifica dei playbook limita l'introduzione di errori derivanti dall'attività manuale. L'automazione dei playbook riduce il tempo necessario per rispondere a un evento eliminando il requisito per l'intervento dei membri del team o fornendo loro informazioni aggiuntive quando inizia l'intervento. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Utilizza playbook per identificare i problemi. I playbook sono processi documentati per eseguire indagini sui problemi. Abilita risposte coerenti e tempestive agli scenari di errore documentando i processi nei playbook. I playbook devono contenere le informazioni e le istruzioni necessarie affinché una persona adeguatamente qualificata possa raccogliere le informazioni applicabili, identificare potenziali fonti di errore, isolare i guasti e stabilire i fattori che contribuiscono all'origine di un problema (eseguire l'analisi post-incidente). 
  +  Implementazione dei playbook come codice. Esegui le operazioni come codice mediante lo scripting dei playbook per assicurare coerenza e ridurre gli errori causati dai processi manuali. I playbook possono essere composti da più script che rappresentano le diverse fasi che potrebbero essere necessarie per identificare i fattori che contribuiscono all'origine di un problema. Le attività dei runbook possono essere attivate o eseguite nell'ambito delle attività dei playbook oppure possono richiedere l'esecuzione di un playbook in risposta agli eventi identificati. 
    +  [Automazione dei playbook operativi con AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) 
    +  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
    +  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
    +  [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 
    +  [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
    +  [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
+  [Automazione dei playbook operativi con AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) 
+  [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 

 **Esempi correlati:** 
+  [Automating operations with Playbooks and Runbooks (Automazione delle operazioni con Playbook e Runbook)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

# REL12-BP02 Esecuzione di analisi post-incidente
<a name="rel_testing_resiliency_rca_resiliency"></a>

 Esamina gli eventi che influiscono sui clienti e identifica i fattori che vi hanno contribuito e gli elementi di azione preventivi. Utilizza queste informazioni per sviluppare modi per limitare o prevenire il ripetersi degli imprevisti. Sviluppa procedure per attivare risposte rapide ed efficaci. Comunica i fattori che hanno contribuito al presentarsi dell'imprevisto e le azioni correttive secondo necessità, specificamente mirate per il pubblico di destinazione. All'occorrenza, adotta un metodo per comunicare queste cause ad altri. 

 Valuta perché i test esistenti non hanno individuato il problema. Aggiungi i test per questo caso se i test non esistono già. 

 **Risultato desiderato: ** i tuoi team hanno un approccio coerente e concordato alla gestione dell'analisi post-incidente. Un meccanismo è il [processo di correzione dell'errore (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/). Il processo COE aiuta i team a individuare, comprendere e gestire le cause principali degli incidenti, creando al contempo meccanismi e guardrail per limitare la probabilità che lo stesso incidente si ripeta. 

 **Anti-pattern comuni:** 
+  Individuare i fattori che hanno contribuito al verificarsi dell'incidente, ma non continuare a cercare in maniera più approfondita altri potenziali problemi e approcci da mitigare. 
+  Identificare le cause degli errori umani senza fornire alcuna formazione o automazione che potrebbe prevenirli. 
+  Concentrarsi sull'attribuzione delle colpe piuttosto che sulla comprensione della causa principale, creando così una cultura della paura e ostacolando la comunicazione costruttiva 
+  Mancata condivisione delle informazioni, che mantiene i risultati dell'analisi degli incidenti all'interno di un gruppo ristretto e impedisce ad altri di beneficiare delle lezioni apprese 
+  Nessun meccanismo che consenta di acquisire le conoscenze formali; in questo modo si perdono informazioni preziose in quanto non vengono preservate le lezioni apprese sotto forma di best practice aggiornate, con il conseguente rischio che gli incidenti si ripetano con la stessa causa principale o causa simile 

 **Vantaggi dell'adozione di questa best practice:** l'esecuzione di analisi post-incidente e la condivisione dei risultati consente ad altri carichi di lavoro di mitigare il rischio se hanno implementato gli stessi fattori che hanno contribuito al verificarsi dell'incidente e consente loro di implementare la mitigazione o il ripristino automatico prima che si verifichi un incidente. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Una buona analisi post-incidente fornisce opportunità per proporre soluzioni comuni a problemi con modelli di architettura utilizzati in altri punti nei tuoi sistemi. 

 Un elemento fondamentale del processo COE è la documentazione e la risoluzione dei problemi. È consigliabile definire un modo standard per documentare le cause principali critiche e assicurarsi che queste vengano esaminate e risolte. Assegna in modo chiaro il responsabile del processo di analisi post-incidente. Designa un team o una persona responsabile della supervisione delle indagini e dei follow-up degli incidenti. 

 Promuovi una cultura basata sull'apprendimento e sul miglioramento piuttosto che sull'attribuzione di colpe. Insisti sul fatto che l'obiettivo è prevenire incidenti futuri e non penalizzare le persone. 

 Sviluppa procedure ben definite per l'esecuzione delle analisi post-incidente. Queste procedure dovrebbero stabilire le misure da adottare, le informazioni da raccogliere e le questioni chiave da risolvere durante l'analisi. Svolgi indagini approfondite sugli incidenti, andando oltre le cause immediate per identificare le cause principali e i fattori determinanti. Usa tecniche come i *[Cinque Perché](https://en.wikipedia.org/wiki/Five_whys)* per analizzare approfonditamente i problemi sottostanti. 

 Mantieni un archivio delle conclusioni derivanti dalle analisi degli incidenti. Queste conoscenze formali possono fungere da riferimento per futuri incidenti e attività di prevenzione. Condividi i risultati e gli approfondimenti delle analisi post-incidente e valuta la possibilità di organizzare riunioni di revisione post-incidente con invito aperto per discutere i risultati e le conclusioni. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Durante l'analisi post-incidente, assicurati che il processo non comporti la colpevolizzazione delle parti coinvolte. Ciò consente alle parti interessate di essere imparziali rispetto delle azioni correttive proposte, nonché di promuovere l'autovalutazione e la collaborazione a livello di team. 
+  Definisci una procedura standardizzata per documentare i problemi critici. Una struttura di esempio per tale documento è la seguente: 
  +  Cosa è successo? 
  +  Quale impatto ha avuto su clienti e attività? 
  +  Qual è stata la causa principale? 
  +  Di quali dati disponi a supporto di questo problema? 
    +  Ad esempio, metriche e grafici 
  +  Quali sono state le principali implicazioni sui pilastri critici, specialmente per quanto riguarda la sicurezza? 
    +  Quando progetti l'architettura dei carichi di lavoro, devi trovare dei compromessi tra i pilastri su cui si regge il contesto aziendale. Questo tipo di decisioni aziendali deve essere alla base delle tue priorità ingegneristiche. Potresti ridurre i costi a spese dell'affidabilità in ambienti di sviluppo oppure, per quanto riguarda le soluzioni mission-critical, potresti ottimizzare l'affidabilità con costi maggiori. La sicurezza ha la massima priorità quando si tratta di proteggere i tuoi clienti. 
  +  Quali lezioni hai imparato? 
  +  Quali azioni correttive stai adottando? 
    +  Azioni correttive 
    +  Articoli correlati 
+  Crea precise procedure operative standard per lo svolgimento delle analisi post-incidente. 
+  Configura un processo standardizzato di segnalazione degli incidenti. Documenta in modo esaustivo tutti gli incidenti, includendo il rapporto iniziale sull'incidente, i log, le comunicazioni e le azioni intraprese durante l'incidente. 
+  Ricorda che un incidente non necessariamente comporta un'interruzione del servizio. Potrebbe trattarsi di un near miss o di un sistema che funziona in modo imprevisto pur continuando a svolgere la sua funzione aziendale. 
+  Migliora continuamente il processo di analisi post-incidente sulla base dei feedback e delle lezioni apprese. 
+  Acquisisci i risultati chiave in un sistema di gestione delle conoscenze e valuta eventuali modelli da aggiungere alle linee guide per gli sviluppatori o alle liste di controllo usate nella fase di pre-implementazione. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Why you should develop a correction of error (COE) (Perché sviluppare una correzione dell'errore)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) 

 **Video correlati:** 
+ [Amazon’s approach to failing successfully](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021 - Amazon Builders’ Library: Operational Excellence at Amazon ](https://www.youtube.com/watch?v=7MrD4VSLC_w)

# REL12-BP03 Test dei requisiti funzionali
<a name="rel_testing_resiliency_test_functional"></a>

 Utilizza tecniche come i test unitari e i test di integrazione per convalidare le funzionalità richieste. 

 Puoi ottenere i migliori risultati quando questi test vengono eseguiti automaticamente come parte delle operazioni di sviluppo e distribuzione. Ad esempio, utilizzando AWS CodePipeline, gli sviluppatori affidano le modifiche a un repository di origine in cui CodePipeline rileva automaticamente le modifiche. Queste modifiche vengono create e vengono eseguiti test. Una volta completati i test, il codice creato viene distribuito ai server temporaneo per il test. Dal server temporaneo, CodePipeline esegue più test, come quelli di integrazione o caricamento. Una volta completati con successo i test, CodePipeline distribuisce il codice testato e approvato alle istanze di produzione. 

 Inoltre, l'esperienza dimostra che i test sintetici delle transazioni (noti anche come *test canary*, ma da non confondere con le implementazioni canary) in grado di eseguire e simulare il comportamento dei clienti sono uno dei processi di test più importanti. Esegui questi test costantemente sugli endpoint del carico di lavoro da diverse posizioni remote. Amazon CloudWatch Synthetics ti consente di [creare "canary"](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) per monitorare gli endpoint e le API. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Test dei requisiti funzionali. Includono test delle unità e test di integrazione che convalidano la funzionalità richiesta. 
  +  [Utilizzo di CodePipeline con AWS CodeBuild per testare il codice ed eseguire compilazioni](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html) 
  +  [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) 
  +  [Distribuzione continua e integrazione continua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html) 
  +  [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
  +  [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner che possono essere d'aiuto nell'implementazione di una pipeline di integrazione continua](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration) 
+  [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild (AWS CodePipeline aggiunge il supporto per i test di unità e integrazione personalizzati con AWS CodeBuild)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/) 
+  [Marketplace AWS: prodotti utilizzabili per l'integrazione continua](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration) 
+  [Distribuzione continua e integrazione continua](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html) 
+  [Automazione e test del software](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation) 
+  [Utilizzo di CodePipeline con AWS CodeBuild per testare il codice ed eseguire compilazioni](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html) 
+  [Utilizzo di Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 

# REL12-BP04 Test dei requisiti di dimensionamento e prestazioni
<a name="rel_testing_resiliency_test_non_functional"></a>

 Utilizza tecniche come i test di carico per convalidare che il carico di lavoro soddisfi i requisiti di dimensionamento e prestazioni. 

 Nel cloud, puoi creare un ambiente di test su scala di produzione on demand per il tuo carico di lavoro. Se esegui questi test su un'infrastruttura ridotta, devi dimensionare i risultati osservati in base a ciò che pensi accadrà in produzione. I test di carico e prestazioni possono essere eseguiti anche in produzione se si fa attenzione a non influire sugli utenti effettivi e si contrassegna con tag i dati di test in modo da non utilizzare dati utente reali e non danneggiare le statistiche di utilizzo o i report di produzione. 

 Con i test, assicurati che le risorse di base, le impostazioni di dimensionamento, le quote di servizio e la progettazione di resilienza funzionino come previsto sotto carico. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Test dei requisiti di dimensionamento e prestazioni. Esegui test del carico per verificare che il carico di lavoro soddisfi i requisiti di dimensionamento e prestazioni. 
  +  [Distributed Load Testing on AWS (Test di carico distribuito su AWS): simula migliaia di utenti connessi](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
  +  [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected) 
    +  Distribuisci la tua applicazione in un ambiente identico al tuo ambiente di produzione ed esegui un test di carico. 
      +  Utilizza un'infrastruttura come code concept per creare un ambiente il più simile possibile al tuo ambiente di produzione. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Distributed Load Testing on AWS (Test di carico distribuito su AWS): simula migliaia di utenti connessi](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
+  [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected) 

# REL12-BP05 Test della resilienza tramite l'utilizzo dell'ingegneria del caos
<a name="rel_testing_resiliency_failure_injection_resiliency"></a>

 Esegui regolarmente esperimenti di ingegneria del caos in ambienti di produzione o per quanto possibile ambienti analoghi per capire in che modo il sistema risponde a condizioni avverse. 

 ** Risultato desiderato: ** 

 La resilienza del carico di lavoro viene regolarmente verificata mediante l'applicazione dell'ingegneria del caos sotto forma di esperimenti di iniezione di errori o di inserimento di carichi imprevisti, nonché mediante il test della resilienza che convalida i comportamenti previsti noti del carico di lavoro durante un evento. Combina l'ingegneria del caos e i test della resilienza per verificare se il carico di lavoro è in grado di superare i guasti dei componenti ed eseguire il ripristino da interruzioni del servizio impreviste con un impatto minimo o nullo. 

 ** Anti-pattern comuni: ** 
+  Progettazione della resilienza, ma mancata verifica del funzionamento del carico di lavoro nel suo complesso in caso di errori. 
+  Mancata sperimentazione in scenari reali e con carichi previsti. 
+  Mancato trattamento degli esperimenti come codice o loro conservazione durante il ciclo di sviluppo. 
+  Mancata esecuzione degli esperimenti di ingegneria del caos sia nella pipeline CI/CD che esternamente alle implementazioni. 
+  Mancato utilizzo delle precedenti analisi post-incidente durante la determinazione degli errori su cui eseguire i test. 

 ** Vantaggi dell'adozione di questa best practice:** l'introduzione di errori per verificare la resilienza del carico di lavoro consente di verificare che le procedure di ripristino della progettazione resiliente funzionerà se viene generato un vero e proprio errore. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 L'ingegneria del caos offre ai team la possibilità di continuare a inserire scenari di errore reali (simulazioni) in modo controllato a livello di fornitore di servizi, infrastruttura, carico di lavoro e componente con un impatto minimo o nullo per i clienti. Consente inoltre ai team di imparare dagli errori e osservare, misurare e migliorare la resilienza dei carichi di lavoro, nonché verificare l'attivazione degli avvisi e se tali avvisi vengono recapitati ai team se si verifica un evento definito. 

 Se applicata in modo continuativo, l'ingegneria del caos può mettere in evidenza i difetti del carico di lavoro che, se non risolti, possono avere ripercussioni negative sulla disponibilità e sulle operazioni. 

**Nota**  
L'ingegneria del caos è la disciplina che sperimenta un sistema per creare fiducia nella capacità del sistema di affrontare condizioni turbolenti nella produzione. – [Principi di ingegneria del caos](https://principlesofchaos.org/) 

 Se un sistema è in grado di sopportare queste interruzioni, l'esperimento di ingegneria del caos deve essere convertito in test automatico di regressione. In questo modo, gli esperimenti di ingegneria del caos devono essere eseguiti nell'ambito del ciclo di vita dello sviluppo dei sistemi (SDLC) e della pipeline CI/CD. 

 Per garantire che il carico di lavoro sia in grado di gestire un guasto del componente, esegui l'iniezione di eventi di errore reali durante l'esecuzione degli esperimenti. Ad esempio, esegui esperimenti relativi alla perdita di istanze Amazon EC2 o a eventi di failover delle istanze database Amazon RDS primario e quindi verifica che il carico di lavoro non sia stato compromesso oppure o che si stato interessato solo in minima parte. Utilizza una combinazione di errori dei componenti per simulare gli eventi che possono essere causati da un'interruzione del servizio in una zona di disponibilità. 

 Per gli errori a livello di applicazione, ad esempio gli arresti anomali, puoi iniziare utilizzando fattori di stress, ad esempio l'esaurimento della memoria o della CPU. 

 Per convalidare i [meccanismi di fallback o failover](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) per le dipendenze esterne causate da interruzioni intermittenti dei servizi di rete, i componenti devono simulare tale evento bloccando l'accesso ai fornitori di terze parti per una durata specificata, che può durare da pochi secondi ad alcune ore. 

 Altre modalità di degrado possono causare funzionalità ridotte e risposte lente, spesso con conseguente interruzione dei servizi. Le fonti comuni di questo degrado sono una maggiore latenza nei servizi critici e una comunicazione di rete inaffidabile (pacchetti persi). Gli esperimenti basati su questi errori, inclusi gli effetti a livello di rete come latenza, messaggi eliminati ed errori DNS, possono prevedere l'incapacità di risolvere un nome, raggiungere il servizio DNS o stabilire connessioni a servizi dipendenti. 

 **Strumenti dell'ingegneria del caos** 

 AWS Fault Injection Service (AWS FIS) è un servizio completamente gestito per l'esecuzione di esperimenti di iniezione di errori che possono essere utilizzati come parte della pipeline di CD o al suo esterno. AWS FIS è una soluzione estremamente valida da utilizzare durante i giorni di gioco dell'ingegneria del caos. Supporta l'introduzione simultanea di errori in diversi tipi di risorse, ad esempio Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon RDS. Questi errori includono la cessazione delle risorse, la forzatura dei failover, l'applicazione di fattori di stress a CPU o memoria, la limitazione della lunghezza di banda della rete, la latenza e la perdita di pacchetti. Poiché è integrato con gli allarmi Amazon CloudWatch, è possibile impostare condizioni di arresto come guardrail per eseguire il rollback di un esperimento se causa un impatto inatteso. 

![\[Diagramma che mostra AWS Fault Injection Service integrato con le risorse AWS per consentire l'esecuzione di esperimenti di iniezione di errori per i carichi di lavoro.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/fault-injection-simulator.png)


Esistono anche diverse opzioni di terze parti per gli esperimenti di iniezione di errori. Queste includono strumenti open source, ad esempio [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/)e [Litmus Chaos](https://litmuschaos.io/), nonché opzioni commerciali come Gremlin. Per ampliare l'ambito degli errori che possono essere inseriti in AWS, AWS FIS [si integra con Chaos Mesh e Litmus Chaos](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/)e ciò consente di coordinare i flussi di lavoro relativi all'iniezione di errori tra più strumenti. Ad esempio, puoi eseguire un test di stress sulla CPU di un pod utilizzando gli errori di Chaos Mesh o Litmus Chaos durante la cessazione di una percentuale casualmente selezionata di nodi di cluster mediante le operazioni di errore di AWS FIS. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Determinazione degli errori da utilizzare per gli esperimenti. 

   Valutazione della progettazione del carico di lavoro a livello di resilienza. Tali progettazioni, create mediante le best practice del [Canone di architettura AWS](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) giustificano i rischi in base alle dipendenze critiche, agli eventi pregressi, alle problematiche note e ai requisiti di conformità. Elenca i singoli elementi della progettazione che devono conservare la resilienza e gli errori per mitigare i quali è stata sviluppata. Per ulteriori informazioni su questi elenchi, consulta [il whitepaper relativo alla prontezza operativa](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) , contenente linee guida su come creare un processo per impedire che si verifichino di nuovo incidenti già noti. Il processo FMEA (Failure Modes and Effects Analysis) fornisce un framework per l'esecuzione di un'analisi degli errori a livello di componente e del relativo impatto sul carico di lavoro. Il processo FMEA è descritto più in dettaglio nell'articolo di Adrian Cockcroft su [modalità di errore e resilienza continua](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5). 
+  Assegna una priorità a ogni errore. 

   Comincia con una categorizzazione approssimativa, ad esempio alta, media o bassa. Per assegnare la priorità, considera la frequenza dell'errore e l'impatto dell'errore sul carico di lavoro nel suo complesso. 

   Durante la valutazione della frequenza di un errore specifico, analizza i precedenti dati per lo stesso carico di lavoro, se disponibili. Se non sono disponibili, utilizza i dati di altri carichi di lavoro eseguiti in un ambiente simile. 

   Durante la valutazione dell'impatto di un errore specifico, in genere maggiore è l'ambito dell'errore, maggiore sarà l'impatto. Considera la progettazione e lo scopo del carico di lavoro. Ad esempio, la capacità di accedere ai datastore di origine è di cruciale importanza per un carico di lavoro responsabile della trasformazione e dell'analisi dei dati. In questo caso, darai la precedenza agli esperimenti relativi agli errori di accesso, nonché a quelli con accesso limitato a livello di larghezza di banda e inserimento di latenza. 

   Le analisi post-incidente rappresentano un'ottima fonte di dati per la comprensione della frequenza e dell'impatto delle modalità di errore. 

   Utilizza la priorità assegnata per determinare il primo errore su cui eseguire l'esperimento e l'ordine in cui sviluppare i nuovi esperimenti di iniezione di errori. 
+  Per ogni esperimento eseguito, attieniti ai principi del volano dell'ingegneria del caos e della resilienza continua.   
![\[Diagramma del volano dell'ingegneria del caos e della resilienza continua, con le fasi relative a miglioramento, stato stazionario, ipotesi, esecuzione dell'esperimento e verifica.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/chaos-engineering-flywheel.png)
  +  Definisci lo stato stazionario come output misurabile di un carico di lavoro che indica un comportamento normale. 

     Il carico di lavoro è associato allo stato stazionario se il suo funzionamento è affidabile e conforme a quanto previsto. Verifica pertanto che il carico di lavoro sia integro prima di definire lo stato stazionario. Lo stato stazionario non necessariamente indica l'assenza di impatto sul carico di lavoro se si verifica un errore in quanto una data percentuale di errori può rientrare nei limiti di valori accettabili. Lo stato stazionario rappresenta il punto di riferimento che verrà osservato durante l'esperimento e che metterà in evidenza le anomalie se le ipotesi definite nel passaggio successivo non sono conformi alle previsioni. 

     Ad esempio, lo stato stazionario di un sistema di pagamento può essere definito come elaborazione di 300 TPS con una percentuale di successo pari al 99% e un tempo di round trip pari a 500 ms. 
  +  Definisci un'ipotesi in merito alle reazioni del carico di lavoro all'errore. 

     Un'ipotesi ottimale fa riferimento al modo in cui il carico di lavoro presumibilmente è in grado di ridurre l'impatto dell'errore e salvaguardare lo stato stazionario. Nell'ipotesi è definito che, dato un errore di un tipo specifico, il sistema o il carico di lavoro rimarrà nello stato stazionario perché la progettazione del carico di lavoro ha previsto sistemi specifici di attenuazione degli errori. Il tipo di errore specifico e i sistemi di attenuazione devono essere specificati nell'ipotesi. 

     Per l'ipotesi è possibile utilizzare il seguente modello, anche se è accettabile una formulazione diversa: 
**Nota**  
 Se si verifica un *errore specifico* , il carico di lavoro *nome del carico di lavoro* descriverà *i controlli di attenuazione* per controbilanciare *l'impatto sulle metriche aziendali o tecniche*. 

     Ad esempio: 
    +  In caso di arresto del 20% dei nodi nel gruppo di nodi Amazon EKS, l'API di creazione delle transazioni continua a servire il 99° percentile delle richieste in meno di 100 ms (stato stazionario). Verrà eseguito il ripristino dei nodi Amazon EKS entro cinque minuti; i pod verranno riprogrammati ed elaboreranno il traffico entro otto minuti dall'inizio dell'esperimento. Gli avvisi verranno attivati entro tre minuti. 
    +  Se si verifica un errore in un'istanza Amazon EC2, il controllo dell'integrità Elastic Load Balancing del sistema degli ordini farà sì che Elastic Load Balancing si limiti a inviare richieste alle rimanenti istanze integre, mentre la funzionalità Amazon EC2 Auto Scaling sostituirà l'istanza in errore, garantendo un incremento inferiore allo 0,01% degli errori (5xx) lato server (stato stazionario). 
    +  Se l'istanza database primario Amazon RDS restituisce un errore, il carico di lavoro della raccolta di dati della catena di approvvigionamento eseguirà il failover e si connetterà all'istanza database in standby Amazon RDS per mantenere meno di un minuto di errori di lettura o scrittura del database (stato stazionario). 
  +  Esegui l'esperimento inserendo l'errore. 

     Per impostazione predefinita, un esperimento deve essere a prova di errore e tollerato dal carico di lavoro. Se sei consapevole del fatto che il carico di lavoro avrà esito negativo, non eseguire l'esperimento. L'ingegneria del caos deve essere utilizzata per individuare scenari noti sconosciuti o scenari completamente sconosciuti. *"Scenari noti sconosciuti"* fanno riferimento a quegli scenari di cui sei consapevole, ma non ne comprendi completamente la natura, mentre con *"scenari completamente sconosciuti"* si intendono quegli scenari a te non noti e di cui non ne comprendi la natura o i motivi. L'esecuzione di esperimenti su un carico di lavoro non funzionante non può fornire nuovi approfondimenti chiarificatori. L'esperimento deve infatti essere pianificato con attenzione, essere caratterizzato da un ambito ben definito relativamente al suo impatto, nonché fornire un meccanismo di rollback applicabile in caso di esiti negativi imprevisti. Se il criterio di due diligence indica che il carico di lavoro è in grado di sostenere l'esperimento, procedi ed esegui l'esperimento. Sono disponibili varie opzioni per l'inserimento degli errori. Per i carichi di lavoro in AWS, [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) fornisce numerose simulazioni di errore predefinite denominate [operazioni](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). Puoi anche definire operazioni personalizzate eseguibili in AWS FIS utilizzando i [documenti AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html). 

     È sconsigliato l'uso di script personalizzati per gli esperimenti di ingegneria del caos, a meno che gli script non siano in grado di rilevare lo stato corrente del carico di lavoro, generare log e fornire meccanismi di rollback e condizioni di arresto, laddove possibile. 

     Un framework o set di strumenti efficace che supporta l'ingegneria del caos deve tenere traccia dello stato corrente di un esperimento, generare log e fornire meccanismi di rollback a supporto dell'esecuzione controllata di un esperimento. Inizia utilizzando un servizio noto, ad esempio AWS FIS, che consente di eseguire esperimenti con ambiti e meccanismi di sicurezza ben definiti in grado di eseguire il rollback dell'esperimento in caso di esiti negativi imprevisti. Per ulteriori informazioni sull'intera gamma di esperimenti che utilizzano AWS FIS, consulta anche la sezione relativa al [laboratorio relativo alle app Well-Architected resilienti con ingegneria del caos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). Inoltre, [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) analizzerà il carico di lavoro e creerà gli esperimenti che potrai scegliere di implementare ed eseguire in AWS FIS. 
**Nota**  
 Per ogni esperimento, devi essere consapevole del suo ambito e del relativo impatto. È consigliabile eseguire la simulazione dell'errore in un ambiente non di produzione prima di eseguirla in un ambiente di produzione vero e proprio. 

     Gli esperimenti devono essere eseguiti in ambienti di produzione con un carico reale mediante [implementazioni canary](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) , che attivano sistemi sperimentali e di controllo, laddove possibile. L'esecuzione degli esperimenti durante gli orari non di punta è altamente consigliata al fine di ridurre al massimo potenziali eventi negativi durante la prima esecuzione dell'esperimento negli ambienti di produzione. Inoltre, se l'utilizzo dell'effettivo traffico clienti costituisce un rischio eccessivo, puoi eseguire gli esperimenti utilizzando una sintesi del traffico nell'infrastruttura di produzione utilizzando implementazioni sperimentali e di controllo. Se l'utilizzo di un ambiente di produzione non è possibile, esegui gli esperimenti in ambienti di pre-produzione il più simili possibile agli effettivi ambienti di produzione. 

     Devi definire e monitorare i guardrail per essere sicuro che l'esperimento non abbia un impatto sul traffico di produzione o sugli altri sistemi che superi i limiti accettabili. Definisci condizioni di arresto per interrompere l'esperimento se viene raggiunta la soglia definita nella metrica del guardrail. In tali condizioni devono essere incluse le metriche relative allo stato stazionario del carico di lavoro e le metriche riferite ai componenti in cui inserisci l'errore. Un [monitor sintetico](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (definito anche canary utente) è una metrica che in genere deve essere inclusa come proxy utente. [Le condizioni di arresto per AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) sono supportate nel modello di esperimento, nella misura di un massimo di cinque condizioni di arresto per modello. 

     Uno dei principi dell'ingegneria del caos prevede la riduzione dell'ambito dell'esperimento e del relativo impatto. 

     Se da un lato deve essere prevista la possibilità di un determinato impatto negativo a breve termine, dall'altro il contenimento e la riduzione delle conseguenze negative degli esperimenti sono una responsabilità esclusiva dell'addetto all'ingegneria del caos. 

     Un metodo per verificare l'ambito e il potenziale impatto prevede l'esecuzione dell'esperimento dapprima in un ambiente non di produzione, la verifica che le soglie delle condizioni di arresto vengano attivate come previsto durante lo svolgimento di un esperimento e l'utilizzo effettivo delle misure di osservabilità finalizzate all'acquisizione di un'eccezione, anziché eseguire l'esperimento direttamente in produzione. 

     Durante l'esecuzione di esperimenti di iniezione di errori, verifica che tutte le parti responsabili ne siano a conoscenza. Comunica ai team appropriati, ad esempio i team responsabili delle operazioni, dell'affidabilità dei servizi e del supporto clienti, quando verranno eseguiti gli esperimenti e l'impatto previsto. Metti a disposizione di questi team strumenti di comunicazione che consentano loro di informare i responsabili dell'esperimento di eventuali effetti avversi. 

     È necessario ripristinare lo stato originario del carico di lavoro e dei relativi sistemi sottostanti. La progettazione resiliente del carico di lavoro è spesso caratterizzata da funzionalità di riparazione automatica. Tuttavia, alcune progettazioni difettose o alcuni esperimenti non riusciti possono compromettere in modo imprevisto lo stato del carico di lavoro. Entro la fine dell'esperimento dovrai essere consapevole di questa situazione e ripristinare il carico di lavoro e i sistemi. Con AWS FIS puoi impostare una configurazione di rollback, definita anche post-operazione, all'interno dei parametri operativi. Una post-operazione ripristina una destinazione allo stato in cui si trovava prima dell'esecuzione dell'operazione stessa. Indipendentemente dal fatto che vengano eseguite in modalità automatica, ad esempio utilizzando AWS FIS, o manuale, queste post-operazioni devono essere incluse in un playbook in cui vengono descritte le procedure di rilevamento e gestione degli errori. 
  +  Verifica l'ipotesi. 

    [Principi di ingegneria del caos](https://principlesofchaos.org/) è un documento contenente le linee guida su come verificare lo stato stazionario del carico di lavoro. 

    È necessario concentrarsi sull'output misurabile di un sistema e non sugli attributi interni del sistema. Le misurazioni di tale output in un breve periodo di tempo costituiscono un'attestazione dello stato stazionario del sistema. La velocità di trasmissione effettiva del sistema nel suo complesso, le percentuali di errori e i percentili della latenza possono essere considerati metriche di interesse che rappresentano il comportamento di uno stato stazionario. Sulla base dei rilevamenti dei modelli di comportamento sistematico durante gli esperimenti, l'ingegneria del caos verifica che il sistema funzioni correttamente anziché tentare di convalidare il modo in cui funziona.

     Nei due esempi precedenti sono state incluse le metriche dello stato stazionario relative a un incremento inferiore allo 0,01% di errori (5xx) lato server e inferiore a un minuto di errori di lettura e scrittura del database. 

     Gli errori 5xx rappresentano una buona metrica perché sono la conseguenza della modalità di errore che un client del carico di lavoro sperimenterà direttamente. La misurazione degli errori del database risulta valida come conseguenza diretta dell'errore, ma deve essere supportata da una misurazione diretta dell'impatto, ad esempio le richieste cliente non riuscite o gli errori restituiti a livello di client. Includi anche un monitor sintetico, definito canary utente, in qualsiasi API o URI a cui il client del carico di lavoro ha accesso diretto. 
  +  Migliora la progettazione del carico di lavoro con un occhio di riguardo per la resilienza. 

     Se lo stato stazionario non è stato preservato, analizza in che modo puoi migliorare la progettazione del flusso di lavoro per azzerare l'impatto dell'errore applicando le best practice descritte nel [Pilastro AWS Well-Architected relativo all'affidabilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Ulteriori linee guida e risorse sono disponibili nella [libreria di AWS Builder](https://aws.amazon.com/builders-library/), dove sono contenuti articoli su come [migliorare i controlli dell'integrità](https://aws.amazon.com/builders-library/implementing-health-checks/) oppure [impiegare nuovi tentativi con backoff nel codice dell'applicazione](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/). 

     Dopo aver implementato queste modifiche, esegui di nuovo l'esperimento (rappresentato dalla linea punteggiata nel volano relativo all'ingegneria del caos) per determinare la relativa efficacia. Se nella fase di verifica risulta che l'ipotesi è vera, il carico di lavoro sarà in stato stazionario e il ciclo continuerà. 
+  Esegui gli esperimenti con regolarità. 

   Un esperimento di ingegneria del caos è un ciclo e gli esperimenti devono essere eseguiti regolarmente nell'ambito dell'ingegneria del caos. Se un carico di lavoro è conforme all'ipotesi dell'esperimento, l'esperimento deve essere automatizzato affinché venga eseguito continuamente come fase di regressione della pipeline CI/CD. Per ulteriori informazioni in merito, consulta questo blog relativamente alle [procedure di esecuzione degli esperimenti AWS FIS utilizzando AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/). Questo laboratorio relativo a esperimenti [AWS FIS ricorrenti in una pipeline CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) ti consente di fare esperienza pratica. 

   Gli esperimenti di iniezione di errori fanno inoltre parte delle giornate di gioco (consulta [REL12-BP06 Esecuzione regolare di giornate di gioco](rel_testing_resiliency_game_days_resiliency.md)). Le giornate di gioco simulano un errore o un evento per verificare sistemi, processi e risposte dei team. Lo scopo è di eseguire effettivamente le azioni che compirebbe il team come se si verificasse un evento eccezionale. 
+  Acquisisci e archivia i risultati degli esperimenti. 

  I risultati degli esperimenti di iniezione di errori devono essere acquisiti e resi persistenti. Includi tutti i dati necessari, ad esempio orari, carico di lavoro e condizioni, in modo da essere in grado di analizzare i risultati e i trend in un secondo momento. I risultati potrebbero includere, ad esempio, screenshot dei pannelli di controllo, dump in formato CSV del database delle metriche oppure appunti scritti a mano relativi a eventi e osservazioni associati all'esperimento. [La registrazione degli esperimenti mediante AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) può rientrare nel processo di acquisizione dei dati.

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL08-BP03 Esecuzione di test di resilienza come parte integrante dell'implementazione](rel_tracking_change_management_resiliency_testing.md) 
+  [REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione](rel_planning_for_recovery_dr_tested.md) 

 **Documenti correlati:** 
+  [What is AWS Fault Injection Service? (Che cos'è AWS Fault Injection Service?)](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 
+  [What is AWS Resilience Hub? (Che cos'è AWS Resilience Hub?)](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 
+  [Principi di ingegneria del caos](https://principlesofchaos.org/) 
+  [Chaos Engineering: Planning your first experiment (Ingegneria del caos: pianificazione del primo esperimento)](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde) 
+  [Resilience Engineering: Learning to Embrace Failure](https://queue.acm.org/detail.cfm?id=2371297) 
+  [Chaos Engineering stories (Storie relative all'ingegneria del caso)](https://github.com/ldomb/ChaosEngineeringPublicStories) 
+  [Evitare fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) 
+  [Canary Deployment for Chaos Experiments (Implementazione canary per gli esperimenti di ingegneria del caos)](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) 

 **Video correlati:** 
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering (ARC316) (Esecuzione di test di resilienza mediante l'ingegneria del caos [ARC316])](https://www.youtube.com/watch?v=OlobVYPkxgg) 
+  [AWS re:Invent 2019: migliorare la resilienza con l'ingegneria del caos (DOP309-R1)](https://youtu.be/ztiPjey2rfY) 
+  [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301) (Esecuzione dell'ingegneria del caos in uno scenario serverless [CMY301])](https://www.youtube.com/watch?v=vbyjpMeYitA) 

 **Esempi correlati:** 
+  [Well-Architected lab: Level 300: Testing for Resiliency of Amazon EC2, Amazon RDS, and Amazon S3 (Test della resilienza di Amazon EC2, Amazon RDS e Amazon S3)](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/) 
+  [Chaos Engineering on AWS lab (Laboratorio relativo all'ingegneria del caos in AWS)](https://chaos-engineering.workshop.aws/en/) 
+  [Resilient and Well-Architected Apps with Chaos Engineering lab (Laboratorio relativo alle app Well-Architected resilienti con ingegneria del caos)](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US) 
+  [Serverless Chaos lab (Laboratorio relativi a esperimenti di ingegneria del caos per architetture serverless)](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless) 
+  [Measure and Improve Your Application Resilience with AWS Resilience Hub lab (Laboratorio di misurazione e ottimizzazione della resilienza dell'applicazione con AWS Resilience Hub)](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab) 

 ** Strumenti correlati: ** 
+  [AWS Fault Injection Service](https://aws.amazon.com/fis/) 
+ Marketplace AWS: [Gremlin Chaos Engineering Platform (Piattaforma di ingegneria del caos di Gremlin)](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney) 
+  [Chaos Toolkit](https://chaostoolkit.org/) 
+  [Chaos Mesh](https://chaos-mesh.org/) 
+  [Litmus](https://litmuschaos.io/) 

# REL12-BP06 Esecuzione regolare di giornate di gioco
<a name="rel_testing_resiliency_game_days_resiliency"></a>

 Utilizza le giornate di gioco per provare regolarmente le procedure per rispondere a eventi ed errori nel modo più vicino possibile alla produzione (anche negli ambienti di produzione) con le persone che si occuperanno di eventuali scenari di errore reali. Le giornate di gioco applicano misure per garantire che gli eventi di produzione non influiscano sugli utenti. 

 Le giornate di gioco simulano un errore o un evento per testare sistemi, processi e risposte dei team. Lo scopo è di eseguire effettivamente le azioni che compirebbe il team come se si verificasse un evento eccezionale. Questi ti aiuta a capire dove puoi apportare dei miglioramenti e ti può aiutare a sviluppare un'esperienza organizzativa nella gestione degli eventi. Tali azioni devono essere svolte regolarmente in modo che il team costruisca *una memoria muscolare* su come rispondere. 

 Quando la progettazione per la resilienza è in loco ed è stata testata in ambienti non di produzione, un game day è il modo per garantire che tutto funzioni come pianificato in produzione. Una giornata di gioco, soprattutto la prima, è un'attività di duro lavoro per tutti, in cui tutti gli ingegneri e i team operativi vengono informati in merito a quando accadrà e cosa accadrà. I runbook sono in loco. Gli eventi simulati, compresi i possibili eventi di guasto, vengono eseguiti nei sistemi di produzione nel modo prescritto e ne viene valutato l'impatto. Se tutti i sistemi funzionano come progettato, il rilevamento e la correzione automatica avvengono con un impatto minimo o nullo. Tuttavia, se si osserva un impatto negativo, viene eseguito il rollback del test e i problemi relativi al carico di lavoro vengono risolti, se necessario manualmente (utilizzando il runbook). Poiché le giornate di gioco hanno spesso luogo in produzione, è necessario prendere tutte le precauzioni per garantire che non vi sia alcun impatto sulla disponibilità per i clienti. 

 **Anti-pattern comuni:** 
+  Documentare le procedure senza mai esercitarle. 
+  Non includere i responsabili delle decisioni aziendali negli esercizi di test. 

 **Vantaggi dell'adozione di questa best practice:** Eseguire giornate di gioco garantisce che tutto il personale segua le policy e le procedure quando si verifica un incidente reale e convalida che tali policy e procedure siano appropriate. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Programma giornate di gioco per provare regolarmente i tuoi runbook e playbook. Le giornate di gioco devono coinvolgere tutte le persone implicate in un evento di produzione: proprietari di aziende, personale addetto allo sviluppo, personale operativo e team di risposta agli incidenti. 
  +  Esegui i test di carico o delle prestazioni e successivamente esegui l'iniezione degli errori. 
  +  Ricerca anomalie nei tuoi runbook e opportunità di provare i tuoi playbook. 
    +  In caso di deviazione dai tuoi runbook, perfeziona il runbook o correggi il comportamento. Se ti eserciti sul tuo playbook, identifica il runbook che avrebbe dovuto essere usato, oppure creane uno nuovo. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Che cos'è AWS GameDay?](https://aws.amazon.com/gameday/) 

 **Video correlati:** 
+  [AWS re:Invent 2019: migliorare la resilienza con l'ingegneria del caos (DOP309-R1)](https://youtu.be/ztiPjey2rfY) 

   **Esempi correlati:** 
+  [AWS Well-Architected Labs – Test di resilienza](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/) 

# REL 13. Come si pianifica il disaster recovery o ripristino di emergenza?
<a name="rel-13"></a>

Avere backup e componenti del carico di lavoro ridondanti in loco è l'inizio della strategia di disaster recovery. [RTO e RPO sono i tuoi obiettivi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) per il ripristino del carico di lavoro. Imposta questi valori in base alle esigenze aziendali. Implementa una strategia per raggiungere questi obiettivi, prendendo in considerazione le posizioni e la funzione delle risorse e dei dati del carico di lavoro. La probabilità di interruzione e il costo del ripristino sono fattori chiave che aiutano a comunicare il valore aziendale che può avere il ripristino di emergenza per un carico di lavoro.

**Topics**
+ [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Gestione della deviazione di configurazione nel sito o nella Regione del ripristino di emergenza](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Automatizzazione del ripristino](rel_planning_for_recovery_auto_recovery.md)

# REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati
<a name="rel_planning_for_recovery_objective_defined_recovery"></a>

 Il carico di lavoro ha un Recovery Time Objective (RTO) e Recovery Point Objective (RPO). 

 *Il Recovery Time Objective (RTO)* è il ritardo massimo accettabile tra l'interruzione del servizio e il suo ripristino. Questo determina ciò che viene considerato un intervallo di tempo accettabile quando il servizio non è disponibile. 

 *Recovery Point Objective (RPO)*  è il periodo di tempo massimo accettabile dall'ultimo punto di ripristino dei dati. Questo determina ciò che viene considerato una perdita di dati accettabile tra l'ultimo punto di ripristino e l'interruzione del servizio. 

 RTO e RPO sono valori importanti quando si seleziona una strategia adeguata di ripristino di emergenza per il proprio carico di lavoro. Tali obiettivi sono stabiliti dall'azienda e poi vengono utilizzati dai team tecnici per selezionare e implementare una strategia di ripristino di emergenza. 

 **Risultato desiderato:**  

 Ogni carico di lavoro ha un RTO e un RPO assegnati, definiti in base all'impatto aziendale. Il carico di lavoro viene assegnato a un livello predefinito, che stabilisce la disponibilità del servizio e la perdita accettabile di dati, con un RTO e un RPO associati. Se tale livello non è raggiungibile, è possibile assegnare un livello personalizzato per carico di lavoro, con l'obiettivo di creare i livelli in un secondo momento. RTO e RPO sono valori fondamentali per la selezione di una strategia di ripristino di emergenza da implementare per il carico di lavoro. Altre riflessioni nel momento della scelta di una strategia di ripristino di emergenza sono i vincoli economici, le dipendenze del carico di lavoro e i requisiti operativi. 

 Per l'RTO è necessario comprendere l'impatto in base alla durata di un'interruzione. È lineare o ci sono implicazioni non lineari? (Ad esempio, dopo 4 ore, chiudi una linea di produzione fino l'inizio del turno successivo). 

 Una matrice di ripristino di emergenza, come quella seguente, può aiutarti a capire come la criticità del carico di lavoro sia collegata agli obiettivi di ripristino. (Da notare che i valori reali per gli assi X e Y devono essere personalizzati in base alle esigenze della tua organizzazione). 

![\[Grafico che mostra la matrice del ripristino di emergenza\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/disaster-recovery-matrix.png)


 **Anti-pattern comuni:** 
+  Nessun obiettivo di ripristino definito. 
+  Selezione di obiettivi di ripristino arbitrari. 
+  Selezione di obiettivi di ripristino troppo tolleranti e che non soddisfano gli obiettivi di business. 
+  Mancanza di comprensione dell'impatto dei tempi di inattività e perdita dei dati. 
+  Selezione di obiettivi di ripristino non realistici, come tempo zero di ripristino e nessuna perdita di dati, che potrebbero non essere raggiungibili per la configurazione del tuo carico di lavoro. 
+  Selezione di obiettivi di ripristino più severi rispetto agli obiettivi aziendali effettivi. Questo costringe a effettuare implementazioni di ripristino di emergenza più costose e complicate rispetto alle esigenze del carico di lavoro. 
+  Selezione di obiettivi di ripristino non compatibili con quelli di un carico di lavoro dipendente. 
+  I tuoi obiettivi di ripristino non considerano i requisiti di conformità normativa. 
+  RTO e RPO definiti per un carico di lavoro, ma mai testati. 

 **Vantaggi dell'adozione di questa best practice:** Gli obiettivi di ripristino in termini di tempo e perdita di dati sono necessari per guidare l'implementazione del disaster recovery. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per un dato carico di lavoro devi considerare l'impatto dei tempi di inattività e della perdita dei dati per la tua azienda. L'impatto generalmente aumenta all'aumentare dei tempi di inattività o della perdita dei dati, ma il ritmo di tale crescita cambia in base al tipo di carico di lavoro. Ad esempio, potresti tollerare l'inattività per massimo un'ora con conseguenze minime, ma successivamente l'impatto diventerebbe rapidamente più serio. L'impatto sull'azienda si manifesta in forme diverse, tra cui costi economici (come perdita di fatturato), fiducia del cliente (e impatto sulla reputazione), problematiche operative (come stipendi in ritardo o diminuzione della produttività) e rischi normativi. Usa i passaggi seguenti per comprendere questi aspetti e impostare i valori RTO e RPO per il tuo carico di lavoro. 

 **Passaggi dell'implementazione** 

1.  Individua gli stakeholder aziendali per questo carico di lavoro e collabora con loro per implementare questi passaggi. Gli obiettivi di ripristino di un carico di lavoro sono il frutto di una decisione aziendale. I team tecnici, quindi, lavorano con gli stakeholder aziendali e usano questi obiettivi per selezionare una strategia di ripristino di emergenza. 
**Nota**  
Per i passaggi 2 e 3 puoi usare [Foglio di lavoro di implementazione](#implementation-worksheet).

1.  Raccogli le informazioni necessarie per prendere una decisione rispondendo alle domande qui di seguito. 

1.  Hai categorie o livelli di criticità in termini di impatto del tuo carico di lavoro nella tua organizzazione? 

   1.  Se sì, assegna questo carico di lavoro a una categoria 

   1.  Se no, definisci queste categorie. Crea al massimo cinque categorie e perfeziona l'intervallo del tuo Obiettivo del tempo di ripristino (RTO) per ognuna. Ecco alcune categorie di esempio: critico, alto, medio, basso. Per capire come mappare i carichi di lavoro rispetto alle categorie devi considerare se il carico di lavoro è mission-critical, importante per l'azienda o non trainante. 

   1.  Imposta i valori RTO e RPO del carico di lavoro in base alla categoria. Scegli sempre una categoria più severa (RTO e RPO inferiori) rispetto ai valori grezzi calcolati in questa fase. Se ciò comporta una variazione significativa di valore non rispondente alle esigenze, prendi in considerazione la possibilità di creare una nuova categoria. 

1.  In base alle risposte assegna i valori RTO e RPO al carico di lavoro. Puoi farlo direttamente o assegnando il carico di lavoro a un livello predefinito di servizio. 

1.  Crea un documento con il piano di ripristino di emergenza (DRP) per questo carico di lavoro, che sarà parte del [piano di continuità aziendale della tua organizzazione (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html), in un punto accessibile al team del carico di lavoro e agli stakeholder. 

   1.  Registra i valori RTO e RPO e le informazioni usate per definire questi valori. Includi la strategia utilizzata per valutare l'impatto del carico di lavoro sull'azienda. 

   1.  Registra altre metriche, oltre ai valori RTO e RPO che stai monitorando o che pensi di monitorare per gli obiettivi di ripristino di emergenza. 

   1.  Dopo aver creato questi valori, potrai aggiungere i dettagli della tua strategia di ripristino di emergenza e il runbook. 

1.  Osservando le criticità del carico di lavoro in una matrice come quella della Figura 15, puoi iniziare a stabilire livelli predefiniti di servizio per la tua organizzazione. 

1.  Dopo aver implementato una strategia di ripristino di emergenza (o un proof of concept per una strategia di ripristino di emergenza) secondo quanto stabilito da [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md), testa questa strategia per stabilire i valori reali di RTC (Recovery Time Capability) e di RPC (Recovery Point Capability) del carico di lavoro. Se questi valori non sono in linea con gli obiettivi target di ripristino, puoi collaborare con gli stakeholder della tua azienda per modificarli o cambiare la strategia di ripristino di emergenza in modo che possa soddisfare tali obiettivi. 

 **Domande principali** 

1.  Qual è il tempo massimo durante il quale il carico di lavoro può essere inattivo prima che questo abbia un impatto grave sull'attività? 

   1.  Definisci il costo monetario (impatto finanziario diretto) sull'attività al minuto se il carico di lavoro è inattivo. 

   1.  Considera che l'impatto non è sempre lineare. L'impatto può essere limitato all'inizio e poi aumentare rapidamente oltre un punto critico specifico. 

1.  Qual è la quantità massima di dati che possiamo perdere prima che questo abbia un impatto grave sull'attività? 

   1.  Considera questo valore per gli archivi di dati più strategici. identifica le criticità relative ad altri archivi di dati. 

   1.  I dati del carico di lavoro possono essere ricreati se persi? Se questo è operativamente più facile rispetto al backup e al ripristino, scegli il valore RPO in base alla criticità dei dati di origine utilizzati per ricreare i dati del carico di lavoro. 

1.  Quali sono gli obiettivi di ripristino e le aspettative di disponibilità dei carichi di lavoro da cui questo valore dipende (downstream) o i carichi di lavoro che dipendono da questo valore (upstream)? 

   1.  Scegli obiettivi di ripristino che consentono a questo carico di lavoro di soddisfare i requisiti delle dipendenze upstream. 

   1.  Scegli obiettivi di ripristino che sono raggiungibili considerate le funzionalità di ripristino delle dipendenze downstream. Possono essere escluse le dipendenze downstream non critiche (quelle che puoi "aggirare"). In alternativa, lavora con dipendenze downstream critiche per migliorare le funzionalità di ripristino, laddove necessario. 

 **Domande aggiuntive** 

 Considera queste domande e come possono essere applicate a questo carico di lavoro: 

1.  Hai RTO e RPO diversi a seconda del tipo di interruzione (Regione rispetto ad AZ e così via)? 

1.  Esiste un periodo specifico (stagionalità, eventi commerciali, lanci di prodotto) in cui RTO/RPO possono cambiare? Se sì, qual è la misurazione diversa e il vincolo temporale? 

1.  Se il carico di lavoro viene perturbato, quanti clienti ne subiranno l'impatto? 

1.  Qual è l'impatto sulla reputazione se il carico di lavoro è perturbato? 

1.  Quali altri impatti operativi possono verificarsi se il carico di lavoro subisce perturbazioni? Ad esempio, l'impatto sulla produttività dei dipendenti se i sistemi e-mail non sono disponibili o sei i sistemi di buste paga non sono in grado di inviare le transazioni. 

1.  In che modo il carico di lavoro e i valori RTO e RPO si allineano alla linea di business e alla strategia di ripristino di emergenza dell'organizzazione? 

1.  Esistono obblighi contrattuali interni per fornire un servizio? Esistono delle penali nel caso in cui non siano soddisfatti? 

1.  Quali sono i limiti normativi o di conformità dei dati? 

## Foglio di lavoro di implementazione
<a name="implementation-worksheet"></a>

 Puoi usare questo foglio di lavoro per le fasi 2 e 3 dell'implementazione. Adegua questo foglio di lavoro in base alle tue esigenze specifiche, aggiungendo, ad esempio, altre domande. 

<a name="worksheet"></a>![\[Foglio di lavoro\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/worksheet.png)


 **Livello di impegno per il piano di implementazione: **Bassa 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [REL09-BP04 Ripristino periodico dei dati per verificare l'integrità e i processi di backup:](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](rel_planning_for_recovery_disaster_recovery.md) 
+ [REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione](rel_planning_for_recovery_dr_tested.md) 

 **Documenti correlati:** 
+  [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [Gestire le policy di resilienza con AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html) 
+  [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 

 **Video correlati:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
+  [Ripristino di emergenza di carichi di lavoro su AWS](https://www.youtube.com/watch?v=cJZw5mrxryA) 

# REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino
<a name="rel_planning_for_recovery_disaster_recovery"></a>

Definisci una strategia di ripristino di emergenza (DR) che soddisfi gli obiettivi di ripristino del carico di lavoro. Scegli una strategia, ad esempio backup e ripristino, standby (attivo/passivo) o attivo/attivo.

 **Risultato desiderato:** definizione e implementazione di una strategia di ripristino di emergenza per ogni carico di lavoro che permette al carico di lavoro di realizzare gli obiettivi di ripristino di emergenza. Le strategie di ripristino di emergenza tra carichi di lavoro utilizzano modelli riutilizzabili (come strategie descritte in precedenza), 

 **Anti-pattern comuni:** 
+  Implementazione di procedure di ripristino incoerenti per carichi di lavoro con obiettivi di ripristino simili. 
+  Implementazione di una strategia di ripristino di emergenza ad-hoc quando si verifica un disastro. 
+  Assenza di piani per il ripristino di emergenza. 
+  Dipendenza dalle operazioni del piano di controllo durante il ripristino. 

 **Vantaggi dell'adozione di questa best practice:** 
+  L'utilizzo di strategie di ripristino definite consente di utilizzare strumenti e procedure di test comuni. 
+  L'uso di strategie di ripristino definite permette la condivisione delle informazioni tra team e l'implementazione del ripristino di emergenza nei carichi dl lavoro di loro proprietà. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato Senza una strategia di ripristino di emergenza pianificata, implementata e testata, è poco probabile riuscire a raggiungere gli obiettivi di ripristino in caso di eventi disastrosi. 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Una strategia di ripristino di emergenza si basa sulla capacità di creare il tuo carico di lavoro in un sito di ripristino se la tua sede principale non è disponibile per eseguire il carico di lavoro. Gli obiettivi di ripristino più comuni sono RTO e RPO, come discusso in [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md). 

 Una strategia di ripristino di emergenza (DR) su più zone di disponibilità (AZ) all'interno di un singolo Regione AWS può offrire la mitigazione rispetto a eventi disastrosi come incendi, alluvioni e interruzioni gravi dell'energia. Se è un requisito implementare una protezione rispetto a un evento improbabile che impedisca al tuo carico di lavoro di poter essere eseguito in un determinato Regione AWS, puoi usare una strategia di ripristino di emergenza basata su più regioni. 

 Quando pianifichi una strategia di ripristino di emergenza su più regioni, devi scegliere una delle seguenti strategie. Sono elencate in ordine crescente di complessità e di costi e in ordine decrescente di RTO e RPO. Per *regione di ripristino* si intende una Regione AWS diversa da quella primaria usata per il carico di lavoro. 

![\[Diagramma che mostra le strategie di ripristino di emergenza\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/disaster-recovery-strategies.png)

+  **Backup e ripristino** (RPO nell'ordine di ore, RTO in 24 ore o meno): backup dei dati e delle applicazioni nella regione di ripristino. Adottando backup continui o automatizzati otterrai un ripristino point-in-ime che può ridurre il valore dell'RPO fino a raggiungere in alcuni casi 5 minuti. Nel caso in cui si verifichi un disastro, distribuirai l'infrastruttura (usando l'infrastruttura come codice per ridurre l'RTO), distribuirai il codice e ripristinerai i dati del backup dopo un disastro nella regione di ripristino. 
+  **Pilot Light** (RPO nell'ordine di minuti, RTO nell'ordine di decine di minuti): provisioning di una copia dell'infrastruttura principale del carico di lavoro nella regione di ripristino. Replica i dati nella regione di ripristino e crea un backup in essa. Le risorse necessarie per supportare la replica dei dati e il backup, come database e archiviazione di oggetti, sono sempre attive. Altri elementi come i server applicativi o il calcolo serverless non vengono distribuiti, ma possono essere creati quando necessari con la configurazione e il codice applicativo richiesti. 
+  **Warm Standby** (RPO nell'ordine di secondi, RTO nell'ordine di minuti): esecuzione continua di una versione ridotta ma completamente funzionale del carico di lavoro nella regione di ripristino. I sistemi business critical sono completamente duplicati e sono sempre accesi, ma con un parco istanze ridimensionato. I dati vengono replicati e si trovano nella regione di ripristino. Quando viene il momento del ripristino, il sistema viene dimensionato rapidamente per gestire il carico di produzione. Maggiore è il dimensionamento nella strategia di Warm Standby, più bassi saranno l'RTO e la dipendenza del piano di controllo (control-plane). Quando il dimensionamento è completo, si parla di *standby a caldo*. 
+  **Attivo/attivo multi-regione (multisito)** (RPO quasi pari a zero, RTO potenzialmente pari a zero): il carico di lavoro viene implementato in più regioni AWS e distribuisce attivamente il traffico da più Regioni AWS. Questa strategia comporta la sincronizzazione dei dati tra le regioni. È necessario evitare o gestire possibili conflitti causati da scritture sullo stesso record in due diverse repliche regionali, un'attività che potrebbe rivelarsi complessa. La replica dei dati è utile per la sincronizzazione dei dati e ti proteggerà da alcuni tipi di disastri, ma non dalla corruzione o dalla distruzione dei dati, a meno che la tua soluzione non includa opzioni per il ripristino point-in-time. 

**Nota**  
 La differenza tra Pilot Light e Warm Standby può talvolta essere difficile da comprendere. Entrambe prevedono un ambiente nella tua regione di ripristino con copie degli asset della tua regione principale. La differenza è che la strategia Pilot Light non può elaborare le richieste senza aver prima intrapreso altre azioni, mentre Warm Standby può gestire immediatamente il traffico (a livelli ridotti di capacità). La strategia Pilot Light richiede l'attivazione dei server, possibilmente l'implementazione di un'infrastruttura aggiuntiva (non principale) e l'aumento di risorse, mentre Warm Standby richiede solo l'aumento di risorse (tutto è già stato implementato ed è in esecuzione). Scegli tra queste opzioni in base alle tue esigenze di RTO e RPO.   
 Quando i costi sono un motivo di preoccupazione e vuoi realizzare obiettivi RPO ed RTO simili a quelli definiti nella strategia di Warm Standby, puoi prendere in considerazione soluzioni native nel cloud, come Ripristino di emergenza di elastico di AWS, che adotta l'approccio Pilot Light e offre obiettivi RPO ed RTO migliori. 

 **Passaggi dell'implementazione** 

1.  **Definisci una strategia di ripristino di emergenza in linea con i requisiti di ripristino di questo carico di lavoro.** 

 La scelta di una strategia di ripristino di emergenza è un compromesso tra la riduzione dei tempi di inattività e della perdita di dati (RTO ed RPO) e i costi e la complessità di implementazione della strategia. Dovresti evitare di implementare una strategia che sia più severa del necessario, in quanto questo comporterebbe costi aggiuntivi. 

 Ad esempio, nel diagramma seguente, l'azienda ha stabilito l'RTO massimo concesso e il limite di spesa per la strategia di ripristino del servizio. Considerati gli obiettivi dell'azienda, le strategie di ripristino di emergenza Pilot Light o di Warm Standby soddisfano sia l'RTO sia i criteri per i costi. 

![\[Grafico che mostra la scelta di una strategia di ripristino di emergenza in base all'RTO e ai costi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/choosing-a-dr-strategy.png)


 Per ulteriori informazioni, consulta [Piano di continuità aziendale](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html). 

1.  **Esamina i modelli con cui la strategia di ripristino di emergenza selezionata può essere implementata.** 

 Questo passaggio consiste nel capire come implementare la strategia selezionata. Le strategie vengono spiegate con Regioni AWS come siti principali e di ripristino. Tuttavia, puoi anche decidere di utilizzare le zone di disponibilità in una singola regione come strategia di ripristino di emergenza, utilizzando aspetti di più strategie. 

 Nei passaggi seguenti puoi applicare la strategia al carico di lavoro specifico. 

 **Backup e ripristino**  

 La strategia di *backup e ripristino* è la meno complessa da implementare, ma richiede più tempo e impegno per il ripristino del carico di lavoro, causando un RTO e un RPO più elevati. È buona pratica creare sempre backup dei dati e copiarli in un altro sito (ad esempio, un altro Regione AWS). 

![\[Diagramma che mostra un'architettura di backup e ripristino\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/backup-restore-architecture.png)


 Per ulteriori informazioni su questa strategia, consulta [Architettura di ripristino di emergenza su AWS, parte II: backup e ripristino con recupero rapido](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/). 

 **Pilot light** 

 Con l'approccio *Pilot Light* puoi replicare i dati dalla regione primaria alla regione di ripristino. Le risorse di base utilizzate per l'infrastruttura del carico di lavoro vengono distribuite nella regione di ripristino; tuttavia sono comunque necessarie risorse aggiuntive ed eventuali dipendenze per rendere funzionale questo stack. Ad esempio, nella Figura 20 non viene implementata alcuna risorsa di calcolo. 

![\[Diagramma che mostra un'architettura pilot light\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/pilot-light-architecture.png)


 Per ulteriori informazioni su questa strategia, consulta [Architettura di ripristino di emergenza su AWS, parte III: Pilot Light e Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). 

 **Warm standby** 

 L'approccio *Warm Standby* garantisce che vi sia una copia ridotta ma completamente funzionale dell'ambiente di produzione in un'altra regione. Questo approccio estende il concetto di Pilot Light e diminuisce il tempo di ripristino, poiché il carico di lavoro è sempre attivo in un'altra regione. Se la regione di ripristino è implementata alla massima capacità, la strategia è nota come *standby a caldo*. 

![\[Figura 21: Diagramma che mostra un'architettura Warm standby\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/warm-standby-architecture.png)


 Se si utilizza Warm Standby o Pilot Light è necessario un aumento delle risorse nella regione di ripristino. Per verificare che sia disponibile capacità sufficiente quando necessario, valuta se usare [prenotazioni di capacità](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) per istanze EC2. Se usi AWS Lambda, la [concorrenza assegnata](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) può fornire ambienti di esecuzione pronti a rispondere immediatamente alle chiamate della funzione. 

 Per ulteriori informazioni su questa strategia, consulta [Architettura di ripristino di emergenza su AWS, parte III: Pilot Light e Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). 

 **Attivo/attivo multi-sito** 

 Puoi eseguire il carico di lavoro simultaneamente in più regioni come parte di una strategia *attivo/attivo multisito*. La strategia attivo/attivo multi-sito serve il traffico da tutte le regioni in cui è distribuita. I clienti possono selezionare questa strategia per motivi diversi dal ripristino di emergenza. Può essere utilizzata per aumentare la disponibilità o nella distribuzione di un carico di lavoro a un pubblico globale (per posizionare l'endpoint più vicino agli utenti e/o per distribuire stack localizzati al pubblico di quella regione). Come strategia di ripristino di emergenza, se il carico di lavoro non può essere supportato in una delle Regioni AWS in cui viene implementato, la regione viene evacuata e vengono usate le regioni rimanenti per garantire la disponibilità. Attivo/attivo multi-sito è la strategia di ripristino operativamente più complessa e dovrebbe essere selezionata solo quando lo richiedono i requisiti aziendali. 

![\[Diagramma che mostra un'architettura attivo/attivo multi-sito\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/multi-site-active-active-architecture.png)


 

 Per ulteriori informazioni su questa strategia, consulta [Architettura di ripristino di emergenza su AWS, parte IV: attivo/attivo multisito](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/). 

 **Ripristino di emergenza di elastico di AWS** 

 Se stai prendendo in considerazione la strategia Pilot Light o di Warm Standby per il ripristino di emergenza, Ripristino di emergenza di elastico di AWS può fornire un approccio alternativo con vantaggi ancora migliori. Elastic Disaster Recovery può offrire obiettivi RPO e RTO simili al Warm Standby, ma mantenendo l'approccio a basso costo della strategia Pilot Light. Elastic Disaster Recovery replica i dati dalla regione primaria alla regione di ripristino, usando una protezione continua dei dati per realizzare un RPO misurato in secondi e un RTO che può essere misurato in minuti. Solo le risorse necessarie per replicare i dati vengono implementate nella regione di ripristino, mantenendo i costi ridotti come nella strategia Pilot Light. Quando usi Elastic Disaster Recovery, il servizio coordina e orchestra il ripristino delle risorse di calcolo quando viene avviato come parte di un failover o di un'esercitazione. 

![\[Diagramma dell'architettura che descrive il funzionamento di Ripristino di emergenza di elastico di AWS.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/drs-architecture.png)


 

 **Procedure aggiuntive per la protezione dei dati** 

 Con tutte le strategie devi anche mitigare un disastro relativo ai dati. La replica continua dei dati ti proteggerà da alcuni tipi di disastri, ma non dalla corruzione o dalla distruzione dei dati, a meno che la tua soluzione non includa opzioni per il ripristino point-in-time o il controllo delle versioni dei dati archiviati. Devi anche creare un backup dei dati replicati nel sito di ripristino per creare backup point-in-time in aggiunta alle repliche. 

 **Uso di più zone di disponibilità in una singola Regione AWS** 

 Quando si usano più zone di disponibilità all'interno di un'unica regione, l'implementazione della strategia di ripristino di emergenza usa più elementi delle strategie precedenti. Devi innanzitutto creare un'architettura con disponibilità elevata usando più zone di disponibilità, come mostrato nella Figura 23. Questa architettura usa un approccio attivo/attivo multisito, in quanto le [istanze Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) e l'[Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) hanno risorse implementate in più zone di disponibilità per la gestione attiva delle richieste. L'architettura presenta anche la strategia di standby a caldo, in cui se l'istanza [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) primaria (o la zona di disponibilità stessa) restituisce un errore, l'istanza in standby viene promossa a istanza primaria. 

![\[Figura 24: Diagramma che mostra un'architettura multi-AZ\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/multi-az-architecture2.png)


 Oltre a questa architettura HA, devi aggiungere i backup di tutti i dati richiesti per eseguire il tuo carico di lavoro. Questo aspetto è particolarmente importante per i dati limitati a un'unica zona come i [volumi Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) o i [cluster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Se fallisce una zona di disponibilità, dovrai ripristinare i dati in un'altra zona di disponibilità. Laddove possibile, devi anche copiare i backup di dati su un'altra Regione AWS come livello di protezione aggiuntivo. 

 Un approccio alternativo meno comune alla singola regione, ovvero il ripristino di emergenza multi-AZ, viene descritto nel post di blog [Creazione di applicazioni altamente resilienti usando il Sistema di controllo Amazon Route 53 per il ripristino di applicazioni, parte 1: stack a regione singola](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). In questo caso la strategia adottata è quella di garantire il più possibile l'isolamento tra le zone di disponibilità, ossia come le regioni operano. Usando questa strategia alternativa puoi scegliere un approccio attivo/attivo o attivo/passivo. 

**Nota**  
Alcuni carichi di lavoro hanno requisiti normativi di residenza dei dati. Se questo si applica a un carico di lavoro in una località che attualmente ha solo una Regione AWS, la multi-regione non soddisferà i requisiti aziendali. Le strategie con più zone di disponibilità offrono una buona protezione dalla maggior parte dei disastri. 

1.  **Valuta le risorse del tuo carico di lavoro e quale sarà la loro configurazione nella regione di ripristino prima del failover (durante la normale operatività).** 

 Per l'infrastruttura e le risorse AWS, usa una soluzione Infrastruttura come codice (IaC), come [AWS CloudFormation](https://aws.amazon.com/cloudformation) o strumenti di terze parti come Hashicorp Terraform. Per un'implementazione tra più account e regioni con un'unica operazione, puoi usare [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Per le strategie multi-sito attivo/attivo e standby a caldo, l'infrastruttura distribuita nella tua regione di ripristino ha le stesse risorse della regione principale. Per le strategie Pilot Light e Warm Standby l'infrastruttura distribuita richiederà azioni aggiuntive per essere pronta per la produzione. Usando [parametri](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) e [logica condizionale](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) in CloudFormation, puoi controllare se uno stack implementato sia attivo o in standby con [un unico modello](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). Quando usi Elastic Disaster Recovery, il servizio replica e orchestra il ripristino delle configurazioni delle applicazioni e delle risorse di calcolo. 

 Tutte le strategie di ripristino di emergenza richiedono il backup delle origini dati all'interno della Regione AWS e i backup vengono quindi copiati nella regione di ripristino. [AWS Backup](https://aws.amazon.com/backup/) offre una visualizzazione centralizzata in cui puoi configurare, pianificare e monitorare i backup per queste risorse. Per gli approcci Pilot Light, di Warm Standby e attivo/attivo multisito, devi anche replicare i dati dalla regione primaria alle risorse di dati nella regione di ripristino, come [Amazon Relational Database Service (Amazon RDS), istanze di database o tabelle ](https://aws.amazon.com/rds)[Amazon DynamoDB](https://aws.amazon.com/dynamodb). Queste risorse di dati sono pertanto attive e pronte per servire le richieste nella regione di ripristino. 

 Per ulteriori informazioni sul funzionamento dei servizi AWS tra regioni, consulta questa serie di blog sulla [creazione di un'applicazione in più regioni con servizi AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/). 

1.  **Stabilisci e implementa le modalità con cui preparerai la tua regione al failover nel momento in cui sarà necessario (durante un evento disastroso).** 

 Per la strategia attivo/attivo multisito, il failover significa evacuare una regione e usare le regioni attive rimanenti. In generale, tali regioni sono pronte per accettare il traffico. Per le strategie Pilot Light e di Warm Standby, le azioni di ripristino devono implementare le risorse mancanti, come le istanze EC2 nella Figura 20, insieme a risorse mancanti di altro tipo. 

 Per tutte le strategie precedenti potresti dover promuovere istanze di database i sola lettura a istanze di lettura/scrittura principali. 

 Per il backup e il ripristino, il ripristino dei dati dai backup crea risorse per tali dati, come volumi EBS, istanze DB RDS e tabelle DynamoDB. Devi anche ripristinare l'infrastruttura e distribuire il codice. Puoi usare AWS Backup per ripristinare i dati nella regione di ripristino. Consulta [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md) per ulteriori dettagli. La ricreazione dell'infrastruttura include la creazione di risorse come le istanze EC2, insieme a [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), alle sottoreti e ai gruppi di sicurezza necessari. Puoi automatizzare gran parte del processo di ripristino. Per informazioni su come fare, consulta [questo post di blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/). 

1.  **Stabilisci e implementa le modalità con cui reindirizzerai il traffico al failover nel momento in cui sarà necessario (durante un evento disastroso).** 

 Questa operazione di failover può essere avviata automaticamente o manualmente. Il failover avviato automaticamente in base a controlli dell'integrità o allarmi deve essere usato con attenzione, poiché un failover non necessario (falso allarme) comporta dei costi in termini di non disponibilità e perdita dei dati. Pertanto si usa spesso il failover avviato manualmente. In questo caso, devi comunque automatizzare i passaggi del failover, in modo che l'avvio manuale si limiti al clic su un pulsante. 

 Esistono diverse opzioni di gestione del traffico da considerare quando si usano i servizi AWS. Un'opzione consiste nell'usare [Amazon Route 53](https://aws.amazon.com/route53). Con Amazon Route 53 puoi associare più endpoint IP in una o più Regioni AWS con un nome di dominio Route 53. Per implementare un failover avviato manualmente, puoi usare il [Sistema di controllo Amazon Route 53 per il ripristino di applicazioni](https://aws.amazon.com/route53/application-recovery-controller/), che fornisce un'API del piano dati a disponibilità elevata per reinstradare il traffico nella regione di ripristino. Nella fase di implementazione del failover, usa le operazioni di piano dati ed evita quelle del piano di controllo come descritto in [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md). 

 Per ulteriori informazioni su questa e altre opzioni, consulta [questa sezione del whitepaper sul ripristino di emergenza](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light). 

1.  **Progetta un piano per il failback del carico di lavoro.** 

 Si parla di failback quando un'operazione del carico di lavoro torna alla regione principale, dopo che un vento disastroso è diminuito di intensità. Il provisioning di infrastruttura e codice alla regione principale in genere segue gli stessi passaggi usati inizialmente, affidandosi all'infrastruttura come codice e alle pipeline di distribuzione del codice. La sfida del failback è il ripristino dei data store e la garanzia della loro coerenza con la regione di ripristino attiva. 

 Nello stato di failover i database nella regione di ripristino sono attivi e hanno dati aggiornati. L'obiettivo è eseguire una nuova sincronizzazione tra la regione di ripristino e la regione principale, per garantire il suo aggiornamento. 

 Alcuni servizi AWS eseguono questa operazione in automatico. Se quando usi [tabelle globali Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/) la tabella nella regione primaria diventa non disponibile, quando torna online DynamoDB riprende la propagazione delle scritture in sospeso. Se usi il [Database globale Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) e un [failover pianificato gestito](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), viene mantenuta la topologia di replica esistente del Database globale Aurora. Pertanto, l'istanza precedente in lettura/scrittura nella regione principale diventa una replica e riceve gli aggiornamenti dalla regione di ripristino. 

 Nei casi in cui questo non è automatico devi ristabilire il database nella regione principale come replica del database nella regione di ripristino. In molti casi questo comporterà l'eliminazione del database principale precedente e la creazione di nuove repliche. Ad esempio, per istruzioni su come fare usando il Database globale Amazon Aurora presupponendo un failover *non pianificato*, consulta questo lab: [Failback di un database globale](https://awsauroralabsmy.com/global/failback/). 

 Dopo un failover, se puoi proseguire l'esecuzione nella tua regione di ripristino, valuta la possibilità di farlo nella tua regione principale. Compieresti comunque tutte le operazioni precedenti per trasformare la precedente regione principale in una regione di ripristino. Alcune organizzazioni eseguono una rotazione pianificata, scambiando periodicamente le regioni principale e di ripristino (ad esempio, ogni tre mesi). 

 Tutti i passaggi richiesti per failover e failback devono essere inseriti in un playbook disponibile a tutti i membri del team, sottoposto periodicamente a revisione. 

 Quando usi Elastic Disaster Recovery, il servizio fornirà assistenza per l'orchestrazione e l'automazione del processo di failback. Per ulteriori informazioni, consulta [Esecuzione di un failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html). 

 **Livello di impegno per il piano di implementazione:** elevato 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md)
+  [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati](rel_planning_for_recovery_objective_defined_recovery.md) 

 **Documenti correlati:** 
+  [AWS Architecture Blog: serie sul ripristino di emergenza](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [Opzioni di ripristino di emergenza nel cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html) 
+  [Build a serverless multi-region, active-active backend solution in an hour](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf) 
+  [Multi-region serverless backend — reloaded](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0) 
+  [RDS: creazione di una replica di lettura in una regione AWS diversa](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn) 
+  [Route 53: configurazione del failover DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) 
+  [S3: replica tra regioni](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) 
+  [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [Che cos'è il Sistema di controllo Route 53 per il ripristino di applicazioni?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [Ripristino di emergenza elastico AWS](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 
+  [HashiCorp Terraform: Get Started - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started) 
+  [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [Marketplace AWS: prodotti che possono essere usati per il ripristino di emergenza](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 

 **Video correlati:** 
+  [Ripristino di emergenza per carichi di lavoro su AWS](https://www.youtube.com/watch?v=cJZw5mrxryA) 
+  [AWS re:Invent 2018: Modelli architetturali per applicazioni attivo/attivo multi-regione (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
+  [Nozioni di base sul ripristino di emergenza elastico AWS \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as) 

 **Esempi correlati:** 
+  [Well-Architected Lab: Ripristino di emergenza](https://wellarchitectedlabs.com/reliability/disaster-recovery/) – Serie di workshop che descrivono le strategie di ripristino di emergenza 

# REL13-BP03 Esecuzione di test sull'implementazione del ripristino di emergenza per convalidare l'implementazione
<a name="rel_planning_for_recovery_dr_tested"></a>

Testa regolarmente il failover nel sito di ripristino per verificare che funzioni correttamente e che sia possibile soddisfare l'RTO e l'RPO.

 **Anti-pattern comuni:** 
+  Non eseguire mai failover di prova in produzione. 

 **Vantaggi dell'adozione di questa best practice:** l'esecuzione regolare di test del piano di ripristino di emergenza permette di verificare che funzionerà quando necessario e che il team è in grado di eseguire la strategia. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Un modello da evitare è lo sviluppo di percorsi di ripristino eseguiti raramente. Ad esempio, è possibile che si disponga di un archivio dati secondario utilizzato per query di sola lettura. Quando scrivi in un archivio dati e quello principale ha un guasto, puoi eseguire il failover verso l'archivio dati secondario. Se non testi frequentemente questo failover, è possibile che i presupposti relativi alle funzionalità dell'archivio dati secondario non siano corretti. La capacità dell'archivio dati secondario, che potrebbe essere stata sufficiente durante l'ultimo test, potrebbe non essere più in grado di tollerare il carico in questo scenario. La nostra esperienza ha dimostrato che l'unico ripristino da errore che funziona è il percorso sottoposto a frequenti test. Per questo è preferibile avere un numero ridotto di percorsi di ripristino. Puoi stabilire dei modelli di ripristino e testarli regolarmente. Se disponi di un percorso di ripristino complesso o critico, devi comunque riprodurre regolarmente il guasto specifico in produzione per convincerti che il percorso di ripristino funzioni. Nell'esempio appena discusso, è necessario eseguire il failover regolarmente in standby, indipendentemente dalle necessità. 

 **Passaggi dell'implementazione** 

1.  Progetta i carichi di lavoro per il ripristino. Esegui regolarmente test dei tuoi percorsi di ripristino. Il calcolo orientato al ripristino identifica le caratteristiche nei sistemi che migliorano il ripristino: isolamento e ridondanza, ripristino a livello di sistema dello stato precedente rispetto alle modifiche, capacità di fornire diagnostica, ripristino automatico, progettazione modulare e possibilità di riavvio. Prova il percorso di ripristino per verificare di poter completare il ripristino nel tempo specificato e in base allo stato specificato. Usa i tuoi runbook durante questo ripristino per documentare i problemi e trovare le loro soluzioni prima del test successivo. 

1. Per carichi di lavoro basati su Amazon EC2, usa [Ripristino di emergenza di elastico di AWS](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) per implementare e avviare istanze di prova per la strategia di ripristino di emergenza. Ripristino di emergenza di elastico di AWS permette di eseguire esercitazioni in modo efficiente, semplificando la preparazione a un evento di failover. Puoi anche avviare spesso le istanze usando Elastic Disaster Recovery per scopi di test ed esercitazione senza reindirizzare il traffico.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [AWS Architecture Blog: serie sul ripristino di emergenza](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [Marketplace AWS: prodotti che possono essere usati per il ripristino di emergenza](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 
+  [Ripristino di emergenza di elastico di AWS](https://aws.amazon.com/disaster-recovery/) 
+  [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [Ripristino di emergenza di elastico di AWS – Preparazione per il failover](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html) 
+  [Il progetto di informatica orientata al ripristino Berkeley/Stanford](http://roc.cs.berkeley.edu/) 
+  [Che cos'è il Simulatore di iniezione guasti AWS?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 

 **Video correlati:** 
+  [AWS re:Invent 2018: Modelli architetturali per applicazioni attivo/attivo multi-regione](https://youtu.be/2e29I3dA8o4) 
+  [AWS re:Invent 2019: Backup-e ripristino e soluzioni di ripristino di emergenza con AWS](https://youtu.be/7gNXfo5HZN8) 

 **Esempi correlati:** 
+  [Well-Architected Lab – Esecuzione di test per la resilienza](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/) 

# REL13-BP04 Gestione della deviazione di configurazione nel sito o nella Regione del ripristino di emergenza
<a name="rel_planning_for_recovery_config_drift"></a>

 Assicurati che l'infrastruttura, i dati e la configurazione soddisfino le esigenze del sito o nella Regione del ripristino di emergenza. Ad esempio, controlla che le AMI e le quote di servizio siano aggiornate. 

 AWS Config monitora e registra in modo continuo le configurazioni delle risorse AWS. È in grado di rilevare le deviazioni e attivare [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) per risolverle e attivare allarmi. AWS CloudFormation è inoltre in grado di rilevare le deviazioni negli stack distribuiti. 

 **Anti-pattern comuni:** 
+  Non eseguire aggiornamenti nelle sedi di ripristino, quando esegui modifiche di configurazione o di infrastruttura nelle tue sedi principali. 
+  Ignorare le limitazioni potenziali (ad esempio le differenze di servizio) nelle sedi di disaster recovery e principali. 

 **Vantaggi dell'adozione di questa best practice:** Assicurarsi che l'ambiente di disaster recovery sia coerente con quello esistente garantisce il ripristino completo. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Assicurati che le tue pipeline di distribuzione riforniscano sia i siti principali che di backup. Le pipeline per la distribuzione di applicazioni in produzione devono essere distribuite in tutte le posizioni della strategia di disaster recovery specificate, inclusi gli ambienti di sviluppo e test. 
+  Abilitazione di AWS Config per monitorare le potenziali posizioni di deviazione. Utilizza le regole AWS Config per creare sistemi in grado di applicare le strategie di disaster recovery e generare avvisi quando rilevano una deviazione. 
  +  [Correzione di risorse AWS non conformi in base alle regole di Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) 
  +  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  Utilizza AWS CloudFormation per distribuire la tua infrastruttura. AWS CloudFormation è in grado di rilevare le deviazioni tra ciò che i modelli di CloudFormation specificano e ciò che viene effettivamente distribuito. 
  +  [AWS CloudFormation: rilevamento delle deviazioni su un intero stack CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS CloudFormation: rilevamento delle deviazioni su un intero stack CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html) 
+  [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [In che modo è possibile implementare una soluzione di gestione della configurazione dell'infrastruttura in AWS?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected) 
+  [Correzione di risorse AWS non conformi in base alle regole di Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) 

 **Video correlati:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli di architettura per applicazioni attive-attive multiregione) (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 

# REL13-BP05 Automatizzazione del ripristino
<a name="rel_planning_for_recovery_auto_recovery"></a>

 Utilizza AWS o strumenti di terze parti per automatizzare il ripristino del sistema e instradare il traffico verso il sito o la Regione del ripristino di emergenza. 

 In base ai controlli di integrità configurati, i servizi AWS, come Elastic Load Balancing e AWS Auto Scaling, possono distribuire il carico a zone di disponibilità integre, mentre i servizi, come Amazon Route 53 e AWS Global Accelerator, instradano il carico a Regioni AWS integre. Amazon Route 53 Application Recovery Controller aiuta a gestire e coordinare il failover utilizzando i controlli di disponibilità e le funzionalità di controlli di routing. Queste funzionalità monitorano continuamente la capacità dell'applicazione di riprendersi dai guasti e permettono di controllarne il ripristino delle applicazioni su più Regioni AWS, zone di disponibilità e on-premise. 

 Per i carichi di lavoro su data center fisici o virtuali o cloud privati, [Ripristino di emergenza elastico AWS](https://aws.amazon.com/cloudendure-disaster-recovery/), disponibile tramite Marketplace AWS, consente alle organizzazioni di organizzare una strategia di ripristino di emergenza su AWS. CloudEndure supporta, inoltre, il ripristino di emergenza tra Regioni e zone di disponibilità in AWS. 

 **Anti-pattern comuni:** 
+  L'implementazione di failover e failback automatici identici può causare flapping quando si verifica un errore. 

 **Vantaggi dell'adozione di questa best practice:** Il ripristino automatico riduce i tempi di ripristino eliminando la possibilità di errori manuali. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Automatizzazione dei percorsi di ripristino. Per tempi di ripristino brevi, non è possibile servirsi del giudizio umano e dell'azione per scenari di disponibilità elevata. Il sistema dovrebbe ripristinarsi automaticamente in ogni situazione. 
  +  Usa il ripristino di emergenza CloudEndure per failover e failback automatizzati. Il ripristino di emergenza CloudEndure replica in modo continuo le macchine (tra cui sistema operativo, configurazione dello stato del sistema, database, applicazioni e file) in un'area di gestione temporanea a basso costo nell'Account AWS di destinazione e nella Regione preferita. In caso di emergenza, è possibile indicare a CloudEndure Disaster Recovery di avviare automaticamente migliaia di macchine nello stato di provisioning completo in pochi minuti. 
    +  [Performing a Disaster Recovery Failover and Failback](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm) 
    +  [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Partner APN: partner che possono assistere con disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [Marketplace AWS: prodotti utilizzabili per il disaster recovery](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [Ripristino di emergenza CloudEndure in AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L) 
+  [Ripristino di emergenza dei carichi di lavoro su AWS: ripristino nel cloud (whitepaper di AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 

 **Video correlati:** 
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (Modelli architetturali per applicazioni attive-attive su più Regioni) (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 

# Efficienza delle prestazioni
<a name="a-performance-efficiency"></a>

Il principio dell'efficienza delle prestazioni comprende l'abilità di utilizzare in modo efficiente le risorse di elaborazione per soddisfare i requisiti del sistema e conservare tale efficienza a seconda dei cambiamenti della domanda e dell'evoluzione delle tecnologie. È possibile trovare linee guida prescrittive sull'implementazione nel [Whitepaper sul principio dell'efficienza delle prestazioni](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html?ref=wellarchitected-wp).

**Topics**
+ [Scelta dell'architettura](a-selection.md)
+ [Elaborazione e hardware](a-compute-hardware.md)
+ [Gestione dati](a-data-management.md)
+ [Reti e distribuzione di contenuti](a-networking-delivery.md)
+ [Processo e cultura](a-process-culture.md)

# Scelta dell'architettura
<a name="a-selection"></a>

**Topics**
+ [PERF 1. In che modo selezioni le risorse e l'architettura cloud appropriate per il tuo carico di lavoro?](perf-01.md)

# PERF 1. In che modo selezioni le risorse e l'architettura cloud appropriate per il tuo carico di lavoro?
<a name="perf-01"></a>

 La soluzione ottimale per un determinato carico di lavoro può variare e le soluzioni spesso combinano molteplici approcci. I carichi di lavoro Well-Architected utilizzano soluzioni multiple e impiegano funzionalità diverse per migliorare le prestazioni. 

**Topics**
+ [PERF01-BP01 Informazioni e identificazione dei servizi e delle funzionalità cloud disponibili](perf_architecture_understand_cloud_services_and_features.md)
+ [PERF01-BP02 Utilizzo delle indicazioni del provider cloud o di un partner appropriato per conoscere gli schemi di architettura e le best practice](perf_architecture_guidance_architecture_patterns_best_practices.md)
+ [PERF01-BP03 Influenza dei costi nelle decisioni sull'architettura](perf_architecture_factor_cost_into_architectural_decisions.md)
+ [PERF01-BP04 Valutazione dell'influenza dei compromessi sui clienti e sull'efficienza dell'architettura](perf_architecture_evaluate_trade_offs.md)
+ [PERF01-BP05 Uso delle policy e delle architetture di riferimento](perf_architecture_use_policies_and_reference_architectures.md)
+ [PERF01-BP06 Uso del benchmarking per guidare le decisioni sull'architettura](perf_architecture_use_benchmarking.md)
+ [PERF01-BP07 Uso di un approccio basato sui dati per le scelte dell'architettura](perf_architecture_use_data_driven_approach.md)

# PERF01-BP01 Informazioni e identificazione dei servizi e delle funzionalità cloud disponibili
<a name="perf_architecture_understand_cloud_services_and_features"></a>

 Informati continuamente e identifica i servizi e le configurazioni disponibili che ti aiutano a prendere le decisioni giuste sull'architettura e a migliorare l'efficienza delle prestazioni dei carichi di lavoro. 

 **Anti-pattern comuni:** 
+  Utilizzi il cloud come data center in co-location. 
+  Non stai modernizzando la tua applicazione con la migrazione al cloud. 
+  Stai solo usando un tipo di archiviazione per tutte le cose che devono essere conservate in modo persistente. 
+  Se necessario, utilizzi tipi di istanze strettamente correlate ai tuoi standard attuali, ma più grandi. 
+  Distribuisci e gestisci le tecnologie disponibili come servizi gestiti. 

 **Vantaggi dell'adozione di questa best practice:** Prendendo in considerazione nuovi servizi e configurazioni, puoi migliorare notevolmente le prestazioni, ridurre i costi e ottimizzare le attività necessarie per mantenere il carico di lavoro. Puoi anche accelerare il time-to-value per i prodotti abilitati al cloud. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 AWS rilascia continuamente nuovi servizi e funzionalità in grado di migliorare le prestazioni e ridurre i costi dei carichi di lavoro del cloud. Rimanere aggiornati su questi nuovi servizi e funzionalità è fondamentale per mantenere l'efficacia delle prestazioni nel cloud. La modernizzazione dell'architettura dei carichi di lavoro consente inoltre di accelerare la produttività, promuovere l'innovazione e sbloccare ulteriori opportunità di crescita. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Esegui l'inventario del software e dell'architettura del carico di lavoro per i servizi correlati. Determina su quale categoria di prodotti ottenere ulteriori informazioni. 
+  Esplora le offerte AWS per individuare e conoscere i servizi e le opzioni di configurazione pertinenti che possono aiutarti a migliorare le prestazioni e ridurre i costi e la complessità operativa. 
  +  [Novità di AWS](https://aws.amazon.com/new/) 
  +  [Blog AWS](https://aws.amazon.com/blogs/) 
  +  [AWS Skill Builder](https://skillbuilder.aws/) 
  +  [Eventi e webinar AWS](https://aws.amazon.com/events/) 
  +  [AWS Training e certificazioni](https://www.aws.training/) 
  +  [Canale YouTube di AWS](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg) 
  +  [Workshop di AWS](https://workshops.aws/) 
  +  [Community AWS](https://aws.amazon.com/events/asean/community-and-events/) 
+  Usa gli ambienti di sperimentazione (sandbox) non di produzione per apprendere e sperimentare nuovi servizi senza incorrere in costi aggiuntivi. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Centro di progettazione AWS](https://aws.amazon.com/architecture/) 
+  [AWS Partner Network](https://aws.amazon.com/partners/) 
+  [Portfolio di soluzioni AWS](https://aws.amazon.com/solutions/) 
+  [Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [Costruisci applicazioni moderne su AWS](https://aws.amazon.com/modern-apps/) 

 **Video correlati:** 
+  [La mia architettura](https://aws.amazon.com/architecture/this-is-my-architecture/) 

 **Esempi correlati:** 
+  [Esempi di AWS](https://github.com/aws-samples) 
+  [Esempi di SDK AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 

# PERF01-BP02 Utilizzo delle indicazioni del provider cloud o di un partner appropriato per conoscere gli schemi di architettura e le best practice
<a name="perf_architecture_guidance_architecture_patterns_best_practices"></a>

 Usa le risorse aziendali del cloud come documentazione, solutions architect, servizi professionali o partner appropriati per guidare le tue decisioni sull'architettura. Queste risorse ti aiutano a rivedere e migliorare l'architettura per ottenere prestazioni ottimali. 

 **Anti-pattern comuni:** 
+  AWS è usato come un comune provider di servizi cloud. 
+  I servizi AWS vengono utilizzati in modo diverso rispetto alla loro progettazione iniziale. 
+  Le indicazioni vengono seguite senza considerare il contesto aziendale. 

 **Vantaggi dell'adozione di questa best practice:** avvalersi della guida di un provider di servizi cloud o di un partner appropriato può aiutarti a fare le scelte giuste per l'architettura del tuo carico di lavoro e darti fiducia nelle tue decisioni. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 AWS offre un'ampia scelta di linee guida, documentazione e risorse che possono aiutarti a creare e gestire i carichi di lavoro del cloud in modo efficiente. La documentazione AWS fornisce esempi di codice, esercitazioni e spiegazioni dettagliate sui servizi. Oltre alla documentazione, AWS offre programmi di formazione e certificazione, solutions architect e servizi professionali che i clienti possono usare per esplorare diversi aspetti dei servizi cloud e implementare un'architettura cloud efficiente su AWS. 

 Sfrutta queste risorse per ottenere approfondimenti sulle informazioni e sulle best practice preziose per risparmiare tempo e ottenere risultati migliori nel Cloud AWS. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Consulta la documentazione e le linee guida AWS e segui le best practice. Queste risorse possono aiutarti a scegliere e configurare i servizi in modo efficace e a ottenere prestazioni migliori. 
  +  [Documentazione di AWS](https://docs.aws.amazon.com/) (come guide utente e white paper) 
  +  [Blog AWS](https://aws.amazon.com/blogs/) 
  +  [AWS Training e certificazioni](https://www.aws.training/) 
  +  [Canale YouTube di AWS](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg) 
+  Partecipa agli eventi per i partner AWS (come summit AWS a livello mondiale, gruppi di utenti di AWS re:Invent e workshop) per apprendere dagli esperti AWS le best practice per l'utilizzo dei servizi AWS. 
  +  [Eventi e webinar AWS](https://aws.amazon.com/events/) 
  +  [Workshop di AWS](https://workshops.aws/) 
  +  [Community AWS](https://aws.amazon.com/events/asean/community-and-events/) 
+  Contatta AWS per ricevere assistenza quando ti occorrono ulteriori indicazioni o informazioni sui prodotti. Gli AWS Solutions Architect e [AWS Professional Services](https://aws.amazon.com/professional-services/) forniscono linee guida per l'implementazione della soluzione. [I Partner AWS](https://aws.amazon.com/partners/) mettono a disposizione la propria competenza su AWS per aiutarti ad assicurare alla tua azienda agilità ed innovazione. 
+  utilizza [Supporto](https://aws.amazon.com/contact-us/) se hai bisogno di supporto tecnico per utilizzare un servizio in modo efficace. [I nostri piani di assistenza](https://aws.amazon.com/premiumsupport/plans/) sono pensati per offrirti il giusto mix di strumenti e competenze in modo da poter conseguire il successo con AWS ottimizzando le prestazioni, gestendo i rischi e tenendo sotto controllo i costi. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Centro di progettazione AWS](https://aws.amazon.com/architecture/) 
+  [Portfolio di soluzioni AWS](https://aws.amazon.com/solutions/) 
+  [Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [Supporto Enterprise di AWS](https://aws.amazon.com/premiumsupport/plans/enterprise/) 

 **Video correlati:** 
+  [La mia architettura](https://aws.amazon.com/architecture/this-is-my-architecture/) 

 **Esempi correlati:** 
+  [Esempi di AWS](https://github.com/aws-samples) 
+  [Esempi di SDK AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 

# PERF01-BP03 Influenza dei costi nelle decisioni sull'architettura
<a name="perf_architecture_factor_cost_into_architectural_decisions"></a>

 Tieni conto dei costi nelle decisioni sull'architettura per migliorare l'utilizzo delle risorse e l'efficienza delle prestazioni del tuo carico di lavoro cloud. Quando si è consapevoli delle implicazioni dei costi del carico di lavoro cloud, è più probabile che si utilizzino risorse efficienti e si riducano le procedure inutili. 

 **Anti-pattern comuni:** 
+  Utilizzi una sola famiglia di istanze. 
+  Ometti di valutare le soluzioni con licenza rispetto alle soluzioni open-source. 
+  Non definisci le policy del ciclo di vita dell'archiviazione. 
+  Non esamini i nuovi servizi e funzionalità del Cloud AWS. 
+  Utilizzi solo lo storage a blocchi. 

 **Vantaggi dell'adozione di questa best practice:** La contabilizzazione dei costi nel processo decisionale consente di utilizzare risorse più efficienti ed esplorare altri investimenti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 L'ottimizzazione dei carichi di lavoro in base ai costi può migliorare l'utilizzo delle risorse ed evitare sprechi nel carico di lavoro cloud. Tenere conto dei costi nelle decisioni sull'architettura di solito include il corretto dimensionamento dei componenti del carico di lavoro e l'abilitazione dell'elasticità, comportando una migliore efficienza delle prestazioni del carico di lavoro cloud. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Stabilisci gli obiettivi di costo, come i limiti del budget, per il tuo carico di lavoro cloud. 
+  Identifica i componenti chiave, come istanze e archiviazione, che determinano il costo del carico di lavoro. Puoi utilizzare [Calcolatore dei prezzi AWS](https://calculator.aws/#/) e [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) per identificare i principali fattori di costo del carico di lavoro. 
+  utilizza [Migliori pratiche di ottimizzazione dei costi di Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) per ottimizzare questi componenti chiave in termini di costi. 
+  Monitora e analizza continuamente i costi per identificare le opportunità di ottimizzazione dei costi nel tuo carico di lavoro. 
  +  utilizza [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/) per ricevere gli avvisi per i costi inaccettabili. 
  +  utilizza [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) oppure [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) per ottenere suggerimenti sull'ottimizzazione dei costi. 
  +  utilizza [Rilevamento delle anomalie dei costi AWS](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) per rilevare in modo automatico le anomalie dei costi e analizzare la causa principale. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [A Detailed Overview of the Cost Intelligence Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/a-detailed-overview-of-the-cost-intelligence-dashboard/) 
+  [Centro di progettazione AWS](https://aws.amazon.com/architecture/) 
+  [AWS Partner Network](https://aws.amazon.com/partners/) 
+  [Portfolio di soluzioni AWS](https://aws.amazon.com/solutions/) 
+  [Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 

 **Video correlati:** 
+  [La mia architettura](https://aws.amazon.com/architecture/this-is-my-architecture/) 
+  [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg&ref=wellarchitected) 

 **Esempi correlati:** 
+  [Esempi di AWS](https://github.com/aws-samples) 
+  [Esempi di SDK AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 
+  [Rightsizing with Compute Optimizer and Memory utilization enabled (Dimensionamento corretto con Compute Optimizer e l'utilizzo della memoria abilitati)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 
+  [AWS Compute Optimizer Demo code (Codice dimostrativo di AWS Compute Optimizer)](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) 

# PERF01-BP04 Valutazione dell'influenza dei compromessi sui clienti e sull'efficienza dell'architettura
<a name="perf_architecture_evaluate_trade_offs"></a>

 Quando valuti i miglioramenti correlati alle prestazioni, determina quali scelte hanno impatto sui clienti e sull'efficienza del carico di lavoro. Ad esempio, se l'utilizzo di un datastore chiave-valore aumenta le prestazioni del sistema, è importante valutare in che modo la consistenza finale intrinseca di questo cambiamento avrà un impatto sui clienti. 

 **Anti-pattern comuni:** 
+  Ritieni che tutti i vantaggi prestazionali debbano essere implementati, anche se ci sono compromessi per l'implementazione. 
+  Valuti di apportare modifiche ai carichi di lavoro solo quando un problema prestazionale ha raggiunto un punto critico. 

 **Vantaggi dell'adozione di questa best practice:** Quando si valutano potenziali miglioramenti relativi alle prestazioni, è necessario decidere se i compromessi per le modifiche sono accettabili con i requisiti del carico di lavoro. In alcuni casi, potrebbe essere necessario implementare controlli aggiuntivi per compensare i compromessi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Identifica le aree critiche della tua architettura in termini di prestazioni e impatto sui clienti. Stabilisci in che modo puoi apportare miglioramenti e quali compromessi comportano, oltre al loro impatto sul sistema e sull'esperienza degli utenti. L'implementazione di cache di dati, ad esempio, può contribuire a migliorare notevolmente le prestazioni ma richiede una strategia ben definita sulle modalità e sui tempi di aggiornamento o di invalidamento dei dati che vi sono contenuti, per evitare che il sistema si comporti in modo non corretto. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Comprendi i requisiti del tuo carico di lavoro e gli accordi sul livello di servizio (SLA). 
+  Definisci chiaramente i fattori di valutazione. I fattori possono riguardare il costo, l'affidabilità, la sicurezza e le prestazioni del carico di lavoro. 
+  Seleziona l'architettura e i servizi in grado di soddisfare le tue esigenze. 
+  Conduci sperimentazioni e proof of concept (POC) per valutare i fattori di compromesso, l'impatto sui clienti e l'efficienza dell'architettura. Di solito, i carichi di lavoro altamente disponibili, performanti e sicuri consumano più risorse cloud offrendo al contempo una esperienza cliente migliore. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Amazon Builders' Library](https://aws.amazon.com/builders-library) 
+  [Quick KPIs (KPI di Amazon QuickSight)](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html) 
+  [RUM Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 
+  [X-Ray Documentation (Documentazione di X-Ray)](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+ [ Understand resiliency patterns and trade-offs to architect efficiently in the cloud ](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)

 **Video correlati:** 
+  [Creazione di un piano di monitoraggio](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) 
+  [Optimize applications through Amazon CloudWatch RUM (Ottimizzazione delle applicazioni tramite RUM Amazon CloudWatch)](https://www.youtube.com/watch?v=NMaeujY9A9Y) 
+  [Demo di Amazon CloudWatch Synthetics](https://www.youtube.com/watch?v=hF3NM9j-u7I) 

 **Esempi correlati:** 
+  [Measure page load time with Amazon CloudWatch Synthetics (Misurare il tempo di caricamento della pagina con Amazon CloudWatch Synthetics)](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance) 
+  [Amazon CloudWatch RUM Web Client (Client Web RUM Amazon CloudWatch)](https://github.com/aws-observability/aws-rum-web) 

# PERF01-BP05 Uso delle policy e delle architetture di riferimento
<a name="perf_architecture_use_policies_and_reference_architectures"></a>

 Utilizza le policy interne e le architetture di riferimento esistenti per la selezione dei servizi e delle configurazioni per essere più efficiente nella progettazione e nell'implementazione del carico di lavoro. 

 **Anti-pattern comuni:** 
+  Usi una vasta gamma di tecnologie che possono influire sul sovraccarico di gestione della tua azienda. 

 **Vantaggi dell'adozione di questa best practice:** La definizione di una policy per la scelta dell'architettura, della tecnologia e del fornitore consentirà di prendere decisioni rapidamente. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Avere politiche interne nella selezione delle risorse e dell'architettura fornisce standard e linee guida da seguire quando si effettuano scelte architettoniche. Queste linee guida semplificano il processo decisionale nella scelta del servizio cloud giusto e possono contribuire a migliorare l'efficienza delle prestazioni. Distribuisci il carico di lavoro utilizzando policy o architetture di riferimento. Integra i servizi nell'implementazione cloud, quindi utilizza i test delle prestazioni per verificare che i requisiti prestazionali siano sempre rispettati. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Comprendi chiaramente i requisiti del tuo carico di lavoro cloud. 
+  Rivedi le policy interne ed esterne per identificare quelle più pertinenti. 
+  Utilizza le architetture di riferimento appropriate fornite dalle best practice AWS o di settore. 
+  Crea un contesto composto da policy, standard, architetture di riferimento e linee guida prescrittive per situazioni comuni. In questo modo i tuoi team possono muoversi più velocemente. Personalizza le risorse per il tuo settore verticale, se applicabile. 
+  Convalida queste policy e architetture di riferimento per il tuo carico di lavoro in ambienti di sperimentazione (sandbox). 
+  Rimani aggiornato con gli standard e gli aggiornamenti AWS del settore per assicurarti che le tue policy e le architetture di riferimento ottimizzino il carico di lavoro cloud. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Centro di progettazione AWS](https://aws.amazon.com/architecture/) 
+  [AWS Partner Network](https://aws.amazon.com/partners/) 
+  [Portfolio di soluzioni AWS](https://aws.amazon.com/solutions/) 
+  [Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 

 **Video correlati:** 
+  [La mia architettura](https://aws.amazon.com/architecture/this-is-my-architecture/) 

 **Esempi correlati:** 
+  [Esempi di AWS](https://github.com/aws-samples) 
+  [Esempi di SDK AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 

# PERF01-BP06 Uso del benchmarking per guidare le decisioni sull'architettura
<a name="perf_architecture_use_benchmarking"></a>

 Esegui il benchmark delle prestazioni di un carico di lavoro esistente per comprendere le prestazioni sul cloud e guidare le decisioni sull'architettura basate sui dati. 

 **Anti-pattern comuni:** 
+  Fai affidamento su valori di riferimento comuni che non sono indicativi delle caratteristiche del carico di lavoro. 
+  L'unico punto di riferimento è dato dal feedback e dalle percezioni dei clienti. 

 **Vantaggi dell'adozione di questa best practice:** Il benchmarking dell'implementazione corrente ti consente di misurare il miglioramento delle prestazioni. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Utilizza test sintetici di benchmarking per valutare le prestazioni dei componenti durante il carico di lavoro. Di solito, i benchmark sono più rapidi da configurare rispetto ai test di carico e vengono utilizzati per valutare la tecnologia di un componente specifico. Il benchmarking viene spesso utilizzato all'inizio di un nuovo progetto, quando non è ancora disponibile una soluzione completa da sottoporre a test di carico. 

 Puoi creare benchmark personalizzati, oppure utilizzare un test standard di settore, come [TPC-DS](http://www.tpc.org/tpcds/), per eseguire il benchmark dei carichi di lavoro. I benchmark di settore sono utili quando devi confrontare ambienti diversi. Quelli personalizzati, invece, sono indicati per analizzare tipi specifici di operazioni che prevedi di eseguire nell'architettura. 

 In fase di benchmarking, è importante effettuare delle operazioni preliminari sull'ambiente di test al fine di garantire la validità dei risultati. Dovrai eseguire lo stesso benchmark più volte, per verificare di avere acquisito ogni eventuale variazione nel corso del tempo. 

 Dal momento che, di solito, l'esecuzione dei benchmark è più rapida di quella dei test di carico, il benchmarking può essere utilizzato sin dalle prime fasi della pipeline di distribuzione, così da fornire al team feedback più rapidi sulle deviazioni delle prestazioni. Quando valuti un cambiamento significativo in un componente o servizio, i benchmark possono essere un modo rapido per verificare se l'impegno necessario per apportare la modifica sia giustificato. L'utilizzo del benchmarking in combinazione con i test di carico è importante perché questi ultimi forniscono indicazioni sulle prestazioni del carico di lavoro in fase di produzione. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Definisci i parametri (come l'utilizzo della CPU, la latenza o la velocità di trasmissione effettiva) per valutare le prestazioni del tuo carico di lavoro. 
+  Identifica e configura uno strumento di benchmarking adatto al carico di lavoro. Puoi utilizzare servizi AWS come [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)) o uno strumento di terze parti compatibile con il tuo carico di lavoro. 
+  Esegui i test di benchmark e monitora i parametri durante il test. 
+  Analizza e documenta i risultati del benchmarking per identificare eventuali colli di bottiglia e problemi. 
+  Usa i risultati dei test per prendere decisioni sull'architettura e modificare il carico di lavoro. Questa operazione può includere la modifica dei servizi o l'adozione di nuove funzionalità. 
+  Ripeti il tuo carico di lavoro dopo la modifica. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Centro di progettazione AWS](https://aws.amazon.com/architecture/) 
+  [AWS Partner Network](https://aws.amazon.com/partners/) 
+  [Portfolio di soluzioni AWS](https://aws.amazon.com/solutions/) 
+  [Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [RUM Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 
+  [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 

 **Video correlati:** 
+  [La mia architettura](https://aws.amazon.com/architecture/this-is-my-architecture/) 
+  [Optimize applications through Amazon CloudWatch RUM (Ottimizzazione delle applicazioni tramite il RUM Amazon CloudWatch)](https://www.youtube.com/watch?v=NMaeujY9A9Y) 
+  [Demo di Amazon CloudWatch Synthetics](https://www.youtube.com/watch?v=hF3NM9j-u7I) 

 **Esempi correlati:** 
+  [Esempi di AWS](https://github.com/aws-samples) 
+  [Esempi di SDK AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 
+  [Test di carico distribuito](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 
+  [Measure page load time with Amazon CloudWatch Synthetics (Misurare il tempo di caricamento della pagina con Amazon CloudWatch Synthetics)](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance) 
+  [Amazon CloudWatch RUM Web Client (Client Web RUM Amazon CloudWatch)](https://github.com/aws-observability/aws-rum-web) 

# PERF01-BP07 Uso di un approccio basato sui dati per le scelte dell'architettura
<a name="perf_architecture_use_data_driven_approach"></a>

 Definisci un approccio chiaro e basato sui dati per le scelte dell'architettura e verificare che vengano utilizzati i servizi e le configurazioni cloud corretti per soddisfare le tue esigenze aziendali specifiche. 

 **Anti-pattern comuni:** 
+  Ritieni che l'architettura corrente diventi statica e non venga aggiornata nel corso del tempo. 
+  Le tue scelte dell'architettura si basano su ipotesi e presupposizioni. 
+  Introduci modifiche all'architettura nel tempo senza giustificazioni. 

 **Vantaggi dell'adozione di questa best practice:** Con un approccio ben definito per le scelte dell'architettura, utilizzi i dati per influenzare la progettazione del carico di lavoro e prendere decisioni informate nel tempo. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Affidati all'esperienza e alle competenze interne in materia di cloud o utilizza risorse esterne, come casi d’uso pubblicati o whitepaper, per scegliere risorse e servizi per la tua architettura. È necessario definire con cura un processo che incoraggi la sperimentazione e il benchmarking con i servizi che possono essere utilizzati nel carico di lavoro. 

 I backlog dei carichi di lavoro critici devono consistere non solo in storie che offrono funzionalità rilevanti per l'azienda e gli utenti, ma anche in storie tecniche che definiscono la presentazione dell'architettura per il carico di lavoro. Questa presentazione include i nuovi progressi tecnologici e i nuovi servizi e li adotta sulla base di dati e giustificazioni adeguate. Verifica che l'architettura sia a prova di futuro e non diventi obsoleta. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Interagisci con i principali stakeholder per definire i requisiti del carico di lavoro, comprese le prestazioni, la disponibilità e le considerazioni sui costi. Includi fattori quali il numero di utenti e il modello di utilizzo del tuo carico di lavoro. 
+  Crea una presentazione dell'architettura o un backlog tecnologico a cui venga assegnata la priorità insieme al backlog funzionale. 
+  Valuta e identifica i diversi servizi cloud (per maggiori dettagli, consulta [PERF01-BP01 Informazioni e identificazione dei servizi e delle funzionalità cloud disponibili](perf_architecture_understand_cloud_services_and_features.md)). 
+  Esplora i diversi modelli di architettura, come microservizi o serverless, che soddisfano i tuoi requisiti di prestazioni (per maggiori dettagli, consulta [PERF01-BP02 Utilizzo delle indicazioni del provider cloud o di un partner appropriato per conoscere gli schemi di architettura e le best practice](perf_architecture_guidance_architecture_patterns_best_practices.md)). 
+  Consulta altri team, diagrammi di architettura e risorse, come AWS Solution Architects, [Centro di progettazione AWS](https://aws.amazon.com/architecture/)e [AWS Partner Network](https://aws.amazon.com/partners/), per aiutarti a scegliere l'architettura giusta per il tuo carico di lavoro. 
+  Definisci i parametri, come la velocità di trasmissione effettiva e il tempo di risposta, che possono aiutarti a valutare le prestazioni del tuo carico di lavoro. 
+  Sperimenta e utilizza i parametri definiti per convalidare le prestazioni dell'architettura selezionata. 
+  Monitora continuamente e apporta le modifiche necessarie per mantenere ottimali le prestazioni della tua architettura. 
+  Documenta l'architettura e le decisioni selezionate come riferimento per aggiornamenti e apprendimenti futuri. 
+  Rivedi e aggiorna continuamente l'approccio di selezione dell'architettura in base agli apprendimenti, alle nuove tecnologie e ai parametri che indicano un problema o un cambiamento necessario nell'approccio attuale. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Portfolio di soluzioni AWS](https://aws.amazon.com/solutions/) 
+  [Knowledge Center di AWS](https://aws.amazon.com/premiumsupport/knowledge-center/) 

 **Video correlati:** 
+  [La mia architettura](https://aws.amazon.com/architecture/this-is-my-architecture/) 

 **Esempi correlati:** 
+  [Esempi di AWS](https://github.com/aws-samples) 
+  [Esempi di SDK AWS](https://github.com/awsdocs/aws-doc-sdk-examples) 

# Elaborazione e hardware
<a name="a-compute-hardware"></a>

# PERF 2. In che modo selezioni e utilizzi le risorse di elaborazione nel tuo carico di lavoro?
<a name="perf-02"></a>

 La soluzione ottimale di elaborazione per un determinato sistema potrebbe variare in base alla progettazione dell'applicazione, ai modelli di utilizzo e alle impostazioni di configurazione. Le architetture possono utilizzare diverse soluzioni di calcolo per vari componenti e impiegare funzionalità diverse per migliorare le prestazioni. Selezionare la soluzione di elaborazione sbagliata per un'architettura può ridurre l'efficienza delle prestazioni. 

**Topics**
+ [PERF02-BP01 Selezione delle migliori opzioni di elaborazione per il carico di lavoro](perf_compute_hardware_select_best_compute_options.md)
+ [PERF02-BP02 Identificazione delle funzionalità e configurazione di calcolo disponibili](perf_compute_hardware_understand_compute_configuration_features.md)
+ [PERF02-BP03 Raccolta dei parametri relativi al calcolo](perf_compute_hardware_collect_compute_related_metrics.md)
+ [PERF02-BP04 Configurazione e dimensionamento corretto delle risorse di elaborazione](perf_compute_hardware_configure_and_right_size_compute_resources.md)
+ [PERF02-BP05 Dimensionamento dinamico delle risorse di elaborazione](perf_compute_hardware_scale_compute_resources_dynamically.md)
+ [PERF02-BP06 Uso di acceleratori di elaborazione ottimizzati basati su hardware](perf_compute_hardware_compute_accelerators.md)

# PERF02-BP01 Selezione delle migliori opzioni di elaborazione per il carico di lavoro
<a name="perf_compute_hardware_select_best_compute_options"></a>

 La selezione dell'opzione di elaborazione più appropriata per il carico di lavoro consente di migliorare le prestazioni, ridurre i costi non necessari dell'infrastruttura e diminuire le attività operative richieste per mantenere il carico di lavoro. 

 **Anti-pattern comuni:** 
+  Si utilizza la stessa opzione di elaborazione utilizzata in locale. 
+  Non si conoscono le opzioni, le funzionalità e le soluzioni di cloud computing e come queste migliorino le prestazioni di elaborazione. 
+  Si dimensiona in eccesso l'opzione di elaborazione per soddisfare i requisiti di dimensionamento o prestazioni, quando il passaggio a una nuova opzione di elaborazione soddisferebbe le caratteristiche del carico di lavoro in modo più preciso. 

 **Vantaggi dell'adozione di questa best practice:** Identificando i requisiti di elaborazione e valutando le opzioni disponibili è possibile rendere il carico di lavoro più efficiente in termini di risorse. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per ottimizzare i carichi di lavoro cloud e ottenere prestazioni efficienti, è importante selezionare le opzioni di elaborazione più appropriate per il tuo caso d'uso e i requisiti di prestazioni. AWS offre una varietà di opzioni di elaborazione che soddisfano diversi carichi di lavoro nel cloud. Ad esempio, puoi usare [Amazon EC2](https://docs.aws.amazon.com/ec2/) per avviare e gestire server virtuali, [AWS Lambda](https://docs.aws.amazon.com/lambda/?icmpid=docs_homepage_featuredsvcs) eseguire codice senza dover effettuare il provisioning o la gestione dei server, [Amazon ECS](https://aws.amazon.com/ecs/) oppure [Amazon EKS](https://aws.amazon.com/eks/) per eseguire e gestire container, oppure [AWS Batch](https://aws.amazon.com/batch/) per elaborare grandi volumi di dati in parallelo. In base alle tue esigenze di dimensionamento ed elaborazione, scegli e configura la soluzione di elaborazione ottimale per la tua situazione. Puoi anche prendere in considerazione l'utilizzo di più tipi di soluzioni di elaborazione in un unico carico di lavoro in quanto ognuna ha i suoi vantaggi e svantaggi. 

 I passaggi seguenti ti guidano nella selezione delle opzioni di elaborazione giuste per soddisfare le caratteristiche del carico di lavoro e i requisiti prestazionali. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Comprendi i requisiti di elaborazione del tuo carico di lavoro. I requisiti essenziali da considerare includono le esigenze di elaborazione, gli schemi di traffico, gli schemi di accesso ai dati, le esigenze di dimensionamento e i requisiti di latenza. 

1.  Scopri le diverse opzioni di elaborazione disponibili per il tuo carico di lavoro in AWS (come descritto in [PERF01-BP01 Informazioni e identificazione dei servizi e delle funzionalità cloud disponibili](perf_architecture_understand_cloud_services_and_features.md). Ecco alcune importanti opzioni di elaborazione AWS, le caratteristiche e i casi d'uso più comuni:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_compute_hardware_select_best_compute_options.html)

1.  Valuta i costi (come la tariffa oraria o il trasferimento dei dati) e il sovraccarico di gestione (come l'applicazione di patch e il dimensionamento) associati a ciascuna opzione di elaborazione. 

1.  Esegui esperimenti e benchmarking in un ambiente non di produzione per identificare quale opzione di elaborazione può soddisfare al meglio i requisiti del tuo carico di lavoro. 

1.  Dopo aver sperimentato e identificato la tua nuova soluzione di calcolo, pianifica la migrazione e convalida i parametri prestazionali. 

1.  Usa strumenti di monitoraggio AWS come [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) e servizi di ottimizzazione come [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) per ottimizzare continuamente le risorse di elaborazione in base a modelli di utilizzo reali. 

 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Elaborazione in cloud con AWS ](https://aws.amazon.com/products/compute/?ref=wellarchitected) 
+  [Tipi di istanza Amazon EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html?ref=wellarchitected) 
+  [Amazon EKS Container: nodi worker di Amazon EKS ](https://docs.aws.amazon.com/eks/latest/userguide/worker.html?ref=wellarchitected) 
+  [Container Amazon ECS: Istanze di container di Amazon ECS ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html?ref=wellarchitected) 
+  [Funzioni: configurazione della funzione Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html?ref=wellarchitected#function-configuration) 
+ [Prescriptive Guidance for Containers (Guida prescrittiva per i container)](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortText&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23containers&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all) 
+  [Prescriptive Guidance for Serverless (Guida prescrittiva per serverless)](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortText&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23serverless&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all) 

 **Video correlati:** 
+  [How to choose compute option for startups (Come scegliere un'opzione di calcolo per le start-up)](https://aws.amazon.com/startups/start-building/how-to-choose-compute-option/) 
+  [Optimize performance and cost for your AWS compute ](https://www.youtube.com/watch?v=zt6jYJLK8sg) 
+  [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system ](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected) 
+  [Deploy ML models for inference at high performance and low cost](https://www.youtube.com/watch?v=4FqHt5bmS2o) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2](https://www.youtube.com/watch?v=_dvh4P2FVbw&ref=wellarchitected) 

 **Esempi correlati:** 
+  [Migrating the Web application to containers](https://application-migration-with-aws.workshop.aws/en/container-migration.html) 
+  [Esecuzione di un "Hello, World\$1" serverless](https://aws.amazon.com/getting-started/hands-on/run-serverless-code/) 

# PERF02-BP02 Identificazione delle funzionalità e configurazione di calcolo disponibili
<a name="perf_compute_hardware_understand_compute_configuration_features"></a>

 Comprendi le opzioni e le funzionalità di configurazione disponibili per il tuo servizio di elaborazione in modo da fornire la giusta quantità di risorse e migliorare l'efficienza delle prestazioni. 

 **Anti-pattern comuni:** 
+  Non valuti le opzioni di elaborazione o le famiglie di istanze disponibili rispetto alle caratteristiche del carico di lavoro. 
+  Esegui un provisioning eccessivo delle risorse di elaborazione per soddisfare i requisiti di picco della domanda. 

** Vantaggi dell'adozione di questa best practice:** acquisisci familiarità con le funzionalità e le configurazioni di elaborazione di AWS in modo da poter utilizzare una soluzione di elaborazione ottimizzata per soddisfare le caratteristiche e le esigenze del carico di lavoro.

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Ogni soluzione di elaborazione ha disponibili configurazioni e funzionalità specifiche per supportare caratteristiche e requisiti diversi del carico di lavoro. Scopri in che modo puoi completare al meglio il tuo carico di lavoro e quali opzioni di configurazione sono le migliori per la tua applicazione. Esempi di tali opzioni includono la famiglia di istanze, le dimensioni, le caratteristiche (GPU, I/O), il bursting, i timeout, le dimensioni delle funzioni, le istanze di container e la simultaneità. Se per il carico di lavoro è stata utilizzata la stessa opzione di calcolo per oltre quattro settimane e sai già che le caratteristiche resteranno uguali in futuro, puoi utilizzare [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)  per scoprire se la tua attuale opzione di elaborazione è adatta ai carichi di lavoro dal punto di vista della CPU e della memoria. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Comprendi i requisiti del carico di lavoro, come CPU, memoria e latenza. 

1.  Consulta la documentazione e le best practice AWS per scoprire le opzioni di configurazione consigliate che possono contribuire a migliorare le prestazioni dell'elaborazione. Ecco alcune opzioni di configurazione chiave da considerare:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_compute_hardware_understand_compute_configuration_features.html)

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Elaborazione in cloud con AWS ](https://aws.amazon.com/products/compute/?ref=wellarchitected) 
+  [Tipi di istanza Amazon EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html?ref=wellarchitected) 
+  [Controllo degli stati del processore dell'istanza Amazon EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html?ref=wellarchitected) 
+  [Amazon EKS Container: nodi worker di Amazon EKS ](https://docs.aws.amazon.com/eks/latest/userguide/worker.html?ref=wellarchitected) 
+  [Container Amazon ECS: Istanze di container di Amazon ECS ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html?ref=wellarchitected) 
+  [Funzioni: configurazione della funzione Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html?ref=wellarchitected#function-configuration) 

 **Video correlati:** 
+  [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system ](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected) 
+  [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg&ref=wellarchitected) 

 **Esempi correlati:** 
+  [Rightsizing with Compute Optimizer and Memory utilization enabled (Dimensionamento corretto con Compute Optimizer e l'utilizzo della memoria abilitati)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 
+  [AWS Compute Optimizer Demo code (Codice dimostrativo di AWS Compute Optimizer)](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) 

# PERF02-BP03 Raccolta dei parametri relativi al calcolo
<a name="perf_compute_hardware_collect_compute_related_metrics"></a>

 Registra e monitora i parametri relativi all'elaborazione per comprendere meglio le prestazioni delle tue risorse di elaborazione e migliorarne le prestazioni e l'utilizzo. 

 **Anti-pattern comuni:** 
+  Utilizzi solo i file di log manuali per la ricerca dei parametri.  
+  Utilizzi solo i parametri predefiniti registrati dal software di monitoraggio. 
+  Rivedi i parametri solo quando c'è un problema. 

 **Vantaggi dell'adozione di questa best practice:** la raccolta dei parametri relativi alle prestazioni ti aiuta ad allineare le prestazioni delle applicazioni ai requisiti aziendali per garantire il rispetto delle esigenze dei carichi di lavoro. Può anche aiutarti a migliorare costantemente le prestazioni e l'utilizzo delle risorse del tuo carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I carichi di lavoro del cloud possono generare grandi volumi di dati quali parametri, log ed eventi. Nel Cloud AWS, la raccolta dei parametri è un passaggio cruciale per migliorare la sicurezza, l'efficienza in termini di costi, le prestazioni e la sostenibilità. AWS fornisce un'ampia gamma di parametri relativi alle prestazioni utilizzando servizi di monitoraggio, come [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) per fornirti approfondimenti preziosi. Parametri quali l'utilizzo della CPU, l'utilizzo della memoria, l'I/O del disco e il traffico di rete in entrata e in uscita possono fornire approfondimenti sui livelli di utilizzo o sui colli di bottiglia delle prestazioni. Utilizza tali parametri come parte di un approccio basato sui dati per ottimizzare e ottimizzare le risorse del tuo carico di lavoro.  L'ideale sarebbe raccogliere tutti i parametri relativi alle tue risorse di elaborazione in un'unica piattaforma con policy di conservazione implementate per supportare costi e obiettivi operativi. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Identifica quali parametri relativi alle prestazioni sono rilevanti per il tuo carico di lavoro. Raccogli i parametri sull'utilizzo delle risorse e sul modo in cui opera il tuo carico di lavoro nel cloud (come il tempo di risposta e la velocità di trasmissione effettiva). 

   1.  [Parametri predefiniti di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) 

   1.  [Parametri predefiniti di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch-metrics.html) 

   1.  [Parametri predefiniti di Amazon EKS](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/kubernetes-eks-metrics.html) 

   1.  [Parametri predefiniti di Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html) 

   1.  [Parametri di memoria e del disco di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html) 

1.  Scegli e configura la soluzione di registrazione e monitoraggio giusta per il tuo carico di lavoro. 

   1.  [Osservabilità nativa di AWS](https://catalog.workshops.aws/observability/en-US/aws-native) 

   1.  [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/) 

   1.  [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/grafana/latest/userguide/prometheus-data-source.html) 

1.  Definisci il filtro e l'aggregazione richiesti per i parametri in base ai requisiti del tuo carico di lavoro. 

   1.  [Quantify custom application metrics with Amazon CloudWatch Logs and metric filters](https://aws.amazon.com/blogs/mt/quantify-custom-application-metrics-with-amazon-cloudwatch-logs-and-metric-filters/) 

   1.  [Collect custom metrics with Amazon CloudWatch strategic tagging](https://aws.amazon.com/blogs/infrastructure-and-automation/collect-custom-metrics-with-amazon-cloudwatch-strategic-tagging/) 

1.  Configura le policy di conservazione dei dati per i parametri in modo che corrispondano ai tuoi obiettivi operativi e di sicurezza. 

   1.  [Conservazione dei dati predefinita per i parametri CloudWatch](https://aws.amazon.com/cloudwatch/faqs/#AWS_resource_.26_custom_metrics_monitoring) 

   1.  [Conservazione dei dati predefinita per CloudWatch Logs](https://aws.amazon.com/cloudwatch/faqs/#Log_management) 

1.  Se necessario, crea allarmi e notifiche per i parametri in modo da rispondere in modo proattivo ai problemi relativi alle prestazioni. 

   1.  [Create alarms for custom metrics using Amazon CloudWatch anomaly detection](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection.html) 

   1.  [Create metrics and alarms for specific web pages with Amazon CloudWatch RUM](https://aws.amazon.com/blogs/mt/create-metrics-and-alarms-for-specific-web-pages-amazon-cloudwatch-rum/) 

1.  Usa l'automazione per implementare gli agenti di aggregazione di parametri e log. 

   1.  [Automazione AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html?ref=wellarchitected) 

   1.  [OpenTelemetry Collector](https://aws-otel.github.io/docs/getting-started/collector) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Documentazione di Amazon CloudWatch](https://docs.aws.amazon.com/cloudwatch/index.html?ref=wellarchitected) 
+  [Raccolta di parametri e registri da istanze Amazon EC2 e da server on-premise con l'agente di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected) 
+  [Accesso a Amazon CloudWatch Logs per AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html?ref=wellarchitected) 
+  [Utilizzo di CloudWatch Logs con istanze di container](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html?ref=wellarchitected) 
+  [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html?ref=wellarchitected) 
+  [AWS Answers: Centralized Logging (AWS Answers: registrazione centralizzata)](https://aws.amazon.com/answers/logging/centralized-logging/?ref=wellarchitected) 
+  [Servizi AWS che pubblicano parametri CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html?ref=wellarchitected) 
+  [Monitoraggio di Amazon EKS su AWS Fargate](https://aws.amazon.com/blogs/containers/monitoring-amazon-eks-on-aws-fargate-using-prometheus-and-grafana/) 

 **Video correlati:** 
+  [Application Performance Management on AWS (Gestione delle prestazioni delle applicazioni su AWS)](https://www.youtube.com/watch?v=5T4stR-HFas&ref=wellarchitected) 

 **Esempi correlati:** 
+  [Level 100: Monitoring with CloudWatch Dashboards (Livello 100: Monitoraggio con i pannelli di controllo CloudWatch)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) 
+  [Level 100: Monitoring Windows EC2 instance with CloudWatch Dashboards (Livello 100: Monitoraggio dell'istanza EC2 di Windows con i pannelli di controllo CloudWatch)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_windows_ec2_cloudwatch/) 
+  [Level 100: Monitoring an Amazon Linux EC2 instance with CloudWatch Dashboards (Livello 100: Monitoraggio dell'istanza EC2 di Amazon Linux con i pannelli di controllo CloudWatch)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_linux_ec2_cloudwatch/) 

# PERF02-BP04 Configurazione e dimensionamento corretto delle risorse di elaborazione
<a name="perf_compute_hardware_configure_and_right_size_compute_resources"></a>

 Configura e dimensiona correttamente le risorse di elaborazione per soddisfare i requisiti di prestazioni del carico di lavoro ed evitare un utilizzo insufficiente o eccessivo delle risorse. 

 **Anti-pattern comuni:** 
+  Ignori i requisiti di prestazioni del carico di lavoro, con il risultato del provisioning eccessivo o insufficiente delle risorse di elaborazione. 
+  Scegli semplicemente l'istanza più grande o più piccola disponibile per tutti i carichi di lavoro. 
+  Usi una sola famiglia di istanze per semplificare la gestione. 
+  Ignori i suggerimenti di AWS Cost Explorer o Compute Optimizer per il corretto dimensionamento. 
+  Non rivaluti il carico di lavoro in base all'idoneità dei nuovi tipi di istanza. 
+  Certifichi solo un numero limitato di configurazioni di istanza per l'organizzazione. 

 **Vantaggi dell'adozione di questa best practice:** il corretto dimensionamento delle risorse di elaborazione garantisce un funzionamento ottimale nel cloud evitando il provisioning eccessivo o insufficiente delle risorse. Il corretto dimensionamento delle risorse di elaborazione comporta in genere prestazioni ottimali e una migliore esperienza cliente, riducendo al contempo i costi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Il dimensionamento corretto consente alle organizzazioni di gestire la propria infrastruttura cloud in modo efficiente ed economico, rispettando al contempo le esigenze aziendali. Un provisioning eccessivo delle risorse cloud può comportare costi aggiuntivi, mentre un provisioning insufficiente può comportare prestazioni scadenti e un'esperienza negativa per il cliente. AWS fornisce strumenti come [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) e [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) che utilizzano dati storici per fornire consigli per dimensionare correttamente le risorse di elaborazione. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Scegli il tipo di istanza più adatto alle tue esigenze: 
  +  [Come faccio a scegliere il tipo di istanza Amazon EC2 appropriato per il mio carico di lavoro?](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/) 
  +  [Selezione del tipo di istanza basata sugli attributi per il parco istanze Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) 
  +  [Create an Auto Scaling group using attribute-based instance type selection](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) 
  +  [Optimizing your Kubernetes compute costs with Karpenter consolidation](https://aws.amazon.com/blogs/containers/optimizing-your-kubernetes-compute-costs-with-karpenter-consolidation/) 
+  Analizza le varie caratteristiche di prestazione del tuo carico di lavoro e come queste sono correlate a memoria, rete e utilizzo della CPU. Utilizza questi dati per scegliere le risorse che meglio corrispondono al profilo del tuo carico di lavoro e agli obiettivi di prestazioni. 
+  Monitora l'utilizzo delle risorse con gli strumenti di monitoraggio di AWS come Amazon CloudWatch. 
+  Seleziona la configurazione corretta per la risorsa di elaborazione. 
  +  Per i carichi di lavoro effimeri, valuta le [metriche Amazon CloudWatch dell'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) , ad esempio `CPUUtilization` per identificare se l'istanza è sottoutilizzata o sovrautilizzata. 
  +  Per i carichi di lavoro stabili, esegui i controlli con gli strumenti di ridimensionamento di AWS, come AWS Compute Optimizer e AWS Trusted Advisor a intervalli regolari per individuare le opportunità di ottimizzazione e ridimensionamento della risorsa di elaborazione. 
    +  [Well-Architected Lab: Raccomandazioni per il dimensionamento corretto ](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/) 
    +  [Well-Architected Lab: dimensionamento corretto con Compute Optimizer ](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/) 
+  Esegui il test delle modifiche apportate alla configurazione in un ambiente non di produzione prima di implementarle in un ambiente live. 
+  Rivaluta costantemente nuove offerte di elaborazione e confrontale con le esigenze del carico di lavoro. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Elaborazione in cloud con AWS](https://aws.amazon.com/products/compute/) 
+  [Tipi di istanza Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) 
+  [Container Amazon ECS: Istanze di container di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html) 
+  [Amazon EKS Container: nodi worker di Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) 
+  [Funzioni: configurazione della funzione Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) 
+  [Controllo degli stati del processore dell'istanza Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html) 

 **Video correlati:** 
+  [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2](https://www.youtube.com/watch?v=_dvh4P2FVbw) 
+  [Deploy ML models for inference at high performance and low cost](https://www.youtube.com/watch?v=4FqHt5bmS2o) 
+  [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4) 
+  [Semplificare l'elaborazione dei dati per migliorare l'innovazione con strumenti serverless](https://aws.amazon.com/startups/start-building/how-to-choose-compute-option/) 

 **Esempi correlati:** 
+  [Rightsizing with Compute Optimizer and Memory utilization enabled (Dimensionamento corretto con Compute Optimizer e l'utilizzo della memoria abilitati)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 
+  [AWS Compute Optimizer Demo code (Codice dimostrativo di AWS Compute Optimizer)](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) 

# PERF02-BP05 Dimensionamento dinamico delle risorse di elaborazione
<a name="perf_compute_hardware_scale_compute_resources_dynamically"></a>

 Sfrutta l'elasticità del cloud per dimensionare dinamicamente le risorse di elaborazione per soddisfare le tue esigenze ed evitare un provisioning eccessivo o insufficiente per il tuo carico di lavoro. 

 **Anti-pattern comuni:** 
+  Risposta agli allarmi aumentando manualmente la capacità. 
+  Utilizzi le stesse linee guida per il dimensionamento (generalmente infrastruttura statica) di quelle on-premise. 
+  Mantenimento della maggiore capacità dopo un evento di dimensionamento, senza ripristinare quella originale. 

 **Vantaggi dell'adozione di questa best practice:** La configurazione e il test dell'elasticità delle risorse di elaborazione possono aiutarti a risparmiare denaro, mantenere i benchmark delle prestazioni e migliorare l'affidabilità al variare del traffico. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 AWS offre la flessibilità necessaria per dimensionare le risorse in modo dinamico attraverso una varietà di meccanismi di dimensionamento per soddisfare le variazioni della domanda. In combinazione con i parametri relativi all'elaborazione, il dimensionamento dinamico consente ai carichi di lavoro di rispondere automaticamente alle modifiche e utilizzare il set ottimale di risorse di elaborazione per raggiungere l'obiettivo. 

 Puoi adottare varie strategie di approccio per associare l'offerta di risorse alla domanda. 
+  **Approccio al tracciamento degli obiettivi**: monitora il parametro di dimensionamento e aumenta o diminuisci automaticamente la capacità in base alle esigenze. 
+  **Dimensionamento predittivo**: dimensiona in previsione delle tendenze giornaliere e settimanali. 
+  **Approccio basato sulla pianificazione**: imposta il tuo programma di dimensionamento in base alle variazioni di carico prevedibili. 
+  **Scalabilità del servizio**: scegli i servizi (come quelli serverless) che si dimensionano automaticamente per progettazione. 

 Assicurati che le distribuzioni dei carichi di lavoro siano in grado di gestire eventi di dimensionamento. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Istanze di elaborazione, container e funzioni forniscono tutti meccanismi di elasticità, in combinazione con il dimensionamento automatico o sotto forma di funzionalità del servizio. Ecco alcuni esempi di meccanismi di dimensionamento automatico:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_compute_hardware_scale_compute_resources_dynamically.html)
+  Si parla spesso di dimensionamento con servizi di elaborazione come le istanze Amazon EC2 o le funzioni AWS Lambda. Assicurati di considerare anche la configurazione di servizi non di elaborazione come [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/auto-scaling.html) per soddisfare la domanda. 
+  Verifica che i parametri per il dimensionamento corrispondano alle caratteristiche del carico di lavoro da implementare. Se distribuisci un'applicazione di transcodifica video, è previsto il 100% di utilizzo della CPU e non deve essere il parametro principale. Utilizza la profondità della coda dei processi di transcodifica. Puoi utilizzare una [metrica personalizzata](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) per la tua politica di scalabilità, se necessario. Per scegliere la metrica corretta, consulta le linee guida seguenti per Amazon EC2: 
  +  La metrica deve essere una metrica di utilizzo valida e descrivere il livello di impiego di un'istanza. 
  +  Il valore della metrica deve aumentare o diminuire proporzionalmente in base al numero di istanze nel gruppo con Auto Scaling. 
+  Assicurati di utilizzare il [dimensionamento dinamico](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html) invece del [dimensionamento manuale](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) per il gruppo con Auto Scaling in uso. È consigliabile utilizzare le [policy di dimensionamento del monitoraggio degli obiettivi](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) nel dimensionamento dinamico. 
+  Verifica che le implementazioni dei carichi di lavoro siano in grado di gestire entrambi gli eventi di dimensionamento (aumento e riduzione). Ad esempio, puoi usare la [cronologia delle attività](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html) per verificare un'attività di dimensionamento per un gruppo Auto Scaling. 
+  Analizza il tuo carico di lavoro per individuare modelli prevedibili e dimensionare le tue risorse in modo proattivo, anticipando variazioni nella domanda previste e pianificate. Con il dimensionamento predittivo puoi eliminare la necessità di offrire capacità in eccedenza. Per ulteriori informazioni, consulta [Dimensionamento predittivo con Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Elaborazione in cloud con AWS](https://aws.amazon.com/products/compute/) 
+  [Tipi di istanza Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) 
+  [Container Amazon ECS: Istanze di container di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html) 
+  [Amazon EKS Container: nodi worker di Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) 
+  [Funzioni: configurazione della funzione Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) 
+  [Controllo degli stati del processore dell'istanza Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html) 
+  [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/) 
+  [Introducing Karpenter – An Open-Source High-Performance Kubernetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/) 

 **Video correlati:** 
+  [Amazon EC2 foundations](https://www.youtube.com/watch?v=kMMybKqC2Y0) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2](https://www.youtube.com/watch?v=_dvh4P2FVbw) 
+  [Optimize performance and cost for your AWS compute](https://www.youtube.com/watch?v=zt6jYJLK8sg) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4) 
+  [Sviluppa un ambiente di calcolo efficiente dal punto di vista dei costi, delle energie e delle risorse](https://www.youtube.com/watch?v=8zsC5e1eLCg) 

 **Esempi correlati:** 
+  [Esempi di gruppo di Amazon EC2 Auto Scaling](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) 
+  [Implement Autoscaling with Karpenter](https://www.eksworkshop.com/beginner/085_scaling_karpenter/) 

# PERF02-BP06 Uso di acceleratori di elaborazione ottimizzati basati su hardware
<a name="perf_compute_hardware_compute_accelerators"></a>

 Usa gli acceleratori hardware per eseguire determinate funzioni in modo più efficiente rispetto alle alternative basate sulla CPU. 

 **Anti-pattern comuni:** 
+  Nel carico di lavoro non hai confrontato un'istanza generica con un'istanza dedicata in grado di offrire prestazioni più elevate e costi inferiori. 
+  Usi gli acceleratori di calcolo basati su hardware per attività in cui sono più efficienti le alternative basate su CPU. 
+  Utilizzo delle GPU non monitorato. 

**Vantaggi dell'adozione di questa best practice:** utilizzando gli acceleratori basati su hardware, come le unità di elaborazione grafica (GPU) e gli FPGA (Field Programmable Gate Array), è possibile eseguire determinate funzioni di elaborazione in modo più efficiente. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Le istanze a calcolo accelerato forniscono l'accesso agli acceleratori di calcolo basati su hardware, come GPU e FPGA. Questi acceleratori hardware eseguono alcune funzioni, come l'elaborazione grafica o la rilevazione della corrispondenza dei modelli di dati, in modo più efficiente rispetto alle alternative basate su CPU. Molti carichi di lavoro accelerati, come il rendering grafico, la transcodifica e il machine learning, sono altamente variabili in termini di utilizzo di risorse. Esegui questo hardware solo per il tempo necessario e disattivalo con l'automazione quando non serve per migliorare l'efficienza complessiva delle prestazioni. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Identifica quali [istanze a calcolo accelerato](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html) possono soddisfare le tue esigenze. 
+  Per i carichi di lavoro di machine learning, sfrutta l'hardware specifico per il tuo carico di lavoro, come ad esempio [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)e [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/). Le istanze AWS Inferentia come le istanze Inf2 [offrono prestazioni per watt superiori fino al 50% rispetto a istanze Amazon EC2 comparabili](https://aws.amazon.com/machine-learning/inferentia/). 
+  Raccogli i parametri di utilizzo delle istanze a calcolo accelerato. Ad esempio, puoi utilizzare l'agente CloudWatch per raccogliere metriche come `utilization_gpu` e `utilization_memory` per le tue GPU come mostrato nella sezione relativa alla [acquisizione delle metriche della GPU NVIDIA con Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html). 
+  Ottimizza il codice, il funzionamento della rete e le impostazioni degli acceleratori hardware per garantire il pieno utilizzo dell'hardware sottostante. 
  +  [Ottimizza l impostazioni delle GPU](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/optimize_gpu.html) 
  +  [Monitoraggio e ottimizzazione delle GPU nell'AMI per il deep learning](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-gpu.html) 
  +  [Ottimizzazione dell'I/O per la messa a punto delle prestazioni delle GPU dedicate all'addestramento del deep learning in Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/optimizing-i-o-for-gpu-performance-tuning-of-deep-learning-training-in-amazon-sagemaker/) 
+  Utilizza le librerie e i driver per GPU più recenti e performanti. 
+  Utilizza l'automazione per rilasciare le istanze GPU non in uso. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Istanze GPU](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html#gpu-instances) 
+  [Instanze con AWS Trainium](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html#aws-trainium-instances) 
+  [Instanze con AWS Inferentia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html#aws-inferentia-instances) 
+  [Progettiamo\$1 Sviluppo di architetture con chip e acceleratori personalizzati](https://aws.amazon.com/blogs/architecture/lets-architect-custom-chips-and-accelerators/) 
+  [Calcolo accelerato](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing) 
+  [Istanze Amazon EC2 VT1](https://aws.amazon.com/ec2/instance-types/vt1/) 
+  [Come faccio a scegliere il tipo di istanza Amazon EC2 appropriato per il mio carico di lavoro?](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/) 
+  [Scegli il miglior acceleratore IA e compilatore del modello per l'inferenza nella visione artificiale con Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/choose-the-best-ai-accelerator-and-model-compilation-for-computer-vision-inference-with-amazon-sagemaker/) 

 **Video correlati:** 
+  [How to select Amazon EC2 GPU instances for deep learning](https://www.youtube.com/watch?v=4bVrIbgGWEA&ab_channel=AWSEvents) 
+  [Implementazione dell'inferenza deep learning a costi contenuti](https://www.youtube.com/watch?v=WiCougIDRsw&ab_channel=AWSOnlineTechTalks) 

# Gestione dati
<a name="a-data-management"></a>

# PERF 3. In che modo archivi, gestisci e accedi ai dati nel tuo carico di lavoro?
<a name="perf-03"></a>

 La soluzione ottimale per la gestione dei dati in un sistema specifico varia in base al tipo di dati (blocco, file o oggetto), agli schemi di accesso (casuali o sequenziali), alla velocità di trasmissione effettiva necessaria, alla frequenza di accesso (online, offline, archivio), alla frequenza di aggiornamento (WORM, dinamico) e ai vincoli di disponibilità e durata. I carichi di lavoro Well-Architected utilizzano archivi dati appositamente progettati che impiegano diverse funzionalità per migliorare le prestazioni. 

**Topics**
+ [PERF03-BP01 Uso di un archivio dati dedicato che supporta al meglio i requisiti di accesso e archiviazione dei dati](perf_data_use_purpose_built_data_store.md)
+ [PERF03-BP02 Valutazione delle opzioni di configurazione disponibili per datastore](perf_data_evaluate_configuration_options_data_store.md)
+ [PERF03-BP03 Raccolta e registrazione dei parametri delle prestazioni del datastore](perf_data_collect_record_data_store_performance_metrics.md)
+ [PERF03-BP04 Implementazione di strategie per migliorare le prestazioni delle query nel datastore](perf_data_implement_strategies_to_improve_query_performance.md)
+ [PERF03-BP05 Implementa modelli di accesso ai dati che utilizzano la memorizzazione nella cache](perf_data_access_patterns_caching.md)

# PERF03-BP01 Uso di un archivio dati dedicato che supporta al meglio i requisiti di accesso e archiviazione dei dati
<a name="perf_data_use_purpose_built_data_store"></a>

 Comprendi le caratteristiche dei dati (come la condivisione, le dimensioni, la dimensione della cache, gli schemi di accesso, la latenza, la velocità di trasmissione effettiva e la persistenza dei dati) per selezionare i data store (archiviazione o database) dedicati per il tuo carico di lavoro. 

 **Anti-pattern comuni:** 
+  Continui a utilizzare un datastore per via dell'esperienza e delle competenze interne relative a quel particolare tipo di soluzione di database. 
+  Ritieni che tutti i carichi di lavoro abbiano requisiti di accesso e archiviazione dei dati simili. 
+  Non hai implementato un catalogo di dati per eseguire l'inventario dei tuoi asset. 

 **Vantaggi dell'adozione di questa best practice:** la comprensione delle caratteristiche e dei requisiti dei dati ti consente di determinare la tecnologia di archiviazione più efficiente e performante appropriata per le tue esigenze del carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Quando selezioni e implementi l'archiviazione di dati, assicurati che le caratteristiche di query, dimensionamento e archiviazione supportino i requisiti dei dati del carico di lavoro. AWS fornisce numerose tecnologie di database e archiviazione di dati, tra cui archiviazione a blocchi, archiviazione di oggetti, archiviazione di streaming, file system, database relazionali, chiave-valore, di documenti, in memoria, a grafo, di serie temporali e di libro mastro. Ogni soluzione di gestione dei dati offre soluzioni e configurazioni adatte a gestire i tuoi casi d'uso e modelli di dati. Comprendendo le caratteristiche e i requisiti dei dati, puoi abbandonare la tecnologia di archiviazione monolitica e gli approcci restrittivi e validi per tutti, per concentrarti sulla gestione dei dati in modo appropriato. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Esegui un inventario dei vari tipi di dati esistenti nel tuo carico di lavoro. 
+  Comprendi e documenta le caratteristiche e i requisiti dei dati, tra cui: 
  +  Tipo di dati (non strutturati, semi-strutturati, relazionali) 
  +  Volume e crescita dei dati 
  +  Durabilità dei dati: persistenti, effimeri, transitori 
  +  Requisiti ACID (atomicità, coerenza, isolamento, durabilità) 
  +  Schemi di accesso ai dati (con uso intensivo di lettura o scrittura) 
  +  Latenza 
  +  Throughput 
  +  IOPS (operazioni di input/output al secondo) 
  +  Periodo di conservazione dei dati 
+  Scopri i diversi archivi di dati disponibili per il carico di lavoro AWS che possono soddisfare le caratteristiche dei tuoi dati (come descritto in [PERF01-BP01 Informazioni e identificazione dei servizi e delle funzionalità cloud disponibili](perf_architecture_understand_cloud_services_and_features.md)). Alcuni esempi di tecnologie di archiviazione AWS e delle loro caratteristiche chiave sono:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_data_use_purpose_built_data_store.html)
+  Se stai creando una piattaforma di dati, sfrutta [l'architettura moderna dei dati](https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/) su AWS per l’integrazione del data lake, del data warehouse e dei data store creati appositamente. 
+  Le domande chiave da porsi quando si sceglie un data store per il carico di lavoro sono le seguenti:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_data_use_purpose_built_data_store.html)
+  Esegui esperimenti e benchmarking in un ambiente non di produzione per identificare quale datastore può soddisfare al meglio i requisiti del tuo carico di lavoro. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Tipi di volume di Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) 
+  [Storage Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html) 
+  [Amazon EFS: prestazioni di Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/performance.html) 
+  [Amazon FSx for Lustre Performance](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html) 
+  [Amazon FSx for Windows File Server Performance (Prestazioni di Amazon FSx for Windows File Server)](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/performance.html) 
+  [Amazon Glacier: Amazon Glacier documentazione](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html) 
+  [Amazon S3: considerazioni su velocità e prestazioni delle richieste](https://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html) 
+  [Storage cloud con AWS](https://aws.amazon.com/products/storage/) 
+  [Caratteristiche di I/O Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html) 
+  [Database su cloud AWS ](https://aws.amazon.com/products/databases/?ref=wellarchitected) 
+  [AWS Database Caching (Memorizzazione nella cache del database AWS) ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) 
+  [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/?ref=wellarchitected) 
+  [Best practice con Amazon Aurora ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected) 
+  [Prestazioni di Amazon Redshift ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected) 
+  [10 suggerimenti prestazionali su Amazon Athena ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected) 
+  [Best practice di Amazon Redshift Spectrum ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/?ref=wellarchitected) 
+  [Best practice di Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html?ref=wellarchitected) 
+  [Choose between Amazon EC2 and Amazon RDS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/comparison.html) 
+ [ Best practice per l'implementazione di Amazon ElastiCache ](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/BestPractices.html)

 **Video correlati:** 
+  [Deep dive on Amazon EBS](https://www.youtube.com/watch?v=wsMWANWNoqQ) 
+  [Optimize your storage performance with Amazon S3](https://www.youtube.com/watch?v=54AhwfME6wI) 
+ [Modernize apps with purpose-built databases](https://www.youtube.com/watch?v=V-DiplATdi0)
+ [ Amazon Aurora storage demystified: How it all works ](https://www.youtube.com/watch?v=uaQEGLKtw54)
+ [ Amazon DynamoDB deep dive: Advanced design patterns ](https://www.youtube.com/watch?v=6yqfmXiZTlM)

 **Esempi correlati:** 
+  [Driver CSI di Amazon EFS](https://github.com/kubernetes-sigs/aws-efs-csi-driver) 
+  [Driver CSI di Amazon EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) 
+  [Utility di Amazon EFS](https://github.com/aws/efs-utils) 
+  [Amazon EBS Autoscale](https://github.com/awslabs/amazon-ebs-autoscale) 
+  [Esempi di Amazon S3](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html) 
+  [Optimize Data Pattern Using Amazon Redshift Data Sharing (Ottimizzare lo schema dei dati con la condivisione dei dati di Amazon Redshift)](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/) 
+  [Migrazioni dei database](https://github.com/aws-samples/aws-database-migration-samples) 
+  [MS SQL Server - AWS Database Migration Service (AWS DMS) Replication Demo](https://github.com/aws-samples/aws-dms-sql-server) 
+  [Database Modernization Hands On Workshop (Workshop pratico sulla modernizzazione dei database)](https://github.com/aws-samples/amazon-rds-purpose-built-workshop) 
+  [Esempi di Amazon Neptune](https://github.com/aws-samples/amazon-neptune-samples) 

# PERF03-BP02 Valutazione delle opzioni di configurazione disponibili per datastore
<a name="perf_data_evaluate_configuration_options_data_store"></a>

 Comprendi e valuta le varie funzionalità e opzioni di configurazione disponibili per i tuoi datastore per ottimizzare lo spazio di archiviazione e le prestazioni per il tuo carico di lavoro. 

 **Anti-pattern comuni:** 
+  Utilizzi un solo tipo di storage, ad esempio Amazon EBS, per tutti i carichi di lavoro. 
+  Utilizzi la capacità di IOPS allocata per tutti i carichi di lavoro senza test reali su tutti i livelli di archiviazione. 
+  Non conosci le opzioni di configurazione della soluzione di gestione dei dati scelta. 
+  Ti basi soltanto sull'aumento delle dimensioni dell'istanza, senza tenere conto di altre opzioni di configurazione disponibili. 
+  Non esegui il test delle caratteristiche di dimensionamento del tuo datastore. 

 **Vantaggi dell'adozione di questa best practice:** Esplorare le configurazioni del datastore e sperimentare con esse può consentire di ridurre il costo dell'infrastruttura, migliorare le prestazioni e ridurre l'impegno richiesto per mantenere i carichi di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Un carico di lavoro può utilizzare uno o più datastore in base ai requisiti di archiviazione e accesso ai dati. Per ottimizzare prestazioni, efficienza e costi, è necessario valutare gli schemi di accesso ai dati per determinare le configurazioni appropriate del datastore. Nella valutazione delle opzioni di datastore, prendi in considerazione vari aspetti come le opzioni di archiviazione, la memoria, l'elaborazione, la replica di lettura, i requisiti di coerenza, il pool di connessioni e le opzioni di caching. Esegui esperimenti con queste diverse opzioni di configurazione per migliorare i parametri di efficienza delle prestazioni. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Esamina le configurazioni correnti (come il tipo di istanza, la dimensione di archiviazione o la versione del motore di database) del tuo datastore. 
+  Consulta la documentazione e le best practice AWS per scoprire le opzioni di configurazione consigliate che possono contribuire a migliorare le prestazioni del datastore. Le principali opzioni da considerare per il datastore sono le seguenti:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_data_evaluate_configuration_options_data_store.html)
+  Esegui esperimenti e benchmarking in un ambiente non di produzione per identificare quale opzione di configurazione può soddisfare i requisiti del tuo carico di lavoro. 
+  Dopo aver sperimentato, pianifica la migrazione e convalida i parametri delle prestazioni. 
+  Usa il monitoraggio di AWS (come [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)) e strumenti di ottimizzazione (come [Amazon S3 Storage Lens](https://aws.amazon.com/s3/storage-lens/)) per ottimizzare continuamente il tuo archivio dati utilizzando modelli di utilizzo reali. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Storage cloud con AWS](https://aws.amazon.com/products/storage/?ref=wellarchitected) 
+  [Tipi di volume di Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) 
+  [Storage Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html) 
+  [Amazon EFS: prestazioni di Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/performance.html) 
+  [Amazon FSx for Lustre Performance](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html) 
+  [Amazon FSx for Windows File Server Performance (Prestazioni di Amazon FSx for Windows File Server)](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/performance.html) 
+  [Amazon Glacier: Amazon Glacier documentazione](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html) 
+  [Amazon S3: considerazioni su velocità e prestazioni delle richieste](https://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html) 
+  [Storage cloud con AWS](https://aws.amazon.com/products/storage/) 
+  [Storage cloud con AWS](https://aws.amazon.com/products/storage/?ref=wellarchitected) 
+  [Caratteristiche di I/O Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html) 
+  [Database su cloud AWS ](https://aws.amazon.com/products/databases/?ref=wellarchitected) 
+  [AWS Database Caching (Memorizzazione nella cache del database AWS) ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) 
+  [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/?ref=wellarchitected) 
+  [Best practice con Amazon Aurora ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected) 
+  [Prestazioni di Amazon Redshift ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected) 
+  [10 suggerimenti prestazionali su Amazon Athena ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected) 
+  [Best practice di Amazon Redshift Spectrum ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/?ref=wellarchitected) 
+  [Best practice di Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html?ref=wellarchitected) 

 **Video correlati:** 
+  [Deep dive on Amazon EBS](https://www.youtube.com/watch?v=wsMWANWNoqQ) 
+  [Optimize your storage performance with Amazon S3](https://www.youtube.com/watch?v=54AhwfME6wI) 
+ [Modernize apps with purpose-built databases](https://www.youtube.com/watch?v=V-DiplATdi0)
+ [ Amazon Aurora storage demystified: How it all works ](https://www.youtube.com/watch?v=uaQEGLKtw54)
+ [ Amazon DynamoDB deep dive: Advanced design patterns ](https://www.youtube.com/watch?v=6yqfmXiZTlM)

 **Esempi correlati:** 
+  [Driver CSI di Amazon EFS](https://github.com/kubernetes-sigs/aws-efs-csi-driver) 
+  [Driver CSI di Amazon EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) 
+  [Utility di Amazon EFS](https://github.com/aws/efs-utils) 
+  [Amazon EBS Autoscale](https://github.com/awslabs/amazon-ebs-autoscale) 
+  [Esempi di Amazon S3](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html) 
+  [Esempi di Amazon DynamoDB](https://github.com/aws-samples/aws-dynamodb-examples) 
+  [Esempi di migrazione di database con AWS](https://github.com/aws-samples/aws-database-migration-samples) 
+  [Database Modernization Workshop (Workshop sulla modernizzazione dei database)](https://github.com/aws-samples/amazon-rds-purpose-built-workshop) 
+  [Utilizzo dei parametri sul database di Amazon RDS per PostgreSQL](https://github.com/awsdocs/amazon-rds-user-guide/blob/main/doc_source/Appendix.PostgreSQL.CommonDBATasks.Parameters.md) 

# PERF03-BP03 Raccolta e registrazione dei parametri delle prestazioni del datastore
<a name="perf_data_collect_record_data_store_performance_metrics"></a>

 Tieni traccia e registra i parametri delle prestazioni pertinenti per il tuo datastore per capire l'andamento delle prestazioni delle soluzioni di gestione dei dati. Questi parametri possono aiutarti a ottimizzare il tuo datastore, verificare che i requisiti del carico di lavoro siano rispettati e fornire una panoramica chiara sull'andamento delle prestazioni del carico di lavoro. 

 **Anti-pattern comuni:** 
+  Utilizzi solo i file di log manuali per la ricerca dei parametri. 
+  Pubblichi i parametri solo sugli strumenti interni utilizzati dal tuo team e non hai un quadro completo del carico di lavoro. 
+  Utilizzi solo i parametri predefiniti registrati dal software di monitoraggio selezionato. 
+  Rivedi i parametri solo quando c'è un problema. 
+  Monitori solo i parametri a livello di sistema, senza acquisire i parametri di accesso ai dati o di utilizzo. 

 **Vantaggi dell'adozione di questa best practice:** la definizione di una linea di base delle prestazioni ti aiuta a comprendere il comportamento normale e i requisiti dei carichi di lavoro. Gli schemi anomali possono essere identificati ed eliminati più rapidamente, per migliorare le prestazioni e l'affidabilità del datastore. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per monitorare le prestazioni dei datastore, devi registrare più parametri delle prestazioni in un periodo di tempo. Ciò consente di rilevare le anomalie e di misurare le prestazioni rispetto ai parametri aziendali, per verificare che le esigenze del carico di lavoro siano rispettate. 

 I parametri devono includere sia il sistema sottostante che supporta il datastore sia i parametri del database. I parametri del sistema sottostante possono includere utilizzo della CPU, memoria, spazio di archiviazione su disco disponibile, I/O su disco, percentuale di riscontri nella cache e parametri di rete in entrata e in uscita, mentre i parametri del datastore possono includere transazioni al secondo, query principali, velocità media delle query, tempi di risposta, utilizzo degli indici, blocco delle tabelle, timeout delle query e numero di connessioni aperte. Questi dati sono cruciali per capire l'andamento del carico di lavoro e come viene utilizzata la soluzione di gestione dei dati. Utilizza tali parametri come parte di un approccio basato sui dati per mettere a punto e ottimizzare le risorse del tuo carico di lavoro.  

 Utilizza strumenti, librerie e sistemi che registrano misure delle prestazioni relative alle prestazioni del database. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Determina i principali parametri delle prestazioni da monitorare per il tuo datastore. 

   1.  [Parametri e dimensioni - Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/metrics-dimensions.html) 

   1.  [Metriche di monitoraggio per un'istanza di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) 

   1.  [Monitoraggio del carico del database con Performance Insights su Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 

   1.  [Panoramica del monitoraggio avanzato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.overview.html) 

   1.  [Parametri e dimensioni - DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html) 

   1.  [Monitoraggio di DynamoDB Accelerator](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.Monitoring.html) 

   1.  [Monitoraggio di Amazon MemoryDB con Amazon CloudWatch](https://docs.aws.amazon.com/memorydb/latest/devguide/monitoring-cloudwatch.html) 

   1.  [Quali parametri è opportuno monitorare?](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html) 

   1.  [Monitoraggio delle prestazioni del cluster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/metrics.html) 

   1.  [Parametri e dimensioni - Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/metrics-dimensions.html) 

   1.  [Metriche di Amazon CloudWatch per Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html) 

   1.  [Registrazione e monitoraggio in Amazon Keyspaces (for Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/monitoring.html) 

   1.  [Monitoraggio delle risorse di Amazon Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/monitoring.html) 

1.  Utilizza una soluzione di registrazione e monitoraggio approvata per raccogliere queste metriche. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) può raccogliere i parametri per tutte le risorse dell'architettura. Puoi anche raccogliere e pubblicare parametri personalizzati per ottenere parametri aziendali o derivati. Utilizza CloudWatch o soluzioni di terze parti per impostare allarmi che indicano il superamento delle soglie. 

1.  Verifica se il monitoraggio dei datastore può trarre vantaggio da una soluzione di machine learning che rileva le anomalie delle prestazioni. 

   1.  [Amazon DevOps Guru per Amazon RDS](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-rds.overview.how-it-works.html) offre visibilità sui problemi di prestazioni e fornisce suggerimenti per le azioni correttive. 

1.  Configura la conservazione dei dati nella soluzione di monitoraggio e registrazione per soddisfare i tuoi obiettivi operativi e di sicurezza. 

   1.  [Conservazione dei dati predefinita per i parametri CloudWatch](https://aws.amazon.com/cloudwatch/faqs/#AWS_resource_.26_custom_metrics_monitoring) 

   1.  [Conservazione dei dati predefinita per CloudWatch Logs](https://aws.amazon.com/cloudwatch/faqs/#Log_management) 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Database Caching (Memorizzazione nella cache del database AWS)](https://aws.amazon.com/caching/database-caching/) 
+  [10 suggerimenti prestazionali su Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) 
+  [Best practice con Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html) 
+  [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/) 
+  [Best practice di Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html) 
+  [Best practice di Amazon Redshift Spectrum (Best practice per Amazon Redshift Spectrum)](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/) 
+  [Prestazioni di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html) 
+  [Database su cloud AWS](https://aws.amazon.com/products/databases/) 
+  [Amazon RDS Performance Insights](https://aws.amazon.com/rds/performance-insights/) 

 **Video correlati:** 
+  [Database dedicati AWS](https://www.youtube.com/watch?v=q81TVuV5u28) 
+  [Amazon Aurora storage demystified: How it all works](https://www.youtube.com/watch?v=uaQEGLKtw54) 
+  [Amazon DynamoDB deep dive: Advanced design patterns](https://www.youtube.com/watch?v=6yqfmXiZTlM) 
+  [Best Practices for Monitoring Redis Workloads on Amazon ElastiCache](https://www.youtube.com/watch?v=c-hTMLN35BY&ab_channel=AWSOnlineTechTalks) 

 **Esempi correlati:** 
+  [Level 100: Monitoring with CloudWatch Dashboards (Livello 100: Monitoraggio con i pannelli di controllo CloudWatch)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) 
+  [AWS Dataset Ingestion Metrics Collection Framework (Framework di raccolta dei parametri di ingestione del set di dati AWS)](https://github.com/awslabs/aws-dataset-ingestion-metrics-collection-framework) 
+  [Workshop di monitoraggio Amazon RDS](https://www.workshops.aws/?tag=Enhanced%20Monitoring) 

# PERF03-BP04 Implementazione di strategie per migliorare le prestazioni delle query nel datastore
<a name="perf_data_implement_strategies_to_improve_query_performance"></a>

 Implementa le strategie per ottimizzare i dati e migliorare le query sui dati in modo da consentire una maggiore scalabilità e prestazioni più efficienti per il tuo carico di lavoro. 

 **Anti-pattern comuni:** 
+  Non suddividi i dati in partizioni nel tuo datastore. 
+  I dati vengono archiviati in un solo formato di file nel tuo datastore. 
+  Non usi gli indici nel tuo datastore. 

 **Vantaggi dell'adozione di questa best practice:** L'ottimizzazione delle prestazioni dei dati e delle query si traduce in maggiore efficienza, costi inferiori e migliore esperienza utente. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

L'ottimizzazione dei dati e delle query è un aspetto critico dell'efficienza delle prestazioni in un datastore, poiché influisce sulle prestazioni e sulla reattività dell'intero carico di lavoro cloud. Le query non ottimizzate possono comportare un maggiore utilizzo delle risorse e rallentamenti, riducendo così l'efficienza complessiva di un datastore. 

L'ottimizzazione dei dati include diverse tecniche per garantire prestazioni efficienti per l'archiviazione e l'accesso ai dati. Ciò aiuta anche a migliorare le prestazioni delle query in un datastore. Le strategie chiave includono il partizionamento, la compressione e la denormalizzazione dei dati, che contribuiscono a ottimizzare i dati sia per l'archiviazione che per l'accesso.

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Esamina e analizza le query sui dati critiche che vengono eseguite nel tuo datastore. 
+  Individua le query lente del tuo datastore e utilizza i piani di query per comprenderne lo stato attuale. 
  +  [Analisi del piano di query in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/c-analyzing-the-query-plan.html) 
  +  [Using EXPLAIN and EXPLAIN ANALYZE in Athena](https://docs.aws.amazon.com/athena/latest/ug/athena-explain-statement.html) 
+  Implementa le strategie per migliorare le prestazioni delle query. Alcune strategie chiave sono: 
  +  Usando un [formato di file colonnare](https://docs.aws.amazon.com/athena/latest/ug/columnar-storage.html) (come Parquet o ORC). 
  + Compressione dei dati nel datastore per ridurre lo spazio di archiviazione e il funzionamento di I/O.
  +  Partizionamento dei dati per suddividere i dati in parti più piccole e ridurre i tempi di analisi dei dati. 
    + [ Partizionamento dei dati in Athena ](https://docs.aws.amazon.com/athena/latest/ug/partitions.html)
    + [ Partizioni e distribuzione dei dati ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html)
  +  L'indicizzazione dei dati sulle colonne comuni della query. 
  +  Scegli l'operazione di unione corretta per la query. Quando unisci due tabelle, specifica la tabella più grande sul lato sinistro dell'unione e la tabella più piccola sul lato destro. 
  +  La soluzione di caching distribuita migliora la latenza e riduce il numero di operazioni di I/O del database. 
  +  La manutenzione regolare, ad esempio l'esecuzione di statistiche. 
+  La sperimentazione e i test delle strategie in un ambiente non di produzione. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Best practice con Amazon Aurora ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected) 
+  [Prestazioni di Amazon Redshift ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected) 
+  [10 suggerimenti prestazionali su Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected) 
+  [AWS Database Caching (Memorizzazione nella cache del database AWS) ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) 
+  [Best practice per l'implementazione di Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/BestPractices.html) 
+  [Partizionamento dei dati in Athena](https://docs.aws.amazon.com/athena/latest/ug/partitions.html) 

 **Video correlati:** 
+  [Optimize Data Pattern Using Amazon Redshift Data Sharing (Ottimizzare lo schema dei dati con la condivisione dei dati di Amazon Redshift)](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/) 
+  [Optimize Amazon Athena Queries with New Query Analysis Tools ](https://www.youtube.com/watch?v=7JUyTqglmNU&ab_channel=AmazonWebServices) 

 **Esempi correlati:** 
+  [Driver CSI di Amazon EFS](https://github.com/kubernetes-sigs/aws-efs-csi-driver) 

# PERF03-BP05 Implementa modelli di accesso ai dati che utilizzano la memorizzazione nella cache
<a name="perf_data_access_patterns_caching"></a>

 Implementa modelli di accesso che possano trarre vantaggio dalla memorizzazione dei dati nella cache per il recupero rapido dei dati a cui si accede di frequente. 

 **Anti-pattern comuni:** 
+  Memorizzare nella cache dati che cambiano in maniera frequente. 
+  Fare affidamento sui dati memorizzati nella cache come se fossero archiviati in modo duraturo e sempre disponibili. 
+  Non tenere conto della coerenza dei dati memorizzati nella cache. 
+  Non monitorare l'efficienza dell'implementazione della cache. 

 **Vantaggi dell'adozione di questa best practice:** L'archiviazione dei dati in una cache può migliorare la latenza di lettura, la velocità effettiva di lettura, l'esperienza utente e l'efficienza complessiva, oltre a ridurre i costi. 

 **Livello di rischio associato se questa best practice non fosse adottata**: medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Una cache è un componente software o hardware progettato per archiviare dati in modo che le richieste future degli stessi dati possano essere soddisfatte più velocemente o in modo più efficiente. I dati memorizzati in una cache possono essere ricostruiti in caso di perdita, ripetendo un calcolo precedente o recuperandolo da un altro datastore. 

 La memorizzazione dei dati nella cache può essere una delle strategie più efficaci per migliorare le prestazioni complessive delle applicazioni e ridurre il carico sulle origini dati primarie sottostanti. I dati possono essere memorizzati nella cache a diversi livelli dell'applicazione, ad esempio all'interno dell'applicazione che effettua chiamate remote, operazione nota come *memorizzazione nella cache lato client*, o utilizzando un servizio secondario veloce per l'archiviazione dei dati, operazione nota come *memorizzazione nella cache remota*. 

 **Memorizzazione nella cache lato client** 

 Con la memorizzazione nella cache lato client, ogni client (un'applicazione o un servizio che interroga il datastore di backend) può archiviare localmente i risultati delle proprie query uniche per un periodo di tempo specificato. Ciò può ridurre il numero di richieste a un datastore attraverso la rete perché viene controllata prima la cache del client locale. Se questa non contiene risultati, l'applicazione può interrogare il datastore e archiviare tali risultati localmente. Questo modello consente a ciascun client di archiviare i dati nella sede più vicina possibile (il client stesso), garantendo così la latenza più bassa possibile. I client possono inoltre continuare a eseguire query quando il datastore di backend non è disponibile, aumentando la disponibilità dell'intero sistema. 

 Uno svantaggio di questo approccio è che quando sono coinvolti più client, potrebbero archiviare localmente gli stessi dati memorizzati nella cache. Ciò si traduce in un utilizzo duplicato dell'archiviazione e nell'incoerenza dei dati tra questi client. Può accadere che un client memorizzi nella cache i risultati di una query e un minuto dopo un altro client esegua la stessa query ottenendo un risultato diverso. 

 **Memorizzazione nella cache remota** 

 Per risolvere il problema della duplicazione dei dati tra client, utilizza un servizio esterno veloce o *una cache remota*per archiviare i dati sottoposti a query. Anziché controllare un datastore locale, ogni client controllerà la cache remota prima di interrogare il datastore di backend. Questa strategia consente di ottenere risposte più coerenti tra i client, una migliore efficienza dei dati archiviati e un volume maggiore di dati memorizzati nella cache, perché lo spazio di archiviazione si dimensiona in maniera indipendente dai client. 

 Lo svantaggio di una cache remota è che l'intero sistema può registrare una latenza più elevata, poiché è necessario un hop di rete aggiuntivo per controllare la cache remota. Per migliorare la latenza, è possibile utilizzare la memorizzazione nella cache lato client insieme alla memorizzazione nella cache remota, eseguendo così una memorizzazione nella cache su più livelli. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Identifica database, API e servizi di rete che potrebbero trarre vantaggio dalla memorizzazione nella cache. I candidati migliori per la memorizzazione nella cache sono i servizi che presentano carichi di lavoro di lettura elevati, un rapporto lettura/scrittura elevato o che sono costosi da dimensionare. 
   +  [Memorizzazione nella cache del database](https://aws.amazon.com/caching/database-caching/) 
   +  [Abilita la memorizzazione nella cache dell'API per migliorare la velocità di risposta](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html) 

1.  Identifica il tipo di strategia di memorizzazione nella cache più adatto al tuo modello di accesso. 
   +  [Strategie di cache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Strategies.html) 
   +  [Soluzioni di memorizzazione nella cache AWS](https://aws.amazon.com/caching/aws-caching/) 

1.  Seguici [Best practice di memorizzazione nella cache](https://aws.amazon.com/caching/best-practices/) per il tuo datastore. 

1.  Configura una strategia di invalidazione della cache per tutti i dati, ad esempio un TTL (Time-to-live), che permetta di bilanciare attualità dei dati e riduzione della pressione sul datastore di backend. 

1.  Abilita funzionalità quali tentativi di connessione automatici, backoff esponenziale, timeout lato client e pool di connessioni nel client, se disponibili, che possono migliorare prestazioni e affidabilità. 
   +  [Best practice: client Redis e Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) 

1.  Monitora la percentuale di riscontri nella cache con un obiettivo dell'80% o superiore. Valori inferiori possono indicare una dimensione della cache insufficiente o un modello di accesso che non sfrutta la memorizzazione nella cache. 
   +  [Quali parametri è opportuno monitorare?](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html) 
   +  [Best practices for monitoring Redis workloads on Amazon ElastiCache](https://www.youtube.com/watch?v=c-hTMLN35BY) 
   +  [Monitoring best practices with Amazon ElastiCache (Redis OSS) using Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/) 

1.  Implementa [la replica dei dati](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) per distribuire il carico delle letture su più istanze e migliorare le prestazioni e la disponibilità di lettura dei dati. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Using the Amazon ElastiCache Well-Architected Lens](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WellArchitechtedLens.html) 
+  [Monitoring best practices with Amazon ElastiCache (Redis OSS) using Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/) 
+  [Quali parametri è opportuno monitorare?](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html) 
+  [Performance at Scale with Amazon ElastiCache whitepaper](https://docs.aws.amazon.com/whitepapers/latest/scale-performance-elasticache/scale-performance-elasticache.html) 
+  [Sfide e strategie di caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 

 **Video correlati:** 
+  [Amazon ElastiCache Learning Path](https://pages.awscloud.com/GLB-WBNR-AWS-OTT-2021_LP_0003-DAT_AmazonElastiCache.html) 
+  [Design for success with Amazon ElastiCache best practices](https://youtu.be/_4SkEy6r-C4) 

 **Esempi correlati:** 
+  [Boosting MySQL database performance with Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/getting-started/hands-on/boosting-mysql-database-performance-with-amazon-elasticache-for-redis/) 

# Reti e distribuzione di contenuti
<a name="a-networking-delivery"></a>

# PERF 4. In che modo selezioni e configuri le risorse di rete nel carico di lavoro?
<a name="perf-04"></a>

 La soluzione di database più efficace per un determinato sistema può variare in base ai requisiti di disponibilità, coerenza, tolleranza della partizione, latenza, durata, scalabilità e capacità di query. Molti sistemi utilizzano diverse soluzioni di database per vari sottosistemi e attivano funzionalità differenti per migliorare le prestazioni. Selezionare la soluzione e le funzionalità del database sbagliate per un sistema può ridurre l'efficienza delle prestazioni. 

**Topics**
+ [PERF04-BP01 In che modo la rete influisce sulle prestazioni](perf_networking_understand_how_networking_impacts_performance.md)
+ [PERF04-BP02 Valuta le funzionalità di rete disponibili](perf_networking_evaluate_networking_features.md)
+ [PERF04-BP03 Scegli la connettività dedicata o la VPN appropriata per il tuo carico di lavoro](perf_networking_choose_appropriate_dedicated_connectivity_or_vpn.md)
+ [PERF04-BP04 Utilizzo del bilanciamento del carico per distribuire il traffico su più risorse](perf_networking_load_balancing_distribute_traffic.md)
+ [PERF04-BP05 Scelta dei protocolli di rete per migliorare le prestazioni](perf_networking_choose_network_protocols_improve_performance.md)
+ [PERF04-BP06 Scelta della posizione del carico di lavoro in base ai requisiti di rete](perf_networking_choose_workload_location_network_requirements.md)
+ [PERF04-BP07 Ottimizzazione della configurazione di rete in base alle metriche](perf_networking_optimize_network_configuration_based_on_metrics.md)

# PERF04-BP01 In che modo la rete influisce sulle prestazioni
<a name="perf_networking_understand_how_networking_impacts_performance"></a>

 Analizza e comprendi in che modo le decisioni correlate alla rete influiscono sul carico di lavoro per fornire prestazioni efficienti e una migliore esperienza utente. 

 **Anti-pattern comuni:** 
+  Tutto il traffico passa attraverso i data center esistenti. 
+  Si instrada tutto il traffico attraverso i firewall centrali anziché utilizzare strumenti di sicurezza di rete nativi del cloud. 
+  Si effettua il provisioning delle connessioni AWS Direct Connect senza comprendere gli effettivi requisiti di utilizzo. 
+  Quando si definiscono le soluzioni di rete, non si considerano le caratteristiche del carico di lavoro e l'overhead della crittografia. 
+  Per le soluzioni di rete nel cloud si utilizzano concetti e strategie on-premise. 

 **Vantaggi dell'adozione di questa best practice:** Comprendere l'impatto della rete sulle prestazioni del carico di lavoro ti aiuta a identificare i potenziali colli di bottiglia, migliorare l'esperienza dell'utente, aumentare l'affidabilità e ridurre la manutenzione operativa al variare del carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 La rete è responsabile della connettività tra componenti dell'applicazione, servizi cloud, reti edge e dati on-premise e quindi può avere un forte impatto sulle prestazioni dei carichi di lavoro. Oltre alle prestazioni del carico di lavoro, l'esperienza dell'utente può essere influenzata anche da latenza della rete, larghezza di banda, protocolli, posizione, congestione della rete, jitter, velocità di trasmissione effettiva e regole di instradamento. 

 Disporre di un elenco documentato dei requisiti di rete del carico di lavoro, tra cui latenza, dimensione dei pacchetti, regole di instradamento, protocolli e modelli di traffico di supporto. Esaminare le soluzioni di rete disponibili e individuare il servizio che soddisfi le caratteristiche di rete del proprio carico di lavoro. Le reti basate sul cloud possono essere ricostruite rapidamente, quindi l'evoluzione dell'architettura di rete nel tempo è necessaria per migliorare l'efficienza delle prestazioni. 

### Passaggi dell'implementazione:
<a name="implementation-steps"></a>

1.  Definisci e documenta i requisiti di prestazioni di rete, tra cui metriche come latenza di rete, larghezza di banda, protocolli, posizioni, modelli di traffico (picchi e frequenza), velocità di trasmissione effettiva, crittografia, ispezione e regole di instradamento. 

1.  Scopri i principali servizi di rete AWS come [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html), [AWS Direct Connect](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect.html), [Elastic Load Balancing (ELB)](https://aws.amazon.com/elasticloadbalancing/)e [Amazon Route 53](https://aws.amazon.com/r53/). 

1.  Acquisisci le seguenti caratteristiche di rete fondamentali:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_networking_understand_how_networking_impacts_performance.html)

1.  Esegui il benchmark e testa le prestazioni della rete: 

   1.  [Esegui il benchmark](https://aws.amazon.com/premiumsupport/knowledge-center/network-throughput-benchmark-linux-ec2/) della velocità di trasmissione effettiva della rete, poiché alcuni fattori possono influire sulle prestazioni della rete Amazon EC2 quando le istanze si trovano nello stesso VPC. Misura la larghezza di banda della rete tra le istanze Amazon EC2 Linux nello stesso VPC. 

   1.  Esegui [test di carico](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) per sperimentare soluzioni e opzioni di rete. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
+  [Reti avanzate su Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html) 
+  [Reti avanzate su Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking.html) 
+  [Gruppi di collocamento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) 
+  [Abilitazione delle reti avanzate con Elastic Network Adapter (ENA) sulle istanze Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) 
+  [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
+  [Nuovi prodotti di rete con AWS](https://aws.amazon.com/products/networking/) 
+  [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw) 
+  [Passaggio all'instradamento basato sulla latenza in Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html) 
+  [Endpoint VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) 
+  [Log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 

 **Video correlati:** 
+  [Connectivity to AWS and hybrid AWS network architectures](https://www.youtube.com/watch?v=eqW6CPb58gs) 
+  [Ottimizzazione delle prestazioni di rete per istanze Amazon EC2](https://www.youtube.com/watch?v=DWiwuYtIgu0) 
+  [Improve Global Network Performance for Applications](https://youtu.be/vNIALfLTW9M) 
+  [EC2 Instances and Performance Optimization Best Practices](https://youtu.be/W0PKclqP3U0) 
+  [Ottimizzazione delle prestazioni di rete per istanze Amazon EC2](https://youtu.be/DWiwuYtIgu0) 
+  [Networking best practices and tips with the Well-Architected Framework](https://youtu.be/wOMNpG49BeM) 
+  [AWS networking best practices in large-scale migrations](https://youtu.be/qCQvwLBjcbs) 

 **Esempi correlati:** 
+  [AWS Transit Gateway and Scalable Security Solutions](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions) 
+  [AWS Networking Workshops](https://networking.workshop.aws/) 

# PERF04-BP02 Valuta le funzionalità di rete disponibili
<a name="perf_networking_evaluate_networking_features"></a>

Valuta le funzionalità di rete nel cloud che possono aumentare le prestazioni. Misura l'impatto di tali funzionalità attraverso test, parametri e analisi. Ad esempio, sfrutta le funzionalità a livello di rete disponibili per ridurre latenza, distanza di rete o jitter.

 **Anti-pattern comuni:** 
+ Rimani all'interno di una regione perché è lì che si trova fisicamente la tua sede centrale.
+ Utilizzi i firewall anziché i gruppi di sicurezza per filtrare il traffico.
+ Interrompi TLS per l'ispezione del traffico anziché affidarti a gruppi di sicurezza, policy degli endpoint e altre funzionalità native del cloud.
+ Utilizzi solo la segmentazione basata su sottoreti anziché i gruppi di sicurezza.

 **Vantaggi dell'adozione di questa best practice:** la valutazione di tutte le funzionalità e le opzioni del servizio consente di ridurre il costo dell'infrastruttura e l'impegno necessario per mantenere il carico di lavoro e aumentare l'assetto di sicurezza generale. La struttura portante globale di AWS ti aiuta a fornire ai tuoi clienti la migliore esperienza di rete. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 AWS offre servizi come [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) e [Amazon CloudFront](https://aws.amazon.com/cloudfront/) , i quali possono contribuire a migliorare le prestazioni della rete, mentre la maggior parte dei servizi AWS include funzionalità di prodotto (come [l'Accelerazione del trasferimento Amazon S3](https://aws.amazon.com/s3/transfer-acceleration/) ) per ottimizzare il traffico di rete. 

 Analizza quali opzioni di configurazione relative alla rete sono disponibili e come possono influire sul tuo carico di lavoro. L'ottimizzazione delle prestazioni dipende dalla comprensione del modo in cui queste opzioni interagiscono con l'architettura e dall'impatto che hanno sulle prestazioni misurate e sull'esperienza utente. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Crea l'elenco dei componenti del carico di lavoro. 
  +  Prendi in considerazione l'utilizzo di [Cloud AWS WAN](https://aws.amazon.com/cloud-wan/) per creare, gestire e monitorare la rete dell'organizzazione durante la creazione di una rete globale unificata. 
  +  Monitora le tue reti globali e principali con [le metriche di Amazon CloudWatch Logs](https://docs.aws.amazon.com/network-manager/latest/tgwnm/monitoring-cloudwatch-metrics.html). Sfrutta [Amazon CloudWatch RUM](https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-cloudwatch-rum-applications-client-side-performance/), che fornisce approfondimenti utili per identificare, comprendere e migliorare l'esperienza digitale degli utenti. 
  +  Visualizza la latenza di rete aggregata tra Regioni AWS e zone di disponibilità, nonché all'interno di ciascuna zona di disponibilità, utilizzando [AWS Network Manager](https://aws.amazon.com/transit-gateway/network-manager/) , che ti permette di ottenere informazioni dettagliate sul modo in cui le prestazioni delle applicazioni variano in base alle prestazioni della rete AWS sottostante. 
  +  Utilizza uno strumento per database di gestione delle configurazioni (CMDB) esistente oppure un servizio come [AWS Config](https://aws.amazon.com/config/) per creare un inventario del carico di lavoro e della relativa configurazione. 
+  Se si tratta di un carico di lavoro esistente, individua e documenta l'analisi di benchmark per le metriche relative alle prestazioni, concentrandoti sui colli di bottiglia e sulle aree da migliorare. Le metriche relative alla rete a livello di prestazioni varieranno a seconda dei requisiti aziendali e delle caratteristiche del carico di lavoro. Come punto di partenza, le seguenti metriche possono essere importanti per la revisione del carico di lavoro: larghezza di banda, latenza, perdita di pacchetti, jitter e ritrasmissioni. 
+  Se si tratta di un nuovo carico di lavoro, esegui i [test di carico](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) per individuare eventuali colli di bottiglia relativi alle prestazioni. 
+  Per tutti i colli di bottiglia di questo tipo riscontrati, esamina le opzioni di configurazione per le soluzioni in uso per individuare le opportunità di miglioramento delle prestazioni. Consulta le seguenti opzioni e funzionalità di rete fondamentali:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_networking_evaluate_networking_features.html)

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [Istanze ottimizzate per Amazon EBS ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)
+ [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Reti avanzate su Linux ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html)
+ [Reti avanzate su Windows ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking.html)
+ [Gruppi di collocamento ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
+ [Abilitazione delle reti avanzate con Elastic Network Adapter (ENA) sulle istanze Linux ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html)
+ [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [Nuovi prodotti di rete con AWS](https://aws.amazon.com/products/networking/)
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Passaggio all'instradamento basato sulla latenza in Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html)
+ [Endpoint VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html)
+ [Log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)

 **Video correlati:** 
+ [Connectivity to AWS and hybrid AWS network architectures](https://www.youtube.com/watch?v=eqW6CPb58gs)
+ [Ottimizzazione delle prestazioni di rete per istanze Amazon EC2](https://www.youtube.com/watch?v=DWiwuYtIgu0)
+ [AWS Global Accelerator](https://www.youtube.com/watch?v=Docl4julOQw)

 **Esempi correlati:** 
+ [AWS Transit Gateway and Scalable Security Solutions ](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions)
+ [AWS Networking Workshops](https://catalog.workshops.aws/networking/en-US)

# PERF04-BP03 Scegli la connettività dedicata o la VPN appropriata per il tuo carico di lavoro
<a name="perf_networking_choose_appropriate_dedicated_connectivity_or_vpn"></a>

 Quando hai bisogno di una connettività ibrida per connettere risorse on-premise e cloud, assicurati di avere una larghezza di banda adeguata per soddisfare i tuoi requisiti di prestazione. Fai una stima dei requisiti di larghezza di banda e latenza per il carico di lavoro ibrido. I valori calcolati determineranno le tue esigenze di dimensionamento. 

 **Anti-pattern comuni:** 
+  Valutazione delle soluzioni VPN solo per i tuoi requisiti di crittografia di rete. 
+  Non vengono valutate opzioni di backup o di connettività ridondante. 
+  Non è possibile identificare tutti i requisiti del carico di lavoro (esigenze di crittografia, protocollo, larghezza di banda e traffico). 

 **Vantaggi dell'adozione di questa best practice:** La selezione e la configurazione di soluzioni di connettività appropriate migliorano l'affidabilità del carico di lavoro e massimizzano le prestazioni. L'identificazione di requisiti del carico di lavoro, la pianificazione anticipata e la valutazione di soluzioni ibride ti permetteranno di ridurre al minimo le costose modifiche alla rete fisica e i costi operativi, migliorando al contempo il time-to-value. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Sviluppa un'architettura di rete ibrida basata sui requisiti di larghezza di banda. [Direct Connect](https://aws.amazon.com/directconnect/) ti consente di connettere la tua rete on-premise in modo privato con AWS. È utile quando hai bisogno di larghezza di banda elevata, bassa latenza e di mantenere le prestazioni coerenti. Una connessione VPN permette di connettersi in modo sicuro su Internet. Viene utilizzata quando è necessaria solo una connessione temporanea, quando il costo è un fattore importante o come misura di contingenza in attesa che venga stabilita una connettività di rete fisica resiliente mentre Direct Connect è in uso. 

 Se i tuoi requisiti di larghezza di banda sono elevati, potresti prendere in considerazione l'utilizzo di più Direct Connect o di servizi di VPN. Il traffico può essere bilanciato in termini di carico tra i servizi, ma il bilanciamento del carico tra Direct Connect e VPN è sconsigliato a causa delle differenze di latenza e larghezza di banda. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Calcola i requisiti di larghezza di banda e latenza delle tue app esistenti. 

   1.  Per i carichi di lavoro esistenti che vengono spostati in AWS, utilizza i dati raccolti dai sistemi di monitoraggio di rete interni. 

   1.  Per i carichi di lavoro nuovi o esistenti per i quali non sono disponibili dati di monitoraggio, consulta i proprietari dei prodotti per definire metriche sulle prestazioni adeguate e offrire un'esperienza utente soddisfacente. 

1.  Scegli una connessione dedicata o una VPN come opzione di connettività. A seconda di tutti i requisiti del carico di lavoro (esigenze di crittografia, larghezza di banda e traffico), puoi scegliere AWS Direct Connect o [Site-to-Site VPN](https://aws.amazon.com/vpn/) (o entrambi). Il diagramma seguente può aiutarti a scegliere il tipo di connessione appropriato. 

   1.  [AWS Direct Connect](https://aws.amazon.com/directconnect/) fornisce connettività dedicata all'ambiente AWS da 50 Mbps fino a 100 Gbps, utilizzando connessioni dedicate od ospitate. In questo modo, disporrai di latenza gestita e controllata, nonché di larghezza di banda assegnata, in modo che il carico di lavoro possa connettersi con efficienza ad altri ambienti. Ricorrendo a partner AWS Direct Connect, otterrai connettività end-to-end da più ambienti, per una rete estesa con prestazioni coerenti. AWS permette di dimensionare la larghezza di banda di connessione Direct Connect usando connettività nativa a 100 Gbps, gruppi di aggregazione di collegamenti (LAG, Link Aggregation Group) o instradamento ECMP (Equal-Cost Multipath) con BGP. 

   1.  AWS [Site-to-Site VPN](https://aws.amazon.com/vpn/) offre un servizio VPN gestito che supporta il protocollo IPSec (Internet Protocol security). Quando viene creata una connessione VPN, ogni connessione include due tunnel per la disponibilità elevata. 

1.  Consulta la documentazione AWS per scegliere l'opzione di connettività appropriata: 

   1.  Se decidi di utilizzareDirect Connect, seleziona la larghezza di banda appropriata per la tua connettività. 

   1.  Se utilizzi una AWS Site-to-Site VPN tra più posizioni per connetterti a una Regione AWS, prova a utilizzare una [connessione Site-to-Site VPN accelerata](https://docs.aws.amazon.com/vpn/latest/s2svpn/accelerated-vpn.html) per migliorare le prestazioni della rete. 

   1.  Se il progetto di rete è costituito da una connessione VPN IPSec tramite [AWS Direct Connect](https://aws.amazon.com/directconnect/), prendi in considerazione l'utilizzo di VPN con indirizzo IP privato per migliorare la sicurezza e ottenere la segmentazione. [La VPN sito-sito AWS con indirizzo IP privato](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-site-to-site-vpn-private-ip-vpns/) viene implementata sull'interfaccia virtuale di transito (VIF). 

   1.  [AWS Direct Connect SiteLink](https://aws.amazon.com/blogs/aws/new-site-to-site-connectivity-with-aws-direct-connect-sitelink/) consente di creare connessioni ridondanti e a bassa latenza tra i data center in tutto il mondo inviando dati lungo il percorso più veloce tra [sedi di AWS Direct Connect](https://aws.amazon.com/directconnect/locations/), bypassando Regioni AWS. 

1.  Convalida la configurazione della connettività prima di eseguire l'implementazione in produzione. Esegui test di sicurezza e prestazioni per assicurarti di soddisfare i requisiti di larghezza di banda, affidabilità, latenza e conformità. 

1.  Monitora regolarmente le prestazioni e l'utilizzo della connettività e ottimizzali, se necessario. 

![\[Diagramma di flusso che descrive le opzioni da prendere in considerazione nel determinare se siano o meno necessarie prestazioni deterministiche nella rete.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deterministic-networking-flowchart.png)


 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [ Nuovi prodotti di rete con AWS](https://aws.amazon.com/products/networking/)
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [ Passaggio all'instradamento basato sulla latenza in Amazon Route 53 ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html)
+ [ Endpoint VPC ](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html)
+  [Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) 
+  [Creazione di un'infrastruttura di rete AWS scalabile e sicura con più VPC](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) 
+  [Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) 
+  [Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/what-is.html) 

 **Video correlati:** 
+ [ Connectivity to AWS and hybrid AWS network architectures ](https://www.youtube.com/watch?v=eqW6CPb58gs)
+ [ Ottimizzazione delle prestazioni di rete per istanze Amazon EC2 ](https://www.youtube.com/watch?v=DWiwuYtIgu0)
+  [AWS Global Accelerator](https://www.youtube.com/watch?v=lAOhr-5Urfk) 
+  [Direct Connect](https://www.youtube.com/watch?v=DXFooR95BYc&t=6s) 
+  [AWS Transit Gateway Connect](https://www.youtube.com/watch?v=_MPY_LHSKtM&t=491s) 
+  [Soluzioni VPN](https://www.youtube.com/watch?v=qmKkbuS9gRs) 
+  [Security with VPN Solutions](https://www.youtube.com/watch?v=FrhVV9nG4UM) 

 **Esempi correlati:** 
+  [AWS Transit Gateway e soluzioni di sicurezza scalabili](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions) 
+  [AWS Networking Workshop](https://networking.workshop.aws/) 

# PERF04-BP04 Utilizzo del bilanciamento del carico per distribuire il traffico su più risorse
<a name="perf_networking_load_balancing_distribute_traffic"></a>

 Distribuisci il traffico tra varie risorse o servizi affinché il carico di lavoro possa trarre vantaggio dall'elasticità fornita dal cloud. Puoi anche utilizzare il bilanciamento del carico per la terminazione dell'offloading della crittografia al fine di migliorare le prestazioni, l'affidabilità e gestire e instradare il traffico in modo efficiente. 

 **Anti-pattern comuni:** 
+  Scelta del tipo di sistema di bilanciamento del carico senza tenere conto dei requisiti del carico di lavoro. 
+  Mancato utilizzo delle funzionalità del sistema di bilanciamento del carico per l'ottimizzazione delle prestazioni. 
+  Esposizione diretta del carico di lavoro a Internet senza un sistema di bilanciamento del carico. 
+  Instradi tutto il traffico Internet attraverso i sistemi di bilanciamento del carico esistenti. 
+  Utilizzi il bilanciamento del carico TCP generico e fai in modo che ogni nodo di calcolo gestisca la crittografia SSL. 

 **Vantaggi dell'adozione di questa best practice:** Un sistema di bilanciamento del carico gestisce il carico variabile del traffico dell'applicazione in una o più zone di disponibilità e consente alta disponibilità, dimensionamento automatico e un migliore utilizzo del carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I sistemi di bilanciamento del carico operano come punto di ingresso per il carico di lavoro, dal quale distribuiscono il traffico alle destinazioni di backend, come istanze di calcolo o container per migliorarne l'utilizzo. 

 La scelta del tipo corretto di sistema di bilanciamento del carico è il primo passaggio per ottimizzare l'architettura. Per iniziare, elenca le caratteristiche del carico di lavoro, tra cui protocollo (TCP, HTTP, TLS o WebSocket), tipo di destinazione (istanze, container o servizi serverless), requisiti dell'applicazione (connessioni a esecuzione prolungata, autenticazione utente o persistenza) e ubicazione (regione, zona locale, Outpost o isolamento zonale). 

 AWS fornisce diversi modelli di bilanciamento del carico per le tue applicazioni. [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) è l'ideale per il bilanciamento del carico del traffico HTTP e HTTPS. Inoltre, offre l'instradamento avanzato delle richieste dedicato alla distribuzione delle architetture applicative moderne, fra cui microservizi e container. 

 [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) è l'ideale per il bilanciamento del carico del traffico TCP, in cui sono richieste prestazioni elevatissime. È in grado di gestire milioni di richieste al secondo, mantenendo al contempo latenze ridottissime. Inoltre, è ottimizzato per la gestione degli schemi di traffico improvvisi e incostanti. 

 [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) fornisce la gestione integrata dei certificati e la decrittografia SSL/TLS, offrendoti la flessibilità di gestire centralmente le impostazioni SSL del sistema di bilanciamento del carico e di sollevare il carico di lavoro dall'utilizzo intensivo della CPU. 

 Dopo aver scelto il sistema di bilanciamento del carico appropriato, puoi iniziare a utilizzarne le funzionalità per ridurre la quantità di attività che deve svolgere il backend per distribuire il traffico. 

 Ad esempio, usando un Application Load Balancer (ALB) e un Network Load Balancer (NLB), puoi eseguire l'offload della crittografia SSL/TLS, il che costituisce un'opportunità per evitare il completamento dell'handshake TLS a elevato utilizzo di CPU da parte delle destinazioni e migliorare anche la gestione dei certificati. 

 Se configurato nel sistema di bilanciamento del carico, l'offload SSL/TLS diventa responsabile della crittografia del traffico da e verso i client, distribuendo il traffico non crittografato ai backend, liberando le risorse backend e migliorando il tempo di risposta per i client. 

 L'Application Load Balancer può anche distribuire traffico HTTP/2 senza che questo debba essere supportato nelle destinazioni. Questa semplice decisione può migliorare il tempo di risposta dell'applicazione, in quanto HTTP/2 usa connessioni TCP in modo più efficiente. 

 Nel definire l'architettura, è bene tenere conto dei requisiti di latenza del carico di lavoro. Ad esempio, se un'applicazione è sensibile alla latenza, è possibile scegliere di usare un Network Load Balancer, che offre latenze estremamente ridotte. In alternativa, è possibile decidere di avvicinare il carico di lavoro ai clienti utilizzando l'Application Load Balancer in [zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) o anche [AWS Outposts](https://aws.amazon.com/outposts/rack/). 

 Un altro aspetto di cui tenere conto per i carichi di lavoro sensibili alla latenza è il bilanciamento del carico tra zone. Con il bilanciamento del carico tra zone, ogni nodo del sistema di bilanciamento del carico distribuisce il traffico tra le destinazioni registrate in tutte le zone di disponibilità autorizzate. 

 Usa Auto Scaling integrato con il sistema di bilanciamento del carico. Uno degli aspetti principali di un sistema con prestazioni efficienti riguarda il dimensionamento corretto delle risorse backend. A questo scopo, puoi utilizzare integrazioni dei sistemi di bilanciamento del carico per le risorse di destinazione backend. Usando l'integrazione dei sistemi di bilanciamento del carico con gruppi con Auto Scaling, le destinazioni vengono aggiunte o rimosse nel e dal sistema di bilanciamento del carico in base alle esigenze, in risposta al traffico in ingresso. I sistemi di bilanciamento del carico possono anche essere integrati con [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html) e [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) per carichi di lavoro containerizzati. 
+  [Amazon ECS - Bilanciamento del carico dei servizi](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html) 
+  [Bilanciamento del carico delle applicazioni in Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html) 
+  [Bilanciamento del carico di rete in Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/network-load-balancing.html) 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Definisci i tuoi requisiti di bilanciamento del carico, tra cui volume considerevole, disponibilità e scalabilità delle applicazioni. 
+  Scegli il tipo di sistema di bilanciamento del carico giusto per la tua applicazione. 
  +  Usa un Application Load Balancer per carichi di lavoro HTTP/HTTPS. 
  +  Usa un Network Load Balancer per carichi di lavoro non HTTP in esecuzione su TCP o UDP. 
  +  Usa una combinazione di entrambi ([ALB come destinazione dell'NLB](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/)) se desideri sfruttare le funzionalità di entrambi i prodotti. Ad esempio, puoi scegliere questa opzione se vuoi usare gli indirizzi IP statici dell'NLB insieme all'instradamento basato su intestazione HTTP dell'ALB, oppure se vuoi esporre il carico di lavoro HTTP a un [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-share-your-services.html). 
  +  Per un confronto completo dei sistemi di bilanciamento del carico, consulta [Confronto dei prodotti ELB](https://aws.amazon.com/elasticloadbalancing/features/). 
+  Se possibile, utilizza l'offload SSL/TLS. 
  +  Configura gli ascoltatori HTTPS/TLS utilizzando [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) e [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-tls-listener.html) integrati con [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/). 
  +  Alcuni carichi di lavoro possono richiedere la crittografia end-to-end per motivi di conformità. In questo caso, è necessario consentire la crittografia nelle destinazioni. 
  +  Per le best practice di sicurezza, consulta [SEC09-BP02 Applicazione della crittografia dei dati in transito](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_data_transit_encrypt.html). 
+  Seleziona l'algoritmo di instradamento corretto (solo ALB) 
  +  L'algoritmo di instradamento può fare la differenza per quanto riguarda l'uso corretto delle destinazioni backend e, di conseguenza, l'impatto sulle prestazioni. Ad esempio, ALB fornisce [due opzioni per gli algoritmi di instradamento](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm): 
  +  **Numero minimo di richieste in sospeso:** usa questa opzione per ottenere una migliore distribuzione del carico nelle destinazioni backend nei casi in cui le richieste per l'applicazione variano per complessità o le destinazioni variano per capacità di elaborazione. 
  +  **Round robin:** usa questa opzione quando le richieste e le destinazioni sono simili o se devi distribuire equamente le richieste tra le destinazioni. 
+  Valuta se usare l'isolamento tra zone o quello zonale. 
  +  Disattiva l'isolamento tra zone (usando l'isolamento zonale) per migliorare la latenza e in caso di errori di zona. Questo è disattivato per impostazione predefinita in NLB, mentre in [ALB puoi disattivarlo per gruppo di destinazione](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html). 
  +  Attiva l'isolamento tra zone per ottenere disponibilità e flessibilità maggiori. Per impostazione predefinita, la modalità tra zone è attivata per ALB, mentre in [NLB puoi attivarla per gruppo di destinazione](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-cross-zone.html). 
+  Attiva keep-alive HTTP per i carichi di lavoro HTTP (solo ALB). Con questa funzionalità, il sistema di bilanciamento del carico può riutilizzare le connessioni backend fino allo scadere del timeout del keep-alive, migliorando la richiesta HTTP e il tempo di risposta e riducendo anche l'utilizzo delle risorse nelle destinazioni backend. Per i dettagli su come eseguire questa operazione per Apache e Nginx, consulta [Quali sono le impostazioni ottimali per l'uso di Apache o NGINX come server backend per l'ELB?](https://aws.amazon.com/premiumsupport/knowledge-center/apache-backend-elb/) 
+  Attiva il monitoraggio del tuo sistema di bilanciamento del carico. 
  +  Attiva i log di accesso per [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-access-logging.html) e [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html). 
  +  I campi principali da considerare per l'ALB sono `request_processing_time`, `request_processing_time`e `response_processing_time`. 
  +  I campi principali da considerare per l'NLB sono `connection_time` e `tls_handshake_time`. 
  +  Preparati a eseguire query sui log quando necessario. Puoi usare Amazon Athena per interrogare [i log ALB](https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html) e [i log NLB](https://docs.aws.amazon.com/athena/latest/ug/networkloadbalancer-classic-logs.html). 
  +  Crea allarmi per metriche correlate alle prestazioni come [`TargetResponseTime` per l'ALB](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Confronto dei prodotti ELB ](https://aws.amazon.com/elasticloadbalancing/features/) 
+  [Infrastruttura globale di AWS ](https://aws.amazon.com/about-aws/global-infrastructure/) 
+  [Miglioramento delle prestazioni e riduzione dei costi tramite l'affinità delle zone di disponibilità ](https://aws.amazon.com/blogs/architecture/improving-performance-and-reducing-cost-using-availability-zone-affinity/) 
+  [Step by step for Log Analysis with Amazon Athena ](https://github.com/aws/elastic-load-balancing-tools/tree/master/amazon-athena-for-elb) 
+  [Querying Application Load Balancer logs](https://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html) 
+  [Monitor your Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html) 
+  [Monitor your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-monitoring.html) 
+  [Use Elastic Load Balancing to distribute traffic across the instances in your Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 

 **Video correlati:** 
+  [AWS re:Invent 2018: Elastic Load Balancing: Deep Dive and Best Practices](https://www.youtube.com/watch?v=VIgAT7vjol8) 
+  [AWS re:Invent 2021 - How to choose the right load balancer for your AWS workloads ](https://www.youtube.com/watch?v=p0YZBF03r5A) 
+  [AWS re:Inforce 2022 - How to use Elastic Load Balancing to enhance your security posture at scale](https://www.youtube.com/watch?v=YhNc5VSzOGQ) 
+  [AWS re:Invent 2019: Get the most from Elastic Load Balancing for different workloads](https://www.youtube.com/watch?v=HKh54BkaOK0) 

 **Esempi correlati:** 
+  [CDK and CloudFormation samples for Log Analysis with Amazon Athena ](https://github.com/aws/elastic-load-balancing-tools/tree/master/log-analysis-elb-cdk-cf-template) 

# PERF04-BP05 Scelta dei protocolli di rete per migliorare le prestazioni
<a name="perf_networking_choose_network_protocols_improve_performance"></a>

 Prendi decisioni sui protocolli per la comunicazione tra sistemi e reti in base all'impatto sulle prestazioni del carico di lavoro. 

 Esiste una relazione tra latenza e larghezza di banda per ottenere la velocità di trasmissione desiderata. Se per il trasferimento di file viene usato il protocollo TCP, latenze più elevate molto probabilmente ridurranno la velocità di trasmissione effettiva complessiva. Alcuni approcci risolvono questo problema tramite l'ottimizzazione del TCP e l'utilizzo di protocolli di trasferimento ottimizzati, un altro prevede l'utilizzo del protocollo UDP (User Datagram Protocol). 

 **Anti-pattern comuni:** 
+  Puoi utilizzare il TCP per tutti i carichi di lavoro, indipendentemente dai requisiti prestazionali. 

 **Vantaggi dell'adozione di questa best practice:** La verifica del protocollo appropriato per la comunicazione tra utenti e componenti del carico di lavoro contribuisce a migliorare l'esperienza utente complessiva per le applicazioni. Ad esempio, l'UDP senza connessione garantisce velocità elevata, ma non offre ritrasmissione o alta affidabilità. Il TCP è un protocollo completo, ma richiede un sovraccarico maggiore per l'elaborazione dei pacchetti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Se hai la possibilità di scegliere protocolli diversi per la tua applicazione e hai esperienza in questo campo, ottimizza l'applicazione e l'esperienza dell'utente finale utilizzando un protocollo diverso. Tieni conto che questo approccio presenta notevoli difficoltà e dovrebbe essere tentato solo dopo aver ottimizzato l'applicazione in altri modi. 

 Un aspetto principale per il miglioramento delle prestazioni del carico di lavoro consiste nell'identificare i requisiti di latenza e velocità di trasmissione effettiva e quindi scegliere i protocolli di rete che ottimizzano le prestazioni. 

 **Quando valutare se usare TCP** 

 TCP permette la trasmissione affidabile dei dati e può essere usato per la comunicazione tra i componenti del carico di lavoro quando l'affidabilità e la garanzia di trasmissione dei dati sono due aspetti importanti. Molte applicazioni Web usano protocolli basati su TCP, come HTTP e HTTPS, per aprire socket TCP per la comunicazione tra i componenti dell'applicazione. Il TCP viene comunemente usato per il trasferimento di dati di posta elettronica e di file, in quanto è un meccanismo di trasferimento semplice e affidabile tra i componenti dell'applicazione. L'uso di TLS con TCP può aggiungere un certo sovraccarico alla comunicazione, il che produce maggiore latenza e velocità di trasmissione effettiva inferiore, ma presenta come vantaggio una maggiore sicurezza. Il sovraccarico è dovuto prevalentemente al processo di handshake, il cui completamento può richiedere diversi round trip. Al termine del processo di handshake, il sovraccarico dovuto alla crittografia e alla decrittografia dei dati è relativamente ridotto. 

 **Quando valutare se usare UDP** 

 UDP è un protocollo di tipo connection-less (senza connessione) e di conseguenza è ideale per applicazioni che necessitano di una trasmissione veloce ed efficiente, ad esempio per i log, il monitoraggio e i dati VoIP. Valuta se usare UDP anche se vi sono componenti del carico di lavoro che rispondono a piccole query provenienti da grandi quantità di client per garantire prestazioni ottimali del carico di lavoro. Datagram Transport Layer Security (DTLS) è l'equivalente UDP di Transport Layer Security (TLS). Quando viene usato DTLS con UDP, il sovraccarico è dovuto alla crittografia e alla decrittografia dei dati, in quanto il processo di handshake è semplificato. DTLS aggiunge anche un piccolo sovraccarico ai pacchetti UDP, perché include altri campi per indicare i parametri di sicurezza e rilevare la manomissione. 

 **Quando valutare se usare SRD** 

 SRD (Scalable Reliable Datagram) è un protocollo di trasporto di rete ottimizzato per carichi di lavoro a velocità di trasmissione effettiva elevata grazie alla sua capacità di bilanciare il carico del traffico tra più percorsi e di recuperare rapidamente dalla perdita di pacchetti e da errori di collegamento. Di conseguenza, SRD è ideale per carichi di lavoro di calcolo ad alte prestazioni (HPC) che richiedono comunicazioni tra nodi di calcolo a velocità di trasmissione effettiva elevata e a bassa latenza. Possono essere incluse attività di elaborazione in parallelo come la simulazione, la modellazione e l'analisi dei dati che implicano il trasferimento di grandi quantità di dati tra nodi. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Utilizza [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) e [AWS Transfer Family](https://aws.amazon.com/aws-transfer-family/) per migliorare la velocità di trasmissione effettiva delle applicazioni di trasferimento di file online. Il servizio AWS Global Accelerator ti permette di ottenere latenza inferiore tra i dispositivi client e il carico di lavoro in AWS. Con AWS Transfer Family puoi usare protocolli basati su TCP come SFTP (Secure Shell File Transfer Protocol) ed FTPS (File Transfer Protocol over SSL) per dimensionare e gestire i trasferimenti di file in servizi di archiviazione AWS in tutta sicurezza. 

1.  Usa la latenza di rete per determinare se TCP sia il protocollo appropriato per la comunicazione tra componenti del carico di lavoro. Se la latenza di rete tra l'applicazione client e il server è elevata, il processo di handshake a tre vie tramite TCP può richiedere tempo, influendo sulla velocità di risposta dell'applicazione. Per misurare la latenza di rete, puoi usare, ad esempio, le metriche TTFB (tempo di acquisizione al primo byte) e RTT (tempo di andata e ritorno). Se il tuo carico di lavoro fornisce agli utenti contenuti dinamici, prendi in considerazione l'utilizzo di [Amazon CloudFront](https://aws.amazon.com/cloudfront/), che stabilisce una connessione persistente a ogni origine per il contenuto dinamico in modo da eliminare il tempo di configurazione della connessione, che altrimenti rallenterebbe ogni richiesta client. 

1.  L'uso di TLS con TCP o UDP può causare maggiore latenza e minore velocità di trasmissione effettiva per il carico di lavoro a causa dell'impatto della crittografia e della decrittografia. Per carichi di lavoro di questo tipo, prendi in considerazione l'offload SSL/TLS in [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) per migliorare le prestazioni permettendo al sistema di bilanciamento del carico di gestire la crittografia e la decrittografia SSL/TLS invece di predisporre a questo scopo istanze back-end. In questo modo, puoi ridurre l'utilizzo della CPU sulle istanze back-end, migliorando le prestazioni e aumentando la capacità. 

1.  Utilizza [il Network Load Balancer (NLB)](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/) per implementare servizi basati sul protocollo UDP, tra cui autenticazione e autorizzazione, registrazione, DNS, IoT e streaming di contenuti multimediali, in modo da migliorare le prestazioni e l'affidabilità del carico di lavoro. L'NLB distribuisce il traffico UDP in ingresso tra più destinazioni, permettendo di aumentare o ridurre orizzontalmente il carico di lavoro, incrementare la capacità e diminuire il sovraccarico su un'unica destinazione. 

1.  Per i tuoi carichi di lavoro HPC (calcolo ad alte prestazioni), prendi in considerazione l'utilizzo della funzionalità [Adattatore elastico di rete (ENA) Express](https://aws.amazon.com/about-aws/whats-new/2022/11/elastic-network-adapter-ena-express-amazon-ec2-instances/) , che usa il protocollo SRD per migliorare le prestazioni di rete fornendo una larghezza di banda a flusso singolo più elevata (25 Gbps) e una latenza di coda inferiore (99,9 percentile) per il traffico di rete tra istanze EC2. 

1.  Utilizza [l'Application Load Balancer (ALB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) per instradare il traffico gRPC (Remote Procedure Call) tra componenti del carico di lavoro o tra client e servizi gRPC e per bilanciarne il carico. gRPC usa il protocollo HTTP/2 basato su TCP per il trasporto e fornisce vantaggi in termini di prestazioni, tra cui un impatto di rete minore, la compressione, la serializzazione binaria efficiente, il supporto per diversi linguaggi e lo streaming bidirezionale. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Istanze ottimizzate per Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html) 
+  [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
+  [Reti avanzate su Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html) 
+  [Reti avanzate su Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking.html) 
+  [Gruppi di collocamento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) 
+  [Abilitazione delle reti avanzate con Elastic Network Adapter (ENA) sulle istanze Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) 
+  [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
+  [Nuovi prodotti di rete con AWS](https://aws.amazon.com/products/networking/) 
+  [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw) 
+  [Passaggio all'instradamento basato sulla latenza in Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/TutorialTransitionToLBR.html) 
+  [Endpoint VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) 
+  [Log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 

 **Video correlati:** 
+  [Connectivity to AWS and hybrid AWS network architectures](https://www.youtube.com/watch?v=eqW6CPb58gs) 
+  [Ottimizzazione delle prestazioni di rete per istanze Amazon EC2](https://www.youtube.com/watch?v=DWiwuYtIgu0) 

 **Esempi correlati:** 
+  [AWS Transit Gateway and Scalable Security Solutions](https://github.com/aws-samples/aws-transit-gateway-and-scalable-security-solutions) 
+  [AWS Networking Workshops](https://networking.workshop.aws/) 

# PERF04-BP06 Scelta della posizione del carico di lavoro in base ai requisiti di rete
<a name="perf_networking_choose_workload_location_network_requirements"></a>

Valuta le opzioni per il posizionamento delle risorse in modo da diminuire la latenza di rete e migliorare la velocità di trasmissione effettiva, fornendo un'esperienza utente ottimale attraverso la riduzione dei tempi di caricamento delle pagine e di trasferimento dei dati.

 **Anti-pattern comuni:** 
+  Consolidamento di tutte le risorse del carico di lavoro in un'unica posizione geografica. 
+  Scelta della regione più vicina alla propria posizione, ma non al carico di lavoro dell'utente finale. 

 **Vantaggi dell'adozione di questa best practice:** L'esperienza utente è fortemente condizionata dalla latenza tra utente e applicazione. Utilizzando le Regioni AWS appropriate e una rete globale AWS privata, puoi ridurre la latenza e offrire un'esperienza migliore agli utenti remoti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Le risorse, ad esempio le istanze Amazon EC2, vengono collocate in zone di disponibilità all'interno di [Regioni AWS](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/), [zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/), [AWS Outposts](https://aws.amazon.com/outposts/)o [zone AWS Wavelength](https://aws.amazon.com/wavelength/) . La scelta della posizione influisce sulla latenza di rete e sulla velocità di trasmissione effettiva dall'ubicazione di un utente specifico. Servizi edge come [Amazon CloudFront](https://aws.amazon.com/cloudfront/) e [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) possono essere usati per migliorare le prestazioni di rete memorizzando nella cache i contenuti presso posizioni edge o fornendo agli utenti un percorso ottimale verso il carico di lavoro tramite la rete globale AWS. 

 Amazon EC2 offre gruppi di collocazione per le reti. Un gruppo di collocazione è un raggruppamento logico di istanze per ridurre la latenza. L'utilizzo di gruppi di collocazione con tipi di istanza supportati e un Adattatore elastico di rete (ENA) consente ai carichi di lavoro di partecipare a una rete a 25 Gbps a bassa latenza e a jitter ridotto. I gruppi di collocazione sono consigliati per i carichi di lavoro che traggono beneficio da reti a bassa latenza, throughput di rete elevato o entrambi. 

 I servizi sensibili alla latenza vengono forniti nelle posizioni edge utilizzando una rete AWS globale, ad esempio [Amazon CloudFront](https://aws.amazon.com/cloudfront/). Tali posizioni edge forniscono solitamente servizi come rete di distribuzione di contenuti (CDN) e sistema dei nomi di dominio (DNS). Fornendo questi servizi nell'edge, possono rispondere con una latenza ridotta alle richieste di contenuti o risoluzione DNS. Inoltre, possono offrire servizi geografici come la geotargetizzazione dei contenuti (ossia fornire contenuti diversi in base alla posizione dell'utente finale) o l'instradamento basato sulla latenza, per indirizzare gli utenti alla regione più vicina (latenza minima). 

 Usa i servizi edge per ridurre la latenza e abilitare la memorizzazione nella cache dei contenuti. Configura correttamente il controllo cache sia per DNS sia per HTTP/HTTPS al fine di sfruttare tutti i vantaggi offerti da tali approcci. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Acquisisci informazioni sul traffico IP in entrata e in uscita dalle interfacce di rete. 
  + [ Log del traffico IP tramite log di flusso VPC ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
  + [ Come viene conservato l'indirizzo IP del client in AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/preserve-client-ip-address.headers.html)
+  Analizza i modelli di accesso alla rete nel tuo carico di lavoro per capire come gli utenti usano la tua applicazione. 
  +  Usa strumenti di monitoraggio, come [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) e [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), per raccogliere dati sulle attività di rete. 
  +  Analizza i dati per identificare il modello di accesso alla rete. 
+  Seleziona regioni appropriate per l'implementazione del carico di lavoro in base ai seguenti elementi chiave: 
  +  **Ubicazione dei dati:** per le applicazioni a uso intensivo di dati, ad esempio applicazioni di big data e machine learning, il codice dell'applicazione deve essere eseguito il più vicino possibile ai dati. 
  +  **Ubicazione degli utenti**: per le applicazioni per gli utenti, scegli una regione o più regioni vicine agli utenti del carico di lavoro. 
  +  **Altri vincoli**: considera vincoli quali la sicurezza e la conformità, come illustrato nel post relativo agli [elementi da considerare quando si seleziona una regione per i propri carichi di lavoro.](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
+  Utilizza [zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) per eseguire carichi di lavoro come il rendering video. Le zone locali consentono di sfruttare i vantaggi derivanti dalla disponibilità di risorse di calcolo e archiviazione più vicine agli utenti finali. 
+  Utilizza [AWS Outposts](https://aws.amazon.com/outposts/) per carichi di lavoro che devono rimanere in locale, ma vuoi che vengano eseguiti in modo ottimale con il resto degli altri carichi di lavoro in AWS. 
+  Applicazioni come quelle di streaming di video live ad alta risoluzione, audio ad alta fedeltà o realtà aumentata o realtà virtuale (AR/VR) richiedono latenza bassissima per i dispositivi 5G. Per tali applicazioni, considera [zone AWS Wavelength](https://aws.amazon.com/wavelength/). AWS Wavelength integra i servizi di elaborazione e archiviazione di AWS entro le reti 5G, offrendo un'infrastruttura mobile di edge computing per lo sviluppo, la distribuzione e il dimensionamento di applicazioni a bassissima latenza. 
+  Utilizza la memorizzazione nella cache locale o [soluzioni di memorizzazione nella cache AWS](https://aws.amazon.com/caching/aws-caching/) per gli asset di frequente utilizzo per migliorare le prestazioni, ridurre lo spostamento dei dati e minimizzare l'impatto ambientale.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_networking_choose_workload_location_network_requirements.html)
+  Utilizza servizi in grado di supportarti nell'esecuzione del codice in posizioni più vicine agli utenti del carico di lavoro, come i seguenti:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_networking_choose_workload_location_network_requirements.html)
+  Alcune applicazioni richiedono punti di ingresso fissi o prestazioni più elevate attraverso la riduzione della latenza di ricezione del primo byte e l'instabilità e l'aumento della velocità di trasmissione effettiva. Queste applicazioni possono trarre vantaggio dai servizi di rete che forniscono indirizzi IP anycast statici e cessazione TCP nelle posizioni edge. [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) può migliorare le prestazioni per le applicazioni fino al 60% e offre un failover rapido per architetture in più regioni. AWS Global Accelerator fornisce indirizzi IP anycast statici che operano come punto di ingresso fisso per le applicazioni ospitate in una o più Regioni AWS. Questi indirizzi IP permettono l'ingresso del traffico nella rete AWS globale più vicina possibile agli utenti. AWS Global Accelerator riduce il tempo di configurazione della connessione iniziale stabilendo una connessione TCP tra il client e la posizione edge di AWS più vicina al client. Riesamina l'uso di AWS Global Accelerator per migliorare le prestazioni dei carichi di lavoro TCP/UDP e fornire il rapido failover per architetture in più regioni. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [ COST07-BP02 Implementazione delle regioni in base al costo ](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_pricing_model_region_cost.html)
+ [ COST08-BP03 Implementazione dei servizi per ridurre il costo di trasferimento dei dati ](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_data_transfer_implement_services.html)
+ [ REL10-BP01 Implementazione del carico di lavoro in diversi luoghi ](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_fault_isolation_multiaz_region_system.html)
+ [ REL10-BP02 Selezione delle posizioni appropriate per la tua implementazione multiposizione ](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_fault_isolation_select_location.html)
+ [ SUS01-BP01 Scelta della Regione in base alle esigenze aziendali e agli obiettivi di sostenibilità. ](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_region_a2.html)
+ [ SUS02-BP04 Ottimizzazione del posizionamento geografico dei carichi di lavoro in base ai requisiti di rete ](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_user_a5.html)
+ [ SUS04-BP07 Riduzione al minimo dello spostamento di dati tra reti ](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_data_a8.html)

 **Documenti correlati:** 
+ [ Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [AWS Local Zones and AWS Outposts, choosing the right technology for your edge workload ](https://aws.amazon.com/blogs/compute/aws-local-zones-and-aws-outposts-choosing-the-right-technology-for-your-edge-workload/)
+ [ Gruppi di collocazione ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
+ [ zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)
+ [AWS Outposts](https://aws.amazon.com/outposts/)
+ [ zone AWS Wavelength](https://aws.amazon.com/wavelength/)
+ [ Amazon CloudFront ](https://aws.amazon.com/cloudfront/)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [AWS Direct Connect](https://aws.amazon.com/directconnect/)
+ [AWS Site-to-Site VPN](https://aws.amazon.com/vpn/site-to-site-vpn/)
+ [ Amazon Route 53 ](https://aws.amazon.com/route53/)

 **Video correlati:** 
+ [AWS Local Zones Explainer Video ](https://www.youtube.com/watch?v=JHt-D4_zh7w)
+ [AWS Outposts: Overview and How it Works ](https://www.youtube.com/watch?v=ppG2FFB0mMQ)
+ [AWS re:Invent 2021 - AWS Outposts: Bringing the AWS experience on premises ](https://www.youtube.com/watch?v=FxVF6A22498)
+ [AWS re:Invent 2020: AWS Wavelength: Run apps with ultra-low latency at 5G edge ](https://www.youtube.com/watch?v=AQ-GbAFDvpM)
+ [AWS re:Invent 2022 - AWS Local Zones: Building applications for a distributed edge ](https://www.youtube.com/watch?v=bDnh_d-slhw)
+ [AWS re:Invent 2021 - Building low-latency websites with Amazon CloudFront ](https://www.youtube.com/watch?v=9npcOZ1PP_c)
+ [AWS re:Invent 2022 - Improve performance and availability with AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)
+ [AWS re:Invent 2022 - Build your global wide area network using AWS](https://www.youtube.com/watch?v=flBieylTwvI)
+ [AWS re:Invent 2020: Global traffic management with Amazon Route 53 ](https://www.youtube.com/watch?v=E33dA6n9O7I)

 **Esempi correlati:** 
+ [ Workshop AWS Global Accelerator](https://catalog.us-east-1.prod.workshops.aws/workshops/effb1517-b193-4c59-8da5-ce2abdb0b656/en-US)
+ [ Gestione delle riscritture e dei reindirizzamenti usando funzioni di edge computing ](https://catalog.us-east-1.prod.workshops.aws/workshops/814dcdac-c2ad-4386-98d5-27d37bb77766/en-US)

# PERF04-BP07 Ottimizzazione della configurazione di rete in base alle metriche
<a name="perf_networking_optimize_network_configuration_based_on_metrics"></a>

 Usa i dati raccolti e analizzati per prendere decisioni informate riguardo l'ottimizzazione della configurazione della tua rete. 

 **Anti-pattern comuni:** 
+  Ritieni che tutti i problemi relativi alle prestazioni siano correlati all'applicazione. 
+  Verifica delle prestazioni di rete solo da una posizione vicina a quella in cui è stato distribuito il carico di lavoro. 
+  Uso di configurazioni predefinite per tutti i servizi di rete. 
+  Provisioning in eccesso di risorse di rete per fornire capacità sufficiente. 

 **Vantaggi dell'adozione di questa best practice:** la raccolta delle metriche necessarie per la rete AWS e l'implementazione di strumenti di monitoraggio di rete permettono di identificare le prestazioni di rete e ottimizzare le configurazioni di rete. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Il monitoraggio del traffico da e verso VPC, sottoreti o interfacce di rete è essenziale per identificare come utilizzare risorse di rete AWS e ottimizzare le configurazioni di rete. Usando i seguenti strumenti di rete AWS, puoi esaminare ulteriormente le informazioni sull'utilizzo del traffico, sull'accesso alla rete e sui log. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Identifica le metriche delle prestazioni fondamentali da raccogliere, come la latenza o la perdita di pacchetti. AWS fornisce diversi strumenti che possono aiutarti a raccogliere queste metriche. Usando i seguenti strumenti, puoi esaminare ulteriormente le informazioni sull'utilizzo del traffico, sull'accesso alla rete e sui log:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_networking_optimize_network_configuration_based_on_metrics.html)
+  Identifica i top talker e gli schemi di traffico delle applicazioni utilizzando VPC e i log di flusso di AWS Transit Gateway. 
+  Valuta e ottimizza la tua attuale architettura di rete, inclusi VPC, sottoreti e routing. Ad esempio, puoi valutare come i diversi VPC per il peering o AWS Transit Gateway possono aiutarti a migliorare la rete nella tua architettura. 
+  Valuta i percorsi di routing nella tua rete per verificare che venga sempre utilizzato il percorso più breve tra le destinazioni. Network Access Analyzer può aiutarti a farlo. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Log di flusso VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 
+  [Registrazione delle query DNS pubbliche](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html) 
+  [Che cos'è IPAM?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) 
+  [What is Reachability Analyzer?](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 
+  [What is Network Access Analyzer?](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html) 
+  [Parametri di CloudWatch per i VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cloudwatch.html) 
+  [Ottimizzazione delle prestazioni e riduzione dei costi per l'analisi della rete con log di flusso VPC in formato Apache Parquet ](https://aws.amazon.com/blogs/big-data/optimize-performance-and-reduce-costs-for-network-analytics-with-vpc-flow-logs-in-apache-parquet-format/) 
+  [Monitoring your global and core networks with Amazon CloudWatch metrics](https://docs.aws.amazon.com/vpc/latest/tgwnm/monitoring-cloudwatch-metrics.html) 
+  [Continuously monitor network traffic and resources](https://docs.aws.amazon.com/whitepapers/latest/security-best-practices-for-manufacturing-ot/continuously-monitor-network-traffic-and-resources.html) 

 **Video correlati:** 
+  [Networking best practices and tips with the AWS Well-Architected Framework ](https://www.youtube.com/watch?v=wOMNpG49BeM) 
+  [Monitoring and troubleshooting network traffic ](https://www.youtube.com/watch?v=Ed09ReWRQXc) 

 **Esempi correlati:** 
+  [AWS Networking Workshops](https://networking.workshop.aws/) 
+  [AWS Network Monitoring](https://github.com/aws-samples/monitor-vpc-network-patterns) 

# Processo e cultura
<a name="a-process-culture"></a>

# PERF 5. In che modo le pratiche e la cultura dell'organizzazione contribuiscono all'efficienza delle prestazioni nel carico di lavoro?
<a name="perf-05"></a>

 Durante la fase di progettazione dei carichi di lavoro, esistono principi e pratiche che è possibile adottare per gestire al meglio carichi di lavoro cloud efficienti e ad alte prestazioni. Per adottare una cultura che promuova l'efficienza delle prestazioni dei carichi di lavoro cloud, prendi in considerazione questi principi e pratiche fondamentali: 

**Topics**
+ [PERF05-BP01 Individuazione degli indicatori chiave di prestazioni (KPI) per misurare l'integrità e le prestazioni del carico di lavoro](perf_process_culture_establish_key_performance_indicators.md)
+ [PERF05-BP02 Uso di soluzioni di monitoraggio per comprendere le aree in cui le prestazioni sono più critiche](perf_process_culture_use_monitoring_solutions.md)
+ [PERF05-BP03 Definizione di un processo per migliorare le prestazioni del carico di lavoro](perf_process_culture_workload_performance.md)
+ [PERF05-BP04 Esecuzione del test del carico di lavoro](perf_process_culture_load_test.md)
+ [PERF05-BP05 Uso dell'automazione per risolvere in modo proattivo i problemi relativi alle prestazioni](perf_process_culture_automation_remediate_issues.md)
+ [PERF05-BP06 Aggiornamento continuo del carico di lavoro e dei servizi](perf_process_culture_keep_workload_and_services_up_to_date.md)
+ [PERF05-BP07 Analisi dei parametri a intervalli regolari](perf_process_culture_review_metrics.md)

# PERF05-BP01 Individuazione degli indicatori chiave di prestazioni (KPI) per misurare l'integrità e le prestazioni del carico di lavoro
<a name="perf_process_culture_establish_key_performance_indicators"></a>

 Individua gli indicatori chiave di prestazione (KPI) per misurare le prestazioni del carico di lavoro. I KPI consentono di misurare l'integrità e le prestazioni di un carico di lavoro correlato a un obiettivo aziendale. 

 **Anti-pattern comuni:** 
+  Monitori i parametri a livello di sistema solo per avere una visione del carico di lavoro e non valuti gli impatti aziendali di tali parametri. 
+  Ritieni che i KPI siano già in fase di pubblicazione e condivisi come dati parametrici standard. 
+  Non definisci un KPI quantitativo e misurabile. 
+  Non esegui l'allineamento dei KPI a obiettivi o strategie aziendali. 

 **Vantaggi dell'adozione di questa best practice:** l'individuazione di KPI specifici che rappresentino l'integrità e le prestazioni del carico di lavoro aiuta ad allineare i team alle priorità e a definire risultati aziendali ottimali. La condivisione di tali parametri con tutti i reparti fornisce visibilità e allineamento su soglie, aspettative e impatto aziendale. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Gli indicatori chiave di prestazione consentono ai team aziendali e di ingegneri di allinearsi sulla misurazione degli obiettivi e delle strategie e sul modo in cui questi fattori si combinano per produrre risultati aziendali. Ad esempio, il carico di lavoro di un sito Web può utilizzare il tempo di caricamento della pagina come indicazione delle prestazioni complessive. Questa metrica sarebbe uno dei molteplici punti dati che misurano l'esperienza dell'utente. Oltre a identificare le soglie di tempo di caricamento della pagina, è necessario documentare il risultato atteso o il rischio aziendale se le prestazioni ideali non vengono rispettate. Un lungo tempo di caricamento della pagina si ripercuote direttamente sugli utenti finali, diminuisce la loro esperienza d'uso e può portare a una perdita di clienti. Quando definisci le soglie degli indicatori chiave di prestazione, devi combinare sia i benchmark di settore sia le aspettative degli utenti finali. Ad esempio, se l'attuale benchmark del settore prevede il caricamento di una pagina Web entro un periodo di tempo di due secondi, ma gli utenti finali si aspettano che la pagina Web venga caricata entro un periodo di tempo di un secondo, allora devi prendere in considerazione entrambi i dati al momento di stabilire l'indicatore chiave di prestazione (KPI). 

 Il team deve valutare i KPI del carico di lavoro utilizzando dati granulari in tempo reale e dati storici di riferimento e creare pannelli di controllo che eseguano calcoli metrici sui dati KPI per ricavare informazioni operative e di utilizzo. I KPI devono essere documentati e includere le soglie che supportano gli obiettivi e le strategie aziendali e che sono mappati sui parametri da monitorare. Gli indicatori chiave di prestazione devono essere riesaminati quando cambiano gli obiettivi aziendali, le strategie o i requisiti degli utenti finali.   

## Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Individua e documenta gli stakeholder aziendali. 

1.  Collabora con questi stakeholder per definire e documentare gli obiettivi del carico di lavoro. 

1.  Esamina le best practice del settore per individuare i KPI pertinenti in linea con gli obiettivi del carico di lavoro. 

1.  Utilizza le best practice del settore e gli obiettivi di carico di lavoro per fissare i valori dei KPI del carico di lavoro. Utilizza queste informazioni per impostare soglie dei KPI per livello di gravità o allarme. 

1.  Identificare e documentare il rischio e l'impatto se il KPI non viene raggiunto. 

1.  Individua e documenta i parametri che possono aiutarti a determinare i KPI. 

1.  Usa strumenti di monitoraggio, come [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) oppure [AWS Config](https://aws.amazon.com/config/) per raccogliere metriche e misurare i KPI. 

1.  Usa le dashboard per visualizzare e comunicare i KPI agli stakeholder. 

1.  Esamina e analizza regolarmente i parametri per individuare le aree del carico di lavoro che devono essere migliorate. 

1.  Riesamina i KPI quando gli obiettivi aziendali o le prestazioni del carico di lavoro cambiano. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Documentazione di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [Monitoraggio, registrazione di log e prestazioni - AWS Partner](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+  [X-Ray Documentation (Documentazione di X-Ray)](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+  [Utilizzo dei pannelli di controllo Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html?ref=wellarchitected) 
+  [Quick KPIs (KPI di Amazon QuickSight)](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html) 

 **Video correlati:** 
+  [AWS re:Invent 2019: Scaling up to your first 10 million users](https://www.youtube.com/watch?v=kKjm4ehYiMs&ref=wellarchitected) 
+  [Cut through the chaos: Gain operational visibility and insight](https://www.youtube.com/watch?v=nLYGbotqHd0&ref=wellarchitected) 
+  [Creazione di un piano di monitoraggio](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) 

 **Esempi correlati:** 
+  [Creating a dashboard with Quick (Creazione di un pannello di controllo con Amazon QuickSight)](https://github.com/aws-samples/amazon-quicksight-sdk-proserve) 

# PERF05-BP02 Uso di soluzioni di monitoraggio per comprendere le aree in cui le prestazioni sono più critiche
<a name="perf_process_culture_use_monitoring_solutions"></a>

 Comprendi e identifica le aree in cui l'aumento delle prestazioni del carico di lavoro determinerà un impatto positivo sull'efficienza o sull'esperienza del cliente. Ad esempio, un sito web che ha una grande quantità di interazione con i clienti può trarre vantaggio dall'utilizzo dei servizi edge per spostare la distribuzione di contenuti più vicino ai clienti. 

 **Anti-pattern comuni:** 
+  Ritieni che i parametri di calcolo standard, ad esempio l'utilizzo della CPU o il carico della memoria, siano sufficienti per rilevare problemi di prestazioni. 
+  Utilizzi solo i parametri predefiniti registrati dal software di monitoraggio selezionato. 
+  Rivedi i parametri solo quando c'è un problema. 

 **Vantaggi dell'adozione di questa best practice:** l'individuazione delle aree critiche delle prestazioni consente ai proprietari del carico di lavoro di monitorare i KPI e dare priorità ai miglioramenti ad alto impatto. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Configura il tracciamento end-to-end per identificare gli schemi di traffico, la latenza e le aree con prestazioni critiche. Monitora gli schemi di accesso ai dati per query lente o dati scarsamente frammentati e partizionati. Identifica le aree vincolate del carico di lavoro utilizzando il test o il monitoraggio del carico. 

 aumenta l'efficienza delle prestazioni comprendendo l'architettura, gli schemi di traffico e gli schemi di accesso ai dati e identifica la latenza e i tempi di elaborazione. Identifica i potenziali colli di bottiglia che potrebbero influire sull'esperienza del cliente man mano che il carico di lavoro aumenta. Dopo aver identificato queste aree, individua quale soluzione puoi implementare per evitare tali problemi di prestazioni. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1.  Configura il monitoraggio end-to-end per acquisire tutti i componenti e i parametri del carico di lavoro. Ecco alcuni esempi di soluzioni di monitoraggio su AWS.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/perf_process_culture_use_monitoring_solutions.html)

1.  Esegui i test per generare parametri, identificare schemi di traffico, colli di bottiglia e aree con prestazioni critiche. Ecco alcuni esempi di come eseguire i test: 
   +  Configura [i canary sintetici di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) per simulare le attività degli utenti basate sul browser in modo programmatico utilizzando espressioni della frequenza o processi CRON di Linux per generare parametri coerenti nel tempo. 
   +  Utilizza [AWS Distributed Load Testing (Test di carico distribuito in AWS)](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) per generare picchi di traffico o testare il carico di lavoro al tasso di crescita previsto. 

1.  Valuta i parametri e i dati di telemetria per identificare le aree critiche delle prestazioni. Esamina queste aree con il tuo team per determinare il monitoraggio e le soluzioni per evitare i colli di bottiglia. 

1.  Sperimenta i miglioramenti delle prestazioni e valuta tali modifiche con i dati. Ad esempio, puoi usare la [CloudWatch Evidently](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html) per testare nuovi miglioramenti e impatti sulle prestazioni del tuo carico di lavoro. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Amazon Builders' Library](https://aws.amazon.com/builders-library) 
+  [X-Ray Documentation (Documentazione di X-Ray)](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+  [Usare Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 
+  [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) 

 **Video correlati:** 
+  [The Amazon Builders’ Library: 25 years of Amazon operational excellence](https://www.youtube.com/watch?v=DSRhgBd_gtw) 
+  [Visual Monitoring of Applications with Amazon CloudWatch Synthetics](https://www.youtube.com/watch?v=_PCs-ucZz7E) 

 **Esempi correlati:** 
+  [Measure page load time with Amazon CloudWatch Synthetics (Misurare il tempo di caricamento della pagina con Amazon CloudWatch Synthetics)](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance) 
+  [Amazon CloudWatch RUM Web Client (Client Web Amazon CloudWatch RUM)](https://github.com/aws-observability/aws-rum-web) 
+  [SDK X-Ray per Node.js](https://github.com/aws/aws-xray-sdk-node) 
+  [SDK X-Ray per Phyton](https://github.com/aws/aws-xray-sdk-python) 
+  [SDK X-Ray per Java](https://github.com/aws/aws-xray-sdk-java) 
+  [SDK X-Ray per .Net](https://github.com/aws/aws-xray-sdk-dotnet) 
+  [SDK X-Ray per Ruby](https://github.com/aws/aws-xray-sdk-ruby) 
+  [Daemon X-Ray](https://github.com/aws/aws-xray-daemon) 
+  [Test di carico distribuito in AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 

# PERF05-BP03 Definizione di un processo per migliorare le prestazioni del carico di lavoro
<a name="perf_process_culture_workload_performance"></a>

 Definisci un processo per valutare i nuovi servizi, i modelli di progettazione, i tipi di risorse e le configurazioni man mano che diventano disponibili. Ad esempio, esegui test delle prestazioni esistenti sulle nuove offerte di istanze per determinare il loro potenziale per migliorare il carico di lavoro. 

 **Anti-pattern comuni:** 
+  Ritieni che l'architettura corrente diventi statica e non venga aggiornata nel corso del tempo. 
+  Introduci modifiche all'architettura nel tempo senza dei parametri che le giustifichino. 

 **Vantaggi dell'adozione di questa best practice:** Definire un processo per apportare modifiche all'architettura consente ai dati raccolti di influenzare la progettazione del carico di lavoro nel corso del tempo. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Le prestazioni del carico di lavoro presentano alcuni vincoli principali. Documentali, in modo da sapere quali tipi di innovazione potrebbero migliorare le prestazioni del carico di lavoro. Utilizza queste informazioni quando vieni a conoscenza di nuovi servizi e tecnologie, man mano che si rendono disponibili, in modo da identificare le soluzioni per ovviare ai vincoli o ai colli di bottiglia. 

 Determina i principali vincoli riguardanti le prestazioni del carico di lavoro. Documenta i vincoli prestazionali del carico di lavoro in modo da sapere quali tipi di innovazione potrebbero migliorare le prestazioni del carico di lavoro. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Identifica i KPI relativi alle prestazioni del carico di lavoro come indicato in [PERF05-BP01 Individuazione degli indicatori chiave di prestazioni (KPI) per misurare l'integrità e le prestazioni del carico di lavoro](perf_process_culture_establish_key_performance_indicators.md) per stabilire una baseline per il carico di lavoro. 
+  utilizza [strumenti di osservabilità di AWS](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/aws-observability-tools.html) per raccogliere metriche sulle prestazioni e misurare i KPI. 
+  Conduci un'analisi approfondita per individuare le aree (come la configurazione e il codice applicativo) del carico di lavoro con prestazioni insufficienti, come indicato in [PERF05-BP02 Uso di soluzioni di monitoraggio per comprendere le aree in cui le prestazioni sono più critiche](perf_process_culture_use_monitoring_solutions.md). 
+  Usa i tuoi strumenti di analisi e prestazioni per individuare la strategia di ottimizzazione delle prestazioni. 
+  Utilizza gli ambienti di sperimentazione (sandbox) o di preproduzione per convalidare l'efficacia della strategia. 
+  Implementa le modifiche in produzione e monitora continuamente le prestazioni del carico di lavoro. 
+  Documenta i miglioramenti e comunicali agli stakeholder. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Blog AWS](https://aws.amazon.com/blogs/) 
+  [Novità di AWS](https://aws.amazon.com/new/?ref=wellarchitected) 

 **Video correlati:** 
+  [Canale YouTube degli eventi AWS](https://www.youtube.com/channel/UCdoadna9HFHsxXWhafhNvKw) 
+  [Canale YouTube dei Tech talk online di AWS](https://www.youtube.com/user/AWSwebinars) 
+  [Canale YouTube di Amazon Web Services](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg) 

 **Esempi correlati:** 
+  [Github AWS](https://github.com/aws) 
+  [AWS Skill Builder](https://explore.skillbuilder.aws/learn) 

# PERF05-BP04 Esecuzione del test del carico di lavoro
<a name="perf_process_culture_load_test"></a>

 Esegui il test del carico di lavoro per verificare che sia in grado di gestire la produzione e individuare eventuali colli di bottiglia nelle prestazioni. 

 **Anti-pattern comuni:** 
+  Vengono testate le singole parti del carico di lavoro, ma non l'intero carico di lavoro. 
+  Il test di carico viene eseguito su un'infrastruttura diversa dall'ambiente di produzione. 
+  Esegui i test di carico solo per il carico previsto e non oltre, per prevedere dove si potrebbero riscontrare problemi futuri. 
+  Esegui test di carico senza consultare la [Politica di test di Amazon EC2](https://aws.amazon.com/ec2/testing/) e inviando un modulo di invio di eventi simulati. Ciò comporta la mancata esecuzione del test, poiché sembra un evento di negazione del servizio. 

 **Vantaggi dell'adozione di questa best practice:** Misurando le prestazioni in un test di carico, potrai vedere dove avrà luogo l'impatto con l'aumento del carico. In questo modo puoi anticipare le modifiche necessarie prima che influiscano sul carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Il test di carico nel cloud è un processo per misurare le prestazioni del carico di lavoro in condizioni realistiche e con il carico degli utenti previsto. Questo processo prevede il provisioning di un ambiente cloud simile a quello di produzione, l'utilizzo di strumenti di test di carico per generare il carico e l'analisi dei parametri per valutare la capacità del carico di lavoro di gestire un carico realistico. Occorre eseguire i test di carico tramite versioni sintetiche o purificate dei dati di produzione (rimuovendo le informazioni sensibili o che permettono l'identificazione degli utenti). Esegui automaticamente test di carico come parte della pipeline di distribuzione e confronta i risultati con KPI e soglie predefiniti. Questo processo ti consente di ottenere le prestazioni richieste. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Configura l'ambiente di test in base al tuo ambiente di produzione. Puoi utilizzare i servizi AWS per eseguire ambienti in ambito di produzione e sottoporre l'architettura a test. 
+  Scegli e configura lo strumento di test più adatto al carico di lavoro. 
+  Definisci gli scenari e i parametri del test di carico (come la durata del test e il numero di utenti). 
+  Esegui gli scenari di test su larga scala. Sfrutta i vantaggi offerti dal Cloud AWS per testare il carico di lavoro e scoprire dove la scalabilità non è possibile o se non è lineare. Ad esempio, usa le istanze Spot per generare carichi a costi ridotti e rilevare i colli di bottiglia prima che si verifichino in produzione. 
+  Monitora e registra i parametri delle prestazioni (come la velocità di trasmissione effettiva e il tempo di risposta). Amazon CloudWatch può raccogliere i parametri per le risorse dell'architettura in uso. Puoi anche raccogliere e pubblicare parametri personalizzati per ottenere parametri aziendali o derivati. 
+  Analizza i risultati per individuare i colli di bottiglia delle prestazioni e le aree di miglioramento. 
+  Documenta il processo e comunica i risultati del test di carico. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
+  [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 
+  [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [Distributed Load Testing on AWS (Test di carico distribuito in AWS)](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/welcome.html) 

 **Video correlati:** 
+  [Solving with AWS Solutions: Distributed Load Testing](https://www.youtube.com/watch?v=Y-2rk0sSyOM) 
+  [Optimize applications through Amazon CloudWatch RUM (Ottimizzazione delle applicazioni tramite RUM Amazon CloudWatch)](https://www.youtube.com/watch?v=NMaeujY9A9Y) 
+  [Demo di Amazon CloudWatch Synthetics](https://www.youtube.com/watch?v=hF3NM9j-u7I) 

 **Esempi correlati:** 
+  [Test di carico distribuito in AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 

# PERF05-BP05 Uso dell'automazione per risolvere in modo proattivo i problemi relativi alle prestazioni
<a name="perf_process_culture_automation_remediate_issues"></a>

 Utilizza indicatori chiave di prestazioni (KPI), in combinazione con sistemi di monitoraggio e allarmi, per risolvere in modo proattivo i problemi correlati alle prestazioni. 

 **Anti-pattern comuni:** 
+  Consenti solo al personale operativo di apportare modifiche operative al carico di lavoro. 
+  Lasci che tutti gli allarmi giungano direttamente al team operativo senza alcuna correzione proattiva. 

 **Vantaggi dell'adozione di questa best practice:** La correzione proattiva delle azioni di allarme consente al personale di supporto di concentrarsi sugli elementi che non sono attivabili automaticamente. In questo modo, il personale operativo non viene sovraccaricato da tutti gli allarmi e si concentra, invece, solo sugli allarmi critici. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Laddove possibile, utilizza gli allarmi per attivare operazioni automatizzate per risolvere i problemi. Se non è possibile rispondere in modo automatizzato, inoltra l'allarme a coloro che possono intervenire. Ad esempio, puoi implementare un sistema in grado di prevedere i valori attesi per gli indicatori chiave di prestazioni (KPI) e di inviare allarmi qualora essi oltrepassino determinate soglie, oppure uno strumento che arresta o esegue automaticamente il rollback delle implementazioni nel caso in cui i valori dei KPI si discostino dai valori attesi. 

 Implementa processi che forniscono visibilità sulle prestazioni durante l'esecuzione del carico di lavoro. Crea pannelli di controllo del monitoraggio e stabilisci norme di riferimento per le aspettative riguardanti le prestazioni, per determinare se il carico di lavoro ha prestazioni ottimali. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Individua e comprendi il problema delle prestazioni che può essere risolto automaticamente. Utilizza soluzioni di monitoraggio di AWS come [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) o AWS X-Ray per aiutarti a comprendere meglio la causa principale del problema. 
+  Crea un piano e un processo di risoluzione dettagliato che possono essere utilizzati per risolvere automaticamente il problema. 
+  Configura il trigger per avviare automaticamente il processo di risoluzione. Ad esempio, è possibile definire un trigger per riavviare automaticamente un'istanza quando raggiunge una determinata soglia di utilizzo della CPU. 
+  Utilizza i servizi e le tecnologie AWS per automatizzare il processo di risoluzione. Ad esempio, [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) fornisce un modo sicuro e scalabile per automatizzare il processo di risoluzione. 
+  Esegui il test del processo di risoluzione automatizzato in un ambiente di preproduzione. 
+  Dopo i test, implementa il processo di risoluzione nell'ambiente di produzione e monitora continuamente per individuare le aree di miglioramento. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Documentazione di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [Monitoraggio, registrazione di log e prestazioni - Partner AWS Partner Network](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+  [X-Ray Documentation (Documentazione di X-Ray)](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 
+  [Using Alarms and Alarm Actions in CloudWatch (Utilizzo degli allarmi e delle azioni di allarme in Amazon CloudWatch)](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html) 

 **Video correlati:** 
+  [Intelligently automating cloud operations](https://www.youtube.com/watch?v=m0S8eAF0l54) 
+  [Setting up controls at scale in your AWS environment](https://www.youtube.com/watch?v=NkE9_okfPG8) 
+  [Automating patch management and compliance using AWS](https://www.youtube.com/watch?v=gL3baXQJvc0) 
+  [How Amazon uses better metrics for improved website performance](https://www.youtube.com/watch?v=_uaaCiyJCFA&ab_channel=AWSEvents) 

 **Esempi correlati:** 
+  [CloudWatch Logs Customize Alarms](https://github.com/awslabs/cloudwatch-logs-customize-alarms) 

# PERF05-BP06 Aggiornamento continuo del carico di lavoro e dei servizi
<a name="perf_process_culture_keep_workload_and_services_up_to_date"></a>

 Rimani aggiornato sui nuovi servizi cloud per adottare funzionalità efficienti, rimuovere i problemi e migliorare l'efficienza complessiva delle prestazioni del tuo carico di lavoro. 

 **Anti-pattern comuni:** 
+  Ritieni che l'architettura corrente diventi statica e non venga aggiornata nel corso del tempo. 
+  Non disponi di sistemi né esegui regolarmente una valutazione per la compatibilità di software e pacchetti aggiornati con il carico di lavoro. 

 **Vantaggi dell'adozione di questa best practice:** stabilendo un processo per rimanere aggiornati su nuovi servizi e offerte, è possibile adottare nuove capacità e funzionalità, risolvere problemi e migliorare le prestazioni dei carichi di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Valuta i modi per migliorare le prestazioni man mano che nuovi servizi, modelli di progettazione e funzionalità di prodotti diventano disponibili. Determina come possono migliorare le prestazioni o aumentare l'efficienza del carico di lavoro tramite una valutazione, una discussione interna o un'analisi esterna. Definisci un processo per valutare gli aggiornamenti, le nuove funzioni e i servizi rilevanti per il tuo carico di lavoro. Ad esempio, crea un proof of concept che utilizza le nuove tecnologie o consultati con un gruppo interno. Quando provi nuove idee o servizi, esegui i test delle prestazioni per misurare l'impatto del carico di lavoro sulle prestazioni. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Esegui l'inventario del software e dell'architettura e identifica i componenti che richiedono un aggiornamento. 
+  Identifica le novità e le fonti di aggiornamento relative ai componenti del carico di lavoro. Ad esempio, puoi iscriverti al [blog Novità di AWS](https://aws.amazon.com/new/) per i prodotti che corrispondono al componente del carico di lavoro. Puoi iscriverti al feed RSS o gestire le tue [sottoscrizioni e-mail](https://pages.awscloud.com/communication-preferences.html). 
+  Definisci una pianificazione per valutare nuovi servizi e funzionalità per il tuo carico di lavoro. 
  +  Puoi utilizzare [AWS Systems Manager Inventory](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html) per raccogliere i metadati relativi a sistema operativo (SO), applicazioni e istanze dalle istanze Amazon EC2 per avere una panoramica immediata su quali istanze stanno eseguendo il software e le configurazioni richieste dalle policy software e quali istanze devono essere aggiornate. 
+  Individua le modalità di aggiornamento dei componenti del carico di lavoro. Sfrutta l'agilità del cloud per testare in modo semplice e rapido il modo in cui le nuove funzionalità possono migliorare il carico di lavoro per ottenere efficienza delle prestazioni. 
+  Utilizza l'automazione del processo di aggiornamento per ridurre il livello di impegno per distribuire le nuove funzionalità e limitare gli errori causati dai processi manuali. 
  +  Puoi utilizzare [CI/CD](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/) per aggiornare automaticamente le AMI, le immagini di container e altri artefatti relativi alla tua applicazione cloud. 
  +  Puoi usare strumenti come [Gestione patch di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) per automatizzare il processo di aggiornamento del sistema e pianificare l'attività utilizzando le [finestre di manutenzione di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html). 
+  Documenta il processo di valutazione di aggiornamenti e nuovi servizi. Fornisci ai proprietari il tempo e lo spazio necessari per ricercare, testare, sperimentare e convalidare aggiornamenti e nuovi servizi. Fai riferimento ai requisiti aziendali e ai KPI documentati per stabilire la priorità dell'aggiornamento che avrà un impatto positivo sull'azienda. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Blog AWS](https://aws.amazon.com/blogs/) 
+  [Novità di AWS](https://aws.amazon.com/new/?ref=wellarchitected) 

 **Video correlati:** 
+  [Canale YouTube degli eventi AWS](https://www.youtube.com/channel/UCdoadna9HFHsxXWhafhNvKw) 
+  [Canale YouTube dei Tech talk online di AWS](https://www.youtube.com/user/AWSwebinars) 
+  [Canale YouTube di Amazon Web Services](https://www.youtube.com/channel/UCd6MoB9NC6uYN2grvUNT-Zg) 

 **Esempi correlati:** 
+  [Well-Architected Labs: Inventario e gestione delle patch](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/) 
+  [Laboratorio: AWS Systems Manager](https://mng.workshop.aws/ssm.html) 

# PERF05-BP07 Analisi dei parametri a intervalli regolari
<a name="perf_process_culture_review_metrics"></a>

 Come manutenzione ordinaria o in risposta a eventi o incidenti, esamina quali parametri vengono raccolti. Stabilisci quali di questi parametri sono fondamentali per risolvere i problemi e quali altri parametri aggiuntivi, se monitorati, possono contribuire a identificare, affrontare o prevenire i problemi. 

 **Anti-pattern comuni:** 
+  Lasci che i parametri rimangano in uno stato di allarme per un lungo periodo di tempo. 
+  Crei allarmi che non sono utilizzabili da un sistema di automazione. 

 **Vantaggi dell'adozione di questa best practice:** Esamina continuamente i parametri raccolti per verificare che identifichino, risolvano o prevengano adeguatamente i problemi. I parametri possono anche diventare obsoleti se lasciati in uno stato di allarme per un lungo periodo di tempo. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Migliora continuamente la raccolta e il monitoraggio dei parametri. Nell'ambito della risposta a incidenti ed eventi, valuta quali parametri sono stati utili per affrontare il problema e quali sarebbero stati utili ma non sono attualmente misurati. Questo metodo ti aiuterà a migliorare la qualità dei parametri raccolti, in modo da prevenire o risolvere più rapidamente gli incidenti futuri. 

 Nell'ambito della risposta a incidenti ed eventi, valuta quali parametri sono stati utili per affrontare il problema e quali sarebbero stati utili ma non sono attualmente misurati. Queste considerazioni ti aiuteranno a migliorare la qualità dei parametri raccolti, per prevenire o risolvere più rapidamente gli incidenti futuri. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

1. Definisci metriche prestazionali critiche da monitorare in linea con il tuo obiettivo di carico di lavoro. 

1. Imposta un valore di base e auspicabile per ogni metrica. 

1. Imposta una cadenza (ad esempio settimanale o mensile) per rivedere le metriche più critiche. 

1. Durante ogni revisione, valuta le tendenze e la deviazione dai valori di base. Cerca eventuali rallentamenti o anomalie nelle prestazioni. 

1. Per i problemi identificati, esegui un'analisi approfondita delle cause principali per comprendere il motivo più importante alla base del problema. 

1. Documenta gli esiti e utilizza strategie per affrontare i problemi e i rallentamenti identificati. 

1. Valuta e migliora continuamente il processo di revisione delle metriche.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Documentazione di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [Raccolta di parametri e registri da istanze Amazon EC2 e da server on-premise con l'agente di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected) 
+  [Monitoraggio, registrazione di log e prestazioni - Partner AWS Partner Network](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance) 
+  [X-Ray Documentation (Documentazione di X-Ray)](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 

 **Video correlati:** 
+  [Setting up controls at scale in your AWS environment](https://www.youtube.com/watch?v=NkE9_okfPG8) 
+  [How Amazon uses better metrics for improved website performance](https://www.youtube.com/watch?v=_uaaCiyJCFA&ab_channel=AWSEvents) 

 **Esempi correlati:** 
+  [Creating a dashboard with Quick (Creazione di un pannello di controllo con Amazon QuickSight)](https://github.com/aws-samples/amazon-quicksight-sdk-proserve) 
+  [Level 100: Monitoring with CloudWatch Dashboards (Livello 100: Monitoraggio con i pannelli di controllo CloudWatch)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) 

# Ottimizzazione dei costi
<a name="a-cost-optimization"></a>

Il principio dell'ottimizzazione dei costi include la possibilità di eseguire sistemi per offrire valore aggiunto al prezzo più basso. È possibile trovare linee guida prescrittive sull'implementazione nel [Whitepaper sul principio dell'ottimizzazione dei costi](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html?ref=wellarchitected-wp).

**Topics**
+ [Implementazione della gestione finanziaria del cloud](a-practice-cloud-financial-management.md)
+ [Comprensione delle spese e dell'utilizzo](a-expenditure-and-usage-awareness.md)
+ [Risorse a costi contenuti](a-cost-effective-resources.md)
+ [Gestione delle risorse di domanda e offerta](a-manage-demand-and-supply-resources.md)
+ [Ottimizzazione nel tempo](a-optimize-over-time.md)

# Implementazione della gestione finanziaria del cloud
<a name="a-practice-cloud-financial-management"></a>

**Topics**
+ [COST 1. Come implementi la gestione finanziaria nel cloud?](cost-01.md)

# COST 1. Come implementi la gestione finanziaria nel cloud?
<a name="cost-01"></a>

L'implementazione della gestione finanziaria del cloud aiuta le organizzazioni a conseguire un valore aggiunto e il successo finanziario ottimizzando i costi e l'utilizzo e dimensionando le risorse in AWS.

**Topics**
+ [COST01-BP01 Stabilire la responsabilità dell'ottimizzazione dei costi](cost_cloud_financial_management_function.md)
+ [COST01-BP02 Definizione di una partnership tra team finanziari e tecnologici](cost_cloud_financial_management_partnership.md)
+ [COST01-BP03 Definizione di budget e previsioni per il cloud](cost_cloud_financial_management_budget_forecast.md)
+ [COST01-BP04 Implementazione della consapevolezza dei costi nei processi dell'organizzazione](cost_cloud_financial_management_cost_awareness.md)
+ [COST01-BP05 Invio di report e notifiche sull'ottimizzazione dei costi](cost_cloud_financial_management_usage_report.md)
+ [COST01-BP06 Monitoraggio proattivo dei costi](cost_cloud_financial_management_proactive_process.md)
+ [COST01-BP07 Mantenimento dell'aggiornamento sulle nuove versioni dei servizi](cost_cloud_financial_management_scheduled.md)
+ [COST01-BP08 Creazione di una cultura consapevole dei costi](cost_cloud_financial_management_culture.md)
+ [COST01-BP09 Quantificare il valore aggiunto realizzato attraverso l'ottimizzazione dei costi](cost_cloud_financial_management_quantify_value.md)

# COST01-BP01 Stabilire la responsabilità dell'ottimizzazione dei costi
<a name="cost_cloud_financial_management_function"></a>

 Crea un team (Cloud Business Office, Cloud Center of Excellence, o FinOps) responsabile di stabilire e mantenere la consapevolezza dei costi in tutta l'organizzazione. Il responsabile dell'ottimizzazione dei costi può essere un individuo o un team (sono necessarie persone provenienti da team finanziari, tecnologici e aziendali) che ha una comprensione dell'intera organizzazione e degli aspetti finanziari legati al cloud. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Questa è un'introduzione al processo di formazione di un team Ufficio aziendale per il cloud (Cloud Business Office, CBO) o Centro di eccellenza del cloud (Cloud Center of Excellence, CCoE) responsabile di stabilire e mantenere una cultura basata sulla consapevolezza dei costi legati al cloud computing. Può trattarsi di una figura professionale già in organico, di un team all'interno della tua organizzazione o di un nuovo team di stakeholder chiave dei settori finanza, tecnologia e organizzazione provenienti da tutta l'azienda. 

 La funzione (individuo o team) stabilisce le priorità e dedica la parte prevista del proprio tempo alle attività di gestione e ottimizzazione dei costi. In un'organizzazione di dimensioni ridotte, la quantità di tempo dedicata dalla funzione potrebbe essere inferiore rispetto a quella dedicata da una funzione a tempo pieno in un'azienda di dimensioni maggiori. 

 Questa funzione (individuo o team) stabilisce le priorità e dedica la parte prevista del proprio tempo alle attività di gestione e ottimizzazione dei costi. Per una piccola organizzazione, la funzione potrebbe dedicare una percentuale di tempo inferiore alle attività di gestione e ottimizzazione dei costi rispetto a una funzione a tempo pieno per un'azienda più grande. 

 La funzione richiede un approccio multidisciplinare, con capacità di gestione dei progetti, data science, analisi finanziaria e sviluppo di software o infrastruttura. Può migliorare l'efficienza del carico di lavoro eseguendo ottimizzazioni dei costi all'interno di tre diversi tipi di responsabilità: 
+  **Team centralizzati:** attraverso team designati come il team FinOps, il team Cloud Financial Management (CFM), l’Ufficio aziendale per il cloud (Cloud Business Office, CBO) o il Centro di eccellenza del cloud (Cloud Center of Excellence, CCoE), i clienti possono progettare e implementare meccanismi di governance e promuovere le best practice a livello aziendale. 
+  **Team decentralizzati:** Influenzando i team tecnologici per ottimizzare i costi. 
+  **Team ibridi:** Una combinazione di team centralizzati e decentralizzati può collaborare fattivamente per eseguire l'ottimizzazione dei costi. 

 La funzione può essere valutata in base alla sua capacità di eseguire e conseguire risultati rispetto agli obiettivi di ottimizzazione dei costi (ad esempio in base a parametri di efficienza dei carichi di lavoro). 

 Un fattore chiave per il successo di questa funzione è la disponibilità di sponsorizzazione da parte del management. Lo sponsor deve essere un sostenitore del consumo efficiente del cloud e fornire alla funzione un supporto in caso di escalation, per garantire che le attività di ottimizzazione dei costi vengano trattate con il livello di priorità definito dall'organizzazione. In caso contrario, le linee guida possono essere ignorate e non verrà data priorità alle opportunità di riduzione dei costi. Insieme, lo sponsor (cioè la figura o le figure di garanzia all’interno del management) e il team dell'organizzazione possono aiutare a utilizzare il cloud in modo efficiente e generare valore aziendale. 

 Se hai un piano di supporto Business, Enterprise-On-Ramp o [Enterprise](https://aws.amazon.com/premiumsupport/plans/) e hai bisogno di aiuto per creare questo team o questa funzione, contatta i tuoi esperti di Cloud Financial Management (CFM) tramite il team del tuo account. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Definizione dei membri chiave:** tutte le parti rilevanti della tua organizzazione devono contribuire ed essere interessate alla gestione dei costi. I team più comuni all'interno delle organizzazioni includono in genere: team finanziari, responsabili di applicazioni o prodotti, team di gestione e team tecnici (DevOps). Alcuni soggetti sono impegnati a tempo pieno (ad esempio quelli di tipo finanziario o tecnico), mentre altri sono coinvolti periodicamente secondo necessità. I singoli o i team che svolgono mansioni di gestione finanziaria del cloud devono disporre del seguente set di competenze: 
  +  **Sviluppo software:** nel caso in cui vengano creati script e automazione. 
  +  **Progettazione dell'infrastruttura:** per implementare script, automatizzare processi e comprendere in che modo viene effettuato il provisioning di risorse e servizi. 
  +  **Acume operativo:** gestione finanziaria del cloud significa una presenza efficiente nel cloud mediante la misurazione, il monitoraggio, la modifica, la pianificazione e il dimensionamento dell'utilizzo efficiente del cloud stesso. 
+  **Definizione di obiettivi e parametri: **La funzione deve fornire valore all'organizzazione in modi diversi. Questi obiettivi sono definiti e si evolvono continuamente con l'evolversi dell'organizzazione. Tra le attività più comuni figurano la creazione e l'esecuzione di programmi di formazione sull'ottimizzazione dei costi in tutta l'organizzazione, lo sviluppo di standard a livello aziendale, come monitoraggio ed elaborazione di report per l'ottimizzazione dei costi, e la definizione degli obiettivi di ottimizzazione dei carichi di lavoro. Inoltre, è necessario comunicare regolarmente all'organizzazione la relativa capacità di ottimizzazione dei costi. 

   È possibile definire gli indicatori chiave delle prestazioni (KPI) basati sui valori o sui costi. Quando vengono definiti i KPI, è possibile calcolare il costo previsto in termini di efficienza e risultati aziendali previsti. I KPI basati sui valori associano le metriche relative a costi e utilizzo ai fattori legati al valore aziendale e ciò aiuta a razionalizzare le modifiche ai livelli di spesa per AWS. Il primo passo per derivare i KPI basati sui valori è collaborare tra organizzazioni al fine di scegliere e concordare un set standard di KPI. 
+  **Definizione di una regolare cadenza:** il gruppo (team finanziario, tecnologico e aziendale) deve riunirsi regolarmente per rivedere le metriche e gli obiettivi. Una periodicità tipica implica la revisione dello stato dell'organizzazione, la revisione dei programmi attualmente in esecuzione e la revisione dei parametri finanziari e di ottimizzazione generali. Quindi, per i carichi di lavoro chiave, è opportuno elaborare report più dettagliati. 

   Durante queste riunioni periodiche è possibile analizzare l'efficienza (costo) dei carichi di lavoro e il risultato aziendale. Ad esempio, un incremento del 20% dei costi di un carico di lavoro potrebbe essere determinato dall'aumento dell'utilizzo da parte dei clienti. In questo caso, l'incremento del 20% dei costi può essere interpretato come investimento. Questi incontri periodici possono aiutare i team a individuare i KPI basati sul valore in grado di garantire un valore aggiunto all'intera organizzazione. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS CCOE Blog (Blog CCOE AWS)](https://aws.amazon.com/blogs/enterprise-strategy/tag/ccoe/) 
+  [Creating Cloud Business Office (Creazione di un ufficio aziendale per il cloud)](https://aws.amazon.com/blogs/enterprise-strategy/creating-the-cloud-business-office/) 
+  [CCOE - Cloud Center of Excellence (CCoE - Centro di eccellenza del Cloud)](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html) 

 **Video correlati:** 
+ [Vanguard CCOE Success Story (Storia di successo CCOE Vanguard)](https://www.youtube.com/watch?v=0XA08hhRVFQ)

 **Esempi correlati:** 
+ [Using a Cloud Center of Excellence (CCOE) to Transform the Entire Enterprise (Utilizzo di un Centro di eccellenza del Cloud [CCoE] per trasformare l'intera azienda)](https://aws.amazon.com/blogs/enterprise-strategy/using-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise/)
+ [Building a CCOE to transform the entire enterprise (Creazione di un Centro di eccellenza del Cloud [CCoE] per trasformare l'intera azienda)](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/building-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise.html)
+ [7 Pitfalls to Avoid When Building CCOE (7 errori da evitare durante la creazione di un Centro di eccellenza del Cloud [CCoE])](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/)

# COST01-BP02 Definizione di una partnership tra team finanziari e tecnologici
<a name="cost_cloud_financial_management_partnership"></a>

Coinvolgi i team finanziari e tecnologici nelle discussioni su costi e utilizzo in tutte le fasi del tuo approccio al cloud. I team si riuniscono regolarmente e discutono argomenti quali obiettivi e target organizzativi, stato attuale di costi e utilizzo e pratiche finanziarie e contabili. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

i team tecnologici possono innovare più rapidamente nel cloud grazie a cicli di approvazione, approvvigionamento e distribuzione dell'infrastruttura più brevi. Può trattarsi di una novità per le organizzazioni finanziarie che in precedenza erano abituate a eseguire processi dispendiosi, in termini di tempo e di risorse, per acquistare e distribuire capitale in data center e ambienti locali, allocando i costi solo in fase di approvazione del progetto. 

Dal punto di vista delle organizzazioni finanziarie e addette all'approvvigionamento, il processo di elaborazione del piano degli investimenti, della richiesta, dell'approvazione e dell'approvvigionamento degli investimenti e dell'installazione dell'infrastruttura fisica è stato interiorizzato e standardizzato da decenni:
+ I team di progettazione o IT sono in genere i richiedenti
+ I vari team finanziari fungono da approvatori e procuratori
+ I team operativi assemblano, implementano e distribuiscono un'infrastruttura pronta all'uso

![\[Circular workflow diagram showing technology teams, procurement, supply chain, and operations interactions.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/cost01-bp02-finance-and-procurement-workflow.png)


Con l'adozione del cloud, l'approvvigionamento e il consumo dell'infrastruttura non sono più vincolati da una catena di dipendenze. Nel modello cloud, i team tecnologici e del prodotto non sono più semplici "costruttori", ma anche operatori e proprietari dei loro prodotti, responsabili della maggior parte delle attività storicamente associate ai team finanziari e operativi, compresi l'approvvigionamento e l'implementazione.

Quanto in realtà è necessario per il provisioning delle risorse cloud è un account utente e il set appropriato di autorizzazioni, elementi questi che riducono i rischi IT e finanziari. Ciò significa che ai team basta un numero ridotto di clic o chiamate API per terminare le risorse cloud non necessarie o inattive. Ciò inoltre consente ai team tecnologici di velocizzare l'innovazione, grazie all'agilità e alla capacità di potenziare e quindi ridimensionare i vari progetti sperimentali. Se da un lato la natura variabile del consumo del cloud può influenzare la prevedibilità dal punto di vista del processo di elaborazione del piano degli investimenti e delle previsioni, il cloud fornisce alle organizzazioni la capacità di ridurre il costo del provisioning eccessivo e contemporaneamente il costo delle opportunità associato a un provisioning insufficiente di carattere conservativo.

![\[Diagram showing Technology and Product teams deploying, Finance and Business teams operating, with optimization at the center.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/cost01-bp02-deploy-operate-optimize.png)


Stabilisci una collaborazione tra i principali stakeholder finanziari e tecnologici per creare una comprensione condivisa degli obiettivi organizzativi e sviluppare meccanismi che consentano il successo finanziario nel modello di spesa variabile del cloud computing. I team pertinenti all'interno della tua organizzazione devono essere coinvolti nelle discussioni su costi e utilizzo in tutte le fasi del tuo viaggio verso il cloud; tra di essi vi sono: 
+ ** Responsabili finanziari:** CFO, controllori finanziari, pianificatori finanziari, analisti aziendali, approvvigionamento e selezione delle risorse e contabilità fornitori devono comprendere il modello di consumo del cloud, le opzioni di acquisto e il processo di fatturazione mensile. I team finanziari devono collaborare con i team tecnologici per creare e divulgare a livello aziendale una narrazione del valore IT che aiuti i team aziendali a comprendere lo stretto legame tra spesa in tecnologie e risultati aziendali. In questo modo, la spesa tecnologica viene considerata non tanto come un costo, quanto piuttosto come un vero e proprio investimento. A causa delle differenze fondamentali tra il cloud (ad esempio il tasso di variazione dell'utilizzo, i prezzi a consumo o a scaglioni, i modelli di prezzo e le informazioni dettagliate su fatturazione e utilizzo) e le operazioni in locale, è essenziale che l'organizzazione finanziaria capisca in che modo l'utilizzo del cloud può influire sugli aspetti aziendali, tra cui processi di approvvigionamento, monitoraggio degli incentivi, allocazione dei costi e bilanci.
+  **Responsabili tecnologici:** i responsabili tecnologici (inclusi i proprietari di prodotti e applicazioni) devono essere a conoscenza dei requisiti finanziari (ad esempio i vincoli di budget) e dei requisiti aziendali (ad esempio i contratti sul livello di servizio). In questo modo, il carico di lavoro può essere implementato in modo opportuno per raggiungere gli obiettivi desiderati dall'azienda. 

La collaborazione tra finanza e tecnologia offre i seguenti vantaggi: 
+ I team finanziari e tecnologici hanno una visibilità quasi in tempo reale su costi e utilizzo.
+ I team finanziari e tecnologici stabiliscono una procedura operativa standard per gestire le variazioni di spesa nel cloud.
+ Gli stakeholder finanziari fungono da consulenti strategici per quanto riguarda il modo in cui il capitale viene utilizzato per acquistare sconti a fronte di impegni (ad esempio, istanze riservate o AWS Savings Plans) e il modo in cui il cloud viene utilizzato per far crescere l'organizzazione. 
+ I processi di approvvigionamento e di contabilità esistenti vengono applicati al cloud.
+ I team finanziari e tecnologici collaborano per prevedere costi e utilizzo di AWS futuri, al fine di allineare e sviluppare i budget aziendali. 
+ La comunicazione all'interno dell'organizzazione migliora attraverso un linguaggio condiviso e una comprensione comune dei concetti finanziari.

Altri stakeholder all'interno della tua organizzazione che devono essere coinvolti nelle discussioni su costi e utilizzo includono: 
+ **Proprietari delle unità aziendali:** i proprietari delle unità aziendali devono comprendere il modello aziendale del cloud in modo da indirizzare l'operato delle unità aziendali e di tutta l'azienda. Questa conoscenza del cloud è fondamentale quando è necessario prevedere la crescita e l'utilizzo del carico di lavoro, ma anche quando si valutano le diverse opzioni di acquisto, come le istanze riservate o i Savings Plans. 
+ **Team di progettazione: **lo sviluppo di una partnership tra team finanziari e tecnologici è essenziale per la creazione di una cultura consapevole dei costi che incoraggi il coinvolgimento degli ingegneri nella gestione finanziaria del cloud. Uno dei problemi comuni dei professionisti della gestione finanziaria del cloud o delle operazioni e dei team finanziari è far capire agli ingegneri l'attività nel cloud nel suo complesso e implementare le azioni consigliate.
+ **Terze parti: **se la tua organizzazione si avvale di terze parti (ad esempio, consulenti o strumenti), assicurati che esse siano allineate ai tuoi obiettivi finanziari e possano dimostrare sia l'allineamento, tramite i loro modelli di coinvolgimento, sia il ritorno sull'investimento (ROI). In genere, le terze parti contribuiscono alla creazione di report e all'analisi di eventuali carichi di lavoro da esse gestiti, e forniscono anche l'analisi dei costi relativi ai carichi di lavoro da esse progettati.

L'implementazione della gestione finanziaria del cloud e il conseguimento dei risultati richiedono la stretta collaborazione tra team finanziari, tecnologici e aziendali, nonché un cambiamento nel modo in cui la spesa cloud viene comunicata e valutata all'interno dell'organizzazione. Includi i team di progettazione in modo da renderli partecipi delle discussioni su costi e utilizzi in tutte le fasi e incoraggiali ad attenersi alle best practice e ad adottare le azioni concordate.

**Passaggi dell'implementazione**
+ **Definizione dei membri chiave: **Verifica che tutti i membri rilevanti dei team finanziari e tecnologici partecipino alla partnership. I membri del team finanziario interessati saranno quelli che hanno a che fare con la fatturazione dei servizi cloud. In genere si tratta di CFO, controllori finanziari, pianificatori finanziari, analisti aziendali, addetti agli acquisti e al sourcing. I membri tecnologici sono in genere i proprietari di prodotti e applicazioni, manager tecnici e rappresentanti di tutti i team che si basano sul cloud. Altri membri possono includere i responsabili di unità aziendali, ad esempio il marketing che influenzerà l'utilizzo dei prodotti, e terze parti, come i consulenti, necessari per garantire l'allineamento agli obiettivi e meccanismi e per fornire assistenza nell'elaborazione dei report.
+ **Definizione degli argomenti oggetto della discussione:** Definisci gli argomenti comuni tra i team o che necessitano di una comprensione condivisa. Segui il costo dal momento in cui viene creato, fino al pagamento della fattura. Prendi nota di tutti i membri coinvolti e dei processi organizzativi che devono essere applicati. Comprendi ogni fase o processo e le informazioni associate, come i modelli di prezzo disponibili, i prezzi a scaglioni, i modelli di sconto, il budget e i requisiti finanziari.
+ **Definizione di una regolare cadenza: **per creare una partnership tra team finanziari e tecnologici, definisci la periodicità delle comunicazioni per creare e gestire l'allineamento. Il gruppo deve riunirsi regolarmente in base ai propri obiettivi e parametri. Una cadenza tipica implica la revisione dello stato dell'organizzazione, la revisione dei programmi attualmente in esecuzione e la revisione dei parametri finanziari e di ottimizzazione generali. Quindi, per i carichi di lavoro chiave, è opportuno elaborare report più dettagliati.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Blog delle novità di AWS](https://aws.amazon.com/blogs/aws/) 

# COST01-BP03 Definizione di budget e previsioni per il cloud
<a name="cost_cloud_financial_management_budget_forecast"></a>

 Adatta i processi di previsione e di budgeting organizzativi esistenti in modo che siano compatibili con la natura altamente variabile dei costi e dell'utilizzo del cloud. I processi devono essere dinamici, utilizzando algoritmi basati su tendenze o fattori chiave aziendali o una combinazione di entrambi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I clienti utilizzano il cloud per ottenere efficienza, velocità e agilità, determinando un'elevata variabilità in termini di costi e utilizzo. I costi possono diminuire (o a volte aumentare) in seguito all'aumento dell'efficienza del carico di lavoro o con la distribuzione di nuovi carichi di lavoro e funzionalità. I carichi di lavoro possono essere dimensionati per servire un maggior numero di clienti, aumentando l'utilizzo e i costi del cloud. Le risorse sono ancora più accessibili di prima. L'elasticità del cloud va di pari passo con l'elasticità dei costi e delle previsioni. Gli attuali processi di budgeting dell'organizzazione devono essere modificati per incorporare questa variabilità. 

 Il budget è generalmente previsto per un solo anno e rimane fisso, richiedendo il rispetto rigoroso di tutte le parti coinvolte. Al contrario, le previsioni sono più flessibili, consentono aggiustamenti nel corso dell'anno e forniscono proiezioni dinamiche su un periodo di uno, due o tre anni. Sia la definizione del budget che le previsioni svolgono un ruolo cruciale nella definizione delle aspettative finanziarie tra le varie parti interessate tecnologiche e aziendali. Una previsione e un'implementazione accurate rendono responsabili anche le parti interessate che sono direttamente coinvolte nella gestione costi di provisioning e possono aumentare la loro consapevolezza generale dei costi. 

 È possibile adattare i processi di budgeting e previsione esistenti per renderli più dinamici utilizzando un algoritmo basato sulle tendenze (utilizzando i costi storici come input) o algoritmi basati sui fattori aziendali (ad esempio, lancio di nuovi prodotti, espansione regionale o nuovi ambienti per i carichi di lavoro), ideali per un ambiente di spesa dinamico e variabile o una combinazione di fattori legati alle tendenze e al business. 

 Puoi utilizzare [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) per elaborare previsioni basate sulle tendenze per un intervallo di tempo futuro definito in base alle spese pregresse. Il motore di previsione di AWS Cost Explorer segmenta i dati storici in base ai tipi di addebito, ad esempio le istanze riservate, e utilizza una combinazione di machine learning e modelli basati su regole per elaborare previsioni di spesa per tutti i singoli tipi di addebito. 

 È necessario identificare i fattori di business che possono influire sui costi di utilizzo e fare previsioni per ciascuno di essi separatamente per assicurarsi che l'utilizzo previsto sia calcolato in anticipo. Alcuni dei fattori sono collegati ai team IT e di prodotto all'interno dell'organizzazione. Altri fattori di business, come eventi di marketing, promozioni, fusioni e acquisizioni, sono noti ai responsabili delle vendite, del marketing e del business, ed è importante collaborare e tenere conto anche di tutti questi fattori trainanti della domanda. È necessario lavorare a stretto contatto con loro per comprendere l'impatto sui nuovi fattori aziendali interni. 

 Dopo aver determinato la previsione basata sulle tendenze utilizzando Cost Explorer o altri strumenti, utilizza il [Calcolatore dei prezzi AWS](https://calculator.aws/#/) per calcolare la stima dei costi futuri e dei casi d'uso AWS in base all'utilizzo previsto (traffico, richieste al secondo, istanza Amazon EC2 richiesta). È possibile utilizzarlo anche per supportare il processo di pianificazione delle modalità di spesa, la ricerca delle opportunità di riduzione dei costi e l'elaborazione di decisioni informate in caso di utilizzo di AWS. È importante tenere traccia dell'accuratezza di tale previsione poiché i budget devono essere impostati sulla base di questi calcoli e stime delle previsioni. 

 utilizza [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/) per impostare budget personalizzati a un livello granulare specificando il periodo di tempo, la periodicità o l'importo (fisso o variabile) e aggiungendo filtri come servizi, Regione AWS e tag. Per essere sempre aggiornati in merito alle prestazioni dei budget esistenti, puoi creare e programmare [report Budget AWS](https://docs.aws.amazon.com/cost-management/latest/userguide/reporting-cost-budget.html) da inviare tramite e-mail a te e alle parti coinvolte a cadenza regolare. Puoi anche creare [avvisi Budget AWS](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html) basati sui costi effettivi, ovvero avvisi intrinsecamente reattivi, oppure sui costi previsti, ovvero avvisi che consentono di implementare tempestivamente azioni correttive a fronte di potenziali eventi di superamento dei costi. È possibile essere avvisati al superamento o al previsto superamento dei costi o dell'utilizzo definiti nel budget. 

 utilizza [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) Per evitare o ridurre gli imprevisti a livello di costi e ottimizzare il controllo senza rallentare i processi di innovazione. AWS Cost Anomaly Detection sfrutta il machine learning per individuare spese anomale e cause principali in modo da rendere possibile la tempestiva adozione di misure correttive. [Grazie a tre semplici passaggi](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/), puoi creare una funzione di controllo contestualizzato personalizzato e ricevere avvisi quando viene rilevata una spesa anomala. 

 Come indicato nel pilastro sull'ottimizzazione dei costi di Well-Architected [Sezione Collaborazione tra finanza e tecnologia](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/finance-and-technology-partnership.html)è importante che esistano collaborazione e opportunità di contatto tra IT, finanza e le altre parti coinvolte per verificare che tutti stiano utilizzando gli stessi strumenti e processi a garanzia del modello di consistenza. Nei casi in cui si rendano necessarie modifiche del budget, l'incremento della frequenza delle occasioni di contatto permette infatti di intervenire e reagire più tempestivamente. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Analizza le previsioni basate sulle tendenze:** Utilizza strumenti di previsione basati sulle tendenze preferiti come AWS Cost Explorer e Amazon Forecast. Analizza i costi di utilizzo rispetto a diversi aspetti o componenti come servizio, account, tag e categorie di costi. Se è necessaria una previsione avanzata, importa i dati AWS Cost and Usage Report in Amazon Forecast (che applica la regressione lineare alla previsione come forma di machine learning). 
+  **Analizza le previsioni basate sui driver:** identifica l'impatto dei fattori aziendali sull'utilizzo del cloud e fai previsioni per ciascuno di essi separatamente per calcolare in anticipo il costo di utilizzo previsto. Collabora a stretto contatto con i responsabili delle unità aziendali e le parti interessate per comprendere l'impatto sui nuovi driver aziendali e calcolare le variazioni dei costi previste per definire budget accurati. 
+  **Aggiorna i processi di previsione e budget esistenti:** Definisci i tuoi processi di previsione del budget in base ai metodi di previsione adottati, ad esempio basati sulle tendenze, basati sui fattori di business o su una combinazione di entrambi i metodi di previsione. I budget devono essere calcolati e realistici, basati su tali processi di previsione. 
+  **Configurazione di avvisi e notifiche:** Usa Avvisi Budget AWS e AWS Cost Anomaly Detection per ricevere avvisi e notifiche. 
+  **Esecuzione di revisioni a intervalli regolari con le parti coinvolte chiave, **ad esempio le parti coinvolte nelle aree IT, finanza, piattaforma e altre aree strategiche dell'azienda, dovrebbero essere allineate alle modifiche a livello di direttive e utilizzi aziendali. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/?sc_channel=cfm-blog&sc_campaign=using-the-right-tools-for-your-cloud-cost-forecasting&sc_medium=plan-and-evaluate&sc_content=cfm-blog&sc_detail=link&sc_outcome=aw&sc_publisher=cfm-awareness&trk=using-the-right-tools-for-your-cloud-cost-forecasting_cfm-blog_link) 
+  [AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) 
+  [Previsioni Quick](https://docs.aws.amazon.com/quicksight/latest/user/forecasts-and-whatifs.html) 
+  [Amazon Forecast](https://aws.amazon.com/forecast/) 
+  [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/) 
+  [Blog delle novità di AWS](https://aws.amazon.com/blogs/aws/) 

 **Video correlati:** 
+  [How can I use Budget AWS to track my spending and usage](https://www.youtube.com/watch?v=Ris23gKc7s0) 
+  [AWS Cost Optimization Series: Budget AWS](https://www.youtube.com/watch?v=5vYEVQzoMeM) 

 **Esempi correlati:** 
+  [Understand and build driver-based forecasting](https://aws.amazon.com/blogs/aws-cloud-financial-management/understand-and-build-driver-based-forecasting/) 
+  [How to establish and drive a forecasting culture](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-establish-and-drive-a-forecasting-culture/) 
+  [How to improve your cloud cost forecasting](https://aws.amazon.com/blogs/aws-cloud-financial-management/forecasting-blog-series-1-3-ways-to-more-effectively-forecast-cloud-spend/) 
+  [Using the right tools for your cloud cost forecasting](https://aws.amazon.com/blogs/aws-cloud-financial-management/using-the-right-tools-for-your-cloud-cost-forecasting/) 

# COST01-BP04 Implementazione della consapevolezza dei costi nei processi dell'organizzazione
<a name="cost_cloud_financial_management_cost_awareness"></a>

Implementa la consapevolezza dei costi e crea trasparenza e funzionalità di controllo in processi nuovi o esistenti che influiscono sull'utilizzo e sfrutta i processi esistenti per favorire la consapevolezza dei costi. Implementa la consapevolezza dei costi nella formazione dei dipendenti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

La consapevolezza dei costi deve essere implementata nei processi organizzativi nuovi ed esistenti. Si tratta di un prerequisito fondamentale per altre best practice. È consigliabile riutilizzare e modificare i processi esistenti, laddove possibile, riducendo al minimo l'impatto sull'agilità e sulla velocità. Comunica i costi del cloud ai team tecnologici e ai responsabili dei processi decisionali nei team aziendali e finanziari per accrescere la consapevolezza dei costi e definisci indicatori chiave delle prestazioni (KPI) per l'efficienza da segnalare alle parti coinvolte nelle varie aree finanziarie e aziendali. Le seguenti raccomandazioni aiuteranno a implementare la consapevolezza dei costi nel carico di lavoro:
+ Verifica che la gestione delle modifiche includa una misurazione dei costi per quantificare l'impatto finanziario delle modifiche. Questo aiuta a risolvere in modo proattivo le problematiche relative ai costi nonché a evidenziare i risparmi ottenuti.
+ Verifica che l'ottimizzazione dei costi sia un componente fondamentale delle tue capacità operative. Ad esempio, puoi sfruttare gli attuali processi di gestione degli incidenti per analizzare e identificare la causa principale di anomalie di costi e utilizzo o delle eccedenze di costo.
+ Accelera la riduzione dei costi e la realizzazione del valore aggiunto attraverso l'automazione o l'utilizzo di strumenti. Quando valuti i costi dell'implementazione, includi nella valutazione un componente ROI per giustificare l'investimento di tempo o denaro.
+ Assegna i costi del cloud mediante l'implementazione delle policy di showback/chargeback per la spesa cloud, compresa la spesa per opzioni di acquisto basate su impegno, servizi condivisi e acquisti su marketplace, a supporto di un consumo del cloud maggiormente consapevole dei costi.
+ Estendi i programmi di formazione e sviluppo esistenti per includere la formazione sulla consapevolezza dei costi in tutta l'organizzazione, comprese attività di formazione continua e certificazione. In questo modo, creerai un'organizzazione in grado di gestire in modo autonomo i costi e l'utilizzo.
+ Sfrutta i vantaggi degli strumenti nativi AWS gratuiti, come [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/), [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/)e [Report Budget AWS](https://aws.amazon.com/about-aws/whats-new/2019/07/introducing-aws-budgets-reports/).

Quando le organizzazioni adottano in modo sistematico le best practice relative alla [gestione finanziaria del cloud,](https://aws.amazon.com/aws-cost-management/) questi comportamenti vengono inglobati nelle procedure di lavoro e nei processi decisionali. Ne risulterà una cultura basata su una maggiore consapevolezza dei costi, condivisa dagli sviluppatori che creano nuove applicazioni per il cloud e dai responsabili dell'area finanziaria che analizzano il ROI per questi nuovi investimenti a livello di cloud.

**Passaggi dell'implementazione**
+ ** Identificazione dei processi organizzativi pertinenti: **Ogni unità organizzativa esamina i propri processi e identifica i processi che influiscono su costi e utilizzo. Tutti i processi che determinano la creazione o la cessazione di una risorsa devono essere inclusi nella revisione. Inoltre, individua i processi che possono supportare la consapevolezza dei costi nella tua azienda, ad esempio la gestione degli incidenti e la formazione. 
+ **Definizione di una cultura consapevole dei costi autosufficiente:** assicurati che tutte le parti coinvolte rilevanti siano concordi sulla causa della modifica e sull'impatto come costo in modo che abbiano la piena consapevolezza del costo del cloud. Ciò consentirà all'organizzazione di definire una cultura consapevole dei costi autosufficiente finalizzata all'innovazione.
+ ** Aggiornamento dei processi con la consapevolezza dei costi:** Ogni processo viene modificato in modo che ci sia una consapevolezza dei costi. Il processo potrebbe richiedere ulteriori controlli preliminari, ad esempio la valutazione dell'impatto dei costi, oppure controlli successivi che attestino il verificarsi dei cambiamenti previsti in termini di costi e utilizzo. I processi di supporto come la formazione e la gestione degli incidenti possono essere estesi per includere elementi relativi a costi e utilizzo. 

Per ottenere assistenza, contatta gli esperti di gestione finanziaria del cloud mediante il team del tuo account oppure esplora le risorse e i documenti correlati elencati di seguito.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [Gestione finanziaria del cloud con AWS](https://aws.amazon.com/aws-cost-management/)

 **Esempi correlati:** 
+  [Strategy for Efficient Cloud Cost Management (Strategia per un'efficiente gestione dei costi del cloud)](https://aws.amazon.com/blogs/enterprise-strategy/strategy-for-efficient-cloud-cost-management/) 
+  [Cost Control Blog Series \$13: How to Handle Cost Shock (Blog relativo al controllo dei costi - Serie 3: Come gestire l'impatto dei costi)](https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-control-blog-series-3-how-to-handle-cost-shock/) 
+  [A Beginner’s Guide to AWS Cost Management (Guida per principianti alla AWS Cost Management)](https://aws.amazon.com/blogs/aws-cloud-financial-management/beginners-guide-to-aws-cost-management/) 

# COST01-BP05 Invio di report e notifiche sull'ottimizzazione dei costi
<a name="cost_cloud_financial_management_usage_report"></a>

 Imposta i budget per il cloud e configura i meccanismi per rilevare anomalie nell'utilizzo. Configura gli strumenti correlati per ricevere avvisi su costi e utilizzo rispetto a obiettivi predefiniti e ricevi notifiche quando l'utilizzo supera tali obiettivi. Organizza riunioni regolari per analizzare l'economicità dei tuoi carichi di lavoro e promuovere la consapevolezza dei costi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 È necessario rendicontare regolarmente l'ottimizzazione dei costi e dell'utilizzo all'interno dell'organizzazione. Puoi implementare sessioni dedicate per discutere le prestazioni in termini di costi o includere l'ottimizzazione dei costi nei regolari cicli di reporting operativi per i tuoi carichi di lavoro. Utilizza servizi e strumenti per monitorare regolarmente le prestazioni in termini di costi e implementare opportunità di risparmio sui costi.  

 Visualizza i costi e l'utilizzo con più filtri e granularità utilizzando [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/), che fornisce dashboard e report come i costi per servizio o per account, i costi giornalieri o i costi del marketplace. Monitora l'avanzamento di costi e utilizzo rispetto ai budget configurati attraverso i [report Budget AWS](https://aws.amazon.com/about-aws/whats-new/2019/07/introducing-aws-budgets-reports/). 

 Utilizza [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/) per configurare budget personalizzati al fine di tenere traccia dei costi e dell'utilizzo e reagire con tempestività agli avvisi ricevuti via e-mail o alle notifiche Amazon Simple Notification Service (Amazon SNS) in caso di superamento della soglia definita. [Imposta il periodo di budget preferito](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-create.html) su giornaliero, mensile, trimestrale o annuale e crea limiti di budget specifici per essere costantemente informato sui valori di utilizzo e sui costi effettivi o previsti rispetto alla soglia definita per il budget. Puoi anche configurare [avvisi](https://docs.aws.amazon.com/cost-management/latest/userguide/sns-alert-chime.html) e [operazioni](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html) da eseguire automaticamente o in base a un processo di approvazione a fronte di tali avvisi quando viene superato l'obiettivo del budget. 

 Implementa notifiche su costi e utilizzo in modo che si possa intervenire rapidamente in caso di variazioni impreviste di costi e utilizzo. [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) consente di ridurre gli inconvenienti a livello di costi e migliorare il controllo senza rallentare il processo di innovazione. AWS Cost Anomaly Detection individua le spese anomale e le cause principali a favore della riduzione del rischio di imprevisti a livello di fatturazione. Grazie a tre semplici passaggi, puoi creare una funzione di controllo contestualizzato personalizzato e ricevere avvisi quando viene rilevata una spesa anomala. 

 Puoi anche utilizzare [Quick](https://aws.amazon.com/quicksight/) con dati AWS Cost and Usage Report (CUR) per fornire funzionalità di reporting personalizzate con dati più granulari. Quick consente di programmare i report e ricevere via e-mail report periodici sui costi relativi all'utilizzo e sui costi storici o sulle opportunità di riduzione dei costi. Controlla il nostro [pannello di controllo Intelligence costi](https://aws.amazon.com/blogs/aws-cloud-financial-management/a-detailed-overview-of-the-cost-intelligence-dashboard/) Soluzione (CID) creata su Quick, che offre una visibilità avanzata. 

 utilizza [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/), che mette a disposizione linee guida per verificare se le risorse allocate sono conformi alle best practice AWS in relazione all'ottimizzazione dei costi. 

 Controlla le tue raccomandazioni Savings Plans tramite grafici visivi confrontandoli con i costi e l'utilizzo granulari. I grafici orari mostrano la spesa on demand insieme all'impegno verso i Savings Plans consigliati, fornendo informazioni sui risparmi stimati, sulla copertura dei Savings Plans e sull'utilizzo dei Savings Plans. Questo aiuta le organizzazioni a capire in che modo i loro Savings Plans si applicano a ogni ora di spesa senza dover investire tempo e risorse nella creazione di modelli per analizzare la spesa stessa. 

 Crea periodicamente report contenenti informazioni di primo piano relative a Savings Plans, istanze riservate e suggerimenti per il corretto dimensionamento di Amazon EC2 forniti da AWS Cost Explorer per favorire la riduzione dei costi associati a carichi di lavoro con stato stazionario e a risorse inattive e sottoutilizzate. Individua e ammortizza la spesa associata all'utilizzo non ottimale del cloud relativamente alle risorse implementate. Con utilizzo non ottimale del cloud si intende la creazione di risorse dimensioni errate oppure la presenza di modelli di utilizzo del cloud diversi da quanto previsto. Segui le migliori pratiche di AWS per ridurre gli sprechi o chiedi al tuo account, al team e al partner di aiutarti [ottimizzare e ridurre](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/) i costi del cloud. 

 Genera regolarmente report per migliorare le opzioni di acquisto delle risorse al fine di ridurre il costo unitario dei carichi di lavoro. Le opzioni di acquisto quali, ad esempio, Savings Plans, istanze riservate o istanze spot Amazon EC2, offrono il massimo risparmio sui costi per carichi di lavoro con tolleranza ai guasti, consentendo alle parti interessate (responsabili di attività aziendali, team finanziari e tecnologici) di essere coinvolte nelle discussioni di merito. 

 Condividi i report contenenti opportunità o annunci di nuovi rilasci a supporto della riduzione del costo totale di proprietà (TCO) del cloud. Adotta nuovi servizi, regioni, funzionalità, soluzioni o nuovi modi per migliorare ulteriormente la riduzione dei costi. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Configura Budget AWS:** Configura Budget AWS su tutti gli account per il tuo carico di lavoro. Imposta un budget per la spesa complessiva dell'account e un budget per il carico di lavoro utilizzando i tag. 
  +  [Well-Architected Labs: utilizzo di costi e governance](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  **Report sull'ottimizzazione dei costi:** Configura un ciclo regolare per discutere e analizzare l'efficienza del carico di lavoro. Utilizzando i parametri stabiliti, segnala i parametri raggiunti e il costo sostenuto per ottenerli. Identifica e correggi eventuali tendenze negative e individua tendenze positive che puoi favorire in tutta l'organizzazione. La rendicontazione dovrebbe coinvolgere i rappresentanti dei team e dei responsabili delle applicazioni, dei responsabili finanziari e dei principali responsabili delle decisioni in merito alla spesa per il cloud. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 
+  [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/) 
+  [AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) 
+  [Budget AWS Best Practices (Best practice per Budget AWS)](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html#budgets-best-practices-setting-budgets%3Fsc_channel=ba%26sc_campaign=aws-budgets%26sc_medium=manage-and-control%26sc_content=web_pdp%26sc_detail=how-do-I%26sc_outcome=aw%26trk=how-do-I_web_pdp_aws-budgets) 
+  [Amazon S3 Analytics (Analisi Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html) 

 **Esempi correlati:** 
+  [Well-Architected Labs: utilizzo di costi e governance](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  [Key ways to start optimizing your AWS cloud costs (Principali soluzioni per iniziare a ottimizzare i costi del cloud AWS)](https://aws.amazon.com/blogs/aws-cloud-financial-management/key-ways-to-start-optimizing-your-aws-cloud-costs/) 

# COST01-BP06 Monitoraggio proattivo dei costi
<a name="cost_cloud_financial_management_proactive_process"></a>

Implementa strumenti e pannelli di controllo per monitorare i costi in modo proattivo per il carico di lavoro. Rivedi regolarmente i costi utilizzando strumenti configurati o pronti all'uso e non limitarti a guardare solo i costi e le categorie quando ricevi le notifiche. Il monitoraggio e l'analisi proattivi dei costi aiutano a individuare i trend positivi e ti consente di promuoverli all'interno dell'organizzazione. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

si consiglia di monitorare i costi e l'utilizzo all'interno dell'organizzazione in modo proattivo, e non solo in caso di eccezioni o anomalie. I pannelli di controllo con un'elevata visibilità in tutto l'ufficio o l'ambiente di lavoro garantiscono che le persone chiave abbiano accesso alle informazioni di cui hanno bisogno e dimostrano l'attenzione che l'organizzazione presta all'ottimizzazione dei costi. I pannelli di controllo visibili consentono di promuovere attivamente i risultati positivi e di implementarli in tutta l'organizzazione.

Crea procedure giornaliere o frequenti che utilizzino [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) o qualsiasi altro pannello di controllo, come [Amazon Quick](https://aws.amazon.com/quicksight/) , per verificare i costi e analizzarli in modo proattivo. Analizza l'utilizzo e i costi dei servizi AWS a livello di account AWS, carico di lavoro o servizio AWS specifico in gruppo o mediante filtri e verifica che siano in linea con quanto previsto. Utilizza tag e granularità a livello orario o di risorsa per filtrare e individuare i costi ricorrenti relativi alle risorse di maggiore utilizzo. Puoi anche creare report personalizzati con il [pannello di controllo Intelligence costi](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/), una soluzione [Amazon Quick](https://aws.amazon.com/quicksight/) sviluppata dagli AWS Solutions Architect, e confrontare i budget con i costi e l'utilizzo effettivi.

**Passaggi dell'implementazione**
+  **Report sull'ottimizzazione dei costi:** Configura un ciclo regolare per discutere e analizzare l'efficienza del carico di lavoro. Utilizzando i parametri stabiliti, segnala i parametri ottenuti e il costo sostenuto per ottenerli. Identifica e correggi eventuali tendenze negative e identifica le tendenze positive che puoi favorire in tutta l'organizzazione. L'elaborazione dei report deve coinvolgere i rappresentanti dei team applicativi e dei proprietari, dei team finanziari e di gestione. 
+ **Creazione e abilitazione di [Budget AWS](https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-daily-cost-and-usage-budgets/) con granularità giornaliera relativi a costi e utilizzo per adottare misure tempestive volte a impedire potenziali superamenti dei costi: ** Budget AWS consente di configurare notifiche di avviso per essere sempre informati se qualsiasi tipo di budget non è conforme alle soglie preconfigurate. Il modo migliore per utilizzare Budget AWS è configurare i costi e l'utilizzo previsti come limite in modo tale che qualsiasi superamento del budget possa essere considerato un superamento del limite di spesa.
+ **Creazione del AWS Cost Anomaly Detection per il monitoraggio dei costi: ** [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) utilizza la tecnologia avanzata di machine learning per individuare le spese anomale e le cause principali in modo da garantire un intervento tempestivo. Ti consente di configurare funzionalità di monitoraggio dei costi che definiscono i segmenti di spesa da valutare, ad esempio singoli servizi AWS, account membro, tag di allocazione dei costi e categorie di costo, nonché di impostare quando, dove e come riceverai le notifiche di avviso. Per ciascuna funzionalità di monitoraggio, puoi associare più sottoscrizioni agli avvisi per proprietari di azienda e team tecnologici, inclusi un nome, una soglia relativa all'impatto dei costi e la frequenza di avviso (avvisi singoli, riepilogo giornaliero, riepilogo settimanale) per ciascuna sottoscrizione.
+ **Utilizzo di AWS Cost Explorer o integrazione dei dati AWS Cost and Usage Report (CUR) con i pannelli di controllo Amazon Quick per la visualizzazione dei costi dell'organizzazione:** La funzionalità AWS Cost Explorer è caratterizzata da un'interfaccia di semplice utilizzo che consente di visualizzare, analizzare e gestire l'utilizzo e i costi AWS nel tempo. Il [pannello di controllo Intelligence costi](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) è personalizzabile e accessibile e consente di creare le basi di uno strumento di gestione e ottimizzazione dei costi personalizzato.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ [Daily Cost and Usage Budgets (Budget per costi e utilizzo giornalieri)](https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-daily-cost-and-usage-budgets/)
+ [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)

 **Esempi correlati:** 
+  [AWS Well-Architected Labs: visualizzazione](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html) 
+  [AWS Well-Architected Labs: visualizzazione avanzata](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+ [Well-Architected Labs: Cloud Intelligence Dashboards (Pannelli di controllo Intelligence cloud)](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/)
+ [Well-Architected Labs: Cost Visualization (Visualizzazione dei costi)](https://wellarchitectedlabs.com/cost/200_labs/200_5_cost_visualization/)
+ [AWS Cost Anomaly Detection Alert with Slack (Avvisi AWS Cost Anomaly Detection con Slack)](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/)

# COST01-BP07 Mantenimento dell'aggiornamento sulle nuove versioni dei servizi
<a name="cost_cloud_financial_management_scheduled"></a>

 Consultati regolarmente con gli esperti o con i partner AWS per valutare quali servizi e caratteristiche offrono un costo inferiore. Consulta i blog AWS e altre fonti di informazione. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

AWS continua ad aggiungere nuove caratteristiche in modo da consentirti di utilizzare le tecnologie più aggiornate a supporto di un più rapido processo di sperimentazione e innovazione. Potresti essere in grado di implementare nuovi servizi e funzionalità AWS per aumentare l'efficienza in termini di costi del carico di lavoro. Consulta regolarmente la pagina [Gestione dei costi AWS](https://aws.amazon.com/aws-cost-management/), il [Blog delle novità di AWS](https://aws.amazon.com/blogs/aws/), il [Blog sulla gestione dei costi AWS](https://aws.amazon.com/blogs/aws-cloud-financial-management/)e [Novità di AWS](https://aws.amazon.com/new/) per informazioni su nuovi servizi e versioni di funzionalità. I post nella sezione Novità forniscono una breve panoramica di tutti gli annunci relativi a servizi AWS, funzionalità ed espansione delle regioni al momento del loro rilascio.

**Passaggi dell'implementazione**
+  **Iscriviti ai blog:** Vai alle pagine dei blog AWS e iscriviti al Blog delle novità e ad altri blog di interesse. Puoi effettuare la registrazione nella pagina delle [preferenze di comunicazione](https://pages.awscloud.com/communication-preferences?languages=english) utilizzando il tuo indirizzo e-mail.
+ **Iscriviti alle novità di AWS: **consulta regolarmente il [Blog delle novità di AWS](https://aws.amazon.com/blogs/aws/) e [Novità di AWS](https://aws.amazon.com/new/) per informazioni su nuovi servizi e versioni di funzionalità. Iscriviti ai feed RSS oppure utilizza il tuo indirizzo e-mail per essere sempre aggiornato su annunci e nuovi rilasci.
+ **Segui le informazioni riportate nella sezione relativa alle riduzioni di prezzo AWS:** con regolari riduzioni di prezzo su tutti i nostri servizi, AWS ha regolarmente offerto una maggiore efficienza economica ai nostri clienti acquisiti. Ad aprile 2022, AWS ha ridotto i prezzi 115 volte dal suo lancio nel 2006. Se hai ancora qualche dubbio in merito a decisioni commerciali da prendere a causa di questioni relative ai prezzi, puoi fare riferimento ai nuovi tariffari, che includono riduzioni dei prezzi e nuove integrazioni dei servizi. Puoi avere ulteriori informazioni sulle precedenti riduzioni dei prezzi, comprese quelle relative alle istanze Amazon Elastic Compute Cloud (Amazon EC2), nella [categoria relativa alla riduzione dei prezzi del Blog delle novità di AWS](https://aws.amazon.com/blogs/aws/category/price-reduction/).
+ ** Eventi e incontri AWS: **Partecipa al summit AWS locale e a qualsiasi incontro locale con altre organizzazioni della tua area. Se non riesci a partecipare dal vivo, prova ad accedere agli eventi virtuali per poter ascoltare gli esperti AWS e rimanere informato sui casi aziendali di altri clienti.
+ ** Organizza riunioni con il team del tuo account: **Pianifica una cadenza regolare di incontri con il team del tuo account, organizza riunioni con il team e discuti delle tendenze del settore e dei servizi AWS. Parla con gli account manager, i solutions architect e i team di supporto a te assegnati. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Gestione dei costi AWS](https://aws.amazon.com/aws-cost-management/) 
+ [Novità di AWS](https://aws.amazon.com/new/)
+  [Blog delle novità di AWS](https://aws.amazon.com/blogs/aws/) 

 **Esempi correlati:** 
+  [Amazon EC2 – 15 Years of Optimizing and Saving Your IT Costs (15 anni di ottimizzazione e risparmio dei costi IT)](https://aws.amazon.com/blogs/aws-cost-management/amazon-ec2-15th-years-of-optimizing-and-saving-your-it-costs/) 
+ [AWS News Blog - Price Reduction (Blog delle novità di AWS - Riduzione dei prezzi)](https://aws.amazon.com/blogs/aws/category/price-reduction/)

# COST01-BP08 Creazione di una cultura consapevole dei costi
<a name="cost_cloud_financial_management_culture"></a>

 Implementa modifiche o programmi all'interno dell'organizzazione per creare una cultura consapevole dei costi. Si consiglia di iniziare in piccolo, per poi implementare programmi di grandi dimensioni e di vasta portata all'aumentare delle capacità e dell'utilizzo del cloud da parte dell'organizzazione. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Una cultura consapevole dei costi consente di ricalibrare l'ottimizzazione e la gestione finanziaria del cloud (team operativi e finanziari, Centro di eccellenza del Cloud, operazioni nel cloud e così via) attraverso best practice eseguite in modo organico e decentralizzato all'interno di tutta l'organizzazione. La consapevolezza dei costi crea livelli elevati di capacità all'interno dell'organizzazione con uno sforzo minimo, qualcosa di analogo a un approccio centralizzato e dall'alto verso il basso.

La creazione della consapevolezza dei costi nel cloud computing, soprattutto per quanto riguarda i principali driver dei costi, consente ai team di avere la piena consapevolezza dei risultati previsti associati a qualsiasi variazione a livello di costi. I team con accesso agli ambienti cloud devono conoscere i modelli dei prezzi e la differenza tra i tradizionali data center on-premise e il cloud computing.

Il principale vantaggio di una cultura consapevole dei costi è che i team tecnologici ottimizzano i costi in modo proattivo e continuativo (ad esempio, i costi vengono considerati un requisito non funzionale durante la definizione dell'architettura dei nuovi carichi di lavoro oppure quando vengono apportate modifiche ai carichi di lavoro esistenti) anziché eseguire ottimizzazioni reattive dei costi, in caso di necessità.

Piccoli cambiamenti nella cultura possono avere un grande impatto sull'efficienza dei carichi di lavoro attuali e futuri. Esempi di questo tipo includono:
+ Avere visibilità e consapevolezza consente ai team tecnici di progettazione di controllare il loro operato e di capire il tipo di impatto che la loro attività ha in termini di costi.
+ Gamificare costi e utilizzo in tutta l'organizzazione. Questa operazione può essere eseguita tramite un pannello di controllo visibile pubblicamente o un report che confronta i costi e l'utilizzo normalizzati tra i team (ad esempio, i costi per carico di lavoro e i costi per transazione).
+ Premiare l'efficienza dei costi. Ricompensa pubblicamente o privatamente i risultati di ottimizzazione dei costi volontari o non sollecitati e impara dagli errori per evitare di ripeterli in futuro.
+ Crea requisiti organizzativi dall'alto verso il basso affinché i carichi di lavoro siano eseguiti nel rispetto dei budget predefiniti.
+ Esegui una verifica continua dei requisiti aziendali relativi alle modifiche e dell'impatto dei costi delle modifiche richieste sull'infrastruttura dell'architettura o sulla configurazione del carico di lavoro per essere sicuro di pagare solo quanto è necessario.
+ Verifica che il responsabile delle modifiche sia consapevole delle modifiche previste con un impatto sui costi, che a loro volta devono essere confermate dalle parti coinvolte al fine di ottenere risultati aziendali in modo economicamente conveniente.

**Passaggi dell'implementazione**
+ **Comunica i costi del cloud ai team tecnologici:** per favorire la consapevolezza dei costi e definire indicatori KPI relativi all'efficienza per le parti coinvolte nelle aree finanziarie e aziendali.
+ **Comunica le modifiche pianificate alle parti coinvolte o ai membri dei team:** crea una voce nel programma per discutere le modifiche pianificate e l'impatto costi/benefici a livello di carico di lavoro durante le riunioni settimanali.
+ ** Organizza riunioni con il team del tuo account: **definisci una cadenza regolare per le riunioni con il team del tuo account e discuti delle tendenze del settore e dei servizi AWS. Parla con account manager, architect e team di supporto a te assegnati. 
+ **Condividi le storie di successo:** condividi le storie di successo relative alla riduzione dei costi per qualsiasi carico di lavoro, Account AWS o organizzazione per creare un atteggiamento favorevole e incoraggiare la consapevolezza a questo proposito.
+ **Formazione: **assicurati che i team tecnici o i membri dei vari team abbiano ricevuto una formazione adeguata in merito alla consapevolezza dei costi delle risorse nel Cloud AWS.
+ ** Eventi e incontri AWS: **partecipa al summit AWS locale e a qualsiasi incontro locale con altre organizzazioni della tua area. 
+  **Iscriviti ai blog:** Vai alle pagine dei blog AWS e iscriviti al [Blog delle novità](https://aws.amazon.com/new/) e altri blog rilevanti per essere sempre aggiornato sulle nuove versioni, implementazioni, esempi e modifiche condivise da AWS. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Blog AWS](https://aws.amazon.com/blogs/) 
+  [Gestione dei costi AWS](https://aws.amazon.com/blogs/aws-cost-management/) 
+  [Blog delle novità di AWS](https://aws.amazon.com/blogs/aws/) 

 **Esempi correlati:** 
+  [Gestione finanziaria del cloud con AWS](https://aws.amazon.com/blogs/aws-cloud-financial-management/) 
+  [AWS Well-Architected Labs: Cloud Financial Management (Gestione finanziaria del cloud)](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/1_cloud_financial_management/) 

# COST01-BP09 Quantificare il valore aggiunto realizzato attraverso l'ottimizzazione dei costi
<a name="cost_cloud_financial_management_quantify_value"></a>

 La quantificazione del valore aggiunto realizzato tramite l'ottimizzazione dei costi consente di comprendere l'intero set di vantaggi per la tua organizzazione. Poiché l'ottimizzazione dei costi è un investimento necessario, la quantificazione del valore aggiunto consente di spiegare il ritorno sull'investimento agli stakeholder. La quantificazione del valore aggiunto può aiutarti a ottenere maggiori consensi dagli stakeholder sugli investimenti futuri in materia di ottimizzazione dei costi, e fornisce un framework per misurare i risultati delle attività di ottimizzazione dei costi della tua organizzazione. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Quantificare il valore aziendale significa misurare i vantaggi che le aziende ottengono dalle azioni e dalle decisioni che prendono. Il valore aziendale può essere tangibile (riduzione delle spese o aumento dei profitti) o intangibile (migliore reputazione del marchio o maggiore soddisfazione del cliente). 

 Quantificare il valore aziendale derivante dall'ottimizzazione dei costi significa determinare il valore o i vantaggi ottenuti dall'impegno dedicato a rendere più efficiente la spesa. Ad esempio, supponiamo che un'azienda spenda 100.000 dollari per implementare un carico di lavoro su AWS e successivamente lo ottimizzi, portandone il costo a 80.000 dollari senza sacrificare la qualità o la produzione. In questo scenario, il valore aziendale quantificato derivante dall'ottimizzazione dei costi è un risparmio di 20.000 dollari. Ma oltre ai semplici risparmi, l'azienda potrebbe anche quantificare il valore in termini di tempi di consegna più rapidi, maggiore soddisfazione dei clienti o altre metriche derivanti dall'impegno nell'ambito dell'ottimizzazione dei costi. Le parti interessate devono prendere decisioni in merito al potenziale valore dell'ottimizzazione dei costi, al costo dell'ottimizzazione del carico di lavoro e al valore del ritorno sugli investimenti. 

 oltre a rendicontare i risparmi derivanti dall'ottimizzazione dei costi, è consigliabile quantificare il valore aggiunto fornito. I vantaggi dell'ottimizzazione dei costi sono in genere quantificati in termini di costi inferiori per ottenere un risultato aziendale. Ad esempio, puoi quantificare la riduzione dei costi di Amazon Elastic Compute Cloud (Amazon EC2) quando acquisti Savings Plans, che riduce i costi e mantiene i livelli di output del carico di lavoro. Puoi quantificare la riduzione dei costi di AWS quando le istanze Amazon EC2 inattive vengono rimosse o quando i volumi Amazon Elastic Block Store (Amazon EBS) scollegati vengono eliminati. 

 I vantaggi derivanti dall'ottimizzazione dei costi, tuttavia, vanno oltre la riduzione o l'eliminazione dei costi. Prendi in considerazione l'acquisizione di dati aggiuntivi per misurare i miglioramenti dell'efficienza e il valore aggiunto. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Valuta i vantaggi aziendali:** questo è il processo di analisi e regolazione dei costi del Cloud AWS in modo da massimizzare i vantaggi derivanti da ogni dollaro speso. Invece di concentrarti sulla riduzione dei costi senza considerare il valore aziendale, nell'ambito dell'ottimizzazione dei costi valuta i vantaggi aziendali e il ritorno sugli investimenti, che potrebbero aumentare il valore del denaro speso. Si tratta di spendere con saggezza e di fare investimenti e spese nelle aree che producono i migliori rendimenti. 
+  **Analizza la previsione dei costi AWS:** la previsione consente agli stakeholder finanziari di stabilire le aspettative con altri soggetti interni ed esterni dell'organizzazione e aiuta a migliorare la prevedibilità finanziaria dell'organizzazione. [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) può essere utilizzato per effettuare previsioni sui costi e sull'utilizzo. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Vantaggi economici del Cloud AWS](https://aws.amazon.com/economics/)
+  [Blog AWS](https://aws.amazon.com/blogs/) 
+  [Gestione dei costi AWS](https://aws.amazon.com/blogs/aws-cost-management/) 
+  [AWS News Blog](https://aws.amazon.com/blogs/aws/) 
+  [whitepaper sul principio dell'affidabilità secondo il Canone di architettura](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) 
+  [Esploratore dei costi AWS](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 

 **Video correlati:** 
+ [ Unlock Business Value with Windows on AWS](https://aws.amazon.com/windows/tco/)

 **Esempi correlati:** 
+ [ Measuring and Maximizing the Business Value of Customer 360 ](https://pages.awscloud.com/measuring-and-maximizing-the-business-value-of-customer-360-062022.html)
+ [ The Business Value of Adopting Amazon Web Services Managed Databases ](https://pages.awscloud.com/rs/112-TZM-766/images/The Business Value of Adopting Amazon Web Services Managed Databases.pdf)
+ [ The Business Value of Amazon Web Services for Independent Software Vendors ](https://pages.awscloud.com/rs/112-TZM-766/images/The Business Value of Amazon Web Services %28AWS%29 for Independent Software Vendors %28ISVs%29.pdf)
+ [ Business Value of Cloud Modernization ](https://pages.awscloud.com/aws-cfm-known-business-value-of-cloud-modernization-2022.html)
+ [ The Business Value of Migration to Amazon Web Services ](https://pages.awscloud.com/global-in-gc-500-business-value-of-migration-whitepaper-learn.html)

# Comprensione delle spese e dell'utilizzo
<a name="a-expenditure-and-usage-awareness"></a>

**Topics**
+ [COST 2. In che modo gestisci l'utilizzo?](cost-02.md)
+ [COST 3. In che modo monitori i costi e l'utilizzo?](cost-03.md)
+ [COST 4. In che modo disattivi le risorse?](cost-04.md)

# COST 2. In che modo gestisci l'utilizzo?
<a name="cost-02"></a>

Stabilisci policy e meccanismi per verificare che i costi sostenuti mentre raggiungi gli obiettivi siano adeguati. Utilizzando un approccio di controllo e bilanciamento reciproco, è possibile innovare senza spendere troppo. 

**Topics**
+ [COST02-BP01 Sviluppo di policy basate sui requisiti dell'organizzazione](cost_govern_usage_policies.md)
+ [COST02-BP02 Implementazione di obiettivi e target](cost_govern_usage_goal_target.md)
+ [COST02-BP03 Implementazione di una struttura di account](cost_govern_usage_account_structure.md)
+ [COST02-BP04 Implementazione di gruppi e ruoli](cost_govern_usage_groups_roles.md)
+ [COST02-BP05 Implementazione dei controlli di costo](cost_govern_usage_controls.md)
+ [COST02-BP06 Monitoraggio del ciclo di vita del progetto](cost_govern_usage_track_lifecycle.md)

# COST02-BP01 Sviluppo di policy basate sui requisiti dell'organizzazione
<a name="cost_govern_usage_policies"></a>

Sviluppa policy che definiscano il modo in cui le risorse vengono gestite dalla tua organizzazione e controllale periodicamente. Le policy devono coprire gli aspetti dei costi relativi alle risorse e ai carichi di lavoro, comprese la creazione, la modifica e la disattivazione nel ciclo di vita delle risorse.

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Comprendere i costi e i fattori chiave della tua organizzazione è fondamentale per gestire i costi e l'utilizzo in modo efficiente e per identificare le opportunità di riduzione dei costi. In genere, le organizzazioni gestiscono molteplici carichi di lavoro eseguiti da più team. Questi team possono trovarsi in diverse unità aziendali, ognuna con un proprio flusso di ricavi. La capacità di attribuire i costi delle risorse ai singoli proprietari del carico di lavoro, del prodotto o dell'organizzazione incoraggia un comportamento di utilizzo efficiente e contribuisce a ridurre gli sprechi. Un monitoraggio accurato dei costi e dell'utilizzo consente di comprendere quanto sia ottimizzato un carico di lavoro e quanto siano redditizi i prodotti e le unità organizzative. Questa conoscenza consente di prendere decisioni più informate su dove allocare le risorse all'interno dell'organizzazione. La consapevolezza dell'utilizzo a tutti i livelli dell'organizzazione è fondamentale per promuovere il cambiamento, poiché la modifica dell'utilizzo determina variazioni dei costi. Prova a adottare una strategia versatile per acquisire consapevolezza delle tue spese.

il primo passo per attuare la governance consiste nell'utilizzare i requisiti della tua organizzazione per sviluppare politiche per l'utilizzo del cloud. Queste policy definiscono il modo in cui l'organizzazione utilizza il cloud e il modo in cui le risorse vengono gestite. Le policy devono coprire tutti gli aspetti dei costi relativi alle risorse e ai carichi di lavoro correlati a costi o utilizzo, compresa la creazione, la modifica e la disattivazione durante il ciclo di vita di una risorsa. Verifica che policy e procedure vengano eseguite e implementate per qualsiasi modifica apportata in un ambiente cloud. Durante gli incontri per la gestione delle modifiche IT, poni domande relative all'impatto sui costi delle modifiche pianificate (se implicano un aumento o una riduzione), alla giustificazione aziendale e ai risultati attesi. 

Le policy devono essere semplici, in modo che siano facilmente comprensibili e possano essere implementate in modo efficace in tutta l'organizzazione. Le policy devono anche essere facili da seguire e interpretare (in modo da essere utilizzate) e specifiche (senza interpretazioni errate tra i team). Inoltre, devono essere ispezionate periodicamente (come i nostri meccanismi) e aggiornate man mano che le condizioni o le priorità aziendali dei clienti cambiano, il che renderebbe la policy obsoleta.

 Inizia con policy ampie e di alto livello, ad esempio in quale regione geografica è consentito l'utilizzo o l'ora del giorno in cui le risorse devono essere in esecuzione. Raffina gradualmente le policy per le varie unità organizzative e i diversi carichi di lavoro. Le policy comuni includono i servizi e le funzionalità che possono essere utilizzati (ad esempio, archiviazione dalle prestazioni inferiori negli ambienti di test e sviluppo), i tipi di risorse che possono essere utilizzati dai diversi gruppi (ad esempio, le dimensioni massime di una risorsa in un account di sviluppo possono essere impostate su medie) e per quanto tempo queste risorse saranno in uso (temporaneamente, a breve termine o per un periodo di tempo specifico). 

 **Esempio di policy** 

 Di seguito è riportato un esempio di policy che puoi esaminare per creare le tue policy di governance del cloud, basate sull'ottimizzazione dei costi. Assicurati di adattare la policy ai requisiti della tua organizzazione e alle richieste delle parti interessate. 
+  **Nome della policy:** definisci un nome chiaro per la policy, ad esempio Ottimizzazione delle risorse e Policy di riduzione dei costi. 
+  **Scopo:** spiega perché questa policy dovrebbe essere utilizzata e qual è il risultato previsto. L'obiettivo di questa policy è verificare che sia richiesto un costo minimo per implementare ed eseguire il carico di lavoro desiderato per soddisfare i requisiti aziendali. 
+  **Ambito di applicazione:** definisci chiaramente chi deve utilizzare questa policy e quando deve essere utilizzata, ad esempio Team DevOps X per utilizzare questa policy per i clienti nella zona di disponibilità Stati Uniti-Est per l'ambiente X (di produzione o non di produzione). 

 **Dichiarazione delle policy** 

1.  Seleziona us-east-1 o più regioni Stati Uniti-Est in base all'ambiente del carico di lavoro e ai requisiti aziendali (sviluppo, test di accettazione da parte degli utenti, preproduzione o produzione). 

1.  Pianifica l'esecuzione delle istanze Amazon EC2 e Amazon RDS tra le sei del mattino e le otto di sera (Ora solare orientale [EST]). 

1.  Arresta tutte le istanze Amazon EC2 inutilizzate dopo otto ore e le istanze Amazon RDS inutilizzate dopo 24 ore di inattività. 

1.  Interrompi tutte le istanze Amazon EC2 inutilizzate dopo 24 ore di inattività in ambienti non di produzione. Ricorda al proprietario dell'istanza Amazon EC2 (in base ai tag) di esaminare le istanze Amazon EC2 arrestate in produzione e di informarlo che le istanze Amazon EC2 verranno terminate entro 72 ore se non vengono utilizzate. 

1.  Usa la famiglia e le dimensioni delle istanze generiche come m5.large, quindi ridimensiona l'istanza in base all'utilizzo della CPU e della memoria mediante AWS Compute Optimizer. 

1.  Assegna la priorità utilizzando il dimensionamento automatico per regolare dinamicamente il numero di istanze in esecuzione in base al traffico. 

1.  Usa le istanze spot per carichi di lavoro non critici. 

1.  Esamina i requisiti di capacità per impegnare piani di risparmio o istanze riservate per carichi di lavoro prevedibili e informa il team della gestione finanziaria del cloud. 

1.  Utilizza le policy Amazon S3 del ciclo di vita per spostare i dati a cui si accede di rado su livelli di archiviazione più economici. Se non è stata definita alcuna policy di conservazione, utilizza Piano intelligente Amazon S3 per spostare automaticamente gli oggetti nel livello archiviato. 

1.  Monitora l'utilizzo delle risorse e imposta allarmi per attivare eventi di dimensionamento utilizzando Amazon CloudWatch. 

1.  Per ogni Account AWS, utilizza Budget AWS per impostare i budget di costo e utilizzo per il tuo account in base al centro di costo e alle unità aziendali. 

1.  L'utilizzo di Budget AWS per impostare i budget di costi e utilizzo del tuo account può aiutarti a tenere sotto controllo le spese ed evitare fatture impreviste, consentendoti di controllare meglio i costi. 

 **Procedura:** fornisci procedure dettagliate per l'attuazione di questa policy o fai riferimento ad altri documenti che descrivono come implementare ciascuna dichiarazione della policy. Questa sezione dovrebbe fornire istruzioni dettagliate per l'adempimento dei requisiti della policy. 

 Per implementare questa policy, puoi utilizzare vari strumenti o regole AWS Config di terze parti per verificare la conformità alla dichiarazione e attivare azioni correttive automatiche utilizzando le funzioni AWS Lambda. Puoi anche usare AWS Organizations per applicare la policy. Inoltre, dovresti controllare regolarmente l'utilizzo delle risorse e modificare la policy, se necessario, per verificare che continui a soddisfare le esigenze aziendali. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Incontra le parti interessate:** per sviluppare le policy, chiedi alle parti interessate (ufficio aziendale per il cloud, ingegneri o responsabili delle decisioni funzionali per l'applicazione delle policy) all'interno della tua organizzazione di specificare i loro requisiti e documentarli. Segui un approccio iterativo iniziando in modo generale e perfezionando continuamente le unità più piccole in ogni fase. I membri del team includono quelli con interesse diretto nel carico di lavoro, ad esempio unità organizzative o proprietari di applicazioni, nonché gruppi di supporto, come i team di sicurezza e i team finanziari.
+  **Ottieni conferma:** verifica che i team siano d'accordo sulle policy a cui possono accedere e che possono distribuire sul Cloud AWS. Verifica che rispettino le policy della tua organizzazione e conferma che le creazioni di risorse siano in linea con le policy e le procedure concordate. 
+  **Organizza sessioni di formazione per l'onboarding:** chiedi ai nuovi membri dell'organizzazione di partecipare a corsi di formazione di onboarding per sviluppare una consapevolezza sui costi e sui requisiti aziendali. Potrebbero adottare policy diverse legate all'esperienza precedente o non rifletterci affatto. 
+ ** Definizione delle posizioni per il carico di lavoro: **Definisci dove opera il carico di lavoro, incluso il paese e l'area all'interno del paese. Queste informazioni vengono utilizzate per la mappatura su Regioni AWS e sulle zone di disponibilità. 
+ ** Definizione e raggruppamento di servizi e risorse: **Definisci i servizi richiesti dai carichi di lavoro. Per ogni servizio, specifica i tipi, la dimensione e il numero di risorse richieste. Definisci i gruppi per le risorse in base alla funzione, ad esempio i server di applicazioni o lo storage di database. Le risorse possono appartenere a più gruppi. 
+  **Definizione e raggruppamento degli utenti per funzione: **Definisci gli utenti che interagiscono con il carico di lavoro, concentrandoti su ciò che fanno e su come utilizzano il carico di lavoro, non su chi sono o sulla loro posizione nell'organizzazione. Raggruppa utenti o funzioni simili. Puoi utilizzare le policy gestite da AWS come guida di riferimento. 
+ ** Definizione delle operazioni:** Utilizzando le posizioni, le risorse e gli utenti identificati in precedenza, definisci le azioni richieste da ciascuno di essi per ottenere i risultati del carico di lavoro durante il ciclo di vita (sviluppo, funzionamento e disattivazione). Identifica le operazioni in base ai gruppi, non ai singoli elementi nei gruppi, in ogni posizione. Inizia in generale con lettura o scrittura, quindi perfeziona le azioni specifiche per ciascun servizio. 
+ ** Definizione del periodo di revisione:** I carichi di lavoro e i requisiti organizzativi possono cambiare nel corso del tempo. Definisci la pianificazione della revisione del carico di lavoro per assicurarti che sia allineata alle priorità organizzative. 
+  **Documentazione delle policy: **verifica che le policy definite siano accessibili come richiesto dall'organizzazione. Queste policy vengono utilizzate per implementare, mantenere e controllare l'accesso agli ambienti. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Gestione delle modifiche nel cloud](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-cloud.html) 
+  [Policy gestite da AWS per le funzioni lavorative](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [Strategia di fatturazione con account multipli di AWS](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [Operazioni, risorse e chiavi di condizione per i servizi AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html) 
+  [Gestione e governance AWS](https://aws.amazon.com/products/management-and-governance/) 
+  [Controllo dell'accesso a Regioni AWS utilizzando le policy IAM](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [Regioni e zone di disponibilità dell'infrastruttura globale](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 

 **Video correlati:** 
+  [AWS Management and Governance at Scale (Gestione e governance AWS su scala)](https://www.youtube.com/watch?v=xdJSUnPcPPI) 

 **Esempi correlati:** 
+  [VMware - Quali sono le policy cloud?](https://blogs.vmware.com/cloudhealth/what-are-cloud-policies/) 

# COST02-BP02 Implementazione di obiettivi e target
<a name="cost_govern_usage_goal_target"></a>

Implementa obiettivi e target di costi e utilizzo per il carico di lavoro. Gli obiettivi forniscono indicazioni alla tua organizzazione sui risultati attesi, mentre i target forniscono risultati misurabili per i tuoi carichi di lavoro.

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Sviluppa obiettivi e target di costi e utilizzo per la tua organizzazione. In un'organizzazione in crescita in AWS, è importante definire e monitorare gli obiettivi per l'ottimizzazione dei costi. Questi obiettivi o [indicatori chiave delle prestazioni (KPI)](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metric-the-touchstone-of-your-it-planning-and-evaluation/) possono includere elementi come la percentuale della spesa on demand o l'adozione di determinati servizi ottimizzati come le istanze AWS Graviton o i tipi di volume gp3 EBS. La definizione di obiettivi misurabili e raggiungibili aiuta a misurare i miglioramenti dell'efficienza, un fattore importante per le operazioni aziendali in corso. Gli obiettivi forniscono all'organizzazione linee guida e indicazioni sui risultati previsti. I target forniscono i risultati specifici e misurabili da raggiungere. In breve, l'obiettivo è la direzione in cui desideri andare, mentre il target è la distanza da percorrere in quella direzione e il momento in cui l'obiettivo deve essere raggiunto (utilizzando la guida SMART, specifica, misurabile, assegnabile, realistica e tempestiva). Un esempio di obiettivo è che l'utilizzo della piattaforma aumenti in modo significativo, con solo un piccolo incremento (non lineare) dei costi. Un esempio di target è un aumento del 20% dell'utilizzo della piattaforma, con un incremento dei costi inferiore al 5%. Un altro obiettivo comune è che i carichi di lavoro devono essere più efficienti ogni sei mesi. L'obiettivo corrispondente prevede che il costo per metrica aziendale debba diminuire del cinque per cento ogni sei mesi. 

Un obiettivo per l'ottimizzazione dei costi è l'incremento dell'efficienza del carico di lavoro, ossia la riduzione delle spese per il risultato aziendale del carico di lavoro nel corso del tempo. Si consiglia di implementare questo obiettivo per tutti i carichi di lavoro e di stabilire, inoltre, un target come l'incremento dell'efficienza del 5% ogni 6-12 mesi. Questo può essere ottenuto nel cloud attraverso la creazione di capacità per l'ottimizzazione dei costi e tramite il rilascio di nuovi servizi e funzionalità.

 È importante avere una visibilità quasi in tempo reale sui KPI e sulle relative opportunità di risparmio e monitorare lo stato di avanzamento nel tempo. Per iniziare a definire e monitorare gli obiettivi KPI, è consigliabile usare il pannello di controllo dei KPI del [framework Dashboard di cloud intelligence (CID)](https://aws.amazon.com/blogs/mt/visualize-and-gain-insights-into-your-aws-cost-and-usage-with-cloud-intelligence-dashboards-using-amazon-quicksight/). Sulla base dei dati disponibili in AWS Cost and Usage Report, il pannello di controllo dei KPI fornisce una serie di KPI consigliati per l'ottimizzazione dei costi con la possibilità di impostare obiettivi personalizzati e monitorare lo stato di avanzamento nel tempo. 

 Se disponi di un'altra soluzione che ti consente di impostare e monitorare gli obiettivi KPI, assicurati che sia adottata da tutte le parti coinvolte nella gestione finanziaria del cloud della tua organizzazione. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Definisci i livelli di utilizzo previsti: **Per iniziare, concentrati sui livelli di utilizzo. Coinvolgi i proprietari dell'applicazione, i team di marketing e i team aziendali a livello più ampio per capire quali saranno i livelli di utilizzo previsti per il carico di lavoro. Considera in che modo cambierà la domanda dei clienti nel corso del tempo e se ci saranno modifiche dovute a incrementi stagionali o campagne di marketing. 
+ ** Definisci le risorse e i costi del carico di lavoro: **Una volta definiti i livelli di utilizzo, quantifica le modifiche nelle risorse del carico di lavoro necessarie per soddisfarli. Potresti dover aumentare le dimensioni o il numero di risorse per un componente del carico di lavoro, aumentare il trasferimento dei dati o modificare i componenti del carico di lavoro in un servizio diverso a un livello specifico. Specifica quali saranno i costi in ciascuno di questi punti principali e quali saranno le variazioni dei costi in caso di variazioni di utilizzo. 
+  **Definisci gli obiettivi aziendali: **Prendendo l'output dalle variazioni previste in termini di utilizzo e costi, combinalo con le modifiche previste nella tecnologia o in qualsiasi programma in esecuzione e sviluppa obiettivi per il carico di lavoro. Gli obiettivi devono considerare l'utilizzo, il costo e la relazione tra i due. Gli obiettivi devono essere semplici, di alto livello e aiutare le persone a capire cosa si aspetta l'azienda in termini di risultati (come avere la certezza che le risorse non utilizzate rimangano al di sotto di determinati livelli di costo). Non è necessario definire gli obiettivi per ogni tipo di risorsa non utilizzato o definire i costi causati dalle perdite per gli obiettivi e i target. Assicurati che siano disponibili programmi a livello di organizzazione (ad esempio lo sviluppo di competenze come la formazione e l'istruzione), se ci sono variazioni previste dei costi senza variazioni di utilizzo.
+  **Definisci i target: **Per ciascuno degli obiettivi definiti, specifica un target misurabile. Se l'obiettivo è aumentare l'efficienza nel carico di lavoro, il target quantificherà il miglioramento (generalmente espresso in risultati aziendali per dollaro speso) e il momento in cui sarà efficace. Ad esempio, se definisci un obiettivo secondo cui vuoi ridurre lo spreco legato al provisioning eccessivo, allora il target può essere lo spreco dovuto a un provisioning eccessivo che, nel primo livello dei carichi di lavoro di produzione, non deve superare il 10% dei costi di elaborazione, e lo spreco legato al provisioning eccessivo per il calcolo che nel secondo livello dei carichi di lavoro di produzione non deve superare il 5% dei costi di elaborazione del livello. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Policy gestite da AWS per le funzioni lavorative](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [Strategia AWS multi-account per la tua zona di destinazione AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) 
+  [Controllo dell'accesso a Regioni AWS utilizzando le policy IAM](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+ [ Obiettivi SMART ](https://en.wikipedia.org/wiki/SMART_criteria)

 **Video correlati:** 
+ [ Well-Architected Labs: obiettivi e target (Livello 100) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/)

 **Esempi correlati:** 
+ [ Well-Architected Labs: disattivazione delle risorse (obiettivi e target) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/)
+ [ Well-Architected Labs: tipo, dimensione e numero di risorse (obiettivi e target) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/6_resource_type_size_number/)

# COST02-BP03 Implementazione di una struttura di account
<a name="cost_govern_usage_account_structure"></a>

 Implementa una struttura di account che si adatta alla tua organizzazione. In questo modo sarà possibile ripartire e gestire i costi in tutta quanta l’organizzazione. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 AWS Organizations consente di creare molteplici Account AWS che possono aiutare a governare centralmente l'ambiente mentre si dimensionano i carichi di lavoro su AWS. È possibile modellare la propria gerarchia organizzativa raggruppando gli Account AWS in una struttura di unità organizzative (OU) e creando molteplici Account AWS sotto ogni OU. Per creare una struttura di account, è necessario decidere innanzitutto quale Account AWS sarà l'account di gestione. Successivamente, è possibile creare nuovi Account AWS o selezionare account esistenti come account membri in base alla struttura degli account progettata, seguendo le [best practice per gli account di gestione](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html) e le [best practice per gli account membri](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html). 

 È consigliabile disporre sempre di almeno un account di gestione con un account membro collegato, indipendentemente dalle dimensioni dell'organizzazione o dall'utilizzo. Tutte le risorse del carico di lavoro dovrebbero risiedere solo all'interno degli account membri e nessuna risorsa dovrebbe essere creata all'interno dell'account di gestione. Non esiste una risposta giusta o sbagliata in merito al numero di Account AWS che bisognerebbe creare. Valuta i tuoi modelli operativi e di costo attuali e futuri per assicurarti che la struttura dei tuoi Account AWS rispecchi quella della tua organizzazione. Alcune aziende creano molteplici Account AWS per motivi aziendali, ad esempio: 
+ È richiesto l'isolamento amministrativo o fiscale e di fatturazione tra unità aziendali o centri di costo o carichi di lavoro specifici.
+ Le restrizioni dei servizi AWS sono impostate in modo che risultino specifiche per determinati carichi di lavoro.
+ Esiste un requisito per l'isolamento e la separazione tra carichi di lavoro e risorse.

 All'interno di [AWS Organizations](https://aws.amazon.com/organizations/), la [fatturazione consolidata](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) crea il costrutto tra uno o più account membri e l'account di gestione. Gli account membri consentono di isolare e distinguere i costi e l'utilizzo per gruppi. Una pratica comune è quella di avere account membri separati per ciascuna unità aziendale (come finanza, marketing e vendite), per il ciclo di vita di ciascun ambiente (come sviluppo, test e produzione) o per ciascun carico di lavoro (carico di lavoro a, b e c) e poi aggregare questi account membri tramite la fatturazione consolidata. 

 La fatturazione consolidata consente di accorpare i pagamenti di più Account AWS membri sotto un unico account di gestione e, al tempo stesso, di fornire comunque visibilità all'attività di ciascun account membro. Il fatto che i costi e l'utilizzo vengono aggregati nell'account di gestione consente di massimizzare gli sconti per volume di servizio e di massimizzare l'utilizzo degli sconti a fronte di impegni (Savings Plans e istanze riservate) per ottenere gli sconti più elevati. 

 Il diagramma seguente mostra come è possibile utilizzare AWS Organizations con le unità organizzative (OU) per raggruppare più account e come inserire molteplici Account AWS sotto ciascuna OU. Si consiglia di utilizzare le OU per diversi casi d'uso e carichi di lavoro che forniscono modelli per l'organizzazione degli account. 

![\[Tree diagram showing how to group multiple accounts under organizational units.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/aws-organizations-ou-grouping.png)


 [AWS Control Tower](https://aws.amazon.com/controltower/) può impostare e configurare rapidamente più account AWS, garantendo una governance in linea con i requisiti dell'organizzazione.

**Passaggi dell'implementazione** 
+  **Definisci i requisiti di separazione:** i requisiti di separazione sono una combinazione di più fattori, tra cui sicurezza, affidabilità e costrutti finanziari. Analizza ciascun fattore in ordine e specifica se il carico di lavoro o l'ambiente del carico di lavoro deve essere separato da altri carichi di lavoro. La sicurezza riguarda il rispetto dei requisiti di accesso e di dati. L'affidabilità riguarda la gestione dei limiti, in modo che gli ambienti e i carichi di lavoro non influiscano gli uni sugli altri. Esamina periodicamente i pilastri della sicurezza e dell'affidabilità del Canone di architettura e segui le best practice messe a disposizione. I costrutti finanziari creano una rigida separazione finanziaria (centri di costo diversi, proprietà e responsabilità dei carichi di lavoro). Esempi comuni di separazione sono i carichi di lavoro di produzione e test eseguiti in account separati o l'utilizzo di un account separato in modo che i dati di fatturazione possano essere forniti ai singoli settori o reparti aziendali dell'organizzazione o alle terze parti proprietarie dell'account. 
+  **Definisci i requisiti di raggruppamento:** i requisiti per il raggruppamento non sostituiscono i requisiti di separazione, ma vengono utilizzati a supporto della gestione. Raggruppa ambienti o carichi di lavoro simili che non richiedono separazione. Un esempio è costituito dal raggruppamento di più ambienti di test o sviluppo associati a uno o più carichi di lavoro.
+  **Definisci la struttura dell'account:** utilizzando queste separazioni e questi raggruppamenti, specifica un account per ogni gruppo e mantieni i requisiti di separazione. Questi account sono i tuoi account membri o collegati. Raggruppando questi account membri in un unico account di gestione o di pagamento, puoi combinarne l'utilizzo, ottenendo maggiori sconti per i volumi e una singola fattura per tutti gli account. È possibile separare i dati di fatturazione e fornire a ciascun account membro una visualizzazione individuale su di essi. Se un account membro non deve avere i dati di utilizzo o di fatturazione visibili a qualsiasi altro account, oppure se è necessaria una fattura separata da parte di AWS, definisci più account di gestione/di pagamento. In questo caso, ogni account membro ha il proprio account di gestione o di pagamento. Le risorse devono sempre essere collocate negli account membri o collegati. Gli account di gestione/di pagamento devono essere utilizzati solo per la gestione. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Utilizzo dei tag di allocazione dei costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) 
+  [Politiche gestite da AWS per le funzioni dell'attività](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html) 
+  [Strategia di fatturazione con account multipli di AWS](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [Controllo dell'accesso a Regioni AWS tramite le politiche IAM](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [AWS Control Tower](https://aws.amazon.com/controltower/) 
+  [AWS Organizations](https://aws.amazon.com/organizations/) 
+  Best practice per [account di gestione](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html) e [account membri](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html) 
+  [Organizzazione dell'ambiente AWS con l'utilizzo di account multipli](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 
+  [Attivazione delle istanze riservate condivise e degli sconti dei Savings Plans](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html) 
+  [Fatturazione consolidata](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) 
+  [Fatturazione consolidata](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) 

 **Esempi correlati:** 
+  [Divisione del Report costi e utilizzo (CUR) e condivisione dell'accesso](https://wellarchitectedlabs.com/Cost/Cost_and_Usage_Analysis/300_Splitting_Sharing_CUR_Access/README.html) 

 **Video correlati:** 
+ [ Presentazione di AWS Organizations](https://www.youtube.com/watch?v=T4NK8fv8YdI)
+ [ Impostazione di un ambiente AWS multi-account che utilizzi le best practice di AWS Organizations](https://www.youtube.com/watch?v=uOrq8ZUuaAQ)

 **Esempi correlati:** 
+ [ Well-Architected Labs: creazione di un'organizzazione AWS (Livello 100) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_1_aws_account_setup/2_account_structure/)
+ [ Divisione del AWS Cost and Usage Report e condivisione dell'accesso ](https://wellarchitectedlabs.com/cost/300_labs/300_splitting_sharing_cur_access/)
+  [Definizione di una strategia AWS multi-account per le aziende di telecomunicazioni](https://aws.amazon.com/blogs/industries/defining-an-aws-multi-account-strategy-for-telecommunications-companies/) 
+  [Best practice per l'ottimizzazione di Account AWS](https://aws.amazon.com/blogs/architecture/new-whitepaper-provides-best-practices-for-optimizing-aws-accounts/) 
+  [Best practice per le unità organizzative con AWS Organizations](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/?org_product_gs_bp_OUBlog) 

# COST02-BP04 Implementazione di gruppi e ruoli
<a name="cost_govern_usage_groups_roles"></a>

 Implementa gruppi e ruoli che si allineino alle tue policy e controlla chi può creare, modificare o ritirare istanze e risorse in ogni gruppo. Ad esempio, implementa gruppi di sviluppo, test e produzione. Questo si applica ai servizi AWS e a soluzioni di terze parti. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

I ruoli e i gruppi di utenti sono elementi costitutivi fondamentali nella progettazione e implementazione di sistemi sicuri ed efficienti. I ruoli e i gruppi aiutano le organizzazioni a trovare il giusto equilibrio a livello di controllo dei requisiti di flessibilità e produttività, supportando in definitiva gli obiettivi organizzativi e le esigenze degli utenti. Come consigliato nella sezione [Gestione di identità e accessi](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) del Pilastro della sicurezza del Framework AWS Well-Architected, è necessaria una solida gestione delle identità e delle autorizzazioni per fornire l'accesso alle risorse giuste alle persone idonee nelle condizioni adatte. Gli utenti disporranno solo del livello di accesso necessario per completare le proprie attività. Ciò riduce al minimo il rischio associato all'accesso non autorizzato o all'uso improprio.

 Dopo avere sviluppato le policy, è possibile creare gruppi logici e ruoli degli utenti all'interno dell'organizzazione. Ciò consente di assegnare le autorizzazioni, controllare l'utilizzo e semplificare l'implementazione di affidabili meccanismi di controllo degli accessi, impedendo l'accesso non autorizzato alle informazioni sensibili. Inizia con i raggruppamenti di persone di alto livello. Generalmente questi corrispondono alle unità organizzative e ai ruoli lavorativi (ad esempio, amministratore di sistema nel reparto IT, controllore finanziario o business analyst). I gruppi classificano le persone che eseguono attività simili e necessitano di un accesso simile. I ruoli definiscono che cosa un gruppo deve fare. È più facile gestire le autorizzazioni per gruppi e ruoli che per i singoli utenti. I ruoli e i gruppi assegnano le autorizzazioni in modo coerente e sistematico a tutti gli utenti, evitando errori e incongruenze. 

 Quando il ruolo di un utente cambia, gli amministratori possono modificare l'accesso a livello di ruolo o di gruppo, anziché riconfigurare i singoli account utente. Ad esempio, un amministratore di sistema nel reparto IT deve disporre di un accesso che permetta di creare tutte le risorse, mentre un membro del team di analisi ha la necessità di creare soltanto risorse di analisi. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+ **Implementazione dei gruppi: **utilizzando i gruppi di utenti definiti nelle policy dell'organizzazione, implementa i gruppi corrispondenti, se necessario. Per le best practice su utenti, gruppi e autenticazione, consulta il [Pilastro della sicurezza](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) del Framework AWS Well-Architected.
+ **Implementazione di ruoli e policy:** utilizzando le operazioni definite nelle policy dell'organizzazione, crea le policy di accesso e i ruoli necessari. Per le best practice su ruoli e policy, consulta il [Pilastro della sicurezza](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) del Framework AWS Well-Architected.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Policy gestite da AWS per le funzioni lavorative](https://docs.aws.amazon.com/iam/latest/UserGuide/access_policies_job-functions.html) 
+  [Strategia di fatturazione con account multipli di AWS](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [Pilastro della sicurezza del Framework AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) 
+ [AWS Identity and Access Management (IAM) ](https://aws.amazon.com/iam/)
+ [ Policy AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)

 **Video correlati:** 
+ [AWS Identity and Access Management (IAM)](https://www.youtube.com/watch?v=SXSqhTn2DuE)

 **Esempi correlati:** 
+  [Well-Architected Labs: Identità e accesso base](https://wellarchitectedlabs.com/Security/100_Basic_Identity_and_Access_Management_User_Group_Role/README.html) 
+  [Easier way to control access to Regioni AWS using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+ [ Starting your Cloud Financial Management journey: Cloud cost operations ](https://aws.amazon.com/blogs/aws-cloud-financial-management/op-starting-your-cloud-financial-management-journey/)

# COST02-BP05 Implementazione dei controlli di costo
<a name="cost_govern_usage_controls"></a>

 Implementa controlli basati sulle policy dell'organizzazione e gruppi e ruoli definiti. Questi garantiscono che i costi siano sostenuti solo in base ai requisiti dell'organizzazione come, ad esempio, il controllo dell'accesso alle regioni o ai tipi di risorse. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Un primo passo comune per implementare i controlli dei costi consiste nell'impostare delle notifiche quando si verificano eventi di costi o utilizzo al di fuori delle policy. In questo modo è possibile agire rapidamente e verificare se è necessaria un'azione correttiva, senza limitare o influire negativamente sui carichi di lavoro o sulle nuove attività. Dopo avere appreso i limiti del carico di lavoro e dell'ambiente, puoi applicare la governance. [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/) consente di impostare notifiche e di definire budget mensili per i costi, l'utilizzo e gli sconti a fronte di impegni di AWS (Savings Plans e istanze riservate). È possibile creare budget a livello di costo aggregato (ad esempio, tutti i costi) o a un livello più granulare, includendo solo dimensioni specifiche come account membri, servizi, tag o zone di disponibilità.

 Una volta configurati i limiti di budget con Budget AWS, utilizza [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) per ridurre i costi inaspettati. AWS Cost Anomaly Detection è un servizio di gestione dei costi che utilizza il machine learning per monitorare costantemente i costi e l'utilizzo con lo scopo di individuare le spese anomale. Aiuta a individuare le spese anomale e le cause principali in modo da garantire un intervento tempestivo. Per prima cosa, crea un monitor dei costi in AWS Cost Anomaly Detection, quindi scegli le tue preferenze relativamente agli avvisi impostando una soglia in dollari (ad esempio, un avviso sulle spese anomale con impatto superiore a 1.000 dollari). Una volta ricevuti gli avvisi, puoi analizzare la causa alla base dell'anomalia e l'impatto sui costi. Puoi inoltre monitorare ed eseguire la tua analisi delle anomalie in AWS Cost Explorer. 

 Imponi le policy di governance in AWS attraverso [AWS Identity and Access Management](https://aws.amazon.com/iam/) e [le Policy di controllo dei servizi (Service Control Policies, SCP) di AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html). IAM permette di gestire in modo sicuro l'accesso ai servizi e alle risorse di AWS. Utilizzando IAM, puoi controllare chi può creare e gestire le risorse di AWS, il tipo di risorse che possono essere create e dove possono essere create. In questo modo riduci al minimo la possibilità che vengano create risorse al di fuori della policy definita. Utilizza i ruoli e i gruppi creati in precedenza e assegna le [policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) per garantire l'utilizzo corretto. Le SCP offrono il controllo centralizzato sul numero massimo di autorizzazioni disponibili per tutti gli account nella tua organizzazione, assicurando che i tuoi account rimangano entro le linee guida di controllo degli accessi. Le SCP sono disponibili soltanto in un'organizzazione con tutte le funzionalità abilitate e possono essere configurate in modo da rifiutare o consentire operazioni agli account membri per impostazione predefinita. Per ulteriori dettagli sull'implementazione della gestione degli accessi, consulta il [whitepaper sul principio della sicurezza del canone di architettura](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html). 

 La governance può essere implementata anche tramite la gestione delle [Service Quotas di AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html). Assicurandoti che le Service Quotas siano impostate con spese minime e siano gestite in modo accurato, puoi ridurre al minimo la creazione di risorse che non rientrano nei requisiti della tua organizzazione. Per ottenere questo risultato, devi comprendere la velocità con cui i tuoi requisiti possono cambiare, valutare i progetti in corso (sia la creazione sia la disattivazione di risorse) e considerare la velocità con cui è possibile implementare le modifiche alle quote. Le [Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) possono essere utilizzate per aumentare le quote all'occorrenza. 

**Passaggi dell'implementazione**
+ **Implementa le notifiche delle spese:** utilizzando le policy dell'organizzazione definite, crea dei [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/) per inviare notifiche quando la spesa ricade al di fuori delle policy. Configura più budget dei costi, uno per ogni account, in modo da ricevere informazioni sulla spesa complessiva del conto. Quindi configura budget di costo aggiuntivi all'interno di ciascun account per unità più piccole al suo interno. Queste unità variano a seconda della struttura dell'account. Alcuni esempi comuni sono Regioni AWS, carichi di lavoro (tramite i tag) o servizi AWS. Configura un elenco di distribuzione e-mail come destinatario per le notifiche e non un account e-mail di una singola persona. È possibile configurare un budget effettivo per quando un importo viene superato oppure utilizzare un budget previsto per la notifica dell'utilizzo previsto. Si possono anche preconfigurare AWS Budget Actions (operazioni di budget) che possono applicare specifiche policy IAM o SCP o arrestare delle istanze Amazon EC2 o Amazon RDS definite. Le operazioni di budget possono essere eseguite automaticamente o richiedere l'approvazione del flusso di lavoro.
+  **Implementa le notifiche sulle spese anomale:** utilizza [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) per ridurre i costi inattesi nella tua organizzazione e analizzare le cause di potenziali spese anomale. Una volta creato il sistema di monitoraggio dei costi per identificare le spese insolite alla granularità specificata e aver configurato le notifiche in AWS Cost Anomaly Detection, viene inviato un avviso quando sono rilevate spese insolite. Questo ti permetterà di analizzare le cause alla base dell'anomalia e di valutarne l'impatto sui costi. Utilizza le categorie di costo AWS durante la configurazione di AWS Cost Anomaly Detection per identificare il team di progetto o il team della business unit che può analizzare la causa principale del costo imprevisto e intraprendere tempestivamente le azioni necessarie. 
+ ** Implementa il controllo dell'utilizzo** utilizzando le policy dell'organizzazione definite, implementa policy e ruoli IAM per specificare quali azioni possono o non possono eseguire gli utenti. In una policy AWS possono essere incluse più policy organizzative. Nello stesso modo in sono state definite le policy, occorre iniziare in modo generale e quindi applicare controlli più dettagliati a ogni fase. Anche le restrizioni dei servizi sono un controllo efficace sull'utilizzo. Implementa le restrizioni dei servizi corrette su tutti gli account. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Politiche gestite da AWS per le funzioni dell'attività](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html) 
+  [Strategia di fatturazione con account multipli di AWS](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [Controllo dell'accesso a Regioni AWS tramite le politiche IAM](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/) 
+  [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 
+  [Controlla i tuoi costi di AWS](https://aws.amazon.com/getting-started/hands-on/control-your-costs-free-tier-budgets/) 

 **Video correlati:** 
+  [Come faccio a utilizzare Budget AWS per tenere traccia delle mie spese e del mio utilizzo](https://www.youtube.com/watch?v=Ris23gKc7s0) 

 **Esempi correlati:** 
+  [Policy di gestione degli accessi IAM di esempio ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html) 
+  [Policy di controllo dei servizi di esempio](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) 
+  [AWS Budget Actions](https://aws.amazon.com/blogs/aws-cloud-financial-management/get-started-with-aws-budgets-actions/) 
+  [Crea una policy IAM per controllare l'accesso alle risorse Amazon EC2 utilizzando i tag](https://aws.amazon.com/premiumsupport/knowledge-center/iam-ec2-resource-tags/) 
+  [Limit l'accesso dell'identità IAM a specifiche risorse Amazon EC2](https://aws.amazon.com/premiumsupport/knowledge-center/restrict-ec2-iam/) 
+  [Crea una policy IAM per limitare l'uso di Amazon EC2 a famiglie di macchine selezionate](https://www.wellarchitectedlabs.com/cost/200_labs/200_2_cost_and_usage_governance/3_ec2_restrict_family/) 
+  [Well-Architected Labs: utilizzo di costi e governance (Livello 100)](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  [Well-Architected Labs: utilizzo di costi e governance (Livello 200)](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_2_Cost_and_Usage_Governance/README.html) 
+  [Integrazioni Slack per Cost Anomaly Detection utilizzando Amazon Q Developer in chat applications](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/) 

# COST02-BP06 Monitoraggio del ciclo di vita del progetto
<a name="cost_govern_usage_track_lifecycle"></a>

 Rileva, misura e controlla il ciclo di vita di progetti, team e ambienti per evitare di usare risorse non necessarie e pagare per esse. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Il monitoraggio efficace del ciclo di vita del progetto consente alle organizzazioni di avere un migliore controllo sui costi attraverso una migliore pianificazione, gestione e ottimizzazione delle risorse, del tempo e della qualità. Le informazioni acquisite attraverso il monitoraggio sono preziose per la formulazione di decisioni informate che contribuiscono alla competitività a livello di costi e al successo complessivo del progetto. 

 Il monitoraggio dell'intero ciclo di vita del carico di lavoro consente di capire quando i carichi di lavoro o i suoi componenti non sono più necessari. I carichi di lavoro e i componenti esistenti possono sembrare in uso, ma quando AWS rilascia nuovi servizi o nuove funzionalità, è possibile che vengano disattivati o adottati. Controlla le fasi precedenti dei carichi di lavoro. Quando un carico di lavoro arriva in produzione, gli ambienti precedenti possono essere disattivati o notevolmente ridotti in termini di capacità fino a quando non sono nuovamente necessari. 

 AWS offre una serie di servizi di gestione e governance utilizzabili per il monitoraggio del ciclo di vita delle entità. Puoi utilizzare [AWS Config](https://aws.amazon.com/config/) o [AWS Systems Manager](https://aws.amazon.com/systems-manager/) per fornire un inventario dettagliato delle risorse e della configurazione AWS. Si consiglia di integrare questi servizi con i sistemi di gestione di progetti o asset esistenti per tenere traccia dei progetti e dei prodotti attivi all'interno della tua organizzazione. La combinazione del tuo sistema attuale con l'ampia gamma di eventi e parametri forniti da AWS ti consentirà di ottenere una panoramica degli eventi del ciclo di vita significativi e di gestire le risorse in modo proattivo per ridurre i costi non necessari. 

 Analogamente alla [gestione del ciclo di vita dell'applicazione (ALM)](https://aws.amazon.com/what-is/application-lifecycle-management/), il monitoraggio del ciclo di vita del progetto dovrebbe coinvolgere più processi, strumenti e team che interagiscono tra loro, ad esempio progettazione e sviluppo, test, produzione, supporto e ridondanza del carico di lavoro. 

 Monitorando attentamente ogni fase del ciclo di vita di un progetto, le organizzazioni ottengono informazioni cruciali e un maggiore controllo, semplificando la pianificazione, l'implementazione e la riuscita del progetto. Questa attenta supervisione verifica che i progetti non solo soddisfino gli standard di qualità, ma vengano consegnati in tempo e nel rispetto del budget, promuovendo l'efficienza complessiva dei costi. 

 Per ulteriori dettagli sull'implementazione del monitoraggio del ciclo di vita delle entità, consulta il [whitepaper sul principio dell'eccellenza operativa del canone di AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html). 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Definisci un processo di monitoraggio del ciclo di vita del progetto:** il [team del Centro di eccellenza del Cloud (CCoE)](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_cloud_financial_management_function.html) deve stabilire un processo di monitoraggio del ciclo di vita del progetto. Stabilisci un approccio strutturato e sistematico per il monitoraggio dei carichi di lavoro al fine di migliorare il controllo, la visibilità e le prestazioni dei progetti. Rendi il processo di monitoraggio trasparente, collaborativo e incentrato sul miglioramento continuo per massimizzarne l'efficacia e il valore. 
+ **Esegui revisioni del carico di lavoro:** come definito dalle policy dell'organizzazione, imposta una cadenza regolare per controllare i progetti esistenti ed eseguire revisioni del carico di lavoro. Lo sforzo per l'audit deve essere proporzionale al rischio, al valore o al costo approssimativo per l'organizzazione. Le aree chiave da includere nell'audit sono il rischio di incidente o interruzione per l'organizzazione, il valore o contributo all'organizzazione (misurato in fatturato o reputazione del marchio), il costo del carico di lavoro (misurato come costo totale delle risorse e costi operativi) e l'utilizzo del carico di lavoro (misurato in numero di risultati dell'organizzazione per unità di tempo). Se queste aree cambiano durante il ciclo di vita, sono necessarie modifiche al carico di lavoro, ad esempio la disattivazione completa o parziale.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Guidance for Tagging on AWS](https://aws.amazon.com/solutions/guidance/tagging-on-aws/)
+ [Cos'è l'ALM (Application Lifecycle Management)?](https://aws.amazon.com/what-is/application-lifecycle-management/)
+  [Politiche gestite da AWS per le funzioni dell'attività](https://docs.aws.amazon.com//latest/UserGuide/access_policies_job-functions.html) 

 **Esempi correlati:** 
+  [Controllo dell'accesso a Regioni AWS tramite le politiche IAM](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 

 **Strumenti correlati:** 
+  [AWS Config](https://aws.amazon.com/config/) 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+ [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)

# COST 3. In che modo monitori i costi e l'utilizzo?
<a name="cost-03"></a>

Stabilisci policy e procedure per monitorare e allocare i costi in modo appropriato. Ciò ti permette di misurare e migliorare l'efficienza in termini di costi del carico di lavoro.

**Topics**
+ [COST03-BP01 Configurazione di fonti di informazione dettagliate](cost_monitor_usage_detailed_source.md)
+ [COST03-BP02 Aggiunta di informazioni sull'organizzazione a costi e utilizzo](cost_monitor_usage_org_information.md)
+ [COST03-BP03 Identificazione delle categorie di attribuzione dei costi](cost_monitor_usage_define_attribution.md)
+ [COST03-BP04 Definizione dei parametri dell'organizzazione](cost_monitor_usage_define_kpi.md)
+ [COST03-BP05 Configurazione degli strumenti di fatturazione e di gestione dei costi](cost_monitor_usage_config_tools.md)
+ [COST03-BP06 Allocazione dei costi in base alle metriche del carico di lavoro](cost_monitor_usage_allocate_outcome.md)

# COST03-BP01 Configurazione di fonti di informazione dettagliate
<a name="cost_monitor_usage_detailed_source"></a>

Configura gli strumenti di gestione dei costi e di reporting per la granularità oraria allo scopo di fornire informazioni dettagliate su costi e utilizzo, consentendo analisi più approfondite e maggiore trasparenza. Configura il carico di lavoro in modo da registrare le voci di log per ogni risultato aziendale raggiunto.

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Informazioni dettagliate sulla fatturazione, come la granularità oraria negli strumenti di gestione dei costi, consentono alle organizzazioni di tenere traccia dei propri consumi con ulteriori dettagli e di aiutarle a identificare alcuni dei motivi di aumento dei costi. Queste origini dati forniscono la visualizzazione più accurata dei costi e dell'utilizzo dell'intera organizzazione. 

 AWS Cost and Usage Report fornisce una granularità di utilizzo giornaliera o oraria, tariffe, costi e attributi di utilizzo per tutti i servizi AWS addebitati. In CUR sono inclusi tutti gli aspetti possibili, compresi tagging, posizione, attributi delle risorse e ID account. 

 Configura CUR con le seguenti personalizzazioni: 
+  Inclusione degli ID risorsa 
+  Aggiornamento automatico del CUR 
+  Granularità oraria 
+  **Controllo delle versioni:** sovrascrittura del report esistente 
+  **Integrazione dei dati:** Athena (formato Parquet e compressione) 

 Utilizzo [AWS Glue](https://aws.amazon.com/glue/) per preparare i dati per l'analisi e [Amazon Athena](https://aws.amazon.com/athena/) per eseguire l'analisi dei dati, utilizzando SQL per eseguire query sui dati. Puoi anche utilizzare [Quick](https://aws.amazon.com/quicksight/) per creare visualizzazioni personalizzate e complesse e distribuirle in tutta l'organizzazione. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Configura il report su costi e utilizzo:** Utilizzando la console di fatturazione, configura almeno un report costi e utilizzo. Configura un report con granularità oraria che include tutti gli identificatori e gli ID risorsa. Puoi anche creare altri report con granularità diverse per fornire informazioni di riepilogo di livello superiore. 
+  **Configura la granularità oraria in Cost Explorer:** Abilita **Ogni ora** e **Dati a livello di risorsa** per accedere ai dati sui costi e sull'utilizzo con granularità oraria negli ultimi 14 giorni e granularità a livello di risorsa. 
+  **Configura la registrazione dell'applicazione:** Verifica che l'applicazione registri ogni risultato aziendale che distribuisce in modo che possa essere monitorato e misurato. Assicurati che la granularità di questi dati sia almeno oraria, affinché possa essere abbinata ai dati relativi a costi e utilizzo. Per ulteriori dettagli su registrazione e monitoraggio, consulta [Whitepaper sul pilastro dell'eccellenza operativa secondo il framework well-architected](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) 
+  [AWS Glue](https://aws.amazon.com/glue/) 
+  [Quick](https://aws.amazon.com/quicksight/) 
+  [Gestione dei costi AWS](https://aws.amazon.com/aws-cost-management/pricing/) 
+  [Applicazione di tag alle risorse AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) 
+  [Analyzing your costs with Budget AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Analisi dei costi con Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Managing AWS Cost and Usage Reports](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 
+  [Whitepaper sul pilastro dell'eccellenza operativa secondo il framework well-architected](https://wa.aws.amazon.com/wat.pillar.operationalExcellence.en.html) 

 **Esempi correlati:** 
+  [Configurazione dell'account AWS](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html) 
+  [AWS Cost Explorer’s New Look and Common Use Cases](https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-cost-explorers-new-ui-and-common-use-cases/) 

# COST03-BP02 Aggiunta di informazioni sull'organizzazione a costi e utilizzo
<a name="cost_monitor_usage_org_information"></a>

Definisci uno scherma per l'applicazione di tag in base alla tua organizzazione, agli attributi del carico di lavoro e alle categorie di allocazione dei costi, in modo da poter filtrare e cercare le risorse o monitorare costi e utilizzo negli strumenti di gestione dei costi. Implementa un'applicazione di tag consistente in tutte le risorse possibili per scopo, team, ambiente o altri criteri pertinenti alla tua azienda. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Implementa l'[applicazione di tag in AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) per aggiungere informazioni sull'organizzazione alle risorse, che verranno, quindi, aggiunte alle informazioni su costi e utilizzo. Un tag è una coppia chiave-valore: la chiave è definita e deve essere univoca all'interno dell'organizzazione, mentre il valore è univoco per un gruppo di risorse. Ad esempio, una coppia chiave-valore può essere costituita da `ambiente` (chiave) e `produzione` (valore). Tutte le risorse nell'ambiente di produzione avranno questa coppia chiave-valore. L'applicazione di tag consente di categorizzare e monitorare i costi con informazioni significative e rilevanti sull'organizzazione. Puoi applicare tag che rappresentano categorie dell'organizzazione (ad esempio, centri di costo, nomi di applicazioni, progetti o proprietari) e identificano carichi di lavoro e rispettive funzionalità (come test o produzione) per attribuire i costi e l'utilizzo all'interno dell'organizzazione.

Quando applichi i tag alle tue risorse AWS (come le istanze Amazon Elastic Compute Cloud o i bucket Amazon Simple Storage Service) e li attivi, AWS aggiunge queste informazioni ai report su costi e utilizzo. Puoi creare report e condurre analisi su risorse con tag e senza tag per incrementare la conformità con le politiche di gestione dei costi interne e garantire un'attribuzione accurata.

La creazione e l'implementazione di uno standard per l'applicazione di tag AWS tra gli account dell'organizzazione ti consente di gestire e amministrare gli ambienti AWS in modo coerente e uniforme. Usa le [politiche sui tag](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) in AWS Organizations per definire regole su come i tag possono essere applicati alle risorse AWS nei tuoi account in AWS Organizations. Le policy di tag consentono di adottare con facilità un approccio standardizzato per l'applicazione di tag alle risorse AWS.

[AWS Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) consente di aggiungere, eliminare e gestire tag di più risorse. Con Tag Editor cerchi le risorse a cui applicare i tag, quindi gestisci i tag per le risorse nei risultati della ricerca.

[AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) consente di assegnare ai tuoi costi significati per l'organizzazione, senza necessità di applicare tag alle risorse. Puoi mappare le informazioni su costi e utilizzo attribuendole a strutture organizzative interne univoche. Puoi definire regole di categoria per mappare e categorizzare i costi utilizzando le dimensioni di fatturazione, ad esempio account e tag. Questo offre un altro livello di funzionalità di gestione oltre all'applicazione di tag. Puoi anche mappare account e tag specifici attribuendoli a più progetti.

**Passaggi dell'implementazione**
+  **Definisci uno schema per l'applicazione di tag:** riunisci tutte le parti interessate di tutta l'azienda per definire uno schema. Questo generalmente include i ruoli tecnici, finanziari e di gestione. Definisci un elenco di tag che tutte le risorse devono avere, nonché un elenco di tag che le risorse dovrebbero avere. Verifica che i nomi e i valori dei tag siano coerenti all'interno dell'organizzazione. 
+ ** Risorse di tag: **utilizzando le categorie di attribuzione dei costi definite, [posiziona i tag](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) su tutte le risorse nei carichi di lavoro in base alle categorie. Utilizza strumenti come l'interfaccia a riga di comando (CLI), Tag Editor o AWS Systems Manager per aumentare l'efficienza. 
+  **Implementa AWS Cost Categories: **puoi creare delle [categorie di costo](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) senza implementare l'applicazione dei tag. Cost Categories utilizza le dimensioni di costo e utilizzo esistenti. Crea regole di categoria dallo schema e implementale in Cost Categories. 
+  **Applicazione automatica di tag:** per verificare di mantenere elevati livelli di applicazione di tag tra tutte le risorse, automatizza l'applicazione di tag in modo che le risorse siano contrassegnate automaticamente al momento della creazione. Usa i servizi come [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html) per verificare che alle risorse vengano applicati i tag al momento della creazione. Puoi anche creare una soluzione personalizzata per [applicare i tag in automatico](https://aws.amazon.com/blogs/mt/auto-tag-aws-resources/) tramite le funzioni Lambda o usare un microservizio che scansioni periodicamente il carico di lavoro e rimuova le risorse non contrassegnate, l'ideale per ambienti di test e sviluppo. 
+ ** Monitora ed elabora report sull'applicazione di tag: **per verificare di mantenere elevati livelli di applicazione di tag nella tua organizzazione, segnala e monitora i tag tra i tuoi carichi di lavoro. Puoi utilizzare [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) per visualizzare il costo delle risorse con tag e senza tag oppure utilizzare servizi come [Tag Editor](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). Verifica regolarmente il numero di risorse senza tag e aggiungi i tag fino a raggiungere il livello desiderato di applicazione di tag. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Best practice per l'applicazione di tag ](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+  [Applicazione di tag alle risorse AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html) 
+  [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 
+  [Applicazione di tag alle risorse AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [Analisi dei costi con Budget AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Analisi dei costi con Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Gestione del report su costi e utilizzo di AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

 **Video correlati:** 
+ [ Come posso applicare tag alle mie risorse AWS per dividere la mia fattura per centro di costo o progetto ](https://www.youtube.com/watch?v=3j9xyyKIg6w)
+ [ Applicazione di tag alle risorse AWS](https://www.youtube.com/watch?v=MX9DaAQS15I)

 **Esempi correlati:** 
+ [ Applica automaticamente tag alle nuove risorse AWS in base all'identità o al ruolo ](https://aws.amazon.com/blogs/mt/auto-tag-aws-resources/)

# COST03-BP03 Identificazione delle categorie di attribuzione dei costi
<a name="cost_monitor_usage_define_attribution"></a>

 Identifica le categorie dell'organizzazione, come unità aziendali, reparti o progetti, che potrebbero essere utilizzate per allocare i costi alle entità responsabili dei consumi interni. Utilizza queste categorie per rafforzare la responsabilità della spesa, creare consapevolezza dei costi e promuovere comportamenti di consumo efficaci. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Il processo di categorizzazione dei costi è fondamentale nella definizione del budget, nella contabilità, nella rendicontazione finanziaria, nel processo decisionale, nell'analisi comparativa e nella gestione dei progetti. La categorizzazione e la classificazione delle spese consentono ai team di comprendere meglio i tipi di costi che dovranno sostenere durante il loro percorso verso il cloud, aiutandoli a prendere decisioni informate e a gestire i budget in modo efficace. 

 La responsabilità della spesa cloud costituisce un forte incentivo per una gestione disciplinata della domanda e dei costi. Il risultato è un notevole risparmio sui costi del cloud per le organizzazioni che destinano la maggior parte della loro spesa per il cloud a unità aziendali o team che utilizzano il cloud. Inoltre, l'allocazione della spesa per il cloud aiuta le organizzazioni ad adottare un numero maggiore di best practice di governance centralizzata del cloud. 

 Collabora con il tuo team finanziario e altre parti interessate per comprendere i requisiti di allocazione dei costi all'interno della tua organizzazione durante le riunioni organizzate con periodicità regolare. I costi del carico di lavoro devono essere allocati per tutto il ciclo di vita, inclusi sviluppo, test, produzione e disattivazione. Comprendi in che modo i costi sostenuti per formazione, sviluppo del personale e creazione di idee sono attribuiti all'interno dell'organizzazione. Questo può essere utile per assegnare correttamente gli account utilizzati a questo scopo ai budget di formazione e sviluppo anziché ai budget di costi IT generici. 

 Dopo aver definito le categorie di attribuzione dei costi con le parti interessate all'interno dell'organizzazione, utilizza [Categorie di costo AWS](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) per raggruppare le informazioni sui costi e sull'utilizzo in categorie significative nel Cloud AWS, ad esempio costi per progetti specifici o Account AWS per reparti o unità aziendali. Puoi creare categorie personalizzate e mappare le informazioni su costi e utilizzo in queste categorie in base a regole che definisci usando componenti diversi come account, tag, servizio o tipo di addebito. Una volta impostate le categorie di costi, è possibile visualizzare le informazioni su costi e utilizzo consentendo così alla tua organizzazione di prendere decisioni di acquisto e strategiche migliori. Tali categorie sono visibili in AWS Cost Explorer, Budget AWS e anche in AWS Cost and Usage Report. 

 Ad esempio, crea categorie di costo per le tue unità aziendali (Team DevOps) e in ogni categoria crea più regole (regole per ogni sottocategoria) con più componenti (Account AWS, tag di allocazione dei costi, servizi o tipo di addebito) in base ai raggruppamenti da te definiti. Con le categorie di costo puoi organizzare i tuoi costi con un motore basato su regole. Le regole che configuri organizzano i costi in categorie. All'interno di queste regole, puoi filtrare utilizzando più aspetti o componenti per ciascuna categoria, come Account AWS, servizi AWS o tipi di addebito specifici. Puoi, quindi, usare queste categorie in più prodotti nella [Gestione dei costi e fatturazione AWS e gestione dei costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-what-is.html) [Gestione dei costi e fatturazione AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/view-billing-dashboard.html). Sono inclusi AWS Cost Explorer, Budget AWS, AWS Cost and Usage Report e AWS Cost Anomaly Detection. 

 Come esempio, il diagramma seguente mostra in che modo raggruppare i costi e le informazioni sull'utilizzo nella tua organizzazione definendo più team (categoria di costo), molteplici ambienti (regole) e assegnando a ogni ambiente molteplici risorse o asset (dimensioni). 

![\[Diagramma di flusso che descrive in dettaglio la relazione tra costi e utilizzo all'interno di un'organizzazione.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/cost-usage-organization-chart.png)


 

 Puoi anche creare gruppi di costi con le categorie di costo. Dopo aver creato le categorie di costo (attendi fino a 24 ore dopo la creazione di una categoria di costo affinché i dati di utilizzo siano aggiornati con i valori), appariranno in [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/), [Budget AWS](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html), [AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)e [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/). In AWS Cost Explorer e Budget AWS, una categoria di costo appare come una componente di fatturazione aggiuntiva. Puoi usarla per filtrare valori specifici della categoria di costo o per definire i gruppi in base alla categoria di costo. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Definisci le categorie dell'organizzazione:** organizza riunioni con le parti interessate interne e le unità di business per definire categorie che riflettano la struttura e i requisiti della tua organizzazione. Queste categorie dovrebbero corrispondere direttamente alla struttura delle categorie finanziarie esistenti, ad esempio unità aziendale, budget, centro di costi o reparto. Osserva i risultati che il cloud offre per la tua azienda, ad esempio la formazione o l'istruzione, poiché anche queste sono categorie organizzative. 
+  **Definisci le categorie funzionali:** organizza riunioni con le parti interessate interne e le unità di business per definire categorie che riflettano le funzioni presenti all'interno della tua azienda. Potrebbe trattarsi del carico di lavoro o dei nomi delle applicazioni e del tipo di ambiente, ad esempio produzione, test o sviluppo.. 
+  **Definisci le Categorie di costo AWS:** Crea categorie di costi per organizzare le informazioni sui costi e sull'utilizzo mediante [Categorie di costo AWS](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) e mappa i costi e l'utilizzo di AWS in [categorie significative](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/create-cost-categories.html). A una risorsa possono essere assegnate più categorie e una risorsa può essere in più categorie diverse, quindi definisci tutte le categorie necessarie in modo da essere in grado di [gestire i costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) all'interno della struttura categorizzata utilizzando le Categorie di costo AWS. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Applicazione di tag alle risorse AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [Utilizzo dei tag di allocazione dei costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) 
+  [Analyzing your costs with Budget AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Analisi dei costi con Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Managing AWS Cost and Usage Reports](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 
+  [Categorie di costo AWS](https://docs.aws.amazon.com/wellarchitected/latest/framework/aws-cost-management/aws-cost-categories/) 
+  [Gestione dei costi con Categorie di costo AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) 
+  [Creazione di categorie di costo](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/create-cost-categories.html) 
+  [Applicazione di tag alle categorie di costo](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/tag-cost-categories.html) 
+  [Suddivisione degli addebiti all'interno delle categorie di costo](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/splitcharge-cost-categories.html) 
+  [Funzionalità delle Categorie di costo AWS](https://aws.amazon.com/aws-cost-management/aws-cost-categories/features/) 

 **Esempi correlati:** 
+  [Organizza i dati su costi e utilizzo con Categorie di costo AWS](https://aws.amazon.com/blogs/aws-cloud-financial-management/organize-your-cost-and-usage-data-with-aws-cost-categories/) 
+  [Gestione dei costi con Categorie di costo AWS](https://aws.amazon.com/aws-cost-management/resources/managing-your-costs-with-aws-cost-categories/) 
+  [Well-Architected Labs: visualizzazione di costi e utilizzo](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  [Well-Architected Labs: Cost Categories](https://wellarchitectedlabs.com/cost/200_labs/200_cost_category/) 

# COST03-BP04 Definizione dei parametri dell'organizzazione
<a name="cost_monitor_usage_define_kpi"></a>

 Definisci i parametri dell'organizzazione necessari per questo carico di lavoro. I parametri esemplificativi di un carico di lavoro sono i report dei clienti prodotti o le pagine web scaricate dai clienti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

comprendi in che modo viene misurato l'output del carico di lavoro rispetto al successo aziendale. Ogni carico di lavoro ha in genere un piccolo set di output principali che indicano le prestazioni. Se disponi di un carico di lavoro complesso con molti componenti, puoi dare priorità alle voci dell'elenco o definire e monitorare i parametri per ogni componente. Collabora con i tuoi team per capire quali parametri utilizzare. Questa unità verrà utilizzata per comprendere l'efficienza del carico di lavoro o il costo per ciascun output aziendale.

**Passaggi dell'implementazione**
+  **Definisci i risultati del carico di lavoro: **organizza riunioni con le parti interessate dell'azienda e definisci i risultati del carico di lavoro. Si tratta di una misura principale dell'utilizzo da parte dei clienti e devono essere parametri aziendali e non parametri tecnici. Deve esserci un piccolo numero di parametri di alto livello (meno di cinque) per carico di lavoro. Se il carico di lavoro produce più risultati per diversi casi d'uso, raggruppali in un singolo parametro. 
+  **Definisci i risultati dei componenti del carico di lavoro: **facoltativamente, se disponi di un carico di lavoro grande e complesso oppure puoi suddividere facilmente il carico di lavoro in componenti (ad esempio microservizi) con input e output ben definiti, definisci i parametri per ogni componente. Lo sforzo deve riflettere il valore e il costo del componente. Inizia con i componenti più grandi e punta ai componenti più piccoli. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Applicazione di tag alle risorse AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [Analisi dei costi con Budget AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Analisi dei costi con Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Gestione del report su costi e utilizzo di AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

# COST03-BP05 Configurazione degli strumenti di fatturazione e di gestione dei costi
<a name="cost_monitor_usage_config_tools"></a>

 Configura gli strumenti di gestione dei costi in linea con le politiche della tua organizzazione per gestire e ottimizzare gli investimenti nel cloud. Sono inclusi servizi, strumenti e risorse per organizzare e monitorare dati su costi e utilizzo, migliorare il controllo tramite una fatturazione consolidata e autorizzazioni di accesso, perfezionare la pianificazione tramite budget e previsioni, ricevere notifiche o allarmi e ridurre ulteriormente i costi tramite l'ottimizzazione di prezzi e risorse. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per definire una forte consapevolezza, la strategia che interessa l'account deve essere considerata come parte integrante della strategia di allocazione dei costi. Definisci questo concetto ora per non doverlo affrontare in futuro. In caso contrario, il livello di consapevolezza potrebbe essere insufficiente e si potranno verificare problemi in seguito. 

 Per promuovere la consapevolezza nei confronti della spesa per il cloud, gli utenti devono avere accesso a strumenti in grado di fornire visibilità su costi e utilizzo. È consigliabile che tutti i carichi di lavoro e i team dispongano dei seguenti strumenti configurati relativamente ai seguenti dettagli e scopi: 
+  **Organizzazione:** Definisci l'allocazione dei costi e i riferimenti della governance con la tua strategia di applicazione dei tag e le tue categorizzazioni. 
+  **Organizzazione:** definisci l'allocazione dei costi e i riferimenti della governance con la tua strategia di applicazione dei tag e la tassonomia. Assegna tag alle risorse AWS supportate e classificale in modo significativo in base alla struttura organizzativa (unità aziendali, reparti o progetti). Contrassegna con tag i nomi degli account per centri di costo specifici e mappali con AWS Cost Categories per raggruppare gli account per particolari unità aziendali per i relativi centri di costo in modo che il responsabile dell'unità aziendale possa visualizzare il consumo di più account in un’unica posizione. 
+  **Accesso:** monitora le informazioni di fatturazione a livello aziendale nella [fatturazione consolidata](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) e verifica che le parti interessate e gli imprenditori idonei abbiano accesso. 
+  **Controllo:** Crea meccanismi di governance efficaci con i giusti guardrail per prevenire scenari imprevisti quando utilizzi Service Control Policies (SCP), policy di tag e avvisi sul budget. Ad esempio, puoi consentire ai team di creare risorse nelle regioni preferite solo utilizzando meccanismi di controllo efficaci. 
+  **Stato attuale:** configura un pannello di controllo che mostra i livelli correnti di costi e utilizzo. Il pannello di controllo deve essere disponibile in un luogo altamente visibile all'interno dell'ambiente di lavoro (simile a un pannello di controllo delle operazioni). Puoi utilizzare [Dashboard di cloud intelligence (CID)](https://github.com/aws-samples/aws-cudos-framework-deployment) o qualsiasi altro prodotto supportato per creare questa visibilità. 
+  **Notifiche:** avvisano quando il costo o l'utilizzo non rientra nei limiti definiti e quando si verificano anomalie con Budget AWS o AWS Cost Anomaly Detection. 
+  **Report:** riepiloga tutte le informazioni su costi e utilizzo e aumenta il livello di consapevolezza e responsabilità dei tuoi investimenti nel cloud con dati sui costi dettagliati e attribuibili. I report dovrebbero essere pertinenti al team che li utilizza e idealmente dovrebbero contenere raccomandazioni. 
+  **Monitoraggio:** mostra i costi e l'utilizzo attuali rispetto a obiettivi o target stabiliti. 
+  **Analisi:** offri ai membri del team la possibilità di eseguire analisi personalizzate e approfondite fino alla granularità oraria, con tutte le dimensioni possibili. 
+  **Esame:** ricevi aggiornamenti sull'implementazione delle tue risorse e sull'opportunità di ottimizzazione dei costi. Ricevi notifiche (utilizzando Amazon CloudWatch, Amazon SNS o Amazon SES) per l'implementazione delle risorse a livello di organizzazione e rivedi i consigli per l'ottimizzazione dei costi (ad esempio AWS Compute Optimizer o AWS Trusted Advisor). 
+  **Tendenze:** mostra la variabilità dei costi e dell'utilizzo nel periodo di tempo richiesto e con la granularità richiesta. 
+  **Previsioni:** mostra i costi futuri stimati, prevedi l'utilizzo delle risorse e investi con pannelli di controllo che tu stesso crei. 

 Puoi usare strumenti AWS come [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/), [Gestione dei costi e fatturazione AWS](https://aws.amazon.com/aws-cost-management/aws-billing/)o [Budget AWS](https://aws.amazon.com/aws-cost-management/aws-budgets/) per gli elementi essenziali oppure puoi integrare i dati CUR con [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway) e [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway) per fornire questa funzionalità per visualizzazioni più dettagliate. Se non disponi delle competenze o della larghezza di banda essenziali nella tua organizzazione, puoi utilizzare [AWS ProServ](https://aws.amazon.com/professional-services/), [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/)o [AWS Partner](https://aws.amazon.com/partners/) e i relativi strumenti. Puoi anche usare strumenti di terze parti, ma verifica prima che il costo offra valore alla tua organizzazione. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Consenti l'accesso agli strumenti basato sui team:** configura i tuoi account e crea gruppi che abbiano accesso ai report richiesti su costi e utilizzo per i loro consumi e usa [AWS Identity and Access Management](https://aws.amazon.com/iam/) per [controllare l'accesso](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html) agli strumenti come AWS Cost Explorer. Questi gruppi devono includere i rappresentanti di tutti i team che possiedono o gestiscono un'applicazione. In questo modo certifichi che ogni team ha accesso alle informazioni relative a costi e utilizzo propri per monitorare i loro consumi. 
+  **Configurazione di Budget AWS:** [Configura Budget AWS](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) su tutti gli account per i tuoi carichi di lavoro. Imposta un budget per la spesa complessiva dell'account e un budget per il carico di lavoro utilizzando i tag. Configura le notifiche in Budget AWS per ricevere allarmi quando superi gli importi previsti nel budget o quando i costi stimati sono superiori a quelli dei tuoi budget. 
+  **Configurazione di AWS Cost Explorer:** configura [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) per il tuo carico di lavoro e gli account e visualizza i dati sui costi per ulteriori analisi. Crea un pannello di controllo per il carico di lavoro che tenga traccia della spesa generale e le metriche di utilizzo chiave per il carico di lavoro, nonché preveda i costi futuri sulla base dei tuoi dati storici. 
+  **Configurazione di AWS Cost Anomaly Detection:** Utilizza [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) per i tuoi account, i servizi di base o le categorie di costo che hai creato per monitorare costi e utilizzo e individuare investimenti insoliti. Puoi ricevere avvisi individualmente in report aggregati, oppure avvisi in un'email o in un argomento Amazon SNS per poter analizzare e stabilire il motivo principale di un’anomalia, nonché identificare il fattore che determina l'aumento dei costi. 
+  **Configura gli strumenti avanzati:** facoltativamente, puoi creare uno strumento personalizzato per la tua organizzazione che fornisca dettagli e granularità aggiuntivi. Puoi implementare le funzionalità di analisi avanzata utilizzando [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway)e i pannelli di controllo utilizzando [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway). Prendi in considerazione l'utilizzo di [Soluzione CID](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) che ha pannelli di controllo preconfigurati e avanzati. Esistono anche [AWS Partner](https://aws.amazon.com/marketplace/solutions/business-applications/cloud-cost-management) con cui puoi lavorare e adottare le loro soluzioni di gestione del cloud per attivare il monitoraggio delle fatture cloud e l'ottimizzazione in un'unica posizione conveniente. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Gestione dei costi AWS](https://docs.aws.amazon.com/cost-management/latest/userguide/what-is-costmanagement.html) 
+  [Applicazione di tag](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) Risorse AWS 
+  [Analyzing your costs with Budget AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Analisi dei costi con Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Managing AWS Cost and Usage Report](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 
+  [Categorie di costo AWS](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 
+  [Gestione finanziaria del cloud con AWS](https://aws.amazon.com/aws-cost-management/) 
+  [Example service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) 
+  [AWS APN Partners – Cost Management](https://aws.amazon.com/marketplace/solutions/business-applications/cloud-cost-management) 

 **Video correlati:** 
+  [Implementazione di dashboard di intelligenza cloud](https://www.youtube.com/watch?v=FhGZwfNJTnc) 
+  [Ricevi allarmi su qualsiasi metrica FinOps, di ottimizzazione dei costi o KPI](https://www.youtube.com/watch?v=dzRKDSXCtAs) 

 **Esempi correlati:** 
+  [Well-Architected Labs: configurazione dell'account AWS](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html/) 
+  [Well-Architected Labs: visualizzazione della fatturazione](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html) 
+  [Well-Architected Labs: utilizzo di costi e governance](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  [Well-Architected Labs: analisi di costi e utilizzo](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_4_Cost_and_Usage_Analysis/README.html) 
+  [Well-Architected Labs: visualizzazione di costi e utilizzo](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  [Well-Architected Labs: Cloud Intelligence Dashboards (Pannelli di controllo Intelligence cloud)](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) 
+  [How to use SCPs to set permission guardrails across accounts](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/) 

# COST03-BP06 Allocazione dei costi in base alle metriche del carico di lavoro
<a name="cost_monitor_usage_allocate_outcome"></a>

Alloca i costi del carico di lavoro in base alle metriche di utilizzo o ai risultati aziendali per misurare l'efficienza dei costi del carico di lavoro. Implementa un processo per analizzare i dati relativi a costi e utilizzo con i servizi di analisi, che possono fornire informazioni approfondite e funzionalità di chargeback.

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Ottimizzare i costi significa conseguire i risultati aziendali al prezzo più basso, e implica l'allocazione dei costi del carico di lavoro in base ai parametri di quest'ultimo (misurati in termini di efficienza). Monitora le metriche del carico di lavoro definite tramite file di log o altre funzionalità di monitoraggio dell'applicazione. Combina questi dati con i costi del carico di lavoro, che possono essere ottenuti osservando i costi con un determinato valore di tag o ID account. Si consiglia di eseguire questa analisi a livello orario. L'efficienza cambia in genere se disponi di alcuni componenti di costo statico (ad esempio, un database back-end sempre in esecuzione) con un tasso di richiesta variabile (ad esempio, picchi di utilizzo tra le 9:00 e le 17:00, con poche richieste di notte). Comprendere la relazione tra i costi statici e i costi variabili ti aiuterà a rendere più mirate le tue attività di ottimizzazione. 

 La creazione di metriche del carico di lavoro per le risorse condivise può essere difficile rispetto a risorse come applicazioni containerizzate su Amazon Elastic Container Service (Amazon ECS) e Amazon API Gateway. Tuttavia, esistono alcuni modi per classificare l'utilizzo e tenere traccia dei costi. Se devi monitorare le risorse condivise Amazon ECS e AWS Batch, puoi abilitare i dati di allocazione dei costi suddivisi in AWS Cost Explorer. Con i dati di allocazione dei costi suddivisi, puoi analizzare e ottimizzare i costi e l'utilizzo delle tue applicazioni containerizzate e riallocare i costi delle applicazioni alle singole entità aziendali in base al modo in cui vengono consumate le risorse di calcolo e memoria condivise. Se hai condiviso l'utilizzo di funzioni API Gateway e AWS Lambda, puoi usare [AWS Application Cost Profiler](https://docs.aws.amazon.com/application-cost-profiler/latest/userguide/introduction.html) per classificare il loro consumo in base al relativo `ID tenant` oppure `ID cliente`. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Alloca i costi alle metriche del carico di lavoro:** Utilizzando le metriche e l'applicazione di tag definiti e configurati, crea una metrica che combini l'output e il costo del carico di lavoro. Utilizza i servizi di analisi come Amazon Athena e Amazon Quick per creare un pannello di controllo in grado di visualizzare l'efficienza del carico di lavoro complessivo e di ogni suo componente. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Applicazione di tag alle risorse AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [Analisi dei costi con Budget AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [Analisi dei costi con Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [Gestione del report su costi e utilizzo di AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

 **Esempi correlati:** 
+ [ Migliora la visibilità dei costi di Amazon ECS e AWS Batch con i dati di allocazione dei costi suddivisi AWS](https://aws.amazon.com/blogs/aws-cloud-financial-management/la-improve-cost-visibility-of-containerized-applications-with-aws-split-cost-allocation-data-for-ecs-and-batch-jobs/)

# COST 4. In che modo disattivi le risorse?
<a name="cost-04"></a>

Implementa il controllo del cambiamento e la gestione delle risorse dall'inizio del progetto alla fine del ciclo di vita. In questo modo, puoi chiudere o interrompere le risorse non utilizzate per ridurre gli sprechi.

**Topics**
+ [COST04-BP01 Monitoraggio delle risorse durante il loro ciclo di vita](cost_decomissioning_resources_track.md)
+ [COST04-BP02 Implementazione di un processo di disattivazione](cost_decomissioning_resources_implement_process.md)
+ [COST04-BP03 Disattivazione delle risorse](cost_decomissioning_resources_decommission.md)
+ [COST04-BP04 Disattivazione automatica delle risorse](cost_decomissioning_resources_decomm_automated.md)
+ [COST04-BP05 Applicare policy di conservazione dei dati](cost_decomissioning_resources_data_retention.md)

# COST04-BP01 Monitoraggio delle risorse durante il loro ciclo di vita
<a name="cost_decomissioning_resources_track"></a>

 Definisci e implementa un metodo per monitorare le risorse e le loro associazioni con i sistemi durante il loro ciclo di vita. Puoi usare l'applicazione di tag per identificare il carico di lavoro o la funzione della risorsa. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Disattiva le risorse dei carichi di lavoro che non sono più necessarie. Un esempio comune sono le risorse utilizzate per i test: dopo il completamento dei test, le risorse possono essere rimosse. La tracciabilità delle risorse con i tag (e l'esecuzione di report su tali tag) può aiutare a identificare le risorse da disattivare, poiché non saranno più in uso o la loro licenza è in scadenza. L'utilizzo dei tag è un modo efficace per monitorare le risorse: puoi etichettare la risorsa con la relativa funzione o con una data nota in cui può essere disattivata. Puoi quindi eseguire i report su questi tag. Esempi di valori per l'applicazione di tag relativi alle funzionalità sono `test funzionalità X` per identificare lo scopo della risorsa in termini di ciclo di vita del carico di lavoro. Un altro esempio è l'utilizzo di `LifeSpan` o `TTL` per le risorse, come il nome e il valore della chiave associati al tag da cancellare per definire il periodo di tempo al termine del quale deve avvenire la disattivazione o il momento specifico di tale attività. 

**Passaggi dell'implementazione**
+ **Implementa uno schema di applicazione di tag:** implementa uno schema di applicazione di tag che identifichi il carico di lavoro a cui appartiene la risorsa, verificando che tutte le risorse all'interno del carico di lavoro siano contrassegnate dai tag in modo conseguente. L'applicazione dei tag aiuta a classificare le risorse in base allo scopo, al team, all'ambiente o ad altri criteri rilevanti per l'azienda. Per maggiori dettagli sui casi d'uso, le strategie e le tecniche di applicazione dei tag, consulta [Best practice per l'applicazione dei tag in AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html).
+ ** Implementa il monitoraggio del throughput del carico di lavoro o degli output: **Implementa il monitoraggio o gli allarmi del throughput del carico di lavoro, attivandolo sulle richieste in input o sulla restituzione dei risultati in output. Configuralo per fornire notifiche quando le richieste o gli output del carico di lavoro scendono a zero, indicando che le risorse del carico di lavoro non sono più utilizzate. Incorpora un fattore temporale se il carico di lavoro scende periodicamente a zero in condizioni normali. Per maggiori dettagli sulle risorse inutilizzate o sottoutilizzate, consulta [Controllo per l'ottimizzazione dei costi di AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html).
+  **Raggruppa le risorse AWS:** Crea gruppi per le risorse AWS. Puoi utilizzare [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) per ottimizzare e gestire le tue risorse AWS che si trovano nella stessa regione Regione AWS. Puoi aggiungere tag alla maggior parte delle risorse affinché sia possibile identificarle e ordinarle all'interno dell'organizzazione. Utilizza l'[editor di tag](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) per aggiungere tag alle risorse supportate in blocco. Valuta l'utilizzo di [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/index.html) per creare, gestire e distribuire agli utenti finali portafogli di prodotti approvati e gestire il ciclo di vita del prodotto. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [Controlli per l'ottimizzazione dei costi di AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html) 
+  [Applicazione di tag alle risorse AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/Amazon/latest/monitoring/publishingMetrics.html) 

 **Video correlati:** 
+  [Come ottimizzare i costi utilizzando AWS Trusted Advisor](https://youtu.be/zcQPufNFhgg) 

 **Esempi correlati:** 
+  [Organizza le risorse AWS](https://aws.amazon.com/premiumsupport/knowledge-center/resource-groups/) 
+  [Ottimizza i costi utilizzando AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/knowledge-center/trusted-advisor-cost-optimization/) 

# COST04-BP02 Implementazione di un processo di disattivazione
<a name="cost_decomissioning_resources_implement_process"></a>

 Implementa un processo per identificare e disattivare le risorse inutilizzate. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Implementa un processo standardizzato in tutta l'organizzazione per identificare e rimuovere le risorse inutilizzate. Il processo deve definire la frequenza di esecuzione della ricerca e i processi per rimuovere la risorsa al fine di verificare che tutti i requisiti dell'organizzazione siano soddisfatti.

**Passaggi dell'implementazione**
+  **Crea e implementa un processo di disattivazione:** collabora con sviluppatori e proprietari del carico di lavoro alla creazione di un processo di disattivazione per il carico di lavoro e le relative risorse. Il processo deve includere il metodo per verificare se il carico di lavoro è in uso e quello per capire se ciascuna delle risorse del carico di lavoro è in uso. Specifica le fasi necessarie per disattivare la risorsa, rimuovendola dal servizio e garantendo allo stesso tempo la conformità a qualsiasi requisito normativo. Dovrebbero essere incluse tutte le risorse associate, come ad esempio le licenze o lo spazio di archiviazione collegato. Invia una notifica ai proprietari del carico di lavoro indicando che il processo di disattivazione è stato eseguito. 

   Utilizza i seguenti passaggi di disattivazione per guidarti su quali dovrebbero essere le verifiche eseguite come parte del processo: 
  +  **Identifica le risorse da disattivare:** identifica le risorse che sono idonee alla disattivazione all'interno dell'ambiente Cloud AWS. Registra tutte le informazioni necessarie e pianifica la disattivazione. Nella sequenza temporale, assicurati di tenere conto di eventuali problemi imprevisti e di quando si verificano durante il processo. 
  +  **Coordina e comunica:** collabora con i proprietari del carico di lavoro per confermare le risorse da disattivare 
  +  **Registra i metadati e crea i backup:** se necessario per le risorse nell'ambiente di produzione o se si tratta di risorse critiche, registra i metadati (come IP pubblici, regione, zona di disponibilità, VPC, sottorete e gruppi di sicurezza) e crea i backup (come snapshot Amazon Elastic Block Store o acquisizione di AMI, esportazione di chiavi ed esportazione di certificati). 
  +  **Valida la distribuzione come infrastructure-as-code:** determina se le risorse sono state implementate utilizzando CloudFormation, Terraform, AWS Cloud Development Kit (AWS CDK) o qualsiasi altro strumento di implementazione di infrastructure-as-code in modo che possano essere implementate di nuovo se necessario. 
  +  **Impedisci l'accesso:** applica controlli restrittivi per un certo periodo di tempo al fine di impedire l'uso delle risorse mentre determini se la risorsa è necessaria. Verifica che l'ambiente delle risorse possa essere ripristinato allo stato originale, se necessario. 
  +  **Segui il processo di disattivazione interno:** segui le attività amministrative e il processo di disattivazione dell'organizzazione, come la rimozione della risorsa dal dominio, la rimozione del record DNS e la rimozione della risorsa dagli strumenti di gestione della configurazione, di monitoraggio, di automazione e di sicurezza. 

   Se la risorsa è un'istanza Amazon EC2, consulta l'elenco seguente. [Per ulteriori dettagli, consulta In che modo è possibile eliminare o terminare le risorse di Amazon EC2?](https://aws.amazon.com/premiumsupport/knowledge-center/delete-terminate-ec2/) 
  +  Arresta o termina tutte le tue istanze Amazon EC2 e i sistemi di bilanciamento del carico. Per un breve periodo dopo la loro eliminazione le istanze Amazon EC2 continuano a essere visibili nella console. Non verrà addebitato alcun costo per le istanze che non si trovano in stato di esecuzione 
  +  Elimina l'infrastruttura Auto Scaling. 
  +  Rilascia tutti gli host dedicati. 
  +  Elimina tutti i volumi e gli snapshot Amazon EBS. 
  +  Rilascia tutti gli Indirizzi IP elastici. 
  +  Annulla la registrazione di tutte le Amazon Machine Image (AMI). 
  +  Terminata tutti gli ambienti AWS Elastic Beanstalk. 

   Se la risorsa è un oggetto in uno spazio di archiviazione Amazon Glacier e se si elimina un archivio prima di aver raggiunto la durata minima di archiviazione, verrà addebitato un costo di eliminazione anticipata proporzionale. La durata minima di archiviazione di Amazon Glacier dipende dalla classe di archiviazione utilizzata. Per un riepilogo della durata minima di archiviazione per ciascuna classe di archiviazione, consulta [Prestazioni delle classi di archiviazione Amazon S3](https://aws.amazon.com/s3/storage-classes/?nc=sn&loc=3#Performance_across_the_S3_Storage_Classes). Per informazioni dettagliate sulle modalità di calcolo delle tariffe di cancellazione anticipata, consulta [Prezzi di Amazon S3](https://aws.amazon.com/s3/pricing/). 

 Il seguente semplice diagramma di flusso del processo di disattivazione illustra le fasi della disattivazione. Prima di disattivare le risorse, verifica che le risorse identificate per la disattivazione non siano utilizzate dall'organizzazione. 

![\[Flow chart depicting the steps of decommissioning a resource.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/decommissioning-process-flowchart.png)


## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 

 **Video correlati:** 
+  [Cancella lo stack CloudFormation ma mantieni alcune risorse](https://www.youtube.com/watch?v=bVmsS8rjuwk) 
+  [Scopri quale utente ha avviato l'istanza Amazon EC2](https://www.youtube.com/watch?v=SlyAHc5Mv2A) 

 **Esempi correlati:** 
+  [Elimina o termina le risorse Amazon EC2](https://aws.amazon.com/premiumsupport/knowledge-center/delete-terminate-ec2/) 
+  [Scopri quale utente ha avviato l'istanza Amazon EC2](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-user-launched-instance/) 

# COST04-BP03 Disattivazione delle risorse
<a name="cost_decomissioning_resources_decommission"></a>

 Disattivazione delle risorse attivate da eventi come audit periodici o modifiche relative all'utilizzo. La disattivazione viene in genere eseguita periodicamente e può essere manuale o automatizzata. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

La frequenza e lo sforzo di ricerca delle risorse inutilizzate dovrebbero riflettere i risparmi potenziali, pertanto un account con costi contenuti deve essere analizzato con una frequenza minore rispetto a un account che ha costi maggiori. Gli eventi di ricerca e disattivazione possono essere attivati da modifiche di stato nel carico di lavoro, ad esempio il termine del ciclo di vita di un prodotto o la sua sostituzione. Le ricerche e gli eventi di disattivazione possono anche essere attivati da eventi esterni, ad esempio cambiamenti nelle condizioni di mercato o cessazione del prodotto.

**Passaggi dell'implementazione**
+  **Disattivazione delle risorse: **si tratta della fase di disattivazione delle risorse AWS non più necessarie o del termine di un contratto di licenza. Completa tutti i controlli finali prima di passare alla fase di dismissione e disattivazione delle risorse per evitare interruzioni indesiderate durante fasi come l'esecuzione di snapshot o backup. Utilizzando il processo di disattivazione, disattiva tutte le risorse identificate come inutilizzate.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 

 **Esempi correlati:** 
+  [ Well-Architected Labs: disattivazione delle risorse (Livello 100) ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/) 

# COST04-BP04 Disattivazione automatica delle risorse
<a name="cost_decomissioning_resources_decomm_automated"></a>

 Progetta il tuo carico di lavoro in modo da gestire in modo controllato la disattivazione delle risorse, identificando e disattivando le risorse non critiche, le risorse non necessarie o quelle a basso utilizzo. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Utilizza l'automazione per ridurre o rimuovere i costi associati al processo di ritiro. Progettare il carico di lavoro per eseguire automaticamente la disattivazione ridurrà i costi complessivi del carico di lavoro durante il suo ciclo di vita. Per eseguire il processo di disattivazione puoi utilizzare [AWS Auto Scaling](https://aws.amazon.com/autoscaling/). Puoi anche implementare un codice personalizzato utilizzando [l'API o l'SDK](https://aws.amazon.com/developer/tools/) per disattivare automaticamente le risorse associate a un carico di lavoro.

 Le [applicazioni moderne](https://aws.amazon.com/modern-apps/) sono sviluppate in modalità serverless-first, una strategia che dà priorità all'adozione di servizi serverless. AWS ha sviluppato [servizi serverless](https://aws.amazon.com/serverless/) per tutti e tre i livelli dello stack: calcolo, integrazione e memorizzazione dei dati. L'utilizzo di un'architettura serverless consente di risparmiare sui costi nei periodi di scarso traffico e di approfittare del dimensionamento automatico. 

**Passaggi dell'implementazione**
+ ** Implementa AWS Auto Scaling: **nel caso delle risorse che sono supportate, configurale con [AWS Auto Scaling](https://aws.amazon.com/autoscaling/). AWS Auto Scaling può aiutarti a ottimizzare l'utilizzo e l'efficienza dei costi durante l'utilizzo dei servizi AWS. Quando la domanda diminuisce, AWS Auto Scaling rimuove automaticamente la capacità di risorse in eccesso per evitare spese inutili.
+ ** Configura CloudWatch per la terminazione delle istanze:** le istanze possono essere configurate affinché terminino in base agli [allarmi CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingTerminateActions). Utilizzando i parametri del processo di disattivazione, implementa un allarme con un'operazione Amazon Elastic Compute Cloud. Verifica l'operazione in un ambiente non di produzione prima di eseguire il roll out. 
+  **Implementa il codice all'interno del carico di lavoro** per disattivare le risorse associate al carico di lavoro puoi utilizzare l'SDK AWS o la AWS CLI. Implementa il codice all'interno dell'applicazione che si integra con AWS e termina o rimuove le risorse che non vengono più utilizzate. 
+  **Utilizza servizi serverless:** per compilare ed eseguire le tue applicazioni dai la priorità allo sviluppo di [architetture serverless](https://aws.amazon.com/serverless/) e [architetture basate su eventi](https://aws.amazon.com/event-driven-architecture/) su AWS. AWS offre diversi servizi basati su tecnologie serverless che offrono un utilizzo intrinsecamente ottimizzato delle risorse e la disattivazione automatizzata (riduzione e incremento orizzontali). Con le applicazioni serverless, l'utilizzo delle risorse viene ottimizzato automaticamente e non si paga mai il provisioning in eccesso. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [Serverless su AWS](https://aws.amazon.com/serverless/) 
+  [Crea allarmi per arrestare, terminare, riavviare o recuperare un'istanza](https://docs.aws.amazon.com/Amazon/latest/monitoring/UsingAlarmActions.html) 
+  [Nozioni di base su Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Aggiungi le operazioni di terminazione agli allarmi Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingTerminateActions) 

 **Esempi correlati:** 
+  [Pianificazione della cancellazione automatica degli stack AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/scheduling-automatic-deletion-of-aws-cloudformation-stacks/) 
+  [ Well-Architected Labs: disattivazione delle risorse (Livello 100)](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/) 
+  [Pulizia automatica su AWS di Servian](https://github.com/servian/aws-auto-cleanup) 

# COST04-BP05 Applicare policy di conservazione dei dati
<a name="cost_decomissioning_resources_data_retention"></a>

 Definisci le policy di conservazione dei dati su risorse supportate per gestire l'eliminazione degli oggetti in base ai requisiti della tua organizzazione. Identifica ed elimina risorse non necessarie oppure orfane e oggetti non più richiesti. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

 Usa le policy di conservazione dei dati e del ciclo di vita per ridurre i costi associati al processo di disattivazione e i costi di archiviazione per le risorse identificate. La definizione delle policy di conservazione dei dati e del ciclo di vita per eseguire l'eliminazione e la migrazione di classi di archiviazione automatizzate contribuirà a ridurre i costi di archiviazione generale durante la sua durata. Si può usare Amazon Data Lifecycle Manager per automatizzare la creazione e l'eliminazione di snapshot Amazon Elastic Block Store e Amazon Machine Images (AMI) supportate da Amazon EBS e usare Amazon S3 Intelligent-Tiering o una configurazione del ciclo di vita Amazon S3 per gestire il ciclo di vita dei tuoi oggetti Amazon S3. È possibile anche implementare un codice personalizzato utilizzando un'[API o un SDK](https://aws.amazon.com/tools/) per creare policy del ciclo di vita e regole di policy per oggetti da eliminare automaticamente. 

 **Passaggi dell'implementazione** 
+  **Usa Amazon Data Lifecycle Manager:** usa policy del ciclo di vita su Amazon Data Lifecycle Manager per automatizzare l'eliminazione di snapshot Amazon EBS e AMI supportate da Amazon EBS. 
+  **Imposta la configurazione del ciclo di vita su un bucket:** usa la configurazione del ciclo di vita di Amazon S3 su un bucket per definire le azioni che Amazon S3 deve intraprendere durante il ciclo di vita di un oggetto, oltre all'eliminazione alla fine del ciclo di vita di un oggetto, in base ai requisiti aziendali. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/dlm/?icmpid=docs_homepage_mgmtgov) 
+  [Come impostare la configurazione del ciclo di vita su un bucket Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html) 

 **Video correlati:** 
+  [Automatizzare gli snapshot Amazon EBS con Amazon Data Lifecycle Manager](https://www.youtube.com/watch?v=RJpEjnVSdi4) 
+  [Svuotare un bucket Amazon S3 con una regola di configurazione del ciclo di vita](https://www.youtube.com/watch?v=JfK9vamen9I) 

 **Esempi correlati:** 
+  [Svuotare un bucket Amazon S3 con una regola di configurazione del ciclo di vita](https://aws.amazon.com/premiumsupport/knowledge-center/s3-empty-bucket-lifecycle-rule/) 
+  [ Well-Architected Labs: disattivazione automatica delle risorse (Livello 100)](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/) 

# Risorse a costi contenuti
<a name="a-cost-effective-resources"></a>

**Topics**
+ [COST 5. In che modo valuti i costi quando selezioni i servizi?](cost-05.md)
+ [COST 6. In che modo raggiungi gli obiettivi di costo quando selezioni il tipo, le dimensioni e il numero delle risorse?](cost-06.md)
+ [COST 7. In che modo impieghi i modelli di prezzo per ridurre i costi?](cost-07.md)
+ [COST 8. In che modo pianifichi i costi per il trasferimento dei dati?](cost-08.md)

# COST 5. In che modo valuti i costi quando selezioni i servizi?
<a name="cost-05"></a>

Amazon EC2, Amazon EBS e Amazon S3 sono servizi AWS di base. I servizi gestiti, come Amazon RDS e Amazon DynamoDB, sono servizi AWS di livello superiore o applicativo. Selezionando i blocchi predefiniti e i servizi gestiti appropriati, è possibile ottimizzare questo carico di lavoro per i costi. Ad esempio, utilizzando i servizi gestiti, puoi ridurre o eliminare gran parte dei costi generali amministrativi e operativi, liberandotene per lavorare su applicazioni e attività correlate al tuo business.

**Topics**
+ [COST05-BP01 Identificazione dei requisiti dell'organizzazione sui costi](cost_select_service_requirements.md)
+ [COST05-BP02 Analisi di tutti i componenti del carico di lavoro](cost_select_service_analyze_all.md)
+ [COST05-BP03 Esecuzione di un'analisi accurata di ciascun componente](cost_select_service_thorough_analysis.md)
+ [COST05-BP04 Selezione di software con licenze convenienti](cost_select_service_licensing.md)
+ [COST05-BP05 Selezione dei componenti del carico di lavoro per ottimizzare i costi in linea con le priorità dell'organizzazione](cost_select_service_select_for_cost.md)
+ [COST05-BP06 Esecuzione di un'analisi dei costi per diversi valori di utilizzo nel tempo](cost_select_service_analyze_over_time.md)

# COST05-BP01 Identificazione dei requisiti dell'organizzazione sui costi
<a name="cost_select_service_requirements"></a>

 Lavora con i membri del team per definire il bilanciamento tra l'ottimizzazione dei costi e altri pilastri, come le prestazioni e l'affidabilità, per questo carico di lavoro. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Nella maggior parte delle organizzazioni, il reparto di tecnologia dell'informazione (IT) è composto da diversi team di piccole dimensioni, ciascuno con una propria agenda e area di interesse, che riflettono le specializzazioni e le competenze dei suoi membri. È necessario comprendere gli obiettivi, le priorità e le finalità generali dell'organizzazione e in che modo ogni reparto o progetto contribuisce a tali obiettivi. La catalogazione di tutte le risorse essenziali, inclusi personale, attrezzature, tecnologia, materiali e servizi esterni, è fondamentale per il raggiungimento degli obiettivi organizzativi e una pianificazione precisa del budget. L'adozione di questo approccio sistematico all'identificazione e alla comprensione dei costi è fondamentale per stabilire un piano dei costi realistico e affidabile per l'organizzazione. 

 al momento di selezionare i servizi per un carico di lavoro, è fondamentale comprendere le priorità dell'organizzazione. Assicurati che vi sia equilibrio tra i costi e gli altri pilastri del Framework AWS Well-Architected, ad esempio prestazioni e affidabilità. È necessario eseguire questo processo sistematicamente e regolarmente in modo da acquisire i cambiamenti a livello di obiettivi, condizioni di mercato e dinamiche operative dell'organizzazione. Un carico di lavoro completamente ottimizzato per i costi è la soluzione più in linea con i requisiti della tua organizzazione, e non necessariamente quella con il costo più basso. Per raccogliere il maggior numero di informazioni, interpella tutti i team all'interno dell'organizzazione, come i team dedicati ai prodotti, di business, tecnici e finanziari. Valuta l'impatto dei compromessi tra interessi concorrenti o approcci alternativi, per aiutare a prendere decisioni informate quando si stabilisce dove concentrare le attività o scegliere una linea di azione. 

 Ad esempio, accelerare l'introduzione sul mercato di nuove funzionalità può essere preferibile all'ottimizzazione dei costi. Oppure, è possibile scegliere un database relazionale per i dati non relazionali per semplificare la migrazione di un sistema, anziché migrare a un database ottimizzato per il tuo tipo di dati e aggiornare l'applicazione. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+ **Identifica i requisiti dell'organizzazione sui costi:** organizza riunioni con i membri dei team della tua organizzazione, tra cui i team di gestione dei prodotti, i team proprietari delle applicazioni, i team operativi e di sviluppo, i team di gestione e finanziari. Dai la priorità ai pilastri Well-Architected per questo carico di lavoro e i relativi componenti. L'output dovrebbe essere un elenco ordinato dei pilastri. Puoi anche aggiungere un fattore di ponderazione a ciascun pilastro per indicare il livello di attenzione aggiuntiva assegnato o quanto è simile il livello di attenzione assegnato a due pilastri.
+  **Analizza il debito tecnico e documentalo: ** durante la revisione del carico di lavoro, analizza il debito tecnico. Documenta gli elementi lasciati in sospeso per riesaminare il carico di lavoro in un secondo momento, con l'obiettivo di rifattorizzarlo o riprogettarlo per ottimizzarlo ulteriormente. Alle altre parti interessate è fondamentale comunicare in modo chiaro le scelte di compromesso adottate. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [REL11-BP07 Progettazione del prodotto in modo da soddisfare gli obiettivi di disponibilità e i contratti sul livello di servizio per i tempi di attività](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_service_level_agreements.html)
+ [OPS01-BP06 Valutazione dei compromessi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)

 **Documenti correlati:** 
+  [Calcolatore del costo totale di proprietà (TCO) di AWS](https://aws.amazon.com/tco-calculator/) 
+  [Classi di archiviazione di Amazon S3](https://aws.amazon.com/s3/storage-classes/) 
+  [Prodotti cloud](https://aws.amazon.com/products/) 

# COST05-BP02 Analisi di tutti i componenti del carico di lavoro
<a name="cost_select_service_analyze_all"></a>

 Verifica che ogni componente del carico di lavoro venga analizzato, indipendentemente dalle dimensioni attuali o dai costi correnti. L'attività di revisione deve riflettere i potenziali benefici, come i costi correnti e quelli previsti. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I componenti del carico di lavoro, progettati per fornire valore aziendale all'organizzazione, possono includere vari servizi. Per ogni componente, è possibile scegliere servizi Cloud AWS specifici per soddisfare specifiche esigenze aziendali. Questa selezione potrebbe essere influenzata da fattori quali la familiarità o l'esperienza precedente nell'uso di questi servizi. 

 Dopo aver identificato i requisiti dell'organizzazione (come indicato in [COST05-BP01 Identificazione dei requisiti dell'organizzazione sui costi](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_select_service_requirements.html), esegui un'analisi approfondita di tutti i componenti del carico di lavoro. Analizza ogni componente considerando i costi e le dimensioni attuali e previsti. Considera il costo dell'analisi rispetto a qualsiasi potenziale risparmio del carico di lavoro durante il suo ciclo di vita. L'impegno dedicato all'analisi di tutti i componenti di questo carico di lavoro dovrebbe corrispondere al potenziale risparmio o ai miglioramenti previsti derivanti dall'ottimizzazione del componente specifico. Ad esempio, se il costo della risorsa proposta è di 10 USD al mese e sotto i carichi previsti non supererà i 15 USD al mese, la spesa di una giornata di impegno per ridurre i costi del 50% (5 USD al mese) potrebbe superare il potenziale vantaggio per tutta la durata del sistema. L'utilizzo di una stima basata sui dati, più rapida ed efficiente, fornisce il migliore risultato complessivo per questo componente. 

 I carichi di lavoro possono cambiare nel corso del tempo e il giusto set di servizi potrebbe non essere ottimale se l'architettura o l'utilizzo del carico di lavoro cambiano. L'analisi per la selezione dei servizi deve integrare gli stati del carico di lavoro e i livelli di utilizzo attuali e futuri. Implementare un servizio in funzione dello stato o dell'utilizzo futuro del carico di lavoro può ridurre i costi complessivi, riducendo o rimuovendo lo sforzo necessario per apportare modifiche future. Ad esempio, l'utilizzo di Amazon EMR Serverless potrebbe essere inizialmente la scelta appropriata. Tuttavia, con l'aumento del consumo del servizio, il passaggio a Amazon EMR in Amazon EC2 potrebbe ridurre i costi per il componente specifico del carico di lavoro. 

 La revisione strategica di tutti i componenti del carico di lavoro, indipendentemente dalle loro caratteristiche attuali, ha il potenziale di generare notevoli miglioramenti e risparmi finanziari nel tempo. L'impegno dedicato in questo processo di revisione dovrebbe essere programmato, con un'attenta considerazione dei potenziali vantaggi che potrebbero essere realizzati. 

 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) e [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) (CUR) possono analizzare i costi di un proof of concept (PoC) o di un ambiente in esecuzione. Puoi anche utilizzare [Calcolatore dei prezzi AWS](https://calculator.aws/#/) per stimare i costi del carico di lavoro. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Elenca i componenti del carico di lavoro:** crea un elenco dei componenti del carico di lavoro. Tale elenco viene utilizzato come verifica per controllare che ogni componente sia stato analizzato. Gli sforzi sostenuti devono riflettere la criticità del carico di lavoro secondo quanto definito dalle priorità dell'organizzazione. Raggruppare le risorse in modo funzionale, ad esempio in base all'archiviazione del database di produzione, migliora l'efficienza se sono presenti più database. 
+  **Assegna le priorità all'elenco dei componenti:** assegna ai componenti in elenco una priorità in base all'impegno che richiedono. Tale assegnazione viene in genere eseguita in ordine dal componente più costoso a quello meno costoso o in base alla criticità definita dalle priorità dell'organizzazione.
+ **Esegui l'analisi:** per ogni componente dell'elenco, esamina le opzioni e i servizi disponibili e scegli l'opzione che si allinea meglio alle priorità dell'organizzazione.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Calcolatore dei prezzi AWS](https://calculator.aws/#/) 
+  [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 
+  [Classi di archiviazione di Amazon S3](https://aws.amazon.com/s3/storage-classes/) 
+  [Prodotti cloud](https://aws.amazon.com/products/) 

# COST05-BP03 Esecuzione di un'analisi accurata di ciascun componente
<a name="cost_select_service_thorough_analysis"></a>

 Considera il costo complessivo per l'organizzazione di ogni componente. Considera il costo totale di proprietà tenendo conto dei costi operativi e di gestione, soprattutto quando si utilizzano i servizi gestiti del provider cloud. L'attività di revisione deve riflettere i potenziali benefici (ad esempio il tempo speso per l'analisi dovrebbe essere proporzionale al costo dei componenti). 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Si consideri tempo risparmiato, che consentirà al proprio team di concentrarsi sull'eliminazione del debito tecnico, sull'innovazione e sulle funzionalità che offrono un valore aggiunto e sullo sviluppo di ciò che diversifica il business. Ad esempio, si potrebbe avere la necessità di eseguire il rehosting (lift and shift) del proprio database dall’ambiente on-premise nel cloud il più rapidamente possibile ed eseguire l'ottimizzazione in un secondo momento. Vale la pena soffermarsi sul risparmio possibile che puoi ottenere usando i servizi gestiti su AWS che rimuovono o riducono i costi di licenza. I servizi gestiti su AWS eliminano l'onere operativo e amministrativo legato alla manutenzione di un servizio, come l'applicazione di patch o l'aggiornamento del sistema operativo, consentendoti di concentrarti sull'innovazione e sul business. 

 Dato che i servizi gestiti operano su scala cloud, possono offrire un costo inferiore per transazione o servizio. Questo vuol dire fare alcune ottimizzazioni potenziali in modo da ottenere benefici tangibili, senza modificare l'architettura principale dell'applicazione. Ad esempio, si potrebbe voler ridurre il tempo dedicato alla gestione delle istanze di database migrando verso una piattaforma di database-as-a-service come [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) o migrando la propria applicazione a una piattaforma completamente gestita come [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/). 

Solitamente, i servizi gestiti presentano attributi che si possono impostare per garantire la capacità necessaria. Devi impostare e monitorare questi attributi in modo che la tua capacità in eccesso sia mantenuta al minimo e le prestazioni siano massimizzate. Puoi modificare gli attributi di AWS Managed Services utilizzando la Console di gestione AWS o le API e gli SDK AWS per allineare le risorse necessarie con le variazioni della domanda. Ad esempio, puoi aumentare o diminuire il numero di nodi di un cluster Amazon EMR (o di un cluster Amazon Redshift) per ridimensionarlo.

Puoi anche unire più istanze in una risorsa AWS per ottenere una densità di utilizzo più elevata. Ad esempio, puoi effettuare il provisioning di diversi database più piccoli su una singola istanza database Amazon Relational Database Service (Amazon RDS). Quando l'utilizzo si intensifica, puoi migrare uno dei database su un'istanza database Amazon RDS dedicata utilizzando un processo di generazione dello snapshot e ripristino.

Quando predisponi carichi di lavoro su servizi gestiti, devi comprendere i requisiti inerenti alla modifica della capacità del servizio. Tali requisiti solitamente riguardano il tempo, l'impegno e qualunque impatto sul normale funzionamento del carico di lavoro. La risorsa predisposta deve offrire il tempo necessario per l'applicazione delle modifiche, pertanto procurati i mezzi necessari a tal fine. L'impegno costante richiesto per modificare i servizi può essere ridotto praticamente a zero grazie alle API e agli SDK integrati con strumenti di sistema e di monitoraggio come Amazon CloudWatch.

[Amazon RDS](https://aws.amazon.com/rds/), [Amazon Redshift](https://aws.amazon.com/redshift/), e [Amazon ElastiCache](https://aws.amazon.com/elasticache/) offrono un servizio di database gestito. [Amazon Athena](https://aws.amazon.com/athena/), [Amazon EMR](https://aws.amazon.com/emr/) e [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) offrono un servizio di analisi gestito.

[AMS](https://aws.amazon.com/managed-services/) è un servizio che gestisce l'infrastruttura AWS per conto di clienti e partner aziendali. Offre un ambiente sicuro e conforme su cui è possibile implementare i carichi di lavoro. AMS utilizza modelli operativi cloud aziendali dotati di automazione per consentirti di soddisfare i requisiti aziendali, di passare più rapidamente al cloud e di ridurre i costi di gestione correnti.

**Passaggi dell'implementazione**
+ ** Esegui un'analisi completa: **utilizzando l'elenco dei componenti, analizza ogni componente dalla priorità più alta alla priorità più bassa. Per la priorità più alta e i componenti più costosi, esegui analisi aggiuntive e valuta tutte le opzioni disponibili e il loro impatto a lungo termine. Per i componenti con priorità più bassa, valuta se le modifiche relative all'utilizzo hanno un impatto sulla priorità del componente, quindi esegui un'analisi dello sforzo appropriato. 
+  **Confronta risorse gestite e non gestite:** considera i costi operativi delle risorse che gestisci e confrontali con quelli delle risorse gestite AWS. Ad esempio, rivedi i tuoi database in esecuzione su istanze Amazon EC2 e confrontali con le opzioni Amazon RDS (un servizio gestito AWS) o Amazon EMR paragonato all'esecuzione di Apache Spark su Amazon EC2. Quando si passa da un carico di lavoro autogestito a un carico di lavoro AWS completamente gestito, esamina attentamente le tue opzioni. I tre fattori più importanti da considerare sono il [tipo di servizio gestito](https://aws.amazon.com/products/?&aws-products-all.q=managed) che vuoi usare, il processo che userai per [migrare i tuoi dati](https://aws.amazon.com/big-data/datalakes-and-analytics/migrations/) e comprendere il [AWS modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Calcolatore del costo totale di proprietà (TCO) di AWS](https://aws.amazon.com/tco-calculator/) 
+  [Classi di archiviazione di Amazon S3](https://aws.amazon.com/s3/storage-classes/) 
+  [Prodotti Cloud AWS](https://aws.amazon.com/products/) 
+ [ Modello di responsabilità condivisa AWS](https://aws.amazon.com/compliance/shared-responsibility-model/)

 **Video correlati:** 
+ [ Perché passare a un database gestito? ](https://www.youtube.com/watch?v=VRFdc-MVa4I)
+ [ Che cos'è Amazon EMR e come posso usarlo per elaborare i dati? ](https://www.youtube.com/watch?v=jylp2atrZjc)

 **Esempi correlati:** 
+ [ Perché passare a un database gestito ](https://aws.amazon.com/getting-started/hands-on/move-to-managed/why-move-to-a-managed-database/)
+ [ Consolida i dati da database SQL Server identici in un unico database Amazon RDS for SQL Server con AWS DMS](https://aws.amazon.com/blogs/database/consolidate-data-from-identical-sql-server-databases-into-a-single-amazon-rds-for-sql-server-database-using-aws-dms/)
+ [ Distribuisci i dati su scala su Amazon Managed Streaming for Apache Kafka (Amazon MSK) ](https://aws.amazon.com/getting-started/hands-on/deliver-data-at-scale-to-amazon-msk-with-iot-core/?ref=gsrchandson)
+ [ Migra un'applicazione Web ASP.NET su AWS Elastic Beanstalk](https://aws.amazon.com/getting-started/hands-on/migrate-aspnet-web-application-elastic-beanstalk/?ref=gsrchandson&id=itprohandson)

# COST05-BP04 Selezione di software con licenze convenienti
<a name="cost_select_service_licensing"></a>

 Il software open source elimina i costi di licenza del software, che contribuiscono in modo significativo ai costi dei carichi di lavoro. Nei casi in cui il software con licenza sia obbligatorio, evita le licenze legate ad attributi arbitrari, ad esempio CPU, e cerca le licenze legate all'output o ai risultati. Il costo di queste licenze si ridimensiona in base ai vantaggi che offrono. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Il concetto di open source è nato nel contesto dello sviluppo del software per indicare che il software è conforme a determinati criteri di distribuzione gratuita. Il software open source è composto da codice sorgente che chiunque può analizzare, modificare e migliorare. In base ai requisiti aziendali, alle competenze professionali, all'utilizzo previsto o ad altre dipendenze tecnologiche, le organizzazioni possono prendere in considerazione l'utilizzo di software open source in AWS per ridurre al minimo i costi di licenza. In altre parole, utilizzando [software open source](https://aws.amazon.com/what-is/open-source/) è possibile eliminare il costo delle licenze software. Con l'aumentare delle dimensioni del carico di lavoro, l'impatto sui costi può essere significativo. 

 Misura i vantaggi di usare software con licenza in rapporto ai costi totali per ottimizzare il carico di lavoro. Crea modelli per le eventuali modifiche alla licenza e il relativo impatto sui costi del carico di lavoro. Se un fornitore modifica il costo della licenza del database, valuta come questo incide sull'efficienza complessiva del carico di lavoro. Effettua un'analisi dello storico dei prezzi dei tuoi fornitori per scoprire le tendenze dei cambiamenti relativi alle licenze dei loro prodotti. I costi delle licenze possono anche essere adattati indipendentemente dal throughput o dall'utilizzo, come nel caso delle licenze che si adattano in base all'hardware (licenze legate alla CPU). È necessario evitare queste licenze poiché i costi possono aumentare rapidamente senza che vi siano vantaggi correlati. 

 Ad esempio, l'utilizzo di un'istanza Amazon EC2 in us-east-1 con un sistema operativo Linux consente di ridurre i costi di circa il 45% rispetto all'esecuzione di un'altra istanza Amazon EC2 eseguita su Windows. 

 [Calcolatore dei prezzi AWS](https://calculator.aws/) offre un modo completo per confrontare i costi di varie risorse con diverse opzioni di licenza, come le istanze Amazon RDS e diversi motori di database. Inoltre, AWS Cost Explorer fornisce un punto di vista impareggiabile per i costi dei carichi di lavoro esistenti, in particolare quelli derivanti da licenze diverse. Per la gestione delle licenze, [AWS License Manager](https://aws.amazon.com/license-manager) offre un metodo semplificato per supervisionare e gestire le licenze software. I clienti possono implementare e rendere operativo il loro software open source preferito nel Cloud AWS. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+ **Analizza le opzioni di licenza:** rivedi i termini di licenza del software disponibile. Cerca le versioni open source che dispongono delle funzionalità necessarie e considera se i vantaggi del software con licenza superano i costi. Condizioni convenienti possono rendere il costo del software proporzionato ai vantaggi che offre.
+ **Analizza il fornitore del software:** esamina tutte le modifiche ai prezzi o alle licenze apportate dal fornitore. Identifica eventuali modifiche non allineate ai risultati, ad esempio termini punitivi per l'esecuzione su hardware o piattaforme di fornitori specifici. Inoltre, verifica il modo in cui vengono eseguiti gli audit e le sanzioni in cui potresti incorrere.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Open Source at AWS](https://aws.amazon.com/opensource/)
+  [Calcolatore del costo totale di proprietà (TCO) di AWS](https://aws.amazon.com/tco-calculator/) 
+  [Classi di archiviazione di Amazon S3](https://aws.amazon.com/s3/storage-classes/) 
+  [Prodotti cloud](https://aws.amazon.com/products/) 

 **Esempi correlati:** 
+ [Blog relativi all'open source](https://aws.amazon.com/blogs/opensource/)
+ [Blog relativi all'open source AWS](https://aws.github.io/)
+ [Optimization and Licensing Assessment](https://aws.amazon.com/optimization-and-licensing-assessment/)

# COST05-BP05 Selezione dei componenti del carico di lavoro per ottimizzare i costi in linea con le priorità dell'organizzazione
<a name="cost_select_service_select_for_cost"></a>

 Tieni in considerazione il costo nella selezione di tutti i componenti del tuo carico di lavoro. Ciò include l'utilizzo di servizi a livello di applicazione e servizi gestiti o serverless, container o un'architettura basata sugli eventi per ridurre i costi complessivi. Riduci al minimo i costi di licenza utilizzando software open source, software che non hanno costi di licenza o altre alternative per contenere la spesa. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Quando si selezionano tutti i componenti, è necessario considerare il costo dei servizi e delle opzioni. Questo include l'utilizzo di servizi gestiti e a livello di applicazione, come [Amazon Relational Database Service](https://aws.amazon.com/rds/) (Amazon RDS), [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS) e [Amazon Simple Email Service](https://aws.amazon.com/ses/) (Amazon SES) per ridurre il costo complessivo dell'organizzazione. 

 Utilizza funzioni serverless e container per l'elaborazione, come [AWS Lambda](https://aws.amazon.com/lambda/) e [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) per i siti web statici. Se possibile, containerizza la tua applicazione e utilizza servizi di container gestiti di AWS come [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (Amazon ECS) oppure [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) (Amazon EKS). 

 Riduci al minimo i costi di licenza utilizzando software open source o software che non prevedono tariffe di licenza, come ad esempio Amazon Linux per carichi di lavoro di calcolo, oppure esegui la migrazione dei database su Amazon Aurora. 

 puoi utilizzare servizi serverless o a livello di applicazione, ad esempio [Lambda](https://aws.amazon.com/lambda/), [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/), [Amazon SNS](https://aws.amazon.com/sqs/)e [Amazon SES](https://aws.amazon.com/ses/). Questi servizi eliminano la necessità di gestire una risorsa e forniscono funzioni di esecuzione del codice, servizi di accodamento e consegna dei messaggi. L'altro vantaggio è che le prestazioni e i costi vengono adattati in base all'utilizzo, garantendo l'allocazione e l'attribuzione dei costi in modo efficiente. 

 Utilizzando [un'architettura basata su eventi](https://aws.amazon.com/what-is/eda/) è possibile anche con servizi serverless. Le architetture basate su eventi funzionano su base push, per cui tutto succede on demand quando l'evento si presenta sul router. In questo modo non devi sostenere i costi di un continuo polling per verificare un evento. Ciò significa minor consumo di larghezza di banda della rete, minor utilizzo della CPU, minor capacità di parco istanze inattiva e minor numero di handshake SSL/TLS. 

 Per ulteriori informazioni sul serverless, consultare [whitepaper di approfondimento sulle applicazioni serverless secondo il Canone di architettura.](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html) 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Seleziona ciascun servizio per ottimizzare i costi:** Utilizzando l'elenco e l'analisi prioritari, seleziona ogni opzione che fornisce la migliore corrispondenza con le priorità dell'organizzazione. Invece di aumentare la capacità per soddisfare la domanda, prendi in considerazione altre opzioni che potrebbero offrirti performance migliori a costi inferiori. Ad esempio, è necessario rivedere il traffico previsto per i database su AWS e prendere in considerazione la possibilità di aumentare le dimensioni dell'istanza o di utilizzare servizi Amazon ElastiCache (Redis o Memcached) per fornire meccanismi di cache per i database. 
+  **Valuta l'architettura basata sugli eventi:** l'utilizzo dell'architettura serverless consente inoltre di costruire un'architettura basata sugli eventi per applicazioni distribuite basate su microservizi, che aiuta a costruire soluzioni scalabili, resilienti, agili ed economiche. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Calcolatore del costo totale di proprietà (TCO) di AWS](https://aws.amazon.com/tco-calculator/) 
+  [AWS Serverless](https://aws.amazon.com/serverless/) 
+  [In cosa consiste l'architettura basata su eventi](https://aws.amazon.com/what-is/eda/) 
+  [Classi di archiviazione di Amazon S3](https://aws.amazon.com/s3/storage-classes/) 
+  [Prodotti cloud](https://aws.amazon.com/products/) 
+  [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis) 

 **Esempi correlati:** 
+  [Getting started with event-driven architecture](https://aws.amazon.com/blogs/compute/getting-started-with-event-driven-architecture/) 
+  [Architettura basata su eventi](https://aws.amazon.com/event-driven-architecture/) 
+  [How Statsig runs 100x more cost-effectively using Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/database/how-statsig-runs-100x-more-cost-effectively-using-amazon-elasticache-for-redis/) 
+  [Best practices for working with AWS Lambda functions](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) 

# COST05-BP06 Esecuzione di un'analisi dei costi per diversi valori di utilizzo nel tempo
<a name="cost_select_service_analyze_over_time"></a>

 I carichi di lavoro possono cambiare nel corso del tempo. Alcuni servizi o funzionalità sono più convenienti a diversi livelli di utilizzo. Eseguendo l'analisi su ogni componente nel tempo e all'utilizzo previsto, il carico di lavoro rimane conveniente per tutta la sua durata. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Quando AWS rilascia nuovi servizi e funzionalità, è possibile che i servizi ottimali per il carico di lavoro cambino. Tale cambiamento comporta un impegno, che dovrebbe essere commensurato ai vantaggi potenziali. La frequenza di revisione del carico di lavoro dipende dai requisiti dell'organizzazione. Se si tratta di un carico di lavoro con costi importanti, una rapida implementazione dei nuovi servizi massimizzerà i risparmi sui costi, e in tal caso una revisione più frequente può risultare vantaggiosa. Un altro stimolo importante per la revisione è il cambiamento dei modelli di utilizzo. Se si verificassero notevoli cambiamenti nell'utilizzo, ciò potrebbe indicare un maggiore vantaggio dei servizi alternativi.

 Se si ha bisogno di trasferire i dati nel Cloud AWS è possibile scegliere i numerosi servizi offerti da AWS e gli strumenti dei partner per avere un supporto nella migrazione dei tuoi set di dati, sia che si tratti di file, database, immagini di macchine, volumi a blocchi o persino backup su nastro. Ad esempio, per spostare grandi quantità di dati da e verso AWS o elaborare dati in posizioni edge è possibile usare uno dei dispositivi AWS dedicati per migrare, in modo contenuto nei costi, petabyte di dati offline. Un altro esempio: per velocità di trasferimento dei dati più elevate, un servizio di connessione diretta può risultare più economico di una VPN e garantire la connettività coerente richiesta per la tua attività. 

 In base all'analisi dei costi per usi diversi nel tempo, rivedi le tue attività di dimensionamento. Analizza i risultati per vedere se la policy di dimensionamento può essere ottimizzata per aggiungere istanze con tipi di istanze e opzioni di acquisto diversi. Esamina le tue impostazioni per vedere se il minimo può essere ridotto per soddisfare le richieste degli utenti, ma con una dimensione inferiore del parco istanze, e aggiungi più risorse per i momenti attesi di incremento della domanda. 

 Esegui l'analisi dei costi per diversi utilizzi nel tempo discutendone con le parti interessate della tua organizzazione e usa la funzione di previsione di [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) per prevedere l'impatto potenziale di modifiche dei servizi. Monitora i trigger dei livelli di utilizzo con Budget AWS, gli allarmi di fatturazione di CloudWatch e AWS Cost Anomaly Detection per identificare e implementare in tempi rapidi i servizi più contenuti nei costi. 

**Passaggi dell'implementazione**
+ ** Definisci modelli di utilizzo previsti: **collaborando con la tua organizzazione, ad esempio con i proprietari di prodotti e marketing, documenta quali sono i modelli di utilizzo previsti e attesi per il carico di lavoro. Discuti con le parti interessate dell'azienda dell'aumento dell'utilizzo e dei costi storici e previsti e verifica che tali incrementi siano in linea con i requisiti aziendali. Identifica i giorni, le settimane o i mesi di calendario in cui prevedi che un maggior numero di utenti userà le tue risorse AWS, il che indica che dovrai aumentare la capacità delle risorse esistenti o adottare servizi aggiuntivi per ridurre i costi e migliorare le performance. 
+ ** Esegui l'analisi dei costi in base all'utilizzo previsto: ** utilizzando i modelli di utilizzo definiti, esegui l'analisi in ciascuno di questi punti. Lo sforzo di analisi dovrebbe riflettere il potenziale risultato. Ad esempio, se la variazione dell'utilizzo è elevata, è necessario eseguire un'analisi accurata per verificare eventuali costi e modifiche. In altre parole, quando il costo aumenta dovrebbe aumentare anche l'utilizzo per l'azienda. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Calcolatore del costo totale di proprietà (TCO) di AWS](https://aws.amazon.com/tco-calculator/) 
+  [Classi di archiviazione di Amazon S3](https://aws.amazon.com/s3/storage-classes/) 
+  [Prodotti cloud](https://aws.amazon.com/products/) 
+ [ Amazon EC2 Auto Scaling ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [ Migrazione cloud dei dati ](https://aws.amazon.com/cloud-data-migration/)
+ [AWS Snow Family](https://aws.amazon.com/snow/)

 **Video correlati:** 
+ [AWS OpsHub for Snow Family](https://www.youtube.com/watch?v=0Q7s7JiBCf0)

# COST 6. In che modo raggiungi gli obiettivi di costo quando selezioni il tipo, le dimensioni e il numero delle risorse?
<a name="cost-06"></a>

Assicurati di scegliere la dimensione e il numero delle risorse appropriati per l'attività in questione. Selezionando il tipo, le dimensioni e il numero più convenienti, riduci al minimo gli sprechi.

**Topics**
+ [COST06-BP01 Esecuzione della modellazione dei costi](cost_type_size_number_resources_cost_modeling.md)
+ [COST06-BP02 Selezione di tipo, dimensione e numero di risorse sulla base dei dati](cost_type_size_number_resources_data.md)
+ [COST06-BP03 Selezione automatica del tipo e della dimensione della risorsa in base ai parametri](cost_type_size_number_resources_metrics.md)

# COST06-BP01 Esecuzione della modellazione dei costi
<a name="cost_type_size_number_resources_cost_modeling"></a>

Identifica i requisiti dell'organizzazione (come le esigenze aziendali e gli impegni esistenti) ed esegui la modellazione dei costi (costi complessivi) del carico di lavoro e di ciascuno dei suoi componenti. Esegui attività di analisi comparativa per il carico di lavoro in base ai diversi carichi previsti e confronta i costi. L'impegno di modellazione deve riflettere il potenziale risultato. Ad esempio, il tempo speso dovrebbe essere proporzionale al costo dei componenti.

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Esegui la modellazione dei costi per il tuo carico di lavoro e ciascuno dei suoi componenti per stabilire il giusto equilibrio tra le risorse e trova la dimensione appropriata per ogni risorsa nel carico di lavoro, sulla base di un determinato livello di prestazioni. La comprensione delle considerazioni sui costi può informare il business case dell'organizzazione e il processo decisionale quando si valutano i risultati di realizzazione del valore per l'implementazione del carico di lavoro pianificato. 

 Esegui attività di analisi comparativa per il carico di lavoro in base ai diversi carichi previsti e confronta i costi. L'impegno di modellazione deve riflettere il potenziale risultato. Ad esempio, il tempo speso dovrebbe essere proporzionale al costo dei componenti o ai risparmi previsti. Per le best practice, consulta [Revisione della sezione del Principio dell'efficienza della performance di AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/review.html). 

 Come esempio, per creare la modellazione dei costi per un carico di lavoro con risorse di calcolo [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) può assistere con la modellazione dei costi per l'esecuzione dei carichi di lavoro. Fornisce consigli di dimensionamento appropriato per le risorse di calcolo in base a una valutazione cronologica dell'utilizzo. Assicurati che gli agenti CloudWatch siano distribuiti sulle istanze Amazon EC2 per raccogliere le metriche della memoria che aiutano a fornire raccomandazioni più accurate all'interno di AWS Compute Optimizer. Questa è l'origine dati ideale per le risorse di calcolo perché è un servizio gratuito e utilizza il machine learning per generare più raccomandazioni a seconda dei livelli di rischio. 

 Esistono [più servizi](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html) che è possibile utilizzare con log personalizzati come origini dati per le operazioni di ridimensionamento di altri servizi e componenti del carico di lavoro, ad esempio [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/), [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) e [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). AWS Trusted Advisor controlla le risorse e segnala quelle a basso utilizzo, che aiutano a dimensionare correttamente le risorse e a creare una modellazione dei costi. 

 Di seguito sono riportate le raccomandazioni per i parametri e i dati di modellazione dei costi: 
+  Il monitoraggio deve corrispondere in modo preciso all'esperienza degli utenti. Seleziona la granularità corretta per un dato periodo di tempo e scegli in modo ponderato il 99° percentile o quello massimo invece del valore medio. 
+  Seleziona la granularità corretta per il periodo di analisi richiesto per coprire tutti i cicli del carico di lavoro. Ad esempio, se esegui un'analisi di due settimane, potresti ignorare un ciclo mensile di utilizzo elevato, e questo potrebbe causare un provisioning insufficiente. 
+  Scegli i servizi AWS giusti per il carico di lavoro pianificato considerando gli impegni esistenti, i modelli di prezzo selezionati per altri carichi di lavoro e la capacità di innovare più rapidamente e di concentrarsi sul valore del core business. 

**Passaggi dell'implementazione**
+ ** Esegui una modellazione dei costi per le risorse:** implementa il carico di lavoro o un proof of concept in un account separato con i tipi di risorse e dimensioni specifiche da testare. Esegui il carico di lavoro con i dati di test e registra i risultati di output, insieme ai dati relativi ai costi per il tempo in cui è stato eseguito il test. Quindi, implementa di nuovo il carico di lavoro o modifica i tipi e le dimensioni delle risorse ed esegui nuovamente il test. Includi i costi di licenza di qualsiasi prodotto che si possa utilizzare con queste risorse e i costi operativi stimati (manodopera o tecnici) per l'implementazione e la gestione di queste risorse durante la creazione di modelli di costo. Considera la modellazione dei costi per un periodo (orario, giornaliero, mensile, annuale o triennale).

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+ [ Identificare le opportunità per un dimensionamento corretto ](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)
+  Funzionalità di [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) 
+  [Ottimizzazione dei costi: dimensionamento appropriato di Amazon EC2](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html) 
+  [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 
+ [ Calcolatore dei prezzi AWS](https://calculator.aws/#/)

 **Esempi correlati:** 
+ [ Esegui una modellazione dei costi basata sui dati ](https://aws.amazon.com/blogs/mt/how-to-use-aws-well-architected-with-aws-trusted-advisor-to-achieve-data-driven-cost-optimization/)
+ [ Stima il costo delle configurazioni di risorse AWS pianificate ](https://aws.amazon.com/premiumsupport/knowledge-center/estimating-aws-resource-costs/)
+ [ Scegli gli strumenti AWS corretti ](https://www.learnaws.org/2019/09/27/choose-right-aws-tools/)

# COST06-BP02 Selezione di tipo, dimensione e numero di risorse sulla base dei dati
<a name="cost_type_size_number_resources_data"></a>

Seleziona la dimensione o il tipo di risorsa in base ai dati relativi al carico di lavoro e alle caratteristiche delle risorse come, ad esempio, elaborazione, memoria, throughput o scrittura intensiva. Questa selezione è tipicamente effettuata utilizzando una versione precedente (on-premise) del carico di lavoro, utilizzando la documentazione o altre fonti di informazione sul carico di lavoro.

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Amazon EC2 offre un'ampia selezione di tipi di istanza con vari livelli di CPU, memoria, archiviazione e capacità di rete per adattarsi a diversi casi d'uso. Questi tipi di istanza offrono diverse combinazioni di CPU, memoria, archiviazione e funzionalità di rete, che garantiscono versatilità nella scelta delle risorse giuste per i tuoi progetti. Ogni tipo di istanza è disponibile in più dimensioni, per consentire di adattare le risorse alle richieste del carico di lavoro. Per determinare il tipo di istanza necessario, acquisisci i dettagli sui requisiti di sistema dell'applicazione o del software che intendi eseguire sull'istanza. Tali dettagli devono includere le informazioni seguenti: 
+  Sistema operativo 
+  Numero di core della CPU 
+  Core della GPU 
+  Quantità di memoria di sistema (RAM) 
+  Tipo e spazio di archiviazione 
+  Requisiti di larghezza di banda della rete 

 Identifica lo scopo dei requisiti di calcolo e l'istanza necessaria, quindi analizza le varie famiglie di istanze Amazon EC2. Amazon offre le seguenti famiglie di tipi di istanza: 
+  Per uso generico 
+  Ottimizzate per il calcolo 
+  Ottimizzate per la memoria 
+  Ottimizzate per l'archiviazione 
+  Calcolo accelerato 
+  Ottimizzate per il calcolo ad alte prestazioni (HPC) 

 Per una comprensione più approfondita degli scopi e dei casi d'uso specifici che una particolare famiglia di istanze Amazon EC2 può soddisfare, consulta [Instance typesAWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html). 

 L'acquisizione dei requisiti di sistema è fondamentale per selezionare la famiglia e il tipo di istanze specifici più adatti alle proprie esigenze. I nomi dei tipi di istanza sono composti dal nome della famiglia e dalla dimensione dell'istanza. Ad esempio, l'istanza t2.micro appartiene alla famiglia T2 ed è di dimensioni ridotte. 

 Seleziona la dimensione o il tipo di risorsa in base al carico di lavoro e alle caratteristiche delle risorse come, ad esempio, calcolo, memoria, velocità di trasmissione effettiva o uso intensivo di operazioni di scrittura. Questa selezione è in genere effettuata ricorrendo alla modellazione dei costi, a una versione precedente del carico di lavoro (ad esempio una versione on-premise), alla documentazione o ad altre fonti di informazione sul carico di lavoro (come whitepaper o soluzioni pubblicate). L'uso di calcolatori dei prezzi AWS o di strumenti di gestione dei costi può aiutare a elaborare decisioni informate su tipi, dimensioni e configurazioni delle istanze. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+ **Seleziona le risorse in base ai dati:** utilizza i dati di modellazione dei costi per selezionare il livello di utilizzo previsto del carico di lavoro e scegliere il tipo e la dimensione delle risorse specificati. Basandoti sui dati di modellazione dei costi, determina il numero di CPU virtuali, la memoria totale (GiB), il volume dell'archivio dell'istanza locale (GB), i volumi Amazon EBS e il livello di prestazioni della rete, tenendo conto della velocità di trasferimento dei dati richiesta per l'istanza. Effettua sempre selezioni basate su analisi dettagliate e dati accurati per ottimizzare le prestazioni e contemporaneamente gestire i costi in modo efficace.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [Tipi di istanza AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  Funzionalità di [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) 
+  [Cost Optimization: EC2 Right Sizing](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html) 

 **Video correlati:** 
+ [ Selecting the right Amazon EC2 instance for your workloads ](https://www.youtube.com/watch?v=q5Dn9gcmpJg)
+ [ Right size your service ](https://youtu.be/wcp1inFS78A)

 **Esempi correlati:** 
+ [ It just got easier to discover and compare Amazon EC2 instance types ](https://aws.amazon.com/blogs/compute/it-just-got-easier-to-discover-and-compare-ec2-instance-types/)

# COST06-BP03 Selezione automatica del tipo e della dimensione della risorsa in base ai parametri
<a name="cost_type_size_number_resources_metrics"></a>

Utilizza i parametri del carico di lavoro in esecuzione per selezionare la dimensione e il tipo giusti per ottimizzare i costi. Esegui il provisioning in modo appropriato di throughput, dimensione e spazio di archiviazione per servizi di calcolo, memorizzazione, gestione dati e di rete. Questa operazione può essere eseguita con un ciclo di feedback, ad esempio attraverso l'auto scaling o tramite codice personalizzato nel carico di lavoro.

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Crea un ciclo di feedback all'interno del carico di lavoro che utilizza i parametri attivi del carico di lavoro in esecuzione per apportarvi modifiche. È possibile utilizzare un servizio gestito come [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) che può essere configurato per eseguire le giuste operazioni di dimensionamento per conto proprio. AWS fornisce anche [API, SDK](https://aws.amazon.com/developer/tools/) e funzionalità che permettono alle risorse di essere modificate con un minimo sforzo. Puoi programmare un carico di lavoro affinché arresti e riavvii un'istanza Amazon EC2 per consentire una modifica delle dimensioni o del tipo di istanza. Ciò offre i vantaggi del dimensionamento appropriato, eliminando al contempo quasi tutti i costi operativi necessari per apportare la modifica.

Alcuni servizi AWS includono una selezione integrata automatica di tipo o dimensione come [Amazon Simple Storage Service Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/). Basandosi sui modelli di utilizzo, Amazon S3 Intelligent-Tiering sposta automaticamente i dati tra due livelli di accesso: frequente e poco frequente.

**Passaggi dell'implementazione**
+ **Incrementa l'osservabilità configurando i parametri del carico di lavoro:** acquisisci i parametri chiave del carico di lavoro. Questi parametri, come ad esempio l'output del carico di lavoro, forniscono un'indicazione dell'esperienza del cliente e danno indicazioni legate alle differenze tra tipi e dimensioni di risorse, come l'utilizzo di CPU e memoria. Per le risorse di calcolo, analizza i dati sulle prestazioni per dimensionare correttamente le istanze Amazon EC2. Identifica le istanze inattive e quelle sottoutilizzate. Le metriche chiave da controllare sono l'utilizzo della CPU e della memoria (ad esempio, il 40% di utilizzo della CPU per il 90% del tempo, come spiegato in [Ridimensionamento con AWS Compute Optimizer e utilizzo della memoria abilitati](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)). Identifica le istanze con un utilizzo massimo della CPU e della memoria inferiore al 40% su un periodo di quattro settimane. Questi sono i casi in cui è necessario dimensionare correttamente il sistema per ridurre i costi. Per le risorse di archiviazione come Amazon S3 è possibile utilizzare [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) che, per impostazione predefinita, consente di visualizzare 28 parametri in varie categorie a livello di bucket e 14 giorni di dati storici nel pannello di controllo. Per analizzare specifici parametri, si possono applicare dei filtri su riepilogo e ottimizzazione dei costi o eventi all'interno del pannello di controllo di Amazon S3 Storage Lens. 
+ **Visualizza le raccomandazioni per il dimensionamento appropriato:** utilizza le raccomandazioni per il dimensionamento appropriato in AWS Compute Optimizer e lo strumento per il dimensionamento appropriato di Amazon EC2 nella console di gestione dei costi, oppure esamina l'attività di dimensionamento appropriato di AWS Trusted Advisor per apportare le opportune regolazioni sul tuo carico di lavoro. Quando si dimensionano in modo appropriato diverse risorse è importante usare gli [strumenti giusti ](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html) e seguire le [linee guida al dimensionamento appropriato](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html) che si tratti di un'istanza Amazon EC2, di classi di archiviazione AWS o di tipi di istanza Amazon RDS. Per le risorse di archiviazione è possibile utilizzare Amazon S3 Storage Lens, che offre visibilità sull'utilizzo dello spazio di archiviazione di oggetti e sulle tendenze delle attività e fornisce raccomandazioni operative per ottimizzare i costi e applicare le best practice di protezione dei dati. Utilizzando le raccomandazioni contestuali che [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) deriva dall'analisi dei parametri all'interno della tua organizzazione, si possono adottare misure immediate per ottimizzare lo spazio di archiviazione. 
+ **Seleziona automaticamente il tipo e la dimensione delle risorse in base ai parametri:** utilizzando i parametri del carico di lavoro, seleziona manualmente o automaticamente le relative risorse. Per le risorse di calcolo, la configurazione di AWS Auto Scaling o l'implementazione di codice all'interno dell'applicazione può ridurre lo sforzo necessario in caso di modifiche frequenti e permettere di implementare potenzialmente eventuali modifiche più velocemente rispetto a un processo manuale. Si può lanciare e scalare automaticamente un parco istanze on demand e di istanze Spot all'interno di un singolo gruppo Auto Scaling. Oltre a ricevere sconti per l'utilizzo di Istanze Spot, è possibile utilizzare Istanze Riservate o Savings Plans per ricevere tariffe scontate rispetto al normale prezzo delle Istanze on demand. La combinazione di tutti questi fattori consente di ottimizzare i risparmi sui costi delle istanze Amazon EC2 e di determinare il dimensionamento e le prestazioni desiderate per la tua applicazione. Si può anche usare una strategia di [selezione del tipo di istanza basata su attributi (ABS)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) nei [gruppi Auto Scaling (ASG)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) che consenta di esprimere i requisiti dell'istanza come un set di attributi, ad esempio vCPU, memoria e spazio di archiviazione. È possibile utilizzare automaticamente i tipi di istanza di nuova generazione quando vengono rilasciati e accedere a una gamma più ampia di capacità con le istanze Spot di Amazon EC2. Il parco istanze Amazon EC2 e Amazon EC2 Auto Scaling selezionano e avviano istanze che corrispondono agli attributi specificati, eliminando la necessità di scegliere manualmente i tipi di istanza. Per le risorse di archiviazione puoi usare le funzionalità di [Intelligent Tiering di Amazon S3](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) e [accesso non frequente di Amazon EFS](https://aws.amazon.com/efs/features/infrequent-access/), che consentono di selezionare automaticamente le classi di archiviazione che offrono risparmi automatici sui relativi costi quando cambiano i modelli di accesso ai dati, senza impatto sulle prestazioni né sovraccarico operativo. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [Dimensionamento appropriato di AWS](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/) 
+  [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 
+  Funzionalità di [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) 
+  [Configurazione di CloudWatch](https://docs.aws.amazon.com/Amazon/latest/monitoring/GettingSetup.html) 
+  [Pubblicazione di parametri personalizzati in CloudWatch](https://docs.aws.amazon.com/Amazon/latest/monitoring/publishingMetrics.html) 
+  [Nozioni di base su Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) 
+  [Intelligent Tiering di Amazon S3](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/) 
+  [Accesso non frequente di Amazon EFS](https://aws.amazon.com/efs/features/infrequent-access/) 
+  [Avvia un'istanza Amazon EC2 utilizzando l'SDK](https://docs.aws.amazon.com/sdk-for-net/v2/developer-guide/run-instance.html) 

 **Video correlati:** 
+  [Dimensiona in modo appropriato i tuoi servizi](https://www.youtube.com/watch?v=wcp1inFS78A) 

 **Esempi correlati:** 
+  [Selezione dell'istanza basata sugli attributi per Auto Scaling per il parco istanze Amazon EC2](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/) 
+  [Ottimizzazione dei costi di Amazon Elastic Container Service utilizzando il dimensionamento programmato ](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/) 
+  [Dimensionamento predittivo con Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/) 
+  [Ottimizza i costi e acquista visibilità sull'utilizzo con Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) 
+  [Well-Architected Labs: raccomandazioni per il dimensionamento appropriato (Livello 100)](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/) 
+  [Well-Architected Labs: dimensionamento appropriato con AWS Compute Optimizer e l'utilizzo della memoria abilitati (Livello 200)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 

# COST 7. In che modo impieghi i modelli di prezzo per ridurre i costi?
<a name="cost-07"></a>

Utilizza il modello di prezzo più appropriato per le tue risorse per ridurre al minimo le spese.

**Topics**
+ [COST07-BP01 Esecuzione di un'analisi del modello di prezzo](cost_pricing_model_analysis.md)
+ [COST07-BP02 Scegli le regioni in base al costo](cost_pricing_model_region_cost.md)
+ [COST07-BP03 Selezione di contratti di terze parti con condizioni economicamente convenienti](cost_pricing_model_third_party.md)
+ [COST07-BP04 Implementazione di modelli di determinazione dei prezzi per tutti i componenti del carico di lavoro](cost_pricing_model_implement_models.md)
+ [COST07-BP05 Esecuzione dell'analisi del modello di prezzo a livello di account di gestione](cost_pricing_model_master_analysis.md)

# COST07-BP01 Esecuzione di un'analisi del modello di prezzo
<a name="cost_pricing_model_analysis"></a>

Analizza ogni componente del carico di lavoro. Determina se il componente e le risorse saranno in esecuzione per periodi prolungati (per sconti a fronte di impegni) o dinamici e di breve durata (per spot oppure on demand). Esegui un'analisi sul carico di lavoro utilizzando i suggerimenti presenti negli strumenti di gestione dei costi e applica le regole aziendali a tali suggerimenti per ottenere rendimenti elevati.

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

AWS ha più [modelli di prezzo](https://aws.amazon.com/pricing/) che consentono di pagare per le risorse nel modo più conveniente e adatto alle esigenze della tua organizzazione e in base al prodotto. Lavora con i tuoi team per stabilire il modello di prezzi più appropriato. Spesso il modello di prezzi è costituito da più opzioni, in base alla tua disponibilità 

 **Istanze on demand** consentono di pagare capacità di elaborazione o di database all'ora o al secondo (minimo 60 secondi) in base a quali istanze esegui, senza impegni nel lungo termine o pagamenti anticipati. 

 **Savings Plans** sono un modello di prezzi flessibile che offre prezzi contenuti sull'utilizzo di Amazon EC2, Lambda e AWS Fargate, in cambio di un impegno per un uso sostenuto (misurato in dollari per ora) in un periodo di un anno o di tre anni. 

 **Istanze spot** sono un meccanismo di prezzo Amazon EC2 che consente di richiedere capacità di elaborazione inutilizzata a una tariffa oraria scontata (fino al 90% rispetto al prezzo on-demand) senza un impegno iniziale. 

 **Istanze riservate** consentono di ottenere uno sconto fino al 75% con un pagamento anticipato per la capacità. Per maggiori dettagli consulta [Ottimizzare i costi con le prenotazioni](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html). 

 Potresti scegliere di includere un Savings Plans per le risorse associate alla produzione, alla qualità e agli ambienti di sviluppo. In alternativa, poiché le risorse dell'ambiente di sperimentazione (sandbox) vengono attivate solo se necessarie, potresti adottare un modello on-demand per le risorse presenti in quel contesto. Use le [Istanze spot](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#spot-instances) Amazon per ridurre i costi Amazon EC2 oppure usa [Compute Savings Plans](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#savings-plans) per ridurre i costi Amazon EC2, Fargate e Lambda. Lo strumento di suggerimenti [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) offre opportunità di ottenere sconti con i Saving Plan. 

 Se hai acquistato [Istanze riservate](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/reserved-instances/?track=costop) per Amazon EC2 in passato o hai definito procedure di allocazione dei costi all'interno della tua organizzazione, puoi continuare a usare le Istanze riservate Amazon EC2 per il momento. Tuttavia, ti consigliamo di lavorare su una strategia per usare Savings Plans in futuro come meccanismo più flessibile di risparmio sui costi. Puoi aggiornare i suggerimenti Savings Plans (SP) in AWS Cost Management per generare nuovi suggerimenti di Saving Plan in qualsiasi momento. Usa le Istanze riservate (RI) per ridurre i costi Amazon RDS, Amazon Redshift, Amazon ElastiCache e Amazon OpenSearch Service. Saving Plan e Istanze riservate sono disponibili in tre opzioni: pagamento anticipato totale, pagamento anticipato parziale e nessun pagamento anticipato. Usa le raccomandazioni fornite nei consigli di acquisto RI e SP AWS Cost Explorer. 

 Per trovare opportunità per i carichi di lavoro Spot, utilizza una visualizzazione oraria dell'utilizzo complessivo e cerca periodi regolari di variazione dell'utilizzo o di elasticità. Puoi usare le Istanze spot per diverse applicazioni flessibili e tolleranti ai guasti. Tra gli esempi figurano server Web stateless, endpoint di API, applicazioni di big data e analisi, carichi di lavoro containerizzati, CI/CD e altri carichi di lavoro flessibili. 

 Analizza se le tue istanze Amazon EC2 e Amazon RDS possono essere disattivate quando non le usi (dopo l'orario di lavoro e nei weekend). In questo modo potrai ridurre i costi di almeno il 70% rispetto al loro utilizzo 24 ore su 24, 7 giorni su 7. Se hai cluster Amazon Redshift che devono essere disponibili solo in orari specifici, puoi metterli in pausa e poi riattivarli. Quando il cluster Amazon Redshift o Amazon EC2 e l'istanza Amazon RDS vengono arrestati, la fattura relativa all'elaborazione si arresta e si applicano solo i costi di archiviazione. 

 Da notare che le [Prenotazioni della capacità on-demand](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-pricing-billing.html) (ODCR) non sono uno sconto sul prezzo. Le prenotazioni della capacità vengono addebitate alla tariffa on-demand equivalente, sia che tu esegua istanze con capacità riservata oppure no. Tali prenotazioni devono essere prese in considerazione quando hai bisogno di offrire capacità sufficiente alle risorse che desideri eseguire. Le ODCR non devono essere considerate un impegno nel lungo termine, poiché possono essere annullate quando non ne hai più bisogno, ma possono anche approfittare degli sconti offerti da Savings Plans o dalle Istanze riservate. 

**Passaggi dell'implementazione**
+  **Analizza l'elasticità del carico di lavoro: **Utilizzando la granularità oraria in Cost Explorer o un pannello di controllo personalizzato, analizza l'elasticità del tuo carico di lavoro. Vai alla ricerca di modifiche regolari del numero di istanze in esecuzione. Le istanze in esecuzione per brevi periodi di tempo sono candidate per essere istanze Spot o serie di istanze Spot. 
  +  [Well-Architected Lab: Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity) 
  +  [Well-Architected Labs: visualizzazione dei costi](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  **Esamina i contratti esistenti sui prezzi:** esamina i contratti o gli impegni in essere per le esigenze nel lungo termine. Analizza ciò di cui disponi ora e fino a che punto gli impegni presi vengono sfruttati. Sfrutta sconti contrattuali preesistenti o accordi aziendali. Gli [Accordi aziendali](https://aws.amazon.com/pricing/enterprise/) offrono ai clienti la possibilità di personalizzare i contratti in modo che siano rispondenti alle esigenze aziendali. Per accordi nel lungo termine, prendi in considerazione gli sconti dei prezzi riservati, le Istanze riservate o Savings Plans per il tipo di istanza specifico, la famiglia delle istanze, Regione AWS e le zone di disponibilità. 
+ ** Esegui un'analisi degli sconti in seguito a un impegno contrattuale:** tramite l'uso di Cost Explorer nel tuo account, esamina Savings Plans e i suggerimenti delle Istanze riservate. Per verificare di implementare le raccomandazioni corrette con gli sconti e i rischi richiesti, segui i [Well-Architected Labs](https://wellarchitectedlabs.com/cost/costeffectiveresources/). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Accesso alle raccomandazioni di istanza riservata](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [Opzioni di acquisto delle istanze](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+ [AWS Enterprise ](https://aws.amazon.com/pricing/enterprise/)

 **Video correlati:** 
+  [Risparmia fino al 90% ed esegui i carichi di lavoro di produzione su Spot](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **Esempi correlati:** 
+  [Well-Architected Lab: Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity) 
+  [Well-Architected Labs: visualizzazione dei costi](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  [Well-Architected Lab: modelli di prezzo](https://wellarchitectedlabs.com/Cost/CostEffectiveResources.html) 

# COST07-BP02 Scegli le regioni in base al costo
<a name="cost_pricing_model_region_cost"></a>

La determinazione dei prezzi delle risorse può essere diversa in ciascuna regione. Individua le differenze di costo a livello regionale ed esegui la distribuzione solo nelle Regioni con costi più elevati per soddisfare i requisiti di latenza, posizionamento fisico dei dati e sovranità dei dati. La considerazione del costo della regione garantisce il pagamento del prezzo complessivo più basso per questo carico di lavoro.

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

L' [infrastruttura Cloud AWS](https://aws.amazon.com/about-aws/global-infrastructure/) è globale, ospitata in [più sedi in tutto il mondo](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)e costruita in base a Regioni AWS, zone di disponibilità, zone locali, AWS Outposts e zone di lunghezza d'onda. Una regione è una posizione fisica nel mondo e ogni regione è un'area geografica separata in cui AWS ha più zone di disponibilità. Le zone di disponibilità, che sono più sedi isolate all'interno di ogni regione, sono costituite da uno o più data center discreti, ciascuno con alimentazione, rete e connettività ridondanti. 

Ogni Regione AWS opera nelle condizioni di mercato locale e il prezzo delle risorse è diverso in ogni Regione, ad esempio a causa delle differenze nel costo della terra, della fibra, dell'elettricità e delle tasse. Scegli una regione specifica per gestire un componente o tutta la tua soluzione in modo da eseguirla al minor prezzo possibile a livello globale. Utilizza lo strumento [Calcolatore dei prezzi AWS](https://calculator.aws/#/) per stimare i costi del carico di lavoro in varie Regioni, cercando i servizi per tipo di località (Regione, zona di lunghezza d'onda e zona locale) e Regione. 

Quando progetti le tue soluzioni, una best practice da seguire è quella di cercare di posizionare le risorse di calcolo vicino agli utenti per offrire una latenza inferiore e una forte sovranità dei dati. Seleziona la posizione geografica in base alle esigenze di business, privacy dei dati, performance e requisiti di sicurezza. Per le applicazioni con utenti finali globali, utilizza più sedi.

 Utilizza le regioni che offrono prezzi più bassi per i servizi AWS per distribuire i carichi di lavoro se non hai obblighi in materia di privacy dei dati, sicurezza e requisiti aziendali. Ad esempio, se la regione predefinita è ap-southeasth-2 (Sydney) e se non ci sono restrizioni (privacy dei dati, sicurezza, ad esempio) per l'utilizzo di altre regioni, l'implementazione di istanze Amazon EC2 non critiche (sviluppo e test) nella regione north-east-1 (N. Virginia) costerà meno. 

![\[Grafico che mostra diverse Regioni con conformità, latenza, costi, servizi e funzionalità.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/region-feature-matrix.png)


 

 La tabella a matrice precedente mostra che la Regione 4 è l'opzione migliore per questo scenario specifico perché la latenza è bassa rispetto ad altre Regioni, il servizio è disponibile ed è la Regione meno costosa. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+ ** Rivedi i prezzi della Regione AWS: **analizza i costi del carico di lavoro nella regione corrente. A partire dai costi più elevati per servizio e tipo di utilizzo, calcola i costi in altre regioni disponibili. Se il risparmio previsto supera il costo di spostamento del componente o del carico di lavoro, esegui la migrazione alla nuova regione. 
+  **Rivedi i requisiti per implementazioni multi-regione:** analizza i requisiti e gli obblighi aziendali (privacy dei dati, sicurezza o prestazioni) per scoprire se ci sono restrizioni che impediscono di utilizzare più Regioni. Se non ci sono obblighi che limitano l'utilizzo di una sola regione, allora utilizza più regioni. 
+  **Analizza il trasferimento di dati richiesto:** considera i costi per il trasferimento dei dati quando selezioni le Regioni. Mantieni i dati vicino ai clienti e alle risorse. Seleziona le Regioni AWS meno costose in cui confluiscono i dati e che richiedono trasferimenti minimi di dati. A seconda dei requisiti aziendali per il trasferimento dei dati, puoi utilizzare [Amazon CloudFront](https://aws.amazon.com/cloudfront/), [AWS PrivateLink](https://aws.amazon.com/privatelink/), [AWS Direct Connect](https://aws.amazon.com/directconnect/)e [AWS Virtual Private Network](https://aws.amazon.com/vpn/) per ridurre i costi di rete, nonché migliorare le prestazioni e la sicurezza. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Accesso alle raccomandazioni di istanza riservata](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [Prezzi di Amazon EC2](https://aws.amazon.com/ec2/pricing/) 
+  [Opzioni di acquisto dell'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+  [Tabella delle regioni](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) 

 **Video correlati:** 
+  [Risparmia fino al 90% ed esegui i carichi di lavoro di produzione su Spot](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **Esempi correlati:** 
+ [ Panoramica dei costi di trasferimento dei dati per architetture comuni ](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [ Considerazioni sui costi per implementazioni globali ](https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-considerations-for-global-deployments/)
+ [ elementi da considerare quando si seleziona una regione per i propri carichi di lavoro ](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
+ [ Well-Architected Labs: limita l'utilizzo dei servizi per Regione (Level 200) ](https://www.wellarchitectedlabs.com/cost/200_labs/200_2_cost_and_usage_governance/2_ec2_restrict_region/)

# COST07-BP03 Selezione di contratti di terze parti con condizioni economicamente convenienti
<a name="cost_pricing_model_third_party"></a>

 Gli accordi e i termini convenienti assicurano che i costi di questi servizi siano ridimensionati in base ai vantaggi che offrono. Seleziona gli accordi e i prezzi che si ridimensionano quando forniscono ulteriori vantaggi alla tua organizzazione. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Sul mercato esistono diversi prodotti che possono aiutarti a gestire i costi negli ambienti cloud. In termini di funzionalità possono presentare alcune differenze che dipendono dalle esigenze del cliente, ad esempio alcuni clienti sono più interessati alla governance o alla visibilità dei costi mentre altri all'ottimizzazione di questi ultimi. Un fattore chiave per rendere più efficaci l'ottimizzazione e la governance dei costi è l'utilizzo dello strumento giusto con le funzionalità necessarie combinato al giusto modello di prezzo. Questi prodotti hanno modelli di prezzo diversi. Alcuni addebitano una determinata percentuale dell'importo fatturato mensilmente, mentre altri addebitano una percentuale dei risparmi realizzati. Idealmente, dovresti pagare solo ciò che hai effettivamente utilizzato. 

 Quando utilizzi soluzioni o servizi di terze parti nel cloud, è importante che le strutture dei prezzi siano allineate ai risultati desiderati. I prezzi devono essere adattati in base ai risultati e al valore che forniscono. Ad esempio, se utilizzi un software che contempla una percentuale del risparmio che fornisce, più risparmi (come risultato) e maggiore sarà l'importo addebitato. I contratti di licenza in cui paghi di più all'aumentare delle spese potrebbero non essere sempre nel tuo interesse ai fini dell'ottimizzazione dei costi. Tuttavia, se il fornitore offre vantaggi evidenti per tutte le voci incluse in fattura, questa tariffa scalare potrebbe essere giustificata. 

 Ad esempio, una soluzione che fornisce suggerimenti per Amazon EC2 e addebita una percentuale dell'intera fattura può diventare più dispendiosa se utilizzi altri servizi che non procurano alcun vantaggio. Un altro esempio è un servizio gestito che viene addebitato a una percentuale del costo delle risorse gestite. Una dimensione di istanza più grande potrebbe non richiedere necessariamente un maggiore impegno di gestione, ma potrebbe comportare un addebito superiore. Verifica che queste disposizioni tariffarie dei servizi includano un programma di ottimizzazione dei costi o funzionalità di servizio volte a migliorare l'efficienza. 

 I clienti potrebbero trovare i prodotti sul mercato più avanzati o più facili da usare. È necessario considerare il costo di questi prodotti e valutare i potenziali risultati di ottimizzazione dei costi a lungo termine. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Analizza i contratti e le condizioni stabilite con le terze parti:** esamina i prezzi nei contratti di terze parti. Esegui la modellazione per diversi livelli di utilizzo e considera i nuovi costi, come il nuovo utilizzo del servizio o aumenti dei servizi attuali a causa della crescita del carico di lavoro. Decidi se i costi aggiuntivi forniscono i vantaggi necessari alla tua azienda. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Accesso alle raccomandazioni di istanza riservata](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [Opzioni di acquisto delle istanze](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 

 **Video correlati:** 
+  [Risparmia fino al 90% ed esegui i carichi di lavoro di produzione su Spot](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

# COST07-BP04 Implementazione di modelli di determinazione dei prezzi per tutti i componenti del carico di lavoro
<a name="cost_pricing_model_implement_models"></a>

 Le risorse in esecuzione in modo permanente devono utilizzare la capacità riservata, ad esempio Savings Plans o istanze riservate. La capacità a breve termine è configurata per usare le istanze Spot o la serie di istanze Spot. Le istanze on demand vengono utilizzate solo per carichi di lavoro a breve termine che non possono essere interrotti e che non durano abbastanza a lungo per la capacità riservata, tra il 25% e il 75% del periodo, a seconda del tipo di risorsa. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Per migliorare l'efficienza in termini di costi, AWS fornisce diversi consigli sull'impegno economico basati sull'utilizzo pregresso. Puoi utilizzare questi consigli per capire cosa puoi risparmiare e il livello di impegno richiesto. Puoi utilizzare questi servizi come istanze on demand o istanze spot oppure impegnarti per un determinato periodo di tempo e ridurre i costi delle istanze on demand mediante istanze riservate (RI) e Savings Plans (Savings Plans). Per ottimizzare il carico di lavoro, è necessario comprendere non solo i singoli componenti del carico di lavoro e i vari servizi AWS, ma anche gli sconti applicati agli impegni, le opzioni di acquisto e le istanze spot per questi servizi. 

 Considera i requisiti dei componenti del tuo carico di lavoro e valuta i diversi modelli di prezzo per questi servizi. Definisci il requisito di disponibilità dei componenti. Determina se ci sono più risorse indipendenti che eseguono la funzione nel carico di lavoro e quali sono i requisiti del carico di lavoro nel corso del tempo. Confronta il costo delle risorse utilizzando il modello di prezzo on demand predefinito e altri modelli applicabili. Tieni conto di qualsiasi potenziale cambiamento nelle risorse o nei componenti del carico di lavoro. 

 Analizza, ad esempio, questa architettura di applicazione Web su AWS. Questo carico di lavoro di esempio è composto da più servizi AWS, come Amazon Route 53, AWS WAF, Amazon CloudFront, istanze Amazon EC2, istanze Amazon RDS, sistemi di bilanciamento del carico, archiviazione Amazon S3 e Amazon Elastic File System (Amazon EFS). È necessario esaminare ciascuno di questi servizi e individuare le potenziali opportunità di risparmio sui costi con diversi modelli di prezzo. Alcuni potrebbero essere idonei per le istanze riservate (RI) o per il modello Savings Plans, mentre altri potrebbero essere disponibili solo nelle istanze on demand. Come illustrato nell'immagine seguente, alcuni servizi AWS possono essere eseguiti utilizzando le istanze riservate (RI) o il modello Savings Plans. 

![\[Chart of AWS services committed using Reserved Instances and Savings Plans\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/ri-sp-services.png)


### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Implementazione dei modelli di prezzo:** utilizza i risultati dell'analisi, acquista Savings Plans, istanze riservate (RI) o implementa istanze spot. Se è il tuo primo acquisto a fronte di impegni, scegli i primi cinque o dieci consigli nell'elenco, quindi monitora e analizza i risultati nel corso del mese successivo o dei due mesi successivi. AWS Cost Management Console ti guida durante l'intero processo. Rivedi i consigli relativi all'istanza riservata (RI) o al modello Savings Plans sulla console, personalizza i consigli (tipo, pagamento e durata) e rivedi l'impegno orario (ad esempio, 20 USD all'ora), quindi aggiungilo al carrello. Gli sconti sono applicati automaticamente all'utilizzo idoneo. Acquista un importo ridotto di sconti a fronte di impegni a cicli regolari, ad esempio ogni 2 settimane o ogni mese. Implementa istanze Spot per carichi di lavoro che possono essere interrotti o che sono stateless. Infine, seleziona le istanze Amazon EC2 on demand e alloca le risorse per i requisiti rimanenti.
+  **Ciclo di revisione del carico di lavoro:** implementa un ciclo di revisione per il carico di lavoro che analizzi in modo specifico la copertura del modello di prezzo. Quando il carico di lavoro ha la copertura necessaria, acquista ulteriori sconti a fronte di impegni parzialmente (ogni tanto) o al variare dell'utilizzo dell'organizzazione.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [Introduzione ai consigli Savings Plans](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+  [Accessing Reserved Instance recommendations](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [Come acquistare istanze riservate](https://aws.amazon.com/ec2/pricing/reserved-instances/buyer/) 
+  [Opzioni di acquisto delle istanze](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+  [Istanze Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) 
+ [Modelli di prenotazione per altri servizi AWS](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-reservation-models/reservation-models-for-other-aws-services.html)
+ [Servizi supportati dai Savings Plans](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-services.html)

 **Video correlati:** 
+  [Risparmia fino al 90% ed esegui i carichi di lavoro di produzione su Spot](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **Esempi correlati:** 
+ [Cosa devo considerare prima di acquistare Savings Plans?](https://repost.aws/knowledge-center/savings-plans-considerations)
+ [Come faccio a utilizzare Cost Explorer per analizzare le mie spese e il mio utilizzo?](https://repost.aws/knowledge-center/cost-explorer-analyze-spending-and-usage)

# COST07-BP05 Esecuzione dell'analisi del modello di prezzo a livello di account di gestione
<a name="cost_pricing_model_master_analysis"></a>

 Verifica gli strumenti di gestione dei costi e di fatturazione e dai un'occhiata agli sconti suggeriti con impegni e prenotazioni per eseguire analisi regolari a livello di account di gestione. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 L'esecuzione della modellazione dei costi a intervalli regolari garantisce l'implementazione di opportunità di ottimizzazione su più carichi di lavoro. Ad esempio, se più carichi di lavoro utilizzano istanze on demand a livello aggregato, il rischio di modifica è inferiore e l'implementazione di uno sconto a fronte di impegni permetterà di raggiungere un costo complessivo inferiore. Si consiglia di eseguire l'analisi seguendo cicli regolari con una periodicità da due settimane a un mese. In questo modo è possibile effettuare acquisti in piccoli incrementi, così che la copertura dei modelli di prezzo evolva di pari passo con i carichi di lavoro e i relativi componenti. 

 Utilizza lo strumento per i suggerimenti [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) per trovare opportunità di sconti a fronte di impegni nell'account di gestione. I suggerimenti a livello di account di gestione sono calcolati considerando l'utilizzo di tutti gli account nella tua organizzazione AWS con Istanze riservate o la condivisione di sconti Savings Plans (SP) abilitata. Vengono inoltre calcolati quando viene attivata la condivisione degli sconti per consigliare un impegno che massimizzi i risparmi su tutti gli account. 

 Sebbene in molti casi l'acquisto a livello di account di gestione rappresenti un’ottimizzazione che garantisce risparmi massimi, in alcuni casi potresti prendere in considerazione l'acquisto di Savings Plans a livello di account collegato, ad esempio quando desideri che gli sconti si applichino prima all'utilizzo in quel particolare account collegato. I suggerimenti degli account membri sono calcolati a livello di singolo account per massimizzare i risparmi per ogni account isolato. Se il tuo account ha vincoli o impegni sia per istanze riservate (RI) che per Savings Plans (SP), questi verranno applicati nel seguente ordine: 

1.  RI zonale 

1.  RI standard 

1.  RI convertibile 

1.  Piano di risparmio delle istanze 

1.  Piano di risparmio di calcolo 

 Se acquisti un SP a livello di account di gestione, i risparmi verranno applicati in base alla percentuale di sconto dalla più alta alla più bassa. I Savings Plans a livello di account di gestione esaminano tutti gli account collegati e applicano i risparmi ovunque lo sconto sia il più elevato. Se desideri limitare il luogo in cui vengono applicati i risparmi, puoi acquistare un Savings Plan a livello di account collegato e ogni volta che l'account esegue servizi di calcolo idonei, verrà applicato lo sconto. Quando l'account non esegue servizi di calcolo idonei, lo sconto verrà condiviso con gli altri account collegati con lo stesso account di gestione. La condivisione degli sconti è attivata per impostazione predefinita, ma può essere disattivata se necessario. 

 In una famiglia con fatturazione consolidata, i Savings Plans vengono applicati prima all'utilizzo dell'account del proprietario e, quindi, all'utilizzo degli altri account. Ciò si verifica solo se la condivisione è abilitata. I tuoi Savings Plans vengono applicati prima alla percentuale di risparmio più alta. Se ci sono più utilizzi con percentuali di risparmio uguali, i Savings Plans sono applicati al primo utilizzo con la tariffa Savings Plans più bassa. I Savings Plans continuano ad essere applicati fino a quando non ci sono più utilizzi rimanenti o fino all'esaurimento dell'impegno o del vincolo. L'eventuale utilizzo residuo viene addebitato in base alle tariffe on demand. Puoi aggiornare i suggerimenti dei Savings Plans in AWS Cost Managemet per generare nuovi suggerimenti dei Savings Plans in qualsiasi momento. 

 Dopo aver analizzato la flessibilità delle istanze, puoi prendere una decisione in base ai suggerimenti ricevuti. Crea una modellazione dei costi analizzando i costi a breve termine del carico di lavoro rispetto a potenziali diverse opzioni di risorse, analizzando i modelli di prezzo AWS e allineandoli ai requisiti aziendali per scoprire il costo totale di proprietà e le possibilità di [Ottimizzazione dei costi](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html) . 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>

 **Esecuzione di un'analisi degli sconti a fronte di impegni**: utilizza Cost Explorer nel tuo account, esamina Savings Plans e le raccomandazioni relative alle istanze riservate. Verifica di aver compreso i suggerimenti dei Saving Plan, fai una stima della tua spesa mensile e calcola il risparmio che puoi ottenere su tale intervallo di tempo. Esamina i consigli a livello di account di gestione, calcolati considerando l'utilizzo in tutti gli account membri della tua organizzazione AWS con abilitata la condivisione degli sconti Savings Plans o Istanze Riservate, per ottenere il massimo risparmio tra gli account. Per assicurarti di implementare le raccomandazioni corrette con gli sconti e i rischi richiesti, segui i Well-Architected Labs. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Come funzionano i prezzi di AWS?](https://aws.amazon.com/pricing/?nc2=h_ql_pr_ln) 
+  [Opzioni di acquisto dell'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+  [Panoramica del Saving Plan](file:///Users/mergenf/Documents/WELL%20ARCHITECTED/COST%20OPT%20PILLAR/phase3a/COST06/•%09https:/docs.aws.amazon.com/savingsplans/latest/userguide/sp-overview.html) 
+  [Suggerimenti per il Saving Plan](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html) 
+  [Accesso alle raccomandazioni di istanza riservata](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [Understanding your Saving Plans recommendation](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html) 
+  [Come Savings Plans si applica al tuo utilizzo di AWS](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html) 
+  [Saving Plans with Consolidated Billing](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-consolidated-billing/) 
+  [Attivazione delle istanze riservate condivise e degli sconti dei Savings Plans](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html) 

 **Video correlati:** 
+  [Risparmia fino al 90% ed esegui i carichi di lavoro di produzione su Spot](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **Esempi correlati:** 
+  [AWS Well-Architected Lab: Pricing Models (Level 200)](https://wellarchitectedlabs.com/cost/200_labs/200_3_pricing_models/) 
+  [AWS Well-Architected Labs: Pricing Model Analysis (Level 200)](https://www.wellarchitectedlabs.com/cost/200_labs/200_pricing_model_analysis/) 
+  [Cosa devo considerare prima di acquistare un Savings Plan?](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-considerations/) 
+  [How can I use rolling Savings Plans to reduce commitment risk?](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-can-i-use-rolling-savings-plans-to-reduce-commitment-risk/) 
+  [Quando utilizzare le istanze spot](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-leveraging-ec2-spot-instances/when-to-use-spot-instances.html) 

# COST 8. In che modo pianifichi i costi per il trasferimento dei dati?
<a name="cost-08"></a>

Assicurati di pianificare e monitorare i costi di trasferimento dei dati in modo da poter prendere decisioni sull'architettura per ridurre al minimo i costi. Una modifica piccola ma efficace dell'architettura può ridurre drasticamente i costi operativi nel tempo. 

**Topics**
+ [COST08-BP01 Esecuzione della modellazione del trasferimento dei dati](cost_data_transfer_modeling.md)
+ [COST08-BP02 Selezione dei componenti per ottimizzare il costo di trasferimento dei dati](cost_data_transfer_optimized_components.md)
+ [COST08-BP03 Implementazione dei servizi per ridurre il costo di trasferimento dei dati](cost_data_transfer_implement_services.md)

# COST08-BP01 Esecuzione della modellazione del trasferimento dei dati
<a name="cost_data_transfer_modeling"></a>

 Raccogli i requisiti dell'organizzazione ed esegui la modellizzazione del trasferimento dei dati del carico di lavoro e di ciascuno dei suoi componenti. Questo identifica il punto di costo più basso per le sue attuali esigenze di trasferimento dei dati. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Quando si progetta una soluzione nel cloud, i costi del trasferimento dei dati vengono in genere ignorati a causa dell'abitudine di progettare l'architettura utilizzando data center on-premise o per mancanza di conoscenze. I costi del trasferimento dei dati in AWS sono determinati dall'origine, dalla destinazione e dal volume del traffico. Tenere conto di questi costi durante la fase di progettazione può produrre risparmi. Capire dove avviene il trasferimento dei dati nel carico di lavoro, il costo del trasferimento e i vantaggi associati è molto importante per stimare con precisione il costo totale di proprietà (TCO). In questo modo puoi prendere una decisione consapevole quando si tratta di modificare o accettare una decisione relativa all'architettura. Ad esempio, potresti disporre di una configurazione con più zone di disponibilità dove replichi i dati tra le varie zone di disponibilità. 

 Puoi modellare i componenti dei servizi che trasferiscono i dati nel carico di lavoro e decidere che si tratta di un costo accettabile (simile a quello del calcolo e dell'archiviazione in entrambe le zone di disponibilità) per ottenere l'affidabilità e la resilienza richieste. Modella i costi in base a livelli differenti di utilizzo. L'utilizzo del carico di lavoro può cambiare nel corso del tempo e servizi differenti possono risultare più convenienti a livelli differenti. 

 Mentre modelli il trasferimento dei dati, pensa alla quantità di dati acquisiti e alla loro provenienza. Inoltre, considera la quantità di dati elaborati e la capacità di archiviazione o calcolo necessaria. Durante la modellazione, attieniti alle best practice relative alle reti in relazione all'architettura del carico di lavoro per ottimizzare i potenziali costi di trasferimento dei dati. 

 Calcolatore dei prezzi AWS può aiutarti a vedere i costi stimati per servizi AWS specifici e per il trasferimento di dati previsto. Se hai un carico di lavoro già in esecuzione (a scopo di test o in un ambiente di preproduzione), usa [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) o [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) (CUR) per comprendere e modellare i costi di trasferimento dei dati. Configura un proof of concept (PoC) o testa il carico di lavoro ed esegui un test con un carico simulato realistico. Puoi modellare i costi in base alle diverse esigenze di carico di lavoro. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Identificazione dei requisiti:** quali sono l'obiettivo principale e i requisiti aziendali per il trasferimento pianificato dei dati tra origine e destinazione? Qual è il risultato aziendale previsto finale? Acquisisci i requisiti aziendali e definisci il risultato previsto. 
+  **Identificazione dell'origine e della destinazione:** quali sono l'origine e la destinazione dei dati da trasferire? (ad esempio all'interno delle Regioni AWS, verso servizi AWS o in Internet) 
  + [Trasferimento dei dati all'interno di una Regione AWS](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-within-region)
  + [Trasferimento dei dati tra Regioni AWS](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-between-regions)
  + [Trasferimento dei dati su Internet](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-out-internet)
+  **Identificazione delle classificazioni dei dati:** qual è la classificazione dei dati per questo trasferimento di dati? Di che tipo di dati si tratta? Quali sono le dimensioni dei dati? Con quale frequenza devono essere trasferiti i dati? I dati sono sensibili? 
+  **Identificazione dei servizi o degli strumenti AWS da utilizzare:** quali servizi AWS vengono utilizzati per questo trasferimento di dati? È possibile utilizzare un servizio che è già stato predisposto per un altro carico di lavoro? 
+  **Calcolo dei costi del trasferimento dei dati:** utilizza i [prezzi di AWS](https://aws.amazon.com/pricing/) per la modellazione del trasferimento dei dati creata in precedenza per calcolare i costi di trasferimento dei dati per il carico di lavoro. Calcola i costi di trasferimento dei dati a diversi livelli di utilizzo, ipotizzando incrementi e riduzioni dell'utilizzo del carico di lavoro. Nei casi in cui sono disponibili più opzioni per l'architettura del carico di lavoro valuta i costi di ogni opzione per il confronto. 
+  **Collegamento dei costi ai risultati:** per il costo sostenuto per ogni trasferimento dei dati, specifica il risultato ottenuto per il carico di lavoro. Se si tratta di un trasferimento tra componenti potrebbe trattarsi di una necessità di disaccoppiamento, se si tratta di un trasferimento tra zone di disponibilità potrebbe trattarsi di una necessità di ridondanza. 
+  **Creazione della modellazione per il trasferimento dei dati:** dopo aver acquisito tutte le informazioni, crea una base concettuale di modellazione del trasferimento dei dati per più casi d'uso e diversi carichi di lavoro. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Soluzioni di memorizzazione nella cache di AWS](https://aws.amazon.com/caching/aws-caching/) 
+  [Prezzi di AWS](https://aws.amazon.com/pricing/) 
+  [Prezzi di Amazon EC2](https://aws.amazon.com/ec2/pricing/on-demand/) 
+  [Prezzi di Amazon VPC](https://aws.amazon.com/vpc/pricing/) 
+ [Introduzione ai costi di trasferimento dei dati](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html)

 **Video correlati:** 
+ [Monitoring and Optimizing Your Data Transfer Costs](https://www.youtube.com/watch?v=UjliYz25_qo)
+ [ Introduction to Amazon S3 Transfer Acceleration ](https://youtu.be/J2CVnmUWSi4)

 **Esempi correlati:** 
+ [ Panoramica dei costi di trasferimento dei dati per architetture comuni ](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [Guida prescrittiva di AWS per le reti](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortDate&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23network&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all)

# COST08-BP02 Selezione dei componenti per ottimizzare il costo di trasferimento dei dati
<a name="cost_data_transfer_optimized_components"></a>

 Tutti i componenti sono selezionati e l'architettura è progettata per ridurre i costi di trasferimento dei dati. Questo include l'utilizzo di componenti come l'ottimizzazione WAN e le configurazioni Multi-AZ 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Una progettazione basata sul trasferimento dei dati riduce i costi del trasferimento stesso. Potrebbe implicare l'uso di reti di distribuzione di contenuti per posizionare i dati vicino agli utenti, oppure l'uso di collegamenti di rete dedicati dalle tue sedi ad AWS. Puoi anche utilizzare l'ottimizzazione WAN e l'ottimizzazione delle applicazioni per ridurre la quantità di dati trasferiti tra i componenti. 

 Quando si trasferiscono dati verso il Cloud AWS o al suo interno, è essenziale conoscere la destinazione in base a vari casi d'uso, alla natura dei dati e alle risorse di rete disponibili al fine di selezionare i servizi AWS corretti per ottimizzare il trasferimento dei dati. AWS offre una gamma di servizi personalizzati per le diverse esigenze di migrazione dei dati. Seleziona le opzioni di [archiviazione dei dati](https://aws.amazon.com/products/storage/) e [trasferimento dei dati](https://aws.amazon.com/cloud-data-migration/) corrette in base alle esigenze aziendali della tua organizzazione. 

 Quando pianifichi o rivedi l'architettura di un carico di lavoro, considera quanto segue: 
+  **Usa gli endpoint VPC in AWS:** gli endpoint VPC consentono connessioni private tra il VPC e i servizi AWS supportati. Ciò consente di evitare l'utilizzo della rete Internet pubblica, che può comportare costi di trasferimento dei dati. 
+  **Usa un gateway NAT:** utilizza un [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) in modo che le istanze in una sottorete privata possano connettersi a Internet o ai servizi esterni al tuo VPC. Verifica se le risorse dietro il gateway NAT che inviano la maggior parte del traffico si trovano nella stessa zona di disponibilità del gateway NAT. In caso negativo, crea nuovi gateway NAT nella stessa zona di disponibilità della risorsa per ridurre i costi di trasferimento dei dati tra zone di disponibilità. 
+  L'**uso di AWS Direct Connect** Direct Connect ignora la rete Internet pubblica e stabilisce una connessione privata diretta tra la rete locale e AWS. Ciò può essere più conveniente e coerente rispetto al trasferimento di grandi volumi di dati su Internet. 
+  **Evita il trasferimento di dati oltre i confini regionali:** i trasferimenti di dati tra Regioni AWS (da una regione all'altra) in genere sono a pagamento. Seguire questo approccio basato sul trasferimento tra regioni dovrebbe essere una decisione molto ponderata. Per maggiori dettagli, consulta [Scenari multi-regione](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/multi-region-scenarios.html). 
+  **Monitora il trasferimento dei dati:** utilizza Amazon CloudWatch e i [log dei flussi VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) per acquisire dettagli sul trasferimento dei dati e sull'utilizzo della rete. Analizza le informazioni sul traffico di rete acquisite nei tuoi VPC, come l'indirizzo IP o l'intervallo a livello di interfacce di rete. 
+  **Analizza l'utilizzo della rete:** utilizza strumenti di misurazione e segnalazione come AWS Cost Explorer, i dashboard CUDOS o CloudWatch, per analizzare il costo del trasferimento dei dati del tuo carico di lavoro. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Seleziona i componenti per il trasferimento dei dati:** utilizzando la modellazione per il trasferimento dei dati descritta in [COST08-BP01 Esecuzione della modellazione del trasferimento dei dati](cost_data_transfer_modeling.md), concentrati su dove si trovano i costi di trasferimento dei dati più elevati o dove sarebbero se l'utilizzo del carico di lavoro cambiasse. Individua architetture alternative o componenti aggiuntivi che eliminano o riducono la necessità di trasferimento dei dati o ne riducono i costi. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+  [COST08-BP01 Esecuzione della modellazione del trasferimento dei dati](cost_data_transfer_modeling.md) 
+  [COST08-BP03 Implementazione dei servizi per ridurre il costo di trasferimento dei dati](cost_data_transfer_implement_services.md) 

 **Documenti correlati:** 
+ [ Migrazione cloud dei dati ](https://aws.amazon.com/cloud-data-migration/)
+  [Soluzioni di memorizzazione nella cache di AWS](https://aws.amazon.com/caching/aws-caching/) 
+  [Distribuisci contenuti più rapidamente con Amazon CloudFront](https://aws.amazon.com/getting-started/tutorials/deliver-content-faster/) 

 **Esempi correlati:** 
+ [ Panoramica dei costi di trasferimento dei dati per architetture comuni ](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [Suggerimenti per l'ottimizzazione della rete AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [ Ottimizzazione delle prestazioni e riduzione dei costi per l'analisi della rete con log di flusso VPC in formato Apache Parquet ](https://aws.amazon.com/blogs/big-data/optimize-performance-and-reduce-costs-for-network-analytics-with-vpc-flow-logs-in-apache-parquet-format/)

# COST08-BP03 Implementazione dei servizi per ridurre il costo di trasferimento dei dati
<a name="cost_data_transfer_implement_services"></a>

 Implementa i servizi per ridurre il costo di trasferimento dei dati. Ad esempio, utilizza edge location o reti per la distribuzione di contenuti (CDN) per fornire contenuti agli utenti finali, crea livelli di memorizzazione nella cache davanti ai database o ai server delle applicazioni e utilizza connessioni di rete dedicate anziché VPN per la connettività al cloud. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Esistono diversi servizi AWS che possono aiutarti a ottimizzare l'utilizzo del trasferimento dei dati di rete. A seconda dei componenti del carico di lavoro, del tipo e dell'architettura cloud, questi servizi possono aiutarti nella compressione, nella memorizzazione nella cache, nella condivisione e distribuzione del traffico sul cloud. 
+  [Amazon CloudFront](https://aws.amazon.com/cloudfront/) è una rete globale di distribuzione di contenuti che trasferisce i dati con una latenza ridotta e una velocità di trasferimento elevata. Cattura i dati nelle posizioni edge di tutto il mondo, riducendo così il carico sulle tue risorse. Utilizzando CloudFront puoi ridurre l'impegno amministrativo legato alla distribuzione dei contenuti per numeri elevati di utenti a livello globale, con una latenza minima. Al [security savings bundle](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/?sc_channel=em&sc_campaign=Launch_mult_OT_awsroadmapemail_20200910&sc_medium=em_whats_new&sc_content=launch_ot_ot&sc_country=mult&sc_geo=mult&sc_category=mult&sc_outcome=launch) può aiutarti a risparmiare fino al 30% sull'utilizzo di CloudFront se prevedi di aumentarlo nel tempo. 
+  [AWS Direct Connect](https://aws.amazon.com/directconnect/) ti consente di creare una connessione di rete dedicata ad AWS. In questo modo puoi ridurre i costi di rete, aumentare la larghezza di banda e offrire un'esperienza di rete più costante rispetto alle connessioni Internet. 
+  [Site-to-Site VPN](https://aws.amazon.com/vpn/) consente di stabilire una connessione sicura e privata tra la rete privata e la rete globale AWS. È ideale per piccoli uffici o partner aziendali perché offre una connettività semplificata ed è un servizio completamente gestito ed elastico. 
+  [Endpoint VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) consentono la connettività tra i servizi AWS su reti private e possono essere utilizzati per ridurre i costi di trasferimento di dati pubblici e dei costi dei [Gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) . [Gli endpoint VPC del gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-gateway.html) non prevedono tariffe orarie e supportano Amazon S3 e Amazon DynamoDB. [Gli endpoint VPC dell'interfaccia](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) sono forniti da [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) e prevedono una tariffa oraria e un costo di utilizzo per GB. 
+  [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) offrono scalabilità e gestione integrate che riducono i costi rispetto a un'istanza NAT autonoma. Per ridurre i costi di trasferimento ed elaborazione dei dati, posiziona i gateway NAT nelle stesse zone di disponibilità delle istanze a elevato traffico e valuta la possibilità di utilizzare gli endpoint VPC per le istanze che devono accedere a Amazon DynamoDB o Amazon S3. 
+  utilizza [AWS Snow Family](https://aws.amazon.com/snow/) dispositivi che dispongono di risorse di calcolo per raccogliere ed elaborare dati all'edge. Dispositivi AWS Snow Family ([Snowball Edge](https://aws.amazon.com/snowcone/), [Snowball Edge](https://aws.amazon.com/snowball/) e [Snowmobile](https://aws.amazon.com/snowmobile/)) consentono di spostare petabyte di dati a Cloud AWS in modo conveniente e offline. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Implementa i servizi:** Seleziona i servizi di rete di AWS applicabili in base al servizio e al tipo di carico di lavoro utilizzando la modellazione del trasferimento dei dati e la revisione dei log di flusso VPC. Scopri dove si trovano i costi maggiori e i flussi con volumi più elevati. Esamina i servizi AWS e valuta se esiste un servizio che riduce o rimuove il trasferimento, in particolare nell'ambito delle reti e della distribuzione di contenuti. Individua anche servizi di caching in cui si verifica un accesso ripetuto ai dati o in cui sono presenti grandi quantità di dati. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Direct Connect](https://aws.amazon.com/directconnect/) 
+  [Esplora i prodotti AWS](https://aws.amazon.com/) 
+  [Soluzioni di memorizzazione nella cache AWS](https://aws.amazon.com/caching/aws-caching/) 
+  [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 
+  [AWS Snow Family](https://aws.amazon.com/snow/) 
+  [Amazon CloudFront Security Savings Bundle](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/) 

 **Video correlati:** 
+  [Monitoring and Optimizing Your Data Transfer Costs](https://www.youtube.com/watch?v=UjliYz25_qo) 
+  [AWS Cost Optimization Series: CloudFront](https://www.youtube.com/watch?v=k8De2AfAN3k) 
+  [How can I reduce data transfer charges for my NAT gateway?](https://www.youtube.com/watch?v=hq4KtPRezus) 

 **Esempi correlati:** 
+  [How-to chargeback shared services: An AWS Transit Gateway example](https://aws.amazon.com/blogs/aws-cloud-financial-management/gs-chargeback-shared-services-an-aws-transit-gateway-example/) 
+  [Understand AWS data transfer details in depth from cost and usage report using Athena query and QuickSight](https://aws.amazon.com/blogs/networking-and-content-delivery/understand-aws-data-transfer-details-in-depth-from-cost-and-usage-report-using-athena-query-and-quicksight/) 
+  [Panoramica dei costi di trasferimento dei dati per architetture comuni](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/) 
+  [Using AWS Cost Explorer to analyze data transfer costs](https://aws.amazon.com/blogs/mt/using-aws-cost-explorer-to-analyze-data-transfer-costs/) 
+  [Cost-Optimizing your AWS architectures by utilizing Amazon CloudFront features](https://aws.amazon.com/blogs/networking-and-content-delivery/cost-optimizing-your-aws-architectures-by-utilizing-amazon-cloudfront-features/) 
+  [How can I reduce data transfer charges for my NAT gateway?](https://aws.amazon.com/premiumsupport/knowledge-center/vpc-reduce-nat-gateway-transfer-costs/) 

# Gestione delle risorse di domanda e offerta
<a name="a-manage-demand-and-supply-resources"></a>

**Topics**
+ [COST 9. Come gestisci la domanda e fornisci le risorse?](cost-09.md)

# COST 9. Come gestisci la domanda e fornisci le risorse?
<a name="cost-09"></a>

Per avere un carico di lavoro con costo e prestazioni bilanciate, verifica che venga utilizzato tutto ciò per cui paghi ed evita le istanze molto sottoutilizzate. Un parametro di utilizzo distorto, in qualsiasi delle suddette direzioni, ha un impatto negativo sull'organizzazione, sia per i costi operativi (basse prestazioni a causa di un utilizzo eccessivo) che per le spese inerenti a AWS sprecate (a causa di un provisioning eccessivo).

**Topics**
+ [COST09-BP01 Analisi della domanda del carico di lavoro](cost_manage_demand_resources_cost_analysis.md)
+ [COST09-BP02 Implementazione di un buffer o del throttling per gestire la domanda](cost_manage_demand_resources_buffer_throttle.md)
+ [COST09-BP03 Fornitura dinamica delle risorse](cost_manage_demand_resources_dynamic.md)

# COST09-BP01 Analisi della domanda del carico di lavoro
<a name="cost_manage_demand_resources_cost_analysis"></a>

 Analizza la domanda del carico di lavoro nel tempo. Verifica che l'analisi copra l'andamento stagionale e rappresenti accuratamente le condizioni operative per l'intera durata del carico di lavoro. L'attività di analisi deve riflettere i potenziali benefici, ad esempio che il tempo speso sia proporzionale al costo del carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** alto 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 L'analisi della domanda di carichi di lavoro per il cloud computing implica la comprensione dei modelli e delle caratteristiche delle attività di elaborazione avviate nell'ambiente cloud. Questa analisi aiuta gli utenti a ottimizzare l'allocazione delle risorse, gestire i costi e verificare che le prestazioni soddisfino i livelli richiesti. 

 Conoscere i requisiti del carico di lavoro. I requisiti dell'organizzazione devono indicare i tempi di risposta del carico di lavoro per le richieste. Il tempo di risposta può essere utilizzato per determinare se la domanda è gestita o se l'offerta di risorse cambierà per soddisfare la domanda. 

 L'analisi deve includere la prevedibilità e la ripetibilità della domanda, la velocità di variazione della domanda e la quantità di variazione della domanda. Esegui l'analisi per un periodo sufficientemente lungo da incorporare qualsiasi variazione stagionale, ad esempio l'elaborazione di fine mese o i picchi legati alle festività. 

 Lo sforzo di analisi dovrebbe riflettere i potenziali vantaggi dell'implementazione della scalabilità. Osserva il costo totale previsto del componente ed eventuali aumenti o riduzioni di utilizzo e costi durante il ciclo di vita del carico di lavoro. 

 Di seguito sono riportati alcuni aspetti chiave da prendere in considerazione quando si esegue l'analisi della domanda del carico di lavoro per il cloud computing: 

1.  **Metriche relative all'utilizzo delle risorse e alle prestazioni**: analizza come vengono utilizzate le risorse AWS nel tempo. Determina i modelli di utilizzo di picco e non di picco per ottimizzare l'allocazione delle risorse e le strategie di dimensionamento. Monitora i parametri metriche delle prestazioni come tempi di risposta, latenza, throughput e tassi di errore. Queste metriche aiutano a valutare lo stato e l'efficienza complessive dell'infrastruttura cloud. 

1.  **Comportamento di scalabilità di utenti e applicazioni**: comprendi il comportamento degli utenti e come influisce sulla domanda del carico di lavoro. L'esame dei modelli di traffico degli utenti aiuta a migliorare la fornitura di contenuti e la reattività delle applicazioni. Analizza la modalità di dimensionamento dei carichi di lavoro in base all'aumento della domanda. Determina se i parametri di dimensionamento automatico sono configurati correttamente ed efficacemente per gestire le fluttuazioni del carico. 

1.  **Tipi di carico di lavoro**: identifica i diversi tipi di carichi di lavoro in esecuzione nel cloud, come l'elaborazione in batch, l'elaborazione dei dati in tempo reale, le applicazioni web, i database o i processi di machine learning. Ogni tipo di carico di lavoro può avere requisiti di risorse e profili di prestazioni diversi. 

1.  **Accordi sul livello di servizio (SLA)**: confronta le prestazioni effettive con gli SLA per garantire la conformità e identificare le aree che necessitano di miglioramento. 

 Puoi utilizzare [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) per raccogliere e tenere traccia dei parametri, monitorare i file di log, impostare avvisi e reagire automaticamente ai cambiamenti nelle tue risorse AWS. Puoi anche utilizzare Amazon CloudWatch per ottenere visibilità a livello di sistema su utilizzo delle risorse, prestazioni delle applicazioni e stato di integrità operativa. 

 con [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/), puoi rendere disponibili le tue risorse seguendo le best practice per migliorare le prestazioni e l'affidabilità del sistema, aumentare la sicurezza e trovare opportunità di risparmio di denaro. Puoi anche disattivare le istanze non di produzione e utilizzare Amazon CloudWatch e Auto Scaling per far fronte agli aumenti o alle riduzioni della domanda. 

 Infine, puoi usare [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) oppure [Quick](https://aws.amazon.com/quicksight/) con il file AWS Cost and Usage Report CUR o i log delle applicazioni per eseguire un'analisi avanzata della domanda del carico di lavoro. 

 Nel complesso, un'analisi completa della domanda dei carichi di lavoro consente alle organizzazioni di prendere decisioni informate sul provisioning, la scalabilità e l'ottimizzazione delle risorse, con conseguente miglioramento delle prestazioni, dell'efficienza dei costi e della soddisfazione degli utenti. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  **Analizza i dati del carico di lavoro esistenti:** Analizza i dati provenienti dal carico di lavoro esistente, dalle versioni precedenti del carico di lavoro o dai modelli di utilizzo previsti. Utilizza Amazon CloudWatch, i file di log e i dati di monitoraggio per ottenere informazioni dettagliate su come è stato utilizzato il carico di lavoro. Analizza un ciclo completo del carico di lavoro e raccogli i dati per eventuali variazioni stagionali, ad esempio eventi di fine mese o di fine anno. L'attività che emerge dall'analisi deve riflettere le caratteristiche del carico di lavoro. L'impegno maggiore dovrebbe riguardare i carichi di lavoro di alto valore che presentano le maggiori variazioni della domanda. Il minimo impegno dovrebbe riguardare carichi di lavoro di basso valore che hanno variazioni minime nella domanda. 
+  **Esegui previsioni dell'influenza dei fattori esterni:** Incontra i membri del team di tutta l'organizzazione che possono influenzare o modificare la domanda del carico di lavoro. I team più comuni sono le vendite, il marketing o il business development. Collabora con loro per conoscere i cicli secondo cui operano e se ci sono eventi che potrebbero modificare la domanda del carico di lavoro. Prevedi la richiesta del carico di lavoro con questi dati. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 
+  [AWS X-Ray](https://aws.amazon.com/xray/) 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) 
+  [Nozioni di base su Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) 
+  [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 
+  [Quick](https://aws.amazon.com/quicksight/) 

 **Video correlati:** 

 **Esempi correlati:** 
+  [Monitor, Track and Analyze for cost optimization](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/monitor-track-and-analyze/) 
+  [Searching and analyzing logs in CloudWatch](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-search-analysis.html) 

# COST09-BP02 Implementazione di un buffer o del throttling per gestire la domanda
<a name="cost_manage_demand_resources_buffer_throttle"></a>

 Buffering e throttling modificano la domanda sul carico di lavoro, attenuando eventuali picchi. Implementa il throttling quando i client eseguono nuovi tentativi. Implementa il buffering per archiviare la richiesta e rinviare l'elaborazione a un secondo momento. Verifica che le esecuzioni di throttling e buffering siano progettate in modo che i client ricevano una risposta nel tempo richiesto. 

 **Livello di rischio associato alla mancata adozione di questa best practice:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 L'implementazione di un buffer o di una limitazione della larghezza di banda della rete è fondamentale nel cloud computing per gestire la domanda e ridurre la capacità allocata richiesta per il carico di lavoro. Per ottenere prestazioni ottimali, è essenziale valutare la domanda totale, compresi i picchi, la velocità con cui variano le richieste e il tempo di risposta necessario. Quando i client hanno la possibilità di inviare nuovamente le proprie richieste, conviene applicare la limitazione della larghezza di banda della rete. Al contrario, per i client che non dispongono della funzionalità di esecuzione di nuovi tentativi, l'approccio ideale è implementare una soluzione buffer. Tali buffer semplificano l'afflusso di richieste e ottimizzano l'interazione delle applicazioni con diverse velocità operative. 

![\[Demand curve with two distinct peaks that require high provisioned capacity\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/provisioned-capacity-1.png)


 Supponiamo che un carico di lavoro sia caratterizzato dalla curva della domanda illustrata nella figura precedente. Questo carico di lavoro presenta due picchi e per gestire tali picchi viene eseguito il provisioning della capacità di risorse mostrata dalla linea arancione. Le risorse e l'energia utilizzate per questo carico di lavoro non sono indicate nell'area sotto la curva della domanda, ma nell'area sotto la linea della capacità allocata, poiché per gestire questi due picchi è necessario eseguire il provisioning di tale capacità. Diminuire la curva della domanda del carico di lavoro può aiutarti a ridurre la capacità fornita tramite provisioning di un carico di lavoro, oltre al suo impatto sull'ambiente. Per attenuare il picco, valuta la possibilità di implementare una soluzione basata sulla limitazione della larghezza di banda della rete o sul buffering. 

 Per comprendere meglio queste due soluzioni, proviamo ad analizzarle. 

 **Limitazione della larghezza di banda della rete:** se l'origine della richiesta dispone di funzionalità di ripetizione dei tentativi, è possibile implementare la limitazione della larghezza di banda della rete. La limitazione della larghezza di banda della rete indica all'origine che, se non è in grado di soddisfare la richiesta all'ora corrente, dovrebbe riprovare più tardi. L'origine attende un periodo di tempo, quindi riprova a eseguire la richiesta. L'implementazione del throttling ha il vantaggio di limitare la quantità massima di risorse e i costi del carico di lavoro. In AWS, puoi usare [Amazon API Gateway](https://aws.amazon.com/api-gateway/) per implementare la limitazione della larghezza di banda della rete. 

 **Basato sul buffering:** un approccio basato sul buffering utilizza *produttori* (componenti che inviano messaggi alla coda), *consumatori* (componenti che ricevono messaggi dalla coda) e una *coda* (che contiene i messaggi) per archiviare i messaggi. I messaggi vengono letti ed elaborati dai consumatori e ciò consente ai messaggi di essere eseguiti alla velocità che soddisfa i requisiti aziendali del consumatore stesso. Utilizzando una metodologia basata sul buffering, i messaggi dei produttori sono ospitati in code o flussi, dove i produttori possono accedervi a un ritmo in linea con le rispettive esigenze operative. 

In AWS, puoi scegliere tra più servizi per implementare un approccio basato sul buffering. [Amazon Simple Queue Service(Amazon SQS)](https://aws.amazon.com/sqs/) è un servizio gestito che fornisce code che consentono a un singolo utente di leggere singoli messaggi. [Amazon Kinesis](https://aws.amazon.com/kinesis/) fornisce un flusso che consente a molti utenti di leggere gli stessi messaggi.

 Il buffering e la limitazione della larghezza di banda della rete possono attenuare eventuali picchi modificando la domanda sul carico di lavoro. Usa la limitazione della larghezza di banda della rete quando i client riprovano le azioni e usa il buffering per bloccare la richiesta ed elaborarla in un secondo momento. Durante l'utilizzo dell'approccio basato sul buffering, assicurati di progettare il carico di lavoro per soddisfare la richiesta nel tempo richiesto e verifica di essere in grado di gestire le richieste duplicate. Analizza la domanda complessiva, la velocità di modifica e il tempo di risposta richiesto per determinare le dimensioni del throttling o del buffer richiesto. 

### Passaggi dell'implementazione
<a name="implementation-steps"></a>
+ **Analisi dei requisiti del client:** analizza le richieste del client per determinare se sono in grado di eseguire nuovi tentativi. Per i client che non possono eseguire nuovi tentativi, è necessario implementare i buffer. Analizza la domanda complessiva, la velocità di modifica e il tempo di risposta richiesto per determinare le dimensioni del throttling o del buffer richiesto.
+ **Implementazione di un buffer o della limitazione della larghezza di banda della rete:** implementa un buffer o la limitazione della larghezza di banda della rete nel carico di lavoro. Una coda come Amazon Simple Queue Service (Amazon SQS) può offrire un buffer ai componenti del carico di lavoro. Amazon API Gateway può fornire una funzionalità di throttling ai componenti del carico di lavoro. 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [SUS02-BP06 Implementazione del buffering o della limitazione (della larghezza di banda della rete) per ridurre la curva della domanda](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a7.html)
+ [REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)

 **Documenti correlati:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) 
+  [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 
+  [Amazon Simple Queue Service](https://aws.amazon.com/sqs/) 
+  [Nozioni di base su Amazon SQS](https://aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) 
+  [Amazon Kinesis](https://aws.amazon.com/kinesis/) 

 **Video correlati:** 
+ [ Scegliere il servizio di messaggistica corretto per l'app distribuita ](https://www.youtube.com/watch?v=4-JmX6MIDDI)

 **Esempi correlati:** 
+ [ Gestione e monitoraggio della limitazione delle API nei carichi di lavoro ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Throttling a tiered, multi-tenant REST API at scale using API Gateway ](https://aws.amazon.com/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-scale-using-api-gateway-part-1/)
+ [ Enabling Tiering and Throttling in a Multi-Tenant Amazon EKS SaaS Solution Using Amazon API Gateway ](https://aws.amazon.com/blogs/apn/enabling-tiering-and-throttling-in-a-multi-tenant-amazon-eks-saas-solution-using-amazon-api-gateway/)
+ [ Integrazione dell'applicazione con code e messaggi ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)

# COST09-BP03 Fornitura dinamica delle risorse
<a name="cost_manage_demand_resources_dynamic"></a>

Viene eseguito il provisioning delle risorse in modo pianificato. La pianificazione può essere basata sulla domanda, ad esempio tramite il dimensionamento automatico, oppure sul tempo, quando la domanda è prevedibile e le risorse sono fornite in base al tempo. Questi metodi comportano la minore quantità possibile di provisioning in eccesso o in difetto.

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Esistono diversi modi in cui i clienti AWS possono aumentare le risorse disponibili per le proprie applicazioni e fornire risorse per soddisfare la domanda. Una di queste opzioni consiste nell'utilizzare AWS Instance Scheduler, che automatizza l'avvio e l'arresto delle istanze Amazon Elastic Compute Cloud (Amazon EC2) e Amazon Relational Database Service (Amazon RDS). L'altra opzione è utilizzare AWS Auto Scaling, che consente di dimensionare automaticamente le risorse di calcolo in base alla richiesta dell'applicazione o del servizio. Fornire risorse in base alla domanda ti consentirà di pagare solo per le risorse che usi, di ridurre i costi lanciando le risorse quando sono necessarie e di interromperle quando non servono più. 

 [AWS Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/) consente di configurare l'arresto e l'avvio delle istanze Amazon EC2 e Amazon RDS a orari definiti, in modo da poter soddisfare la domanda delle stesse risorse secondo uno schema orario coerente, ad esempio ogni giorno gli utenti accedono alle istanze Amazon EC2 alle otto del mattino che non servono dopo le sei di sera. Questa soluzione aiuta a ridurre i costi operativi arrestando le risorse inutilizzate e avviandole quando sono necessarie. 

![\[Diagramma che mostra l'ottimizzazione dei costi mediante AWS Instance Scheduler.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/instance-scheduler-diagram.png)


 

Puoi anche configurare in modo semplice e rapido le pianificazioni per le tue istanze Amazon EC2 nei tuoi account e nelle tue Regioni con un'interfaccia utente (UI) utilizzando Configurazione rapida di AWS Systems Manager. Puoi pianificare le istanze Amazon EC2 e Amazon RDS con AWS Instance Scheduler e arrestare e avviare le istanze esistenti. Tuttavia, non è possibile arrestare e avviare le istanze che fanno parte del proprio gruppo (ASG) Auto Scaling o che gestiscono servizi come Amazon Redshift o Amazon OpenSearch Service. I gruppi Auto Scaling hanno una propria pianificazione per le istanze del gruppo e queste istanze vengono create. 

[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) ti aiuta a regolare la capacità per mantenere prestazioni stabili e prevedibili al minor costo possibile per soddisfare le mutevoli esigenze. È un servizio gratuito e completamente gestito per il dimensionamento della capacità della tua applicazione, che si integra con le istanze Amazon EC2 e le serie di istanze spot, Amazon ECS, Amazon DynamoDB e Amazon Aurora. Auto Scaling fornisce il rilevamento automatico delle risorse per identificare risorse configurabili nel carico di lavoro, dispone di strategie di dimensionamento integrate volte a ottimizzare le prestazioni, i costi, o trovare un equilibrio tra i due, e fornisce il dimensionamento predittivo per risolvere i picchi ricorrenti con regolarità. 

 Sono disponibili diverse opzioni di dimensionamento per dimensionare il tuo gruppo Auto Scaling: 
+  Conservazione dei livelli correnti di istanze in ogni momento 
+  Dimensionamento manuale 
+  Dimensionamento basato su una pianificazione 
+  Dimensionamento basato sulla domanda 
+  Utilizzo del dimensionamento predittivo 

 Le policy Auto Scaling sono diverse e possono essere classificate come policy di dimensionamento dinamico e pianificato. Le policy dinamiche fanno riferimento al dimensionamento manuale o dinamico, programmato o predittivo. È possibile utilizzare le policy di dimensionamento per il dimensionamento dinamico, pianificato e predittivo. Puoi anche utilizzare le metriche e gli allarmi di [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) per attivare eventi di dimensionamento per il tuo carico di lavoro. Ti consigliamo di utilizzare i [modelli di avvio](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html), che consentono di accedere alle funzionalità e ai miglioramenti più recenti. Non tutte le funzionalità Auto Scaling sono disponibili quando si utilizzano le configurazioni di avvio. Ad esempio, non è possibile creare un gruppo Auto Scaling che avvii istanze spot e on demand o che specifichi più tipi di istanze. È necessario utilizzare un modello di avvio per configurare queste funzionalità. Quando utilizzi i modelli di avvio, ti consigliamo di modificare ciascuno di essi. Con il controllo delle versioni dei modelli di avvio, puoi creare un sottoinsieme del set completo di parametri. Quindi, puoi riutilizzarlo per creare altre versioni dello stesso modello di avvio. 

 Puoi utilizzare AWS Auto Scaling o incorporare il dimensionamento nel codice con [API o SDK AWS](https://aws.amazon.com/developer/tools/). Ciò riduce i costi complessivi del carico di lavoro rimuovendo i costi operativi dall'apportare manualmente modifiche al tuo ambiente; le modifiche possono essere apportate molto più rapidamente. In questo modo, inoltre, il carico di lavoro viene adattato alla domanda in qualsiasi momento. Per seguire questa best practice e fornire risorse in modo dinamico all'organizzazione, è necessario comprendere il dimensionamento orizzontale e verticale in Cloud AWS e la natura delle applicazioni in esecuzione sulle istanze Amazon EC2. È meglio che il team di Cloud Financial Management collabori con i team tecnici per seguire questa best practice. 

 [Elastic Load Balancing (Elastic Load Balancing)](https://aws.amazon.com/elasticloadbalancing/) consente di ricalibrare le risorse distribuendo la domanda su più risorse. Utilizzando ASG e Elastic Load Balancing, puoi gestire le richieste in arrivo ottimizzando l'instradamento del traffico in modo che nessuna istanza venga sovraccaricata in un gruppo Auto Scaling. Le richieste vengono distribuite tra tutti gli obiettivi di un gruppo target in modalità Round Robin, senza tenere conto della capacità o dell'utilizzo. 

 Le metriche tipiche possono essere metriche standard di Amazon EC2, ad esempio l'utilizzo della CPU, la velocità di trasmissione effettiva della rete e la latenza di richiesta/risposta osservata da Elastic Load Balancing. Quando possibile, è consigliabile utilizzare un parametro indicativo dell'esperienza del cliente, in genere si tratta di un parametro personalizzato che potrebbe avere origine dal codice dell'applicazione all'interno del carico di lavoro. Per capire come soddisfare la domanda in modo dinamico in questo documento, Auto Scaling verrà suddiviso in due categorie (modello di fornitura basata sulla domanda e modello di fornitura basata sul tempo) e verrà approfondito ciascun modello. 

**Fornitura basata sulla domanda:** sfrutta l'elasticità del cloud per fornire risorse in grado di soddisfare la domanda in continua evoluzione facendo riferimento allo stato della domanda quasi in tempo reale. Per la fornitura basata sulla domanda, utilizza API o funzionalità dei servizi per modificare in modo programmatico la quantità di risorse del cloud nella tua architettura. Ciò ti consente di dimensionare i componenti nella tua architettura e aumentare il numero di risorse durante i picchi di domanda per mantenere le prestazioni, nonché diminuire la capacità quando la domanda cala in modo da ridurre i costi. 

![\[Diagramma che descrive le policy di dimensionamento basato sulla domanda, come il dimensionamento semplice/graduale e il monitoraggio degli obiettivi.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/demand-based-supply.png)


 
+  **Dimensionamento semplice/graduale:** monitora le metriche e aggiunge/rimuove le istanze secondo i passaggi definiti manualmente dai clienti. 
+  **Monitoraggio degli obiettivi:** meccanismo di controllo simile a un termostato che aggiunge o rimuove automaticamente le istanze per mantenere le metriche in base a un obiettivo definito dal cliente. 

Quando prevedi di usare una strategia basata sulla domanda in un progetto, tieni presenti due considerazioni principali. In primo luogo, devi capire con quale velocità è necessario predisporre le nuove risorse. In secondo luogo, devi capire che la dimensione del margine tra domanda e risorse fornite cambierà. Devi prepararti ad affrontare le variazioni nella domanda, nonché le risorse insufficienti.

**Fornitura basata sul tempo:** una strategia basata sul tempo allinea la capacità delle risorse alla domanda, che è prevedibile o ben definita nel tempo. In genere questa strategia non dipende dai livelli di utilizzo delle risorse. Una strategia basata sul tempo assicura che le risorse siano disponibili nel momento esatto in cui vengono richieste e possano essere fornite senza ritardi dovuti alle procedure di avvio e ai controlli di sistema o di coerenza. Attraverso una strategia basata sul tempo si possono fornire risorse aggiuntive o incrementare la capacità nei periodi più intensi.

![\[Diagramma che descrive le policy di dimensionamento basato sul tempo, come il dimensionamento programmato e predittivo.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/time-based-supply.png)


 

Puoi utilizzare il dimensionamento automatico pianificato e predittivo per implementare un approccio basato sul tempo. I carichi di lavoro possono essere programmati per eseguire il dimensionamento in determinati momenti (ad esempio, all'inizio dell'orario di lavoro), garantendo quindi la disponibilità delle risorse all'arrivo degli utenti on demand. Il dimensionamento predittivo utilizza modelli per dimensionare orizzontalmente, mentre il dimensionamento pianificato utilizza tempi predefiniti per dimensionare orizzontalmente. Puoi anche utilizzare la strategia di [selezione del tipo di istanza basata sugli attributi (ABS)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) nei gruppi Auto Scaling che consenta di esprimere i requisiti dell'istanza come un set di attributi, ad esempio vCPU, memoria e spazio di archiviazione. È possibile utilizzare automaticamente i tipi di istanza di nuova generazione quando vengono rilasciati e accedere a una gamma più ampia di capacità con le istanze spot di Amazon EC2. Il parco istanze Amazon EC2 e Amazon EC2 Auto Scaling selezionano e avviano istanze che corrispondono agli attributi specificati, eliminando la necessità di scegliere manualmente i tipi di istanza. 

Puoi anche utilizzare [API e SDK AWS](https://aws.amazon.com/developer/tools/) e [AWS CloudFormation](https://aws.amazon.com/cloudformation/) per predisporre e ritirare automaticamente interi ambienti quando ne hai bisogno. Questa strategia risulta particolarmente adatta per gli ambienti di sviluppo o di prova che operano solo in determinati orari di lavoro o periodi di tempo. Puoi usare le API per dimensionare le risorse all'interno di un ambiente (dimensionamento verticale). Ad esempio, potresti dimensionare verticalmente un carico di lavoro di produzione modificando la dimensione o la classe dell'istanza. Ciò è possibile arrestando e avviando l'istanza e selezionando una dimensione o classe diversa. Questa tecnica può essere applicata anche ad altre risorse, come gli Elastic Volumes Amazon EBS, che possono essere modificati per aumentarne le dimensioni, regolarne le prestazioni (IOPS) o modificare il tipo di volume durante l'utilizzo.

Quando prevedi una strategia basata sul tempo in un progetto, tieni presenti due considerazioni principali. In primo luogo, che livello di coerenza presenta il modello di utilizzo? In secondo luogo, qual è l'impatto se il modello cambia? Puoi migliorare l'accuratezza delle previsioni monitorando i tuoi carichi di lavoro e utilizzando la business intelligence. Se noti cambiamenti significativi nel modello di utilizzo, puoi modificare i tempi per assicurarti che la copertura sia fornita.

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+ ** Configura il dimensionamento pianificato: **per le variazioni prevedibili della domanda, il dimensionamento basato sul tempo può fornire il numero corretto di risorse in modo tempestivo. Inoltre è utile se la creazione e la configurazione delle risorse non sono abbastanza veloci da rispondere alle variazioni della domanda. Utilizzando l'analisi del carico di lavoro, configura il dimensionamento pianificato utilizzando AWS Auto Scaling. Per configurare la pianificazione basata sul tempo, è possibile utilizzare il dimensionamento predittivo del dimensionamento pianificato per aumentare il numero di istanze Amazon EC2 nei gruppi Auto Scaling in anticipo in base alle variazioni di carico previste o prevedibili.
+  **Configura il dimensionamento predittivo:** il dimensionamento predittivo consente di aumentare il numero di istanze Amazon EC2 del gruppo Auto Scaling in anticipo rispetto agli schemi giornalieri e settimanali dei flussi di traffico. Se si hanno picchi di traffico regolari e applicazioni che richiedono molto tempo per avviarsi, si dovrebbe prendere in considerazione l'utilizzo del dimensionamento predittivo. Il dimensionamento predittivo può aiutare a scalare più velocemente inizializzando la capacità prima del carico previsto rispetto al solo dimensionamento dinamico, che è di natura reattiva. Ad esempio, se gli utenti iniziano a utilizzare il carico di lavoro all'inizio dell'orario di lavoro e non lo utilizzano dopo l'orario di lavoro, il dimensionamento predittivo può aggiungere capacità prima dell'orario di lavoro, eliminando i ritardi del dimensionamento dinamico per reagire alle variazioni del traffico. 
+ ** Configura il dimensionamento automatico dinamico: **per configurare il dimensionamento in base alle metriche del carico di lavoro attivo, usa Auto Scaling. Utilizza l'analisi e configura Auto Scaling per l'avvio sui livelli di risorse corretti e assicurati che il carico di lavoro si ridimensioni nel tempo richiesto. Si può avviare e dimensionare automaticamente un parco istanze on demand e istanze spot all'interno di un singolo gruppo Auto Scaling. Oltre a ricevere sconti per l'utilizzo delle istanze spot, è possibile utilizzare istanze riservate o Savings Plans per ricevere tariffe scontate rispetto al normale prezzo delle istanze on demand. La combinazione di tutti questi fattori consente di ottimizzare i risparmi sui costi delle istanze Amazon EC2 e di determinare il dimensionamento e le prestazioni desiderate per la tua applicazione.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) 
+  Dimensiona il tuo gruppo Auto Scaling 
+  [Nozioni di base su Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Nozioni di base su Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) 
+  [Dimensionamento programmato per Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
+ [ Dimensionamento predittivo per Amazon EC2 Auto Scaling ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html)

 **Video correlati:** 
+ [ Policy di dimensionamento del monitoraggio degli obiettivi per Auto Scaling ](https://www.youtube.com/watch?v=-RumeaoPB2M)
+ [AWS Instance Scheduler ](https://www.youtube.com/watch?v=nTLEyo2NzUs)

 **Esempi correlati:** 
+ [ Selezione del tipo di istanza basata sugli attributi per Auto Scaling per il parco istanze Amazon EC2 ](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [ Ottimizzazione dei costi di Amazon Elastic Container Service utilizzando il dimensionamento programmato ](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [ Dimensionamento predittivo con Amazon EC2 Auto Scaling ](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [ Come uso Instance Scheduler con CloudFormation per pianificare le istanze Amazon EC2? ](https://aws.amazon.com/premiumsupport/knowledge-center/stop-start-instance-scheduler/)

# Ottimizzazione nel tempo
<a name="a-optimize-over-time"></a>

**Topics**
+ [COST 10. In che modo valuti i nuovi servizi?](cost-10.md)
+ [COST 11. Come valuti il costo dell'impegno?](cost-11.md)

# COST 10. In che modo valuti i nuovi servizi?
<a name="cost-10"></a>

Nel momento in cui AWS rilascia nuovi servizi e caratteristiche, è buona prassi rivedere le decisioni esistenti relative all'architettura per verificare che continuino a essere le più convenienti.

**Topics**
+ [COST10-BP01 Sviluppo di un processo di revisione del carico di lavoro](cost_evaluate_new_services_review_process.md)
+ [COST10-BP02 Valutazione e analisi regolare del carico di lavoro](cost_evaluate_new_services_review_workload.md)

# COST10-BP01 Sviluppo di un processo di revisione del carico di lavoro
<a name="cost_evaluate_new_services_review_process"></a>

 Sviluppa un processo che definisca i criteri e il processo per la revisione del carico di lavoro. L'impegno analitico deve riflettere il potenziale risultato. Ad esempio, i carichi di lavoro principali o i carichi di lavoro con un valore superiore al 10% della fattura sono analizzati trimestralmente oppure ogni sei mesi, mentre i carichi di lavoro inferiori al 10% sono analizzati annualmente. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Elevato 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Per far sì che il carico di lavoro sia sempre efficiente in termini di costi, devi analizzarlo regolarmente per stabilire se ci sono opportunità di implementare nuovi servizi, funzionalità e componenti. Per garantire costi complessivi ridotti, il processo deve essere proporzionale al potenziale risparmio. Ad esempio, i carichi di lavoro che rappresentano il 50% della spesa complessiva devono essere esaminati con maggiore regolarità e più nel dettaglio rispetto ai carichi di lavoro che rappresentano il 5% della spesa complessiva. Prendi in considerazione qualsiasi fattore esterno o volatilità. Se il carico di lavoro serve una determinata area geografica o un segmento di mercato e viene previsto un cambiamento in tale area, revisioni più frequenti possono portare a risparmi sui costi. Un altro fattore in fase di revisione è rappresentato dall'impegno necessario per implementare le modifiche. Se i test e la convalida delle modifiche comportassero costi significativi, le revisioni dovrebbero essere meno frequenti. 

Prendi in considerazione il costo nel lungo termine della manutenzione di componenti e risorse obsoleti e legacy, e dell'impossibilità di implementare in essi nuove funzionalità. L'attuale costo del test e della convalida potrebbe superare il vantaggio auspicato. Tuttavia, nel corso del tempo, il costo di apportare modifiche potrebbe crescere in modo significativo all'aumentare del divario tra il carico di lavoro e le tecnologie attuali, generando costi ancora maggiori. Ad esempio, il costo del passaggio a un nuovo linguaggio di programmazione potrebbe attualmente non risultare conveniente. Tuttavia, nel giro di cinque anni, il costo del personale qualificato per tale linguaggio potrebbe aumentare e, a causa dell'aumento del carico di lavoro, potresti dover trasferire un sistema ancora più grande al nuovo linguaggio, richiedendo sforzi ancora maggiori rispetto a prima. 

Suddividi il carico di lavoro in componenti, assegna un costo ai componenti (una stima è sufficiente) e quindi elenca i fattori (ad esempio, impegno richiesto e mercati esterni) accanto a ciascun componente. Utilizza questi indicatori per determinare una frequenza di revisione per ogni carico di lavoro. Ad esempio, potresti avere i server web come un costo elevato, con un impegno di modifica ridotto e fattori esterni elevati, e da questo potrebbe derivare un'alta frequenza di revisione. Un database centrale può avere un costo medio, con un impegno di modifica elevato e un basso fattore esterno, e da questo potrebbe derivare una frequenza di revisione media. 

 Definisci un processo per valutare i nuovi servizi, i modelli di progettazione, i tipi di risorse e le configurazioni per ottimizzare il costo del tuo carico di lavoro man mano che diventano disponibili. Simile ai processi di [revisione del principio di performance](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf-06.html) e di [revisione del principio di affidabilità](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_monitor_aws_resources_review_monitoring.html), identifica, convalida e assegna la priorità ad attività di ottimizzazione e miglioramento e alla correzione di problematiche e integra questo nel tuo backlog. 

**Passaggi dell'implementazione**
+  **Definisci la frequenza della revisione: **definisci la frequenza con cui il carico di lavoro e i relativi componenti devono essere revisionati. Dedica tempo e risorse al miglioramento continuo e alla frequenza di revisione per migliorare l'efficienza e l'ottimizzazione del carico di lavoro. Si tratta di una combinazione di fattori e può variare da carico di lavoro a carico di lavoro all'interno dell'organizzazione, ma può anche variare tra i componenti del carico di lavoro. Fattori più comuni sono: l'importanza per l'organizzazione misurata in termini di fatturato o marchio, il costo totale di esecuzione del carico di lavoro (inclusi costi operativi e delle risorse), la complessità del carico di lavoro, la facilità di implementazione di una modifica, eventuali accordi di licenza software e l'eventuale aumento dei costi di licenza dovuti a licenze punitive in seguito a una modifica. I componenti possono essere definiti a livello funzionale o tecnico come server Web e database, oppure come risorse di calcolo e storage. Equilibra i fattori di conseguenza e prevedi un periodo per il carico di lavoro e i relativi componenti. Si può decidere di esaminare l'intero carico di lavoro ogni 18 mesi, esaminare i server Web ogni 6 mesi, il database ogni 12 mesi, l'elaborazione e lo storage a breve termine ogni 6 mesi e lo storage a lungo termine ogni 12 mesi.
+ ** Definisci la completezza della revisione: **stabilisci quanto impegno deve essere impiegato per la revisione dei componenti o dell’intero carico di lavoro. Come per la frequenza di revisione, si tratta di un equilibrio tra più fattori. Valuta e dai priorità alle opportunità di miglioramento per concentrare gli sforzi dove producono i vantaggi maggiori, stimando l'impegno necessario per queste attività. Se i risultati non sono in linea con gli obiettivi e l'impegno richiesto ha un costo superiore, riprova utilizzando linee d'azione alternative. I processi di revisione devono prevedere l'allocazione di tempo e risorse per rendere possibile il miglioramento incrementale continuo. Ad esempio, si può decidere di dedicare una settimana all'analisi del componente del database, una settimana di analisi alle risorse di calcolo e quattro ore alla revisione dell'archiviazione.

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Blog delle novità di AWS](https://aws.amazon.com/blogs/aws/) 
+  [Tipi di cloud computing](https://aws.amazon.com/types-of-cloud-computing/) 
+  [Le novità di AWS](https://aws.amazon.com/new/) 

 **Esempi correlati:** 
+ [ Servizi di supporto proattivo di AWS](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)
+ [ Revisioni costanti dei carichi di lavoro per carichi SAP ](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/best-practice-4-4.html)

# COST10-BP02 Valutazione e analisi regolare del carico di lavoro
<a name="cost_evaluate_new_services_review_workload"></a>

I carichi di lavoro esistenti vengono rivisti con regolarità in base a ogni processo definito per scoprire se è possibile adottare nuovi servizi, se i servizi esistenti possono essere sostituiti o se i carichi di lavoro possono essere riprogettati.

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

AWS aggiunge costantemente nuove funzionalità che ti consentono di innovare e sperimentare in tempi più rapidi con le tecnologie più recenti. [Le novità di AWS](https://aws.amazon.com/new/) spiegano nel dettaglio come AWS sta procedendo in questo senso e offrono una breve panoramica dei servizi AWS, delle funzionalità e degli annunci sulle espansioni a livello regionale nel momento stesso in cui vengono rilasciati. Puoi approfondire i rilasci previsti e usarli per la revisione e l'analisi dei tuoi carichi di lavoro esistenti. Per ottenere i vantaggi offerti dai nuovi servizi e dalle nuove funzionalità di AWS, devi eseguire il processo di revisione sui carichi di lavoro e implementare nuovi servizi e funzionalità in base alle esigenze. Questo significa che potresti aver bisogno di sostituire i servizi esistenti che usi per il tuo carico di lavoro o modernizzare il tuo carico di lavoro per adottare questi nuovi servizi AWS. Ad esempio, puoi esaminare i carichi di lavoro e sostituire il componente di messaggistica con Amazon Simple Email Service. Ciò elimina il costo di gestione e manutenzione di un parco istanze, fornendo al contempo tutte le funzionalità a un costo ridotto. 

 Per analizzare il tuo carico di lavoro e individuare le opportunità potenziali, dovresti prendere in considerazione non solo i nuovi servizi, ma anche le nuove modalità per creare le soluzioni. Guarda i video della serie [Questa è la mia architettura](https://aws.amazon.com/architecture/this-is-my-architecture) su AWS per scoprire progetti architetturali di altri clienti, le sfide affrontate e le soluzioni adottate. Dai un'occhiata alle [serie All-In](https://aws.amazon.com/architecture/all-in-series/) per scoprire le applicazioni nel mondo reale dei servizi AWS e le storie dei clienti. Puoi anche guardare la serie di video [Back to Basics](https://aws.amazon.com/architecture/back-to-basics/) che spiega, esamina e scompone best practice su modelli architetturali cloud di base. Un'altra risorsa è costituita dai video della serie [Come si sviluppa](https://aws.amazon.com/architecture/how-to-build-this/), progettati per assistere le persone con grandi idee su come sviluppare un prodotto minimo funzionante (MVP) avvalendosi dei servizi AWS. È un modo per gli sviluppatori di tutto il mondo con grandi idee di ottenere indicazioni sulle architetture da AWS Solutions Architects esperti. Infine, è possibile consultare i materiali della risorsa [Nozioni di base](https://aws.amazon.com/getting-started/) con tutorial dettagliati. 

 Prima di avviare il processo di revisione segui i requisiti aziendali per il carico di lavoro, i requisiti sulla privacy dei dati e la sicurezza per usare un servizio o un'area geografica specifica e i requisiti di performance, seguendo al tempo stesso il processo di revisione concordato. 

**Passaggi dell'implementazione**
+ ** Esamina con regolarità il carico di lavoro: **utilizzando il processo definito, esegui le revisioni con la frequenza specificata. Accertati di dedicare la quantità di impegno necessaria per ciascun componente. Questo processo è simile a quello di progettazione iniziale in cui hai selezionato i servizi per l'ottimizzazione dei costi. Analizza i servizi e i vantaggi che porterebbero; questa volta considera anche il costo del tempo necessario per la modifica, non solo i vantaggi a lungo termine. 
+ ** Implementa nuovi servizi:** se in seguito all'analisi ritieni di dover implementare modifiche, esegui innanzitutto una baseline del carico di lavoro per scoprire il costo corrente per ogni output. Implementa le modifiche, quindi esegui un'analisi per verificare il nuovo costo per ogni output. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Blog delle novità di AWS](https://aws.amazon.com/blogs/aws/) 
+  [Le novità di AWS](https://aws.amazon.com/new/) 
+ [ Documentazione AWS](https://docs.aws.amazon.com/)
+ [ Nozioni di base su AWS](https://aws.amazon.com/getting-started/)
+ [ Risorse generali su AWS](https://docs.aws.amazon.com/#general_resources)

 **Video correlati:** 
+  [AWS - La mia architettura](https://aws.amazon.com/architecture/this-is-my-architecture) 
+  [AWS - Ripartiamo dall'inizio](https://aws.amazon.com/architecture/back-to-basics/) 
+  [AWS - Serie All-In](https://aws.amazon.com/architecture/all-in-series/) 
+  [Come si sviluppa](https://aws.amazon.com/architecture/how-to-build-this/) 

# COST 11. Come valuti il costo dell'impegno?
<a name="cost-11"></a>

**Topics**
+ [COST11-BP01 Esecuzione di automazioni per le operazioni](cost_evaluate_cost_effort_automations_operations.md)

# COST11-BP01 Esecuzione di automazioni per le operazioni
<a name="cost_evaluate_cost_effort_automations_operations"></a>

 Valuta il costo dell'impegno per le operazioni nel cloud. Quantifica il risparmio in termini di tempi e impegno relativamente alle attività amministrative, alle implementazioni e ad altre operazioni grazie all'automazione. Valuta il tempo richiesto e il costo dell'impegno per le operazioni e automatizza le attività amministrative per ridurre l'intervento umano, laddove possibile. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

 Automatizzando le operazioni è possibile migliorare la consistenza e la scalabilità, offrire più visibilità, affidabilità e flessibilità, ridurre i costi e accelerare l'innovazione liberando il personale e perfezionando le metriche. Questa soluzione riduce la frequenza di attività manuali, migliora l'efficienza e offre vantaggi alle aziende con un'esperienza affidabile e consistente durante l'implementazione, l'amministrazione o l'operatività dei carichi di lavoro. Puoi liberare risorse dell'infrastruttura da attività operative manuali e usarle per attività e innovazioni di maggior valore, migliorando così i risultati aziendali. Le aziende vogliono un modo testato e collaudato di gestire i propri carichi di lavoro nel cloud. La soluzione deve essere sicura, veloce e contenuta nei costi, con rischio minimo e massima affidabilità. 

 Inizia assegnando le priorità alle tue operazioni sulla base dell'impegno richiesto, considerando i costi complessivi delle operazioni nel cloud. Ad esempio, quanto tempo è necessario per distribuire nuove risorse nel cloud, eseguire modifiche di ottimizzazione alle risorse esistenti o implementare le configurazioni necessarie? Esamina il costo totale delle attività eseguite dal personale, tenendo conto dei costi operativi e di gestione. Dai la priorità alle automazioni per le attività amministrative per ridurre il livello di impegno delle persone. L'impegno di revisione deve riflettere il potenziale risultato. Ad esempio, il tempo impiegato per eseguire delle attività manualmente rispetto a quello per eseguirle in automatico. Dai la priorità all'automazione di attività ripetitive e di valore elevato. Le attività che presentano un rischio più elevato di errore umano sono in genere il punto migliore da cui iniziare con l'automazione, poiché il rischio spesso comporta un costo operativo aggiuntivo indesiderato (come gli straordinari del team operativo). 

 Usando i servizi e gli strumenti AWS o i prodotti di terze parti, puoi scegliere quali automazioni AWS implementare e personalizzare per i tuoi requisiti specifici. La tabella seguente mostra alcune delle funzioni e delle caratteristiche operative di base che puoi ottenere con i servizi AWS per automatizzare attività amministrative e operative: 
+  [AWS Audit Manager](https://aws.amazon.com/audit-manager/): esegui un audit continuo del tuo utilizzo di AWS per semplificare la valutazione dei rischi e della conformità 
+  [AWS Backup](https://aws.amazon.com/backup/): gestisci centralmente e automatizza la protezione dei dati. 
+  [AWS Config](https://aws.amazon.com/config/): configura le risorse di elaborazione, valuta, esegui audit e analizza le configurazioni e l'inventario delle risorse. 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/): avvia risorse altamente disponibili con infrastructure as code. 
+  [AWS CloudTrail](https://aws.amazon.com/cloudtrail/): gestione delle modifiche IT, della conformità e del controllo. 
+  [Amazon EventBridge](https://aws.amazon.com/eventbridge/): pianifica gli eventi e attiva AWS Lambda. 
+  [AWS Lambda](https://aws.amazon.com/lambda/): automatizza i processi ripetitivi attivandoli con eventi o eseguendoli sulla base di una pianificazione prefissata con Amazon EventBridge. 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/): avvia e interrompi carichi di lavoro, applica patch ai sistemi operativi, automatizza la configurazione e la gestione continua. 
+  [AWS Step Functions](https://aws.amazon.com/step-functions/): pianifica i processi e automatizza i flussi di lavoro. 
+  [AWS Service Catalog](https://aws.amazon.com/servicecatalog/): utilizzo di modelli e infrastructure as code con conformità e controllo. 

 Considera il risparmio in termini di tempo, che consentirà al tuo team di concentrarsi sull'eliminazione del debito tecnico, sull'innovazione e sulle funzionalità che offrono un valore aggiunto. Ad esempio, potresti avere bisogno di eseguire il rehosting (lift and shift) del tuo ambiente on-premise nel cloud il più rapidamente possibile ed eseguire l'ottimizzazione in un secondo momento. Vale la pena soffermarsi sul risparmio che puoi ottenere usando i servizi gestiti di AWS che rimuovono o riducono i costi di licenza come [Amazon Relational Database Service](https://aws.amazon.com/rds/), [Amazon EMR](https://aws.amazon.com/emr/), [Amazon WorkSpaces](https://aws.amazon.com/workspaces/) e [Amazon SageMaker AI](https://aws.amazon.com/sagemaker/). i servizi gestiti eliminano l'onere operativo e amministrativo legato alla manutenzione di un servizio, consentendoti di concentrarti sull'innovazione. Inoltre, poiché i servizi gestiti operano su scala cloud, possono offrire un costo inferiore per transazione o servizio. 

 Se desideri adottare immediatamente le automazioni usando i prodotti e i servizi AWS, ma non hai le risorse richieste al tuo interno, contatta [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/), [AWS Professional Services](https://aws.amazon.com/professional-services/) o [AWS Partners](https://aws.amazon.com/partners/work-with-partners/) per aumentare l'adozione dell'automazione e migliorare la tua eccellenza operativa nel cloud. 

 [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) è un servizio che gestisce l'infrastruttura AWS per conto di clienti e partner aziendali. Offre un ambiente sicuro e conforme su cui è possibile implementare i carichi di lavoro. AMS utilizza modelli operativi cloud aziendali dotati di automazione per consentirti di soddisfare i requisiti aziendali, di passare più rapidamente al cloud e di ridurre i costi di gestione correnti. 

 [AWS Professional Services](https://aws.amazon.com/professional-services/) può anche aiutarti a raggiungere i risultati aziendali auspicati e ad automatizzare le operazioni con AWS. AWS Professional Services offre linee guida globali di specializzazione a supporto del tuo impegno in aree strategiche del cloud computing aziendale. Le linee guida di specializzazione offrono suggerimenti mirati tramite best practice, framework, strumenti e servizi per soluzioni, tecnologia e aree specifiche di settore. Tali indicazioni aiutano i clienti a implementare operazioni IT automatizzate, solide e agili, nonché funzionalità di governance ottimizzate per il cloud center. 

 **Passaggi dell'implementazione** 
+  **Sviluppa una volta e implementa molte:** usa infrastructure-as-code come AWS CloudFormation, AWS SDK o AWS Command Line Interface (AWS CLI) per implementare una volta e usare molte volte per lo stesso ambiente o per scenari di ripristino di emergenza. Applica tag durante l'implementazione per monitorare il tuo consumo definito in altre best practice. Usa [AWS Launch Wizard](https://aws.amazon.com/launchwizard/) per ridurre i tempi di implementazione di molti carichi di lavoro aziendali diffusi. AWS Launch Wizard ti guida attraverso il dimensionamento, la configurazione e l'implementazione di carichi di lavoro aziendali seguendo le best practice AWS. Puoi anche usare [AWS Service Catalog](https://aws.amazon.com/servicecatalog/), che ti consente di creare e gestire modelli approvati di infrastructure-as-code da usare su AWS in modo che tutti abbiano accesso a risorse cloud self-service e approvate. 
+  **Automatizza le operazioni:** esegui operazioni di routine automaticamente senza l'intervento umano. Usando i servizi e gli strumenti AWS, puoi scegliere quali automazioni AWS implementare e personalizzare per i tuoi requisiti specifici. Ad esempio, usa [EC2 Image Builder](https://aws.amazon.com/image-builder/) per lo sviluppo, il test e l'implementazione di macchine virtuali e immagini di container da usare su AWS oppure on-premise. Se l'azione desiderata non può essere eseguita con i servizi AWS o se hai bisogno di azioni più complesse con risorse di filtraggio, allora automatizza le tue operazioni con gli strumenti [AWS CLI](https://aws.amazon.com/cli/index.html) o AWS SDK. AWS CLI offre la possibilità di automatizzare l'intero processo di controllo e gestione dei servizi AWS tramite script senza usare la Console AWS. Seleziona i tuoi AWS SDK preferiti per interagire con i servizi AWS. Per altri esempi di codice consulta [Repository di esempi di codice AWS SDK](https://github.com/awsdocs/aws-doc-sdk-examples). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Modernizzare le operazioni nel Cloud AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-operations-integration/welcome.html)
+ [ Servizi AWS per l'automazione ](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-operations-integration/aws-services-for-automation.html)
+ [ Automazione AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [ Automazioni AWS per amministrazione e operazioni SAP ](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-sap-automation/automations.html)
+ [AWS Managed Services](https://aws.amazon.com/managedservices/index.html)
+ [ Servizi professionali AWS](https://aws.amazon.com/professional-services/)
+ [ Infrastruttura e automazione ](https://aws.amazon.com/blogs/infrastructure-and-automation/)

 **Esempi correlati:** 
+ [ Reinventare le operazioni automatizzate (Parte I) ](https://aws.amazon.com/blogs/mt/reinventing-automated-operations-part-i/)
+ [ Reinventare le operazioni automatizzate (Parte II) ](https://aws.amazon.com/blogs/mt/reinventing-automated-operations-part-ii/)
+ [ Automazioni AWS per amministrazione e operazioni SAP ](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-sap-automation/automations.html)
+ [ Automazioni IT con AWS Lambda](https://aws.amazon.com/lambda/it-automation/)
+ [ Repository degli esempi di codice AWS](https://github.com/awsdocs/aws-doc-sdk-examples)
+ [ Esempi di AWS](https://github.com/aws-samples)

# Sostenibilità
<a name="a-sustainability"></a>

Il principio della sostenibilità include la consapevolezza dell'impatto dei servizi utilizzati, la quantificazione di tale impatto per l'intero ciclo di vita del carico di lavoro e l'applicazione dei principi di progettazione e delle best practice per ridurlo nella fase di sviluppo di carichi di lavoro cloud. È possibile trovare linee guida prescrittive sull'implementazione nel [Whitepaper sul principio della sostenibilità](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp).

**Topics**
+ [Selezione delle regioni](a-region-selection.md)
+ [Allineamento alla domanda](a-alignment-to-demand.md)
+ [Software e architettura](a-sus-software-architecture.md)
+ [Dati](a-sus-data.md)
+ [Hardware e servizi](a-sus-hardware-and-services.md)
+ [Processo e cultura](a-sus-process-and-culture.md)

# Selezione delle regioni
<a name="a-region-selection"></a>

**Topics**
+ [SUS 1 Come si selezionano le regioni per un carico di lavoro?](w2aac19c17b7b5.md)

# SUS 1 Come si selezionano le regioni per un carico di lavoro?
<a name="w2aac19c17b7b5"></a>

La scelta della Regione per il carico di lavoro influisce in modo significativo sui suoi KPI, tra cui prestazioni, costi e impatto ambientale. Per migliorare in modo efficace questi KPI, devi scegliere le regioni per i carichi di lavoro in base alle esigenze aziendali e agli obiettivi di sostenibilità.

**Topics**
+ [SUS01-BP01 Scelta della Regione in base alle esigenze aziendali e agli obiettivi di sostenibilità.](sus_sus_region_a2.md)

# SUS01-BP01 Scelta della Regione in base alle esigenze aziendali e agli obiettivi di sostenibilità.
<a name="sus_sus_region_a2"></a>

Scegli la Regione del tuo carico di lavoro in base alle esigenze aziendali e agli obiettivi di sostenibilità per ottimizzare i suoi KPI, tra cui prestazioni, costi e impatto ambientale.

 **Anti-pattern comuni:** 
+  Selezione della Regione del carico di lavoro in base alla propria collocazione. 
+  Consolidamento di tutte le risorse del carico di lavoro in un'unica posizione geografica. 

 **Vantaggi dell'adozione di questa best practice:** la collocazione di un carico di lavoro in prossimità di progetti legati alla generazione di energia rinnovabile di Amazon o in Regioni con un'intensità ridotta di emissione di anidride carbonica nota può contribuire a ridurre il suo impatto ambientale. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

Il Cloud AWS è una rete in costante espansione di Regioni e punti di presenza (PoP), con un'infrastruttura di rete globale che li collega tra loro. La scelta della Regione per il carico di lavoro influisce in modo significativo sui suoi KPI, tra cui prestazioni, costi e impatto ambientale. Per migliorare efficacemente questi KPI, è necessario scegliere le Regioni per il proprio carico di lavoro in base alle esigenze aziendali e agli obiettivi di sostenibilità.

 **Passaggi dell'implementazione** 
+  Segui questi passaggi per valutare e selezionare le potenziali Regioni per il tuo carico di lavoro in base ai requisiti aziendali, tra cui la conformità, le funzionalità disponibili, il costo e la latenza. 
  +  Conferma che queste Regioni siano conformi in base alle normative locali richieste. 
  +  Utilizza gli [elenchi dei servizi regionali di AWS](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) per verificare che le Regioni dispongano dei servizi e delle funzionalità necessarie per gestire il tuo carico di lavoro. 
  +  Calcola il costo del carico di lavoro su ogni Regione utilizzando [Calcolatore dei prezzi AWS](https://calculator.aws/). 
  +  Valuta la latenza di rete tra le sedi degli utenti finali e ogni Regione AWS. 
+  Scegli le Regioni in prossimità dei progetti di generazione di energia rinnovabile di Amazon e le Regioni in cui la griglia presenta un'intensità di emissione di anidride carbonica nota inferiore a quella di altre sedi (o Regioni). 
  +  Identifica le tue principali linee guida sulla sostenibilità per tracciare e confrontare le emissioni di anidride carbonica anno per anno sulla base del [Greenhouse Gas Protocol](https://ghgprotocol.org/) (metodi basati sul mercato e sulla localizzazione). 
  +  Scegli la Regione in base al metodo utilizzato per monitorare le emissioni di anidride carbonica. Per maggiori dettagli sulla scelta di una Regione in base alle linee guida sulla sostenibilità, consulta [Come selezionare una Regione per il carico di lavoro in base agli obiettivi di sostenibilità](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Comprendere le stime delle emissioni di anidride carbonica](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ccft-estimation.html) 
+  [Amazon Around the Globe](https://sustainability.aboutamazon.com/about/around-the-globe?energyType=true) 
+  [Metodologia delle energie rinnovabili](https://sustainability.aboutamazon.com/amazon-renewable-energy-methodology) 
+  [Quali elementi valutare quando si seleziona una Regione per i propri carichi di lavoro](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/) 

 **Video correlati:** 
+  [Progettare in modo sostenibile e ridurre le emissioni di anidride carbonica su AWS](https://www.youtube.com/watch?v=jsbamOLpCr8) 

# Allineamento alla domanda
<a name="a-alignment-to-demand"></a>

**Topics**
+ [SUS 2 Come si allineano le risorse cloud alla domanda?](sus-02.md)

# SUS 2 Come si allineano le risorse cloud alla domanda?
<a name="sus-02"></a>

Il modo in cui gli utenti e le applicazioni utilizzano i carichi di lavoro e altre risorse può aiutarti a identificare i miglioramenti da implementare per realizzare gli obiettivi di sostenibilità. Dimensiona l'infrastruttura in modo che sia costantemente adatta alla domanda e verifica di usare solo le risorse minime necessarie per supportare gli utenti. Allinea i livelli di servizio alle esigenze dei clienti. Colloca le risorse in modo da limitare la rete necessaria per il loro consumo da parte di utenti e applicazioni. Rimuovi gli asset inutilizzati. Offri ai membri del team dispositivi in grado di soddisfarne le esigenze con un impatto minimo in termini di sostenibilità.

**Topics**
+ [SUS02-BP01 Scala dinamicamente l'infrastruttura dei carichi di lavoro](sus_sus_user_a2.md)
+ [SUS02-BP02 Allineamento degli SLA agli obiettivi di sostenibilità](sus_sus_user_a3.md)
+ [SUS02-BP03 Interruzione della creazione e della manutenzione di risorse inutilizzate](sus_sus_user_a4.md)
+ [SUS02-BP04 Ottimizzazione del posizionamento geografico dei carichi di lavoro in base ai requisiti di rete](sus_sus_user_a5.md)
+ [SUS02-BP05 Ottimizzazione delle risorse dei membri del team in base alle attività eseguite](sus_sus_user_a6.md)
+ [SUS02-BP06 Implementazione del buffering o della limitazione (della larghezza di banda della rete) per ridurre la curva della domanda](sus_sus_user_a7.md)

# SUS02-BP01 Scala dinamicamente l'infrastruttura dei carichi di lavoro
<a name="sus_sus_user_a2"></a>

Usa l'elasticità del cloud e dimensiona la tua infrastruttura in modo dinamico per rispondere alla richiesta di fornitura di risorse cloud ed evitare capacità sovra-assegnate nel tuo carico di lavoro.

**Anti-pattern comuni:**
+ Mancato dimensionamento dell'infrastruttura in base al carico degli utenti.
+ Costante dimensionamento manuale dell'infrastruttura.
+ Dopo un evento di dimensionamento, lasci una capacità aumentata anziché ridurre il dimensionamento.

 **vantaggi derivanti dall'applicazione di questa best practice:** la configurazione e il test dell'elasticità dei carichi di lavoro aiuta ad abbiinare correttamente richiesta e fornitura di risorse cloud e a evitare capacità sovra-assegnate. Puoi sfruttare i vantaggi dell'elasticità nel cloud per dimensionare automaticamente la capacità durante e dopo i picchi di richiesta ed essere sicuro di utilizzare solo il numero esatto di risorse necessario per soddisfare le esigenze aziendali.

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Il cloud offre la flessibilità necessaria per espandere o ridurre le risorse in modo dinamico attraverso una serie di meccanismi per soddisfare i cambiamenti della domanda. La corrispondenza ottimale tra offerta e domanda consente l'impatto ambientale più basso per un carico di lavoro. 

 La domanda può essere fissa o variabile e richiede parametri e automazione, allo scopo di garantire che la gestione non diventi particolarmente onerosa. Le applicazioni possono essere dimensionate verticalmente (verso l'alto o verso il basso) modificando la dimensione dell'istanza, orizzontalmente (aumentando o diminuendo) modificando il numero di istanze o tramite una combinazione delle due opzioni. 

 Puoi adottare varie strategie di approccio per associare l'offerta di risorse alla domanda. 
+  **Approccio di monitoraggio del target:** monitora il parametro di dimensionamento e aumenta o diminuisci automaticamente la capacità in base alle esigenze. 
+  **Dimensionamento predittivo:** dimensiona l'anticipazione di tendenze giornaliere e settimanali. 
+  **Approccio basato sulla pianificazione:** imposta la tua pianificazione di dimensionamento in base a modifiche di carico prevedibili. 
+  **Dimensionamento dei servizi:** scegli i servizi (come il serverless) che usano il dimensionamento in modo nativo per impostazione predefinita o che forniscono il dimensionamento automatico come funzionalità. 

 Identifica i periodi di utilizzo assente o ridotto e dimensiona le risorse per evitare capacità in eccesso e migliorare il livello di efficienza. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+ L'elasticità corrisponde all'offerta di risorse disponibili rispetto alla relativa domanda. Istanze, container e funzioni offrono meccanismi di elasticità, sia insieme al dimensionamento automatico sia come funzionalità del servizio. AWS offre una gamma di meccanismi di dimensionamento automatico per avere la certezza che i carichi di lavoro possano essere ridotti facilmente e velocemente nei periodi di basso carico di utenti. Ecco alcuni esempi di meccanismi di dimensionamento automatico:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_user_a2.html)
+  Si parla spesso di dimensionamento con servizi di elaborazione come le istanze Amazon EC2 o le funzioni AWS Lambda. Considera la configurazione di servizi non di elaborazione come unità di capacità di lettura e scrittura [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) o partizioni [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) per rispondere alle richieste. 
+  Verifica che le metriche per il dimensionamento verticale o orizzontale siano convalidate in base al tipo di carico di lavoro implementato. Se distribuisci un'applicazione di transcodifica video, è previsto il 100% di utilizzo della CPU e non deve essere il parametro principale. Se necessario, puoi usare una [metrica personalizzata](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) (come l'uso della memoria) per la tua politica di dimensionamento. Per scegliere la metrica corretta, consulta le linee guida seguenti per Amazon EC2: 
  +  La metrica deve essere una metrica di utilizzo valida e descrivere il livello di impiego di un'istanza. 
  +  Il valore della metrica deve aumentare o diminuire proporzionalmente in base al numero di istanze nel gruppo con Auto Scaling. 
+  Usa il [dimensionamento dinamico](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html) invece del [dimensionamento manuale](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) per il tuo gruppo Auto Scaling. Ti consigliamo anche di usare [politiche di dimensionamento del monitoraggio degli obiettivi](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) nel tuo dimensionamento dinamico. 
+  Verifica che le implementazioni dei carichi di lavoro siano in grado di gestire eventi di dimensionamento orizzontale. Crea scenari di test per eventi di dimensionamento orizzontale per verificare che il carico di lavoro si comporti secondo le aspettative e che non incida sull'esperienza utente (come nel caso della perdita di sessioni permanenti). Puoi usare la [Cronologia delle attività](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html) per verificare un'attività di dimensionamento per un gruppo Auto Scaling. 
+  Analizza il tuo carico di lavoro per individuare modelli prevedibili e dimensionare le tue risorse in modo proattivo, anticipando variazioni nella domanda previste e pianificate. Con il dimensionamento predittivo puoi eliminare la necessità di offrire capacità in eccedenza. Per maggiori dettagli consulta [Dimensionamento predittivo con Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Nozioni di base su Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Dimensionamento predittivo per EC2, alimentato dal machine learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 
+  [Analizza il comportamento degli utenti tramite Amazon OpenSearch Service, Amazon Data Firehose e Kibana](https://aws.amazon.com/blogs/database/analyze-user-behavior-using-amazon-elasticsearch-service-amazon-kinesis-data-firehose-and-kibana/) 
+  [Che cos'è Amazon CloudWatch?](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html) 
+  [Monitoraggio del carico del database con Performance Insights su Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 
+  [Introduzione al supporto nativo per il dimensionamento predittivo con Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/) 
+  [Introducing Karpenter - An Open-Source, High-Performance Kubernetes Cluster Autoscaler (Introduzione a Karpenter - Kubernetes Cluster Autoscaler, uno strumento open source a elevate prestazioni)](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/) 
+  [Deep Dive su Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/) 

 **Video correlati:** 
+  [Sviluppa un ambiente di calcolo efficiente dal punto di vista dei costi, delle energie e delle risorse](https://www.youtube.com/watch?v=8zsC5e1eLCg) 
+  [Calcolo migliore, più veloce, più economico: ottimizzazione dei costi di Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) 

 **Esempi correlati:** 
+  [Laboratorio: esempi di gruppi Amazon EC2 Auto Scaling](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) 
+  [Lab: Implement Autoscaling with Karpenter (Laboratorio: Implementazione del dimensionamento automatico con Karpenter)](https://www.eksworkshop.com/beginner/085_scaling_karpenter/) 

# SUS02-BP02 Allineamento degli SLA agli obiettivi di sostenibilità
<a name="sus_sus_user_a3"></a>

 Rivedi e ottimizza gli Accordi sul livello di servizio (SLA) del carico di lavoro in base ai tuoi obiettivi di sostenibilità per ridurre la quantità di risorse richieste per supportare il carico di lavoro e continuare a soddisfare le esigenze aziendali. 

 **Anti-pattern comuni:** 
+  Gli SLA dei carichi di lavoro sono sconosciuti o ambigui. 
+  Definisci il tuo SLA solo per disponibilità e performance. 
+  Usi lo stello modello di progettazione (come l'architettura multi-AZ) per tutti i carichi di lavoro. 

 **Vantaggi dell'adozione di questa best practice:** allineare gli SLA agli obiettivi di sostenibilità porta a un utilizzo ottimale delle risorse e, al contempo, a una conciliazione con le esigenze aziendali. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Gli SLA definiscono il livello di servizio che ci si aspetta da un carico di lavoro cloud, come ad esempio i tempi di risposta, la disponibilità e la conservazione dei dati. Essi influenzano l'architettura, l'utilizzo delle risorse e l'impatto ambientale di un carico di lavoro nel cloud. Con cadenza regolare, rivedi gli SLA e accetta dei compromessi che riducano l'utilizzo di risorse in modo significativo in cambio di una diminuzione accettabile dei livelli di servizio. 

 **Passaggi dell'implementazione** 
+  Definisci o riprogetta SLA che supportano i tuoi obiettivi di sostenibilità e, al tempo stesso, soddisfano gli altri requisiti aziendali, senza superarli. 
+  Accetta dei compromessi che riducano l'impatto in termini di sostenibilità in modo significativo in cambio di una diminuzione accettabile dei livelli di servizio. 
  +  **Sostenibilità e affidabilità:** i carichi di lavoro altamente disponibili tendono a consumare più risorse. 
  +  **Sostenibilità e performance:** l'uso di una maggiore quantità di risorse per aumentare le performance potrebbe avere un impatto ambientale più significativo. 
  +  **Sostenibilità e sicurezza:** carichi di lavoro con una sicurezza eccessiva potrebbero avere un impatto maggiore sull'ambiente. 
+  Usa modelli di progettazione come [microservizi su AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html) che danno la priorità a funzioni strategiche per la tua azienda e consentono livelli di servizio inferiori (in tema di obiettivi per tempi di risposta o di ripristino) per funzioni non critiche. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Contratti sul livello di servizio (SLA) di AWS](https://aws.amazon.com/legal/service-level-agreements/?aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all) 
+  [L’importanza del contratto sul livello di servizi (SLA) per i provider SaaS](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/) 

 **Video correlati:** 
+ [ Offrire architetture sostenibili e ad alte prestazioni ](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [Sviluppa un ambiente di calcolo efficiente dal punto di vista dei costi, delle energie e delle risorse](https://www.youtube.com/watch?v=8zsC5e1eLCg)

# SUS02-BP03 Interruzione della creazione e della manutenzione di risorse inutilizzate
<a name="sus_sus_user_a4"></a>

Disattiva le risorse non utilizzate nel tuo carico di lavoro per ridurre il numero di risorse cloud richieste per supportare la domanda e per ridurre gli sprechi.

 **Anti-pattern comuni:** 
+  Non analizzi la tua applicazione per individuare le risorse ridondanti o non più necessarie. 
+  Non rimuovi le risorse ridondanti o non più necessarie. 

 **Vantaggi dell'adozione di questa best practice:** se si eliminano le risorse non utilizzate si libera capacità e si migliora l'efficienza generale del carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Le capacità inutilizzate consumano risorse cloud come spazio di archiviazione e potenza di elaborazione. Individuando ed eliminando queste risorse, puoi liberare capacità e ottenere un'architettura cloud più efficiente. Analizza le risorse delle applicazioni con regolarità (come report precompilati, set di dati, immagini statiche e modelli di accesso alle risorse) per identificare ridondanze, sottoutilizzi e obiettivi potenziali di disattivazione. Elimina le risorse ridondanti per ridurre gli sprechi nel tuo carico di lavoro. 

 **Passaggi dell'implementazione** 
+  Usa strumenti di monitoraggio per identificare risorse statiche non più necessarie. 
+  Prima di rimuovere qualsiasi risorsa, valuta l'impatto della rimozione sull'architettura. 
+  Sviluppa un piano e rimuovi le risorse che non sono più necessarie. 
+  Analizza le risorse generate in sovrapposizione per rimuovere le elaborazioni ridondanti. 
+  Aggiorna le tue applicazioni per smettere di produrre e archiviare risorse che non sono più necessarie. 
+  Istruisci le terze parti affinché smettano di produrre e di archiviare per tuo conto risorse gestite non più necessarie. 
+  Istruisci le terze parti e invitale a consolidare le risorse ridondanti prodotte per tuo conto. 
+  Esamina con regolarità il tuo carico di lavoro per individuare e rimuovere risorse non utilizzate. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Ottimizzazione dell'infrastruttura AWS per la sostenibilità, Parte II: Achiviazione](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/) 
+ [ Come posso terminare risorse attive che non mi servono più sul mio Account AWS? ](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-resources-account-closure/)

 **Video correlati:** 
+ [ Come posso verificare la presenza di risorse attive che non mi servono più sul mio Account AWS? ](https://www.youtube.com/watch?v=pqg9AqESRlg)

# SUS02-BP04 Ottimizzazione del posizionamento geografico dei carichi di lavoro in base ai requisiti di rete
<a name="sus_sus_user_a5"></a>

Seleziona le sedi cloud e i servizi per il carico di lavoro per ridurre la distanza che il traffico di rete deve percorrere e diminuire così le risorse totali di rete richieste per supportare il carico di lavoro.

 ** Anti-pattern comuni: ** 
+  Selezione della regione del carico di lavoro in base alla propria collocazione. 
+  Consolidamento di tutte le risorse del carico di lavoro in un'unica posizione geografica. 
+  Tutto il traffico passa attraverso i data center esistenti. 

 **Vantaggi dell'adozione di questa best practice:** il posizionamento di un carico di lavoro in prossimità dei relativi utenti garantisce la latenza più bassa e la contemporanea riduzione del trasferimento dei dati nella rete e dell'impatto ambientale. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 L'infrastruttura Cloud AWS viene definita con opzioni diverse relative alle sedi, come Regioni, zone di disponibilità, gruppi di posizionamento e posizioni edge come [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) e [zone locali AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). Queste opzioni relative alle sedi sono responsabili della gestione della connettività tra i componenti delle applicazioni, i servizi cloud, le reti edge e i data center on-premise. 

 Analizza i modelli di accesso alla rete nel tuo carico di lavoro per stabilire come usare queste opzioni relative alle sedi cloud e ridurre la distanza che il traffico di rete deve percorrere. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Analizza i modelli di accesso alla rete nel tuo carico di lavoro per capire come gli utenti usano la tua applicazione. 
  +  Usa strumenti di monitoraggio, come [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) e [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), per raccogliere dati sulle attività di rete. 
  +  Analizza i dati per identificare il modello di accesso alla rete. 
+  Seleziona le regioni appropriate per l'implementazione del carico di lavoro in base ai seguenti elementi chiave: 
  +  **Obiettivo di sostenibilità definito:** come illustrato in [Selezione delle regioni](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html). 
  +  **Ubicazione dei dati:** per le applicazioni a uso intensivo di dati, ad esempio applicazioni di big data e machine learning, il codice dell'applicazione deve essere eseguito il più vicino possibile ai dati. 
  +  **Ubicazione degli utenti:** per le applicazioni per gli utenti, scegli una Regione o più Regioni vicine agli utenti del carico di lavoro.
  + **Altri vincoli:** considera vincoli quali la sicurezza e la conformità, come illustrato nel post relativo agli [elementi da considerare quando si seleziona una regione per i propri carichi di lavoro](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/).
+  Utilizza la memorizzazione nella cache locale o [soluzioni di memorizzazione nella cache AWS](https://aws.amazon.com/caching/aws-caching/) per gli asset di frequente utilizzo per migliorare le prestazioni, ridurre lo spostamento dei dati e minimizzare l'impatto ambientale.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_user_a5.html)
+  Utilizza servizi in grado di supportarti nell'esecuzione del codice in posizioni più vicine agli utenti del carico di lavoro:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_user_a5.html)
+  Utilizza il pooling delle connessioni per consentire il loro riutilizzo e ridurre le risorse richieste. 
+  Utilizza archivi di dati distribuiti che non si affidano a connessioni persistenti e aggiornamenti sincroni per garantire coerenza e servire le popolazioni regionali. 
+  Sostituisci la capacità di rete statica preassegnata con una capacità dinamica condivisa e condividi l'impatto in termini di sostenibilità della capacità di rete con altri sottoscrittori. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking (Ottimizzazione dell'infrastruttura AWS per la sostenibilità, parte III: reti)](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/) 
+  [Documentazione su Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/index.html) 
+  [Che cos'è Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 
+  [Caratteristiche principali di Amazon CloudFront](https://aws.amazon.com/cloudfront/features/) 

 **Video correlati:** 
+  [Demystifying data transfer on AWS (Demistificazione del trasferimento dei dati su AWS)](https://www.youtube.com/watch?v=-MqXgzw1IGA) 
+ [ Dimensionamento delle prestazioni di rete sulle istanze Amazon EC2 di nuova generazione ](https://www.youtube.com/watch?v=jNYpWa7gf1A)

 **Esempi correlati:** 
+  [AWS Networking Workshops (Workshop di rete AWS)](https://catalog.workshops.aws/networking/en-US) 
+ [ Progettazione di architetture per la sostenibilità: riduzione al minimo dello spostamento dei dati tra reti ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)

# SUS02-BP05 Ottimizzazione delle risorse dei membri del team in base alle attività eseguite
<a name="sus_sus_user_a6"></a>

Ottimizza le risorse fornite ai membri del team per ridurre al minimo l'impatto sulla sostenibilità ambientale e supportare al tempo stesso le loro esigenze. 

 **Anti-pattern comuni:** 
+  Ignori l'impatto dei dispositivi utilizzati dai membri del tuo team sull'efficienza complessiva della tua applicazione cloud. 
+  Gestisci e aggiorni manualmente le risorse utilizzate dai membri del tuo team. 

 **Vantaggi dell'adozione di questa best practice:** se si ottimizzano le risorse dei membri del team si migliora l'efficienza generale delle applicazioni abilitate al cloud. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Identifica le risorse che i membri del tuo team usano per accedere ai tuoi servizi, il loro ciclo di vita atteso e l'impatto finanziario e di sostenibilità. Implementa strategie per ottimizzare queste risorse. Esegui ad esempio operazioni complesse, come rendering e compilazione, su infrastrutture scalabili altamente utilizzate, invece che su sistemi per utenti singoli, sottoutilizzati e con un alto dispendio energetico. 

 **Passaggi dell'implementazione** 
+  Effettua il provisioning di workstation e altri dispositivi in linea con il modo in cui vengono utilizzati. 
+  Usa desktop virtuali e lo streaming di applicazioni per limitare gli aggiornamenti e i requisiti dei dispositivi. 
+  Trasferisci i processori o le attività a uso intensivo della memoria nel cloud per sfruttare la sua elasticità. 
+  Valuta l'impatto di processi e sistemi sul ciclo di vita dei tuoi dispositivi e seleziona soluzioni che riducono al minimo i requisiti per la sostituzione dei dispositivi, pur continuando a soddisfare i requisiti di business. 
+  Implementa la gestione remota dei dispositivi per ridurre gli spostamenti aziendali. 
  +  [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html) è un'esperienza di interfaccia utente (UI) unificata che ti aiuta a gestire da remoto i tuoi nodi in esecuzione su AWS oppure on-premise. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Che cos'è Amazon WorkSpaces?](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html) 
+ [ Cost Optimizer per Amazon WorkSpaces ](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/overview.html)
+  [Documentazione su Amazon AppStream 2.0](https://docs.aws.amazon.com/appstream2/) 
+  [NICE DCV](https://docs.aws.amazon.com/dcv/) 

 **Video correlati:** 
+  [Gestire i costi per Amazon WorkSpaces su AWS](https://www.youtube.com/watch?v=0MoY31hZQuE) 

# SUS02-BP06 Implementazione del buffering o della limitazione (della larghezza di banda della rete) per ridurre la curva della domanda
<a name="sus_sus_user_a7"></a>

Il buffering e la limitazione (della larghezza di banda della rete) riducono la curva delle richieste e la capacità fornita tramite provisioning per il tuo carico di lavoro. 

 **Anti-pattern comuni:** 
+ Elabori immediatamente le richieste del client, anche se non è necessario.
+ Non analizzi i requisiti relativi alle richieste dei clienti.

 **Vantaggi dell'azione di questa best practice:** ridurre la curva della domanda per diminuire la capacità richiesta fornita tramite provisioning per il carico di lavoro. Ridurre la capacità fornita tramite provisioning significa ridurre il consumo di energia e contenere l'impatto ambientale. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

 Diminuire la curva della domanda del carico di lavoro può aiutarti a ridurre la capacità fornita tramite provisioning di un carico di lavoro, oltre al suo impatto sull'ambiente. Supponiamo che un carico di lavoro abbia la curva della domanda mostrata nella figura qui sotto. Questo carico di lavoro presenta due picchi e per gestire tali picchi viene eseguito il provisioning della capacità di risorse mostrata dalla linea arancione. Le risorse e l'energia utilizzate per questo carico di lavoro non sono indicate nell'area sotto la curva della domanda, ma nell'area sotto la linea della capacità fornita, poiché per gestire questi due picchi è necessario eseguire il provisioning di tale capacità. 

![\[Forma d'onda della capacità fornita tramite provisioning con due picchi distinti che richiedono una capacità elevata.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/provisioned-capacity-1.png)


 

 Puoi usare il buffering o la limitazione (della larghezza di banda della rete) per modificare la curva della domanda e appianare i picchi, con conseguente diminuzione della capacità fornita tramite provisioning e consumo inferiore di energia. Implementa la limitazione (della larghezza di banda della rete) quando i client eseguono nuovi tentativi. Implementa il buffering per archiviare la richiesta e rinviare l'elaborazione a un secondo momento. 

![\[Diagramma a onda che mostra un carico di lavoro con picchi smussati, creato tramite il buffering o la limitazione (della larghezza di banda della rete).\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/provisioned-capacity-2.png)


 

 **Passaggi dell'implementazione** 
+  Analizza le richieste del client per stabilire come rispondere. Le domande da considerare includono: 
  +  Questa richiesta può essere elaborata in modo asincrono? 
  +  Il client ha la possibilità di ripetere i tentativi? 
+  Se il client ha la possibilità di ripetere i tentativi puoi implementare la limitazione (della larghezza di banda della rete), che indica alla sorgente che, se non è in grado di soddisfare la richiesta all'ora corrente, dovrebbe riprovare più tardi. 
  +  Puoi usare [Amazon API Gateway](https://aws.amazon.com/api-gateway/) per implementare la limitazione (della larghezza di banda della rete). 
+  Per i client che non possono eseguire altri tentativi, è necessario implementare un buffer per ridurre i picchi della curva della domanda. Il buffering rinvia l'elaborazione delle richieste, consentendo alle applicazioni eseguite a velocità diverse di comunicare in modo efficace. Un approccio basato sul buffering impiega una coda o un flusso per l'accettazione dei messaggi dai produttori. I messaggi vengono letti ed elaborati dai consumatori e ciò consente ai messaggi di essere eseguiti alla velocità che soddisfa i requisiti aziendali del consumatore stesso. 
  +  [Amazon Simple Queue Service(Amazon SQS)](https://aws.amazon.com/sqs/) è un servizio gestito che offre code che consentono a un singolo consumatore di leggere singoli messaggi. 
  +  [Amazon Kinesis](https://aws.amazon.com/kinesis/) offre un flusso che consente a più consumatori di leggere gli stessi messaggi. 
+  Analizza la domanda complessiva, la velocità di modifica e il tempo di risposta richiesto per determinare le dimensioni del throttling o del buffer richiesto. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Nozioni di base su Amazon SQS ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [ Integrazione dell'applicazione con code e messaggi ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)

 **Video correlati:** 
+ [ Scegliere il servizio di messaggistica corretto per l'app distribuita ](https://www.youtube.com/watch?v=4-JmX6MIDDI)

# Software e architettura
<a name="a-sus-software-architecture"></a>

**Topics**
+ [SUS 3 In che modo sfrutti i modelli di software e architetture per sostenere i tuoi obiettivi di sostenibilità?](sus-03.md)

# SUS 3 In che modo sfrutti i modelli di software e architetture per sostenere i tuoi obiettivi di sostenibilità?
<a name="sus-03"></a>

Implementa modelli per eseguire lo smoothing del carico e garantire un utilizzo elevato e coerente delle risorse implementate per ridurre al minimo il loro consumo. In seguito alle modifiche nei comportamenti degli utenti nel tempo, alcuni componenti potrebbero diventare inattivi per mancanza di utilizzo. Rivedi modelli e architetture per consolidare i componenti sottoutilizzati e aumentare l'uso complessivo. Ritira i componenti che non sono più necessari. Analizza le prestazioni dei componenti dei tuoi carichi di lavoro e ottimizza quelli che usano la maggior quantità di risorse. Identifica i dispositivi che i clienti utilizzano per accedere ai servizi e implementa modelli in grado di ridurre al minimo la necessità di aggiornamenti dei dispositivi. 

**Topics**
+ [SUS03-BP01 Ottimizzazione del software e delle architetture per processi asincroni e pianificati](sus_sus_software_a2.md)
+ [SUS03-BP02 Rimozione o rifattorizzazione dei componenti dei carichi di lavoro con un utilizzo ridotto o assente](sus_sus_software_a3.md)
+ [Ottimizzazione delle aree di codice che consumano la maggior parte del tempo o delle risorse](sus_sus_software_a4.md)
+ [SUS03-BP04 Ottimizzazione dell'impatto su dispositivi e apparecchiature](sus_sus_software_a5.md)
+ [SUS03-BP05 Uso dei modelli e le architetture software che meglio supportano l'accesso ai dati e i modelli di archiviazione](sus_sus_software_a6.md)

# SUS03-BP01 Ottimizzazione del software e delle architetture per processi asincroni e pianificati
<a name="sus_sus_software_a2"></a>

Utilizza modelli efficienti di software e di architettura, come quelli basati sulle code, per mantenere un utilizzo elevato e costante delle risorse distribuite.

 **Anti-pattern comuni:** 
+  Provisioning di risorse in eccedenza per il carico di lavoro in cloud con lo scopo di far fronte a picchi di domanda imprevisti. 
+  Architettura non in grado di disaccoppiare i mittenti e i ricevitori di messaggi asincroni mediante un componente di messaggistica. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Modelli efficienti di software e architettura riducono al minimo le risorse inutilizzate nel carico di lavoro e migliorano l'efficienza complessiva. 
+  È possibile dimensionare le risorse dedicate all'elaborazione indipendentemente dalla ricezione di messaggi asincroni. 
+  Grazie a un componente di messaggistica, i requisiti di disponibilità si attenuano e possono essere soddisfatti con un numero inferiore di risorse. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Utilizza modelli di architettura efficienti, come l'[architettura basata su eventi](https://aws.amazon.com/event-driven-architecture/), che consentono un utilizzo uniforme dei componenti e riducono al minimo il provisioning in eccedenza nel carico di lavoro. L'utilizzo di modelli architetturali efficienti riduce al minimo le risorse inattive a causa del mancato utilizzo dovuto alle variazioni della domanda nel tempo. 

 Comprendi i requisiti dei componenti del carico di lavoro e adotta modelli di architettura che aumentino l'utilizzo complessivo delle risorse. Ritira i componenti che non sono più necessari. 

 **Passaggi dell'implementazione** 
+  Analizza le esigenze del tuo carico di lavoro per determinare come rispondere a tali richieste. 
+  Per le richieste o i processi che non necessitano di risposte sincrone, utilizza architetture basate su code e worker a scalabilità automatica per massimizzare l'utilizzo. Ecco alcuni esempi in cui potresti prendere in considerazione un'architettura basata sulle code:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_software_a2.html)
+  Per le richieste o i processi che possono essere elaborati in qualsiasi momento, ottieni una maggiore efficienza utilizzando i meccanismi di pianificazione dell'elaborazione delle attività in blocco. Ecco alcuni esempi di meccanismi di pianificazione su AWS:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_software_a2.html)
+  Se nella tua architettura utilizzi meccanismi di polling e webhook, sostituiscili con eventi. Utilizza [architetture basate su eventi](https://docs.aws.amazon.com/lambda/latest/operatorguide/event-driven-architectures.html) per realizzare carichi di lavoro efficienti. 
+  Approfitta dei servizi [serverless su AWS](https://aws.amazon.com/serverless/) per eliminare la necessità di provisioning in eccedenza sull'infrastruttura. 
+  Dimensiona in modo appropriato i singoli componenti dell'architettura per evitare la presenza di risorse inattive in attesa di input. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Che cos'è Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) 
+  [Che cos'è Amazon MQ?](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) 
+  [Dimensionamento basato su Amazon SQS](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html) 
+  [Che cos'è AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 
+  [Che cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 
+  [Utilizzo di AWS Lambda con Amazon SQS](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html) 
+  [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 

 **Video correlati:** 
+  [Passaggio ad architetture basate su eventi](https://www.youtube.com/watch?v=h46IquqjF3E) 

# SUS03-BP02 Rimozione o rifattorizzazione dei componenti dei carichi di lavoro con un utilizzo ridotto o assente
<a name="sus_sus_software_a3"></a>

Elimina i componenti non utilizzati e non più necessari e rifattorizza quelli con scarso utilizzo per limitare lo spreco di risorse nel tuo carico di lavoro.

 **Anti-pattern comuni:** 
+  Non verifichi con regolarità il livello di utilizzo dei singoli componenti del tuo carico di lavoro. 
+  Non verifichi e analizzi i consigli ricevuti dagli strumenti di dimensionamento AWS, ad esempio [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/). 

 **Vantaggi dell'adozione di questa best practice:** se si eliminano i componenti non utilizzati si riducono gli sprechi e si migliora l'efficienza generale del carico di lavoro cloud. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Esamina il tuo carico di lavoro per identificare componenti inattivi o non utilizzati. Si tratta di un processo di migliorie iterativo che può essere attivato da cambiamenti nella domanda o dal rilascio di un nuovo servizio cloud. Ad esempio, una riduzione significativa dei tempi di esecuzione della funzione [AWS Lambda](https://docs.aws.amazon.com/lambda/) può essere un indicatore della necessità di diminuire la dimensione della memoria. Inoltre, quando AWS rilascia nuovi servizi e funzionalità, è possibile che i servizi ottimali e l'architettura per il carico di lavoro cambino. 

 Monitora continuamente l'attività del carico di lavoro e cerca le opportunità per migliorare il livello di utilizzo dei singoli componenti. Eliminando i componenti inattivi ed eseguendo attività di ridimensionamento, soddisfi i requisiti aziendali con il numero minimo di risorse cloud. 

 **Passaggi dell'implementazione** 
+  Monitora e acquisici metriche di utilizzo per componenti strategici del tuo carico di lavoro (like l'utilizzo della CPU, l'utilizzo della memoria o la velocità di trasmissione effettiva nelle metriche [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)). 
+  Per carichi di lavoro stabili, verifica gli strumenti di ridimensionamento AWS come [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) a intervalli regolari per individuare componenti inattivi, inutilizzati o sottoutilizzati. 
+  Per carichi di lavoro effimeri, valuta metriche di utilizzo per identificare componenti inattivi, inutilizzati o sottoutilizzati. 
+  Ritira componenti e risorse associate (come le immagini Amazon ECR) che non sono più necessarie. 
+  Rifattorizza o consolida i componenti sottoutilizzati con altre risorse per promuovere un utilizzo efficiente. Ad esempio, puoi eseguire il provisioning di più database di piccole dimensioni su una singola istanza di database [Amazon RDS](https://aws.amazon.com/rds/) invece di eseguire database su singole istanze sottoutilizzate. 
+  Scopri le [risorse fornite dal tuo carico di lavoro per completare un'unità di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/evaluate-specific-improvements.html). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+  [Che cos'è Amazon CloudWatch?](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html) 
+  [Pulizia automatizzata di immagini non utilizzate in Amazon ECR](https://aws.amazon.com/blogs/compute/automated-cleanup-of-unused-images-in-amazon-ecr/) 

 **Esempi correlati:** 
+ [ Well-Architected Lab - Ridimensionamento con AWS Compute Optimizer](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [ Well-Architected Lab: ottimizzazione dei modelli hardware e conformità con gli indicatori KPI di sostenibilità ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)

# Ottimizzazione delle aree di codice che consumano la maggior parte del tempo o delle risorse
<a name="sus_sus_software_a4"></a>

Ottimizza il codice eseguito all'interno di diversi componenti della tua architettura per ridurre l'utilizzo delle risorse e massimizzare al tempo stesso le prestazioni.

 **Anti-pattern comuni:** 
+  Ignori l'ottimizzazione del codice per l'utilizzo delle risorse. 
+  In genere, rispondi ai problemi di performance aumentando le risorse. 
+  La revisione del codice e il processo di sviluppo non monitorano le modifiche a livello di prestazioni. 

 **Vantaggi dell'adozione di questa best practice:** l'uso di codice efficiente riduce al minimo l'utilizzo delle risorse e migliora le prestazioni. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 È fondamentale esaminare ogni area funzionale, incluso il codice per un'applicazione ideata nel cloud, per ottimizzare l'uso delle risorse e le performance. Monitora costantemente le performance del tuo carico di lavoro negli ambienti di sviluppo e produzione e identifica le opportunità per migliorare gli snippet di codice che comportano un utilizzo particolarmente elevato delle risorse. Adotta un processo di revisione con cadenza regolare per identificare i bug o gli anti-pattern all'interno del codice che utilizzano le risorse in modo non efficiente. Sfrutta algoritmi semplici ed efficienti che hanno gli stessi risultati per il tuo caso d'uso. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Mentre sviluppi i tuoi carichi di lavoro, adotta un processo di revisione del codice automatizzato, per migliorar la qualità e identificare bug e anti-pattern. 
  + [ Automazione delle revisioni del codice con il Amazon CodeGuru Reviewer ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
  + [ Rilevare i bug concomitanti con Amazon CodeGuru ](https://aws.amazon.com/blogs/devops/detecting-concurrency-bugs-with-amazon-codeguru/)
  + [ Aumentare la qualità del codice per le applicazioni Python con Amazon CodeGuru ](https://aws.amazon.com/blogs/devops/raising-code-quality-for-python-applications-using-amazon-codeguru/)
+  Mentre esegui i tuoi carichi di lavoro, monitora le risorse per individuare i componenti che presentano maggiori requisiti di risorse per unità di lavoro e sottoponili a revisioni del codice. 
+  Per le revisioni del codice, utilizza un profiler di codice per identificare le aree di codice che utilizzano la maggior parte del tempo o delle risorse e trasformale in obiettivi di ottimizzazione. 
  + [ Ridurre l'impatto ambientale della tua organizzazione con Amazon CodeGuru Profiler ](https://aws.amazon.com/blogs/devops/reducing-your-organizations-carbon-footprint-with-codeguru-profiler/)
  + [ Capire l'utilizzo della memoria nella tua applicazione Java con Amazon CodeGuru Profiler ](https://aws.amazon.com/blogs/devops/understanding-memory-usage-in-your-java-application-with-amazon-codeguru-profiler/)
  + [ Migliorare l'esperienza del cliente e ridurre i costi con Amazon CodeGuru Profiler ](https://aws.amazon.com/blogs/devops/improving-customer-experience-and-reducing-cost-with-codeguru-profiler/)
+  Usa il sistema operativo e il linguaggio di programmazione più efficienti per il carico di lavoro. Per dettagli sui linguaggi di programmazione efficienti dal punto di vista delle risorse (incluso Rust), consulta [Sostenibilità con Rust](https://aws.amazon.com/blogs/opensource/sustainability-with-rust/). 
+  Sostituisci gli algoritmi a uso intensivo di elaborazioni con una versione più semplice ed efficiente che produce gli stessi risultati. 
+  Rimuovi il codice non necessario, come quello relativo all'ordinamento e alla formattazione. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [What is Amazon CodeGuru Profiler? (Che cos'è Amazon CodeGuru Profiler?)](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html) 
+  [Istanze FPGA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/fpga-getting-started.html) 
+  [SDK AWS su Strumenti per creare su AWS](https://aws.amazon.com/tools/) 

 **Video correlati:** 
+ [ Migliora l'efficienza del codice con Amazon CodeGuru Profiler ](https://www.youtube.com/watch?v=1pU4VddsBRw)
+ [ Automatizza le revisioni del codice e i consigli sulle prestazioni dell'applicazione con Amazon CodeGuru ](https://www.youtube.com/watch?v=OD8H63C0E0I)

# SUS03-BP04 Ottimizzazione dell'impatto su dispositivi e apparecchiature
<a name="sus_sus_software_a5"></a>

Conoscere i dispositivi e le apparecchiature utilizzate nell'architettura e applicare strategie per ridurre il loro uso. Questo può ridurre l'impatto ambientale complessivo del tuo carico di lavoro cloud. 

 **Anti-pattern comuni:** 
+  Ignori l'impatto ambientale dei dispositivi utilizzati dai clienti. 
+  Gestisci e aggiorni manualmente le risorse utilizzate dai clienti. 

 **Vantaggi dell'adozione di questa best practice:** implementare modelli e funzionalità software ottimizzati per i dispositivi dei clienti può ridurre l'impatto ambientale complessivo del carico di lavoro del cloud. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Implementare modelli e funzionalità software ottimizzati per i dispositivi dei clienti può ridurre l'impatto ambientale in diversi modi: 
+  Implementare nuove funzionalità compatibili con le versioni precedenti può ridurre il numero di sostituzioni hardware. 
+  Ottimizzare un'applicazione per un'esecuzione efficiente sui dispositivi può contribuire a ridurre l'utilizzo di energia ed estendere la durata della loro batteria (se sono alimentati tramite batteria). 
+  Ottimizzare un'applicazione per i dispositivi significa anche ridurre il trasferimento dei dati sulla rete. 

 Conoscere i dispositivi e l'attrezzatura utilizzati nella tua architettura, il loro ciclo di vita atteso e l'impatto della sostituzione di tali componenti. Implementare modelli e funzionalità software che possono contribuire a ridurre l'uso di energia da parte del dispositivo, la necessità da parte dei clienti di sostituirlo e anche di eseguire l'aggiornamento manuale. 

 **Passaggi dell'implementazione** 
+  Fai un inventario dei dispositivi usati nella tua architettura. I dispositivi possono essere cellulari, tablet, dispositivi IOT, illuminazione smart o persino dispositivi smart in una fabbrica. 
+  Ottimizza l'applicazione in esecuzione sui dispositivi: 
  +  Usa strategie come l'esecuzione di attività in background per ridurre l'uso di energia. 
  +  Prendi in considerazione la larghezza di banda e la latenza della rete durante la creazione di payload e implementa funzionalità che consentano alle tue applicazioni di lavorare bene anche in presenza di una larghezza di banda ridotta e di link ad alta latenza. 
  +  Converti payload e file in formati ottimizzati richiesti dai dispositivi. Ad esempio, puoi usare [Amazon Elastic Transcoder](https://docs.aws.amazon.com/elastic-transcoder/) o [AWS Elemental MediaConvert](https://aws.amazon.com/mediaconvert/) per convertire file di media digitali di grandi dimensioni e di qualità elevata in formati che gli utenti possono riprodurre su dispositivi mobili, tablet, browser web e televisioni connesse. 
  +  Esegui attività a elevata intensità computazionale lato server (come, ad esempio, il rendering delle immagini) oppure usa lo streaming delle applicazioni per migliorare l'esperienza utente sui dispositivi di versioni precedenti. 
  +  Esegui la segmentazione e la paginazione dell'output, soprattutto per le sessioni interattive, per gestire i payload e limitare i requisiti di archiviazione in locale. 
+  Usa un meccanismo via etere (OTA) automatizzato per distribuire gli aggiornamenti a uno o più dispositivi. 
  +  Puoi usare una [pipeline CI/CD](https://aws.amazon.com/blogs/mobile/build-a-cicd-pipeline-for-your-android-app-with-aws-services/) per aggiornare le applicazioni mobili. 
  +  Puoi usare [AWS IoT Device Management](https://aws.amazon.com/iot-device-management/) per gestire da remoto dispositivi connessi su scala. 
+  Per testare nuove funzionalità e aggiornamenti, usa device farm gestite con set di hardware rappresentativi e iterare lo sviluppo per ottimizzare i dispositivi supportati. Per ulteriori dettagli, consulta [SUS06-BP04 Utilizzo di device farm gestite per i test](sus_sus_dev_a5.md). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Che cos'è AWS Device Farm?](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) 
+  [Documentazione su Amazon AppStream 2.0](https://docs.aws.amazon.com/appstream2/) 
+  [NICE DCV](https://docs.aws.amazon.com/dcv/) 
+ [ Tutorial OTA per l'aggiornamento del firmware su dispositivi che eseguono FreeRTOS ](https://docs.aws.amazon.com/freertos/latest/userguide/dev-guide-ota-workflow.html)

 **Video correlati:** 
+ [ Introduzione a AWS Device Farm](https://www.youtube.com/watch?v=UiJo_PEZkD4)

# SUS03-BP05 Uso dei modelli e le architetture software che meglio supportano l'accesso ai dati e i modelli di archiviazione
<a name="sus_sus_software_a6"></a>

Scopri come i dati vengono utilizzati all'interno del tuo carico di lavoro, consumati dagli utenti, trasferiti e archiviati. Usa architetture e modelli software in grado di supportare al meglio l'accesso ai dati e l'archiviazione per ridurre le risorse di elaborazione, rete e storage richieste dal carico di lavoro.

 **Anti-pattern comuni:** 
+  Ritieni che tutti i carichi di lavoro abbiano modelli di accesso e archiviazione dei dati simili. 
+  Utilizzi un solo livello di storage, presupponendo che tutti i carichi di lavoro rientrino in tale livello. 
+  Ritieni che gli schemi di accesso ai dati rimarranno coerenti nel tempo. 
+  La tua architettura supporta una potenziale espansione elevata dell'accesso ai dati, con conseguente inattività delle risorse per la maggior parte del tempo. 

 **Vantaggi dell'adozione di questa best practice:** selezionando e ottimizzando la tua architettura in base all'accesso ai dati e ai modelli di archiviazione diminuirà la complessità dello sviluppo e aumenterà l'utilizzo complessivo. Capire quando utilizzare le tabelle globali, il partizionamento dei dati e la memorizzazione nella cache, ti aiuterà a ridurre i costi operativi e a effettuare il dimensionamento in base alle esigenze del carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Usa modelli di software e architetture che siano quanto più in linea con le caratteristiche dei tuoi dati e i modelli di accesso. Ad esempio, usa [un'architettura di dati moderni su AWS](https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/) che ti consenta di utilizzare servizi dedicati ottimizzati per i tuoi casi d'uso di analisi specifici. Questi modelli di architettura consentono un'elaborazione efficiente dei dati e riducono l'uso delle risorse. 

 **Passaggi dell'implementazione** 
+  Analizza le caratteristiche dei dati e i modelli di accesso per individuare la configurazione corretta per le tue risorse cloud. Gli aspetti chiave da considerare includono: 
  +  **Tipi di dati:** strutturati, semi-strutturati, non strutturati 
  +  **Crescita dei dati:** delimitati, non delimitati 
  +  **Durabilità dei dati:** persistenti, effimeri, transitori 
  +  **Modelli di accesso:** letture o scritture, frequenza di aggiornamento, con picchi o costante 
+  Usa tipi di architetture che meglio supportano l'accesso ai dati e i modelli di archiviazione. 
  + [ Progettiamo\$1 Architetture dei dati moderne ](https://aws.amazon.com/blogs/architecture/lets-architect-modern-data-architectures/)
  + [Database su AWS: lo strumento più adatto per ciascun processo ](https://www.youtube.com/watch?v=-pb-DkD6cWg)
+  Sfrutta le tecnologie che lavorano in modo nativo con i dati compressi. 
+  Usa [servizi di analisi](https://aws.amazon.com/big-data/datalakes-and-analytics/?nc2=h_ql_prod_an_a) per l'elaborazione dei dati nella tua architettura. 
+  Utilizza il motore del database che meglio supporta il modello di query dominante. Gestisci gli indici di database per garantire un'esecuzione efficiente delle query. Per ulteriori informazioni consulta [Database AWS](https://aws.amazon.com/products/databases/). 
+  Seleziona protocolli di rete che riducano la quantità di capacità di rete utilizzata dalla tua architettura. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Formati file di supporto alla compressione di Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html) 
+  [COPY dai formati dei dati in colonne con Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/copy-usage_notes-copy-from-columnar.html) 
+  [Convertire il formato dei record di input in Firehose](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html) 
+  [Opzioni di formato per input e output ETL in AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html) 
+  [Migliora le prestazioni delle query su Amazon Athena con una conversione ai formati in colonne](https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.html) 
+  [Caricamento di file di dati compressi da Amazon S3 con Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html) 
+  [Monitoraggio del carico del database con Performance Insights su Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 
+  [Monitoraggio del carico del database con Performance Insights su Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 
+ [ Classe di storage Amazon S3 Intelligent-Tiering ](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/)

 **Video correlati:** 
+ [ Sviluppare architetture dei dati moderne su AWS](https://www.youtube.com/watch?v=Uk2CqEt5f0o)

# Dati
<a name="a-sus-data"></a>

**Topics**
+ [SUS 4 Come si può usufruire delle policy e dei modelli di gestione dei dati per supportare gli obiettivi di sostenibilità?](sus-04.md)

# SUS 4 Come si può usufruire delle policy e dei modelli di gestione dei dati per supportare gli obiettivi di sostenibilità?
<a name="sus-04"></a>

Implementa procedure di gestione dei dati per ridurre l'archiviazione assegnata richiesta per supportare il carico di lavoro e le risorse necessarie per l'uso correlato. Analizza i tuoi dati e usa tecnologie e configurazioni di archiviazione che supportano più efficacemente il valore aziendale dei dati e il modo in cui vengono utilizzati. Esegui il ciclo di vita dei dati su un'archiviazione più efficiente e meno performante al diminuire dei requisiti ed elimina i dati che non sono più necessari. 

**Topics**
+ [SUS04-BP01 Implementazione di una policy di classificazione dei dati](sus_sus_data_a2.md)
+ [SUS04-BP02 Utilizzo di tecnologie che supportano l'accesso ai dati e i modelli di archiviazione](sus_sus_data_a3.md)
+ [SUS04-BP03 Utilizzo delle policy per gestire il ciclo di vita dei set di dati](sus_sus_data_a4.md)
+ [SUS04-BP04 Utilizzo dell'elasticità e dell'automazione per espandere lo storage a blocchi o il file system](sus_sus_data_a5.md)
+ [SUS04-BP05 Eliminazione dei dati ridondanti o non necessari](sus_sus_data_a6.md)
+ [SUS04-BP06 Utilizzo di file system condivisi o archiviazione per accedere a dati comuni](sus_sus_data_a7.md)
+ [SUS04-BP07 Riduzione al minimo dello spostamento di dati tra reti](sus_sus_data_a8.md)
+ [SUS04-BP08 Backup dei dati solo quando sono difficili da ricreare](sus_sus_data_a9.md)

# SUS04-BP01 Implementazione di una policy di classificazione dei dati
<a name="sus_sus_data_a2"></a>

Classifica i dati per capire le criticità rispetto ai risultati aziendali e scegli il livello di archiviazione ad alta efficienza corretto per le tue informazioni.

 **Anti-pattern comuni:** 
+  Non identifichi asset di dati con caratteristiche simili (come sensibilità, criticità aziendale o requisiti normativi) che vengono elaborati o archiviati. 
+  Non hai implementato un catalogo di dati per eseguire l'inventario dei tuoi asset. 

 **Vantaggi derivanti dall'adozione di questa best practice:** l'implementazione di una policy di classificazione dei dati ti consente di stabilire il livello di archiviazione più efficiente per i dati. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 La classificazione dei dati comporta l'identificazione dei tipi di dati elaborati e archiviati in un sistema informativo di proprietà o gestito da un'organizzazione. Inoltre, è necessario stabilire la criticità dei dati e il probabile impatto di una compromissione, perdita o uso improprio dei dati. 

 Implementare la policy di classificazione dei dati partendo dall'uso contestuale dei dati e creando uno schema di categorizzazione che tenga conto del livello di criticità di un determinato set di dati per le operazioni dell'organizzazione. 

 **Passaggi dell'implementazione** 
+  Esegui un inventario dei vari tipi di dati esistenti per il carico di lavoro. 
  +  Per maggiori dettagli sulle categorie di classificazione dei dati consulta [Whitepaper sulla classificazione dei dati](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html). 
+  Determina la criticità, la riservatezza, l'integrità e la disponibilità dei dati in base al rischio per l'organizzazione. Utilizza questi requisiti per raggruppare i dati in uno dei livelli di classificazione dei dati adottati. 
  +  Come esempio vedi [Quattro semplici passaggi per classificare i tuoi dati e proteggere la tua startup](https://aws.amazon.com/blogs/startups/four-simple-steps-to-classify-your-data-and-secure-your-startup/). 
+  Verifica periodicamente il tuo ambiente per individuare dati non classificati e privi di tag e quindi taggare e classificare i dati in maniera adeguata. 
  +  Come esempio vedi [Catalogo dati e crawler in AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html). 
+  Stabilisci un catalogo di dati che fornisca funzionalità di audit e governance. 
+  Definisci e documenta le procedure di gestione per ogni classe di dati. 
+  Usa l'automazione per verificare periodicamente il tuo ambiente e individuare dati non classificati e privi di tag e quindi taggare e classificare i dati in maniera adeguata. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Utilizzo di Cloud AWS per supportare la classificazione dei dati](https://docs.aws.amazon.com/whitepapers/latest/data-classification/leveraging-aws-cloud-to-support-data-classification.html) 
+  [Policy di tag di AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) 

 **Video correlati:** 
+ [ promuovere l'agilità con la governance dei dati su AWS](https://www.youtube.com/watch?v=vznDgJkoH7k)

# SUS04-BP02 Utilizzo di tecnologie che supportano l'accesso ai dati e i modelli di archiviazione
<a name="sus_sus_data_a3"></a>

 Usa tecnologie di archiviazione in grado di supportare al meglio il modo in cui viene effettuato l'accesso ai dati e come vengono archiviati per ridurre la quantità di risorse assegnate e supportare al tempo stesso il tuo carico di lavoro. 

 **Anti-pattern comuni:** 
+  Ritieni che tutti i carichi di lavoro abbiano modelli di accesso e archiviazione dei dati simili. 
+  Utilizzi un solo livello di archiviazione, presupponendo che tutti i carichi di lavoro rientrino in tale livello. 
+  Ritieni che gli schemi di accesso ai dati rimarranno coerenti nel tempo. 

 **Vantaggi dell'adozione di questa best practice:** selezionare e ottimizzare le tecnologie di archiviazione in base all'accesso ai dati e ai modelli di archiviazione ti consentirà di ridurre le risorse cloud richieste per soddisfare le tue esigenze aziendali e migliorare l'efficienza generale del tuo carico di lavoro cloud. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Seleziona la soluzione di archiviazione più adatta ai tuoi modelli di accesso. In alternativa, puoi modificarli affinché siano in linea con la soluzione di archiviazione, allo scopo di ottimizzare l'efficienza delle prestazioni. 
+  Valuta le caratteristiche dei tuoi dati e il modello di accesso per raccogliere gli aspetti chiave delle tue esigenze di archiviazione. Gli aspetti chiave da considerare includono: 
  +  **Tipo di dati:** strutturati, semi-strutturati, non strutturati 
  +  **Crescita dei dati:** limitata, illimitata 
  +  **Durabilità dei dati:** persistenti, effimeri, transitori 
  +  **Modelli di accesso:** letture o scritture, frequenza, con picchi o costante 
+  Migra i dati alla tecnologia di archiviazione appropriata che supporta le caratteristiche dei tuoi dati e il modello di accesso. Ecco alcuni esempi di tecnologie di archiviazione AWS e delle loro caratteristiche chiave:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_data_a3.html)
+  Per i sistemi di archiviazione con dimensione fissa, come Amazon EBS o Amazon FSx, monitora lo spazio di archiviazione disponibile e automatizza l'allocazione dell'archiviazione al raggiungimento di una soglia. È possibile sfruttare Amazon CloudWatch al fine di raccogliere e analizzare metriche diverse per [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html) e [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring-cloudwatch.html). 
+  Le classi di archiviazione di Amazon S3 possono essere configurate a livello di oggetto e un singolo bucket può contenere oggetti archiviati in tutte le classi. 
+  Si possono anche utilizzare le policy Amazon S3 Lifecycle per passare automaticamente gli oggetti tra le classi di archiviazione oppure rimuovere i dati senza modifiche all'applicazione. In generale, devi raggiungere un equilibrio tra efficienza delle risorse, latenza di accesso e affidabilità, quando consideri questi meccanismi di storage. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Tipi di volume di Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) 
+  [Archivio dell'istanza Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) 
+  [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html) 
+ [ Caratteristiche di I/O Amazon EBS ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html)
+ [ Utilizzo delle classi di archiviazione di Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)
+  [Che cos'è Amazon Glacier?](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html) 

 **Video correlati:** 
+  [Architectural Patterns for Data Lakes on AWS (Modelli architetturali per i data lake su AWS)](https://www.youtube.com/watch?v=XpTly4XHmqc&ab_channel=AWSEvents) 
+ [ Analisi approfondita di Amazon EBS (STG303-R1) ](https://www.youtube.com/watch?v=wsMWANWNoqQ)
+ [ Ottimizzazione delle prestazioni di archiviazione con Amazon S3 (STG343) ](https://www.youtube.com/watch?v=54AhwfME6wI)
+ [ Sviluppare architetture dei dati moderne su AWS](https://www.youtube.com/watch?v=Uk2CqEt5f0o)

 **Esempi correlati:** 
+ [ Driver CSI di Amazon EFS ](https://github.com/kubernetes-sigs/aws-efs-csi-driver)
+ [ Driver CSI di Amazon EBS ](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
+ [ Utility di Amazon EFS ](https://github.com/aws/efs-utils)
+ [ Amazon EBS Autoscale ](https://github.com/awslabs/amazon-ebs-autoscale)
+ [ Esempi di Amazon S3 ](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html)

# SUS04-BP03 Utilizzo delle policy per gestire il ciclo di vita dei set di dati
<a name="sus_sus_data_a4"></a>

Gestisci il ciclo di vita di tutti i tuoi dati e applica in automatico le cancellazioni per ridurre i requisiti totali di archiviazione del tuo carico di lavoro.

 **Anti-pattern comuni:** 
+  Cancellazione manuale dei dati. 
+  Conservazione di tutti i dati del carico di lavoro. 
+  Mancato spostamento dei dati su livelli di archiviazione più efficienti dal punto di vista energetico in base ai requisiti di conservazione e accesso. 

 **Vantaggi dell'adozione di questa best practice:** l'utilizzo delle policy per il ciclo di vita dei dati garantisce un accesso e una conservazione efficienti dei dati in un carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 i set di dati presentano solitamente requisiti di conservazione e accesso che cambiano durante il loro ciclo di vita. Ad esempio, l'applicazione potrebbe avere bisogno di accedere frequentemente ad alcuni set di dati per un periodo di tempo limitato. In seguito, questi set di dati vengono consultati di rado. 

 Per gestire in modo efficiente i set di dati durante il loro ciclo di vita, è necessario configurare le policy per il ciclo di vita, ovvero le regole che definiscono la gestione dei set di dati. 

 Con le regole di configurazione del ciclo di vita, è possibile indicare al servizio di archiviazione di trasferire un set di dati a livelli di archiviazione più efficienti dal punto di vista energetico, di archiviarlo o di eliminarlo. 

 **Passaggi dell'implementazione** 
+  [Classifica i set di dati del carico di lavoro.](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_data_a2.html) 
+  Definisci le procedure di gestione per ogni classe di dati. 
+  Imposta policy automatizzate per il ciclo di vita per applicare le regole correlate. Ecco alcuni esempi di come impostare policy automatizzate per il ciclo di vita di diversi servizi di archiviazione di AWS:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_data_a4.html)
+  Elimina i volumi inutilizzati, gli snapshot e i dati che hanno superato il periodo di conservazione. Sfrutta le caratteristiche native del servizio, come il Time To Live di Amazon DynamoDB o la conservazione dei log di Amazon CloudWatch per programmare l'eliminazione. 
+  Aggrega e comprimi i dati quando possibile in base alle regole del ciclo di vita. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Ottimizza le regole del ciclo di vita di Amazon S3 con l'analisi delle classi di archiviazione di Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html) 
+  [Valutazione delle risorse con Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 

 **Video correlati:** 
+  [Semplifica il ciclo di vita dei dati e ottimizza i costi di archiviazione con Amazon S3 Lifecycle](https://www.youtube.com/watch?v=53eHNSpaMJI) 
+ [Riduci i costi di archiviazione con Amazon S3 Storage Lens](https://www.youtube.com/watch?v=A8qOBLM6ITY)

# SUS04-BP04 Utilizzo dell'elasticità e dell'automazione per espandere lo storage a blocchi o il file system
<a name="sus_sus_data_a5"></a>

Usa l'elasticità e l'automazione per espandere lo storage a blocchi o il file system con l'aumento dei dati per ridurre l'archiviazione totale oggetto di provisioning.

 **Anti-pattern comuni:** 
+  Acquisti uno storage a blocchi di grandi dimensioni o un file system per necessità future. 
+  Esegui un provisioning eccessivo delle operazioni di input e output al secondo (IOPS) del tuo file system. 
+  Non monitori l'utilizzo dei volumi di dati. 

 **Vantaggi dell'adozione di questa best practice:** ridurre il provisioning eccessivo per il sistema di archiviazione significa ridurre le risorse inattive e migliorare l'efficienza complessiva del tuo carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Crea storage a blocchi e file system con l'allocazione delle dimensioni, la velocità di trasmissione effettiva e la latenza adeguate al tuo carico di lavoro. Usa l'elasticità e l'automazione per espandere lo storage a blocchi o il file system con l'aumento dei dati per evitare un provisioning eccessivo per questi servizi di archiviazione. 

 **Passaggi dell'implementazione** 
+  Per i sistemi di storage di dimensioni fisse, come [Amazon EBS](https://aws.amazon.com/ebs/), assicurati di monitorare la quantità di archiviazione utilizzata rispetto alle dimensioni complessive dell'archiviazione e di creare, se possibile, un'automazione per aumentarne le dimensioni quando si raggiunge una soglia. 
+  Utilizza volumi elastici e servizi di dati a blocchi gestiti per automatizzare l'allocazione di archivi aggiuntivi man mano che i dati persistenti aumentano. Come esempio puoi usare i [Volumi elastici Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html) per modificare le dimensioni dei volumi, il tipo di volume o adeguare le performance dei tuo volumi Amazon EBS. 
+  Scegli la classe di archiviazione corretta, le performance e la velocità di trasmissione effettiva per il tuo file system per rispondere alle esigenze della tua azienda, senza eccedere. 
  + [ Performance Amazon EFS ](https://docs.aws.amazon.com/efs/latest/ug/performance.html)
  + [ Performance dei volumi Amazon EBS sulle istanze Linux ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html)
+  Imposta i livelli target di utilizzo per i volumi di dati e ridimensiona i volumi al di fuori degli intervalli previsti. 
+  Dimensiona i volumi di sola lettura per adattarli ai dati. 
+  Migra i dati su archivi oggetti per evitare il provisioning di capacità eccessive da dimensioni di volumi fisse su archiviazioni a blocchi. 
+  Esamina regolarmente i volumi elastici e i file system per terminare i volumi inattivi e ridurre i volumi con un provisioning eccessivo per adattarli alla dimensione corrente dei dati. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [ Documentazione Amazon FSx](https://docs.aws.amazon.com/fsx/index.html) 
+  [Che cos'è Amazon Elastic File System?](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) 

 **Video correlati:** 
+ [Approfondimento sui volumi elastici di Amazon EBS](https://www.youtube.com/watch?v=Vi_1Or7QuOg)
+ [ Strategie Amazon EBS e di ottimizzazione degli snapshot per performance migliori e risparmio sui costi ](https://www.youtube.com/watch?v=h1hzRCsJefs)
+ [ Ottimizzare Amazon EFS per costi e performance, usando le best practice ](https://www.youtube.com/watch?v=9kfeh6_uZY8)

# SUS04-BP05 Eliminazione dei dati ridondanti o non necessari
<a name="sus_sus_data_a6"></a>

Elimina i dati non necessari o ridondanti per ridurre al minimo le risorse di archiviazione necessarie per memorizzare i set di dati. 

 **Anti-pattern comuni:** 
+  Duplicazione dei dati che possono essere facilmente recuperati o ricreati. 
+  Backup di tutti i dati senza prenderne in considerazione la criticità. 
+  Cancellazione dei dati eseguita in modo irregolare, in occasione di eventi operativi o non eseguita affatto. 
+  Archiviazione dei dati in modo ridondante, indipendentemente dall'affidabilità del servizio di archiviazione. 
+  Abilitazione del versioning di Amazon S3 senza alcuna giustificazione aziendale. 

 **Vantaggi dell'adozione di questa best practice:** la rimozione dei dati non necessari riduce le dimensioni dello spazio di archiviazione necessario per il carico di lavoro e il relativo impatto ambientale. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Non memorizzare i dati che non ti servono. Automatizza l'eliminazione dei dati non necessari. Utilizza tecnologie di backup che deduplicano i dati a livello di file e blocco. Sfrutta le funzionalità native di replica e ridondanza dei dati dei servizi. 

 **Passaggi dell'implementazione** 
+  Valuta se è possibile evitare la memorizzazione dei dati utilizzando set di dati esistenti disponibili pubblicamente in [AWS Data Exchange](https://aws.amazon.com/data-exchange/) e [Open Data su AWS](https://registry.opendata.aws/). 
+  Utilizza meccanismi che possano deduplicare i dati a livello di blocco e oggetto. Ecco alcuni esempi di come deduplicare i dati su AWS:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_data_a6.html)
+  Analizza l'accesso ai dati per identificare quelli non necessari. Automatizza le policy per il ciclo di vita. Sfrutta le caratteristiche native del servizio, come il [Time To Live di Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html), [Amazon S3 Lifecycle](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) o la [conservazione dei log di Amazon CloudWatch](https://docs.aws.amazon.com/managedservices/latest/userguide/log-customize-retention.html) per l'eliminazione. 
+  Utilizza le funzionalità di virtualizzazione dei dati di AWS per mantenere i dati sul loro sistema di origine ed evitare la loro duplicazione. 
  +  [Virtualizzazione dei dati nativa del cloud su AWS](https://www.youtube.com/watch?v=BM6sMreBzoA) 
  +  [Lab: ottimizzare lo schema dei dati con la condivisione dei dati di Amazon Redshift](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/) 
+  Utilizza una tecnologia di backup in grado di eseguire backup incrementali. 
+  Per raggiungere i tuoi obiettivi di persistenza, sfrutta l'affidabilità di [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html) e la [replica di Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) invece di tecnologie da gestire in autonomia (come i dischi RAID). 
+  Centralizza i log e traccia i dati, deduplica le voci di log identiche e stabilisci meccanismi per ottimizzarne la verbosità quando necessario. 
+  Popola in anticipo le cache solo quando è necessario. 
+  Definisci il monitoraggio e l'automazione della cache per ridimensionarla in base alle esigenze. 
+  Rimuovi le implementazioni e le risorse obsolete dagli archivi di oggetti e dalle cache edge durante la distribuzione di nuove versioni del carico di lavoro. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Modifica la conservazione dei dati di log in CloudWatch Logs](https://docs.aws.amazon.com/Amazon/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) 
+  [Deduplicazione dei dati su Amazon FSx per Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-data-dedup.html) 
+  [Funzionalità di Amazon FSx per ONTAP, compresa la deduplicazione dei dati](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html#features-overview) 
+  [Invalidazione dei file su Amazon CloudFront](https://docs.aws.amazon.com/Amazon/latest/DeveloperGuide/Invalidation.html) 
+  [Utilizzo di AWS Backup per il backup e il ripristino dei file system di Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) 
+  [Che cos'è Amazon CloudWatch Logs?](https://docs.aws.amazon.com/Amazon/latest/logs/WhatIsLogs.html) 
+  [Lavorare con i backup su Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 

 **Video correlati:** 
+  [Matching fuzzy e deduplicazione di dati con trasformazioni ML per AWS Lake Formation](https://www.youtube.com/watch?v=g34xUaJ4WI4) 

 **Esempi correlati:** 
+  [Come faccio ad analizzare i miei log di accesso al server Amazon S3 utilizzando Amazon Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) 

# SUS04-BP06 Utilizzo di file system condivisi o archiviazione per accedere a dati comuni
<a name="sus_sus_data_a7"></a>

Adotta file system o un'archiviazione condivisa per evitare duplicazioni di dati e abilitare un'infrastruttura più efficiente per il tuo carico di lavoro. 

 **Anti-pattern comuni:** 
+  Esegui il provisioning dell'archiviazione per ogni singolo client. 
+  Non scolleghi volumi di dati da client inattivi. 
+  Non fornisci l'accesso allo storage su piattaforme e sistemi. 

 **Vantaggi dell'adozione di questa best practice:** usare file system o archiviazioni condivisi consente di distribuire i dati a uno o più consumatori senza doverli copiare. Questo consente di ridurre le risorse di archiviazione necessarie per il carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Se hai più utenti o applicazioni che accedono agli stessi set di dati, usare una tecnologia di archiviazione condivisa è fondamentale per abilitare un'infrastruttura efficiente per il tuo carico di lavoro. La tecnologia di archiviazione condivisa offre una posizione centrale per archiviare e gestire set di dati ed evitare la loro duplicazione. Verifica anche la coerenza dei dati su sistemi diversi. Inoltre, la tecnologia di archiviazione condivisa consente un uso più efficiente della potenza di elaborazione, poiché più risorse di calcolo possono accedere ed elaborare i dati allo stesso momento in parallelo. 

 Acquisisci i dati dai servizi di archiviazione condivisa in base alle necessità e scollega i volumi non utilizzati per liberare le risorse. 

 **Passaggi dell'implementazione** 
+  Esegui la migrazione dei dati nell'archiviazione condivisa quando i dati hanno più consumer. Ecco alcuni esempi della tecnologia di archiviazione condivisa su AWS:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_data_a7.html)
+ Copia o acquisici i dati solo da file system condivisi in base alle necessità. Come esempio, puoi creare un [file system Amazon FSx for Lustre supportato da Amazon S3](https://aws.amazon.com/blogs/storage/new-enhancements-for-moving-data-between-amazon-fsx-for-lustre-and-amazon-s3/) e caricare solo il sottoinsieme di dati richiesti per l'elaborazione dei processi su Amazon FSx.
+ Elimina i dati nella modalità corretta per i tuoi modelli di utilizzo come definito in [SUS04-BP03 Utilizzo delle policy per gestire il ciclo di vita dei set di dati](sus_sus_data_a4.md).
+  Distacca i volumi dai client che non li utilizzano attivamente. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Collegare il file system a un bucket Amazon S3 ](https://docs.aws.amazon.com/fsx/latest/LustreGuide/create-dra-linked-data-repo.html)
+ [ Usare Amazon EFS per AWS Lambda nelle applicazioni serverless ](https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aws-lambda-in-your-serverless-applications/)
+ [ Amazon EFS Intelligent-Tiering ottimizza i costi per carichi di lavoro con modelli di accesso mutevoli ](https://aws.amazon.com/blogs/aws/new-amazon-efs-intelligent-tiering-optimizes-costs-for-workloads-with-changing-access-patterns/)
+ [ Uso di Amazon FSx con repository di dati on-premise](https://docs.aws.amazon.com/fsx/latest/LustreGuide/fsx-on-premises.html)

 **Video correlati:** 
+ [ ottimizzazione dei costi di archiviazione con Amazon EFS ](https://www.youtube.com/watch?v=0nYAwPsYvBo)

# SUS04-BP07 Riduzione al minimo dello spostamento di dati tra reti
<a name="sus_sus_data_a8"></a>

Usa file system condivisi o l'archiviazione a oggetti per accedere ai dati comuni e contenere le risorse di rete totali necessarie per supportare i trasferimenti dei dati per il carico di lavoro.

 **Anti-pattern comuni:** 
+  Archivia tutti i dati nella stessa Regione AWS, indipendentemente dalla posizione degli utenti. 
+  Non ottimizzi la dimensione e il formato dei dati prima di trasferirli sulla rete. 

 **Vantaggi dell'adozione di questa best practice:** l'ottimizzazione del trasferimento dei dati sulla rete riduce la quantità di risorse di rete totali richieste per il carico di lavoro e diminuisce l'impatto ambientale. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Trasferire i dati all'interno dell'organizzazione significa disporre di risorse di elaborazione, rete e archiviazione. Usa tecniche per ridurre il movimento dei dati e migliorare l'efficienza generale del tuo carico di lavoro. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Considera la vicinanza ai dati o agli utenti come un fattore importante nella fase decisionale per la [selezione di un'area geografica per il tuo carico di lavoro](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/). 
+  Esegui la partizione dei servizi consumati a livello regionale in modo che i dati specifici della regione siano archiviati nella regione in cui sono usati. 
+  Usa formati di file efficienti (come Parquet oppure ORC) e comprimi i dati prima di spostarli sulla rete. 
+  Non trasferire dati inutilizzati. Alcuni esempi che possono aiutarti a evitare di spostare dati inutilizzati: 
  +  Riduci le risposte API solo ai dati pertinenti. 
  +  Aggrega i dati laddove richiesto (le informazioni a livello di record non sono necessarie). 
  +  Consulta [Well-Architected Lab - Optimize Data Pattern Using Amazon Redshift Data Sharing (Ottimizzare lo schema dei dati con la condivisione dei dati di Amazon Redshift)](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/). 
  +  Considera il servizio [di condivisione dei dati tra account in AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html). 
+  Utilizza servizi in grado di supportarti nell'esecuzione del codice in posizioni più vicine agli utenti del carico di lavoro.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_data_a8.html)

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/) 
+  [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure/) 
+  [Funzionalità principali di Amazon CloudFront incluso CloudFront Global Edge Network](https://aws.amazon.com/cloudfront/features/) 
+  [Compressione delle richieste HTTP in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gzip.html) 
+  [Compressione intermedia dei dati con Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-output-compression.html#HadoopIntermediateDataCompression) 
+  [Caricamento di file di dati compressi da Amazon S3 a Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html) 
+  [Distribuzione dei file compressi con Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html) 

 **Video correlati:** 
+ [ Demystifying data transfer on AWS (Demistificazione del trasferimento dei dati su AWS) ](https://www.youtube.com/watch?v=-MqXgzw1IGA)

 **Esempi correlati:** 
+ [ Progettazione di architetture per la sostenibilità: riduzione al minimo dello spostamento dei dati tra reti ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)

# SUS04-BP08 Backup dei dati solo quando sono difficili da ricreare
<a name="sus_sus_data_a9"></a>

Evita il back-up di dati senza valore aziendale per ridurre i requisiti delle risorse di archiviazione per il tuo carico di lavoro. 

 **Anti-pattern comuni:** 
+  Non hai una strategia di back-up per i tuoi dati. 
+  Esegui il back-up di dati che possono essere facilmente ricreati. 

 **Vantaggi dell'adozione di questa best practice:** se si evita il back-up di dati non critici si riduce la quantità di risorse di archiviazione richiesta per il carico di lavoro e si diminuisce l'impatto ambientale. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Evitando il back-up di dati non necessari si possono ridurre i costi e le risorse di archiviazione utilizzate dal carico di lavoro. Esegui il backup solo dei dati che hanno un valore aziendale o sono considerati necessari per soddisfare i requisiti di conformità. Esamina le policy di backup ed escludi l'archiviazione temporanea che non offre valore in uno scenario di ripristino. 

 **Passaggi dell'implementazione** 
+  Implementazione di una policy di classificazione dei dati come definito in [SUS04-BP01 Implementazione di una policy di classificazione dei dati](sus_sus_data_a2.md). 
+  Usa le criticità della classificazione dei tuoi dati e la strategia di backup della progettazione basate su [Obiettivo del tempo di ripristino (RTO) e Obiettivo del punto di ripristino (RPO](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)). Evita il back-up di dati non critici. 
  +  Escludi i dati che possono essere facilmente ricreati. 
  +  Escludi dati temporanei dai backup. 
  +  Escludi copie locali dei dati, a meno che il tempo necessario per ripristinare tali dati da una posizione comune superi gli accordi sul livello di servizio (SLA). 
+  Usa una soluzione automatizzata o un servizio gestito per eseguire il back-up di dati aziendali strategici. 
  +  [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) è un servizio completamente gestito che semplifica la centralizzazione e l'automazione della protezione dei dati tra i servizi AWS, nel cloud e on-premise. Per linee guida pratiche su come creare back-up automatizzati con AWS Backup, consulta [Well-Architected Labs: Test di backup e ripristino dei dati](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/). 
  +  [Automatizza i back-up e ottimizza i costi di back-up per Amazon EFS con AWS Backup](https://aws.amazon.com/blogs/storage/automating-backups-and-optimizing-backup-costs-for-amazon-efs-using-aws-backup/). 

## Risorse
<a name="resources"></a>

 **Best practice correlate:** 
+ [REL09-BP01 Identificazione e backup di tutti i dati che richiedono un backup o riproduzione dei dati dalle origini](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_identified_backups_data.html)
+ [REL09-BP03 Esecuzione del backup dei dati in automatico](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_automated_backups_data.html)
+ [REL13-BP02 Utilizzo di strategie di ripristino definite per conseguire gli obiettivi di ripristino](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)

 **Documenti correlati:** 
+  [Utilizzo di AWS Backup per il backup e il ripristino dei file system di Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) 
+  [Snapshot di Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html) 
+  [Lavorare con i backup su Amazon Relational Database Service](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 
+ [Partner APN: partner per il backup](https://partners.amazonaws.com/search/partners?keyword=Backup)
+ [Marketplace AWS: prodotti che possono essere utilizzati per il backup ](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [ Backup di Amazon EFS ](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [ Backup Amazon FSx per Windows File Server ](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [ Backup e ripristino per Amazon ElastiCache (Redis OSS) ](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)

 **Video correlati:** 
+ [AWS re:Invent 2021 - Backup, ripristino di emergenza e protezione ransomware con AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup Demo: backup trasversale tra account e regioni ](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Approfondimento su AWS Backup, con Rackspace (STG341) ](https://www.youtube.com/watch?v=av8DpL0uFjc)

 **Esempi correlati:** 
+ [Well-Architected Lab: Test di backup e ripristino dei dati ](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Well-Architected Lab: Backup e ripristino con failback per il carico di lavoro analitico ](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [ Well-Architected Lab: Ripristino di emergenza – Backup e ripristino) ](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)

# Hardware e servizi
<a name="a-sus-hardware-and-services"></a>

**Topics**
+ [SUS 5 Come si selezionano e usano hardware e servizi cloud nell'architettura per supportare gli obiettivi di sostenibilità?](sus-05.md)

# SUS 5 Come si selezionano e usano hardware e servizi cloud nell'architettura per supportare gli obiettivi di sostenibilità?
<a name="sus-05"></a>

Cerca opportunità per ridurre l'impatto dei carichi di lavoro in termini di sostenibilità apportando modifiche alle tue prassi di gestione hardware. Riduci al minimo la quantità di hardware necessaria per il provisioning e l'implementazione e scegli l'hardware e i servizi più efficienti per il singolo carico di lavoro. 

**Topics**
+ [SUS05-BP01 Utilizzo della quantità minima di hardware per soddisfare le esigenze aziendali](sus_sus_hardware_a2.md)
+ [SUS05-BP02 Utilizzo di tipi di istanze con il minimo impatto](sus_sus_hardware_a3.md)
+ [SUS05-BP03 Utilizzo dei servizi gestiti](sus_sus_hardware_a4.md)
+ [SUS05-BP04 Ottimizzazione dell'uso degli acceleratori di calcolo basati su hardware](sus_sus_hardware_a5.md)

# SUS05-BP01 Utilizzo della quantità minima di hardware per soddisfare le esigenze aziendali
<a name="sus_sus_hardware_a2"></a>

Usa la quantità minima di hardware per il tuo carico di lavoro per soddisfare in modo efficiente le tue esigenze aziendali.

 **Anti-pattern comuni:** 
+  Non monitori l'utilizzo delle risorse. 
+  Nella tua architettura sono presenti risorse con un basso livello di utilizzo. 
+  Non analizzi l'uso di hardware statico per stabilire se deve essere ridimensionato. 
+  Non imposti obiettivi di utilizzo dell'hardware per la tua infrastruttura di elaborazione in base a KPI aziendali. 

 **Vantaggi dell'adozione di questa best practice:** il corretto dimensionamento delle risorse cloud consente di ridurre l'impatto ambientale di un carico di lavoro, risparmiare denaro ed essere in linea con i benchmark di performance. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Seleziona con precisione la quantità di hardware richiesta dal tuo carico di lavoro per migliorare l'efficienza generale. Il Cloud AWS offre la flessibilità necessaria per espandere o ridurre il numero di risorse in modo dinamico attraverso una serie di meccanismi, come [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) e soddisfare i cambiamenti della domanda. AWS offre anche [API e SDK](https://aws.amazon.com/developer/tools/) che consentono alle risorse di essere modificate con il minimo sforzo. usa queste funzionalità per apportare modifiche frequenti alle implementazioni dei carichi di lavoro. Usa inoltre le linee guida sul dimensionamento corretto degli strumenti AWS per gestire le risorse cloud in modo efficiente e soddisfare le esigenze aziendali. 

 **Passaggi dell'implementazione** 
+  Scegli il tipo di istanza più adatto alle tue esigenze. 
  + [ Come faccio a scegliere il tipo di istanza Amazon EC2 appropriato per il mio carico di lavoro? ](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
  + [ Selezione del tipo di istanza basata sugli attributi per il parco istanze Amazon EC2. ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
  + [ Crea un gruppo Auto Scaling tramite una selezione del tipo di istanza basata sugli attributi. ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)
+  Dimensiona usando i piccoli incrementi per carichi di lavoro variabili. 
+  usa più opzioni di acquisto delle risorse di calcolo per bilanciare flessibilità e scalabilità delle istanze, oltre a ridurre i costi. 
  +  [Istanze on-demand](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html) sono più adatte a carichi di lavoro nuovi, stateful e con picchi che non possono essere tipi di istanze, posizione o flessibili dal punto di vista temporale. 
  +  [Istanze spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) sono un ottimo modo per fornire altre opzioni alle applicazioni flessibili e tolleranti ai guasti. 
  +  Sfrutta i [Savings Plans per il calcolo](https://aws.amazon.com/savingsplans/compute-pricing/) per carichi di lavoro stazionari che consentono soluzioni flessibili se le tue esigenze (come AZ, area geografica, famiglie di istanze o tipi di istanze) cambiano. 
+  Usa la diversità di istanze e zone di disponibilità per ottimizzare la disponibilità delle applicazioni e sfruttare la capacità in eccesso, se possibile. 
+  Utilizza le raccomandazioni per il dimensionamento di AWS per modificare il carico di lavoro. 
  + [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
  + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+  Negozia SLA che consentano una riduzione temporanea della capacità quando l'automazione implementa risorse di sostituzione. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Ottimizzazione dell'infrastruttura AWS per la sostenibilità, Parte I: elaborazione](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)
+ [ Selezione del tipo di istanza basata sugli attributi per Auto Scaling per il parco istanze Amazon EC2 ](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [ Documentazione di AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/index.html)
+  [Uso di Lambda: ottimizzazione delle performance](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/) 
+  [Documentazione sulla scalabilità automatica](https://docs.aws.amazon.com/autoscaling/index.html) 

 **Video correlati:** 
+ [Sviluppa un ambiente di calcolo efficiente dal punto di vista dei costi, delle energie e delle risorse](https://www.youtube.com/watch?v=8zsC5e1eLCg)

 **Esempi correlati:** 
+ [Well-Architected Labs: dimensionamento appropriato con AWS Compute Optimizer e utilizzo della memoria abilitati (Livello 200)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)

# SUS05-BP02 Utilizzo di tipi di istanze con il minimo impatto
<a name="sus_sus_hardware_a3"></a>

Esegui un monitoraggio costante e usa nuovi tipi di istanza per sfruttare le migliorie in termini di efficienza energetica.

 **Anti-pattern comuni:** 
+  Utilizzi una sola famiglia di istanze. 
+  Utilizzi solo istanze x86. 
+  Specifichi un tipo di istanza nella configurazione Amazon EC2 Auto Scaling. 
+  Utilizzi istanze AWS in un modo per il quale non sono state progettate, ad esempio utilizzi istanze ottimizzate per il calcolo per un carico di lavoro a uso intensivo della memoria. 
+  Non valuti regolarmente l'uso di nuovi tipi di istanza. 
+  Non segui i consigli ricevuti dagli strumenti di dimensionamento AWS, ad esempio [AWS Compute Optimizer.](https://aws.amazon.com/compute-optimizer/) 

 **Vantaggi dell'adozione di questa best practice:** l'uso di risorse energeticamente efficienti e di dimensioni corrette ti consente di ridurre in modo considerevole l'impatto ambientale e i costi del carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 L'uso di istanze efficienti nel carico di lavoro cloud è fondamentale per ridurre l'utilizzo delle risorse e i costi. Monitora costantemente il rilascio di nuovi tipi di istanza e sfrutta le migliorie in tema di efficienza energetica, inclusi i tipi di istanza progettati per supportare carichi di lavoro specifici, come la formazione del machine learning, le inferenze e la transcodifica dei video. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Esplora e approfondisci i tipi di istanza in grado di ridurre l'impatto ambientale del carico di lavoro. 
  +  Iscriviti a [Novità di AWS](https://aws.amazon.com/new/) per rimanere aggiornato sulle più recenti tecnologie e istanze AWS. 
  +  Approfondisci i vari tipi di istanza AWS. 
  +  Impara a conoscere le istanze basate su AWS Graviton, che offrono le migliori prestazioni per watt di energia utilizzato in Amazon EC2 guardando [re:Invent 2020 - Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances (re:Invent 2020 - Approfondimenti relativi alle istanze AWS con tecnologia basata su processi Amazon EC2 Graviton2)](https://www.youtube.com/watch?v=NLysl0QvqXU) e [Approfondisci le istanze AWS Graviton3 e Amazon EC2 C7g](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents). 
+  Pianifica la transizione del carico di lavoro a tipi di istanza caratterizzati da un minore impatto. 
  +  Definisci un processo per valutare nuove caratteristiche o istanze per il carico di lavoro. Sfrutta l'agilità del cloud per testare in modo semplice e rapido in che modo i nuovi tipi di istanza possono migliorare la sostenibilità ambientale del carico di lavoro. Utilizza metriche proxy per misurare la quantità di risorse necessarie per completare un'unità di lavoro. 
  +  Se possibile, modifica il carico di lavoro in modo che funzioni con diversi numeri di CPU e quantità di memoria diverse per massimizzare la scelta del tipo di istanza. 
  +  Valuta l'ipotesi di trasferire il carico di lavoro in istanze basate su Graviton per migliorare l'efficienza delle prestazioni del carico di lavoro. 
    +  [AWS Graviton Fast Start](https://aws.amazon.com/ec2/graviton/fast-start/) 
    +  [Considerazioni relative alla transizione dei carichi di lavoro a istanze Amazon Elastic Compute Cloud basate su AWS Graviton](https://github.com/aws/aws-graviton-getting-started/blob/main/transition-guide.md) 
    +  [AWS Graviton2 for ISVs (AWS Graviton2 per fornitori di software indipendente [ISV])](https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/welcome.html) 
  +  Valuta l'ipotesi di selezionare l'opzione AWS Graviton quando utilizzi i [servizi gestiti da AWS.](https://github.com/aws/aws-graviton-getting-started/blob/main/managed_services.md) 
  +  Esegui la migrazione del carico di lavoro nelle regioni che offrono istanze con il minor impatto in termini di sostenibilità e che contemporaneamente soddisfano i requisiti aziendali. 
  +  Per i carichi di lavoro di machine learning, sfrutta l'hardware specifico per il tuo carico di lavoro, come ad esempio [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)e [Amazon EC2 DL1.](https://aws.amazon.com/ec2/instance-types/dl1/) Le istanze AWS Inferentia come Inf2 offrono fino al 50% in più di prestazioni per watt rispetto alle istanze Amazon EC2 paragonabili. 
  +  Utilizza la [inferenza con funzione di suggerimento Amazon SageMaker AI](https://docs.aws.amazon.com/sagemaker/latest/dg/inference-recommender.html) per dimensionare l'endpoint dell'inferenza ML. 
  +  Per carichi di lavoro con picchi (carichi di lavoro con requisiti non frequenti di capacità aggiuntiva), utilizza [istanze con prestazioni espandibili.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html) 
  +  Per carichi di lavoro stateless e con tolleranza ai guasti, usa le [istanze Spot Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) per aumentare l'utilizzo complessivo del cloud e ridurre l'impatto di sostenibilità delle risorse inutilizzate. 
+  Esegui e ottimizza l'istanza del carico di lavoro. 
  +  Per i carichi di lavoro effimeri, valuta le [metriche Amazon CloudWatch dell'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics) , ad esempio `CPUUtilization` , per verificare se l'istanza è inattiva o sottoutilizzata. 
  +  Per i carichi di lavoro stabili, esegui controlli con gli strumenti di dimensionamento AWS come [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) a intervalli regolari per individuare eventuali opportunità di ottimizzazione e ridimensionamento delle istanze. 
    + [ Well-Architected Lab: Raccomandazioni per il dimensionamento corretto ](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
    + [ Well-Architected Lab: dimensionamento corretto con Compute Optimizer ](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
    + [ Well-Architected Lab: ottimizzazione dei modelli hardware e conformità agli indicatori KPI di sostenibilità ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Optimizing your AWS Infrastructure for Sustainability, Part I: Compute (Ottimizzazione dell'infrastruttura AWS per la sostenibilità, Parte I: Calcolo)](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/) 
+  [AWS Graviton](https://aws.amazon.com/ec2/graviton/) 
+  [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/) 
+  [Parchi istanze di prenotazione della capacità di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cr-fleets.html) 
+  [Serie di istanze spot Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html) 
+  [Funzioni: configurazione della funzione Lambda](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) 
+ [ Selezione del tipo di istanza basata sugli attributi per il parco istanze Amazon EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [Creazione di applicazioni sostenibili, efficienti e ottimizzate in termini di costi su AWS](https://aws.amazon.com/blogs/compute/building-sustainable-efficient-and-cost-optimized-applications-on-aws/)
+ [ In che modo il pannello di controllo Contino relativo alla sostenibilità aiuta i clienti a ottimizzare la loro impronta di carbonio ](https://aws.amazon.com/blogs/apn/how-the-contino-sustainability-dashboard-helps-customers-optimize-their-carbon-footprint/)

 **Video correlati:** 
+  [Deep dive on AWS Graviton2 processer-powered Amazon EC2 instances (Approfondimenti relativi alle istanze Amazon EC2 con tecnologia basata su processi AWS Graviton2)](https://www.youtube.com/watch?v=NLysl0QvqXU) 
+  [Approfondisci le istanze AWS Graviton3 e Amazon EC2 C7g](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents) 
+ [ Sviluppa un ambiente di calcolo efficiente dal punto di vista dei costi, delle energie e delle risorse ](https://www.youtube.com/watch?v=8zsC5e1eLCg)

 **Esempi correlati:** 
+ [ Soluzione: linee guida per l'ottimizzazione dei carichi di lavoro deep learning per la sostenibilità su AWS](https://aws.amazon.com/solutions/guidance/optimizing-deep-learning-workloads-for-sustainability-on-aws/)
+  [Well-Architected Lab: Raccomandazioni per il dimensionamento corretto](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/) 
+  [Well-Architected Lab: dimensionamento corretto con Compute Optimizer](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/) 
+  [Well-Architected Lab: Ottimizzazione dei modelli hardware e conformità con gli indicatori KPI di sostenibilità](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/) 
+ [ Well-Architected Lab: Migrazione dei servizi su Graviton ](https://www.wellarchitectedlabs.com/sustainability/100_labs/100_migrate_services_to_graviton/)

# SUS05-BP03 Utilizzo dei servizi gestiti
<a name="sus_sus_hardware_a4"></a>

Usa i servizi gestiti per operare in modo più efficiente nel cloud.

 **Anti-pattern comuni:** 
+  Usi istanze Amazon EC2 in modo ridotto per eseguire le tue applicazioni. 
+  Il tuo team interno gestisce solo il carico di lavoro, senza tempo per focalizzarsi sull'innovazione o sulle semplificazioni. 
+  Implementi e mantieni tecnologie per attività che possono essere eseguite in modo più efficiente sui servizi gestiti. 

 **Vantaggi dell'adozione di questa best practice:** 
+  L'uso dei servizi gestiti sposta la responsabilità su AWS, che ha visibilità su milioni di clienti, i quali possono contribuire alla promozione di nuove innovazioni ed efficienze. 
+  Il servizio gestito distribuisce l'impatto ambientale del servizio su molti utenti a causa dei piani di controllo multi-tenet. 

 **Livello di rischio associato se questa best practice non fosse adottata:** Medium 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 I servizi gestiti consentono di affidare ad AWS la responsabilità di mantenere un utilizzo alto e un'ottimizzazione della sostenibilità dell'hardware implementato. I servizi gestiti eliminano anche l'onere operativo e amministrativo legato alla manutenzione di un servizio, consentendo al tuo team di avere più tempo e di concentrarsi sull'innovazione. 

 Esamina il carico di lavoro per identificare i componenti che possono essere sostituiti dai servizi gestiti AWS. Ad esempio, [Amazon RDS](https://aws.amazon.com/rds/), [Amazon Redshift](https://aws.amazon.com/redshift/) e [Amazon ElastiCache](https://aws.amazon.com/elasticache/) offrono un servizio di database gestito. [Amazon Athena](https://aws.amazon.com/athena/), [Amazon EMR](https://aws.amazon.com/emr/) e [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) offrono un servizio di analisi gestito. 

 **Passaggi dell'implementazione** 

1.  Esegui un inventario del tuo carico di lavoro per servizi e componenti. 

1.  Valuta e identifica i componenti che possono essere sostituiti dai servizi gestiti. Ecco alcuni esempi in cui potresti prendere in considerazione l'uso di un servizio gestito:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_hardware_a4.html)

1.  Identifica le dipendenze e crea un piano di migrazione. Aggiorna runbook e playbook. 
   +  [AWS Application Discovery Service](https://aws.amazon.com/application-discovery/) raccoglie e illustra automaticamente informazioni dettagliate sulle dipendenze delle applicazioni e sul loro utilizzo per aiutarti a prendere decisioni più informate durante la pianificazione della migrazione. 

1.  Testa il servizio prima di migrare al servizio gestito. 

1.  Usa il piano di migrazione per sostituire servizi auto-ospitati con servizi gestiti. 

1.  Monitora costantemente il servizio al termine della migrazione per apportare le modifiche richieste e ottimizzare il servizio. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Prodotti Cloud AWS](https://aws.amazon.com/products/)
+ [Calcolatore del costo totale di proprietà (TCO) di AWS](https://calculator.aws/#/)
+  [Amazon DocumentDB](https://aws.amazon.com/documentdb/) 
+  [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) 
+  [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://aws.amazon.com/msk/) 

 **Video correlati:** 
+ [ Operatività cloud su scala con AWS Managed Services](https://www.youtube.com/watch?v=OCK8GCImWZw)

# SUS05-BP04 Ottimizzazione dell'uso degli acceleratori di calcolo basati su hardware
<a name="sus_sus_hardware_a5"></a>

Ottimizza l'uso delle istanze a calcolo accelerato per ridurre i requisiti dell'infrastruttura fisica del carico di lavoro.

 **Anti-pattern comuni:** 
+  Utilizzo delle GPU non monitorato. 
+  Utilizzo di un'istanza generica per il carico di lavoro quando un'istanza appositamente sviluppata potrebbe offrire prestazioni più elevate, costi inferiori e migliori prestazioni per watt. 
+  Utilizzo di acceleratori di calcolo basati su hardware per attività in cui sono più efficienti le alternative basate su CPU. 

 **Vantaggi dell'adozione di questa best practice:** ottimizzando l'uso degli acceleratori basati su hardware, è possibile ridurre le richieste di infrastruttura fisica del carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Se si necessita di un'elevata capacità di elaborazione, si può trarre vantaggio dall'uso di istanze a calcolo accelerato, che forniscono l'accesso ad acceleratori di calcolo basati su hardware, come le unità di elaborazione grafica (GPU) e i field programmable gate array (FPGA). Questi acceleratori hardware eseguono alcune funzioni, come l'elaborazione grafica o la rilevazione della corrispondenza dei modelli di dati, in modo più efficiente rispetto alle alternative basate su CPU. Molti carichi di lavoro accelerati, come il rendering grafico, la transcodifica e il machine learning, sono altamente variabili in termini di utilizzo di risorse. Mantieni in esecuzione questo tipo di hardware solo per il tempo necessario e disattivalo automaticamente quando non serve per ridurre la quantità di risorse utilizzate. 

## Passaggi dell'implementazione
<a name="implementation-steps"></a>
+  Identifica quali [istanze a calcolo accelerato](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html) possono soddisfare le tue esigenze. 
+  Per i carichi di lavoro di machine learning, sfrutta l'hardware specifico per il tuo carico di lavoro, come ad esempio [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)e [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/). Le istanze AWS Inferentia come le istanze Inf2 offrono [prestazioni migliorate fino al 50% rispetto a istanze Amazon EC2 paragonabili](https://aws.amazon.com/machine-learning/inferentia/). 
+  Raccogli i parametri di utilizzo delle istanze a calcolo accelerato. Ad esempio, puoi utilizzare l'agente CloudWatch per raccogliere metriche come `utilization_gpu` e `utilization_memory` per le tue GPU come mostrato nella sezione relativa alla [acquisizione delle metriche della GPU NVIDIA con Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html). 
+  Ottimizza il codice, il funzionamento della rete e le impostazioni degli acceleratori hardware per garantire il pieno utilizzo dell'hardware sottostante. 
  +  [Ottimizza l impostazioni delle GPU](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/optimize_gpu.html) 
  +  [Monitoraggio e ottimizzazione delle GPU nell'AMI per il deep learning](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-gpu.html) 
  +  [Ottimizzazione dell'I/O per la messa a punto delle prestazioni delle GPU dedicate all'addestramento del deep learning in Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/optimizing-i-o-for-gpu-performance-tuning-of-deep-learning-training-in-amazon-sagemaker/) 
+  Utilizza le librerie e i driver per GPU più recenti e performanti. 
+  Utilizza l'automazione per rilasciare le istanze GPU non in uso. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Calcolo accelerato](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing) 
+ [ Progettiamo\$1 Sviluppo di architetture con chip e acceleratori personalizzati ](https://aws.amazon.com/blogs/architecture/lets-architect-custom-chips-and-accelerators/)
+ [ Come faccio a scegliere il tipo di istanza Amazon EC2 appropriato per il mio carico di lavoro? ](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+  [Istanze Amazon EC2 VT1](https://aws.amazon.com/ec2/instance-types/vt1/) 
+ [ Scegli il miglior acceleratore IA e compilatore del modello per l'inferenza nella visione artificiale con Amazon SageMaker AI ](https://aws.amazon.com/blogs/machine-learning/choose-the-best-ai-accelerator-and-model-compilation-for-computer-vision-inference-with-amazon-sagemaker/)

 **Video correlati:** 
+ [ How to select Amazon EC2 GPU instances for deep learning ](https://www.youtube.com/watch?v=4bVrIbgGWEA)
+  [Implementazione dell'inferenza deep learning a costi contenuti](https://www.youtube.com/watch?v=WiCougIDRsw) 

# Processo e cultura
<a name="a-sus-process-and-culture"></a>

**Topics**
+ [SUS 6 In che modo i processi organizzativi possono supportare gli obiettivi di sostenibilità?](sus-06.md)

# SUS 6 In che modo i processi organizzativi possono supportare gli obiettivi di sostenibilità?
<a name="sus-06"></a>

Cerca opportunità per ridurre l'impatto di sostenibilità apportando modifiche alle tue prassi di sviluppo, test e implementazione. 

**Topics**
+ [SUS06-BP01 Adozione di metodi che consentano di introdurre rapidamente migliorie in tema di sostenibilità](sus_sus_dev_a2.md)
+ [SUS06-BP02 Aggiornamento del carico di lavoro](sus_sus_dev_a3.md)
+ [SUS06-BP03 Aumento dell'utilizzo degli ambienti di costruzione](sus_sus_dev_a4.md)
+ [SUS06-BP04 Utilizzo di device farm gestite per i test](sus_sus_dev_a5.md)

# SUS06-BP01 Adozione di metodi che consentano di introdurre rapidamente migliorie in tema di sostenibilità
<a name="sus_sus_dev_a2"></a>

Adotta metodi e processi per convalidare migliorie potenziali, ridurre i costi legati ai test e offrire piccole migliorie.

 **Anti-pattern comuni:** 
+  Analizzare l'applicazione rispetto alla sostenibilità è un'attività che viene eseguita solo una volta, all'inizio di un progetto. 
+  Il tuo carico di lavoro non è aggiornato, poiché il processo di rilascio è troppo complesso per introdurre modifiche minori per l'efficienza delle risorse. 
+  Non hai meccanismi per migliorare il tuo carico di lavoro in termini di sostenibilità. 

 **Vantaggi dell'adozione di questa best practice:** definendo un processo per avviare e monitorare le migliorie in termini di sostenibilità, potrai adottare continuamente nuove funzionalità, eliminare i problemi e migliorare l'efficienza del carico di lavoro. 

 **Livello di rischio associato se questa best practice non fosse adottata:** medio 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Testa e convalida potenziali miglioramenti all'impatto sulla sostenibilità prima di implementarli in produzione. Tieni in considerazione il costo dei test quando calcoli il potenziale vantaggio futuro di un miglioramento. Sviluppa metodi di test a basso costo per consentire la distribuzione di piccoli miglioramenti. 

 **Passaggi dell'implementazione** 
+  Aggiungi i requisiti per migliorare la sostenibilità nel tuo backlog di sviluppo. 
+  Usa un [processo di migliorie](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/improvement-process.html) iterativo che ti consente di identificare, valutare, dare la priorità, testare e implementare queste migliorie. 
+  Migliora e semplifica continuamente i tuoi processi di sviluppo. Ad esempio, [Automatizza il processo di distribuzione del software con pipeline di distribuzione e integrazione continue (CI/CD)](https://aws.amazon.com/getting-started/hands-on/set-up-ci-cd-pipeline/) per testare e distribuire migliorie potenziali per ridurre il livello di impegno e gli errori causati da processi manuali. 
+  Sviluppa e testa i potenziali miglioramenti utilizzando i componenti rappresentativi minimi realizzabili per ridurre i costi legati ai test. 
+  Valuta continuamente l'impatto delle migliorie e fai gli adeguamenti richiesti. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS offre soluzioni di sostenibilità](https://aws.amazon.com/sustainability/) 
+ [ Procedure di sviluppo agile e scalabile basate su AWS CodeCommit](https://aws.amazon.com/blogs/devops/scalable-agile-development-practices-based-on-aws-codecommit/)

 **Video correlati:** 
+ [ Offrire architetture sostenibili e ad alte prestazioni ](https://www.youtube.com/watch?v=FBc9hXQfat0)

 **Esempi correlati:** 
+  [Well-Architected Lab - Trasformare i report su costi e utilizzo in report sull'efficienza](https://www.wellarchitectedlabs.com/sustainability/300_labs/300_cur_reports_as_efficiency_reports/) 

# SUS06-BP02 Aggiornamento del carico di lavoro
<a name="sus_sus_dev_a3"></a>

Aggiorna il tuo carico di lavoro per adottare funzionalità efficienti, eliminare le problematiche e migliorare l'efficienza generale del tuo carico di lavoro. 

 **Anti-pattern comuni:** 
+ Ritieni che l'architettura corrente diventi statica e non venga aggiornata nel corso del tempo.
+  Non disponi di sistemi né esegui regolarmente una valutazione per la compatibilità di software e pacchetti aggiornati con il carico di lavoro. 

 **Vantaggi dell'adozione di questa best practice:** la definizione di un processo per garantire il costante aggiornamento del carico di lavoro ti consentirà di adottare nuove caratteristiche e funzionalità, risolvere i problemi e migliorare l'efficienza del carico di lavoro.

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Sistemi operativi, runtime, middleware, librerie e applicazioni aggiornati possono incidere sull'efficienza dei carichi di lavoro e facilitano l'adozione delle tecnologie più efficienti. Il software aggiornato potrebbe anche includere funzionalità per misurare in modo più accurato l'impatto in termini di sostenibilità del carico di lavoro, poiché i fornitori offrono caratteristiche per raggiungere i propri obiettivi di sostenibilità. Adotta una cadenza regolare per aggiornare il tuo carico di lavoro con le ultime funzionalità e i rilasci più recenti. 

 **Passaggi dell'implementazione** 
+  Definisci un processo e una pianificazione per valutare nuove caratteristiche o istanze per il carico di lavoro. Sfrutta l'agilità del cloud per testare in modo semplice e rapido il modo in cui le nuove funzionalità possono migliorare il carico di lavoro nei seguenti ambiti: 
  +  Riduzione dell'impatto a livello di sostenibilità. 
  +  Raggiungimento di maggiore efficienza in termini di prestazioni. 
  +  Eliminazione delle barriere finalizzata a un miglioramento pianificato. 
  +  Miglioramento della capacità di misurare e gestire l'impatto a livello di sostenibilità. 
+  Esegui l'inventario del software e dell'architettura e identifica i componenti che richiedono un aggiornamento. 
  +  Puoi usare [AWS Systems Manager Inventory](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html) per raccogliere i metadati relativi a sistema operativo (SO), applicazioni e istanze dalle istanze Amazon EC2 per avere una panoramica immediata su quali istanze stanno eseguendo il software e le configurazioni richieste dalle policy software e quali istanze devono essere aggiornate. 
+  Individua le modalità di aggiornamento dei componenti del carico di lavoro.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/sus_sus_dev_a3.html)
+  Utilizza l'automazione del processo di aggiornamento per ridurre il livello di impegno per distribuire le nuove funzionalità e limitare gli errori causati dai processi manuali. 
  +  Puoi usare [CI/CD](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/) per aggiornare automaticamente le AMI, le immagini di container e altri artefatti relativi alla tua applicazione cloud. 
  +  Puoi usare strumenti come [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) per automatizzare il processo degli aggiornamenti di sistema e pianificare le attività tramite [Finestre di manutenzione AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html). 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [Centro di progettazione AWS](https://aws.amazon.com/architecture) 
+  [Le novità di AWS](https://aws.amazon.com/new/?ref=wellarchitected&ref=wellarchitected) 
+  [Strumenti per sviluppatori AWS](https://aws.amazon.com/products/developer-tools/) 

 **Esempi correlati:** 
+  [ Well-Architected Labs: Inventario e gestione delle patch](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/) 
+  [Laboratorio: AWS Systems Manager](https://mng.workshop.aws/ssm.html) 

# SUS06-BP03 Aumento dell'utilizzo degli ambienti di costruzione
<a name="sus_sus_dev_a4"></a>

Aumenta l'uso delle risorse per sviluppare, testare e creare i tuoi carichi di lavoro.

 **Anti-pattern comuni:** 
+  Esegui il provisioning manuale o interrompi i tuoi ambienti di sviluppo. 
+  Fai in modo che i tuoi ambienti di sviluppo siano in esecuzione indipendentemente dalle attività di test, creazione o rilascio (ad esempio, eseguire un ambiente al di fuori dell'orario di lavoro dei membri del tuo team di sviluppo). 
+  Esegui un provisioning eccessivo delle tue risorse per gli ambienti di creazione. 

 **Vantaggi derivanti dall'adozione di questa best practice:** aumentando l'uso degli ambienti di sviluppo, puoi migliorare l'efficienza complessiva del tuo carico di lavoro cloud, allocando al contempo le risorse di cui gli sviluppatori hanno bisogno per creare, testare e sviluppare in modo efficiente. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

 Utilizza l'automazione e l'infrastruttura come codice per rendere operativi gli ambienti di produzione quando necessario e dismetterli quando non vengono utilizzati. Un modello comune consiste nel pianificare periodi di disponibilità che coincidano con l'orario di lavoro dei membri del team incaricati dello sviluppo. Gli ambienti di test devono essere molto simili alla configurazione di produzione. Tuttavia, cerca la possibilità di utilizzare tipi di istanze con capacità di espansione, istanze Spot Amazon EC2, servizi di database con dimensionamento automatico, container e tecnologie serverless per allineare la capacità di sviluppo e test all'uso. Limita i volumi di dati per soddisfare solo i requisiti di test. Se usi i dati di produzione per i test, rifletti sulla possibilità di condividere i dati di produzione invece di spostarli. 

 **Passaggi dell'implementazione** 
+  Usa l'infrastruttura come codice per eseguire il provisioning dei tuoi ambienti di sviluppo. 
+  Utilizza l'automazione per gestire il ciclo di vita degli ambienti di sviluppo e test e massimizzare l'efficienza delle tue risorse di sviluppo. 
+  Utilizza strategie per ottimizzare l'utilizzo degli ambienti di sviluppo e test. 
  +  Utilizza ambienti rappresentativi minimi realizzabili per lo sviluppo e il test di potenziali miglioramenti. 
  +  Utilizza tecnologie serverless, se possibile. 
  +  Utilizza istanze on-demand per integrare i dispositivi per gli sviluppatori. 
  +  Utilizza i tipi di istanze con capacità di espansione, istanze Spot e altre tecnologie per allineare la capacità di compilazione all'uso. 
  +  Adotta servizi cloud nativi per un accesso sicuro alle shell delle istanze invece di implementare parchi istanze di host bastion. 
  +  Dimensiona automaticamente le tue risorse di sviluppo in base alle tue attività. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+  [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 
+  [ Istanze espandibili di prestazioni Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html) 
+  [Che cos'è AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
+ [ Che cos'è AWS CodeBuild? ](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [ Instance Scheduler su AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)

 **Video correlati:** 
+ [Best practice sull'integrazione continua ](https://www.youtube.com/watch?v=77HvSGyBVdU)

# SUS06-BP04 Utilizzo di device farm gestite per i test
<a name="sus_sus_dev_a5"></a>

Usa device farm gestite per testare in maniera efficiente una nuova funzionalità su un set rappresentativo di hardware.

 **Anti-pattern comuni:** 
+  Testa e distribuisci manualmente la tua applicazione su singoli dispositivi fisici. 
+  Non usare il servizio di test delle app per testare e interagire con le tue app (ad esempio, Android, iOS e app Web) su dispositivi fisici reali. 

 **Vantaggi dell'adozione di questa best practice:** usare le device farm gestite per testare applicazioni abilitate al cloud offre una serie di vantaggi: 
+  Offrono funzionalità più efficienti per testare le applicazioni su un'ampia gamma di dispositivi. 
+  Eliminano la necessità di un'infrastruttura in-house per i test. 
+  Offrono diverse tipologie di dispositivi, tra cui hardware di generazioni precedenti e meno diffuso, eliminando così la necessità di aggiornamenti non necessari dei dispositivi. 

 **Livello di rischio associato se questa best practice non fosse adottata:** basso 

## Guida all'implementazione
<a name="implementation-guidance"></a>

L'uso di device farm gestite può aiutarti a semplificare il processo di test per le nuove funzionalità su un gruppo rappresentativo di hardware. Le device farm gestite offrono diversi tipi di dispositivi, inclusi hardware meno diffusi e di generazioni precedenti, ed evitano l'impatto sulla sostenibilità dei clienti dovuti ad aggiornamenti dei dispositivi non necessari.

 **Passaggi dell'implementazione** 
+  Definisci i requisiti di test ed esegui la pianificazione (come tipo di test, sistemi operativi e programma di test). 
  +  Puoi usare [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) per raccogliere e analizzare dati lato client e formulare il tuo piano di test. 
+  Seleziona la device farm gestita che supporta i tuoi requisiti di test. Ad esempio, puoi usare [AWS Device Farm](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) per testare e capire l'impatto delle tue modifiche su un set rappresentativo di hardware. 
+  Usa l'integrazione continua/l'implementazione continua (CI/CD) per pianificare ed eseguire i test. 
  + [ Integrazione di AWS Device Farm con la pipeline CI/CD per eseguire i test Selenium sui diversi browser ](https://aws.amazon.com/blogs/devops/integrating-aws-device-farm-with-ci-cd-pipeline-to-run-cross-browser-selenium-tests/)
  + [ Creazione e test di app iOS e iPadOS con AWS DevOps e servizi mobili ](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)
+  Esamina sempre i risultati dei test e apporta le migliorie richieste. 

## Risorse
<a name="resources"></a>

 **Documenti correlati:** 
+ [ Elenco dei dispositivi AWS Device Farm](https://awsdevicefarm.info/)
+ [ Visualizzazione del dashboard CloudWatch RUM ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-view-data.html)

 **Esempi correlati:** 
+ [ App di esempio AWS Device Farm per Android ](https://github.com/aws-samples/aws-device-farm-sample-app-for-android)
+ [ App di esempio AWS Device Farm per iOS ](https://github.com/aws-samples/aws-device-farm-sample-app-for-ios)
+ [ Test Appium Web per AWS Device Farm](https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium-python)

 **Video correlati:** 
+ [ Ottimizza le applicazioni con gli approfondimenti degli utenti finali con Amazon CloudWatch RUM ](https://www.youtube.com/watch?v=NMaeujY9A9Y)