Lambda Inventory & Template Drift

Verified 2026-07-07 · re-verified 2026-07-17 against commit 1ce5b3e · account 660537473428, us-east-1

Key findings

• 208 functions deployed (102 prod_*, 101 dev_*, + 5 unprefixed)
• 102 prod functions vs 63 in the template — 39 deployed outside it
• The problem is missing IaC, not missing source. Every function now has source in the repo; what’s missing is a template describing it
• A second API (JB360IntegrationAPI → jb360dealer Java Lambdas, created 2026-01-13) — source is jbw-api/, which has no IaC of any kind
• prodapi_jb360dealer is running a scaffold, not the application — see below
• CloudFormation stale since May 2024 — every change since bypassed it

Totals

208 functions: 102 prod_*, 101 dev_*, plus prodapi_jb360dealer, devapi_jb360dealer, devapi_swaggerjson, jbwpendingagreementsnotification, api_cognitoclienttokenauthorizer.

Runtimes: Node.js 20/22/24 (mixed — some functions runtime-upgraded ad hoc), Java 17 (×4), Python 3.12/3.13 (×2). Node breakdown: nodejs20.x ×113, nodejs22.x ×55, nodejs24.x ×34.

The 07-07 snapshot undercounted

The first pass recorded 206 (99 dev_*, 3 unprefixed). The true figure was already 208 — jbwpendingagreementsnotification (last modified 2024-04-04) and devapi_swaggerjson (2026-05-28) both predate that snapshot. The dev_* 99→101 gap could not be resolved: list-functions exposes no creation date, and distinguishing new functions from config-touched ones needs CloudTrail. prod_* has held at exactly 102 across both passes.

The extraction Module, As Deployed

	prod	dev
Function	prod_jbwextraction	dev_jbwextraction
Runtime / handler	Java 17, Spring Cloud Function FunctionInvoker	same
Timeout / memory	900 s / 2048 MB	300 s / 512 MB
Trigger	SQS prodtenantList, batch 5	SQS tenantList, batch 10
CloudFormation stack	jbw-prod-extraction (Jan 2024)	jbw-extraction

The jb360dealer API

Java 17 Lambdas prodapi_jb360dealer (15 s / 512 MB) and devapi_jb360dealer (900 s / 2048 MB), fronted by the JB360IntegrationAPI gateway (created 2026-01-13) with the cognitoclienttokenauthorizer TOKEN authorizer.

Its source is in the repo, at jbw-api/ — a Spring Boot 3.5.4 / Java 17 vendor-facing API, added 2026-05-20 (commit cfc5e7a, “Spring Release Changes”). The decisive evidence: devapi_jb360dealer’s deployed handler is com.maktix.jb.api.StreamLambdaHandler::handleRequest, and that package is jbw-api/src/main/java/com/maktix/jb/api/. The Cognito scope and user-pool ID in jbw-api/src/main/resources/application.properties also match the authorizer’s expectations exactly.

What jbw-api/ genuinely lacks is any infrastructure-as-code — no template.yaml, no samconfig.toml, no CI workflow. It ships as manual jar uploads.

prodapi_jb360dealer is running the SAM scaffold, not the application

	prodapi_jb360dealer	devapi_jb360dealer
Handler	example.Hello::handleRequest	com.maktix.jb.api.StreamLambdaHandler::handleRequest
Env vars	none	10 (DATABASE_ENDPOINT, SECRET_NAME, S3_BUCKET_NAME, COGNITO_SCOPES, …)
VPC	none	vpc-0d29d310746998b07
LastModified	2026-01-27	—

example.Hello::handleRequest is the stock aws-sam Java scaffold default. With no env vars and no VPC config, this function cannot reach the RDS proxy and cannot be running the Spring app — even though its CodeSize (88.8 MB) suggests a full fat jar is uploaded.

Meanwhile the prod stage of JB360IntegrationAPI targets it (stage variable lambdaName=prodapi_jb360dealer, stage last updated 2026-01-31), reachable at api-jb360.jbwarranties.com/prod. So either the prod vendor API is dead, or it is serving scaffold responses. This is the highest-value thing to confirm with the team. It is exactly the failure mode un-templated manual deploys produce.

/api-docs is unauthenticated and invokes the dev Lambda

On JB360IntegrationAPI, GET /api-docs and GET /swagger.json are authorizationType=NONE and integrate with devapi_jb360dealer / devapi_swaggerjson — the dev Spring app, which does hold DB credentials and VPC reach into the stage RDS proxy. A public, unauthenticated method on the prod-facing gateway invoking a database-connected dev application.

By contrast /dealer/{proxy+} (ANY) is protected — authorizationType=CUSTOM, authorizerId=r0bw81 (jb360ApiAuthorizer, TOKEN, 300 s TTL). The cross-tenant authorization gap in the jbw-api code is therefore not exposed unauthenticated.

Is the July 2026 release deployed?

