A central networking account owns a large VPC with several shared subnets, and the platform team wants application accounts in the same AWS Organizations structure to launch their own EC2 instances directly into those subnets so the subnets stay owned and managed in one place. The team wants the application accounts to accept the access without an administrator clicking accept in each account. Which approach lets the other accounts use the subnets with the least ongoing administration?
- AShare the subnets with the organisation through AWS Resource Access Manager and enable sharing within the organisation so invitations are accepted automatically. Correct
- BCreate a VPC peering connection from the networking account to each application account and add routes so the application instances can reach the subnets.
- CDeploy a CloudFormation StackSet that recreates an identical copy of each subnet inside every application account from the same baseline template.
- DPublish the subnets as an AWS Service Catalog product so application teams can provision a subnet on demand from an approved portfolio.
Why A is correct: Resource Access Manager shares supported resources such as subnets, and enabling sharing within AWS Organizations auto-accepts the share for member accounts without per-account action.
Why B is wrong: Peering connects separate VPCs for routing between them but does not let another account launch instances into the owner's subnets, so it does not deliver shared subnet ownership.
Why C is wrong: StackSets would create separate duplicate subnets in each account rather than sharing the single owner-managed subnets, defeating the goal of one place of management.
Why D is wrong: Service Catalog provisions new approved stacks per account and is for self-service products, not for sharing existing subnets owned by another account.