DEV Community: luis zuñiga

🚀 Beyond the HCL: Trench Lessons from Deploying Critical Architectures on GCP with Terraform

luis zuñiga — Wed, 06 May 2026 21:54:39 +0000

The "Bunker" vs. Resilience: Scaling Windows Server Without the Burnout
By: Luis Alonso Zuñiga Carballo
Cloud Architect & Security Strategist

💣 The Challenge: The Problem That Kept Me Up at Night
Imagine this: You are tasked with deploying a critical-tier enterprise infrastructure on Google Cloud Platform (GCP). It’s not just about "spinning up VMs"; it’s about orchestrating an environment that supports Windows Server applications, ensures hybrid connectivity with on-premises offices, and—most importantly—doesn't break when traffic spikes or a node fails.

The true challenge was transforming a "functional bunker" into a High Availability Hybrid Architecture that was 100% reproducible and transparent for the stakeholder.

🏗️ The Strategy: Operational Symmetry in Action
For this deployment, I followed a three-stage validation workflow that ensures what is designed is exactly what is deployed:

Phase 1: Architectural Blueprint (ASCII): Before writing a single line of code, I mapped the entire logic using ASCII diagrams. This provided immediate clarity on traffic flow and subnet isolation without the distraction of complex tooling.

Phase 2: Infrastructure as Code (Terraform): Once the logic was solidified, I translated the ASCII blueprint into Terraform HCL. This allowed for the consistent deployment of 66 resources across multiple regions.

Phase 3: Stakeholder Visibility (PNG): Finally, I generated a high-fidelity PNG diagram based on the actual deployment. This served as the final "source of truth" to share with the client, providing full visibility into the security layers and hybrid connectivity established.

🛡️ Key Architectural Pillars

🌐 Global Networking
We utilized a custom VPC with Global routing mode to simplify BGP propagation across regions (us-east1 and us-east4).
🛡️ Layer 7 Shielding
We implemented Cloud Armor (WAF) and Identity-Aware Proxy (IAP). This eliminated public IPs for administration, allowing RDP access only through encrypted tunnels.
💾 Dual-Region Resilience
For critical backups, the standard was Dual-Region Cloud Storage, ensuring data survivability even in the event of a regional outage.

🛠️ The Hard Way: Lessons Learned from the Field
⚠️ The Quota Ghost: Never assume instance families are ready. Requesting vCPU quota increases in GCP can take at least one week.

🔌 The Routing "Trap": After establishing the IPsec tunnel, dynamic propagation often needs a manual nudge within the VPC Route Tables to ensure the Cloud Router is advertising correctly.

🤖 The Antigravity Factor: Using AI as a "copilot" to accelerate HCL generation is a force multiplier, but it requires human-in-the-loop auditing to maintain the Principle of Least Privilege (IAM).

💰 Business Value: Why Does This Matter?
This triple-stage workflow (ASCII → Terraform → PNG) isn't just about technical tidiness; it’s about Risk Mitigation:

Transparency: The client sees exactly what they are paying for.

Agility: We reduced deployment time from days to minutes through modular IaC.

Compliance: By following applied industry scenarios, we ensure that internal corporate procedures remain protected while delivering world-class security.

🏁 Call to Action
What is your preferred workflow for bridging the gap between a conceptual sketch and a production-ready environment? Let’s discuss in the comments! 👇

googlecloud #terraform #gcpcommunity #devops #cloudsecurity #iac #hybridcloud

⚖️ Technical & Legal Safe Harbor Disclaimer

AUTHORSHIP AND INDEPENDENT CAPACITY: This publication is authored solely by me in my individual and private capacity. The views, methodologies, and technical workflows expressed herein are my own and do not necessarily reflect the official policy or strategic direction of my current or former employers, clients, or any legal entity I am affiliated with.

INTELLECTUAL PROPERTY & CONFIDENTIALITY COMPLIANCE:

Zero Proprietary Disclosure: This content has been developed using publicly available information, official documentation, and personal research. No confidential information belonging to my employer has been disclosed.

Independent Development: The workflows described are based on general industry best practices and were not developed as a "work for hire."

LIMITATION OF LIABILITY: All technical info is provided "AS IS" without warranty. The author shall not be liable for any claim arising from the use of this information.

COMPLIANCE: This contribution is made in good faith and adheres to global technical community standards.

🛠️ From Foundations to Advanced SecOps: The GCP Developer’s Toolkit 🛡️

luis zuñiga — Fri, 24 Apr 2026 01:42:03 +0000

Hey GCP Community,

As developers and cloud engineers, we often start our journey learning how to deploy a VM or configure a bucket. But in today's landscape, "working code" isn't enough. We need "secure-by-design" architectures.

I’ve been documenting my journey and best practices in my latest project: GCP-ToolKit101. While the toolkit starts with the essentials, the goal is to bridge the gap between basic infrastructure and elite security operations using Chronicle, Mandiant, and SCC.

Here is how we evolve from 101 basics to enterprise-grade security:

⚡ Scaling Beyond Logs: Google Chronicle Once you master VPC Flow Logs in the "101" stage, the next level is Chronicle. It’s not just about storing logs; it's about sub-second detection using YARA-L.

Real-world case: Detecting Insider Threats in financial systems by correlating VPN access with unusual BigQuery exports.

🧠 Intelligence-Driven Code: Mandiant Advantage Security isn't just about blocking IPs; it's about knowing who is attacking. Integrating Mandiant APIs into your automated workflows allows you to:

Proactively block spear-phishing domains before they hit your users.

Prioritize vulnerabilities based on what actual APT groups are exploiting right now.

🏯 Total Posture: Security Command Center (SCC) Your infrastructure is only as strong as its weakest configuration. SCC acts as the "Command Tower" for:

Identity Leakage: Detecting when service account keys are accidentally pushed to public repos.

Compliance: Real-time monitoring of PCI-DSS or CIS benchmarks.

🚀 The Roadmap: GCP-ToolKit101
I created GCP-ToolKit101 to be a living resource. It’s the starting point for developers who want to master the Google Cloud ecosystem with a professional edge.

What you’ll find in the repo:

🏗️ Core Infrastructure: Clean, reusable patterns for GCP deployments.

🔒 Security First: Standardized configurations to harden your cloud environment.

📈 Evolution: I am currently integrating advanced SecOps modules, including YARA-L rule templates for Chronicle and automation scripts for SCC.

🛠️ Join the Journey
If you are a developer looking to bridge the gap between "it works" and "it's secure," this toolkit is being built for you. I’m sharing everything I learn while building B2B solutions for the Latam market.

👉 Check out the repo, drop a ⭐, and let’s build more secure cloud environments together:
https://github.com/luiszuniga1990/GCP-ToolKit101.git

GCP #GCPDev #CloudSecurity #DevSecOps #GoogleCloud #Mandiant #Chronicle #CompanyOfOne #TechCommunity

Deep Dive: Accelerating Infrastructure as Code (IaC) on GCP using Terraform and Antigravity

luis zuñiga — Fri, 17 Apr 2026 00:42:09 +0000

Key Stack: Terraform, Google Cloud Platform (GCP), Cloud Armor, Cloud SQL, Antigravity AI

When designing robust and scalable architectures for production environments, efficiency is non-negotiable. Traditionally, SRE and Infrastructure teams spend significant cycles managing network segregation, variable consistency, and manual security audits. However, the paradigm has shifted: Generative AI applied to Platform Engineering has arrived to eliminate operational toil.

In this article, we will technically analyze the paquetesaction project. We will explore how to deploy advanced Terraform modules on Google Cloud by operating alongside Antigravity—an AI-powered assistant tailored for infrastructure workflows based on Google DeepMind technology—which acts as an additional software engineer within your terminal.

The Multi-Project Modularity Challenge For this use case, the requirements demanded four distinct architectures designed to coexist within an enterprise ecosystem. The goal was clear: total isolation and automated scalability.

Base VPC (Core Networking): Implementation of custom networks with Private Google Access enabled for internal consumption of Google APIs without internet egress.

Private Data Workloads: Cloud SQL (MySQL) with restricted access via VPC Peering, eliminating any public IP exposure.

Resilient L7 Frontend: Global HTTP(S) Load Balancer supported by Managed Instance Groups (MIG) and perimeter protection via Cloud Armor.

Management Access (Bastion): e2-micro instances for administration, using strict tag-based routing.

Antigravity: Pair Programming "On Steroids" The true disruption of Antigravity lies not in static code generation, but in its ability to execute an iterative framework within the DevOps lifecycle.

Rather than generating isolated code, the agent operated as a collaborator aware of the repository and the Terraform lifecycle. While orchestrating the environments/dev directory, the agent autonomously structured:

The file architecture (main.tf, variables.tf, outputs.tf).

