Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se incluye un índice de prácticas recomendadas para Cloud Storage. Puedes usar la información recopilada aquí como referencia rápida de lo que debes tener en cuenta cuando compiles una aplicación que use Cloud Storage.
Realiza una estimación aproximada de la cantidad de tráfico que se enviará a Cloud Storage. En particular, ten en cuenta esta información:
Las operaciones por segundo. ¿Cuántas operaciones por segundo esperas que realicen los depósitos y los objetos? ¿y para las operaciones de creación, actualización y eliminación?
El ancho de banda. ¿Cuántos datos se enviarán y durante cuánto tiempo? Considera usar una herramienta como Wolfram Alpha para evitar errores en tus cálculos.
El control de caché. Especificar los metadatos Cache-Control en objetos de acceso público beneficiará la latencia de lectura en los objetos activos o de acceso frecuente.
Consulta Visualiza y edita metadatos para obtener instrucciones sobre la configuración de metadatos de objetos como Cache-Control.
Diseña tu aplicación para minimizar los picos de tráfico. Si hay clientes de tu aplicación que realizan actualizaciones, distribúyelos a lo largo del día.
Asegúrate de que tu aplicación use una estrategia de reintento para evitar problemas debido a los picos de actividad de tráfico.
Vuelve a intentarlo con una conexión nueva y, quizás, una resolución nueva del nombre de dominio. Esto ayuda a evitar la "persistencia del servidor", en la que un reintento trata de pasar por la misma ruta y llega al mismo componente en mal estado que la solicitud inicial.
Si tu aplicación es sensible a la latencia, usa solicitudes encubiertas. Las solicitudes encubiertas te permiten volver a intentarlo más rápido y reducir la latencia final. Lo hacen sin reducir el plazo de solicitud, lo que podría provocar que las solicitudes agoten el tiempo de espera de manera prematura. Para obtener más información, consulta The Tail at Scale.
Comprende el nivel de rendimiento que los clientes esperan de tu aplicación. Esta información te ayudará a elegir una opción de almacenamiento y una región cuando crees nuevos depósitos. Por ejemplo, considera colocar tus recursos de procesamiento con los buckets de Cloud Storage para aplicaciones de estadísticas.
Las solicitudes de Cloud Storage se refieren a los depósitos y los objetos por sus nombres. Como resultado, a pesar de que las LCA evitarán que terceros no autorizados operen en objetos o depósitos, un tercero puede intentar ejecutar solicitudes con nombres de objetos o depósitos y determinar su existencia, si observa las respuestas de error. Debido a esto, puede que se filtre la información en los nombres de objetos o depósitos. Si te preocupa la privacidad de los nombres de tu bucket o de tu objeto, debes tomar las siguientes precauciones adecuadas:
Elegir nombres de depósitos y de objetos que sean difíciles de adivinar. Por ejemplo, un bucket llamado mybucket-gtbytul3 es lo bastante aleatorio como para evitar que terceros no autorizados puedan adivinarlo o enumerar otros nombres de bucket s a partir de él.
Evitar el uso de información sensible como parte de los nombres de objetos o depósitos. Por ejemplo, en lugar de nombrar tu bucket mysecretproject-prodbucket, asígnale el nombre somemeaninglesscodename-prod. En algunas aplicaciones, es posible que desees mantener los metadatos sensibles en encabezados personalizados de Cloud Storage , como x-goog-meta, en lugar de codificar los metadatos en los nombres de los objetos.
Es preferible usar grupos que enumerar de forma explícita grandes cantidades de usuarios. Esto escala mejor y proporciona una forma muy eficiente de actualizar el control de acceso para una gran cantidad de objetos a la vez. Por último, es más barato, ya que no necesitas realizar una solicitud por objeto para cambiar las LCA.
El sistema de control de acceso de Cloud Storage incluye la capacidad de especificar que los objetos se puedan leer de forma pública. Asegúrate de que deseas que todos los objetos que escribas con este permiso sean públicos. Una vez que se “publican”, los datos en Internet se pueden copiar en muchos lugares, por lo que es imposible recuperar el control de lectura sobre un objeto escrito con este permiso.
El sistema de control de acceso de Cloud Storage incluye la capacidad de especificar que los depósitos se puedan escribir de forma pública. Si bien configurar un bucket de esta manera puede ser conveniente para varios objetivos, recomendamos no usar este permiso, ya que se puede abusar de él con el fin de distribuir contenido ilegal, virus y otros tipos de software malicioso. El propietario del bucket es responsable a nivel legal y financiero del contenido almacenado en él.
Si necesitas que el contenido esté disponible de forma segura para los usuarios que no tienen cuentas de usuario, recomendamos que uses URLs firmadas. Por ejemplo, con las URLs firmadas, puedes proporcionar un vínculo a un objeto y los clientes de tu aplicación no necesitarán autenticarse con Cloud Storage para acceder al objeto. Cuando creas una URL firmada, controlas el tipo (de lectura, escritura y borrado) y la duración del acceso.
Cargas de datos
Si usas devoluciones de llamadas XMLHttpRequest (XHR) para obtener actualizaciones de progreso, no cierres y vuelvas a abrir la conexión si detectas que el progreso se detuvo.
Si lo haces, se creará un bucle de reacción positivo indeseado cuando haya congestión en la red. Cuando la red está congestionada, las devoluciones de llamada XHR se pueden atrasar detrás de la actividad de confirmación (ACK y NACK) de la transmisión de la carga. Si se cierra y se vuelve a abrir la conexión cuando esto sucede, se usa más capacidad de la red en el preciso momento en el que menos lo puedes permitir.
Para subir tráfico, recomendamos configurar tiempos de espera de una duración razonable. Para asegurar una experiencia óptima del usuario final, puedes establecer un cronómetro del lado del cliente que actualice la ventana del estado del cliente con un mensaje (p. ej., “congestión de la red”) cuando tu aplicación no haya recibido una devolución de llamada XHR durante mucho tiempo. No cierres la conexión y vuelvas a intentarlo cuando esto suceda.
Una forma fácil y conveniente de reducir el ancho de banda necesario para cada solicitud es habilitar la compresión gzip. Aunque esto requiere un tiempo de CPU adicional para descomprimir los resultados, la compensación con los costos de la red suele hacer que valga la pena.
Por lo general, un objeto que se subió en formato gzip se puede también entregar en formato gzip. Sin embargo, evita subir contenido que tenga un content-encoding: gzip o un content-type comprimido, ya que esto puede provocar un comportamiento inesperado.
Te recomendamos usar cargas reanudables, que te permiten reanudar la transferencia de datos incluso cuando una falla de comunicación haya interrumpido el flujo de datos. También puedes usar cargas multiparte de la API de XML para subir partes de un archivo en paralelo, lo que puede reducir el tiempo de completar la carga general.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-05 (UTC)"],[],[],null,["# Best practices for Cloud Storage\n\nThis page contains an index of best practices for Cloud Storage. You can use\nthe information collected here as a quick reference of what to keep in mind when\nbuilding an application that uses Cloud Storage.\n\nIf you are just starting out with Cloud Storage, this page may not be\nthe best place to start, because it does not teach you the basics of how to use\nCloud Storage. If you are a new user, we suggest that you start with\n[Discover object storage with the Google Cloud console](/storage/docs/discover-object-storage-console) or\n[Discover object storage with the gcloud tool](/storage/docs/discover-object-storage-gcloud).\n\nFor best practices for media workloads, see [Best practices for media workloads](/storage/docs/best-practices-media-workload).\n\nNaming\n------\n\nSee [Bucket naming](/storage/docs/buckets#naming) and [Object naming](/storage/docs/objects#naming) for name requirements\nand considerations.\n\nTraffic\n-------\n\n- Perform a back-of-the-envelope estimation of the amount of traffic that will\n be sent to Cloud Storage. Specifically, think about:\n\n - Operations per second. How many operations per second do you expect, for\n both buckets and objects, and for create, update, and delete operations.\n\n - Bandwidth. How much data will be sent, over what time frame? Consider\n using a tool like [Wolfram Alpha](https://www.wolframalpha.com/input?i=350GB+in+5+minutes)\n to avoid mistakes in your calculations.\n\n - Cache control. Specifying the [`Cache-Control` metadata](/storage/docs/metadata#cache-control) on publicly\n accessible objects will benefit read latency on hot or frequently accessed\n objects.\n See [Viewing and Editing Metadata](/storage/docs/viewing-editing-metadata#edit) for instructions for setting object\n metadata, such as `Cache-Control`.\n\n- Design your application to minimize spikes in traffic. If there are clients of\n your application doing updates, spread them out throughout the day.\n\n- When designing applications for high request rates, be aware of\n [rate limits](/storage/quotas) for certain operations. Know the [bandwidth limits](/storage/quotas#bandwidth) for\n certain types of egress and follow the\n [Request Rate and Access Distribution Guidelines](/storage/docs/request-rate). Be especially aware of\n autoscaling and the need to gradually ramp up request rates for the best\n performance.\n\n- When handling errors:\n\n - Make sure your application uses a [retry strategy](/storage/docs/retry-strategy) in order to\n avoid problems due to large traffic bursts.\n\n - Retry using a new connection and possibly re-resolve the domain name. This\n helps avoid \"server stickiness\", where a retry attempts to go through the\n same path and hits the same unhealthy component that the initial request\n hit.\n\n- If your application is latency sensitive, use hedged requests. Hedged requests\n allow you to retry faster and cut down on tail latency. They do this while not\n reducing your request deadline, which could cause requests to time out\n prematurely. For more information, see\n [The Tail at Scale](https://research.google/pubs/pub40801/).\n\n- Understand the performance level customers expect from your application. This\n information helps you choose a storage option and region when creating new\n buckets. For example, consider colocating your compute resources with your\n Cloud Storage buckets for analytics applications.\n\nLocations and data storage options\n----------------------------------\n\nSee the [Storage class](/storage/docs/storage-classes) and [Bucket location](/storage/docs/locations) topics for guidance on how\nto best store your data.\n\nACLs and access control\n-----------------------\n\n- Cloud Storage requests refer to buckets and objects by their names. As a\n result, even though ACLs prevent unauthorized third parties from operating on\n buckets or objects, a third party can attempt requests with bucket or object\n names and determine their existence by observing the error responses. It can\n then be possible for information in bucket or object names to be leaked. If you\n are concerned about the privacy of your bucket or object names, you should take\n appropriate precautions, such as:\n\n - **Choosing bucket and object names that are difficult to guess.** For\n example, a bucket named `mybucket-gtbytul3` is random enough that\n unauthorized third parties cannot feasibly guess it or enumerate other\n bucket names from it.\n\n - **Avoiding use of sensitive information as part of bucket or object\n names.** For example, instead of naming your bucket\n `mysecretproject-prodbucket`, name it `somemeaninglesscodename-prod`. In\n some applications, you may want to keep sensitive metadata in\n [custom Cloud Storage headers](/storage/docs/metadata#custom-metadata) such as `x-goog-meta`, rather than encoding\n the metadata in object names.\n\n- Using groups is preferable to explicitly listing large numbers of users. Not\n only does it scale better, it also provides a very efficient way to update\n the access control for a large number of objects all at once. Lastly, it's\n cheaper as you don't need to make a request per-object to change the ACLs.\n\n- Review and follow [access control best practices](/storage/docs/access-control/best-practices-access-control).\n\n- The Cloud Storage access control system includes the ability to\n specify that objects are publicly readable. Make sure you intend for any\n objects you write with this permission to be public. Once \"published\", data on\n the Internet can be copied to many places, so it's effectively impossible to\n regain read control over an object written with this permission.\n\n- The Cloud Storage access control system includes the ability to\n specify that buckets are publicly writable. While configuring a bucket this\n way can be convenient for various purposes, we recommend against using this\n permission - it can be abused for distributing illegal content, viruses, and\n other malware, and the bucket owner is legally and financially responsible for\n the content stored in their buckets.\n\n If you need to make content available securely to users who don't have user\n accounts, we recommend you use [signed URLs](/storage/docs/access-control/signed-urls). For example, with signed URLs\n you can provide a link to an object, and your application's customers don't\n need to authenticate with Cloud Storage to access the object. When you\n create a signed URL you control the type (read, write, delete) and duration of\n access.\n\nData uploads\n------------\n\n- If you use XMLHttpRequest (XHR) callbacks to get progress updates, do not\n close and re-open the connection if you detect that progress has stalled.\n Doing so creates a bad positive feedback loop during times of network\n congestion. When the network is congested, XHR callbacks can get backlogged\n behind the acknowledgement (ACK/NACK) activity from the upload stream, and\n closing and reopening the connection when this happens uses more network\n capacity at exactly the time when you can least afford it.\n\n- For upload traffic, we recommend setting reasonably long timeouts. For a good\n end-user experience, you can set a client-side timer that updates the client\n status window with a message (e.g., \"network congestion\") when your\n application hasn't received an XHR callback for a long time. Don't just\n close the connection and try again when this happens.\n\n- An easy and convenient way to reduce the bandwidth needed for each request is\n to enable gzip compression. Although this requires additional CPU time to\n uncompress the results, the trade-off with network costs usually makes it\n very worthwhile.\n\n An object that was uploaded in gzip format can generally be served in gzip\n format as well. However, avoid uploading content that has both\n `content-encoding: gzip` and a `content-type` that is compressed, as this\n may lead to [unexpected behavior](/storage/docs/transcoding#gzip-gzip).\n- We recommend using [resumable uploads](/storage/docs/resumable-uploads), which allow you to resume\n transferring data even when a communication failure has interrupted the flow\n of data. You can also use XML API multipart uploads to upload parts of a file\n in parallel, which potentially reduces the time to complete the overall\n upload.\n\nDeletion of data\n----------------\n\nSee [Delete objects](/storage/docs/deleting-objects) for guidelines and considerations on deleting data.\nYou can also use [features for controlling data lifecycles](/storage/docs/control-data-lifecycles) to help protect\nyour data from getting erroneously deleted by your application software or\nusers."]]
