Creating AWS API Gateway with PRIVATE endpointType requires ResourcePolicy

Serverless Framework
,
1

I am trying to deploy an API Gateway for a serverless function with a private endpoint type. When I try to deploy the API I get the following message:

An error occurred: ApiGatewayDeployment… - Private REST API doesn’t have a resource policy attached to it (Service: AmazonApiGateway; Status Code: 400; Error Code: BadRequestException; Request ID: …).

I am using the documentation found in the serverless docs. It doesn’t mention anything about having to create a resource policy. The VPC endpoint itself has a very permissive policy.

Should the example below work? Do I need a resource policy as well or should the framework add it for me as it generates the CF stack?

VPC endpoint policy:

{
"Statement": [
    {
        "Action": "*",
        "Effect": "Allow",
        "Resource": "*",
        "Principal": "*"
    }
]
}

Serverless.yml file:

service:
    name: helloworld-api

provider:
    name: aws
    runtime: nodejs12.x
    region: ap-southeast-2
    stage: ${opt:stage, 'dev'}
    endpointType: PRIVATE
    vpcEndpointIds:
      - ${env:VPC_ENDPOINT_ID}  
    vpc:
      subnetIds: 
        - ${env:SUBNET_ID_1}
        - ${env:SUBNET_ID_2}
1 Like
2

Hello gomesp, did you find a solution?

3

It seems that serverless framework is setting an empty policy string if you won’t specify provider.resourcePolicy yourself.

This seems to be causing problems for the PRIVATE endpoint type.

As AWS suggests you should allow only traffic from your VPC for the PRIVATE endpoint type.

4

Also I guess that gomesp may had it right but the Resource policy inside serverless.yml shouldn’t contain the Statement only the array itself like this:

You can see an example of how to add Resoruce policy to the serverless.yml here https://www.serverless.com/framework/docs/providers/aws/events/apigateway#resource-policy

provider:
  resourcePolicy:
   - Effect: Allow
     Action: '*'
     Resource: '*'
     Principal: '*'

Of course it is not advised to have such policies so I would stick with the AWS policy mentioned above.