State Management

DE-CIX PDM Team Updated by DE-CIX PDM Team

Terraform State Management with DE-CIX Resources

Terraform tracks all managed resources in a state file. Understanding how state works with DE-CIX IX-API resources is important for safely managing the lifecycle of Cloud ROUTERs, network service configurations, prefix lists, and policies.

How Terraform State Works

Each terraform apply reconciles the desired configuration in your .tf files with the real state of resources in the IX-API. Terraform stores the current state — IDs, attribute values, dependencies — in a state file, by default terraform.tfstate in your working directory.

Key rules:

  • Resources created by Terraform are tracked by ID in the state file.
  • Removing a resource block from your configuration causes Terraform to destroy that resource on the next apply.
  • Changing an attribute that requires replacement causes Terraform to destroy and recreate the resource.

Remote State (Recommended)

For any production use, store state remotely so that multiple team members can share it and it is not lost if a local machine is unavailable.

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "de-cix/cloud-router/terraform.tfstate"
    region = "eu-central-1"
  }
}

Resource Deletion Order

Cloud ROUTER resources have dependencies that must be respected during teardown. Terraform handles this automatically based on the implicit reference graph, but it is important to understand the order:

  1. Network Service Configs (NSCs) must be deleted before the Cloud ROUTER (VRF) they are attached to.
  2. Cloud VC Network Services can only be deleted once their NSCs are removed.
  3. The Cloud ROUTER can only be deleted once all NSCs are gone.
  4. Prefix lists and policies are independent and can be deleted in any order.

If you need to tear down only NSCs while keeping the Cloud ROUTER, use count = 0 to remove resources conditionally:

variable "create_nsc" {
  type    = bool
  default = true
}

resource "ixapi_de_cix_cloud_router_network_service_config_p2p_vc" "session" {
  count = var.create_nsc ? 1 : 0
  # ...
}

Apply with create_nsc = false to delete the NSC without touching the Cloud ROUTER.

Preventing Accidental Deletion

Use lifecycle blocks to protect critical resources:

resource "ixapi_de_cix_cloud_router" "main" {
  # ...

  lifecycle {
    prevent_destroy = true
  }
}

With prevent_destroy = true, Terraform raises an error if a plan would destroy this resource.

Handling Drift

If a resource is modified outside of Terraform (e.g. via the IX-API portal), the next terraform plan detects the drift and shows what changes would be applied to bring the resource back to the desired state. To accept the external change, update the relevant attribute values in your configuration and run terraform apply.

Recommended Workflow

  1. Plan before applying — always review terraform plan output before running terraform apply.
  2. Use variable files for environment-specific values:
$ terraform apply -var-file=production.tfvars
  1. Delete NSCs before Cloud ROUTERs — when decommissioning, first apply with NSC resources removed, then remove the Cloud ROUTER resource.
  2. Back up state before destructive operations when not using a remote backend with versioning.

How did we do?

Managing Services

End-to-End Example

Get in touch