Strategi Tagging AWS 2026: Panduan FinO…

Q: Berapa maksimal tag yang bisa ditempel per resource AWS?

Sebagian besar service AWS mengizinkan hingga 50 tag per resource dengan key maksimal 128 karakter dan value maksimal 256 karakter. Batas ini cukup untuk pola tujuh tag inti plus tag operasional tambahan seperti backup schedule dan compliance flag.

Diperbarui: 13 Agustus 2026

Strategi tagging AWS untuk cost allocation adalah kombinasi tag key/value yang konsisten di seluruh account, aktivasi tag sebagai cost allocation tag di Billing console, dan enforcement lewat Tag Policies di AWS Organizations agar setiap dollar di Cost and Usage Report (CUR) bisa dikaitkan ke owner, environment, dan cost center yang jelas. Tanpa strategi yang ditulis dan dienforce, laporan biaya multi-account cepat berubah jadi tumpukan resource "untagged" yang tidak bisa di-chargeback. Panduan ini menuntun saya (dan Anda) dari nol sampai tag governance yang siap audit.

AWS punya dua jenis tag untuk billing: AWS-generated (prefix aws:) dan user-defined. Keduanya harus diaktifkan manual di Billing console sebelum muncul sebagai kolom di Cost Explorer atau CUR.
Tag butuh waktu hingga 24 jam untuk mulai terlihat di data biaya setelah diaktifkan, dan tidak backfill secara retroaktif ke periode sebelum aktivasi.
Di lingkungan multi-account, Tag Policies dari AWS Organizations menjaga konsistensi case dan value yang diizinkan, sementara Service Control Policies (SCP) memblokir pembuatan resource yang tidak sesuai skema tag.
Kombinasikan cost allocation tag dengan Cost Categories untuk mengelompokkan biaya lintas account/service tanpa mengubah tag di resource itu sendiri.
Standarisasi ke FOCUS 1.0 saat mengekspor CUR ke data warehouse agar tag Anda kompatibel dengan tooling FinOps multi-cloud.

Apa itu cost allocation tag di AWS?

Cost allocation tag adalah tag biasa di resource AWS (EC2, S3 bucket, Lambda function, dsb.) yang secara eksplisit Anda "aktifkan" untuk masuk ke laporan biaya. AWS memisahkan tag jadi dua kategori: AWS-generated tag (otomatis diterapkan oleh service seperti aws:createdBy, aws:cloudformation:stack-name, atau aws:autoscaling:groupName) dan user-defined tag yang Anda tempel sendiri lewat Console, CLI, Terraform, atau CloudFormation.

Kedua jenis tag ini tidak otomatis muncul sebagai dimensi di Cost Explorer atau CUR. Anda harus masuk ke Billing and Cost Management → Cost allocation tags di management account dan mengklik "Activate" untuk setiap key yang ingin dipakai untuk allocation. Setelah diaktifkan, AWS butuh sekitar 24 jam untuk memproses dan tag baru mulai terlihat sebagai kolom filter. Dokumentasi resminya bisa dibaca di panduan cost allocation tags AWS.

Yang sering bikin frustrasi: aktivasi tidak bersifat retroaktif. Kalau Anda menempel tag CostCenter di 1.000 EC2 minggu lalu tapi baru mengaktifkannya hari ini, biaya minggu lalu tetap muncul sebagai (untagged). Karena itu langkah pertama saya di setiap engagement multi-account adalah audit tag mana saja yang sudah dipakai, aktifkan semua kandidat cost allocation tag sebelum tim mulai menempel tag baru, dan biarkan clock 24 jam berjalan.

Skema tag minimum yang saya rekomendasikan

Setelah sekian setup multi-account (dari 3 sampai 400+ account), pola yang paling sering saya pakai adalah "tujuh tag inti". Cukup untuk 90% pertanyaan chargeback, tidak berlebihan sampai tim engineering ogah menempel tag. Semua key saya tulis PascalCase tanpa spasi — kompatibel dengan Athena query dan mudah dibaca di CSV.

