Resource Access Manager (RAM) & VPC Sharing

Recap: From Permission Ceilings to Shared Plumbing

Foundations You'll Need Today

1. Why This Is on the Exam

SAP-C02 scenarios are written by people who have watched real enterprises fail at multi-account networking, and the failure they care about most is the one that starts innocently. A company creates a handful of accounts, gives each one its own VPC, and connects them with peering. That works at three accounts. At thirty it does not, because peering is a full mesh by nature: every new VPC has to be peered with every existing VPC, and each peering relationship consumes a route table entry, a connection object, and a CIDR range that must not overlap with anything else in the mesh. The operational cost grows quadratically while the value grows linearly, and the CIDR planning problem becomes unsolvable once two business units independently pick 10.0.0.0/16.

RAM is the AWS answer to the ownership half of that problem. It is not a connectivity service — it does not move packets — but it changes who is allowed to place resources into a network, which in turn changes how many networks you need. The exam tests this because the correct answer to a surprising number of networking scenarios is "you do not need a second VPC at all." A question that describes three application teams needing to reach a shared database, or a central team wanting to control all CIDR allocation, or a security team wanting every workload to sit behind one inspection point, is often probing whether you reach for peering and Transit Gateway by reflex or whether you recognize that subnet sharing removes the requirement for separate networks in the first place.

This maps most directly to Domain 1 (Design Solutions for Organizational Complexity) and to the networking portions of Domain 2 (Design for New Solutions). The organizational-complexity framing is the one to internalize: RAM is a governance tool that happens to have networking consequences. It lets a central network account remain the single owner of the VPC, its CIDRs, its route tables, and its gateways, while application accounts get exactly the slice of that network they need and nothing more. The exam will frequently pair it with AWS Organizations, because sharing within an organization is the low-friction path, and with SCPs, because the central account can constrain what participants are allowed to do with the subnets they have been given.

2. How RAM Actually Works

RAM is built around three objects: a resource share, the resources placed into it, and the principals it is shared with. The owner account creates a resource share, adds one or more shareable resources to it, and specifies principals — either individual account IDs, an organizational unit, or the entire organization. When the share is created with an organization as the principal, participants do not receive an invitation to accept; the share is simply active for them. When the principal is a bare account ID outside the organization, that account receives an invitation and must accept it before the resource becomes usable. This distinction matters in exam scenarios because it determines whether a step exists in the deployment sequence at all.

For VPC subnet sharing specifically, the mechanism is worth tracing carefully because it is where most misconceptions live. The VPC owner creates a subnet and then shares that subnet through RAM. A participant account sees the subnet appear in its own console and API as a subnet it can launch into, but the subnet is still owned by the VPC owner. The participant can create ENIs, instances, RDS instances, Lambda functions with VPC configuration, and load balancer nodes inside that subnet. The participant cannot modify the subnet, cannot change its route table association, cannot delete it, and cannot see or edit the VPC's other subnets unless those were shared too. Route tables, network ACLs, internet gateways, NAT gateways, and the VPC itself all remain under the owner's control.

The consequence is a clean separation of duties that the exam likes to test. The network account owns addressing, routing, and egress. The application accounts own their compute and their security groups. A participant's security group can reference another participant's security group by ID within the same shared VPC, which is how cross-account application tiers are wired without any peering at all. That reference works because the VPC is genuinely one VPC — the accounts are tenants in it, not peers of it. This is the single most important mental model to carry into the exam: subnet sharing is not connectivity between networks, it is co-tenancy inside one network.

RAM also shares other resource types, and the same three-object model applies. Transit Gateways can be shared so that participant accounts create their own attachments to a centrally owned TGW. Route 53 Resolver rules can be shared so that every account in the organization resolves the same on-premises domains without duplicating forwarding rules. License configurations, Aurora DB clusters, and CodeBuild projects are shareable as well. The pattern is consistent: the owner keeps control of the resource's lifecycle and configuration, and participants get the ability to consume it.

