Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
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 integrasi berkelanjutan/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. Seringkali, ini adalah beban kerja statis sederhana yang telah dibangun menggunakan prosedur tertulis tradisional atau yang dimigrasi seperti menggunakan alat seperti CloudEndure dari lingkungan lokal. Alat migrasi, seperti Migration Hub dan CloudEndure, 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 (fitur dari AWS Management Console) 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. Template peluncuran Amazon EC2 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
TagPropertyperlu diatur dalam definisi grup Auto Scaling di template Anda. AWS CloudFormation Atau, jika Anda menggunakan Template Peluncuran EC2 dengan grup Auto Scaling maka Anda dapat menentukan tag dalam definisinya. Dianjurkan untuk menggunakan Template Peluncuran EC2 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
AWS CloudFormation Hooks
AWS CloudFormation menyediakan kemampuan untuk mendeteksi ketika sumber daya (lihat Sumber daya yang mendukung deteksi drift) 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)
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.0AWS::AutoScaling::AutoScalingGroup
TagPropertydigunakan.
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'] <<Tag must have a permitted value Tag must have PropagateAtLaunch set to 'true'>> } } 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-/ <<Tag must have a permitted value Tag must have PropagateAtLaunch set to 'true'>> } }
Dalam contoh kode, kami memfilter template untuk semua sumber daya yang berjenisAutoScalingGroup
, dan kemudian memiliki dua aturan:
-
tags_asg_automation_EnvironmentId
- Memeriksa bahwa tag dengan kunci ini ada, memiliki nilai dalam daftar nilai yang diizinkan, danPropagateAtLaunch
itu diatur ketrue
-
tags_asg_costAllocation_CostCenter
- Memeriksa bahwa tag ada dengan kunci ini, memiliki nilai yang dimulai dengan nilai awalan yang ditentukan, dan yangPropagateAtLaunch
diatur ketrue
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 diterapkan pada OU 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.
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 untuk daftar.
ExampleInc-Alokasi biaya.json
Berikut ini adalah contoh kebijakan tag yang melaporkan dan/atau 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). 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_tags). 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 (SCP) adalah jenis kebijakan organisasi yang dapat Anda gunakan untuk mengelola izin di organisasi Anda. SCP menawarkan kontrol pusat atas izin maksimum yang tersedia untuk semua akun di organisasi atau unit organisasi (OU) Anda. SCP hanya memengaruhi 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, SCP dapat memberikan perincian tambahan untuk penegakan tag serta kebijakan tag apa yang dapat disediakan.
Dalam contoh berikut, kebijakan akan menolak ec2:RunInstances
permintaan di mana example-inc:cost-allocation:CostCenter
tag tidak ada.
Berikut ini adalah penolakan SCP:
{ "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 dengan SCP, 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.