Scaling Multi-Cloud Infrastructure: Streamlining GitOps with Terraform, OpenTofu, and Atlantis

Introduction to Modern Multi-Cloud Complexities

In the contemporary enterprise landscape, adopting a multi-cloud strategy has transitioned from a competitive advantage to an operational necessity. Organizations leverage a mix of Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) to maximize redundancy, optimize costs, and avoid vendor lock-in. However, managing infrastructure across disparate cloud ecosystems introduces unprecedented complexity. Operations teams frequently grapple with fragmented states, configuration drift, and visibility silos.

Historically, Infrastructure as Code (IaC) tools like HashiCorp Terraform revolutionized how teams provision resources. Yet, running IaC commands from local terminals or disjointed CI/CD pipelines often introduces security vulnerabilities and collaboration bottlenecks. This is where the open-source GitOps paradigm, powered by Atlantis and supported by both Terraform and its open-source alternative OpenTofu, provides a unified, web-based operational framework for multi-cloud environments.

The Core Components: Terraform, OpenTofu, and Atlantis

Terraform and OpenTofu: The Foundations of IaC

Terraform has long been the industry standard for declarative infrastructure provisioning. By defining resources in high-level configuration code, it allows engineers to manage any cloud API deterministically. Following recent licensing changes in the ecosystem, OpenTofu emerged as a community-driven, open-source drop-in replacement under the Linux Foundation. Both tools utilize the same HashiCorp Configuration Language (HCL) syntax, meaning organizations can seamlessly deploy either engine depending on their compliance and open-source preferences.

Atlantis: Pull Request-Driven Automation

Atlantis is an open-source application that listens for Webhooks from Git providers (such as GitHub, GitLab, or Bitbucket). It acts as a dedicated execution environment for your IaC workflows, bringing the deployment execution directly into the Pull Request (PR) interface. Instead of running terraform plan or tofu apply locally, developers and platform engineers execute these commands via comments on the pull request. Atlantis then posts the output back into the PR, providing a transparent audit trail.

Why Combine Atlantis with Multi-Cloud IaC?

Deploying a centralized Atlantis server to handle multi-cloud infrastructure offers several transformative institutional benefits:

• Enhanced Collaboration and Visibility: Infrastructure changes are no longer obscured inside a developer's local terminal or hidden deep within isolated CI server logs. Every team member can review the exact resource modifications directly inside the version control system.
• Strict Security and Compliance: Credentials for AWS, Azure, and GCP are stored securely on the central Atlantis server or managed via cloud-native IAM roles. Individual developers do not require administrative cloud access on their local machines, dramatically shrinking the organization's attack surface.
• Automated State Locking: Atlantis automatically locks the specific project directory when a PR is opened. This prevents concurrent executions on the same state file, eliminating accidental resource overwrites and race conditions.

Architecture: How It Works Under the Hood

The operational workflow of managing a multi-cloud footprint through Atlantis follows a structured, highly secure lifecycle:

1. Code Modification: An engineer creates a new branch, modifies the HCL files (specifying resources across AWS, Azure, or GCP), and submits a Pull Request to the main branch.
2. Automated Planning: Atlantis intercepts the PR webhook, acquires a state lock, and executes atlantis plan (which internally runs either terraform plan or tofu plan). The resulting execution plan is automatically appended as a comment on the PR.
3. Peer Review and Approval: Team leads and peers review the generated plan, validating resource costs, security compliance, and architectural alignment.
4. Execution via Comment: Once approved, an authorized user types atlantis apply in the PR comments. Atlantis executes the infrastructure changes across the targeted cloud providers and reports the success or failure directly back to the thread.
5. Merge and Unlock: Upon a successful apply, the PR is merged automatically into the main branch, and Atlantis releases the state lock.

"By shifting infrastructure execution to a GitOps model via Atlantis, organizations achieve a single source of truth where the Git repository precisely mirrors the live multi-cloud infrastructure state."

Step-by-Step Guide to Configuring Atlantis for Multi-Cloud

1. Designing the Directory Structure

To successfully govern multiple clouds, your Git repository should adopt a modular, environment-based or provider-based directory structure. A segregated structure prevents state bloat and limits blast radiuses:

infrastructure-repo/├── .github/│   └── workflows/├── atlantis.yaml├── modules/│   ├── aws_vpc/│   └── azure_vnet/└── environments/    ├── aws-production/    │   ├── main.tf    │   └── variables.tf    └── gcp-staging/        ├── main.tf        └── outputs.tf

2. Writing the atlantis.yaml Configuration

The atlantis.yaml file located at the root of your repository tells Atlantis exactly how to orchestrate the execution. Below is an example configured to handle both standard Terraform configurations and OpenTofu workflows interchangeably:

version: 3projects:- name: aws-production  dir: environments/aws-production  autoplan:    when_modified: ["*.tf", "../modules/**/*.tf"]    enabled: true  workflow: terraform-default- name: gcp-staging  dir: environments/gcp-staging  autoplan:    when_modified: ["*.tf"]    enabled: true  workflow: opentofu-defaultworkflows:  terraform-default:    plan:      steps:      - run: terraform init -input=false      - run: terraform plan -input=false -out=$PLANFILE    apply:      steps:      - run: terraform apply -input=false $PLANFILE  opentofu-default:    plan:      steps:      - run: tofu init -input=false      - run: tofu plan -input=false -out=$PLANFILE    apply:      steps:      - run: tofu apply -input=false $PLANFILE

Best Practices for Multi-Cloud GitOps Operations

To maximize the efficiency and safety of an Atlantis-driven multi-cloud architecture, enterprises should enforce the following operational best practices:

Implement Policy as Code (Open Policy Agent / Conftest)

Integrate automated compliance checks into your Atlantis workflow. By adding a conftest step within the custom workflow definitions, Atlantis can automatically evaluate the generated plan against organizational security baselines (e.g., ensuring S3 buckets are private or checking that Azure network security groups do not allow broad internet access) before allowing an apply command to proceed.

Utilize Cloud-Native Identity Federation

Avoid hardcoding cloud provider credentials or access keys onto the server hosting Atlantis. Instead, host your Atlantis instance inside a Kubernetes cluster or virtual machine that utilizes native IAM roles, such as AWS EKS IAM Roles for Service Accounts (IRSA) or GCP Workload Identity. This allows Atlantis to securely assume roles across various cloud provider accounts dynamically.

Enforce Strict Server-Side Approvals

Configure Atlantis to require explicit repository approvals before permitting the atlantis apply command. This ensures that even if an engineer has the technical capability to write HCL code, no infrastructure adjustments hit production without validated architectural oversight.

Conclusion

Managing multi-cloud environments does not have to result in operational chaos or fragmented control. By anchoring your infrastructure strategy around GitOps and utilizing Atlantis as a unified execution platform for Terraform and OpenTofu, your organization can achieve unprecedented levels of agility, transparency, and safety. This setup democratizes infrastructure contributions across your engineering departments while maintaining centralized governance, ensuring your multi-cloud footprint remains resilient, scalable, and inherently secure.