Load-Balanced Web App on OCI

Deploy a highly available web app on OCI with load balancing and monitoring.

Introduction

30 Second Summary

When a website goes down, every second of downtime costs real money and erodes user trust. High availability means designing your infrastructure so that if one server fails, another picks up the slack without anyone noticing.

In this project, you will deploy a load-balanced web application on Oracle Cloud Infrastructure using two web servers, a flexible load balancer, performance monitoring with alarms, and hardened network security.

What You'll Build

A production-style highly available web application on OCI with traffic distributed across two compute instances behind a load balancer, complete with monitoring and security hardening.

By the end of this project, you'll have:

A Virtual Cloud Network (VCN) with properly segmented public and private subnets, internet gateway, and routing.
Two Always Free compute instances running Apache web servers behind an Always Free Flexible Load Balancer with health checks.
A CPU utilization alarm with email notifications via OCI Monitoring so you know when something needs attention.
Network Security Groups implementing least-privilege access controls following Oracle's recommended security best practices.
Secret Mission: Simulate a backend failure and observe the load balancer's automatic failover behavior, then document the incident response.

Are there any prerequisites?

No prior OCI experience is required. This guide walks you through account setup, SSH key generation, and all configuration from scratch. You will need a Kali Linux VM in VirtualBox (for SSH access) and a Windows browser for the OCI Console.

Set Up Your OCI Account and SSH Keys

Before you can build anything on Oracle Cloud Infrastructure, you need two things: an OCI account to provision resources, and an SSH key pair so you can securely connect to your cloud servers from your local machine.

In this step, you will create a Free Tier account on OCI, generate SSH keys in your Kali Linux VM, and take a quick tour of the OCI Console so you know where everything lives.

In this step, get ready to:

Sign up for an OCI Free Tier account and choose your home region.
Generate an SSH key pair in your Kali Linux VM.
Log in to the OCI Console and explore the main navigation sections.

Sign up for Oracle Cloud Free Tier

OCI offers a Free Tier that includes Always Free resources and $300 in trial credits for up to 30 days. You will use Always Free compute instances and a load balancer throughout this project, so you will not be charged.

On your Windows host, open a browser and navigate to cloud.oracle.com.
Click Sign Up to start the Free Tier registration.
Enter your country, name, and email address.
Complete the CAPTCHA verification and click Verify my email.
Open your email inbox and click the verification link from Oracle. You have 30 minutes before it expires.
Set a password for your account. It must be 8 to 40 characters with at least one lowercase letter, one uppercase letter, one number, and one special character.
Select your customer type (choose Individual).
Create a Cloud Account Name. This identifies your tenancy.
Select your Home Region. Choose a region geographically close to you.

Why does my home region matter?

Your home region is permanent. You cannot change it after sign-up. Always Free resources like compute instances and load balancers can only be provisioned in your home region.

Pick the region closest to you for the best latency. If your first choice is not available during sign-up, select the nearest alternative.

Accept the Terms of Use and click Continue.
Enter your address and phone number, then click Continue.
Click Add payment verification method and select Credit Card.
Enter your credit card details and click Finish.

Will I be charged?

No. Oracle uses your card only for identity verification. You may see a temporary $1 authorization hold that is reversed within a few days. You will not be charged unless you manually upgrade to a paid account.

Accept the terms and click Start my free trial.
Wait for Oracle to provision your cloud environment. This can take a few minutes. You will receive an email when your account is ready.

What about Multi-Factor Authentication?

When you sign in for the first time, Oracle may require you to enable Multi-Factor Authentication. Follow the on-screen prompts to set up an authenticator app on your phone (such as Oracle Mobile Authenticator or any TOTP app).

Generate an SSH key pair in your Kali Linux VM

SSH keys let you connect securely to your OCI compute instances without typing a password each time. You will generate a key pair now and paste the public key into OCI when you create instances in a later step.

Open your Kali Linux VM in VirtualBox.
Open a terminal window inside the VM.
Generate your SSH key pair by running this command:

ssh-keygen

What will ssh-keygen ask me?

The command prompts you three times:

File location: Press Enter to accept the default path (~/.ssh/id_rsa).
Passphrase: Press Enter for no passphrase (simplifies SSH in this project).
Confirm passphrase: Press Enter again.

Press Enter three times to accept the default file location and skip the passphrase.

You should see output showing the key fingerprint and a randomart image. This confirms the key pair was created successfully.

Display and copy your public key by running this command:

cat ~/.ssh/id_rsa.pub

Select and copy the entire output. It starts with ssh-rsa and ends with your username.
Save this text somewhere accessible. You will paste it into the OCI Console when creating compute instances.

