A hands-on cloud engineering project demonstrating secure networking, high availability, load balancing, object storage, and infrastructure design using Google Cloud Platform.

Introduction

Imagine FreshCart, a rapidly growing e-commerce startup, announcing a weekend flash sale. Thousands of shoppers begin visiting the website simultaneously, expecting a smooth shopping experience.

Now imagine the entire application runs on a single virtual machine that's directly connected to the Internet.

That single server becomes responsible for handling incoming traffic, serving application requests, performing operating system updates, and protecting itself from attackers—all while trying to stay online.

It only takes one unexpected traffic spike, hardware issue, or security vulnerability to bring everything down.

As FreshCart's newly hired cloud engineer, my goal was to redesign this architecture into something more secure, scalable, and production-ready.

Rather than exposing the backend server directly to the Internet, I built a two-tier architecture where:

• users only communicate with a public load balancer,

• backend compute resources remain isolated inside private networking,

• static website assets are served separately from object storage,

• HTTPS is enforced using managed SSL certificates,

• and storage costs are automatically optimized through lifecycle management.

This project was built entirely on Google Cloud Platform (GCP) using the gcloud CLI, with security, availability, and operational simplicity as the primary design goals.

The Problem with a Single Public VM

At first glance, deploying everything on one virtual machine seems simple.

However, this architecture creates several problems.

Security

A publicly accessible VM increases the attack surface considerably. Even with firewall rules in place, a misconfiguration could expose SSH or application ports to the Internet.

Availability

A single VM represents a single point of failure.

If the instance crashes, undergoes maintenance, or experiences an outage, the entire application becomes unavailable.

Scalability

As traffic grows, scaling becomes increasingly difficult because all requests are handled by one server.

Introducing additional instances later requires redesigning the networking from scratch.

Maintainability

Serving static website files from the same machine as the backend application mixes responsibilities that should remain independent.

Modern cloud architectures separate these concerns to improve security and operational efficiency.

These limitations motivated the architecture shown below.

Planning Before Building

Before opening Cloud Shell or running a single gcloud command, I first sketched the intended architecture.

The primary design objectives were:

• isolate backend infrastructure from the Internet

• expose only one secure public entry point

• allow backend servers to access updates without public IP addresses

• separate static content from application traffic

• prepare the network for future scaling across multiple zones

Initial Architecture Sketch

Initial architecture concept

During implementation, the overall design remained largely unchanged, although a few networking details—such as firewall rules for Google Load Balancer health checks and managed certificate provisioning—were refined after testing.

Final Architecture

The completed architecture consists of two distinct layers.

• Public Layer

  • HTTPS Load Balancer

  • Google Cloud Storage Static Website

  • Managed SSL Certificate

• Private Layer

  • Custom VPC

  • Two private subnets

  • Backend VM

  • Cloud Router

  • Cloud NAT

Final Network Architecture Diagram

Architecture Diagram

How Traffic Flows

1. A user opens the FreshCart website.

2. Requests to the marketing website are served directly from Google Cloud Storage over HTTPS.

3. Requests to the backend application first arrive at the Google Cloud HTTP(S) Load Balancer.

4. The load balancer terminates HTTPS before forwarding traffic to the backend VM using HTTP.

5. The backend VM processes the request entirely inside the private subnet.

6. Whenever the VM needs to download operating system updates or install packages, outbound traffic is routed through Cloud NAT.

At no point is the backend VM directly reachable from the Internet.

Building the Infrastructure

After finalizing the design, I implemented each component using the Google Cloud CLI.

Rather than dumping every command used, I'll highlight a few that illustrate the major architectural decisions.

1. Creating the Custom VPC

I began by creating a dedicated Virtual Private Cloud rather than relying on GCP's default network.

This gave me complete control over subnets, firewall rules, routing, and IP ranges.

2. Creating Two Private Subnets

Two private subnets were created across separate zones.

Although only one backend VM was deployed for this project, designing the network across multiple zones means future scaling can happen without redesigning the infrastructure.

Subnets

3. Deploying the Backend VM

One of the most important decisions was deploying the backend server without a public IP address.

A simplified version of the deployment command looked like this:

gcloud compute instances create freshcart-backend \
    --no-address

That single flag (--no-address) ensures the VM cannot be reached directly from the public Internet.

Instead, all traffic must pass through the load balancer.

The backend application itself was a simple Nginx server returning a placeholder response.

Backend VM

"FreshCart backend is up"

4. Configuring Cloud NAT

Removing the VM's public IP introduced another challenge.

Without Internet access, package installation and system updates would fail.

To solve this, I configured Cloud Router together with Cloud NAT.

Cloud NAT allows outbound Internet access while preventing any inbound connections.

This preserves security without sacrificing maintainability.

Cloud NAT

5. Configuring the Load Balancer

The Google Cloud HTTP(S) Load Balancer became the only public entry point into the backend application.

It performs several important functions:

• receives Internet traffic

• terminates HTTPS

• performs health checks

• forwards requests only to healthy backend instances

This means unhealthy instances never receive production traffic.

Load Balancer

Backend Service

6. Hosting the Static Website

Instead of serving the landing page from the VM, I deployed it using Google Cloud Storage's static website hosting.

This approach offers several advantages:

