Turn Your PartyRock App
Into a Real Website

Before we build anything, we need to understand what your PartyRock app does. Every app is made of "widgets." We need to write down each one.

Open Your App in Edit Mode

1. Go to partyrock.aws and sign in
2. Click on your app to open it
3. Click the Edit button in the top right corner

The 5 Widget Types

Fill In This Widget Map

For each widget, click the ✏️ edit icon and note down:

Widget #1
  Type:       [ User Input / Text Generation / Image / Chatbot / Document ]
  Title:      ________________________________
  Prompt:     ________________________________
  References: ________________________________ (other widgets it uses)

✅ Checkpoint

• List of all widgets written down
• Prompt text for each AI widget noted
• Screenshots of each widget's settings saved

Create an AWS Account

1. Go to aws.amazon.com
2. Click the orange "Create an AWS Account" button (top right)
3. Enter your email and choose an account name (e.g. "my-ai-apps")
4. Verify your email, create a password, add payment info, verify phone
5. Select Basic support — Free and complete sign up

Create an IAM User

We create a limited user called github-deployer that GitHub will use to deploy your app.

1. Sign in at console.aws.amazon.com
2. Search for IAM in the top search bar and click it
3. Click Users in the left sidebar → Create user
4. Username: github-deployer → click Next
5. Select Attach policies directly
6. Search for and check each of these 6 policies:

• AWSCloudFormationFullAccess
• AWSLambda_FullAccess
• IAMFullAccess
• AmazonAPIGatewayAdministrator
• AmazonS3FullAccess
• AmazonBedrockFullAccess

Create an Access Key

1. Click on the github-deployer user
2. Click the Security credentials tab
3. Scroll to Access keys → Create access key
4. Select Application running outside AWS → Next → Create
5. Copy and save both values somewhere safe:

Create an S3 Bucket for Deployments

1. Search for S3 in the AWS Console and click it
2. Click Create bucket
3. Bucket name: yourname-sam-deploy-2026 (must be globally unique)
4. Region: Asia Pacific (Malaysia) ap-southeast-5
5. Leave all other settings as default → Create bucket
6. Save the bucket name — you'll need it later

✅ Checkpoint

• AWS account created and verified
• IAM user github-deployer created with all 6 policies
• Access Key ID saved
• Secret Access Key saved
• S3 bucket created, name saved

Amazon Bedrock is the AI service that powers your app. By default, AI models are not enabled — you have to turn them on. It's free to request.

Open Amazon Bedrock

1. In the AWS Console search bar, type Bedrock and click it
2. Check the region in the top right and choose Asia Pacific (Malaysia) — ap-southeast-5. Use this same region for everything in this tutorial.

Request Model Access

1. In the left sidebar, click Model access
2. Click Manage model access (top right of the table)
3. Find the Anthropic section
4. Check the box next to Claude Haiku 4.5 (recommended — fast, low cost, works in every sandbox account)
5. Optionally also try Claude Haiku 5.5 or Claude Sonnet 5.5. They are newer and more capable, but AWS enables them per account, so they may answer "not available for this account". If so, stay on Haiku 4.5
6. Scroll down and click Save changes

Wait for Approval

Refresh the Model access page every few minutes. When the status shows a green checkmark and says Access granted, you're ready. Most requests are approved instantly.

✅ Checkpoint

• Opened Amazon Bedrock in ap-southeast-5 (Malaysia) region
• Claude Haiku 4.5 shows "Access granted" status

GitHub is where your code lives. Every time you save code there, it automatically deploys to AWS. No technical knowledge needed to use it for this tutorial.

Create a GitHub Account

1. Go to github.com and click Sign up
2. Enter your email, create a password, choose a username
3. Verify your email address
4. Select the Free plan

Create a New Repository

1. Click the + icon in the top right corner
2. Click New repository

3. Repository name: my-partyrock-app
4. Visibility: select Public
5. Check Add a README file
6. Click Create repository

