Introducing the Three AWS Governance Pillars with Terraform

Source: Dev.to

The Three Governance Pillars

To get hands‑on with your new infrastructure skills, let me introduce three AWS resources that will form the foundation of your business: Organizations, Accounts, and Policies.

AWS Organizations and Organizational Units

An Organization acts as a control tower for your entire cloud infrastructure, providing centralized management for multiple AWS accounts. The hierarchy is:

• Organization Root – the single parent container for everything.
• Organizational Units (OUs) – logical groupings (e.g., Production, Development, Security) that help you segment accounts by function, environment, or business unit.

Organizations work hand‑in‑hand with Accounts (which live inside OUs) and Policies (which can be attached at any level of the hierarchy).

AWS Organization Accounts

Individual AWS accounts are the fundamental security and resource boundaries. Each account has its own billing, access controls, and resource limits. Using multiple accounts provides:

• Natural blast‑radius containment
• Simplified compliance boundaries
• Clearer cost allocation

Accounts inherit any policies applied to their parent OU or the organization root, creating a governance cascade from top to bottom.

Service Control Policies (SCPs)

Service Control Policies are guardrails that define the maximum permissions any entity in an account can have, regardless of IAM permissions. Typical uses include:

• Preventing accounts from leaving the organization
• Restricting allowed AWS regions
• Blocking deletion of critical resources such as CloudTrail logs

SCPs can be attached to the Organization Root, OUs, or individual accounts and flow downward through the hierarchy.

Terraform Modules

In this section we’ll create reusable Terraform modules for the governance resources. These modules will live in a GitHub repository called terraform-aws-governance and serve as building blocks for your AWS foundation.

Choosing the Right Granularity

When structuring Infrastructure as Code (IaC), three common approaches exist:

• Monolithic – a single large Terraform configuration. Quick to start but becomes cumbersome and risky as you grow.
• One‑repo‑per‑module – each module in its own repository. Offers maximum isolation but makes consistency and versioning harder.
• Grouped modules – related modules in a single repository (our choice). Balances reusability with maintainability and works well with Terragrunt for orchestration.

We’re adopting the grouped approach because governance resources are inherently related and often change together.

Core Modules

We’ll start with three foundational modules:

• organization – creates the AWS Organization with baseline security policies
• organizational-unit – creates OUs with customizable policies
• account – provisions new AWS accounts within specified OUs

Each module is stateless and idempotent, meaning it can be applied repeatedly without side effects.

Repository Structure

terraform-aws-governance/
├── organization/
│   ├── main.tf
│   ├── variables.tf
│   └── outputs.tf
├── organizational-unit/
│   ├── main.tf
│   ├── variables.tf
│   └── outputs.tf
└── account/
    ├── main.tf
    ├── variables.tf
    └── outputs.tf

These modules can be orchestrated with Terragrunt to build a complete, well‑governed AWS infrastructure stack.