Feature/lambda architecture param

[sirirako]

feat: add LambdaArchitecture parameter for configurable CPU architecture

Body

Summary

Adds a LambdaArchitecture parameter that allows customers to select arm64 or x86_64 for all Lambda container images in the unified pattern. Defaults to arm64 (Graviton) for best price-performance. Use x86_64 when deploying with custom base images that only support AMD64.

Previously, the architecture was hardcoded to arm64 across 15 Lambda functions, the Dockerfile, and all three buildspec files. Customers using internal artifact repositories with x86_64-only base images had to manually patch multiple files to switch architectures.

Usage

# Default (arm64 — no change needed for existing deployments)
idp-cli deploy --stack-name IDP --admin-email admin@example.com --region us-east-1

# Switch to x86_64
idp-cli deploy --stack-name IDP --admin-email admin@example.com --region us-east-1 \
  --parameters "LambdaArchitecture=x86_64"

The parameter appears in the CloudFormation console under "Advanced - Container Images".

How it flows

CloudFormation Parameter: LambdaArchitecture (arm64 | x86_64)
  │
  ├── Lambda functions: Architectures: [!Ref LambdaArchitecture]
  │
  └── CodeBuild env var: LAMBDA_ARCHITECTURE
        │
        ├── buildspec: --platform linux/arm64 or linux/amd64
        │
        └── Dockerfile.optimized: FROM public.ecr.aws/lambda/python:3.12-<arch>

Changes

• template.yaml — New `LambdaArchitecture` parameter, added to ParameterGroups ("Advanced - Container Images"), passed to PATTERNSTACK
• patterns/unified/template.yaml — New parameter; all 15 `Architectures: [arm64]` replaced with `[!Ref LambdaArchitecture]`; `LAMBDA_ARCHITECTURE` env var added to DockerBuildProject
• Dockerfile.optimized — Global `BASE_IMAGE_SUFFIX` build arg (default `arm64`) replaces hardcoded `-arm64` on both builder and runtime stages
• patterns/unified/buildspec.yml — Maps `LAMBDA_ARCHITECTURE` to Docker `--platform` flag; passes `BASE_IMAGE_SUFFIX` build arg
• patterns/unified/buildspec-bda.yml — Same platform mapping + `-f Dockerfile.optimized` + build args
• patterns/unified/buildspec-pipeline.yml — Same platform mapping + `-f Dockerfile.optimized` + build args

Backward compatibility

• Default is `arm64` — existing deployments unaffected
• Existing stacks can update without specifying the parameter
• No changes to root template Lambda functions (they remain x86_64 ZIP-based with layers)

Tested

Both architectures deployed and verified end-to-end (us-east-1, `DeployInVPC=true`):

arm64 (default):

• Stack update succeeds
• CodeBuild Docker build succeeds with `--platform linux/arm64`
• All 15 Lambda functions report `arm64` architecture
• Document processing end-to-end (upload → OCR → Classification → Extraction)

x86_64:

• Stack update succeeds
• CodeBuild Docker build succeeds with `--platform linux/amd64`
• All 15 Lambda functions report `x86_64` architecture
• Document processing end-to-end (upload → OCR → Classification → Extraction)

[rstrahan]

AI review identifies 1 blocker and a few suggestions..

Findings
🔴 Blocking (correctness) — patterns/unified/template.yaml:2693-2714 — The DockerBuildRun custom resource does not include LambdaArchitecture in its properties. CloudFormation only invokes the trigger Lambda's @HELPER.update handler (which calls start_build) when one of the custom resource's own properties changes. On a stack update that flips only LambdaArchitecture (the exact migration path the PR advertises: --parameters "LambdaArchitecture=x86_64"), the ImageVersion content hash is unchanged, DockerBuildRun's properties are unchanged, so CodeBuild does not re-run — the Lambda Architectures property flips to x86_64 while the ECR images remain arm64. That yields a runtime exec format error / function-update failure. The PR's "Tested" section likely passed because the testers also changed source (new ImageVersion) or recreated stacks. Fix: add LambdaArchitecture: !Ref LambdaArchitecture to DockerBuildRun.Properties so an arch-only change forces a rebuild.

🟡 Should fix — CHANGELOG.md — No entry under [Unreleased]. This is a user-facing parameter; the repo convention (and pr-review/documentation skills) requires a changelog entry. Add an ### Added bullet.

🟡 Should fix (dead code) — patterns/unified/buildspec-bda.yml and patterns/unified/buildspec-pipeline.yml — These two files are not referenced anywhere in the repo (only patterns/unified/buildspec.yml is wired into DockerBuildProject and publish.py/idp_sdk). The PR not only adds the arch mapping here but also makes a functional change — switching the BDA build from per-function build context ("${func_path}", no -f) to the shared Dockerfile.optimized with --build-arg FUNCTION_PATH and context .. Since these files are orphaned, the change is untested and ships confusion. Recommend either (a) deleting both dead buildspecs in a separate cleanup, or (b) at minimum noting in the PR that they're unused. The change itself is more correct than the old form (BDA dirs have no Dockerfile), which suggests these files were stale leftovers from the pattern consolidation.

🟢 Nice to have — Dockerfile.optimized:4 — The CKV_DOCKER_3 checkov-skip reason still hardcodes "public.ecr.aws/lambda/python:3.12-arm64". Now that the suffix is parameterized, update the comment to 3.12-${BASE_IMAGE_SUFFIX} to avoid drift.

[rstrahan]

Note - to reduce turnaround time, you can easily run your own PR review using the claude or cline skill in the repo.. Just start claude code in the repo root, and ask 'Review PR '

[sirirako]

Bob, I swear, I did use the PR review skill before submitting PR.

[sirirako]

• Added LambdaArchitecture to DockerBuildRun custom resource properties — forces CodeBuild rebuild when only architecture changes (prevents exec format error on arch-only updates)
• Added CHANGELOG entry under [Unreleased]
• Added NOTE comments to buildspec-bda.yml and buildspec-pipeline.yml clarifying they are not referenced by the main stack
• Updated Dockerfile checkov comment to reference ${BASE_IMAGE_SUFFIX} instead of hardcoded arm64
• Merged upstream/develop — resolved CHANGELOG conflict (kept both entries)