Cloud Foundations#

Sub-chapter 5 of DevOps · Someone else's computer, and someone else's account

Everything you have run so far has been local: Docker on your laptop, a kind cluster, a homelab box. That is deliberate, because owning the whole machine teaches you what the abstractions are hiding. But no Welzin customer runs their production system on your laptop. They run it on AWS, GCP, or Azure - usually in an account you do not control, with a security team who wants to know exactly what you are about to create.

This sub-chapter is the missing bridge. It will not make you a cloud architect. It will make you the engineer who can be handed a customer's cloud console and not break anything, not overspend, and not get blocked for three weeks.

---

Outline#

1. The three providers, and why the differences matter less than you think
2. The mental model: regions, availability zones, and the shared responsibility line
3. IAM - the thing that will actually bite you
4. Networking: VPCs, subnets, and why your database cannot be reached
5. Compute: the ladder from VM to serverless
6. Managed data: databases, object storage, and the queue
7. The bill: what costs money, and the four charges that surprise everyone
8. Working in a customer's account, without incident

---

1. The three providers#

AWS is the biggest and the most likely to be in front of you. GCP tends to show up where the team is data or ML heavy (BigQuery is genuinely a differentiator). Azure shows up where the company already runs Microsoft everywhere, which in enterprise India and enterprise anywhere is a lot of companies.

The good news for a forward deployed engineer: the primitives are the same and they map almost one to one.

Concept	AWS	GCP	Azure
Virtual machine	EC2	Compute Engine	Virtual Machines
Managed Kubernetes	EKS	GKE	AKS
Object storage	S3	Cloud Storage	Blob Storage
Managed Postgres	RDS / Aurora	Cloud SQL	Azure Database for PostgreSQL
Serverless function	Lambda	Cloud Run functions	Azure Functions
Container service	ECS / Fargate	Cloud Run	Container Apps
Secrets	Secrets Manager	Secret Manager	Key Vault
Identity	IAM	IAM	Entra ID + RBAC
Private network	VPC	VPC	VNet

Learn one deeply and you can find your way around the other two in a day, because the questions are identical: who is allowed to do this, what network is it on, what does it cost, and how do I get the logs. Spend your depth on AWS unless a customer forces otherwise, and stop worrying about which is "better" - you rarely get to choose. The customer chose years ago.

2. The mental model#

Three ideas carry most of the weight.

Regions and availability zones. A region is a geographic location (ap-south-1 is Mumbai, asia-south2 is Delhi). An availability zone is an isolated datacenter within that region. Two rules follow: put your compute in the same region as your data, or you pay for the distance in both latency and egress charges; and spread across zones if the service must survive one datacenter failing. For Indian customers, ap-south-1 is usually the right default - and increasingly it is a compliance answer, not a latency one, because data residency requirements say the data stays in India.

Everything is an API. The console is a website in front of an API. Anything you click, you could have scripted. This matters because clicking is unreproducible: the whole point of infrastructure-as-code (Terraform, Pulumi, CloudFormation) is that the customer's environment can be recreated, reviewed in a pull request, and destroyed cleanly. Click to learn, script to ship.

The shared responsibility model. The provider secures the cloud; you secure what you put in it. AWS guarantees the S3 service does not lose your object. AWS does not stop you from making that bucket public. Almost every cloud data breach you have read about lives on your side of that line: a public bucket, an over-permissive role, a hardcoded key in a repo.

3. IAM, the thing that will actually bite you#

If you remember one section, this one. IAM (Identity and Access Management) is where cloud work goes to die, because failures are non-obvious: a 403 at 11pm that means one of a dozen things.

The model, in the order things are evaluated:

• Principal - who is asking (a user, a role, a service account).
• Policy - a document saying which actions are allowed on which resources, under which conditions.
• Role - a set of permissions a principal can assume temporarily. This is the important one.

Rules that keep you safe:

1. Never use long-lived access keys for compute. A machine that needs S3 access gets an instance role (AWS) or service account (GCP) attached to it, and the SDK picks up short-lived credentials automatically. An AKIA... key pasted into a config file is the single most common cause of cloud compromise, because it leaks into git, Slack, and screenshots.
2. Least privilege, and start too small. Grant the specific actions on the specific resource. Starting narrow and widening on a real error is fast; starting with "Action": "*" and promising to tighten later is how * reaches production.
3. Humans use SSO, not IAM users. Federated login via the customer's identity provider means access dies when the person leaves.
4. Read the error properly. AccessDenied names the principal, the action, and the resource. That line tells you exactly which of the three is wrong.

The FDE trap: you will be tempted to ask a customer's cloud admin for broad access "to move faster". Ask for the specific permissions your deliverable needs and expect it to take a few days. Broad access makes you the most likely explanation for any incident during your engagement, deserved or not.

4. Networking#

The second most common source of confusion: things that will not connect.

• A VPC is your private network in the cloud. Inside it are subnets.
• A public subnet has a route to an internet gateway. A private subnet does not.
• Security groups are per-resource firewalls (stateful, allow rules only).
• To reach the internet out from a private subnet - to call an LLM API, for example - traffic goes through a NAT gateway, which costs real money per hour and per GB.

The canonical production layout: application in a private subnet, database in a private subnet with a security group that only accepts traffic from the application's security group, and a load balancer in the public subnet as the single front door. Nothing but the load balancer is reachable from the internet.

