Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Casi d'uso per l'etichettatura
<a name="tagging-use-cases"></a>

**Topics**
+ [Tag per l'allocazione dei costi e la gestione finanziaria](tags-for-cost-allocation-and-financial-management.md)
+ [Tag per operazioni e supporto](tags-for-operations-and-support.md)
+ [Tag per la sicurezza dei dati, la gestione del rischio e il controllo degli accessi](tags-for-data-security-risk-management-and-access-control.md)

# Tag per l'allocazione dei costi e la gestione finanziaria
<a name="tags-for-cost-allocation-and-financial-management"></a>

 Uno dei primi casi d'uso di etichettatura che le organizzazioni affrontano spesso è la visibilità e la gestione dei costi e dell'utilizzo. Di solito ci sono alcuni motivi per questo: 
+  **In genere si tratta di uno scenario ben compreso e i requisiti sono ben noti.** Ad esempio, i team finanziari vogliono vedere il costo totale dei carichi di lavoro e dell'infrastruttura che si estendono su più servizi, funzionalità, account o team. Un modo per ottenere questa visibilità dei costi consiste nell'etichettare in modo coerente le risorse. 
+  **I tag e i relativi valori sono chiaramente definiti.** Di solito, i meccanismi di allocazione dei costi esistono già nei sistemi finanziari di un'organizzazione, ad esempio il monitoraggio per centro di costo, unità aziendale, team o funzione organizzativa. 
+  **Ritorno sull'investimento rapido e dimostrabile.** È possibile tenere traccia delle tendenze di ottimizzazione dei costi nel tempo quando le risorse vengono etichettate in modo coerente, ad esempio per le risorse che sono state dimensionate correttamente, ridimensionate automaticamente o inserite in una pianificazione. 

 Capire come si sostengono i costi AWS consente di prendere decisioni finanziarie informate. Conoscere i costi sostenuti a livello di risorse, carico di lavoro, team o organizzazione migliora la comprensione del valore fornito al livello applicabile rispetto ai risultati aziendali raggiunti. 

 I team di progettazione potrebbero non avere esperienza nella gestione finanziaria delle proprie risorse. Affidare una persona con competenze specialistiche nella gestione AWS finanziaria, in grado di formare i team di progettazione e sviluppo sui fondamenti della gestione AWS finanziaria e creare un rapporto tra finanza e ingegneria per promuovere la cultura della, FinOps aiuterà a raggiungere risultati misurabili per l'azienda e incoraggerà i team a sviluppare tenendo conto dei costi. La definizione di buone pratiche finanziarie è trattata in modo approfondito dal [Cost Optimization Pillar](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) del Well-Architected Framework, ma toccheremo alcuni dei principi fondamentali in questo white paper. 

# Tag di allocazione dei costi
<a name="cost-allocation-tags"></a>

 L'allocazione dei costi si riferisce all'assegnazione o alla distribuzione dei costi sostenuti agli utenti o ai beneficiari di tali costi secondo un processo definito. **Nel contesto di questo white paper, dividiamo l'allocazione dei costi in due tipi: showback e chargeback.** 

 Gli strumenti e i meccanismi di *showback aiutano* ad aumentare la consapevolezza dei costi. *Chargeback* aiuta a recuperare i costi e favorisce la consapevolezza dei costi. *Showback* riguarda la presentazione, il calcolo e la rendicontazione degli addebiti sostenuti da un'entità specifica, ad esempio un'unità aziendale, un'applicazione, un utente o un centro di costo. Ad esempio: «il team di progettazione dell'infrastruttura si è occupato di X dollari di AWS spesa il mese scorso». Il *chargeback* riguarda l'addebito effettivo dei costi sostenuti a tali entità tramite processi contabili interni dell'organizzazione, come i sistemi finanziari o i voucher contabili. Ad esempio: «X \$1 sono stati detratti dal budget del team di progettazione dell'infrastruttura». AWS In entrambi i casi, etichettare le risorse in modo appropriato può aiutare ad allocare i costi a un'entità, con l'unica differenza se ci si aspetta che qualcuno effettui o meno un pagamento. 

 La governance finanziaria dell'organizzazione potrebbe richiedere una contabilità trasparente dei costi sostenuti a livello di applicazione, unità aziendale, centro di costo e team. L'esecuzione dell'attribuzione dei [costi supportata dai tag di allocazione](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) dei costi fornisce i dati necessari per attribuire con precisione i costi sostenuti da un'entità a partire da risorse adeguatamente etichettate. 
+  **Responsabilità**: assicuratevi che i costi siano assegnati ai responsabili dell'utilizzo delle risorse. Un singolo punto di assistenza o gruppo può essere responsabile della revisione e della rendicontazione delle spese. 
+  **Trasparenza finanziaria**: mostra una visione chiara delle allocazioni di liquidità verso l'IT creando dashboard efficaci e analisi dei costi significative per la leadership. 
+  **Investimenti IT informati**: monitora il ROI in base al progetto, all'applicazione o alla linea di business e consenti ai team di prendere decisioni aziendali migliori, ad esempio stanziando maggiori fondi per applicazioni che generano entrate. 

 In sintesi, i tag di allocazione dei costi possono aiutarti a dirti: 
+  Chi possiede la spesa ed è responsabile dell'ottimizzazione? 
+  Quale carico di lavoro, applicazione o prodotto è destinato alla spesa? In quale ambiente o palcoscenico? 
+  Quali aree di spesa stanno crescendo più rapidamente? 
+  Quanta spesa può essere detratta da un AWS budget in base alle tendenze passate? 
+  Qual è stato l'impatto degli sforzi di ottimizzazione dei costi su particolari carichi di lavoro, applicazioni o prodotti? 

 L'attivazione dei tag delle risorse per l'allocazione dei costi aiuta a definire le pratiche di misurazione all'interno dell'organizzazione che possono essere utilizzate per fornire la visibilità dell' AWS utilizzo e aumentare la trasparenza nella responsabilità delle spese. Si concentra inoltre sulla creazione di un livello di granularità appropriato per quanto riguarda la visibilità dei costi e dell'utilizzo e sull'influenza dei comportamenti di consumo del cloud attraverso la reportistica sull'allocazione dei costi e il monitoraggio dei KPI. 

# Creazione di una strategia di allocazione dei costi
<a name="building-a-cost-allocation-strategy"></a>

## Definizione e implementazione di un modello di allocazione dei costi
<a name="defining-and-implementing-a-cost-allocation-model"></a>

Crea account e struttura dei costi per le risorse in cui vengono impiegate. AWS Stabilisci la relazione tra i costi derivanti dalla AWS spesa, il modo in cui tali costi sono stati sostenuti e chi o cosa ha sostenuto tali costi. Le strutture di costo comuni si basano su AWS Organizations Account AWS, ambienti ed entità all'interno delle organizzazioni, ad esempio una linea di business o un carico di lavoro. Le strutture dei costi possono essere basate su più attributi per consentire l'esame dei costi in modi diversi o a diversi livelli di granularità, ad esempio ripartendo i costi dei singoli carichi di lavoro in base alla linea di business in cui operano.

 *Quando scegli una struttura dei costi in linea con i risultati desiderati, valuta i meccanismi di allocazione dei costi in base alla *facilità* di implementazione rispetto alla precisione desiderata.* Ciò potrebbe includere considerazioni relative alla responsabilità, alla disponibilità degli strumenti e ai cambiamenti culturali. I tre modelli più diffusi di allocazione dei costi da cui i AWS clienti di solito partono sono: 
+  **Basato sull'account**: questo modello richiede il minimo sforzo e offre un'elevata precisione per gli showback e i chargeback, ed è adatto per le organizzazioni che hanno una struttura di account definita (ed è coerente con le raccomandazioni del white paper [Organizing Your AWS](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) Environment Using Multiple Accounts). Ciò offre una chiara visibilità dei costi per account. Per la visibilità e l'allocazione dei costi, è possibile utilizzare [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html)i [report sui costi e sull'utilizzo e](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) i [AWS budget](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) per il monitoraggio e il monitoraggio dei costi. Questi strumenti forniscono opzioni di filtraggio e raggruppamento per. Account AWS Dal punto di vista dell'allocazione dei costi, questo modello non deve basarsi su un'etichettatura accurata delle singole risorse. 
+  Basato su **unità aziendali o team**: costi allocabili a team, unità aziendali o organizzazioni all'interno di un'azienda. Questo modello richiede uno sforzo moderato, offre un'elevata precisione per gli showback e i chargeback ed è adatto per le organizzazioni che hanno una struttura di account definita (in genere utilizzata AWS Organizations), con separazione tra vari team, applicazioni e tipi di carico di lavoro. [Ciò offre una chiara visibilità dei costi tra team e applicazioni e, come ulteriore vantaggio, riduce il rischio di raggiungere le quote di servizio all'interno di un'unica AWS soluzione.](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) Account AWS Ad esempio, ogni team può avere cinque account (`prod`,,, `staging` `test``dev`,`sandbox`) e non ci sono due team e applicazioni che condivideranno lo stesso account. Con tale struttura, [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) fornirà quindi la funzionalità per raggruppare gli account o altri tag («meta-tagging») in categorie, che possono essere tracciate negli strumenti citati nell'esempio precedente. È importante notare che AWS Organizations consente l'etichettatura di account e unità organizzative (OUs), tuttavia questi tag non saranno applicabili per l'allocazione dei costi e i report di fatturazione (ovvero, non è possibile raggruppare o filtrare i costi per unità organizzative). AWS Cost Explorer AWS A tal fine è necessario utilizzare le Cost Categories. 
+  Basato **su tag**: questo modello richiede uno sforzo maggiore rispetto ai due precedenti e fornirà un'elevata precisione per gli showback e i chargeback a seconda dei requisiti e dell'obiettivo finale. Sebbene raccomandiamo vivamente di adottare le pratiche descritte nel white paper [Organization Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html), realisticamente i clienti si trovano spesso a dover affrontare strutture di account miste e complesse che richiedono tempo per migrare. L'implementazione di una strategia di tagging rigorosa ed efficace è la chiave in questo scenario, seguita dall'[attivazione dei tag pertinenti per l'allocazione dei costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) nella console Billing and Cost Management ( AWS Organizations infatti, i tag possono essere attivati per l'allocazione dei costi solo dall'account Management Payer). Dopo l'attivazione dei tag per l'allocazione dei costi, è possibile utilizzare gli strumenti per la visibilità e l'allocazione dei costi menzionati nei metodi precedenti per gli showback e i chargeback. Tieni presente che i tag di allocazione dei costi non sono retroattivi e verranno visualizzati negli strumenti di reporting di fatturazione e monitoraggio dei costi solo dopo essere stati attivati per l'allocazione dei costi. 

 Per riassumere, se è necessario tenere traccia dei costi per unità aziendale, è possibile utilizzare [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) per raggruppare di conseguenza gli account collegati all'interno AWS dell'organizzazione e visualizzare questo raggruppamento nei report di fatturazione. [Quando si creano account separati per ambienti di produzione e non di produzione, è inoltre possibile filtrare i costi relativi agli ambienti utilizzando strumenti come [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html), o tenere traccia di tali costi utilizzando Budgets.AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) Infine, se il tuo caso d'uso richiede un monitoraggio dei costi più granulare, ad esempio per singoli carichi di lavoro o applicazioni, puoi etichettare di conseguenza le risorse all'interno di tali account, [attivare le chiavi di tag per l'allocazione dei costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) nell'account di gestione e quindi filtrare tale costo per chiavi di tag negli strumenti di reporting di fatturazione. 

## Definizione di processi di rendicontazione e monitoraggio dei costi
<a name="establing-cost-reporting-and-monitoring-processes"></a>

 Inizia con l'identificazione dei tipi di costi importanti per gli stakeholder interni (ad esempio, spesa giornaliera, costo per account, costo per X, costi ammortizzati). In questo modo, è possibile mitigare i rischi di bilancio associati a spese impreviste o anomale più rapidamente rispetto all'attesa della fattura definitiva. AWS I tag forniscono l'attribuzione che abilita questi scenari di reporting. Le informazioni ottenute dalla rendicontazione possono aiutarvi a mitigare l'impatto di spese anomale e impreviste sui budget finanziari. Quando si verifica un aumento imprevisto dei costi, è importante valutare se si è verificato un aumento imprevisto del valore fornito, in modo da poter determinare se e quali azioni sono necessarie. 

 Quando sviluppate una strategia di etichettatura per supportare l'allocazione dei costi, tenete presente i seguenti elementi: 
+  **AWS Organizations**- L'allocazione dei costi all'interno di più account può essere eseguita per account, gruppi di account o gruppo di tag creati per le risorse di tali account. I tag creati per le risorse che risiedono in singoli account in AWS Organizations possono essere utilizzati per l'allocazione dei costi solo dall'account di gestione. 
+  **AWS Account**: l'allocazione dei costi all'interno di uno Account AWS può essere eseguita utilizzando dimensioni aggiuntive come servizi o regioni. È possibile etichettare ulteriormente le risorse all'interno di un account e lavorare con i gruppi di tali tag di risorse. 
+  Tag di **allocazione dei costi: sia i tag** creati dall'utente che i tag AWS generati possono essere attivati per l'allocazione dei costi, se necessario. L'attivazione dei tag per l'allocazione dei costi nella console di fatturazione (dell'account di gestione AWS Organizations) facilita lo showback e i chargeback. 
+  **Categorie di costo: le** categorie di AWS costo consentono di raggruppare gli account e i tag di raggruppamento («meta-tagging») all'interno di un' AWS organizzazione, il che offre inoltre la possibilità di analizzare i costi relativi a queste categorie tramite strumenti come AWS Budgets e Cost and AWS Cost Explorer Usage Report. AWS 

## Esecuzione di showback e chargeback per unità aziendali, team o organizzazioni all'interno dell'azienda
<a name="performing-showback-and-chargeback-for-business-units"></a>

 Attribuisci i costi utilizzando il processo di allocazione dei costi supportato dalla struttura dei costi e dai tag di allocazione dei costi. I tag possono essere utilizzati per fornire informazioni ai team che non sono direttamente responsabili del pagamento dei costi, ma sono responsabili per averli sostenuti. Questo approccio consente di conoscere il loro contributo alla spesa e il modo in cui tali costi vengono sostenuti. Effettua il chargeback ai team direttamente responsabili dei costi per recuperare le spese relative alle risorse che hanno consumato e per informare i team su tali costi e su come sono stati sostenuti. 

## Misurazione e diffusione dell'efficienza o del valore KPIs
<a name="measuring-and-circulating-kpis"></a>

 Concorda una serie di parametri relativi al costo unitario o ai KPI per misurare l'impatto dei tuoi investimenti nella gestione finanziaria nel cloud. Questo esercizio crea un linguaggio comune tra gli stakeholder tecnologici e aziendali e racconta una storia basata sull'economia, anziché una storia incentrata esclusivamente sulla spesa assoluta e aggregata. Per ulteriori informazioni, consultate questo blog che illustra [come le metriche unitarie possono](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metrics-help-create-alignment-between-business-functions/) aiutare a creare l'allineamento tra le funzioni aziendali. 

## Allocazione di spese non allocabili
<a name="allocating-unallocatable-spend"></a>

 A seconda delle pratiche contabili dell'organizzazione, diversi tipi di addebito potrebbero richiedere un trattamento diverso. Identifica le risorse o le categorie di costo che non possono essere etichettate. A seconda dei servizi utilizzati e di quelli che si prevede di utilizzare, concordate i meccanismi su come trattare e misurare tali spese non allocabili. Ad esempio, controlla l'elenco delle risorse supportate da [AWS Resource Groups and Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html) nella Guida per l'utente di *AWS Resource Groups and Tags*. 

 Un esempio comune di categoria di costo che non può essere etichettata sono alcune commissioni per sconti basati su impegni, come Reserved Instances (RI) e Savings Plans (SP). Sebbene le tariffe di abbonamento e le tariffe SP e RI non utilizzate non possano essere contrassegnate prima che compaiano negli strumenti di reporting di fatturazione, è possibile monitorare in seguito come gli sconti RI e SP si applicano agli account, alle risorse e ai relativi tag. AWS Organizations Ad esempio, AWS Cost Explorer è possibile esaminare il costo ammortizzato, raggruppare la spesa in base ai tag key pertinenti e applicare filtri pertinenti al proprio caso d'uso. Nel rapporto sui AWS costi e sull'utilizzo (CUR), puoi filtrare le righe che corrispondono all'utilizzo coperto dagli sconti RI e SP (leggi di più nella sezione sui casi d'uso della [documentazione CUR](https://docs.aws.amazon.com/cur/latest/userguide/use-cases.html)) e selezionare le colonne che riguardano solo te. Ogni chiave tag attivata per l'allocazione dei costi verrà presentata in una colonna separata alla fine del rapporto CUR, in modo analogo a come viene presentata in altri report di fatturazione precedenti, come il [rapporto di allocazione dei costi mensile](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html). Per ulteriori riferimenti, consulta i [AWS Well-Architected](https://www.wellarchitectedlabs.com/cost/300_labs/300_cur_queries/) Labs per esempi di come ottenere informazioni su costi e utilizzo dai dati CUR. 

## Creazione di report
<a name="reporting-charges"></a>

 Oltre agli AWS strumenti disponibili per agevolare gli showback e i chargeback, è disponibile una serie di altre soluzioni AWS create e di terze parti che possono aiutare a monitorare il costo delle risorse con tag e misurare l'efficacia della strategia di tagging. [A seconda dei requisiti e dell'obiettivo finale dell'organizzazione, è possibile investire tempo e risorse nella creazione di soluzioni personalizzate o acquistare strumenti forniti da uno dei Management Tools Competency Partner.Cloud AWS](https://aws.amazon.com/products/management-tools/partner-solutions/?partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=%2Aall&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-use-case=%2Aall&awsf.partner-solutions-filter-partner-location=%2Aall) Se decidi di creare il tuo strumento di allocazione *dei costi da un'unica fonte di verità* con parametri controllati pertinenti per l'azienda, il rapporto sui AWS costi e sull'utilizzo (CUR) fornisce i dati più dettagliati su costi e utilizzo e consente la creazione di dashboard di ottimizzazione personalizzate, consentendo il filtraggio e il raggruppamento per account, servizi, categorie di costi, tag di allocazione dei costi e molte altre dimensioni. Tra le soluzioni basate su CUR sviluppate da AWS che possono essere utilizzate come uno di questi strumenti, consulta [Cloud Intelligence Dashboards](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) sul sito Web Well-Architected AWS Labs. 

# Tag per operazioni e supporto
<a name="tags-for-operations-and-support"></a>

 Un AWS ambiente avrà più account, risorse e carichi di lavoro con requisiti operativi diversi. I tag possono essere utilizzati per fornire contesto e indicazioni a supporto dei team operativi per migliorare la gestione dei servizi. I tag possono essere utilizzati anche per garantire la trasparenza della governance operativa delle risorse gestite. 

 Alcuni dei principali fattori che determinano una definizione coerente dei tag operativi sono: 
+  **Per filtrare le risorse durante le attività di infrastruttura automatizzata.** Ad esempio, durante la distribuzione, l'aggiornamento o l'eliminazione di risorse. Un altro è il ridimensionamento delle risorse per l'ottimizzazione dei costi e la riduzione dell'utilizzo fuori orario. Vedi la soluzione [AWS Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler/) per un esempio funzionante. 
+  **Identificazione di risorse isolate o obsolete.** Le risorse che hanno superato la durata di vita definita o che sono state segnalate per l'isolamento da meccanismi interni devono essere etichettate in modo appropriato in modo da assistere il personale di supporto nelle indagini. Le risorse obsolete devono essere etichettate prima dell'isolamento, dell'archiviazione e della cancellazione. 
+  **Requisiti di supporto per un gruppo di risorse.** Le risorse hanno spesso requisiti di supporto diversi, ad esempio questi requisiti possono essere negoziati tra i team o impostati come parte della criticità di un'applicazione. Ulteriori indicazioni sui modelli operativi sono disponibili nell'[Operational Excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html) Pillar. 
+  **Migliora il processo di gestione degli incidenti.** Etichettando le risorse con tag che offrono una maggiore trasparenza nel processo di gestione degli incidenti, i team di supporto e gli ingegneri, nonché i team di Major Incident Management (MIM), possono gestire gli eventi in modo più efficace. 
+  **Backup.** I tag possono essere utilizzati anche per identificare la frequenza di backup delle risorse e la destinazione delle copie di backup o il luogo in cui ripristinare i backup. [Linee guida prescrittive per gli approcci di Backup e ripristino](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/welcome.html) su. AWS
+  **Applicazione di patch.** L'applicazione di patch alle istanze mutabili in esecuzione AWS è fondamentale sia per la strategia generale di patching che per la correzione delle vulnerabilità zero-day. [Una guida più approfondita sulla più ampia strategia di patching è disponibile nella guida prescrittiva.](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html) [La correzione delle vulnerabilità zero-day viene discussa in questo blog.](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/) 
+  **Osservabilità operativa.** La traduzione di una strategia KPI operativa in tag di risorse aiuterà i team operativi a monitorare meglio se gli obiettivi vengono raggiunti per migliorare i requisiti aziendali. Lo sviluppo di una strategia KPI è un argomento a parte, ma tende a concentrarsi su un'azienda che opera in uno stato stazionario o su cui misurare l'impatto e i risultati del cambiamento. I [KPI Dashboards](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/cost-usage-report-dashboards/dashboards/2c_kpi_dashboard/) (AWS Well-Architected labs) e l'Operations KPI Workshop (un [servizio proattivo di Enterprise AWS Support](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)) riguardano entrambi le prestazioni di misurazione in uno stato stazionario. L'articolo del blog di strategia AWS aziendale [Measuring the Success of Your Transformation esplora la misurazione dei KPI per un programma di trasformazione](https://aws.amazon.com/blogs/enterprise-strategy/measuring-the-success-of-your-transformation/), come la modernizzazione dell'IT o la migrazione dall'ambiente locale a. AWS

# Attività di infrastruttura automatizzate
<a name="automated-infrastructure-activities"></a>

 I tag possono essere utilizzati in un'ampia gamma di attività di automazione per la gestione dell'infrastruttura. L'uso di [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/index.html), ad esempio, ti consentirà di gestire automazioni e runbook sulle risorse specificate dalla coppia chiave-valore definita che crei. Per i nodi gestiti, è possibile definire un set di tag per tracciare o indirizzare i nodi in base al sistema operativo e all'ambiente. È quindi possibile eseguire uno script di aggiornamento per tutti i nodi di un gruppo o esaminare lo stato di tali nodi. [Le risorse di Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/taggable-resources.html) possono anche essere etichettate per affinare e tracciare ulteriormente le attività automatizzate. 

 L'automazione del ciclo di vita iniziale e finale delle risorse ambientali può fornire una significativa riduzione dei costi a qualsiasi organizzazione. [Instance Scheduler on AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler/) è un esempio di soluzione in grado di avviare e arrestare istanze Amazon EC2 e Amazon RDS quando non sono necessarie. Ad esempio, gli ambienti di sviluppo che utilizzano istanze Amazon EC2 o Amazon RDS che non devono essere eseguite nei fine settimana non sfruttano il potenziale di risparmio sui costi offerto dalla chiusura di tali istanze. Analizzando le esigenze dei team e dei loro ambienti e etichettando correttamente queste risorse per automatizzarne la gestione, puoi utilizzare il budget in modo efficace. 

 *Un esempio di tag di pianificazione utilizzato dallo scheduler di istanze su un'istanza Amazon EC2:* 

```
{
    "Tags": [
        {
            "Key": "Schedule",
            "ResourceId": "i-1234567890abcdef8",
            "ResourceType": "instance",
            "Value": "mon-9am-fri-5pm"
        }
    ]
}
```

# Ciclo di vita del carico di lavoro
<a name="workload-lifecycle"></a>

**Verifica l'accuratezza dei dati operativi di supporto.** Assicurati che vengano effettuate revisioni periodiche dei tag associati al ciclo di vita del carico di lavoro e che le parti interessate siano coinvolte in tali revisioni. 

 *Tabella 7 — Rivedi i tag operativi come parte del ciclo di vita del carico di lavoro* 


|  Caso d'uso  |  Tag Key  |  Rationale  |  Valori di esempio  | 
| --- | --- | --- | --- | 
|  Proprietario dell'account  | example-inc:account-owner:owner  |  Il proprietario dell'account e delle relative risorse.  | ops-center, dev-ops, app-team  | 
|  Recensione del proprietario dell'account  | example-inc:account-owner:review  |  Verifica che i dati relativi alla proprietà dell'account siano aggiornati e corretti.  | <review date in the correct format defined in your tagging library>  | 
|  Titolare dei dati  | example-inc:data-owner:owner  |  Il proprietario dei dati che risiedono negli account.  | bi-team, logistics, security  | 
|  Recensione del proprietario dei dati  | example-inc:data-owner:review  |  Verifica dell'aggiornamento e della correttezza dei dettagli sulla proprietà dei dati.  | <review date in the correct format defined in your tagging library>  | 

## Assegnazione di tag agli account sospesi prima della migrazione all'unità organizzativa sospesa
<a name="assigning-tags-to-suspending-accounts"></a>

 Prima di sospendere un account e passare all'unità organizzativa sospesa, come descritto nel white paper [Organization Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html), è necessario aggiungere dei tag all'account per facilitare il tracciamento interno e il controllo del ciclo di vita di un account. Ad esempio, un URL relativo o un riferimento al ticket sul sistema di ticketing ITSM di un'organizzazione, che mostra l'audit trail di un'applicazione sospesa. 

 *Tabella 8 - Aggiungi tag operativi quando il ciclo di vita del carico di lavoro entra in una nuova fase* 


|  Caso d'uso  |  Tag Key  |  Rationale  |  Valori di esempio  | 
| --- | --- | --- | --- | 
|  Proprietario dell'account  | example-inc:account-owner:owner  |  Il proprietario dell'account e delle relative risorse.  | ops-center, dev-ops, app-team  | 
|  Proprietario dei dati  | example-inc:data-owner:owner  |  Il proprietario dei dati che risiedono negli account.  | bi-team, logistics, security  | 
|  Data di sospensione  | example-inc:suspension:date  |  La data in cui l'account è stato sospeso  |  <suspended date in the correct format defined in your tagging library>  | 
|  Approvazione per la sospensione  | example-inc:suspension:approval  |  Il link all'approvazione della sospensione dell'account  | workload/deprecation  | 

# Gestione degli incidenti
<a name="incident-management"></a>

 I tag possono svolgere un ruolo fondamentale in tutte le fasi della gestione degli incidenti, a partire dalla registrazione degli incidenti, dall'assegnazione delle priorità, all'indagine, alla comunicazione, alla risoluzione fino alla chiusura. 

 I tag possono indicare dove registrare un incidente, il team o i team che devono essere informati dell'incidente e la priorità di escalation definita. È importante ricordare che i tag non sono crittografati, quindi considera quali informazioni memorizzi in essi. Inoltre, nelle organizzazioni, nei team e nelle linee di reporting, le responsabilità cambiano, quindi valuta la possibilità di archiviare un collegamento a un portale sicuro in cui queste informazioni possano essere gestite in modo più efficace. Non è necessario che questi tag siano esclusivi. Ad esempio, l'ID dell'applicazione potrebbe essere utilizzato per cercare i percorsi di escalation in un portale di gestione dei servizi IT. Assicurati che nelle definizioni operative sia chiaro che questo tag viene utilizzato per diversi scopi. 

 I tag dei requisiti operativi possono anche essere dettagliati, per aiutare i responsabili degli incidenti e il personale operativo a perfezionare ulteriormente i propri obiettivi in risposta a un incidente o evento. 

 I link relativi (all'URL della Knowledge System Base) per [runbook](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.runbook.en.html) e [playbook](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.playbook.en.html) possono essere inclusi come tag per aiutare i team che hanno risposto a identificare il processo, la procedura e la documentazione corrispondenti. 

 *Tabella 9 - Utilizzate i tag operativi per informare la gestione degli incidenti* 


|  Caso d'uso  |  Tag Key  |  Rationale  |  Valori di esempio  | 
| --- | --- | --- | --- | 
|  Gestione degli incidenti  | example-inc:incident-management:escalationlog  |  Il sistema utilizzato dal team di supporto per registrare gli incidenti  | jira, servicenow, zendesk  | 
|  Gestione degli incidenti  | example-inc:incident-management:escalationpath  |  Percorso di escalation  | ops-center, dev-ops, app-team  | 
|  Allocazione dei costi e gestione degli incidenti  | example-inc:cost-allocation:CostCenter |  Monitora i costi per centro di costo. Questo è un esempio di tag a doppio uso in cui il centro di costo viene utilizzato come codice applicativo per la registrazione degli incidenti  | 123-\$1  | 
|  Pianificazione del backup  | example-inc:backup:schedule  |  Pianificazione del backup della risorsa  | Daily  | 
|  Playbook/ Gestione degli incidenti  | example-inc:incident-management:playbook  |  Playbook documentato  | webapp/incident/playbook  | 

# Applicazione delle patch
<a name="patching"></a>

 Organizations può automatizzare la propria strategia di patching per ambienti di elaborazione mutabili e mantenere le istanze mutabili in linea con la linea di base delle patch definita per quell'ambiente applicativo utilizzando Systems Manager Patch Manager e. AWS AWS Lambda****Una strategia di etichettatura per le istanze mutabili all'interno di questi ambienti può essere gestita assegnando tali istanze a Patch Groups e Maintenance Windows.**** Vedi i seguenti esempi per una divisione Dev → Test → Prod. AWS sono disponibili linee guida prescrittive per la [gestione delle patch delle istanze mutabili](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html). 

 *Tabella 10 - I tag operativi possono essere specifici dell'ambiente* 


|  Sviluppo  |  Gestione temporanea  |  Produzione  | 
| --- | --- | --- | 
|  <pre>{<br />"Tags": [<br />{<br />"Key": "Maintenance Window",<br />"ResourceId": "i-012345678ab9ab111",<br />"ResourceType": "instance",<br />"Value": "cron(30 23 ? * TUE#1 *)"<br />},<br />{<br />"Key": "Name",<br />"ResourceId": "i-012345678ab9ab222",<br />"ResourceType": "instance",<br />"Value": "WEBAPP"<br />},<br />{<br />"Key": "Patch Group",<br />"ResourceId": "i-012345678ab9ab333",<br />"ResourceType": "instance",<br />"Value": "WEBAPP-DEV-AL2"<br />}<br />]<br />}<br /></pre>  |  <pre>{<br />"Tags": [<br />{<br />"Key": "Maintenance Window",<br />"ResourceId": "i-012345678ab9ab444",<br />"ResourceType": "instance",<br />"Value": "cron(30 23 ? * TUE#2 *)"<br />},<br />{<br />"Key": "Name",<br />"ResourceId": "i-012345678ab9ab555",<br />"ResourceType": "instance",<br />"Value": "WEBAPP"<br />},<br />{<br />"Key": "Patch Group",<br />"ResourceId": "i-012345678ab9ab666",<br />"ResourceType": "instance",<br />"Value": "WEBAPP-TEST-AL2"<br />}<br />]<br />}<br /></pre>  |  <pre>{<br />"Tags": [<br />{<br />"Key": "Maintenance Window",<br />"ResourceId": "i-012345678ab9ab777",<br />"ResourceType": "instance",<br />"Value": "cron(30 23 ? * TUE#3 *)"<br />},<br />{<br />"Key": "Name",<br />"ResourceId": "i-012345678ab9ab888",<br />"ResourceType": "instance",<br />"Value": "WEBAPP"<br />},<br />{<br />"Key": "Patch Group",<br />"ResourceId": "i-012345678ab9ab999",<br />"ResourceType": "instance",<br />"Value": "WEBAPP-PROD-AL2"<br />}<br />]<br />}<br /></pre>  | 

 Le vulnerabilità zero-day possono essere gestite anche definendo tag a complemento della strategia di patching. Per una guida dettagliata, consulta [Evita le vulnerabilità zero-day applicando le patch di sicurezza lo stesso giorno utilizzando Systems AWS Manager](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/). 

# Osservabilità operativa
<a name="operational-observability"></a>

 L'osservabilità è necessaria per ottenere informazioni utili sulle prestazioni degli ambienti e aiutarvi a rilevare e analizzare i problemi. Ha anche uno scopo secondario che consente di definire e misurare gli indicatori chiave di prestazione () e gli obiettivi dei livelli di servizio (KPIs), come l'SLOsoperatività. Per la maggior parte delle organizzazioni, le operazioni più importanti KPIs sono il tempo medio di rilevamento (MTTD) e il tempo medio di ripristino (MTTR) a seguito di un incidente. 

In termini di osservabilità, il contesto è importante, poiché i dati vengono raccolti e quindi vengono raccolti i tag associati. Indipendentemente dal servizio, dall'applicazione o dal livello di applicazione su cui ti stai concentrando, puoi filtrare e analizzare per quel set di dati specifico. I tag possono essere utilizzati per automatizzare l'onboarding di CloudWatch Alarms in modo che i team giusti possano essere avvisati quando vengono superate determinate soglie metriche. Ad esempio, una chiave di tag `example-inc:ops:alarm-tag` e il relativo valore potrebbero indicare la creazione dell'allarme. CloudWatch Una soluzione che lo dimostra è descritta in [Utilizzare i tag per creare e mantenere CloudWatch allarmi Amazon per le istanze Amazon EC2](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/).

 La configurazione di troppi allarmi può facilmente creare una tempesta di avvisi, quando un gran numero di allarmi o notifiche sovraccarica rapidamente gli operatori e ne riduce l'efficacia complessiva, mentre gli operatori sono impegnati a classificare manualmente e a dare priorità ai singoli allarmi. È possibile fornire un contesto aggiuntivo per gli allarmi sotto forma di tag, il che significa che è possibile definire regole all'interno di Amazon EventBridge per garantire che venga prestata attenzione al problema originario anziché alle dipendenze a valle. 

 Il ruolo delle operazioni parallele DevOps viene spesso trascurato, ma per molte organizzazioni i team operativi centrali forniscono ancora una prima risposta fondamentale al di fuori del normale orario lavorativo. (Maggiori dettagli su questo modello sono disponibili nel [white paper Operational Excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html).) [A differenza del DevOps team responsabile del carico di lavoro, in genere non hanno la stessa conoscenza approfondita, quindi il contesto fornito dai tag all'interno di dashboard e avvisi può indirizzarli al runbook corretto per il problema o avviare un runbook automatizzato (consulta il post sul blog Automating Amazon Alarms with). CloudWatch AWS Systems Manager](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/) 

# Tag per la sicurezza dei dati, la gestione del rischio e il controllo degli accessi
<a name="tags-for-data-security-risk-management-and-access-control"></a>

 Organizations ha esigenze e obblighi diversi da soddisfare per quanto riguarda la gestione appropriata dell'archiviazione e dell'elaborazione dei dati. La classificazione dei dati è un importante precursore per diversi casi d'uso, come il controllo degli accessi, la conservazione dei dati, l'analisi dei dati e la conformità. 

# Sicurezza dei dati e gestione dei rischi
<a name="data-security-and-risk-management"></a>

All'interno di un AWS ambiente, probabilmente avrai account con requisiti di conformità e sicurezza diversi. Ad esempio, potreste avere una sandbox per sviluppatori e un account che ospita l'ambiente di produzione per un carico di lavoro altamente regolamentato, come l'elaborazione dei pagamenti. Isolandoli in diversi account, è possibile [applicare controlli di sicurezza distinti](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#apply-distinct-security-controls-by-environment), [limitare l'accesso ai dati sensibili](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data) e ridurre l'ambito di controllo per i carichi di lavoro regolamentati. 

 L'adozione di un unico standard per tutti i carichi di lavoro può comportare delle sfide. Sebbene molti controlli si applichino allo stesso modo in un ambiente, alcuni controlli sono eccessivi o irrilevanti per gli account che non devono soddisfare specifici quadri normativi e per gli account in cui non saranno mai presenti dati personali identificabili (ad esempio, una sandbox per sviluppatori o account di sviluppo del carico di lavoro). Ciò porta in genere a risultati di sicurezza falsi positivi che devono essere valutati e chiusi senza alcuna azione, il che distoglie lo sforzo dai risultati da esaminare. 

 *Tabella 11 — Esempi di tag per la sicurezza dei dati e la gestione del rischio* 


|  Caso d’uso  |  Tag Key  |  Rationale  |  Valori di esempio  | 
| --- | --- | --- | --- | 
| Gestione degli incidenti  | example-inc:incident- management:escalationlog |  Il sistema utilizzato dal team di supporto per registrare gli incidenti  |  jira, servicenow, zendesk  | 
| Gestione degli incidenti  | example-inc:incident- management:escalationpath |  Percorso di escalation  | ops-center, dev-ops, app-team  | 
| Classificazione dei dati  | example-inc:data:classification |  Classificate i dati per la conformità e la governance  | Public, Private, Confidential, Restricted  | 
| Conformità  | example-inc:compliance:framework |  Identifica il framework di conformità a cui è soggetto il carico di lavoro  | PCI-DSS, HIPAA  | 

 La gestione manuale dei diversi controlli in un AWS ambiente richiede molto tempo ed è soggetta a errori. Il passaggio successivo consiste nell'automatizzare l'implementazione dei controlli di sicurezza appropriati e configurare l'ispezione delle risorse in base alla classificazione di tale account. Applicando tag agli account e alle risorse al loro interno, l'implementazione dei controlli può essere automatizzata e configurata in modo appropriato per il carico di lavoro. 

**Esempio: **

 Un carico di lavoro include un bucket Amazon S3 con il `example-inc:data:classification` tag con il valore. `Private` L'automazione degli strumenti di sicurezza implementa una AWS Config regola `s3-bucket-public-read-prohibited` che controlla le impostazioni Block Public Access del bucket Amazon S3, la policy del bucket e l'elenco di controllo dell'accesso al bucket (ACL), confermando che la configurazione del bucket è appropriata per la classificazione dei dati. Per garantire che il contenuto del bucket sia coerente con la classificazione, [Amazon Macie può essere configurato per verificare la presenza di informazioni di identificazione personale](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/) (PII). Il blog [Using Amazon Macie to Validate S3 Bucket Data Classification](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/) esplora questo modello in modo più approfondito. 

 Alcuni ambienti normativi, come quello assicurativo e sanitario, potrebbero essere soggetti a politiche obbligatorie di conservazione dei dati. La conservazione dei dati tramite tag, combinata con le policy del ciclo di vita di Amazon S3, può essere un modo semplice ed efficace per definire le transizioni degli oggetti verso un livello di storage diverso. Le regole del ciclo di vita di Amazon S3 possono essere utilizzate anche per far scadere gli oggetti per l'eliminazione dei dati dopo la scadenza del periodo di conservazione obbligatorio. Per una guida [approfondita su questo processo, consulta Semplifica il ciclo di vita dei dati utilizzando i tag degli oggetti con Amazon S3](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/) Lifecycle. 

 Inoltre, durante la valutazione o la risoluzione di problemi di sicurezza, i tag possono fornire all'investigatore un contesto importante che aiuta a qualificare il rischio e a coinvolgere i team appropriati per indagare o mitigare i risultati. 

# Tag per la gestione delle identità e il controllo degli accessi
<a name="tags-for-identity-management-and-access-control"></a>

 Quando si gestisce il controllo degli accessi in un AWS ambiente con AWS IAM Identity Center, i tag possono abilitare diversi modelli di scalabilità. È possibile applicare diversi modelli di delega, alcuni basati sull'etichettatura. Li affronteremo individualmente e forniremo collegamenti per ulteriori letture su ciascuno di essi. 

# ABAC per risorse individuali
<a name="abac-for-individual-resources"></a>

 Gli utenti e i ruoli IAM Identity Center supportano il controllo degli accessi basato sugli attributi (ABAC), che consente di definire l'accesso alle operazioni e alle risorse in base ai tag. ABAC aiuta a ridurre la necessità di aggiornare le politiche di autorizzazione e ti aiuta a basare l'accesso sugli attributi dei dipendenti presenti nell'elenco aziendale. Se state già utilizzando una strategia multi-account, ABAC può essere utilizzato in aggiunta al controllo degli accessi basato sui ruoli (RBAC) per fornire a più team che operano sullo stesso account un accesso granulare a risorse diverse. Ad esempio, gli utenti di IAM Identity Center o i ruoli IAM possono includere condizioni per limitare l'accesso a istanze Amazon EC2 specifiche che altrimenti dovrebbero essere elencate esplicitamente in ciascuna policy per potervi accedere. 

 Poiché un modello di autorizzazione ABAC dipende dai tag per l'accesso alle operazioni e alle risorse, è importante fornire barriere per prevenire accessi involontari. SCPs può essere utilizzato per proteggere i tag all'interno dell'organizzazione, consentendone la modifica solo in determinate condizioni. I blog [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/) e [Permissions boundaries for IAM Entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) forniscono informazioni su come implementarla. 

 Laddove le istanze Amazon EC2 di lunga durata vengono utilizzate per supportare pratiche operative più tradizionali, questo approccio può essere utilizzato, il [blog Configure IAM Identity Center ABAC for Amazon EC2 instances and Systems Manager Session Manager](https://aws.amazon.com/blogs/security/configure-aws-sso-abac-for-ec2-instances-and-systems-manager-session-manager/) tratta in modo più dettagliato questa forma di controllo degli accessi basato sugli attributi. Come accennato in precedenza, non tutti i tipi di risorse supportano l'etichettatura e, tra quelli che lo fanno, non tutti supportano l'applicazione tramite le politiche dei tag, quindi è una buona idea valutarlo prima di iniziare a implementare questa strategia su un Account AWS.

Per maggiori informazioni sui servizi che supportano ABAC, consulta la sezione [AWS Servizi che funzionano con](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) IAM.