Skip to main content

Cross-Account Patterns Beyond the Landing Zone (2026): RAM, Delegated Admin, Route 53 Profiles, RCPs, and Declarative Policies

Cloud ArchitectureUpdated Palaniappan P5 min read

Quick summary: Your landing zone set up the org, OUs, and baseline SCPs. Then most teams stall, duplicating resources per account and wiring brittle cross-account role chains. Since re:Invent 2024 the toolkit changed: RCPs bound what can be done TO a resource (even by external principals), declarative policies enforce EC2/VPC/EBS config state that survives new APIs, and one Route 53 Profile can push DNS to up to 5,000 VPCs. This post has the mechanism-by-job decision matrix and a rollout order that avoids lockouts.

Key Takeaways

  • This is for platform, networking, and security teams who already run AWS Control Tower or an equivalent landing zone
  • Benchmark pattern (not a cited client): A composite 40-account org, ~3 VPCs per workload account, centralized DNS that had been hand-associated per VPC
  • Modeled arithmetic: ~120 per-VPC DNS associations collapse to one Route 53 Profile (a single Profile supports up to 5,000 VPCs) shared to the workload OU via RAM
  • The win comes from account #41 inheriting networking and DNS on creation instead of generating a setup ticket
  • Building cross-account IAM role chains to reach a shared subnet is the anti-pattern; RAM shares it natively and auditably
Cross-Account Patterns Beyond the Landing Zone (2026): RAM, Delegated Admin, Route 53 Profiles, RCPs, and Declarative Policies
Table of Contents

Your landing zone is done: the org exists, OUs are carved out, the account factory works, and baseline SCPs are attached. That is where most multi-account programs quietly stall. The next failures are operational: teams duplicate the same VPC/DNS/security config into every new account, wire brittle cross-account IAM role chains for things AWS now shares natively, and write SCPs that break the moment AWS ships a new API. Since AWS re:Invent 2024 (November 2024) the toolkit for “day two” multi-account is materially different: Resource Control Policies (RCPs) and declarative policies are new policy types, and Amazon Route 53 Profiles collapses cross-account DNS. This post is the mechanism-by-job map.

This is for platform, networking, and security teams who already run AWS Control Tower or an equivalent landing zone. We ship a cross-account sharing & guardrail decision matrix and an example RCP data-perimeter policy.

The four jobs and the mechanism for each

Almost every “how do we do X across accounts” question is really one of four jobs. Picking the wrong mechanism is what creates sprawl.

Job 1: share a resource one account owns with others (AWS RAM)

Centralized VPC subnets, Transit Gateway, Route 53 Profiles, License Manager configs, Service Catalog portfolios: share them with AWS Resource Access Manager, scoped to an OU, not an account list. Building cross-account IAM role chains to reach a shared subnet is the anti-pattern; RAM shares it natively and auditably.

Job 2: administer a service org-wide without the management account (delegated administrator)

GuardDuty, Security Hub, AWS Config, IAM Access Analyzer, Inspector, and account provisioning all support a delegated administrator. Run them from a dedicated Security account and keep the management account minimal. The management account is for billing and org structure; treat a console login to it as an alarmable event. (This is also why your least-privilege IAM baseline matters most there.)

Job 3: standardize DNS across VPCs and accounts (Route 53 Profiles)

Define private hosted zones, Resolver rules, and DNS Firewall rule groups once in a Profile and apply across the org, shared via RAM. One Profile covers up to 5,000 VPCs; since April 2025 it also covers interface VPC endpoint hosted zones. This replaces the per-VPC association toil that DNS traffic-management setups used to require at scale.

Job 4: guarantee a config or block an action everywhere (SCP, RCP, or declarative policy)

