Migrate Google Cloud Functions to AWS Lambda

Hey there, Darian Vance here. As a Senior DevOps Engineer at TechResolve, I’ve seen my fair share of multi-cloud setups. One of the most common tasks that lands on my desk is migrating services between providers. For a long time, I treated Google Cloud Functions (GCF) and AWS Lambda as entirely different beasts. But once I realized how similar their core concepts were, I started building a repeatable playbook for migration. It’s saved my team countless hours, and I’m hoping it’ll do the same for you. Let’s dive in.

Prerequisites

Before we start, make sure you have the following ready:

• An AWS account with IAM permissions to create Lambda functions, API Gateway endpoints, and IAM roles.
• A Google Cloud Platform account with an existing Cloud Function to migrate.
• The AWS CLI and Python installed on your local machine.
• A basic understanding of both GCF and Lambda concepts.

The Step-by-Step Migration Guide

Step 1: Analyze Your Existing Google Cloud Function

First, let’s look at a typical HTTP-triggered function in GCF. The code is usually straightforward. It takes a single `request` object, which is a Flask Request object under the hood.

Here’s a simple GCF `main.py` that we’ll use as our starting point:

# GCF: main.py
import functions_framework
import os

@functions_framework.http
def gcf_handler(request):
    """
    Responds to an HTTP request.
    Expects a JSON payload like: {"name": "Alex"}
    """
    # GCF automatically parses the JSON body for you
    request_json = request.get_json(silent=True)
    
    if request_json and 'name' in request_json:
        name = request_json['name']
    else:
        name = 'World'
        
    # Accessing an environment variable
    greeting = os.environ.get('GREETING', 'Hello')

    return f"{greeting}, {name} from Google Cloud!"

The key things to note here are the function signature `gcf_handler(request)` and how it directly uses `request.get_json()` to access the payload. This is the part that will change the most.

Step 2: Refactor the Function for AWS Lambda

Now, let’s adapt this logic for Lambda. AWS Lambda’s handler signature is different; it takes two arguments: `event` and `context`.

• event: This is a dictionary that contains all the invocation data. For an HTTP call from API Gateway, it includes headers, query parameters, and the request body.
• context: This object provides runtime information about the invocation, function, and execution environment. We won’t use it here, but it’s good to know it exists.

I’m going to skip the standard project setup steps—creating a directory, setting up a Python virtual environment, and so on. You likely have your own workflow for that, and I want to get straight to the Python logic that matters.

Here’s the refactored `lambda_function.py`:

# Lambda: lambda_function.py
import json
import os

def lambda_handler(event, context):
    """
    AWS Lambda handler function.
    Triggered by API Gateway.
    """
    print(f"Received event: {event}") # Good for debugging!

    try:
        # The request body comes in as a string inside the 'body' key.
        # We need to load it into a dictionary.
        body = json.loads(event.get('body', '{}'))
        name = body.get('name', 'World')
    except (json.JSONDecodeError, AttributeError):
        # Fallback if body is empty or not valid JSON
        name = 'World'
        
    # Accessing environment variables is the same!
    greeting = os.environ.get('GREETING', 'Hello')

    message = f"{greeting}, {name} from AWS Lambda!"
    
    # API Gateway expects a specific JSON response format.
    return {
        'statusCode': 200,
        'headers': {
            'Content-Type': 'application/json'
        },
        'body': json.dumps({'message': message})
    }

Notice the two major changes:

1. We parse the request body from `event[‘body’]`, which is a string.
2. We return a structured dictionary with `statusCode`, `headers`, and `body`. API Gateway needs this to formulate a proper HTTP response.

Pro Tip: In my production setups, I rarely use the manual ZIP and upload process. I highly recommend using a framework like the AWS Serverless Application Model (SAM) or the Serverless Framework. They automate packaging, deployment, and configuration of resources like API Gateway and IAM roles, saving you from a world of configuration headaches.

Step 3: Package and Deploy to Lambda

Unlike GCF, which just needs a `requirements.txt`, Lambda requires you to bundle your dependencies into a deployment package (a .zip file).

1. Install Dependencies Locally: You’ll need to install any packages from your `requirements.txt` into your project folder. A common way to do this is with pip’s target flag, which directs the installation into the current directory.
2. Create the Zip File: Create a zip file containing `lambda_function.py` and all the installed dependency folders. Make sure the Python file is at the root of the zip archive, not inside another folder.
3. Create the Lambda Function: In the AWS Console, create a new Lambda function. Choose the Python runtime, and upload your .zip file. Set the handler to `lambda_function.lambda_handler` (which means `filename.function_name`).
4. Configure Environment Variables: In the function’s configuration tab, you can add the same environment variables you had in GCF (like our `GREETING` variable).

Step 4: Set Up the API Gateway Trigger

To make our Lambda function accessible via HTTP, we need to create a trigger. The most common choice is Amazon API Gateway.

1. In your Lambda function’s page, click “Add trigger”.
2. Select “API Gateway”.
3. Choose “Create a new API” and select “HTTP API” for simplicity and lower cost.
4. Leave the security as “Open” for now and add the trigger.

Once created, API Gateway will give you an API endpoint URL. You can now send a POST request to this URL with a JSON body like `{“name”: “Darian”}`, and you should get your Lambda’s response back!

Common Pitfalls (Here’s Where I Usually Mess Up)

• IAM Permissions: This gets me every time. Your GCF function had an implicit identity and permissions. In AWS, your Lambda function needs an explicit IAM “Execution Role”. If your function needs to talk to S3, DynamoDB, or any other AWS service, you must add the necessary permissions to this role. The default role is extremely limited.
• The `event` Structure: I showed the structure for an API Gateway trigger. If your trigger is an S3 object creation, a message from an SQS queue, or a CloudWatch event, the `event` dictionary will look completely different. I always start by adding `print(event)` as the first line in my handler so I can inspect the exact structure in the CloudWatch logs.
• Packaging Errors: Zipping up the parent folder instead of its contents is a classic. If AWS says it can’t find your handler module, this is usually the culprit. Your `lambda_function.py` must be at the top level of the archive.

Conclusion

And that’s the core workflow. Migrating from GCF to Lambda is less about a complete rewrite and more about adapting to a new handler signature, response format, and deployment model. The business logic—the actual work your function does—often remains nearly identical. By focusing on these key differences, you can make the transition smooth and predictable. Happy building!

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions