DEV Community

Amit Malhotra
Amit Malhotra

Posted on • Originally published at buoyantcloudtech.com

What a Fractional GCP Architect Actually Does (And When You Need One)

There's a hiring pattern I see a lot in B2B SaaS companies at the 50–200 employee stage: engineering is moving fast, the cloud infrastructure is getting complex, but it's not quite time to hire a full-time Principal Cloud Architect.
That's exactly where fractional cloud architecture fits.
I'm Amit Malhotra, a Principal GCP Architect and founder of Buoyant Cloud. I embed with SaaS engineering teams as a fractional GCP architect — bringing senior-level cloud expertise scoped to what the team actually needs, when they need it.

What fractional actually means in practice
Fractional isn't a watered-down engagement. It's a scoped one.
You get a senior architect who has designed and shipped production GCP infrastructure across industries — not someone learning on your dime. The difference is the model: instead of a full-time hire or a 12-month consulting contract, you get focused, high-impact work tied to your current priorities.
That might look like:

Designing and building a GCP landing zone from scratch
Hardening a GKE cluster ahead of a SOC 2 audit
Replacing service account keys with Workload Identity Federation across your CI/CD pipeline
Investigating and resolving a sudden spike in cloud costs
Setting up a DevSecOps pipeline that your team can actually own and maintain

After the core engagement, many clients keep me on retainer — PR reviews, architecture advisory, and course-correcting before small decisions become expensive problems.

The stack I bring to every engagement
IaC: Terraform with a modular structure — separate modules for networking, GKE, IAM, and services. Terragrunt for DRY configuration across environments.
Identity & Access: Workload Identity Federation over service account keys, always. WIF eliminates an entire class of credential exposure risk at the CI/CD layer.
Networking: Shared VPC with host/service project separation. VPC Service Controls for clients touching regulated data or going through SOC 2. Private Google Access on by default.
Secrets: Secret Manager with versioning and automatic rotation where possible — injected at runtime via WIF, never baked into images or plaintext environment variables.
CI/CD: Cloud Build or GitHub Actions depending on where the team already lives. Artifact Registry for container images. Binary Authorization for production workloads.
Observability: Cloud Monitoring and Cloud Logging as the baseline. Prometheus + Grafana on GKE where teams want more control. OpenTelemetry for instrumentation.

How I structure every engagement — the SCALE Framework
Every engagement I run is grounded in the SCALE Framework:

S — Security by Design (not bolted on post-launch)
C — Cloud-Native architecture (managed services over self-managed where it makes sense)
A — Automation & IaC (everything in code, nothing clicked in console)
L — Lifecycle Ops (Day 2 operations planned from Day 0)
E — Elastic Scalability (design for growth without redesign)

It's the pattern I kept seeing in every successful infrastructure build versus every one that needed to be rebuilt six months later.

What I'm writing about here
Practical, implementation-level content from real engagements:

GKE hardening walkthroughs
Terraform patterns for GCP landing zones
Workload Identity Federation end-to-end
VPC Service Controls deep dives
Kong API Gateway on GKE — real configs
SOC 2 on GCP — mapping controls to actual infrastructure

Long-form guides live on buoyantcloudtech.com/blog.

Let's connect
If you're a CTO or engineering lead evaluating whether fractional cloud architecture is the right fit for your stage — or dealing with a specific GCP challenge right now — I'd love to talk. buoyantcloudtech.com or connect on LinkedIn.

Top comments (0)