AWS Cloud Operations & Migrations Blog

Provision sandbox accounts with budget limits to reduce costs using AWS Control Tower

Many Amazon Web Services (AWS) customers struggle to keep cloud costs under control while allowing employees to innovate and develop their AWS skills. We talk to technology leaders every day who rank controlling cloud spend among their top concerns. Those same leaders don’t want to stifle innovation or restrict employee’s ability to learn AWS. Using shared development accounts for learning and experimentation can lead to uncontrolled costs since it is hard to track, and can also impact resources that will eventually be promoted to production workloads. In this post, we’ll use AWS native services to provision AWS sandbox accounts for employees to learn and experiment in with automated controls to limit monthly AWS costs per account.

The solution covered in this post uses Account Factory Customization (AFC), a feature of AWS Control Tower, to deploy sandbox accounts with configurable and automatically enforced monthly budgets. Your employees can grow their AWS skills and experiment without impacting path to production (dev/test) environments, while staying within your desired budget. We will define an AWS Budgets monthly budget with automated enforcement using AWS CloudFormation, create a blueprint as a product in AWS Service Catalog, deploy a sandbox account from AWS Control Tower Account Factory using the blueprint, and verify the sandbox account is working as expected.

Prerequisites

  1. You must have an AWS Control Tower managed landing zone set up and have access to the management account. For instructions see Getting started with AWS Control Tower. Have your Account Factory configured and understand how to use it.
  2. You need access to an AWS account where you can deploy products from AWS Service Catalog. We recommend using a separate account as your Service Catalog hub as shown in this blog post. We do not recommend the use of your AWS management account for this.

Solution design and architecture

This solution uses multiple AWS native services to deploy and automate governance of your sandbox accounts. For this use case, a sandbox account is an AWS account used for learning, experimentation, and other non-SDLC activities. A sandbox should not be connected to your organizations network or be used to develop workloads that will be deployed to production. The best practice is for your sandbox accounts to live in a separate Sandbox Organizational Unit (OU) in your landing zone.

You will learn how to enable employees to have a place to learn AWS and experiment with new ideas while staying within a monthly budget. To do this, the employees need to be automatically restricted from incurring additional costs in the AWS account once the budget limit is hit. The account must also reset at the beginning of each month to restore full access to the employee.

The AWS landing zone is managed using AWS Control Tower. An account will be provisioned through your Account Factory with your standard controls in place. An Account Factory Customization blueprint will be used to transform the account into a sandbox.

Figure 1, Sandbox account provisioning. From AWS Control Tower an account will be provisioned in Account Factory using Account Factory Customization. A CloudFormation template will create the additional resources in the account to make it a budget limited sandbox.

Figure 1 Sandbox account provisioning

Your sandbox account will have a SandboxDeveloper IAM role for the employee to assume when accessing the account. This role will have power user access with restrictions limiting the ability to change the AWS Budget and Lambda functions that govern the sandbox. The account will have AWS Budgets enabled and a configurable budget set with a default monthly limit of $100. The budget will publish warning notifications to an Amazon SNS topic when the account hits 50% and 80% of the limit(configurable percentages), and to a different topic when the limit is met. The warning notifications do not have subscribers by default so you can decide who or what receives these alerts. The limit met notification will have an AWS Lambda function subscribing to it that will change the SandboxDeveloper role access to read only so the employee can still access the account, but not create new resources.

Using a Lambda function to determine what actions are taken when the budget is met gives you a lot of flexibility. You could attach a custom policy to the role that allows for deletion of created resources or use the Lambda function to kick off a process to clean up the account and delete any resources already created. For this how to guide you are only changing the developer access to read only and back, but you can use custom IAM policies or update the Lambda functions to suit your needs. If you want to terminate account resources, you can add the desired function logic and delete resources with the AWS Cloud Control API or develop your own account reaper application to call from the Lambda function.

Figure 2, Architecture for sandbox account lockdown. Budget limit warning alerts in AWS Budgets send notifications to a topic in SNS that can be subscribed to using SMS or email. Budget exceeded alerts from AWS Budgets will send notifications to a different SNS topic that triggers a Lambda function to set the Sandbox Developer role to read only.

