Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Membangun strategi penandaan Anda Seperti banyak praktik dalam operasi, menerapkan strategi penandaan *adalah proses iterasi dan peningkatan*. Mulailah dari yang kecil dengan prioritas langsung Anda dan kembangkan skema penandaan sesuai kebutuhan. ![\[Diagram yang menunjukkan representasi grafis dari iterasi strategi penandaan dan siklus peningkatan\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/tagging-best-practices/images/tagging-strategy-cycle.png) Sepanjang proses ini, kepemilikan adalah kunci akuntabilitas dan kemajuan. Karena tag dapat digunakan untuk berbagai tujuan, strategi penandaan keseluruhan dapat dibagi menjadi area tanggung jawab dalam suatu organisasi. Penandaan memungkinkan pendekatan terprogram untuk kegiatan yang bergantung pada karakterisasi sumber daya. Kisaran pemangku kepentingan yang dapat mengambil manfaat dari penandaan akan tergantung pada ukuran organisasi dan praktik operasional. Organisasi yang lebih besar dapat memperoleh manfaat dari mendefinisikan secara jelas tanggung jawab tim yang terlibat dalam membangun dan menerapkan strategi penandaan. Beberapa pemangku kepentingan dapat bertanggung jawab untuk mengidentifikasi kebutuhan (mendefinisikan kasus penggunaan) untuk penandaan; yang lain dapat bertanggung jawab untuk memelihara, menerapkan, dan meningkatkan strategi penandaan. Dengan menetapkan kepemilikan, Anda berada dalam posisi yang baik untuk menerapkan aspek individual dari strategi. Jika perlu, kepemilikan ini dapat diformalkan sebagai kebijakan dan didokumentasikan dalam matriks tanggung jawab (misalnya, RACI: Bertanggung Jawab, Bertanggung Jawab, Dikonsultasikan, dan Diinformasikan), atau dalam model tanggung jawab bersama. Dalam organisasi yang lebih kecil, tim mungkin memainkan banyak peran dalam strategi penandaan, mulai dari definisi persyaratan hingga implementasi dan penegakan hukum. # Mendefinisikan kebutuhan dan kasus penggunaan Mulailah membangun strategi Anda dengan terlibat dengan pemangku kepentingan yang memiliki kebutuhan mendasar mendasar untuk mengkonsumsi metadata. Tim-tim ini menentukan metadata yang perlu ditandai dengan sumber daya untuk mendukung aktivitas mereka, seperti pelaporan, otomatisasi, dan klasifikasi data. Mereka menguraikan bagaimana sumber daya perlu diatur dan kebijakan mana yang perlu dipetakan. Contoh peran dan fungsi yang dapat dimiliki oleh para pemangku kepentingan ini dalam organisasi meliputi: + **Keuangan** dan **Lini Bisnis** perlu memahami nilai investasi dengan memetakannya ke biaya untuk memprioritaskan tindakan yang perlu diambil ketika menangani ketidakseimbangan. Memahami *biaya vs nilai yang dihasilkan* membantu mengidentifikasi lini bisnis atau penawaran produk yang gagal. Ini mengarah pada keputusan berdasarkan informasi tentang dukungan berkelanjutan, mengadopsi alternatif (misalnya, menggunakan penawaran SaaS atau layanan terkelola), atau menghentikan penawaran bisnis yang tidak menguntungkan. + **Tata Kelola** dan **Kepatuhan** perlu memahami kategorisasi data (misalnya, publik, sensitif, atau rahasia), apakah beban kerja tertentu berada di dalam atau di luar ruang lingkup untuk audit terhadap standar atau peraturan tertentu, dan kekritisan layanan (apakah layanan atau aplikasi bersifat bisnis penting) untuk menerapkan kontrol dan pengawasan yang sesuai, seperti izin, kebijakan, dan pemantauan. + **Operasi** dan **Pengembangan** perlu memahami siklus hidup beban kerja, tahapan implementasi produk yang didukung, dan pengelolaan tahapan rilis (misalnya, Pengembangan, Pengujian, Pembagian produksi) dan prioritas dukungan terkait dan persyaratan manajemen pemangku kepentingan. Tugas seperti Backup, Patching, Observability dan Deprecation juga perlu didefinisikan dan dipahami. + **Keamanan Informasi (InfoSec)** dan **Operasi Keamanan (SecOps)** menguraikan kontrol apa yang harus diterapkan dan mana yang direkomendasikan. InfoSec biasanya mendefinisikan implementasi kontrol, dan umumnya SecOps bertanggung jawab untuk mengelola kontrol tersebut. Bergantung pada kasus penggunaan, prioritas, ukuran organisasi, dan praktik operasional, Anda mungkin memerlukan perwakilan dari berbagai tim dalam organisasi, seperti Keuangan (termasuk Pengadaan), Keamanan Informasi, Pengaktifan Cloud, dan Operasi Cloud. Anda juga memerlukan representasi dari pemilik aplikasi dan proses untuk fungsi-fungsi seperti menambal, mencadangkan dan memulihkan, memantau, penjadwalan pekerjaan, dan pemulihan bencana. Perwakilan ini membantu mendorong definisi, implementasi, dan mengukur efektivitas strategi penandaan. Mereka harus [https://www.youtube.com/watch?v=aFdpBqmDpzM](https://www.youtube.com/watch?v=aFdpBqmDpzM) dari pemangku kepentingan dan kasus penggunaannya, dan melakukan lokakarya lintas fungsi. Dalam lokakarya, mereka mendapatkan kesempatan untuk berbagi perspektif dan kebutuhan mereka, dan membantu mendorong strategi secara keseluruhan. Contoh peserta dan keterlibatan mereka dalam berbagai kasus penggunaan dijelaskan kemudian dalam whitepaper ini. Para pemangku kepentingan juga mendefinisikan dan memvalidasi kunci untuk tag wajib, dan dapat merekomendasikan ruang lingkup untuk tag opsional. Misalnya, Tim Keuangan mungkin perlu menghubungkan sumber daya ke pusat biaya internal, unit bisnis, atau keduanya. Dengan demikian, mereka mungkin mengharuskan kunci tag tertentu, seperti `CostCenter` dan`BusinessUnit`, dibuat wajib. Tim pengembangan individu mungkin memutuskan untuk menggunakan tag tambahan untuk tujuan otomatisasi, seperti`EnvironmentName`,`OptIn`, atau`OptOut`. Pemangku kepentingan utama perlu menyetujui pendekatan strategi penandaan, dan mendokumentasikan jawaban untuk pertanyaan terkait kepatuhan dan tata kelola, seperti: + Kasus penggunaan apa yang perlu ditangani? + Siapa yang bertanggung jawab untuk menandai sumber daya (implementasi)? + Bagaimana tag diberlakukan dan metode dan otomatisasi apa yang akan digunakan (proaktif atau reaktif)? + Bagaimana efektivitas dan tujuan penandaan diukur? + Seberapa sering strategi penandaan harus ditinjau? + Siapa yang mendorong perbaikan? Bagaimana ini dilakukan? Fungsi bisnis, seperti Cloud Enablement, Cloud Business Oce, dan Cloud Platform Engineering, kemudian dapat berperan sebagai fasilitator untuk proses membangun strategi penandaan, membantu mendorong adopsi, dan memastikan konsistensi aplikasinya dengan mengukur kemajuan, menghilangkan hambatan, dan mengurangi upaya duplikat. # Mendefinisikan dan menerbitkan skema penandaan Gunakan pendekatan yang konsisten dalam menandai AWS sumber daya Anda, baik untuk tag wajib maupun opsional. Skema penandaan yang komprehensif membantu Anda mencapai konsistensi ini. Contoh berikut dapat membantu Anda memulai: + Setuju pada kunci tag wajib + Tentukan nilai yang dapat diterima dan konvensi penamaan tag (huruf besar atau kecil, tanda hubung atau garis bawah, hierarki, dan sebagainya) + Konfirmasi nilai tidak akan merupakan informasi identitas pribadi (PII) + Tentukan siapa yang dapat menentukan dan membuat kunci tag baru + Setuju tentang cara menambahkan nilai tag wajib baru dan cara mengelola tag opsional Tinjau tabel [kategori penandaan](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) berikut, yang dapat digunakan sebagai dasar dari apa yang mungkin Anda sertakan dalam skema penandaan Anda. Anda masih perlu menentukan konvensi yang akan Anda gunakan untuk kunci tag dan nilai apa yang diizinkan untuk masing-masing. Skema penandaan adalah dokumen di mana Anda mendefinisikan ini untuk lingkungan Anda. *Tabel 6 - Contoh skema penandaan definitif* | Kasus Penggunaan | Tag Kunci | Alasan | Nilai yang Diizinkan (Terdaftar atau awalan nilai/sux) | Digunakan untuk Alokasi Biaya | Jenis Sumber Daya | Lingkup | Diperlukan | | --- | --- | --- | --- | --- | --- | --- | --- | | Alokasi Biaya | example-inc:cost-allocation:ApplicationId | Lacak biaya vs nilai yang dihasilkan oleh setiap lini bisnis | DataLakeX, RetailSiteX | Y | Semua | Semua | Wajib | | Alokasi Biaya | example-inc:cost-allocation:BusinessUnitId | Pantau biaya berdasarkan unit bisnis | Architecture, DevOps, Finance | Y | Semua | Semua | Wajib | | Alokasi Biaya | example-inc:cost-allocation:CostCenter | Pantau biaya berdasarkan pusat biaya | 123-\$1 | Y | Semua | Semua | Wajib | | Alokasi Biaya | example-inc:cost-allocation:Owner | Pemegang anggaran mana yang bertanggung jawab atas beban kerja ini | Marketing, RetailSupport | Y | Semua | Semua | Wajib | | Kontrol Akses | example-inc:access-control:LayerId | Identifikasi SubComponent /Layer untuk memberikan akses ke sumber daya berdasarkan peran | DB\$1Layer, Web\$1Layer, App\$1Layer | T | Semua | Semua | Opsional | | Otomatisasi | example-inc:automation:EnvironmentId | Menerapkan penjadwalan lingkungan pengujian dan pengembangan, juga disebut sebagai tahap siklus hidup pengembangan perangkat lunak (SDLC) | Prod, Dev, Test, Sandbox | T | EC2, RDS, EBS | Semua | Wajib | | DevOps | example-inc:operations:Owner | Yang team/squad bertanggung jawab atas penciptaan dan pemeliharaan sumber daya | Squad01 | T | Semua | Semua | Wajib | | Pemulihan Bencana | example-inc:disaster-recovery:rpo | Tentukan tujuan titik pemulihan (RPO) untuk sumber daya | 6h, 24h | T | S3, EBS | Prod | Wajib | | Klasifikasi Data | example-inc:data:classification | Klasifikasi data untuk kepatuhan dan tata kelola | Public, Private, Confidential, Restricted | T | S3, EBS | Semua | Wajib | | Kepatuhan | example-inc:compliance:framework | Mengidentifikasi kerangka kerja kepatuhan yang dikenakan beban kerja | PCI-DSS, HIPAA | T | Semua | Prod | Wajib | Setelah skema penandaan didefinisikan, kelola skema dalam repositori yang dikendalikan versi yang dibuat dapat diakses oleh semua pemangku kepentingan yang relevan untuk referensi yang mudah dan pembaruan yang dapat dilacak. Pendekatan ini meningkatkan efisiensi dan memungkinkan kelincahan. # AWS Organizations — Kebijakan tag Kebijakan dalam AWS Organizations memungkinkan Anda menerapkan jenis tata kelola tambahan Akun AWS di organisasi Anda. [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) adalah bagaimana Anda dapat mengekspresikan skema penandaan Anda dalam bentuk JSON sehingga platform dapat melaporkan dan secara opsional menegakkan skema dalam lingkungan Anda. AWS Kebijakan tag mendefinisikan nilai yang dapat diterima untuk kunci tag pada jenis sumber daya tertentu. Kebijakan ini dapat berupa daftar nilai, atau awalan yang diikuti oleh karakter wildcard ()`*`. Pendekatan awalan sederhana kurang ketat daripada daftar nilai diskrit tetapi membutuhkan perawatan yang lebih sedikit. Contoh berikut menunjukkan cara mendefinisikan kebijakan penandaan untuk memvalidasi nilai yang dapat diterima untuk kunci yang diberikan. Bekerja dari definisi tabel skema yang ramah manusia, Anda dapat menyalin informasi ini ke dalam satu atau beberapa kebijakan tag. Kebijakan terpisah dapat digunakan untuk mendukung kepemilikan yang didelegasikan atau beberapa kebijakan mungkin hanya berlaku dalam skenario tertentu. ## ExampleInc- CostAllocation .json Berikut ini adalah contoh kebijakan tag yang melaporkan tag Alokasi Biaya: ``` { "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- DisasterRecovery .json Berikut ini adalah contoh kebijakan tag yang melaporkan tag Disaster Recovery: ``` { "tags": { "example-inc:disaster-recovery:rpo": { "tag_key": { "@@assign": "example-inc:disaster-recovery:rpo" }, "tag_value": { "@@assign": [ "6h", "24h" ] } } } } ``` Dalam contoh ini, kebijakan `ExampleInc-CostAllocation` tag dilampirkan ke `Workloads` OU, dan karenanya berlaku untuk semua akun di kedua `Prod` dan `Test` anak OUs. Demikian pula, kebijakan `ExampleInc-DisasterRecovery` tag dilampirkan ke `Prod` OU dan oleh karena itu hanya berlaku untuk akun di bawah OU ini. Whitepaper [Mengatur Lingkungan Anda Menggunakan Beberapa Akun](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) mengeksplorasi struktur OU yang direkomendasikan secara lebih rinci. ![\[Diagram yang menunjukkan lampiran kebijakan tag ke struktur OU dan kebijakan yang efektif\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/tagging-best-practices/images/adding-tagging-to-policies-in-ou-structure.png) Melihat `marketing-prod` akun dalam diagram, kedua kebijakan tag berlaku untuk akun ini, jadi kami memiliki konsep *kebijakan yang efektif*, yaitu konvolusi kebijakan dari jenis tertentu yang berlaku untuk akun. Jika Anda mengelola sumber daya secara manual, Anda dapat meninjau kebijakan efektif dengan mengunjungi [Resource Groups & Tag Editor:Tag policy di konsol](https://console.aws.amazon.com/resource-groups/tag-policies). Jika Anda menggunakan infrastruktur sebagai kode (IAc) atau skrip untuk mengelola sumber daya, Anda dapat menggunakan panggilan [https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html)API. # Menerapkan dan menegakkan penandaan Di bagian ini, kami akan memperkenalkan Anda pada alat yang tersedia untuk strategi manajemen sumber daya berikut: manual, infrastruktur sebagai kode (IAc), dan integration/continuous pengiriman berkelanjutan (CI/CD). Dimensi kunci untuk pendekatan ini adalah tingkat penyebaran yang semakin sering. ## Sumber daya yang dikelola secara manual Ini biasanya beban kerja yang termasuk dalam [dasar atau tahap migrasi adopsi](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html). Seringkali, ini adalah beban kerja statis sederhana yang telah dibangun menggunakan prosedur tertulis tradisional atau yang dimigrasi *seperti* menggunakan alat seperti AWS Application Migration Service dari lingkungan lokal. Alat migrasi, seperti Migration Hub dan Application Migration Service, dapat menerapkan tag sebagai bagian dari proses migrasi. Namun, jika tag tidak diterapkan selama migrasi asli atau skema penandaan telah berubah sejak saat itu, [Editor Tag](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) (fitur dari Konsol Manajemen AWS) memungkinkan Anda untuk mencari sumber daya menggunakan berbagai kriteria pencarian dan menambah, memodifikasi, atau menghapus tag secara massal. Kriteria pencarian dapat mencakup sumber daya dengan atau tanpa kehadiran tag atau nilai tertentu. AWS Resource Tagging API memungkinkan Anda menjalankan fungsi-fungsi ini secara terprogram. Karena beban kerja ini dimodernisasi, jenis sumber daya seperti grup Auto Scaling diperkenalkan. Jenis sumber daya ini memungkinkan elastisitas yang lebih besar dan ketahanan yang lebih baik. Grup penskalaan otomatis mengelola instans Amazon EC2 atas nama Anda, namun, Anda mungkin masih ingin instans EC2 diberi tag secara konsisten dengan sumber daya yang dibuat secara manual. [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html) menyediakan sarana untuk menentukan tag yang harus diterapkan Auto Scaling ke instance yang dibuatnya. Ketika sumber daya beban kerja dikelola secara manual, akan sangat membantu untuk mengotomatiskan penandaan sumber daya. Ada berbagai solusi yang tersedia. Salah satu pendekatannya adalah dengan menggunakan Aturan AWS Config, yang dapat memeriksa `required_tags` dan kemudian memulai fungsi Lambda untuk menerapkannya. Aturan AWS Config dijelaskan secara lebih rinci nanti di whitepaper ini. ## Sumber daya yang dikelola Infrastruktur sebagai kode (IAc) AWS CloudFormation menyediakan bahasa umum untuk menyediakan semua sumber daya infrastruktur di lingkungan Anda AWS . CloudFormation template adalah file JSON atau YAMAL yang membuat AWS sumber daya secara otomatis. Saat membuat AWS sumber daya menggunakan CloudFormation templat, Anda dapat menggunakan properti Tag CloudFormation Sumber Daya untuk menerapkan tag ke jenis sumber daya yang didukung saat pembuatan. Mengelola tag serta sumber daya dengan IAc membantu memastikan konsistensi. Ketika sumber daya dibuat oleh AWS CloudFormation, layanan secara otomatis menerapkan satu set tag yang AWS ditentukan ke sumber daya yang dibuat oleh AWS CloudFormation template. Ini adalah: ``` aws:cloudformation:stack-name aws:cloudformation:stack-id aws:cloudformation:logical-id ``` Anda dapat dengan mudah menentukan grup sumber daya berdasarkan AWS CloudFormation tumpukan. Tag AWS yang ditentukan ini diwarisi oleh sumber daya yang dibuat oleh tumpukan. Namun, untuk instans Amazon EC2 dalam grup Auto Scaling, [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)perlu diatur dalam definisi grup Auto Scaling di template Anda. AWS CloudFormation Atau, jika Anda menggunakan [Template Peluncuran EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) dengan grup Auto Scaling maka Anda dapat menentukan tag dalam definisinya. Dianjurkan untuk menggunakan [Template Peluncuran EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) dengan grup Auto Scaling atau dengan AWS layanan kontainer. Layanan ini dapat membantu memastikan penandaan instans Amazon EC2 Anda secara konsisten dan juga mendukung Auto [Scaling di Beberapa Jenis Instans & Opsi Pembelian](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/), yang dapat meningkatkan ketahanan dan mengoptimalkan biaya komputasi Anda. [AWS CloudFormation Hooks](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/) menyediakan pengembang dengan sarana untuk menjaga aspek-aspek kunci dari aplikasi mereka konsisten dengan standar organisasi mereka. Hooks dapat dikonfigurasi untuk memberikan *peringatan* atau *mencegah penyebaran*. Fitur ini paling cocok untuk memeriksa elemen konfigurasi utama dalam template Anda, seperti apakah grup Auto Scaling dikonfigurasi untuk menerapkan tag yang ditentukan pelanggan ke semua instans Amazon EC2 yang diluncurkan, atau untuk memastikan bahwa semua bucket Amazon S3 dibuat dengan pengaturan enkripsi yang diperlukan. Dalam kedua kasus tersebut, evaluasi kepatuhan ini didorong ke proses penerapan sebelumnya dengan AWS CloudFormation kait sebelum penerapan. AWS CloudFormation menyediakan kemampuan untuk mendeteksi ketika sumber daya (lihat Sumber [daya yang mendukung deteksi drift](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html)) yang disediakan dari templat telah dimodifikasi dan sumber daya tidak lagi cocok dengan konfigurasi templat yang diharapkan. Ini dikenal sebagai *drift*. Jika Anda menggunakan otomatisasi untuk menerapkan tag ke sumber daya yang dikelola melalui IAc, maka Anda memodifikasinya, memperkenalkan drift. Saat menggunakan IAc, saat ini disarankan untuk mengelola persyaratan penandaan apa pun sebagai bagian dari templat IAc, menerapkan AWS CloudFormation kait, dan menerbitkan kumpulan aturan AWS CloudFormation Guard yang dapat digunakan oleh otomatisasi. ## Sumber daya terkelola pipa CI/CD Ketika kematangan beban kerja meningkat, kemungkinan teknik seperti integrasi berkelanjutan dan penerapan berkelanjutan (CI/CD) diadopsi. Teknik-teknik ini membantu mengurangi risiko penyebaran dengan membuatnya lebih mudah untuk menerapkan perubahan kecil lebih sering dengan peningkatan otomatisasi pengujian. Strategi observabilitas yang mendeteksi perilaku tak terduga yang diperkenalkan oleh penerapan dapat secara otomatis memutar kembali penerapan dengan dampak pengguna minimal. Ketika Anda mencapai tahap penyebaran puluhan kali sehari, menerapkan tag secara surut tidak lagi praktis. Semuanya perlu dinyatakan sebagai kode atau konfigurasi, dikontrol versi, dan, sedapat mungkin, diuji dan dievaluasi sebelum penerapan ke dalam produksi. Dalam [model pengembangan dan operasi (DevOps)](https://aws.amazon.com/devops/what-is-devops/) gabungan, banyak praktik membahas pertimbangan operasional sebagai kode dan memvalidasinya di awal siklus hidup penerapan. Idealnya, Anda ingin mendorong pemeriksaan ini sedini mungkin dalam proses (seperti yang ditunjukkan dengan AWS CloudFormation kait), sehingga Anda dapat yakin bahwa AWS CloudFormation template Anda memenuhi kebijakan Anda sebelum mereka meninggalkan mesin pengembang. [AWS CloudFormation Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/) menyediakan sarana untuk menulis aturan kepatuhan preventif untuk apa pun yang dapat Anda definisikan. CloudFormation Template divalidasi terhadap aturan di lingkungan pengembangan. Jelas, fitur ini memiliki berbagai aplikasi, tetapi dalam whitepaper ini, kita hanya akan melihat beberapa contoh yang akan memastikan selalu [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)digunakan. Berikut ini adalah contoh aturan CloudFormation Penjaga: ``` 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-/ <> } } ``` Dalam contoh kode, kami memfilter template untuk semua sumber daya yang berjenis`AutoScalingGroup`, dan kemudian memiliki dua aturan: + **`tags_asg_automation_EnvironmentId`**- Memeriksa bahwa tag dengan kunci ini ada, memiliki nilai dalam daftar nilai yang diizinkan, dan `PropagateAtLaunch` itu diatur ke `true` + **`tags_asg_costAllocation_CostCenter`**- Memeriksa bahwa tag ada dengan kunci ini, memiliki nilai yang dimulai dengan nilai awalan yang ditentukan, dan yang `PropagateAtLaunch` diatur ke `true` ## Penegakan Seperti dijelaskan sebelumnya, **Resource Groups & Tag Editor** menyediakan sarana untuk mengidentifikasi di mana sumber daya Anda gagal memenuhi persyaratan penandaan yang ditentukan dalam kebijakan tag yang OUs diterapkan pada organisasi. Mengakses alat konsol **Resource Groups & Tag Editor** dari dalam akun anggota Organisasi menunjukkan kepada Anda kebijakan yang berlaku untuk akun tersebut dan sumber daya dalam akun yang gagal memenuhi persyaratan kebijakan tag. Jika diakses dari akun manajemen (dan jika **kebijakan Tag** *mengaktifkan Akses* di layanan di bawah AWS Organizations), Anda dapat melihat [kepatuhan kebijakan tag untuk semua akun tertaut di organisasi](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). Dalam Kebijakan Tag itu sendiri, Anda dapat mengaktifkan penegakan untuk jenis sumber daya tertentu. Dalam contoh kebijakan berikut, kami telah menambahkan penegakan hukum sehingga semua jenis sumber daya `ec2:instance` dan `ec2:volume` harus mematuhi kebijakan. Ada beberapa batasan yang diketahui, seperti harus ada tag pada sumber daya agar dapat dievaluasi oleh kebijakan tag. Lihat [Sumber daya yang mendukung penegakan dengan kebijakan tag](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html) untuk daftar. ### ExampleInc-Alokasi biaya.json Berikut ini adalah contoh kebijakan tag yang melaporkan and/or memberlakukan tag Alokasi Biaya: ``` { "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 adalah layanan yang memungkinkan Anda menilai, mengaudit, dan mengevaluasi konfigurasi AWS sumber daya Anda (lihat [Jenis sumber daya yang didukung oleh AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)). Dalam kasus penandaan, kita dapat menggunakannya untuk mengidentifikasi sumber daya yang tidak memiliki tag dengan kunci tertentu, menggunakan `required_tags` aturan (lihat [tipe Sumber daya yang didukung oleh required\$1tags](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)). Dari contoh sebelumnya, kami mungkin menguji keberadaan kunci pada semua instans Amazon EC2. Dalam kasus di mana kunci tidak ada, instance akan terdaftar sebagai tidak sesuai. AWS CloudFormation Template ini menjelaskan AWS Config Aturan untuk menguji keberadaan kunci wajib yang dijelaskan dalam tabel, di bucket Amazon S3, instans Amazon EC2, dan volume 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 ``` Untuk lingkungan di mana sumber daya dikelola secara manual, AWS Config aturan dapat ditingkatkan untuk secara otomatis menambahkan kunci tag yang hilang ke sumber daya menggunakan remediasi otomatis melalui AWS Lambda fungsi. Meskipun ini berfungsi dengan baik untuk beban kerja statis, ini semakin kurang efektif saat Anda mulai mengelola sumber daya Anda melalui IAc dan pipeline penerapan. **AWS Organizations Kebijakan kontrol layanan (SCPs)** adalah jenis kebijakan organisasi yang dapat Anda gunakan untuk mengelola izin di organisasi Anda. SCPsmenawarkan kontrol pusat atas izin maksimum yang tersedia untuk semua akun di organisasi atau unit organisasi (OU) Anda. SCPs hanya mempengaruhi pengguna dan peran yang dikelola oleh akun yang merupakan bagian dari organisasi. Meskipun mereka tidak memengaruhi sumber daya secara langsung, mereka membatasi izin pengguna dan peran yang mencakup izin untuk tindakan penandaan. Sehubungan dengan penandaan, SCPs dapat memberikan perincian tambahan untuk penegakan tag serta apa yang dapat diberikan oleh kebijakan tag. Dalam contoh berikut, kebijakan akan menolak `ec2:RunInstances` permintaan di mana `example-inc:cost-allocation:CostCenter` tag tidak ada. Berikut ini adalah penolakan SCP: ------ #### [ 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" } } } ] } ``` ------ Tidak mungkin untuk mengambil kebijakan kontrol layanan efektif yang berlaku untuk akun tertaut berdasarkan desain. Jika Anda menerapkan penandaan SCPs, dokumentasi harus tersedia bagi pengembang sehingga mereka dapat memastikan sumber daya mereka memenuhi kebijakan yang telah diterapkan ke akun mereka. Memberikan akses hanya baca ke CloudTrail acara dalam akun mereka dapat mendukung pengembang dalam tugas debugging ketika sumber daya mereka gagal mematuhi. # Mengukur efektivitas penandaan dan mendorong peningkatan Setelah Anda menerapkan strategi penandaan, penting untuk mengukur efektivitasnya terhadap kasus penggunaan target. Ukuran efektivitas akan bervariasi menurut kasus penggunaan. Contoh: + **Atribusi biaya** - Anda dapat mengukur cakupan penandaan sumber daya berdasarkan pengeluaran menggunakan alat seperti [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)atau Laporan [AWS Biaya dan Penggunaan](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/). Misalnya, Anda dapat melacak *persentase sumber daya yang ditandai atau tidak ditandai* yang menghasilkan biaya, terutama memantau kunci tag tertentu. + **Otomatisasi** - Anda mungkin ingin mengaudit jika hasil yang diinginkan telah tercapai. Misalnya, apakah instans Amazon EC2 non-produksi ditangguhkan di luar jam kerja, waktu mulai dan berhenti instans audit. [Resource Groups & Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) dalam akun manajemen menyediakan kemampuan tambahan untuk menganalisis kepatuhan kebijakan tag untuk semua akun tertaut di organisasi Anda. Berdasarkan hasil pengukuran efektivitas penandaan Anda, identifikasi apakah ada perbaikan atau perubahan yang diperlukan dalam salah satu langkah seperti definisi kasus penggunaan, penerapan skema penandaan, atau penegakan hukum. Buat perubahan yang diperlukan dan ulangi siklus sampai efektivitas yang diinginkan tercapai. Dalam contoh dengan atribusi biaya, Anda dapat melihat peningkatan persentase. Karena pengembang dan operatorlah yang perlu melakukan penandaan sumber daya yang sebenarnya, sangat penting untuk meminta mereka mengambil kepemilikan. Ini bukan satu-satunya tanggung jawab tambahan yang biasanya diasumsikan tim dalam perjalanan AWS adopsi mereka. Peningkatan tanggung jawab untuk keamanan dan biaya pengembangan dan pengoperasian aplikasi mereka juga penting. Organizations sering menggunakan tujuan dan target sebagai sarana untuk memotivasi penerapan praktik baru, jadi ini juga dapat diterapkan di sini.