Not seeing any output?

Make sure you ran ssh-keygen first and accepted the defaults. Check that the file exists by running ls ~/.ssh/id_rsa.pub. If the file does not appear, run ssh-keygen again.

Help me troubleshoot my SSH key generation

Explore the OCI Console navigation

Now that your account is ready, take a moment to learn where the key services live in the OCI Console. You will navigate to these sections frequently throughout the project.

On your Windows browser, go to cloud.oracle.com and sign in with your new credentials.
Enter your Cloud Account Name and click Next.
Enter your username and password, then click Sign In.
Complete the MFA setup if prompted.
Once signed in, locate the hamburger menu (three horizontal lines) in the top-left corner of the Console. Click it to open the navigation menu.
Click Networking in the menu. This is where you will create your VCN, subnets, and load balancer.
Open the hamburger menu again and click Compute. This is where you will launch your cloud server instances.
Open the menu and click Observability and Management. This is where you will set up monitoring and alarms.
Open the menu and click Identity and Security. This is where you manage users, policies, and security groups.

What is a compartment?

When you first sign in, OCI places all resources in a root compartment tied to your tenancy. For this project, you will use this default compartment.

In production environments, compartments help organize resources and control access across teams.

Your OCI account is live and your SSH keys are ready. Next up, you will build the network architecture that your web servers and load balancer will live on.

Create the VCN and Network Architecture

Your OCI account is ready and your SSH keys are generated. Now you need a network for your infrastructure to live in.

Every cloud resource needs a network to communicate. In OCI, that network is called a Virtual Cloud Network (VCN). You will create a VCN with multiple subnets to separate your compute instances from your load balancer, following Oracle's recommended architecture.

In this step, get ready to:

Create a VCN with public and private subnets using the VCN Wizard.
Create a second public subnet dedicated to the load balancer.
Configure routing and security rules for the load balancer subnet.

Create a VCN using the VCN Wizard

The VCN Wizard automates the creation of a complete network with subnets, gateways, and route tables in a single workflow.

Open the navigation menu (hamburger icon in the top left corner of the OCI Console).
Select Networking, then click Virtual Cloud Networks.
Make sure the correct compartment is selected under List Scope in the left navigation pane.
Click Start VCN Wizard.
Select Create VCN with Internet Connectivity and click Start VCN Wizard.

Fill in the wizard configuration with these values:

Enter a VCN name such as ha-webapp-vcn.
Set the VCN CIDR block to 10.0.0.0/16.
Leave the public subnet CIDR block at its default (for example, 10.0.0.0/24).
Leave the private subnet CIDR block at its default (for example, 10.0.1.0/24).
Check Use DNS Hostnames in this VCN.
Click Next to review your settings, then click Create.

Wait for the wizard to finish provisioning. Once complete, click View Virtual Cloud Network to open your new VCN's details page.

What did the VCN Wizard create?

The wizard automatically created a complete network setup: a VCN, a public subnet with an internet gateway route, a private subnet with NAT gateway and service gateway routes, and the gateways themselves.

The public subnet allows resources to have public IP addresses and reach the internet. The private subnet keeps resources hidden from the internet while still allowing outbound access through the NAT gateway.

Why separate subnets for the load balancer and compute instances?

Oracle requires the load balancer to reside in a different subnet from the application instances it serves. This separation lets you apply different security rules to the load balancer (public HTTP access) versus the backend servers (access only from the load balancer).

Create a second public subnet for the load balancer

The VCN Wizard created one public subnet for your compute instances. You now need a separate public subnet for the load balancer.

On your VCN details page, click Subnets in the left navigation pane under Resources.
Click Create Subnet.
Enter a name such as lb-subnet.
Set the Subnet Type to Regional.
Enter a CIDR block of 10.0.2.0/24 (this must not overlap with existing subnets).
Under Subnet Access, select Public Subnet.
Leave Route Table, DHCP Options, and Security Lists at their defaults for now. You will configure these in the next substep.
Click Create Subnet.

Your new subnet appears in the subnets list and becomes available after a few moments.

Single-AD regions

Some OCI regions have only one Availability Domain. This is fine. Regional subnets span all ADs in the region, so your load balancer subnet works regardless of how many ADs your region has.

Configure routing and security for the load balancer subnet

Your new load balancer subnet needs an internet gateway route so the load balancer can receive public traffic. It also needs a security list rule allowing inbound HTTP on port 80.

On the VCN details page, click Route Tables in the left navigation pane.
Click the route table associated with your load balancer subnet (if you used the default, click Default Route Table for your VCN).
Click Add Route Rules.
Set Target Type to Internet Gateway.
Set Destination CIDR Block to 0.0.0.0/0.
Select the internet gateway that the VCN Wizard created as the Target.
Click Add Route Rules.

What does this route rule do?

This rule tells OCI to send all traffic destined for addresses outside the VCN (0.0.0.0/0) through the internet gateway. Without this rule, the load balancer subnet cannot send or receive public internet traffic.

Now configure the security list to allow inbound HTTP traffic:

Return to your VCN details page by clicking the VCN name in the breadcrumbs at the top.
Click Security Lists in the left navigation pane.
Click the security list associated with your load balancer subnet (the default security list if you did not select a custom one).
Click Add Ingress Rules.
Set Source CIDR to 0.0.0.0/0.
Set IP Protocol to TCP.
Set Destination Port Range to 80.
Click Add Ingress Rules.

What does this security rule do?

This ingress rule allows any IP address on the internet (0.0.0.0/0) to send TCP traffic to port 80 on resources in this subnet. This is necessary so public users can reach your load balancer over HTTP.

Verify your setup by checking the subnet list on your VCN details page. You should see three subnets: the original public subnet (for compute instances), the private subnet, and your new load balancer subnet.

Don't see three subnets?

Make sure you are viewing the correct compartment in the left navigation pane. If the load balancer subnet is not listed, go back to Subnets and check that the subnet creation completed successfully.

If you see a CIDR overlap error, choose a different CIDR range (like 10.0.3.0/24) that does not overlap with the existing subnets.

Having trouble setting up the VCN?

Your network architecture is ready. Next up, you will launch two compute instances in the public subnet and configure them as web servers.

Provision Compute Instances and Install Web Servers

Your network is ready with properly segmented subnets and internet connectivity. Now you need actual servers to run inside that network.

In this step, you will launch two compute instances in your public subnet and configure them as web servers. Each server will display a unique page so you can later verify that the load balancer distributes traffic evenly.

In this step, get ready to:

Launch two Always Free compute instances with Oracle Linux.
Install and configure Apache HTTP Server on both instances via SSH.
Create unique web pages and open the OS firewall to allow HTTP traffic.

Launch two Always Free compute instances

A compute instance is a virtual machine running in OCI's data centers. You will create two instances using the Always Free shape so you can run web servers without any cost.

In the OCI Console, click the hamburger menu (top left).
Select Compute, then Instances.
Click Create instance.

The Create Instance wizard opens. Configure it with the following settings for your first instance:

Enter webserver-1 as the instance name.
Under Image and shape, confirm the image is set to Oracle Linux. If not, click Edit and select an Oracle Linux image.
Click Change shape. Select the VM.Standard.E2.1.Micro shape (AMD processor). This is the Always Free eligible shape.
Under Networking, select your existing VCN. For the subnet, choose your public compute subnet (the one created by the VCN Wizard).
Ensure Assign a public IPv4 address is selected. You need this to SSH in and to test the web server.
Under Add SSH keys, select Paste public keys. Paste the SSH public key content you generated in your Kali Linux VM.
Scroll down to the Oracle Cloud Agent section. Confirm that the Compute Instance Monitoring plugin is enabled. This sends performance metrics to OCI Monitoring.
Click Create.

What is the Oracle Cloud Agent?

The Oracle Cloud Agent is lightweight software that runs on your instance and manages plugins. The Compute Instance Monitoring plugin collects CPU, memory, and disk metrics and sends them to OCI's Monitoring service. You will use these metrics to set up alarms in a later step.

Wait for the instance to reach the Running state. This takes 1-2 minutes.

Now create the second instance by repeating the same process:

Click Create instance again from the Instances list page.
Enter webserver-2 as the instance name.
Use the same settings: Oracle Linux image, VM.Standard.E2.1.Micro shape, same VCN and public compute subnet, public IP assigned, same SSH public key pasted, Compute Instance Monitoring enabled.
Click Create.

Wait for both instances to show Running status. Note down the public IP address of each instance from the Instance Details page.

Instance stuck in Provisioning?

Always Free instances can only be created in your home region. If provisioning fails, verify you selected the correct region in the top-right region selector.

Also confirm you chose the VM.Standard.E2.1.Micro shape. Other shapes may not be available on the Free Tier.

Help me troubleshoot my OCI instance provisioning failure.

SSH into each instance and install Apache

With both instances running, you can connect to them from your Kali Linux VM using SSH. The default username for Oracle Linux instances is opc.

Switch to your Kali Linux VM in VirtualBox.
Open a terminal window.
Connect to your first instance by running this command:

ssh opc@[[INSTANCE1_IP="your first instance's public IP address"]]

