Atlas Cluster IaC
Parent: MongoDB Atlas Terraform Provider · Published reference · snapshot 2026-10-24 · skill mongodb-cohort-ac926399aa55
↓ Facts as markdownall context files
Source-anchored research for Atlas Cluster IaC. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- Terraform prevent_destroy rejects destructive plans while its rule remains in configuration, but does not protect a resource whose configuration is removed. Atlas separately exposes termination_protection_enabled to reject cluster deletion at the service; these protections operate at different layers. (high confidence) [source]
How it works
- The provider currently warns that use_effective_fields has no effect when a cluster has more than one replication_specs entry. Shard correlation relies on list position: preserve entry order, append new shards after existing entries, and do not rely on indexed ignore_changes rules during topology changes. (low confidence) (verified as of 2026-10-24) [source]
- Existing clusters can be imported into mongodbatlas_advanced_cluster using PROJECTID-CLUSTERNAME. The resource documentation also requires configuration migration when upgrading from provider 1.x to 2.0 or later; old tutorial HCL should be checked against the selected provider schema. (low confidence) (verified as of 2026-10-24) [source]
How-to and procedures
- Enable Atlas termination protection to block accidental cluster deletion; deleting a protected cluster requires disabling that protection first. (high confidence) [source]
- To introduce effective fields on an existing cluster, the provider instructs users to enable the flag and remove spec-related ignore_changes rules in the same apply, without unrelated changes. Previously omitted read-only or analytics specs may require a preparatory apply to explicitly retain nodes or set node_count to zero. (low confidence) (verified as of 2026-10-24) [source]
Problems, failure modes and limitations
- A September 23, 2026 Crossplane integration report described repeated DISK_SIZE_GB_TOO_SMALL errors after initProvider.diskSizeGb was reapplied following Atlas storage growth. The issue closed October 21, 2026; this is an integration-specific historical failure, not proof of a current Terraform-wide defect. (low confidence) [source]
Comparisons and alternatives
- AWS's deployment pattern stores Terraform state in S3 and retrieves Atlas API keys from Secrets Manager. OneUptime independently recommends environment variables or a secrets manager instead of credential-bearing tfvars files. (high confidence) [source]
- Atlas autoscaling can change compute and storage values outside Terraform. Without effective-field handling, targeted lifecycle.ignore_changes rules let Atlas retain control of those attributes rather than having a later apply restore configured values. HashiCorp defines ignored attributes as considered on creation but ignored when planning updates. (high confidence) (verified as of 2026-10-24) [source]
- The AWS landing-zone pattern stores Atlas API keys in Secrets Manager and deployment state in an S3 backend, with separate development, staging or production environment inputs. These are concrete integration patterns rather than guarantees that a Terraform-created cluster is reachable. (low confidence) [source]
Facts and statements
- The MongoDB Atlas Terraform provider provisions and manages Atlas infrastructure across AWS, Azure and Google Cloud, allowing database resources to participate in application deployment workflows. (high confidence) [source]
- Cluster IaC can describe replica-set, sharded and global cluster topologies, with cloud regions, node counts and instance sizes represented in configuration. (high confidence) [source]
- A reviewable deployment workflow runs terraform init, previews changes with terraform plan, applies them with terraform apply, and then validates the deployed application or infrastructure. (high confidence) [source]
- A usable deployment includes more than a cluster: Terraform examples also configure projects, database users, network access and cloud connectivity; AWS publishes a PrivateLink-based landing-zone pattern. (high confidence) [source]
- If Atlas autoscaling changes running capacity, a later Terraform apply can attempt to restore configured sizing unless the configuration explicitly accommodates Atlas-managed changes. (high confidence) [source]
- The provider documentation recommends use_effective_fields = true for autoscaling: configured specs retain intent, while effective specs expose actual capacity without autoscaling plan drift. (high confidence) (verified as of 2026-10-24) [source]
- Effective fields apply to dedicated M10+ clusters. While autoscaling stays enabled across an update, instance_size, disk_size_gb and disk_iops are ignored together; toggling autoscaling can apply requested sizes. (low confidence) (verified as of 2026-10-24) [source]
- The Atlas provider models cluster creation, updates and deletion as Terraform resources; Google and AWS deployment examples combine Atlas and application-cloud infrastructure in one declarative workflow. (high confidence) [source]
- mongodbatlas_advanced_cluster defines replica-set, sharded and global clusters through cluster_type and nested replication_specs/region_configs, including cloud, region, node counts and instance sizes. Its examples include multi-cloud deployments. (low confidence) (verified as of 2026-10-24) [source]
- The deployment sequence is terraform init, terraform plan and terraform apply; both cloud-provider examples also document terraform destroy for teardown. Review the plan before applying changes to a stateful database. (high confidence) [source]
- Atlas provisioning and application connectivity need separate validation. AWS recommends testing from an EC2 instance or Lambda attached to the VPC after deploying the landing zone and PrivateLink connection. (low confidence) [source]
- For supported dedicated clusters, use_effective_fields separates configured sizing intent from effective runtime sizes and avoids autoscaling-induced plan drift. MongoDB documents this for M10-and-larger dedicated clusters, excluding Flex; the provider also excludes tenant clusters. (high confidence) (verified as of 2026-10-20) [source]
- Google’s 2022 deployment example requires both Google Cloud and Atlas accounts and explicitly maps their differing region identifiers. Its example demonstrates integration, but its API-key permissions and M0 assumptions should not be treated as current production defaults. (low confidence) (verified as of 2022-10-10) [source]
Children
- No children recorded.