Solve 'yum command not found' in AWS Lambda Python 3.12 base image

Solve ‘yum: command not found’ in AWS Lambda Python 3.12+ Base Image

by

If your Lambda Dockerfile suddenly breaks with yum: command not found after upgrading to the Python 3.12 base image (or later), the fix is straightforward. AWS switched the Lambda base image from Amazon Linux 2 to Amazon Linux 2023, which replaces yum with microdnf. This affects Python 3.12, 3.13, and 3.14 runtimes.

Why yum Is Missing

The Lambda base images for Python 3.11 and earlier used Amazon Linux 2, which includes yum as its package manager. Starting with Python 3.12, the images switched to Amazon Linux 2023 minimal, which uses microdnf — a lightweight, standalone implementation of dnf.

In the AL2023 image, microdnf is also symlinked as dnf, so you can use either command.

Python Runtime Base OS Package Manager
3.8 — 3.11 Amazon Linux 2 yum
3.12+ Amazon Linux 2023 microdnf / dnf

The Fix: Replace yum with microdnf

In your Dockerfile, replace every yum command with microdnf (or dnf). The syntax is the same for common operations.

Before (Python 3.11 and earlier)

RUN yum update -y && \
    yum install -y gcc make unixODBC-devel && \
    yum clean all

After (Python 3.12+)

RUN microdnf update -y && \
    microdnf install -y gcc make unixODBC-devel && \
    microdnf clean all

That’s the entire fix for most use cases. The install, update, remove, and clean subcommands work the same way.

Full Example: Installing ODBC Driver for SQL Server

A common reason to install system packages in a Lambda container is for database drivers. Here’s a working Dockerfile that installs the Microsoft ODBC driver for SQL Server on the Python 3.12 Lambda base image — useful if you’re connecting Lambda to SQL Server using PyODBC:

FROM public.ecr.aws/lambda/python:3.12

WORKDIR /opt/python/

# Install build tools and ODBC dependencies
RUN microdnf update -y && \
    microdnf install -y \
        gcc gcc-c++ make unixODBC-devel unzip python3-devel wget && \
    microdnf clean all

# Add the Microsoft package repo and install ODBC driver
RUN wget -qO- https://packages.microsoft.com/keys/microsoft.asc | \
        tee /etc/pki/rpm-gpg/MICROSOFT-GPG-KEY && \
    echo -e "[packages-microsoft-com-prod]\n\
name=packages-microsoft-com-prod\n\
baseurl=https://packages.microsoft.com/rhel/9/prod\n\
enabled=1\n\
gpgcheck=1\n\
gpgkey=file:///etc/pki/rpm-gpg/MICROSOFT-GPG-KEY" \
    > /etc/yum.repos.d/msprod.repo && \
    ACCEPT_EULA=Y microdnf install -y msodbcsql18 && \
    microdnf clean all && \
    rm -rf /var/cache/dnf /var/tmp/* /tmp/*

# Install Python dependencies
COPY requirements.txt .
RUN pip install -r requirements.txt --target .

COPY app.py ${LAMBDA_TASK_ROOT}
CMD ["app.handler"]

Key changes from an AL2-based Dockerfile:

  • yum replaced with microdnf everywhere
  • Microsoft repo baseurl uses rhel/9/prod (AL2023 is RHEL 9-compatible, not RHEL 7)
  • ODBC driver is msodbcsql18 (version 18 is current; version 17 is in maintenance)
  • Cache cleanup uses /var/cache/dnf instead of /var/cache/yum

If you hit CI/CD build hangs with this setup, see Fixing GitLab CI/CD Hangs: Building Docker Images for Lambda Runtime with MSSQL and ODBC.

Limitations of microdnf

microdnf is a minimal implementation. It doesn’t support everything yum or full dnf can do:

  • Cannot install an RPM from a remote URL directly (e.g., microdnf install https://example.com/package.rpm will fail)
  • Cannot install a local .rpm file directly
  • Workaround: download the RPM with wget or curl first, then install it with rpm -i package.rpm

Conclusion

The fix is a direct swap: replace yum with microdnf (or dnf) in your Dockerfile. This applies to all Lambda container images based on Python 3.12 and later. If you’re packaging Python dependencies as layers instead of containers, see How to Build and Deploy Python Libraries for AWS Lambda Layers.