SRA building blocks – AWS Organizations, accounts, and guardrails

AWS security services, their controls, and interactions are best employed on a foundation of AWS multi-account strategy and identity and access management guardrails. These guardrails set the ability for your implementation of least privilege, separation of duties, and privacy, and provide the support for decisions about what types of controls are needed, where each security service is managed, and how they may share data and permissions in the AWS SRA. 

An AWS account provides security, access, and billing boundaries for your AWS resources and enables you to achieve resource independence and isolation. Use of multiple AWS accounts plays an important role in how you meet your security requirements, as discussed in the Benefits of using multiple AWS accounts section of the Organizing Your AWS Environment Using Multiple Accounts whitepaper. For example, you can organize your workloads in separate accounts and group accounts within an organizational unit (OU) based on function, compliance requirements, or a common set of controls instead of mirroring your enterprise's reporting structure. Keep security and infrastructure in mind to enable your enterprise to set common guardrails as your workloads grow. This approach provides robust boundaries and controls between workloads. Account-level separation, in combination with AWS Organizations, is used to isolate production environments from development and test environments, or to provide a strong logical boundary between workloads that process data of different classifications such as Payment Card Industry Data Security Standard (PCI DSS) or Health Insurance Portability and Accountability Act (HIPAA). Although you might begin your AWS journey with a single account, AWS recommends that you set up multiple accounts as your workloads grow in size and complexity. 

Permissions let you specify access to AWS resources. Permissions are granted to IAM entities known as principals (users, groups, and roles). By default, principals start with no permissions. IAM entities can do nothing in AWS until you grant them permissions, and you can set up guardrails that apply as broadly as your entire AWS organization or as fine-grained as an individual combination of principal, action, resource, and conditions.