Cloud Fundamentals: Regions, AZs & Serverless

Key terms in plain words

• Latency: the time a request takes to travel and get an answer. Low latency means fast.
• High availability: a design that keeps the system working even when some parts fail.
• Disaster recovery: the plan and tools to bring a system back after a very big failure, such as a whole region going down.
• Elasticity: the ability to grow and shrink resources quickly as demand changes.
• Object storage (like S3) is a service that stores files as "objects" in buckets. You read and write them over HTTP, and it keeps many copies for safety.
• Terraform is a tool that reads text files (written in a language called HCL) that describe your cloud resources, and then creates them. OpenTofu is an open-source fork of Terraform.
• AWS Lambda is Amazon's serverless function service. It runs your code when an event arrives.

Global infrastructure: regions and availability zones

• Region: a geographic area (like Mumbai, Frankfurt or Virginia) with several availability zones. Regions are isolated from each other, so a problem in one should not affect another.
• Availability Zone (AZ): one or more data centres inside a region. Each has its own power, cooling and networking. AZs are some distance apart (AWS says up to about 100 km) and are joined by fast private links. They are designed to fail independently: a fire, flood or power cut in one should not take down the others.
• Edge locations: many small sites around the world. They are used for CDN caching, DNS (the service that turns names into IP addresses) and edge compute, which means running code close to users (post 14).

Design implications:

• Single AZ: simple, but one data-centre problem takes you down. This is fine for dev and test, but not for production.
• Multi-AZ (the production standard): run servers, databases (with standby replicas, which are spare copies ready to take over) and load balancers across 2–3 AZs in one region. You survive the loss of a data centre. Latency stays low and the extra cost is small (post 40).
• Multi-region: survives the loss of an entire region and serves users around the world with low latency. But it is much more complex and expensive, especially for copying data between regions and keeping it consistent (posts 24 and 27–28). Use it for the most critical systems, or when the law requires it.
• Choose regions based on user location (latency), data residency laws (rules that say some data must stay in one country), service availability (not every service exists in every region) and price (it is different in each region).

Service models: who manages what

A service model tells you how much of the work the provider does and how much you do. Think of getting a meal: you can buy groceries and cook (IaaS), order a meal kit (PaaS), order from a menu (serverless) or eat in a restaurant (SaaS).

• IaaS (Infrastructure as a Service): rent virtual machines (computers that run as software), disks and networks. You get the most control, but you manage the operating system, the security updates (patching) and the scaling.
• PaaS (Platform as a Service) / managed containers: you give the platform your code or container. It runs, scales and patches it for you.
• Serverless / FaaS (Functions as a Service): you upload small pieces of code called functions. They run only when something triggers them. They scale automatically, and you pay per request.
• SaaS (Software as a Service): you use finished software, like Gmail or Slack, in a browser.
• Managed services for building blocks: managed databases (RDS, Cloud SQL, Aurora), caches (ElastiCache, Memorystore), queues (SQS, Pub/Sub), object storage (S3, GCS) and search (OpenSearch Service). You get backups, replication (extra copies of data), patching and failover (automatic switch to a spare when something breaks) without running the servers yourself.

A common rule: prefer managed services for "undifferentiated heavy lifting". This means hard work that every company needs but that does not make your product special, like databases, queues and load balancers. Spend your team's time on your product, not on patching database servers.

Core building blocks (rough equivalents)

Networking basics:

• VPC (Virtual Private Cloud): your own private network inside the cloud. Other customers cannot see it.
• Subnets: smaller parts of the VPC. Public ones can be reached from the internet (used for load balancers). Private ones cannot (used for app servers and databases).
• Security groups / firewall rules: rules that say which network traffic is allowed in and out.
• NAT gateways let private servers open connections to the internet, while the internet cannot open connections to them. (Remember from post 40: use one per AZ, so there is a spare.)

Serverless

Serverless does not mean "no servers". Servers still exist. It means you do not manage them. With functions like AWS Lambda, this is what happens:

Great for:

