In the previous lesson we reached an uncomfortable conclusion: the instances of a managed group are disposable, they can vanish at any moment and therefore nothing important can live on their disk. Right now AlpinaShop has 60 GB of product images on the local disk of a rented physical server, with no real backup, served by the same process that renders the catalogue. This lesson solves that problem.

Cloud Storage is Google Cloud's object storage: a service where you keep files — images, videos, backups, exports, logs — with extreme durability, without managing disks or servers, and reachable over HTTPS from anywhere. It is probably the most cross-cutting service on the whole platform: it will turn up again in Cloud SQL backups (02-03), as a data source for BigQuery (04-01), as an artefact store in pipelines (06-01) and as the CDN's origin (03-03).

In this lesson you will understand the object model and why "directories" are an illusion; you will choose a location and a storage class on cost grounds; you will actually migrate the 60 GB to the alpinashop-catalogo bucket; you will secure access with uniform IAM and signed URLs; you will automate savings with lifecycle rules; and you will connect the Flask application to Storage in order to upload the image of a new product.

1. The object model: buckets, objects and the illusion of folders
2. Bucket names and location
3. Storage classes and their real cost
4. Migrating AlpinaShop's 60 GB
5. Access control: uniform IAM, ACLs and public buckets
6. Signed URLs for private content
7. Object versioning
8. Lifecycle rules
9. Retention and object locking
10. Metadata and Cache-Control
11. Notifications to Pub/Sub
12. Access from the Flask application with the Python library
13. Egress cost and design tips

Cloud Storage is not a file system. It has exactly two levels:

• Bucket: the container. Created once, it has a name that is unique across all of Google Cloud, a fixed location and a default class.
• Object: the file. It has a name (which may contain slashes), binary contents and some metadata.

And nothing else. Directories do not exist. When you see this in the console:

what is really there is three objects whose full names are mochilas/moc-40-frontal.jpg, mochilas/moc-40-lateral.jpg and botas/bot-gtx-frontal.jpg. The / slash is just another character in the name; the console and the tools interpret it as a separator and simulate a hierarchy using prefixes.

Very real practical consequences:

• Renaming a "folder" with many objects is not an atomic operation: it means copying and deleting every object.
• An empty folder does not exist. If you delete every object with the mochilas/ prefix, the folder disappears from view.
• Listing is an operation by prefix. Listing gs://bucket/mochilas/ walks the objects starting with that string; in buckets with millions of objects, the choice of prefix matters for performance.
• Your naming design is your schema. A good prefix convention replaces the folder structure.

For AlpinaShop we settle on this convention, which we will use throughout the course:

The date prefix in exportaciones/ is not accidental: it makes lifecycle rules and partitioned loads into BigQuery easier.

Other important properties of the model:

• Objects are immutable. You do not modify an object: you replace it with another one of the same name. There is no such thing as "writing at byte 500".
• Strong consistency. After a successful write, any subsequent read returns the new version; listing is consistent too. This was not always the case in other clouds, and it eliminates a whole category of bugs.
• Advertised durability of eleven nines (99.999999999 %) a year. Do not confuse durability with availability, or with protection against human error: if you delete an object, it is deleted. That is what versioning is for (section 7).

The bucket name is globally unique, shared with every Google Cloud customer in the world. If catalogo is taken — it is — you will have to choose another one. The rules:

• Between 3 and 63 characters, lower case, digits, hyphens, underscores and dots.
• It cannot begin with goog or resemble google.
• It cannot look like an IP address.
• The name is visible to whoever receives a URL: do not put sensitive information in it.

Since the namespace is global, the usual convention is to prefix it with the name of the organization or the project. AlpinaShop will use alpinashop-catalogo; if that were taken, alpinashop-catalogo-prod or similar.

The location is immutable: it is decided when the bucket is created and cannot be changed. To move it you have to create another one and copy. Three types:

