Overlapping CIDRs and Private Access for a Claims Migration
A healthcare payer runs a claims platform in AWS ca-central-1. Its VPC CIDR is 10.50.0.0/16, and the on-premises data center also uses 10.50.0.0/16. The payer is moving a 12 TB Oracle 19c claims database to Oracle Database@AWS. During a 9-month transition, 250 application servers in AWS and 40 on-premises batch servers must reach the database. There are 40 DBAs, 15 auditors, and one external vendor that wants a public database endpoint because it is simpler. The existing AWS Direct Connect is 1 Gbps; a backup VPN is 200 Mbps. The security team requires private connectivity, least privilege, and immutable audit evidence. The network team proposes attaching the existing VPC directly to the Oracle Database@AWS network. You must resolve the design before the migration window.
1. Resolve the CIDR overlap and design private connectivity for AWS, on-premises, and the vendor. What must change?
Read the worked answer
Overlap resolution. The existing VPC and on-premises both use 10.50.0.0/16, so they cannot be attached to the Oracle Database@AWS network as-is; overlapping CIDRs break routing and can cause traffic to black-hole. Create a new, non-overlapping VPC for the database landing zone, for example 10.60.0.0/16, with a dedicated subnet for Oracle Database@AWS. Connect it to the existing VPC and on-premises through AWS Transit Gateway and the Direct Connect gateway, and advertise only the specific database subnets. Do not attach the overlapping VPC directly. For the vendor, use a private VPC endpoint or a partner private connection; refuse the public endpoint. The backup VPN is for break-glass only, not 250 production application servers. Validate asymmetric routing and return paths before cutover.
2. Design identity and access for DBAs, auditors, and the vendor.
Read the worked answer
Identity design. Federate the workforce identity provider into AWS IAM Identity Center and then into OCI IAM; do not create separate standing OCI users. Map groups: ODB-DBA-Prod for database management without tenancy admin, ODB-DBA-OnCall for break-glass with approval, ODB-Auditor for read-only metadata and audit logs, and ODB-Vendor for a restricted schema and time-bound access. Require MFA. Use OCI policies scoped to the database compartment. For the vendor, create a limited database service and a named user with no access to other schemas; expire the account after the transition. Auditors need read access to unified audit and OCI audit, not SELECT on claims data. Review entitlements quarterly and alert on policy changes. Do not let the vendor use a shared DBA account; attribution is part of the audit evidence.
3. What controls prove immutability and protect data at rest and in transit?
Read the worked answer
Controls. Use TDE with customer-managed keys in OCI Vault, rotate keys, and restrict key policy to the security group. Encrypt network paths with TLS for database connections; keep traffic off the public internet. Enable unified auditing for logon, privilege changes, data access by the vendor, and failed access; ship audit records to an immutable, write-once destination with retention that meets policy. Enable OCI Audit and AWS CloudTrail for control-plane actions, and restrict deletion of audit buckets. Separate duties: DBAs manage databases but cannot delete audit or key material. Test restore and audit retrieval, not just configuration. Document that Oracle Database@AWS infrastructure is provider-managed, while customer data, users, and keys remain customer responsibilities.