No. Commit 1ce5b3e (“Terms of use, Renewal fixes and July stability release changes”) landed 2026-07-16T13:04:50Z. No Lambda in the account has a LastModified after that timestamp. The most recent deploy anywhere is prod_jbwclaimsstupdate at 2026-07-15T01:53:27Z — 35 hours before the commit.

The deploy/commit relationship is inverted from what you’d expect:

• Console-pushed shortly before being committed (modified Jul 11–15): jbwclaimsstupdate, jbwagreementwithequipmentsdetails (prod); jbwdealeradmintoolsupdate, jbwdealerregistercreate, jbwgetactivedealerregistrationdetails, jbwinvoicejobsearch, jbwresetpasswordforexpireduser (dev). Timestamp-adjacent only — proving equivalence needs a build and a CodeSha256 comparison.
• Not deployed at all (release changes exist only in git; Lambda last touched in 2025): jbwclaimsdealeradmintoolsupdate, jbwcontactus, jbwdealercreateadmintool, jbwdealerverifyadmintool, jbwvwonboardeddealersearch, jbwtenantbusinessunitsdatapull, jbwworkiztenantifno.
• Never deployed to prod: prod_jbwresetpasswordforexpireduser does not exist (dev-only). Same for swaggerjson — only devapi_swaggerjson exists.

The “Terms of use” and “Renewal fixes” the commit is named for were deployed by console 5+ weeks before the commit (jbwsetusertermsagreed prod 2026-06-12; jbwservicetitansagreementspull prod 2026-06-08). Git is a record of this system, not its deployment mechanism.

Template vs Deployed (prod)

template.yaml defines 63 functions; 102 prod_* functions are deployed. The template was last edited 2025-10-26 (commit 3d19230, “October 2025 Release”) and the July 2026 release did not touch it — while adding 13 new function directories.

Deployed but NOT in the template (39)

Functions whose source exists in the repo but isn’t templated (matches the non-templated dirs list):

jbwagreementdismiss, jbwagreementreferenceremovalfromst, jbwagreementsearch, jbwagreementslocationsfetch, jbwagreementsyncfileupload, jbwagreementsyncuploadcsvdata, jbwautoprocessagreementsstatus, jbwclaimsadmintoolsupdate, jbwclaimsdownloadadmintools, jbwclaimsearch, jbwcreatepotentialclaim, jbwcreateupdateemailtemplate, jbwdatapullfromJB, jbwdbconnection, jbwdealeradmintoolsupdate, jbwgetagreementdetailsbyjbwagreementid, jbwgetequipmenttypes, jbwgetstinstalledequipments, jbwinvoiceitemskuupdate, jbwinvoicelookup, jbwinvoicesummarylist, jbwremoveduplicatelocationnotesfromst, jbwsendagreementemail, jbwstlocationdatawithagreement, jbwupdateagreementcontactinfo, jbwupdateagreementsynclocation, jbwusersignupemail

(jbwextraction also appears in this diff but is the separately-deployed extraction module above.)

The 11 “repo-less” functions now have source — resolved 2026-07-16

The 07-07 snapshot listed 11 functions as having no source anywhere in the repo: jbwcontactus, jbwdealercreateadmintool, jbwdealerverifyadmintool, jbwclaimsdealeradmintoolsupdate, jbwgetactivedealerregistrationdetails, jbwsetusertermsagreed, jbwtenantbusinessunitsdatapull, jbwvwonboardeddealersearch, jbwworkizjobdatapush, jbwworkizjoblocationsdatapull, jbwworkiztenantifno.

All 11 were added to jbw-sam/src/ by commit 1ce5b3e on 2026-07-16 (verified per-function with git log --diff-filter=A), along with jbwresetpasswordforexpireduser and swaggerjson. That finding was correct when written and expired nine days later.

Note the direction of travel: the source arrived in the repo after the code was already running in production — console first, git second. None of the 13 was added to template.yaml.

What’s actually missing is IaC, not source

With the 11 above recovered and jbw-api/ identified as the jb360dealer source, every deployed function now has source in the repo. The gap that remains is infrastructure-as-code:

• 39 prod functions deployed outside template.yaml (up from ~30 source dirs at the 07-07 snapshot; the July release added 13 more and templated none)
• jbw-api/ has no template, no samconfig, no CI — manual jar uploads only
• template.yaml last edited 2025-10-26 and describes May 2024’s deployed reality

The old “recover the source” follow-up is closed. The source-of-truth decision is not.

Odds and ends: the template’s jbwtblproductssearch is deployed as prod_Jbwtblproductssearch (capital J).

CloudFormation Stacks

Stack	Last updated	Contents
jbw-prod-api	2024-05-06	The SAM backend (prod) — stale vs reality
jbw-stage-api	2024-04-27	The SAM backend (stage)
jbw-prod-extraction	2024-01-24	extraction module (prod)
jbw-extraction	2024-01-22	extraction module (stage)

All recent changes bypassed CloudFormation

Lambdas show 2025–2026 modification dates while every stack sat untouched since early/mid 2024 — two years of production changes exist only in the console. The repo’s template.yaml describes May 2024, not today; treat it as historical until the source-of-truth decision is made.