24.5 Cloud Networking Project

Overview of the Cloud Networking Project

The cloud networking project brings together many ideas from the course and applies them to a practical scenario that lives in a public cloud environment. Your goal is to design, build, and test a small but realistic network in the cloud that supports a simple application, exposes only what is necessary to the internet, and follows basic security and reliability principles.

You will not be learning cloud vendor specifics in depth here. Instead, you will focus on the networking concepts that carry over between providers, such as virtual private networks in the cloud, subnets, routing, security boundaries, and connectivity from your home or office to the cloud.

By the end of this project, you should be able to explain what you built, why you built it that way, and how traffic flows through your cloud network from a user on the internet to your application and back.

Project Scenario

Imagine that you are asked to deploy a simple web application in the cloud. The application might be a static website, a small blog, or a demonstration API. Users will access it over the internet using HTTP or HTTPS. The company expects more users in the future, so the design must be flexible enough to grow, but for now you only need a small starting setup.

You do not need a complex microservices architecture for this project. Instead, you will focus on one or two application servers and, optionally, a separate database server. The important part is how these servers are arranged inside a cloud virtual network and how traffic is controlled with routing and security rules.

The typical requirements are:

1. A private, isolated virtual network in the cloud for your workload.
2. A clear separation between internet-facing components and internal components.
3. Controlled inbound and outbound traffic with security rules.
4. The ability for you, as the administrator, to connect for management and troubleshooting.
5. Basic logging and verification that the network behaves as expected.

High-Level Cloud Network Design

Most public cloud providers offer a similar building block for private networking. It is usually called a Virtual Private Cloud or a Virtual Network. In this project, you will design one such virtual network and divide it into multiple subnets that play different roles.

At a high level, your design can be described as follows:

You create one cloud virtual network that uses a private IP address range. Inside this network, you create at least two subnets. One subnet hosts public-facing resources that accept traffic from the internet. The other subnet hosts private resources that do not have direct internet access. A routing configuration and security rules control how packets move between these subnets and to or from the internet.

The table below summarizes the logical components that you will use.

Your exact IP ranges and resource names may differ, but the structure should follow this pattern.

Choosing IP Ranges and Subnets

The first design step is to choose an IP range for your cloud virtual network. This range must not overlap with IP ranges that you already use in your home lab or other networks that you may connect later. It must also use private address space.

A simple approach is to pick a private block such as $10.0.0.0/16$ and then divide it into smaller subnets.

For example:

You will apply subnetting knowledge to decide how many hosts you need now and how many you might need later. In a beginner project, a /24 subnet usually provides more than enough addresses.

Once you have selected your ranges, document them clearly. This documentation becomes part of your project deliverables and helps you keep track of where everything lives.

Public and Private Subnets

Public and private subnets are used to separate resources that should be reachable from the internet from those that should not.

In this project, a public subnet is a subnet with a route to the internet gateway and may host resources that have public IP addresses. Typical examples include:

1. A public load balancer that accepts user traffic on port 80 or 443.
2. A bastion or jump host that you use to administer internal servers.

A private subnet is a subnet that does not expose resources directly to the internet. It only sends traffic to other internal subnets or sometimes through a controlled gateway that can reach the internet on behalf of internal resources.

Your design can use a simple pattern, where:

1. The public subnet hosts a web server or an application front end, and
2. The private subnet hosts a database server that only the application can reach.

By placing the database server in a private subnet, you make it much harder for an attacker on the internet to reach it directly, which is an important security goal.

Internet Connectivity and Gateways

Your cloud network needs a controlled way to reach and be reached from the internet. The typical component for this is an internet gateway that attaches to your virtual network. The internet gateway provides a path between public IP addresses in your account and the global internet.

To use this path, your public subnet needs a route that sends traffic bound for unknown destinations to the internet gateway. In routing terms, this is a default route.

An example entry in your route table might look like this.

In your project, you should:

1. Attach an internet gateway to your virtual network.
2. Associate a route table with the public subnet that includes a default route to the gateway.
3. Keep the private subnet route table without a direct internet route, or route its external traffic through a more restricted outbound mechanism if needed.

Security Groups and Network ACLs

Cloud environments usually provide more than one layer of packet filtering. The naming and exact behavior vary between providers, but you will typically find two main mechanisms.

One mechanism is often attached to individual resources, such as virtual machines or load balancers. It acts like a stateful firewall specific to that resource. You can use it to say which ports are allowed from which sources. This is where you define rules like "allow HTTP from anywhere" or "allow database traffic only from the web server."

Another mechanism can be applied to subnets and acts as a network-wide access control list. It may have separate rules for inbound and outbound traffic and can be stateless, which means return traffic must also be explicitly allowed.

In your project, you should:

1. Use resource-level security rules to tightly control which IPs and ports can reach your application server.
2. Use stricter rules for the private subnet to limit which sources can reach database ports.
3. Ensure that administrative access, such as SSH or RDP, is allowed only from specific trusted IP addresses.

For example, a basic rule set for a web server virtual machine might be:

You can refine these as you test your design and learn which flows are actually needed.

Load Balancers and High-Level Traffic Flow

