AWS Customer OIDC Setup

This guide is the canonical customer walkthrough for connecting a customer AWS account to Dart Cloud Functions (DCF) through IAM OIDC and sts:AssumeRoleWithWebIdentity.

The current DCF AWS onboarding flow is:

The customer owns the AWS account.
The customer owns the S3 artifact bucket.
The customer owns the CodeBuild project that turns a staged artifact into a Lambda deployment.
The customer creates an IAM OIDC provider that trusts the DCF runtime token.
The customer creates an IAM role that DCF can assume with a short-lived web identity token.

DCF must not request or store static AWS access keys for this flow.

In This Section

Responsibility Split

DCF Owns

The Dart Cloud Functions platform team owns:

mounting a projected Kubernetes service account token for the API/deployment runner with audience sts.amazonaws.com
exposing that token path through AWS_WEB_IDENTITY_TOKEN_FILE or the saved integration oidc_token_path
returning the exact DCF issuer, subject, and setup commands from GET /api/v1/projects/{projectId}/integrations/aws/oidc/setup-commands
verifying the customer IAM role with POST /api/v1/projects/{projectId}/integrations/aws/oidc/verify
storing only metadata on the integration row, such as role_arn, region, oidc_issuer, oidc_subject, oidc_token_path, aws_account_id, bucket_name, and codebuild_project
using OIDC temporary credentials for S3 bucket checks, artifact uploads, artifact reads, artifact cleanup, and CodeBuild start/status calls
passing AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE, and AWS_REGION into the AWS deployment runner

DCF also owns the API and frontend flow for these endpoints:

GET /api/v1/projects/{projectId}/integrations/aws/oidc/setup-commands
POST /api/v1/projects/{projectId}/integrations/aws/oidc/verify
POST /api/v1/projects/{projectId}/integrations/aws/bucket/validate
POST /api/v1/projects/{projectId}/integrations/aws/bucket/save
GET /api/v1/projects/{projectId}/integrations/aws/bucket/config

Customer Owns

The customer owns these resources in their AWS account:

an IAM OIDC provider for the DCF issuer, with client ID sts.amazonaws.com
an IAM role with a trust policy that allows only the expected DCF issuer, subject, and audience
an S3 bucket for DCF artifacts
an ECR repository for Lambda container images
a CodeBuild project in the selected region
a CodeBuild service role with permissions to read the staged artifact and create or update the customer’s Lambda resources
any Lambda execution role used by the deployed function

The customer gives DCF these values after setup:

roleArn
region
bucketName
codebuildProject
ecrRepositoryUri
lambdaExecutionRoleArn

The customer does not give DCF static AWS access keys.

What The Customer Must Provide To DCF

After setup, enter these values in the DCF AWS integration flow:

roleArn: the IAM role DCF will assume
region: the AWS region used for STS, S3, CodeBuild, and Lambda
bucketName: the S3 artifact bucket
codebuildProject: the CodeBuild project name
ecrRepositoryUri: the full ECR repository URI used for Lambda container images
lambdaExecutionRoleArn: the execution role used by the deployed Lambda function

Example:

roleArn=arn:aws:iam::123456789012:role/dcf-gke-role
region=us-east-1
bucketName=dcf-customer-artifacts
codebuildProject=dcf-lambda-build
ecrRepositoryUri=123456789012.dkr.ecr.us-east-1.amazonaws.com/dcf-lambda-repo
lambdaExecutionRoleArn=arn:aws:iam::123456789012:role/lambda-execution-role

Standard Customer Contract

To keep onboarding consistent, use these defaults unless the customer already has approved equivalents:

IAM role name: dcf-gke-role
inline role policy name: DcfRuntimeAccess
artifact object key used by DCF: builds/app.zip
CodeBuild environment variables supplied by DCF: S3_BUCKET, S3_KEY=builds/app.zip, FUNCTION_NAME, AWS_REGION, ECR_REPOSITORY_URI, and LAMBDA_EXECUTION_ROLE_ARN
optional CodeBuild environment variables: IMAGE_TAG, LAMBDA_TIMEOUT_SECONDS, LAMBDA_MEMORY_MB, and DCF_ENVIRONMENT
standard buildspec: backend/functions/aws/codebuild/buildspec.lambda-container.yml
buildspec ownership: DCF supplies this standard buildspec as the CodeBuild buildspec override when starting a deployment

The CodeBuild project name, S3 bucket name, ECR repository URI, and Lambda execution role ARN vary by customer.

Submitted Dart packages must use one of the currently supported SDK constraints:

>=3.10.0 <3.11.0
>=3.11.0 <3.12.0

