Inventory the Lambda Workload

Create a migration record with enough evidence to reproduce and compare source behavior.

To inventory the lambda workload, follow these steps:

  1. Record configuration, deployment path, dependencies, layers, native libraries, environment variables, VPC settings, IAM role, triggers, owner, and operational contacts.
  2. Capture baseline metrics: invocation rate, peak concurrency, p95 and p99 duration, maximum duration, memory used, payload sizes, errors, timeouts, throttles, retries, DLQ or failure count, queue age or backlog, alarm thresholds, and downstream capacity limits.
  3. Save representative success events, malformed events, duplicate events, timeout cases, permission failures, downstream failure samples, and source log examples with sensitive values redacted.

Look for: A complete inventory record with evidence links, initial risk notes, and gaps that need owner confirmation.

Output: Do not rely only on configuration exports. Logs, metrics, alarms, and representative events usually reveal behavior that configuration alone does not show.

Assess Each Sampled Function for OCI Functions Migration

Record the requirements, required changes, and migration decision for each sampled function.

To assess each sampled function for OCI Functions migration, complete an assessment record with the following items for each sampled function:

  • Function name and application owner
  • Business purpose and criticality
  • Runtime and version
  • Trigger and incoming event format
  • AWS services and SDK calls used
  • Execution time, memory, concurrency, and payload size
  • Retry, ordering, duplicate-delivery, and failure behavior
  • IAM permissions and network dependencies
  • Current logs, metrics, alarms, and service-level objectives
  • Required OCI Functions configuration and trigger pattern
  • Required code, adapter, or deployment changes
  • Known gaps and unresolved risks

Use one of the following assessment outcomes:

  • OCI Functions migration ready: The workload can move to OCI Functions with limited changes.
  • OCI Functions migration with changes: The workload requires an adapter, targeted code changes, configuration changes, or operational changes.
  • Exception review required: OCI Functions may not meet a documented workload requirement. Do not proceed with a non-Functions architecture without the exception review described in this playbook.

The application owner and migration owner should review the assessment before implementation begins.

Assess OCI Functions Migration Requirements

Determine the OCI Functions migration approach for a workload.

To assess OCI Functions migration requirements, follow these steps:

  1. Review the workload’s trigger, runtime, dependencies, execution duration, memory, concurrency, payload, IAM, networking, and operational requirements to determine the OCI Functions migration approach.
  2. Separate portable business logic from AWS-specific event parsing, SDK calls, IAM assumptions, logging, and retry handling.

    This makes the required migration changes visible before implementation begins.

  3. Use the following OCI Functions migration patterns as a starting point.
    Workload pattern OCI Functions migration pattern Validate
    Stateless, event-driven, short-running workload OCI Functions Payload, memory, timeout, concurrency, dependencies, and required downstream access
    HTTP API workload OCI API Gateway plus OCI Functions Authentication, methods, routes, headers, payload size, error responses, latency, and timeout
    Object, notification, queue, stream, or log event processor OCI Functions with the applicable OCI Events, Oracle Cloud Infrastructure Queue, OCI Notifications, OCI Streaming, or OCI Connector Hub service Event format, delivery behavior, retries, ordering, duplicate handling, failure destination, and backpressure

OCI Functions is the default target for Lambda migration initiatives when it meets the workload’s functional, performance, security, and operational requirements.

Design the Target OCI Architecture

Define invocation, identity, secret, network, dependency, observability, and cutover patterns.

To design the target OCI architecture, follow these steps:

  1. Select the invocation path and document expected authentication, payload shape, headers or metadata, latency, retries, ordering, batch behavior, duplicate delivery, filtering, and failure destination.
  2. Define the OCI Functions application, compartment, image repository, VCN, subnets, route tables, security rules, service gateway or NAT gateway, private access, egress requirements, and downstream endpoints.
  3. Identify every OCI service or external endpoint the function calls at runtime, including OCI Object Storage, OCI Queue, OCI Streaming, OCI Vault, databases, and third-party APIs.
  4. Define operational signals such as log fields, correlation ID, invocation count, duration, errors, timeouts, capacity symptoms, downstream failures, dashboard views, alarms, and runbook steps.

