🎯 TL;DR: AGIC Direct Pod Ingress for High-Performance AKS Workloads

AGIC provides direct pod ingress bypassing Kubernetes ClusterIP for up to 50% lower network latency compared to in-cluster solutions. Problem: Traditional ingress controllers add network hops and consume AKS compute resources. Solution: Application Gateway routes directly to pod IPs via Azure Resource Manager integration, offering WAF, SSL termination, and managed updates as AKS add-on. Critical limitation: 100 backend pool limit means 2000+ services require 20 Application Gateways, making cost-effective deployment challenging for large-scale clusters.

Recently I ran into an interesting issue with an AKS cluster running 2000+ services. There is nothing wrong in running 2000+ services that’s what Kubernetes is there for, scale! but the interesting aspect that caught my attention was trying to get the Applicaiton Gateway Ingress Controller (AGIC) to ingress to all these services. I had worked with Istio and NGINX for ingress into AKS with no issues and never AGIC, so I had to try this to see where it worked well, what the advantages are and where the limitations are.

Application Gateway

Application Gateway (App Gateway) is a well-established layer 7 service that has been around for a while, some of the major features are:

• URL routing
• Cookie-based affinity
• SSL termination
• End-to-end SSL
• Support for public, private, and hybrid web sites
• Integrated web application firewall
• Zone redundancy
• Connection draining

This post isn’t focused on the App Gateway itself, it’s more about how and what it can do as an ingress controller for AKS. You can find out more about App Gateway and all abouts its features here

🎯 TL;DR: Dynamic IP Management for CI/CD to Secured Azure Functions

IP-restricted Function Apps block GitHub Actions runners causing HTTP 403 deployment failures since runners use dynamic IP addresses. Problem: Cannot whitelist entire GitHub IP range due to frequent changes. Solution: Dynamic IP management in GitHub Actions workflow using Azure CLI to temporarily add runner IP to SCM site access restrictions, deploy code, then remove IP. Implementation uses ipify API for IP detection, --use-same-restrictions-for-scm-site false for SCM isolation, and automated cleanup to maintain security posture.

This secures our function app and it isn’t available publicly, any one that tries to access our function app url will get “HTTP 403 Forbidden”.

This secures our function app; now what about deploying code changes to the function app via GitHub Actions? we should be able to CI/CD to our function app, but there is a problem here. The GitHub action will fail with the same “HTTP 403 Forbidden”, this is because GitHub actions run on runners (its a hosted virtual environment), each time we run the Action we get a new runner and it can have a different ip address. So how can we get around this? do we white list the entire GitHub ip range?

GitHub’s ip ranges can change any time, so will have to keep scanning for changes to these ranges and proactively update our ip restrictions, this is not very scalable or practical. So what are other ways of getting around this? we have a couple of ways to get around this.

Possible Solutions

There are two viable solutions here

🎯 TL;DR: Cost-Optimized Security for Serverless Microservices

Consumption plan Function Apps and APIM Standard lack VNet integration for cost optimization but expose services publicly. Problem: Serverless microservices accessible directly bypassing API Management security policies. Solution: IP restriction-based security using APIM’s public IP address to whitelist only API Management access, configuring both main site and SCM site restrictions. Architecture includes Azure Front Door for WAF capabilities since APIM Standard lacks native WAF protection.

Here is a scenario that I recently encountered. Imagine we are building micro-services using serverless (a mix on Azure Function Apps and Logic Apps) with APIM in the front. Lets say we went with the APIM standard instance and all the logic and function apps are going to be running on consumption plan (for cost reasons as its cheaper). This means we wont be getting any vnet capability and our function and logic apps will be exposed out to the world (remember to get vnet with APIM we have to go with the premium version, we are going APIM standard here for cost saving reasons).

So how do we restrict our function and logic apps to only go through the APIM, in another words all our function and logic apps must only go through the APIM and if anyone tries to access them directly they should be getting a “HTTP 403 Forbidden”.

Lets visualize this scenario; We have some WAF capable ingress endpoint, in this case its Azure Front Door, that is forwarding traffic to APIM which then sends the requests to the serverless apps.
Reason for having Front Door before APIM is because APIM doesn’t have WAF natively so we will need to put something in front of it that has that capability to be secure.

There are few options like Azure Firewall, Application Gateway etc, but for the purposes of this scenario we have Azure Front Door in front of APIM (and we can have an APIM policy that will only accept traffic from Azure Font Door, we wont be going in to that, we will keep it to securing our function apps to just being available via APIM for today)

After sitting on this for a long time and wanting to blog / write down my thoughts, I’ve finally got my act together and started this. There were so many times I was asked some very good questions which I am sure not just the person asking me but a lot more would have been interested in knowing the answer/solution/thoughts around the matter. This is a way to write about that and help the wider community who are searching for similar solutions.

I regularly answer in Stack Overflow and in some cases I wrote a question and answered it myself just incase some one was looking for something similar, that wasn’t really the ideal platform to do that. There have been so many times that going through and reading other people’s blogs have helped me and unlocked me in problems that I was stuck with; this is a in a way trying to give back to the community and helping people that are on the look out for a solution for a similar problem.

How to power the blog

There were so many choices out there when it came to what frameworks and libraries to use to build the blog and what to use to host the blog.

My requirements when it came to building were simple

• Easy to author posts
• Easy to build
• Easy to maintain
• Most customizations (eg: search, ads, tags, categories etc) should come out of the box

My requirements when it came to hosting were even simpler

• Has to be free
• Has to be able to handle ‘some’ level of load
• Easy to CI/CD