Memperbarui Konten CloudFront: Cara Membuat Invalidasi Cache untuk Menampilkan File Terbaru dari S3

Kamu sudah mengganti file di S3, tapi CloudFront masih melayani versi lama ke pengguna — ini adalah salah satu skenario paling umum yang membuat engineer frustrasi saat pertama kali bekerja dengan CloudFront. Masalahnya bukan di S3, melainkan di edge cache CloudFront yang menyimpan salinan file lama hingga TTL habis. Artikel ini menjelaskan cara membuat CloudFront Invalidation untuk memaksa edge location membuang cache dan mengambil versi terbaru dari origin.

TL;DR: Invalidasi Cache CloudFront

SituasiSolusi
File lama masih muncul setelah update S3Buat invalidasi dengan path file spesifik
Seluruh situs perlu di-refresh sekaligusGunakan wildcard path /*
Ingin otomatis invalidasi setiap deployIntegrasikan CLI invalidasi ke pipeline CI/CD
Ingin menghindari biaya invalidasi berulangGunakan versioning file (cache busting)

Bagaimana CloudFront Cache Bekerja

CloudFront beroperasi sebagai jaringan CDN berlapis. Ketika pengguna meminta sebuah file, permintaan diarahkan ke edge location terdekat. Jika edge location memiliki salinan file yang masih valid (belum melewati TTL), file tersebut dikembalikan langsung tanpa menyentuh origin S3. Inilah yang menyebabkan file lama tetap muncul meskipun kamu sudah mengganti isinya di S3.

TTL default dikontrol oleh header Cache-Control dari origin, atau oleh pengaturan Default TTL di behavior CloudFront. Tanpa invalidasi, edge location baru akan mengambil versi terbaru hanya setelah TTL habis — yang bisa berlangsung berjam-jam.

graph LR User["Pengguna"] --> Edge["Edge Location
CloudFront"] Edge -- "Cache HIT
(TTL masih valid)" --> User Edge -- "Cache MISS atau
Sudah Diinvalidasi" --> S3["Amazon S3
(Origin)"] S3 -- "Versi Terbaru" --> Edge Edge -- "Simpan cache baru
+ kirim ke pengguna" --> User
  1. Request pengguna masuk ke edge location CloudFront terdekat.
  2. Cache HIT: Edge location memiliki salinan valid → langsung dikembalikan, S3 tidak disentuh.
  3. Cache MISS / Invalidated: Edge location tidak punya salinan atau cache sudah diinvalidasi → permintaan diteruskan ke S3 sebagai origin.
  4. S3 mengembalikan versi terbaru → edge location menyimpan salinan baru → dikirim ke pengguna.

Cara Membuat Invalidasi CloudFront via AWS Console

Langkah paling cepat untuk membersihkan cache edge secara manual adalah melalui AWS Management Console. Ini berguna untuk invalidasi satu kali atau saat debugging.

  1. Buka CloudFront di AWS Console, pilih distribusi yang relevan.
  2. Klik tab Invalidations, lalu klik Create invalidation.
  3. Masukkan path file yang ingin diinvalidasi. Contoh:
    • /images/logo.png — invalidasi satu file spesifik
    • /assets/* — invalidasi semua file dalam folder assets
    • /* — invalidasi seluruh distribusi
  4. Klik Create invalidation. Status akan berubah dari In Progress ke Completed dalam beberapa menit.
Invalidasi bukan operasi instan di semua edge location secara bersamaan. CloudFront menyebarkan instruksi invalidasi ke seluruh jaringan edge secara bertahap — dalam kondisi normal selesai dalam 1-2 menit, tapi bisa lebih lama tergantung jumlah edge location yang terlibat.

Membuat Invalidasi CloudFront via AWS CLI

Untuk kebutuhan otomasi atau pipeline deployment, CLI adalah cara yang tepat. Kamu perlu distribution-id dari distribusi CloudFront dan menentukan path yang akan diinvalidasi.

Langkah 1: Temukan Distribution ID

Sebelum membuat invalidasi, pastikan kamu menggunakan Distribution ID yang benar — bukan domain name. Kesalahan ini sering terjadi karena keduanya terlihat mirip di console.

aws cloudfront list-distributions \
  --query "DistributionList.Items[*].{ID:Id,Domain:DomainName,Status:Status}" \
  --output table

Catat nilai kolom ID (format: E1EXAMPLE12345) untuk distribusi yang ingin kamu invalidasi.

Langkah 2: Buat Invalidasi untuk File Spesifik

Gunakan perintah berikut untuk menginvalidasi satu atau beberapa file. Parameter --invalidation-batch membutuhkan Paths dan CallerReference — nilai CallerReference harus unik untuk setiap request invalidasi.

aws cloudfront create-invalidation \
  --distribution-id E1EXAMPLE12345 \
  --paths "/images/logo.png" "/css/style.css"

Langkah 3: Invalidasi Seluruh Distribusi (Wildcard)

Jika kamu baru saja melakukan full deployment dan perlu membersihkan semua cache sekaligus, gunakan wildcard. Perhatikan bahwa setiap path wildcard dihitung sebagai satu invalidasi path untuk tujuan kuota.

aws cloudfront create-invalidation \
  --distribution-id E1EXAMPLE12345 \
  --paths "/*"

Langkah 4: Cek Status Invalidasi

Invalidasi tidak selesai secara instan. Gunakan perintah berikut untuk memantau status — tunggu hingga status berubah menjadi Completed sebelum memverifikasi konten di browser.

aws cloudfront list-invalidations \
  --distribution-id E1EXAMPLE12345 \
  --query "InvalidationList.Items[*].{ID:Id,Status:Status,CreateTime:CreateTime}" \
  --output table

IAM Permission yang Diperlukan untuk Invalidasi

Jika kamu menjalankan invalidasi dari pipeline CI/CD atau role IAM tertentu, pastikan policy berikut sudah diberikan. Tanpa permission cloudfront:CreateInvalidation, perintah CLI akan gagal dengan error AccessDenied.

🔽 Klik untuk melihat IAM Policy 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudfrontInvalidation",
      "Effect": "Allow",
      "Action": [
        "cloudfront:CreateInvalidation",
        "cloudfront:GetInvalidation",
        "cloudfront:ListInvalidations"
      ],
      "Resource": "arn:aws:cloudfront::123456789012:distribution/E1EXAMPLE12345"
    },
    {
      "Sid": "AllowListDistributions",
      "Effect": "Allow",
      "Action": [
        "cloudfront:ListDistributions"
      ],
      "Resource": "*"
    }
  ]
}

Perhatikan bahwa cloudfront:ListDistributions memerlukan "Resource": "*" karena aksi List tidak mendukung resource-level restriction. Selalu verifikasi di AWS Service Authorization Reference sebelum mempersempit scope resource.

Invalidasi Otomatis dalam Pipeline CI/CD

Menjalankan invalidasi secara manual setelah setiap deploy adalah resep untuk lupa. Integrasikan langkah ini langsung ke pipeline deployment kamu.

Contoh script shell sederhana yang bisa dimasukkan sebagai langkah post-deploy:

#!/bin/bash
DISTRIBUTION_ID="E1EXAMPLE12345"

# Upload file baru ke S3
aws s3 sync ./dist s3://nama-bucket-kamu/ --delete

# Invalidasi cache CloudFront setelah upload selesai
INVALIDATION_ID=$(aws cloudfront create-invalidation \
  --distribution-id "$DISTRIBUTION_ID" \
  --paths "/*" \
  --query "Invalidation.Id" \
  --output text)

echo "Invalidation dibuat: $INVALIDATION_ID"

# Tunggu hingga invalidasi selesai
aws cloudfront wait invalidation-completed \
  --distribution-id "$DISTRIBUTION_ID" \
  --id "$INVALIDATION_ID"

echo "Cache berhasil dibersihkan. Deploy selesai."

Perintah aws cloudfront wait invalidation-completed akan memblokir eksekusi script hingga invalidasi benar-benar selesai di semua edge location — berguna jika langkah selanjutnya dalam pipeline bergantung pada konten terbaru yang sudah tersedia.

Alternatif Jangka Panjang: Cache Busting dengan Versioning File

Invalidasi menyelesaikan masalah, tapi bukan solusi terbaik untuk konten yang sering berubah. Setiap invalidasi memiliki biaya — AWS memberikan 1.000 path invalidasi gratis per bulan, dan setelah itu dikenakan biaya. Selain itu, invalidasi wildcard (/*) yang terlalu sering digunakan bisa menyebabkan cache miss rate tinggi dan meningkatkan beban ke origin S3.

Pendekatan yang lebih skalabel adalah cache busting: sertakan hash konten atau nomor versi dalam nama file.

# Contoh penamaan file dengan versioning
style.abc123.css   # hash konten
app.v2.1.0.js      # nomor versi

# Upload dengan nama baru
aws s3 cp ./dist/style.abc123.css s3://nama-bucket-kamu/css/style.abc123.css

# HTML referensi file dengan nama baru — CloudFront otomatis fetch dari origin
# karena path berbeda, tidak perlu invalidasi

Dengan pendekatan ini, setiap versi file memiliki URL unik. CloudFront tidak pernah menyajikan versi lama karena path-nya berbeda — tidak ada invalidasi yang diperlukan sama sekali.

Diagnosis: Kenapa File Masih Lama Meski Sudah Diinvalidasi?

Ini pernah terjadi: invalidasi sudah Completed, tapi browser masih menampilkan versi lama. Instinct pertama biasanya menyalahkan CloudFront lagi — tapi setelah dicek dengan curl -I, header X-Cache: Miss from cloudfront sudah muncul, artinya CloudFront sudah mengambil dari origin.

Penyebab sebenarnya: browser cache lokal. CloudFront mengirim header Cache-Control ke browser, dan browser menyimpan salinannya sendiri. Invalidasi CloudFront tidak menyentuh cache browser.

# Verifikasi apakah CloudFront sudah melayani versi terbaru
# X-Cache: Hit from cloudfront  → masih dari cache edge
# X-Cache: Miss from cloudfront → sudah diambil dari origin
curl -I https://d1example.cloudfront.net/images/logo.png

Jika header menunjukkan Miss from cloudfront tapi browser masih menampilkan versi lama, lakukan hard refresh (Ctrl+Shift+R) atau buka di mode incognito. Masalah ada di browser, bukan di CloudFront.

graph TD A["Buat Invalidasi"] --> B["CloudFront menyebarkan
ke semua Edge Location"] B --> C["Edge cache dibersihkan"] C --> D["Request berikutnya
diteruskan ke S3"] D --> E["S3 mengembalikan
versi terbaru"] E --> F["Edge simpan cache baru"] F --> G{"Browser cache?"} G -- "Tidak ada / expired" --> H["Pengguna melihat
versi terbaru"] G -- "Masih ada salinan lama" --> I["Hard Refresh
diperlukan"]
  1. Invalidasi dibuat → CloudFront menyebarkan instruksi ke semua edge location.
  2. Edge cache dibersihkan → Request berikutnya ke edge akan diteruskan ke S3.
  3. S3 mengembalikan versi baru → Edge menyimpan salinan baru.
  4. Browser cache → Terpisah dari CloudFront, tidak terpengaruh oleh invalidasi. Hard refresh diperlukan jika browser menyimpan salinan lokal.

Kuota dan Biaya Invalidasi CloudFront

Sebelum menggunakan invalidasi secara agresif, pahami model biayanya. AWS memberikan 1.000 path invalidasi gratis per bulan per akun. Setelah itu, setiap path dikenakan biaya. Wildcard /* dihitung sebagai satu path, bukan satu per file yang diinvalidasi.

Untuk detail biaya terkini, selalu cek halaman AWS CloudFront Pricing karena harga dapat berubah sewaktu-waktu.

Ringkasan dan Langkah Selanjutnya untuk Invalidasi CloudFront

Membuat CloudFront Invalidation adalah cara paling langsung untuk memaksa edge location membuang cache dan mengambil versi terbaru dari S3. Untuk kebutuhan sesekali, gunakan console. Untuk deployment rutin, integrasikan CLI ke pipeline dengan aws cloudfront create-invalidation dan tunggu completion dengan aws cloudfront wait invalidation-completed. Untuk konten yang sering berubah dalam skala besar, pertimbangkan cache busting berbasis versioning file untuk menghindari ketergantungan pada invalidasi.

Langkah selanjutnya yang disarankan:

  • Pelajari pengaturan Cache Behavior dan TTL di distribusi CloudFront kamu untuk mengoptimalkan kapan cache expire secara alami.
  • Pertimbangkan menggunakan CloudFront Functions atau Lambda@Edge jika kamu perlu logika cache yang lebih granular.
  • Baca dokumentasi resmi: Invalidating Files - AWS CloudFront Developer Guide.

Glosarium

IstilahPenjelasan
Edge LocationServer CloudFront yang tersebar secara geografis, menyimpan cache konten untuk melayani pengguna dengan latensi rendah.
InvalidationInstruksi ke CloudFront untuk menghapus salinan cache dari edge location sebelum TTL habis.
TTL (Time to Live)Durasi waktu sebuah objek disimpan di cache edge sebelum dianggap kadaluarsa dan perlu diambil ulang dari origin.
Cache BustingTeknik menyertakan versi atau hash dalam nama file sehingga setiap perubahan menghasilkan URL baru, menghindari kebutuhan invalidasi.
OriginSumber konten asli yang dilayani CloudFront — dalam konteks ini adalah bucket S3.

Komentar

Posting Komentar

Postingan populer dari blog ini

EBS vs EFS untuk Multiple EC2 Instance: Cara Berbagi Folder Antar Instance

Saat tim backend kami perlu berbagi direktori konfigurasi antara lima EC2 instance sekaligus, pertanyaan pertama yang muncul adalah: apakah EBS bisa di-mount ke beberapa instance? Jawabannya tidak sesederhana yang terlihat di konsol AWS — dan salah memilih storage di sini bisa menyebabkan data corruption atau arsitektur yang tidak scalable. Artikel ini membahas perbedaan EBS vs EFS secara operasional untuk skenario shared folder antar multiple EC2 instance . TL;DR: EBS vs EFS untuk Berbagi Folder Aspek EBS EFS Mount ke banyak instance Terbatas (lihat catatan Multi-Attach) Ya, tanpa batas jumlah instance Protokol akses Block device (seperti hard disk) NFS v4.1 / v4.0 Lintas Availability Zone Tidak (terikat satu AZ) Ya (regional, multi-AZ) Cocok untuk shared folder Tidak direkomendasikan un...
Baca selengkapnya

Memahami Instance T3 Burstable: Cara Kerja CPU Credits dan Kenapa Server Tiba-tiba Melambat

Anda baru saja deploy aplikasi di instance T3, semua berjalan lancar selama beberapa menit — lalu tiba-tiba response time melonjak, CPU usage turun drastis, dan pengguna mulai mengeluh. Tidak ada error di log aplikasi, tidak ada masalah jaringan. Ini adalah gejala klasik CPU credit exhaustion pada instance T3 burstable, dan memahami mekanisme di baliknya adalah kunci untuk menghindari insiden serupa di production. TL;DR: CPU Credits pada Instance T3 Aspek Penjelasan Apa itu CPU Credit? Satuan yang merepresentasikan hak pakai CPU penuh selama 1 menit pada 1 vCPU Kapan credit bertambah? Saat CPU usage di bawah baseline instance Kapan credit berkurang? Saat CPU usage melebihi baseline instance Mode default T3 Unlimited — instance dapat burst melampaui credit balance dengan biaya tambahan Gejala credit h...
Baca selengkapnya

EC2 Tidak Bisa Akses Internet di Custom VPC: Cara Pasang Internet Gateway dan Update Route Table

Kamu baru saja membuat custom VPC, meluncurkan EC2 instance di public subnet, lalu mencoba ping google.com — dan tidak ada respons sama sekali. Ini adalah salah satu jebakan paling umum saat pertama kali bekerja dengan EC2 no internet access di custom VPC , dan penyebabnya hampir selalu kombinasi dari tiga hal: tidak ada Internet Gateway, route table yang belum diupdate, atau Security Group yang memblokir traffic. TL;DR: Checklist EC2 Tidak Bisa Internet di Custom VPC Komponen Yang Harus Dicek Kondisi Benar Internet Gateway Sudah dibuat dan di-attach ke VPC State: attached Route Table Ada route 0.0.0.0/0 ke IGW Target: igw-xxxxxxxx Subnet Association Public subnet terhubung ke route table yang benar Subnet ID muncul di associations Security Group Inbound HTTP/HTTPS/ICMP diizinkan Rule eksplisit untuk port 80, 443, atau ICMP Public IP Instance punya public IP atau Elastic IP PublicIpAddress tidak n...
Baca selengkapnya