{
	"id": "22bce729-fecf-4d9d-a779-97e2e1c2fff3",
	"created_at": "2026-04-06T01:31:36.097477Z",
	"updated_at": "2026-04-10T03:20:18.556423Z",
	"deleted_at": null,
	"sha1_hash": "d5e4a2cd25b2a089cca78858761c9334ed8f3edb",
	"title": "Best practices for Cloud Storage",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 75266,
	"plain_text": "Best practices for Cloud Storage\r\nArchived: 2026-04-06 00:17:00 UTC\r\nSkip to main content\r\nTechnology areas\r\nOverview\r\nGuides\r\nReference\r\nSamples\r\nResources\r\nCross-product tools\r\nConsole\r\nCloud Storage\r\nAll resources\r\nPricing\r\nPricing examples\r\nQuotas \u0026 limits\r\nRelease notes\r\nFrequently asked questions\r\nBest practices\r\nPublic datasets\r\nPartners\r\nDMCA policy\r\nService level agreement\r\nBest practices for Cloud Storage Stay organized with collections Save and\r\ncategorize content based on your preferences.\r\nOn this page\r\nNaming\r\nTraffic\r\nLocations and data storage options\r\nACLs and access control\r\nData uploads\r\nDeletion of data\r\nhttps://cloud.google.com/storage/docs/best-practices\r\nPage 1 of 4\n\nThis page contains an index of best practices for Cloud Storage. You can use the information collected here as a\r\nquick reference of what to keep in mind when building an application that uses Cloud Storage.\r\nIf you are just starting out with Cloud Storage, this page may not be the best place to start, because it does not\r\nteach you the basics of how to use Cloud Storage. If you are a new user, we suggest that you start with Discover\r\nobject storage with the Google Cloud console or Discover object storage with the Google Cloud CLI.\r\nFor best practices for media workloads, see Best practices for media workloads.\r\nNaming\r\nSee Bucket naming and Object naming for name requirements and considerations.\r\nTraffic\r\nPerform a back-of-the-envelope estimation of the amount of traffic that will be sent to Cloud Storage.\r\nSpecifically, think about:\r\nOperations per second. How many operations per second do you expect, for both buckets and\r\nobjects, and for create, update, and delete operations.\r\nBandwidth. How much data will be sent, over what timeframe? Consider using a tool like Wolfram\r\nAlpha to avoid mistakes in your calculations.\r\nCache control. Specifying the Cache-Control metadata on publicly accessible objects will benefit\r\nread latency on hot or frequently accessed objects. See Viewing and Editing Metadata for\r\ninstructions for setting object metadata, such as Cache-Control .\r\nDesign your application to minimize spikes in traffic. If there are clients of your application doing updates,\r\nspread them out throughout the day.\r\nWhen designing applications for high request rates, be aware of rate limits for certain operations. Know the\r\nbandwidth limits for certain types of egress and follow the Request Rate and Access Distribution\r\nGuidelines. Be especially aware of autoscaling and the need to gradually ramp up request rates for the best\r\nperformance.\r\nWhen handling errors:\r\nMake sure your application uses a retry strategy in order to avoid problems due to large traffic\r\nbursts.\r\nRetry using a new connection and possibly re-resolve the domain name. This helps avoid \"server\r\nstickiness\", where a retry attempts to go through the same path and hits the same unhealthy\r\ncomponent that the initial request hit.\r\nIf your application is latency sensitive, use hedged requests. Hedged requests allow you to retry faster and\r\ncut down on tail latency. They do this while not reducing your request deadline, which could cause requests\r\nhttps://cloud.google.com/storage/docs/best-practices\r\nPage 2 of 4\n\nto time out prematurely. For more information, see The Tail at Scale.\r\nUnderstand the performance level customers expect from your application. This information helps you\r\nchoose a storage option and region when creating new buckets. For example, consider colocating your\r\ncompute resources with your Cloud Storage buckets for analytics applications.\r\nLocations and data storage options\r\nSee the Storage class and Bucket location topics for guidance on how to best store your data.\r\nACLs and access control\r\nCloud Storage requests refer to buckets and objects by their names. As a result, even though ACLs prevent\r\nunauthorized third parties from operating on buckets or objects, a third party can attempt requests with\r\nbucket or object names and determine their existence by observing the error responses. It can then be\r\npossible for information in bucket or object names to be leaked. If you are concerned about the privacy of\r\nyour bucket or object names, you should take appropriate precautions, such as:\r\nChoosing bucket and object names that are difficult to guess. For example, a bucket named\r\nmybucket-gtbytul3 is random enough that unauthorized third parties cannot feasibly guess it or\r\nenumerate other bucket names from it.\r\nAvoiding use of sensitive information as part of bucket or object names. For example, instead of\r\nnaming your bucket mysecretproject-prodbucket , name it somemeaninglesscodename-prod . In\r\nsome applications, you may want to keep sensitive metadata in custom Cloud Storage headers such\r\nas x-goog-meta , rather than encoding the metadata in object names.\r\nUsing groups is preferable to explicitly listing large numbers of users. Not only does it scale better, it also\r\nprovides a very efficient way to update the access control for a large number of objects all at once. Lastly,\r\nit's cheaper as you don't need to make a request per-object to change the ACLs.\r\nReview and follow access control best practices.\r\nThe Cloud Storage access control system includes the ability to specify that objects are publicly readable.\r\nMake sure you intend for any objects you write with this permission to be public. Once \"published\", data\r\non the Internet can be copied to many places, so it's effectively impossible to regain read control over an\r\nobject written with this permission.\r\nThe Cloud Storage access control system includes the ability to specify that buckets are publicly writable.\r\nWhile configuring a bucket this way can be convenient for various purposes, we recommend against using\r\nthis permission - it can be abused for distributing illegal content, viruses, and other malware, and the\r\nbucket owner is legally and financially responsible for the content stored in their buckets.\r\nIf you need to make content available securely to users who don't have user accounts, we recommend you\r\nuse signed URLs. For example, with signed URLs you can provide a link to an object, and your\r\nhttps://cloud.google.com/storage/docs/best-practices\r\nPage 3 of 4\n\napplication's customers don't need to authenticate with Cloud Storage to access the object. When you create\r\na signed URL you control the type (read, write, delete) and duration of access.\r\nData uploads\r\nIf you use XMLHttpRequest (XHR) callbacks to get progress updates, do not close and re-open the\r\nconnection if you detect that progress has stalled. Doing so creates a bad positive feedback loop during\r\ntimes of network congestion. When the network is congested, XHR callbacks can get backlogged behind\r\nthe acknowledgement (ACK/NACK) activity from the upload stream, and closing and reopening the\r\nconnection when this happens uses more network capacity at exactly the time when you can least afford it.\r\nFor upload traffic, we recommend setting reasonably long timeouts. For a good end-user experience, you\r\ncan set a client-side timer that updates the client status window with a message (e.g., \"network\r\ncongestion\") when your application hasn't received an XHR callback for a long time. Don't just close the\r\nconnection and try again when this happens.\r\nA convenient way to reduce the bandwidth needed for each request is to enable gzip compression.\r\nAlthough this requires additional CPU time to extract the results, the trade-off with network costs usually\r\nmakes it very worthwhile.\r\nAn object that was uploaded in gzip format can generally be served in gzip format as well. However, avoid\r\nuploading content that has both content-encoding: gzip and a content-type that is compressed, as\r\nthis may lead to unexpected behavior.\r\nWe recommend using resumable uploads, which allow you to resume transferring data even when a\r\ncommunication failure has interrupted the flow of data. You can also use XML API multipart uploads to\r\nupload parts of a file in parallel, which potentially reduces the time to complete the overall upload.\r\nDeletion of data\r\nSee Delete objects for guidelines and considerations on deleting data. You can also use features for controlling\r\ndata lifecycles to help protect your data from getting erroneously deleted by your application software or users.\r\nExcept as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0\r\nLicense, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site\r\nPolicies. Java is a registered trademark of Oracle and/or its affiliates.\r\nLast updated 2026-04-03 UTC.\r\nSource: https://cloud.google.com/storage/docs/best-practices\r\nhttps://cloud.google.com/storage/docs/best-practices\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://cloud.google.com/storage/docs/best-practices"
	],
	"report_names": [
		"best-practices"
	],
	"threat_actors": [],
	"ts_created_at": 1775439096,
	"ts_updated_at": 1775791218,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d5e4a2cd25b2a089cca78858761c9334ed8f3edb.pdf",
		"text": "https://archive.orkl.eu/d5e4a2cd25b2a089cca78858761c9334ed8f3edb.txt",
		"img": "https://archive.orkl.eu/d5e4a2cd25b2a089cca78858761c9334ed8f3edb.jpg"
	}
}