--- title: Cross-Account Patterns Beyond the Landing Zone (2026): RAM, Delegated Admin, Route 53 Profiles, RCPs, and Declarative Policies description: 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. Here is the mechanism-by-job decision matrix and a rollout order that avoids lockouts. url: https://www.factualminds.com/blog/aws-cross-account-patterns-beyond-landing-zone-2026/ datePublished: 2026-06-10T00:00:00.000Z dateModified: 2026-06-10T00:00:00.000Z author: Palaniappan P category: Cloud Architecture tags: aws, aws-organizations, multi-account, governance, networking --- # Cross-Account Patterns Beyond the Landing Zone (2026): RAM, Delegated Admin, Route 53 Profiles, RCPs, and Declarative Policies > 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. Here is the mechanism-by-job decision matrix and a rollout order that avoids lockouts. **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 aren't foundational; they're 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, not another landing-zone walkthrough. This is for platform, networking, and security teams who already run [AWS Control Tower](/blog/how-to-set-up-aws-control-tower-multi-account-governance/) or an equivalent [landing zone](/blog/aws-multi-account-strategy-landing-zone-best-practices/). We ship a [cross-account sharing & guardrail decision matrix](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/cross-account-patterns/sharing-decision-matrix.md) and an [example RCP data-perimeter policy](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/cross-account-patterns/rcp-data-perimeter-example.json). > **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 same shape replaces dozens of bespoke cross-account peering/role relationships with a handful of **OU-scoped RAM shares** for subnets and Transit Gateway. The win isn't a dollar figure — it's that account #41 inherits networking and DNS on creation instead of generating a setup ticket. ## The four jobs — and the one 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](/blog/aws-vpc-networking-best-practices-for-production/), 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](/blog/aws-iam-best-practices-least-privilege-access-control/) 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 → 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](/blog/aws-route-53-dns-traffic-management-patterns/) 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 and aren't: - **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. > **What broke** — A team rolled an RCP enforcing an S3 org-identity perimeter straight to the organization root to "lock down data fast." Within an hour a legitimate partner-facing data exchange — an external account that had been granted bucket access on purpose — started returning Access Denied, because the RCP denies external principals regardless of the bucket policy. Detected via a spike in CloudTrail `AccessDenied` on the export bucket. The fix was to add a scoped exception (`aws:PrincipalOrgID` plus an explicit allow path for the known partner principal) and to do what should have come first: stage the RCP in a non-prod OU, review denials for a week, then promote. RCPs are powerful precisely because they ignore the bucket policy — which is exactly why you stage them. ## 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 → staging OU → 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 — 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](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/cross-account-patterns/sharing-decision-matrix.md) 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](https://bitbucket.org/baymail/factualminds-astro/src/main/examples/architecture-blog-2026/cross-account-patterns/rcp-data-perimeter-example.json) in a **non-prod OU** and watch CloudTrail before promoting. ## What this post doesn't cover - **Building the landing zone itself** — see [Control Tower multi-account governance](/blog/how-to-set-up-aws-control-tower-multi-account-governance/) and [multi-account landing zone best practices](/blog/aws-multi-account-strategy-landing-zone-best-practices/). - **Secure cross-account data sharing** (Lake Formation / data mesh grants) — a different mechanism than RAM resource shares; out of scope here. - **Exact RCP-supported services and declarative-policy attributes** — these expand over time; confirm in the AWS Organizations User Guide. - **Cost allocation across accounts** — see [tagging, chargeback & FinOps ownership](/blog/aws-tagging-chargeback-finops-ownership-2026/). --- **Related:** [Control Tower governance](/blog/how-to-set-up-aws-control-tower-multi-account-governance/) · [Landing zone best practices](/blog/aws-multi-account-strategy-landing-zone-best-practices/) · [VPC networking](/blog/aws-vpc-networking-best-practices-for-production/) · [IAM least privilege](/blog/aws-iam-best-practices-least-privilege-access-control/) · [AWS managed services](/services/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. ## FAQ ### 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 genuinely one-off, single-account share — there, 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. --- *Source: https://www.factualminds.com/blog/aws-cross-account-patterns-beyond-landing-zone-2026/*