Broader ranges such as >=3.11.0 <4.0.0 currently fail deployment validation. Choose the exact minor runtime range that matches the Dart runtime used by the function container.

AWS Lambda Deployment Architecture

DCF uses a customer-owned deployment boundary for AWS Lambda:

DCF assumes the customer IAM role with sts:AssumeRoleWithWebIdentity.
DCF uploads the function archive to the customer S3 bucket at builds/app.zip.
DCF starts the configured CodeBuild project and passes the deployment environment variables.
CodeBuild downloads the archive, builds a Linux AMD64 Lambda container image, and pushes it to the customer ECR repository.
CodeBuild creates or updates the Lambda function with the customer Lambda execution role.
CodeBuild ensures a Lambda Function URL exists and prints the URL at the end of the build.
DCF records the deployment metadata and build result.

The DCF assumed role starts and monitors the deployment. The CodeBuild service role performs the ECR push and Lambda create/update work inside the customer’s AWS account.

Architecture flow: DCF → OIDC AssumeRole → S3 artifact upload → CodeBuild → Docker image build → ECR image push → Lambda create/update → Function URL → public HTTPS endpoint.

The standard AWS Lambda deployment path exposes the function through a Lambda Function URL. DCF creates or preserves that Function URL with auth-type NONE and adds the public invoke permission needed for HTTPS access. API Gateway is not required for this deployment path. Do not deploy sensitive handlers without application-level authorization in the Dart function or an approved upstream gateway pattern.

Required AWS Services

Each connected AWS account needs these resources in the selected region:

IAM OIDC provider for the DCF issuer
IAM role that DCF can assume with web identity
S3 bucket for staged deployment artifacts
ECR repository for Lambda container images
CodeBuild project that can run privileged Docker builds
CodeBuild service role
Lambda execution role
CloudWatch Logs access for CodeBuild and Lambda logs

Current DCF Identity Values

Use the values returned by the DCF setup command endpoint for the environment being connected. Do not copy values from another environment.

The setup command response includes:

issuer
ksa
expectedAudience=sts.amazonaws.com
runtime token warnings when the API pod is missing the projected AWS audience token

The AWS trust policy must match the returned issuer and subject exactly.

Customer Setup Steps

1. Confirm AWS Admin Context

aws sts get-caller-identity

Save the 12-digit AWS account ID from the output.

2. Fetch The DCF Setup Values

In DCF, call:

GET /api/v1/projects/\{projectId\}/integrations/aws/oidc/setup-commands
Authorization: Bearer <Firebase ID token>

Use the returned issuer, ksa, and generated setup commands for the next steps.

3. Create The AWS OIDC Provider

DCF_ISSUER="<issuer-from-dcf>"

aws iam create-open-id-connect-provider \
  --url "$DCF_ISSUER" \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 9e99a48a9960b14926bb7f3b02e22da0afd10df6

If a compatible provider already exists, reuse it.

4. Create The IAM Trust Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/<ISSUER_HOST>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<ISSUER_HOST>:sub": "<DCF_SUBJECT>",
          "<ISSUER_HOST>:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

Replace:

<ACCOUNT_ID> with the AWS account ID
<ISSUER_HOST> with the DCF issuer without https://
<DCF_SUBJECT> with the ksa value returned by DCF

Save this file as trust-policy.json.

5. Create The IAM Role

ROLE_NAME="dcf-gke-role"

aws iam create-role \
  --role-name "$ROLE_NAME" \
  --assume-role-policy-document file://trust-policy.json

Save the returned role ARN. DCF needs this value.

6. Attach Runtime Permissions To The IAM Role

Create dcf-runtime-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DcfS3Bucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::<DCF_ARTIFACT_BUCKET>"
    },
    {
      "Sid": "DcfS3Objects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::<DCF_ARTIFACT_BUCKET>/*"
    },
    {
      "Sid": "DcfCodeBuild",
      "Effect": "Allow",
      "Action": [
        "codebuild:StartBuild",
        "codebuild:BatchGetBuilds"
      ],
      "Resource": "arn:aws:codebuild:<AWS_REGION>:<ACCOUNT_ID>:project/<CODEBUILD_PROJECT_NAME>"
    },
    {
      "Sid": "DcfLambdaUndeploy",
      "Effect": "Allow",
      "Action": [
        "lambda:GetFunction",
        "lambda:GetFunctionUrlConfig",
        "lambda:DeleteFunctionUrlConfig",
        "lambda:RemovePermission",
        "lambda:DeleteFunction"
      ],
      "Resource": "arn:aws:lambda:<AWS_REGION>:<ACCOUNT_ID>:function:*"
    }
  ]
}