If prompted to confirm the host fingerprint, type yes and press Enter.

You are now connected to your first instance. Install Apache HTTP Server, start the service, and enable it to start automatically on boot.

Install and start Apache by running this command:

sudo yum install -y httpd && sudo systemctl start httpd && sudo systemctl enable httpd

What does this command do?

This is three commands chained together. sudo yum install -y httpd installs the Apache HTTP Server package. sudo systemctl start httpd starts the web server immediately. sudo systemctl enable httpd ensures Apache starts automatically whenever the instance reboots.

Type exit to disconnect from the first instance.
Connect to your second instance by running:

ssh opc@[[INSTANCE2_IP="your second instance's public IP address"]]

Run the same Apache installation command on the second instance:

sudo yum install -y httpd && sudo systemctl start httpd && sudo systemctl enable httpd

Stay connected to Instance 2 for the next substep.

Connection timed out?

If SSH hangs or times out, confirm that your instance's subnet uses a route table with an internet gateway rule. Also verify the subnet's security list allows inbound TCP traffic on port 22 from 0.0.0.0/0 (this is included in the default security list created by the VCN Wizard).

Help me fix my SSH connection to an OCI compute instance.

Create unique pages and open the firewall

Each instance needs a unique web page so you can tell which server is responding when you test the load balancer. You also need to open port 80 on the instance's OS-level firewall, which is separate from OCI's network security lists.

On Instance 2 (you should still be connected), create its unique web page by running:

echo '<h1>Server 2</h1>' | sudo tee /var/www/html/index.html

Open port 80 on the OS firewall by running:

sudo firewall-cmd --permanent --add-port=80/tcp && sudo firewall-cmd --reload

Why open the firewall separately?

OCI has two layers of network security. The VCN security list controls traffic at the cloud network level. The instance's OS firewall (firewalld on Oracle Linux) controls traffic at the operating system level. Both must allow port 80 for HTTP traffic to reach Apache.

Type exit to disconnect from Instance 2.
Connect back to Instance 1:

ssh opc@[[INSTANCE1_IP="your first instance's public IP address"]]

Create the unique web page for Instance 1 by running:

echo '<h1>Server 1</h1>' | sudo tee /var/www/html/index.html

Open port 80 on the OS firewall:

sudo firewall-cmd --permanent --add-port=80/tcp && sudo firewall-cmd --reload

Type exit to disconnect from Instance 1.

Now verify both servers are accessible. Switch to your Windows browser and test each instance:

Open a new browser tab and navigate to http:// followed by your first instance's public IP address. You should see a page displaying Server 1.
Open another tab and navigate to http:// followed by your second instance's public IP address. You should see Server 2.

Page not loading in the browser?

Make sure you are using http:// (not https://) in the browser URL. Apache is not configured for HTTPS.

If the page still does not load, verify that the security list on your public compute subnet allows inbound TCP on port 80 from 0.0.0.0/0. The default security list created by the VCN Wizard may not include this rule. Add it if missing.

Help me troubleshoot why my Apache web server is not reachable in the browser.

Both web servers are live and serving unique pages. Next up, you will place a load balancer in front of them to distribute traffic and monitor their health automatically.

Configure the Load Balancer with Health Checks

Your two web servers are live and serving unique pages. Now you need a single entry point that distributes incoming traffic across both instances automatically.

A load balancer sits in front of your servers and forwards each request to a healthy backend. If one server goes down, the load balancer detects the failure and routes all traffic to the remaining healthy server. In this step, you will create an OCI Flexible Load Balancer, configure it to monitor both instances, and verify that traffic alternates between them.

In this step, get ready to:

Create a public Always Free Flexible Load Balancer in the OCI Console.
Configure a backend set with health checks to monitor your instances.
Verify traffic distribution across both web servers.

Create a public Flexible Load Balancer

The OCI load balancer creation wizard walks you through five pages: Add details, Choose backends, Configure listener, Manage logging, and Review and create. You will start with the first page to set the load balancer's visibility, shape, and subnet.

In the OCI Console, click the hamburger menu (navigation menu) in the top left.
Select Networking.
Click Load Balancers.
Click Create Load Balancer.
Select Load Balancer (the L7 application load balancer type, not Network Load Balancer).
Enter a display name for your load balancer (for example, web-lb).
Set Visibility Type to Public.
Under Bandwidth, select Flexible shapes.
Set Minimum bandwidth to 10 Mbps.
Set Maximum bandwidth to 10 Mbps.
Under Choose networking, select your VCN.
Select the load balancer subnet you created earlier (the second public subnet reserved specifically for the load balancer).
Click Next to proceed to the Choose backends page.

