Cloud

Cloud#

The cloud is where the operator stands up campaign infrastructure on demand and tears it down clean: redirectors, C2 planes, collection workers, defended estates, analyst boxes. It is also where most targets and adversary infrastructure now live. The major providers (AWS, Google Cloud, and Azure) offer the same core building blocks under different names; knowing the taxonomy lets the operator move between them, recognize what they are looking at on target, and choose the platform that fits the mission’s authorization, latency, and attribution constraints.

        mindmap
  root((Cloud<br/>Building Blocks))
    Compute
      VMs
      Containers
      Serverless
      Batch
    Storage
      Object
      Block
      File
      Archive
    Database
      Relational
      NoSQL
      Cache
      Warehouse
    Network
      VPC
      Load Balancer
      CDN
      DNS
    Identity
      IAM
      Workload Identity
      Secrets
    Observability
      Logs
      Metrics
      Traces
    Messaging
      Queues
      Streams
      Pub-Sub
    Security
      WAF
      KMS
      Audit Logs

The Big Three#

The cloud providers an operator picks among first. AWS has the broadest catalog and longest history; GCP is strongest in Kubernetes, data, and ML; Azure leads in enterprise and Microsoft-stack integration. Each shares the same building blocks under different names.

AWS, the largest, broadest catalog.
Google Cloud (GCP), strong in Kubernetes, data, ML.
Azure, deep enterprise + Microsoft ecosystem integration.

Honorable mentions include Cloudflare, DigitalOcean, Linode, Hetzner, Fly.io, Render, Vercel, and Netlify; often a better fit for smaller workloads or specific use cases.

Service Models#

The cloud is sold in layers. Each model raises the abstraction and shifts more of the stack from the operator to the provider, in exchange for less control over the underlying machinery. The operator picks the model that fits the workload’s authorization, latency, and attribution needs.

Layer	on-prem	IaaS	CaaS	PaaS	FaaS	SaaS
Data	operator	operator	operator	operator	operator	operator
Application	operator	operator	operator	operator	operator	provider
Runtime / middleware	operator	operator	operator	provider	provider	provider
Operating system	operator	operator	provider	provider	provider	provider
Virtualisation	operator	provider	provider	provider	provider	provider
Hardware / network	operator	provider	provider	provider	provider	provider

        flowchart LR
  IAAS[IaaS] --> EC2[AWS EC2]
  IAAS --> GCE[GCP Compute Engine]
  IAAS --> AVM[Azure VMs]
  IAAS --> VSP["VMware vSphere VMs (vCenter)"]
  CAAS["CaaS / containers"] --> ECS["AWS ECS, EKS"]
  CAAS --> GKE["GCP GKE, Cloud Run"]
  CAAS --> AKS["Azure AKS, Container Apps"]
  CAAS --> TKG[VMware Tanzu Kubernetes Grid]
  PAAS[PaaS] --> EB[AWS Elastic Beanstalk]
  PAAS --> APE[GCP App Engine]
  PAAS --> APS[Azure App Service]
  PAAS --> TAS[VMware Tanzu Application Service]
  FAAS[FaaS] --> LAM[AWS Lambda]
  FAAS --> CF[GCP Cloud Functions]
  FAAS --> AF[Azure Functions]
  FAAS --> OF["OpenFaaS on Tanzu (self-hosted)"]
  SAAS[SaaS] --> EX["Workspace, M365, Salesforce, Workspace ONE"]

IaaS, raw VMs and storage. Maximum control, maximum operator burden. The choice when a campaign needs the kernel, custom drivers, or a specific networking stack. AWS EC2, GCP Compute Engine, Azure VMs, vSphere VMs managed by vCenter.
CaaS, managed container runtime. The operator owns the image; the provider owns the host and the scheduler. The current default for stateful operator-built capability. AWS ECS / EKS, GCP GKE / Cloud Run, Azure AKS / Container Apps, VMware Tanzu Kubernetes Grid on vSphere.
PaaS, the operator hands over source or a build artifact and the provider runs it. Fast to stand up, brittle to escape if the provider’s runtime constraints bite mid-engagement. AWS Elastic Beanstalk, GCP App Engine, Azure App Service, VMware Tanzu Application Service.
FaaS, functions invoked on events. Per-millisecond billing, no idle cost. Right for sparse workloads, a webhook, a redirector health check, an enrichment side car. AWS Lambda, GCP Cloud Functions, Azure Functions. VMware ships no first-party FaaS; self-host OpenFaaS or Knative on Tanzu when the workload calls for it.
SaaS, the operator only owns data and configuration. Mail, chat, ticketing, document stores, endpoint management. The most common target class on modern engagements (M365, Workspace, Salesforce, Slack, VMware Workspace ONE).

