aws-samples / aws-samples/agents4energy

Deploy workflow: AgentCore gateway target creation fails on fresh stacks — Lambda permission granted too late

Open
#161 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
48
Forks
68
PR merge metrics
No merged PRs in 30d

Description

## Summary

On a fresh Amplify sandbox identifier/stack, the `Deploy AgentCore harness + gateway` step in `.github/workflows/deploy.yml` reliably fails when creating the `InvokeAgentTarget` gateway target, because the Lambda resource policy granting the gateway permission to invoke `invokeAgentLambda` is never in place before `CreateGatewayTarget` runs.

This is pre-existing and unrelated to the branch-truncation fix in #158 / PR #51 — confirmed present on the last 20 `Deploy` runs on `main` as well.

## Error

```
CDK deploy failed: ❌ AgentCore-default-default failed: DeploymentError: Resource updates failed:
└─ InvokeAgentTarget (AWS::BedrockAgentCore::GatewayTarget)
🛑 Resource handler returned message: "Gateway execution role lacks permission to invoke Lambda function
arn:aws:lambda:us-east-1:...:function:amplify-web-...-invokeagentlambda.... Update
the permission and retry (Service: BedrockAgentCoreControl, Status Code: 400, ...)"
(HandlerErrorCode: InvalidRequest)
```

Reproduced in [run 28808840173](https://github.com/waltmayf/agentcore-amplify-fullstack/actions/runs/28808840173) and [run 28811378510](https://github.com/waltmayf/agentcore-amplify-fullstack/actions/runs/28811378510).

## Root cause

The permission grant and the resource that needs it are created in two different places, on two different deploy passes, in the wrong order:

1. **`.github/workflows/deploy.yml` (Deploy Amplify backend step)** — `ampx sandbox --once` deploys the Amplify backend. `web/amplify/backend.ts:171-176` grants the gateway `lambda:InvokeFunction` on `invokeAgentLambda`, but only `if (AGENTCORE_GATEWAY_ARN)`. On a brand-new identifier/stack, that env var is empty at this point — the gateway doesn't exist yet, so its ARN hasn't been discovered.
2. **`.github/workflows/deploy.yml` (Deploy AgentCore harness + gateway step)** — `agentcore deploy` runs. `agent/default/agentcore/cdk/lib/cdk-stack.ts:301-316` reads `invoke_agent_lambda_arn` from `web/amplify_outputs.json` (written by step 1) and creates the `InvokeAgentTarget` (`AWS::BedrockAgentCore::GatewayTarget`) pointing at that Lambda. This is also the step that first creates/knows the gateway's ARN (`cdk-stack.ts:272`, `attrGatewayArn`).
3. **`.github/workflows/deploy.yml` (Inject AgentCore env vars for Amplify build step)** — `inject-agentcore-env.js` writes `AGENTCORE_GATEWAY_ARN` to `$GITHUB_ENV` — but this runs *after* step 2 already failed, and there's no second `ampx sandbox` pass afterward to pick it up.

So on a fresh stack, `CreateGatewayTarget` (step 2) always fails: the Lambda's resource policy is never updated with permission before the gateway tries to invoke it, because the one Amplify pass that could grant it runs *before* the gateway ARN is known.

## Suggested fix

Grant the Lambda invoke permission directly in `agent/default/agentcore/cdk/lib/cdk-stack.ts`, alongside the `InvokeAgentTarget` resource (around line 301), since that pass already has both `invokeAgentLambdaArn` and `cfnGateway.attrGatewayArn` available at the same time. This sidesteps the ordering problem entirely, rather than patching around it (e.g. adding a second `ampx sandbox --once` call after `agentcore deploy`).

Something like an `aws_lambda.Function.fromFunctionArn(...).addPermission(...)`, or an `AWS::Lambda::Permission` `CfnResource`, granting `bedrock-agentcore.amazonaws.com` `lambda:InvokeFunction` with `SourceArn: cfnGateway.attrGatewayArn`, created before/alongside `InvokeAgentTarget`.

The existing `if (AGENTCORE_GATEWAY_ARN)` grant in `web/amplify/backend.ts:171-176` would then be redundant for the initial-deploy case (it may still help on a true redeploy where the gateway ARN is already known at Amplify-deploy time) but should be reviewed once the CDK-side grant is in place.

## Context

Found and confirmed while reviewing/testing PR #51 (branch-name truncation fix for `ampx sandbox --identifier`). Not a blocker for that PR — it targets a different, earlier pipeline step.

---
*Imported from `waltmayf/agentcore-amplify-fullstack`#55 — originally filed by @app/github-actions on 2026-07-06. Migrated to open-source repo; cross-references updated post-import.*

Contributor guide

Open the contributing guide

Research direction

Start with .github/workflows/deploy.yml and compare the Deploy Amplify backend and Deploy AgentCore harness + gateway steps. Then read agent/default/agentcore/cdk/lib/cdk-stack.ts around lines 272 and 301-316, plus web/amplify/backend.ts:171-176, to trace when the gateway ARN and Lambda permission become available. Done means a fresh-stack deployment creates InvokeAgentTarget successfully and the existing redeploy behavior remains understood.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, github-actions, typescript
Domain
cloud, devops, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.