Then attach it:

aws iam put-role-policy \
  --role-name dcf-gke-role \
  --policy-name DcfRuntimeAccess \
  --policy-document file://dcf-runtime-policy.json

DcfLambdaUndeploy is required when DCF is expected to remove deployed Lambda resources during undeploy.

7. Create Or Select The S3 Artifact Bucket

The bucket must exist before DCF bucket validation.

DCF uploads the deployment artifact to:

s3://<bucketName>/builds/app.zip

8. Create Or Select The CodeBuild Project

The CodeBuild project must be in the selected AWS region.

DCF starts the build and passes:

S3_BUCKET=<bucketName>
S3_KEY=builds/app.zip
FUNCTION_NAME=<sanitized-function-name>
AWS_REGION=<region>
ECR_REPOSITORY_URI=<repository-uri>
LAMBDA_EXECUTION_ROLE_ARN=<lambda-execution-role-arn>

DCF supplies the standard buildspec as the CodeBuild buildspec override when it starts the deployment:

backend/functions/aws/codebuild/buildspec.lambda-container.yml

It builds the submitted Dart HTTP server as a Lambda container image and injects AWS Lambda Web Adapter if the submitted Dockerfile does not already include it. The standard injection appends this behavior before the final image starts:

COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.9.1 /lambda-adapter /opt/extensions/lambda-adapter
ENV PORT=8080

The saved AWS integration must include ECR_REPOSITORY_URI and LAMBDA_EXECUTION_ROLE_ARN so DCF can pass them into CodeBuild at deployment time.

The CodeBuild service role must be able to:

read the staged object from the S3 artifact bucket
push the built image to ECR
write CloudWatch Logs for the build
create or update Lambda resources according to the DCF-supplied buildspec
pass the Lambda execution role if the build creates or updates Lambda functions

The customer owns the CodeBuild project and roles. DCF owns the standard buildspec so every customer deployment uses the same reviewed build contract.

9. Configure The Lambda Execution Role

The Lambda execution role is the role attached to the deployed function. It is not the same as the DCF assumed role and it is not the same as the CodeBuild service role.

For a basic HTTP function, attach the AWS managed policy service-role/AWSLambdaBasicExecutionRole or equivalent inline permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WriteLambdaLogs",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:<AWS_REGION>:<ACCOUNT_ID>:*"
    }
  ]
}

Add application-specific permissions only when the Dart function needs to call other AWS services.

10. Confirm The ECR Repository Policy

For same-account deployments, the CodeBuild service role usually only needs IAM permissions to push images to ECR. If the Lambda service or CodeBuild role needs an explicit repository policy, use a scoped policy similar to this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCodeBuildPush",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ACCOUNT_ID>:role/<CODEBUILD_SERVICE_ROLE>"
      },
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:CompleteLayerUpload",
        "ecr:InitiateLayerUpload",
        "ecr:PutImage",
        "ecr:UploadLayerPart"
      ]
    },
    {
      "Sid": "AllowLambdaPull",
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": [
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer"
      ],
      "Condition": {
        "StringLike": {
          "aws:SourceArn": "arn:aws:lambda:<AWS_REGION>:<ACCOUNT_ID>:function:*"
        }
      }
    }
  ]
}

The repository URI entered in DCF must match the repository that CodeBuild can push to, for example:

123456789012.dkr.ecr.us-east-1.amazonaws.com/dcf-lambda-repo

11. Attach CodeBuild Service Role Permissions

The CodeBuild service role needs read access to the staged artifact, ECR push permissions, CloudWatch Logs permissions, Lambda create/update permissions, and permission to pass the Lambda execution role.

During real deployment validation, the Lambda statement below was required for successful create/update deployments, Lambda waiters, Function URL creation, and public Function URL permissions. Do not treat these as optional conceptual permissions: missing lambda:GetFunctionConfiguration, lambda:CreateFunctionUrlConfig, lambda:AddPermission, or lambda:TagResource can allow the image build to succeed and then fail the deployment during the Lambda phase.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadDcfArtifact",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::<DCF_ARTIFACT_BUCKET>/builds/app.zip"
    },
    {
      "Sid": "GetEcrAuthToken",
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PushLambdaImage",
      "Effect": "Allow",
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:CompleteLayerUpload",
        "ecr:InitiateLayerUpload",
        "ecr:PutImage",
        "ecr:UploadLayerPart"
      ],
      "Resource": "arn:aws:ecr:<AWS_REGION>:<ACCOUNT_ID>:repository/<ECR_REPOSITORY_NAME>"
    },
    {
      "Sid": "WriteBuildLogs",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:<AWS_REGION>:<ACCOUNT_ID>:*"
    },
    {
      "Sid": "CreateOrUpdateLambda",
      "Effect": "Allow",
      "Action": [
        "lambda:CreateFunction",
        "lambda:UpdateFunctionCode",
        "lambda:UpdateFunctionConfiguration",
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration",
        "lambda:GetFunctionUrlConfig",
        "lambda:CreateFunctionUrlConfig",
        "lambda:AddPermission",
        "lambda:TagResource"
      ],
      "Resource": "arn:aws:lambda:<AWS_REGION>:<ACCOUNT_ID>:function:*"
    },
    {
      "Sid": "PassLambdaExecutionRole",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::<ACCOUNT_ID>:role/<LAMBDA_EXECUTION_ROLE>",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "lambda.amazonaws.com"
        }
      }
    }
  ]
}