The criterion for AlpinaShop: the images are served to customers in Spain and Portugal, and the compute (the MIG's VMs, App Engine, GKE) is in europe-west1. A regional bucket in europe-west1 is the right choice: minimum cost, minimum latency towards the compute and zero egress charges between services in the same region. Geographic distribution towards the end customer will be handled with Cloud CDN (03-03), not by paying for a multi-region bucket.

The last two flags deserve attention right away: --uniform-bucket-level-access disables per-object ACLs and lets all access be governed by IAM (section 5), and --public-access-prevention stops anyone — even by mistake — making the bucket public. Both are security good practices that are much harder to turn on later than at the start.

All objects are stored with the same durability and the same access latency (milliseconds, even in Archive). What changes between classes is the balance between what you pay to keep them and what you pay to read them.

The amounts are orders of magnitude as of 2026 for reasoning about proportions, not price lists. Always check the official Cloud Storage pricing page and the Google Cloud calculator.

The minimum duration is the most frequent trap. If you store an object in Coldline and delete it after 10 days, you are billed just the same as if it had been there for 90 days. And if you read it several times, the retrieval cost can far exceed the storage saving.

Rule of thumb: the saving from a cold class is only real if the object is almost never read and is going to stay for a long time.

An indicative calculation for AlpinaShop. Its 60 GB of images, with the thumbnails and web versions that will be generated, will come to around 90 GB:

Conclusion: for the catalogue's live images, Standard. Cold classes will be reserved for old versions and exports, through lifecycle rules (section 8). Optimising 90 cents a month while paying for oversized instances is a poor use of your time; in 07-05 we will systematise where the real money is.

There is also Autoclass, which automatically moves each object between classes according to its actual access pattern, with no retrieval cost for the transitions. It is the sensible option when you do not know how the data will be accessed:

Marta has the images in /var/www/imagenes on the physical server. The goal is to get them into gs://alpinashop-catalogo/productos/ without interrupting the current shop.

Step 1: install the CLI and authenticate on the source server. The physical server is not a Google VM, so it needs credentials. The right approach is a service account with write-only permission on that bucket:

Two important warnings. First: the objectCreator role allows objects to be created but not read or deleted; if that key leaked, the damage would be limited. Second: service account JSON keys are long-lived credentials and the most dangerous asset in a project. Delete it as soon as the migration finishes (gcloud iam service-accounts keys delete). In 03-04 and 07-04 you will see keyless alternatives (Workload Identity Federation).

Step 2: first bulk copy. gcloud storage cp with --recursive uploads the whole tree. The modern version of the CLI parallelises automatically:

If you want to control the parallelism (for example, so as not to saturate the office connection during working hours):

Parallel composite upload splits a large file into chunks that are uploaded simultaneously and then reassembled on the server. It speeds up files of hundreds of MB a great deal, but it produces objects with a different kind of checksum (composite CRC32C), which can confuse older tools. For images of a few MB, like AlpinaShop's, it does not apply.

Step 3: incremental synchronisation. On cut-over day you do not want to upload 60 GB again, only whatever has changed. That is what rsync is for:

Careful with --delete-unmatched-destination-objects: it deletes everything at the destination that is not in the source. It is what you want for an exact mirror, and a catastrophe if you point the source at the wrong place. Before running it for real, use the simulation:

Step 4: verify. Check the number of objects and the total size:

When not to use the CLI. If you had tens of TB or the data were in another cloud, the right tool would be Storage Transfer Service, which handles retries, verification and scheduling without tying up your server; and for petabytes without the bandwidth, Transfer Appliance, a physical device Google sends you. For 60 GB over a decent connection, gcloud storage is more than enough: at 100 Mbps it is around 90 minutes.

There are two historical access control mechanisms, and it is worth being crystal clear about which to use:

With uniform bucket-level access enabled, ACLs stop having any effect and everything is decided with IAM. That is what we did when creating the bucket, and it has been Google's firm recommendation for years: the reason bucket data historically leaked was not a lack of controls, but that nobody was able to audit millions of individual ACLs.

The most used predefined roles:

That IAM condition is a good example of least privilege applied precisely: Lucía can read exportaciones/ and nothing else, with no need for a separate bucket. The full mechanism of IAM conditions is studied in 03-04.

Public buckets. Making a bucket readable by the whole internet is as easy as granting objectViewer to allUsers:

Real risks:

• What is public is public forever. A URL indexed by a search engine or cached by a third party cannot be withdrawn.
• You pay everyone's egress. If someone links your images from a busy forum, the bill is yours.
• A prefix mistake exposes the whole bucket, not just what you intended.

When it is reasonable: genuinely public static assets (CSS, JS, the logo) in a separate bucket created explicitly for that. AlpinaShop's product images, even though they are not secret, will be served through the CDN with the bucket as a private origin (03-03), not by opening it to the internet. That is why we created the bucket with --public-access-prevention.

So how does AlpinaShop let a customer download their invoice as a PDF, or let Dani share a file with a supplier, without making anything public and without giving them a Google account?

With a signed URL: a temporary link that embeds a cryptographic signature and works for a limited time. Whoever holds it can get access; when it expires, it stops working.

And from the application, which is where it is really used:

Details that matter:

• version="v4" is the current signing algorithm; always use this one.
• response_disposition forces the download with a friendly name, instead of opening the PDF in the browser under the object's internal name.
• The expiry must be short. A signed URL valid for 7 days is practically a public link: it gets forwarded by email and survives.
• It also works for uploading (method="PUT"): the user's browser uploads straight to Cloud Storage without going through your server, which saves bandwidth and processing time. It is the recommended pattern for large uploads.
• Signing requires a key. If the application runs on a VM or on Cloud Run with a service account and no key file, it needs the iam.serviceAccounts.signBlob permission (the Service Account Token Creator role) in order to sign through the IAM API.

Objects are immutable, but their names are not: if you upload another object with the same name, the previous one is lost. And if someone runs a badly aimed rsync, a great deal more is lost.

Versioning makes every overwrite or deletion keep the previous version as a noncurrent version, identified by a generation number:

The #<generation> suffix identifies a specific version. Restoring simply means copying it over the current one.

Versioning is the only real protection against human error — accidental deletion, the wrong script, ransomware — but it has a cost: you pay for all the versions. Without a lifecycle rule that cleans up the old ones, the bucket grows indefinitely. They always go together.

A lifecycle rule is a policy that Cloud Storage applies automatically to objects meeting certain conditions. It is defined in JSON:

Rule by rule:

1. At 30 days, exports move to Nearline. Lucía's reports are consulted a lot in the first week and hardly ever afterwards. matchesStorageClass stops the rule reprocessing objects that have already been moved.
2. At 180 days they move to Coldline. They are kept in case a history needs rebuilding, at a quarter of the cost.
3. Noncurrent versions are deleted 30 days after they stop being current, provided at least 3 newer versions exist. The combination of the two conditions is deliberate: it guarantees a recovery time window and a minimum number of versions kept.
4. Incomplete multipart uploads are aborted after 7 days. An interrupted large upload leaves fragments that take up space and are billed without appearing when you list the bucket. It is a classic phantom cost; this rule should be in all your buckets.

Applying and checking:

Warnings about the behaviour: the rules are evaluated once a day asynchronously, so do not expect an immediate effect; and transitions to cold classes restart the minimum duration, so moving something to Coldline when you are going to delete it in a month is counterproductive.

Notice that we apply no transition at all to the catalogue's live images: they are read constantly and must stay in Standard.

When the law or a contract requires data to be kept for a period, versioning is not enough: anyone with sufficient permissions can delete the lot. That is what two stronger mechanisms are for.

Bucket retention policy: no object can be deleted or overwritten until it reaches the stated age.

Locking the policy (lock): it makes retention irreversible. Neither the project owner, nor the organization administrator, nor Google support can reduce or remove it. The period can only be increased.

It is one of those operations that admit no second thoughts: if you lock 6 years, that bucket cannot be emptied for 6 years, and nor can it be deleted while it contains objects. That is exactly its purpose (regulatory compliance, protection against an attacker with administrator credentials), but it demands complete certainty.

In addition, retention on individual objects lets you mark specific objects with a retention date, and event-based holds and temporary holds freeze an object indefinitely until the hold is released (useful, for example, in the face of litigation).

Every object has metadata, some of which turn directly into HTTP headers when it is served:

Why Cache-Control matters so much. When we put Cloud CDN in front of the bucket (03-03), this header is what decides how long the CDN keeps each object at the points of presence. A high max-age means most requests are served from the edge of the network: faster for the customer and far cheaper, because they never leave the bucket.

The problem is what happens when an image changes. That is why the correct technique is to name objects immutably: if the file includes a hash or a version (frontal-800.a3f9c1.webp), it is never overwritten, and publishing a new image means publishing a new name. That way you can cache for a year without fear. It is the same idea you already used without realising it when versioning the instance templates in the previous lesson.

By default, Cloud Storage objects are served with Cache-Control: public, max-age=3600, which is rarely what you want. Set it explicitly when uploading.

Cloud Storage can publish a message to a Pub/Sub topic every time an object is created, deleted, archived or has its metadata changed. It is the basis of event-driven architectures:

The natural use case for AlpinaShop: when the team uploads an original image to productos/<sku>/original/, an event is published, and a consumer automatically generates the web version and the thumbnail. The OBJECT_FINALIZE event fires when the write has completed, not when it starts.

We will not develop it here: Pub/Sub has a lesson of its own (04-04) and the natural consumer would be a Cloud Function (06-03). Hold on to the idea that the bucket is not a passive store but a source of events.

The moment has come to connect AlpinaShop's catalogue to the bucket. Installation:

About authentication: the code carries no passwords and no paths to key files. The library uses the Application Default Credentials we saw in 01-06, and resolves them in this order: the GOOGLE_APPLICATION_CREDENTIALS variable if it exists, then the credentials from gcloud auth application-default login on your laptop, and finally — when the code runs on a VM, on GKE or on Cloud Run — the attached service account, obtained from the metadata server. The same code works locally and in production with no changes. This is one of the great strengths of the Google Cloud model.

Teaching points from the code:

• storage.Client() outside the view. Creating it on every request is a common performance mistake: it means resolving credentials and opening new connections every time.
• Extension validation and secure_filename. Never build the object name directly from what the user sends: it could contain ../ or unexpected characters.
• upload_from_file with the stream. It uploads in streaming without touching the instance's disk, which can disappear at any moment.
• A name with a UUID. It avoids collisions and makes the object immutable, enabling the aggressive caching from section 10.
• Signed URLs when listing. The bucket is private; the images are shown with temporary links. In production this will be replaced by the CDN with a private origin (03-03).

Downloading an object is just as direct:

Storage in Cloud Storage is cheap. What surprises people on the bill is almost always the egress: the traffic leaving Google Cloud towards the internet.

An indicative example for AlpinaShop: if the shop serves 200 GB of images a month straight from the bucket, the egress comes to around $16–24/month, against less than $2 of storage. In other words, moving the data costs ten times more than keeping it. That is why the CDN is not a performance luxury but a cost measure too.

Design tips that follow from all of the above:

• Put the compute in the same region as the bucket. europe-west1 in both cases: zero transfer cost between services.
• Serve the images through the CDN with a long Cache-Control and immutable names.
• Optimise the weight before uploading. Converting to WebP and resizing reduces egress proportionally; it is the most profitable cost optimisation in this lesson.
• Watch out for very small objects. Millions of tiny files pay more in operations than in storage; sometimes it is worth grouping them.
• Always enable the rule that aborts incomplete multipart uploads.
• Label the buckets with entorno, equipo, centro-coste and aplicacion so that spend can be apportioned (01-04).

• Thinking in folders. They do not exist. Renaming a prefix with 50,000 objects means copying and deleting 50,000 objects.
• Choosing the location badly. It is immutable. An EU multi-region bucket to serve Spanish customers costs more without adding anything over europe-west1 + CDN.
• Putting everything in Coldline "to save money". If the objects are read, the retrieval cost and the minimum durations work out dearer than Standard.
• Enabling versioning without a lifecycle rule. The bucket grows forever and nobody notices until the bill.
• Making a bucket public "for a quick test". What is public gets indexed, and turning off access does not delete what has already been copied.
• Using per-object ACLs. Impossible to audit. Enable uniform access and work with IAM.
• Signed URLs with an expiry of days. They amount to public links: they get forwarded.
• Forgetting Cache-Control. The default of 1 hour ruins the CDN's effectiveness.
• Creating the Storage client on every Flask request. An unnecessary latency penalty on every request.
• Tip: use --dry-run before any rsync with deletion.
• Tip: name objects immutably (a hash or a UUID). It simplifies caching, versioning and publishing.
• Tip: delete service account JSON keys as soon as the one-off task that justified them is over.
• Tip: review spend per bucket with the billing export to BigQuery you configured in 01-04.

1. Create a bucket with a unique name (alpinashop-catalogo-<yourinitials>) in europe-west1, Standard class, uniform access and public access prevention.
2. Create locally a structure simulating three products with one image each and upload it respecting the productos/<sku>/original/ convention.
3. Check that no real "folders" exist: list the objects with their full name.
4. Work out the total size and the number of objects.
5. Apply a one-year Cache-Control to every image under productos/.

1. Enable versioning on your bucket.
2. Overwrite one of the images with different content and list all the versions.
3. Restore the original version by its generation number.
4. Write and apply a lifecycle file that: moves to Nearline anything under exportaciones/ older than 30 days, deletes noncurrent versions older than 15 days while keeping at least 2 newer ones, and aborts incomplete multipart uploads after 7 days.
5. Verify the configuration applied.

1. Create a service account sa-tienda-lectura with read-only object permission on your bucket.
2. Generate a signed URL valid for 10 minutes for one of the images and check it with curl.
3. Check that the direct URL (unsigned) returns 403.
4. Write a Flask endpoint that receives a file by POST, validates the extension, uploads it with an immutable name under productos/<sku>/original/ and returns a 5-minute signed URL.
5. Explain why the code contains no credentials.

Solution 1

In point 3 you will see output like gs://<bucket>/productos/MOC-40/original/frontal.jpg: a single object whose name contains slashes. There is no "folder" entity you can describe or assign permissions to.

Solution 2

An important note: the restore works because versioning was on before the overwrite. Enabling it afterwards recovers nothing. That is the reason to enable it the day the bucket is created, not the day the accident happens.

Solution 3

5. The code contains no credentials because the client library uses the Application Default Credentials. On Dani's laptop they are the ones from gcloud auth application-default login; on the MIG's VM, on GKE or on Cloud Run they are those of the attached service account, obtained from the metadata server and rotated automatically. The same code, with no changes and no key files, works in both places. That is the identity model we will go deeper into in 03-04.

Cleaning up when you finish:

AlpinaShop's 60 GB of images no longer depend on the disk of a physical server. You have understood that Cloud Storage is not a file system but a flat object store, where folders are an illusion built on top of prefixes, and you have settled on a naming convention (productos/<sku>/original|web|thumb/, exportaciones/<date>/) that will hold up the rest of the course. You know that the bucket name is global and that the location is irreversible, and you have reasoned why a regional bucket in europe-west1 is a better choice than a multi-region one for a shop that will serve its images through a CDN. You know the four storage classes, their minimum durations and the trap of the retrieval cost, and you have arrived at an honest conclusion: live images stay in Standard, and cold classes are reserved for old exports.

You have done the real migration with gcloud storage cp and rsync, with controlled parallelism, a prior simulation and subsequent verification, using a service account with creation permission only. You have secured the bucket with uniform access, public access prevention, minimal roles and an IAM condition that limits Lucía to exportaciones/; and you have learned to share private content with short-lived v4 signed URLs, both for reading and for direct upload. You have enabled versioning — the only net against human error — always accompanied by lifecycle rules that stop the bucket growing out of control, including the rule that aborts incomplete uploads. You have seen locked retention for legal obligations, you have tuned Cache-Control and you have understood why immutable names are the key to caching. And you have connected the Flask catalogue to the bucket with the Python library, without a single credential in the code.

One piece of AlpinaShop is still anchored to the physical server, and it is the most delicate of all: the tienda database, that single PostgreSQL Marta administers by hand, with no replica, no failover and with backups nobody has ever tried to restore. In 02-03, Cloud SQL, we will migrate it to the managed instance alpinashop-pedidos: we will compare which tasks Marta stops doing, create the instance with regional high availability and a read replica for Lucía's reports, configure automatic backups and point-in-time recovery, connect the Flask application securely with the Python connector and carry out the real migration with pg_dump and an import from the bucket we have just created.