Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Caching dan ketersediaan
<a name="ConfiguringCaching"></a>

Anda dapat menggunakannya CloudFront untuk mengurangi jumlah permintaan yang harus ditanggapi oleh server asal Anda secara langsung. Dengan CloudFront caching, lebih banyak objek dilayani dari lokasi CloudFront tepi, yang lebih dekat dengan pengguna Anda. Ini mengurangi beban di server asal Anda dan mengurangi latensi.

Semakin banyak permintaan yang CloudFront dapat ditayangkan dari cache tepi, semakin sedikit permintaan pemirsa yang CloudFront harus diteruskan ke asal Anda untuk mendapatkan versi terbaru atau versi unik dari suatu objek. CloudFront Untuk mengoptimalkan agar permintaan ke asal Anda sesedikit mungkin, pertimbangkan untuk menggunakan CloudFront Origin Shield. Untuk informasi selengkapnya, lihat [Gunakan Amazon CloudFront Origin Shield](origin-shield.md).

Proporsi permintaan yang disajikan langsung dari CloudFront cache dibandingkan dengan semua permintaan disebut *rasio hit cache*. Anda dapat melihat persentase permintaan pemirsa yang merupakan klik, kesalahan, dan kesalahan di CloudFront konsol. Untuk informasi selengkapnya, lihat [Lihat laporan statistik CloudFront cache](cache-statistics.md).

Sejumlah faktor memengaruhi rasio tembolok. Anda dapat menyesuaikan konfigurasi CloudFront distribusi Anda untuk meningkatkan rasio hit cache dengan mengikuti panduan di[Tingkatkan proporsi permintaan yang disajikan langsung dari CloudFront cache (rasio hit cache)](cache-hit-ratio.md).

Untuk mempelajari tentang menambahkan dan menghapus konten yang CloudFront ingin Anda sajikan, lihat[Menambahkan, menghapus, atau mengganti konten yang CloudFront mendistribusikan](AddRemoveReplaceObjects.md).

**Topics**
+ [

# Tingkatkan proporsi permintaan yang disajikan langsung dari CloudFront cache (rasio hit cache)
](cache-hit-ratio.md)
+ [

# Gunakan Amazon CloudFront Origin Shield
](origin-shield.md)
+ [

# Optimalkan ketersediaan tinggi dengan failover CloudFront asal
](high_availability_origin_failover.md)
+ [

# Mengelola berapa lama konten tetap dalam cache (kedaluwarsa)
](Expiration.md)
+ [

# Konten cache berdasarkan parameter string kueri
](QueryStringParameters.md)
+ [

# Konten cache berdasarkan cookie
](Cookies.md)
+ [

# Konten cache berdasarkan header permintaan
](header-caching.md)

# Tingkatkan proporsi permintaan yang disajikan langsung dari CloudFront cache (rasio hit cache)
<a name="cache-hit-ratio"></a>

Anda dapat meningkatkan kinerja dengan meningkatkan proporsi permintaan pemirsa Anda yang disajikan langsung dari CloudFront cache alih-alih pergi ke server asal Anda untuk konten. Hal ini dikenal sebagai peningkatan rasio temuan cache.

Bagian berikut menjelaskan cara meningkatkan rasio temuan cache Anda.