Why set both bandwidth values to 10 Mbps?

Setting minimum and maximum bandwidth to the same value creates a fixed-size load balancer. The Always Free tier includes one Flexible Load Balancer with minimum and maximum bandwidth set to 10 Mbps. This keeps your project at zero cost.

Why a separate subnet for the load balancer?

Oracle requires the load balancer to reside in a different subnet from application instances. This separation allows you to apply distinct security rules to the load balancer tier and the application tier independently.

Configure the backend set and health checks

A backend set groups your servers together with a traffic distribution policy and a health check policy. The load balancer uses the health check to continuously verify that each backend can serve traffic.

On the Choose backends page, you will see the backend set configuration.
Set the Load Balancing Policy to Weighted Round Robin.
Click Add Backends.
Select both of your compute instances from the list.
Confirm the port is set to 80 for each backend.
Click Add Selected Backends.

Now configure the health check settings below the backends list:

Set Protocol to HTTP.
Set Port to 80.
Set URL Path (URI) to /.
Set Interval in milliseconds to 10000 (10 seconds).
Leave the other health check defaults (timeout, retries) as they are.
Click Next to proceed to the Configure listener page.

What is Weighted Round Robin?

Weighted Round Robin distributes requests to each backend server in turn, proportional to the weight assigned to each. Since both your backends have equal weight, each server receives roughly the same amount of traffic.

The health check sends an HTTP GET request to / on port 80 every 10 seconds. If a backend fails to respond, the load balancer removes it from rotation until it recovers.

Create a listener and verify traffic distribution

A listener defines the port and protocol that the load balancer watches for incoming connections. You will create one that accepts HTTP traffic on port 80.

On the Configure listener page, enter a name for the listener (for example, http-listener).
Set Protocol to HTTP.
Set Port to 80.
Click Next to proceed to the Manage logging page.
Accept the default logging settings.
Click Submit to create the load balancer.

How long does provisioning take?

The load balancer takes a few minutes to provision. The status will show as Creating initially. Wait until it changes to Active before testing.

Wait for the load balancer's status to change to Active.
On the load balancer's details page, find its Public IP address.
Open a new browser tab and enter the load balancer's public IP address in the address bar.
Refresh the page several times.

You should see the response alternate between "Server 1" and "Server 2" with each refresh. This confirms the load balancer is distributing traffic across both backends.

Return to the load balancer details page in the OCI Console.
Click Backend Sets under Resources.
Click on your backend set name.
Verify that both backends show a health status of OK.

Not seeing alternating responses?

If you only see one server's page, your browser may be caching the response. Try a hard refresh (Ctrl+Shift+R on Windows or Cmd+Shift+R on macOS), or open an incognito window.

If you get a timeout or no response at all, confirm the load balancer subnet's security list allows inbound TCP traffic on port 80 from 0.0.0.0/0. Also verify both instances have port 80 open in their OS firewalls.

If backends show as unhealthy, check that Apache is still running on both instances. SSH into each instance and run sudo systemctl status httpd to confirm.

help me troubleshoot my OCI load balancer not distributing traffic to backends

Your load balancer is live and distributing traffic evenly across both servers. Next up, you will set up performance monitoring with alarms to get notified when your infrastructure needs attention.

Set Up Performance Monitoring and Alarms

Your load balancer is distributing traffic across both instances. But how do you know when something is going wrong before users notice?

In this step, you'll set up OCI Monitoring to watch your instances' CPU utilization and automatically send you an email when it crosses a dangerous threshold. This is how production infrastructure teams catch problems early.

In this step, get ready to:

Verify that CpuUtilization metrics are flowing from your instances.
Create a threshold alarm that triggers when CPU exceeds 80%.
Configure email notifications so you get alerted automatically.

Verify CpuUtilization metrics are appearing

The Compute Instance Monitoring plugin you enabled earlier sends performance data to OCI Monitoring every 10 seconds. Before creating an alarm, you need to confirm that metric data is actually flowing.

In the OCI Console, click the hamburger menu (three horizontal lines) in the top left.
Click Observability and Management.
Under Monitoring, click Service Metrics.
Select your compartment from the Compartment dropdown on the left side.
In the Metric Namespace dropdown, select oci_computeagent.
Look for the CpuUtilization chart. You should see metric data plotted for both of your instances.

What is the oci_computeagent namespace?

OCI organizes metrics into namespaces. The oci_computeagent namespace contains all Compute Instance metrics like CPU, memory, and disk activity. These data points are sampled every 10 seconds by the monitoring plugin.

Don't see any metrics?

