Sample Structure

As you scale your Terraform or OpenTofu usage, it's important to enable self-service for users who will be deploying the code. The Scalr inheritance model is built to enable your end users while ensuring they inherit the correct variables, credentials, modules, and more. Objects that are created at the account scope by an admin will be assigned and inherited by the environments. Objects that are assigned to environments, like variables or provider credentials, will then be inherited by the workspaces within environments. The inheritance model allows you to create the concept of environment admins by allowing them to create and manage their workspaces knowing that they are operating within the guidelines that the top-level admins have set. Many of our customers are familiar with the inheritance model and structure that is set in AWS, which Scalr is not far off from, see a sample structure below.

Sample Structure - AWS Comparison

When customers initially onboard into Scalr we typically get asked the question about best practices for structuring Scalr. If you're accustomed to the AWS account structure, and it works for you in AWS, then we recommend following that same structure in Scalr. The structure being the concept of an AWS management account with multiple child accounts. That same concept applies in Scalr, where the Scalr account is equivalent to the AWS management account and Scalr environments are equivalent to the AWS child accounts.

In the diagram above, we see that the management account is managing the child accounts, and assigning policies as well as integrations. Each child account has a set of teams that have access to it, potentially admin access depending on the permissions, where they are deploying cloud resources. This same concept can be applied to Scalr:

In Scalr, the account scope is where the administration team manages all of the environments, creates policies, variables, sets modules, controls IAM, and has visibility over reports and operations. The environments are where the development teams can deploy their code and depending on permissions, have complete admin control of that environment or multiple environments.

Modeling the structure after AWS not only helps the admins deploy the same concept in AWS and Scalr, but also helps the development teams with visualization when they are switching contexts between AWS and Scalr.