To prepare for future growth, you can place a load balancer in the public subnet in front of your web server instances. Even if you start with a single server, using a load balancer lets you later add more servers behind it without changing the public interface.

In the project, you do not need complex balancing algorithms. It is enough to understand that:

1. The load balancer has a public endpoint that users access.
2. The load balancer forwards traffic to targets in the private or public subnets, using their private IP addresses.
3. Health checks can be used to determine if a target is alive and able to serve traffic.

A simplified flow for a typical request looks like:

1. A user on the internet resolves your domain name into the public IP of the load balancer.
2. The user's browser opens a TCP connection to this IP on port 80 or 443.
3. The load balancer accepts the connection and selects a backend web server target.
4. The load balancer establishes a connection to the selected web server on an internal port.
5. The web server processes the request, possibly querying a database in the private subnet.
6. The response travels back along the same path, from the server to the load balancer, then to the client.

You should be able to describe this flow step by step, including which components see which IP addresses and ports. This explanation is an important part of your project report.

Management and Access from Your Home Network

To manage cloud instances, you need a secure path from your home or office network to your cloud virtual machines. In a simple project, you can do this through:

1. A bastion or jump host in the public subnet, or
2. Direct remote access with very limited allowed source IPs.

A bastion host is a hardened machine that has a public IP and accepts administrative connections. From there, you connect to private instances using their internal IPs, so the private instances themselves do not need public exposure.

In a more advanced design, you could use a site to site VPN between your home router or virtual machine and the cloud virtual network, so private IP addresses are reachable from your local network as if they were on an extended LAN. For a first project, configuring a full VPN is optional, but you should at least be aware of this pattern.

No matter which option you choose, your design document must explain:

1. Which machine has a public IP.
2. How you authenticate to that machine.
3. How you then reach private resources if you use them.
4. How you minimize the attack surface by limiting open ports and allowed source IPs.

Logging, Monitoring, and Verification

A cloud networking project is not complete until you verify that the design behaves as intended and gather some basic visibility into what is happening.

You should perform at least these checks:

1. Confirm that users on the internet can reach the public endpoint, such as the load balancer or web server, using ping or HTTP tools where appropriate.
2. Confirm that private resources cannot be reached directly from the internet.
3. Confirm that application servers can reach the database servers over the expected ports.
4. Confirm that your administrative access works only from approved locations.

Where your cloud provider offers it, enable simple flow logs or connection logs for your subnets or resources. These logs will show which IPs connect and which ports they use. For a beginner project, even a small sampling of logs is enough to show that you understand how to check network behavior.

You should keep a short record of your tests, for example:

This table can be included in your final submission to demonstrate that you validated your network configuration.

Cost Awareness and Resource Sizing

Cloud resources usually cost money, even if the amounts are small. Part of a realistic project is to design with cost in mind.

Basic guidelines for this project are:

1. Use the smallest virtual machine sizes sufficient for your tests.
2. Use one region only, unless multi region scenarios are explicitly required.
3. Avoid unnecessary idle resources, and delete test resources when you are finished.
4. Prefer managed services with free tiers where possible, if they fit the project scope.

Although cost calculation is not the main goal of this chapter, you should be aware of which components tend to be more expensive. Virtual machines, load balancers, and data transfer across regions are common cost drivers. In contrast, configuration elements like route tables or security groups are usually free.

You can include a short summary of your expected monthly cost in the project documentation, even if it is only an estimate. This shows that you understand that network design has budget implications.

Project Deliverables

To complete the cloud networking project, you should produce both a working setup in the cloud and documentation that explains your design. A typical deliverable set includes:

1. A single diagram of your cloud virtual network, including:
1. The virtual network CIDR.
2. Each subnet and its CIDR.
3. The internet gateway or equivalent.
4. Load balancers, bastion hosts, web servers, and databases.
5. Arrows that show the main traffic flows.
2. A written explanation of:
1. Your IP addressing plan.
2. The purpose of each subnet.
3. Your routing choices, including default routes.
4. Your security rules, including at least one inbound and one outbound example.
5. How users access the application and how you access it for management.
3. A short test and verification report that documents how you confirmed that the network behaves as designed.

Your project does not need to be perfect or extremely complex. Its value comes from showing that you can reason about connectivity, isolation, and security in a cloud environment, and that you can map the abstract concepts from the rest of the course onto real cloud networking components.

Reflecting on the Cloud Networking Concepts

After you build and test your project, take time to connect what you have done with the broader networking ideas in the course. Ask yourself questions such as:

1. How does my cloud virtual network compare to a traditional on-premises network?
2. Which parts of my design correspond to routers, switches, and firewalls?
3. How does routing in the cloud differ from routing on physical devices?
4. Where do I see the use of private IP addressing, NAT, and public IPs?
5. How would I scale this design to support more users or more regions?

Writing brief answers to these questions can help deepen your understanding of cloud networking and prepare you for more advanced topics, such as multi region architectures, hybrid cloud, and software defined networks in large environments.

By treating this project as a practical lab and a reflection exercise, you turn abstract theory into a concrete, memorable design that mirrors how real applications live and move in the cloud.