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à. # Sviluppa la tua strategia di tagging Come per molte pratiche operative, l'implementazione di una strategia di tagging è *un processo di iterazione* e miglioramento. Inizia in piccolo con la priorità immediata e amplia lo schema di tagging in base alle tue esigenze. ![\[Diagramma che mostra una rappresentazione grafica del ciclo di iterazione e miglioramento della strategia di tagging\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/tagging-best-practices/images/tagging-strategy-cycle.png) In tutto questo processo, la titolarità è fondamentale per la responsabilità e il progresso. Poiché i tag possono essere utilizzati per una varietà di scopi, la strategia generale di etichettatura può essere suddivisa in aree di responsabilità all'interno di un'organizzazione. L'etichettatura consente un approccio programmatico alle attività che dipendono dalla caratterizzazione delle risorse. La gamma di parti interessate che possono trarre vantaggio dall'etichettatura dipenderà dalle dimensioni dell'organizzazione e dalle pratiche operative. Le organizzazioni più grandi possono trarre vantaggio dalla definizione chiara delle responsabilità dei team coinvolti nella creazione e nell'implementazione di una strategia di etichettatura. Alcune parti interessate possono essere responsabili dell'identificazione delle esigenze (definizione dei casi d'uso) in materia di etichettatura; altre possono essere responsabili del mantenimento, dell'implementazione e del miglioramento della strategia di etichettatura. Assegnando la proprietà, siete in una buona posizione per implementare singoli aspetti della strategia. Se del caso, questa titolarità può essere formalizzata come politica e documentata in una matrice di responsabilità (ad esempio, RACI: Responsible, Accountable, Consulted and Informed) o in un modello di responsabilità condivisa. Nelle organizzazioni più piccole, i team possono svolgere più ruoli in una strategia di etichettatura, dalla definizione dei requisiti all'implementazione e all'applicazione. # Definizione delle esigenze e dei casi d'uso Inizia a sviluppare la tua strategia interagendo con le parti interessate che hanno l'esigenza fondamentale di utilizzare i metadati. Questi team definiscono i metadati con cui le risorse devono essere etichettate per supportare le loro attività, come la reportistica, l'automazione e la classificazione dei dati. Descrivono come le risorse devono essere organizzate e a quali politiche devono essere mappate. Esempi di ruoli e funzioni che queste parti interessate possono avere nelle organizzazioni includono: + **Finance** e **Line of Business** devono comprendere il valore degli investimenti associandolo ai costi per dare priorità alle azioni da intraprendere per far fronte alle disparità. Comprendere il *rapporto tra costo e valore generato* aiuta a identificare le linee di business o le offerte di prodotti che non hanno avuto successo. Ciò porta a decisioni informate sulla continuazione del supporto, sull'adozione di un'alternativa (ad esempio, l'utilizzo di un'offerta SaaS o di un servizio gestito) o sul ritiro di un'offerta aziendale non redditizia. + La **governance** e la **conformità** devono comprendere la categorizzazione dei dati (ad esempio, pubblici, sensibili o riservati), se un carico di lavoro specifico rientra o non rientra nell'ambito di controllo rispetto a uno standard o regolamento specifici e la criticità del servizio (indipendentemente dal fatto che il servizio o l'applicazione siano critici per l'azienda) per applicare controlli e supervisione appropriati, come autorizzazioni, politiche e monitoraggio. + **Le operazioni** e **lo sviluppo** devono comprendere il ciclo di vita del carico di lavoro, le fasi di implementazione dei prodotti supportati e la gestione delle fasi di rilascio (ad esempio, sviluppo, test, divisione della produzione) e le relative priorità di supporto e i requisiti di gestione degli stakeholder. È inoltre necessario definire e comprendere compiti quali backup, patch, osservabilità e deprecazione. + **Information Security (InfoSec)** e **Security Operations (SecOps)** delineano quali controlli devono essere applicati e quali sono consigliati. InfoSec definisce normalmente l'implementazione dei controlli ed SecOps è generalmente responsabile della gestione di tali controlli. A seconda del caso d'uso, delle priorità, delle dimensioni dell'organizzazione e delle pratiche operative, potresti aver bisogno della rappresentanza di vari team all'interno dell'organizzazione, come Finance (incluso Procurement), Information Security, Cloud Enablement e Cloud Operations. È inoltre necessaria la rappresentanza dei proprietari delle applicazioni e dei processi per funzioni quali l'applicazione di patch, il backup e il ripristino, il monitoraggio, la pianificazione dei lavori e il disaster recovery. Questi rappresentanti aiutano a definire, implementare e misurare l'efficacia della strategia di tagging. Dovrebbero [https://www.youtube.com/watch?v=aFdpBqmDpzM](https://www.youtube.com/watch?v=aFdpBqmDpzM) delle parti interessate e dei relativi casi d'uso e condurre un seminario interfunzionale. Nel seminario, hanno la possibilità di condividere le loro prospettive e le loro esigenze e contribuire a definire una strategia globale. Esempi di partecipanti e del loro coinvolgimento in vari casi d'uso sono descritti più avanti in questo white paper. Le parti interessate definiscono e convalidano inoltre le chiavi per i tag obbligatori e possono consigliare l'ambito per i tag opzionali. Ad esempio, i team finanziari potrebbero dover collegare una risorsa a un centro di costo interno, a un'unità aziendale o a entrambi. Pertanto, potrebbero richiedere che determinate chiavi di tag, come `CostCenter` e`BusinessUnit`, siano rese obbligatorie. I singoli team di sviluppo potrebbero decidere di utilizzare tag aggiuntivi per scopi di automazione, ad esempio `EnvironmentName``OptIn`, o`OptOut`. Le principali parti interessate devono concordare l'approccio strategico di etichettatura e documentare le risposte alle domande relative alla conformità e alla governance, come: + Quali casi d'uso devono essere affrontati? + Chi è responsabile dell'etichettatura delle risorse (implementazione)? + Come vengono applicati i tag e quali metodi e automazione verranno utilizzati (proattivi o reattivi)? + Come vengono misurati l'efficacia e gli obiettivi dei tag? + Con che frequenza deve essere rivista la strategia di tagging? + Chi promuove i miglioramenti? Come si fa? Le funzioni aziendali, come Cloud Enablement, Cloud Business Office e Cloud Platform Engineering, possono quindi svolgere un ruolo di facilitatori nel processo di costruzione della strategia di tagging, contribuire a favorirne l'adozione e garantire la coerenza della sua applicazione misurando i progressi, rimuovendo gli ostacoli e riducendo gli sforzi duplicati. # Definizione e pubblicazione di uno schema di tagging Utilizza un approccio coerente per etichettare AWS le tue risorse, sia per i tag obbligatori che per quelli facoltativi. Uno schema di etichettatura completo ti aiuta a raggiungere questa coerenza. I seguenti esempi possono aiutarti a iniziare: + Concordate i tag key obbligatori + Definisci valori accettabili e convenzioni di denominazione dei tag (lettere maiuscole o minuscole, trattini o sottolineature, gerarchia e così via) + I valori di conferma non costituirebbero informazioni di identificazione personale (PII) + Decidi chi può definire e creare nuove chiavi di tag + Concorda su come aggiungere nuovi valori di tag obbligatori e su come gestire i tag opzionali Consulta la seguente tabella [delle categorie di tag](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html), che può essere utilizzata come base di riferimento per ciò che potresti includere nel tuo schema di etichettatura. È comunque necessario determinare la convenzione da utilizzare per la chiave del tag e quali valori sono consentiti per ciascuna di esse. Lo schema di tagging è il documento in cui lo definisci per il tuo ambiente. *Tabella 6 — Esempio di schema di tagging definitivo* | Caso d'uso | Tag Key | Rationale | Valori consentiti (elencati o prefisso/sottofisso del valore) | Utilizzato per l'allocazione dei costi | Tipi di risorsa | Scope | Richiesto | | --- | --- | --- | --- | --- | --- | --- | --- | | Allocazione dei costi | example-inc:cost-allocation:ApplicationId | Tieni traccia del costo rispetto al valore generato da ciascuna linea di business | DataLakeX, RetailSiteX | Y | Tutti | Tutti | Obbligatorio | | Allocazione dei costi | example-inc:cost-allocation:BusinessUnitId | Monitora i costi per unità aziendale | Architecture, DevOps, Finance | Y | Tutti | Tutti | Obbligatorio | | Allocazione dei costi | example-inc:cost-allocation:CostCenter | Monitora i costi per centro di costo | 123-\$1 | Y | Tutti | Tutti | Obbligatorio | | Allocazione dei costi | example-inc:cost-allocation:Owner | Quale titolare del budget è responsabile di questo carico di lavoro | Marketing, RetailSupport | Y | Tutti | Tutti | Obbligatorio | | Controllo degli accessi | example-inc:access-control:LayerId | Identifica SubComponent //Layer per concedere l'accesso alle risorse in base al ruolo | DB\$1Layer, Web\$1Layer, App\$1Layer | N | Tutti | Tutti | Facoltativo | | Automazione | example-inc:automation:EnvironmentId | Implementa la pianificazione degli ambienti di test e sviluppo, nota anche come fase del ciclo di vita dello sviluppo del software (SDLC) | Prod, Dev, Test, Sandbox | N | EC2, RDS, EBS | Tutti | Obbligatorio | | DevOps | example-inc:operations:Owner | Che team/squad è responsabile della creazione e del mantenimento della risorsa | Squad01 | N | Tutti | Tutti | Obbligatorio | | Ripristino di emergenza | example-inc:disaster-recovery:rpo | Definisci il Recovery Point Objective (RPO) per una risorsa | 6h, 24h | N | S3, EBS | Prod | Obbligatorio | | Classificazione dei dati | example-inc:data:classification | Classificazione dei dati per la conformità e la governance | Public, Private, Confidential, Restricted | N | S3, EBS | Tutti | Obbligatorio | | Conformità | example-inc:compliance:framework | Identifica il framework di conformità a cui è soggetto il carico di lavoro | PCI-DSS, HIPAA | N | Tutti | Prod | Obbligatorio | Dopo aver definito lo schema di tagging, gestisci lo schema in un repository a controllo di versione accessibile a tutte le parti interessate per facilitare la consultazione e garantire aggiornamenti tracciabili. Questo approccio migliora l'efficienza e consente l'agilità. # AWS Organizations — Politiche relative ai tag Le politiche AWS Organizations consentono di applicare ulteriori tipi di governance Account AWS all'interno dell'organizzazione. Una [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) consente di esprimere lo schema di tagging in formato JSON in modo che la piattaforma possa segnalare e, facoltativamente, applicare lo schema all'interno del proprio ambiente. AWS La politica dei tag definisce i valori accettabili per una chiave di tag su tipi di risorse specifici. Questa politica può assumere la forma di un elenco di valori o di un prefisso seguito da un carattere jolly ()`*`. L'approccio con prefisso semplice è meno rigoroso di un elenco discreto di valori, ma richiede meno manutenzione. Gli esempi seguenti mostrano come definire una politica di etichettatura per convalidare i valori accettabili per una determinata chiave. Partendo dalla definizione tabulare intuitiva dello schema, è possibile trascrivere queste informazioni in una o più politiche di tag. È possibile utilizzare politiche separate per supportare la proprietà delegata oppure alcune politiche potrebbero essere applicate solo in scenari specifici. ## ExampleInc- .json CostAllocation Di seguito è riportato un esempio di politica dei tag che riporta i tag di allocazione dei costi: ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] } } } } ``` ## ExampleInc- .json DisasterRecovery Di seguito è riportato un esempio di politica dei tag che riporta i tag di Disaster Recovery: ``` { "tags": { "example-inc:disaster-recovery:rpo": { "tag_key": { "@@assign": "example-inc:disaster-recovery:rpo" }, "tag_value": { "@@assign": [ "6h", "24h" ] } } } } ``` In questo esempio, la politica dei `ExampleInc-CostAllocation` tag è allegata all'`Workloads`unità organizzativa e pertanto si applica a tutti gli account sia dell'unità organizzativa che dell'`Prod`account `Test` secondario OUs. Analogamente, la politica sui `ExampleInc-DisasterRecovery` tag è allegata all'`Prod`unità organizzativa e pertanto si applica solo agli account al di sotto di questa unità organizzativa. Il white paper [Organizing Your Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) analizza le strutture organizzative consigliate in modo più dettagliato. ![\[Diagramma che mostra l'associazione delle politiche di tag a una struttura di unità organizzative e la politica efficace\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/tagging-best-practices/images/adding-tagging-to-policies-in-ou-structure.png) Osservando l'`marketing-prod`account nel diagramma, entrambe le politiche relative ai tag si applicano a questo account, quindi abbiamo il concetto di *politica efficace*, che è la convoluzione delle politiche di un determinato tipo che si applicano a un account. Se gestisci le tue risorse principalmente manualmente, puoi rivedere la politica in vigore visitando le politiche [Resource Groups & Tag Editor:Tag nella console](https://console.aws.amazon.com/resource-groups/tag-policies). Se utilizzi l'infrastruttura come codice (IaC) o lo scripting per gestire le risorse, puoi utilizzare la chiamata API. [https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html) # Implementazione e applicazione dei tag In questa sezione, ti presenteremo gli strumenti disponibili per le seguenti strategie di gestione delle risorse: manuale, infrastructure-as code (IaC) e integration/continuous distribuzione continua (CI/CD). La dimensione chiave di questi approcci è una velocità di implementazione sempre più frequente. ## Risorse gestite manualmente Si tratta in genere di carichi di lavoro che rientrano nelle [fasi di base o di migrazione dell'adozione](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html). Spesso si tratta di semplici carichi di lavoro in gran parte statici creati utilizzando procedure scritte tradizionali o di carichi di lavoro migrati così *come* sono utilizzando strumenti come quelli AWS Application Migration Service provenienti da un ambiente locale. Gli strumenti di migrazione, come Migration Hub e Application Migration Service, possono applicare tag come parte del processo di migrazione. Tuttavia, se i tag non sono stati applicati durante la migrazione originale o lo schema di etichettatura è cambiato da allora, il [Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) (una funzionalità di Console di gestione AWS) consente di cercare risorse utilizzando una varietà di criteri di ricerca e di aggiungere, modificare o eliminare tag in blocco. I criteri di ricerca possono includere risorse con o senza la presenza di un particolare tag o valore. L'API AWS Resource Tagging consente di eseguire queste funzioni a livello di codice. Man mano che questi carichi di lavoro vengono modernizzati, vengono introdotti tipi di risorse come i gruppi di Auto Scaling. Questi tipi di risorse consentono una maggiore elasticità e una migliore resilienza. Il gruppo auto scaling gestisce le istanze Amazon EC2 per tuo conto, tuttavia potresti comunque desiderare che le istanze EC2 vengano etichettate in modo coerente con le risorse create manualmente. Un [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html) fornisce i mezzi per specificare i tag che Auto Scaling deve applicare alle istanze che crea. Quando le risorse di un carico di lavoro vengono gestite manualmente, può essere utile automatizzare l'etichettatura delle risorse. Sono disponibili varie soluzioni. Un approccio è quello di utilizzare Regole di AWS Config, che può verificare `required_tags` e quindi avviare una funzione Lambda per applicarli. Regole di AWS Config è descritto più dettagliatamente più avanti in questo white paper. ## risorse gestite dall'infrastruttura come codice (IaC) AWS CloudFormation fornisce un linguaggio comune per il provisioning di tutte le risorse dell'infrastruttura AWS nell'ambiente. CloudFormation i modelli sono file JSON o YAML che creano AWS risorse in modo automatizzato. Quando si creano AWS risorse utilizzando CloudFormation modelli, è possibile utilizzare la proprietà CloudFormation Resource Tags per applicare tag ai tipi di risorse supportati al momento della creazione. La gestione dei tag e delle risorse con IAc aiuta a garantire la coerenza. Quando le risorse vengono create da AWS CloudFormation, il servizio applica automaticamente un set di tag AWS definiti alle risorse create dal AWS CloudFormation modello. Questi sono: ``` aws:cloudformation:stack-name aws:cloudformation:stack-id aws:cloudformation:logical-id ``` È possibile definire facilmente un gruppo di risorse in base allo AWS CloudFormation stack. Questi tag AWS definiti vengono ereditati dalle risorse create dallo stack. Tuttavia, per le istanze Amazon EC2 all'interno di un gruppo Auto Scaling, è [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)necessario impostarlo nella definizione del gruppo Auto Scaling nel modello. AWS CloudFormation In alternativa, se utilizzi un [modello di avvio EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) con il gruppo Auto Scaling, puoi definire i tag nella sua definizione. Si consiglia di utilizzare i [modelli di avvio EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) con gruppi di Auto Scaling o con AWS un servizio container. Questi servizi possono contribuire a garantire l'etichettatura coerente delle istanze Amazon EC2 e supportano anche l'Auto [Scaling su più tipi di istanze e opzioni di acquisto, che possono migliorare la resilienza e](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/) ottimizzare i costi di elaborazione. AWS CloudFormation Gli [hook](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/) forniscono agli sviluppatori un mezzo per mantenere gli aspetti chiave delle loro applicazioni coerenti con gli standard dell'organizzazione. Gli hook possono essere configurati per fornire un *avviso* o *impedire l'*implementazione. Questa funzionalità è ideale per verificare gli elementi chiave di configurazione nei modelli, ad esempio se un gruppo di Auto Scaling è configurato per applicare tag definiti dal cliente a tutte le istanze Amazon EC2 che avvia o per garantire che tutti i bucket Amazon S3 siano creati con le impostazioni di crittografia richieste. In entrambi i casi, la valutazione di questa conformità viene spostata alle fasi iniziali del processo di distribuzione, con accorgimenti preliminari alla distribuzione. AWS CloudFormation AWS CloudFormation fornisce la capacità di rilevare quando una risorsa (vedere [Risorse che supportano il rilevamento delle deviazioni](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html)) fornita da un modello è stata modificata e le risorse non corrispondono più alle configurazioni del modello previste. *Questo fenomeno è noto come deriva.* Se usi l'automazione per applicare tag alle risorse gestite tramite IAc, le stai modificando, introducendo drift. Quando si utilizza IaC, attualmente si consiglia di gestire eventuali requisiti di tagging come parte dei modelli IaC, implementare AWS CloudFormation hook e pubblicare set di regole AWS CloudFormation Guard che possono essere utilizzati dall'automazione. ## Risorse gestite dalla pipeline CI/CD Con l'aumentare della maturità del carico di lavoro, è probabile che vengano adottate tecniche come l'integrazione continua e l'implementazione continua (CI/CD). Queste tecniche aiutano a ridurre il rischio di implementazione semplificando l'implementazione di piccole modifiche più frequentemente con una maggiore automazione dei test. Una strategia di osservabilità che rileva comportamenti imprevisti introdotti da una distribuzione può ripristinare automaticamente l'implementazione con un impatto minimo sull'utente. Quando si arriva alla fase di implementazione decine di volte al giorno, l'applicazione retroattiva dei tag semplicemente non è più pratica. Tutto deve essere espresso sotto forma di codice o configurazione, deve essere controllato dalla versione e, ove possibile, testato e valutato prima dell'implementazione in produzione. Nel [modello combinato di sviluppo e operazioni (DevOps)](https://aws.amazon.com/devops/what-is-devops/), molte pratiche riguardano considerazioni operative sotto forma di codice e le convalidano nelle prime fasi del ciclo di vita dell'implementazione. Idealmente, dovresti eseguire questi controlli il più presto possibile (come illustrato con gli AWS CloudFormation hook), in modo da avere la certezza che il AWS CloudFormation modello soddisfi le tue politiche prima che lascino il computer dello sviluppatore. [AWS CloudFormation Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/) offre i mezzi per scrivere regole di conformità preventive per tutto ciò che è possibile definire. CloudFormation Il modello è convalidato in base alle regole dell'ambiente di sviluppo. Chiaramente, questa funzionalità ha una vasta gamma di applicazioni, ma in questo white paper esamineremo solo alcuni esempi per garantire che venga sempre utilizzata [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html). Di seguito è riportato un esempio di regola CloudFormation Guard: ``` let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ] rule tags_asg_automation_EnvironmentId when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:automation:EnvironmentId' ] %required_tags[*] { PropagateAtLaunch == 'true' Value IN ['Prod', 'Dev', 'Test', 'Sandbox'] <> } } rule tags_asg_costAllocation_CostCenter when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:cost-allocation:CostCenter' ] %required_tags[*] { PropagateAtLaunch == 'true' Value == /^123-/ <> } } ``` Nell'esempio di codice, filtriamo il modello per tutte le risorse del tipo `AutoScalingGroup` e quindi abbiamo due regole: + **`tags_asg_automation_EnvironmentId`**- Verifica che un tag con questa chiave esista, che abbia un valore all'interno dell'elenco di valori consentito e che `PropagateAtLaunch` sia impostato su `true` + **`tags_asg_costAllocation_CostCenter`**- Verifica che esista un tag con questa chiave, che abbia un valore che inizia con il valore del prefisso definito e che `PropagateAtLaunch` sia impostato su `true` ## Applicazione Come descritto in precedenza, **Resource Groups & Tag Editor** fornisce i mezzi per identificare dove le risorse non soddisfano i requisiti di tagging definiti nelle politiche OUs di tag applicate all'organizzazione. L'accesso allo strumento console **Resource Groups & Tag Editor** dall'interno di un account membro dell'organizzazione mostra le politiche che si applicano a quell'account e la risorsa all'interno dell'account che non soddisfa i requisiti della politica sui tag. Se si accede dall'account di gestione (e se **Tag policies** ha *Access abilitato* nei servizi sotto AWS Organizations), è possibile visualizzare la [conformità alle politiche sui tag per tutti gli account collegati dell'organizzazione](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). All'interno della stessa Tag Policy, puoi abilitare l'applicazione per tipi di risorse specifici. Nel seguente esempio di policy, abbiamo aggiunto l'applicazione in modo tale che tutte le risorse, di qualsiasi tipo`ec2:instance`, `ec2:volume` debbano essere conformi alla policy. Esistono alcune limitazioni note, ad esempio la presenza di un tag su una risorsa affinché possa essere valutata dalla politica dei tag. Per un elenco, consulta [Risorse che supportano l'applicazione delle politiche sui tag](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html). ### ExampleInc-Allocazione dei costi. json Di seguito è riportato un esempio di politica dei tag in cui i report applicano i tag di and/or allocazione dei costi: ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } } } } ``` **AWS Config (`required_tag`)** AWS Config è un servizio che consente di valutare, controllare e valutare le configurazioni delle AWS risorse (vedi [Tipi di risorse supportati da](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)). AWS Config Nel caso del tagging, possiamo usarlo per identificare le risorse prive di tag con chiavi specifiche, utilizzando la `required_tags` regola (fai riferimento ai [tipi di risorse supportati da](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html) required\$1tags). Dall'esempio precedente, potremmo verificare l'esistenza della chiave su tutte le istanze Amazon EC2. Nei casi in cui la chiave non esiste, l'istanza verrà registrata come non conforme. Questo AWS CloudFormation modello descrive una AWS Config regola per verificare la presenza delle chiavi obbligatorie descritte nella tabella, su bucket Amazon S3, istanze Amazon EC2 e volumi Amazon EBS. ``` Resources: MandatoryTags: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: ExampleIncMandatoryTags Description: These tags should be in place InputParameters: tag1Key: example-inc:cost-allocation:ApplicationId tag2Key: example-inc:cost-allocation:BusinessUnitId tag3Key: example-inc:cost-allocation:CostCenter tag4Key: example-inc:automation:EnvironmentId Scope: ComplianceResourceTypes: - "AWS::S3::Bucket" - "AWS::EC2::Instance" - "AWS::EC2::Volume" Source: Owner: AWS SourceIdentifier: REQUIRED_TAGS ``` Per gli ambienti in cui le risorse vengono gestite manualmente, è possibile migliorare una AWS Config regola per aggiungere automaticamente la chiave tag mancante alle risorse utilizzando una correzione automatica tramite una funzione. AWS Lambda Sebbene funzioni bene per i carichi di lavoro statici, è progressivamente meno efficace man mano che si inizia a gestire le risorse tramite IaC e pipeline di implementazione. **AWS Organizations — Le politiche di controllo dei servizi (SCPs)** sono un tipo di politica organizzativa che è possibile utilizzare per gestire le autorizzazioni all'interno dell'organizzazione. SCPsoffrono il controllo centralizzato sulle autorizzazioni massime disponibili per tutti gli account dell'organizzazione o dell'unità organizzativa (OU). SCPs riguardano solo gli utenti e i ruoli gestiti da account che fanno parte dell'organizzazione. Sebbene non influiscano direttamente sulle risorse, limitano le autorizzazioni degli utenti e dei ruoli, incluse le autorizzazioni per l'etichettatura delle azioni. Per quanto riguarda l'etichettatura, SCPs può fornire una granularità aggiuntiva per l'applicazione dei tag oltre a quella fornita dalle politiche sui tag. Nell'esempio seguente, la policy negherà le `ec2:RunInstances` richieste in cui il `example-inc:cost-allocation:CostCenter` tag non è presente. Quanto segue è un SCP di negazione: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyRunInstanceWithNoCostCenterTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*" ], "Condition": { "Null": { "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true" } } } ] } ``` ------ Non è possibile recuperare l'effettiva politica di controllo del servizio che si applica a un account collegato fin dalla progettazione. Laddove si impone il tagging with SCPs, la documentazione deve essere disponibile per gli sviluppatori in modo che possano garantire che le loro risorse soddisfino le politiche applicate ai loro account. Fornire l'accesso in sola lettura agli CloudTrail eventi all'interno del proprio account può aiutare gli sviluppatori a eseguire il debug quando le loro risorse non sono conformi. # Misurare l'efficacia dei tag e apportare miglioramenti Dopo aver implementato una strategia di tagging, è importante misurarne l'efficacia rispetto ai casi d'uso target. La misura dell'efficacia varierà in base al caso d'uso. Esempio: + **Attribuzione dei costi**: è possibile misurare la copertura codificata delle risorse in base alla spesa utilizzando strumenti come [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)il rapporto sui [AWS costi e sull'utilizzo](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/). Ad esempio, puoi tenere traccia della *percentuale di risorse con o senza tag che generano addebiti*, in particolare monitorando chiavi di tag specifiche. + **Automazione**: potresti voler verificare se il risultato desiderato è stato raggiunto. Ad esempio, se le istanze Amazon EC2 non di produzione sono sospese al di fuori dell'orario di lavoro, verifica gli orari di inizio e fine delle istanze. [Resource Groups & Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) all'interno dell'account di gestione offre funzionalità aggiuntive per analizzare la conformità alle politiche sui tag per tutti gli account collegati dell'organizzazione. In base ai risultati della misurazione dell'efficacia dei tag, individuate se sono necessari miglioramenti o modifiche in uno qualsiasi dei passaggi, come la definizione dei casi d'uso, l'implementazione o l'applicazione dello schema di tagging. Apportate le modifiche necessarie e ripetete il ciclo fino a raggiungere l'efficacia desiderata. Nell'esempio con l'attribuzione dei costi, puoi considerare il miglioramento percentuale. Poiché sono gli sviluppatori e gli operatori a dover eseguire l'effettiva etichettatura delle risorse, è fondamentale che se ne assumano la responsabilità. Questa non è l'unica responsabilità aggiuntiva che i team in genere si assumono nel loro percorso di AWS adozione. Sono importanti anche una maggiore responsabilità per la sicurezza e i costi di sviluppo e funzionamento delle loro applicazioni. Organizations utilizza spesso obiettivi e traguardi come mezzo per motivare l'adozione di nuove pratiche, quindi questo può valere anche in questo caso.