Introduction

Running Selenium inside AWS Lambda is possible, but it only works well when you treat Lambda as a constrained headless Linux environment rather than a normal desktop machine. The main tasks are packaging a compatible browser binary, running in headless mode, and keeping the function within Lambda's memory, file-system, and startup limits.

Why Selenium is harder on Lambda

A typical Selenium script assumes a local browser installation and enough system packages to launch it. Lambda does not provide that out of the box.

The main constraints are:

• no graphical desktop environment
• limited ephemeral file storage
• cold-start sensitivity
• deployment-size limits unless you use layers or container images

That is why the Lambda version of a Selenium setup usually uses headless Chromium or Chrome plus carefully chosen launch flags.

Basic Python setup

A common pattern is to package Selenium and a compatible headless Chromium build in a Lambda layer or container image.

1from selenium import webdriver
2from selenium.webdriver.chrome.options import Options
3
4
5def build_driver():
6    options = Options()
7    options.binary_location = "/opt/chrome/chrome"
8    options.add_argument("--headless=new")
9    options.add_argument("--no-sandbox")
10    options.add_argument("--disable-dev-shm-usage")
11    options.add_argument("--single-process")
12    options.add_argument("--window-size=1280,720")
13
14    service = webdriver.ChromeService(executable_path="/opt/chromedriver")
15    return webdriver.Chrome(service=service, options=options)

The /opt path is common when the browser and driver arrive through a Lambda layer.

A minimal Lambda handler

Here is a small Lambda handler that opens a page and returns the title.

1from selenium import webdriver
2from selenium.webdriver.chrome.options import Options
3
4
5def lambda_handler(event, context):
6    options = Options()
7    options.binary_location = "/opt/chrome/chrome"
8    options.add_argument("--headless=new")
9    options.add_argument("--no-sandbox")
10    options.add_argument("--disable-dev-shm-usage")
11
12    service = webdriver.ChromeService(executable_path="/opt/chromedriver")
13    driver = webdriver.Chrome(service=service, options=options)
14
15    try:
16        driver.get("https://example.com")
17        return {"title": driver.title}
18    finally:
19        driver.quit()

The important operational detail is always calling quit() so browser processes do not linger between invocations.

Layers versus container images

For small setups, Lambda layers are convenient because they let you share browser binaries and Python dependencies across functions.

For more complex browser automation, container images are often easier. They give you direct control over system libraries, browser version, and packaging layout, which can reduce compatibility surprises.

If your Selenium environment is large or fragile, a container image is usually the more maintainable option.

Operational advice

Browser automation is not a natural Lambda workload if the session is long-lived or heavily stateful. Lambda works best for short, event-driven, disposable browser tasks.

Useful tuning knobs include:

• allocate enough memory, which also increases CPU share
• increase timeout for slow pages
• write temporary downloads only under /tmp
• keep page interactions short to reduce cold-start cost impact

You should also budget for startup latency in both the Lambda runtime and the browser itself. For very short automation tasks, that overhead can be more expensive than the useful work.

Common Pitfalls

A common mistake is packaging a browser binary built for the wrong Linux environment. Selenium may import correctly while the browser fails to launch.

Another issue is forgetting Lambda's file-system constraints. If the browser expects writable directories outside /tmp, startup can fail.

It is also easy to underestimate cold starts and browser startup overhead. For very small automation tasks, the overhead may dominate the useful work.

Summary

• Selenium can run on AWS Lambda, but only with a compatible headless browser setup.
• Use headless Chromium or Chrome, plus launch flags suited to Lambda's environment.
• Store compatible browser binaries in a Lambda layer or container image.
• Keep jobs short, stateless, and careful about /tmp usage.
• If the browser workload is long-lived or heavy, Lambda may be the wrong runtime.