ecr:GetAuthorizationToken must use "Resource": "*". Keep the image push actions scoped to the repository DCF will use for Lambda containers.

If the customer uses a shared policy across accounts or regions during setup, the required Lambda resource pattern is arn:aws:lambda:*:*:function:*. For a single production integration, prefer the scoped arn:aws:lambda:<AWS_REGION>:<ACCOUNT_ID>:function:* resource shown above.

12. Required CodeBuild Environment Variables

DCF passes these variables when starting the build:

S3_BUCKET: the artifact bucket saved in the AWS integration
S3_KEY: builds/app.zip
FUNCTION_NAME: the sanitized DCF function name or deployment override
AWS_REGION: the selected AWS region
ECR_REPOSITORY_URI: the customer ECR repository URI saved in the AWS integration
LAMBDA_EXECUTION_ROLE_ARN: the customer Lambda execution role ARN saved in the AWS integration

The buildspec also accepts:

IMAGE_TAG: optional explicit image tag
LAMBDA_TIMEOUT_SECONDS: optional Lambda timeout, default 30
LAMBDA_MEMORY_MB: optional Lambda memory size, default 512
DCF_ENVIRONMENT: optional value used in Lambda tags, default aws-e2e-qa

13. Package A Dart HTTP Function For Lambda

The artifact that DCF uploads must contain a pubspec.yaml, at least one Dart source file, and a Dockerfile. The container must listen on PORT; the standard buildspec appends AWS Lambda Web Adapter and sets PORT=8080 when the Dockerfile does not already include the adapter.

DCF rejects deployment archives that are missing any mandatory artifact:

Dockerfile
pubspec.yaml
at least one Dart source or entry file (*.dart)

Use one of the supported Dart SDK constraints in pubspec.yaml:

environment:
  sdk: '>=3.11.0 <3.12.0'

Minimal Dart server example:

import 'dart:io';

Future<void> main() async {
  final port = int.parse(Platform.environment['PORT'] ?? '8080');
  final server = await HttpServer.bind(InternetAddress.anyIPv4, port);

  await for (final request in server) {
    request.response
      ..headers.contentType = ContentType.json
      ..write('{"ok":true,"service":"dartcloudfunctions"}')
      ..close();
  }
}

Minimal Dockerfile example:

FROM dart:stable AS build
WORKDIR /app
COPY pubspec.* ./
RUN dart pub get
COPY . .
RUN dart compile exe bin/server.dart -o /app/server

FROM debian:bookworm-slim
WORKDIR /app
COPY --from=build /app/server /app/server
EXPOSE 8080
CMD ["/app/server"]

14. Verify And Save In DCF

Verify OIDC trust:

POST /api/v1/projects/\{projectId\}/integrations/aws/oidc/verify
Authorization: Bearer <Firebase ID token>
Content-Type: application/json

{
  "roleArn": "arn:aws:iam::123456789012:role/dcf-gke-role",
  "region": "us-east-1"
}

Then validate and save storage/deployment config:

POST /api/v1/projects/\{projectId\}/integrations/aws/bucket/save
Authorization: Bearer <Firebase ID token>
Content-Type: application/json

{
  "bucketName": "dcf-customer-artifacts",
  "codebuildProject": "dcf-lambda-build",
  "ecrRepositoryUri": "123456789012.dkr.ecr.us-east-1.amazonaws.com/dcf-lambda-repo",
  "lambdaExecutionRoleArn": "arn:aws:iam::123456789012:role/lambda-execution-role"
}

Verifying A Lambda Deployment

After a deployment succeeds:

Open the CodeBuild build logs and confirm the final command printed a Lambda Function URL.
In the Lambda console, confirm the function exists in the selected region and uses the image URI from the configured ECR repository.
In the Function URL tab, confirm the URL exists with auth-type NONE and the public invoke permission was added for the deployed function.
In ECR, confirm the image tag pushed by CodeBuild exists in the repository configured in DCF.