Service Taxonomy#

The cross-cloud Rosetta stone. Each capability has a standard implementation per provider; knowing the names makes architecture documents portable. The table below is the lookup an operator runs when translating a customer’s Azure stack into an AWS proposal or vice versa.

Capability	AWS	GCP	Azure
VMs	EC2	Compute Engine	Virtual Machines
Managed Kubernetes	EKS	GKE	AKS
Serverless functions	Lambda	Cloud Functions / Run	Functions / Container Apps
Object storage	S3	Cloud Storage	Blob Storage
Block storage	EBS	Persistent Disk	Managed Disks
Managed Postgres	RDS / Aurora	Cloud SQL / AlloyDB	Database for PostgreSQL
NoSQL	DynamoDB	Firestore / Bigtable	Cosmos DB
Cache	ElastiCache	Memorystore	Cache for Redis
Message queue	SQS	Pub/Sub / Tasks	Service Bus / Queue Storage
Streaming	Kinesis / MSK	Pub/Sub / Dataflow	Event Hubs
Identity	IAM	IAM	Entra ID / RBAC
Secrets	Secrets Manager / SSM	Secret Manager	Key Vault
DNS	Route 53	Cloud DNS	Azure DNS
CDN	CloudFront	Cloud CDN	Front Door / CDN
Load balancer	ELB / ALB / NLB	Cloud Load Balancing	Load Balancer / App Gateway
Logging	CloudWatch Logs	Cloud Logging	Monitor Logs
Metrics	CloudWatch	Cloud Monitoring	Monitor Metrics
Tracing	X-Ray	Cloud Trace	Application Insights
Data warehouse	Redshift	BigQuery	Synapse

VMware vSphere does not slot cleanly into this matrix because most of its services are infrastructure primitives rather than managed platforms. The rough equivalents are vSphere VMs for compute, vSAN for object and block storage, NSX-T for VPC and load balancing, vCenter SSO for identity, and Tanzu for managed Kubernetes. The operator wires the higher-level capabilities themselves.

Deployment Models#

The deployment model is the trust boundary. The operator picks where the substrate sits, who else shares it, and what crosses the seam between premises.

        flowchart LR
  subgraph public[Public]
    PA[provider region]
  end
  subgraph private[Private]
    PR["vSphere cluster behind vCenter, or dedicated tenancy"]
  end
  subgraph hybrid[Hybrid]
    direction LR
    H1[on-prem vCenter] <-->|VPN / Direct Connect / HCX| H2[provider region]
  end
  subgraph multi[Multi-cloud]
    direction LR
    M1[AWS] <--> M2[GCP]
    M2 <--> M3[Azure]
    M3 <--> M4[VMware Cloud on AWS]
  end

Public, provider owns the substrate; the operator rents capacity. AWS, GCP, Azure default regions. The standard choice for ephemeral campaign infrastructure where attribution sits on the redirector layer above.
Private, single-tenant on dedicated hardware. VMware vSphere managed by vCenter is the most common implementation in the enterprise. Provider-flavoured equivalents include AWS Outposts, Azure Stack HCI, and GCP Anthos on bare metal. The choice when data must not leave the operator’s premise.
Hybrid, workload spans private and public, joined by a VPN or direct interconnect (AWS Direct Connect, GCP Cloud Interconnect, Azure ExpressRoute) or by VMware HCX for warm migrations between vCenter and a hyperscaler. Standard on enterprise targets and on engagements where collection happens on-prem and analysis happens in the cloud.
Multi-cloud, workload runs on more than one provider on purpose. AWS plus GCP plus Azure for resilience or cost arbitrage; or vSphere plus VMware Cloud on AWS for a single control plane across on-prem and public. Wins are resilience to a single-vendor outage, cost arbitrage, and jurisdictional dispersion.
Community, shared by organizations with common requirements. AWS GovCloud, Azure Government, GCP Assured Workloads, VMware Sovereign Cloud providers. The trust boundary is the community’s membership rules.