This is the one teams get wrong, because the three look similar:

  • SCP: caps what principals can do (deny org-leave, deny disabling CloudTrail, region deny). Evaluated against the caller.
  • RCP: caps what can be done to a resource, including by external principals (deny S3 access from outside the org = data perimeter). Evaluated against the resource.
  • Declarative policy: enforces a service configuration (VPC Block Public Access, block public AMIs) that persists across new APIs, for EC2/VPC/EBS today.

Opinionated take: stop writing SCPs that deny individual config-changing APIs. The day AWS ships a new API reaching the same end state, your SCP is a false sense of security. For configuration baselines, use a declarative policy (“set once”) and keep SCPs for identity-side guardrails and RCPs for the data perimeter.

Rollout order that avoids lockouts

  1. Enable all features in AWS Organizations (required for SCP/RCP/declarative).
  2. Stand up the Security delegated-admin account; move GuardDuty/Security Hub/Config admin there.
  3. Replace per-account duplication with RAM shares to OUs (subnets, Transit Gateway, Route 53 Profiles).
  4. Add declarative policies for config baselines (VPC Block Public Access, public-AMI block): sandbox OU, then staging OU, then root.
  5. Add RCPs for the data perimeter (start with S3/STS/KMS/SQS/Secrets Manager), tested in a non-prod OU with CloudTrail review before root.
  6. Keep SCPs for identity guardrails (deny org-leave, deny disabling security services, region deny).

What to do this week

  1. Inventory every place you’ve duplicated networking/DNS config per account, then pick the worst offender and move it to a RAM share or a Route 53 Profile.
  2. Confirm GuardDuty, Security Hub, and Config run from a delegated-admin Security account, not the management account.
  3. Run the decision matrix over your top three “cross-account” pain points and label each as a RAM / delegated-admin / Profiles / SCP / RCP / declarative job.
  4. Stage the example RCP in a non-prod OU and watch CloudTrail before promoting.

What this post doesn’t cover

Related: Control Tower governance · Landing zone best practices · VPC networking · IAM least privilege · AWS managed services

If you only do one thing: Take your single most-duplicated cross-account config and replace it with an OU-scoped RAM share or a Route 53 Profile, so the next account you create inherits it instead of filing a ticket.

Frequently asked questions