3. The Core Decision Boundary: Share the Network or Connect to It

Almost every RAM scenario reduces to one fork. Either the application accounts need to be inside a network that someone else owns, or they need their own network that can reach someone else's. The first is subnet sharing. The second is peering, Transit Gateway, or PrivateLink. Getting this fork right determines the rest of the answer, because the two paths have different failure modes, different cost profiles, and different blast radii.

The tell in a scenario is usually about ownership and control. If the question says the central team must control CIDR allocation, or that application teams should not be able to create their own VPCs, or that all egress must traverse a single inspected path, the answer is subnet sharing. If the question says two teams have already built their own VPCs and now need to talk, or that the networks must remain administratively separate for compliance, the answer is a connectivity service. If the question says the two networks have overlapping CIDRs, the answer is PrivateLink, because neither sharing nor peering can reconcile overlapping address space.

One row deserves emphasis because it is the most commonly missed. Cross-account security group referencing works inside a shared VPC and does not work across peering or Transit Gateway. If a scenario describes a three-tier application where the database tier must accept traffic only from the application tier's security group, and the tiers live in different accounts, subnet sharing is the only option that gives you that control natively. Peering would force you to reference CIDR ranges instead, which is both less precise and harder to maintain.

4. Configuration Modes and Their Tradeoffs

The first knob is who the principal is. Sharing with an organizational unit or the whole organization is the low-friction mode: no invitations, no acceptance step, and new accounts added to the OU automatically gain access to the share. Sharing with a bare account ID outside the organization requires the participant to accept an invitation, which introduces a manual step and a pending state that can silently block a deployment. For exam purposes, "share with the organization" is almost always the intended answer when the accounts are in the same organization, because it removes an operational failure mode rather than adding one.

The second knob is which subnets you share, and this is where the real design work happens. A common pattern is to share only private application subnets and keep the public subnets, NAT gateways, and the VPC's internet gateway entirely within the network account. Participants then have no path to the internet except through the owner's NAT gateway, which is exactly the centralized-egress property the network team wanted. The alternative — sharing public subnets too — gives participants the ability to attach public IPs and elastic IPs, which is usually the opposite of what a governance-focused design intends. The tradeoff is that participants lose the ability to run anything that genuinely needs a public address, so the decision has to be made deliberately rather than by default.

The third knob is whether the share is created with automatic association to the organization. When you share with an organization or OU, you can enable automatic sharing so that resources added to the share later are immediately visible to all principals. Without it, each new resource requires an explicit association. The tradeoff is between convenience and surprise: automatic sharing means a subnet added to the share is instantly usable by every participant, which is convenient but means a mistake in the network account propagates immediately. Manual association adds a step but gives the network team a checkpoint.

The fourth knob is tagging and tag-based access control. RAM supports sharing based on tags, and the owner can require that participants only launch resources carrying specific tags. Combined with SCPs in the participant accounts, this is how a central team enforces that everything launched into a shared subnet is attributable to a cost center. The tradeoff is enforcement overhead: tag policies and SCP conditions have to be maintained, and a missing tag becomes a hard failure at launch time rather than a soft warning. Teams that skip this step usually discover the gap during their first chargeback cycle.

5. Sizing, Limits and Quotas

Subnet sharing changes the arithmetic of IP address planning in a way that catches people out. In a per-account VPC model, each account gets its own address space and the only constraint is that the spaces do not overlap. In a shared VPC model, every participant draws from the same address space, so the VPC's CIDR has to be sized for the aggregate of all participants plus growth. A /16 gives 65,536 addresses, which sounds generous until you remember that AWS reserves five addresses per subnet, that a subnet cannot span Availability Zones, and that a large EKS cluster can consume thousands of addresses on its own through pod networking.