Reference Architectures#

The recurring shapes the operator runs into, both as a target on recon and as a builder of operator-grade capability. Each pattern is provider-agnostic; the names change, the topology does not. Service mappings below cover AWS, GCP, Azure, and the VMware vSphere / Tanzu stack on vCenter.

Three-tier web#

The textbook web application. CDN fronts a load balancer; the web tier serves static and forwards dynamic to an app tier; the app tier reads and writes a primary database with a cache in front and read replicas behind. The default shape for in-house line-of- business apps.

        architecture-beta
    group edge(cloud)[Edge]
    group webtier(cloud)[Web Tier]
    group apptier(cloud)[App Tier]
    group data(cloud)[Data]

    service client(internet)[Client]
    service cdn(cloud)[CDN] in edge
    service lb(cloud)[Load Balancer] in edge
    service web(server)[Web] in webtier
    service app(server)[App] in apptier
    service cache(disk)[Cache] in data
    service db(database)[Primary DB] in data
    service rr(database)[Read Replica] in data

    client:R --> L:cdn
    cdn:R --> L:lb
    lb:R --> L:web
    web:R --> L:app
    app:B --> T:cache
    app:R --> L:db
    db:B --> T:rr

Layer	AWS	GCP	Azure	vSphere / Tanzu
CDN	CloudFront	Cloud CDN	Front Door	VMware NSX Advanced LB or third-party
Load balancer	ALB	Cloud Load Balancing	App Gateway	NSX Advanced LB (Avi)
Web / app tier	EC2 + ASG	Compute Engine MIG	VMSS	vSphere VMs + DRS
Cache	ElastiCache	Memorystore	Cache for Redis	Redis on vSphere VM
Primary DB	RDS / Aurora	Cloud SQL	DB for PostgreSQL	PostgreSQL on vSphere VM

Microservices#

Many small services behind an API gateway, each owning its own data store. Inter-service traffic splits between synchronous RPC and asynchronous events on a bus. The standard greenfield shape on top of Kubernetes.

        architecture-beta
    group services(cloud)[Services]
    group data(cloud)[Data]

    service client(internet)[Client]
    service gw(cloud)[API Gateway]
    service auth(server)[Auth] in services
    service ord(server)[Order] in services
    service pay(server)[Payment] in services
    service inv(server)[Inventory] in services
    service authdb(database)[AuthDB] in data
    service orddb(database)[OrderDB] in data
    service paydb(database)[PaymentDB] in data
    service invdb(database)[InventoryDB] in data
    service bus(disk)[Event Bus]

    client:R --> L:gw
    gw:R --> L:auth
    gw:R --> L:ord
    gw:R --> L:pay
    gw:R --> L:inv
    auth:B --> T:authdb
    ord:B --> T:orddb
    pay:B --> T:paydb
    inv:B --> T:invdb
    ord:R --> L:bus
    bus:R --> L:pay
    bus:R --> L:inv

Layer	AWS	GCP	Azure	vSphere / Tanzu
API gateway	API Gateway	API Gateway / Apigee	API Management	Tanzu Service Mesh ingress
Service runtime	EKS / ECS Fargate	GKE / Cloud Run	AKS / Container Apps	Tanzu Kubernetes Grid
Event bus	EventBridge / MSK	Pub/Sub	Event Grid / Service Bus	RabbitMQ on Tanzu (VMware Tanzu RabbitMQ)
Per-service DB	DynamoDB / Aurora	Firestore / Cloud SQL	Cosmos DB / SQL DB	Cassandra or Postgres on Tanzu

Serverless web#

