Build a Cloud Landing Zone

Give every other Pulumi project in your cloud account a consistent, pre-built foundation (shared network, identity, key store, audit logs) so downstream stacks adopt it by name instead of rebuilding it every time.

Step 1 of 1

Choose cloud

Choose an option to continue.

Frequently asked questions

What prerequisites does this blueprint need?
A Pulumi account with the Pulumi CLI, a cloud account or subscription or project where you can create networking, IAM, key, and audit resources, and the language toolchain for the variant you chose (Node, Python, or Go).
How do I add more workload identities later?
The reusable component exposes the two default identities (deployer and read-only) as outputs. Define additional IAM role / managed identity / service account resources in the same program, attach the policies you need, and export them as new stack outputs. The Add another identity section on this page shows the exact shape for each cloud.
Does this land audit logs in a SIEM?
No. This blueprint writes audit logs to a retention bucket in the same cloud account so you have a durable record out of the box. The Audit logging section points to the provider features you would layer on to forward those logs to Splunk, Datadog, Sumo, or a custom SIEM.
Can I reuse this outside the blueprint?
Yes. The LandingZone component is the unit meant for reuse. Import it into another Pulumi project, or publish the whole stack and consume its outputs from other stacks through Pulumi ESC or StackReference.
What scope does this guide target?
One cloud account, subscription, or project. The resources here are the building blocks every team needs inside that scope. When you are ready to wire them into a cloud organization, extend the same Pulumi project with the aws.organizations, azure-native.billing, or gcp.organizations resources you need; everything this blueprint provisions stays in place.
What does this cost?
NAT gateways, KMS keys, audit log storage, and identity evaluations all create charges even when no workloads are running. Inspect the blueprint and the tags it applies before deploying to a billed account.
What can I deploy on top of a landing zone?
Two blueprints in this catalog consume these outputs directly. The managed Kubernetes blueprint stands up an opinionated EKS / AKS / GKE cluster on the landing-zone network. The serverless React + Postgres blueprint deploys a full-stack demo app (React SPA + serverless API + managed PostgreSQL) inside the same account. Both read networkId, privateSubnetIds, and secretsStore through StackReference and fail fast at preview time if the landing-zone stack is missing.