Your sandbox lease ended, or your team got a new sandbox account, and your app stopped working. Nothing is wrong with your code. This guide gets the same app running again in the new account.

What Happens When a Sandbox Lease Ends

When a lease ends, the sandbox account is wiped clean and returned to the pool. A new lease gives you an AWS account that is almost always a different one (a new Account ID), with nothing in it.

Before You Start

• Your new sandbox lease shows Active in the Innovation Sandbox web app
• Your GitHub repository still has infra/template.yaml, backend/, frontend/ and .github/workflows/deploy.yml
• If your app uses an API key (API_KEY_VALUE in Step 6 of the main tutorial), you have that value, or you are happy to make up a new 20+ character string
• Kiro is installed and signed in on your computer, and your project folder is open in it. Kiro installs everything else for you in Step 3
• You know which region your app uses. The tutorial now uses Malaysia (ap-southeast-5). Apps built earlier may still say ap-southeast-1 inside deploy.yml (see the note in Step 3)

Step 1 — Get Into Your New Account

1. Open aws-sandbox.eliteacademy.id → Leases → your new lease → Access Account.
   Or go straight to the sign-in portal eliteacademy.awsapps.com/start, enter your email, and choose the account named like ETA-Sandbox-NN → Management console.
2. Write down your Account ID (top-right corner, click your name). It is different from your old account.
3. Choose Asia Pacific (Malaysia) in the region menu (top-right). Sandbox accounts only allow these five regions:

Step 2 — Check That Bedrock Works

1. Search for Bedrock in the console, make sure you are in your region, then open Playground → Chat.
2. Pick a model, type hi, and click Run. You should get an answer.

In current sandbox accounts the Anthropic models work without a separate Model access request. If Bedrock shows a form asking about your use case, fill it in (for example "Student hackathon project") and wait for approval, which is usually instant.

Model IDs That Work in a Sandbox

Checked in a sandbox account, region Malaysia, in October 2026. Use these exact IDs in your Lambda code.

If your Lambda gets an AccessDenied that does not mention a service control policy, your function's role is missing Bedrock permissions. Make sure its policy in template.yaml includes:

