Com2us Platform · Multi-cloud

Summoners War: Sky Arena multi-cloud and firewall redesign

A massive game platform across GCP and Tencent Cloud, with 600 servers and 70 databases, a full firewall policy redesign, and patching with no maintenance window.

Role: Cloud Engineer · Main engineer
Period: Feb 2023 – Feb 2026
Cloud: GCP · Tencent
Scale: 600 servers · 70 databases · Massive
Key tech: GCP · Tencent Cloud · Terraform · Terragrunt · Cloud Armor

600
Servers: 70
Databases: - 40 %
Deployment time after moving to Terragrunt

At a glance

What remains is regrouped by server role, which makes rules easier to review and change.

Problem

This was the company's largest project, with Tencent added for service in China. Firewall policies across the two clouds had grown duplicated and complex, and code spread across many regions had become hard to manage with Terraform alone.

Approach

A full analysis of cross-cloud firewall policies removed duplicate and unneeded rules and regrouped the rest by role: web, game, database, and admin. Terraform moved to a Terragrunt structure to remove code duplication. Most servers sat behind load balancers, so patches rolled through by taking servers out and back one at a time.

Result

Simpler firewall policies were easier to review and change, with a smaller exposed surface. Moving to Terragrunt cut deployment time by 40%, and GCP Cloud Armor provided DDoS protection.

Up close

The whole pool is patched without stopping the service.

What this code does: Creates one GCP firewall rule for each entry in the rule map (var.rules) and uses the map key as the rule name. For INGRESS the ranges become sources, for EGRESS they become destinations, and use_service_accounts decides whether sources and targets are set by network tags or by service accounts. Because each rule is declared as a map entry rather than its own resource block, a policy grouped by role can be managed directly as data.

resource "google_compute_firewall" "rules" {
  for_each = var.rules

  network                 = each.value.network
  name                    = each.key
  direction               = each.value.direction
  source_ranges           = each.value.direction == "INGRESS" ? each.value.ranges : null
  destination_ranges      = each.value.direction == "EGRESS" ? each.value.ranges : null
  source_tags             = each.value.use_service_accounts || each.value.direction == "EGRESS" ? null : each.value.sources
  source_service_accounts = each.value.use_service_accounts && each.value.direction == "INGRESS" ? each.value.sources : null
  target_tags             = each.value.use_service_accounts ? null : each.value.targets
  target_service_accounts = each.value.use_service_accounts ? each.value.targets : null
  priority                = each.value.priority

What I learned

The big lesson was that a firewall policy that only ever gains rules soon becomes unreadable. Regrouping long-accumulated rules by role, web, game, DB, and management, made it obvious where to look for any change and shrank the exposed surface along with it. Code hit the same problem at scale, so Terraform that had grown across many regions had to move to a Terragrunt structure to strip out the duplication. Running without maintenance windows came less from any special technique than from a structure where servers sit behind load balancers and can be taken out and put back one at a time. And because a policy cleaned up by one full analysis piles up again over time, I learned that cleanup has to be a recurring check, not a one-time job.

Related field notes

Redesigning a tangle of firewall rules