Load Balancing with ARR
When one server is not enough, Application Request Routing turns IIS into a load balancer that spreads traffic across several web servers.
On this page · 5 min · Advanced
On this page
- In simple words
- Learning objectives
- Explanation
- Code example
- Step by step
- Real-world use
- Common mistakes
- Best practices
- Remember this
- Practice exercise
- Mini quiz
- Related topics
- My notes
- Reading time
- 5 min
- Difficulty
- Advanced
- Updated
- Oct 30, 2026
Related tutorials
In simple words#
ARR is a restaurant host who seats each arriving group at whichever kitchen (server) is least busy, and stops seating people at a kitchen whose stove has broken (health check failed).
- Server farm
- Group of back-end servers behind ARR.
- Health test
- URL ARR checks to know a server is healthy.
- Affinity (sticky sessions)
- Same client always goes to the same server.
Learning objectives#
- Install ARR and create a server farm
- Configure health checks
- Choose a load balancing algorithm
- Make apps work behind a load balancer
Explanation#
Install Application Request Routing 3.0 (with URL Rewrite) on a front-end IIS server. Create a Server Farm and add back-end servers.
Health Test: ARR requests a URL (e.g. /health) every few seconds and removes unhealthy servers.
Algorithms: weighted round robin, least requests, least response time, hashing. Client affinity (cookie) pins users to one server — avoid it by keeping apps stateless.
Apps behind ARR must share session storage and Data Protection keys, and read the client IP from X-Forwarded-For.
Code example: Server farm with health check (applicationHost.config)#
<webFarms>
<webFarm name="ShopFarm" enabled="true">
<server address="web01.internal" enabled="true" />
<server address="web02.internal" enabled="true" />
<applicationRequestRouting>
<healthCheck url="http://shop.example.com/health" interval="00:00:10" responseMatch="Healthy" />
<loadBalancing algorithm="LeastRequests" />
<affinity useCookie="false" />
</applicationRequestRouting>
</webFarm>
</webFarms>
<!-- URL Rewrite rule on the front-end site routes requests to the farm -->
<!-- <action type="Rewrite" url="http://ShopFarm/{R:0}" /> -->
Requests are spread to the server with the fewest active requests; if web02’s /health stops returning “Healthy”, all traffic goes to web01 until it recovers.
This example is illustrative. Copy or download it and run it in your own environment; the expected output is shown above.
Step-by-step explanation#
- Two back-end servers form the farm.
- Every 10 seconds ARR checks /health on each server.
- LeastRequests sends traffic to the less busy server.
- Affinity is off, so the app must be stateless.
Real-world use case#
An e-commerce site survives a server patch window: one server is drained and updated while the other keeps serving customers.
Common mistakes#
Users lose their cart when they switch servers. Use a shared session store.
Cookies issued by one server fail on another. Share the key ring.
Best practices#
- Stateless apps
- Meaningful /health endpoints
- Shared Data Protection keys
- Drain servers before maintenance
Remember this#
ARR = IIS as a load balancer.
Health checks remove broken servers.
Stateless apps scale; sticky sessions are a crutch.
Practice exercise#
Your task: Which ASP.NET Core feature lets the app see the real client IP behind ARR?
Show solution
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});
Mini quiz#
What does an ARR health test do?
Want more? Practise all IIS MCQs · IIS interview questions
My notes#
Saved in this browser.