In this project, we’ll build a simple yet secure login system using Flask, a lightweight Python web framework, and MySQL as our database backend. The application architecture follows a best-practice AWS setup with a public-facing bastion host running the Flask app and a private EC2 instance hosting the MySQL database. This multi-tier setup simulates the foundational security design used in real-world banking applications, where sensitive data is isolated in private subnets and only accessible through controlled channels.

Our Flask application will serve a login page where users can enter their credentials, which are then validated against the user data stored in the private MySQL database. By following this project, you will learn how to:

• Set up a secure AWS environment with public and private EC2 instances.

• Install and configure MySQL in a private subnet.

• Build a Flask web app that communicates with a remote database.

• Implement basic user authentication.

• Manage security groups to control access between instances.

This project is perfect for beginners wanting to understand web application architecture, security best practices on AWS, and the basics of Flask and MySQL integration.

Tools Required

• AWS Account: To launch EC2 instances and configure networking.

• EC2 Instances: One public instance (bastion host) and one private instance.

• Amazon VPC: With public and private subnets configured.

• Python 3: Installed on the public EC2 instance.

• Flask: Python web framework for building the login application.

• MySQL Server: Installed on the private EC2 instance to store user credentials.

• MySQL Client: For managing the MySQL database from command line.

• PyMySQL: Python package to enable Flask to connect to MySQL.

• Security Groups: Configured to allow traffic between the public and private instances securely.

• Basic Command Line Tools: ssh, apt-get, and text editors like nano or vim.

Setting Up the Bastion Host Infrastructure

To build a secure multi-tier architecture on AWS, we start by creating a custom VPC with separate public and private subnets. This setup ensures your database server remains isolated and accessible only through the bastion host.

Step 1: Create a Custom VPC

• In the AWS Console, navigate to VPC and select Create VPC.

• Define an IPv4 CIDR block (e.g., 10.0.0.0/16) and give it a meaningful name (e.g., MyCustomVPC).

Step 2: Create Subnets

• Create two subnets within your VPC:

  • Public subnet (e.g., 10.0.1.0/24) where the bastion host will reside.

  • Private subnet (e.g., 10.0.2.0/24) where the database server will reside.

Step 3: Create and Attach an Internet Gateway (IGW)

• Create an Internet Gateway and attach it to your custom VPC.

• This allows instances in the public subnet to access the internet.

Step 4: Create Route Tables and Associate Subnets

• Create a Public Route Table:

  • Add a route with destination 0.0.0.0/0 and target as the Internet Gateway (IGW).

  • Associate the public subnet with this route table.

• Create a Private Route Table:

  • Initially, it will have no routes to IGW, keeping the subnet private.

Step 5: Set Up NAT Gateway for Private Subnet Internet Access

• Allocate an Elastic IP address for the NAT Gateway.

• Create a NAT Gateway in the public subnet, assigning the Elastic IP.

• Update the Private Route Table:

  • Add a route with destination 0.0.0.0/0 and target as the NAT Gateway.

  • Associate the private subnet with this private route table.

Step 6: Launch EC2 Instances

• Launch a public EC2 instance (bastion host) in the public subnet with a public IP.

• Launch a private EC2 instance (database server) in the private subnet without a public IP.

Step 7: Configure Security Groups

• Public instance SG: Allow inbound SSH (port 22) from your IP and inbound HTTP (port 80) or Flask app port (e.g., 5000) from anywhere or your IP.

• Private instance SG: Allow inbound MySQL (port 3306) only from the security group of the public instance.

This completes your foundational AWS networking setup for a secure bastion host environment. The bastion host in the public subnet can communicate with the private database server securely, while the database remains inaccessible from the internet.

I have logged into my AWS account. Let us begin building

Let's go ahead and create a custom virtual private network (VPC) and name it "Indian Bank VPC." In the search bar at the top, type "VPC" and select it.

Click on create VPC button

Creating the VPC for the Indian Bank Infrastructure

To begin building our secure cloud environment, the first step is to create a custom Virtual Private Cloud (VPC). This VPC will act as the isolated network in which all our AWS resources — including EC2 instances and subnets — will reside.

VPC Configuration

• VPC Name: Indian Bank VPC

• IPv4 CIDR Block: 11.0.0.0/16
  This provides a large address space of 65,536 IP addresses, allowing ample room for subnetting and future scalability.

• Tenancy: Default
  We are using the default tenancy, which means EC2 instances will run on shared hardware. This is cost-effective and perfectly suitable for development and testing environments.

