fix(payments): align boto3 region with AWS_REGION from .env

[fahadfa-aws]

Issue

The tutorial .env files set AWS_REGION, but boto3 reads AWS_DEFAULT_REGION from the environment and ignores AWS_REGION entirely (AWS_REGION is the env var the AWS SDK for JavaScript honors; the Python SDK does not). So a .env that sets AWS_REGION=us-west-2 is silently ignored, and boto3.Session() falls back to whatever ~/.aws/config says — commonly us-east-1. Resources get created in the wrong region without any warning.

Live-reproduced today: with AWS_REGION=us-west-2 set and no AWS_DEFAULT_REGION, boto3.Session().region_name returns us-east-1 (from ~/.aws/config).

The boto3 docs confirm AWS_REGION is not in the recognized env-var list: https://docs.aws.amazon.com/boto3/latest/guide/configuration.html#using-environment-variables

Changes

utils.py: add a resolve_region(default=\"us-west-2\") helper that promotes AWS_REGION to AWS_DEFAULT_REGION when the operator hasn't set AWS_DEFAULT_REGION explicitly, then returns the resolved region. If both env vars are set, the operator's explicit AWS_DEFAULT_REGION is preserved.

Three call sites use the helper:

• deploy_payment_agent.py:48-52 — Tutorial 02 deploy script
• bazaar_gateway_agent.py:53-58 — Tutorial 04 gateway script
• utils.setup_cognito_user_pool (line 467) — Cognito setup helper

Setup scripts (setup_agentcore_payments.py, multi_provider_setup.py) already pass region_name= explicitly to boto3.Session, so they aren't affected.

Verification

Static — tested resolve_region() against 4 env states with ~/.aws/config set to us-east-1:

Env state	Old behavior	New behavior
AWS_REGION=us-west-2, no AWS_DEFAULT_REGION	boto3 picked us-east-1 from ~/.aws/config (silent skew)	All boto3 surfaces aligned to us-west-2
AWS_DEFAULT_REGION=eu-west-1 (operator explicit)	boto3 picks eu-west-1	boto3 picks eu-west-1 (no overwrite)
Neither env set	boto3 falls back to config	boto3 falls back to config (unchanged)
AWS_DEFAULT_REGION only	works	works (unchanged)

Live AWS — ran agentcore deploy against us-west-2 with AWS_REGION=us-west-2 and AWS_DEFAULT_REGION unset:

• Before the fix: deploy would land in us-east-1
• After the fix: CFN stack AgentCore-PaymentAgent-default reaches CREATE_COMPLETE in us-west-2, confirmed not present in us-east-1. Stack torn down after.

Notes

No hardcoded account, region, or ARN in the diff. The default fallback (us-west-2) matches what the existing code uses (os.environ.get(\"AWS_REGION\", \"us-west-2\")); it's a last-resort fallback only when nothing else is set.

[fahadfa-aws]

@mvangara10 — flagging this for your review when you have a moment. Tagged across the full set of payments-tutorial fixes I've been pushing today; happy to walk through any of them. Audit logs and test evidence are referenced in the PR description.

[github-actions]

Latest scan for commit: 0a84aad | Updated: 2026-06-16 12:33:08 UTC

Security Scan Results

Scan Metadata

• Project: ASH
• Scan executed: 2026-06-16T12:32:45+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	11	0	903ms	0	PASSED	MED (g)
cdk-nag	0	0	0	0	0	0	6.1s	0	PASSED	MED (g)
cfn-nag	0	0	0	0	0	0	5ms	0	PASSED	MED (g)
checkov	0	0	0	0	0	0	4.9s	0	PASSED	MED (g)
detect-secrets	0	0	0	0	0	0	902ms	0	PASSED	MED (g)
grype	0	0	0	0	0	0	47.0s	0	PASSED	MED (g)
npm-audit	0	0	0	0	0	0	187ms	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.1s	0	PASSED	MED (g)

[fahadfa-aws]

Superseded by #1738 (consolidated PR)