Minimal AWS Accounts for permission restrictions

Isolating AWS resources into single purpose AWS Accounts

Table Of Contents

Today I Explained

When viewing an AWS Organization you may have come across organization units or AWS Accounts that are named after technologies or responsibilities. Some of these might be similar to what is seen:

• DNS
• Logs
• Certificates
• Vault
• Entrypoint

This is a pattern in which an AWS Account is acting as an isolation control for important infrastructure resources. The most likely to be familiar is either the DNS or Vault. The DNS AWS Account is responsible for isolating the Route53 root domains in-use by an organization, and using subdomain delegation to allow those domains to be in-use within other AWS Accounts.

While the Vault AWS Account contains secrets that are accessible from other AWS Accounts, allowing for a single point for rotation, or single point for mirroring into other accounts.

This pattern is adopted within AWS Organizations because the AWS Account is a definitive boundary for permissions. Part of this is because identity & resource policies in IAM aren’t always the most straightforward to guarantee that a resource cannot be viewed or modified by another while within an AWS Account. Cross-account does not have this concern, and requires explicit permissions to allow cross-account access.

The other aspect is that it just makes a sensible container for these kind of resources:

    ┌─────────┬───────OU Root────────┬────────────┐
    │         │          │           │            │
    ▼         ▼          ▼           ▼            ▼
   DNS      Vault    Workloads   Infrastructure   ...

    ▼         ▼          ▲           ▲
    ▼         ▼          ▲           ▲
    ► ► ► ► ► ► ► ► ► ► ► ► ► ► ► ► ►
       --  Permission Share --

A diagram showing a tree structure in which the nodes ‘DNS’ and ‘Vault’ have a relationship with the ‘workloads’ and ‘infrastructure’ nodes by explicit permission share