Learn Cloud Computing - Cloud Storage Solutions (Block, File & Object Storage)

#Introduction

In episode 6, you ran a VM and learned how to choose and pay for compute. But a machine without storage is like an empty house — there's nowhere to keep anything. Episode 7 covers how data is stored in the cloud.

We'll break down the three storage types that are often confused: block, file, and object storage. Then we'll go deeper into object storage — buckets, objects, metadata, storage tiers, and lifecycle policies — because it's the foundation of modern architecture. At the end of the episode there's a comparison of the three providers along with CLI command examples.

#Three Types of Storage: Block, File, and Object

These three types differ in how data is accessed and what they're designed for. The easiest analogy: three ways of storing items in an office.

• Block storage is like a hard drive installed directly into one computer. The VM sees it as a complete disk device, written in small block units, with the lowest latency. One volume can only be attached to one VM at a time.
• File storage is like a shared folder on an office server. Many computers can open and write the same file via NFS or SMB protocols, complete with a folder hierarchy. Suitable for web farms that share assets.
• Object storage is like an external cloud storage service. You place files via an HTTP API, and each file becomes one "object" with a unique name and metadata. There's no concept of physical folders, and capacity is practically unlimited.

#Block Storage: The Disk for Virtual Machines

Block storage is the "disk" attached to a VM. On AWS it's called EBS, on GCP Persistent Disk, on Azure Managed Disks. A volume is created with a certain size, attached to the instance, then formatted and mounted like a regular hard drive.

The important patterns:

• Volumes can be resized (enlarged) without downtime — you just increase the size in the console and expand the filesystem from inside the VM.
• Snapshots can be taken periodically as point-in-time backups, then restored into new volumes.
• A volume is tied to one AZ — if you want to move it between AZs, you need a snapshot or a copy.

#File Storage: Sharing Between VMs

File storage answers the need for "several machines reading the same files". On AWS it's called EFS (Elastic File System), on GCP Filestore, on Azure Azure Files. It's exposed as an NFS or SMB mount point that can be attached to many VMs at once.

This is the right solution when several web servers need to share an upload directory, shared configuration, or static content generated by one process and read by others. Unlike block storage, which attaches to a single machine, file storage is shared — this difference is what determines when to use which.

#Object Storage: Buckets, Objects, and Metadata

Now for the star of this episode: object storage. On AWS it's called S3, on GCP Cloud Storage, on Azure Blob Storage. How it works is very different from the previous two types:

• A bucket is a storage container. Bucket names must be globally unique (on AWS and GCP) — they appear in the service's public URLs.
• An object is a single unit of data: the file itself plus metadata (content-type, size, custom tags, and so on). Objects aren't organized in physical folders; a "path" like reports/januari.pdf is only part of the name (key), not a real folder.
• Access is via the HTTP API — curl, SDKs, or CLIs like aws s3 cp or gsutil cp. No disk mount required.

#Practice: Copying Files to Object Storage

# AWS S3
aws s3 cp laporan-bulanan.pdf s3://backup-produksi/reports/
aws s3 ls s3://backup-produksi/reports/
 
# GCP Cloud Storage
gsutil cp laporan-bulanan.pdf gs://backup-produksi/reports/
gsutil ls gs://backup-produksi/reports/

Notice the pattern: aws s3 cp and gsutil cp use the same URI — the bucket name followed by a key. The main difference is at the permission and SDK level, not the concept.

#Storage Tiers and Lifecycle Policies

Not all data is equally "hot". Files accessed thousands of times a day deserve low-latency, expensive storage; archive files that may never be opened again can live on cheap, slow storage. Every provider offers storage tiers with a cost-versus-speed trade-off:

Managing tier transitions manually is tedious and error-prone. The solution: lifecycle policies — automatic rules that move objects between tiers based on age or the last access date.

{
  "Rules": [
    {
      "Id": "ArchiveAfter90Days",
      "Status": "Enabled",
      "Filter": { "Prefix": "reports/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    }
  ]
}

Read the rule above: all objects with the reports/ prefix that are 30 days old are moved to the STANDARD_IA tier, on day 90 to GLACIER, and on day 365 they're deleted. Without a single line of code, storage costs drop automatically as data ages.

#Comparing the Big 3 Storage Services

Summarized in one map, the three storage types across the three providers look like this:

#Conclusion

In this episode 7, you distinguished the three types of cloud storage: block for disks attached to one VM, file for sharing between VMs, and object for unlimited storage via an API. We also covered buckets, objects, metadata, the hot-to-archive storage tiers, and lifecycle policies that automate data movement to keep costs low.

The keys to take away:

• Block for a single machine's low-latency needs, file for sharing, object for unlimited scale.
• Lifecycle policies turn storage cost from a "fixed cost" into "automatically cheaper over time".
• A misconfigured public bucket is a source of data leaks — always check access.

Your architecture now has networking, machines, and storage. But one machine is still a single point of failure. In the next episode, episode 8, we'll discuss Cloud Load Balancing & Auto-Scaling — how to distribute traffic across many machines, avoid total failures, and make capacity follow load automatically.