**Topics**
+ [

## Tentukan berapa lama CloudFront cache objek Anda
](#cache-hit-ratio-duration)
+ [

## Gunakan Origin Shield
](#cache-hit-ratio-use-origin-shield)
+ [

## Caching berdasarkan parameter string kueri
](#cache-hit-ratio-query-string-parameters)
+ [

## Memisahkan berdasarkan nilai cookie
](#cache-hit-ratio-cookies)
+ [

## Menyimpan berdasarkan header permintaan
](#cache-hit-ratio-request-headers)
+ [

## Hapus `Accept-Encoding` header saat kompresi tidak diperlukan
](#cache-hit-ratio-remove-accept-encoding)
+ [

## Sajikan konten media melalui HTTP
](#cache-hit-ratio-http-streaming)

## Tentukan berapa lama CloudFront cache objek Anda
<a name="cache-hit-ratio-duration"></a>

Untuk meningkatkan rasio temuan cache, Anda dapat mengonfigurasi asal Anda untuk menambah arahan [Cache-Control max-age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) ke objek Anda, dan menentukan nilai praktis terpanjang untuk `max-age`. Semakin pendek durasi cache, semakin sering CloudFront mengirim permintaan ke asal Anda untuk menentukan apakah suatu objek telah berubah dan untuk mendapatkan versi terbaru. Anda dapat melengkapi `max-age` dengan `stale-if-error` arahan `stale-while-revalidate` dan untuk lebih meningkatkan rasio hit cache dalam kondisi tertentu. Untuk informasi selengkapnya, lihat [Mengelola berapa lama konten tetap dalam cache (kedaluwarsa)](Expiration.md).

## Gunakan Origin Shield
<a name="cache-hit-ratio-use-origin-shield"></a>

CloudFront Origin Shield dapat membantu meningkatkan rasio hit cache CloudFront distribusi Anda, karena menyediakan lapisan caching tambahan di depan asal Anda. Saat Anda menggunakan Origin Shield, semua permintaan dari CloudFront semua lapisan caching ke asal Anda berasal dari satu lokasi. CloudFront dapat mengambil setiap objek menggunakan permintaan asal tunggal dari Origin Shield, dan semua lapisan cache lainnya (lokasi tepi dan CloudFront [cache tepi regional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) dapat mengambil objek dari Origin Shield.

Untuk informasi selengkapnya, lihat [Gunakan Amazon CloudFront Origin Shield](origin-shield.md).

## Caching berdasarkan parameter string kueri
<a name="cache-hit-ratio-query-string-parameters"></a>

Jika Anda CloudFront mengkonfigurasi cache berdasarkan parameter string kueri, Anda dapat meningkatkan caching jika Anda melakukan hal berikut:
+ Konfigurasikan CloudFront untuk meneruskan hanya parameter string kueri yang asal Anda akan mengembalikan objek unik.
+ Gunakan kasus yang sama (huruf besar atau kecil) untuk semua kasus parameter yang sama. Misalnya, jika satu permintaan berisi `parameter1=A` dan permintaan lainnya berisi`parameter1=a`, CloudFront teruskan permintaan terpisah ke asal Anda saat permintaan berisi `parameter1=A` dan saat permintaan berisi`parameter1=a`. CloudFront kemudian secara terpisah menyimpan objek terkait yang dikembalikan oleh asal Anda secara terpisah meskipun objeknya identik. Jika Anda hanya menggunakan `A` atau `a`, CloudFront mengirimkan lebih sedikit permintaan ke asal Anda.
+ Cantumkan parameter dalam urutan yang sama. Seperti halnya perbedaan dalam kasus, jika satu permintaan untuk objek berisi string kueri `parameter1=a&parameter2=b` dan permintaan lain untuk objek yang sama berisi`parameter2=b&parameter1=a`, CloudFront teruskan kedua permintaan ke asal Anda dan secara terpisah menyimpan objek yang sesuai meskipun keduanya identik. Jika Anda selalu menggunakan urutan parameter yang sama, CloudFront teruskan lebih sedikit permintaan ke asal Anda.

Untuk informasi selengkapnya, lihat [Konten cache berdasarkan parameter string kueri](QueryStringParameters.md). Jika Anda ingin meninjau string kueri yang CloudFront diteruskan ke asal Anda, lihat nilai di `cs-uri-query` kolom file CloudFront log Anda. Untuk informasi selengkapnya, lihat [Akses log (log standar)](AccessLogs.md).

## Memisahkan berdasarkan nilai cookie
<a name="cache-hit-ratio-cookies"></a>

Jika Anda CloudFront mengonfigurasi cache berdasarkan nilai cookie, Anda dapat meningkatkan caching jika Anda melakukan hal berikut:
+ Konfigurasikan CloudFront untuk meneruskan hanya cookie tertentu alih-alih meneruskan semua cookie. Untuk cookie yang Anda konfigurasikan CloudFront untuk meneruskan ke asal Anda, CloudFront teruskan setiap kombinasi nama dan nilai cookie. Kemudian dia menyimpan secara terpisah objek yang dikembalikan asal Anda, bahkan jika semuanya identik.

  Misalnya, anggaplah bahwa pemirsa menyertakan dua cookie dalam setiap permintaan, bahwa setiap cookie memiliki tiga nilai yang mungkin, dan bahwa semua kombinasi nilai cookie dimungkinkan. CloudFront meneruskan hingga sembilan permintaan berbeda ke asal Anda untuk setiap objek. Jika asal Anda mengembalikan versi objek yang berbeda hanya berdasarkan salah satu cookie, maka meneruskan CloudFront lebih banyak permintaan ke asal Anda daripada yang diperlukan dan tidak perlu menyimpan beberapa versi objek yang identik.
+ Buat perilaku cache terpisah untuk konten statis dan dinamis, dan konfigurasikan CloudFront untuk meneruskan cookie ke asal Anda hanya untuk konten dinamis.

  Misalnya, Anda hanya memiliki satu perilaku cache untuk distribusi Anda dan bahwa Anda menggunakan distribusi baik untuk konten dinamis, seperti `.js` file, dan untuk `.css` file yang jarang berubah. CloudFront cache versi terpisah dari `.css` file Anda berdasarkan nilai cookie, sehingga setiap lokasi CloudFront tepi meneruskan permintaan ke asal Anda untuk setiap nilai cookie baru atau kombinasi nilai cookie.

  Jika Anda membuat perilaku cache yang pola jalurnya `*.css` dan yang CloudFront tidak di-cache berdasarkan nilai cookie, maka CloudFront teruskan permintaan `.css` file ke asal Anda hanya untuk permintaan pertama yang diterima lokasi tepi untuk `.css` file tertentu dan untuk permintaan pertama setelah `.css` file kedaluwarsa.
+ Jika memungkinkan, buat perilaku cache terpisah untuk konten dinamis ketika nilai cookie unik untuk setiap pengguna (seperti ID pengguna), dan konten dinamis yang bervariasi berdasarkan jumlah nilai unik yang lebih kecil.

Untuk informasi selengkapnya, lihat [Konten cache berdasarkan cookie](Cookies.md). Jika Anda ingin meninjau cookie yang CloudFront diteruskan ke asal Anda, lihat nilai di `cs(Cookie)` kolom file CloudFront log Anda. Untuk informasi selengkapnya, lihat [Akses log (log standar)](AccessLogs.md).

## Menyimpan berdasarkan header permintaan
<a name="cache-hit-ratio-request-headers"></a>

Jika Anda CloudFront mengonfigurasi cache berdasarkan header permintaan, Anda dapat meningkatkan caching jika Anda melakukan hal berikut:
+ Konfigurasikan CloudFront untuk meneruskan dan cache hanya berdasarkan header yang ditentukan, bukan penerusan dan caching berdasarkan semua header. Untuk header yang Anda tentukan, CloudFront teruskan setiap kombinasi nama dan nilai header. Kemudian ini menyimpan objek secara terpisah yang asal Anda kembali meskipun semuanya identik.
**catatan**  
CloudFront selalu meneruskan ke asal Anda header yang ditentukan dalam topik berikut:  
Cara CloudFront memproses dan meneruskan permintaan ke server asal Amazon S3 Anda> [Header permintaan HTTP yang CloudFront menghapus atau memperbarui](RequestAndResponseBehaviorS3Origin.md#request-s3-removed-headers)
Cara CloudFront memproses dan meneruskan permintaan ke server asal kustom Anda> [Header dan CloudFront perilaku permintaan HTTP (asal kustom dan Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)

  Saat Anda CloudFront mengonfigurasi cache berdasarkan header permintaan, Anda tidak mengubah header yang CloudFront diteruskan, hanya jika CloudFront cache objek berdasarkan nilai header.
+ Coba hindari cache berdasarkan header permintaan yang memiliki nilai unik dalam jumlah besar.

  Misalnya, jika Anda ingin menyajikan ukuran gambar yang berbeda berdasarkan perangkat pengguna, maka jangan CloudFront mengkonfigurasi cache berdasarkan `User-Agent` header, yang memiliki sejumlah besar kemungkinan nilai. Sebagai gantinya, konfigurasikan CloudFront ke cache berdasarkan header CloudFront tipe perangkat`CloudFront-Is-Desktop-Viewer`,,, `CloudFront-Is-Mobile-Viewer` dan. `CloudFront-Is-SmartTV-Viewer` `CloudFront-Is-Tablet-Viewer` Selain itu, jika Anda mengembalikan versi citra yang sama untuk tablet dan desktop, maka teruskan header `CloudFront-Is-Tablet-Viewer` saja, bukan header `CloudFront-Is-Desktop-Viewer`.

Untuk informasi selengkapnya, lihat [Konten cache berdasarkan header permintaan](header-caching.md).

## Hapus `Accept-Encoding` header saat kompresi tidak diperlukan
<a name="cache-hit-ratio-remove-accept-encoding"></a>

Jika kompresi tidak diaktifkan—karena asal tidak mendukungnya, CloudFront tidak mendukungnya, atau konten tidak dapat dikompresikan—Anda dapat meningkatkan rasio hit cache dengan mengaitkan perilaku cache dalam distribusi Anda ke asal yang menetapkan sebagai berikut: Custom Origin Header
+ **Nama header**: `Accept-Encoding`
+ **Nilai header**: (Biarkan kosong)

Saat Anda menggunakan konfigurasi ini, CloudFront hapus `Accept-Encoding` header dari kunci cache dan tidak menyertakan header dalam permintaan asal. Konfigurasi ini berlaku untuk semua konten yang CloudFront berfungsi dengan distribusi dari asal itu.

## Sajikan konten media melalui HTTP
<a name="cache-hit-ratio-http-streaming"></a>

Untuk informasi tentang mengoptimalkan video sesuai permintaan (VOD) dan konten video streaming, lihat [Video sesuai permintaan dan video streaming langsung dengan CloudFront](on-demand-streaming-video.md).

# Gunakan Amazon CloudFront Origin Shield
<a name="origin-shield"></a>

CloudFront Origin Shield adalah lapisan tambahan dalam infrastruktur CloudFront caching yang membantu meminimalkan beban asal Anda, meningkatkan ketersediaannya, dan mengurangi biaya operasinya. Dengan CloudFront Origin Shield, Anda mendapatkan manfaat berikut:

**Rasio temuan cache yang lebih baik**  
Origin Shield dapat membantu meningkatkan rasio hit cache CloudFront distribusi Anda karena menyediakan lapisan caching tambahan di depan asal Anda. Saat Anda menggunakan Origin Shield, semua permintaan dari CloudFront semua lapisan caching ke asal Anda melalui Origin Shield, meningkatkan kemungkinan terkena cache. CloudFrontdapat mengambil setiap objek dengan permintaan asal tunggal dari Origin Shield ke asal Anda, dan semua lapisan cache lainnya (lokasi tepi dan CloudFront [cache tepi regional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) dapat mengambil objek dari Origin Shield.

**Pengurangan muatan asal**  
Origin Shield dapat mengurangi lebih lanjut jumlah [permintaan secara bersamaan](RequestAndResponseBehaviorCustomOrigin.md#request-custom-traffic-spikes) yang dikirimkan ke tempat asal Anda untuk objek yang sama. Permintaan konten yang tidak berada dalam cache Origin Shield digabungkan dengan permintaan lain untuk objek yang sama, yang mengakibatkan sesedikit mungkin permintaan yang dikirimkan ke asal Anda. Menangani lebih sedikit permintaan di tempat asal Anda dapat mempertahankan ketersediaan asal Anda selama beban puncak atau lonjakan lalu lintas yang tidak terduga, dan dapat mengurangi biaya untuk hal-hal seperti just-in-time pengemasan, transformasi gambar, dan transfer data keluar (DTO).

**Kinerja jaringan yang lebih baik**  
Bila Anda mengaktifkan Origin Shield di AWS Wilayah [yang memiliki latensi terendah ke asal Anda, Anda](#choose-origin-shield-region) bisa mendapatkan performa jaringan yang lebih baik. Untuk asal-usul di suatu AWS Wilayah, lalu lintas CloudFront jaringan tetap berada di CloudFront jaringan throughput tinggi sampai ke asal Anda. Untuk asal di luar AWS, lalu lintas CloudFront jaringan tetap berada di CloudFront jaringan sampai ke Origin Shield, yang memiliki koneksi latensi rendah ke asal Anda.

Anda akan dikenakan biaya tambahan untuk menggunakan Origin Shield. Untuk informasi selengkapnya, lihat [harga CloudFront ](https://aws.amazon.com/cloudfront/pricing/).

**catatan**  
Origin Shield tidak didukung dengan permintaan gRPC. Jika distribusi yang mendukung gRPC mengaktifkan Origin Shield, permintaan gRPC akan terus berfungsi. Namun, permintaan akan diproksi langsung ke asal gRPC tanpa melalui Origin Shield. Untuk informasi selengkapnya, lihat [Menggunakan gRPC dengan distribusi CloudFront](distribution-using-grpc.md).

**Topics**
+ [

## Gunakan kasus untuk Tameng Asal
](#origin-shield-use-cases)
+ [

## Pilih AWS Wilayah untuk Origin Shield
](#choose-origin-shield-region)
+ [

## Aktifkan Origin Shield
](#enable-origin-shield)
+ [

## Perkirakan biaya Origin Shield
](#origin-shield-costs)
+ [

## Ketersediaan tinggi Origin Shield
](#origin-shield-high-availability)
+ [

## Bagaimana Origin Shield berinteraksi dengan fitur lain CloudFront
](#origin-shield-and-other-features)

## Gunakan kasus untuk Tameng Asal
<a name="origin-shield-use-cases"></a>

CloudFront Origin Shield dapat bermanfaat untuk banyak kasus penggunaan, termasuk yang berikut:
+ Penampil yang tersebar di berbagai wilayah geografis
+ Origins yang menyediakan just-in-time kemasan untuk streaming langsung atau pemrosesan on-the-fly gambar
+ Asal di lokasi dengan kapasitas atau keterbatasan bandwidth
+ Beban kerja yang menggunakan beberapa jaringan pengiriman konten () CDNs

Tameng Asal mungkin tidak cocok untuk kasus lain, seperti konten dinamis yang disadarkan dengan asal, konten dengan kemampuan cache rendah, atau konten yang tidak sering diminta.

Bagian berikut menjelaskan manfaat Tameng Asal untuk kasus penggunaan berikut.

**Topics**
+ [

### Penampil di wilayah geografis yang berbeda
](#os-use-cases-global-viewers)
+ [

### Berganda CDNs
](#os-use-cases-multi-cdn)

### Penampil di wilayah geografis yang berbeda
<a name="os-use-cases-global-viewers"></a>

Dengan Amazon CloudFront, Anda secara inheren mendapatkan pengurangan beban pada asal Anda karena permintaan yang CloudFront dapat ditayangkan dari cache tidak masuk ke asal Anda. Selain [jaringan global lokasi edge, cache edge](https://aws.amazon.com/cloudfront/features/#Amazon_CloudFront_Infrastructure) [regional berfungsi sebagai lapisan caching](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) tingkat menengah untuk memberikan klik cache dan mengkonsolidasikan permintaan asal untuk pemirsa di wilayah geografis terdekat. CloudFront Permintaan penampil dirutekan terlebih dahulu ke lokasi terdekat CloudFront lokasi tepian, dan jika objek tidak tersimpan di lokasi tersebut, permintaan dikirim ke cache tepi regional.

Ketika penampil berada di wilayah geografis yang berbeda, permintaan dapat diarahkan melalui cache edge regional yang berbeda, yang masing-masing dapat mengirim permintaan ke asal Anda untuk konten yang sama. Tetapi dengan Origin Shield, Anda mendapatkan lapisan tambahan cache antara edge cache regional dan tempat asal Anda. Semua permintaan dari semua cache tepi regional masuk melalui Origin Shield, lebih lanjut mengurangi muatan di tempat asal Anda. Diagram berikut menggambarkan hal ini. Dalam diagram berikut, asalnya adalah. AWS Elemental MediaPackage

**Tanpa Origin Shield**

Tanpa Origin Shield, negara asal Anda mungkin menerima permintaan duplikat untuk konten yang sama, seperti yang ditunjukkan pada diagram berikut.

![\[Tanpa CloudFront Origin Shield, asal mungkin menerima permintaan duplikat.\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without.png)


**Dengan Origin Shield**

Menggunakan Tameng Asal dapat membantu mengurangi beban pada asal Anda, seperti yang ditunjukkan dalam diagram berikut.

![\[Dengan CloudFront Origin Shield, asal dapat menerima lebih sedikit permintaan duplikat.\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with.png)


### Berganda CDNs
<a name="os-use-cases-multi-cdn"></a>

Untuk menayangkan acara video langsung atau konten sesuai permintaan populer, Anda dapat menggunakan beberapa jaringan pengiriman konten (CDNs). Menggunakan beberapa CDNs dapat menawarkan keuntungan tertentu, tetapi itu juga berarti bahwa asal Anda mungkin menerima banyak permintaan duplikat untuk konten yang sama, masing-masing berasal dari lokasi yang berbeda CDNs atau berbeda dalam CDN yang sama. Permintaan berlebihan ini dapat mempengaruhi ketersediaan asal Anda atau menyebabkan biaya operasi tambahan untuk proses seperti just-in-time pengemasan atau transfer data (DTO) ke internet.

Ketika Anda menggabungkan Origin Shield dengan menggunakan CloudFront distribusi Anda sebagai asal untuk yang lain CDNs, Anda bisa mendapatkan manfaat berikut:
+ Lebih sedikit permintaan berlebihan yang diterima di negara asal Anda, yang membantu mengurangi dampak negatif penggunaan banyak CDNs.
+ Umum [kunci cache](controlling-the-cache-key.md) di seluruh CDNs, dan manajemen terpusat untuk fitur asal-usul.
+ Peningkatan kinerja jaringan. Lalu lintas jaringan dari CDNs yang lain dihentikan di lokasi CloudFront tepi terdekat, yang mungkin memberikan hit dari cache lokal. Jika objek yang diminta tidak berada di cache lokasi tepi, permintaan ke asal tetap ada di CloudFront jaringan sampai ke Origin Shield, yang memberikan throughput tinggi dan latensi rendah ke asal. Jika objek yang diminta berada dalam cache Origin Shield, permintaan kepada asal Anda dapat dihindari sepenuhnya.

**penting**  
Jika Anda tertarik untuk menggunakan Origin Shield dalam arsitektur multi-CDN, dan memiliki harga diskon, [hubungi kami](https://aws.amazon.com/contact-us/) atau perwakilan AWS penjualan Anda untuk informasi lebih lanjut. Mungkin dapat dikenakan biaya tambahan.

Diagram berikut menunjukkan bagaimana konfigurasi ini dapat membantu meminimalkan beban pada asal Anda saat Anda menyajikan acara video langsung populer dengan beberapa. CDNs Dalam diagram berikut, asalnya adalah. AWS Elemental MediaPackage

**Tanpa Origin Shield (beberapa CDNs)**

Tanpa Origin Shield, negara asal Anda mungkin menerima banyak permintaan duplikat untuk konten yang sama, yang masing-masing berasal dari CDN yang berbeda, seperti yang ditunjukkan pada diagram berikut.

![\[Grafik yang menunjukkan bagaimana asal dapat menerima permintaan duplikat, masing-masing berasal dari CDN yang berbeda.\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without-multi-cdn.png)


**Dengan Origin Shield (beberapa CDNs)**

Menggunakan Origin Shield, dengan CloudFront sebagai asal untuk yang lain CDNs, dapat membantu mengurangi beban pada asal Anda, seperti yang ditunjukkan pada diagram berikut.

![\[Grafik yang menunjukkan CloudFront Origin Shield menerima lebih sedikit permintaan duplikat.\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with-multi-cdn.png)


## Pilih AWS Wilayah untuk Origin Shield
<a name="choose-origin-shield-region"></a>

Amazon CloudFront menawarkan Origin Shield di AWS Wilayah yang CloudFront memiliki [cache tepi regional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches). Saat mengaktifkan Origin Shield, Anda memilih AWS Region for Origin Shield. Anda harus memilih Wilayah AWS yang memiliki latensi terendah dengan asal Anda. Anda dapat menggunakan Origin Shield dengan asal yang ada di AWS Wilayah, dan dengan asal yang tidak ada AWS.

### Untuk asal-usul di suatu AWS Wilayah
<a name="choose-origin-shield-region-inside-aws"></a>

Jika asal Anda berada di suatu AWS Wilayah, tentukan terlebih dahulu apakah asal Anda berada di Wilayah yang CloudFront menawarkan Origin Shield. CloudFront menawarkan Origin Shield di AWS Wilayah berikut.
+ AS Timur (Ohio) – `us-east-2`
+ AS Timur (Virginia Utara) – `us-east-1`
+ AS Barat (Oregon) – `us-west-2`
+ Asia Pasifik (Mumbai)–`ap-south-1`
+ Asia Pasifik (Seoul)–`ap-northeast-2`
+ Asia Pasifik (Singapura)–`ap-southeast-1`
+ Asia Pasifik (Sydney)–`ap-southeast-2`
+ Asia Pasifik (Tokyo) – `ap-northeast-1`
+ Eropa (Frankfurt) – `eu-central-1`
+ Eropa (Irlandia)–`eu-west-1`
+ Eropa (London) – `eu-west-2`
+ Amerika Selatan (São Paulo) – `sa-east-1`
+ Timur Tengah (UEA) - `me-central-1`

**Jika asal Anda berada di AWS Wilayah yang CloudFront menawarkan Origin Shield**

Jika asal Anda berada di AWS Wilayah yang CloudFront menawarkan Origin Shield (lihat daftar sebelumnya), aktifkan Origin Shield di Wilayah yang sama dengan asal Anda.

**Jika asal Anda tidak berada di AWS Wilayah yang CloudFront menawarkan Origin Shield**

 Jika asal Anda tidak berada di AWS Wilayah yang CloudFront menawarkan Origin Shield, lihat tabel berikut untuk menentukan Wilayah mana yang akan mengaktifkan Origin Shield.


|  **Jika asal Anda berada di...**  |  **Aktifkan Origin Shield di...**  | 
| --- | --- | 
|  AS Barat (N. California) – `us-west-1`  |  AS Barat (Oregon) – `us-west-2`  | 
|  Afrika (Cape Town) – `af-south-1`  |  Eropa (Irlandia) – `eu-west-1`  | 
|  Asia Pasifik (Hong Kong) – `ap-east-1`  |  Asia Pasifik (Singapura) – `ap-southeast-1`  | 
|  Kanada (Pusat) – `ca-central-1`  |  AS Timur (Virginia Utara) – `us-east-1`  | 
|  Eropa (Milan) – `eu-south-1`  |  Eropa (Frankfurt) – `eu-central-1`  | 
|  Eropa (Paris) – `eu-west-3`  |  Eropa (London) – `eu-west-2`  | 
|  Eropa (Stockholm) – `eu-north-1`  |  Eropa (London) – `eu-west-2`  | 
|  Timur Tengah (Bahrain) – `me-south-1`  |  Asia Pasifik (Mumbai) – `ap-south-1`  | 

### Untuk asal-usul di luar AWS
<a name="choose-origin-shield-region-outside-aws"></a>

Anda dapat menggunakan Origin Shield dengan asal yang berada di lokasi atau tidak berada di Wilayah AWS . Dalam hal ini, aktifkan Origin Shield di AWS Wilayah yang memiliki latensi terendah ke asal Anda. Jika Anda tidak yakin AWS Wilayah mana yang memiliki latensi terendah ke asal Anda, Anda dapat menggunakan saran berikut untuk membantu Anda menentukan.
+ Anda dapat melihat tabel sebelumnya untuk perkiraan Wilayah AWS yang mungkin memiliki latensi terendah ke asal Anda, berdasarkan lokasi geografis asal Anda.
+ Anda dapat meluncurkan instans Amazon EC2 di beberapa AWS Wilayah berbeda yang secara geografis dekat dengan asal Anda, dan menjalankan beberapa pengujian `ping` untuk mengukur latensi jaringan tipikal antara Wilayah tersebut dan asal Anda.

## Aktifkan Origin Shield
<a name="enable-origin-shield"></a>

Anda dapat mengaktifkan Origin Shield untuk meningkatkan rasio tekan cache, mengurangi beban pada asal Anda, dan membantu meningkatkan kinerja. Untuk mengaktifkan Origin Shield, ubah pengaturan asal dalam CloudFront distribusi. Tameng Asal adalah milik asal usul. Untuk setiap asal dalam CloudFront distribusi Anda, Anda dapat mengaktifkan Origin Shield secara terpisah di AWS Wilayah mana pun yang memberikan kinerja terbaik untuk asal tersebut.

Anda dapat mengaktifkan Origin Shield di CloudFront konsol CloudFormation, dengan, atau dengan CloudFront API.

------
#### [ Console ]

**Untuk mengaktifkan Tameng Asal untuk asal yang ada (konsol)**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih distribusi yang memiliki asal yang ingin Anda perbarui.

1. Pilih tab **Origins**.

1. Pilih asal pembaruan, lalu pilih **Edit**.

1. Untuk **Aktifkan Perisai Asal**, pilih **Ya**.

1. Untuk **Wilayah Origin Shield**, pilih Wilayah AWS tempat Anda ingin mengaktifkan Origin Shield. Untuk bantuan memilih Wilayah, lihat [Pilih AWS Wilayah untuk Origin Shield](#choose-origin-shield-region).

1. Pilih **Simpan perubahan**.

Saat status distribusi Anda **Diterapkan**, Tameng Asal sudah siap. Ini memerlukan waktu beberapa menit.

**Untuk mengaktifkan Shield Asal untuk asal baru (konsol)**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Untuk membuat asal baru dalam distribusi yang sudah ada, lakukan hal berikut ini:

   1. Pilih distribusi tempat Anda ingin membuat asal.

   1. Pilih **Buat Asal**, lalu lanjutkan ke langkah 3.

   Untuk membuat asal baru dalam distribusi standar baru, lakukan hal berikut:

   1. Ikuti langkah-langkah untuk membuat distribusi standar di konsol. Untuk informasi selengkapnya, lihat [Buat CloudFront distribusi di konsol](distribution-web-creating-console.md#create-console-distribution).

   1. Di bagian **Pengaturan**, pilih **Sesuaikan pengaturan asal**. Lanjutkan ke langkah 3.

1. Untuk **Aktifkan Perisai Asal**, pilih **Ya**.

1. Untuk **Wilayah Origin Shield**, pilih Wilayah AWS tempat Anda ingin mengaktifkan Origin Shield. Untuk bantuan memilih Wilayah, lihat [Pilih AWS Wilayah untuk Origin Shield](#choose-origin-shield-region).

1. Ikuti langkah-langkah di konsol untuk menyelesaikan pembuatan asal atau distribusi Anda.

Saat status distribusi Anda **Diterapkan**, Tameng Asal sudah siap. Ini memerlukan waktu beberapa menit.

------
#### [ CloudFormation ]

Untuk mengaktifkan Origin Shield dengan CloudFormation, gunakan `OriginShield` properti dalam jenis `Origin` properti dalam `AWS::CloudFront::Distribution` sumber daya. Anda dapat menambahkan `OriginShield` menjadi `Origin`, atau masukkan saat Anda membuat `Origin`.

Contoh berikut menunjukkan sintaks, dalam format YAML, untuk memungkinkan `OriginShield` di Wilayah (Oregon) Barat AS (`us-west-2`). Untuk bantuan memilih Wilayah, lihat [Pilih AWS Wilayah untuk Origin Shield](#choose-origin-shield-region). Contoh ini hanya menunjukkan `Origin` jenis properti, bukan keseluruhan `AWS::CloudFront::Distribution` sumber daya.

```
Origins:
- DomainName: 3ae97e9482b0d011.mediapackage.us-west-2.amazonaws.com
  Id: Example-EMP-3ae97e9482b0d011
  OriginShield:
    Enabled: true
    OriginShieldRegion: us-west-2
  CustomOriginConfig:
    OriginProtocolPolicy: match-viewer
    OriginSSLProtocols: TLSv1
```

Untuk informasi selengkapnya, lihat [AWS::CloudFront::Distribution Asal](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html) di bagian referensi sumber daya dan properti di *Panduan AWS CloudFormation Pengguna*.

------
#### [ API ]

Untuk mengaktifkan Origin Shield dengan CloudFront API menggunakan AWS SDKs or AWS Command Line Interface (AWS CLI), gunakan `OriginShield` tipe. Anda menentukan `OriginShield` dalam `Origin`, dalam `DistributionConfig`. Untuk informasi tentang `OriginShield` jenisnya, lihat informasi berikut di *Referensi Amazon CloudFront API*.
+ [OriginShield](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginShield.html) (jenis)
+ [Asal](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_Origin.html) (jenis)
+ [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html) (jenis)
+ [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) (operasi)
+ [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) (operasi)

Sintaks spesifik untuk menggunakan jenis dan operasi ini berbeda-beda berdasarkan klien SDK, CLI, atau API. Untuk informasi lebih lanjut, lihat dokumentasi referensi untuk SDK, CLI, atau klien Anda.

------

## Perkirakan biaya Origin Shield
<a name="origin-shield-costs"></a>

Anda mengakumulasikan biaya untuk Tameng Asal berdasarkan jumlah permintaan yang masuk ke Tameng Asal sebagai lapisan tambahan.

 Untuk permintaan dinamis (non-cacheable) yang berhubungan dengan asal usul, Shield Asal selalu merupakan lapisan tambahan. Permintaan dinamis menggunakan metode HTTP`PUT`,`POST`,`PATCH`, dan`DELETE`.

`GET`dan `HEAD` permintaan yang memiliki pengaturan waktu untuk hidup (TTL) kurang dari 3600 detik dianggap sebagai permintaan dinamis. Selain itu, `GET` dan `HEAD` permintaan yang telah menonaktifkan caching juga dianggap permintaan dinamis.

Untuk memperkirakan biaya untuk Shield Asal untuk permintaan dinamis, gunakan rumus berikut:

Total jumlah permintaan dinamis **x** Biaya Tameng Asal per 10.000 permintaan **/** 10.000

Untuk permintaan non-dinamis dengan metode HTTP`GET`,, dan `HEAD``OPTIONS`, Origin Shield terkadang merupakan lapisan tambahan. Ketika Anda mengaktifkan Origin Shield, Anda memilih Wilayah AWS untuk Origin Shield. Untuk permintaan yang secara alami masuk ke [cache tepi regional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) di Region yang sama dengan Origin Shield, Origin Shield bukanlah lapisan tambahan. Anda tidak dikenakan biaya Origin Shield untuk permintaan ini. Untuk permintaan yang masuk ke cache edge regional di Region yang berbeda dari Origin Shield, dan kemudian pergi ke Origin Shield, Origin Shield adalah lapisan tambahan. Anda mengakumulasikan biaya Tameng Asal untuk permintaan ini.

Untuk memperkirakan biaya Anda untuk Perisai Asal untuk permintaan yang dapat disimpan, gunakan rumus berikut:

Total jumlah permintaan yang dapat disimpan **x** (1 – laju ketukan cache) **x** persentase permintaan yang masuk ke Origin Shield dari edge cache regional di wilayah yang berbeda **x** Biaya Tameng Asal per 10.000 permintaan **/** 10.000

Untuk informasi lebih lanjut tentang biaya per 10.000 permintaan untuk Origin Shield, lihat [CloudFront Harga](https://aws.amazon.com/cloudfront/pricing/).

## Ketersediaan tinggi Origin Shield
<a name="origin-shield-high-availability"></a>

Origin Shield memanfaatkan fitur [cache edge CloudFront regional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches). Masing-masing cache edge ini dibangun di AWS Wilayah menggunakan setidaknya tiga [Availability Zone dengan armada instans](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) Amazon EC2 auto-scaling. Koneksi dari CloudFront Lokasi ke Tameng Asal juga menggunakan pelacakan kesalahan aktif untuk setiap permintaan untuk secara otomatis mengirimkan permintaan ke lokasi Tameng Asal sekunder jika lokasi Perisai Asal primer tidak tersedia.

## Bagaimana Origin Shield berinteraksi dengan fitur lain CloudFront
<a name="origin-shield-and-other-features"></a>

Bagian berikut menjelaskan bagaimana Origin Shield berinteraksi dengan CloudFront yang berbeda.

### Origin Shield dan CloudFront logging
<a name="origin-shield-logging"></a>

Untuk melihat kapan Origin Shield menangani permintaan, Anda harus mengaktifkan salah satu dari yang berikut:
+ [CloudFront log standar (log akses)](AccessLogs.md). Catatan standar disediakan secara gratis.
+ [CloudFront log akses real-time](real-time-logs.md). Anda dikenakan biaya tambahan untuk menggunakan log akses real-time. Lihat [Amazon CloudFront Harga](https://aws.amazon.com/cloudfront/pricing/).

Cache hits dari Origin Shield muncul seperti `OriginShieldHit` di `x-edge-detailed-result-type` bidang di CloudFront log. Origin Shield memanfaatkan [cache edge regional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) Amazon CloudFront. Jika permintaan dirutekan dari lokasi CloudFront tepi ke cache tepi regional yang bertindak sebagai Origin Shield, permintaan tersebut dilaporkan sebagai a `Hit` di log, bukan sebagai`OriginShieldHit`.

### Origin Shield dan kelompok asal
<a name="origin-shield-and-origin-group"></a>

Origin Shield kompatibel dengan [CloudFront kelompok asal](high_availability_origin_failover.md). Karena Origin Shield adalah properti asal, permintaan selalu melakukan perjalanan melalui Origin Shield untuk setiap asal bahkan ketika asal-usul adalah bagian dari kelompok asal. Untuk permintaan tertentu, CloudFront merutekan permintaan ke asal utama dalam grup asal melalui Origin Shield asal utama. Jika permintaan tersebut gagal (sesuai dengan kriteria failover grup asal), CloudFront rutekan permintaan ke asal sekunder melalui Origin Shield asal sekunder.

### Perisai Asal dan Lambda@Edge
<a name="origin-shield-and-lambda-at-edge"></a>

Origin Shield tidak memengaruhi fungsionalitas dari fungsi [Lambda@Edge](lambda-at-the-edge.md) namun dapat memengaruhi Wilayah AWS tempat fungsi tersebut dijalankan.

Saat Anda menggunakan Origin Shield dengan Lambda @Edge, [pemicu yang menghadap ke](lambda-cloudfront-trigger-events.md) asal (permintaan asal dan respons asal) berjalan di Wilayah AWS tempat Origin Shield diaktifkan. Jika lokasi Origin Shield utama tidak tersedia dan CloudFront merutekan permintaan ke lokasi Origin Shield sekunder, pemicu Lambda @Edge yang menghadap ke asal juga akan bergeser untuk menggunakan lokasi Origin Shield sekunder.

Pemicu yang berhadapan dengan penampil tidak terpengaruh.

# Optimalkan ketersediaan tinggi dengan failover CloudFront asal
<a name="high_availability_origin_failover"></a>

Anda dapat mengatur CloudFront dengan failover asal untuk skenario yang memerlukan ketersediaan tinggi. Untuk memulai, Anda membuat *grup asal* dengan dua asal usul: primer dan sekunder. Jika asal primer tidak tersedia, atau mengembalikan kode status respons HTTP tertentu yang menunjukkan kegagalan, CloudFront secara otomatis beralih ke asal sekunder.

Untuk mengatur failover asal, Anda harus memiliki distribusi dengan setidaknya dua asal. Selanjutnya, Anda membuat grup asal untuk distribusi Anda yang mencakup dua asal, menetapkan satu sebagai yang utama. Terakhir, Anda membuat atau memperbarui perilaku cache untuk menggunakan grup asal.

Untuk melihat langkah-langkah pengaturan grup asal dan konfigurasi opsi failover asal tertentu, lihat [Buat grup asal](#concept_origin_groups.creating).

Setelah Anda mengonfigurasi failover asal untuk perilaku cache, CloudFront lakukan hal berikut untuk permintaan penampil:
+ Ketika ada hit cache, CloudFront mengembalikan objek yang diminta.
+ Saat ada cache yang hilang, CloudFront rutekan permintaan ke asal utama di grup asal.
+ Ketika asal utama mengembalikan kode status yang tidak dikonfigurasi untuk failover, seperti kode status HTTP 2xx atau 3xx, CloudFront menyajikan objek yang diminta ke penampil.
+ Jika terjadi hal-hal berikut:
  + Asal utama mengembalikan kode status HTTP yang telah Anda konfigurasikan untuk failover
  + CloudFront gagal terhubung ke asal utama (ketika 503 disetel sebagai kode failover)
  + Respons dari asal utama memakan waktu terlalu lama (waktu habis) (ketika 504 disetel sebagai kode failover)

  Kemudian CloudFront rute permintaan ke asal sekunder di grup asal.
**catatan**  
Untuk beberapa kasus penggunaan, seperti streaming konten video, Anda mungkin CloudFront ingin gagal ke asal sekunder dengan cepat. Untuk menyesuaikan seberapa cepat CloudFront gagal ke asal sekunder, lihat[Kontrol batas waktu dan upaya asal](#controlling-attempts-and-timeouts).

CloudFront merutekan semua permintaan yang masuk ke asal primer, bahkan ketika permintaan sebelumnya gagal ke asal sekunder. CloudFront hanya mengirim permintaan ke asal sekunder setelah permintaan ke asal primer gagal.

CloudFront gagal ke asal sekunder hanya jika metode HTTP dari permintaan penampil adalah`GET`,`HEAD`, atau`OPTIONS`. CloudFront tidak gagal ketika penampil mengirim metode HTTP yang berbeda (misalnya`POST`,`PUT`, dan sebagainya).

**catatan**  
CloudFront tidak akan failover jika tidak `OPTIONS` disetel sebagai [Metode HTTP yang di-cache](DownloadDistValuesCacheBehavior.md#DownloadDistValuesCachedHTTPMethods) perilaku cache Anda.

Diagram berikut menggambarkan cara kerja failover asal.

![\[Bagaimana cara kerja failover asal\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-overview.png)


**Topics**
+ [

## Buat grup asal
](#concept_origin_groups.creating)
+ [

## Kontrol batas waktu dan upaya asal
](#controlling-attempts-and-timeouts)
+ [

## Gunakan failover asal dengan fungsi Lambda@Edge
](#concept_origin_groups.lambda)
+ [

## Gunakan halaman kesalahan kustom dengan failover asal
](#concept_origin_groups.custom-error)

## Buat grup asal
<a name="concept_origin_groups.creating"></a><a name="create-origin-groups-procedure"></a>

**Untuk membuat grup asal**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih distribusi yang ingin Anda buat sebagai grup asal.

1. Pilih tab **Origins**.

1. Pastikan distribusi memiliki lebih dari satu asal. Jika tidak, tambahkan asal kedua.

1. Pada tab **Origins**, di panel **Grup asal**, pilih **Buat grup asal**.

1. Pilih asal untuk grup asal. Setelah Anda menambahkan asal, gunakan panah untuk menetapkan prioritas—yaitu, asal mana yang utama dan yang kedua.

1. Masukkan nama untuk grup asal.

1. Pilih kode status HTTP untuk digunakan sebagai kriteria failover. Anda dapat memilih kombinasi kode status berikut: 400, 403, 404, 416, 429, 500, 502, 503, atau 504. Ketika CloudFront menerima respons dengan salah satu kode status yang Anda tentukan, itu gagal ke asal sekunder.
**catatan**  
CloudFront gagal ke asal sekunder hanya jika metode HTTP dari permintaan penampil adalah`GET`,`HEAD`, atau`OPTIONS`. CloudFront tidak gagal ketika penampil mengirim metode HTTP yang berbeda (misalnya`POST`,`PUT`, dan sebagainya).

1. Di bawah **Kriteria pemilihan Asal**, tentukan bagaimana asal Anda dipilih saat distribusi Anda merutekan permintaan penampil. Anda dapat memilih opsi berikut.  
**Default**  
CloudFront akan menggunakan prioritas asal default yang Anda tentukan di halaman **Pengaturan**.  
**Skor kualitas media**  
CloudFront melacak dan menggunakan skor ini untuk menentukan asal pertama untuk meneruskan permintaan ke. Ini juga mengizinkan CloudFront untuk membuat `HEAD` permintaan asinkron ke asal alternatif di grup asal untuk menentukan skor kualitas medianya. Anda hanya dapat memilih opsi ini untuk asal AWS Elemental MediaPackage v2. Untuk informasi selengkapnya, lihat [Ketahanan sadar kualitas media](media-quality-score.md). 

1. Pilih **Buat grup asal**.

Pastikan untuk menetapkan grup asal Anda sebagai asal untuk perilaku cache distribusi Anda. Untuk informasi selengkapnya, lihat [Nama](DownloadDistValuesOrigin.md#DownloadDistValuesId).

## Kontrol batas waktu dan upaya asal
<a name="controlling-attempts-and-timeouts"></a>

Secara default, CloudFront mencoba untuk terhubung ke asal utama dalam grup asal selama 30 detik (3 upaya koneksi masing-masing 10 detik) sebelum gagal ke asal sekunder. Untuk beberapa kasus penggunaan, seperti streaming konten video, Anda mungkin CloudFront ingin gagal ke asal sekunder lebih cepat. Anda dapat menyesuaikan pengaturan berikut untuk memengaruhi seberapa cepat CloudFront gagal ke asal sekunder. Jika asal adalah asal sekunder, atau asal yang bukan bagian dari grup asal, pengaturan ini memengaruhi seberapa cepat CloudFront mengembalikan respons HTTP 504 ke penampil.

Untuk gagal dengan lebih cepat, tentukan waktu koneksi yang lebih singkat, lebih sedikit upaya koneksi, atau keduanya. Untuk asal kustom (termasuk asal bucket Amazon S3 yang *adalah* dikonfigurasi dengan hosting situs web statis), Anda juga dapat menyesuaikan waktu habis respons asal.

**Waktu habis koneksi asal**  
Pengaturan batas waktu koneksi asal memengaruhi berapa lama CloudFront menunggu ketika mencoba membuat koneksi ke asal. Secara default, CloudFront tunggu 10 detik untuk membuat koneksi, tetapi Anda dapat menentukan 1-10 detik (inklusif). Untuk informasi selengkapnya, lihat [Batas waktu koneksi](DownloadDistValuesOrigin.md#origin-connection-timeout).

**Upaya koneksi asal**  
Pengaturan upaya koneksi asal mempengaruhi berapa kali CloudFront upaya untuk terhubung ke asal. Secara default, CloudFront coba 3 kali untuk terhubung, tetapi Anda dapat menentukan 1-3 (inklusif). Untuk informasi selengkapnya, lihat [Upaya koneksi](DownloadDistValuesOrigin.md#origin-connection-attempts).  
Untuk custom origin (termasuk bucket Amazon S3 yang dikonfigurasi dengan hosting situs web statis), pengaturan ini juga memengaruhi berapa kali CloudFront upaya mendapatkan respons dari asal jika terjadi batas waktu respons asal.

**Waktu habis untuk respons asal**  
Batas waktu respons asal, juga dikenal sebagai batas waktu baca asal, memengaruhi berapa lama CloudFront menunggu untuk menerima respons (atau untuk menerima respons lengkap) dari asal. Secara default, CloudFront menunggu selama 30 detik, tetapi Anda dapat menentukan 1-120 detik (inklusif). Untuk informasi selengkapnya, lihat [Batas waktu respons](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).

### Cara mengubah pengaturan ini
<a name="controlling-attempts-and-timeouts-how-to"></a>

**Untuk mengubah pengaturan ini di [CloudFrontkonsol](https://console.aws.amazon.com/cloudfront/v4/home)**
+ Untuk asal baru atau distribusi baru, Anda menentukan nilai ini saat membuat sumber daya.
+ Untuk asal yang sudah ada dalam distribusi yang sudah ada, Anda menentukan nilai ini saat mengedit asal.

Untuk informasi selengkapnya, lihat [Semua referensi pengaturan distribusi](distribution-web-values-specify.md).

## Gunakan failover asal dengan fungsi Lambda@Edge
<a name="concept_origin_groups.lambda"></a>

Anda dapat menggunakan fungsi Lambda @Edge dengan CloudFront distribusi yang telah Anda atur dengan grup asal. Untuk menggunakan fungsi Lambda, tentukan di [permintaan asal usul atau pemicu respons asal](lambda-cloudfront-trigger-events.md) untuk grup asal ketika Anda membuat perilaku cache. Saat Anda menggunakan fungsi Lambda@Edge dengan grup asal, fungsi ini dapat dipicu dua kali untuk permintaan penampil tunggal. Misalnya, pertimbangkan skenario ini:

1. Anda membuat fungsi Lambda@Edge dengan pemicu permintaan asal.

1. Fungsi Lambda dipicu sekali saat CloudFront mengirim permintaan ke asal utama (pada cache yang hilang).

1. Asal utama merespons dengan kode status HTTP yang dikonfigurasi untuk failover.

1. Fungsi Lambda dipicu lagi saat CloudFront mengirim permintaan yang sama ke asal sekunder.

Diagram berikut menggambarkan cara kerja asal-usul saat Anda menyertakan fungsi Lambda@Edge dalam permintaan asal usul atau pemicu respons.

![\[Bagaimana cara kerja awal failover menggunakan fungsi Lambda@Edge\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-with-lambda-edge.png)


Untuk informasi lebih lanjut tentang menggunakan pemicu Lambda@Edge, lihat [Tambahkan pemicu untuk fungsi Lambda @Edge](lambda-edge-add-triggers.md).

Untuk informasi selengkapnya tentang mengelola failover DNS, lihat [Mengonfigurasi failover DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) di Panduan Pengembang *Amazon Route 53*.

## Gunakan halaman kesalahan kustom dengan failover asal
<a name="concept_origin_groups.custom-error"></a>

Anda dapat menggunakan halaman kesalahan kustom dengan grup asal yang serupa dengan cara Anda menggunakannya dengan asal yang tidak disiapkan untuk failover asal. 

Saat Anda menggunakan failover asal, Anda dapat mengonfigurasi CloudFront untuk mengembalikan halaman kesalahan kustom untuk asal primer atau sekunder (atau keduanya):
+ **Mengembalikan halaman kesalahan kustom untuk asal utama** — Jika asal utama mengembalikan kode status HTTP yang tidak dikonfigurasi untuk failover, CloudFront mengembalikan halaman kesalahan kustom ke pemirsa.
+ **Mengembalikan halaman kesalahan kustom untuk asal sekunder** - Jika CloudFront menerima kode status kegagalan dari asal sekunder, CloudFront mengembalikan halaman kesalahan kustom.

Untuk informasi selengkapnya tentang menggunakan halaman kesalahan kustom dengan CloudFront, lihat[Hasilkan respons kesalahan khusus](GeneratingCustomErrorResponses.md).

# Mengelola berapa lama konten tetap dalam cache (kedaluwarsa)
<a name="Expiration"></a>

Anda dapat mengontrol berapa lama file Anda berada dalam CloudFront cache sebelum CloudFront meneruskan permintaan lain ke asal Anda. Mengurangi durasi memungkinkan Anda untuk melayani konten dinamis. Peningkatan durasi berarti bahwa pengguna Anda mendapatkan kinerja yang lebih baik karena file Anda lebih mungkin dilayani secara langsung dari edge cache. Durasi yang lebih lama juga mengurangi beban yang berasal dari Anda.

Biasanya, CloudFront menyajikan file dari lokasi tepi hingga durasi cache yang Anda tentukan lewat — yaitu, hingga file kedaluwarsa. Setelah kedaluwarsa, saat berikutnya lokasi tepi mendapat permintaan untuk file tersebut, CloudFront teruskan permintaan ke asal untuk memverifikasi bahwa cache berisi versi terbaru dari file tersebut. Tanggapan dari sumber tergantung pada apakah file telah berubah:
+ Jika CloudFront cache sudah memiliki versi terbaru, asal mengembalikan kode status`304 Not Modified`.
+ Jika CloudFront cache tidak memiliki versi terbaru, asal mengembalikan kode status `200 OK` dan versi terbaru file.

Jika file di lokasi tepi tidak sering diminta, CloudFront mungkin mengusir file — hapus file sebelum tanggal kedaluwarsa — untuk memberi ruang bagi file yang telah diminta baru-baru ini.

Sebaiknya mengelola durasi cache Anda dengan memperbarui kebijakan cache distribusi Anda. Jika Anda memilih untuk tidak menggunakan kebijakan cache, TTL default (Time to Live) adalah 24 jam, tetapi Anda dapat memperbarui pengaturan berikut untuk mengganti default:
+ Untuk mengubah durasi cache untuk semua file yang cocok dengan pola jalur yang sama, Anda dapat mengubah CloudFront pengaturan untuk TTL **Minimum, TTL** **Maksimum, dan TTL** **Default untuk perilaku** cache. Untuk informasi tentang pengaturan individual, lihat[TTL Minimum](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL),[TTL Maksimum](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL), dan[TTL bawaan](DownloadDistValuesCacheBehavior.md#DownloadDistValuesDefaultTTL).
+ Untuk mengubah durasi cache untuk file individual, Anda dapat mengonfigurasi asal Anda untuk menambahkan `Cache-Control` header dengan `max-age` atau `s-maxage` direktif, atau `Expires` header ke file. Untuk informasi selengkapnya, lihat [Gunakan header untuk mengontrol durasi cache untuk masing-masing objek](#expiration-individual-objects).

Untuk informasi selengkapnya tentang bagaimana **TTL Minimum**, **TTL Default**, dan **TTL Maksimum** berinteraksi dengan `s-maxage` arahan `max-age` dan bidang `Expires` header, lihat. [Tentukan jumlah waktu yang menyimpan objek dalam CloudFront cache](#ExpirationDownloadDist)

Anda juga dapat mengontrol berapa lama kesalahan (misalnya,`404 Not Found`) tinggal di CloudFront cache sebelum CloudFront mencoba lagi untuk mendapatkan objek yang diminta dengan meneruskan permintaan lain ke asal Anda. Untuk informasi selengkapnya, lihat [Bagaimana CloudFront memproses kode status HTTP 4xx dan 5xx dari asal Anda](HTTPStatusCodes.md).

**Topics**
+ [

## Gunakan header untuk mengontrol durasi cache untuk masing-masing objek
](#expiration-individual-objects)
+ [

## Sajikan konten basi (kedaluwarsa)
](#stale-content)
+ [

## Tentukan jumlah waktu yang menyimpan objek dalam CloudFront cache
](#ExpirationDownloadDist)
+ [

## Tambahkan header ke objek Anda dengan menggunakan konsol Amazon S3
](#ExpirationAddingHeadersInS3)

## Gunakan header untuk mengontrol durasi cache untuk masing-masing objek
<a name="expiration-individual-objects"></a>

Anda dapat menggunakan `Cache-Control` dan `Expires` header untuk mengontrol berapa lama objek tetap berada di dalam cache. Pengaturan untuk **TTL Minimum**, **TTL bawaan**, dan **TTL Maksimum ** juga memengaruhi durasi cache, tetapi berikut ini gambaran umum tentang bagaimana header dapat memengaruhi durasi cache: 
+ `Cache-Control max-age`Direktif memungkinkan Anda menentukan berapa lama (dalam detik) bahwa Anda ingin objek tetap berada di cache sebelum CloudFront mendapatkan objek lagi dari server asal. CloudFrontDukungan waktu kedaluwarsa minimum adalah 0 detik. Nilai maksimumnya adalah 100 tahun. Tentukan nilai dalam format berikut:

  `Cache-Control: max-age=`*seconds*

  Misalnya, arahan berikut memberitahu CloudFront untuk menyimpan objek terkait dalam cache selama 3600 detik (satu jam):

  `Cache-Control: max-age=3600`

  Jika Anda ingin objek tetap berada di cache CloudFront tepi untuk durasi yang berbeda dari yang berada di cache browser, Anda dapat menggunakan `Cache-Control s-maxage` arahan `Cache-Control max-age` dan bersama-sama. Untuk informasi selengkapnya, lihat [Tentukan jumlah waktu yang menyimpan objek dalam CloudFront cache](#ExpirationDownloadDist).
+ `Expires` kolom header memungkinkan Anda menentukan tanggal dan waktu kedaluwarsa menggunakan format yang ditentukan dalam [RFC 2616, Protokol Transfer Hiperteks -- HTTP/1.1 Bagian 3.3.1, Tanggal Penuh](https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1), misalnya:

  `Sat, 27 Jun 2015 23:59:59 GMT`

Kami sarankan Anda menggunakan `Cache-Control max-age` lebih langsung, bukan `Expires` kolom header untuk mengontrol caching objek. Jika Anda menentukan nilai baik untuk `Cache-Control max-age` dan untuk`Expires`, hanya CloudFront menggunakan nilai`Cache-Control max-age`.

Untuk informasi selengkapnya, lihat [Tentukan jumlah waktu yang menyimpan objek dalam CloudFront cache](#ExpirationDownloadDist).

Anda tidak dapat menggunakan bidang HTTP `Cache-Control` atau `Pragma` header dalam `GET` permintaan dari penampil CloudFront untuk memaksa kembali ke server asal untuk objek tersebut. CloudFront mengabaikan bidang header tersebut dalam permintaan penampil.

Untuk informasi lebih lanjut tentang `Cache-Control` dan `Expires` kolom header, lihat bagian berikut di *RFC 2616, Protokol Transfer Hiperteks -- HTTP/1.1*: 
+ [Bagian 14.9 Kontrol Cache](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9)
+ [Bagian 14.21 Kedaluwarsa](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21)

## Sajikan konten basi (kedaluwarsa)
<a name="stale-content"></a>

CloudFront mendukung arahan kontrol `Stale-While-Revalidate` dan `Stale-If-Error` cache. Anda dapat menggunakan arahan ini untuk menentukan berapa lama konten basi tersedia untuk pemirsa.

**Topics**
+ [

### `Stale-While-Revalidate`
](#stale-while-revalidate)
+ [

### `Stale-If-Error`
](#stale-if-error-only)
+ [

### Gunakan kedua arahan
](#use-both-stale-directives)

### `Stale-While-Revalidate`
<a name="stale-while-revalidate"></a>

Arahan ini memungkinkan CloudFront untuk menyajikan konten basi dari cache sementara secara CloudFront asinkron mengambil versi baru dari asal. Ini meningkatkan latensi karena pemirsa menerima tanggapan langsung dari lokasi tepi tanpa harus menunggu pengambilan latar belakang. Konten segar dimuat di latar belakang untuk permintaan future.

**Example Contoh: `Stale-While-Revalidate`**  
CloudFront melakukan hal berikut ketika Anda mengatur `Cache-Control` header untuk menggunakan arahan ini.   

```
Cache-Control: max-age=3600, stale-while-revalidate=600
```

1. CloudFront akan menyimpan respons selama satu jam (`max-age=3600`).

1. Jika permintaan dibuat setelah durasi ini, CloudFront menyajikan konten basi, sementara secara bersamaan mengirim permintaan ke asal untuk memvalidasi ulang dan menyegarkan konten yang di-cache. 

1. Saat konten sedang divalidasi ulang, CloudFront menyajikan konten basi hingga 10 menit (). `stale-while-revalidate=600`

**catatan**  
CloudFront akan menyajikan konten basi hingga nilai `stale-while-revalidate` direktif atau nilai [TTL CloudFront maksimum](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL), mana yang kurang. Setelah durasi TTL maksimum, objek basi tidak akan tersedia dari cache tepi, terlepas dari nilainya. `stale-while-revalidate` 

### `Stale-If-Error`
<a name="stale-if-error-only"></a>

Arahan ini memungkinkan CloudFront untuk menyajikan konten basi dari cache jika asal tidak dapat dijangkau atau mengembalikan kode kesalahan antara 500 dan 600. Ini memastikan bahwa pemirsa dapat mengakses konten bahkan selama pemadaman asal.

**Example Contoh: `Stale-If-Error`**  
CloudFront melakukan hal berikut ketika Anda mengatur `Cache-Control` header untuk menggunakan arahan ini.   

```
Cache-Control: max-age=3600, stale-if-error=86400
```

1. CloudFront cache respons selama satu jam (`max-age=3600`).

1. Jika asal tidak aktif atau mengembalikan kesalahan setelah durasi ini, CloudFront terus menyajikan konten basi hingga 24 jam () `stale-if-error=86400`

1. Jika Anda mengonfigurasi respons kesalahan kustom, CloudFront akan mencoba menyajikan konten basi jika terjadi kesalahan dalam `stale-if-error` durasi yang ditentukan. Jika konten basi tidak tersedia, maka CloudFront akan menyajikan respons kesalahan kustom yang Anda konfigurasikan untuk kode status kesalahan yang sesuai. Untuk informasi selengkapnya, lihat [Hasilkan respons kesalahan khusus](GeneratingCustomErrorResponses.md).

**Catatan**  
CloudFront akan menyajikan konten basi hingga nilai `stale-if-error` direktif atau nilai [TTL CloudFront maksimum](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL), mana yang kurang. Setelah durasi TTL maksimum, objek basi tidak akan tersedia dari cache tepi, terlepas dari nilainya. `stale-if-error` 
Jika Anda tidak mengonfigurasi `stale-if-error` atau respons kesalahan kustom, CloudFront akan mengembalikan objek basi atau meneruskan respons kesalahan kembali ke penampil, tergantung pada apakah objek yang diminta ada di cache tepi atau tidak. Untuk informasi selengkapnya, lihat [Cara CloudFront memproses kesalahan jika Anda belum mengonfigurasi halaman kesalahan kustom](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages).

### Gunakan kedua arahan
<a name="use-both-stale-directives"></a>

Keduanya `stale-while-revalidate` dan `stale-if-error` merupakan arahan kontrol cache independen yang dapat Anda gunakan bersama untuk mengurangi latensi dan menambahkan buffer agar asal Anda merespons atau memulihkan.

**Example Contoh: Menggunakan kedua arahan**  
CloudFront melakukan hal berikut ketika Anda mengatur `Cache-Control` header untuk menggunakan arahan berikut.   

```
Cache-Control: max-age=3600, stale-while-revalidate=600, stale-if-error=86400
```

1. CloudFront cache respons selama satu jam (`max-age=3600`). 

1. Jika permintaan dibuat setelah durasi ini, CloudFront menyajikan konten basi hingga 10 menit (`stale-while-revalidate=600`) saat konten sedang divalidasi ulang. 

1. Jika server asal mengembalikan kesalahan saat CloudFront mencoba memvalidasi ulang konten, CloudFront akan terus menyajikan konten basi hingga 24 jam (). `stale-if-error=86400`

Caching adalah keseimbangan antara kinerja dan kesegaran. Menggunakan arahan seperti `stale-while-revalidate` dan `stale-if-error` dapat meningkatkan kinerja dan pengalaman pengguna, tetapi pastikan konfigurasi selaras dengan seberapa segar konten yang Anda inginkan. Arahan konten basi paling cocok untuk kasus penggunaan di mana konten perlu disegarkan tetapi memiliki versi terbaru tidak penting. Selain itu, jika konten Anda tidak berubah atau jarang berubah, `stale-while-revalidate` dapat menambahkan permintaan jaringan yang tidak perlu. Sebagai gantinya, pertimbangkan untuk mengatur durasi cache yang panjang.

## Tentukan jumlah waktu yang menyimpan objek dalam CloudFront cache
<a name="ExpirationDownloadDist"></a>

Untuk mengontrol jumlah waktu yang CloudFront menyimpan objek dalam cache sebelum mengirim permintaan lain ke asal, Anda dapat:
+ Tetapkan nilai TTL minimum, maksimum, dan default dalam perilaku cache CloudFront distribusi. Anda dapat mengatur nilai-nilai ini dalam [kebijakan cache](controlling-the-cache-key.md) yang melekat pada perilaku cache (disarankan), atau dalam pengaturan cache warisan.
+ Sertakan `Cache-Control` atau `Expires` header dalam tanggapan dari asal. Header ini juga membantu menentukan berapa lama browser menyimpan objek di cache browser sebelum mengirim permintaan lain. CloudFront

Tabel berikut menjelaskan bagaimana header `Cache-Control` dan `Expires` yang dikirim dari asal digunakan bersama dengan pengaturan TTL dalam perilaku cache untuk memengaruhi caching.


****  

| Header asal | TTL minimum = 0 | TTL Minimum> 0 | 
| --- | --- | --- | 
|  **Asal menambahkan `Cache-Control: max-age` direktif ke objek**  |  **CloudFront caching** CloudFront cache objek untuk yang lebih rendah dari nilai `Cache-Control: max-age` direktif atau nilai TTL maksimum. CloudFront  **Caching browser** Browser menyimpan cache objek untuk nilai arahan `Cache-Control: max-age`.  |  **CloudFront caching** CloudFront caching tergantung pada nilai TTL CloudFront minimum dan TTL maksimum dan arahan: `Cache-Control max-age` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Caching browser** Browser menyimpan cache objek untuk nilai arahan `Cache-Control: max-age`.  | 
|  **Asal tidak menambahkan `Cache-Control: max-age` direktif ke objek**  |  **CloudFront caching** CloudFront cache objek untuk nilai TTL CloudFront default. **Caching browser** Tergantung pada peramban.  |  **CloudFront caching** CloudFront cache objek untuk nilai TTL CloudFront minimum atau TTL default yang lebih besar. **Caching browser** Tergantung pada peramban.  | 
|  **Asal menambahkan `Cache-Control: max-age` dan `Cache-Control: s-maxage` mengarahkan ke objek**  |  **CloudFront caching** CloudFront cache objek untuk yang lebih rendah dari nilai `Cache-Control: s-maxage` direktif atau nilai TTL maksimum. CloudFront  **Caching browser** Browser menyimpan cache objek untuk nilai arahan `Cache-Control max-age`.  |  **CloudFront caching** CloudFront caching tergantung pada nilai TTL CloudFront minimum dan TTL maksimum dan arahan: `Cache-Control: s-maxage` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Caching browser** Browser menyimpan cache objek untuk nilai arahan `Cache-Control: max-age`.  | 
|  **Asal menambahkan `Expires` header ke objek**  |  **CloudFront caching** CloudFront cache objek sampai tanggal di `Expires` header atau untuk nilai TTL CloudFront maksimum, mana yang lebih cepat. **Caching browser** Browser menyimpan cache objek hingga tanggal di header `Expires`.  |  **CloudFront caching** CloudFront caching tergantung pada nilai TTL CloudFront minimum dan TTL maksimum dan header: `Expires` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Caching browser** Browser menyimpan cache objek hingga tanggal dan waktu di header `Expires`.  | 
|  **Origin menambahkan `Cache-Control: no-cache``no-store`,, dan/atau `private` arahan ke objek**  |  CloudFront dan browser menghormati header.  |  **CloudFront caching** CloudFront cache objek untuk nilai TTL CloudFront minimum. [Lihat peringatan di bawah tabel ini](#stale-if-error). **Caching browser** Browser mematuhi header.  | 

**Awas**  
Jika TTL minimum Anda lebih besar dari 0, CloudFront gunakan TTL minimum kebijakan cache, meskipun and/or `private` arahan`Cache-Control: no-cache`,`no-store`, ada di header asal.  
Jika asal dapat dijangkau, CloudFront dapatkan objek dari asal dan kembalikan ke penampil.
Jika asal tidak dapat dijangkau dan nilai TTL minimum *atau* maksimum lebih besar dari 0, CloudFront akan melayani objek yang didapat dari asal sebelumnya.
Untuk menghindari perilaku ini, sertakan arahan `Cache-Control: stale-if-error=0` dengan objek yang dikembalikan dari asal. Hal ini menyebabkan CloudFront untuk mengembalikan kesalahan dalam menanggapi permintaan future jika asal tidak dapat dijangkau, daripada mengembalikan objek yang didapatnya dari asal sebelumnya.
CloudFront tidak menyimpan kode status HTTP 501 (Tidak Diimplementasikan) dari asal S3 saat header asal menyertakan arahan`Cache-Control: no-cache`,,`no-store`. and/or `private` Ini adalah perilaku default untuk asal S3, bahkan jika pengaturan [TTL minimum](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) Anda lebih besar dari 0.

Untuk informasi tentang cara mengubah pengaturan untuk distribusi menggunakan CloudFront konsol, lihat[Perbarui distribusi](HowToUpdateDistribution.md). Untuk informasi tentang cara mengubah setelan distribusi menggunakan CloudFront API, lihat [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).

## Tambahkan header ke objek Anda dengan menggunakan konsol Amazon S3
<a name="ExpirationAddingHeadersInS3"></a>

Anda dapat menambahkan bidang `Cache-Control` atau `Expires` header ke objek Amazon S3 Anda. Untuk melakukannya, Anda memodifikasi bidang metadata untuk objek.

**Untuk menambahkan bidang `Cache-Control` atau `Expires` header ke objek Amazon S3**

1. *Ikuti prosedur di bagian **Mengganti metadata yang ditentukan sistem pada metadata** [objek pengeditan dalam topik konsol Amazon S3 di Panduan Pengguna Amazon](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) S3.*

1. Untuk **Kunci**, pilih nama header yang Anda tambahkan (**Kontrol Cache** atau **Kedaluwarsa**).

1. Untuk **Nilai**, masukkan nilai header. Misalnya, untuk header `Cache-Control`, Anda bisa memasukkan `max-age=86400`. Untuk `Expires`, Anda dapat memasukkan tanggal kedaluwarsa dan waktu seperti `Wed, 30 Jun 2021 09:28:00 GMT`.

1. Ikuti prosedur lainnya untuk menyimpan perubahan metadata Anda.

# Konten cache berdasarkan parameter string kueri
<a name="QueryStringParameters"></a>

Beberapa aplikasi web menggunakan string pencarian untuk mengirimkan informasi ke sumber. String kueri adalah bagian dari permintaan web yang muncul setelah `?` karakter; string dapat berisi satu atau lebih parameter, dipisahkan oleh `&` karakter. Dalam contoh berikut, string query mencakup dua parameter, *color=red* dan*size=large*:

`https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`

Untuk distribusi, Anda dapat memilih apakah Anda CloudFront ingin meneruskan string kueri ke asal Anda dan apakah akan menyimpan konten Anda berdasarkan semua parameter atau parameter yang dipilih. Mengapa hal ini mungkin berguna? Pertimbangkan contoh berikut.

Misalkan situs web Anda tersedia dalam lima bahasa. Struktur direktori dan nama file untuk kelima versi situs web ini adalah identik. Saat pengguna melihat situs web Anda, permintaan yang diteruskan untuk CloudFront menyertakan parameter string kueri bahasa berdasarkan bahasa yang dipilih pengguna. Anda dapat mengonfigurasi CloudFront untuk meneruskan string kueri ke asal dan cache berdasarkan parameter bahasa. Jika Anda mengonfigurasi server web Anda untuk mengembalikan versi halaman tertentu yang sesuai dengan bahasa yang dipilih, CloudFront cache setiap versi bahasa secara terpisah, berdasarkan nilai parameter string kueri bahasa.

Dalam contoh ini, jika halaman utama untuk situs web Anda`main.html`, lima permintaan berikut CloudFront menyebabkan cache `main.html` lima kali, sekali untuk setiap nilai parameter string kueri bahasa:
+ `https://d111111abcdef8.cloudfront.net/main.html?language=de`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=en`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=es`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=fr`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=jp`

Perhatikan hal-hal berikut:
+ Beberapa server HTTP tidak memproses parameter string kueri dan, oleh karena itu, tidak mengembalikan versi objek yang berbeda berdasarkan nilai parameter. Untuk asal-usul ini, jika Anda mengonfigurasi CloudFront untuk meneruskan parameter string kueri ke asal, CloudFront tetap cache berdasarkan nilai parameter meskipun asal mengembalikan versi objek yang identik CloudFront untuk setiap nilai parameter.
+ Untuk parameter string pencarian agar berfungsi seperti yang dijelaskan dalam contoh di atas dengan bahasa, Anda harus menggunakan `&` karakter sebagai pembatas antara parameter string pencarian. Jika Anda menggunakan pembatas yang berbeda, Anda mungkin mendapatkan hasil yang tidak terduga, tergantung pada parameter mana yang Anda tentukan CloudFront untuk digunakan sebagai dasar untuk caching, dan urutan parameter yang muncul dalam string kueri.

  Contoh berikut menunjukkan apa yang terjadi jika Anda menggunakan pembatas yang berbeda dan Anda mengonfigurasi CloudFront ke cache hanya berdasarkan parameter: `color` 
  + Dalam permintaan berikut, CloudFront cache konten Anda berdasarkan nilai `color` parameter, tetapi CloudFront menafsirkan nilai sebagai: *red;size=large*

    `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red;size=large`
  + Dalam permintaan berikut, CloudFront cache konten Anda tetapi tidak mendasarkan caching pada parameter string kueri. Ini karena Anda CloudFront mengonfigurasi cache berdasarkan `color` parameter, tetapi CloudFront menafsirkan string berikut sebagai hanya berisi `size` parameter yang memiliki nilai*large;color=red*:

    `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large;color=red`

Anda dapat mengonfigurasi CloudFront untuk melakukan salah satu hal berikut:
+ Jangan meneruskan string kueri ke asal sama sekali. Jika Anda tidak meneruskan string kueri, CloudFront tidak cache berdasarkan parameter string kueri.
+ Teruskan string kueri ke asal, dan simpan berdasarkan semua parameter dalam string kueri.
+ Teruskan string kueri ke asal, dan cache berdasarkan parameter yang ditentukan dalam string kueri.

Untuk informasi selengkapnya, lihat [Optimalkan caching](#query-string-parameters-optimizing-caching).

**Topics**
+ [

## Pengaturan konsol dan API untuk penerusan string dan caching kueri
](#query-string-parameters-console)
+ [

## Optimalkan caching
](#query-string-parameters-optimizing-caching)
+ [

## Parameter string kueri dan log CloudFront standar (log akses)
](#query-string-parameters-access-logs)

## Pengaturan konsol dan API untuk penerusan string dan caching kueri
<a name="query-string-parameters-console"></a>

Saat Anda membuat distribusi di CloudFront konsol, CloudFront mengonfigurasi penerusan string kueri dan caching untuk Anda berdasarkan tipe asal Anda. Secara opsional, Anda dapat mengedit pengaturan ini secara manual. Untuk informasi selengkapnya, lihat pengaturan berikut di[Semua referensi pengaturan distribusi](distribution-web-values-specify.md):
+ [Penerusan string kueri dan caching](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryString)
+ [Daftar izin string kueri](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryStringAllowlist)

Untuk mengonfigurasi penerusan dan caching string kueri dengan CloudFront API, lihat [CachePolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CachePolicy.html)dan di [OriginRequestPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginRequestPolicy.html)Referensi *Amazon CloudFront * API.

## Optimalkan caching
<a name="query-string-parameters-optimizing-caching"></a>

Saat Anda CloudFront mengonfigurasi cache berdasarkan parameter string kueri, Anda dapat mengambil langkah-langkah berikut untuk mengurangi jumlah permintaan yang CloudFront diteruskan ke asal Anda. Saat lokasi CloudFront tepi menyajikan objek, Anda mengurangi beban di server asal dan mengurangi latensi karena objek dilayani dari lokasi yang lebih dekat dengan pengguna Anda.

**Cache hanya berdasarkan parameter yang asal Anda mengembalikan versi objek yang berbeda**  
Untuk setiap parameter string kueri yang diteruskan aplikasi web AndaCloudFront, CloudFront teruskan permintaan ke asal Anda untuk setiap nilai parameter dan cache versi terpisah dari objek untuk setiap nilai parameter. Hal ini berlaku bahkan jika asal Anda selalu mengembalikan objek yang sama terlepas dari nilai parameter. Untuk parameter multipel, jumlah permintaan dan jumlah objek berlipat ganda.  
Sebaiknya Anda CloudFront mengonfigurasi cache hanya berdasarkan parameter string kueri yang asal Anda mengembalikan versi yang berbeda, dan Anda mempertimbangkan dengan cermat manfaat caching berdasarkan setiap parameter. Misalnya, Anda memiliki situs web ritel. Ada gambar jaket dengan enam warna berbeda, dan jaket ini tersedia dalam 10 ukuran berbeda. Gambar yang Anda miliki pada jaket menunjukkan warna yang berbeda tetapi tidak berbeda ukuran. Untuk mengoptimalkan caching, Anda harus CloudFront mengkonfigurasi cache hanya berdasarkan parameter warna, bukan pada parameter ukuran. Ini meningkatkan kemungkinan yang CloudFront dapat melayani permintaan dari cache, yang meningkatkan kinerja dan mengurangi beban pada asal Anda.

**Selalu daftar parameter dalam urutan yang sama**  
Urutan parameter penting dalam string kueri. Dalam contoh berikut, string kueri identik kecuali bahwa parameter berada dalam urutan yang berbeda. Hal ini menyebabkan CloudFront untuk meneruskan dua permintaan terpisah untuk image.jpg ke asal Anda dan untuk cache dua versi terpisah dari objek:  
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large&color=red`
Kami menyarankan Anda untuk selalu mencantumkan nama parameter dalam urutan yang sama, seperti urutan abjad.

**Selalu gunakan kasus yang sama untuk nama dan nilai parameter**  
CloudFront mempertimbangkan kasus nama parameter dan nilai saat caching berdasarkan parameter string kueri. Dalam contoh berikut, string pencarian identik kecuali untuk kasus nama dan nilai parameter. Hal ini menyebabkan CloudFront untuk meneruskan empat permintaan terpisah untuk image.jpg ke asal Anda dan men-cache empat versi terpisah dari objek:  
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=Red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=Red`
Kami menyarankan agar Anda menggunakan kasus secara konsisten untuk nama dan nilai parameter, seperti semua huruf kecil.

**Jangan gunakan nama parameter yang bertentangan dengan tanda tangan URLs**  
Jika Anda menggunakan tanda tangan URLs untuk membatasi akses ke konten Anda (jika Anda menambahkan tanda tangan tepercaya ke distribusi Anda), CloudFront hapus parameter string kueri berikut sebelum meneruskan sisa URL ke asal Anda:  
+ `Expires`
+ `Key-Pair-Id`
+ `Policy`
+ `Signature`
Jika Anda menggunakan tanda tangan URLs dan ingin mengonfigurasi CloudFront untuk meneruskan string kueri ke asal Anda, parameter string kueri Anda sendiri tidak dapat diberi nama`Expires`,, `Key-Pair-Id``Policy`, atau`Signature`.

## Parameter string kueri dan log CloudFront standar (log akses)
<a name="query-string-parameters-access-logs"></a>

Jika Anda mengaktifkan logging, CloudFront mencatat URL lengkap, termasuk parameter string kueri. Ini benar terlepas dari apakah Anda telah mengonfigurasi CloudFront untuk meneruskan string kueri ke asal. Untuk informasi selengkapnya tentang CloudFront pencatatan, lihat[Akses log (log standar)](AccessLogs.md).

# Konten cache berdasarkan cookie
<a name="Cookies"></a>

Secara default, CloudFront tidak mempertimbangkan cookie saat memproses permintaan dan tanggapan, atau saat menyimpan objek Anda di lokasi tepi. Jika CloudFront menerima dua permintaan yang identik kecuali untuk apa yang ada di `Cookie` header, maka, secara default, CloudFront memperlakukan permintaan sebagai identik dan mengembalikan objek yang sama untuk kedua permintaan.

Anda dapat mengonfigurasi CloudFront untuk meneruskan ke asal Anda beberapa atau semua cookie dalam permintaan penampil, dan untuk menyimpan versi terpisah dari objek Anda berdasarkan nilai cookie yang diteruskannya. Saat Anda melakukan ini, CloudFront gunakan beberapa atau semua cookie dalam permintaan penampil — mana pun yang dikonfigurasi untuk diteruskan—untuk mengidentifikasi objek dalam cache secara unik.

Sebagai contoh, anggaplah bahwa permintaan untuk `locations.html` berisi sebuah cookie `country` yang memiliki nilai `uk` atau `fr`. Saat Anda mengonfigurasi CloudFront untuk menyimpan objek Anda berdasarkan nilai `country` cookie, CloudFront teruskan permintaan `locations.html` ke asal dan sertakan `country` cookie dan nilainya. Asal Anda kembali`locations.html`, dan CloudFront menyimpan objek satu kali untuk permintaan di mana nilai `country` cookie berada `uk` dan sekali untuk permintaan di mana nilainya. `fr`

**penting**  
Amazon S3 dan beberapa server HTTP tidak memproses cookie. Jangan mengkonfigurasi CloudFront untuk meneruskan cookie ke asal yang tidak memproses cookie atau tidak mengubah responsnya berdasarkan cookie. Itu dapat menyebabkan CloudFront untuk meneruskan lebih banyak permintaan ke asal untuk objek yang sama, yang memperlambat kinerja dan meningkatkan beban pada asal. Jika, mengingat contoh sebelumnya, asal Anda tidak memproses `country` cookie atau selalu mengembalikan versi yang sama dari `locations.html` ke CloudFront terlepas dari nilai `country` cookie, jangan konfigurasikan CloudFront untuk meneruskan cookie itu.  
Sebaliknya, jika asal kustom Anda bergantung pada cookie tertentu atau mengirimkan tanggapan berbeda berdasarkan cookie, pastikan Anda mengonfigurasi CloudFront untuk meneruskan cookie tersebut ke asal. Jika tidak, CloudFront hapus cookie sebelum meneruskan permintaan ke asal Anda.

Untuk mengonfigurasi penerusan cookie, Anda memperbarui perilaku cache distribusi. Untuk informasi lebih lanjut tentang perilaku cache, lihat [Pengaturan perilaku cache](DownloadDistValuesCacheBehavior.md), terutama [Teruskan cookie](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardCookies) dan [Daftar cookie yang diizinkan](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies) bagian.

Anda dapat mengonfigurasi setiap perilaku cache untuk melakukan salah satu hal berikut:
+ **Teruskan semua cookie ke asal Anda —** CloudFront termasuk semua cookie yang dikirim oleh pemirsa saat meneruskan permintaan ke asal. Saat asal Anda mengembalikan respons, CloudFront cache respons menggunakan nama dan nilai cookie dalam permintaan penampil. Jika respons asal menyertakan `Set-Cookie` header, CloudFront mengembalikannya ke penampil dengan objek yang diminta. CloudFront juga menyimpan `Set-Cookie` header dengan objek yang dikembalikan dari asal, dan mengirimkan `Set-Cookie` header tersebut ke pemirsa di semua klik cache.
+ **Teruskan satu set cookie yang Anda tentukan —** CloudFront menghapus cookie apa pun yang dikirim penampil yang tidak ada dalam daftar yang diizinkan sebelum meneruskan permintaan ke asal. CloudFront cache respons menggunakan nama dan nilai cookie yang tercantum dalam permintaan penampil. Jika respons asal menyertakan `Set-Cookie` header, CloudFront mengembalikannya ke penampil dengan objek yang diminta. CloudFront juga menyimpan `Set-Cookie` header dengan objek yang dikembalikan dari asal, dan mengirimkan `Set-Cookie` header tersebut ke pemirsa di semua klik cache.

  Untuk informasi tentang menentukan wildcard dalam nama cookie, lihat. [Daftar cookie yang diizinkan](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies)

  Untuk kuota saat ini pada jumlah nama cookie yang dapat Anda teruskan untuk setiap perilaku cache, atau untuk meminta kuota yang lebih tinggi, lihat. [Kuota pada string kueri (pengaturan cache warisan)](cloudfront-limits.md#limits-allowlisted-query-strings)
+ **Jangan meneruskan cookie ke asal Anda —** CloudFront tidak menyimpan objek Anda berdasarkan cookie yang dikirim oleh pemirsa. Selain itu, CloudFront menghapus cookie sebelum meneruskan permintaan ke asal Anda, dan menghapus `Set-Cookie` header dari tanggapan sebelum mengembalikan tanggapan ke pemirsa Anda. Karena ini bukan cara optimal untuk menggunakan sumber daya asal Anda, ketika Anda memilih perilaku cache ini, Anda harus memastikan bahwa asal Anda tidak menyertakan cookie dalam respons asal secara default.

Perhatikan hal berikut tentang menentukan cookie yang ingin Anda teruskan:

**Log akses**  
Jika Anda CloudFront mengonfigurasi permintaan log dan mencatat cookie, CloudFront mencatat semua cookie dan semua atribut cookie, bahkan jika Anda mengonfigurasi untuk CloudFront tidak meneruskan cookie ke asal Anda atau jika Anda mengonfigurasi CloudFront untuk meneruskan hanya cookie tertentu. Untuk informasi selengkapnya tentang CloudFront pencatatan, lihat[Akses log (log standar)](AccessLogs.md).

**Sensitivitas kasus**  
Nama dan nilai cookie bersifat peka huruf besar-kecil. Misalnya, jika CloudFront dikonfigurasi untuk meneruskan semua cookie, dan dua permintaan penampil untuk objek yang sama memiliki cookie yang identik kecuali untuk kasus, CloudFront cache objek dua kali.

**CloudFront mengurutkan cookie**  
Jika CloudFront dikonfigurasi untuk meneruskan cookie (semua atau sebagian), CloudFront urutkan cookie dalam urutan alami berdasarkan nama cookie sebelum meneruskan permintaan ke asal Anda.  
 Nama cookie yang dimulai dengan `$` karakter tidak didukung. CloudFront akan menghapus cookie sebelum meneruskan permintaan ke asal. Anda dapat menghapus `$` karakter atau menentukan karakter yang berbeda di awal nama cookie.

**`If-Modified-Since` dan `If-None-Match`**  
`If-Modified-Since`dan permintaan `If-None-Match` bersyarat tidak didukung ketika CloudFront dikonfigurasi untuk meneruskan cookie (semua atau subset).

**Nama standar–format pasangan nilai diperlukan**  
CloudFront meneruskan header cookie hanya jika nilainya sesuai dengan format [pasangan nama-nilai standar](https://tools.ietf.org/html/rfc6265#section-4.1.1), misalnya: `"Cookie: cookie1=value1; cookie2=value2"`

**Nonaktifkan cache `Set-Cookie` header**  
Jika CloudFront dikonfigurasi untuk meneruskan cookie ke asal (baik semua atau cookie tertentu), itu juga menyimpan `Set-Cookie` header yang diterima dalam respons asal. CloudFront termasuk `Set-Cookie` header ini dalam responsnya terhadap penampil asli, dan juga memasukkannya dalam tanggapan berikutnya yang disajikan dari CloudFront cache.  
Jika Anda ingin menerima cookie di asal Anda tetapi Anda tidak CloudFront ingin menyimpan `Set-Cookie` header di tanggapan asal Anda, konfigurasikan asal Anda untuk menambahkan `Cache-Control` header dengan `no-cache` arahan yang menentukan `Set-Cookie` sebagai nama bidang. Sebagai contoh: `Cache-Control: no-cache="Set-Cookie"`. Untuk informasi lebih lanjut, lihat [Cache Respons-Arahan Kontrol](https://tools.ietf.org/html/rfc7234#section-5.2.2) dalam standar *Protokol Transfer Hiperteks (HTTP/1.1): Caching*.

**Panjang maksimum nama cookie**  
Jika Anda mengonfigurasi CloudFront untuk meneruskan cookie tertentu ke asal Anda, jumlah total byte di semua nama cookie yang Anda konfigurasikan CloudFront untuk diteruskan tidak dapat melebihi 512 dikurangi jumlah cookie yang Anda teruskan. Misalnya, jika Anda mengonfigurasi CloudFront untuk meneruskan 10 cookie ke asal Anda, panjang gabungan nama 10 cookie tidak dapat melebihi 502 byte (512 — 10).  
Jika Anda mengonfigurasi CloudFront untuk meneruskan semua cookie ke asal Anda, panjang nama cookie tidak menjadi masalah.

Untuk informasi tentang menggunakan CloudFront konsol untuk memperbarui distribusi sehingga CloudFront meneruskan cookie ke asal, lihat[Perbarui distribusi](HowToUpdateDistribution.md). Untuk informasi tentang menggunakan CloudFront API untuk memperbarui distribusi, lihat [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)di *Referensi CloudFront API Amazon*.

# Konten cache berdasarkan header permintaan
<a name="header-caching"></a>

CloudFront memungkinkan Anda memilih apakah Anda CloudFront ingin meneruskan header ke asal Anda dan untuk menyimpan versi terpisah dari objek tertentu berdasarkan nilai header dalam permintaan penampil. Ini memungkinkan Anda untuk menyajikan versi konten yang berbeda berdasarkan perangkat yang digunakan pengguna, lokasi penampil, bahasa yang digunakan penampil, dan berbagai kriteria lainnya.

**Topics**
+ [

## Header dan distribusi – ikhtisar
](#header-caching-web)
+ [

## Pilih header untuk mendasarkan caching
](#header-caching-web-selecting)
+ [

## Konfigurasikan CloudFront untuk menghormati pengaturan CORS
](#header-caching-web-cors)
+ [

## Konfigurasikan caching berdasarkan jenis perangkat
](#header-caching-web-device)
+ [

## Konfigurasikan caching berdasarkan bahasa pemirsa
](#header-caching-web-language)
+ [

## Konfigurasikan caching berdasarkan lokasi penampil
](#header-caching-web-location)
+ [

## Konfigurasikan caching berdasarkan protokol permintaan
](#header-caching-web-protocol)
+ [

## Konfigurasikan caching untuk file terkompresi
](#header-caching-web-compressed)
+ [

## Bagaimana caching berdasarkan header memengaruhi kinerja
](#header-caching-web-performance)
+ [

## Bagaimana kasus nilai header dan header memengaruhi caching
](#header-caching-web-case)
+ [

## Header yang CloudFront kembali ke penampil
](#header-caching-web-response)

## Header dan distribusi – ikhtisar
<a name="header-caching-web"></a>

Secara default, CloudFront tidak mempertimbangkan header saat menyimpan objek Anda di lokasi tepi. Jika asal Anda mengembalikan dua objek dan mereka hanya berbeda dengan nilai di header permintaan, CloudFront cache hanya satu versi objek.

Anda dapat mengonfigurasi CloudFront untuk meneruskan header ke asal, yang menyebabkan CloudFront cache beberapa versi objek berdasarkan nilai dalam satu atau beberapa header permintaan. CloudFront Untuk mengonfigurasi objek cache berdasarkan nilai header tertentu, Anda menentukan pengaturan perilaku cache untuk distribusi Anda. Untuk informasi lebih lanjut, lihat [ Cache Berdasarkan Header Permintaan yang Dipilih](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeaders).

Misalnya, bayangkan permintaan penampil untuk `logo.jpg` berisi sebuah header `Product` kustom yang memiliki nilai `Acme` atau `Apex`. Saat Anda mengonfigurasi CloudFront untuk menyimpan objek Anda berdasarkan nilai `Product` header, CloudFront teruskan permintaan `logo.jpg` ke asal dan sertakan nilai `Product` header dan header. CloudFront cache `logo.jpg` sekali untuk permintaan di mana nilai `Product` header adalah `Acme` dan sekali untuk permintaan di mana nilainya. `Apex`

Anda dapat mengonfigurasi setiap perilaku cache dalam distribusi untuk melakukan salah satu hal berikut: 
+ Teruskan semua header ke asal Anda
**catatan**  
**Untuk pengaturan cache lama** — Jika Anda mengonfigurasi CloudFront untuk meneruskan semua header ke asal Anda, CloudFront tidak akan menyimpan objek yang terkait dengan perilaku cache ini. Alih-alih, email mengirimkan setiap permintaan ke sumber.
+ Teruskan daftar header yang Anda tentukan. CloudFront cache objek Anda berdasarkan nilai di semua header yang ditentukan. CloudFront juga meneruskan header yang diteruskan secara default, tetapi cache objek Anda hanya berdasarkan header yang Anda tentukan. 
+ Teruskan hanya header default. Dalam konfigurasi ini, CloudFront tidak men-cache objek Anda berdasarkan nilai di header permintaan.

Untuk kuota saat ini pada jumlah header yang dapat Anda teruskan untuk setiap perilaku cache atau untuk meminta kuota yang lebih tinggi, lihat. [Kuota pada header](cloudfront-limits.md#limits-custom-headers)

Untuk informasi tentang menggunakan CloudFront konsol untuk memperbarui distribusi sehingga CloudFront meneruskan header ke asal, lihat. [Perbarui distribusi](HowToUpdateDistribution.md) Untuk informasi tentang penggunaan CloudFront API untuk memperbarui distribusi yang ada, lihat [Memperbarui Distribusi](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) di *Referensi CloudFront API Amazon*.

## Pilih header untuk mendasarkan caching
<a name="header-caching-web-selecting"></a>

Header yang dapat Anda teruskan ke asal dan yang CloudFront mendasari caching bergantung pada apakah asal Anda adalah ember Amazon S3 atau asal khusus.
+ **Amazon S3 -** Anda dapat mengonfigurasi CloudFront untuk meneruskan dan menyimpan objek berdasarkan sejumlah header tertentu (lihat daftar pengecualian berikut). Namun, kami menyarankan agar Anda menghindari penerusan header dengan asal Amazon S3 kecuali Anda perlu menerapkan berbagi sumber daya lintas asal (CORS) atau Anda ingin mempersonalisasi konten dengan menggunakan Lambda @Edge dalam acara yang menghadap ke asal.
  + Untuk mengonfigurasi CORS, Anda harus meneruskan header yang memungkinkan CloudFront untuk mendistribusikan konten untuk situs web yang diaktifkan untuk berbagi sumber daya lintas asal (CORS). Untuk informasi selengkapnya, lihat [Konfigurasikan CloudFront untuk menghormati pengaturan CORS](#header-caching-web-cors). 
  + Untuk mempersonalisasi konten dengan menggunakan header yang Anda teruskan ke asal Amazon S3, Anda menulis dan menambahkan fungsi Lambda @Edge dan mengaitkannya dengan distribusi CloudFront Anda untuk dipicu oleh peristiwa yang menghadap ke asal. Untuk informasi lebih lanjut tentang bekerja dengan header untuk mempersonalisasi konten, lihat [Personalisasi konten berdasarkan header negara atau jenis perangkat - contoh](lambda-examples.md#lambda-examples-redirecting-examples).

    Kami menyarankan Anda menghindari penerusan header yang tidak Anda gunakan untuk mempersonalisasi konten karena meneruskan header tambahan dapat mengurangi rasio hit cache Anda. Artinya, tidak CloudFront dapat melayani banyak permintaan dari cache tepi, sebagai proporsi dari semua permintaan.
+ **Asal yang disesuaikan ** – Anda dapat mengonfigurasi CloudFront untuk cache berdasarkan nilai header permintaan apa pun kecuali hal berikut:
  + `Connection`
  + `Cookie` – Jika Anda ingin meneruskan dan menyimpan berdasarkan cookie, Anda menggunakan pengaturan terpisah dalam distribusi Anda. Untuk informasi selengkapnya, lihat [Konten cache berdasarkan cookie](Cookies.md).
  + `Host (for Amazon S3 origins)`
  + `Proxy-Authorization`
  + `TE`
  + `Upgrade`

  Anda dapat CloudFront mengonfigurasi objek cache berdasarkan nilai di `User-Agent` header `Date` dan, tetapi kami tidak merekomendasikannya. Header ini memiliki banyak nilai yang mungkin, dan caching berdasarkan nilainya dapat menyebabkan CloudFront untuk meneruskan lebih banyak permintaan secara signifikan ke asal Anda.

Untuk daftar lengkap header permintaan HTTP dan cara CloudFront memprosesnya, lihat[Header dan CloudFront perilaku permintaan HTTP (asal kustom dan Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior).

## Konfigurasikan CloudFront untuk menghormati pengaturan CORS
<a name="header-caching-web-cors"></a>

Jika Anda telah mengaktifkan cross-origin resource sharing (CORS) pada bucket Amazon S3 atau origin khusus, Anda harus memilih header tertentu untuk diteruskan, untuk menghargai pengaturan CORS. Header yang harus Anda teruskan berbeda tergantung asal (Amazon S3 atau custom) dan apakah Anda ingin melakukan cache `OPTIONS` tanggapan mereka.

**Amazon S3**
+ Jika Anda ingin `OPTIONS` respons yang harus disimpan, lakukan hal berikut:
  + Pilih opsi untuk pengaturan perilaku cache default yang mengaktifkan cache untuk `OPTIONS` tanggapan mereka. 
  + Konfigurasikan CloudFront untuk meneruskan header berikut:`Origin`,`Access-Control-Request-Headers`, dan`Access-Control-Request-Method`.
+ Jika Anda tidak ingin `OPTIONS` respons untuk disimpan, dikonfigurasi CloudFront untuk meneruskan `Origin` header, bersama dengan header lain yang diwajibkan oleh negara asal Anda (misalnya, `Access-Control-Request-Headers`, `Access-Control-Request-Method`, atau lainnya).

**Asal yang disesuaikan** – Meneruskan `Origin` beserta header lainnya yang diperlukan sesuai dengan asal Anda.

 CloudFront Untuk mengonfigurasi respons cache berdasarkan CORS, Anda harus mengonfigurasi CloudFront untuk meneruskan header dengan menggunakan kebijakan cache. Untuk informasi selengkapnya, lihat [Mengontrol kunci cache dengan kebijakan](controlling-the-cache-key.md).

Untuk informasi selengkapnya tentang CORS dan Amazon S3, [lihat Menggunakan berbagi sumber daya lintas asal (CORS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html) di Panduan Pengguna Layanan Penyimpanan *Sederhana Amazon*.

## Konfigurasikan caching berdasarkan jenis perangkat
<a name="header-caching-web-device"></a>

Jika Anda CloudFront ingin menyimpan versi objek yang berbeda berdasarkan perangkat yang digunakan pengguna untuk melihat konten Anda, konfigurasikan CloudFront untuk meneruskan header yang berlaku ke asal kustom Anda:
+ `CloudFront-Is-Desktop-Viewer`
+ `CloudFront-Is-Mobile-Viewer`
+ `CloudFront-Is-SmartTV-Viewer`
+ `CloudFront-Is-Tablet-Viewer`

Berdasarkan nilai `User-Agent` header, CloudFront tetapkan nilai header ini ke `true` atau `false` sebelum meneruskan permintaan ke asal Anda. Jika perangkat termasuk dalam lebih dari satu kategori, lebih dari satu nilai mungkin `true`. Misalnya, untuk beberapa perangkat tablet, CloudFront mungkin mengatur keduanya `CloudFront-Is-Mobile-Viewer` dan `CloudFront-Is-Tablet-Viewer` ke`true`.

## Konfigurasikan caching berdasarkan bahasa pemirsa
<a name="header-caching-web-language"></a>

Jika Anda CloudFront ingin menyimpan versi objek yang berbeda berdasarkan bahasa yang ditentukan dalam permintaan, konfigurasikan CloudFront untuk meneruskan `Accept-Language` header ke asal Anda.

## Konfigurasikan caching berdasarkan lokasi penampil
<a name="header-caching-web-location"></a>

Jika Anda CloudFront ingin menyimpan versi objek yang berbeda berdasarkan negara asal permintaan, konfigurasikan CloudFront untuk meneruskan `CloudFront-Viewer-Country` header ke asal Anda. CloudFront secara otomatis mengubah alamat IP tempat permintaan berasal menjadi kode negara dua huruf. Untuk easy-to-use daftar kode negara, dapat diurutkan berdasarkan kode dan nama negara, lihat entri Wikipedia [ISO 3166-1](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) alpha-2.

## Konfigurasikan caching berdasarkan protokol permintaan
<a name="header-caching-web-protocol"></a>

Jika Anda CloudFront ingin menyimpan versi objek yang berbeda berdasarkan protokol permintaan, HTTP atau HTTPS, konfigurasikan CloudFront untuk meneruskan `CloudFront-Forwarded-Proto` header ke asal Anda.

## Konfigurasikan caching untuk file terkompresi
<a name="header-caching-web-compressed"></a>

Jika asal Anda mendukung kompresi Brotli, Anda dapat melakukan cache berdasarkan header. `Accept-Encoding` Konfigurasi cache berdasarkan pada `Accept-Encoding` hanya jika asal Anda melayani konten yang berbeda berdasarkan header.

## Bagaimana caching berdasarkan header memengaruhi kinerja
<a name="header-caching-web-performance"></a>

Saat Anda CloudFront mengonfigurasi cache berdasarkan satu atau beberapa header dan header memiliki lebih dari satu nilai yang mungkin, CloudFront teruskan lebih banyak permintaan ke server asal Anda untuk objek yang sama. Hal ini memperlambat kinerja dan meningkatkan beban pada server asal Anda. Jika server asal Anda mengembalikan objek yang sama terlepas dari nilai header yang diberikan, sebaiknya Anda tidak CloudFront mengonfigurasi cache berdasarkan header tersebut. 

Jika Anda mengonfigurasi CloudFront untuk meneruskan lebih dari satu header, urutan header dalam permintaan penampil tidak memengaruhi caching selama nilainya sama. Misalnya, jika satu permintaan berisi header A: 1, B: 2 dan permintaan lain berisi B: 2, A: 1, cache hanya satu salinan objek. CloudFront 

## Bagaimana kasus nilai header dan header memengaruhi caching
<a name="header-caching-web-case"></a>

Ketika CloudFront cache berdasarkan nilai header, itu tidak mempertimbangkan kasus nama header, tetapi mempertimbangkan kasus nilai header:
+ Jika permintaan penampil menyertakan keduanya `Product:Acme` dan`product:Acme`, CloudFront cache objek hanya sekali. Satu-satunya perbedaan di antara keduanya adalah kasus nama header, yang tidak memengaruhi caching.
+ Jika permintaan penampil menyertakan keduanya `Product:Acme` dan`Product:acme`, CloudFront cache objek dua kali, karena nilainya ada `Acme` di beberapa permintaan dan `acme` permintaan lainnya.

## Header yang CloudFront kembali ke penampil
<a name="header-caching-web-response"></a>

Mengkonfigurasi CloudFront untuk meneruskan dan menyimpan header tidak memengaruhi header mana yang CloudFront kembali ke penampil. CloudFront mengembalikan semua header yang didapatnya dari asal dengan beberapa pengecualian. Untuk informasi selengkapnya, lihat topik yang berlaku:
+ **Asal Amazon S3 – ** Lihat [Header respons HTTP yang CloudFront menghapus atau memperbarui](RequestAndResponseBehaviorS3Origin.md#response-s3-removed-headers).
+ **Asal yang disesuaikan – ** Lihat [Header respons HTTP yang CloudFront menghapus atau menggantikan](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomRemovedHeaders).