Operations

Day-2 runbook items. Common things you'll need to do once the deployment is live.

Pause the platform (stop the gateway)

Useful when:

• You want to temporarily disable the deployment (e.g., during a maintenance window or while you're not using it).
• You're trying to rule out the gateway as the cause of a problem.

Steps:

1. AWS Console → Elastic Container Service.
2. Open your cluster.
3. Open the Service (the agents gateway service).
4. Click Update Service.
5. Set Desired tasks to 0.
6. Click Update.

The running task stops within a minute or two. The dashboard and API stop responding.

Existing data is preserved — DynamoDB, KMS, Cognito, S3 are untouched. You're only stopping the compute.

Resume the platform

Reverse of the above:

1. ECS → cluster → service → Update Service.
2. Set Desired tasks back to 1 (or whatever your normal count is).
3. Click Update.

The service starts a fresh task. Wait ~2 minutes for it to pass health checks before sign-in works again.

Look at logs

AWS Console → CloudWatch → Log groups → open /ecs/agent-gateway (the gateway service writes there).

You'll find:

• Each request the gateway handled.
• LLM calls and their token counts.
• Errors with stack traces.

Use the log group's Live Tail mode to watch logs as something breaks in real time.

Rotate the gateway

If the gateway is misbehaving and you don't want to debug it right now, force a fresh task:

1. ECS → cluster → service → Update Service → tick Force new deployment → Update.
2. ECS spins up a new task and drains the old one.

This is the equivalent of "have you tried turning it off and on again" — solves a surprising number of transient issues.

Watch for cost spikes

AWS Console → Billing → Cost Explorer → group by Service.

The big-ticket items in a healthy deployment are typically:

Service	Why
Bedrock	LLM calls. Scales with usage.
ECS Fargate	Gateway compute. ~Constant.
DynamoDB	Storage and reads. Grows with conversations.
CloudFront	Dashboard egress. Small.

If something jumps unexpectedly, drill into the Cost Explorer's per-resource view to find the source.

Update Cognito user attributes

Things like display name, email verification, or MFA settings on a Cognito pool are managed in the Cognito console — not the platform.

AWS Console → Cognito → user pool → Users tab.

Use this for:

• Manually adding admins (e.g., a colleague who needs admin access).
• Resetting a stuck user's password.
• Toggling MFA / additional security features.

Backup and restore

Stateful resources are kept durable but the deployment does not enable point-in-time recovery or bucket versioning by default. If you need either, turn them on yourself in the AWS console:

Resource	Default	Recommended
DynamoDB	Standard durability; PITR is not enabled out of the box.	Enable PITR on each agent_* table for restore-to-point-in-time.
KMS keys	Annual auto-rotation; deletion has a 30-day waiting period.	No action needed.
S3	Versioning is not enabled on the deployment's customer-side buckets.	Enable versioning on the dashboard, media, and staging buckets if you want object recovery.
Cognito	Pool data is durable; users can be exported via the console.	No action needed.

For ad-hoc backups, use the AWS console for each service.

Tear-down semantics differ by resource. Most stateful resources are configured RETAIN — deleting the deployment's CloudFormation stack leaves the dashboard bucket, KMS key, agent_* DynamoDB tables, and Cognito pools in place; you'd have to delete them manually for a full wipe. The agent_deployment_details table and the local staging bucket, however, are configured DESTROY and will be removed with the stack — keep that in mind before tearing down.

Common questions

• "Can I delete the deployment entirely?" Yes — delete the deployment's CloudFormation stack. The retained stateful resources (dashboard bucket, KMS key, agent_* tables, Cognito pools) stay; delete them manually if you want a full wipe. The agent_deployment_details table and the local staging bucket are removed automatically with the stack.
• "How do I move to a different AWS region?" You don't, in place. Spin up a new deployment in the target region, migrate users / agents manually, then tear down the old one.
• "Can two deployments share one Cognito pool?" Yes — see Authentication → External pool.

What's next

• Updating when a new version drops.
• The Admin Guide and User Guide for the day-to-day inside the platform.