The practical guidance is to size the shared VPC for the whole organization's foreseeable footprint rather than for today's workloads, and to use secondary CIDR blocks on the VPC when the primary block runs short. A VPC can have multiple CIDR associations, and additional blocks can be added later without recreating the VPC, which is the escape hatch when the original sizing was optimistic. Subnets themselves cannot be resized after creation, so the subnet-level split is the decision that is genuinely hard to reverse.

Two quota behaviors are worth internalizing. First, sharing with an OU or an organization counts as a single principal regardless of how many accounts are inside it, which is why organization-level sharing scales so much better than enumerating account IDs. Second, the number of subnets a participant can launch into is bounded by the owner's VPC subnet count, not by anything in the participant account, so a participant hitting a limit is often a signal that the network account needs a quota increase rather than the application account. Always check which account owns the resource before filing the increase.

6. Failure Modes and What They Look Like in Production

The most common failure is a launch that fails with an authorization error the participant cannot explain, because the participant's IAM policy looks correct. The cause is almost always that the subnet was never shared, or was shared with a different principal than the one being used, or the invitation is still pending. The first diagnostic move is to check the resource share from the owner account and confirm the participant appears as an active principal rather than a pending one. The second is to confirm the participant is launching into the shared subnet and not into a subnet in its own VPC that happens to have a similar name.

The second failure mode is a connectivity problem that looks like a routing bug but is actually a security group or NACL issue. Because the network ACL belongs to the owner and the security group belongs to the participant, a change in either place can break traffic, and the two teams will each believe the other is at fault. The symptom is typically asymmetric: outbound works, return traffic is dropped, or vice versa. The first diagnostic move is to check the NACL on the subnet in the owner account and the security group on the ENI in the participant account, in that order, because NACLs are stateless and are the more common culprit for one-directional failures.

The third failure mode is address exhaustion, and it presents as intermittent launch failures that correlate with load rather than with any configuration change. Because all participants draw from one pool, a single participant with a runaway autoscaling group can consume the shared subnet's free addresses and cause unrelated teams to fail. This is the shared-VPC equivalent of a noisy neighbor, and it is the strongest argument for per-participant subnet segmentation rather than one large shared subnet for everyone. Monitoring free IP count per subnet is the control that catches it before it becomes an incident.

The fourth failure mode is the accidental dependency. A participant builds a workload that assumes the shared subnet will always exist, and the network team later deletes or re-CIDRs it. Because the participant cannot see the owner's change management, the breakage arrives without warning. The mitigation is organizational rather than technical: the network account's change process has to treat shared subnets as a public interface with consumers, and participants should be told about planned changes through the same channel they would use for any other dependency.

7. The Operational and SRE Angle

From an SRE perspective, a shared VPC introduces a dependency that is invisible in the participant's own dashboards. The participant's service health depends on a subnet, a route table, and a NAT gateway that live in another account and are monitored by another team. If the network account's NAT gateway saturates, every participant sees elevated latency and connection failures simultaneously, and each participant's on-call will independently conclude that their own service is broken. The runbook has to start with a cross-account check: is the shared network healthy, and is anyone else affected at the same time.

The metrics worth alarming on are the ones that describe the shared resource rather than the participant's workload. Free IP addresses per shared subnet, NAT gateway bytes and connection counts, and the age of the oldest pending resource share invitation are the three that catch the most incidents. For the participant side, the useful signal is a synthetic check that exercises the actual path through the shared subnet to a dependency, because that is the only thing that proves the cross-account path is intact end to end. Internal service metrics will look healthy right up until the moment the network path breaks.

The SLO implication is that a participant's availability target is capped by the network account's availability target, whether or not anyone wrote that down. If the shared NAT gateway is designed for 99.9% and the participant promises 99.95%, the participant's promise is unachievable and the gap will only surface during a post-incident review. The honest approach is to make the dependency explicit in the service's error budget calculation and to agree on the network account's target as an input to the participant's own target. This is the same reasoning that applies to any shared platform, and it is worth stating plainly in the design document rather than leaving implicit.

