# Cross-account sharing & guardrail decision matrix

Pick the **mechanism** by what you are actually trying to do across accounts.
The landing zone (Control Tower / AFT) sets up the org, OUs, and baseline SCPs.
Everything below is what you reach for *after* the landing zone exists — and the
most common mistake is copying/duplicating resources per account when a share or
an org-level guardrail would have been simpler and safer.

> Capabilities reflect the mid-2026 model. RCPs and declarative policies were
> introduced at re:Invent 2024 (Nov 2024); confirm current service/region
> support in the AWS Organizations and AWS RAM docs before committing.

## 1. "I need account B to use a resource account A owns"

| You want to share… | Use | Notes |
|--------------------|-----|-------|
| Subnets / VPC (centralized networking) | **AWS RAM** (VPC subnets) | Participants launch resources into shared subnets; owner keeps route/IGW control |
| Transit Gateway | **AWS RAM** | Share once to the OU; avoids per-account TGW + peering sprawl |
| DNS config (PHZs, Resolver rules, DNS Firewall) | **Route 53 Profiles** (+ RAM) | One Profile → up to 5,000 VPCs; shared read-only or admin via RAM |
| License configs, Resource Groups, Service Catalog portfolios | **AWS RAM** | Share to OU, not account-by-account |
| Data lake tables / columns | **Lake Formation** grants | See the secure data-sharing post; not a RAM share |

**Rule:** share to an **Organizational Unit**, not a list of account IDs. New
accounts inherit the share automatically; account-ID lists rot.

## 2. "I need a team to administer a service org-wide without the management account"

| Service | Mechanism | Why |
|---------|-----------|-----|
| GuardDuty, Security Hub, Config, IAM Access Analyzer, Inspector | **Delegated administrator** | Run security tooling from a dedicated Security account; keep the management account minimal |
| Account provisioning (Account Factory) | Delegated admin (Control Tower) | Platform team provisions without management-account access |
| FIS, CloudTrail org trail, Resource Explorer | Delegated admin where supported | Same principle: least use of the management account |

**Rule:** the management account is for billing and org structure. Delegate
everything else. Treat management-account console logins as an alarmable event.

## 3. "I need to *guarantee* a configuration or block an action everywhere"

| Goal | Use | Evaluates against | Example |
|------|-----|-------------------|---------|
| Cap what **principals** (roles/users) can do | **SCP** | The caller's identity | Deny leaving the org; deny disabling CloudTrail |
| Cap what can be done **to a resource**, incl. external principals | **RCP** | The resource | Deny S3 access from outside the org (data perimeter) |
| Enforce a **service configuration** that persists across new APIs | **Declarative policy** | The service (EC2/VPC/EBS) | VPC Block Public Access; block public AMIs; require IMDSv2-class settings |

**SCP vs RCP in one line:** SCPs bound the *requester*; RCPs bound the
*resource* (and apply even to external/anonymous principals). They are
complementary — a data perimeter usually needs both.

**Declarative policies vs SCPs:** an SCP that denies `ec2:ModifyVpcAttribute`
breaks the moment AWS ships a new API that achieves the same thing. A
declarative policy declares the *desired end state* (e.g. VPC public access
blocked) and keeps enforcing it as new APIs, features, and accounts appear —
"set once," with account status reports and a customizable error message.

## When NOT to reach for these

- **Don't** build cross-account IAM role chains for something RAM shares natively
  (subnets, TGW, Route 53 Profiles). Role-assumption sprawl is harder to audit
  than a resource share scoped to an OU.
- **Don't** put org-wide guardrails in the management account expecting them to
  cover it — RCPs and SCPs **do not affect the management account**. Keep
  nothing in there worth attacking.
- **Don't** use a declarative policy where you need per-request authorization
  logic — that's an SCP/RCP job. Declarative policies are for *configuration
  state*, not API allow/deny on arbitrary actions.
- **Don't** enable RCPs without inventorying resource policies first — an
  over-broad `Deny` can lock out a legitimate cross-account integration. Roll out
  in a non-prod OU with CloudTrail review before org root.

## Rollout order that avoids lockouts

1. Enable **all features** in 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** (networking, DNS).
4. Add **declarative policies** for config baselines (VPC BPA, public AMI block)
   in a sandbox OU → staging OU → root.
5. Add **RCPs** for the data perimeter (S3/STS/KMS/SQS/Secrets Manager first),
   tested in a non-prod OU, reviewing CloudTrail `Access Denied` before root.
6. Keep **SCPs** for identity-side guardrails (deny org-leave, deny disabling
   security services, region deny).