AWS API Gateway as Ingress Controller Advanced settings

3 min readMay 19, 2020

I was trying to use [1] to set up API Gateway faced Ingress setup. But when I was doing that I found a lot of short falls in the feature list present. Rather than complaining I developed these missing features by myself. So this blog is to introduce these features.

If you look at the PR I sent[2] it contains a lot of changes because I had to upgrade the goformation version to use WAF V2. So to use the latest version I had to migrate to go modules. Here I am not going to elaborate on those. I will just focus on the features I presented.

Update API GW resources when Ingress rules are changed.

This is a very basic feature that was missing from the repository. When we update the ingress rules it’s not updating the cloud formation stacks with new rule configuration. In our case it’s a miss for the CICD process. So my first step was to implement that.

Allow to change API GW Endpoint type (EDGE, Regional) via annotations

In the original repository, Endpoint type was hard coded to EDGE. I added an annotation to make it configurable. Still the default is EDGE if we don’t mention.

Want to read this story later? Save it in Journal.

WAF (V2) Integration

WAF integration is also a very important feature for a production grade system. It was not there in the ingress controller. While doing this addition I had to upgrade the goformation dependency because WAF V2 was only present in goformation v4.x. And it led me to migrate whole project from deps to go modules.

WAF Rule definition

This was one of the most trickiest implementations here. WAF rules could be of various types. How can we apply WAF rules from ingress controllers in a way that works for all cases. Here what I have done is let the user input the cloudformation json segment of the WAF rules via the annotation. With this any WAF rule can be configured in a manner the user needs.

API Keys and Usage Plan integrations

Earlier it only had the capability of authentication with IAM user and aws signatures for authentication. But I added the capability of configuring API Keys and Usage Plans to the Ingress Controller itself.

Route 53 Integration

Even Though it contains the feature of APIGW custom domains, it doesn’t have the route53 record set creation. I added that feature also with my changes. It’s configurable via a simple annotation now.

Route53 in central account

This could be another important feature for production grade systems. When we have multiple accounts in AWS we want to manage route 53 from a central place sometimes. So this feature allows to configure the central Route 53 hosted zone by assuming a role. Here node group role of EKS should be given access to assume the role provided in the annotation. And the role provided should have access to cloudformation and route53 to create records.

You can find the full code in my GitHub location[3]. And I added an example to the README[4].