- Effect: Allow
  Action:
    - bedrock:InvokeModel
    - bedrock:InvokeModelWithResponseStream
  Resource:
    - !Sub arn:aws:bedrock:${AWS::Region}:${AWS::AccountId}:inference-profile/global.*
    - !Sub arn:aws:bedrock:${AWS::Region}::foundation-model/*
    - arn:aws:bedrock:::foundation-model/*

Step 3 — Let Kiro Deploy Everything

You do not run any command yourself. Copy one prompt into Kiro and Kiro does the whole job on your computer: installs the tools that are missing (AWS CLI, SAM CLI, uv), sets up your sandbox sign-in, fixes the region and models, deploys, uploads the website and tests it. The only thing you do by hand is click Allow when the browser sign-in page opens, and answer if Kiro asks for your new Account ID.

1. Open Kiro and open your project folder (File → Open Folder). Not installed yet? Follow Kiro Login via Elite Academy Portal first.
2. Keep Kiro in Supervised mode, so it shows each command and waits for your Approve click.
3. Have your new Account ID ready (from Step 1). Paste the prompt below into the Kiro chat and send it.

You are my deployment assistant. My AWS sandbox expired and I got a NEW sandbox account. Redeploy this project there. You do EVERYTHING yourself: install missing tools, set up my sign-in, run every command, read the output, fix problems, and report. I only click "Allow" in the browser when the sign-in page opens. Never ask me to run commands.

RULES (follow strictly)
- Only touch the account that the AWS profile "sandbox" points to. Use --profile sandbox --region ap-southeast-5 (Malaysia) on every aws and sam command.
- Never create IAM users or access keys, never print or ask for secrets, never delete anything outside this project's own stack, never run git push, never overwrite an existing AWS profile or config file without making a backup copy first.
- Before each step, say in one line what you are about to do. If something fails, read the error, find the root cause (CloudFormation events, Lambda logs), fix it and retry. Stop and ask me only if you need a decision, my Account ID, or my sign-in.

STEPS
0. SET UP TOOLS. Detect my operating system. Check aws --version (need AWS CLI v2), sam --version (AWS SAM CLI) and uv --version. Install whatever is missing with the official method for my OS (macOS: Homebrew or the official installer; Windows: winget or the official MSI; Linux: the official installer). Ask me before anything that needs administrator or sudo rights. Show the final versions.
1. SET UP MY SIGN-IN. FIRST ask me for my NEW sandbox Account ID (12 digits, from my Active lease in the Innovation Sandbox web app) if I did not write it above, and remember it. Then run "aws sts get-caller-identity --profile sandbox". If it works AND the Account number equals the one I gave, skip to step 2. If the profile exists but shows a DIFFERENT account, it is an old or expired sandbox: do NOT use it, tell me, and fix the profile as below. If any later call fails with "explicit deny in a service control policy" (for example p-1lb4bh9n), do NOT ask me to contact an administrator: first check that the Account ID is my current active lease, because an old account that was returned to the pool is blocked on purpose. Back up ~/.aws/config, then add these blocks (if a profile named sandbox exists, show me and ask first):
[sso-session sandbox]
sso_start_url = https://eliteacademy.awsapps.com/start
sso_region = ap-southeast-1
sso_registration_scopes = sso:account:access
[profile sandbox]
sso_session = sandbox
sso_account_id = <MY ACCOUNT ID>
sso_role_name = myisb_IsbUsersPS
region = ap-southeast-5
output = json
Then run: aws sso login --profile sandbox . A browser opens: tell me to click Allow, then wait. Finally run aws sts get-caller-identity --profile sandbox and show the Account ID. It must equal the one I gave. If the session expires later (ExpiredToken), run the login again and continue.
2. CONNECT THE AWS MCP SERVER (optional helper). Create or merge .kiro/settings/mcp.json in this project with a server named aws-mcp-sandbox: command uvx, timeout 100000, transport stdio, args ["mcp-proxy-for-aws@latest", "https://aws-mcp.us-east-1.api.aws/mcp", "--profile", "sandbox", "--metadata", "AWS_REGION=ap-southeast-5"]. Keep any other servers already in the file. If the server does not show up as connected, do not wait: continue with the normal aws and sam commands, and tell me I can reload MCP servers later.
3. READ THE PROJECT. Read .github/workflows/deploy.yml and infra/template.yaml. Report the stack name, the template path, and every placeholder like __URL_*__ in frontend/index.html.
4. FIX OLD REGION AND MODELS. Search the whole project for "ap-southeast-1" and other hard-coded regions, and for old model IDs. Change them to ap-southeast-5 in infra/template.yaml and .github/workflows/deploy.yml (also the Bedrock IAM ARNs). Use only these model IDs: global.anthropic.claude-haiku-4-5-20251001-v1:0 (recommended), global.anthropic.claude-haiku-5-5 (only if it works), global.anthropic.claude-sonnet-5-5, global.amazon.nova-2-lite-v1:0. For each model the IAM policy needs three ARNs: arn:aws:bedrock:ap-southeast-5:<ACCOUNT_ID>:inference-profile/<id>, arn:aws:bedrock:ap-southeast-5::foundation-model/<base id without global.>, and arn:aws:bedrock:::foundation-model/<base id without global.>. Show me a short summary of what you changed.
5. CHECK THE MODELS. With aws bedrock-runtime converse in ap-southeast-5 (maxTokens 20, message "hi"), test these in order and show each result: global.anthropic.claude-haiku-4-5-20251001-v1:0, global.anthropic.claude-haiku-5-5, global.anthropic.claude-sonnet-5-5, global.amazon.nova-2-lite-v1:0. Use the FIRST one that answers as the app's default model: set it wherever the project defines its model ID (code, template environment variable, or config), so the app works today. Do not stop to ask me about this. If a model fails, quote the exact error and use this table: "Model use case details have not been submitted" = this account has not filled the Anthropic use-case form yet (tell me; I can fill it later in the Bedrock console, or you can submit it with aws bedrock put-use-case-for-model-access only after I give you the five answers: company name, website, intended users, industry, use case); "explicit deny" = the sandbox blocks that model, do not try to bypass it; "model identifier is invalid" = wrong model ID or not offered in Malaysia.
6. BUILD AND DEPLOY. Run sam build --template infra/template.yaml, then sam deploy --stack-name <stack from deploy.yml> --resolve-s3 --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ap-southeast-5 --profile sandbox --no-confirm-changeset --no-fail-on-empty-changeset. Do NOT use the GitHub secrets or --s3-bucket. IMPORTANT: Lambda Function URLs (FunctionUrlConfig) do not exist in ap-southeast-5. If the template uses them, replace them with an AWS::Serverless::HttpApi (CORS *) and an HttpApi event per function, keep the same URL placeholders, and tell me what you changed.
7. WEBSITE. Read the stack outputs. Replace every __URL_*__ placeholder in frontend/index.html with the matching output URL (same logic as the workflow). If the file contains old real URLs or an old Account ID instead of placeholders, replace those too. Then upload with aws s3 sync frontend/ s3://<FrontendBucketName>/ --cache-control no-cache --profile sandbox --region ap-southeast-5.
8. TEST. Call the backend URL with curl (POST, JSON body {"prompt":"Say hi in five words"}) and fetch the FrontendUrl with curl. Show the HTTP status and the first lines of each response.
9. REPORT. Finish with a table: Account ID, region, stack status, FrontendUrl, backend URL result, default model, files you changed. List anything I must do myself (for example the Anthropic form or GitHub secrets).

When something fails, or you want to understand a result, just ask Kiro:

grep -rn "ap-southeast-1" --include=*.yml --include=*.yaml --include=*.py --include=*.html .

  AppHttpApi:
    Type: AWS::Serverless::HttpApi
    Properties:
      CorsConfiguration:
        AllowOrigins: ['*']
        AllowHeaders: ['*']
        AllowMethods: [POST, OPTIONS]

  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      # ...keep everything else, but delete FunctionUrlConfig and AWS_LWA_INVOKE_MODE
      Timeout: 25
      Events:
        Http:
          Type: HttpApi
          Properties:
            ApiId: !Ref AppHttpApi
            Path: /my-widget
            Method: POST

Outputs:
  MyApiUrl:
    Value: !Sub https://${AppHttpApi}.execute-api.${AWS::Region}.amazonaws.com/my-widget

Optional — Automatic Deploys With GitHub Actions

Only if you want every commit to redeploy by itself. Kiro already put your app online in Step 3, so you can skip this.

B1. Create the deploy user, keys and bucket. Click the CloudShell icon (>_) in the top bar of the AWS console, wait for the prompt, and run:

REGION=ap-southeast-5
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)

aws iam create-user --user-name github-deployer
for P in AWSCloudFormationFullAccess AWSLambda_FullAccess IAMFullAccess \
         AmazonAPIGatewayAdministrator AmazonS3FullAccess AmazonBedrockFullAccess; do
  aws iam attach-user-policy --user-name github-deployer \
    --policy-arn arn:aws:iam::aws:policy/$P
done

aws iam create-access-key --user-name github-deployer \
  --query 'AccessKey.[AccessKeyId,SecretAccessKey]' --output text

aws s3 mb s3://sam-deploy-$ACCOUNT-$REGION --region $REGION

B2. Update your GitHub secrets. First see which secrets your workflow uses (search secrets. in deploy.yml on GitHub):

grep -o 'secrets\.[A-Z_]*' .github/workflows/deploy.yml | sort -u

In your repository open Settings → Secrets and variables → Actions. The old secrets already exist, so click the pencil icon → Update on each one (do not create duplicates):

B3. Run the workflow. GitHub → Actions → your workflow → Run workflow. Wait 3–5 minutes for every step to turn green, then open the Print URLs step and copy the API URL and Frontend URL.

Step 4 — Check Your Frontend Points to the New Backend

Your website talks to your backend through addresses that are different in every account. There are two cases:

Kiro checks this for you in Step 3. To check it yourself (from your project folder):

grep -n "__URL_\|__API" frontend/index.html
grep -n "sed -i" .github/workflows/deploy.yml

Find every old value that points to the previous account:

grep -rnE "[0-9]{12}|execute-api|lambda-url|cloudfront.net|s3-website" \
  --include=*.html --include=*.py --include=*.yaml --include=*.yml .

A 12-digit number is usually your old Account ID. execute-api and lambda-url are old backend addresses. (Some matches, like timestamps, are harmless.) Anything that points to the old account must be changed.

To replace an old address, ask Kiro, sharing frontend/index.html:

• Kiro deployment (Step 3): already done. Kiro replaced the addresses and uploaded the file. Ask it: "Show me every old URL or Account ID left in the project."
• Optional GitHub Actions: commit the updated frontend/index.html to GitHub. The workflow redeploys by itself.

Step 5 — Restore Data and Extras (If You Use Them)

Step 6 — Check That Everything Works

• Bedrock Playground answers with the model you chose
• CloudFormation shows your stack as CREATE_COMPLETE
• Your new website address (FrontendUrl) opens in a browser
• Run All returns AI answers (5–10 seconds)
• CloudWatch → Log groups → /aws/lambda/your-function shows no errors
• (Optional GitHub Actions) The GitHub secrets were updated and the workflow is green
• You shared the new URL with your coach or audience

If Something Goes Wrong

Make the Next Expiry Painless

• Keep everything in GitHub. Templates, code and workflow files only. Never keep the only copy of something inside AWS.
• Note your expiry date. The Innovation Sandbox web app shows the days left. Set a reminder for 3 days before.
• Back up data you care about. Before expiry, for example: aws dynamodb scan --table-name YOUR-TABLE > backup.json, then keep the file in your repository (never keep the only copy inside AWS).
• Write a small REDEPLOY.md in your repository with your stack name, region and the exact deploy commands Kiro used (ask Kiro: "Write REDEPLOY.md with the commands you ran").
• Need more time? Ask your coach before the lease ends. Leases can be extended while they are still active.