Tag Key	Contoh Value	Wajib?	Fungsi utama
`CostCenter`	`CC-1042`	Ya	Chargeback ke unit bisnis / GL code finance
`Environment`	`prod`, `staging`, `dev`	Ya	Pemisahan lifecycle & anggaran per environment
`Owner`	`team-payments`	Ya	Kontak eskalasi & showback tim
`Project`	`checkout-v3`	Ya	Attribusi ke inisiatif / feature
`Application`	`orders-api`	Ya	Grouping resource satu service
`DataClassification`	`pii`, `internal`, `public`	Opsional	Compliance + billing per tier keamanan
`ManagedBy`	`terraform`, `cdk`, `console`	Opsional	Deteksi resource "kabur" dari IaC

Nilai ManagedBy terdengar sepele tapi menyelamatkan saya berkali-kali: begitu Anda bisa memfilter biaya berdasarkan resource yang di-provision lewat console (bukan IaC), Anda punya daftar target audit yang jelas. Untuk pengelolaan biaya di container, saya sarankan juga menempel label yang sama di Kubernetes lewat panduan optimasi biaya Kubernetes agar CUR dan Kubecost bicara bahasa yang sama.

Cara mengaktifkan cost allocation tag di Billing console

Aktivasi hanya bisa dilakukan dari management account di AWS Organizations, tidak dari member account. Dari console: Billing and Cost Management → Cost allocation tags → User-defined cost allocation tags. Pilih semua key yang sudah dipakai atau yang direncanakan (termasuk yang belum menempel di resource, supaya begitu tag muncul, langsung tercatat). Klik Activate.

Untuk automasi (dan supaya Terraform Anda menjadi single source of truth), gunakan CLI. Contoh script yang saya jalankan sebagai bagian dari account baseline:

# Aktifkan tujuh tag inti di management account
# Butuh permission ce:UpdateCostAllocationTagsStatus
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status '[
    {"TagKey":"CostCenter","Status":"Active"},
    {"TagKey":"Environment","Status":"Active"},
    {"TagKey":"Owner","Status":"Active"},
    {"TagKey":"Project","Status":"Active"},
    {"TagKey":"Application","Status":"Active"},
    {"TagKey":"DataClassification","Status":"Active"},
    {"TagKey":"ManagedBy","Status":"Active"}
  ]' \
  --region us-east-1

# Verifikasi status
aws ce list-cost-allocation-tags --status Active --region us-east-1 \
  --query 'CostAllocationTags[].TagKey' --output table

Jangan lupa juga mengaktifkan AWS-generated tag yang relevan: aws:createdBy (siapa yang provision), aws:cloudformation:stack-name, dan untuk EKS aws:eks:cluster-name. Setelah 24 jam, buka Cost Explorer dan buat report yang di-group by Tag: Environment. Kalau nilai (no tag) masih dominan, itu petunjuk bahwa Anda perlu enforcement yang lebih agresif, bukan sekadar dokumentasi Confluence.

Tag Policies di AWS Organizations untuk multi-account

Tag Policies adalah tipe policy di AWS Organizations yang mendefinisikan skema tag: key mana yang wajib, case apa yang harus digunakan, dan value apa saja yang diizinkan. Tag Policies tidak memblokir pembuatan resource yang melanggar (itu tugas SCP), tapi mereka menandai resource sebagai non-compliant di Resource Groups dan bisa memaksa case yang benar saat tag ditulis lewat operasi yang tag-on-create aware.

Sebelum bisa memakai Tag Policies, aktifkan dulu di management account:

# Aktifkan Tag policy type untuk seluruh Organization
aws organizations enable-policy-type \
  --root-id r-xxxx \
  --policy-type TAG_POLICY

Berikut Tag Policy minimal yang saya pakai di semua engagement. Perhatikan @@assign (nilai wajib), @@append (menambah dari policy induk), dan enforced_for (service yang benar-benar akan menolak operasi non-compliant):