• Tags:
  Always apply meaningful tags when creating AWS resources. Tags improve the management, organization, and identification of resources, especially in projects involving multiple components. For example:

  • Key: Name

  • Value: Indian-Bank-VPC

Why a Custom VPC?

Using a custom VPC allows for complete control over networking — including IP ranges, subnet placement, routing, and internet access. It’s a foundational best practice when building secure and scalable cloud applications.

With the VPC now created, the next step is to define public and private subnets to organize the network infrastructure for the bastion host and database server.

For the Indian Bank VPC, I chose the CIDR block 11.0.0.0/16. This gives me a total of 65,536 IP addresses, which is more than sufficient for a project of this scale. It allows for the creation of up to 256 /24 subnets, each with 251 usable IPs after AWS reservations.

Click on create VPC button

Creating Subnets in the Indian Bank VPC (Region: us-east-1)

After creating your custom VPC, the next step is to define subnets to logically separate public-facing and internal resources. In this setup, we will create:

• A public subnet for the bastion host (Flask app server).

• A private subnet for the MySQL database.

By default, subnets in AWS are private unless you explicitly configure them to route through an Internet Gateway.

🔧 Step 1: Create Two Subnets

Go to VPC Dashboard → Subnets → Create Subnet and configure:

Subnet 1: Public Subnet

• Name tag: IndianBank-Public-Subnet

• VPC: Indian Bank VPC

• Availability Zone: us-east-1a (or any AZ of your choice in us-east-1)

• IPv4 CIDR block: 11.0.1.0/24

Subnet 2: Private Subnet

• Name tag: IndianBank-Private-Subnet

• VPC: Indian Bank VPC

• Availability Zone: us-east-1b (for high availability)

• IPv4 CIDR block: 11.0.2.0/24

Click Create Subnet to finish.

⚠️ Reminder: Subnets Are Private by Default

Without routing configuration, subnets can’t access the internet. Even if you launch an EC2 instance with a public IP, it won't work until you:

• Attach an Internet Gateway (IGW) to the VPC.

• Associate a route table with a route pointing to the IGW.

🌐 Step 2: Convert the Public Subnet to Truly Public

1. Create and Attach an Internet Gateway (IGW)

• Go to VPC Dashboard → Internet Gateways → Create Internet Gateway

• Name tag: IndianBank-IGW

• Create and attach it to Indian Bank VPC

2. Create Public Route Table

• Go to Route Tables → Create Route Table

• Name tag: IndianBank-Public-RT

• VPC: Indian Bank VPC

• Create the route table.

3. Edit Routes

• Click into the route table → Routes → Edit routes

• Add:

  • Destination: 0.0.0.0/0

  • Target: Internet Gateway (IndianBank-IGW)

4. Associate Route Table with Public Subnet

• Go to the Subnet Associations tab

• Click Edit subnet associations

• Select IndianBank-Public-Subnet and save.

✅ Your public subnet is now truly public. EC2 instances launched here with auto-assign public IP enabled can access the internet.

Click on create subnet button

To calculate the IPv4 subnet CIDR block, I will use a tool called the site IPv4 subnet calculator. Here is the link for your reference.

https://www.site24x7.com/tools/ipv4-subnetcalculator.html

Subnet Planning and CIDR Allocation

In this project, we begin by defining a custom IPv4 CIDR block during the creation of our VPC. For the Indian Bank VPC, we chose:

• CIDR Block: 11.0.0.0/16

This provides 65,536 total IP addresses (from 11.0.0.0 to 11.0.255.255), which we can divide into smaller subnets as needed.

📌 Subnet Allocation for the Project

For this project, we decided to create 16 subnets to simulate a scalable, production-like environment. You can select the number of subnets directly in the AWS VPC wizard:

• Number of subnets: 16