What is the difference between an SCP and an RCP?
A Service Control Policy (SCP) bounds what principals (IAM roles and users) in your accounts are allowed to do; it is evaluated against the identity making the request. A Resource Control Policy (RCP), introduced at AWS re:Invent 2024, bounds what can be done to a resource, and it is evaluated regardless of who makes the request, including external and anonymous principals. That is why RCPs are the right tool for a data perimeter: an RCP attached to your org root can deny access to your S3 buckets from any principal outside your organization even if a bucket policy would otherwise allow it. SCPs and RCPs are complementary, not substitutes: a real data perimeter usually needs both, plus identity- and resource-based policies. At launch RCPs supported S3, STS, KMS, SQS, and Secrets Manager; coverage has since expanded (GovCloud in May 2025, Cognito and CloudWatch Logs in January 2026), so confirm current supported services in the AWS Organizations User Guide before relying on a given resource type.
When should we NOT use a Resource Control Policy?
Do not enable an RCP without first inventorying the resource policies and legitimate cross-account integrations it could affect. An over-broad Deny can silently break a partner integration or a cross-account data pipeline. Roll RCPs out in a non-production OU first, review CloudTrail Access Denied events for several days, and only then attach to the organization root. Also remember RCPs do not affect the management account, so they are not a way to protect resources you (incorrectly) keep there; the fix for that is to not keep workloads in the management account at all. Finally, an RCP is not a per-request authorization engine for arbitrary actions; if you need to allow or deny specific API calls based on the caller, that is an SCP or an identity policy job.
What are declarative policies and how are they different from SCPs?
Declarative policies are an AWS Organizations capability introduced at re:Invent 2024 that lets you centrally declare a desired baseline configuration for a service (currently Amazon EC2, VPC, and EBS) and have AWS enforce that configuration state directly at the service control plane. The key difference from an SCP is durability: an SCP that denies a specific API (for example, the call that disables VPC Block Public Access) breaks the day AWS ships a new API that reaches the same end state, whereas a declarative policy declares the end state itself (public access blocked) and keeps enforcing it as new APIs, features, accounts, and resources appear. Declarative policies also give you account status reports and a customizable error message you can point users to. Use declarative policies for configuration baselines; keep SCPs and RCPs for authorization guardrails.
How does Amazon Route 53 Profiles change multi-account DNS?
Before Route 53 Profiles, sharing private hosted zones, Resolver rules, and DNS Firewall rule groups across many accounts meant custom orchestration and per-VPC associations. A Route 53 Profile lets you define a standard DNS configuration once and apply it consistently across VPCs and accounts in a Region, with a single Profile associable to up to 5,000 VPCs and shareable across accounts via AWS Resource Access Manager (with read-only or admin permissions) and AWS Organizations. Each VPC can have one associated Profile, and where a local VPC setting and a Profile setting conflict at equal specificity, the local setting wins while the most specific matching rule wins overall. Since April 2025 Profiles also support interface VPC endpoint managed private hosted zones, removing more manual association work for centralized networking teams.
Should we share resources to specific account IDs or to an OU?
Share to an Organizational Unit, not a list of account IDs, whenever the resource is meant for a class of accounts. With AWS RAM you can scope a share (subnets, Transit Gateway, Route 53 Profiles, License Manager configurations, Service Catalog portfolios) to an OU so that any new account created in that OU inherits the share automatically. Account-ID lists rot: someone provisions a new account, forgets to add it to ten different shares, and you get a slow trickle of "why can this team not reach the shared VPC" tickets. The exception is a one-off, single-account share, where an account ID is fine. The general rule is to make sharing follow your OU structure so it scales with account creation rather than fighting it.
Do these patterns replace the landing zone or Control Tower?
No. The landing zone (whether you built it with AWS Control Tower, Landing Zone Accelerator, or a custom Terraform foundation) establishes the organization, OU structure, account factory, centralized logging, and baseline SCPs. The patterns in this post are what you reach for after that foundation exists, to operate it day two: sharing resources without duplication (RAM), running security tooling without the management account (delegated administrators), standardizing DNS (Route 53 Profiles), and enforcing data perimeters and configuration baselines (RCPs and declarative policies). If you do not yet have a landing zone, start there (see our Control Tower and landing-zone guides) and treat this post as the next layer.
Share:
Palaniappan P
Palaniappan P

AWS Cloud Architect & AI Expert

AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.

AWS ArchitectureCloud MigrationGenAI on AWSCost OptimizationDevOps

Related AWS Services

Work with our certified AWS architects to implement the strategies covered in this article.

AWS Architecture Review

Well-Architected Framework review covering reliability, performance, security, and operational excellence.

Learn more

AWS Serverless

Design and build event-driven serverless systems using Lambda, API Gateway, Step Functions, and DynamoDB.

Learn more

AWS Migration

Migrate workloads from on-premises, GCP, Azure, or legacy hosting to AWS with minimal downtime.

Learn more

Recommended Reading

Explore All Articles »
Enterprise AWS Governance (2026): OU Taxonomy, Policy Layering, and Exception RFCs That Scale
Cloud Architecture
4 min

Enterprise AWS Governance (2026): OU Taxonomy, Policy Layering, and Exception RFCs That Scale

Control Tower gets you an org, but it does not tell you how many OUs you need or which policy type owns VPC public access. Since re:Invent 2024 you have four layers (SCP, RCP, declarative, and tag policies), and RCP coverage grew through Feb 2026 (DynamoDB). A composite 60-account enterprise cut exception SCP attachments from 14 ad-hoc to 3 time-boxed RFCs in two quarters by moving accounts out of "temporary" prod OUs.

Palaniappan P