LAB 42 ‐ Three Tier Architecture & Setup - gautam-amitesh/OCI GitHub Wiki

In OCI, a three-tier architecture is a logical design that divides an application into three layers: the Presentation Tier, the Application (Logic/Business) Tier, and the Database (Data) Tier. Each tier is isolated within its own subnet inside a VCN. To ensure security and controlled network access, Security Lists, Network Security Groups (NSGs), and Route Tables are configured and applied to the corresponding subnets.

This architecture proposes the creation of two separate application compartments: a HUB compartment for Network and Security Administrators, and a SPOKE compartment for Application Teams and Database Administrators.

Within the HUB compartment, a HUB VCN is created that contains a public subnet hosting a Bastion (Jump) Server. Within the SPOKE compartment, a SPOKE VCN is created that contains the following subnets:

  • WEB Subnet (Public Subnet): Responsible for receiving incoming user traffic through the Internet Gateway (IGW), filtering traffic using Load Balancers, delivering UI assets such as HTML, CSS, and JavaScript to users, and routing HTTP/HTTPS requests to the backend application tier.
  • APP Subnet (Private Subnet): Responsible for executing business logic using a Compute Instance Pool. Instances in this subnet cannot be accessed directly from the public internet. Administrative access is restricted to the Bastion Server through the DRG, while outbound connectivity for software updates and patching is provided through the NAT Gateway, and private access to OCI services (Object Storage, Vault, Streaming) over Oracle's internal network fabric is provided via Service Gateway.
  • DB Subnet (Private Subnet): Responsible for storing and retrieving data using Autonomous Database and Base Database Service. Databases in this subnet accept connections and queries only from the Application Tier, ensuring secure access to backend data resources. To enable private database backups directly to OCI Object Storage and access to OCI Vault for encryption keys without routing through the public internet, Service Gateway is used.

This compartmentalized and tiered design enhances security, simplifies administration, and provides clear separation of responsibilities between networking, security, application, and database teams.

Create Compartments

  1. Create the hub2_compartment within the root compartment, and create the hub2_network_compartment and hub2_compute_and_storage_compartment within the hub2_compartment.

  2. Create the spoke2_compartment within the root compartment, and create the spoke2_network_compartment and spoke2_compute_and_storage_compartment within the spoke2_compartment.

Create VCNs & Subnets

  1. Create a hub2_vcn and a public_subnet within the hub2_network_compartment.

  2. Create a spoke2_vcn with three subnets, web_subnet (public), app_subnet (private), and db_subnet (private), within the spoke2_network_compartment.

HUB: Create, Configure, and Attach SL

  1. Create a security list named public_subnet-SL for the public_subnet in hub2_vcn. Configure an ingress rule to permit SSH access from a specific IP address and an egress rule allowing all destinations and all protocols. Attach the security list to the subnet and remove the default security list association.

HUB: Create IGW and DRG

  1. Create an Internet Gateway named hub2_vcn-IGW in the hub2_vcn VCN.

  2. Create a Dynamic Routing Gateway (DRG) named hub2-spoke2_DRG in the hub2_network_compartment, and then create the corresponding VCN attachments.

HUB: Create, Configure, and Attach RT

  1. Create a route table named public_subnet-RT, configure route rules for both the Internet Gateway and the DRG, and associate the route table with the public_subnet.

SPOKE: Create, Configure, and Attach SL

  1. Create security lists named web_subnet-SL, app_subnet-SL, and db_subnet-SL for web_subnet, app_subnet, and db_subnet respectively in spoke2_vcn.

  2. In web_subnet-SL allow inbound TCP connections on port 80 from any source and allow outbound TCP connections to app_subnet on destination port 80. Attach the security list to the web_subnet and remove the default security list association.

  3. In app_subnet-SL allow inbound TCP connections from web_subnet on port 80, allow inbound SSH access from the public_subnet of hub2_vcn, allow inbound TCP connections on port 80 and ICMP connections from the public_subnet of hub2_vcn, and an egress rule allowing all destinations and all protocols. Attach the security list to the app_subnet and remove the default security list association.

  4. In db_subnet-SL allow inbound TCP connections from app_subnet on port 1521 and allow outbound TCP connection to All IAD Services In Oracle Services Network on all ports. Attach the security list to the db_subnet and remove the default security list association.

SPOKE: Create IGW, NAT, and SGW

  1. Verify DRG Attachment to VCN and create an Internet Gateway named spoke2_vcn-IGW in the spoke2_vcn VCN

  2. Create a NAT Gateway named spoke2_vcn-NAT in the spoke2_vcn VCN

  3. Create a Service Gateway named spoke2_vcn-SGW in the spoke2_vcn VCN

SPOKE: Create, Configure, and Attach RT

  1. For a standard three-tier SPOKE VCN, only two route tables are typically required: a Public Route Table for the web_subnet and a Private Route Table for the app_subnet and db_subnet. However, to maximize security and completely isolate the database subnet from the public internet, a dedicated route table should be used for the database tier. Create three route tables named web_subnet-RT, app_subnet-RT, and db_subnet-RT for the web_subnet, app_subnet, and db_subnet, respectively. Configure Internet Gateway route rules in web_subnet-RT, configure NAT Gateway, Service Gateway, and DRG route rules in app_subnet-RT, and configure only a Service Gateway route rule in db_subnet-RT. Finally, associate each route table with its corresponding subnet: web_subnet-RT with web_subnet, app_subnet-RT with app_subnet, and db_subnet-RT with db_subnet.