✅ Checkpoint

• GitHub account created
• New public repository created
• Repository page visible with Code, Actions, Settings tabs

Upload the files Kiro generated for you. No Git commands needed — just drag and drop in the browser.

Your File Structure

your-app/
├── frontend/
│   └── index.html
├── backend/
│   └── lambda/
│       └── (your Python files)
├── infra/
│   └── template.yaml
└── .github/
    └── workflows/
        └── deploy.yml

Upload Your Files

Upload the frontend files

1. Click Add file → Upload files
2. On your computer, open the frontend folder and drag index.html into the upload area
3. Commit message: Add frontend files → Commit changes

Upload the backend Lambda files

1. Click Add file → Create new file
2. In the filename box, type the full path: backend/lambda/your_function.py
3. Open the .py file on your computer, copy all contents, paste into the text area
4. Commit message: Add Lambda function → Commit new file
5. Repeat for each Lambda .py file

Upload the infrastructure template

1. Click Add file → Create new file
2. Filename: infra/template.yaml
3. Copy the contents of your template.yaml file and paste into the text area
4. Commit message: Add infrastructure template → Commit new file

Upload the GitHub Actions workflow

1. Click Add file → Create new file
2. In the filename box, type exactly: .github/workflows/deploy.yml
3. Paste the contents of your deploy.yml file into the text area
4. Click Commit new file

✅ Checkpoint

• frontend/index.html uploaded
• backend/lambda/ files uploaded (one per Lambda function)
• infra/template.yaml uploaded
• .github/workflows/deploy.yml uploaded
• All 4 folders visible in the repository

GitHub needs permission to deploy to your AWS account. We add "secrets" — private values that GitHub keeps hidden and uses automatically. One of these secrets is also what locks down your API, so random strangers can't rack up your AWS bill by calling it directly.

Open Repository Secrets

1. In your GitHub repository, click the Settings tab
2. In the left sidebar, click Secrets and variables
3. Click Actions in the submenu

Make Up an API Key Value

Your API key isn't something AWS generates for you ahead of time — you pick the value yourself, right now, and your deployment uses that exact value to lock the API. Anyone calling your API without this exact value gets rejected.

1. Make up a random string at least 20 characters long — mash your keyboard, or use a free generator like a password generator site (no account needed)
2. Save it somewhere — you'll paste this same value into your frontend code in Step 8

Add the 5 Secrets

Click New repository secret for each one:

✅ Checkpoint

• AWS_ACCESS_KEY_ID secret added
• AWS_SECRET_ACCESS_KEY secret added
• SAM_DEPLOY_BUCKET secret added
• AWS_REGION secret added
• API_KEY_VALUE secret added, and the same value saved somewhere for Step 8
• All 5 secrets visible in the repository secrets list

Now we press the launch button. GitHub Actions will connect to AWS, create all the services, and give you a live URL. Takes about 3–5 minutes.

Trigger the Deployment

1. In your GitHub repository, click the Actions tab
2. In the left sidebar, click your workflow name (e.g. "Deploy Health Tracker")
3. Click the Run workflow button on the right
4. Click the green Run workflow button in the popup

Watch It Run

1. Refresh the page — a new row appears with a yellow spinning circle
2. Click that row, then click the deploy job
3. Watch each step get a green ✅ checkmark

What Each Step Does

If Something Goes Wrong

✅ Checkpoint

• Deployment triggered from the Actions tab
• All steps show green checkmarks
• No red X errors

Find Your Live URL

1. Go to the Actions tab in GitHub
2. Click your most recent successful deployment run
3. Click the deploy job
4. Scroll to the last step: Print URLs and expand it
5. Copy both the Frontend URL and the API URL

Add Your API Key to the Frontend

Your app won't work yet — the frontend doesn't know the API key you chose in Step 6. We paste it in now.