{
  "tags": {
    "CostCenter": {
      "tag_key": { "@@assign": "CostCenter" },
      "tag_value": {
        "@@assign": ["CC-1042", "CC-2088", "CC-3021", "CC-9000"]
      },
      "enforced_for": {
        "@@assign": ["ec2:instance", "ec2:volume", "rds:db", "s3:bucket"]
      }
    },
    "Environment": {
      "tag_key": { "@@assign": "Environment" },
      "tag_value": { "@@assign": ["prod", "staging", "dev", "sandbox"] },
      "enforced_for": {
        "@@assign": ["ec2:instance", "rds:db", "lambda:function"]
      }
    },
    "Owner": {
      "tag_key": { "@@assign": "Owner" }
    }
  }
}

Attach policy ini ke root, ke OU per lingkungan (prod/non-prod), atau ke account tertentu. Kombinasi inheritance dari Tag Policies dan Cost Categories adalah cara paling bersih untuk mereplikasi struktur organisasi finance ke dalam data biaya AWS. Detail syntax dan operator lengkap ada di dokumentasi Tag Policies AWS Organizations.

Enforcement lewat SCP dan AWS Config

Tag Policies memberi tahu Anda tentang non-compliance; SCP dan AWS Config mencegah dan memperbaiki. Saya biasanya deploy tiga lapis:

1. SCP yang menolak resource tanpa tag wajib

SCP di bawah ini menolak RunInstances dan CreateVolume kalau tag CostCenter atau Environment tidak disertakan pada saat create. Karena SCP dieksekusi di IAM authorization layer, resource yang melanggar tidak pernah dibuat sama sekali, bukan sekadar ditandai belakangan.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyRunInstancesWithoutRequiredTags",
    "Effect": "Deny",
    "Action": ["ec2:RunInstances", "ec2:CreateVolume"],
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "Null": {
        "aws:RequestTag/CostCenter": "true",
        "aws:RequestTag/Environment": "true"
      }
    }
  }]
}

2. AWS Config rule untuk deteksi drift

Untuk resource yang tidak bisa Anda cegat via SCP (misalnya Lambda function yang di-update lewat CodeDeploy), pakai managed rule required-tags:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "required-tags-prod",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "REQUIRED_TAGS"
  },
  "InputParameters": "{\"tag1Key\":\"CostCenter\",\"tag2Key\":\"Environment\",\"tag3Key\":\"Owner\"}",
  "Scope": {
    "ComplianceResourceTypes": [
      "AWS::EC2::Instance", "AWS::RDS::DBInstance",
      "AWS::S3::Bucket", "AWS::Lambda::Function"
    ]
  }
}'

3. Auto-remediation via SSM Automation

Kalau Anda tidak ingin sekadar melaporkan drift, pasangkan Config rule dengan SSM Automation document AWS-SetRequiredTags, atau tulis Lambda kecil yang menempel tag default (CostCenter=UNASSIGNED) sekaligus memicu ticket di ITSM Anda. Prinsipnya: resource selalu punya tag, meskipun awalnya tag "tidak tahu siapa yang punya". Yang jelas, jauh lebih mudah dilacak daripada resource benar-benar tanpa tag.

Cost Categories: ketika tag tidak cukup

Tag hidup di level resource. Kadang Anda butuh mengelompokkan biaya lintas account, service, atau bahkan tag itu sendiri, misalnya "semua biaya prod, tidak peduli apakah di account A, B, atau C". Untuk itu ada AWS Cost Categories: aturan berbasis expression yang menciptakan dimensi baru di Cost Explorer dan CUR.

Contoh kategori "BusinessUnit" yang meng-map beberapa cost center + linked account ke unit bisnis:

