Skip to content
Replacement for AWS API-Gateway that invokes your AWS Lambdas based on HTTP requests
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


Simple replacement for AWS API-Gateway that invokes your AWS Lambdas based on HTTP requests.


I like the simplicity of deploying and maintaining AWS Lambdas and use them quite often for APIs. But AWS charges a lot for API-Gateway requests so I wrote this replacement. The goal is not to build a feature-complete clone of the AWS API-Gateway. It just takes a HTTP request, invokes a Lambda and serves it's response.

Function-Gateway uses the same envelope like API-Gateway, so your existing Lambdas should be compatible out of the box.

As I use Serverless Framework for deploying Lambdas and it offers an easy way to declare HTTP method and path to deploy an AWS API-Gateway on the fly, I wanted Function-Gateway to be compatible with this workflow more or less.


Make sure you have Java 8 installed!

  1. Download the latest JAR or WAR
  2. Configure the Function-Gateway (See below)
  3. For JAR: Run java -jar function-gateway.jar
  4. For WAR: Deploy to e.g. Tomcat (AWS Elastic Beanstalk works well!)


Download the default gateway.yml here and put it the same directory as your function-gateway.jar.

You'll find help within the YAML on how to configure the Function-Gateway.

AWS Credentials

For sure the Function-Gateway will need access to your AWS resources. It should only use the following actions:

  • lambda:InvokeFunction
  • If you enabled the CrawlAWS resolver it'll also use:
    • lambda:ListFunctions
    • lambda:ListTags

Function-Gateway will use the default credentials provider chain. Read more about it here.


Resolvers are sources for HTTP method, path and what Lambda should be invoked. You can use all resolvers simultaneously to fit your needs.


The static resolver allows you to declare your mapping in the gateway.yml.


This resolver does what its name suggests. It will load all Lambdas and it's tags directly from AWS in a fixed interval and adjust mappings accordingly.

This resolver works best with Serverless Framework!

Migrate Serverless Framework to use Function-Gateway

Let's say you have the following function in your serverless.yml:

    handler: de.ketrwu.api.HelloWorld
    - http:
        path: /hello/world
        method: GET

All you need to do:

    handler: de.ketrwu.api.HelloWorld
      path: /hello/world
      method: GET

The CrawlAWS resolver can read this information and adjusts mappings accordingly.


The Webhook is used by serverless-function-gateway plugin. It announces new created Lambdas directly after deployment to your function-gateway.

Further info on this, here.


When this resolver is enabled, it will look for database changes each request and adjust routes on the fly. Useful if you have multiple Function-Gateways as a cluster, example:

One Function-Gateway (Master) has the CrawlAWS and Database resolver enabled and all slaves only the Database resolver. All nodes will use the same database and serve the same routes.

There is no Load-Balancer / Proxy included

You can configure your database credentials at the bottom of your gateway.yml. By default it uses H2 (in-memory database). The drivers for MySQL and MariaDB are included, e.g.:

    driver-class-name: org.mariadb.jdbc.Driver
    url: jdbc:mariadb://localhost/databasename
    username: username
    password: password


Here are some examples how you could configure Function-Gateway to fit different approaches.

Gateway per stage

You can have your Lambdas deployed for different stages and have separate Function-Gateways for different stages.

  • Set the stage of the gateway: gateway.stage: dev
  • Optional: Enable stage prefix gateway.pathStagePrefix: true
    • Let's say you have the path /hello/world
    • With this setting enabled it will be served at /dev/hello/world

Gateway cluster

You can run multiple gateways with the same datasource to have fail-safe redundancy.

Let's assume:

  • You have 5 gateways and a load-balancer that randomly picks one gateway and redirects the HTTP request to it
  • 1 Gateway has CrawlAWS and Database resolver enabled
  • 4 Gateways have only Database resolver enabled
  • All share the same database
  • The first gateway will always update the routes in the database
  • All others can read the database without being busy with crawling
  • No matter where the load-balancer redirects the request, you'll always have a gateway that can handle it.

You can also have multiple CrawlAWS gateways an no database but that might cause inconsistency

You can also directly edit the database (or update it from another third-party application)

You can’t perform that action at this time.