• CIDR Notation Enabled: ✅ (check the box to view or customize each subnet's CIDR)

This setup automatically splits your /16 block into 16 smaller /20 subnets, each providing 4,096 IP addresses.

🔐 Reserved IP Addresses in Each Subnet

Within each subnet, AWS reserves 5 IP addresses that cannot be used:

Click on add new subnet button

Creating the Private Subnet: private-subnet-1b

After setting up the public subnet, the next step is to create a private subnet where the MySQL database server will reside. This subnet will be isolated from direct internet access, ensuring that sensitive components remain protected within the network.

📌 Step-by-Step: Create private-subnet-1b

1. Go to the VPC Dashboard → Subnets → Create Subnet.

2. Fill in the following details:

   • Name tag: private-subnet-1b

   • VPC ID: Select your custom VPC (Indian Bank VPC)

   • Availability Zone: Select us-east-1b (to spread across AZs for high availability)

   • IPv4 CIDR block:
     Use a non-overlapping subnet from your CIDR range (e.g., 11.0.2.0/24)
     You can find this using a subnet calculator

3. ✅ This will provide 256 IP addresses, with 251 usable (after AWS reserves 5 IPs).

4. Click Create Subnet.

🔒 Why a Private Subnet?

This subnet is intended for backend services such as a MySQL database, which should not be accessible directly from the internet. Instead, access is restricted to internal traffic — for example, only from the bastion host in the public subnet.

🔢 Example of Reserved IPs (for 11.0.2.0/24)

CIDR Notation Field – Quick Note:

The CIDR notation field helps define the IP range of your subnet and automatically calculates the host IDs — the usable IP addresses for your resources. For example, a subnet like 11.0.2.0/24 gives you 256 IPs, out of which 251 are usable, as AWS reserves 5 IPs for networking functions (router, DNS, etc.). This field is essential for proper subnet planning and resource allocation.

Click on create subnet button

Click on save button

🔧 How to Convert a Subnet into a Public Subnet in AWS

By default, all newly created subnets in AWS are private — they do not assign public IPs to EC2 instances. To make a subnet public, you must enable auto-assign public IPv4 addresses.

Here are the steps to convert a specific subnet into a public one:

✅ Step-by-Step Instructions:

1. Go to the AWS Management Console
   Navigate to the VPC Dashboard.

2. Click on Subnets
   In the left-hand menu, choose Subnets.

3. Select the Subnet to Convert
   Find the subnet you want to make public — for example:
   IndianBank-Public-Subnet (11.0.1.0/24)
   Click the checkbox next to it.

4. Click on the “Actions” Button
   At the top of the Subnets table, click Actions → select Edit subnet settings.

5. Enable Auto-Assign Public IPv4 Address
   In the configuration panel, check the box:
   ✅ Enable auto-assign public IPv4 address

6. Click Save Changes
   This will apply the new setting immediately.

7. Verify the Setting

   • Scroll down to the Subnet details panel.

   • Under Auto-assign public IPv4 address, it should now say: Yes

Click on create internet gateway button

Provide the name for your Internet Gateway. Tags will be assigned automatically by AWS. Click on the create Internet gateway button.

It is in a detached state, as you can see in the above screenshot. We now need to attach this IGW to our custom VPC.

Click on the Actions button → Select the Attach to a VPC option.

Choose your custom VPC from the drop-down menu provided. Click on the "Attach Internet Gateway" button.

Now, click on "Route Tables" on the left side.

Note: When you create a custom VPC, AWS automatically creates a default route table for it. This route table:

• Has no name tag (you'll often see it as - under the Name column)

• Is automatically associated with all subnets unless you manually associate them with a different route table

• Is completely usable and editable — you can rename it, add routes, or leave it as is

Configuring the Public Route Table for Internet Access

Once your VPC and subnets are created, the next crucial step is to configure a route table to enable internet connectivity for your public subnet. AWS automatically creates a default route table when you create a custom VPC, but it often lacks a descriptive name and proper routes. We will rename this route table and configure it to serve as the public route table for our project.

Step 1: Rename the Default Route Table

1. Navigate to the AWS VPC Console and click on Route Tables in the left-hand menu.

2. Locate the default route table created by AWS for your VPC. This table might appear without a name or be shown as “-” in the Name column.

3. Select this route table and click the Actions menu or directly edit the tags.

4. Add a new Name tag with the value:

   This helps clearly identify the route table’s purpose within your infrastructure.

Step 2: Add a Route to the Internet Gateway (IGW)

1. With the public-route-table selected, switch to the Routes tab.

2. Click on the Edit routes button to modify the routing rules.

3. Click Add route to define a new route.

4. In the Destination field, enter:

5.  0.0.0.0/0
   

1. This route signifies that all IPv4 traffic destined for external networks (the internet) should be routed accordingly.

2. In the Target field, select your Internet Gateway from the dropdown menu, which should be labeled something like Indian Bank IGW.

3. After confirming the details, click Save routes to apply the changes.

Step 3: Associate the Public Subnet with the Public Route Table

1. Navigate to the Subnet Associations tab within the same route table view.

2. Click Edit subnet associations to manage which subnets use this route table.

3. From the list of available subnets, select your public subnet — in this case, public-subnet-1a.

4. Click Save associations to finalize the linkage.

Outcome

By completing these steps, you have effectively:

• Renamed your default route table to public-route-table for clarity.

• Added a route that directs all internet-bound traffic (0.0.0.0/0) through your VPC’s Internet Gateway (Indian Bank IGW).

• Associated the public-subnet-1a with this route table, thereby designating it as a public subnet.

Instances launched within this subnet will now be able to communicate with the internet, provided that their security groups and network ACLs allow the required traffic.

Here is what the resource map looks like so far:

Now, we will create two security groups: one for the public EC2 instance, which acts as the bank web application server, and another for the private EC2 instance, which acts as the database server.

Click on create security group

Click on create security group button

Creating a Security Group for Public Instances

To securely manage inbound and outbound traffic for your public EC2 instances, you need to create a dedicated security group. This acts as a virtual firewall controlling the traffic allowed to and from your instances.

Step 1: Define the Security Group

1. In the AWS Management Console, navigate to the VPC service.

2. From the left-hand menu, click on Security Groups.

3. Click the Create security group button to start the process.

4. Provide the following details:

   • Security group name:
     Indian-Bank-Public-Instances-SG
     (This name clearly indicates that this security group is for public-facing instances in the Indian Bank project.)

   • Description:
     Security group for public EC2 instances allowing SSH and HTTP access
     (A descriptive note that helps clarify the purpose of this security group for future reference.)

   • VPC:
     Select your custom VPC, Indian-Bank-VPC, from the dropdown menu to ensure the security group is associated with the correct network.

Step 2: Configure Inbound Rules

You will now define rules to permit inbound traffic essential for managing and accessing your public instances:

• Inbound Rule 1: SSH Access

  • Type: SSH

  • Protocol: TCP

  • Port Range: 22

  • Source: Anywhere (IPv4)

  • Source CIDR: 0.0.0.0/0
    (Allows SSH access from any IPv4 address — useful for remote management via terminal.)

• Inbound Rule 2: HTTP Access

  • Type: HTTP

  • Protocol: TCP

  • Port Range: 80

  • Source: Anywhere (IPv4)

  • Source CIDR: 0.0.0.0/0
    (Allows web traffic to your Flask application or any web server running on port 80.)

Step 3: Leave Outbound Rules as Default

By default, security groups in AWS are stateful, meaning that outbound traffic is automatically allowed in response to inbound traffic. Hence, you can safely leave the outbound rule set as default, which allows all outbound traffic.

Step 4: Add Tags for Identification

Adding tags helps in organizing and managing your AWS resources efficiently:

• Click on Add tag

• Add key-value pairs such as:

  • Key: Project

  • Value: Indian-Bank

  • Key: Environment

  • Value: Production (or Development as applicable)

Step 5: Create the Security Group

• Once all the above configurations are done, click the Create security group button.

Outcome

You have now created a security group named Indian-Bank-Public-Instances-SG that allows secure SSH access from anywhere and serves web traffic on HTTP port 80. This security group will be attached to your public EC2 instances to control their network access securely.

Click on create security group button

Click on create security group button

Creating a Security Group for the Private Database Instance

To secure your private database instance while allowing controlled access only from your public instances, you need to create a dedicated security group with specific inbound rules.

Step 1: Define the Security Group

1. In the AWS Management Console, navigate to the VPC service.

2. Click on Security Groups in the left-hand menu.

3. Click the Create security group button.

4. Provide the following details:

   • Security group name:
     Indian-Bank-Private-Database-Instance-SG
     (Clearly identifies this security group for private database instances.)

   • Description:
     Allows SSH and MySQL traffic only from public instances security group
     (Clarifies that this group restricts access exclusively to public instance sources.)

   • VPC:
     Select your custom VPC: Indian-Bank-VPC.

Step 2: Configure Inbound Rules

Add two inbound rules that limit access strictly to your public instance security group:

• Inbound Rule 1: SSH Access from Public Instances

  • Type: SSH

  • Protocol: TCP

  • Port Range: 22

  • Source: Custom

  • Source security group: Indian-Bank-Public-Instances-SG
    (Allows SSH access only from instances associated with the public instances security group.)

• Inbound Rule 2: MySQL Access from Public Instances

  • Type: Custom TCP

  • Protocol: TCP

  • Port Range: 3306

  • Source: Custom

  • Source security group: Indian-Bank-Public-Instances-SG
    (Allows MySQL database connections exclusively from the public instances security group.)

Step 3: Leave Outbound Rules as Default

The outbound rules should remain unchanged. Since AWS security groups are stateful, responses to allowed inbound traffic will automatically be permitted outbound.

Step 4: Add Tags for Easy Identification

To manage your AWS resources effectively, add relevant tags such as:

• Key: Project

• Value: Indian-Bank

• Key: Environment

• Value: Production (or Development as applicable)

Step 5: Create the Security Group

After verifying all the settings, click the Create security group button.

Outcome

This security group, Indian-Bank-Private-Database-Instance-SG, tightly controls access to your private database instance by allowing only SSH and MySQL traffic originating from your public EC2 instances. This setup enhances security by preventing unwanted external access to your database server.

Search for EC2 in the search bar and click on it.

Launching EC2 Instances in Public and Private Subnets

Step 1: Create a Key Pair Named "EC2-KP-27-AUG.pem"

Before launching your EC2 instances, you need a key pair to securely SSH into them.

1. In the AWS Management Console, navigate to the EC2 Dashboard.

2. On the left sidebar, click Key Pairs under Network & Security.

3. Click the Create Key Pair button.

4. Provide the following details:

   • Key pair name: EC2-KP-27-AUG

   • Key pair type: RSA (default)

   • Private key file format: .pem (for Linux/Mac/Unix or Windows with WSL)

5. Click Create Key Pair.

6. The private key file named EC2-KP-27-AUG.pem will automatically download to your local machine.

7. Important: Store this file securely. Set the correct permissions using:

8.  chmod 400 EC2-KP-27-AUG.pem
   

This key will be required to SSH into your instances.

Step 2: Launch the Public EC2 Instance (Bastion Host / Flask App Server)

1. Go to the EC2 Dashboard and click Launch Instance.

2. Choose your preferred AMI (Amazon Linux 2 or Ubuntu).

3. Select an Instance Type like t2.micro (free tier eligible).

4. Under Configure Instance Details:

   • Network: Select Indian-Bank-VPC.

   • Subnet: Choose the public subnet (1a).

   • Auto-assign Public IP: Enable this so the instance gets a public IP.

5. Add storage as needed.

6. Add tags such as:

   • Name: Indian-Bank-Public-Instance

   • Project: Indian-Bank

7. In Configure Security Group, select the existing security group Indian-Bank-Public-Instances-SG.

8. On the Review and Launch page, select the key pair named EC2-KP-27-AUG from the dropdown under "Key pair".

9. Launch the instance.

Step 3: Launch the Private EC2 Instance (MySQL Database Server)

1. Click Launch Instance again in the EC2 Dashboard.

2. Choose the same or appropriate AMI.

3. Select the instance type (e.g., t2.micro).

4. Configure instance details:

   • Network: Indian-Bank-VPC

   • Subnet: Choose the private subnet (1b)

   • Auto-assign Public IP: Disable this (keep instance private).

5. Add tags such as:

   • Name: Indian-Bank-Private-Database-Instance

   • Project: Indian-Bank

6. Select the security group Indian-Bank-Private-Database-Instance-SG.

7. On the Review and Launch page, select the key pair EC2-KP-27-AUG.

8. Launch the instance.

Summary

• You now have a key pair EC2-KP-27-AUG.pem that you will use to securely access your instances.

• Your public instance will be reachable via the internet.

• Your private instance will remain isolated, accessible only through your public instance (bastion host).

Click on create key pair button

Provide the key pair name, set the key pair type to RSA, and choose the private key pair file format as .pem since we are using Linux OS. Add tags for easier identification and management of your AWS resources. Click on "Create key pair."

Back to EC2 instances

Click the "Launch Instances" button.

Provide the name of your public EC2 instance. Select the AMI as “Ubuntu”.

Select the instance type as “t2.micro” for this project. Select your key pair as well “EC2-KP-27-AUG.pem”.

Select your custom VPC “Indian-Bank-VPC”, Select your public -subnet-1a, Choose your existing “Indian-Bank-Public-Instances-SG” security group.

Leave the storage configuration to default settings.

Click on “Launch Instances” button

Let's repeat the same steps to create a private EC2 database instance.

Provide the name of your EC2 instance as “private-EC2-database-instance.” Next, choose the AMI as “Ubuntu.”

Select the instance type as “t2.micro” and choose the key pair as “EC2-KP-27-AUG.pem”.

Click on "Edit VPC Configuration." Select your custom VPC, "Indian-Bank-VPC." Choose your subnet, "private-subnet-1b." Select the existing security group, "Indian-Bank-Private-Database-instance-SG." Leave the storage configurations at the default settings.

Click on the "Launch Instance" button.

Let's set up an internet connection for our private EC2 database instance using a NAT gateway.

Note: The NAT gateway uses an elastic IP, which is not available under the free tier. Caution: You will incur charges. After the project demonstration, remember to disconnect the elastic IP from the NAT gateway.

On the left-hand side, select "NAT Gateway."

But before that, let's create an elastic IP first. It's easier to attach it during the creation of the NAT gateway.

Click on “allocate elastic IP” button

In this configuration, you only need to provide the tags. Click on the “Allocate” button.

Now, back to your NAT gateway page

Click on “Create NAT gateway” button

In this configuration tab, enter the name of your NAT gateway as “Indian-Bank-NAT-GW” and choose your public subnet, "public-subnet-1a."

Note: NAT gateways must be deployed in the public subnet only.

Select your recently created elastic IP from the dropdown menu. Add tags for easier identification and management of your AWS resources.

Click on the “Create NAT gateway” button.

Done.

Let's create a private route table for my private-subnet-1b.

Click on “create route table” button

Provide the name for your private route table, select your custom VPC - “Indian-Bank-VPC,” and add tags for easier identification and management of your AWS resources.

Click on the “Create route table” button.

Click on routes tab → Select “edit routes” button

Provide the destination as 0.0.0.0/0 and set the target as the NAT gateway. Select your NAT gateway (Indian-Bank-NAT-GW) from the list below.

Click on "Save changes."

In the subnet associations tab, click on the “Edit Subnet Association” button.

Choose your private subnets (private-subnet-1b). Click on the “Save associations” button.

Done

Now, let's give read-only permissions to the key-pair in the downloads folder. Open the terminal and navigate to your key-pair.pem file (for example, EC2-KP-27-AUG.pem in my case).

Use this command to set read-only permissions for the user only.

sudo chmod 400 EC2-KP-27-AUG.pem

I have successfully set read-only permissions for the user, with no permissions for the group or others.

Let's use the scp command to upload your key-pair.pem file from my local machine to my public-EC2-web-app-instance. Access your public-EC2-web-app-instance via SSH, and then use the scp command to upload your key-pair.pem file to your private-EC2-database-instance. Perform ping operations to check if the internet connection is configured properly.

Perform SCP upload of key-pair.pem file from local machine to your public-EC2-instance.

SCP command

scp -i EC2-KP-27-AUG.pem EC2-KP-27-AUG.pem ubuntu@44.223.103.94:/home/ubuntu

Upload of key-pair.pem file successful

Perform SSH login using the command

ssh -i "EC2-KP-27-AUG.pem" ubuntu@44.223.103.94

SSH login successful

pwd
ls -l

As you can see, the key-pair.pem file is located in /home/ubuntu.

Use the “ls -l” command to display the files and folders in the current directory with detailed information.

Before running the SCP command again, perform a ping operation.

ping -c 10 www.google.com
or 
ping www.google.com

Internet connection is working

Now, use the scp command to transfer files from your public EC2 web app instance to your private EC2 database instance.

SCP command

scp -i EC2-KP-27-AUG.pem EC2-KP-27-AUG.pem ubuntu@11.0.104.42:/home/ubuntu

Copy the private IP address of your private-EC2-database-instance.

As we are in the public-EC2-web-app-instance, let us update the system, download python3, and flask application package using the following commands.

nano install-setup.bash

Paste the following installation code within the script. Save and exit

#!/bin/bash

# Update system
sudo apt update && sudo apt upgrade -y

# Install Python3 and pip
sudo apt install python3 python3-pip -y

# Install Flask and PyMySQL
pip3 install flask pymysql

# Confirm installations
echo "Python version:"
python3 --version

echo "Pip version:"
pip3 --version

echo "Installed Flask version:"
python3 -m flask --version

echo "Setup completed successfully."

Give executable permissions to the script file.

sudo chmod 770 install-setup.bash

# To save
ctrl + s

# To exit
ctrl + x

python3 --version
pip3 --version

The packages have been successfully installed

sudo apt install python3-flask -y

Verify if the installation was successful.

python3 -m flask --version

Yes, Python Flask has been successfully installed.

Now, perform the SCP operation.

SCP command

scp -i EC2-KP-27-AUG.pem EC2-KP-27-AUG.pem ubuntu@11.0.104.42:/home/ubuntu

Done, the key-pair.pem file (EC2-KP-27-AUG.pem) has been successfully uploaded to the private-EC2-database-instance.

Now, let's perform an SSH login.

ssh -i "EC2-KP-27-AUG.pem" ubuntu@11.0.104.42

SSH login successful

Now let us update the system

sudo apt update -y && sudo apt upgrade -y

Let's check if the key-pair.pem file is present.

pwd
ls -l

Upload was done right

Once the upgrade completes, you can proceed to:

1. Install MySQL Server (since this is your DB server):

2.  sudo apt install mysql-server -y
   

Start and enable MySQL service:

sudo systemctl start mysql
sudo systemctl enable mysql

The MySQL service is active and running successfully.

Step-by-Step: Set Up MySQL for Flask Login

Run the following commands inside your private EC2 instance:

1. Log in to MySQL as root

sudo mysql

2. Create the database

CREATE DATABASE flaskdb;

3. Use the database

USE flaskdb;

4. Create the users table

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) NOT NULL,
    password VARCHAR(50) NOT NULL
);

5. Insert default login credentials

INSERT INTO users (username, password) VALUES ('admin', 'admin');

6. Create a MySQL user named admin with password admin

CREATE USER 'admin'@'%' IDENTIFIED BY 'admin';

The % allows access from any IP — safe here because your security group limits access to only the public EC2 instance.

7. Grant all privileges on flaskdb to admin

GRANT ALL PRIVILEGES ON flaskdb.* TO 'admin'@'%';
FLUSH PRIVILEGES;

8. Exit MySQL

EXIT;

# To end SSH session
exit

Now, I am connected to my public EC2 web app instance via SSH.

Open or create your Flask app file:

nano app.py

from flask import Flask, request, render_template_string
import pymysql

app = Flask(__name__)

# Replace this with the **private IP** of your private EC2 instance
DB_HOST = "11.0.104.42"  # <-- update this if needed
DB_USER = "admin"
DB_PASSWORD = "admin"
DB_NAME = "flaskdb"

LOGIN_PAGE = '''
    <h2>Login</h2>
    <form method="POST">
        Username: <input name="username" type="text"><br>
        Password: <input name="password" type="password"><br>
        <input type="submit" value="Login">
    </form>
'''

@app.route('/', methods=['GET', 'POST'])
def login():
    if request.method == 'POST':
        uname = request.form['username']
        passwd = request.form['password']

        connection = pymysql.connect(
            host=DB_HOST,
            user=DB_USER,
            password=DB_PASSWORD,
            database=DB_NAME
        )

        with connection.cursor() as cursor:
            cursor.execute("SELECT * FROM users WHERE username=%s AND password=%s", (uname, passwd))
            result = cursor.fetchone()

        connection.close()

        if result:
            return "<h1>Welcome, admin!</h1>"
        else:
            return "<h1>Login Failed</h1>" + LOGIN_PAGE

    return LOGIN_PAGE

