Cloud Building Blocks: Compute, Storage, Databases and Networking

Cloud consoles list hundreds of services, which scares beginners. Here is the secret: a typical web application uses about eight of them. Learn these building blocks and you can read most architecture diagrams — on any provider.

The name table

Compute: virtual machines and auto scaling

A virtual machine (VM) is a computer you rent: choose CPU, memory, operating system and disk, and it is running in a minute or two. You pay per second or hour while it runs.

• Instance types balance CPU and memory differently — general purpose, compute-heavy, memory-heavy, GPU for AI.
• Auto scaling adds VMs when CPU or traffic rises and removes them when it falls. You set the rules ("keep average CPU around 60%, between 2 and 20 servers").
• Pricing options: on-demand (flexible), reserved or savings plans (cheaper for steady use, with a commitment) and spot/preemptible (very cheap, but can be taken back at short notice — good for batch jobs, not your database).

Storage: three different kinds

• Object storage (S3, Blob, Cloud Storage) — files stored as objects in "buckets", accessed over HTTP. Practically unlimited and cheap. Perfect for images, videos, backups, logs and static websites. Not a disk you can install an OS on.
• Block storage (EBS, Managed Disks) — a virtual hard disk attached to one VM. Fast; holds the OS and app data.
• File storage (EFS, Azure Files, Filestore) — a shared network drive many servers can mount at once.

Databases: managed is the default

You can install MySQL on a VM, but then backups, patches, replication and failover are your job. A managed database (RDS, Azure SQL, Cloud SQL) handles those, with multi-AZ standby and point-in-time recovery a few clicks away. Use relational databases for structured data with relationships (orders, users, payments); NoSQL for very high scale, flexible documents or key-value lookups.

Networking: the parts every developer must know

• VPC / VNet — your own private network inside the cloud, with an IP address range you choose.
• Subnets — sections of the VPC. Public subnets can be reached from the internet (load balancers); private subnets cannot (databases, internal services).
• Security groups / firewall rules — which traffic is allowed in and out of each resource. Rule of thumb: open only the ports you need, only to the sources that need them. The database accepts connections only from the app servers, never from the whole internet.
• Load balancer — one entry point that spreads requests across healthy servers in multiple zones, and handles HTTPS certificates.
• DNS — turns www.yourapp.in into the load balancer's address.

Putting it together: a classic web app

User → DNS (yourapp.in) → CDN (images, CSS, JS from object storage)
                       → Load balancer (public subnet, HTTPS)
                          → App servers in 2 zones (private subnets, auto scaling group)
                             → Managed database, multi-AZ (private subnet)
                             → Object storage (user uploads)

Read it from left to right and every arrow is a concept from this lesson. This exact shape — with different service names — runs a huge share of the web.