Network Architecture
When Fractal Cloud initializes an environment, it deploys a hub-and-spoke network topology that follows each cloud vendor's recommended landing zone architecture. This page explains what gets deployed, why, and how the network scales as you add operational environments.
Why Hub-and-Spoke?
Hub-and-spoke is the network architecture prescribed by the major cloud adoption frameworks:
| Cloud Vendor | Framework | Prescribed Pattern |
|---|---|---|
| AWS | Cloud Adoption Framework / Well-Architected Framework | Hub-and-Spoke with Transit Gateway |
| Azure | Cloud Adoption Framework / Landing Zone Accelerator | Hub-and-Spoke with VNet Peering |
| GCP | Cloud Foundation Toolkit / Landing Zone Blueprint | Shared VPC (Host Network) with Cloud NAT |
The core principles are the same across all vendors:
- Centralized egress — all outbound internet traffic flows through a single, auditable point in the hub, where firewalls, NAT, and logging can be applied uniformly.
- Centralized ingress — inbound traffic enters through the hub, where load balancers, WAFs, and API gateways provide a governed entry point.
- Network segmentation — each operational environment runs in its own isolated network (spoke). Spokes cannot communicate directly with each other unless explicitly routed through the hub.
- Shared services — the hub hosts infrastructure that all environments need: DNS resolution, observability collectors, SIEM integrations, and the Fractal Cloud Agents themselves.
Environment Hierarchy and Network Topology
Fractal Cloud organizes infrastructure into two levels of environments:
Management Environment
The Management Environment is the root of the hierarchy. When initialized, it provisions:
- A hub network with centralized internet egress and ingress
- A platform network where the Cloud Agents and shared platform services run
- A connectivity layer that connects the hub to the platform network and to all future operational environment spokes
The Management Environment is the only environment where Cloud Agents are deployed. These agents manage resources both in the management environment itself and in all child operational environments.
Operational Environments
Operational Environments are children of a Management Environment. They represent isolated boundaries for business capabilities, subdomains, or workload tiers (development, staging, production).
Each Operational Environment gets:
- Its own cloud account (AWS Account, Azure Subscription, GCP Project) placed under the Management Environment's organizational unit
- Service accounts that allow the parent Management Environment's agents to manage resources within it
- Its own spoke network connected back to the hub for cross-environment communication and internet access
- Private service endpoints to keep traffic to cloud provider services off the public internet
Operational Environments do not run their own agents. The agents in the parent Management Environment orchestrate all infrastructure within each child environment.
The Full Topology
Management Environment
├── Hub Network ─── Centralized internet egress/ingress
├── Platform Network ─── Cloud Agents, databases, shared services
│ ↕ connectivity layer
├── Operational Environment A ─── Spoke Network (e.g., production)
│ ↕ connectivity layer
├── Operational Environment B ─── Spoke Network (e.g., staging)
│ ↕ connectivity layer
└── Operational Environment C ─── Spoke Network (e.g., data platform)
Live Systems deployed within any operational environment can communicate with Live Systems in other operational environments through the hub. Internet connectivity — both inbound and outbound — is also achieved through the hub.
Dynamic IP Address Management (IPAM)
Fractal Cloud includes a built-in IPAM system that dynamically allocates non-overlapping CIDR blocks across all environments and Live Systems. No IP ranges are hardcoded — every network, subnet, and address space is allocated at runtime based on what's available and what's already in use.
How It Works
-
During initialization, the IPAM system discovers the available address space. By default it uses the full RFC 1918 private ranges, but it can be constrained to a specific range (see BYON below).
-
IPAM detects existing infrastructure. Before allocating, it scans the cloud account for any networks already in use and marks those ranges as unavailable. This prevents conflicts when deploying alongside pre-existing infrastructure.
-
Allocations are sized dynamically. When a new environment or Live System is created, IPAM allocates a block appropriate to the workload size. If the requested size doesn't fit in the available space, it automatically promotes to the next size.
-
Allocations are released when environments or Live Systems are deleted, returning the address space to the pool.
Bring-Your-Own-Network (BYON)
If your organization has pre-allocated IP ranges or existing network infrastructure, you can initialize the Management Environment with a BYON configuration. IPAM will discover the existing network's CIDR and constrain all future allocations within it, ensuring Fractal Cloud integrates seamlessly with your existing address plan. This is fully compatible with the hub-and-spoke topology — spokes are allocated within your existing range.
Live Systems and Networking
When you deploy a Live System into an operational environment, how its networking works depends on what your Fractal Blueprint declares.
Managed Networking (Molecules)
When your Blueprint uses Molecules — composed infrastructure patterns like a Kubernetes platform, a microservices stack, or a managed database tier — the Live System deploys into the environment's spoke network automatically. You don't declare VPCs, subnets, or routing. The platform:
- Allocates subnets within the spoke network via IPAM, sized to the Live System's requirements
- Deploys workloads into those subnets with full hub connectivity already in place
- Ensures centralized egress, network segmentation, and private service endpoints — all inherited from the spoke
This is the recommended approach for most workloads. You get enterprise-grade networking with zero network configuration.
Self-Managed Networking (Atoms)
When your Blueprint explicitly declares Atom-level network components — a VPC, subnets, route tables, security groups — the Live System provisions exactly what you declared. These resources are created outside the hub-and-spoke topology as standalone infrastructure. The platform does not inject them into the spoke network or connect them to the Transit Gateway.
This gives you full control over the network architecture for scenarios where the hub-and-spoke model doesn't fit — for example, workloads with specific compliance requirements, isolated test environments, or custom network topologies.
Live Systems with self-managed VPCs do not benefit from centralized egress, cross-environment connectivity through the hub, or IPAM-managed address allocation. You are responsible for the networking topology of those resources.
Vendor-Specific Details
Each cloud vendor implements the hub-and-spoke pattern using its native networking primitives. Select your vendor for details:
| Provider | Details |
|---|---|
| AWS | Transit Gateway, NAT Gateway, VPC Endpoints |
| Azure | VNet Peering, Service Endpoints, VNet Integration |
| GCP | Shared VPC, VPC Access Connector, Private Google Access |
The network architecture is deployed automatically during Environment Initialization. You do not need to create or configure any networking resources manually.
Right-Sizing by Environment
The hub-and-spoke stack can be provisioned at two tiers so non-critical environments don't pay for production-grade redundancy. See Network Tiers for the nonprod (default) vs prod model, the parity guarantees, and the AWS cost breakdown.