if __name__ == "__main__":
    app.run(host='0.0.0.0', port=80)

# To save the file
ctrl + s

# To exit the file
ctrl + x

Run the Flask app with sudo (because port 80 needs root privileges):

sudo python3 app.py

To fix this, run:

sudo apt update
sudo apt install python3-pymysql -y

After installation, try running your app again with:

sudo python3 app.py

Copy the public IP of the public EC2 web app instance and paste it into any browser of your choice.

http://44.223.103.94:80

Enter the username as "admin" and the password as "admin".

If you don’t see it or get a timeout/error, here are quick checks:

1. Security Group:
   Make sure your public EC2 instance’s security group allows inbound HTTP (port 80) from your IP (or anywhere 0.0.0.0/0 for testing).

2. Flask app running:
   Confirm the Flask app is running (you already did this).

3. Firewall on EC2:
   Check if ufw or any firewall isn’t blocking port 80.

4. Correct IP:
   Double-check you are using the public IP of the public EC2 instance, not the private IP.

Try accessing now and let me know what you see!

Note: There was a huge error. I forgot to install mysql-client package on my public-EC2-web-app instance.

Now, that I have installed it

This is what I received

Now, I will enter an incorrect username and password. Let’s see what I receive

I entered the username as "abhishek" and the password as "abhishek".

