Step 3: Build and deploy the AVX CDK infrastructure

Build Lambda assets

Three Lambda functions bundle their dependencies at build time. Run the build scripts before the first deploy and after any Lambda dependency change:

scripts/build-triage-classifier.sh
scripts/build-api-ws-authorizer.sh
scripts/build-api-vehicle-live-state.sh

Each script packages the Lambda source directory with its dependencies into the expected CDK asset path.

Deploy for staging

AVX deploys one environment, staging. All commands in this chapter target staging. Producing a second environment is left to the operator as a customization — the same CDK stacks, Makefile targets, and IAM patterns apply, but the AgentCore Runtime allow-list requires the execution role name AmazonBedrockAgentCoreSDKRuntime-{region}-vsa-{stage} be present in the target account before the runtime deploy succeeds.

Staging deploys to us-west-2. The deploy-staging Makefile target requires VSA_ADP_KB_ID to tighten the cross-account IAM grant to the specific ADP Knowledge Base ARN:

source .env
VSA_ADP_KB_ID=<adp-kb-id> make deploy-staging

The deploy-staging target runs a pre-flight check (AWS credentials, agentcore CLI presence, KB ID format validation), then:

1. Deploys all AVX CDK stacks to us-west-2 with the KB ID threaded as CDK context.

2. Patches .bedrock_agentcore.yaml with the CDK stack outputs (execution role ARN, S3 bucket path).

3. Deploys the AgentCore voice runtime (vsa_supervisor_bidi_<stage>).

4. If the text runtime (vsa_supervisor_text_<stage>) is registered locally, deploys it too — this runtime powers the CMS Fleet Intelligence portal’s /assistant/chat route.

5. Seeds all demo personas and tenant records.

A note on production

The guidance deploys staging and has no deploy-prod target. To add a production environment, deploy the same stacks under a second stage name, as described below.

CDK stack deploy order

CDK resolves inter-stack dependencies automatically. The logical order is:

1. vsa-<stage>-foundation — AgentCore Memory resource and KMS CMK (created once per environment).

2. vsa-<stage>-analytics — Athena workgroup and results bucket for cross-region ADP Glue catalog queries (deployed to us-east-1 even in a us-west-2 staging environment).

3. vsa-<stage>-core — DynamoDB tables (vsa-<stage>-tenants, vsa-<stage>-actions, vsa-<stage>-triage-decisions), Cognito user pool, AgentCore execution role with all IAM grants.

4. vsa-<stage>-triage-classifier — the DTC triage classifier Lambda.

5. vsa-<stage>-api — API Gateway REST and WebSocket APIs, all Lambda handlers including the /assistant/chat route for the CMS Fleet Intelligence portal.

To verify the stacks are healthy after deploy:

aws cloudformation describe-stacks \
  --region <region> \
  --query 'Stacks[?starts_with(StackName, `vsa-`)].{Name:StackName,Status:StackStatus}' \
  --output table

All stacks should be in CREATE_COMPLETE or UPDATE_COMPLETE.