Cloud Linux Administration

An Azure Linux VM is administered over SSH exactly as covered in Level 9 — the difference is entirely in what surrounds it. A Network Security Group (NSG) is Azure's cloud-level firewall, filtering traffic to the VM's network interface before it ever reaches the VM's own operating system — this means both the NSG and the VM's own OS-level firewall (ufw/firewalld, from Level 10) must allow a given port for traffic to actually get through; blocking at either layer alone is enough to deny access, which is exactly why "I opened the port in ufw but still can't connect" is frequently an NSG problem, not an OS problem, on Azure.

A managed disk is Azure's abstraction over the actual physical storage backing a VM's virtual disks — from inside the VM, a managed disk still appears as an ordinary block device (`/dev/sda`, etc.) that Level 8's partitioning, filesystem, and LVM concepts apply to completely unchanged; Azure's "managed" layer handles the underlying redundancy and physical placement, invisible to the guest OS.

VM extensions are Azure-specific agents that can run inside the VM to perform provider-integrated tasks — installing monitoring agents, running custom setup scripts at first boot, or integrating with Azure's own backup service — genuinely useful, but distinct from anything in core Linux administration; they're a cloud-provider convenience layered on top of a VM that remains, underneath, an ordinary Linux system administered the same way as any other.

AWS uses different names for largely equivalent concepts: an EC2 instance is the AWS term for a virtual machine — administered over SSH exactly like any other Linux server. A Security Group is AWS's direct equivalent of Azure's NSG — a cloud-level firewall attached to the instance's network interface, and just like on Azure, both the Security Group and the instance's own OS-level firewall must allow a port for traffic to actually reach a service.

EBS (Elastic Block Store) volumes are AWS's managed-disk equivalent — they appear inside the instance as ordinary block devices, and everything from Level 8 (partitioning, filesystems, even LVM on top of one or more EBS volumes) applies unchanged. IAM (Identity and Access Management) is AWS's permission system for controlling what AWS API actions a user, role, or the instance itself is allowed to perform — this is a distinct concept from Linux's own user/permission model covered in Level 4; IAM governs access to AWS services and resources (launching instances, reading from a storage bucket), not file permissions or sudo access inside the Linux system itself.

The practical administration skill genuinely transferable across both clouds (and any other cloud provider): recognize which layer a given problem lives in. "Can't SSH in at all" is often a Security Group/NSG problem. "SSH works but a specific application port doesn't" could be either layer, or the OS-level firewall, or the application not actually listening — the same layered diagnostic approach from Level 7's networking lesson applies directly, just with one more layer (the cloud provider's own firewall) added in front of everything you already know how to check.