What Really Caused the Connection Refused Error?

1. AWS Security Groups:

Your security groups were configured properly. The private EC2’s security group allowed inbound MySQL traffic (port 3306) only from the public EC2’s security group — which is the best practice for limiting access. So no issue there.

2. mysql-client on Public EC2:

Installing mysql-client on the public EC2 is optional. It’s a helpful tool for manually testing MySQL connectivity from the public instance, but it is not required for your Flask app to connect programmatically via Python’s pymysql.

3. MySQL Bind Address (The Actual Culprit):

By default, MySQL listens on 127.0.0.1 (localhost) only, meaning it refuses remote connections from other instances. To enable remote access, you need to update the MySQL configuration:

• Open the private-ec2-database-instance → MySQL configuration file, typically located at:

cd /etc/mysql/mysql.conf.d/mysqld.cnf

Find the line that starts with:

bind-address = 127.0.0.1

Change it to:

bind-address = 0.0.0.0

Save the file and restart MySQL to apply changes:

sudo systemctl restart mysql

This change tells MySQL to listen on all network interfaces, including the private IP, allowing your public EC2 instance to connect.

Key Takeaway:

• Proper AWS Security Groups and MySQL configured to listen on 0.0.0.0 = successful remote connection.

• Installing mysql-client on the public EC2 is helpful for testing but not required for your Flask app to connect.

