이 페이지에서는 Cloud Storage 객체를 캐시하는 방법을 제어하는 옵션에 대해 설명합니다. 이 페이지에서는 Cloud Storage 기본 제공 캐시 및 Cloud CDN을 중점적으로 설명하지만 Cloud Storage는 서드 파티 CDN과도 호환됩니다.
개요
Cloud Storage 객체가 캐시되면 객체 데이터의 사본이 Google 또는 인터넷 캐시에 저장되므로 이후 요청에서 객체를 더 빠르게 제공할 수 있습니다. 캐싱을 사용하면 성능이 향상될 수 있지만 객체를 업데이트하더라도 캐시가 이전 버전의 객체를 계속 제공하면 오래된 콘텐츠를 서빙할 위험이 있습니다.
Cloud Storage의 기본 제공 캐싱
Cloud Storage는 개발자가 별도로 작업하지 않아도 콘텐츠 전송 네트워크(CDN)처럼 작동할 수 있습니다. 객체의 데이터가 Cache-Control 메타데이터가 캐싱을 허용하도록 설정되어 있고 다음 기준이 충족되는 경우 Cloud Storage 네트워크에 캐싱되기 때문입니다.
private: 객체가 Cloud Storage에 의해 캐시되지는 않지만 요청자의 로컬 캐시에 캐시될 수 있습니다.
no-cache: 객체가 캐시될 수 있지만 Cloud Storage에 의해 검증되기 전에는 이후 요청을 충족하는 데 사용될 수 없습니다.
no-store: 객체가 캐시될 수 없습니다.
max-age=TIME_IN_SECONDS: 객체가 비활성으로 간주되기 전에 캐시될 수 있는 기간입니다. max-age를 원하는 길이의 시간으로 설정할 수 있습니다. 특수한 상황을 제외하고 비활성 객체는 캐시에서 제공되지 않습니다.
객체의 Cache-Control 메타데이터를 설정하려면 객체 메타데이터 수정을 참고하세요.
IAM 거부 정책에서 기본 제공되는 캐싱 동작
주 구성원 식별자 allUsers에서 객체에 대한 읽기 액세스를 제한하는 조직 수준 IAM 거부 정책이 있는 경우 객체에 대한 읽기 액세스 권한을 allUsers에 부여하는 버킷 수준 IAM 정책이 있더라도 객체에 대한 기본 제공 캐싱이 비활성화됩니다.
하지만 IAM 거부 정책이 개별 사용자만 제한하는 경우 객체에 기본 제공 캐싱이 사용 설정된 상태로 유지됩니다.
성능에 대한 고려사항
성능은 공개적으로 캐시 가능한 객체에서 훨씬 우수할 수 있습니다. 객체 하나로 여러 클라이언트를 제어하고 있어 최신 데이터를 제공하기 위해 캐싱을 사용 중지하려는 경우에는 다음을 확인하세요.
객체의 Cache-Control 메타데이터를 max-age가 15~60초인 public으로 설정해 봅니다. 대부분의 애플리케이션은 성능 향상을 위해 객체가 몇 초 동안 최신 상태가 아닐 수 있습니다.
객체에 Cache-Control: no-store를 사용해 모든 캐시의 후속 요청 시 객체를 캐시하지 않는다고 나타냅니다.
버킷에서 Anywhere Cache 사용
Anywhere Cache는 워크로드와 동일한 영역에 캐시를 만들 수 있는 완전 관리형, 항상 일관된 Cloud Storage 기능입니다. 그러면 캐시를 사용하여 멀티 리전 버킷 대신 데이터 읽기 요청을 완료할 수 있으므로, 멀티 리전 데이터 전송 수수료가 발생하고 성능에 영향을 미치는 대규모 데이터 집약적 워크로드를 실행하는 동안 스토리지 비용을 제어할 수 있습니다. Anywhere Cache, 이 기능의 이점, 이 기능을 사용해야 하는 경우에 관한 자세한 내용은 Anywhere Cache 개요를 참조하세요.
Cloud CDN을 사용하는 Cloud Storage
사용자에게 콘텐츠를 제공할 때 최상의 성능을 얻으려면 Cloud CDN과 함께 Cloud Storage를 사용하는 것이 좋습니다.
Cloud CDN을 사용하려면 Cloud Storage 버킷과 함께 외부 애플리케이션 부하 분산기를 백엔드로 사용해야 합니다. Cloud Storage 버킷으로 HTTP(S) 부하 분산기를 설정하는 방법에 대한 튜토리얼은 정적 웹사이트 호스팅을 참조하세요.
Cloud CDN 캐시 모드를 사용하면 모든 객체에 통합 캐싱 구성을 적용할 수 있습니다. Cloud CDN은 캐시 모드 또는 TTL 한도를 사용하여 Cache-Control 메타데이터를 재정의하지 않는 한 객체에 설정된 Cache-Control 메타데이터를 사용하여 캐시되는 방식을 결정합니다.
Cloud Storage 기본 제공 캐싱과 Cloud CDN 중에서 선택할 때 다음을 고려하세요.
기능
Cloud Storage
Cloud CDN
캐시 가능한 최대 파일 크기
10MiB
100 GiB1
기본 캐시 만료
1시간
1시간(구성 가능)
HTTPS를 통한 커스텀 도메인 지원
아니요
예
캐시 무효화
아니요
예
1원본 서버가 바이트 범위 요청을 지원하는 경우 Cloud CDN의 최대 캐시 가능 파일 크기는 100GiB입니다. 원본 서버가 바이트 범위 요청을 지원하지 않는 경우 Cloud CDN의 최대 캐시 가능한 파일 크기는 10MiB입니다.
가격 책정 고려사항
가격 측면에서 Cloud Storage 기본 제공 캐싱과 Cloud CDN 중에서 무엇을 선택할지는 매달 제공되는 데이터 양에 따라 달라지며 이에 따라 발생하는 네트워킹 비용이 결정됩니다.
캐시할 수 있는 데이터가 한 달에 몇 GiB 미만인 경우 Cloud Storage 기본 제공 캐싱을 사용하는 것이 전반적으로 더 저렴할 수 있습니다.
Cloud Storage 캐싱에서는 캐시된 객체와 캐시되지 않은 객체에 같은 아웃바운드 데이터 전송 비용이 청구되므로 Cloud CDN보다 네트워킹 비용이 더 많이 발생할 수 있습니다. 즉, 캐시 적중에 대한 전체 가격을 지불합니다.
하지만 Cloud Storage, Cloud CDN, Cloud Load Balancing의 조합 대신 Cloud Storage와 관련된 데이터 스토리지 및 작업 사용량 비용만 지불하면 됩니다.
캐시 가능한 데이터를 한 달에 100GiB 이상 정기적으로 제공하거나 요청별 로깅 및 커스텀 헤더를 사용해야 하는 경우 Cloud CDN을 사용하는 것이 전반적으로 더 저렴할 수 있습니다. 캐시 채우기에 Cloud Storage 아웃바운드 데이터 전송 및 Cloud CDN 캐시 채우기 비용이 발생하며, 캐시가 가득 차면 Cloud CDN 네트워킹 가격이 적용됩니다. Cloud CDN을 사용하면 네트워킹 비용을 절약할 수 있으므로 Cloud Storage와 함께 외부 애플리케이션 부하 분산기 및 Cloud CDN 유지보수와 관련된 운영 비용을 더 많이 절감할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],null,["# Caching\n\nThis page discusses the options you have to control how your\nCloud Storage objects are cached. This page focuses on the\nCloud Storage built-in cache and [Cloud CDN](/cdn/docs), but\nCloud Storage is also compatible with third-party CDNs.\n\nOverview\n--------\n\nWhen a Cloud Storage object is cached, copies of the object data are\nstored in a Google or internet cache so your object can be served faster in\nfuture requests. While caching can improve performance, you also\nrisk serving stale content if you make updates to your object but a cache\ncontinues to serve the earlier version of the object.\n\nBuilt-in caching for Cloud Storage\n----------------------------------\n\nCloud Storage can behave like a Content Delivery Network (CDN) with no\nwork on your part, because an object's data is cached in the\nCloud Storage network if its [`Cache-Control` metadata](/storage/docs/metadata#cache-control) is set to\nallow caching and the following criteria are met:\n\n- The object is [publicly accessible](/storage/docs/access-control/making-data-public).\n- The object is not stored in a bucket that has [Requester Pays](/storage/docs/requester-pays) enabled and does not reside within a [Virtual Private Cloud service perimeter](/vpc-service-controls/docs/service-perimeters).\n- The object is not encrypted using [customer-managed encryption keys](/storage/docs/encryption/customer-managed-keys) or [customer-supplied encryption keys](/storage/docs/encryption/customer-supplied-keys).\n\n| **Important:** Proxies or browsers might cache object data and subsequently serve object data from their cache based solely on the object's `Cache-Control` metadata. Additionally, depending on the network path, once object data has left Cloud Storage, the `Cache-Control` value associated with it might be overwritten, for example by a CDN that the data passes through.\n\nCloud Storage respects [standard values](https://datatracker.ietf.org/doc/html/rfc7234#section-5.2) for\n`Cache-Control`, such as the following:\n\n- `public`: the object can be cached.\n\n- `private`: the object won't be cached by Cloud Storage, but can be\n cached in a requester's local cache.\n\n- `no-cache`: the object can be cached, but cannot be used to satisfy future\n requests unless first validated by Cloud Storage.\n\n- `no-store`: the object can't be cached.\n\n- `max-age=`\u003cvar translate=\"no\"\u003eTIME_IN_SECONDS\u003c/var\u003e: the length of time an object\n can be cached before it's considered stale. You can set `max-age` to any\n length of time. Stale objects are not served from caches, except in\n [special circumstances](https://datatracker.ietf.org/doc/html/rfc7234#section-4.2.4).\n\nTo set the `Cache-Control` metadata for an object, see\n[Editing object metadata](/storage/docs/viewing-editing-metadata#edit).\n\n### Built-in caching behavior with IAM Deny policies\n\nWhen there's an organization-level IAM Deny policy that\nrestricts read access for an object from the [principal identifier `allUsers`](/iam/docs/principal-identifiers),\nbuilt-in caching is disabled for the object, even if there's a bucket-level\nIAM policy that grants read access for the object to `allUsers`.\nHowever, if the IAM Deny policy only restricts individual users,\nbuilt-in caching remains enabled for the object.\n\n### Performance considerations\n\nPerformance can be much better for publicly cacheable objects. If you have an\nobject being used to control many clients and thus want to disable caching\nto provide the latest data:\n\n- Consider instead setting the object's `Cache-Control` metadata to `public`\n with `max-age` of 15-60 seconds. Most applications can tolerate having an\n object be out of date for a few seconds, in exchange for performance\n improvements.\n\n- Use `Cache-Control: no-store` for an object to indicate that the object\n must not be cached for subsequent requests in any cache.\n\nUse Anywhere Cache with your buckets\n------------------------------------\n\nAnywhere Cache is a fully-managed, always consistent Cloud Storage\nfeature that lets you create caches in the same zone as your workloads. The\ncaches can then be used to complete data read requests instead of your\nmulti-region bucket, helping you control storage costs while running large,\ndata-intensive workloads that would otherwise incur multi-region data transfer\nfees and impact performance. To learn more about Anywhere Cache, its\nbenefits, and when you should use this feature, see\n[Anywhere Cache overview](/storage/docs/anywhere-cache).\n\nCloud Storage with Cloud CDN\n----------------------------\n\nFor the best performance when delivering content to users, we recommend using\nCloud Storage with Cloud CDN.\n\nTo use Cloud CDN, you must use an [external Application Load Balancer](/load-balancing/docs/https) with your\nCloud Storage buckets as a backend. For a tutorial on setting up an\nHTTP(S) load balancer with a Cloud Storage bucket, see\n[Hosting a static website](/storage/docs/hosting-static-website).\n\n[Cloud CDN cache modes](/cdn/docs/caching#cache-modes) allow you to apply a unified caching\nconfiguration across all your objects. Cloud CDN uses the\n`Cache-Control` metadata set on your objects to determine\n[how they should be cached](/cdn/docs/caching#cacheability), unless you override the `Cache-Control`\nmetadata using a cache mode or [TTL limit](/cdn/docs/using-ttl-overrides).\n\nWhen choosing between Cloud Storage built-in caching and\nCloud CDN, consider the\nfollowing:\n\n^1^The maximum cacheable file size for Cloud CDN is 100 GiB\nif the origin server supports byte range requests. If the origin server doesn't\nsupport byte range requests, the maximum cacheable file size for\nCloud CDN is 10 MiB.\n\n### Pricing considerations\n\nIn terms of pricing, the choice between Cloud Storage built-in caching\nand Cloud CDN depends on how much data you serve every month, which\ndetermines the amount of networking costs you incur.\n\n- If you serve less than a few GiB of cacheable data a month, it may be cheaper\n overall for you to rely on Cloud Storage built-in caching.\n Cloud Storage caching may incur higher networking costs than\n Cloud CDN, since cached and uncached objects are charged the same\n outbound data transfer cost (which means you pay full price for cache hits).\n However, you only pay for data storage and operations usage costs associated\n with Cloud Storage, instead of the combination of\n Cloud Storage, Cloud CDN, and Cloud Load Balancing.\n\n- If you regularly serve 100 GiB or more of cacheable data a month, or need to\n use per-request logging and custom headers, it may be cheaper overall for you\n to rely on Cloud CDN. You incur Cloud Storage outbound data\n transfer and Cloud CDN cache fill costs for cache fill, and\n Cloud CDN networking prices apply after the cache is full. The\n networking cost savings you gain from using Cloud CDN may be worth\n the higher operating costs associated with maintaining the external Application Load Balancer and\n Cloud CDN along with Cloud Storage.\n\nWhat's next\n-----------\n\n- Read more about the [`Cache-Control` metadata](/storage/docs/metadata#cache-control).\n- Learn more about the [RFC `Cache-Control` directives](https://datatracker.ietf.org/doc/html/rfc7234#section-5.2).\n- Read the [caching overview for Cloud CDN](/cdn/docs/caching).\n- Learn how to [create an external HTTP(S) load balancer to serve requests from\n your Cloud Storage bucket](/load-balancing/docs/https/setup-global-ext-https-buckets).\n- Read the pricing details for [external Application Load Balancers](/vpc/network-pricing#lb) and [Cloud CDN](/cdn/pricing)."]]
