14.4 Centralized Resource Sharing with RAM & Service Catalog

14.4 Centralized Resource Sharing with RAM & Service Catalog

As enterprise cloud footprints expand across hundreds of AWS accounts, duplicating foundational infrastructure across every account introduces crippling cost inefficiencies, operational overhead, and security configuration drift. Provisioning a dedicated AWS Transit Gateway, separate Route 53 Resolver outbound endpoints, or redundant VPC topologies in every account fractures centralized governance.

To solve this, AWS provides two foundational governance services:

• AWS Resource Access Manager (RAM): Enables secure, seamless cross-account resource sharing across accounts or Organizational Units without duplicating underlying infrastructure.
• AWS Service Catalog: Enables centralized governance, curation, and self-service provisioning of approved cloud architectures and infrastructure-as-code templates.

---

AWS Resource Access Manager (RAM) Architecture & Capabilities

AWS RAM allows an AWS account that owns a resource to share it with other AWS accounts, Organizational Units (OUs), or an entire AWS Organization. Prior to RAM, cross-account resource access required establishing complex IAM cross-account roles, resource-based policies, or duplicated resources.

Loading diagram...

Organizational Sharing vs. Standalone Sharing

• Sharing Within AWS Organizations: When Enable resource sharing with AWS Organizations is activated in the RAM console settings of the Management account, resources can be shared directly with an account ID, an OU ARN, or the organization root. Accounts in the organization gain immediate access to shared resources without receiving or having to accept an invitation.
• Sharing with External Accounts: When sharing with an AWS account outside the organization, RAM transmits an explicit invitation. The target account administrator must explicitly call AcceptResourceShareInvitation before resources become visible.

Sharable Resource Types for Security Engineers

AWS RAM supports a wide spectrum of resources relevant to security architecture:

• VPC Subnets: Enables centralized VPC networking where a network account owns the VPC and subnets, and workload accounts provision compute resources directly into those shared subnets.
• AWS Transit Gateway: Allows a centrally managed Transit Gateway to connect VPCs across hundreds of accounts.
• Route 53 Resolver Rules: Distributes centralized DNS forwarding rules to all member VPCs, ensuring consistent on-premises DNS resolution and preventing DNS bypass.
• VPC Prefix Lists: Distributes customer-managed CIDR block collections for use in security group rules.
• AWS License Manager Configurations: Enforces software licensing compliance across all compute instances in an organization.
• Security Groups: A VPC owner can share security groups with participants of a shared VPC so they can attach centrally managed groups.

Not everything is shared through RAM. AWS KMS keys, for example, are shared by adding the other account to the key policy, not through RAM.

---

Centralized Networking with Shared VPC Subnets

The Shared VPC model (VPC sharing) is the gold standard for enterprise network security in AWS. In this model, network management is completely decoupled from workload compute.

Ownership vs. Participation

• VPC Owner (Network Account): Owns the VPC container, subnets, route tables, Network Access Control Lists (NACLs), internet gateways, NAT gateways, VPC endpoints, and Transit Gateway attachments.
• Participants (Workload Accounts): Own the application resources they create inside the shared subnets (EC2 instances, Application Load Balancers, RDS databases, Lambda ENIs).

Shared Subnet Security Boundary Matrix

Understanding the strict division of responsibilities in shared VPC subnets is heavily tested on the Specialty exam:

Critical Exam Rule on Security Groups in Shared Subnets: Each security group belongs to the account that created it, and only that account can modify it. A participant in Workload Account 1 can reference a security group owned by Workload Account 2 or by the VPC owner in its own rules by using the account-id/sg-id format, so micro-segmentation by security group works across accounts in a shared VPC. Participants can't attach or edit another account's security groups unless the owner shares them through RAM.

---

Centralized Route 53 Resolver & Prefix List Sharing

Centralized DNS Security via Route 53 Resolver Rules

In hybrid architectures, workloads in AWS must resolve on-premises corporate domain names (such as corp.internal), while on-premises servers resolve AWS resources. Rather than creating Route 53 Resolver Outbound Endpoints in every workload VPC, the network account creates central outbound endpoints and defines Route 53 Resolver Forwarding Rules.

By sharing these resolver rules across the organization via AWS RAM:

• Workload VPCs automatically associate with the shared rules.
• DNS queries for internal corporate domains are forwarded to on-premises DNS servers automatically.
• Developers cannot tamper with or bypass corporate DNS routing, preventing DNS exfiltration.

Centralized IP Governance via Customer-Managed Prefix Lists

A Customer-Managed Prefix List is a set of one or more CIDR blocks managed as a single named object. When an organization has approved corporate IP ranges, partner networks, or monitoring CIDRs that must be allowed across hundreds of security groups:

1. The network security team creates the Prefix List in the central Network Account.
2. The Prefix List is shared across the organization via AWS RAM.
3. Member account administrators reference the Prefix List ID (e.g., pl-12345678) directly in their local security group ingress and egress rules.
4. When corporate IP ranges change, updating the prefix list in the central account automatically updates every referencing security group across the entire multi-account estate.

