Launch Checklist for Google Cloud Storage


This Launch Checklist for Cloud Storage gives recommended activities that you should complete for launching a commercial application that uses Google Cloud Storage. This checklist focuses on Cloud Storage-specific activities. You should also use the general checklist, Launch Checklist for Google Cloud Platform, to understand the activities you should also complete that apply to all services.

This Launch Checklist for Cloud Storage is designed for enterprise developers who are proficient with Cloud Storage. If you are just starting out with Cloud Storage, these instructions will not teach you how to use Cloud Storage; instead, new users should start with the Getting Started: Using the Developers Console or Getting Started: Using the gsutil Tool.

This checklist is broken down into four sections:

  • Architecture Design and Development
  • Alpha Testing
  • Soft Launch
  • Final Launch

The sections are presented in the order we recommend that you use them as you prepare to launch your application. For example, you should start with the Architecture Design and Development Checklist first; it contains activities that we recommend you do early in your app's development lifecycle. Similarly, the Soft Launch Checklist contains activities we recommend when you are close to launch. However, the exact timeline of the checklist activities and the time required for them depends on your app development time frame.

Architecture Design and Development Checklist

We recommend that you use this checklist in the early stages of the development of your application. This checklist is broken into four activity groups:

  • Software Architecture Work
  • Establishing Your Points of Contact with Google
  • Choosing Cloud Storage Features
  • Creating Launch Plans and Traffic Estimates

You can work on the checklist activities from the groups in parallel; however, we recommend that you start the software architecture-related activities as early as possible as they require more time to complete.

Software Architecture Work

Architect your solution following the guidelines in Best Practices. In particular, keep in mind that:
  • Bucket creation is expensive and rate-limited, so design your application for more object operations and fewer bucket operations.
  • An object can be updated or overwritten once per second, so be aware of hot spotting in your application.
  • Access control is a powerful way to manage access to resources; it needs to be considered during application design and then actively managed.
  • Bucket ownership and object ownership cannot be changed after a bucket or object is created.
  • Bucket location cannot be changed after a bucket is created.
In addition to the Cloud Storage Best Practices document, incorporate your own developers' experiences. Be mindful of operations outside of Cloud Storage that will affect the overall experience. For example, is your ISP peered with Google? Will you encrypt and compress data before transmission and need to decrypt and decompress before use? Will your objects be aggregate objects from which you'll extract ranges?

Establishing Your Points of Contact with Google

Consult Google Cloud Storage community support on Stack Overflow. It's a great source of information and practical advice.
Subscribe to the Google Cloud Storage - Announce group. Posts are made to this group for service updates and issue and incident reports. The Cloud Status Dashboard mirrors the issue and incident reports.
Ensure DevOps is familiar with the Google Cloud Platform Console and participates in testing. DevOps should be familiar with the management of users, service accounts, ACLs, buckets and objects through the console and with gsutil (one of the command-line tools bundled into the Cloud SDK). Monitor the Cloud Status Dashboard.

Choosing Cloud Storage Features

If your code already uses Amazon S3, it may be adaptable to the XML API with some minimal configuration changes. If you are creating a new solution, you may find preferable to use the JSON API with its associated client libraries.
Amazon S3 is a trademark of, Inc. or its affiliates in the United States and/or other countries.
If your application relies on the existence of large amounts of data in Cloud Storage, you should determine whether you will have sufficient time to upload/transfer the data before launch. Google Cloud Platform provides multiple mechanisms to support ingesting large amounts of data into Cloud Storage effectively: Online Cloud Import and Offline Disk Import.
If your application depends on the ability to upload large objects, you should consider whether resumable uploads and object composition are needed. Be mindful of the composition limit; an object can maximally be composed from 1024 other objects. To overcome this limit, a new object would need to be created.

Creating Launch Plans and Traffic Estimates

Calculate traffic estimates preferably with a spreadsheet model as this allows you to audit your assumptions and functionality. Start with whatever data points you have and continually evolve and refine the estimates. In your estimates, consider:
  • Bucket and object create, read, and delete operation queries-per-second (QPS) across all objects and for a single object.
  • Estimate overall read and write throughput.
  • Pay particular attention to usage spikes. For example, do your users mostly use your service at a particular time during the day? Do you spread client updates across the world or force updates all at once?
  • Do your users predominantly come from one specific region? This often occurs when you always access Cloud Storage from a specific compute location.
Create a test plan. Always include tests of all bucket and object methods. Test and test again. Make many tests as realistic as possible and include as many people and process as possible. Include tests that cover failure paths (slow responses, 503 responses).
  • If accessing Google Cloud Storage from a limited set of locations (e.g., data centers or on-premises environments), regularly test all methods for several days to ensure Google optimizes the network path between the request locations and Google.
Create a load-test plan. Anticipate “resetting” Google Cloud Platform projects each time (for example, delete buckets and objects) and, for international launches, test internationally. If users need to register to use the product, be sure to load test the new-user signup flow.

Alpha Testing Checklist

Use the Alpha Testing Checklist when you are close to code complete and want to get initial metrics about your application.

Stay current on client libraries and JSON API versions and release notes.
Revise traffic estimates.
Perform at least one more round of load tests.

Soft Launch Checklist

Prior to your application's commercial launch, we recommend using the Soft Launch Checklist activities to test your launch readiness.

Load-test for 1.5x-2.0x traffic estimates. The goal is to prepare for success and to find additional bottlenecks in your application.
Review your cost model against actual costs. Verify that operational costs will be within budget. Revise the Cost Model. Although the Google Cloud Platform pricing calculator enables decent estimates, it won’t be clear until load-testing exactly how much storage and network and operations (classes A & B) that your application uses.

Final Launch Checklist

Use the Final Launch Checklist shortly before and during your launch.

If you have followed the checklist to this point, your application is ready for a successful launch on Google Cloud Storage. Congratulations! We recommend that you also review the Final Launch Checklist in the Launch Checklist for Google Cloud Platform.

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Cloud Storage Documentation