AWS context/profile switcher for AWS CLI and S3 clients

[retrogaming457]

Hi everyone,

I've built a small CLI tool called awsctx to simplify working with multiple AWS profiles across the CLI and other S3-compatible clients (like s3cmd, s5cmd, etc.).

If you often switch between AWS profiles, awsctx helps by:

• Quickly changing the active profile.
• Supporting both formats of AWS CLI config file - Standard and Service-Specific
• Exporting the correct environment variables (AWS_PROFILE, AWS_ENDPOINT_URL, etc.).
• Ensuring compatibility with tools that don’t support the AWS config format directly.

It works on both Linux and Windows shells.

This shell-based tool aimed at improving daily AWS workflows. If you're interested, feel free to check it out or suggest improvements.

🔗 GitHub - awsctx CLI tool

Thanks!

[uldyssian-sh]

Nice work — a lightweight profile/context switcher is genuinely useful, especially when you need to drive both AWS CLI and S3-compatible clients that don’t understand the AWS config format.

A few suggestions that would make a tool like this safer and more interoperable with the AWS ecosystem:

Make sure it never stores long-lived credentials itself.

Prefer switching via standard AWS mechanisms so everything “just works” with the AWS CLI and SDKs:

Use AWS_PROFILE (and AWS_DEFAULT_PROFILE where needed) rather than rewriting config.

export AWS_PROFILE=my-profile

aws sts get-caller-identity

If you support SSO profiles, it helps to remind users they must authenticate first:

aws sso login --profile my-sso-profile

If the goal is also S3-compatible clients, exporting endpoint variables can be helpful, but keep them scoped to the current shell session so users don’t accidentally leak settings into unrelated terminals.

Also consider compatibility flags commonly relied on by SDK users:

AWS_SDK_LOAD_CONFIG=1

This ensures SDKs load the shared config file the same way the CLI does in many environments.

Finally, a “dry-run/show” mode that prints exactly what environment variables would be set (without changing anything) is great for transparency and debugging.

Overall: if the tool primarily manages environment variables (AWS_PROFILE, optional AWS_ENDPOINT_URL, etc.) and avoids persisting secrets, it should play nicely with AWS CLI, SSO, and third-party S3 clients.

[uldyssian-sh]

Thanks! If this helps, please consider marking it as “Helpful” or “Accepted” 😊

[retrogaming457]

Thank you, @uldyssian-sh, for the suggestions—and for reminding me that I posted here 🙂

Since then, the awsctx tool has been completely redesigned with expanded capabilities, including SSO profile login support (and even a new name). It’s currently in the final stages of review and refactoring, and I’ll be committing the changes soon and updating this post.

Meanwhile, in new version, secrets are not persisted. They are only exported optionally using flag.