From Traditional to Serverless: Building a Secure Voting System on GCP

Introduction For the past few weeks, I've been developing "SecureVote" - a cloud infrastructure project for a secure online voting platform that organizations can use for internal elections, board votes, and member surveys. This project has been particularly relevant for my career goals in Qatar, where many organizations require secure, auditable voting systems that comply with data regulations. What started as a traditional infrastructure implementation has evolved into a serverless architecture journey - one that has taught me valuable lessons about modern cloud design principles and cost optimization techniques. The Initial Vision SecureVote was conceptualized with four primary requirements: High Availability: Voting periods have fixed timeframes and cannot tolerate downtime Security: Votes must remain confidential and protected from tampering Scalability: The system must handle voting traffic spikes efficiently Compliance: A complete audit trail must be maintained for verification My initial implementation focused on traditional infrastructure patterns: VPC networks with custom subnets for isolation VM-based compute resources Network firewall rules for security IAM roles for access control The Pivot to Serverless After deploying the initial infrastructure using Terraform, I had a realization. Managing VM instances and the associated infrastructure would require ongoing maintenance and potentially higher costs - especially during periods of inactivity between voting events. That's when I decided to pivot to a serverless architecture. With guidance from Claude, I developed a plan to transform SecureVote into a modern cloud-native application that would: Reduce operational overhead Lower costs through pay-per-use billing Improve security by reducing the attack surface Scale automatically based on demand Technical Evolution Infrastructure as Code Foundation The project uses Terraform to define all infrastructure components, allowing for consistent deployment and version control. The repository structure evolved from focusing on networks and firewalls to encompassing serverless components: securevote-gcp-iac/ ├── terraform/ │ ├── backend.tf # GCS backend configuration │ ├── variables.tf # Input variables │ ├── main.tf # Provider and API configuration │ ├── service_accounts.tf # Service account definitions │ ├── networks.tf # VPC and subnet definitions │ ├── firewalls.tf # Firewall rules │ ├── storage.tf # Frontend static hosting │ ├── cloud_run.tf # Backend API services │ ├── database.tf # Cloud SQL configurations │ ├── iam.tf # IAM roles and bindings │ └── outputs.tf # Output values └── README.md From Network Security to Service-Based Security My initial approach to security focused heavily on network controls: hcl# SSH access firewall rule resource "google_compute_firewall" "vpc_dev_allow_ssh" { project = var.project_id name = "vpc-dev-allow-ssh" network = google_compute_network.vpc_dev.name allow { protocol = "tcp" ports = ["22"] # SSH port } source_ranges = ["0.0.0.0/0"] description = "Allow SSH access to resources" } This was a traditional approach where I was securing VM instances through IP filtering. However, with the serverless architecture, the security model shifted to service-based identity and authorization: hcl# IAM binding for cloud run production service with restricted access resource "google_cloud_run_service_iam_binding" "api_prod_auth" { location = google_cloud_run_service.api_prod.location service = google_cloud_run_service.api_prod.name role = "roles/run.invoker" members = [ "serviceAccount:${google_service_account.cloud_run_service_account.email}" ] } Component Transformation Each component underwent a transformation: Frontend: From potential VM-hosted web servers to Cloud Storage static website hosting Backend: From Compute Engine VMs to fully managed Cloud Run services Database: Remained as Cloud SQL but with serverless connectivity Networking: Added VPC Service Connectors to bridge serverless services with VPC resources Benefits of the Serverless Approach Cost Optimization The serverless model dramatically changed the cost profile of the project. Instead of paying for 24/7 VM instances, the new architecture only incurs costs when the system is actually processing votes. For an election system that might only be used periodically, this difference is substantial. Initial estimates suggest that with careful resource management, the entire development and testing phase could cost less than $20, and potentially even run within GCP's free tier limits. Reduced Operational Burden With serverless components, there's no need to: Patch operating systems Configure SSH access Monitor VM health Handle auto-scaling groups Google Cloud manages t

Apr 26, 2025 - 22:01

From Traditional to Serverless: Building a Secure Voting System on GCP

Introduction

For the past few weeks, I've been developing "SecureVote" - a cloud infrastructure project for a secure online voting platform that organizations can use for internal elections, board votes, and member surveys. This project has been particularly relevant for my career goals in Qatar, where many organizations require secure, auditable voting systems that comply with data regulations.

What started as a traditional infrastructure implementation has evolved into a serverless architecture journey - one that has taught me valuable lessons about modern cloud design principles and cost optimization techniques.

The Initial Vision

SecureVote was conceptualized with four primary requirements:

High Availability: Voting periods have fixed timeframes and cannot tolerate downtime

Security: Votes must remain confidential and protected from tampering

Scalability: The system must handle voting traffic spikes efficiently

Compliance: A complete audit trail must be maintained for verification

My initial implementation focused on traditional infrastructure patterns:

VPC networks with custom subnets for isolation

VM-based compute resources

Network firewall rules for security

IAM roles for access control

The Pivot to Serverless

After deploying the initial infrastructure using Terraform, I had a realization. Managing VM instances and the associated infrastructure would require ongoing maintenance and potentially higher costs - especially during periods of inactivity between voting events.

