Different names.
Recognizable jobs.
Learn the problem each service solves before picking a logo. Use this map to connect the labs you have completed to the next layer of infrastructure.
These are sample names, not our infrastructure. Before copying commands, read Customize the examples: paths, keys, IPs and names. Substitute your own authorized account and resources. Existing lab? Retain its original resource names, usernames and state; renamed samples can cause replacement. See the existing-lab warning before applying updated recipes.
A small, useful service map
These are comparable categories, not interchangeable products. Region availability, permission models, pricing, limits and supported features differ. This is an orientation guide, not a promise that one provider's recipe ports unchanged to another.
| Job | AWS | Azure | Google Cloud |
|---|---|---|---|
| Run a virtual computer | EC2 | Virtual Machines | Compute Engine |
| Store objects/files through APIs | S3 | Blob Storage | Cloud Storage |
| Attach a block disk | EBS | Managed Disks | Persistent Disk / Hyperdisk |
| Run containers without managing a VM fleet | ECS with Fargate | Container Apps | Cloud Run |
| Manage Kubernetes workloads | EKS | AKS | GKE |
| Manage relational databases | RDS | Azure Database for PostgreSQL | Cloud SQL |
| Host DNS records | Route 53 | Azure DNS | Cloud DNS |
| Keep application secrets | Secrets Manager | Key Vault | Secret Manager |
| Collect metrics/logs and notify | CloudWatch | Azure Monitor | Cloud Monitoring / Cloud Logging |
Official three-cloud service comparisonAWS decision guidesAzure technology choices
1. How much of the computer do you want to manage?
You can own the kitchen, bring a lunchbox to a shared kitchen, or order one small meal when you need it. All make food; they give you different control and different chores.
| Pattern | You still decide | Good first question |
|---|---|---|
| VM | OS updates, processes, capacity, access and recovery | Do I need OS-level control or a long-running existing program? |
| Container on a VM | VM upkeep plus image lifecycle, runtime configuration and data | Can I package the app repeatably before adding orchestration? |
| Managed container platform | Images, IAM, ingress, scaling settings, dependencies and data | Can this platform support my runtime, networking and persistence requirements? |
| Function | Code, triggers, permissions, timeouts and downstream failures | Is this a bounded event-driven task rather than a whole server? |
| Kubernetes | Workload design, policy, configuration and operational expertise | Do my requirements justify the added complexity? |
Containers do not require Kubernetes. A platform that can scale to zero may still leave paid storage, networking, minimum instances, logging or external dependencies. Compare the whole design, not only the compute headline.
Try it now
Complete one container on your existing VM. Then write two responsibilities a managed platform could take over and two it would leave with you. Do not create a cluster just to answer that question.
2. Object, block, file, and database are different tools
| Type | Plain English | Wrong assumption to avoid |
|---|---|---|
| Object | A named parcel accessed by an API | It is a running server or a normal writable OS disk |
| Block | A disk the OS divides into filesystems | Deleting/stopping a VM necessarily deletes every disk |
| File share | A shared filesystem using a supported protocol | All shared filesystems have the same access and performance semantics |
| Database | A system that organizes queries and updates | Copying a live data directory is always a usable database backup |
Managed relational databases still need scoped access, patch/version planning, backup retention, tested restoration and a way to manage application connections. Do not use a publicly reachable database or open every IP to solve connectivity.
No-cost design exercise
For each item, name its storage type and recovery method: a public image, an Ubuntu boot disk, a shared team folder, and an order table. For the order table, explain how you would restore to a separate test database without overwriting the live one. This is planning; no database is provisioned here.
3. DNS, TLS, routing, and load balancing are separate jobs
DNS does not open a firewall. A certificate does not start your app. A load balancer does not guarantee that the backend is healthy. A private IP does not by itself prevent data leaving through another path.
The existing SSH-tunnel lab deliberately skips public DNS, certificates and load balancers. It is a temporary learner-access path, not public HTTPS hosting. Do not point your real GuidewellCloud domain at a disposable VM to practice.
Plan before adding infrastructure
- DNS: who owns the domain/zone, what record changes, and how will you undo it?
- TLS: where does encryption terminate, who renews the certificate, and is the backend leg protected?
- Load balancer: why is it needed, what healthcheck decides readiness, and what fixed/usage charges apply?
- Private egress: how do updates reach the VM without a public IP? Price NAT, endpoints and routing before removing the current access path.
These are design checkpoints. The Route 53 lab implements only a spare child zone and a test TXT record—not website migration, private networking or TLS.
4. Give the app an identity, not your password
A process calling a cloud API needs its own scoped authorization. Use the provider's supported workload identity pattern instead of putting a permanent human key into an image, Terraform variable or public repository.
Our demo container serves static content and needs no cloud API permissions. Do not attach an administrator role “for later.” A secrets service stores sensitive values with access controls; it does not fix an overly broad application identity.
Try it now
Use the identity review. Record separately: who deploys, who can SSH, what the running app can access, and who can read its secrets/logs. If the app needs no API, write “none” rather than inventing a permission.
5. Design the failure story as well as the happy path
Every new service introduces a failure mode and often another billable resource. Before deployment, answer:
- What signal proves the app works from the user's intended path?
- Which logs are needed, who may see them, and how long are they kept?
- What can be lost, and what is the acceptable recovery time?
- Which backup has actually been restored in a test?
- Who responds, and which exact runbook tells them what to do?
- What remains billable after stopping the main workload?
Use the operations lesson to gather evidence, then the Tenable/Ansible workflow to investigate one authorized-lab finding. Do not confuse “Terraform can rebuild the VM” with “the application data is recoverable.”
Your next three exercises
- Run and inspect one container on a single existing lab VM. Keep it loopback-only, pin the image, and verify cleanup.
- Write a one-page architecture record. Name the identities, data, access path, cost drivers and recovery evidence.
- Choose only one next managed service from the map. Read its official deployment, pricing and cleanup documentation; compare it to your current design before provisioning anything.