• lower operational cost

• no server maintenance

• high durability

• excellent performance

The website consisted of a simple "FreshCart Coming Soon" landing page.

7. Configuring HTTPS and a Custom Domain

To simulate a production deployment without purchasing a domain, I used DuckDNS.

After reserving a static IP address for the load balancer, I pointed my DuckDNS subdomain to that address.

Google's managed certificate automatically validated ownership through DNS before issuing the SSL certificate.

Once provisioning completed, the website became accessible over HTTPS.

DuckDNS configuration

Managed SSL Certificate

8. Configuring Storage Lifecycle Management

Static assets rarely need to remain in premium storage forever.

To reduce storage costs automatically, I configured a lifecycle policy that:

• moves objects older than 30 days into Nearline Storage

• permanently deletes objects older than 90 days

A simplified version of the lifecycle configuration looked like this:

{
  "rule": [
    {
      "action": {
        "type": "SetStorageClass",
        "storageClass": "NEARLINE"
      },
      "condition": {
        "age": 30
      }
    },
    {
      "action": {
        "type": "Delete"
      },
      "condition": {
        "age": 90
      }
    }
  ]
}

This keeps storage costs predictable without requiring manual cleanup.

Lifecycle Policy

The Three Hardest Engineering Decisions

Cloud engineering is rarely about choosing the "right" service.

More often, it's about making thoughtful trade-offs.

Decision 1 — Keeping the Backend Private

The easiest approach would have been assigning the VM a public IP and restricting access with firewall rules.

Instead, I chose to remove the public IP entirely.

Why?

Even the best firewall rules can be accidentally modified.

A server without a public IP simply cannot be attacked directly from the Internet.

Trade-off

This required adding Cloud NAT, increasing infrastructure cost slightly.

For production workloads, that additional cost is well worth the significant security improvement.

Decision 2 — Designing for Multiple Zones

Although only one VM was required for this project, I still created subnets across different zones.

Why?

Infrastructure should be designed for growth.

If FreshCart later experiences increased traffic, a Managed Instance Group can distribute instances across zones without rebuilding the network.

Trade-off

The architecture is slightly more complex today but significantly easier to scale tomorrow.

Decision 3 — Separating Static Content from Compute

Rather than serving the marketing website from Nginx, I hosted it using Google Cloud Storage.

Why?

Static websites don't require virtual machines.

Object storage is cheaper, highly durable, and eliminates server maintenance entirely.

Trade-off

Dynamic applications still require compute resources, but static assets benefit greatly from object storage.

Challenges I Encountered

Like most cloud projects, not everything worked perfectly on the first attempt.

Managed Certificate Provisioning

The SSL certificate remained in the PROVISIONING state for several minutes.

After verifying my DuckDNS records and waiting for DNS propagation, Google successfully completed validation and issued the certificate.

Load Balancer Health Checks

Initially, the backend service remained unhealthy.

The issue turned out to be missing firewall rules allowing Google's health check IP ranges to reach the backend instance.

Once those rules were added, the backend immediately became healthy.

Private VM Connectivity

Removing the VM's public IP meant package installation failed initially.

Deploying Cloud NAT restored outbound connectivity while maintaining complete inbound isolation.

What I Would Add Next

If FreshCart continued growing, there are several improvements I would implement.

Managed Instance Groups

Replace the single backend VM with a regional Managed Instance Group capable of automatic scaling.

Cloud CDN

Serve static website assets from Google's edge locations around the world to reduce latency.

Cloud Armor

Protect the application from DDoS attacks and common web exploits using Google's Web Application Firewall.

Cloud Monitoring and Logging

Implement dashboards, uptime monitoring, alerting, and centralized logging using Cloud Monitoring and Cloud Logging.

Infrastructure as Code

Convert every CLI command into reusable Terraform modules, enabling version control, code reviews, and automated deployments.

Lessons Learned

This project reinforced several important cloud engineering principles.

Security begins with network design rather than firewall rules alone.

Separating public and private infrastructure significantly reduces attack surfaces while making future scaling much easier.

Building with managed cloud services—such as Load Balancing, Cloud NAT, Cloud Storage, and managed SSL certificates—also reduces operational overhead compared to managing everything manually.

Perhaps the biggest takeaway was that good architecture isn't just about getting resources running. It's about making thoughtful decisions that balance security, cost, scalability, and maintainability from the very beginning.

Conclusion

Designing FreshCart's two-tier architecture gave me practical experience implementing secure networking patterns commonly found in production cloud environments.

Starting from a simple problem—protecting a backend application from direct Internet exposure—I built an architecture that isolates compute resources, centralizes public access through a load balancer, serves static content efficiently from object storage, automates storage lifecycle management, and prepares the infrastructure for future growth.

While this project fulfills the requirements of the capstone, it also demonstrates an approach to cloud architecture that prioritizes security by default, operational simplicity, and scalability. These are principles I intend to carry into every future cloud engineering project.

GitHub Repository

https://github.com/Mikey064/freshcart-twotier

References

• Google Cloud Documentation

• Google Cloud Load Balancing Documentation

• Google Cloud Storage Documentation

• Cloud NAT Documentation

• Google Cloud Managed SSL Certificates Documentation

• DuckDNS Documentation