🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Innovation Sandbox on AWS: Automating Temporary Cloud Environments (COP351)
In this video, the presenter introduces Innovation Sandbox on AWS, a solution that went GA in May 2025 to help organizations manage sandbox environments for upskilling and innovation. The solution addresses challenges like service allow lists in regulated companies and cost management when multiple users share sandboxes. It features three personas: admins who deploy accounts, managers who provision leases with cost and time controls, and users who request sandbox access. Through a live demo, the presenter shows how accounts are pooled, lease templates configure budgets and duration thresholds, and automated actions like freezing or cleaning up accounts using AWS nuke. Key features include IAM Identity Center integration, optional approval workflows, private lease templates for high-budget scenarios, and API support. Common use cases include universities, hackathons, highly regulated customers, and GenAI testing for agentic applications.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Why Sandboxes Matter: Customer Challenges and the Birth of Innovation Sandbox on AWS
Hello everybody. Welcome to session one, the first lightning talk of re:Invent 2025. I'm going to talk about Innovation Sandbox on AWS. At a high level, I'm going to talk about why we want to use sandboxes on AWS and customer challenges, and what Innovation Sandbox on AWS is. Then I'm going to give you a live demo. We had a recorded demo that wasn't working, so we're going to do this live and make it exciting.
First, let me address why sandboxes matter. I come from heavily regulated companies where developers and infrastructure teams had service allow lists that prevented them from using specific services. This created a huge bottleneck on upskilling and innovating. I was talking to a customer a few weeks ago who had a service allow list and a whole approval process. What they found was that services would be requested for approval, go through the process, get approved, and then never get used by developers because they were never able to test them in the real world.
Innovation Sandbox's number one goal is to enable upskilling and democratize innovation and building on AWS. Traditionally, we've been pushing sandboxes for years. I've been at AWS for about six years, and many of our customers are implementing sandboxes to achieve this goal. Typically, an admin or administrator creates an AWS account and provides access, often through a platform engineering team or an identity team, to a user. The user gains access and can play around in the sandbox and build things.
Very often, multiple users use the same sandbox. When multiple users create a lot of resources, it becomes extremely difficult to manage. Cost becomes a huge concern. For customers who have tried to solve the cost concern, it becomes a management overhead of going through all the resources that are in use or not in use and cleaning up the environments.
I've been on the AWS solution team for about four years. We have solutions like Instance Scheduler, Quota Monitor, and Landing Zone Accelerator. About three and a half years ago, we had the idea for Innovation Sandbox. We talked to hundreds of customers—I probably talked to over one hundred customers to get feedback so we could get approval for our developers to build Innovation Sandbox. We heard about this need from universities, startups, and highly regulated customers. They all need some type of solution to help them manage their sandbox environments.
Innovation Sandbox went GA in May of this year. There's more excitement around this solution than any other solution I've seen, probably because every single industry has an interest in testing, innovating, and upskilling. Our software packages are deployable by CloudFormation templates, and there's an implementation guide with each one. This particular package has four CloudFormation templates. It takes about one hour to deploy, and then it's up and running, supported and maintained by AWS, with the code available on GitHub.
How Innovation Sandbox Works: User Personas, Lease Templates, and Account Lifecycle Management
So what does Innovation Sandbox do? I'm going to walk through the workflow fairly quickly, and then I'm going to jump into a demo. When we built the solution, we imagined three different types of users. We have admin personas, manager personas, and user personas. Admins are responsible for deploying the solution and the underlying AWS accounts. Managers do not need to be technical. We want to give them the ability to provide sandbox accounts to their end users and to manage cost and the duration of these sandbox accounts.
The way the solution works is that somebody in the admin persona, such as a platform engineering team or whoever creates AWS accounts, is going to pre-create a certain number of accounts. This could be two accounts, one hundred accounts, or one thousand accounts, and those accounts will be in an account pool. Then we delegate the ability for managers to provision or lease these accounts to sandbox users and provide them access. Using something we call lease templates, the manager is able to create controls around cost and time, which you'll see in the demo where I'll dive a little bit deeper. This is all possible through a user interface. Access to the solution, as well as the AWS accounts, is through IAM Identity Center.
If you're using a third-party provider like Okta or Entra, it works exactly the same way. Access to the solution, which is a user interface, is through IAM Identity Center, and this allows the three different personas to be able to use this solution. The way the account request flow works is that a user authenticates through IAM Identity Center or the third-party provider. They access the application with user permissions and are able to request an account or request a lease. The lease request has an optional approval that the manager can set. If there is an approval, the manager can approve or deny it within the UI. Let's assume they approve it. The sandbox account is provisioned. The user now has access to that sandbox account. You can see a note in the bottom right: we had a release about two to three weeks ago where managers can now assign leases directly to users. This is extremely helpful for hackathons.
We have a private lease template, which I'll show you in the demo, that allows us to create large lease templates with high budgets or thresholds that we don't expose to the users so they can't request them. However, managers can assign those leases to researchers or whatever team would need that high threshold. There are multiple actions that you can complete or set in a lease template based on time or duration. We have send alert, which is fairly self-explanatory. We have freezing the account, and we have cleaning up or recycling the account.
Walking through a full flow, we have our account pool on the left with managers and users. Let's say we're running a small hackathon with four users. We created a lease template that had a five-day duration. After five days, we freeze the accounts. In addition to setting thresholds to complete any of these actions, managers from the user interface can also manually initiate them. A manager can manually terminate a lease or freeze an account at any time.
Let's say five days is up and the accounts are now frozen, which means the users lose access and can no longer access them. However, managers and admins maintain access to those accounts. This is really helpful in scenarios like hackathons where, for example, the first two people during the hackathon build something and want to continue working on it. Managers can go in and manually change specific lease thresholds, increasing the duration from five days to thirty days, for instance. Once they unfreeze those accounts, the users have access to them again.
Option two, which is the least common option, is to eject accounts from the solution at any time. We've seen this pattern from customers who have built something they want to bring over to their development environment. They move that account to a development OU and no longer treat it as a sandbox account. We're able to do that, so it's removed from the solution. The most common pattern is recycling. We can set a cleanup on the duration of maybe seven or eight days, and at eight days, it happens automatically. Alternatively, the manager can manually go in and clean up the account. During the cleanup process, the account is moved into a cleanup OU. All resources are cleaned up using AWS nuke, which is what the solution uses. The account is then returned to the account pool.
Live Demo: Navigating the User Interface from Admin to Manager to Sandbox User
Now we're going to switch over to the live demo. We have full access. This is the user interface of the solution. I authenticate through IAM Identity Center as the administrator. You can see over here we have the Administration tab. As the admin, I'm able to see all of these sections. As a manager, I'm able to see everything except for the Administration tab, and the user is only able to see Home. Starting as the administrator, we can look at the accounts. We can see in this account pool we have three available accounts, four active accounts, one frozen account, for a total of eight accounts.
I'm going to click on the Accounts tab. We can see the details of these accounts down here. We can see the account IDs, and as the admin, I could log into any of these accounts. Because I've authenticated through Identity Center to access the solution, I'm able to log in directly from the solution into the accounts with admin level access.
If I want to add accounts to the account pool, perhaps we're having a hackathon and we want to add 20 accounts for a short period, it's extremely simple. I'm going to click Add Accounts. Any accounts that I have pre-created and moved to an entry organizational unit—empty accounts—I move them into the entry OU and they will be available here. I'm actually going to register this account. This tells me that everything in those accounts will be wiped. I click Submit, and then hopefully the internet works, and we can see the account that I just added has now moved into a cleanup status.
The cleanup process takes about 5 to 10 minutes. It's using AWS nuke in what we call an innovation sandbox hub account. This is all in your environment. The process to clean up runs about 5 to 10 minutes. If I want to shrink the size of the account pool, I can select accounts in any state and click Eject Account. If I can click correctly, these accounts are removed from the solution. If we wanted to shrink the account pool or if something was built on those accounts that we don't want to ever destroy, we could just move them out and treat them as regular accounts.
Moving up to the manager section, I'm not going to log in as the manager, but you can imagine managers are not able to see the Administration tab. Starting with the lease templates, these templates are the core of how to configure the thresholds for the accounts. This is typically going to be done by the manager persona, so it does not need to be technical. We're going to set all the configuration. Clicking on the first one, Agentic-Testing, we can see we have name, description, and visibility. I mentioned earlier that we have the ability to set private visibility, which means when a user logs in, they're able to request an account from the available lease templates. If it's private, they won't be able to see that lease template. We have optional approval.
Let me go over the budget. We could set a maximum budget. We don't have to set a maximum budget, but here we have it set for $50. It's going to send an alert at $75, the account will be frozen, and at $100 the account will be wiped. We have a lot of customers that don't ever want to wipe their sandbox accounts just based on how they use sandboxes today. My recommendation is to always keep the wipe account action, even if you put that dollar amount very high, just as a safeguard against runaway costs. We don't have to do each one of these actions. We can pick and choose.
Duration works identically to a budget, except we're dealing with time, so we can set for, let's say, 24 hours, we'll make this short, and we can add thresholds and set different actions. The last tab we have is Cost Report. Cost Report is a new feature that came out about 2 weeks ago. This allows us to assign metadata to the lease templates based on maybe cost center or a team that's using it. Every 30 days, a cost report will be sent to an S3 bucket that rolls up the costs based on these cost report groups.
We see cost centers a lot or CEUs. You assign this to a lease template, and then if I'm on the security team, I'm only going to choose as a sandbox user the security lease templates, or that's all I'm allowed to choose. So we have a roll up of the different cost centers and how they're using the solution. If I look at the Leases tab, right now I have 3 active leases. You can see who has these leases. This would be the manager persona looking. We can see what the current budget is, when they're expiring, and what the status is. You can see I have one that's in the frozen state. As a manager, I can log into the accounts at any time.
If I click on one of these leases, I'll click on this one here. I can change specific lease thresholds as well as the lease template. Each lease is created from a lease template. That's where it's born from, and it pulls down all the configurations from that template.
However, I can also go into individual leases and make changes. This allows us, again with the hackathon example where 5 days was up, to go into specific leases and extend specific thresholds. As I mentioned, we can now assign leases. If I click assign lease, we can see the 4 lease templates that I have so far. You can see this researcher lease template is marked as visibility private, which means when a user logs in, they are not going to be able to request access to this lease template or a lease from this lease template.
We can see the approvals tab. Right now I have one, AWS Todd, who requests a lot. I can select that and approve it. When an approval request comes through, it sends an email, but you can also see it in the UI itself. Managers and admins can approve. I am going to jump over to a different view for the users. This is what a sandbox user would see. I logged in and authenticated through AWS Identity Center as a sandbox user. I can see if I have any leases currently, and right now I have a total of 4 leases, but only 2 that are active. These first 2 allow me to log into these accounts. I can see what my current budget is and expiration. I have 1 that is pending approval and 1 that was manually terminated just from demoing the solution.
I can request a lease from here, and we are going to see the different lease templates that are public. I could select one. Accept the terms. These terms are configurable. There is a concept of global configuration, which is managed in App Config in the hub account. We can change the terms of service and the maximum number of sandboxes one user can have. Right now I have 2, and I have it set to 3, so I can get a total of 3. We can change the absolute maximums for lease templates, so we could say no lease template can be created larger than $500. We can require cost report groups. They worked extremely hard to make this as configurable as possible.
One thing I have not mentioned is that everything I am doing in the UI is supported with API support. There is a full open API spec, so you can build this into your existing process. I am going to finish the request now. It has completed. Let me jump back. Here is the QR code for Innovation Sandbox on AWS. Since the launch in May, I have probably talked to maybe 50 to 100 customers either deployed or deploying the solution. Some of the common use cases we see include universities, which is a very common one. We see highly regulated customers. We also see hackathons, and the big one I have not mentioned at all yet is GenAI. We see lots of requests for Innovation Sandbox on AWS to test building in sandboxes, whether it is agentic building or building agentic applications. It is a perfect, isolated, secure place with cost and time controls.
Thank you very much. I appreciate it. As always, please complete the survey if you can. I really appreciate it.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)