LAB 55 ‐ 3 TIER APPLICATION SETUP - DevWithNehaCloud/Oracle-Cloud-Infrastructure-wiki GitHub Wiki

OCI Three-Tier Architecture

Overview

Three-Tier Architecture is a common enterprise application design pattern where the application is divided into three logical layers:

  1. Web Layer (Presentation Layer)
  2. Application Layer (Business Logic Layer)
  3. Database Layer (Data Layer)

This architecture improves security, scalability, availability, and manageability.

Architecture Diagram with WAF

                Internet
                    |
                    |
             +------------+
             |    DNS     |
             +------------+
                    |
                    |
             +------------+
             |  OCI WAF   |
             +------------+
                    |
                    |
        +----------------------+
        | Public Load Balancer |
        |   (Public Subnet)    |
        +----------------------+
                    |
                    |
            +---------------+
            |  Backend Set  |
            +---------------+
                    |
                    |
    +----------------------------------+
    |      Application Servers         |
    |    (App Subnet - Private)        |
    +----------------------------------+
                    |
                    |
    +----------------------------------+
    |        Database Servers          |
    |     (DB Subnet - Private)        |
    +----------------------------------+

OCI Components Used

Component Purpose
VCN Provides isolated network
Public Subnet Hosts Load Balancer
Private App Subnet Hosts Application Servers
Private DB Subnet Hosts Database Servers
Load Balancer Distributes incoming traffic
NSG / Security Lists Controls network access
Route Tables Controls traffic routing
Internet Gateway Allows internet access
WAF (Optional) Protects against web attacks

Traffic Flow

Step 1: User Access

User accesses the application using:

https://myapplication.com

  • The DNS record resolves to the Public IP of the OCI Load Balancer.

  • OCI WAF inspects and filters malicious requests such as SQL Injection and XSS attacks.

  • Valid traffic is forwarded to the Public Load Balancer.

Step 2: Request Reaches Load Balancer

The request reaches the Public Load Balancer.

The Load Balancer:

  • Listens on Port 80 or 443
  • Terminates SSL (optional)
  • Performs health checks
  • Routes traffic to healthy backend servers

Step 3: Listener Receives Request

A Listener is configured on the Load Balancer.

Example:

  • Protocol: HTTP/HTTPS
  • Port: 80 or 443

The Listener accepts incoming requests and forwards them to the configured Backend Set.

Step 4: Backend Set Processing

Backend Set contains one or more Application Servers.

Example:

Backend Set

├── App Server 1

├── App Server 2

└── App Server 3

The Load Balancer selects a healthy backend server using policies such as:

  • Round Robin
  • Least Connections
  • IP Hash

Step 5: Request Sent to Application Server

The selected Application Server processes:

  • Business Logic
  • API Requests
  • Authentication
  • Application Processing

The Application Servers reside in a Private Subnet and are not directly accessible from the Internet.

Step 6: Application Connects to Database

Application Servers communicate with Database Servers located in a separate Private DB Subnet.

Only required ports are opened.

Example:

  • MySQL : 3306
  • Oracle DB : 1521
  • PostgreSQL : 5432

Step 7: Response Returned

Database returns data to the Application Server.

Application Server processes the response and sends it back through the Load Balancer to the User.

Where WAF is Placed?

WAF (Web Application Firewall) is deployed in front of the Public Load Balancer.

Traffic Flow:

Internet
   |
   |
  DNS
   |
   |
OCI WAF
   |
   |
Public Load Balancer
   |
Backend Set
   |
Application Servers
   |
Database Servers

Purpose of WAF

WAF protects web applications from common attacks:

  • SQL Injection
  • Cross-Site Scripting (XSS)
  • Cross-Site Request Forgery (CSRF)
  • DDoS Mitigation
  • Malicious Bots
  • OWASP Top 10 Threats

WAF filters malicious requests before they reach the Load Balancer or Application Servers.

Security Design

Load Balancer NSG

Allow:

  • TCP 80
  • TCP 443

Source:

0.0.0.0/0

App Server NSG

Allow:

  • TCP 80 or 8080

Source:

Load Balancer Subnet or Load Balancer NSG

Database NSG

Allow:

  • TCP 1521

Source:

Application Subnet

Benefits

  • Improved Security
  • Better Scalability
  • High Availability
  • Load Distribution
  • Fault Isolation
  • Easier Maintenance

Interview Explanation

