DEV Community

True North profile image Andrea
Andrea for True North

Posted on

Inside the University Cloud: Solving Real-World Networking Challenges

#networking #aws #architecture #cloud

Overview
The university is launching a new Student Portal to give learners a seamless digital experience. Through this portal, students will be able to:

  • View grades
  • Access course materials
  • Pay tuition fees
  • Submit assignments

To support this rollout, James, the Cloud Engineer, and Sarah, the School’s Solutions Architect, were tasked with building a secure and scalable architecture on AWS — the chosen cloud provider for its reliability and customer-obsessed design.

They began by setting up the core networking environment:

  • A VPC to isolate all university resources
  • A public subnet for externally reachable components
  • A private subnet for backend application servers
  • An Internet Gateway (IGW) attached to the VPC
  • A route table to enable internet access for the public subnet
  • An EC2 instance in the private subnet hosting the student portal backend
  • NAT Gateway to Allows private servers to reach the internet without being exposed.
  • Appropriate security groups to regulate inbound and outbound traffic
  • Network ACLs (NACLs) to provide an additional layer of subnet-level security

Before finalizing the setup, James added a bastion host in the public subnet to allow secure SSH access into the private EC2 instances for administration, debugging, and deployments.

With all foundational components in place, the team prepared to launch the portal and validate that every part of the networking environment worked as intended.

The Architecture

The SetUp

Step 1: Create a New VPC

  1. Log in to the AWS Management Console using your credentials.
    Hint: Always create and use an IAM user with the necessary permissions rather than using the root account. This ensures least-privilege access and improves security.

  2. In the search bar at the top, type “VPC” and select Your VPC from the sidebar.

  3. In the VPC Dashboard, you will see a default VPC. For this lab, create a new VPC:

    • Click Create VPC.
    • Give it a name, e.g., web-portal-VPC.
    • Assign an IPv4 CIDR block of 10.0.0.0/16.
    • Hint: Use tags to label your resources — this helps organize and identify VPCs later, especially in environments with multiple resources.

  4. Leave the rest of the options as default and click Create VPC.

  5. After creation, you will see your new VPC listed in the dashboard.

Step 2: Create a Public Subnet

  1. On the VPC dashboard sidebar, click Subnets.
  2. Click Create Subnet at the top of the page.
  3. In the creation form:
    • Select the VPC you created in Step 1 webportal`-VPC. You will see its IPv4 CIDR block 10.0.0.0/16.

CIDR Calculation & Subnet Planning

- VPC CIDR: 10.0.0.0/16 → 32 is the total bits so it’s ( 32-16) =16 bits fixed, 16 bits available → 2^16 = 65,536 IP addresses.
- Subnet CIDR: 10.0.0.0/24 → 32 is the total bits so it’s ( 32-24)=24 bits fixed, 8 bits available → 2^8 = 256 IP addresses.

How to choose subnet ranges:
- Each subnet’s CIDR must be **within the VPC CIDR**.
- Plan enough IPs for all resources in that subnet (EC2s, NAT, load balancers, etc.).
- Keep future growth in mind — don’t allocate too small a range if you may add more instances later.
Enter fullscreen mode Exit fullscreen mode
  1. Name your subnet: e.g., Public-Subnet.
  2. Select an Availability Zone (AZ):
    • AWS regions (e.g., Africa (Cape Town)) contain multiple AZs — isolated data centers.
    • Hint: Using AZs improves high availability. If one AZ goes down, workloads can continue in another AZ. Imagine students all over the world hitting the portal at the same time — if only one AZ handled all traffic, it could overload. Using multiple AZs ensures the system can distribute load and remain operational even under high demand.
  3. Assign a CIDR block for the subnet: e.g., 10.0.0.0/24.
    • Hint: Subnet CIDR must be within the VPC’s CIDR. /24 gives 256 IP addresses (usable for EC2s, NAT, and other resources).
    • This allows you to plan for growth without overlapping other subnets.
  4. Leave the rest of the options as default and click Create subnet.

Step 3: Launch an EC2 Instance in the Public Subnet

Hint / Analogy for EC2 and Instance Setup:

  • EC2: Think of an EC2 instance as your server in the cloud — it’s where your application actually runs, like a web portal server. This is similar to your laptop, which runs applications locally.
  • AMI (Amazon Machine Image): The AMI is like the operating system on your laptop (e.g., Windows or Linux) along with some pre-installed software. It sets the base environment so your application can run.
  • Instance Type: This is like the hardware specification of your laptop — how much CPU, memory, and storage it has. Choosing the right instance type ensures your application performs well under expected load.

Additional Hint for Scaling:

  • This instance hosts the front-facing portal and all services in our lab. For small labs, one EC2 is enough.
  • In real-world scenarios, if thousands of students are using the portal simultaneously (e.g., during exams), you can add more EC2 instances or scale up/down dynamically to handle traffic while optimizing costs.

  1. In the AWS Management Console, use the search bar to type EC2 and select it.

  2. On the sidebar, click Instances, then click Launch Instances.

  3. Configure the instance basics:

    • Name: Web-Portal
    • AMI (Amazon Machine Image): Select an appropriate AMI, e.g., Amazon Linux 2023.

  4. Instance type: Choose a small instance like t3.micro.
    Hint: Instance type determines CPU, memory, and network capacity. For a lab web portal, a small instance is enough. In real scenarios, consider traffic load, student activity, and portal features.

  5. Key pair:

    • Create a new key pair called webportal.
    • Hint: This key allows you to SSH into your EC2 — necessary for administrative tasks, checking logs, or debugging.

  6. Networking:

    • Click Edit under Networking.
    • Select the VPC you created (Web-Portal VPC).
    • Choose the Public Subnet you created earlier.
    • Enable Auto-assign Public IP. Hint: Assigning a public IP lets the instance be accessible from the internet

  7. Security Group:

    • Create a new security group called WebPortal-SG.
    • Hint: Security groups control inbound and outbound traffic. In production, this is dynamic and carefully managed; for this lab, keep it simple.
    • Add Inbound Rule:
      • Type: SSH (22)
      • Source: My IP

Hint: This ensures only your machine can SSH into the instance.

  1. Review your configuration and click Launch Instance.

  2. After launch, the instance will appear in the Instances dashboard:

    • You can see its Status, Public IPv4, and Private IPv4 addresses.
    • Clicking the instance allows you to explore more details, like network interfaces and security groups.

Step 4: Create an Internet Gateway

  1. In the AWS Console, search for VPC and select it.
  2. On the sidebar, click Internet Gateways.
  3. Click Create Internet Gateway.
    • Name: webportal-IGW
    • Leave other settings as default.
  4. After creation, the IGW is available but not yet attached to the VPC.
  5. Select the IGW and click Attach to VPC, then choose the Lab VPC you created. Hint: Now the public subnet can send and receive traffic from the internet, allowing students to reach the portal.

Step 5: to create the route table:

  1. In the AWS Console, search for VPC and click Route Tables on the sidebar.
  2. Click Create Route Table.
    • Name: Public-RT
    • VPC: Select webportal VPC
  3. After creation, select the route table, go to the Routes tab, and click Edit routes.
    • Add a route:
      • Destination: 0.0.0.0/0 (this means all traffic to the internet)
      • Target: Lab-IGW (the internet gateway you created in Step 4)

  4. Save the route.
    Associate the Route Table with the Public Subnet:

  5. Go to the Subnet Associations tab of the route table.

  6. Click Edit subnet associations.

  7. Select the public subnet you created in Step 2 and save.

Hint:

  • Now your public subnet knows that all internet-bound traffic should go through the IGW.
  • This completes the path for students to reach the portal: browser → ALB (or EC2) → public subnet → IGW → internet.

The Progress so far

Understanding the Flow: Public Subnet and Internet Gateway

How traffic flows for the student portal:

  1. A student opens a browser and searches for portal.com (our student portal).
  2. The DNS resolves portal.com to an AWS resource. In a production setup, this would be the ALB (Application Load Balancer) DNS name, e.g., aws-1234fe-alb.amazonaws.com.
  3. The ALB receives the request and forwards it to one of the EC2 instances in the public subnet.
    • At this stage, the request has already reached the EC2 via the internet and IGW; the subnet’s route table is not involved for incoming traffic.
    • Note: A subnet is not public until an Internet Gateway (IGW) is attached and the route table sends traffic to it.
  4. Internet Gateway (IGW) ensures that EC2 in the public subnet can communicate with the internet. Incoming requests from students are received via the IGW.
  5. Outbound traffic / responses:
    • When the EC2 instance responds to the student’s browser, the route table associated with the subnet checks the destination (the student’s public IP) and directs the response through the IGW.
    • Without the route table pointing 0.0.0.0/0 to the IGW, responses wouldn’t reach the internet.
  6. This completes the round-trip: Student browser → ALB → EC2 → public subnet → IGW → student browser.

Hint:

  • Route tables primarily control where traffic leaving the subnet goes, and for incoming using the local route
  • The IGW + route table combination makes a subnet “public”, meaning its instances can respond to internet requests.

Hint:

  • Public subnet + IGW = internet-facing resources.

Server Side Setup

Kindly note: On the server-side (private subnet) you won’t see UI screenshots here. The setup steps are mostly the same as the public-side resources, with only a few key differences we’ve already highlighted. Keep reading through — everything follows the same pattern.

Step 6: Creating a Private Subnet, NAT Gateway, and EC2 for Backend Services

Now that the student-facing application is running on a public subnet, we need to handle backend services that should not be publicly accessible, such as the grading system or other sensitive components of the student portal. These services must remain private to prevent direct access from the internet.

1. Create a Private Subnet

  1. Go to the VPC dashboard in the AWS console.
  2. On the sidebar, click Subnets → Create Subnet.
  3. Select the VPC you created earlier (Web portal VPC).
  4. Name the subnet Private Subnet.
  5. Choose an Availability Zone (AZ). Hint: Using AZs improves high availability—if one AZ goes down or is overloaded, workloads continue in another AZ. For example, if many students hit the portal simultaneously, multi-AZ ensures traffic is distributed.
  6. Assign a CIDR block that:
    • Falls within your VPC range (10.0.0.0/16).
    • Does not overlap with the public subnet.(10.0.0.0/23).
    • Leaves space for growth (e.g., if you anticipate 254 addresses, choose /25 or /23 depending on needs).

2. Create a NAT Gateway

  1. In the sidebar, click NAT Gateways → Create NAT Gateway.
  2. Select the public subnet for the NAT Gateway. Hint: NAT must live in a public subnet to access the internet.
  3. Assign an Elastic IP (EIP). Hint: EIP ensures a stable public IP so that outbound requests from the private subnet appear consistent to the internet (unlike auto-assigned public IPs that can change).
  4. Click Create NAT Gateway.

3. Route Table for the Private Subnet

  1. Go to Route Tables → Create Route Table → name it Private Subnet RT.
  2. Associate this route table with the Private Subnet.
  3. Add a route:
    • Destination: 0.0.0.0/0
    • Target: NAT Gateway
    • then asscosite it with the private subnet
    • Hint: This ensures outbound internet traffic from the private EC2 (e.g., to download updates or call external APIs) passes through the NAT, keeping the EC2 private from inbound internet traffic.

4. Launch an EC2 in the Private Subnet

  1. Go to EC2 → Instances → Launch Instances.
  2. Name it Server-Portal.
  3. Select an AMI (OS) suitable for backend services. Hint: Like before, AMI is the operating system your EC2 will run.
  4. Choose an Instance Type based on expected workload (CPU, memory). Hint: For backend tasks, adjust based on load (grading computations may require more memory/CPU).
  5. Select the Private Subnet for networking.
  6. Assign a security group allowing necessary ports for internal communication (SSH from bastion, application ports from public EC2, etc.).

THE PROBLEM

A few hours after releasing exam results, the university’s IT team started receiving complaints:

“My grades are not appearing on the portal.”
“The page keeps loading forever.”

CloudWatch showed increased errors, but the logs were not detailed enough to reveal the root cause.
So the backend engineering team decided to SSH into the private application server (through the bastion host) to investigate.

THE SOLUTION

So far we have created 2 ec2s try this one alone here are a few instrctions:

Step 7: Create the Bastion Host
The Bastion Host is simply another EC2 instance that acts as a secure jump server to access private resources.

  1. Subnet Placement: Launch it in the public subnet so it can receive SSH connections from your local machine.
  2. Security Group: Create a Bastion-SG that allows inbound SSH (port 22) from your IP only.
    • Note: In production, bastion security groups are more restrictive and often integrated with multi-factor authentication or other controls. For the lab, we keep it simple.
  3. EC2 Setup: Choose an AMI and instance type similar to other EC2s. Assign the public IP automatically so you can SSH into it.

DONE🎉

Step 8: SSH into Bastion and Access Private EC2

With the Bastion Host in place, the team could investigate the issue on the private EC2 instance hosting the backend services.

  1. SSH into Bastion Host:

    • On Git Bash (Linux terminal), use:

      ssh -A -i ec2-user@

This connects your local machine securely to the bastion host in the public subnet.

  1. Prepare Access to Private EC2:
    • Go to the private EC2 instance (“Server Portal”) and update its security group to allow inbound SSH from the Bastion-SG.
    • This ensures the bastion host can reach the private EC2, while the private EC2 remains inaccessible from the internet.

  2. SSH to Private EC2 via Agent Forwarding:

    ssh ec2-user@

This gives secure access without exposing the private key on the bastion host.

  1. Investigate and Solve the Issue:
    • Inside the private EC2, the team discovered:
      • The grade-processing service had crashed.
      • A Python script syncing grades had a file permissions error.
      • A critical directory had incorrect Linux permissions after a deployment.
    • These issues could not be resolved from CloudWatch or the AWS console — direct server access was required.
  2. Outcome:
    • The backend services were fixed, and students experienced fast, reliable portal access again.

ADD ON

Step 9: Creating and Using a Network ACL to Deny Traffic to the Private EC2

1. Go to the NACL page in AWS:

  • In the AWS console search bar, type “Network ACLs” and select it.
  • This is where you manage subnet-level traffic controls.

2. Create a new NACL:

  • Click Create Network ACL.
  • Give it a meaningful name, e.g., PrivateSubnet-Deny-ACL.
  • Select the VPC where your private subnet resides.

3. Associate the NACL with the private subnet:

  • After creating, select the NACL, click Subnet associations, then Edit subnet associations.
  • Check the private subnet to associate this NACL.

4. Add a deny rule for the EC2 instance:

  • Select Inbound Rules and click Edit inbound rules.
  • Add a new rule:
    • Rule #: pick the next available number (e.g., 100)
    • Type: All Traffic (or specify SSH if you want to limit to port 22)
    • Protocol: All (or TCP if limiting)
    • Port Range: 0-65535 (or just 22 for SSH)
    • Source: the private EC2’s IP in CIDR /32 format (e.g., 10.0.1.181/32)
    • Action: Deny

5. (Optional) Outbound rule:

  • If you also want to stop this EC2 from initiating connections to other hosts, add a similar rule under Outbound Rules.

6. Save changes:

  • Once done, the NACL is active.
  • Effect: The bastion host (or any other source) can no longer reach the private EC2, because the NACL explicitly denies traffic.

Hint:

  • NACLs are stateless, so you must create both inbound and outbound rules if you want to block traffic in both directions.
  • Rule numbering matters: lower numbers are evaluated first.

Top comments (0)