Figure 2 Architecture for sandbox account lockdown

The final component is a scheduled rule in Amazon EventBridge that runs at the beginning of each month and kicks off a Lambda function that resets the SandboxDeveloper role access to power user. The budget automatically restarts at $0 since it is set as monthly. An AWS Key Management Service (KMS) key is also created and used to encrypt logs, Lambda functions, and SNS messages.

Figure 3, Architecture for monthly sandbox account reset. On the first day of each month the AWS monthly budget you create is set back to $0. At midnight on that date a scheduled event in Amazon EventBridge triggers a Lambda function that restores full access to the Sandbox Developer role.

Figure 3 Architecture for monthly sandbox account reset

Walkthrough

  1. Federate or sign in to your AWS Control Tower management account as an AWS Control Tower administrator.
  2. Download this CloudFormation template from GitHub, named AWSSandbox.yaml. Take a few minutes to read through the template and see how the parameters and resources are defined.
  3. Go to IAM in the console. Create a new role named AWSControlTowerBluePrintAccess as documented in the user guide.
  4. Create the blueprint as a Service Catalog product using the CloudFormation template you downloaded.
  5. Go to Service Catalog and choose the Product list in the Administration menu.
    6. Figure 4, Service Catalog Product list on menu. The Service Catalog menu as described in this step.

    Figure 4 Service Catalog Product list on menu

  6. In the Product list, choose the Create product button then select Create product
    7. Figure 5, Create a new product. Product list as described in this step.

    Figure 5 Create a new product

  7. In the Product details section, set the Product name to “Sandbox Blueprint” and give it a description and owner.
    8. Figure 6, Blueprint product details in Service Catalog. The Product details screen has a Product name text box, Product description text box, Owner text box, and Distributor text box.

    Figure 6 Blueprint product details in Service Catalog

  8. For the Version details section, make sure Use a template file is selected, then upload the AWSSandbox.yaml template.
    9. Figure 7, Uploading template for blueprint. The Version details screen has a Choose a method section where you pick Use a template file. There is an upload button in the middle that says Choose file where you will upload the YAML template. The last section has a text box for Version name and another for Description.

    Figure 7 Uploading template for blueprint

  9. Skip the rest of the sections and choose the Create product button at the bottom of the page.
  10. Refresh your Product list and you should see Sandbox Blueprint listed.
    11. Figure 8, Sandbox Blueprint in Service Catalog Product list. On the Product list screen you will see your Sandbox Blueprint product listed.

    Figure 8 Sandbox Blueprint in Service Catalog Product list

  11. Go to the AWS Control Tower Account Factory in the management account and choose Create account.
    12. Figure 9, Account factory Create account button. The Account factory screen as described in this step.

    Figure 9 Account factory Create account button

  12. Fill in the Account details. Make sure to use a new email address for the account. Most public email providers allow for email+additionaltext@domain which will allow you to use your existing address. For example, if your email is myname@domain you can use myname+sandbox@domain. You will need to check internally if your organizations email allows for that. Otherwise you can use a separate email from the one used to create your management account. Set the Display name of the account to “MyNewSandbox”.
    13. Figure 10, Sandbox account Account details. The Account details screen has an Account email textbox and a Display name textbox.

    Figure 10 Sandbox account Account details

  13. For the Access configuration section, make sure to use the IAM Identity Center email and user name you use to federate into your other AWS Control Tower accounts. If you need a refresher on AWS Control Tower and Identity Center integration, check the AWS Control Tower User guide.
    14. Figure 11, IAM Identity Center information for the new account. The Access configuration section of the screen has an IAM Identity Center user email text box. Following, there is an IAM Identity Center user name section with text boxes for First name and Last name.

    Figure 11 IAM Identity Center information for the new account

  14. For the Organizational unit, select the Sandbox OU or another OU you have created for use with this solution.
    15. Figure 12, Select the Sandbox OU for your new account. The Organizational unit section of the screen has a dropdown list where you will select the Sandbox OU or other OU you want to use.

    Figure 12 Select the Sandbox OU for your new account

  15. Expand the Account factory customization section and fill in the details. Enter the account number of where your shared Service Catalog products are (your hub account or management account if that’s where you created the Sandbox Blueprint product) and choose Validate account. Select Sandbox Blueprint from the Select a product dropdown list.
    16. Figure 13, Enter the information for the Sandbox Blueprint you are using. The Account factory customization section has a text box for entering the account number of the account where your Service Catalog products are stored. There is a validate account button to the right of the box that you must hit after entering the account number. Once validated there is a dropdown list where you will select Sandbox Blue print. There is also Product version dropdown list.

    Figure 13 Enter the information for the Sandbox Blueprint you are using

  16. Once you load the blueprint, you will see a Blueprint parameters section. These are the parameters set up in the CloudFormation template. For the purposes of this exercise, please keep the default values for all parameters.
    17. Figure 14, the list of parameters for the sandbox blueprint. Section with the Blueprint parameters that includes Budget Limit, Currency type, SNS topic name for budget exceeded, SNS topic name for budget warnings, sandbox role name, start time of the monthly schedule, threshold in budget percentage for locking down the sandbox, and 2 warning threshold percentages. Per the described instructions do not change any of the values for this exercise.

    Figure 14 The list of parameters for the sandbox blueprint

  17. For Deployment Regions select Home Region.
    18. Figure 15, select the Home Region as your Deployment Region. The Deployment Regions section of the screen has selections for Home Region or All governed regions. This shows the Home Region selected.

    Figure 15 Select the Home Region as your Deployment Region

  18. Choose the Create account button at the bottom. Wait until the account is created and enrolled which can take up to 30 minutes.

