Working With Cloud CLIs and APIs

Set up profiles properly, once

1. Configure a named profile per account and environment, never a single default that could be production.
2. Name them unambiguously: prod, staging, sandbox. Not default and default2.
3. Where the platform supports SSO or federated login, use it instead of stored keys.
4. Set a default region per profile, so a command does not accidentally target the wrong one.
5. Add the active profile to your shell prompt. This prevents the single most expensive category of CLI mistake.

A visible prompt indicator is a small change that has prevented a lot of production accidents.

Commands that stop mistakes

• Use the dry-run flag where it exists before anything destructive.
• Filter and query server-side rather than piping everything through grep; it is faster and less error-prone.
• Request JSON output and parse with jq for anything scripted. Table output formatting changes between versions.
• Confirm the account and region before destructive commands — most CLIs have a “who am I” equivalent.
• Prefer explicit resource identifiers to wildcards in anything that deletes.

The CLIs

VPS provider CLIs are much smaller and can be learned in an afternoon. Hyperscaler CLIs are large; learn the subset you need and look the rest up.

When to move from CLI to SDK

Shell scripts wrapping CLI calls work well up to a point. Move to an SDK when you need real error handling, retries with backoff, complex data structures, or concurrency.

• SDKs handle pagination, retries and authentication refresh for you.
• They give typed responses rather than JSON you parse by hand.
• They make concurrent operations practical.
• They are testable in a way shell scripts largely are not.

For infrastructure changes specifically, prefer Terraform over scripts. A script that creates resources has no concept of the current state, so re-running it is unpredictable.

Pagination and rate limits

1. Assume every list operation is paginated. A script reading only the first page will silently miss resources.
2. Handle rate limiting with exponential backoff and jitter, not a fixed sleep.
3. Batch where the API supports it, rather than making one call per item.
4. Cache results that do not change often, such as region and instance type lists.
5. For very large operations, check whether the provider offers a bulk or export mechanism.

The pagination mistake is quiet and dangerous — a cleanup script that only ever sees the first hundred resources appears to work.

Credentials for automation

Scripts running on a cloud instance should use the instance’s attached identity, not stored keys. The CLI and every SDK pick this up automatically from instance metadata.

Scripts running in CI should use OIDC federation. Scripts running on a laptop should use SSO or short-lived credentials. Long-lived keys should be the last resort, scoped narrowly and rotated. See API keys and secrets management.

Common questions

Where to go next

See infrastructure as code and cloud service quotas.