Call the Function URL:

curl -i https://<function-url-id>.lambda-url.<AWS_REGION>.on.aws/

Confirm the response is from the Dart server and the status code is expected.
Confirm CloudWatch has CodeBuild logs for the build and a Lambda log stream for the function.
In DCF, confirm the deployment status is succeeded and the AWS deployment metadata includes the function name, CodeBuild project, and region.

Troubleshooting AWS Lambda Deployments

Use this checklist when a deployment fails after AWS setup appears complete:

CodeBuild cannot read the artifact: confirm the artifact exists at s3://<bucketName>/builds/app.zip and the CodeBuild service role has s3:GetObject for that object.
Docker build starts but no image appears in ECR: confirm ECR_REPOSITORY_URI matches the target repository and the CodeBuild service role has ecr:GetAuthorizationToken plus push permissions for that repository.
Image build succeeds but Lambda is not created or updated: confirm the CodeBuild service role includes the full Lambda action set from the Attach CodeBuild Service Role Permissions section, including lambda:GetFunctionConfiguration.
Lambda waiters fail: check lambda:GetFunctionConfiguration and confirm the Lambda execution role can be passed with iam:PassRole to lambda.amazonaws.com.
Function URL creation fails: check lambda:GetFunctionUrlConfig, lambda:CreateFunctionUrlConfig, and lambda:AddPermission on the CodeBuild service role.
Function URL exists but public HTTPS calls fail: confirm the Function URL uses auth-type NONE and that CodeBuild added public function URL invoke permissions for the deployed function.
Deployment validation rejects the Dart package: confirm pubspec.yaml uses one of the supported SDK windows, >=3.10.0 <3.11.0 or >=3.11.0 <3.12.0. Broader constraints such as >=3.11.0 <4.0.0 currently fail validation.
Runtime starts but HTTP requests fail: confirm the Dart server listens on PORT. DCF injects AWS Lambda Web Adapter and sets PORT=8080; customers should not duplicate adapter setup manually.

Useful AWS checks:

aws codebuild batch-get-builds --ids <build-id> --region <AWS_REGION>
aws ecr describe-images --repository-name <ECR_REPOSITORY_NAME> --region <AWS_REGION>
aws lambda get-function --function-name <FUNCTION_NAME> --region <AWS_REGION>
aws lambda get-function-url-config --function-name <FUNCTION_NAME> --region <AWS_REGION>
aws logs tail /aws/lambda/<FUNCTION_NAME> --since 30m --region <AWS_REGION>

E2E QA Checklist

For a real AWS E2E QA pass, use a dummy customer-style AWS account and verify:

the DCF API pod has an AWS audience token mounted at AWS_WEB_IDENTITY_TOKEN_FILE
the setup command response has no audience warning
the customer IAM OIDC provider trusts the returned DCF issuer
the customer IAM role trust policy matches the returned DCF subject and sts.amazonaws.com audience
POST /integrations/aws/oidc/verify succeeds
POST /integrations/aws/bucket/save succeeds with a real bucket, CodeBuild project, ECR repository URI, and Lambda execution role ARN
function upload writes to S3 through OIDC temporary credentials
AWS deployment uploads builds/app.zip, starts CodeBuild, waits for completion, and records the Lambda deployment metadata
CodeBuild downloads the artifact, builds the container, pushes the image to ECR, and creates or updates the Lambda function
the Lambda Function URL is created with auth-type NONE and returns the expected Dart HTTP response
undeploy removes the Lambda function URL config, public permission, and function when those resources exist

Common Mistakes

Using a default Kubernetes service account token that does not include audience sts.amazonaws.com.
Copying the DCF issuer or subject from a different environment.
Creating the IAM OIDC provider but forgetting the role trust policy StringEquals conditions.
Granting S3 permissions to the CodeBuild role but not to the DCF assumed role.
Granting CodeBuild permissions to the DCF role but not enough Lambda permissions to the CodeBuild service role.
Saving a bucket without a CodeBuild project. AWS deployment needs both.
Saving the integration without ECR_REPOSITORY_URI or LAMBDA_EXECUTION_ROLE_ARN.
Missing lambda:GetFunctionConfiguration on the CodeBuild service role. The AWS CLI waiters need this after create and update operations.
Giving the Lambda execution role to DCF instead of granting CodeBuild iam:PassRole for that role.
Building a container that listens on a hard-coded port instead of the PORT environment variable.
Pointing DCF at an ECR repository in a different region than the Lambda deployment.