Issue #114

Read about infrastructure and programming topics and news every week

---

Below is a practical, AWS-centric comparison to help you map what you already know about AWS to Google Cloud Platform (GCP), with an emphasis on how GCP approaches things differently, not just service names.

1. High-level philosophy: Core strength

• AWS: Breadth and enterprise maturity

• GCP: Data, analytics, ML, and networking

• Mental model

  • AWS: Everything is a service

  • GCP: Everything is a managed platform

• Defaults

  • AWS: Many knobs, lots of choices

  • GCP: Opinionated, sane defaults

• Org structure

  • AWS: Accounts

  • GCP: Organizations → Folders → Projects

Key shift:

AWS gives you flexibility first; GCP gives you “consistency and global primitives first”.

2. Core service mapping (AWS → GCP)

Compute

• EC2 → Compute Engine

  • GCP VMs are simpler, with less instance sprawl

• Auto Scaling Groups → Managed Instance Groups (MIGs)

  • Tighter integration with load balancers and health checks

• ECS / EKS → GKE

  • GKE is the flagship GCP product

• Lambda → Cloud Functions / Cloud Run

  • Cloud Run is closer to Fargate + Lambda than classic Lambda

👉 Big difference:

Cloud Run runs containers serverlessly, scales to zero, HTTP-native. Very different from Lambda’s function-first model.

Networking (this is where GCP shines)

• VPC (regional) → VPC (global)

  • One GCP VPC spans all regions

• Subnets (AZ-scoped) → Subnets (regional)

  • Still regional, but cleaner and simpler to manage

• ALB / NLB → Cloud Load Balancer

  • Fully global, anycast by default

• Route 53 → Cloud DNS

  • Simpler service with fewer features

• NAT Gateway → Cloud NAT

  • Fully managed, no per-AZ setup required

👉 Mindset change:

In GCP, networking is global by default, not stitched together regionally.

Storage & Databases

• S3 → Cloud Storage

  • Very similar services; GCS is slightly simpler

• EBS → Persistent Disk

  • Strong performance with simple, predictable pricing

• RDS → Cloud SQL

  • Fewer engines, but very managed

• DynamoDB → Firestore / Bigtable

  • Firestore is not DynamoDB — it’s more opinionated

• Aurora → Spanner

  • Spanner offers global consistency (this is a huge deal)

👉 Spanner ≠ Aurora

Spanner gives global SQL + strong consistency—no AWS equivalent.

IAM & Security

• IAM Policies → IAM Roles & Bindings

  • GCP IAM is resource-centric, not identity-centric

• STS → Workload Identity

  • Much cleaner model for Kubernetes

• KMS → Cloud KMS

  • Largely comparable services

👉 GCP IAM feels simpler but stricter. Less JSON policy hell.

3. Projects vs Accounts (important!)

• AWS

  • Account = billing, isolation, and IAM boundary

• GCP

  • Project = atomic unit

    • Billing

    • APIs

    • IAM

    • Quotas

You usually create many small projects rather than a few large accounts.

Org

└── Folder (team/env)

└── Project (service/app)

👉 This leads to cleaner blast-radius control than AWS accounts.

---

4. Kubernetes: EKS vs GKE

If you like Kubernetes, GCP will feel more natural.

• Control plane

  • EKS: Paid, semi-managed

  • GKE: Fully managed

• Node upgrades

  • EKS: Manual-ish

  • GKE: Automated

• Networking

  • EKS: Complex (CNI)

  • GKE: Native VPC integration

• IAM

  • EKS: IAM + IRSA

  • GKE: Native Workload Identity

GKE feels like Kubernetes as a product, not just infra.

5. Data & Analytics (GCP’s superpower)

• Redshift / Athena → BigQuery

  • BigQuery replaces both Redshift (warehouse) and Athena (ad-hoc queries)

• EMR → Dataproc

  • Managed Spark / Hadoop

• Glue → Dataflow

  • Serverless data processing pipelines

👉 BigQuery is serverless, insanely fast, and dead simple to use.

Many companies adopt GCP only for BigQuery.

6. Pricing & ops differences

• Discounts

  • AWS: Reserved Instances, Savings Plans

  • GCP: Automatic sustained-use discounts

• Billing

  • AWS: Complex

  • GCP: More transparent

• Free tiers

  • AWS: Many small ones

  • GCP: Generous and practical

GCP pricing is generally less micro-managed.

7. Tooling & UX

• Console

  • AWS: Powerful but cluttered

  • GCP: Clean and fast

