Setting up AWS Organization for centralized management https://www.ordisi.us/posts/2026_2_aws_org/

A very accessible article! Definitely one I will be recommending to beginners. Out of curiosity, why SCPs but no RCPs? I like to refer newcomers to AWS's pre-made collections on GitHub, aws-samples/service-control-policy-examples aws-samples/resource-control-policy-examples Re: credentials, after 13 years of doing AWS work in small and large shops, and reading all sorts of open-source recipes and technical guides, I would say that new user bad habits die very hard. AWS CloudShell works well for bootstrapping Terraform without letting out an access key that provides

AdministratorAccess

. Cheers!

Honestly, I was unaware of RCPs until now lol, thank you for pointing them out

Glad to be of use. RCPs are great! And I think you'll love CloudShell for instructional purposes. Security benefits aside, I've found it takes even fewer steps to explain. No user and key to create. No AWS CLI to install and configure. No local package manager dependency for installing the Terraform CLI. No questions from frustrated readers with an incorrect PATH or an unusual or hopelessly out-of-date shell. (macOS ships with a 2007 version of Bash.) 😂 My pastable Amazon Linux 2023 / CloudShell Terraform installation instructions are embedded here: github.com/sqlxpert/docker-python-openapi-kafka-terraform-cloudformation-aws#installation Command blocks are deliberately broken up to give the user a chance to pause and read status output where it matters. I like CloudShell so much that I find myself using it for stuff I touch only every month or two. State stays in S3 of course, cloned source code and a backend override file hang around in the free CloudShell home directory (1 GB, retained 120 days), and I obliterate

.terraform*

between sessions.

I think you pointing out the OS differences is a big hurdle cleared by cloudshell. I feel bad about the instructions not being quite windows compatible, but providing instructions for all OSes is just not maintainable

Interesting. I'm glad you tried CloudShell, nevertheless! I usually have my users/readers pull Terraform templates down from GitHub to AWS CloudShell, not the reverse. A standard

git

comes pre-installed. If pushing changes up is necessary and AWS Identity Center isn't yet configured, I guess people will have to pick their poison 😂 : long-lived AWS credentials → local machine or GitHub token or SSH key → AWS CloudShell. Hopefully, most tutorials aren't for bootstrapping, so aws sso login can be used to get temporary AWS credentials on the local machine. Completely by coincidence, a recollection of $9000 AWS bill from a person's days as a new AWS user came up on my LinkedIn feed yesterday. He had lucked into a really bad tutorial that recommended just pushing the long-lived AWS access key up with the rest of the source code. 😱 (Although that sounds quaint, and stock GitHub might squawk today, I remember losing a battle at Slack 8 years ago, when I dared suggest a simple string match on

AKIA

as an imperfect, last line of defense. Amusingly, people now pay for tools that do just that.) For fun I tried Supplementary Packages for Amazon Linux [2023] (SPAL), to see if I could install the GitHub CLI easily, to run gh auth login in CloudShell. Alas, no dice. Thanks for this conversation. I enjoy your blog!

Likewise and thank you for the recommendation and perspective. I guess I was just thinking in terms of people building it from scratch and managing it thereafter. Pulling templates seems effective too I was able to get opentofu installed pretty easily on cloudshell, jumped into vim, and started pasting resources

This is really useful for me, @Joe Perez ! I think we're both wondering how best to get through to an audience. What skills can we assume? How do we prevent frustration? How do we help people be successful? I think

vim

would scare people away. I revert to it very naturally in CloudShell, but it was the editor I learned as a high school student in 1992, when I got started with Unix. A lot of instructions assume familiarity with

nano

, but I don't think newer and younger enthusiasts today spend much time with any non-graphical editor. The approach I've taken is to avoid instructions about editing. If it's not a file I supply in my repo, I have a code block in the instructions, designed for copying, pasting to a local (likely graphical) editor, copying again, and pasting to CloudShell (or to a shell on an EC2 instance, via Session Manager). Item 4 in github.com/sqlxpert/docker-python-openapi-kafka-terraform-cloudformation-aws#installation is an example. Another alternative to open-ended editing is the read Bash built-in. "Sample AWS CLI Commands..." at the end of Item 8 of github.com/sqlxpert/aws-rcp-s3-require-intelligent-tiering#installation is an example. With this, a user doesn't even need to know how to set an environment variable. The type-over default option and the option not to echo (though of course whatever "secret" ends up in the environment — watch for subsequent expansion on the command-line) are useful. With TF_VAR__name_ , you could realistically ask a user to supply 3 or 4 custom input values to Terraform module. What tricks do you have for making friction-free instructions?

I think your cat to file is the best option for avoiding vim when forced to use the terminal. , I usually to push people to use the IDEs they are comfortable with to keep things rolling