When using AWS, as a business you often want to collaborate with a development partner. You likely want to grant them access to a staging or development environment, and allow them to test their IaC (Infrastructure as Code) scripts in an isolated environment. You want to do this all under the "umbrella" of your current AWS organization, but you want to keep them separate from a security perspective. You also want payment to run through your corporate billing account, but itemized so you can correctly attribute the spend to that project. Finally, it's common that you might want an easy way to change what they have access to - maybe initially they have access to production (before launch), but later you want to remove that access. Or maybe you want to transfer control to another development partner for maintenance; either way security needs to be quick and flexible.

The first step is to understand that an "organization" is the wrapper within which you will have accounts. Because you want to grant access to a specific account and not the entire organization, create an organization if you don't already have one. Do not grant developer access at the organization level.

The next step here is understanding what an AWS "account" really is. An account is probably best thought of as an "environment". You will have one account for "staging" and one for "production". You may also have a "development" account, although it is increasingly common for developers to be able to use LocalStack to test their IaC scripts on their development workstations.

Each account you create within your organization needs to have an "owner root email address". It's pretty common for there to be a group email assigned to that account, and it's fine to use something provided by your development partner. As an example, at Sembit, if your company was named "CompanyX", and you want to initially grant us access to staging, we'd set up this email: "companyx-staging@sembit.com", which would forward to our tech lead and their backup. Note that an account owner email address must be unique.

When you create and save each new account, it generates an email to the owner email address. At this point you're done - our tech lead will get an email saying we're invited, go to the "sign in" link, select Root signin (instead of IAM - more on that later), and click "reset password" to get started.

Here's what this might all look like when you look at your organization in the AWS console:

When Sembit logs in as the companyx-staging@sembit.com account owner, we don't "see" the rest of your organization. We just see a single, isolated account. We don't control and can't change the billing (that's controlled by the management account that created the organization). We have a blank slate for testing IaC scripts, and can set up cloud infrastructure on your behalf.

When you look at your bill, it's automatically broken out by account, so you'll see the exact cost of the resources Sembit spins up in your Staging environment. This is a great way to understand what's costing you money later on, and keep everything "isolated" from a cost perspective.

There's another way you can set up your organization, and that's using IAM accounts. This is a more recent approach; it's more complex to get right, but has more flexibility. For example, you can grant fine-grained permissions to a user like "S3 admin", or "EC2 admin" within your environment. It's also much easier to see all users in a single place and control their access / security. In general, larger and more sophisticated organizations with dedicated staff to control their AWS infrastructure likely already use IAM and will set it up.

Downsides of IAM include the steep learning curve (hello JSON rules!), possibility of getting permissions "wrong" and granting too many, and no resource-based billing separation (turns out to be surprisingly difficult to answer questions like "how much does prod cost per month, vs staging?").

Keeping things simple with an account-based approach is a good starting point for small and medium-sized companies (and even some larger ones we've worked with).