Configure Lambda HTTP access

From CLI 1.0.70, a compatible ASP.NET Lambda service can declare its HTTP endpoint in stage configuration. Kanject creates a companion REST API stack, routes it through the function’s live alias, and requires a successful health check before recording the release.

Check the supported shape

• Exactly one lambda-aspnetcore entry, managed .NET ZIP packaging, and arm64.
• A public, buffered api-gateway-rest endpoint in one region.
• No stage targets[], custom api.domain, or coupled static site.
• Matching ASP.NET Lambda REST-v1 hosting and serialization in the application.

HTTP API, Function URL, private access, streaming, Native AOT, and multi-entry managed enrollment are outside this release. Keep template/external ownership for those configurations. Existing template-owned services continue on their existing deployment path.

Choose who owns the endpoint

managed lets Kanject reconcile the endpoint. external preserves template/external ownership. pending records that setup is unfinished and blocks deployment before building. External and pending modes cannot carry managed access flags, and switching ownership does not delete an existing managed stack or adopt an existing endpoint.

# Run from the existing service root; preview the local changes firstkanject aws configure http --env dev --entry api --non-interactive \  --kind api-gateway-rest --auth application --verification-path /health --dry-run​# Save the same configuration, then check and deploy itkanject aws configure http --env dev --entry api --non-interactive \  --kind api-gateway-rest --auth application --verification-path /healthkanject doctor --env devkanject aws deploy --env dev

Setup writes httpHost on the manifest entry (aspnetcore-lambda / rest-v1) and the stage’s http map, keyed by entry ID. Managed enrollment can upgrade schema v1 to v2. Existing authentication and health-path choices may be reused; new automated setup must provide them.

{  "http": {    "api": {      "mode": "managed",      "kind": "api-gateway-rest",      "exposure": "public",      "responseMode": "buffered",      "auth": { "kind": "application" },      "verification": {        "required": true,        "path": "/health",        "expectedStatus": 200      }    }  }}

Enroll during initialization

# Enroll an existing compatible project with managed HTTPkanject init --yes --service acme --stages dev --schema 2 \  --http-kind api-gateway-rest --http-auth application \  --http-verification-path /health

Run init only when enrolling an existing project. A service already initialized by kanject new should use aws configure http. Interactive enrollment can also keep external ownership or defer setup; non-interactive initialization without HTTP flags keeps template ownership.

Verify and recover

Deployment rechecks capability and AWS ownership, reconciles the companion stack against the recorded live alias, then runs the required GET probe. Define the path in your application; /health is an example, not a route the gateway creates. A failed required probe prevents a successful release record.

An interrupted operation records its phase and handles. Rerun unchanged inputs to resume. If source or settings changed, KANCLI680 requires inspecting the serving revision and recorded handles before an explicit kanject aws deploy --env dev --restart-http. Restart does not bypass ownership or migration checks. Rollback uses the recorded HTTP evidence and re-verifies the endpoint.

See diagnostics KANCLI670–681 for configuration, ownership, reconciliation, verification, and recovery failures.