About Migrating AWS Lambda Workloads to OCI Functions

AWS Lambda functions are frequently embedded in larger application and integration workflows.

A successful migration requires more than moving code between platforms. OCI Functions is the default target for AWS Lambda migration initiatives. Before selecting OCI Functions as the target, identify how each function is invoked, what services it interacts with, what operational behaviors it relies on, and which behaviors must be preserved.

This inventorying includes collecting trigger type, maximum duration, memory use, payload sizes, concurrency, retry and failure behavior, dependencies, IAM permissions, network paths, logging, monitoring, and recovery expectations. These characteristics determine whether OCI Functions or another OCI service is the better target.

During assessment, validate that the workload’s invocation, payload, timeout, memory, concurrency, networking, dependency, and integration requirements can be supported by OCI Functions.

If OCI Functions cannot meet a documented requirement, pause the migration and complete the exception review before proposing a non-Functions architecture. The exception must include the technical constraint, revised total-cost model, migration effort, operational impact, and explicit approval of the revised approach.

What you will do

  • Create an evidence-based inventory of Lambda configuration, triggers, dependencies, permissions, traffic, failures, and operational signals.
  • Compare source behavior with OCI Functions limits, invocation modes, trigger patterns, security, dependency packaging, networking, and observability.
  • Separate portable business logic from provider-specific event parsing, identity, SDK calls, deployment packaging, logging, secrets, retries, and operational code.
  • Deploy the function as an OCI Functions container image and validate outputs, errors, side effects, latency, capacity, retries, security, observability, and rollback readiness before cutover.

How to Use This Playbook

This playbook is an assessment and implementation guide.

For a large Lambda estate, do not begin by manually assessing every function. Start with a representative sample covering the primary runtimes, triggers, dependencies, traffic profiles, and business-criticality levels.

Use the sample to:

  1. Confirm the OCI Functions migration approach for representative workloads.
  2. Identify required adapters and targeted code changes.
  3. Identify required security, networking, deployment, and operational changes.
  4. Estimate migration effort, risk, and reusable patterns.
  5. Select representative workloads for a working migration pilot.

It does not automatically convert Lambda code or generate all required integrations.

Architecture

This reusable pattern separates source assessment from target implementation.

Inventory the Lambda function, its triggers, and its operational behavior first. Then isolate portable business logic from provider-specific adapters. The target implementation runs in an OCI Functions application, is deployed from a container image stored in Container Registry, uses OCI IAM and resource principals for runtime access, retrieves secrets from an approved secret store such as OCI Vault, and emits operational signals through OCI Logging, Monitoring, Alarms, and APM where needed.

AWS Lambda to OCI Functions relationship map

This is a grouped view of the workload envelope to re-create around OCI Functions


Description of migrate-lambda-functions-arch.png follows
Description of the illustration migrate-lambda-functions-arch.png

migrate-lambda-functions-arch-oracle.zip#GUID-B6E215FE-1619-4CDD-B055-0194D46ADBF8

Architecture principles

  • Assess first, then migrate. Triggers, payloads, retries, layers, permissions, networking, and operational behavior can differ.
  • Treat trigger migration as behavior migration. Compare event shape, authentication, retries, ordering, batching, duplicate delivery, filtering, dead-letter or failure destinations, and poison-message handling.
  • Measure the source workload. Capture invocation rate, peak concurrency, duration percentiles, maximum duration, memory use, cold-start-sensitive paths, payload sizes, error rate, throttle rate, DLQ or failure counts, backlog, and downstream limits.
  • Keep business logic portable. Isolate adapters for event parsing, identity, SDK calls, object or message access, logging, configuration, secrets, and retry behavior.
  • Make operations part of the migration. Logs, metrics, alarms, dashboards, traces, runbooks, rollback triggers, and failure tests must exist before cutover.

Core components

The architecture typically includes the source Lambda workload, a migration record, an OCI invocation layer, the OCI Functions application and image, and the supporting security, networking, and operations services. Treat the source as evidence, not as a direct blueprint; choose OCI components from required behavior and validation results.

AWS Lambda and OCI Equivalent Concepts

Use this key during assessment.

This key is intended as a translation guide, not a promise of one-to-one equivalence. For each row, compare source behavior with target OCI behavior and keep evidence in the migration record.

AWS Lambda concept OCI concept or pattern What to compare or validate
Function and handler OCI Functions with Fn FDK handler Runtime, architecture, handler entry point, event parser, response object, error behavior, local test path, and runtime-specific library support.
ZIP package, layers, extensions Container image or shared base image Dependency versions, native libraries, image size, startup behavior, extension behavior, embedded SDK assumptions, and whether dependencies should be shared across functions.
Execution role and resource policies OCI Identity and Access Management (IAM) policies, dynamic groups, and resource principals Runtime actions, compartment and resource scope, cross-account or cross-compartment access, secret reads, object or queue access, and denied-path tests.
API Gateway plus Lambda OCI API Gateway plus OCI Functions Authentication, route and method, headers, query strings, body schema, status codes, response headers, timeout, payload size, latency, and error body.
S3 object events OCI Object Storage events through OCI Events Event schema, object metadata, namespace, bucket and prefix filters, create/update/delete behavior, retries, duplicates, idempotency, and input/output loop prevention.
SQS, streams, SNS, EventBridge, log subscriptions OCI Queue, OCI Streaming, OCI Notifications, OCI Events, OCI Connector Hub, or redesigned flow Batch size, ordering, retry, partial failure, dead-letter or failure destination, visibility or retry windows, backpressure, poison messages, fanout, filters, and duplicate delivery.
Synchronous or asynchronous invocation Sync or detached invocation Caller response semantics, result handling, invocation timeout, execution timeout, detached completion handling, success/failure destination, and retry path.
Memory, timeout, payload, ephemeral assumptions OCI Functions memory, timeout, request, response, image, and runtime settings p95/p99 and max duration, timeout count, memory headroom, request/response payload sizes, temporary storage assumptions, large-payload offload design, and dependency load time.
Reserved/provisioned concurrency and event-source scaling OCI service limits, application concurrency, provisioned concurrency, trigger controls, and downstream protection Current and peak concurrency, cold-start sensitivity, throttles or 429s, queue age or backlog, retry storms, downstream capacity limits, and whether the source setting reserves capacity, caps traffic, or reduces latency.
CloudWatch Logs, Metrics, Alarms, X-Ray OCI Logging, OCI Monitoring, alarms, dashboards, and Oracle Application Performance Monitoring (APM) where needed Required log fields, correlation IDs, invocation count, duration, error rate, timeout count, alarm thresholds, traces, dashboards, runbooks, and incident response ownership.
Secrets Manager, Parameter Store, KMS, VPC networking OCI Vault, keys, VCN, subnets, gateways, private endpoints, DNS, and security rules Secret rotation, leak checks, route rules, egress, DNS, allowlists, private access, unauthorized-path blocking, and downstream connection limits.