Sharing resources safely
Lesson 3 of 3 in Consistent, Secure Deployment.
Account isolation has a cost: the thing you isolated now has to be reachable. Twelve teams in twelve accounts should not each build a Transit Gateway, run their own private certificate authority, or carve their own VPC out of an address plan nobody coordinates. The question is how to share the expensive, central thing without handing over the account it lives in.
AWS Resource Access Manager shares resources. You create a resource share naming the resources and the principals — specific account ids, an OU, or the whole organization — and the participants use the resource as if it were theirs, from their own account, under their own IAM policies. Enable sharing with AWS Organizations once and shares to principals inside the organization are accepted automatically; a share to an account outside the organization still has to be invited and accepted, which is a seam worth noticing, because it is where data-perimeter controls attach.
What RAM shares, in the combinations the exam keeps using: VPC subnets (so central networking owns the VPC while applications deploy into it), Transit Gateways (one hub, many accounts attaching), AWS Private CA (member accounts issue certificates from a CA they do not administer), License Manager configurations, Route 53 Resolver rules and DNS Firewall rule groups, Network Firewall rule groups and policies, managed prefix lists, EC2 Capacity Reservations and Dedicated Hosts, Image Builder components and images, and Lake Formation-governed Glue catalog objects.
| AWS RAM | AWS Service Catalog | |
|---|---|---|
What crosses the boundary | An existing resource you own — a subnet, a Transit Gateway, a certificate authority | A product: a versioned, pre-approved CloudFormation or Terraform definition |
What the consumer gets | Use of your resource from their own account, still subject to their IAM policies | A launch button. The stack is provisioned in their account by a role you specified |
Permissions the consumer needs | IAM permissions for the actions they take on the shared resource | Permission to launch the product — and not permissions on the underlying services |
Who keeps control | The owner: participants cannot modify or delete the shared resource itself | The administrator: the template, its parameter limits, its tags and the launch role are all fixed in advance |
The security win | One well-run copy of expensive shared infrastructure instead of twelve improvised ones | Compliant deployment without broad permissions — the escalation path is a curated template, not |
The stem that names it | “Share the central Transit Gateway / subnets / private CA with the application accounts” | “Developers must deploy approved, compliant stacks without permission to create the resources directly” |
Be precise about what a RAM share does not delegate, because this is where scenarios get built. Sharing a subnet does not make the participant a VPC administrator: participants create resources in the shared subnet, but cannot modify the VPC, its subnets, route tables or network ACLs, and cannot see or touch resources belonging to other participants in the same shared VPC. Flow logs, DNS settings and the route tables stay with the owner. Sharing a Private CA lets a participant issue certificates; it does not let them delete the CA or export its key. And a share never grants IAM permissions — the participant still needs an identity policy allowing the actions, which is why "we shared it and they still get AccessDenied" is an IAM question, not a RAM question.
Two controls belong on top of sharing. First, a resource share can be created with external principals disallowed, and you can forbid the permissive variant organization-wide with an SCP condition on ram:RequestedAllowsExternalPrincipals — the cleanest way to say "we share internally, never outward". Second, IAM Access Analyzer with the organization as its zone of trust tells you about grants that actually leave the organization, which is the inventory you want when an auditor asks what is shared with whom.
Pick the sharing mechanism
Interactive decision tree — outcomes:
- AWS RAM share targeting the OU or organization
With sharing enabled for AWS Organizations, principals inside the organization accept automatically — no invitation workflow, and accounts added to a targeted OU pick the share up. The owner keeps administration of the resource.
- AWS RAM share to the account id — invitation required
External principals must accept an invitation, which is both the friction and the audit point. Decide deliberately whether your data perimeter permits it, and record why.
- Deny external shares with an SCP
A Deny on share creation when
ram:RequestedAllowsExternalPrincipalsis true. Pair it with an organization-scoped IAM Access Analyzer so you can prove nothing already escaped. - Service Catalog product with a launch constraint
The administrator publishes the template; the launch constraint names the role Service Catalog assumes to provision it. End users launch compliant stacks while holding no permissions on EC2, RDS or IAM themselves.
- A resource-based policy — not RAM
S3 buckets, SQS queues, SNS topics, KMS keys and Lambda functions are shared with their own resource policies (plus the caller’s identity policy). RAM does not share these, and “use RAM to share an S3 bucket” is a reliable wrong answer.
- A cross-account IAM role
A role with a trust policy naming the external principal, ideally with an external id or an
aws:PrincipalOrgIDcondition. This delegates actions in your account — a different thing from sharing a resource into theirs.
AWS Service Catalog deserves its own paragraph because its security property is counter-intuitive and the exam likes it. A portfolio holds products — versioned templates the platform team wrote and reviewed. Constraints then shape how a product may be launched, and the one that matters here is the launch constraint: the IAM role Service Catalog assumes when provisioning. The end user needs permission to launch the product and nothing else — no ec2:RunInstances, no iam:CreateRole, no rds:CreateDBInstance. The permissions live in the launch role, used only through a template you authored.
That inverts the usual trade. Normally "let developers deploy their own environments" means granting broad permissions and hoping a Config rule catches the mistakes. With a launch constraint, the only infrastructure they can create is infrastructure you already approved, and the audit trail shows which product version produced which stack.
The other constraints round it out: template constraints restrict parameter values (instance types, allowed CIDRs) so a product cannot be launched into a non-compliant shape; notification constraints publish stack events to SNS; stack set constraints let one launch deploy across accounts and Regions; tag update and resource update constraints govern what may change afterwards; and TagOptions push required tags onto every provisioned product. Portfolios are shared with accounts, with an OU, or across the organization — and Control Tower's Account Factory is itself a Service Catalog product, which is why vending an account looks like launching one.
Shared VPC: who owns what, exactly?
The owner account owns the VPC, its subnets, route tables, network ACLs, internet and NAT gateways, DNS settings and flow logs. Participants create and own the resources they launch into the shared subnets — instances, load balancers, ENIs, RDS instances — and cannot see or modify each other's.
Two consequences worth carrying. Participants can reference security groups across the shared VPC, which is what makes a shared-subnet architecture usable rather than merely legal. And because the owner runs the flow logs, network telemetry for the whole VPC lands in one account by default — a detection win that comes free with the pattern.
What happens when a share is deleted?
Access stops. Resources the participant already created in a shared subnet do not vanish, but they become awkward — the participant can no longer create new ones, and the owner cannot clean up what the participant owns. Revoking a subnet share is therefore a coordinated operation, not a unilateral one, and the same caution applies to a Private CA share where a participant has issued certificates that are still in use.
This is why the perimeter control belongs at creation time: deny shares that allow external principals, rather than auditing and unpicking them later.
Sharing a Service Catalog portfolio
A portfolio is shared with specific accounts, or — with organization sharing enabled — with an OU or the whole organization, so a product published once is launchable everywhere. The important detail is that the launch constraint's role lives in the consuming account: the share carries the product definition and the constraint, and the role with the real permissions is provisioned in the account where the stack will be created (a StackSet is the usual way to put it there).
Portfolio versions matter too. Updating a product publishes a new version; previously provisioned products keep running their old version until someone updates them, which is both a safety property and an audit question — “which product version is this stack running?” is answerable, and should be asked.
Why not just give the team a cross-account admin role?
Because it fails the question an auditor actually asks: what could this principal have done? A cross-account administrator role can do anything in the account, so the blast radius is the account and the only evidence is CloudTrail after the fact.
A launch constraint inverts it: the principal can create exactly what the approved template describes, the permissions are held by a role nobody can assume directly, and the answer to “what could they have done” is a reviewed, versioned file in a repository. Same convenience for the team, radically smaller claim to defend.
Key terms: AWS Resource Access Manager (AWS RAM), Resource share, AWS Service Catalog, Launch constraint
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.