1. Open Kiro, share your frontend/index.html file
2. Ask: "Set the API_KEY constant (or equivalent) to [paste your API_KEY_VALUE from Step 6], and set the API URL to [paste your API URL from above]."
3. Kiro updates the file for you — review the change, then save it
4. Upload the updated index.html to GitHub the same way you did in Step 5 — this triggers an automatic redeploy
5. Wait for the GitHub Action to finish (watch the Actions tab, same as Step 7)

Open and Test Your App

1. Paste the Frontend URL into a new browser tab
2. Fill in the input fields
3. Click Run All
4. Wait 5–10 seconds — the AI output areas fill with responses

Check Your Logs (If Something's Wrong)

If a request fails or the output looks wrong, your Lambda function's logs usually show exactly why.

1. In the AWS Console, search for CloudWatch and click it
2. In the left sidebar, click Log groups
3. Find the log group named /aws/lambda/your-function-name and click it
4. Click the most recent log stream — the entries are your Lambda's output, newest at the bottom

Share It

Your app URL works for anyone in the world — no AWS or PartyRock account needed. Just share the link.

Before vs. After

What Kind of Sandbox Do You Have?

Using Innovation Sandbox on AWS (ISB)

How ISB Works

Getting Your ISB Sandbox Credentials

1. Log in to the Innovation Sandbox Web UI at aws-sandbox.eliteacademy.id
2. Request a new lease or use an existing active lease
3. Once approved, click "Access Account" to open the AWS Console via SSO
4. For CLI/programmatic access: click your lease → "Get CLI Credentials"
5. Copy the three values: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN

ISB-Specific Considerations

What Is Restricted in a Sandbox

Sandbox environments intentionally limit what you can do. Here is what that means for this tutorial:

Step-by-Step: Deploy From a Sandbox

# REMOVE the AWS::IAM::Role resource block entirely
# Then update each Lambda function to use the LabRole ARN:

CalorieScannerFunction:
  Type: AWS::Serverless::Function
  Properties:
    Role: arn:aws:iam::YOUR_ACCOUNT_ID:role/LabRole
    # ... rest of properties

sam deploy \
  --stack-name my-partyrock-app \
  --s3-bucket ${{ secrets.SAM_DEPLOY_BUCKET }} \
  --region ${{ secrets.AWS_REGION }} \
  --no-confirm-changeset \
  --no-fail-on-empty-changeset

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-session-token: ${{ secrets.AWS_SESSION_TOKEN }}   # ← add this line
    aws-region: ap-southeast-5

Sandbox Limitations Summary

This step covers important upgrades. CloudFront (HTTPS) is RECOMMENDED for everyone. The rest are optional depending on your app.

9.1 Add HTTPS with CloudFront RECOMMENDED

Right now your app URL starts with http:// — no padlock. Most browsers show a "Not Secure" warning, and copy buttons only work on HTTPS pages. CloudFront gives you HTTPS for free.

1. In the AWS Console, search for CloudFront → Create a CloudFront distribution
2. For Origin domain, select your frontend S3 bucket (the .s3-website.ap-southeast-5.amazonaws.com endpoint — note the dot after s3-website in Malaysia)
3. For Viewer protocol policy, select Redirect HTTP to HTTPS
4. Leave all other settings as default → Create distribution
5. Wait 5–10 minutes for status to change to Enabled
6. Copy the Distribution domain name (e.g. d1234abcd.cloudfront.net) — this is your new HTTPS URL

Lock down S3 to CloudFront only

1. Go to S3 → your frontend bucket → Permissions tab → Edit bucket policy
2. Ask Kiro: "Generate an S3 bucket policy that only allows access from my CloudFront distribution. My bucket name is [name], my account ID is [ID], my distribution ID is [ID]."
3. Paste the policy Kiro generates → Save changes

9.2 Add a Custom Domain (Optional)

Want www.myapp.com instead of a long CloudFront URL? You need to own a domain name first (~$10–12/year).

1. AWS Console → Certificate Manager (must be in us-east-1 for CloudFront) → Request a certificate
2. Enter your domain → DNS validation → Request
3. Click Create records in Route 53 → wait for status Issued
4. CloudFront → your distribution → Edit → add your domain as Alternate domain name → select your certificate → Save
5. Route 53 → Hosted zones → your domain → Create record → type A → Alias → CloudFront distribution → Create

9.3 Add AWS WAF Rate Limiting (Optional)

Blocks bots and prevents abuse. Costs ~$5/month.

1. AWS Console → WAF & Shield → Create web ACL
2. Resource type: Regional → Region: ap-southeast-5 → Name: my-app-waf
3. Add rules → Add managed rule groups → enable AWSManagedRulesCommonRuleSet
4. Add your own rule → Rate-based → limit: 100 per 5 min → Action: Block
5. Create web ACL → then attach to API Gateway: API Gateway → your API → Stages → click your deployed stage (usually named Prod) → WAF tab → select your ACL

9.4 Add Chat Session Persistence (Chatbot Apps Only)

Without this, the AI forgets the conversation every time the user sends a message.

1. AWS Console → DynamoDB → Create table
2. Table name: my-app-chat-sessions — Partition key: session_id (String) → Create table
3. Open Kiro, share your chatbot Lambda function, ask: "Update this Lambda to store and retrieve conversation history from DynamoDB table my-app-chat-sessions, keyed by session_id. Add a 24-hour TTL."
4. Open Kiro, share your Lambda's IAM role name, and ask: "Generate an IAM policy that only allows GetItem, PutItem, UpdateItem, and DeleteItem on my DynamoDB table my-app-chat-sessions, not full DynamoDB access." Attach the generated policy via IAM → your Lambda role → Add permissions → Create inline policy
5. Open Kiro, share index.html, ask: "Generate a unique session_id on page load and include it in every chat API request. Add a Clear Chat button."
6. Upload updated files to GitHub → redeploy

9.5 Large File Uploads (File Upload Apps Only)

Default behaviour: The generated app reads files in the browser using FileReader, converts to base64, and sends directly in the Lambda request body. This works for files up to about 4MB — a Lambda request can be at most 6MB and base64 adds ~33% overhead. Most photos, PDFs, DOCX, and CSV files fall within this limit; for bigger files, shrink or split them first.

Only needed for files larger than ~15MB:

1. Open Kiro, share your infra/template.yaml and file-handling Lambda
2. Ask: "Add a presigned URL upload endpoint. I need a Lambda that generates a presigned S3 PUT URL, and update the frontend to use it for files larger than 15MB. Store uploads in a new S3 bucket called my-app-uploads."
3. Upload all changed files to GitHub → redeploy

Every time you save a change to GitHub, your app redeploys automatically. No AWS Console needed.

How to Update a Prompt

1. Open Kiro, share the Lambda file you want to update (e.g. backend/lambda/calorie_scanner.py)
2. Describe the change: "Update the prompt to also recommend a complementary exercise"
3. Kiro edits the file
4. In GitHub, navigate to the file → click the pencil icon → select all → paste the updated content → Commit changes
5. GitHub Actions redeploys automatically — done in 3–5 minutes

How to Update the Frontend

1. Open Kiro, share frontend/index.html
2. Describe the change: "Change the background color to dark blue" or "Make the Run All button larger"
3. In GitHub, navigate to frontend/index.html → pencil icon → select all → paste → Commit changes

How to Roll Back a Broken Change

1. In GitHub, click on the file you changed → click the History (clock) icon
2. Click the commit before your broken change → click <> to view the old version
3. Copy the old content → go back to the current file → edit → paste → Commit

How to Delete Your App

1. AWS Console → CloudFormation → find your stack → check the box → Delete → confirm
2. Also manually delete: the SAM artifacts S3 bucket, CloudWatch log groups, and CloudFront distribution (if applicable)
3. Your GitHub repository and code are NOT deleted — you can redeploy anytime