Understanding TCP Connection Limits for Azure Container Apps with Cosmos DB

Gebriel Tadesse 0 Reputation points
2024-04-07T08:45:41.0833333+00:00

I'm developing an ASP.NET Web API for handling CRUD operations with Cosmos DB and plan to deploy it on Azure Container Apps. My setup involves using multiple CosmosClient instances connected to different accounts, aiming for a multi-tenant architecture. The Cosmos DB documentation on multi tenancy advises determining the maximum number of client instances a single compute instance can support based on the compute environment's limitations and the connection mode used:

Based on the limitations of the compute environment, determine the number of client instances (and therefore number of tenants) a single compute instance can handle. You can estimate the number of connections that will be opened per client depending on the connection mode chosen.

I'm struggling to find specific information on the limits of Azure Container Apps, particularly regarding the maximum number of open TCP connections an instance can support. I've reviewed the quotas documentation for Azure Container Apps but haven't found the answers I need.

Could anyone point me in the right direction or provide insights into the TCP connection limitations within Azure Container Apps environments?

Azure Cosmos DB
Azure Cosmos DB
An Azure NoSQL database service for app development.
1,447 questions
Azure Container Apps
Azure Container Apps
An Azure service that provides a general-purpose, serverless container platform.
270 questions
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Amira Bedhiafi 15,596 Reputation points
    2024-04-21T20:03:27.53+00:00

    Based on this blog :

    Inbound Connections

    With basic pricing tier, there is a limit of 350 concurrent WebSockets per instance. With standard pricing tier and above, there are no theoretical limits on WebSockets, but other factors that can limit the number of WebSockets, for example, maximum simultaneous requests allowed per CPU (a.k.a. maxConcurrentRequestsPerCpu): 7,500 per small VM, 15,000 per medium VM (7,500 x 2 cores), and 75,000 per large VM (18,750 x 4 cores).  For more details, see Azure Web App sandbox · projectkudu/kudu Wiki · GitHub.

     

    Additionally, the platform might throttle requests to protect against DDoS attacks when the request rate is unusually high,  this protects at layer 3 and layer 4 network layers.  For web application protection at layer 7, it is recommended to add protection at the application layer using a WAF(web application firewall) offering.

     

    If you suspect that the app's requests are dropping due to the DDoS protection, you can mitigate this issue through the following operations:

    • If the app service is deployed in the App Service Environment (ASE), you can scale up the Front End instance count to reduce the inbound connection rate per instance.
    • In a multi-tenant environment which is outside of App Service Environment (ASE), such as in the Standard, Premium, Premium2, and Premium3 pricing tiers, we don't have control over the Frontend instance count. In this case, an alternative approach is to create a traffic manager and deploy multiple Azure App Services across different scale units. By using the traffic manager, we can split the incoming requests to different App Services, effectively distributing the load.

    Outbound connections

    The Azure App Service has two types of limitations for outbound connections: Outbound TCP connections and Source Network Address Translation (SNAT). If you encounter intermittent connection issues from the app service to external resources, it is recommended to investigate both of these limitations as potential causes.

     

    Update :

    For outbound connections, similar Azure services like Azure App Service enforce limits based on the instance size: 1,920 connections for smaller instances, scaling up to 16,000 connections for the largest instances. While these numbers provide a rough guideline, they may not directly apply to Azure Container Apps but give a general idea of the scaling capability in Azure's managed services infrastructure.

    When deploying applications that might require managing a high number of connections, it is essential to design with best practices like connection pooling and scaling strategies in mind. In Azure Container Apps, you can scale your applications dynamically based on various metrics through Kubernetes Event-driven Autoscaling (KEDA) which integrates with Azure-specific metrics like Azure Service Bus queues. This allows more effective management of resources in response to load variations.