Conclusion:

Project Conclusion and Key Takeaways

This project involved deploying a Flask web application on a public EC2 instance that connects to a MySQL database hosted on a private EC2 instance within the same AWS VPC. Throughout the deployment and testing phases, several critical insights were uncovered that contributed to the successful setup and highlighted best practices for secure and functional cloud-based application architectures.

Key Takeaways:

1. Network Security and Access Control:
   Proper configuration of AWS Security Groups is fundamental. Restricting MySQL access on the private EC2 instance’s security group to allow inbound traffic only from the public EC2 instance’s security group enhances security by limiting the attack surface.

2. Database Connectivity and Configuration:
   MySQL’s default configuration binds the service to 127.0.0.1, which restricts connections to localhost only. To enable remote connections from the public EC2 instance, updating the bind-address in MySQL’s configuration file (/etc/mysql/mysql.conf.d/mysqld.cnf) to 0.0.0.0 is essential. This change allows MySQL to listen on all network interfaces within the private subnet.

3. Tooling and Testing:
   While installing the MySQL client (mysql-client) on the public EC2 instance is not mandatory for the Flask application’s operation, it is highly beneficial for manual connectivity testing and debugging. This facilitates quicker diagnosis of network and authentication issues.

4. Application Deployment Best Practices:
   Running the Flask development server on port 80 and as root can work for quick testing but is not recommended for production. For production-grade deployments, using a WSGI server such as Gunicorn or uWSGI behind a reverse proxy (e.g., Nginx) is advised.

