Data and Security Boundaries
Last Updated: September 13, 2026
1. Data Ownership Options
| Option | Configuration |
|---|---|
| Centralized DB operations Account | The platform team owns and operates every database in a single Account |
| Workload-owned data | Each workload team owns and operates its own database |
| Hybrid | Operational DBs are chosen per workload; shared assets like a data lake/warehouse/streaming backbone are owned by a separate Data Platform |
Hybrid is a realistic starting point for most organizations. But this choice matters less than the technical constraints of cross-account backup/restore, covered in the next section.
2. Validate Cross-Account Recovery by Resource and Vault Type
Choose data ownership and recovery location together. A restriction in one snapshot API does not make every recovery path impossible.
Sharing RDS snapshots
- For RDS DB instances, copy an automated snapshot to a manual snapshot before sharing. The RDS sharing procedure also discusses AWS Backup-generated snapshots; it does not define every AWS Backup restore workflow.
- A recipient copies an encrypted shared DB-instance snapshot before restoring. Snapshots encrypted with the default AWS-managed KMS key cannot be shared as-is; assess a copy encrypted with an approved customer-managed key.
- A manual snapshot can be shared with up to 20 Accounts. Oracle/SQL Server permanent/persistent options add restrictions.
- Multi-AZ DB cluster snapshots cannot use this RDS snapshot-sharing path. This does not rule out every logical-backup or validated replication/recovery path, and does not mandate workload-owned databases. Check engine, snapshot type, Region support, and alternative recovery RTO/RPO.
Standard AWS Backup vault: copy, then restore
- Source and destination must belong to one Organization, with cross-account backup enabled by its management Account.
- The source role needs
backup:CopyFromBackupVaultandbackup:CopyIntoBackupVault; the destination vault needs a resource policy allowing the latter. Service-specific backup/copy and KMS permissions also apply. - Encryption depends on resource type. Destinations for fully managed AWS Backup resources support
aws/backupor customer-managed keys; other resource types require a customer-managed key. The official copy page also warns against default vaults. This guide therefore uses a dedicated destination vault with explicit key/policy configuration; a vault name alone does not establish encryption/copy suitability. - Standard-vault cross-account recovery copies first, then restores in the destination. Prepare the resource’s service-linked role, restore role, subnets, and SGs.
- Cross-account copy from cold tiers is unsupported. Check the resource and Region feature matrices.
Logically air-gapped vault: restore directly from a shared Account
A logically air-gapped vault can be shared through AWS RAM with individual Accounts, including Accounts in another Organization. The recipient can restore supported recovery points directly, without first copying them into a recipient vault. Thus “AWS Backup never supports direct cross-account restore” is inaccurate.
Distinguish standard-vault copy permissions from air-gapped-vault RAM sharing. Validate resource/Region support, restore IAM, encryption-key type, sharing authorization, and recovery when the source Account is inaccessible. Do not assume this supports every database type.
Restrict unapproved copy and sharing
A destination leaving the Organization may retain existing copies. Assess source backup:CopyTargets/backup:CopyTargetOrgPaths conditions, destination-vault policies, KMS, RAM sharing permissions, and organizational exit procedures together. Enabling cross-account backup does not grant copy permission to every user or bypass IAM, vault, or KMS denies.
RTO includes copy, restore, and application validation actually performed after an incident. Pre-existing copies shift copy cadence into RPO considerations. Record resource-specific recovery tests and objectives in the Decision Framework.
3. Isolating the PII Data Tier
Storage that's placed directly inside a VPC (RDS, etc.) fits well in a separate VPC from the general serving tier. The purpose is to separate the scope of routing, inspection, direct access, and incident containment. A separate VPC alone isn't sufficient — you also need IAM, SG, KMS key policy, logging, and approved access paths working together.
Shared VPC audit access: Participants cannot describe owner NAT gateways, but owner-provided route/NAT inventories, Config, Flow Logs, and delegated read access can provide evidence. Dedicated VPCs can simplify ownership; Shared VPC is not inherently unauditable.
S3 isn't a VPC-placed resource. Control it through bucket/Account ownership, VPC endpoints + endpoint policy, bucket/access point policy, KMS key policy, and org-approved paths.
Blocking Dev/QA access to Production's original PII data
Turning "block direct access" into concrete API-level paths yields a coverage matrix like this.
| Path | Control mechanism |
|---|---|
| AWS Backup cross-account copy | backup:CopyTargets/CopyTargetOrgPaths SCP conditions, destination vault access policy |
| RDS DB-instance snapshot sharing | Restrict rds:ModifyDBSnapshotAttribute to approved automation; audit recipients with DescribeDBSnapshotAttributes |
| Aurora DB-cluster snapshot sharing | Restrict rds:ModifyDBClusterSnapshotAttribute to approved automation; audit recipients with DescribeDBClusterSnapshotAttributes |
| RDS/Aurora public snapshot sharing | Validate recipient allowlists and rejection of restore=all for both sharing APIs; retain KMS, detection, and remediation controls |
| Outbound EBS snapshot sharing | Restrict/audit ec2:ModifySnapshotAttribute and recipient createVolumePermission |
| EC2 Allowed AMIs(consumption) | Account/Region settings or declarative policy limit discovery/use of public/shared AMIs; Account-owned AMIs are excluded |
| S3 Batch Replication / cross-account replication | Bucket policy, restrict replication roles, RCP |
| Movement via DMS/Glue | That service's network/IAM path |
| CDC streams (MSK/Kinesis/DMS) | Resource policy + restrict cross-account consumers |
| Cross-account Athena/Redshift queries, Lake Formation | Audit Lake Formation cross-account grants |
Choose KMS key type and recovery permissions for the selected copy/restore path and organizational requirements. AWS does not universally mandate customer-managed keys for all PII storage. Test destination keys, pre-existing copies, permitted key policies/grants, and air-gapped-vault sharing when the source Account is unavailable.
4. Secrets Manager / KMS Cross-Account
Both the secret's resource policy and the caller's identity policy are required. Cross-account secrets need a customer-managed KMS key, and that key requires both the owner's key policy and the caller's IAM policy. In other words, centralized secret/key management needs more than just policy and rotation — it requires jointly operating permissions and recovery responsibility across both Accounts.
5. AWS-Native Security Telemetry vs. Existing CNAPP
If your organization already has a CNAPP (Cloud-Native Application Protection Platform) and is adopting AWS-native capabilities, the safer approach isn't "replace the product" — it's to compare current coverage against AWS-native capabilities by security purpose, and fill only confirmed gaps. Purposes can be grouped as:
- Organizational preventive controls
- Configuration posture
- Data security posture
- Workload runtime protection
- Threat detection
- Finding workflow
- Workload-context detection
Some confirmed facts:
- Distinguish Security Hub CSPM standards, controls, and ASFF findings from other Security Hub capabilities. Names alone do not establish identical feature scope or Config dependencies.
- Most Security Hub CSPM controls require AWS Config recording. Review this alongside Control Tower 4.0 managed-baseline dependencies, without turning it into a Config prerequisite for the IAM Identity Center service itself.
- Security Hub CSPM doesn't retroactively collect findings generated before activation, and only processes findings in Regions where it's enabled. For full coverage of the documented CIS AWS Foundations Benchmark security checks, you need to enable it in every supported Region. GuardDuty is also enabled per Region.
- GuardDuty and Security Hub are both available in the Seoul Region, but the finding types/control coverage differ by Region — comparisons should be based on actual Seoul Region coverage.
6. Services Confirmed to Support Resource Creation in a Shared Subnet
The table summarizes the official Shared VPC support list. That list explicitly permits omissions: consult service-specific documentation for unlisted services and distinguish explicit lack of support from absence in a list.
| Supported service | Notes |
|---|---|
| Amazon RDS, Aurora | Primary target |
| ElastiCache (Redis OSS) | |
| Redshift, EMR, Glue | Common Data Platform target |
| OpenSearch Service, MSK | |
| EC2, ECS, EKS, Lambda, EFS | |
| ALB/NLB/GWLB | |
| PrivateLink (interface endpoint) | |
| VPC Lattice, TGW, VPC Peering, Traffic Mirroring | |
| Route 53 (PHZ cross-account association) | |
| DMS, Verified Access, SageMaker Unified Studio | |
| Amazon MQ | ActiveMQ only. RabbitMQ is not supported |
For engines explicitly excluded by the official list, such as Amazon MQ RabbitMQ, assess separate placement. Before excluding an entire CUJ from Shared VPC, consider connecting only that dependency through another VPC or API path.
Next
For a way to make all decisions across boundaries, accounts, IAM, network, and data reproducible → Decision Framework and PoC Design