Oracle Cloud Serverless Functions unleashed: exposing OCI Functions through API Gateway

Oracle Cloud Infrastructure API Gateway makes it possible to expose OCI Functions on public endpoints that do not require complex signed HTTP requests. Any function that should be easily publicly accessible can be given such easy access. By creating an API Deployment on an API Gateway and associating a route in that API Deployment with an Oracle Function Backend. If needed, parameter mapping can be added as well as custom authorization and CORS headers in addition to rate limiting, monitoring and logging.

This article describes how easy it is to take a prepared Oracle Function (see for example this article) and a an existing API Gateway (check out this article for an introduction) and add the required security configuration and the route definition to expose the Oracle Function publicly. Once that has been done, these Functions are unleashed. They can be wired together easily, engaged from just about anywhere and start playing the role I believe they are meant to play.

The steps required (provided an API Gateway instance exists and a Function has been deployed) are straightforward:

  • create dynamic group with matching rule (that ensures that the API Gateway is a member of the dynamic group)

Assuming the function has been deployed and can be invoked (in this case function hello in application lab-app in compartments functions-compartment), we can get going:

Create dynamic group with matching rule (that ensures that the API Gateway is a member of the dynamic group)

The API Gateway needs to have permission to access the Function that we want to include in the API Deployment’s Route as a backend. The suggested way for realizing this is through the definition of a Dynamic Group. Dynamic groups allow you to group Oracle Cloud Infrastructure resources as “principal” actors (similar to user groups). You can then create policies to permit instances to make API calls against Oracle Cloud Infrastructure services. When you create a dynamic group, rather than adding members explicitly to the group, you instead define a set of matching rules to define the group members. See the documentation here.

Here I have defined the Dynamic Group fn-gw-dynamic-group.

The intended matching rule is composed of two conditions: resource.type equals ApiGateway and equal the OCID of the compartment where the API Gateway was created (the functions-compartment). The resulting rule:

ALL {resource.type = ‘ApiGateway’, = ‘ocid1.compartment.oc1..aaaaaaaatxf2nfi7pnoyq4ilq’}

Initially, however, with this Matching Rule in place, the API Gateway was not able to access the Function. When I changed ALL to ANY, the access was available. I tried to find out which part of the rule was matched and which was not. Both seemed to be. I then changed ANY back to AND. And the access was still there. I am not sure if I did something wrong (typo in the rule?) or there was a timing issue. Anyways, now it is working as expected.

Create a policy with three statements (that grant privileges to the dynamic group)

The Dynamic Group needs permissions. All members of the group — i.e. the API Gateway — needs three permissions in order to successfully invoke any Function in functions-compartment. These permissions are provided through a policy. The following policy is created in the functions-compartment: dyn-group-gateway-access-functions-compartment and three statements are added:

  • allow dynamic-group [your dynamic group] to use virtual-network-family in compartment [compartment name]

With these three statements, the dynamic group receives all the permissions it needs.

Create an API deployment and a route with Oracle Function as backend type; select the target Function

Select the API Gateway that will contain the API Deployment exposing the Function.

Click on Create Deployment:

Configure the basic configuration: the name fn, the path prefix /fn and the compartments functions-compartment (in my situation):

Press Next.

Configure the Route leading to Function hello. Here is the configuration for Route 1: the path is /hello (so on top of the API Deployment’s path this makes /fn/hello), the supported methods are GET and POST. The backend type is Oracle Functions and the target Function to be invoked is Function hello compartment lap-app.

optional: add additional log and request policies on the API deployment or the routes.

Click on Next. Click on Create:

The new API Deployment is in the process of being created:

and after a little while, the API Deployment is ready for action:

Invoke the Function through the new public endpoint on the API Gateway (once all changes have been processed)

A call to the API on the API Gateway can easily be made from for example Postman. API Gateway will then invoke the Function and the response from the function is returned to the client:

Here we see a POST request sending a simple JSON payload and a response that makes clear that the payload has been received and processed.

From the command line using Curl:

curl -X POST \ \
-d ‘{
“name”:”John Dimbleby”,
“payload”:{“param1″:”221", “param2″:”Some Payload value”}


My previous blog article: Introducing Oracle Cloud API Gateway — the light weight public or private router to public and private OCI endpoints —

First steps with API Gateway —

OCI API Gateway Docs — Adding a Function in Oracle Functions as an API Gateway Back End —

Article/Tutorial by Todd Sharp — Creating Your First API Gateway In The Oracle Cloud —

Originally published at on January 1, 2020.

Lucas Jellema is solution architect and CTO at AMIS, The Netherlands. He is Oracle ACE Director, Groundbreaker Ambassador, JavaOne Rockstar and programmer