Serverless Lambda Magento 1/2 Setup

To run Magento in the AWS Lambda we need Bref Composer package. It helps you deploy PHP-FPM and PHP CLI and run them on AWS Lambda.

Image for post
Image for post
Magento Serverless

Bref provides:

  • PHP custom runtimes for AWS Lambda
  • Serverles Magento deployment tooling
  • documentation

This post created by my notes how I run lambda for Magento 1

First we need to install NodeJS and Serverless framework.

The Serverless Framework is a tool that makes programming AWS Lambda, Azure Functions, and Google Cloud Functions easier, by removing much of the boilerplate out of the native cloud providers’ development experiences. It generates the YAML and configuration required for functions, and simplifies uploading code packs to the cloud. It relies on the cloud provider’s APIs or templating solutions for any provisioning or management beyond the functions themselves.

Image for post
Image for post

As a result, we are having AWS Lambda with custom PHP runtime layer

Image for post
Image for post
Magento Serverless serverless Custom Runtime

If to use Load Ballancer with Lambda it will look like:

Image for post
Image for post

And that’s it. Next, you need just adjust magneto to work with a little bit with our environment. The main difference is in the $_SERVER variables.

Changes needed to make Magento 1 works with Lambda:

Change App/etc and /var folder to /tmp

All writable folders should be inside /tmp/

Some framework or library caches must be written into files. In that case storing in the /tmp directory is a good solution.

Remember that anything stored in /tmp will be lost when a lambda stops. When a lambda starts, the /tmp directory will be empty so the cache will be generated again.

Note that this is useful for deployments: no need to clear caches on deployments since a new version of the lambda will run on new instances (with an empty /tmp directory).

This solution is ideal when the cached data is fast to generate and never changes (e.g. template caching, framework caches).

USE REDIS FOR Cache and session STORAGE

MY index PHP init lines lloks like:

The /dev/ prefix

API Gateway works with “stages”: a stage is an environment (e.g. dev, test, prod).

This is why applications are deployed with URLs ending with the stage name, for example See this StackOverflow question for more information.

If you setup a custom domain for your application this prefix will disappear. If you don’t, you need to take this prefix into account in your Magento routes

To do this you need to fix the next files:

nano magento/app/code/core/Mage/Core/Model/Url.php

nano magento/app/Mage.php

Or just use custom API Gateway domain without stage prefix. Also you can use Elastic load balancer invocation of Magento lambda function.

You can register your Lambda functions as targets and configure a listener rule to forward load balancer requests to the target group for your Lambda function. When the load balancer forwards the request to a target group with a Lambda function as a target, it invokes your Lambda function and passes the content of the request to the Lambda function, in JSON format.

The maximum size of the response JSON that the Lambda function can send is 1 MB.

To add base path mappings, an important concept to note here that this will replace your API stage name in the URL

The default API endpoint would be as follows

Static Assets

Magento Lambda and API Gateway are only used for executing code. Serving assets via PHP does not make sense as this would be a waste of resources and money.

However, in some cases you will need to serve images (or other assets) via PHP lambda.

Binary requests and responses

By default API Gateway does not support binary HTTP requests or responses like images, PDF, binary files… To achieve this, you need to enable the option for binary media types in serverless.yml as well as define the BREF_BINARY_RESPONSES environment variable:

This will make API Gateway support binary file uploads and downloads, and Bref will automatically encode responses to base64 (which is what API Gateway now expects).

You can Magneto serve static content using lambda by adding this lines to index.php:

Logs to CloudWatch

The simplest solution is to push logs to AWS CloudWatch — service for logs.

PHP errors and warnings

By default, all PHP errors, warnings, and notices emitted by PHP will be forwarded into CloudWatch.

That means that you don’t have to configure anything to log errors, warnings or uncaught exceptions.

Writing logs

Your application can write logs to CloudWatch:

For example with Monolog:

Notice! I checked installed Magneto works grate with pre-installed codebase with REDIS. Setup Magento from scratch using lambda more difficult installation process requires files app/etc, sessions modification.

Magento 2 Lambda performance

The Lambda memory selection affects proportionally on the allocated CPU. Currently, AWS Lambda supports 128MB up to 3008MB to choose from.

When the allocated memory crosses the limit of 1,792 MB, it adds the equivalent of one full vCPU (one vCPU-second of credits per second).

More CPU allocated basically means:

  1. Faster function duration — In some cases it means less latency for your customers!
  2. Higher costsPricing increases proportionally.
Image for post
Image for post
Duration Improvement and Price

My Suggestion is to starts from 1700MB and after test with different configurations.

Magento AWS Lambda pricing

The AWS Lambda free usage tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month.

The price for Duration depends on the amount of memory you allocate to your function. You can allocate any amount of memory to your function between 128MB and 3008MB, in 64MB increments. The table below contains a few examples of the price per 100ms associated with different memory sizes.

Image for post
Image for post

Magento Lambda example price calculation excluding free tire discount

Image for post
Image for post

Unit conversions

  • Amount of memory allocated: 1500 MB x 0.0009765625 GB in a MB = 1.46484375 GB

Pricing calculations

  • RoundUp (300) = 300 Duration rounded to nearest 100ms
  • 2,000,000 requests x 300 ms x 0.001 ms to sec conversion factor = 600,000.00 total compute (seconds)
  • 1.46484375 GB x 600,000.00 seconds = 878,906.25 total compute (GB-s)
  • 878,906.25 GB-s x 0.0000166667 USD = 14.65 USD (monthly compute charges)
  • 2,000,000 requests x 0.0000002 USD = 0.40 USD (monthly request charges)
  • 14.65 USD + 0.40 USD = 15.05 USD

Magento Lambda costs — Without Free Tier (monthly): 15.05 USD

How to setup an EFS/NFS file system with AWS Lambda read there:

Written by

Magento/APP Cloud Architect. Melting metal server infrastructure into cloud solutions.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store