Skip to content

fix: cleanup scripts skip DEFAULT endpoint to prevent resource leaks - #2007

Open
jyotsnamas wants to merge 2 commits into
awslabs:mainfrom
jyotsnamas:fix/cleanup-default-endpoint
Open

fix: cleanup scripts skip DEFAULT endpoint to prevent resource leaks#2007
jyotsnamas wants to merge 2 commits into
awslabs:mainfrom
jyotsnamas:fix/cleanup-default-endpoint

Conversation

@jyotsnamas

Copy link
Copy Markdown
Contributor

Summary

  • Fix 18 cleanup.py scripts that silently leak AgentCore runtimes and endpoints
  • The API auto-manages DEFAULT endpoints — they cannot be explicitly deleted
  • Scripts that attempt to delete DEFAULT get ConflictException, which then prevents runtime deletion
  • Scripts report "Cleanup complete" while resources remain alive and accruing costs

Root cause

1. cleanup.py calls DeleteAgentRuntimeEndpoint(endpointName="DEFAULT")
   → ConflictException: "Default endpoints are removed when you delete the agent"
2. cleanup.py calls DeleteAgentRuntime
   → ConflictException: "This agent has endpoints that must be deleted first"
3. Both exceptions caught silently → "Cleanup complete" printed
4. Runtime + endpoint remain READY in AWS

Fix

Skip DEFAULT endpoints during explicit deletion, matching the pattern already used in 01-strands-bedrock/cleanup.py:

for ep in endpoints.get("runtimeEndpoints", []):
    if ep["name"] == "DEFAULT":
        continue
    control.delete_agent_runtime_endpoint(...)

Verification

Deployed and cleaned up multiple modules in us-west-2:

  • Without fix: aws bedrock-agentcore-control list-agent-runtimes shows runtime still READY after cleanup
  • With fix: Runtime successfully deleted, confirmed gone via list-agent-runtimes

Test plan

  • Deploy 02-a2a-protocol → cleanup now deletes runtime successfully
  • Deploy 09-mcp-e2e/01-server-e2e → confirmed leaked runtime with old cleanup, deleted with direct API call
  • Verified strands-bedrock cleanup (already has the fix) works correctly

🤖 Generated with Claude Code

The AgentCore API now auto-manages DEFAULT endpoints — they cannot be
explicitly deleted. cleanup.py scripts that attempt to delete all
endpoints (including DEFAULT) get a ConflictException, which then
prevents the runtime from being deleted. Resources are leaked despite
the script reporting "Cleanup complete".

Fix: Skip DEFAULT endpoints during explicit deletion, matching the
pattern already used in 01-strands-bedrock/cleanup.py. Also fixes
the observability cleanup which used wrong parameter name (name=
instead of endpointName=).

Verified by live deployment testing: deploy → invoke → cleanup now
succeeds without leaking runtimes.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

Latest scan for commit: 059ada3 | Updated: 2026-08-31 16:07:08 UTC

Security Scan Results

Scan Metadata

  • Project: ASH
  • Scan executed: 2026-08-31T16:04:00+00:00
  • ASH version: 3.0.0

Summary

Scanner Results

The table below shows findings by scanner, with status based on severity thresholds and dependencies:

Column Explanations:

Severity Levels (S/C/H/M/L/I):

  • Suppressed (S): Security findings that have been explicitly suppressed/ignored and don't affect the scanner's pass/fail status
  • Critical (C): The most severe security vulnerabilities requiring immediate remediation (e.g., SQL injection, remote code execution)
  • High (H): Serious security vulnerabilities that should be addressed promptly (e.g., authentication bypasses, privilege escalation)
  • Medium (M): Moderate security risks that should be addressed in normal development cycles (e.g., weak encryption, input validation issues)
  • Low (L): Minor security concerns with limited impact (e.g., information disclosure, weak recommendations)
  • Info (I): Informational findings for awareness with minimal security risk (e.g., code quality suggestions, best practice recommendations)

Other Columns:

  • Time: Duration taken by each scanner to complete its analysis
  • Action: Total number of actionable findings at or above the configured severity threshold that require attention

Scanner Results:

  • PASSED: Scanner found no security issues at or above the configured severity threshold - code is clean for this scanner
  • FAILED: Scanner found security vulnerabilities at or above the threshold that require attention and remediation
  • MISSING: Scanner could not run because required dependencies/tools are not installed or available
  • SKIPPED: Scanner was intentionally disabled or excluded from this scan
  • ERROR: Scanner encountered an execution error and could not complete successfully

Severity Thresholds (Thresh Column):

  • CRITICAL: Only Critical severity findings cause scanner to fail
  • HIGH: High and Critical severity findings cause scanner to fail
  • MEDIUM (MED): Medium, High, and Critical severity findings cause scanner to fail
  • LOW: Low, Medium, High, and Critical severity findings cause scanner to fail
  • ALL: Any finding of any severity level causes scanner to fail

Threshold Source: Values in parentheses indicate where the threshold is configured:

  • (g) = global: Set in the global_settings section of ASH configuration
  • (c) = config: Set in the individual scanner configuration section
  • (s) = scanner: Default threshold built into the scanner itself

Statistics calculation:

  • All statistics are calculated from the final aggregated SARIF report
  • Suppressed findings are counted separately and do not contribute to actionable findings
  • Scanner status is determined by comparing actionable findings to the threshold
Scanner S C H M L I Time Action Result Thresh
bandit 0 0 0 0 34 0 947ms 0 PASSED MED (g)
cdk-nag 0 0 0 0 0 0 7.6s 0 PASSED MED (g)
cfn-nag 0 0 0 0 0 0 104ms 0 PASSED MED (g)
checkov 0 0 0 0 0 0 5.8s 0 PASSED MED (g)
detect-secrets 0 0 0 0 0 0 850ms 0 PASSED MED (g)
grype 0 0 0 0 0 0 1m 0s 0 PASSED MED (g)
npm-audit 0 0 0 0 0 0 174ms 0 PASSED MED (g)
opengrep 0 0 0 0 0 0 <1ms 0 SKIPPED MED (g)
semgrep 0 0 0 0 0 0 <1ms 0 MISSING MED (g)
syft 0 0 0 0 0 0 2.2s 0 PASSED MED (g)

Replace broad `except Exception` with `except ClientError` from
botocore.exceptions, replace bare `pass` with informative print
statements, and fix import sorting.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant