Cloud Storage: Object, Block, and File Storage

Cloud Storage: Object, Block, and File Storage

Cloud providers offer three distinct storage models, each designed for different workloads. Choosing the wrong type causes performance problems, unexpected costs, or data access failures. This lesson explains each model, shows where it is used in real IT support work, and walks through hands-on tasks with Amazon Web Services (AWS) services that represent all three.

Object Storage

Object storage treats every piece of data as a self-contained object: the file itself, its metadata, and a globally unique identifier. Objects live in a flat namespace — there is no true folder hierarchy, only key names that may look like paths. You access objects over HTTP/HTTPS using a URL, making object storage ideal for web-facing content, backups, log archives, and software distribution.

AWS Simple Storage Service (S3) is the most widely known object storage service. You create a bucket (a named container), then upload objects into it. Each object can be up to 5 TB. S3 is region-based, but bucket names must be globally unique across all AWS accounts.

Key S3 access controls:

• Block Public Access — a bucket-level or account-level setting that prevents any policy or ACL from accidentally exposing data publicly. Always enable this unless you have a specific, reviewed reason not to.
• Bucket policies — JSON documents that specify who can perform which actions on which resources.
• Pre-signed URLs — time-limited URLs that grant temporary access to a private object without making the object permanently public. A support technician might generate a pre-signed URL so a customer can download a specific file for a set number of minutes.

Block Storage

Block storage presents raw storage to an operating system as if it were a physical disk. The OS sees a device, partitions it, formats it with a filesystem (ext4, NTFS, XFS, etc.), and mounts it. The OS then manages every read and write at the block level.

AWS Elastic Block Store (EBS) volumes are the primary block storage option for EC2 instances. Critical characteristics:

• An EBS volume exists in a single Availability Zone (AZ). You cannot attach the same volume to an instance in a different AZ without snapshotting and recreating it.
• EBS volumes persist independently of the instance — you can detach, reattach, or snapshot them.
• Block storage delivers low latency and is suited for databases, operating system root volumes, and any application that needs direct filesystem control.

Because block storage is AZ-bound, understanding AZ design is important for IT support work. If an AZ goes down, an EBS volume in that AZ is unavailable until the AZ recovers.

File Storage

File storage provides a shared filesystem that multiple clients can mount simultaneously over a network protocol. AWS Elastic File System (EFS) uses NFSv4; Azure Files uses SMB. Many clients — dozens or hundreds of EC2 instances — can read and write the same filesystem at the same time, which makes file storage ideal for shared application data, home directories, and content management systems.

Unlike EBS, EFS is a regional service. It is accessible from multiple AZs within a region simultaneously, so it does not share the single-AZ limitation of block storage.

Comparison Summary

| Attribute | Object (S3) | Block (EBS) | File (EFS) |

|---|---|---|---|

| Access method | HTTP/HTTPS URL | OS block device | NFS/SMB mount |

| Namespace | Flat (key-based) | None (raw device) | Hierarchical |

| Simultaneous clients | Many (via URL/policy) | One instance at a time (standard) | Many instances |

| Availability scope | Regional (multi-AZ) | Single AZ | Regional (multi-AZ) |

| Typical use | Backups, media, web assets | Databases, OS volumes | Shared app data, home dirs |

Safety and Access Control

Cloud storage misconfigurations are among the most common causes of data breaches in IT environments. Follow these practices on every lab and in every job:

1. Enable Block All Public Access on every S3 bucket by default. Only disable specific settings after a documented review.

2. Use the principle of least privilege for all bucket policies and IAM roles — grant only the permissions a user or service actually needs.

3. Never commit AWS credentials (access keys, secret keys) to a code repository or share them in chat. Rotate credentials immediately if they are exposed.

4. Encrypt data at rest and in transit. S3 supports server-side encryption; EBS volumes support encryption with AWS Key Management Service.

5. Log all access. Enable S3 server access logging or AWS CloudTrail so you can audit who accessed or modified objects.

These practices apply in your sandbox today and in production environments throughout your career.

Lab Overview

In today's lab you will:

1. Create an S3 bucket, upload three files, and generate a pre-signed URL.

2. Enable Block All Public Access and confirm a direct public URL returns a 403 Forbidden response.

3. Attach an EBS volume to a running EC2 instance, format and mount it, write a test file, then unmount it.

4. Record your observations in your lab log, including why block storage is tied to a single AZ.

Work carefully and methodically. Verify each step before moving to the next. If a step fails, read the error message, consult AWS documentation, and note what you learned in your lab log.