Lab: Architecting a Secure Multi-Account Environment with AWS Organizations

This lab guides you through the process of designing and implementing a multi-account strategy. You will move from a single-account setup to a structured organization using AWS Organizations, Organizational Units (OUs), and Service Control Policies (SCPs) to enforce governance.

[!WARNING] Remember to run the teardown commands at the end of this lab to avoid ongoing charges or leaving experimental configurations in your root account.

Prerequisites

• AWS Account Access: You must have access to an AWS account with AdministratorAccess permissions.
• AWS CLI: Installed and configured on your local machine with credentials for the management (root) account.
• IAM Permissions: Permission to manage AWS Organizations (organizations:*).
• Active Email Addresses: To create a new child account, you will need a unique email address not already associated with an AWS account (Tip: use yourname+lab@gmail.com).

Learning Objectives

• Initialize an AWS Organization and understand the Management Account role.
• Design a hierarchical structure using Organizational Units (OUs).
• Create a child account programmatically or via console.
• Implement and test Service Control Policies (SCPs) to prevent resource deletion.

Architecture Overview

We will build a simple but robust structure consisting of a Security OU (for logs/auditing) and a Workload OU (for applications).

Step-by-Step Instructions

Step 1: Create the Organization

First, we must enable the AWS Organizations service. This establishes your current account as the Management Account.

▶Console alternative

1. Sign in to the AWS Management Console.
2. Search for and open AWS Organizations.
3. Click Create an organization.
4. Confirm the feature set is set to All features (required for SCPs).

Step 2: Create Organizational Units (OUs)

We will create a "Security" OU to house our shared security services.

[!TIP] You can find your Root ID by running: aws organizations list-roots.

Step 3: Enable Service Control Policies (SCPs)

SCPs are disabled by default. You must enable the policy type for the Root.

Step 4: Create and Attach a "Deny CloudTrail Stop" SCP

This policy ensures that even an administrator in a child account cannot stop logging.

1. Save the following JSON as policy.json:

1. Create the policy in AWS:

1. Attach the policy to the Security OU (not the root, to avoid locking yourself out):

Checkpoints

Clean-Up / Teardown

[!IMPORTANT] Accounts created via Organizations cannot be easily deleted via CLI; they must be closed via the billing console individually.

1. Detach Policies:
   bashCopy

   aws organizations detach-policy --policy-id <POLICY_ID> --target-id <SECURITY_OU_ID>
2. Delete Policies:
   bashCopy

   aws organizations delete-policy --policy-id <POLICY_ID>
3. Delete OUs:
   bashCopy

   aws organizations delete-organizational-unit --organizational-unit-id <SECURITY_OU_ID>
4. Remove Accounts: Move accounts out of OUs to the Root, then close them in the Console under Billing > Close Account.

Troubleshooting

Stretch Challenge

The "Full Lockdown": Create an SCP that restricts resource deployment to only one specific AWS region (e.g., us-east-1). Apply it to a new OU named "Development" and attempt to launch an EC2 instance in us-west-2 from a child account in that OU.

Cost Estimate

• AWS Organizations: Free of charge.
• SCPs: Free of charge.
• Child Accounts: No base cost, but resources launched inside them (EC2, RDS) will incur standard usage fees.
• Total: $0.00 for the management layer.

Concept Review

The following diagram illustrates how SCPs act as a filter for IAM permissions. Even if an IAM user has AdministratorAccess (Full access), the SCP defines the maximum allowable perimeter.

\begin{tikzpicture}[node distance=1.5cm, every node/.style={fill=white, font=\small}] % Layers \draw[fill=blue!10, dashed] (-3,0) rectangle (3,5); \node at (0, 4.5) {\textbf{AWS Account Boundary}};

\end{tikzpicture}

Comparison Table: Account Strategies