Metrics can take a few minutes to appear after instance creation. Wait 3-5 minutes and refresh the page.

Make sure you selected the correct compartment. If your instances are in a different compartment, the metrics won't show up here.

Help me troubleshoot missing OCI compute metrics

Create a CpuUtilization alarm

Now that you've confirmed metrics are flowing, you'll create an alarm that fires when CPU utilization exceeds a safe threshold. This gives you early warning before performance degrades.

Click the hamburger menu in the top left.
Click Observability and Management.
Under Monitoring, click Alarm Definitions.
Click Create Alarm.

You'll now configure the alarm's metric source and threshold.

Enter a name for your alarm (for example, High-CPU-Alarm).
In the Metric namespace dropdown, select oci_computeagent.
In the Metric name dropdown, select CpuUtilization.
Set Interval to 1 minute.
Set Statistic to Mean.

Now configure the trigger threshold.

Set the operator to greater than.
Set the value to 80.
Set the Trigger delay minutes to 5.

Why a 5-minute trigger delay?

The trigger delay prevents false alarms from brief CPU spikes. The alarm only fires if the average CPU stays above 80% for a full 5 minutes. This filters out normal short-lived load bursts.

The underlying MQL expression for this alarm is CpuUtilization[1m].mean() > 80. OCI evaluates this every minute using data sampled every 10 seconds.

Configure notifications and confirm your email

An alarm without a notification destination is useless. You need to tell OCI where to send alerts when the threshold is breached.

Scroll down to the Notifications section of the Create Alarm page.
Under Destination, select Create a topic.
Enter OCI-Infra-Alerts as the topic name.
Set the subscription protocol to Email.
Enter your email address in the subscription field.
Set the Message Format to Send formatted messages.
Enable Repeat notification and set it to every 24 hours.
Click Save alarm.

What is OCI Notifications?

OCI Notifications is the messaging service that delivers alarm alerts. A topic is a channel that groups related notifications. Subscriptions define who receives messages from that topic and how (email, Slack, PagerDuty, etc.).

Now confirm your email subscription.

Open your email inbox and look for a confirmation email from Oracle Cloud.
Click the Confirm subscription link in the email.
Return to the OCI Console and navigate to your alarm. The alarm should be in OK state (since CPU is currently well below 80%).

Don't see the confirmation email?

Check your spam or junk folder. The email comes from Oracle Cloud and may be filtered automatically.

If you still don't see it, navigate to the notification topic in the OCI Console and resend the subscription confirmation.

Help me troubleshoot my OCI notification subscription

Your monitoring is live. If either instance's CPU spikes above 80% for more than 5 minutes, you'll get an email alert. Next up, you'll harden this entire architecture with Network Security Groups to lock down exactly who can talk to what.

Harden Security with Network Security Groups

Your load-balanced web application is live and monitored. However, it currently relies on the default security list, which applies broad rules to every resource in the subnet.

In this step, you will create Network Security Groups (NSGs) that provide per-resource firewall rules. NSGs let you restrict traffic so each component only accepts connections from the specific source it needs.

In this step, get ready to:

Create two Network Security Groups for your load balancer and web servers.
Configure least-privilege ingress and egress rules using inter-NSG references.
Attach NSGs to resources and remove broad default security list rules.

Create the Network Security Groups

Oracle recommends NSGs over security lists for new deployments. Security lists apply to all VNICs in a subnet, while NSGs apply to specific resources you choose. This gives you granular, workload-aligned control.

Open the navigation menu (hamburger icon) in the OCI Console.
Click Networking, then click Virtual Cloud Networks.
Click the name of your VCN to open its details page.
Under Resources on the left, click Network Security Groups.
Click Create Network Security Group.
Enter nsg-loadbalancer in the Name field.
Leave the compartment as your current compartment and click Create Network Security Group.
Skip adding rules for now (you will add them in the next substep). Click Close or navigate back.
Return to the Network Security Groups list under your VCN's Resources.
Click Create Network Security Group again.
Enter nsg-webservers in the Name field and click Create Network Security Group.
Skip adding rules for now.

Why two separate NSGs?

Separating NSGs by tier (load balancer vs. web servers) lets you write rules where one NSG references the other as a source or destination. This means your web servers only accept HTTP traffic from the load balancer NSG, not from the entire internet.

Oracle's security best practice is to create separate NSGs for each tier and restrict inter-tier communication using NSG-to-NSG references.

You should now see both nsg-loadbalancer and nsg-webservers in your VCN's Network Security Groups list.

Don't see the Create button?

Make sure you are viewing your VCN's details page, not the top-level Networking page. The Network Security Groups option appears under Resources on the VCN details page.

