Migrating Serverless Workflows to Containers: Lambda to ECS with API Gateway Canary Quiz

Explore core concepts and practical steps for migrating serverless functions to container-based services using ECS and integrating with API Gateway canary deployments. This quiz focuses on strategies, challenges, and best practices for transitioning workloads in cloud-native environments, optimizing API traffic management, and maintaining high service availability.

1. Identifying Key Differences

   Which core difference should you consider when migrating from a Lambda-based architecture to ECS regarding workload management?

   1. ECS requires manual container lifecycle management, while Lambda abstracts this management.
   2. ECS billings are always higher than Lambda for the same workload.
   3. ECS enforces only Python runtime, while Lambda is multi-runtime.
   4. Lambda always supports persistent network storage, but ECS does not.

   Explanation: The correct answer highlights that ECS places more responsibility on the user to manage the lifecycle of containers, unlike Lambda which abstracts infrastructure management. The second option generalizes costs, which vary depending on usage. The third is incorrect because ECS supports multiple runtimes based on container images, and Lambda also supports several runtimes. The fourth option is misleading as Lambda does not natively support persistent storage across invocations, while containers in ECS can use persistent storage if configured.

2. API Gateway Canary Deployment

   What is a primary benefit of using an API Gateway canary deployment when migrating serverless endpoints to ECS?

   1. Canary deployments allow directing a portion of API traffic to the new ECS tasks for controlled testing.
   2. Canary deployments reduce latency for all users permanently.
   3. Canary deployments require no additional configuration when switching environments.
   4. Canary deployments instantly roll back all changes upon failure.

   Explanation: Canary deployments enable gradual shifts of traffic, helping to identify issues with ECS before a full migration. Reducing latency is not a guaranteed result of a canary deployment. Additional setup is usually required, so the third option is incorrect. The fourth option is inaccurate because automated rollback is not always immediate or part of all canary setups.

3. Task Definition Setup

   When defining a task for ECS, what essential detail must you include that is not needed for configuring Lambda?

   1. The container image to deploy
   2. The function timeout setting
   3. The event trigger type
   4. Secret rotation schedule

   Explanation: Unlike Lambda, ECS requires the specific container image as the main unit of deployment. The function timeout is important for Lambda but not unique to ECS. Event triggers are more native to Lambda, which is event-driven. Secret rotation schedules pertain to credential management and are not directly required when defining a task.

4. API Gateway Integration

   Which integration type allows API Gateway to connect with both Lambda and ECS-based endpoints?

   1. HTTP integration
   2. WS integration
   3. SQL integration
   4. FTP integration

   Explanation: HTTP integration enables API Gateway to forward API requests to any HTTP endpoint, such as those served by ECS or Lambda. WS and SQL are not relevant to standard API Gateway integrations with container or serverless compute. FTP integration is for file transfers, not APIs.

5. State Management Challenge

   During migration from Lambda to ECS, why is handling stateful data often more complex in ECS?

   1. ECS containers can be replaced or restarted, making local state unreliable.
   2. ECS always encrypts data by default.
   3. ECS offers unlimited memory for stateful storage.
   4. Lambda supports built-in persistent databases.

   Explanation: Containers are designed to be ephemeral and can be replaced; thus, storing state locally is risky. Option two is incorrect because encryption is not always default. The third option is not true as containers have defined memory limits. The fourth option is false; neither environment has built-in persistent databases.

6. Security Group Adjustments

   After migrating an API endpoint from Lambda to ECS, what network configuration may need updating to permit traffic?

   1. Security group rules for containers
   2. Runtime memory settings
   3. Lambda permission policies
   4. Billing alert thresholds

   Explanation: ECS tasks often run in a different VPC configuration and require appropriate security group settings to allow network access. Runtime memory and billing alerts are unrelated to communication permissions. Lambda permission policies only affect the serverless function, not ECS.

7. Scaling Behavior

   What is a basic distinction in scaling between Lambda and ECS services?

   1. Lambda automatically scales based on invocation count, whereas ECS needs scaling policies configured.
   2. ECS scales instantly with traffic spikes without settings.
   3. Lambda cannot scale beyond one function instance.
   4. ECS requires hardware upgrades for scaling.

   Explanation: Lambda handles scaling automatically based on demand, while ECS requires you to define how and when tasks are started or stopped through scaling policies. The second choice is incorrect as ECS scaling needs configuration. Lambda can run many instances simultaneously—contradicting option three. ECS does not require manual hardware upgrades for scaling.