The runbook shape follows from that. First, confirm scope: is this one participant or all of them. Second, check the shared network's health metrics in the owner account. Third, check the participant's security group and the subnet's NACL for recent changes. Fourth, check free IP capacity. Only after those four steps does it make sense to look at the participant's application logs, because the first three steps are where the majority of shared-VPC incidents actually live.

8. Edge Cases and Exam Gotchas

The single most-tested gotcha is that a participant cannot delete or modify a shared subnet, and cannot see the VPC's other subnets. Scenarios sometimes describe a participant team that wants to "manage its own networking" while using a shared VPC, and the correct answer is that this is not possible — the participant gets consumption rights, not ownership. If the requirement genuinely includes independent routing control, the answer is a separate VPC with a connectivity service, not subnet sharing.

The second gotcha is the invitation state. Shares to accounts outside the organization require acceptance, and a scenario that describes a deployment failing with an authorization error after a share was created is usually testing whether you check for the pending invitation. Shares to an OU or the organization do not require acceptance, so the same scenario with an in-organization participant has a different answer. Read the principal type carefully before choosing.

The third gotcha is that cross-account traffic inside a shared VPC is still billed as cross-account data transfer. Sharing does not make traffic free, and a scenario that emphasizes cost reduction should not be answered with subnet sharing on that basis alone. The cost argument for sharing is about operational overhead and IP efficiency, not about data transfer pricing.

The fourth gotcha is that RAM shares resources, not permissions. Sharing a subnet does not grant a participant the ability to launch instances — the participant's IAM identity still needs the relevant EC2 permissions, and any SCP in the participant's OU still applies. This is the same ceiling-versus-grant distinction from the permission-boundary material, applied at the resource layer instead of the identity layer. A scenario that says a participant was granted a subnet share but still cannot launch is testing whether you check IAM and SCPs before assuming the share failed.

The fifth gotcha is the difference between sharing a subnet and sharing a Transit Gateway. Sharing a TGW gives participants the ability to create their own attachments to a central hub, which is a connectivity grant. Sharing a subnet gives participants the ability to place resources inside a network they do not own, which is a co-tenancy grant. Both are RAM shares, and scenarios will sometimes offer both as options to see whether you distinguish them.

9. RAM vs. the Services It Gets Confused With

The confusion set is small but the distinctions are sharp. RAM is not a connectivity service, so it never appears as an alternative to peering or Transit Gateway when the requirement is genuinely "connect two existing networks." It appears instead when the requirement is "let these accounts use a network that already exists." The exam will sometimes phrase a question so that both readings are plausible, and the tiebreaker is whether the accounts already have their own VPCs that must remain in place.

Against VPC peering, the distinction is scale and control. Peering is a one-to-one relationship between two VPCs, each side retains full control of its own routing, and the number of relationships grows quadratically with the number of VPCs. Subnet sharing is a one-to-many relationship where the owner retains all routing control and the participant count is bounded only by quotas. Peering is right when the two networks are genuinely independent administrative domains. Sharing is right when one team is the network authority and the others are consumers.

Against Transit Gateway, the distinction is whether you need a network at all. TGW connects networks that already exist and gives you centralized routing between them, which is the right answer when participants must keep their own VPCs for compliance or isolation reasons. Subnet sharing removes the need for those VPCs in the first place. A scenario that says each business unit must have its own VPC for regulatory reasons is pointing at TGW; a scenario that says the central team wants to own all addressing is pointing at sharing.

Against PrivateLink, the distinction is granularity and address overlap. PrivateLink exposes a single service to consumers without any network-level integration, which makes it the only option when CIDRs overlap. Subnet sharing requires a single non-overlapping address space and gives participants a whole subnet rather than a single endpoint. If the requirement is "consume one API," PrivateLink is the smaller, safer answer. If the requirement is "run your workloads in our network," sharing is the answer.

Hands-on Lab: Sharing a Central VPC Across Three Application Accounts (45 min)

Scenario Question Drills (20 min)

Peek into Tomorrow

Sources