• traffic that jumps up and down or is hard to predict (scales from zero to thousands and back),
• event processing: resizing images on upload, processing queue messages, webhooks,
• scheduled jobs and "glue" (small pieces of code that connect services),
• low-traffic APIs and internal tools (costs almost nothing when idle),
• small teams that do not want to manage infrastructure.

Watch out for:

• Cold starts. If a function has not run for a while, the platform must first start a new environment for it. This adds delay, from tens of milliseconds to a few seconds, depending on the language and the size of the code. You can reduce it with provisioned or "minimum" instances (copies kept ready), smaller packages and faster runtimes.
• Time and resource limits. For example, AWS Lambda stops a function after 15 minutes at most. Long jobs need other tools (post 38).
• Statelessness. The function forgets everything after it runs. Keep your data in databases, caches or object storage (post 7).
• Database connection storms. Thousands of function copies can each open their own database connection, and the database runs out of connections. Use a connection pooler or proxy, which shares a few connections between many clients (post 5).
• Cost at high, steady load. Paying per request can cost more than always-on servers when traffic is constant and heavy.
• Debugging and vendor lock-in. Vendor lock-in means it is hard to move to another provider. Testing on your laptop, tracing requests and moving to another provider all take more effort.

Serverless containers (like Cloud Run and AWS Fargate) are a popular middle choice. You give the platform a normal container, and it runs and scales the container for you, sometimes down to zero copies.

The shared responsibility model

You and the provider share the work of security and reliability:

• The provider secures "the cloud": the physical data centres, the hardware, the virtualisation layer (the software that creates virtual machines), and the machines behind the managed services.
• You secure "in the cloud": your data, identities and access (IAM, the system of users and permissions), configuration (for example not making storage buckets public, post 52), network rules, application code, operating system patching (for IaaS), encryption choices and backups (post 45).

The more managed the service is, the more the provider handles. But your data, your access control and your configuration are always your job. Many cloud breaches come from customer misconfiguration (wrong settings), not from the provider being hacked.

Cost awareness: the cloud bill

The cloud makes it easy to spend money, sometimes by accident. Know what costs the most:

• Compute (VMs, containers, functions). Right-sizing (choosing the right machine size) and turning off unused resources help here,
• Storage (disks, object storage, backups, snapshots). Cheaper storage classes and lifecycle rules (which move old data to cheaper storage) help (post 17),
• Data transfer (egress): you are often charged when data leaves the cloud, moves between regions, or even moves between AZs. This can be a surprisingly large part of the bill (post 10),
• Managed services priced per hour, per request or per GB.

Saving tips:

• Reserved instances and savings plans give a discount if you promise to use a set amount for 1 or 3 years.
• Spot / preemptible instances use spare capacity of the provider and can cost up to about 90% less. But the provider can take them back at short notice. They are great for batch jobs and stateless workers that can handle being stopped.
• Auto-scaling (adding and removing machines automatically) and scheduling (turn off dev environments at night).
• CDN caching reduces egress from your origin (the main servers), because the CDN answers many requests itself.
• Tag resources (add labels) by team and project, set budgets and alerts, and review costs often. This habit is called FinOps (cloud financial management).

Infrastructure as code

Do not build production by clicking around in web consoles. Infrastructure as code means you write your servers, networks and databases as text files that a tool reads and creates. Use Terraform / OpenTofu, AWS CloudFormation / CDK, Pulumi and similar tools. The example below is Terraform (HCL) code that creates a private storage bucket:

resource "aws_s3_bucket" "uploads" {  bucket = "myshop-user-uploads"}resource "aws_s3_bucket_public_access_block" "uploads" {  bucket                  = aws_s3_bucket.uploads.id  block_public_acls       = true  block_public_policy     = true  ignore_public_acls      = true  restrict_public_buckets = true}

• ✅ Repeatable: the same code builds dev, staging and production. It can also rebuild everything after a disaster (post 45).
• ✅ Reviewable: changes go through pull requests (a teammate checks them first), like application code.
• ✅ Auditable: the Git history shows who changed what and when.