Oracle Database@AWS Networking, Security, and Identity
This domain tests the two-network, two-control-plane reality of Oracle Database@AWS: an AWS VPC on one side, an OCI VCN on the other, and separate identity systems that must be federated and authorized deliberately.
Two networks
AWS side: subnets, route tables, security groups. OCI side: client and backup subnets, route tables, security lists, and NSGs. Peering is private, but you must add routes in both directions and open the listener port in both the AWS security group and the OCI NSG.
Identity model
- AWS IAM governs the AWS-side resources: who can order, view, and delete Oracle Database@AWS.
- OCI IAM governs the database plane: identity domains, groups, policies, compartments. Federating OCI IAM with AWS IAM Identity Center (or another SAML/SCIM IdP) gives one identity across both consoles.
- Database accounts are a third layer: OCI identity never grants SQL access. Create Oracle users and roles separately, with least privilege, and use TCPS for the listener where required.
Data protection
TDE is mandatory; keys live in a local keystore or OCI Vault/HSM - not AWS KMS. Enable auditing and evaluate Oracle Data Safe for activity monitoring and sensitive-data discovery.
Worked example
App servers in VPC 10.20.0.0/16 must reach PDB APP on port 1521. Steps: create peering to VCN 10.10.0.0/16; add VPC route 10.10.0.0/16 pointing at the peering; add VCN route 10.20.0.0/16 pointing at the peering; allow 1521 from 10.20.0.0/16 in the security group; allow 1521 from the same CIDR in the NSG; create database user APPUSER with only the required privileges; test with tnsping and a TLS connection. Reasoning: a missing route on either side is the most common cause of "database unreachable" reports.
Traps
Opening 1521 to 0.0.0.0/0 to test; assuming AWS security groups filter traffic inside the OCI VCN; using AWS KMS keys for TDE; handing out OCI tenancy-admin to DBAs who only need database access.