8. Monitoring Migration Success

   Which approach helps measure if API Gateway canary traffic handled by ECS is working as intended during migration?

   1. Monitor success and error rates for ECS-handled requests
   2. Only increase the canary proportion to 100% quickly
   3. Replace health checks with manual tests only
   4. Rely solely on memory usage metrics

   Explanation: Tracking success and error rates allows you to verify real traffic outcomes during canary migration. Gradually increasing traffic is safer than immediately shifting all users. Manual tests without health checks may miss certain failures, and focusing only on memory usage does not confirm correct request handling.

9. IAM Permissions Update

   Which step is often necessary when replacing Lambda with ECS regarding identity and access management (IAM)?

   1. Update roles or policies to grant ECS tasks equivalent permissions.
   2. Disable all IAM roles.
   3. Create a new Lambda function for each ECS task.
   4. Assign hardcoded secrets in code.

   Explanation: ECS tasks require appropriate roles with necessary permissions to replicate previous Lambda access. Disabling roles would break access. Replacing each ECS task with a new Lambda is irrelevant to migration. Hardcoding secrets is insecure and not recommended.

10. Function Entry Points

    Why must you specify a container command or entry point for ECS-based tasks, while Lambda does not require this?

    1. Containers need to know which process to run, unlike pre-defined Lambda handlers.
    2. Containers automatically detect the main handler.
    3. Lambda supports only compiled binaries.
    4. ECS automatically configures entry points.

    Explanation: ECS requires explicit instructions for container processes, as it can run any application, while Lambda relies on handler configuration. The second and fourth options misstate the ECS requirement. Lambda supports multiple code types, not just compiled binaries.

11. Traffic Weighting

    When configuring canary deployment for an API endpoint, what does adjusting 'traffic weighting' control?

    1. The percentage of user requests sent to the new ECS service
    2. The memory allocated to each container
    3. The bandwidth limit for the Lambda function
    4. The storage quota of each ECS task

    Explanation: Traffic weighting sets the proportion of requests routed to the new deployment, crucial for safe canary migrations. The other options, involving memory, bandwidth, or storage, do not relate to request distribution during deployment.

12. Zero-Downtime Strategy

    Which migration approach is most suitable to ensure zero-downtime when moving endpoints from Lambda to ECS?

    1. Conducting a gradual canary deployment via API Gateway
    2. Disabling the old endpoint before testing the new one
    3. Manually updating all clients simultaneously
    4. Relying solely on DNS propagation delays

    Explanation: Gradual canary deployments allow overlapping old and new environments, catching issues before a full switch. Disabling old endpoints or updating all clients at once risks interruption. DNS propagation is unpredictable and doesn't guarantee zero-downtime.

13. Environment Variables Management

    What is an important consideration regarding environment variables when migrating from Lambda to containers on ECS?

    1. ECS containers require explicit definition of all environment variables.
    2. Containers inherit all variables from the old Lambda by default.
    3. Environment variables are not supported in ECS.
    4. Variables must be entered via code comments only.

    Explanation: ECS needs environment variables defined in task definitions or orchestration configurations. Variables from Lambda are not transferred automatically. ECS supports environment variables, so option three is incorrect. Defining them via code comments has no effect.

14. Common Logging Changes

    During migration of logging functionality from Lambda to ECS, what typical adjustment is needed?

    1. Configure container logs to forward output to a log aggregation system
    2. Disable all logging to save space
    3. Log output to HTTP headers only
    4. Use the same log directory for all containers and applications

    Explanation: In containers, logs are produced by the running process and need to be routed to a log aggregation or monitoring tool. Disabling logs prevents troubleshooting. Logging to HTTP headers is not a standard logging approach. Sharing one directory can cause conflicts in multi-container systems.

15. Timeout and Retries

    Which consideration is necessary when configuring timeouts and retries after moving an API handler from Lambda to ECS?

    1. ECS services may have different timeout and retry behaviors than Lambda, requiring updates.
    2. Both ECS and Lambda use identical default timeouts.
    3. Retries are not possible in ECS.
    4. Timeouts only apply to database transactions.

    Explanation: Timeout and retry logic differ between the two environments—ECS tasks and load balancers or gateways often need explicit configuration. Default settings do not match exactly. Retries can be set at several layers in ECS. Timeouts can apply to various processes, not just database transactions.

16. Rollback Readiness

    Which feature of API Gateway can assist with rapid rollback during the migration of serverless APIs to ECS?

    1. Quickly reverting traffic weighting to the previous endpoint
    2. Provisioning larger containers instantly
    3. Encrypting all user responses
    4. Deleting all ECS tasks at once

    Explanation: API Gateway can shift traffic back to the original environment by adjusting traffic weights if the new deployment fails. Provisioning, encryption, and mass deletion do not specifically address returning service to a pre-migration state during rollback.