AWS RAM shared VPC architecture SOC 2 is a subnet share with a clear owner. The VPC owner uses AWS Resource Access Manager to share subnets with other accounts in the same organization. Participants launch their own instances, databases, and functions into those subnets. The route table stays with the owner. An auditor who asks who can change the path to the internet is asking for that owner, not for the account that happens to run the instance. The client's SOC 2 report is the client's. Rutagon does not hold one. We build the share so the sample names the route table and the account that can edit it.
A shared subnet looks like "one network" until the first ticket asks a participant to add a route. They can see the table. They cannot change it. Data perimeter architecture is the broader control on which networks may talk. This article is the share itself, and the evidence it leaves.
AWS RAM shared VPC architecture SOC 2 and the route table
The subnet sharing documentation sets the model. The owner shares one or more subnets with participant accounts in the same AWS organization. Participants can view, create, modify, and delete their own application resources in the shared subnet. They cannot view, modify, or delete resources that belong to another participant or to the owner. The point of the share is implicit routing inside one VPC, with separate accounts for billing and access. You share a non-default subnet. Default VPC subnets cannot be shared.
The responsibilities page is the audit line. The owner creates, manages, and deletes the VPC resources they own: subnets, route tables, network ACLs, peering connections, gateway endpoints, interface endpoints, Route 53 Resolver endpoints, internet gateways, NAT gateways, virtual private gateways, and transit gateway attachments. Participants cannot work with route tables in a shared subnet. They cannot create, delete, or associate them. They can describe them. A participant screenshot of the route table proves they can see the path. It does not prove they can change it. The change lives in the owner account, in the route table associated with that subnet.
Participants can create network interfaces and security groups, and they can turn on VPC flow logs for interfaces they own. They cannot create a flow log for the subnet, or for an interface they do not own. The owner can log the subnet and can log interfaces the owner does not own. The owner cannot describe or delete a flow log a participant created. Security groups follow the same split. A participant manages the groups they own. They cannot launch into the VPC's default security group, because the owner owns it. They can use an owner security group only when the owner shares it. They can write a rule that references another account's group as account-id/security-group-id.
share: RAM resource share, non-default subnets, same organization
owner_edits: route tables, NACLs, NAT, IGW, TGW attachment, peering
participant_edits: their ENIs, their security groups, flow logs on their ENIs
participant_cannot: create, delete, or associate a route table
sample: share id, subnet id, owner account, route table id, participant account
report: the client's SOC 2, not Rutagon'sAvailability Zone names do not line up across accounts. The working with shared subnets page says each account maps AZ names on its own, so us-east-1a in the owner can be a different physical zone from us-east-1a in the participant. The AZ ID, such as the identifier shown on the subnet, is the stable name. We place subnets by AZ ID. A participant who "launches in 1a to match the owner" can land in another zone and then pay for cross-zone traffic they did not draw.
Unsharing is an owner action. Existing participant resources keep running. Participants cannot create new ones in the unshared subnet. They can still modify, describe, and delete what they have. The owner cannot delete the subnet, or the VPC, while those resources remain. A teardown that deletes the share and then tries to delete the VPC will stop on the participant's instances. The sample for that change is the disassociate, plus the list of what is still running.
How the bill and the flow log split
The billing page splits the meter the same way it splits the API. Participants pay for their application resources: EC2, RDS, Redshift, Lambda. They also pay data transfer for inter-AZ traffic, peering, internet gateways, and Direct Connect gateways. The owner pays the hourly, processing, and data-transfer charges for NAT gateways, virtual private gateways, transit gateways, PrivateLink, and VPC endpoints. Public IPv4 addresses in the shared VPC are billed to the owner. Data transfer inside the same Availability Zone, identified by AZ ID, is free regardless of which account owns the resources.
That split shows up in an audit sample as two stories that must agree. The route to the NAT is the owner's route table. The NAT charge is the owner's bill. The instance that sent the byte is the participant's bill, including cross-zone transfer if the instance and the NAT are in different AZ IDs. A participant who cannot see the NAT in their console is not missing a resource. The responsibilities page says participants cannot create, delete, or describe NAT gateways in the shared subnet. They describe the route. The owner describes the NAT.
VPC flow logs for SOC 2 need an owner too. A subnet-level flow log is the owner's. An interface log on the participant's instance can be the participant's, and the owner can also log that interface. We pick one log for the sample and we record who created it, because the owner cannot delete the participant's log and the participant cannot create the subnet log. Two logs are fine for operations. One log, named in the evidence note, is what the sample points at.
Tags on the VPC and on resources in the shared VPC are not shared with participants. A tag the owner uses for cost or for scope will not appear in the participant account. We do not ask the participant to export tags they cannot see. The owner exports the route table, the associations, and the resource share. The participant exports their instances and their security groups. The join key is the subnet id and the ENI.
What we put in the sample
The diagnostic walks one subnet. Resource share id, owner account id, participant account ids, subnet id, AZ ID, route table id, and the association. Then one participant ENI, its security group owner, and the flow log we named. Then the NAT or the transit gateway attachment, which only the owner can create. If a participant was expected to attach a Transit Gateway, the share is the wrong tool for that step. Only the VPC owner can attach it to a shared subnet.
We leave the share in place when the accounts trust each other, the CIDR is one routing domain, and the platform team is willing to own every route. We do not share a subnet so that an application team can "move faster" and then discover they cannot add a route, a NAT, or a peering. Those stay tickets to the owner. If the application team must own the route table, give them their own VPC and a peering or a Transit Gateway attachment.
The client's auditor is sampling a network control: who can change the path, and whether the path matches the diagram. The diagram is the owner's route table. The running workload is the participant's instance. Rutagon builds the share, the route table, and the export that shows both. We do not write the SOC 2 report, and we do not hold one.
Rutagon runs this as an architecture diagnostic. We name the owner, the participants, the route table they cannot edit, the AZ IDs, and the flow log that will be in the sample. The sharing page is the source for who may touch which resource. The billing page is the source for who pays the NAT and who pays the instance.
Frequently Asked Questions
Who owns the route table in a shared VPC?
The VPC owner owns it. Participants can describe route tables in a shared subnet, and they cannot create, delete, or associate them. Subnets, NACLs, NAT gateways, internet gateways, and transit gateway attachments are owner resources too. A participant who needs a new route opens a change on the owner account.
What can a participant create?
Participants create their own application resources in the shared subnet, including network interfaces and security groups they own. They can write flow logs for their own interfaces. They cannot modify the subnet, the VPC, or another account's interfaces. They cannot launch with the default security group, because that group belongs to the owner, unless a non-default owner group has been shared with them.
How does this show up in a SOC 2 sample?
The client keeps the sample. AWS RAM shared VPC architecture SOC 2 evidence is the resource share, the subnet, the owner account, the route table id, and a participant workload in that subnet. Rutagon does not hold the SOC 2 report. The export should show that a route change is possible only in the owner account.
Why did two accounts disagree about the Availability Zone?
AZ names are mapped per account, so the owner's us-east-1a can differ from the participant's us-east-1a. AZ IDs are the common label, and the subnet page shows them. Same-AZ data transfer, matched on AZ ID, is free across accounts. A name mismatch puts the instance in another zone and adds a transfer charge.
Who pays for a NAT gateway in the shared subnet?
The owner pays NAT gateway hourly, processing, and data-transfer charges, plus public IPv4 addresses in the shared VPC and the transit gateway, PrivateLink, and VPC endpoint charges. Participants pay for their EC2, RDS, Redshift, and Lambda, and for data transfer on peering, internet gateways, Direct Connect, and cross-AZ paths. Participants cannot describe the NAT. They can describe the route that points at it.
Ask for an architecture diagnostic of the subnet share, the route table owner, and the audit sample. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.