aws ce create-cost-category-definition \
  --name "BusinessUnit" \
  --rule-version "CostCategoryExpression.v1" \
  --rules '[
    {
      "Value": "Payments",
      "Rule": {
        "Or": [
          {"Tags": {"Key":"CostCenter","Values":["CC-1042","CC-1043"]}},
          {"Dimensions": {"Key":"LINKED_ACCOUNT","Values":["111122223333"]}}
        ]
      }
    },
    {
      "Value": "Marketing",
      "Rule": {"Tags": {"Key":"CostCenter","Values":["CC-9000"]}}
    }
  ]' \
  --default-value "Unallocated"

Cost Categories dievaluasi retroaktif hingga 12 bulan ke belakang, berbeda dengan cost allocation tag yang tidak backfill. Karena itu Cost Categories adalah cara terbaik untuk "memperbaiki" data historis tanpa harus menempel tag ke resource yang mungkin sudah tidak ada. Ini juga cocok dipadukan dengan strategi Savings Plans vs Reserved Instances, di mana Anda bisa membuat kategori "CommittedSpend" untuk memisahkan usage yang tercover commitment dari on-demand.

Integrasi ke CUR 2.0 dan FOCUS 1.0

Untuk analitik serius, Cost Explorer selalu terlalu ringkas. Ekspor Cost and Usage Report (CUR 2.0) ke S3, catalog via Glue, lalu query dari Athena atau Redshift. Setiap cost allocation tag yang aktif menjadi kolom bernama resource_tags_user_<tagkey>. AWS-generated tag muncul dengan prefix resource_tags_aws_.

-- Athena: total biaya per CostCenter untuk bulan Juli 2026
SELECT
  resource_tags_user_cost_center AS cost_center,
  resource_tags_user_environment AS environment,
  ROUND(SUM(line_item_unblended_cost), 2) AS cost_usd
FROM my_cur_database.cur2_daily
WHERE line_item_usage_start_date >= DATE '2026-07-01'
  AND line_item_usage_start_date <  DATE '2026-08-01'
  AND line_item_line_item_type = 'Usage'
GROUP BY 1, 2
ORDER BY cost_usd DESC;

Jika Anda beroperasi multi-cloud atau menggunakan tooling FinOps yang mengharapkan skema terstandar, ekspor CUR ke format FOCUS 1.0, spesifikasi terbuka yang menormalisasi kolom biaya lintas AWS, Azure, dan GCP. Kolom seperti BilledCost, EffectiveCost, Tags, dan SubAccountId jadi konsisten, sehingga dashboard Kubecost, CloudZero, atau custom Grafana Anda tidak perlu punya adapter per provider. Detail spesifikasi dan panduan adopsi tersedia di situs FOCUS FinOps Foundation.

Kesalahan umum dan bagaimana menghindarinya

Dari review governance tag di puluhan organisasi, ini pola kegagalan yang paling sering saya lihat:

Menempel tag setelah aktivasi, bukan sebelumnya. Karena tag tidak backfill, biaya di periode "tag menempel tapi belum diaktifkan" hilang selamanya dari allocation report. Aktifkan dulu, tempel belakangan.
Case yang tidak konsisten. Environment=Prod, environment=prod, dan ENV=PROD menghasilkan tiga baris berbeda. Pilih satu konvensi (saya suka PascalCase key + lowercase value) dan enforcement lewat Tag Policies.
Terlalu banyak tag "wajib". Setiap tag wajib adalah friction bagi developer. Mulai dengan 3–5 tag inti dan tambahkan hanya ketika pertanyaan bisnis konkret muncul.
Tidak menempel tag di resource "tidak terlihat" seperti EBS snapshot, unused Elastic IP, atau NAT Gateway. Justru resource ini yang paling sering jadi biaya tak terjelaskan.
Tag hanya di IaC, bukan di runtime. Auto Scaling Group yang menempel tag hanya saat launch tidak menutupi resource turunan seperti Volume atau Network Interface. Pakai Propagate at launch di ASG dan PropagateTagsToVolumeOnCreation di launch template.
Tidak me-review tag secara berkala. Tag [email protected] yang dibuat 2 tahun lalu mungkin merujuk ke orang yang sudah keluar. Jadwalkan quarterly review dan pakai laporan Untagged & Stale Owner sebagai KPI FinOps.

