[AZURE] Chau chau! Azure Functions Proxies

Adiós a Azure Functions Proxies: Te dejo un tips y qué hacer antes de septiembre 2025

Arrancamos..

Hace poco me enteré de una noticia importante sobre Azure Functions que quería compartir con ustedes. Si alguna vez trabajaste con Azure Functions, seguramente recuerdas Azure Functions Proxies, esa funcionalidad práctica para crear endpoints ligeros y unificar rutas sin tener que montar un gateway completo.

Microsoft anunció que Azure Functions Proxies dejará de recibir soporte a partir del 30 de septiembre de 2025. Claramente esto no lo inventé yo, sino que aqui te dejo el aviso oficial aquí: https://learn.microsoft.com/en-us/answers/questions/2285459/official-clarification-needed-azure-functions-prox. Aunque puede seguir funcionando por un tiempo, ya está deprecado y podría eliminarse en cualquier momento.

En este artículo quiero mostrarles un ejemplo práctico de uso de Proxies y cómo podemos migrar a Azure API Management (APIM) para evitar problemas en el futuro. un ejemplo práctico de uso de Proxies y cómo migrar ese escenario a Azure API Management (APIM) para evitar problemas futuros.

Caso práctico: Unificando APIs con Azure Functions Proxies

Supongamos que tienes dos Azure Functions:

• FunctionA en /api/func-a

• FunctionB en /api/func-b

Con Proxies, si es que lo recordás, "Gracias Chatgpt, yo no lo recordaba" podías definir un archivo proxies.json como este:

{
"$schema": "http://json.schemastore.org/proxies",

"proxies": {

"MyAPI": {

"matchCondition": {

"route": "api/my-api/{endpoint}"

},

"backendUri": "https://<funcapp>.azurewebsites.net/api/{endpoint}"

}

}

}

Esto permitía exponer un único endpoint /api/my-api/... que redirigía dinámicamente a las Functions según el parámetro {endpoint}.

¿Cuál es el problema ahora?

A partir de septiembre de 2025, este tipo de configuración dejará de estar soportada. Si tu aplicación depende de Proxies, existe el riesgo de que tus amados endpoints dejen de funcionar.

Alternativa muy recomendada: Azure API Management

Con APIM, podemos lograr la misma funcionalidad creando una API con rutas personalizadas y políticas de reenvío (backend URL rewrite).

Ejemplo de política APIM para la misma lógica anterior:

<inbound>

<base />

<set-backend-service base-url="https://<funcapp>.azurewebsites.net/api" />

</inbound>

Luego definimos las rutas /func-a y /func-b dentro de la API, gestionando autenticación, permisos y versionado de forma centralizada.

Ahh, me olvidaba. Te comparto un example oficial https://github.com/Azure-Samples/functions-proxies/blob/master/ProxiesSamples/proxies.json

Esto que nos deja a mi entender..

El "Shift + Delete" de Azure Functions Proxies marca el fin de una herramienta sencilla que muchos usamos para resolver problemas rápidos en entornos serverless. Sin embargo, también abre la puerta a adoptar soluciones más completas como Azure API Management, que nos brindan mayor seguridad, escalabilidad y control.

Si todavía usas Proxies, este es un buen momento para revisar tu arquitectura y pensar en cómo evolucionarla antes de que llegue septiembre de 2025. Migrar a APIM no solo evita problemas futuros, sino que puede ser una gran oportunidad para ordenar y fortalecer la estrategia de tus APIs.

Con APIM en mi experiencia no fué todo color de rosas, ya que para mí el mayor defecto de APIM es su complejidad inicial de configuración y la curva de aprendizaje para equipos que no están familiarizados con la gestión de políticas y versiones de API.

Para más info sobre APIM y sus capacidades, puedes consultar la siguiente documentación oficial de Microsoft: https://learn.microsoft.com/es-es/azure/api-management/