-
Notifications
You must be signed in to change notification settings - Fork 53
FAQs
Answers to common questions about evaluating, deploying, and operating Innovation Sandbox on AWS.
- General Information
- Features & Benefits
- Use Cases
- Deployment & Prerequisites
- Identity & Access Management
- Leases, Accounts & Lifecycle
- Blueprints & Customization
- SCPs & Guardrails
- Account Cleanup & AWS Nuke
- Cost, Billing & Credits
- Integration with Landing Zones & Control Tower
- Multi-Org, Multi-Instance & Scale
- Upgrading, Roadmap & Support
- Troubleshooting
- Additional Resources
Innovation Sandbox on AWS (ISB) automates the provisioning, governance, and lifecycle management of temporary AWS sandbox accounts. It gives organizations a self-service way to hand out time-boxed, budget-controlled AWS accounts that are automatically cleaned up and recycled when no longer needed.
No, it is not a managed AWS service. Innovation Sandbox on AWS is a packaged software product that is created, maintained, and supported by AWS. It receives regular feature releases and security updates, and customers deploy it into their own AWS accounts using CloudFormation. Customers with an AWS Support plan can open support cases against the product just as they would for an AWS service (support plan levels apply; see "Is Innovation Sandbox supported?" below).
For a list of supported regions where Innovation Sandbox can be deployed, see the Supported AWS Regions section of the implementation guide.
No. ISB requires AWS Organizations but does not require AWS Control Tower. Innovation Sandbox can be deployed in an organization that has Control Tower enabled, with some coexistence considerations (OU governance and drift detection). See Integration with Landing Zones & Control Tower.
Innovation Sandbox is specifically designed to manage temporary AWS accounts for experimentation, training, and prototyping with automated cleanup and recycling. Landing Zone Accelerator (LZA) sets up and manages enterprise AWS environments aligned with AWS best practices and global compliance frameworks. They serve different purposes and complement each other: for example, customers can use LZA to create and baseline the accounts that are then registered into the Innovation Sandbox account pool.
Innovation Sandbox is built and maintained by a dedicated product and engineering team at AWS.
Yes. Innovation Sandbox is a fully supported AWS product. Support includes:
- AWS Support Center access (Developer, Business, or Enterprise Support levels). Innovation Sandbox appears as a selectable option under "Solutions" in the AWS Support console.
- GitHub Issues for bug reports and feature requests
- Comprehensive documentation, including the Implementation Guide, a hands-on workshop, and a free AWS Skill Builder course
Yes. Innovation Sandbox is open source, released under the Apache 2.0 license on GitHub, and customers are free to modify, extend, and customize it as needed. AWS actively supports many customers who have customized the product.
Note that while the code is publicly available, AWS operates the GitHub repository a bit differently than more typical open source projects. Users are encouraged to submit issues and pull requests, but AWS does not merge public PRs directly. All changes go through AWS's internal review, release, and publishing process, so accepted contributions appear in a subsequent official release rather than being merged on GitHub.
Note on support boundaries: AWS Support covers the product as published. Customer-made modifications themselves are not covered, and if a deployment deviates significantly from the official version, there is a practical limit to how effectively AWS can troubleshoot it. The underlying AWS services remain fully supported regardless.
Innovation Sandbox is deployed into the customer's own AWS accounts using CloudFormation templates. See Deployment & Prerequisites below and the Implementation Guide for details.
Sandbox accounts are standard AWS accounts, governed by the service control policies (SCPs) the customer has in place. ISB ships with a default SCP that allows more than 130 commonly used AWS services: those that can be reliably cleaned up by AWS Nuke, a third-party open source cleanup tool (not an AWS product). The full default allowlist is in the GitHub repository. Sandbox activity is also restricted to the AWS Regions the administrator configures (managed regions).
Customers can modify the SCPs in both directions: allow additional services, or further restrict the defaults to fit their security and cost requirements. When allowing additional services, verify that AWS Nuke can clean them up (or explicitly filter them from deletion and protect them with SCPs); otherwise cleanup may fail and accounts will be quarantined. AWS continues to expand the default allowlist as additional services become supported by AWS Nuke.
Deprecated services (e.g., Cloud9) are not available in sandbox accounts, just as they are not available in any standard AWS account.
Lease templates can be public or private. Public templates are visible to all end users on the web portal; private templates are hidden from the self-service catalog. Combined with direct lease assignment, this lets ISB support both a self-service model (users request from visible templates) and an assignment model (managers allocate "invite only" templates to specific users).
Automated Environment Setup
- Single-click CloudFormation deployment
- Reduces sandbox setup time from days or weeks to seconds
- Pre-configured SCP policies and guardrails aligned with best practices
- Automated setup of sandbox Organizational Units (OUs)
Simple Web Interface
- User-friendly web front-end for administrators, managers, and users
- Enables easy provisioning without technical expertise
- Streamlined account management interface
Built-in Security and Governance
- Automated OUs with pre-configured policies
- Workload isolation best practices
- Service and Region restrictions enforced through customizable SCPs
- Standardized guardrails across sandbox accounts
Cost & Account Lifecycle Management
- Granular budget controls with automated alerts
- Time-based account duration settings
- Usage monitoring and reporting
Automatic Account Cleanup
- Automated account recycling via AWS Nuke
- Freeze (prevent new resource creation) or terminate (full cleanup) at configured thresholds
- Effortless account reset for reuse
Blueprints
- Register, configure, and deploy CloudFormation StackSets as reusable infrastructure templates
- Automatically provisioned into sandbox accounts at lease creation
- Configurable deployment strategies with region targeting, concurrency, and failure tolerance
Lease Management
- Direct lease assignment by managers
- Frozen lease recovery
- Cost report groups for chargeback allocation
- Lease template visibility controls (public or private templates)
Innovation Sandbox is applicable to a wide variety of customers globally, including:
- Enterprise organizations – give builders a safe, budget-controlled space to evaluate services, prototype, and run internal training without touching production environments.
- Universities and education institutions – issue students real AWS accounts for coursework with per-student budgets, automatic expiration, and cleanup at the end of a class or semester.
- Government agencies – enable experimentation inside tightly governed environments, with guardrails that can be tightened to meet agency policies.
- Research institutions – let researchers quickly explore how AWS can address a research challenge, then either recycle the account or eject it with its resources intact to continue the work long-term (see Leases, Accounts & Lifecycle). Research IT teams value being able to issue temporary accounts quickly and clean them up if the researcher decides not to proceed.
- AWS Partners – build managed sandbox offerings on top of ISB for their own customers.
Yes. This is one of the stronger ISB use cases: organizations whose standard environments are locked down can use ISB to offer builders a controlled space for experimentation. The sandbox OUs sit apart from production OUs, the default SCPs restrict what can run, and customers can tighten the guardrails further (stricter SCPs, managed region limits, network controls) to meet their compliance requirements. Accounts are automatically cleaned up and recycled, so nothing lingers beyond the lease.
AWS Academy teaches students how to use AWS, while Innovation Sandbox allows students to build on AWS with broad access (limited only by what their institution configures). Innovation Sandbox provides a pathway from AWS Academy's free, pre-configured learning environments to real AWS accounts. Note that the Innovation Sandbox software itself is free; the AWS service usage inside sandbox accounts is billed to the institution like any other AWS usage.
Yes. Several partners have built managed sandbox offerings on top of ISB. Partners can manage the billing/MOU process for their customers and deploy ISB centrally to serve multiple entities. ISB works with Billing Transfer scenarios since it only interacts with the Cost Explorer API.
Key prerequisites include:
- AWS Organizations
- IAM Identity Center (in the management account or a delegated admin account)
- Trusted access activated for CloudFormation StackSets
- Resource sharing enabled via AWS Resource Access Manager
- Amazon SES configured for notifications
- Cost Explorer enabled on the Org Management account (takes approximately 24 hours to activate)
- Dedicated AWS Lambda concurrent executions quota of at least 1,000 in the Hub account (where the ISB compute resources run)
See the full prerequisites in the Implementation Guide.
ISB is deployed via CloudFormation as four stacks: AccountPool, IDC (Identity Center), Data, and Compute. There are two common deployment patterns:
- Within an existing AWS Organization – deploy ISB alongside existing workloads, with the sandbox account pool in its own OU subtree. Simplest to operate; requires coexistence consideration if Control Tower governs the org.
- Dedicated AWS Organization – stand up a separate organization just for ISB. Provides stronger isolation, avoids Control Tower drift findings, and scopes credit sharing to sandbox accounts only, at the cost of managing another org.
Both patterns are used by customers; the choice trades isolation strength against management overhead.
Innovation Sandbox does not create or vend accounts. Account creation is performed by the customer, who can either bring existing accounts or create a fresh pool of accounts (recommended). This can be done through AWS Organizations or Control Tower's Account Factory.
Deployment follows a straightforward CloudFormation-based installation process with clear steps in the Implementation Guide. The initial setup includes deploying the four CloudFormation stacks (AccountPool, IDC, Data, Compute), followed by post-deployment configuration steps (SAML application setup, user onboarding). Most customers complete the initial deployment in a few hours. If you are integrating an external identity provider (e.g., Microsoft Entra ID or Okta), plan for an additional 1–2 hours of IdP configuration.
Root/
├── OrgManagement account
├── Infrastructure OU (or your equivalent)
│ └── ISB Hub account
└── ISB OU/ <- created by the customer
└── InnovationSandboxAccountPool OU/ <- created by the solution
├── Available/
├── Active/
├── Frozen/
├── CleanUp/
├── Quarantine/
├── Entry/
└── Exit/
Who creates what:
- The customer creates the parent OU (the "ISB OU" above, chosen at deployment time) and decides where the Hub account lives.
- The solution (AccountPool stack) creates the account pool OU and the lifecycle OUs beneath it (Available, Active, Frozen, CleanUp, Quarantine, Entry, Exit).
Treat the ISB Hub account as production infrastructure: place it in your standard infrastructure/workloads OU rather than under the ISB OU. This keeps any custom sandbox-restricting SCPs you attach to the ISB OU from limiting the Hub account, and the Hub account is not a sandbox, so it has no reason to live in the sandbox OU subtree.
Important: Never place the Hub or Org management accounts inside the account pool OU. The SCPs applied to that OU will interfere with Hub and Org management account operations.
Yes. Innovation Sandbox requires customers to integrate IAM Identity Center with their identity provider (or use the native IAM Identity Center directory) as a prerequisite. Users log in through IAM Identity Center or through the Innovation Sandbox UI via SAML 2.0.
ISB integrates with AWS IAM Identity Center, which supports:
- Native IAM Identity Center directory (built-in)
- Active Directory (via AWS Directory Service)
- External IdPs such as Microsoft Entra ID (Azure AD), Okta, and other SAML 2.0 providers
See the IAM Identity Center documentation for configuration details.
At a high level: create the three ISB groups in your IdP, sync them to IAM Identity Center via SCIM, configure the SAML application, and verify email attribute mapping. For the full walkthrough, follow the Configuring External IdP documentation rather than working from this FAQ.
Two useful notes:
- You can reuse existing IdP groups. ISB looks up groups by DisplayName first. If a matching group already exists in IAM Identity Center, ISB uses that group rather than creating a new one.
- Connecting your corporate IdP does not expose ISB to your whole directory. Application access is restricted to members of the three ISB groups (Admins, Managers, Users); no one else in the IdP gains access.
Q: We use direct IAM federation with our corporate IdP today. Can we use a separate IdP just for ISB?
Some customers federate into AWS directly through IAM (not IAM Identity Center) and want to connect a different IdP only for ISB. IAM Identity Center supports only one identity source per organization, so if the customer wants a separate IdP dedicated to ISB, they would need a separate AWS Organization. However, direct IAM federation and IAM Identity Center can coexist in the same organization: customers can continue using direct federation for existing workloads while enabling IAM Identity Center (with either IdP) for ISB.
Q: When using the IAM Identity Center native directory, the email claim is not being passed in the JWT. What should I do?
Verify the user's email attribute is correctly stored in IAM Identity Center by running:
aws identitystore list-users \
--identity-store-id $(aws sso-admin list-instances \
--query "Instances[0].IdentityStoreId" --output text)Confirm the Emails array has the correct email value with Primary set to true. If the email is missing or incorrect, update the user profile.
ISB provides three role-based personas, mapped to three groups in IAM Identity Center:
| Capability | Administrator | Manager | User |
|---|---|---|---|
| Configure the product (account pool, SCPs, Blueprints, global settings) | Yes | No | No |
| Create and manage lease templates | Yes | Yes | No |
| Approve or directly assign lease requests | Yes | Yes | No |
| Monitor usage and recover frozen leases | Yes | Yes | No |
| Access end users' sandbox accounts (even beyond active lease status) | Yes | Yes | No |
| Request a lease and work in a sandbox account | Yes | Yes | Yes |
Only members of the Admin or Manager groups can approve lease requests.
No. The default SCPs deny iam:CreateUser and protect ISB's control plane (IAM Identity Center configuration, Organizations settings, and ISB-managed roles) from tampering. Users can create IAM roles and policies (many AWS services require service roles to function), but SCPs apply to every principal in the account, including roles users create themselves, so the guardrails cannot be bypassed this way. If users need access to services blocked by SCPs, an administrator must evaluate the security implications and modify the SCPs accordingly.
ISB currently operates on a one-user-per-lease model. Users (or Managers on their behalf) request a lease from a lease template. Once approved, ISB provisions a sandbox account with the specified budget, duration, and optional Blueprint. When the lease expires or the budget is exhausted, the account is cleaned up for reuse.
Multi-user leases are on the roadmap but not currently supported. In the interim, you can manually add additional users to the lease's IAM Identity Center permission set in the sandbox account. ISB will revoke access from all users on that permission set when the lease terminates. Note that additional users will not see the lease in the ISB web UI and must use the IAM Identity Center access portal directly.
Yes. Managers can directly allocate sandbox leases to users, complementing the self-service request model.
It depends on how the lease template is configured. Budget thresholds can each trigger a different action at a specified spend level: send an alert email, or freeze the lease. Separately, when a lease's maximum budget is reached, the lease is terminated and the account is cleaned up and recycled.
There is approximately a 24-hour delay in AWS cost data, so actual spend may briefly exceed a threshold before the configured action takes effect. Some organizations set internal thresholds slightly below the real limit to provide a buffer.
Note: Freezing prevents further access by the end user, but it does not stop billing. Running resources continue to incur costs until the account is cleaned up.
Yes. Administrators and Managers can restore a frozen lease back to active status with an updated budget or duration. Freezing and unfreezing only change user access; the resources and data in the account are not modified.
Yes. ISB has a built-in "Eject Account" feature that moves the account to an Exit OU exactly as-is, preserving everything in it:
- No cleanup runs
- All user-created resources and Blueprint-deployed infrastructure are retained
- ISB's SCPs stop applying once the account leaves ISB's OUs
To put the ejected account to work in your environment: move it from the Exit OU into the appropriate OU in your organization (so your standard guardrails apply), re-establish access through your normal mechanism (IAM Identity Center assignments or federation), and optionally remove the leftover ISB artifacts (InnovationSandbox-* and stacksets-exec-* IAM roles). IAM Identity Center access granted through ISB is revoked at ejection.
Yes. Customers are required to create or supply the accounts themselves and onboard them into the pool. See How does Innovation Sandbox create/vend accounts?
Blueprints are reusable CloudFormation StackSets that administrators register and attach to lease templates. When a lease is approved, the Blueprint is automatically deployed into the sandbox account, pre-loading it with infrastructure such as:
- Course materials and lab exercises for university classes
- Standard networking and security baselines for enterprise teams
- Pre-configured toolchains for software development
- Connectivity to external data sources or resources
- An Administrator registers a CloudFormation StackSet as a Blueprint
- The Blueprint is attached to one or more lease templates
- When a lease is approved, ISB automatically deploys the Blueprint's StackSet into the sandbox account
- Blueprints support configurable deployment strategies with region targeting, concurrency controls, and failure tolerance
Q: Can I deploy complex AWS services (e.g., SageMaker Unified Studio) inside sandbox accounts using Blueprints?
Blueprints can deploy any infrastructure expressible as a CloudFormation StackSet. For complex services like SageMaker Unified Studio (SMUS):
- SCP compatibility must be verified (e.g., Lake Formation and
ram:CreateResourceShareare blocked by default) - A test cleanup cycle is recommended to validate that AWS Nuke can reliably clean up all deployed resources
Yes. Administrators can configure:
- Terms of Service documents
- Budget and duration thresholds per lease template
- SCPs (service restrictions and guardrails)
- AWS Nuke cleanup configuration (resource filtering)
- Blueprint StackSets for environment pre-provisioning
- IP allow lists for UI access
- Cost report groups for chargeback
Since Innovation Sandbox is open source, customers can also modify the source code directly for deeper customization.
No. There is no direct LMS integration. However, ISB integrates into the customer's SSO environment, which makes it easy to give access to groups of users.
ISB applies SCPs to sandbox accounts to enforce guardrails:
- Supported services SCP: Limits sandbox accounts to services that AWS Nuke can reliably clean up (130+ services by default)
- Region limits SCP: Restricts activity to the managed regions the administrator configures
- Control-plane protection: Prevents sandbox users from modifying IAM Identity Center, Organizations settings, and ISB management roles
-
Explicit denials: Blocks specific risky or cost-implicating actions such as
iam:CreateUser,ram:CreateResourceShare, reserved-capacity purchases, and certain administrative operations
Yes. Service Control Policies in AWS Organizations implement an inheritance model where policies cascade downward through the organizational hierarchy.
Yes. Customers can modify the SCPs to allow or deny additional services. When doing so:
- Any service you allow should also be supported by AWS Nuke for cleanup, otherwise resources may persist and cause accounts to quarantine
- Any resource you filter out of Nuke deletion should have its creation/deletion actions SCP-protected to prevent resource pollution
See the public roadmap for planned improvements to SCP customization.
Note: Manual changes to the ISB-managed SCPs can be overwritten by CloudFormation stack updates. Document your customizations and reapply them after upgrading.
Yes, and this is a common pattern. Rather than editing the ISB-managed SCPs, attach your own SCPs to the ISB OU or the account pool OU. SCPs combine restrictively (an action must be allowed by every policy in the chain), so your custom SCP can only tighten the guardrails. Custom SCPs attached this way are not touched by ISB stack updates, making them easier to maintain across upgrades than edits to the ISB-managed policies.
Not directly within a single ISB deployment. Each deployment applies one set of SCPs to all sandbox accounts. To support different sandbox "tiers," customers can deploy multiple ISB instances with different SCP configurations. Per-lease-template SCPs are a noted feature request.
The ISB SCP only allows services validated to work with AWS Nuke cleanup. If a service is not in the allowlist, access is denied. The default allowlist has expanded over time (Amazon Bedrock and API Gateway are now included by default), but some services (e.g., Textract, Lake Formation) still require manual SCP additions. Check the default SCP allowlist for your deployed version, and the GitHub Issues for community-contributed SCP additions.
This is commonly a cross-region inference issue. Many Bedrock models are served through cross-region inference profiles, which route requests to other AWS Regions. ISB's managed-regions SCP denies activity outside the configured regions, so a model whose inference profile spans regions outside your managed set will fail. Either add the inference profile's regions to the managed regions configuration, or use models/profiles served entirely within your managed regions. See the Bedrock documentation for the region list per inference profile.
ISB sandbox accounts are standard AWS accounts with standard access and resource permission mechanisms. ISB applies SCPs to limit services, budget enforcement, and automated cleanup. Within the scope of what SCPs allow, sandbox users have broad access.
ISB is not designed to be a maximum-isolation sealed environment. For example, a user could potentially exfiltrate data from a sandbox account, just as they could from any AWS account. Customers with strict data isolation requirements should apply additional guardrails (VPC endpoint policies, tighter SCPs, network restrictions) as they would for any AWS account.
Yes. ISB has a built-in managed regions configuration: sandbox activity is restricted via SCP to the regions the administrator selects. Customers can adjust the managed regions list or layer additional region-restricting SCPs of their own.
When a lease terminates, ISB uses AWS Nuke (a third-party open source tool, pinned to a validated version in each ISB release) to delete user-created resources. The account moves through the OU pipeline:
- Active → CleanUp (Nuke runs)
- If successful: CleanUp → Available (account is recycled)
- If failed: CleanUp → Quarantine (requires intervention)
SCPs limit which resources can be created to ensure AWS Nuke can reliably clean up the account.
A quarantined account is one where AWS Nuke failed to clean up all resources. This prevents "dirty" accounts from being leased to new users. To resolve:
- Retry the cleanup process
- If cleanup keeps failing, investigate the Nuke logs for the specific resource causing the failure
- Update the Nuke configuration to filter out the problematic resource
- See the Resolving Account Cleanup Failures documentation
This error occurs when the same AWS Region is listed twice in the Nuke configuration. ISB automatically injects configured regions into the Nuke config based on the managed regions list in the AccountPool stack. If you manually added a region that ISB already injects, remove the duplicate.
Yes. The AWS Nuke configuration (in AWS AppConfig in the Hub account) can be modified to filter out specific resources from deletion. See the AWS Nuke config filtering documentation.
Important: Anything you filter out of deletion should also have its creation/deletion actions SCP-protected to prevent resource pollution.
There is no cost for the Innovation Sandbox application itself; the product is open source. Once installed, there are two categories of AWS charges:
- A small idle cost for the AWS resources that run the ISB application in the customer's account
- The cost of AWS services consumed within the sandbox accounts (depends entirely on the users' workloads)
See the Cost section of the Implementation Guide for a detailed cost breakdown and estimates.
Sandbox account costs roll up to the organization's management (payer) account, which is charged for both the nominal running costs of the application and the cost of AWS services used in sandbox accounts.
Innovation Sandbox takes a best-effort approach to budget enforcement. Due to limitations in AWS cost reporting (up to 24-hour delay), Innovation Sandbox cannot guarantee that budgets will never be exceeded. ISB prioritizes observability of budget consumption with configurable thresholds and notifications. Recommended mitigation strategies:
- Set tight SCPs to prevent users from accessing expensive AWS resources
- Set the budget threshold below the actual maximum (e.g., set $150 if the real limit is $200)
Yes. ISB only interacts with the Cost Explorer API, which remains available in Billing Transfer accounts. Budget calculations will reflect the prices visible to the customer via Cost Explorer, which may differ from invoiced prices.
ISB's cost report groups can tag leases for chargeback purposes. Since accounts are recycled, per-lease cost reporting is more appropriate than account-level billing reports.
Q: Can sandbox accounts benefit from an existing EDP (Enterprise Discount Program) or other private pricing agreement?
Yes. Since sandbox accounts are within the customer's existing AWS Organization, they automatically receive the pricing from the customer's existing EDP or other private pricing agreement.
There is no dedicated credit program for Innovation Sandbox, and credit availability varies by region. Talk to your AWS account team about credit options that may apply to your organization.
Customers have two options for applying credits:
- Account-level: Credits apply to a single account only. Unused credits are lost.
- Org payer-level with credit sharing: Define which sub-accounts are eligible. Good for directing credits specifically to sandbox accounts.
Note: Credit sharing is a global setting. Credits from other AWS programs injected into the payer account (for example, MAP credits) will follow the same sharing rules. To avoid this, customers can create a dedicated AWS Organization for the ISB account pool.
ISB can coexist with Control Tower and LZA. Key considerations:
- ISB manages its own OU structure and SCPs; Control Tower governance on those OUs would conflict
- Control Tower drift: ISB moves accounts between OUs (based on lifecycle state), which Control Tower identifies as a drift violation
- Two solutions: (1) exclude the ISB OU from Control Tower management, or (2) create a dedicated AWS Organization for ISB
- LZA baseline resources deployed into sandbox accounts will be cleaned up by Nuke unless you configure Nuke to exclude them
Both patterns are adopted by customers depending on preference (stronger isolation vs. less management overhead).
- Configure AWS Nuke to exclude LZA baseline resources from deletion
- Add the ISB OU structure to the LZA config post-deployment
- See the LZA deployment guidance in the workshop appendix
Not natively in the current release. SCP names and certain resource names collide. However, customers have successfully done this by prefixing SCP names with the ISB namespace in the CloudFormation template. Official support for parallel deployments is on the roadmap.
Yes. Several large-scale centralized deployments exist, including enterprises, government agencies, and large university systems. The lease template and role-based access model supports this pattern.
ISB is in production at organizations ranging from small teams to large-scale deployments (thousands of users and sandbox accounts) across education, government, and enterprise sectors.
Follow the Update the Solution section of the Implementation Guide. The process involves updating the CloudFormation stacks.
Note: Stack updates can overwrite manual changes to the ISB-managed SCPs and Nuke configuration. Document your customizations and reapply them after upgrading (custom SCPs attached as separate policies to the OUs are not affected).
- Public GitHub roadmap: GitHub Projects Board
- Release notes: GitHub Releases
- Open an issue on GitHub for bugs, feature requests, and documentation feedback
- Pull requests are also welcome, though they are not merged directly; accepted contributions are incorporated through AWS's internal review and release process and appear in a subsequent official release (see "Is Innovation Sandbox open source?" in General Information)
- Open a case through AWS Support for deployment-specific help
The Solution Terms of Use, which administrators accept during deployment, can be found in the GitHub repository: terms-of-use.txt. Separately, administrators can configure their own custom Terms of Service that sandbox users must accept in the web UI.
This error typically occurs when the CloudFormation stack is deployed to a different AWS Region than where IAM Identity Center is provisioned. Deploy the IDC stack in the same Region as your IAM Identity Center instance. A region mismatch is the most common cause of this error.
- Review the AWS Nuke logs in the Hub account
- Common culprits: organization-managed CloudTrail trails, Security Hub resources, organization-managed views, LZA baseline resources
- Update the Nuke configuration in AppConfig to filter out those resources
- Retry the cleanup
- If all else fails, consider a clean uninstall/reinstall (reusing the same accounts)
- Session timeout: Refresh your browser to re-authenticate
- Maintenance mode: If enabled, Manager and User roles will receive 403 errors. Contact your Admin to disable maintenance mode in AWS AppConfig
-
SAML callback URL: Ensure it matches
https://<cloudfront-domain>/api/auth/login/callback - CloudFront configuration: Verify the distribution is properly configured and accessible
The Textract console demo page calls the freetier service behind the scenes. If the ISB SCP does not include freetier in its allowlist, this call is denied. Update the SCP to allow freetier, or use the Textract API directly.
A formatting issue was identified in the AWS Health event notification for v1.1.7. The reference URL in the email is malformed. Use the numbered links in the notification body ([1] through [5]) rather than the broken reference link at the bottom.
- Ensure the SAML application callback URL matches exactly
- Verify email attribute mapping is correctly configured in both the IdP and IAM Identity Center
- Confirm the Identity Center groups match the expected ISB group names
- Check that the user has a valid, primary email address in the identity store
- Review the SsoHandler Lambda function logs for detailed error messages
| Resource | Link |
|---|---|
| Landing Page | aws.amazon.com/solutions/implementations/innovation-sandbox-on-aws |
| Implementation Guide | docs.aws.amazon.com – Innovation Sandbox on AWS |
| GitHub Repository | github.com/aws-solutions/innovation-sandbox-on-aws |
| Skill Builder Course | Innovation Sandbox on AWS (free) |
| Workshop | Innovation Sandbox on AWS Workshop |
| Product Video (YouTube) | youtu.be/FFFVSvMHaBg |
| Blog Post | Empowering educators with Innovation Sandbox on AWS |
| Public Roadmap | GitHub Projects |
Last updated: July 2026. For the latest information, refer to the Implementation Guide and the GitHub repository.