Multi-Tier OCI Landing Zone with Hybrid Connectivity

This engagement involved migrating a large VM estate to Oracle Cloud Infrastructure for an enterprise client with existing workloads on both Azure and AWS. The client's requirement was not just OCI migration — it was hybrid connectivity: OCI workloads needed to reach Azure-hosted databases and AWS-hosted data pipelines over private network paths, with no traffic crossing the public internet. The security and compliance requirements (data classification requirements specific to their industry) meant network segmentation had to be enforced at the infrastructure level, not just via application-layer controls.

The complication that made this more than a standard landing zone build: the client had a partial Terraform implementation that one of their internal teams had started. It had been running against the OCI environment for several months, but the state file had drifted — resources existed in OCI that were not in the state file, and some resources in the state file had been manually modified after Terraform had created them. Starting from that state file meant any Terraform apply would either try to recreate resources that already existed or fail on resource conflicts. The first task was not building the landing zone — it was understanding what actually existed in the tenancy.

I spent the first week running terraform import against the existing OCI resources to rebuild a clean state file that matched reality. This required methodical resource enumeration (OCI Console and CLI to list all existing resources by compartment) and then importing each resource type in dependency order — you have to import the VCN before you can import the subnets that reference it, the DRG before the DRG attachments. By the end of the week, terraform plan showed no changes, which meant the state file accurately reflected the running environment.

The Terraform module hierarchy was built around OCI compartments: a root module that creates the compartment structure, then child modules for networking, compute, security, IAM, and monitoring — each with its own state file. Compartment-based isolation was the compliance requirement driver: each compartment maps to a data classification tier, and IAM policies enforce that principals with access to lower-classification compartments cannot read resources in higher-classification ones. The network firewall rules mirror this — traffic between compartments traverses the OCI Network Firewall, which logs all cross-tier flows for audit.

Hybrid connectivity used OCI Dynamic Routing Gateways as the hub. FastConnect provided the dedicated connection to the client's on-premises network, which also had ExpressRoute to Azure. Site-to-Site VPN handled the AWS side. The DRG route tables control which VCN subnets can reach which remote networks — application servers can reach the Azure database endpoints, but cannot directly reach the AWS pipelines (that routing goes through an intermediate OCI service that acts as a proxy). This constraint was a compliance requirement: all cross-cloud data flows are proxied and logged, not direct.

Provisioning time for a comparable environment before this engagement was measured in weeks — each component was provisioned manually by different teams with coordination overhead. With the Terraform modules, a net-new environment (dev or staging) provisions in approximately 40% of the time the manual process took. Production provisioning still requires change management approval gates, but the technical work is automated. The cost reduction (25% on OCI infrastructure costs) came from rightsizing: the initial manual provisioning had over-sized compute shapes and allocated block volume capacity well above current usage projections. The Terraform modules encoded the correct shapes based on measured workload requirements. What remains open: the monitoring stack is partially manual — OCI Monitoring is configured via Terraform, but the alerting rule tuning for the specific workload thresholds was done manually and hasn't been codified yet.