5. Error Diagnosis and Troubleshooting:
   Connection refused errors often stem from service configuration issues rather than security group misconfigurations. A systematic approach—checking network rules, verifying service bindings, and testing connectivity—proves effective in identifying root causes.

6. The changing of the bind-address to 0.0.0.0 was done on the private EC2 instance where the MySQL server is running. This allows MySQL to listen on all network interfaces, including the private IP address accessible from your public EC2 instance.

7. The public EC2 instance was configured correctly from the start—your Flask app was set up, security groups allowed traffic, and everything was ready to communicate with the private EC2 instance.

   The root cause of the connection issue was solely on the private EC2 instance, where MySQL was bound only to localhost, blocking remote access.

   So, no changes were needed on the public EC2 side regarding connectivity or app setup.

8. Your Flask app is running on the public EC2 instance, which listens on 0.0.0.0 — meaning it accepts incoming HTTP requests from anywhere on the internet (public IP).

9. But when your Flask app connects to MySQL, the MySQL server is on the private EC2 instance inside your VPC.

10. The MySQL server’s bind-address was set to 127.0.0.1 (localhost), meaning it only accepted connections originating from itself — no remote connections allowed.

11. By changing the MySQL bind-address to 0.0.0.0 on the private EC2, it allowed the database to accept connections from other machines inside the VPC, specifically your public EC2.

12. The public EC2’s Flask app connects to MySQL over the private IP of the private EC2 (11.0.104.42), not via the public internet.

So while your Flask app listens on 0.0.0.0 to serve users from the internet, your database connection is internal inside the VPC, protected by security groups.

By adhering to these principles, the project successfully established a secure, scalable, and maintainable architecture for a cloud-hosted Flask application with a remote MySQL backend. This foundation can be extended with further enhancements such as automated deployment pipelines, database replication, and advanced security measures.

Thank you for your time.