From storing files
to running computers.

Your first complete infrastructure lab

A server is a house. The network is its neighborhood. A subnet is its street. Firewall rules decide who can knock, and an SSH key proves you are allowed inside.

The AWS EC2 walkthrough builds a dedicated network, one public subnet, routing, a restricted firewall, an encrypted disk and an Ubuntu server. You connect securely, install Nginx, inspect the machine, then rebuild it with Terraform and configure it with Ansible.

1. Networking: the path to your server

Try it without creating resources

Inspect one existing lab network in your cloud console. Trace the subnet's route, the server's address and the firewall source. Draw the path from your laptop to the server. A route of 0.0.0.0/0 means “all IPv4 destinations”; the same range in an inbound firewall rule means “any IPv4 source.” They are not interchangeable.

AWS public-subnet exampleAzure virtual networksGoogle VPC overview

2. Identity: who is allowed to do what?

An IP firewall checks which street you came from. Identity checks who you are. You need both; opening a port does not grant a user account.

• Human identity: use MFA and short-lived cloud sign-in sessions. Do not use the AWS root account for labs.
• Deployment identity: Terraform needs permission to create exactly the kinds of resources in its recipe. An administrator should scope the role to a dedicated learning environment, with cost and organization controls.
• Workload identity: when a server needs cloud APIs, use an instance role, managed identity or attached service account instead of embedding a long-lived key.
• Operating-system identity: Ubuntu's ubuntu login and sudo permissions are separate from your cloud-console identity.

Try it

Find the identity attached to a VM and list its granted roles. Ask: does this web server need any cloud API permission? In the first AWS lab, the answer is no, so we attach no instance role. Never grant an administrator role just to silence a permission error.

AWS identity best practicesAzure managed identitiesGoogle service accounts

3. Compute and disks: a real computer

A VM has CPU, memory, an operating system and disks. You manage packages, updates, services and recovery. Unlike object storage, it can run a program that processes a request.

• Image: the starting operating-system snapshot. Verify the publisher, CPU architecture and licensing.
• Size: the CPU/memory allowance. A burstable size can slow down after credits run out or charge for surplus credits, depending on configuration.
• Block disk: storage mounted by the server. Encrypt it and inspect whether it survives termination.
• Object storage: files accessed through an API. It is not automatically a VM disk.
• Snapshot: a point-in-time disk copy, usually with separate storage charges. Application-consistent backups can require pausing writes or database-aware tools.

Try it inside the Ubuntu lab

cat /etc/os-release
lscpu
free -h
lsblk
df -h
systemctl status nginx --no-pager

Compare the CPU and memory with the chosen VM size. Compare lsblk (disks) with df (mounted filesystems). A stopped VM may still have billable disks.

4. Operations: know when something breaks

“The page opens” is only the first test. Good infrastructure is observable, recoverable and removable.

1. Check availability: cloud VM status checks, then service health inside the OS. A healthy VM can still have a stopped application.
2. Read logs: inspect Nginx access/error logs and system journal. Avoid logging secrets; plan retention and access before shipping logs to a paid destination.
3. Watch usage: CPU, disk fullness and failed requests. Default cloud VM metrics do not necessarily include memory or filesystem fullness; an agent may be needed.
4. Set alerts: budgets warn about money; health alerts warn about broken services. Neither is a universal automatic shutdown mechanism.
5. Test recovery: for the disposable lab, rebuild from Terraform and Ansible. For real data, keep tested backups and define acceptable data loss and recovery time.

sudo nginx -t
sudo journalctl -u nginx -n 30 --no-pager
sudo tail -n 20 /var/log/nginx/access.log
sudo tail -n 20 /var/log/nginx/error.log

Do not deliberately stop or delete a production resource to practice. Use only your isolated lab.

AWS monitoringAzure VM monitoringGoogle VM monitoring

5. Two tools, two responsibilities

Terraform keeps state linking your recipe to real resource IDs. Treat state and saved plans as private. Ansible connects to the OS and makes the desired configuration true. The new server playbook uses package, template and service modules so a repeat run normally leaves those resources unchanged.

Changing a firewall source should be an infrastructure change. Changing the page message should be a configuration change. Read a plan before applying it, and avoid having two tools manage the same setting.

Build with Terraform · Configure with Ansible

The same concepts, different cloud names

These are conceptual equivalents, not identical defaults or interchangeable security models. All three server walkthroughs are available: AWS, Azure and Google Cloud. Their existing storage guides remain available.

A practical order to learn

1. Available now: complete the AWS network + Ubuntu lab, automate it and clean it up.
2. Available now: repeat the server pattern in Azure and Google Cloud, comparing scopes, identities and firewall behavior.
3. Available now: restrict web access and use an SSH tunnel, review identities and permissions, then check health and test backup/restore on one existing lab server.
4. Available now: package an app in a loopback-only container on one existing VM, then record your architecture and evidence. Use the service map to choose the next problem to solve.
5. Available now: learn DNS and child-zone delegation with Route 53, then use Tenable, Trivy and Ansible to assess and remediate an authorized lab.
6. Next level: private subnets, controlled administration, HTTPS and load balancing. Price NAT and private endpoints before choosing an architecture.
7. After that: database backups, monitoring agents, managed containers and serverless. Add one service at a time so you can explain its purpose and cost.