Validation

Now it is time to verify the sandbox is set up correctly. Follow these instructions to validate so you do not need to wait until the budget limit is hit or until the monthly scheduled reset.

  1. Go to IAM and search for the SandboxDeveloper role. Verify that it has the PowerUserAccess and SandboxPowerUserRestrictions policies attached.
  2. Initiate the sandbox lockdown. Go to SNS, select the SandboxBudgetExceeded topic and choose the Publish message button.
    3. Figure 16, SandboxBudgetExceeded topic in the SNS list. SNS list of topics in the console with the SandboxBudgetExceeded topic selected.

    Figure 16 SandboxBudgetExceeded topic in the SNS list

  3. Set the Subject to “Test” and the Message body to “Testing sandbox lockdown”. Then choose the Publish message button at the bottom. This notification will kick off the LockdownSandbox Lambda function to set the SandboxDeveloper role to ReadOnlyAccess.
    4. Figure 17, Publishing a message to the SandboxBudgetExceeded topic. Publish message to topic screen with the topic ARN displayed, a text box for entering a message subject, a text box for entering message TTL, message structure options of an identical payload for all delivery protocols or custom payload per protocol, and an area to enter in the message body text.

    Figure 17 Publishing a message to the SandboxBudgetExceeded topic

  4. Go to IAM and find the SandboxDeveloper role again. Check the details and instead of PowerUserAccess you will see that the ReadOnlyAccess policy is now attached to the role.
    5. Figure 18, PowerUserAccess is removed and ReadOnlyAccess is attached to the SandboxDeveloper role. IAM details screen for the SandboxDeveloper role showing the attached policies. The ReadOnlyAccess policy is now attached and PowerUserAccess is removed.

    Figure 18 PowerUserAccess is removed and ReadOnlyAccess is attached to the SandboxDeveloper role

  5. For the last step you will run the RestoreSandbox Lambda function manually to verify that it sets the SandboxDeveloper role back to PowerUserAccess. Go to AWS Lambda and choose the RestoreSandbox function. Choose the orange Test button in the Code source section and select Configure test event.
    6. Figure 19, Test button for creating a new test event for a Lambda function. Orange test button on Lambda function screen with an option to configure test event in a drop-down menu.

    Figure 19 Test button for creating a new test event for a Lambda function

  6. Name the event “Test” and keep it on the hello-world template. The sample parameters will be ignored. Choose Save.
    7. Figure 20, configure your hello world test event for the function. Test event configuration screen using the hello-world template. The radio button for create new event is selected, there is a text box for event name where Test is entered, and all other settings are unchanged.

    Figure 20 Configure your hello-world test event for the function

  7. Choose the down arrow next to the Test button and confirm that your new Test event is selected.
    8. Figure 21, make sure your new test event is selected. The orange Test button for the Lambda function is selected again, now with the new Test event highlighted. 7.Choose

    Figure 21 Make sure your new Test event is selected

  8. Choose the Test button to run the test and you will see the results in the following window. The message should say “SandboxDeveloper role access restored”.
    9. Figure 22, Run the test and look for the successful response. Execution results pane shows in a tab following the Test button after it is run. Successful result shows in the pane with a message of SandboxDeveloper role access restored.

    Figure 22 Run the test and look for the successful response

  9. Go back to IAM again and verify the SandboxDeveloper role has the PowerUserAccess policy attached again. If so, the test was successful and you now have a functioning AWS sandbox account!