CDN serves static assets directly from object storage; an API gateway fronts functions; functions read and write a document store and fan out to a queue for asynchronous work. No always-on servers. The cheapest shape for sparse traffic.

        architecture-beta
    group edge(cloud)[Edge]
    group functions(cloud)[Functions]
    group data(cloud)[Data]

    service client(internet)[Client]
    service cdn(cloud)[CDN] in edge
    service apigw(cloud)[API Gateway] in edge
    service bucket(database)[Static Bucket] in data
    service read(server)[Read Fn] in functions
    service write(server)[Write Fn] in functions
    service worker(server)[Worker Fn] in functions
    service store(database)[Document Store] in data
    service queue(disk)[Queue]

    client:R --> L:cdn
    cdn:R --> L:bucket
    cdn:B --> T:apigw
    apigw:R --> L:read
    apigw:R --> L:write
    read:B --> T:store
    write:B --> T:store
    write:R --> L:queue
    queue:R --> L:worker

Layer	AWS	GCP	Azure	vSphere / Tanzu
CDN	CloudFront	Cloud CDN	Front Door	NSX ALB or third-party
Static site	S3	Cloud Storage	Blob Storage	MinIO on Tanzu
API gateway	API Gateway	API Gateway	API Management	Knative ingress on Tanzu
Functions	Lambda	Cloud Functions	Functions	OpenFaaS or Knative on Tanzu
Document store	DynamoDB	Firestore	Cosmos DB	Cassandra on Tanzu
Queue	SQS	Pub/Sub / Tasks	Service Bus	VMware Tanzu RabbitMQ

Event-driven#

Producers publish events to a bus or log; consumers subscribe. Decouples writers from readers, makes the bus the system of record, and lets a stream processor land enriched data in a lake. The default shape for telemetry, audit, and any workload where the write rate exceeds the read rate.

        architecture-beta
    group producers(cloud)[Producers]
    group consumers(cloud)[Consumers]

    service p1(server)[Producer A] in producers
    service p2(server)[Producer B] in producers
    service bus(disk)[Event Bus]
    service c1(server)[Consumer X] in consumers
    service c2(server)[Consumer Y] in consumers
    service sp(server)[Stream Processor] in consumers
    service lake(database)[Data Lake]

    p1:R --> L:bus
    p2:R --> L:bus
    bus:R --> L:c1
    bus:R --> L:c2
    bus:R --> L:sp
    sp:B --> T:lake

Layer	AWS	GCP	Azure	vSphere / Tanzu
Event bus / log	Kinesis / MSK	Pub/Sub	Event Hubs	Kafka on Tanzu (Tanzu Data Services)
Stream processor	Kinesis Data Analytics	Dataflow	Stream Analytics	Flink on Tanzu
Data lake	S3 + Glue + Athena	GCS + BigQuery	ADLS + Synapse	MinIO + Trino on Tanzu

Hub and spoke#

The standard enterprise network topology in the cloud. A hub VPC holds shared services (egress proxy, DNS, identity); spoke VPCs hold workloads. Spokes never talk directly; transit routes through the hub. The pattern lets the operator centralise inspection, audit, and egress without bottlenecking workload deployments.

        flowchart TB
  HUB["Hub VPC, shared services"]
  HUB --- S1["Spoke: prod"]
  HUB --- S2["Spoke: stage"]
  HUB --- S3["Spoke: dev"]
  HUB -->|transit gateway / NVA| ONPREM[On-prem vCenter]
  HUB --> EGRESS[Egress proxy]

Layer	AWS	GCP	Azure	vSphere / NSX
Hub / transit	Transit Gateway	Network Connectivity Center	Virtual WAN	NSX-T Tier-0 gateway
Spoke VPC / VNet	VPC	VPC	VNet	NSX-T Tier-1 segment
East-west inspection	GWLB + appliance	Cloud NGFW	Azure Firewall	NSX Distributed Firewall
On-prem link	Direct Connect	Cloud Interconnect	ExpressRoute	VMware HCX

Multi-region active-passive#