help me find where to create Network Security Groups in the OCI Console

Configure the NSG security rules

NSGs start completely empty. You need to add ingress and egress rules that define exactly which traffic is allowed. You will configure the load balancer NSG first, then the web server NSG.

In the Network Security Groups list, click nsg-loadbalancer to open its details.
Click Add Rules (or Add Security Rules depending on your Console version).
Add an ingress rule with these settings:

Direction: Ingress.
Source Type: CIDR.
Source CIDR: 0.0.0.0/0.
IP Protocol: TCP.
Destination Port Range: 80.
Description: Allow public HTTP traffic.

Click + Add Rule to add a second rule (egress) with these settings:

Direction: Egress.
Destination Type: Network Security Group.
Destination NSG: select nsg-webservers.
IP Protocol: TCP.
Destination Port Range: 80.
Description: Allow traffic to backend web servers.

Click Add Rules to save both rules.

What do these rules do?

The ingress rule allows anyone on the internet to reach the load balancer on port 80. The egress rule restricts the load balancer's outbound traffic so it can only forward requests to resources in the nsg-webservers group on port 80.

The egress rule uses an NSG reference instead of a CIDR. This means even if a web server's IP address changes, the rule still works because it targets the NSG membership, not a specific address.

Now configure the web server NSG.

Navigate back to the Network Security Groups list and click nsg-webservers.
Click Add Rules.
Add an ingress rule for HTTP from the load balancer:

Direction: Ingress.
Source Type: Network Security Group.
Source NSG: select nsg-loadbalancer.
IP Protocol: TCP.
Destination Port Range: 80.
Description: Allow HTTP from load balancer only.

Click + Add Rule to add an SSH ingress rule:

Direction: Ingress.
Source Type: CIDR.
Source CIDR: enter your Kali Linux VM's public IP address followed by /32 (for example, 203.0.113.50/32).
IP Protocol: TCP.
Destination Port Range: 22.
Description: Allow SSH from my IP only.

Click Add Rules to save.

Find your public IP

To find your Kali VM's public IP address, open a terminal in your Kali Linux VM and run:

curl ifconfig.me

Append /32 to the result to create a CIDR that matches only your single address.

Why restrict SSH to your IP?

Allowing SSH from 0.0.0.0/0 means anyone on the internet can attempt to connect to port 22 on your instances. Restricting to your specific IP (/32) means only your machine can SSH in. This is a core least-privilege principle.

Can't find nsg-loadbalancer in the Source NSG dropdown?

Make sure both NSGs are in the same VCN. NSG-to-NSG references only work within the same VCN. If you created the NSGs in different compartments, use the Change Compartment option in the dropdown to locate them.

help me configure NSG rules with inter-NSG references in OCI

Attach NSGs and remove broad security list rules

The NSGs are configured but not yet attached to any resources. You need to associate each NSG with the correct resource and then remove the broad 0.0.0.0/0 rules from the default security list so that traffic control passes entirely to the NSGs.

Navigate to Networking > Load Balancers.
Click your load balancer's name to open its details page.
Find the Network Security Groups section on the details page and click Edit.
Select nsg-loadbalancer from the dropdown and click Save Changes.

Now attach the web server NSG to both compute instances.

Navigate to Compute > Instances.
Click your first instance name to open its details.
Under Resources, click Attached VNICs.
Click the primary VNIC name to open its details.
Next to Network Security Groups, click Edit.
Select nsg-webservers from the dropdown and click Save Changes.
Repeat these steps for your second compute instance.

How does attaching work?

In OCI, NSGs are attached to VNICs (virtual network interface cards), not directly to instances. Each compute instance has a primary VNIC. When you attach an NSG to that VNIC, the NSG's rules govern traffic to and from that specific network interface.

Finally, remove the broad rules from the default security list to enforce NSG-only traffic control.

Navigate to Networking > Virtual Cloud Networks and click your VCN.
Under Resources, click Security Lists.
Click your default security list to open it.
Select the Ingress Rules section.
Select the checkbox next to the rule that allows TCP port 80 from 0.0.0.0/0 and click Remove.
Select the checkbox next to the rule that allows TCP port 22 from 0.0.0.0/0 and click Remove.
Confirm the removal when prompted.

Why remove the security list rules?

In OCI, effective security rules are the union of both security lists and NSGs. If you leave the broad 0.0.0.0/0 rules in the security list, your web servers would still accept traffic from anywhere, defeating the purpose of your NSG configuration.

Removing these rules ensures that only your NSGs control which traffic reaches each resource.

Verify your configuration by opening the load balancer's public IP in your browser.

