Cloud CLI Tools Compared: aws, az, gcloud, doctl and hcloud

Five Command Lines, Two Different Philosophies

Every cloud provider ships a command line tool, and on the surface they all do the same job: authenticate, list things, create things, delete things. Spend a week with several of them and the differences become obvious very quickly.

The hyperscaler tools, aws, az and gcloud, are generated from enormous service APIs. They cover hundreds of services, they nest commands several levels deep, and they assume you will read reference documentation for each call. The developer cloud tools, doctl and hcloud, wrap a much smaller API surface by hand. You can hold most of their command set in your head.

Neither approach is wrong. Knowing which one you are holding, however, changes how you script against it. This comparison walks through installation, authentication, command grammar, output handling and multi account juggling for all five.

Getting Signed In

Authentication is where the tools diverge most, because it reflects how each provider thinks about identity.

The pattern is clear. The developer clouds issue a single API token per account or project, which you paste once and forget. The hyperscalers sit behind a full identity system, so signing in means picking a principal, a tenant or a project as well as proving who you are.

One practical consequence: a Hetzner token is scoped to one project, so a second project means a second context. An AWS profile carries a region, and forgetting to set it is the most common reason a resource seems to vanish. The AWS CLI configuration reference and the gcloud configurations guide are worth reading once rather than guessing.

How the Commands Are Shaped

All five follow a noun then verb structure, but the depth varies. Listing virtual machines looks like this:

• aws ec2 describe-instances
• az vm list
• gcloud compute instances list
• doctl compute droplet list
• hcloud server list

The AWS verb is describe rather than list because the CLI mirrors the service API operation names exactly. That mechanical mapping is why the tool covers so much surface, and also why the help text reads like an API reference rather than a manual.

Creating a server shows the same split. hcloud server create --name web1 --type cx22 --image ubuntu-24.04 --ssh-key laptop is one line with obvious flags. The equivalent aws ec2 run-instances needs an AMI identifier, an instance type, a subnet, a security group and a key pair name, because EC2 genuinely has all those dimensions. Complexity in the tool tracks complexity in the platform.

Discovery works the same way everywhere: append help or --help at any level. gcloud compute instances --help lists the subcommands, and aws ec2 help opens a pager with every operation the service exposes.

Turning Output Into Something a Script Can Use

Default output differs, so the first thing to learn for each tool is how to change it.

aws and az both default to JSON and both accept a JMESPath expression through --query, which means the filtering syntax transfers between them. A command such as aws ec2 describe-instances --query "Reservations[].Instances[].InstanceId" --output text returns bare identifiers ready for a shell loop. Azure has --output table, which is the friendliest human format of any tool here.

gcloud uses its own projection language instead, split across --format and --filter. Once learned it is expressive: gcloud compute instances list --filter="status=RUNNING" --format="value(name,zone)" does the filtering server side where possible.

doctl and hcloud keep it simple. Both print a table by default, both take --output json or -o json, and both let you choose columns, with doctl compute droplet list --format ID,Name,PublicIPv4 and hcloud server list -o columns=id,name,ipv4.

For anything beyond a single field, pipe JSON into jq rather than fighting the built in expression language. It is the same tool across all five providers, and a colleague reading the script later only has to know one syntax.

Working Across Several Accounts Without Accidents

Anyone who runs infrastructure for more than one client eventually deletes something in the wrong account. Each tool has a mechanism to prevent it.

Two habits make this safe. Put the active profile or context in your shell prompt, so the target is visible on every line rather than remembered. And run the verification command in the right hand column as the first step of any destructive script, comparing the answer against an expected value before proceeding.

Environment variables beat flags for automation, because a pipeline job that exports HCLOUD_TOKEN or AWS_PROFILE once cannot forget the flag on the twelfth command.

Which One Deserves Your Time

Learn the CLI for the provider you actually run, and learn it properly rather than copying snippets. The depth pays off in ways a console never does: shell loops over resources, reproducible bootstrap scripts, and quick answers to questions no dashboard page happens to show.

If you are starting out and want the shortest path from zero to a running server, the developer cloud tools are genuinely pleasant. A DigitalOcean account paired with doctl, or a Hetzner account paired with hcloud, gets you a machine in one command once the SSH key is uploaded, which the SSH key guide covers.

If your work involves AWS, the CLI is not optional, because plenty of EC2, IAM and networking settings are far easier to reach from the command line than from the console. An AWS account plus a well organised set of profiles is the normal working setup. The AWS and DigitalOcean comparison is a fair illustration of how platform breadth translates into tool complexity.

One caution: a CLI is for exploration and one off tasks, not for defining infrastructure. The moment a script creates resources that must exist again next month, move it to Terraform or a provider native template. The introduction to infrastructure as code explains where that line sits.

Key Takeaways

• Hyperscaler CLIs mirror large service APIs; developer cloud CLIs wrap a small API by hand. Expect the command depth to match.
• Authentication reflects the identity model: one pasted token for DigitalOcean and Hetzner, a full sign in for AWS, Azure and Google Cloud.
• aws and az share JMESPath through --query; gcloud uses --format and --filter; doctl and hcloud offer column selection plus JSON.
• Profiles, configurations and contexts exist to stop cross account accidents. Show the active one in your prompt and verify it before destructive work.
• Use environment variables in automation and flags at the keyboard, then graduate anything repeatable to infrastructure as code.