"In OCI, we implemented a Three-Tier Architecture where the Load Balancer was deployed in a public subnet and application servers were deployed in a private application subnet. Internet traffic first reached the public Load Balancer through its public IP address. The Listener accepted requests on port 80/443 and forwarded them to a Backend Set containing multiple application servers. The application servers processed business logic and communicated with database servers located in a separate private database subnet. For additional security, OCI WAF was deployed in front of the Load Balancer to protect against SQL Injection, XSS, and other web-based attacks."

First, log in to the Jump Server (Hub VCN - Public Subnet). From the Jump Server, connect to the Private Application Server located in the private subnet.

Now, we will prepare the Private Application Server to host the application.

Now, try to install Apache on the private server. The installation will fail because the NAT Gateway is not configured, and the private server does not have internet access to download the required packages.

yum install httpd

To provide internet access to the private server, create a NAT Gateway in the VCN where the private VM is deployed. After creating the NAT Gateway, update the custom route table associated with the Application Subnet and add a route rule that directs internet-bound traffic (0.0.0.0/0) to the NAT Gateway.

After configuring the NAT Gateway and updating the Application Subnet route table, the private server gained internet access. We were then able to successfully install Apache (httpd) on the private server.

cd /var/www/html/

pwd

vi index.html

Create the index.html file and paste the sample HTML application content into it. Save the file and exit the editor.

At this stage, we are hosting our first sample web application on the server. The application will be used later to validate the complete three-tier architecture setup, including networking, security rules, and load balancing.

In the next steps, we will create and configure the Web Subnet, Application Subnet, and Database Subnet, apply the required security rules, and deploy a Load Balancer. Once the Load Balancer is attached to the backend servers, we will verify that the application is accessible through the load-balanced architecture.

Step 1: Create Web, App and DB Subnets

Created three separate subnets for the three-tier architecture:

  • swiggy-dev-web-subnet
  • swiggy-dev-app-subnet
  • swiggy-dev-db-subnet

Created a dedicated route table and custom security list for each subnet and attached them to their respective subnets.

  • swiggy-dev-web-rt → swiggy-dev-web-sl
  • swiggy-dev-app-rt → swiggy-dev-app-sl
  • swiggy-dev-db-rt → swiggy-dev-db-sl

The default security list was not used. Custom security lists were created for each tier to implement tier-specific network access controls.

Step 2: Create Public Load Balancer

Created a public load balancer in the swiggy-dev-web-subnet to distribute incoming client traffic across the web tier instances.

Configuration Details

  • Load Balancer Name: swiggy-dev-lb
  • Type: Public Load Balancer
  • Compartment: swiggy-dev-network
  • Subnet: swiggy-dev-web-subnet
  • Listener Protocol: HTTP
  • Listener Port: 80
  • Backend Set: swiggy-dev-web-bs
  • Health Check Protocol: HTTP
  • Health Check Port: 80
  • Health Check URL Path: /

The load balancer listener receives incoming requests on port 80 and forwards them to the backend web servers configured in the backend set. Health checks are enabled to continuously monitor backend availability and route traffic only to healthy instances.

Backup Retention Non-Production Environment: Retain backups for 1 month. Production Environment: Retain backups for 3 months.

load balancer is now created and showing the backend server health as critical

Now, when we open the Load Balancer Public IP in the browser, we are getting the following error:

STEP 1 – Check the Internet Gateway

First, we will check whether an Internet Gateway (IGW) is available in the Spoke VCN (spoke-dev-vcn).

  • If the Internet Gateway is already present, we will verify its configuration.
  • If it is not present, we will create an Internet Gateway in the VCN.
  • We will also make sure that the required route is configured in the appropriate Route Table to allow internet traffic.

Next, we will update the Custom Route Table associated with the Web Subnet.

Add a route rule with:

Destination: 0.0.0.0/0 Target Type: Internet Gateway Target: Internet Gateway of spoke-dev-vcn

This will allow the Web Subnet to communicate with the internet through the Internet Gateway.

The Internet Gateway (IGW) is now successfully added to the Custom Route Table of the Web Subnet.

STEP 2 – Recheck the Load Balancer

Now, we will open the Load Balancer Public IP in the browser again.

The same error is still displayed, which means the issue is not resolved by adding the Internet Gateway route.

We will continue troubleshooting by checking the Load Balancer listener, backend set, health status, and security rules.

STEP 2 – Check Security List for Port 80

Next, we will check whether the Custom Security List attached to the Web Subnet allows ingress traffic on port 80 (HTTP).

Verify that an Ingress Rule is configured to allow:

  • Protocol: TCP
  • Source CIDR: 0.0.0.0/0
  • Destination Port: 80