• CLI

  • AWS: aws

  • GCP: gcloud

• Infrastructure as Code (IaC)

  • AWS: CloudFormation

  • GCP: Deployment Manager (rarely used)

👉 On GCP, Terraform is king.

8. When GCP feels better than AWS

• Kubernetes-heavy platforms

• Global services with low latency

• Data / ML pipelines

• Smaller teams who want less infra ceremony

When AWS still wins

• Huge enterprise ecosystems

• Edge services & marketplace

• Ultra-specialised managed services

• Regulated industries (sometimes)

9. Mental model cheat sheet (AWS → GCP)

• Which region? → Usually irrelevant

• Which VPC? → One global VPC

• Which service? → Probably fewer choices

• How do I glue this together? → It is already integrated

TL;DR for an AWS-experienced engineer

GCP is less flexible and more opinionated, but faster to build and harder to screw up.

If AWS feels like Lego, GCP feels like IKEA furniture with fewer missing parts.

---

Caught in the Middle: The New Role of Platform Teams

In this piece, I see platform teams described in a way that closely matches my day-to-day reality: we’re no longer just building infrastructure, we’re sitting at the intersection of security, compliance, finance and application teams, expected to explain outcomes we didn’t directly control. As systems scale and ownership becomes fragmented, platform teams end up with the most complete operational context but without the authority to set policy, budgets or priorities. That creates an accountability gap in which we’re asked to justify cost decisions, security posture, compliance behaviour, or even AI-driven changes simply because our workflows connect everything. The article argues—and I agree—that organisations need to recognise platform engineering as a coordination and decision-making function, support it with clearer ownership, earlier involvement in governance, better decision traceability, and the ability to push back when constraints conflict, rather than treating platform teams as infrastructure providers alone.

https://thenewstack.io/caught-in-the-middle-the-new-role-of-platform-teams/

New Linux malware targets the cloud, steals creds, and then vanishes

VoidLink is a newly discovered, highly advanced Linux malware framework that targets Linux cloud servers and container environments rather than traditional desktops. It was first observed in samples collected by researchers at the cybersecurity firm Check Point in late 2025 and was publicly reported in January 2026.

⚙️ Key Characteristics

📍 Cloud-native and modular

• VoidLink is built as a framework, not just a single malware binary — meaning it’s a platform that attackers can extend with modules/plugins.

• It includes custom loaders, implants, rootkits, and at least 30 plugins that can be loaded as needed.

☁️ Cloud & container awareness

• It detects whether it’s running in cloud environments or containers such as Docker or Kubernetes, and also identifies the cloud provider (e.g., AWS, Azure, Google Cloud, Alibaba, Tencent).

• This allows it to adapt its behaviour for stealth and effectiveness in those environments.

🧠 Stealth and evasion

• VoidLink employs advanced anti-forensics and anti-analysis capabilities: rootkits that hide processes, network sockets, and files; self-deletion if tampering is detected; and log and history wiping.

• It uses custom encrypted communication channels and adaptive behaviours to blend in with legitimate traffic.

📌 Rich functionality

The framework provides modules covering:

• System and environment reconnaissance

• Credential theft (SSH keys, API tokens)

• Lateral movement and tunnelling

• Privilege escalation and persistence

• Container escape helpers

• Anti-forensics and log cleanup

This breadth makes VoidLink far more capable than typical Linux malware has historically been.

🧑‍💻 Origin & Purpose

• The malware samples include development artefacts, debug symbols, and Chinese-localised interfaces, suggesting authors are Chinese-speaking and that the framework is still under active development.

• There’s no evidence yet of widespread active infections in the wild; researchers aren’t sure if it’s intended for use as a commercial red-team tool, sold to other attackers, or used by a specific threat actor.

🔍 Broader Context

• Linux malware has historically been less common than Windows, but the shift toward cloud-native architectures means attackers increasingly target Linux infrastructure directly.

• VoidLink reflects this trend: it’s built for cloud-first environments and demonstrates a level of sophistication more often associated with professional threat actors.

📌 What This Means for Defenders

Even though no active infections have been publicly observed yet, the discovery of VoidLink is a warning sign:

• Organisations with Linux servers in public cloud or container environments should assume attackers are developing more potent Linux-specific threats.

• Best practices such as strong access controls, anomaly monitoring, vulnerability patching, and EDR solutions tailored to Linux/cloud workloads become even more critical.

Buy servers now or cry later: DRAM price spike threatens infrastructure budgets

https://www.theregister.com/2026/01/14/dram_infrastructure_costs/

---