That's when I decided to pivot to a serverless architecture. With guidance from Claude, I developed a plan to transform SecureVote into a modern cloud-native application that would:

Reduce operational overhead

Lower costs through pay-per-use billing

Improve security by reducing the attack surface

Scale automatically based on demand

Technical Evolution

Infrastructure as Code Foundation
The project uses Terraform to define all infrastructure components, allowing for consistent deployment and version control. The repository structure evolved from focusing on networks and firewalls to encompassing serverless components:

securevote-gcp-iac/
├── terraform/
│ ├── backend.tf # GCS backend configuration
│ ├── variables.tf # Input variables
│ ├── main.tf # Provider and API configuration
│ ├── service_accounts.tf # Service account definitions
│ ├── networks.tf # VPC and subnet definitions
│ ├── firewalls.tf # Firewall rules
│ ├── storage.tf # Frontend static hosting
│ ├── cloud_run.tf # Backend API services
│ ├── database.tf # Cloud SQL configurations
│ ├── iam.tf # IAM roles and bindings
│ └── outputs.tf # Output values
└── README.md
From Network Security to Service-Based Security
My initial approach to security focused heavily on network controls:

hcl# SSH access firewall rule
resource "google_compute_firewall" "vpc_dev_allow_ssh" {
  project = var.project_id
  name    = "vpc-dev-allow-ssh"
  network = google_compute_network.vpc_dev.name

  allow {
    protocol = "tcp"
    ports    = ["22"]  # SSH port
  }

  source_ranges = ["0.0.0.0/0"]
  description = "Allow SSH access to resources"
}

This was a traditional approach where I was securing VM instances through IP filtering. However, with the serverless architecture, the security model shifted to service-based identity and authorization:

hcl# IAM binding for cloud run production service with restricted access
resource "google_cloud_run_service_iam_binding" "api_prod_auth" {
  location = google_cloud_run_service.api_prod.location
  service  = google_cloud_run_service.api_prod.name
  role     = "roles/run.invoker"
  members  = [
    "serviceAccount:${google_service_account.cloud_run_service_account.email}"
  ]
}

Component Transformation
Each component underwent a transformation:

Frontend: From potential VM-hosted web servers to Cloud Storage static website hosting

Backend: From Compute Engine VMs to fully managed Cloud Run services

Database: Remained as Cloud SQL but with serverless connectivity

Networking: Added VPC Service Connectors to bridge serverless services with VPC resources

Benefits of the Serverless Approach

Cost Optimization
The serverless model dramatically changed the cost profile of the project. Instead of paying for 24/7 VM instances, the new architecture only incurs costs when the system is actually processing votes. For an election system that might only be used periodically, this difference is substantial.

Initial estimates suggest that with careful resource management, the entire development and testing phase could cost less than $20, and potentially even run within GCP's free tier limits.

Reduced Operational Burden
With serverless components, there's no need to:

Patch operating systems

Configure SSH access

Monitor VM health

Handle auto-scaling groups

Google Cloud manages these aspects automatically, allowing me to focus on application logic rather than infrastructure maintenance.

Improved Security Posture
Removing SSH access and publicly accessible VMs significantly reduced the attack surface. The serverless architecture leverages Google Cloud's identity-aware security controls and private networking features to ensure that only authorized services can communicate with each other.

Why This Matters for Qatar's Tech Landscape

Projects like SecureVote are particularly valuable in Qatar's context for several reasons:

Digital Transformation: Qatar's National Vision 2030 emphasizes technological advancement, and organizations are seeking modern cloud solutions.

Security Requirements: Financial institutions, government agencies, and corporations in Qatar have stringent security requirements that cloud-native architectures can address effectively.

Cost Efficiency: As businesses optimize operations, the pay-per-use model of serverless is increasingly attractive.

Technical Skill Development: Building expertise in serverless architecture positions IT professionals for the evolving job market in Qatar.

Learning Outcomes

This project has been invaluable for my professional development:

Practical IaC Experience: Gained hands-on experience with Terraform for managing cloud infrastructure.

Architectural Decision-Making: Learned to evaluate traditional vs. serverless approaches based on requirements.

Security-First Design: Implemented defense-in-depth through multiple security layers.

Cost Management: Developed strategies for controlling cloud costs without sacrificing functionality.

Modern DevOps Practices: Applied CI/CD concepts through version-controlled infrastructure.

Next Steps

As I continue to refine SecureVote, my focus will be on:

Implementing a CI/CD pipeline for infrastructure deployment

Adding application-level components like Firebase Authentication

Creating developer documentation and operational runbooks

Setting up monitoring and alerting for the serverless components

Conclusion

The journey from traditional to serverless architecture for SecureVote has been enlightening. It's demonstrated that modern cloud platforms enable powerful, secure systems without the operational overhead traditionally associated with such projects.

For anyone building a portfolio for cloud engineering roles, I highly recommend including serverless projects that showcase these principles. They not only demonstrate technical competency but also an understanding of business considerations like cost optimization and operational efficiency - qualities highly valued by employers in Qatar's growing tech sector.