Before You Follow Along: AWS CLI Permissions, Costs, and Credentials Done Right

My AWS CLI is set up with an admin profile, and I want to be upfront about why that's true for me and wrong for you. Here's how I actually think about permissions, cost cleanup, and credential security when I'm not filming.

Why my CLI is running as admin (and why yours shouldn't)

I'll say this plainly at the start of every hands-on segment: my AWS CLI is configured with an administrator-level profile. That's not a recommendation — it's a filming convenience. When I'm walking through a demo, I don't want to stop every few minutes to go adjust a test user's IAM policy just so the next command in the tutorial will work. Admin access lets me move through a lesson without those interruptions.

But that convenience is exactly why it's the wrong setup for anyone doing real work in their own account. An admin profile can do anything — create, modify, or delete essentially any resource across the account. That's a lot of blast radius for a single set of credentials, and it's the kind of setup that turns a small mistake (a mistyped resource ID, a script that loops when it shouldn't) into a very large one. When you're following along and setting up your own CLI, I want you to scope your permissions down to what the exercise actually requires, not mirror what you see on my screen.

I bring this up not to hedge or cover myself, but because I've seen how easy it is for viewers to copy a setup wholesale without thinking about whether it fits their situation. A tutorial environment optimized for smooth recording and a production or even personal-learning AWS account optimized for safety are different things, and they call for different permission models.

Least privilege isn't just a buzzword — it's expected

The principle behind scoping down permissions has a name: least privilege. The idea is simple even if the implementation isn't always: give an identity only the permissions it needs to do its job, nothing more. If a role only ever needs to read from one S3 bucket, it shouldn't also have the ability to delete EC2 instances or modify IAM policies.

This isn't just a best practice I personally favor — it's the expectation in real-world AWS deployments, and it's the expectation on the certification exams too, at least based on how the exam content is generally structured around this principle. If you're studying for an AWS certification alongside a tutorial like this, know that the exam will test whether you understand least privilege, not whether you know how to grant broad access quickly. It's worth double-checking the current exam guide for your specific certification to see exactly how heavily this shows up, since exam content does get revised over time, but the underlying philosophy has been consistent for as long as I've been working with AWS.

The practical upshot is that least privilege isn't a one-time setup task — it's an ongoing discipline. Every time you create a new role, user, or policy, the default question should be 'what's the smallest set of permissions that lets this work?' rather than 'what's easiest to attach right now?' It's slower in the moment and it pays for itself the first time a credential leaks or a script misfires.

That permissions error might not be your fault

Here's a direct consequence of the admin-versus-scoped-access gap: if you've set up your own IAM user or role with restricted permissions — which, again, is what you should be doing — you're going to hit access-denied errors at points in a walkthrough where my screen just works. That's expected, not a sign you did something wrong.

When that happens, resist the urge to just slap an AdministratorAccess policy on your user to make the error go away. That solves the symptom and creates the exact problem I described above. Instead, treat the error as information: it's telling you precisely which permission is missing. Read the error message closely — AWS IAM errors usually name the specific action and resource that were denied — and add only that permission to your policy. It's a bit more friction than copying an admin setup, but you end up with a much better understanding of what each part of a demo actually requires under the hood, which is arguably more valuable than the demo itself.

This is also a good habit to build if you're heading toward certification. Exams love to test your ability to diagnose an access-denied scenario and identify the minimal fix, so getting comfortable reading IAM errors and mapping them back to specific policy statements is time well spent, independent of any single tutorial.

The cleanup step everyone forgets (and pays for)

Separate from permissions, there's a cost dimension to following along with any hands-on cloud tutorial: some of the resources you spin up will keep costing money until you explicitly tell AWS to stop. This trips people up constantly, and it's not because AWS pricing is intentionally confusing — it's because it's easy to finish a lesson, close the terminal, and move on with your day, forgetting that the thing you just created is still running in the background.

My rule of thumb, and the one I'd encourage you to adopt, is to treat cleanup as part of the exercise, not an optional afterthought. When a segment involves creating something that isn't free-tier or inherently temporary, make a mental note — or better, a literal checklist — of what needs to be destroyed, paused, shut down, or terminated once you're done. Depending on the service, that might mean terminating an EC2 instance, deleting a load balancer, tearing down a CloudFormation stack, or pausing a database. The exact verb depends on the resource, but the intent is the same: don't leave metered infrastructure running past the point where you're actively using it.

If you're working through a longer series of tutorials over multiple days, it's also worth doing a periodic sweep of your account — checking the billing dashboard and the resource lists for the services you've touched — rather than relying purely on memory. A five-minute check-in after each session is a lot cheaper than an unpleasant surprise on your next bill.

Ditch the stored credentials — use browser-based login instead

The last habit I want to pass along is about how you authenticate the CLI in the first place. It's tempting to generate a long-lived access key and secret key, drop them into a credentials file on your laptop, and never think about it again. I'd steer you away from that pattern.

Static credentials sitting on a local machine are a liability that just sits there indefinitely — if that machine is ever compromised, backed up somewhere insecure, or the file is accidentally committed to a repo, those keys are valid until someone manually revokes them. Instead, I use a browser-based login flow, similar in spirit to how you'd log into the AWS console, to get temporary, time-limited credentials for CLI use. When those credentials expire, they're just gone — there's no static secret sitting around waiting to be misused.

As I understand the mechanics of this, authenticating through a browser-based login causes your CLI identity to assume the permissions associated with whichever account or role you signed in as through that flow — much like AWS SSO / IAM Identity Center is designed to work. I'd treat the precise details here as worth confirming against the current AWS documentation for your specific setup rather than taking my word for it, since identity federation configurations can vary and AWS does update these flows over time. But the general direction — favor temporary, browser-issued credentials over permanent keys stored on disk — is a security posture I'd stand behind regardless of the exact implementation details in front of you.

If you're currently using long-lived access keys for your CLI, it's worth carving out time to migrate to a temporary-credential flow, even outside the context of any particular tutorial. It's one of those changes that feels like extra setup upfront and then quietly removes an entire category of risk from your workflow going forward.

Conclusion

None of this is meant to slow you down — it's meant to make sure the habits you build while learning are the ones you'll actually want in your own account later. If you take away one thing, let it be this: before your next hands-on AWS session, take five minutes to check what permissions your working credentials actually have and how they're stored, then decide if that matches what you'd want a stranger to have if your laptop went missing tomorrow.