Linux CLI Best Practices
Shell habits that keep credentials and scripts safe.
//
Busque em todas as páginas da documentação
Shell habits that keep credentials and scripts safe.
Walk this list once, then use it as a quick self-review before you commit a script or run an ad hoc command against a real AWS account.
aws configure interactively, or better, use aws sso login, instead of aws configure set aws_secret_access_key <value>, so the value avoids the most obvious history trap.aws sso login or an assumed-role profile over static keys. Short-lived, auto-refreshing credentials remove an entire category of leak risk that static AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY pairs carry.AWS_PROFILE=x aws s3 ls never enters your shell's persistent environment, so there is nothing to forget to unset.unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN prevents them from leaking into later, unrelated commands in the same session.HISTCONTROL=ignorespace and use it. A leading space before a sensitive command keeps that one line out of shell history, going forward.set -euo pipefail. Exit on error, treat unset variables as errors, and propagate failure through pipes, instead of silently continuing on bad state."$var" instead of $var avoids word-splitting and glob surprises, especially with paths or ARNs containing special characters.aws ... || { echo "failed"; exit 1; } stops a pipeline before it acts on a response that never actually arrived.eval and unnecessary sudo in scripts that touch AWS resources. Both widen the blast radius of a mistake or an injected value.--query before grep/sed on structured output. JMESPath understands the JSON shape; grep/sed just match text and break silently when a field's format changes.jq -r when piping a value into another command. Raw output strips the JSON quoting that would otherwise corrupt a shell loop or variable assignment.--output json before piping to jq. jq cannot parse the CLI's table or text output formats.--filters server-side before --query/jq client-side. Both --query and jq run after the full response arrives; server-side filtering is what actually reduces data transfer.env/printenv on shared or recorded terminals. Both dump every exported variable, including credentials; check a specific variable instead, like printenv AWS_REGION.~/.aws/credentials at chmod 600. Owner-only read/write prevents other local users on a shared machine from reading static keys at rest..env files or ~/.aws/ contents to git. Add both to your global gitignore, since a single accidental commit can leak a credential permanently in history.bash step in CI is still code that runs unattended and repeatedly; quote it, test it, and review it accordingly.aws ... | jq . first avoids guessing at field names in Python or TypeScript.--query or jq line answers. If the entire task is "print this one field," the shell is usually faster and simpler than a script.Never type a raw secret as a command argument. It is the most direct path into shell history, and it is entirely avoidable by using aws configure, aws sso login, or an assumed-role profile instead.
grep and sed match text patterns, not JSON structure, so they break silently when a field's formatting or nesting changes. --query and jq understand the actual JSON shape and fail more predictably.
Without it, a failed aws call in the middle of a pipeline can let a script continue as if it had real data, potentially acting on an empty or partial response instead of stopping.
Yes on any shared or multi-user machine. The AWS CLI does not enforce this permission itself, and a world-readable credentials file is an easy, silent way to expose static keys to other local users.
Yes, especially anything committed to a repo or run in CI. It runs unattended and repeatedly just like application code, so the same quoting, error-handling, and review standards apply.
For a genuinely disposable, human-supervised check that touches no secrets and nothing destructive - reading a public bucket listing, checking an instance's state. Anything that writes, deletes, or touches credentials deserves the full list.
No, they only filter the response after AWS has already sent it. Server-side filtering (--filters, a request-level filter parameter) is what actually reduces what is transferred and billed.
Walk through groups A through D against your .bashrc/.zshrc, any scripts in your project, and your ~/.aws/ permissions once, then re-check whenever you set up a new machine or profile.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última atualização: 23 de jul. de 2026