Primary region serves all traffic; a standby region holds a warm copy, brought online by DNS failover when the primary fails. Cheaper than active-active, slower to recover, and only as good as the replication lag at the moment of failure. The pragmatic disaster-recovery default for most workloads.

        architecture-beta
    group regionA(cloud)[Region A active]
    group regionB(cloud)[Region B standby]

    service client(internet)[Client]
    service dns(cloud)[Geo DNS]
    service app1(server)[App] in regionA
    service db1(database)[DB] in regionA
    service app2(server)[App] in regionB
    service db2(database)[DB] in regionB

    client:R --> L:dns
    dns:R --> L:app1
    dns:R --> L:app2
    app1:B --> T:db1
    app2:B --> T:db2
    db1:R --> L:db2

Layer	AWS	GCP	Azure
DNS failover	Route 53 health checks	Cloud DNS routing policies	Traffic Manager
DB replication	Aurora Global Database	Cloud SQL cross-region replica	SQL Geo-Replication
Object replication	S3 Cross-Region Replication	GCS dual-region or turbo replication	Storage GRS / RA-GRS

On vSphere, the same shape uses VMware Site Recovery Manager (SRM) replicating between two vCenter sites, with global DNS failover handled by a load balancer or an external service.

Multi-region active-active#

Every region serves traffic; replication is bidirectional. Lowest latency, highest cost, hardest to reason about (conflict resolution, split brain, global-versus-region consistency). Pick only when the workload demands it (global low-latency reads, write-anywhere requirements).

        architecture-beta
    group regionEU(cloud)[Region EU]
    group regionUS(cloud)[Region US]

    service clientEU(internet)[Client EU]
    service clientUS(internet)[Client US]
    service dns(cloud)[Geo Anycast DNS]
    service appEU(server)[App] in regionEU
    service dbEU(database)[DB] in regionEU
    service appUS(server)[App] in regionUS
    service dbUS(database)[DB] in regionUS

    clientEU:R --> L:dns
    clientUS:R --> L:dns
    dns:R --> L:appEU
    dns:R --> L:appUS
    appEU:B --> T:dbEU
    appUS:B --> T:dbUS
    dbEU:R --> L:dbUS
    dbUS:L --> R:dbEU

Layer	AWS	GCP	Azure
Global front	Global Accelerator + CloudFront	Global External LB	Front Door
Globally distributed DB	DynamoDB global tables	Spanner	Cosmos DB multi-region writes
Object storage	S3 Multi-Region Access Points	GCS dual-region	Cosmos DB / multi-region Blob

VMware does not offer a turn-key active-active across two vCenters; the operator either layers a globally distributed database on top (Cassandra, CockroachDB) or pairs vSphere with a hyperscaler service for the global tier.

Identity and Access#

Cloud IAM is policy-driven. Three concepts worth getting right:

Principals, users, groups, service accounts, machine identities.
Roles / policies, declarative grants of permissions.
Resource-based policies, attached to the resource itself (S3 buckets, KMS keys).

Best practices:

Least privilege, grant only what’s needed; expand when something fails.
No long-lived static credentials in code or images. Use IAM roles, workload identity, OIDC federation.
Separate accounts / projects / subscriptions per environment for blast-radius control.
Audit logs always on, exported off the account they describe.

Cost Management#

The discipline that prevents cloud bills from becoming the quarterly surprise. Consistent tagging attributes spend; right-sizing fights chronic over-provisioning; lifecycle policies move cold data to cheap tiers; commit discounts buy 30-70% off list; egress is the line item to watch.

Tag everything with env, owner, cost-center so spend can be attributed.
Right-size: most VMs are over-provisioned. Use auto-scaling and start small.
Lifecycle storage, transition cold data to cheaper tiers (S3 IA / Glacier, Coldline, Archive).
Commit for predictable workloads, savings plans / committed use discounts / reservations.
Watch egress, inter-region and outbound bandwidth is often the surprise line item.

Reliability Primitives#

The geographic units cloud providers expose. Availability Zones are independently powered facilities within a region; regions are geographically separate; multi-region deployments cross both axes for disaster recovery and latency, at significantly higher complexity and cost.

Availability Zones, separately powered/cooled facilities within a region. Run replicas across AZs.
Regions, geographically separate; cross-region replication for disaster recovery.
Multi-region, use only when you need it. Latency, consistency, and cost get significantly harder.