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.

Scalr-Managed State Storage

Scalr provides a managed state storage solution with the following characteristics:

• AES-256 Encryption: State files managed by Scalr are encrypted at rest using AES-256. This protects infrastructure data from unauthorized access.
• State Versioning and Rollback: Scalr versions state files automatically. This creates a history of the state, allowing users to inspect previous versions and revert to a prior state if necessary.

Automatic State Locking with Scalr Backend

To prevent corruption and conflicts from concurrent operations on the same Terraform state, Scalr implements automatic state locking when its managed backend is used.

• 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.

Option to Use External Backends

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.

terraform import Support

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.

State Storage in Customer-Owned Buckets with Scalr Backend

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.

State Export 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.

Conclusion

Scalr gives you a managed backend that encrypts state, versions it, and locks it during runs. If that doesn't fit, you can disable it per workspace and use an external backend, or on Enterprise keep Scalr's management features while the state lives in your own bucket. Pick the setup that matches how your team handles infrastructure as code.