Clean up

  1. Federate or sign in to your AWS Control Tower management account as an AWS Control Tower administrator. Choose the MyNewSandbox account on your AWS Control Tower Dashboard. Once in the Account details, choose the Unmanage account button to remove it from AWS Control Tower.
    2. Figure 23, details of the MyNewSandbox account in AWS Control Tower. MyNewSandbox account details screen in the Organization section of Control Tower. Shows various account details with an Unmanage account button in the upper left that needs to be selected for the previous instruction.

    Figure 23 Details of the MyNewSandbox account in AWS Control Tower

    It will take a few minutes to remove the account from AWS Control Tower. Once the account no longer shows in your enrolled accounts move to the next step.

  2. Go to AWS Organizations in the console.
  3. You will see MyNewSandbox under Root. On the Account details screen, choose the Close button on the top right to close this account.
    4. Figure 24, MyNewSandbox account details in AWS Organizations. Account details of the MyNewSandbox account in AWS Organizations with a Close button in the top right corner that needs to be selected for the previous instruction.

    Figure 24 MyNewSandbox account details in AWS Organizations

    You will get an email from AWS confirming that your MyNewSandbox account is closed.

  4. Go to Service Catalog and select Product list from the menu. Choose the Sandbox Blueprint product. Once in the Product details, select the Delete button. Confirm deletion and your blueprint is deleted.
Figure 25, go here to delete the Sandbox Blueprint product from the Service Catalog. Product details for Sandbox Blueprint in Service Catalog. There is a delete button in the upper right that must be selected to delete the template. The delete button is the first of 3 buttons, followed by an edit and an actions button.

Figure 25 Go here to delete the Sandbox Blueprint product from Service Catalog

Conclusion

It is important to give employees the ability to learn AWS and innovate in the cloud while also managing costs. AWS services and automation will help you achieve both goals. Through this post, we deployed managed AWS sandbox accounts with monthly budget limits through Account Factory Customization in AWS Control Tower. We learned how to use a CloudFormation template to create the services and resources to make a sandbox account, and how to deploy that blueprint to a new account using AWS Control Tower Account Factory. Finally, we validated the sandbox functionality without hitting the budget limit or waiting for the account to reset.

Next steps

If this solution meets the needs for your sandbox account requirement, edit the CloudFormation, Lambda functions, and other resources to your liking and try it in your AWS Control Tower managed landing zone. Now that you understand how Account Factory Customization works, think about other blueprints you could create to customize different AWS account needs for your organization.

AWS Control Tower

Account Factory Customization (AFC)

AWS Budgets

Grant Britton

Grant is a Senior Solutions Architect at AWS serving customers in Auto & Manufacturing. He is passionate about Cloud Operations, DevOps, and helping customers build new value-driven solutions using AWS. When he is not designing cloud solutions, Grant enjoys spending time with his family, college football, pickleball, and travel.