Initialization logic via CLI commands (terraform init and terraform fmt).

Selection of optimized images (Debian 11) to meet internal compliance policies.

Technical Architecture & Data Flow Below is a breakdown of the critical infrastructure components designed for this project.

A. Managed Database Isolation (Cloud SQL)
Exposing a database to the internet is an unacceptable risk. We utilized Private Services Access to connect our VPC with the Google Tenant Project.


+----------------------------------------------------+
| Your GCP Project (Consumer VPC)                    |
|                                                    |
|  +----------------------------------------------+  |
|  | VPC: "mysql-vpc-dev"                         |  |
|  |                                              |  |
|  |  [Global IP Range Reservation: /16]          |  |
|  |             |                                |  |
|  +-------------|--------------------------------+  |
|                |                                   |
|                v (Automatic VPC Peering)           |
|                                                    |
|  +----------------------------------------------+  |
|  | Google Managed Services (Tenant VPC)          |  |
|  |                                              |  |
|  |  +---------------------------------------+   |  |
|  |  | Cloud SQL Instance (MySQL 8.0)         |   |  |
|  |  | - IPv4_enabled: OFF                   |   |  |
|  |  | - Private IP (from reserved range)    |   |  |
|  |  +---------------------------------------+   |  |
|  +----------------------------------------------+  |
+----------------------------------------------------+

B. Next-Gen WAF Defenses via Cloud Armor
To protect backends, we delegate security to Google's Edge. Cloud Armor acts as a Layer 7 shield, filtering threats before they ever reach our compute instances.


              Inbound Web Traffic
                      |
                      v
       +-------------------------------+
       | Global HTTP Load Balancer     | 
       +--------------+----------------+
                      |
       +--------------v----------------+
       | Cloud Armor Security Policy   |  (L7 Filtering)
       | -> Blocks SQLi, XSS, LFI      |
       +--------------+----------------+
                      |
                      v (Sanitized Traffic)
+---------------------+-----------------------------------+
| Principal VPC                                           |
|   +-------------------------------------------------+   |
|   | Subnet                                          |   |
|   | Firewall: Allow ONLY Google LB IPs              |   |
|   |           (130.211.0.0/22 & 35.191.0.0/16)      |   |
|   |                                                 |   |
|   |   +-----------------------------------------+   |   |
|   |   | Managed Instance Group (MIG)            |   |   |
|   |   |  [ Apache Web Server VM - Debian 11 ]   |   |   |
|   |   +-----------------------------------------+   |   |
|   +-------------------------------------------------+   |
+---------------------------------------------------------+

Checkov: Closing the Governance Loop In a production workflow, compliance is vital. When integrating tools like Checkov, it is common to trigger security alerts. Antigravity helped us apply the Principle of Least Privilege, replacing default accounts with dedicated IAM Service Accounts.

For cases where the design required specific exceptions, the agent injected formal suppression syntax:

Terraform resource "google_compute_instance" "public_instance" { # checkov:skip=CKV_GCP_40: Public IP explicitly required for administrative bastion # checkov:skip=CKV_GCP_32: OS Login bypass authorized for this specific use-case name = "bastion-dev" machine_type = "e2-micro" ... }
Each exception was evaluated during the design phase and documented inline to preserve traceability and facilitate future audits.

The Future of Infrastructure The paquetesaction project demonstrates that the future of the cloud is hybrid: human strategic judgment amplified by AI execution speed. Our next steps involve expanding toward Vertex AI and consolidating security operations with Mandiant.

The infrastructure is code, and AI is its most powerful catalyst!

⚖️ Technical & Legal Safe Harbor Disclaimer
AUTHORSHIP AND INDEPENDENT CAPACITY: This publication is authored solely by me in my individual and private capacity. The views, methodologies, and technical workflows expressed herein are my own and do not necessarily reflect the official policy, position, or strategic direction of my current or former employers, clients, or any legal entity I am affiliated with.

INTELLECTUAL PROPERTY & CONFIDENTIALITY COMPLIANCE:

Zero Proprietary Disclosure: This content has been developed using publicly available information and personal research. No confidential information or internal proprietary source code belonging to any specific organization has been disclosed.

Independent Development: The workflows described are based on general industry best practices and were not developed as a "work for hire".

LIMITATION OF LIABILITY (NO WARRANTY): All code snippets and architectural patterns are provided "AS IS" without warranty of any kind.

COMPLIANCE: This contribution is made in good faith under the MIT-0 License for any included source code patterns.