If port 80 is not allowed, we will add the required ingress rule to the Web Subnet's Custom Security List.

STEP 3 – Recheck the Application

Now, we will check the Load Balancer URL again.

This time, the error has changed from the previous error to:

502 Bad Gateway

This indicates that the Load Balancer is reachable, but it is unable to get a valid response from the backend server.

We will continue troubleshooting by checking the backend server connectivity, Apache service, port 80, and backend health status.

STEP 4 – Check Web Subnet Egress Rule

Till the Load Balancer, everything is working fine. Since the request is reaching the Load Balancer, we do not need to check the Internet Gateway or Route Table within the same VCN again.

Now, we will check the egress rule of the Web Subnet's Custom Security List.

We need to allow traffic from the Web Subnet to the Application Subnet on TCP port 80.

Add an egress rule with:

  • Destination: Application Subnet CIDR
  • Protocol: TCP
  • Destination Port: 80

This will allow the Load Balancer in the Web Subnet to forward HTTP traffic to the backend servers in the Application Subnet.

adding traffic going from web subnet to app subnet

STEP 4 – Check App Subnet Ingress Rule

Now, we will check the Ingress Rule of the Application Subnet's Custom Security List.

We need to allow traffic coming from the Web Subnet to the Application Subnet on TCP port 80.

Add an ingress rule with:

  • Source: Web Subnet CIDR
  • Protocol: TCP
  • Destination Port: 80

The egress rule of the Application Subnet is already allowed for all.

This rule allows HTTP traffic from the Web Subnet to the Application Subnet.

STEP 5 – Check Load Balancer Listener

The Load Balancer backend server health is still showing as Critical.

We checked the Load Balancer Listener and confirmed that it is correctly configured to listen on port 80.

Since the listener is working correctly, we will now check the Backend Set and Health Check configuration, followed by testing connectivity to the backend server on port 80.

STEP 6 – Update Backend Health Check

The backend health check is showing Connection Failed.

We will now update the Load Balancer Health Check configuration.

Previously, the health check protocol was set to TCP. We will change it to HTTP and use port 80.

  • Protocol: HTTP
  • Port: 80
  • Path: /

This will allow the Load Balancer to check whether the backend server is responding correctly to an HTTP request.

STEP 7 – Check OS-Level Firewall

At the OCI console level, we have already verified the complete network path end-to-end, including the Security Lists, Gateways, Route Tables, and Subnet configurations.

Since these configurations are correct, the next step is to troubleshoot at the server/OS level.

One thing we have not checked yet is the OS-level firewall on the private VM. We need to verify whether the firewall is enabled and, if enabled, whether it is blocking port 80.

Log in to the Private VM and check the firewall status:

systemctl status firewalld

Server-Level Firewall Configuration

As we can see, the server-level firewall (firewalld) is enabled on the private server.

We have two options to allow HTTP traffic on port 80:

  1. Disable the server-level firewall.
  2. Keep the firewall enabled and explicitly allow port 80.

We verified the firewall status using:

systemctl status firewalld

Since the firewall is enabled, it can block incoming HTTP traffic on port 80 even if the OCI Security List or NSG allows it.

For this lab, we will choose the first option and disable the server-level firewall:

sudo systemctl stop firewalld

sudo systemctl disable firewalld

After disabling the firewall, port 80 traffic will no longer be blocked at the operating-system level.

the Load Balancer backend server health is now showing as OK (Healthy).

The application is also successfully hosted and accessible on the backend server.

Load Balancer Policies

  • Round Robin: Distributes incoming requests sequentially and approximately equally across all healthy backend servers. It is suitable when backend servers have similar capacity.

  • Weighted Round Robin: Distributes traffic based on the weight assigned to each backend server. A server with a higher weight receives more traffic. For example, with Server 1 = weight 3 and Server 2 = weight 1, approximately 75% traffic goes to Server 1 and 25% to Server 2.

  • IP Hash: Uses the client's source IP address to calculate a hash value and routes requests from the same client to the same backend server, providing client-to-server consistency.

  • Least Connections: Sends new requests to the backend server with the fewest active connections. It is useful when requests have different processing times.

Interview Answer

Round Robin distributes requests approximately equally across healthy backend servers. Weighted Round Robin distributes traffic based on the assigned weight of each server, allowing higher-capacity servers to handle more traffic. IP Hash uses the client's source IP to consistently route requests to a backend server, while Least Connections sends new requests to the backend server with the fewest active connections.