Open a new browser tab and enter your load balancer's public IP address.
Refresh several times. You should still see responses alternating between "Server 1" and "Server 2".
Confirm that the load balancer's backend set still shows both servers as OK (healthy) in the OCI Console.

Load balancer not serving traffic after removing security list rules?

Check that you attached nsg-loadbalancer to the load balancer and nsg-webservers to both compute instance VNICs. If any attachment is missing, the NSG rules won't apply and traffic will be blocked.

Also verify that the egress rule on nsg-loadbalancer references nsg-webservers as the destination (not a CIDR), and that the nsg-webservers ingress rule references nsg-loadbalancer as the source.

help me debug why my load balancer stopped working after I configured NSGs

Your architecture is now hardened with Network Security Groups following Oracle's recommended least-privilege approach. Each resource only accepts traffic from the specific sources it needs, and the broad default rules are gone.

Secret mission

Simulate a Backend Failure and Document Incident Response

Your load balancer is routing traffic across two healthy backends. But what happens when one of them goes down? In this secret mission, you'll simulate a real-world backend failure, observe automatic failover in action, and document the incident like a production engineer would.

Clean Up Your Resources

All resources in this project use the OCI Always Free tier, so there are no ongoing costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

2x VM.Standard.E2.1.Micro compute instances (Always Free).
1x Flexible Load Balancer, 10 Mbps (Always Free).
1x Virtual Cloud Network with subnets, gateways, route tables, and Network Security Groups.
1x Monitoring alarm and notification topic (OCI-Infra-Alerts).
SSH key pair stored in your Kali Linux VM.

Keep everything running

No action needed. Choose this if you are still actively building or want to practice ongoing OCI administration.

All resources are Always Free and remain available indefinitely at no cost.
Your OCI Free Tier account stays active with no expiration on Always Free resources.
Your SSH key pair remains in your Kali Linux VM for future SSH sessions.

Pause - I'll come back to this later

OCI Always Free compute instances cannot be stopped without risk of reclamation. Keep them running or terminate and recreate them later.

Leave your compute instances running. Stopping them may cause OCI to reclaim the resources.
Your load balancer, VCN, alarm, and notification topic will remain active at no cost.
If you want to free local resources, you can close the SSH sessions in your Kali Linux VM. The key pair stays on disk for later use.

Delete - I don't want to use this again

Remove all project resources permanently. Follow these steps in order to avoid dependency errors.

Terminate both compute instances: open the navigation menu, select Compute, then Instances. For each instance, click the Actions menu (three dots) and select Terminate. Select Permanently delete the attached boot volume, then click Terminate Instance.
Delete the load balancer: open the navigation menu, select Networking, then Load Balancers. Select your load balancer, click the Actions menu, and select Terminate. Confirm the deletion.
Delete the monitoring alarm: open the navigation menu, select Observability and Management, then Monitoring, then Alarm Definitions. Select the checkbox for your alarm, click Actions, then Delete alarms. Confirm the deletion.
Delete the notification topic: open the navigation menu, select Developer Services, then Notifications. Select your OCI-Infra-Alerts topic. Click Delete and confirm.
Delete the Network Security Groups: open the navigation menu, select Networking, then Virtual Cloud Networks. Click your VCN name. Under Resources, select Network Security Groups. Delete nsg-webservers and nsg-loadbalancer individually using the Actions menu.
Delete the VCN and all remaining networking resources: on the VCN details page, click Delete at the top of the page. In the dialog, leave Search compartments for resources associated with this VCN selected and click Scan. Once the scan completes, click Delete All to remove subnets, route tables, security lists, gateways, and the VCN itself.
Delete your SSH key pair from Kali Linux by running this command in the Kali terminal:

rm -f ~/.ssh/id_rsa ~/.ssh/id_rsa.pub

What about my OCI account?

Your OCI Free Tier account has no recurring charges for Always Free resources. You can leave it active for future projects at no cost.

Nice Work!

You just deployed a production-style, highly available web application on Oracle Cloud Infrastructure. Two web servers, a load balancer, monitoring, and security hardening, all running on the Always Free tier.

You've learned how to:

Design and deploy a Virtual Cloud Network with public and private subnets, internet gateways, and route tables for proper network segmentation.
Provision two Always Free compute instances running Apache and distribute traffic between them using a Flexible Load Balancer with health checks and a backend set.
Configure OCI Monitoring with a CpuUtilization threshold alarm and email notifications via OCI Notifications.
Secret Mission: Harden the architecture with Network Security Groups following Oracle's least-privilege recommendations, and test automatic failover by simulating a backend failure and documenting the incident response.

Ready to quiz yourself?