Look for a target architecture summary with component list, integration path, security design, operational design, and diagram redraw guidance.

Considerations: Architecture design is complete only when normal flow, retry flow, failure flow, denied-access flow, and rollback flow are described.

Design Considerations and Target Selection

Use these considerations during design review.

They are intentionally action-oriented so reviewers can ask for evidence rather than accepting general statements of readiness.

  • Target fit: Use OCI Functions for stateless, event-driven, short-running, containerizable work that fits the target limits and invocation model. Use another target for long-running, stateful, daemon-like, orchestration-heavy, worker-like, or AWS-service-coupled workloads.
  • Payloads and timeouts: Record actual request and response sizes, maximum duration, timeout count, and caller response semantics. Pass large data by reference through OCI Object Storage, OCI Queue, OCI Streaming, or another store rather than through the function payload.
  • Dependencies: Convert ZIP and Lambda layer assumptions into image or shared-base-image dependencies. Test native libraries, image size, dependency versions, startup behavior, embedded SDK assumptions, and runtime behavior.
  • Concurrency and scaling: Inventory why AWS reserved or provisioned concurrency was used: reserved capacity, traffic cap, cold-start reduction, event-source throttling, or downstream protection. Design OCI behavior with capacity planning, provisioned concurrency where appropriate, trigger controls, backpressure, and downstream limits.
  • Triggers: Validate event shape, retry, ordering, batch behavior, duplicate delivery, filtering, failure destination, and idempotency. Trigger behavior is usually the highest-risk migration area.
  • Operations: Treat logs, metrics, alarms, dashboards, traces, runbooks, rollback trigger, and rollback owner as migration deliverables, not post-cutover cleanup.

Target selection guide

Workload trait Recommended OCI target Why
Stateless, event-driven, short-running, containerizable function OCI Functions Closest fit when payload, timeout, memory, trigger, dependency, networking, and concurrency constraints are satisfied.
HTTP API function with simple request/response behavior OCI API Gateway plus OCI Functions Good fit when authentication, headers, payload size, timeout, latency, status code, and response semantics are validated.
Object, notification, queue, stream, or log event processor OCI Functions with OCI Events, OCI Notifications, OCI Connector Hub, OCI Streaming through Connector Hub, or redesigned messaging flow Potential fit, but delivery, retry, ordering, batch, duplicate, poison-message, and failure behavior must be redesigned and tested.
Long-running job or worker-like process OCI Container Instances, OKE, OCI Compute, or decomposed workflow Avoids function invocation and runtime constraints while preserving a container or service-based deployment path.
Integration-heavy orchestration Oracle Integration, workflow service, or redesign Better fit when the workload coordinates systems, waits for external state, or manages compensating steps rather than executing a small unit of compute.
Stateful process, local durable state, or daemon OCI Compute, OKE, or redesign OCI Functions is not a durable local-state or daemon execution model.

Prepare OCI Resources and Deployment Access

Prepare the minimum target environment needed to build, deploy, and smoke-test.

To prepare OCI resources and deployment access, follow these steps:

  1. Create or identify the compartment, OCI Functions application, VCN subnets, OCI Container Registry repository, OCI Vault secret locations, logging resources, and monitoring alarms.
  2. Configure developer and CI/CD access for building images, pushing images, deploying functions, invoking smoke tests, and reading logs.
  3. Create dynamic group rules and policy statements for runtime access. Scope by compartment and resource where possible, especially for buckets, streams, queues, OCI Vault secrets, and databases.
  4. Smoke-test image push, function deploy, direct invoke, log emission, secret read, denied secret read, and one representative downstream service call.

Look for a ready target environment with access paths documented and a passing smoke test.

Considerations: Ensure that deployment identity and runtime identity are separate when the process requires different permissions.