Pertanyaan yang Sering Diajukan

Berapa lama cost allocation tag mulai terlihat di Cost Explorer?

Sekitar 24 jam setelah Anda mengaktifkan tag key di halaman Billing → Cost allocation tags. Data biaya sebelum aktivasi tidak akan diisi ulang secara retroaktif, jadi selalu aktifkan tag sedini mungkin, bahkan sebelum tag benar-benar menempel di resource.

Apakah AWS-generated tag dan user-defined tag sama-sama bisa dipakai untuk allocation?

Ya, keduanya bisa diaktifkan sebagai cost allocation tag. AWS-generated tag (prefix aws:) berguna karena otomatis diterapkan oleh service seperti CloudFormation, Auto Scaling, dan EKS, tapi jangkauannya terbatas. Untuk allocation berbasis bisnis (cost center, project, owner), user-defined tag tetap wajib.

Berapa maksimal tag yang bisa ditempel per resource AWS?

Sebagian besar service AWS mengizinkan hingga 50 tag per resource dengan key maksimal 128 karakter dan value maksimal 256 karakter. Batas ini cukup untuk pola tujuh tag inti plus tag operasional tambahan seperti backup schedule dan compliance flag.

Bagaimana cara mencegah resource dibuat tanpa tag wajib?

Gunakan Service Control Policy (SCP) di AWS Organizations dengan kondisi aws:RequestTag/<Key> pada action seperti ec2:RunInstances. SCP dieksekusi di IAM authorization layer, sehingga permintaan create tanpa tag wajib akan langsung ditolak sebelum resource dibuat.

Apa bedanya Tag Policies dan Cost Categories?

Tag Policies mendefinisikan skema tag (key, case, dan value yang diizinkan) dan hidup di level resource. Cost Categories menciptakan dimensi bisnis baru di Cost Explorer/CUR dengan menggabungkan tag, linked account, dan service, tanpa mengubah tag di resource itu sendiri, dan bisa dievaluasi retroaktif hingga 12 bulan.

Apakah tag berpengaruh ke harga resource AWS?

Tidak. Tag itu sendiri gratis dan tidak menambah biaya storage, request, atau egress. Yang berbayar adalah layanan analitiknya: menyimpan CUR di S3 (biaya storage kecil), query dari Athena (per TB scanned), dan Cost Explorer API call di luar tier gratis (US$0.01 per request).

Apa itu cost allocation tag di AWS?

Skema tag minimum yang saya rekomendasikan

Cara mengaktifkan cost allocation tag di Billing console

Tag Policies di AWS Organizations untuk multi-account

Enforcement lewat SCP dan AWS Config

1. SCP yang menolak resource tanpa tag wajib

2. AWS Config rule untuk deteksi drift

3. Auto-remediation via SSM Automation

Cost Categories: ketika tag tidak cukup

Integrasi ke CUR 2.0 dan FOCUS 1.0

Kesalahan umum dan bagaimana menghindarinya

Pertanyaan yang Sering Diajukan

Berapa lama cost allocation tag mulai terlihat di Cost Explorer?

Apakah AWS-generated tag dan user-defined tag sama-sama bisa dipakai untuk allocation?

Berapa maksimal tag yang bisa ditempel per resource AWS?

Bagaimana cara mencegah resource dibuat tanpa tag wajib?

Apa bedanya Tag Policies dan Cost Categories?

Apakah tag berpengaruh ke harga resource AWS?

Artikel Terkait

Optimasi Biaya AWS Lambda 2026: Memory Tuning, Graviton ARM64 & SnapStart

Cara Mengurangi Biaya NAT Gateway AWS 2026: VPC Endpoint, NAT Instance & Centralized Egress

Optimasi Biaya AWS S3 2026: Panduan Lifecycle, Storage Class & Intelligent-Tiering