Scalr Terraform State Management: Features and Functionality

Terraform tracks every piece of infrastructure it manages in a state file. If that file is lost, corrupted, or modified by two runs at once, Terraform loses the map between your configuration and what actually exists in the cloud. Keeping it secure, available, and versioned matters as much as the configuration itself.

Scalr handles this with a managed backend that stores state, encrypts it, and keeps a version history. You can also point a workspace at an external backend if you'd rather store state elsewhere. This post walks through both paths and the related features around import, export, and customer-owned storage.

How Does Scalr Encrypt and Version State?

When you use the Scalr-managed backend, state files are encrypted at rest with AES-256, which protects infrastructure data from unauthorized access. Scalr also versions state files automatically, so you can inspect previous versions and revert to a prior state when you need to.

How Does the Scalr Backend Lock State Automatically?

If two operations hit the same Terraform state at once, you can end up with corruption and conflicts. So when you use the Scalr-managed backend, Scalr locks the state automatically.

• When a Terraform operation (e.g., plan or apply) starts in a Scalr workspace, Scalr locks the state file.
• This action prevents other users or processes from modifying the state simultaneously, which helps maintain data integrity.
• The lock is released upon completion of the operation.

This locking mechanism is a built-in feature of the Scalr backend.

Can You Use an External Backend Instead of Scalr's?

Scalr allows users to employ other backends supported by Terraform if the Scalr-managed backend is not preferred.

• Disable Scalr Backend Per Workspace: The Scalr-managed backend can be disabled for individual workspaces. This permits configuration of Terraform to use alternative backends such as Amazon S3, Azure Blob Storage, Google Cloud Storage, or HashiCorp Consul.
• External Backend Locking: If an external backend is used, state locking is handled by that specific backend. For example, an S3 bucket configured with DynamoDB for locking will use those AWS services for concurrency management. Terraform interacts with the chosen backend's locking mechanism.

Does Scalr Support terraform import?

Scalr supports the terraform import command. This function allows users to bring existing infrastructure, not initially created by Terraform, under Terraform management. The state of these imported resources can be stored in Scalr's managed backend or a configured external backend. The state is accessible for inspection and management.

Can Enterprise Customers Store State in Their Own Bucket?

On the Enterprise plan, Scalr offers the option to store state in a customer-owned storage bucket while still utilizing the Scalr backend's management features.

This approach provides:

• Customer control over the storage bucket (e.g., an S3 bucket within the customer's AWS account).
• Continued use of Scalr features such as encryption (which can be layered with bucket-level encryption), state versioning metadata management, UI integration, and access controls.

This option can be used to meet specific compliance, data sovereignty, or data governance requirements.

How Do You Export State Using terraform state pull and Other Methods?

Terraform state data managed by Scalr can be accessed or exported through several methods:

1. Terraform CLI: The terraform state pull command can be used to retrieve the current state file to a local machine.
2. Scalr API: Scalr's API allows programmatic access to and export of state files, which can be used for automation or integration.
3. Customer-Owned Bucket: If state is stored in a customer-owned bucket, the data resides directly within the customer's infrastructure, potentially negating the need for a separate export step from Scalr.

Which State Management Setup Is Right for Your Team?

The Scalr-managed backend encrypts state, keeps a version history, and locks state during runs. If that doesn't fit your needs, you can disable it per workspace and point Terraform at an external backend instead. On the Enterprise plan you can also keep Scalr's management features while the state itself lives in a bucket you own. Which option works best depends on how your team handles infrastructure as code and what your compliance requirements are.