---

AWS Service Catalog Architecture: Portfolios, Products & Constraints

While AWS RAM shares operational infrastructure, AWS Service Catalog governs the provisioning of application architectures. Service Catalog allows organizations to create and manage catalogs of IT services that are approved for use on AWS.

Loading diagram...

Key Structural Entities

• Product: An IT service that can be deployed on AWS. A product is defined by an AWS CloudFormation template or Terraform configuration representing a hardened architecture (e.g., a compliant S3 data lake bucket, a multi-AZ VPC, or an autoscaling microservice stack).
• Portfolio: A collection of products, along with configuration metadata and access governance rules.
• Constraints: Rules that govern the deployment of products within a portfolio.

Service Catalog Constraint Types

Service Catalog supports five constraint types:

1. Launch Constraints (The Fundamental Security Constraint): Specifies an IAM role that Service Catalog assumes when provisioning products in the portfolio. This is the cornerstone of least-privilege self-service in AWS.
2. Template Constraints: Limits the parameter values that end users can select during product launch (e.g., restricting EC2 instance types to t3.medium and m5.large, or forcing a database retention period to 30).
3. Notification Constraints: Specifies an Amazon SNS topic that receives notifications about product launch, update, and termination events.
4. Tag Update Constraints: Enforces whether end users can modify, add, or delete tags on provisioned resources.
5. StackSet Constraints: Let end users deploy a product across accounts and Regions with CloudFormation StackSets, limited to the accounts, Regions, and permissions you specify.

---

Launch Constraints: Least Privilege Without Direct IAM Grants

The primary security value of AWS Service Catalog on the Specialty exam is its ability to enforce the Principle of Least Privilege through Launch Constraints.

The Security Dilemma

In traditional self-service models, if developers need to provision S3 buckets, RDS databases, and KMS keys, administrators must grant those developers direct IAM permissions (s3:CreateBucket, rds:CreateDBInstance, kms:CreateKey). However, granting direct permissions allows developers to bypass approved architectural standards—creating unencrypted buckets, public databases, or non-compliant infrastructure via the AWS CLI or console.

The Launch Constraint Resolution

With a Service Catalog Launch Constraint:

1. The security administrator creates a dedicated IAM Launch Role containing the permissions required to provision the underlying resources.
2. The Launch Role is associated with the Service Catalog product as a Launch Constraint.
3. The end user (developer) is granted permission to access only the Service Catalog portfolio (servicecatalog:LaunchProduct). The end user is explicitly denied direct permissions to create S3 buckets, RDS databases, or KMS keys.
4. When the user launches the product, Service Catalog assumes the Launch Role to deploy the CloudFormation stack. The resources are successfully provisioned under the authority of the Launch Role.
5. If the user attempts to create an S3 bucket directly using the AWS CLI or console, the request fails immediately with AccessDenied.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ServiceCatalogLaunchRolePolicy",
      "Effect": "Allow",
      "Action": [
        "s3:CreateBucket",
        "s3:PutBucketEncryption",
        "s3:PutBucketVersioning",
        "s3:PutBucketPublicAccessBlock",
        "kms:CreateKey",
        "kms:PutKeyPolicy",
        "cloudformation:CreateStack",
        "cloudformation:DescribeStacks"
      ],
      "Resource": "*"
    }
  ]
}

---

Cross-Account Portfolio Distribution

Large enterprises manage Service Catalog centrally using a multi-account distribution model:

1. Central Catalog Account: Architecture and security teams author, version, and security-scan CloudFormation products within a master portfolio.
2. Portfolio Sharing: The master portfolio is shared with member accounts or targeted OUs using AWS Organizations integration.
3. Importing & Local Association: In each member account, the local administrator imports the shared portfolio and grants access to local IAM users, IAM roles, or IAM Identity Center permission sets.
4. Centralized Version Updates: When the security team publishes an updated product version (e.g., adding updated CIS compliance settings to a template), the update propagates across all member accounts automatically.

---

Specialty Exam Traps & Architectural Pitfalls

1. Cross-Account Security Group Referencing in Shared Subnets: Don't assume cross-account references are impossible. In a shared VPC, a participant can reference another participant's or the owner's security group as account-id/sg-id. What participants can't do is modify security groups they don't own.
2. NACL Management in Shared Subnets: Participant accounts cannot create or alter Network Access Control Lists (NACLs) attached to shared subnets. Subnet-level network boundaries remain strictly under the control of the VPC Owner account.
3. Launch Constraint Absence: If a product has no Launch Constraint assigned, Service Catalog attempts to provision resources using the end user's own IAM credentials. If the end user lacks direct permissions to provision those services, the launch operation fails.
4. Accepting Invitations for Organization Shares: When sharing resources via AWS RAM to an OU or organization with Organizations sharing enabled, no invitation is sent, and no manual acceptance is required. If a question describes a scenario where an administrator is waiting for an invitation email within an organization, that indicates a misconfiguration.