Curriculum Overview: Secure Cross-Account Resource Sharing & Governance

This curriculum covers the strategies and tools required to securely share AWS resources across multiple accounts within an organization. It focuses on reducing operational overhead and maintaining a strong security posture through centralized governance using AWS Resource Access Manager (RAM) and AWS Service Catalog.

---

Prerequisites

Before starting this curriculum, students should have a baseline understanding of the following:

• AWS Organizations: Familiarity with Management accounts, Member accounts, and Organizational Units (OUs).
• Identity and Access Management (IAM): Core knowledge of IAM users, roles, and the difference between identity-based and resource-based policies.
• Infrastructure as Code (IaC): Basic understanding of AWS CloudFormation templates and stack deployment.
• AWS Security Specialty Fundamentals: Awareness of the Shared Responsibility Model in a multi-account context.

---

Module Breakdown

---

Learning Objectives per Module

Module 1: Multi-Account Foundations

• Design a hierarchical OU structure to support policy inheritance.
• Explain how AWS Organizations enables resource sharing features across the entire landscape.

Module 2: AWS Resource Access Manager (RAM)

• Identify which AWS resources are "RAM-shareable" (e.g., Transit Gateways, Subnets).
• Configure a resource share to specific OUs to prevent accidental exposure to the public or unauthorized accounts.

Module 3: AWS Service Catalog

• Construct a Portfolio of approved IT services.
• Implement Constraints (launch, notification, or template constraints) to restrict how end-users provision resources.

Module 4: Cross-Account Identity Patterns

• Create secure Trust Relationships between accounts to allow cross-account role assumption.
• Apply Permissions Boundaries to ensure delegated administrators cannot escalate their own privileges during resource sharing.

---

Architecture Visualization

This diagram illustrates the primary pathways for sharing resources versus sharing provisioning templates.

The Trust Relationship Mechanism

Below is a technical representation of the Cross-Account IAM Role flow used when a central account needs to manage resources in a member account.

\begin{tikzpicture}[node distance=2cm, auto] \draw[thick] (0,0) rectangle (3,2) node[midway] {Account A (Trusted)}; \draw[thick] (6,0) rectangle (9,2) node[midway] {Account B (Trusting)}; \draw[->, thick] (3,1) -- (6,1) node[midway, above] {1. AssumeRole}; \draw[<-, thick] (3,0.5) -- (6,0.5) node[midway, below] {2. Temp Credentials}; \node at (7.5, 2.5) {IAM Role with Trust Policy}; \node at (1.5, -0.5) {User/Service}; \end{tikzpicture}

---

Success Metrics

To demonstrate mastery of this curriculum, the learner must be able to:

• Configure RAM: Successfully share a Private Certificate Authority (CA) from a Security account to a Development account and issue a certificate.
• Service Catalog Deployment: Create a Service Catalog product for a "Standardized S3 Bucket" and successfully launch it from a member account without the user having direct S3:CreateBucket permissions.
• Policy Validation: Write an IAM Trust Policy that restricts role assumption only to a specific AWS Organization ID using the aws:PrincipalOrgID condition.
• Security Audit: Use IAM Access Analyzer to identify resources shared outside of the organization zone of trust.

---

Real-World Application

[!IMPORTANT] Secure resource sharing is the backbone of the Landing Zone architecture. Without these tools, organizations suffer from "Resource Sprawl" and inconsistent security configurations.

Scenario 1: The Shared Network Services VPC

In a large enterprise, the Network Team manages a central VPC with inspection tools. Instead of creating VPCs in every account, they use AWS RAM to share specific subnets with Application teams. This allows applications to reside in their own accounts for billing and administrative isolation while utilizing a centrally governed network.

Scenario 2: The Enterprise "Service Store"

Instead of giving developers full CloudFormation or Terraform access (which could lead to non-compliant resource creation), the Cloud Operations team uses AWS Service Catalog. Developers can browse a "menu" of approved, pre-hardened architectures (like a HIPAA-compliant web stack) and click "Provision." The product is deployed using a Launch Role, meaning the developer doesn't need the underlying permissions themselves.

[!TIP] Always use AWS Organizations-level sharing in RAM. This automates the invitation process, meaning member accounts do not need to manually accept the resource share.