Ninety percent of "the database is not reachable" resolves to one of: wrong subnet, security group does not allow the source, or you are outside the VPC entirely and need the VPN. Check those three in that order before you debug anything in your code.

5. Compute: the ladder#

Pick the highest rung that fits, because each step up removes work you would otherwise own:

1. Virtual machine (EC2). Total control, total responsibility - patching, scaling, monitoring. Correct for legacy workloads, GPU boxes, or when a customer's policy demands it.
2. Managed container service (ECS/Fargate, Cloud Run, Container Apps). You hand over a container image and it runs. This is the sweet spot for most Welzin deliverables: your Docker skills transfer directly, no cluster to operate.
3. Managed Kubernetes (EKS/GKE/AKS). Right when the customer already runs Kubernetes, or you genuinely need its scheduling and ecosystem. Wrong as a default - a cluster is a system someone has to operate at 3am.
4. Serverless functions (Lambda, Cloud Run functions). Per-request billing, scales to zero. Excellent for glue, webhooks, and scheduled jobs. Watch for cold starts and execution time limits on anything doing heavy inference.

For most AI work you will land on rung 2 or 4, with GPU workloads on rung 1 or a specialised inference provider. Recall the Docker sub-chapter here: an image that runs cleanly locally runs on any of these.

6. Managed data#

Do not run your own database on a VM. Managed Postgres (RDS, Cloud SQL) costs more per month and saves you backups, failover, patching, and point-in-time recovery. That trade is almost always correct, and it is exactly the argument the Databases chapter makes about reaching for Postgres first.

Object storage (S3 and friends) is where files, model artifacts, and raw data belong. Three things to internalise: buckets are private by default and must stay that way (use pre-signed URLs for temporary access rather than making anything public); storage classes let cold data get much cheaper; and lifecycle rules can expire old data automatically, which is both a cost control and often a compliance requirement.

Queues and events (SQS, Pub/Sub, Service Bus) decouple slow work from the request path. The moment an LLM call takes 20 seconds, you want the API to accept the job, return an id, and let a worker do the work. That pattern is worth reaching for early.

7. The bill#

You will be asked "what will this cost to run?" and a shrug is not an acceptable answer for an engineer the customer is paying.

What actually drives cloud bills:

• Compute time. Instances bill per second while running, whether or not they are doing anything. Idle dev environments left up over a weekend are pure waste.
• Data egress. Data into the cloud is free; data out costs per GB. Cross-region traffic and NAT gateway throughput count.
• Managed service premiums. RDS costs more than the same-size EC2 box. You are buying the operations, and it is usually worth it.
• Storage that never gets deleted. Snapshots, old artifacts, logs with no retention policy. This grows silently for years.

The four that surprise everyone: NAT gateway hourly plus per-GB charges, idle load balancers billing while serving nothing, cross-AZ traffic between chatty services, and CloudWatch/logging volume on a debug-level logger left on in production.

Three habits: put billing alerts on every account before you deploy anything; tag every resource with project and owner so cost can be attributed; and use each provider's pricing calculator to produce an estimate before the customer asks. Bringing an unprompted cost estimate to a scoping conversation is one of the cheapest ways to look senior.

8. Working in a customer's account#

Everything above changes character when the account is not yours. This is where this sub-chapter meets Client Engineering:

• Ask for access on day one. Provisioning a role in an enterprise takes days to weeks. It is usually the critical path, and it starts the moment you say yes.
• Never create resources outside the agreed scope. A stray GPU instance on a customer bill is a trust incident, not a line item.
• Tag everything as yours. project=welzin-<engagement>, owner=<you>. When their finance team asks what this is, the answer should be in the tag.
• Leave the runbook. Which resources exist, what they cost, how to deploy, how to roll back, how to delete it all. Their on-call must be able to operate it without you. That runbook is part of the handoff, not an afterthought.
• Assume you are being audited. Every API call is in CloudTrail with your name on it. This is a feature - it protects you as much as them.

---

Hands-on Checkpoints#

Use a personal account with a hard billing alert set at a small amount before you start. Free tiers cover most of this.

• Create a billing alert first. Everything else comes after.
• Launch a VM, SSH in, and terminate it. Note the exact cost.
• Create a private S3 bucket, upload a file, and share it via a pre-signed URL that expires in 15 minutes. Confirm the raw URL is denied.
• Write an IAM policy granting read-only access to one bucket, attach it to a role, and verify from an instance that the SDK picks up credentials with no keys in your code.
• Deploy the container from the Docker sub-chapter to a managed container service and reach it on a public URL.
• Provision managed Postgres in a private subnet, then connect to it from your app and fail to connect from your laptop. Explain why in one sentence.
• Produce a written monthly cost estimate for that stack using the provider's calculator.
• Tear it all down, then confirm in the billing console that daily spend returns to zero. Forgetting this step is the checkpoint that teaches the most.

---

Further reading#

• AWS Well-Architected Framework - the five pillars; skim the Cost Optimization and Security pillars properly
• Google Cloud Architecture Framework - GCP's equivalent, shorter
• The Open Guide to Amazon Web Services - community-maintained, blunt about what is actually painful
• Terraform: Getting Started - click to learn, script to ship

Welzin opinion: Cloud skill is not memorising service names, it is knowing which questions to ask when something does not work: who is the principal, what network is it on, and what is it costing while I think about it. An engineer who can answer those three in a customer's account on day one is worth more than one who can recite the service catalogue.