Cloud Diagnostics vs Linux CLI

When the Web UI is slow or the instance is unreachable, the CLI is your only diagnostic tool. However, each provider has a different “logical unit” you must remember:

• AWS: Instance ID based (i-xxxxxx).
• GCP: Project/Zone based (–zone).
• Azure: Resource Group based (–resource-group).

1. The Diagnostic Command Map

2. Boot Diagnostics (When SSH Fails)

If you see [FAILED] Failed to start OpenSSH, use these commands to see the “Serial Console” output.

AWS

aws ec2 get-console-output --instance-id i-xxxxxx

GCP

gcloud compute instances get-serial-port-output INSTANCE_NAME --zone=ZONE

Azure

az vm boot-diagnostics get-log --name VM_NAME --resource-group RG_NAME

3. Networking & Security Audit

Linux CLI : ip addr

• AWS Security Groups: Use –query to filter.
• GCP Firewalls: Remember these are VPC-based, not instance-based.
• Azure NSG: Always requires the Resource Group flag or the command will fail.

4. Filter Commands

• 4.1. JSON Filtering

Standard output for Cloud CLIs is a massive JSON wall . You should add the filtering flags to your commands.

• AWS: Uses --query (JMESPath).
• GCP: Uses --filter and --format.
• Azure: Uses --query (JMESPath).

note: JMESPath = James Saryerwinnie’s JSON Path; with some nick name: JSON Management Enterprise System.

JMESPath allows you to tell the CLI: Don’t show me everything; just show me the ID of instances that are currently running.

Example:

To see only the ‘Value’ of the status without the JSON brackets, use these filters:

AWS:

aws ec2 describe-instance-status --instance-ids i-xxx --query 'InstanceStatuses[0].InstanceStatus.Status'

Azure:

az vm get-instance-view -n VM -g RG --query "statuses[1].displayStatus" -o tsv

• 4.2. Authentication Check

A common failure point for CLI users is expired sessions. Logically, your guide should start with how to verify you are even logged in.

AWS

aws sts get-caller-identity

GCP

gcloud auth list

Azure

az account show

• 4.3. SSH Troubleshooting

Mostly, port 22 is blocked by a corporate firewall, but these “Tunneling” commands bypass it.

AWS:

aws ssm start-session --target i-xxxxxx 

(Requires SSM Agent).

GCP:

gcloud compute ssh INSTANCE_NAME 

(Automatically handles keys and firewall).

Azure:

az network connectivity check 

(To see if the path is even open).

• 4.4. Metadata Logic (Inside-out)

Add a section on how to run commands from inside the VM. This is a classic Linux diagnostic move. If you are logged into the Linux box and want to know its own Cloud ID or Public IP without checking the Web UI:

– 4.4.1. The “Magic” IP: 169.254.169.254

This is a Link-Local Address. Logically, it does not exist on the public internet. It is a “shortcut” that only exists inside the virtual network of your cloud provider. When your Linux VM calls this IP, it is talking directly to the physical host hardware it is sitting on.

– 4.4.2. Provider-Specific

You must use the correct “Handshake” (Header) for the provider, or the metadata service will ignore you to prevent “Server-Side Request Forgery” (SSRF) attacks.

AWS (IMDSv2)

AWS requires a “Token” first for security.

Step 1: Get a Token

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`

Step 2: Get the Instance ID

curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id

GCP (Google Cloud)

Google requires the Metadata-Flavor header to prove the request is intentional.

curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/id

Azure

Azure requires the Metadata header and the API version.

curl -H Metadata:true "http://169.254.169.254/metadata/instance?api-version=2021-02-01"