AWS is a popular cloud computing service that can be used for a variety of organizations. It offers a wide range of features, including:

  1. AWS Lambda: This service allows you to run code without having to worry about the underlying infrastructure. You can use this service to create and manage applications, or to automate tasks.
  2. AWS S3: This service allows you to store data in the cloud and access it from anywhere. It also offers features such as deduplication and security.
  3. AWS EBS: This service allows you to create and manage EC2 instances with storage space and CPU power. It also offers features such as automatic scaling and backups.
  4. AWS CloudFormation: This service helps you create custom templates for your applications that can be used by other organizations in the same way that they use templates from other services like WordPress or Drupal.

Two main ways exist to manage employee access to your company AWS account—IAM users and AWS Organizations. Both have their uses, but it’s important to highlight the differences while planning your AWS permission structure.

Short Answer: Both, Actually

Which one should you use? The answer is both, because IAM Users and AWS Organizations do different things. While they’re similar on the surface, they are designed for different goals.

IAM users are a great way to manage access for employees. They enable you to authenticate employees on a “sub-account” with limited permissions. This permissions management system is crucial for segmenting employee access to your AWS resources.

IAM users are also used to authenticate service accounts. For example, if you’ve got the AWS CLI running on an EC2 instance and want to give it access to manage an S3 bucket, you can do that with an IAM user so you don’t have to leave your root account credentials on a remote server.

AWS Organizations does something similar. It enables you to create actual real sub-accounts that are entirely separate from the main account, complete with their own permissions, all while maintaining central billing and control. You may think this would be a great way to give out employee access, but Organizations aren’t meant for that.

The main problem is that you’re limited to four accounts by default. While you can request a limit increase, the limit is here for a reason—all of your Organization accounts are entirely separate. This means that if you had a developer working on a DynamoDB table in their own account, it would be invisible to every other employee.

What you really want is all of your employees working together in a shared environment. The best setup for nearly any business would be as follows:

Use AWS Organizations, and create separate accounts for development and production. This takes some stress off your developers, and enables you to give them more lax permissions in the development environment without fear that they can screw up your production servers. You may also want to create two more environments: testing, which contains clean dummy data and is used by the QE team for running automated builds; and staging, a complete mirror of production used to catch any bugs that may arise using public APIs and real data before they actually affect customers. Within the development environment, create multiple IAM users to give managed access to your employees. Repeat the same process for your QE team in testing, and for your project managers and solutions architects in staging. Production should only be updated by very authorized individuals, and of course, contain the IAM service accounts it needs to function properly.

This structure combines the benefits of both kinds of accounts, and seems to be how AWS wants you to set it up, given the four account rule (by default) of AWS Organization.