Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Menandai kasus penggunaan **Topics** + [Tag untuk alokasi biaya dan manajemen keuangan](tags-for-cost-allocation-and-financial-management.md) + [Tag untuk operasi dan dukungan](tags-for-operations-and-support.md) + [Tag untuk keamanan data, manajemen risiko, dan kontrol akses](tags-for-data-security-risk-management-and-access-control.md) # Tag untuk alokasi biaya dan manajemen keuangan Salah satu kasus penggunaan penandaan pertama yang sering ditangani organisasi adalah visibilitas dan pengelolaan biaya dan penggunaan. Biasanya ada beberapa alasan untuk ini: + **Ini biasanya skenario yang dipahami dengan baik dan persyaratan sudah diketahui.** Misalnya, tim keuangan ingin melihat total biaya beban kerja dan infrastruktur yang menjangkau berbagai layanan, fitur, akun, atau tim. Salah satu cara untuk mencapai visibilitas biaya ini adalah melalui penandaan sumber daya yang konsisten. + **Tag dan nilainya didefinisikan dengan jelas.** Biasanya, mekanisme alokasi biaya sudah ada dalam sistem keuangan organisasi, misalnya, melacak berdasarkan pusat biaya, unit bisnis, tim, atau fungsi organisasi. + **Pengembalian investasi yang cepat dan dapat dibuktikan.** Dimungkinkan untuk melacak tren pengoptimalan biaya dari waktu ke waktu ketika sumber daya ditandai secara konsisten, misalnya, untuk sumber daya yang berukuran benar, diskalakan otomatis, atau diletakkan pada jadwal. Memahami bagaimana Anda mengeluarkan biaya AWS memungkinkan Anda membuat keputusan keuangan yang tepat. Mengetahui di mana Anda telah mengeluarkan biaya di tingkat sumber daya, beban kerja, tim, atau organisasi meningkatkan pemahaman Anda tentang nilai yang diberikan pada tingkat yang berlaku jika dibandingkan dengan hasil bisnis yang dicapai. Tim teknik mungkin tidak memiliki pengalaman dengan manajemen keuangan sumber daya mereka. Melampirkan seseorang dengan keterampilan khusus dalam manajemen AWS keuangan yang dapat melatih tim teknik dan pengembangan pada dasar-dasar manajemen AWS keuangan dan menciptakan hubungan antara keuangan dan teknik untuk menumbuhkan budaya FinOps akan membantu mencapai hasil yang terukur untuk bisnis dan mendorong tim untuk membangun dengan biaya dalam pikiran. Menetapkan praktik keuangan yang baik tercakup secara mendalam oleh [Pilar Optimalisasi Biaya](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) dari Kerangka Well-Architected, tetapi kami akan menyentuh beberapa prinsip dasar dalam whitepaper ini. # Tag alokasi biaya Alokasi biaya mengacu pada penugasan atau distribusi biaya yang dikeluarkan kepada pengguna atau penerima manfaat dari biaya tersebut setelah proses yang ditentukan. *Dalam konteks whitepaper ini, kami membagi alokasi biaya menjadi dua jenis: *showback* dan chargeback.* Alat dan mekanisme *showback* membantu meningkatkan kesadaran biaya. *Chargeback* membantu pemulihan biaya dan mendorong pemberdayaan kesadaran biaya. *Showback* adalah tentang presentasi, perhitungan, dan pelaporan biaya yang dikeluarkan oleh entitas tertentu, seperti unit bisnis, aplikasi, pengguna, atau pusat biaya. Misalnya: “tim teknik infrastruktur bertanggung jawab atas \$1X AWS pengeluaran bulan lalu”. *Chargeback* adalah tentang pengisian aktual biaya yang dikeluarkan kepada entitas tersebut melalui proses akuntansi internal organisasi, seperti sistem keuangan atau voucher jurnal. Misalnya: “\$1 X dikurangkan dari AWS anggaran tim teknik infrastruktur.” Dalam kedua kasus tersebut, menandai sumber daya dengan tepat dapat membantu mengalokasikan biaya ke entitas, satu-satunya perbedaan adalah apakah seseorang diharapkan melakukan pembayaran atau tidak. Tata kelola keuangan organisasi Anda mungkin memerlukan akuntansi transparan biaya yang dikeluarkan di aplikasi, unit bisnis, pusat biaya, dan tingkat tim. Melakukan atribusi biaya yang didukung oleh [Tag Alokasi Biaya](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) memberi Anda data yang diperlukan untuk secara akurat mengaitkan biaya yang dikeluarkan oleh entitas dari sumber daya yang ditandai dengan tepat. + **Akuntabilitas** — Memastikan bahwa biaya dialokasikan kepada mereka yang bertanggung jawab atas penggunaan sumber daya. Satu titik layanan atau kelompok dapat bertanggung jawab atas ulasan dan pelaporan pengeluaran. + **Transparansi keuangan** — Tunjukkan pandangan yang jelas tentang alokasi uang tunai terhadap TI dengan membuat dasbor yang efektif dan analisis biaya yang berarti untuk kepemimpinan. + **Investasi TI yang diinformasikan** — Lacak ROI berdasarkan proyek, aplikasi, atau lini bisnis, dan memberdayakan tim untuk membuat keputusan bisnis yang lebih baik, misalnya, mengalokasikan lebih banyak dana untuk aplikasi yang menghasilkan pendapatan. Singkatnya, tag alokasi biaya dapat membantu memberi tahu Anda: + Siapa yang memiliki pengeluaran dan bertanggung jawab untuk mengoptimalkannya? + Beban kerja, aplikasi, atau produk apa yang mengeluarkan pengeluaran? Lingkungan atau panggung yang mana? + Area pengeluaran apa yang tumbuh paling cepat? + Berapa banyak pengeluaran yang dapat dikurangkan dari AWS anggaran berdasarkan tren masa lalu? + Apa dampak dari upaya optimalisasi biaya dalam beban kerja, aplikasi, atau produk tertentu? Mengaktifkan tag sumber daya untuk alokasi biaya membantu dengan definisi praktik pengukuran dalam organisasi yang dapat digunakan untuk memberikan visibilitas AWS penggunaan yang meningkatkan transparansi ke dalam akuntabilitas untuk pengeluaran. Ini juga berfokus pada menciptakan tingkat granularitas yang sesuai sehubungan dengan visibilitas biaya dan penggunaan dan mempengaruhi perilaku konsumsi cloud melalui pelaporan alokasi biaya dan pelacakan KPI. # Membangun strategi alokasi biaya ## Mendefinisikan dan menerapkan model alokasi biaya Buat struktur akun dan biaya untuk sumber daya yang digunakan. AWS Menetapkan hubungan antara biaya dari AWS pengeluaran, bagaimana biaya itu dikeluarkan, dan siapa atau apa yang mengeluarkan biaya tersebut. Struktur biaya umum didasarkan pada AWS Organizations, Akun AWS, lingkungan, dan entitas dalam organisasi Anda, seperti lini bisnis atau beban kerja. Struktur biaya dapat didasarkan pada beberapa atribut untuk memungkinkan pemeriksaan biaya dengan cara yang berbeda atau pada tingkat granularitas yang berbeda seperti menggulung biaya beban kerja individu ke lini bisnis yang mereka layani. Ketika memilih struktur biaya yang selaras dengan hasil yang diinginkan, evaluasi mekanisme alokasi biaya pada *kemudahan implementasi versus akurasi* *yang diinginkan*. Ini mungkin termasuk pertimbangan dalam hal akuntabilitas, ketersediaan perkakas, dan perubahan budaya. Tiga model alokasi biaya populer yang biasanya dimulai oleh AWS pelanggan adalah: + **Berbasis akun** — Model ini membutuhkan upaya paling sedikit dan memberikan akurasi tinggi untuk showback dan chargeback, dan cocok untuk organisasi yang memiliki struktur akun yang ditentukan (dan konsisten dengan rekomendasi dari whitepaper [Pengorganisasian AWS Lingkungan Anda Menggunakan](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) Beberapa Akun). Ini memberikan visibilitas biaya yang jelas berdasarkan per akun. Untuk visibilitas dan alokasi biaya, Anda dapat menggunakan [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html), [Laporan Biaya dan Penggunaan](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html), serta [AWS Anggaran](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) untuk pemantauan dan pelacakan biaya. Alat-alat ini menyediakan opsi penyaringan dan pengelompokan berdasarkan. Akun AWS Dari perspektif alokasi biaya, model ini tidak harus bergantung pada penandaan yang akurat dari sumber daya individu. + **Unit Bisnis atau Berbasis Tim** — Biaya yang dialokasikan untuk tim, unit bisnis, atau organisasi dalam suatu perusahaan. Model ini membutuhkan upaya yang moderat, memberikan akurasi tinggi untuk showback dan chargeback, dan cocok untuk organisasi yang memiliki struktur akun yang ditentukan (biasanya menggunakan AWS Organizations), dengan pemisahan antara berbagai tim, aplikasi, dan jenis beban kerja. Ini memberikan visibilitas biaya yang jelas di seluruh tim dan aplikasi, dan sebagai manfaat tambahan mengurangi risiko mencapai [kuota AWS layanan](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) dalam satu. Akun AWS Misalnya, setiap tim mungkin memiliki lima akun (`prod`,,`staging`,`test`,`sandbox`)`dev`, dan tidak ada dua tim dan aplikasi yang akan berbagi akun yang sama. Dengan struktur tersebut [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) kemudian akan menyediakan fungsionalitas untuk mengelompokkan akun atau tag lain (“meta-tagging”) ke dalam kategori, yang dapat dilacak dalam alat yang disebutkan dalam contoh sebelumnya. Penting untuk dicatat bahwa AWS Organizations memungkinkan penandaan akun dan unit organisasi (OUs), namun tag ini tidak akan berlaku untuk alokasi biaya dan pelaporan penagihan (yaitu, Anda tidak dapat mengelompokkan atau memfilter biaya Anda AWS Cost Explorer berdasarkan OU). AWS Cost Categories harus digunakan untuk tujuan ini. + **Berbasis Tag** — Model ini membutuhkan lebih banyak usaha dibandingkan dengan dua sebelumnya dan akan memberikan akurasi tinggi untuk showback dan chargeback tergantung pada persyaratan dan tujuan akhir. Meskipun kami sangat menyarankan agar Anda mengadopsi praktik yang diuraikan dalam [Mengatur AWS Lingkungan Anda Menggunakan beberapa akun](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) whitepaper, secara realistis pelanggan sering menemukan diri mereka dengan struktur akun campuran dan kompleks yang membutuhkan waktu untuk bermigrasi. Menerapkan strategi penandaan yang ketat dan efektif adalah kunci dalam skenario ini, diikuti dengan [mengaktifkan tag yang relevan untuk alokasi biaya](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) di konsol Billing and Cost Management ( AWS Organizations dalam, tag dapat diaktifkan untuk alokasi biaya hanya dari akun Management Payer). Setelah tag diaktifkan untuk alokasi biaya, maka alat untuk visibilitas biaya dan alokasi yang disebutkan dalam metode sebelumnya dapat digunakan untuk showback dan chargeback. Perhatikan bahwa tag alokasi biaya tidak retrospektif, dan hanya akan muncul di pelaporan penagihan dan alat pelacak biaya setelah diaktifkan untuk alokasi biaya. Untuk meringkas, jika Anda perlu melacak biaya berdasarkan unit bisnis, Anda dapat menggunakan [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) untuk mengelompokkan akun tertaut dalam AWS Organisasi yang sesuai dan melihat pengelompokan ini dalam laporan penagihan. Saat membuat akun terpisah untuk lingkungan produksi dan non-produksi, Anda juga dapat memfilter biaya yang terkait dengan lingkungan di alat seperti [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html), atau melacak biaya tersebut menggunakan [AWS Anggaran](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html). Terakhir, jika kasus penggunaan Anda memerlukan pelacakan biaya yang lebih terperinci, misalnya, berdasarkan beban kerja atau aplikasi individual, Anda dapat menandai sumber daya dalam akun tersebut, [mengaktifkan kunci tag tersebut untuk alokasi biaya](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) pada akun manajemen, dan kemudian memfilter biaya tersebut berdasarkan kunci tag di alat pelaporan penagihan. ## Menetapkan pelaporan biaya dan proses pemantauan Mulailah dengan mengidentifikasi jenis-jenis biaya yang penting bagi pemangku kepentingan internal (misalnya, pengeluaran harian, biaya berdasarkan akun, biaya oleh X, biaya diamortisasi). Dengan demikian, Anda dapat mengurangi risiko anggaran yang terkait dengan pengeluaran tak terduga atau anomali lebih cepat daripada menunggu faktur yang diselesaikan. AWS Tag menyediakan atribusi yang memungkinkan skenario pelaporan ini. Wawasan yang diperoleh dari pelaporan dapat menginformasikan tindakan Anda untuk mengurangi dampak dari pengeluaran anomali dan tak terduga pada anggaran keuangan. Ketika ada lonjakan biaya yang tidak terduga, penting untuk mengevaluasi apakah ada lonjakan tak terduga dalam nilai yang disampaikan sehingga Anda dapat menentukan apakah dan tindakan apa yang diperlukan. Saat mengembangkan strategi penandaan untuk mendukung alokasi biaya, ingatlah elemen-elemen berikut: + **AWS Organizations**- Alokasi biaya dalam beberapa akun dapat dilakukan oleh akun, grup akun, atau grup tag yang dibuat untuk sumber daya pada akun tersebut. Tag yang dibuat untuk sumber daya yang berada di akun individu AWS Organizations dapat digunakan untuk alokasi biaya hanya dari akun manajemen. + **AWS Akun** - Alokasi biaya dalam satu Akun AWS dapat dilakukan dengan dimensi tambahan seperti layanan atau wilayah. Dimungkinkan untuk menandai sumber daya lebih lanjut dalam akun dan bekerja dengan grup tag sumber daya tersebut. + Tag **Alokasi Biaya - Tag** buatan pengguna dan tag yang AWS dihasilkan dapat diaktifkan untuk alokasi biaya, jika perlu. Mengaktifkan tag untuk alokasi biaya di konsol penagihan (akun manajemen di AWS Organizations) membantu dengan showback dan chargeback. + **Cost Categories** - AWS Cost Categories memungkinkan pengelompokan akun dan pengelompokan tag (“meta-tagging”) dalam suatu AWS Organisasi, yang selanjutnya menyediakan kemampuan untuk menganalisis biaya yang terkait dengan kategori ini melalui alat seperti AWS Cost Explorer, AWS Anggaran dan Laporan Biaya dan Penggunaan. AWS ## Melakukan showback dan chargeback untuk unit bisnis, tim, atau organisasi dalam perusahaan Atribut biaya menggunakan proses alokasi biaya Anda didukung oleh struktur biaya dan tag alokasi biaya Anda. Tag dapat digunakan untuk memberikan showback kepada tim yang tidak secara langsung bertanggung jawab untuk membayar biaya tetapi bertanggung jawab atas biaya tersebut. Pendekatan ini memberikan kesadaran akan kontribusi mereka untuk dibelanjakan dan bagaimana biaya tersebut dikeluarkan. Lakukan tolak bayar kepada tim yang secara langsung bertanggung jawab atas biaya untuk memulihkan biaya sumber daya yang telah mereka konsumsi, dan untuk memberi mereka kesadaran akan biaya-biaya tersebut dan bagaimana biaya-biaya tersebut dikeluarkan. ## Mengukur dan mengedarkan kemampuan atau nilai KPIs Setujui serangkaian biaya unit atau metrik KPI untuk mengukur dampak investasi manajemen keuangan cloud Anda. Latihan ini menciptakan bahasa umum di seluruh pemangku kepentingan teknologi dan bisnis, dan menceritakan kisah berbasis sains, daripada cerita yang hanya berfokus pada pengeluaran agregat absolut. Untuk informasi tambahan, periksa blog ini yang membahas [bagaimana metrik unit dapat membantu menciptakan keselarasan antara fungsi bisnis](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metrics-help-create-alignment-between-business-functions/). ## Mengalokasikan pengeluaran yang tidak dapat dialokasikan Tergantung pada praktik akuntansi organisasi, jenis biaya yang berbeda mungkin memerlukan perlakuan yang berbeda. Identifikasi sumber daya atau kategori biaya yang tidak dapat ditandai. Bergantung pada layanan yang digunakan dan yang direncanakan untuk digunakan, sepakati mekanisme tentang cara memperlakukan dan mengukur pengeluaran yang tidak dapat dialokasikan tersebut. Misalnya, periksa daftar sumber daya yang didukung oleh [AWS Resource Groups dan Editor Tag](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html) di *Panduan Pengguna AWS Resource Groups dan Tag*. Contoh umum dari kategori biaya yang tidak dapat ditandai adalah beberapa biaya untuk diskon berbasis komitmen seperti Instans Cadangan (RI) dan Savings Plans (SP). Meskipun biaya berlangganan dan biaya SP dan RI yang tidak digunakan tidak dapat ditandai sebelum muncul di alat pelaporan penagihan, Anda dapat melacak bagaimana diskon RI dan SP berlaku untuk akun, sumber daya, dan tag mereka AWS Organizations setelah fakta. Misalnya, Anda dapat melihat biaya yang diamortisasi, kelompokkan yang dibelanjakan berdasarkan kunci tag yang relevan, dan terapkan filter yang relevan dengan kasus penggunaan Anda. AWS Cost Explorer Dalam Laporan AWS Biaya dan Penggunaan (CUR), Anda dapat memfilter baris yang sesuai dengan penggunaan yang dicakup oleh diskon RI dan SP (baca lebih lanjut di bagian kasus penggunaan [dokumentasi CUR](https://docs.aws.amazon.com/cur/latest/userguide/use-cases.html)) dan pilih kolom yang hanya relevan bagi Anda. Setiap kunci tag yang diaktifkan untuk alokasi biaya akan disajikan dalam kolom tersendiri di akhir laporan CUR, mirip dengan cara penyajiannya dalam laporan penagihan lama lainnya, seperti laporan alokasi [biaya bulanan](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html). Untuk referensi tambahan, periksa [AWS Well-Architected](https://www.wellarchitectedlabs.com/cost/300_labs/300_cur_queries/) Labs untuk contoh mendapatkan wawasan biaya dan penggunaan dari data CUR. ## Pelaporan Selain AWS alat yang tersedia untuk membantu showback dan chargeback, ada berbagai solusi AWS buatan dan pihak ketiga lainnya yang dapat membantu memantau biaya sumber daya yang ditandai, dan mengukur efektivitas strategi penandaan. Bergantung pada persyaratan dan tujuan akhir organisasi, seseorang dapat menginvestasikan waktu dan sumber daya untuk membangun solusi khusus atau membeli alat yang disediakan oleh salah satu [Mitra Kompetensi Alat AWS Cloud Manajemen](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). Jika Anda memutuskan untuk membuat alat alokasi biaya *kebenaran sumber tunggal* Anda sendiri dengan parameter terkontrol yang relevan untuk bisnis, Laporan AWS Biaya dan Penggunaan (CUR) menyediakan data biaya dan penggunaan yang paling rinci dan memungkinkan pembuatan dasbor pengoptimalan yang disesuaikan, memungkinkan pemfilteran dan pengelompokan berdasarkan akun, layanan, kategori biaya, tag alokasi biaya, dan beberapa dimensi lainnya. Di antara solusi berbasis CURE yang dikembangkan oleh AWS yang dapat digunakan sebagai salah satu alat ini, periksa [Cloud Intelligence Dashboards](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) di situs web Well-Architected AWS Labs. # Tag untuk operasi dan dukungan AWS Lingkungan akan memiliki banyak akun, sumber daya, dan beban kerja dengan persyaratan operasional yang berbeda. Tag dapat digunakan untuk memberikan konteks dan panduan untuk mendukung tim operasi untuk meningkatkan manajemen layanan Anda. Tag juga dapat digunakan untuk memberikan transparansi tata kelola operasional dari sumber daya yang dikelola. Beberapa faktor utama yang mendorong definisi tag operasional yang konsisten adalah: + **Untuk memfilter sumber daya selama aktivitas infrastruktur otomatis.** Misalnya, saat menerapkan, memperbarui, atau menghapus sumber daya. Lain adalah penskalaan sumber daya untuk optimalisasi biaya dan pengurangan penggunaan di luar jam. Lihat solusi [Penjadwal AWS Instance](https://aws.amazon.com/solutions/implementations/instance-scheduler/) untuk contoh kerja. + **Mengidentifikasi sumber daya yang terisolasi atau mencela.** Sumber daya yang telah melampaui umur yang ditentukan atau telah ditandai untuk diisolasi oleh mekanisme internal harus ditandai dengan tepat untuk membantu personel pendukung dalam penyelidikan mereka. Sumber daya yang tidak digunakan lagi harus ditandai sebelum isolasi, pengarsipan, dan penghapusan. + **Persyaratan Support untuk sekelompok sumber daya.** Sumber daya seringkali memiliki persyaratan dukungan yang berbeda, misalnya, persyaratan ini dapat dinegosiasikan antar tim atau ditetapkan sebagai bagian dari kekritisan aplikasi. Panduan lebih lanjut tentang model operasi dapat ditemukan di [Pilar Keunggulan Operasional](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html). + **Meningkatkan proses manajemen insiden.** Dengan menandai sumber daya dengan tag yang menawarkan transparansi yang lebih besar dalam proses manajemen insiden, tim pendukung dan insinyur serta tim Manajemen Insiden Utama (MIM) dapat mengelola acara secara lebih efektif. + **Cadangan.** Tag juga dapat digunakan untuk mengidentifikasi frekuensi sumber daya Anda perlu dicadangkan, dan ke mana salinan cadangan harus pergi atau ke mana harus memulihkan cadangan. [Panduan preskriptif untuk pendekatan Backup dan pemulihan](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/welcome.html) pada. AWS + **Menambal.** Menambal instance yang dapat berubah berjalan sangat AWS penting dalam strategi penambalan menyeluruh Anda dan untuk menambal kerentanan zero-day. Panduan yang lebih dalam tentang strategi penambalan yang lebih luas dapat ditemukan dalam panduan [preskriptif](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html). [Penambalan kerentanan zero-day dibahas di blog ini.](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/) + **Observabilitas operasional**. Memiliki strategi KPI operasional yang diterjemahkan ke tag sumber daya akan membantu tim operasi untuk melacak dengan lebih baik apakah target terpenuhi untuk meningkatkan persyaratan bisnis. Mengembangkan strategi KPI adalah topik yang terpisah, tetapi cenderung difokuskan pada bisnis yang beroperasi dalam keadaan mapan atau di mana mengukur dampak dan hasil perubahan. [Dashboard KPI](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/cost-usage-report-dashboards/dashboards/2c_kpi_dashboard/) (AWS Well-Architected labs) dan Operations KPI Workshop (layanan [proaktif Dukungan AWS Perusahaan](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)) keduanya mengukur kinerja dalam kondisi mapan. Artikel blog strategi AWS perusahaan [Mengukur Keberhasilan Transformasi Anda](https://aws.amazon.com/blogs/enterprise-strategy/measuring-the-success-of-your-transformation/), mengeksplorasi pengukuran KPI untuk program transformasi, seperti modernisasi TI atau migrasi dari tempat ke tempat. AWS # Kegiatan infrastruktur otomatis Tag dapat digunakan dalam berbagai aktivitas otomatisasi saat mengelola infrastruktur. Penggunaan [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/index.html), misalnya, akan memungkinkan Anda mengelola otomatisasi dan runbook pada sumber daya yang ditentukan oleh pasangan nilai kunci yang ditentukan yang Anda buat. Untuk node terkelola, Anda dapat menentukan satu set tag untuk melacak atau menargetkan node berdasarkan sistem operasi dan lingkungan. Anda kemudian dapat menjalankan skrip pembaruan untuk semua node dalam grup atau meninjau status node tersebut. [Sumber Daya Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/taggable-resources.html) juga dapat ditandai untuk lebih menyempurnakan dan melacak aktivitas otomatis Anda. Mengotomatiskan siklus hidup awal dan berhenti sumber daya lingkungan dapat memberikan pengurangan biaya yang signifikan bagi organisasi mana pun. [Penjadwal instans AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler/) aktif adalah contoh solusi yang dapat memulai dan menghentikan instans Amazon EC2 dan Amazon RDS saat tidak diperlukan. Misalnya, lingkungan pengembang yang menggunakan Amazon EC2 atau Amazon RDS instans yang tidak harus berjalan pada akhir pekan tidak menggunakan potensi penghematan biaya yang dapat ditawarkan oleh penutupan instans tersebut. Dengan menganalisis kebutuhan tim dan lingkungan mereka, dan menandai sumber daya ini dengan benar untuk mengotomatiskan manajemen mereka, Anda dapat memanfaatkan anggaran Anda secara efektif. *Contoh tag jadwal yang digunakan oleh penjadwal instans pada instans Amazon EC2:* ``` { "Tags": [ { "Key": "Schedule", "ResourceId": "i-1234567890abcdef8", "ResourceType": "instance", "Value": "mon-9am-fri-5pm" } ] } ``` # Siklus hidup beban kerja **Meninjau keakuratan data operasional pendukung.** Pastikan bahwa ada tinjauan berkala dari tag yang terkait dengan siklus hidup beban kerja Anda, dan bahwa pemangku kepentingan yang sesuai terlibat dalam ulasan ini. *Tabel 7 — Tinjau tag operasional sebagai bagian dari siklus hidup beban kerja* | Kasus Penggunaan | Tag Kunci | Dasar Pemikiran | Nilai contoh | | --- | --- | --- | --- | | Pemilik Akun | example-inc:account-owner:owner | Pemilik akun dan itu berisi sumber daya. | ops-center, dev-ops, app-team | | Ulasan Pemilik Akun | example-inc:account-owner:review | Tinjau detail kepemilikan akun yang mutakhir dan benar. | | | Pemilik Data | example-inc:data-owner:owner | Pemilik data dari akun yang berada di data. | bi-team, logistics, security | | Ulasan Pemilik Data | example-inc:data-owner:review | Tinjauan detail kepemilikan data yang mutakhir dan benar. | | ## Menetapkan tag untuk menangguhkan akun sebelum bermigrasi ke OU yang ditangguhkan Sebelum menangguhkan akun dan pindah ke OU yang ditangguhkan seperti yang dijelaskan dalam whitepaper [Mengatur AWS Lingkungan Anda Menggunakan Beberapa Akun](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html), tag harus ditambahkan ke akun untuk membantu penelusuran internal dan audit siklus hidup akun Anda. Misalnya, URL relatif atau referensi tiket pada sistem tiket ITSM organisasi, yang menunjukkan jejak audit untuk aplikasi yang ditangguhkan. *Tabel 8 - Tambahkan tag operasional saat siklus hidup beban kerja memasuki tahap baru* | Kasus Penggunaan | Tag Kunci | Dasar Pemikiran | Nilai contoh | | --- | --- | --- | --- | | Pemilik Akun | example-inc:account-owner:owner | Pemilik akun dan itu berisi sumber daya. | ops-center, dev-ops, app-team | | Pemilik Data | example-inc:data-owner:owner | Pemilik data dari akun yang berada di data. | bi-team, logistics, security | | Tanggal Ditangguhkan | example-inc:suspension:date | Tanggal akun ditangguhkan | | | Persetujuan untuk penangguhan | example-inc:suspension:approval | Tautan ke persetujuan penangguhan akun | workload/deprecation | # Manajemen insiden Tag dapat memainkan peran penting dalam semua fase manajemen insiden mulai dari pencatatan insiden, prioritas, investigasi, komunikasi, resolusi hingga penutupan. Tag dapat merinci di mana insiden harus dicatat, tim atau tim yang harus diberitahu tentang insiden tersebut, dan prioritas eskalasi yang ditentukan. Penting untuk diingat bahwa tag tidak dienkripsi, jadi pertimbangkan informasi apa yang Anda simpan di dalamnya. Juga, dalam organisasi, tim, dan jalur pelaporan, tanggung jawab berubah, jadi pertimbangkan untuk menyimpan tautan ke portal aman di mana informasi ini dapat dikelola dengan lebih efektif. Tag ini tidak harus eksklusif. Misalnya, ID aplikasi dapat digunakan untuk mencari jalur eskalasi di portal manajemen layanan TI. Pastikan jelas dalam definisi operasional Anda bahwa tag ini digunakan untuk berbagai tujuan. Tag persyaratan operasional dapat dirinci juga, untuk membantu manajer insiden dan personel operasi lebih menyempurnakan tujuan mereka dalam menanggapi insiden atau peristiwa. Tautan relatif (ke URL basis sistem pengetahuan) untuk [runbook dan buku](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.runbook.en.html) [pedoman](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.playbook.en.html) dapat dimasukkan sebagai tag untuk membantu tim yang merespons dalam mengidentifikasi proses, prosedur, dan dokumentasi yang sesuai. *Tabel 9 - Gunakan tag operasional untuk menginformasikan manajemen insiden* | Kasus Penggunaan | Tag Kunci | Dasar Pemikiran | Nilai contoh | | --- | --- | --- | --- | | Manajemen Insiden | example-inc:incident-management:escalationlog | Sistem yang digunakan oleh tim pendukung untuk mencatat insiden | jira, servicenow, zendesk | | Manajemen Insiden | example-inc:incident-management:escalationpath | Jalur eskalasi | ops-center, dev-ops, app-team | | Alokasi Biaya dan Manajemen Insiden | example-inc:cost-allocation:CostCenter | Pantau biaya berdasarkan pusat biaya. Ini adalah contoh tag penggunaan ganda di mana pusat biaya digunakan sebagai kode aplikasi untuk pencatatan insiden | 123-\$1 | | Jadwal Backup | example-inc:backup:schedule | Jadwal Backup Sumber Daya | Daily | | Playbook/Manajemen Insiden | example-inc:incident-management:playbook | Buku pedoman yang didokumentasikan | webapp/incident/playbook | # Menambal Organizations dapat mengotomatiskan strategi patching mereka untuk lingkungan komputasi yang dapat berubah dan menjaga instance yang dapat berubah sejalan dengan baseline patch yang ditentukan dari lingkungan aplikasi tersebut dengan menggunakan Systems Manager Patch Manager dan. AWS AWS Lambda**Strategi penandaan untuk instance yang dapat berubah dalam lingkungan ini dapat dikelola dengan menetapkan instance tersebut ke Grup **Patch** dan Windows Pemeliharaan.** Lihat contoh berikut untuk pemisahan Dev → Test → Prod. AWS panduan preskriptif tersedia untuk [manajemen tambalan instance yang bisa berubah](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html). *Tabel 10 - Tag operasional dapat spesifik lingkungan* | Pengembangan | Pementasan | Produksi | | --- | --- | --- | | 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab111",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#1 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab222",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab333",
"ResourceType": "instance",
"Value": "WEBAPP-DEV-AL2"
}
]
}
| 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab444",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#2 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab555",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab666",
"ResourceType": "instance",
"Value": "WEBAPP-TEST-AL2"
}
]
}
| 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab777",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#3 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab888",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab999",
"ResourceType": "instance",
"Value": "WEBAPP-PROD-AL2"
}
]
}
| Kerentanan zero-day juga dapat dikelola dengan memiliki tag yang ditentukan untuk melengkapi strategi patching Anda. Lihat [Hindari kerentanan zero-day dengan patch keamanan pada hari yang sama menggunakan Systems](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/) Manager untuk panduan terperinci. AWS # Observabilitas operasional Observabilitas diperlukan untuk mendapatkan wawasan yang dapat ditindaklanjuti tentang kinerja lingkungan Anda dan membantu Anda mendeteksi dan menyelidiki masalah. Ini juga memiliki tujuan sekunder yang memungkinkan Anda untuk menentukan dan mengukur indikator kinerja utama (KPIs) dan tujuan tingkat layanan (SLOs) seperti uptime. Bagi sebagian besar organisasi, operasi penting KPIs adalah mean time to detect (MTTD) dan mean time to recover (MTTR) dari suatu insiden. Sepanjang observabilitas, konteks penting, karena data dikumpulkan dan kemudian tag terkait dikumpulkan. Terlepas dari tingkat layanan, aplikasi, atau aplikasi yang Anda fokuskan, Anda dapat memfilter dan menganalisis untuk kumpulan data tertentu. Tag dapat digunakan untuk mengotomatiskan orientasi ke CloudWatch Alarm sehingga tim yang tepat dapat diperingatkan ketika ambang batas metrik tertentu dilanggar. Misalnya, kunci tag `example-inc:ops:alarm-tag` dan nilai di atasnya dapat menunjukkan pembuatan CloudWatch Alarm. Solusi yang menunjukkan hal ini dijelaskan dalam [Gunakan tag untuk membuat dan memelihara CloudWatch alarm Amazon untuk instans Amazon EC2](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/). Memiliki terlalu banyak alarm yang dikonfigurasi dapat dengan mudah membuat badai peringatan — ketika sejumlah besar alarm atau notifikasi dengan cepat membanjiri operator dan mengurangi efektivitas keseluruhan mereka sementara operator secara manual memprioritaskan dan memprioritaskan alarm individu. Konteks tambahan untuk alarm dapat disediakan dalam bentuk tag, yang berarti bahwa aturan dapat didefinisikan dalam Amazon EventBridge untuk membantu memastikan bahwa fokus diberikan pada masalah hulu daripada dependensi hilir. Peran operasi di samping DevOps sering diabaikan, tetapi bagi banyak organisasi, tim operasi pusat masih memberikan respons pertama yang kritis di luar jam kerja normal. (Rincian lebih lanjut dapat ditemukan tentang model ini di [whitepaper Operational Excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html).) [Tidak seperti DevOps tim yang memiliki beban kerja, mereka biasanya tidak memiliki kedalaman pengetahuan yang sama, sehingga konteks yang disediakan tag dalam dasbor dan peringatan, dapat mengarahkannya ke runbook yang benar untuk masalah ini, atau memulai runbook otomatis (lihat posting blog Mengotomatiskan Alarm Amazon dengan). CloudWatch AWS Systems Manager](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/) # Tag untuk keamanan data, manajemen risiko, dan kontrol akses Organizations memiliki berbagai kebutuhan dan kewajiban yang harus dipenuhi mengenai penanganan penyimpanan dan pemrosesan data yang tepat. Klasifikasi data merupakan prekursor penting untuk beberapa kasus penggunaan, seperti kontrol akses, retensi data, analisis data, dan kepatuhan. # Keamanan data dan manajemen risiko Dalam suatu AWS lingkungan, Anda mungkin akan memiliki akun dengan kepatuhan dan persyaratan keamanan yang berbeda. Misalnya, Anda mungkin memiliki kotak pasir pengembang, dan akun yang menghosting lingkungan produksi untuk beban kerja yang sangat diatur, seperti memproses pembayaran. Dengan mengisolasinya ke akun yang berbeda, Anda dapat [menerapkan kontrol keamanan yang berbeda](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#apply-distinct-security-controls-by-environment), [membatasi akses ke data sensitif](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data), dan mengurangi ruang lingkup audit untuk beban kerja yang diatur. Mengadopsi standar tunggal untuk semua beban kerja dapat menimbulkan tantangan. Meskipun banyak kontrol berlaku sama di seluruh lingkungan, beberapa kontrol berlebihan atau tidak relevan untuk akun yang tidak perlu memenuhi kerangka peraturan tertentu, dan akun di mana tidak ada data pribadi yang dapat diidentifikasi (misalnya, kotak pasir pengembang, atau akun pengembangan beban kerja). Hal ini biasanya mengarah pada temuan keamanan positif palsu yang harus diprioritaskan dan ditutup tanpa tindakan, yang membutuhkan upaya menjauh dari temuan yang harus diselidiki. *Tabel 11 — Contoh keamanan data dan tag manajemen risiko* | Kasus penggunaan | Tag Kunci | Dasar Pemikiran | Nilai contoh | | --- | --- | --- | --- | | Manajemen insiden | example-inc:incident- management:escalationlog | Sistem yang digunakan oleh tim pendukung untuk mencatat insiden | jira, servicenow, zendesk | | Manajemen insiden | example-inc:incident- management:escalationpath | Jalur eskalasi | ops-center, dev-ops, app-team | | Klasifikasi data | example-inc:data:classification | Klasifikasi data untuk kepatuhan dan tata kelola | Public, Private, Confidential, Restricted | | Kepatuhan | example-inc:compliance:framework | Mengidentifikasi kerangka kerja kepatuhan yang dikenakan beban kerja | PCI-DSS, HIPAA | Mengelola kontrol yang berbeda secara manual di seluruh AWS lingkungan memakan waktu dan rawan kesalahan. Langkah selanjutnya adalah mengotomatiskan penerapan kontrol keamanan yang sesuai, dan mengonfigurasi inspeksi sumber daya, berdasarkan klasifikasi akun itu. Dengan menerapkan tag ke akun dan sumber daya di dalamnya, penyebaran kontrol dapat diotomatisasi dan dikonfigurasi dengan tepat untuk beban kerja. **Contoh: ** Beban kerja mencakup bucket Amazon S3 dengan `example-inc:data:classification` tag dengan nilainya. `Private` AWS Config Aturan otomatisasi alat keamanan menerapkan`s3-bucket-public-read-prohibited`, yang memeriksa pengaturan Blokir Akses Publik Amazon S3 bucket, kebijakan bucket, dan daftar kontrol akses bucket (ACL), yang mengonfirmasi konfigurasi bucket sesuai untuk klasifikasi datanya. Untuk memastikan konten bucket konsisten dengan klasifikasi, [Amazon Macie dapat dikonfigurasi untuk memeriksa informasi identitas pribadi](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/) (PII). Blog [Menggunakan Amazon Macie untuk Memvalidasi Klasifikasi Data Bucket S3 mengeksplorasi pola](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/) ini secara lebih mendalam. Lingkungan peraturan tertentu, seperti asuransi dan perawatan kesehatan, mungkin tunduk pada kebijakan penyimpanan data wajib. Penyimpanan data menggunakan tag, dikombinasikan dengan kebijakan Siklus Hidup Amazon S3, dapat menjadi cara yang efektif dan sederhana untuk menjangkau transisi objek ke tingkat penyimpanan yang berbeda. Aturan Siklus Hidup Amazon S3 juga dapat digunakan untuk menghapus objek kedaluwarsa setelah periode penahanan wajib berakhir. Lihat [Sederhanakan siklus hidup data Anda dengan menggunakan tag objek dengan Siklus Hidup Amazon S3 untuk panduan mendalam tentang proses](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/) ini. Selain itu, ketika melakukan triaging atau menangani temuan keamanan, tag dapat memberikan penyelidik konteks penting yang membantu memenuhi syarat risiko, dan membantu dalam melibatkan tim yang sesuai untuk menyelidiki atau mengurangi temuan tersebut. # Tag untuk manajemen identitas dan kontrol akses Saat mengelola kontrol akses di seluruh AWS lingkungan dengan AWS IAM Identity Center, tag dapat mengaktifkan beberapa pola untuk penskalaan. Ada beberapa pola delegasi yang dapat diterapkan, beberapa didasarkan pada penandaan. Kami akan mengatasinya secara individual dan memberikan tautan ke bacaan lebih lanjut tentang masing-masing. # ABAC untuk sumber daya individu Pengguna IAM Identity Center dan peran IAM mendukung kontrol akses berbasis atribut (ABAC), yang memungkinkan Anda menentukan akses ke operasi dan sumber daya berdasarkan tag. ABAC membantu mengurangi kebutuhan untuk memperbarui kebijakan izin dan membantu Anda mendasarkan akses dari atribut karyawan dari direktori perusahaan Anda. Jika Anda sudah menggunakan strategi multi-akun, ABAC dapat digunakan selain kontrol akses berbasis peran (RBAC) untuk menyediakan beberapa tim yang beroperasi di akun yang sama akses granular ke sumber daya yang berbeda. Misalnya, pengguna IAM Identity Center atau peran IAM dapat menyertakan kondisi untuk membatasi akses ke instans Amazon EC2 tertentu yang jika tidak harus dicantumkan secara eksplisit di setiap kebijakan untuk mengaksesnya. Karena model otorisasi ABAC bergantung pada tag untuk akses ke operasi dan sumber daya, penting untuk menyediakan pagar pembatas untuk mencegah akses yang tidak diinginkan. SCPs dapat digunakan untuk melindungi tag di seluruh organisasi Anda dengan hanya mengizinkan tag dimodifikasi dalam kondisi tertentu. Blog [Mengamankan tag sumber daya yang digunakan untuk otorisasi menggunakan kebijakan kontrol layanan di AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) dan [batas Izin untuk entitas IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) memberikan informasi tentang cara menerapkan ini. Jika instans Amazon EC2 berumur panjang digunakan untuk mendukung praktik operasi yang lebih tradisional maka pendekatan ini dapat digunakan, [blog Konfigurasikan IAM Identity Center ABAC untuk instans Amazon EC2 dan Systems Manager Session Manager](https://aws.amazon.com/blogs/security/configure-aws-sso-abac-for-ec2-instances-and-systems-manager-session-manager/) membahas bentuk kontrol akses berbasis atribut ini secara lebih rinci. Seperti disebutkan sebelumnya, tidak semua jenis sumber daya mendukung penandaan, dan yang melakukannya, tidak semua mendukung penegakan menggunakan kebijakan tag, jadi sebaiknya evaluasi ini sebelum mulai menerapkan strategi ini pada file Akun AWS. Untuk mempelajari tentang layanan yang mendukung ABAC, lihat [AWS layanan yang bekerja dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).