Three-tier VCN segmentation with private Object Storage access
Northwind is migrating a three-tier SaaS application into OCI. The on-premises data center uses 10.10.0.0/16 and will be connected through a DRG. The new VCN must use 10.20.0.0/16 and support three availability domains. The design has an internet-facing load balancer, application servers that need outbound internet access for OS patching, and databases that must not have internet access but must reach Object Storage for backups. The security team requires that web-tier traffic cannot initiate connections directly to the database tier; only application servers may reach TCP 1521. A junior engineer proposes a single regional subnet for all tiers and one route table with 0.0.0.0/0 pointing to an Internet Gateway, relying on security lists to isolate tiers. The platform lead rejects this but wants a concrete alternative. The company also wants to avoid re-IP later when a second region is added.
1. Propose a subnet and gateway layout that satisfies the tiers, the three-AD requirement, and the no-internet database constraint. Justify the route-table targets.
Read the worked answer
Use three regional subnets, not one shared subnet: public LB subnet 10.20.1.0/24, private app subnet 10.20.2.0/24, and private DB subnet 10.20.3.0/24. Regional subnets span ADs, so the LB can place nodes across ADs without re-creating subnets per AD.
Route tables:
- LB subnet:
0.0.0.0/0-> Internet Gateway. No route to the database subnet is needed; intra-VCN traffic is local and must be controlled by security rules. - App subnet:
0.0.0.0/0-> NAT Gateway for patching;10.10.0.0/16-> DRG for on-premises; Oracle Services Network route -> Service Gateway for Object Storage. - DB subnet: no default route. Add
10.10.0.0/16-> DRG and the OSN route -> Service Gateway. This gives backups to Object Storage without internet exposure.
The VCN 10.20.0.0/16 does not overlap the on-premises 10.10.0.0/16, so the DRG routes are unambiguous. A second region can later use a non-overlapping CIDR such as 10.21.0.0/16 and DRG remote peering.
2. How would you enforce the requirement that only application servers can open TCP 1521 to the database, given that security lists also apply at the subnet level?
Read the worked answer
Use NSGs as the primary workload-level control and keep security lists as a subnet baseline. Create nsg-lb, nsg-app, and nsg-db. On nsg-lb, allow ingress TCP 443 from 0.0.0.0/0 and egress TCP 8080 only to nsg-app. On nsg-app, allow ingress TCP 8080 from nsg-lb, egress TCP 1521 only to nsg-db, and egress to the Oracle Services Network for Object Storage. On nsg-db, allow ingress TCP 1521 only from nsg-app; do not allow it from nsg-lb or from the VCN CIDR.
Because OCI evaluates both NSGs and security lists, the DB subnet security list must also not allow 1521 from the web or LB subnet. If it did, a packet allowed by the NSG could still be dropped, or an unintended source could be allowed if the NSG were misapplied. Keep the DB security list narrow, for example only the app subnet CIDR on 1521, and rely on the NSG reference to prevent web-tier access even if both tiers shared a subnet later. Validate with Network Path Analyzer from a web VNIC to the DB VNIC on 1521; the expected result is denied.
3. What else is needed for on-premises connectivity, and how does this design avoid re-IP when adding a second region?
Read the worked answer
Attach the VCN to the DRG, and add 10.10.0.0/16 -> DRG only in the private app and DB route tables. Do not put that route in the public LB route table unless the LB must reach on-premises. On-premises must route 10.20.0.0/16 back to the DRG or VPN. Confirm that the on-premises firewall and the DRG route tables both allow the specific prefixes, and that no on-premises prefix overlaps 10.20.0.0/16.
To avoid re-IP later, standardize on a regional addressing plan now: 10.20.0.0/16 for region one and a separate non-overlapping block such as 10.21.0.0/16 for region two. Use DRG remote peering or a transit architecture rather than stretching one VCN across regions. This preserves subnet roles and security rules when the second region is added, and it keeps the on-premises return routes simple.