Agave Mountain

Jeff Alexander posted on his blog an entry which exposes who Microsoft.com and update.microsoft.com are setup. Interestingly enough, here are the high points:

• We don't handle HBI data so we don't have the need for external logging capabilities. If we did handle HBI, we'd have firewalls.
• We have ~650GB/day of IIS logs just for www.microsoft.com and update.microsoft.com (not including the 6GB/hour for each download server). Just IIS logs are a challenge without trying to parse another ~650GB of firewall logs.
• 5+ years ago, there wasn't a firewall solution that would scale to our needs and this forced us to focus on network, host, and application security. Based on the success of that work, we've not looked further at firewalls even though there are solutions that I believe (haven't tested) would handled the traffic load (our non-download based web traffic alone can be in the 8-9 Gbps range and ~30 total for internal hosted traffic).
• We also used NLB for load balancing exclusively up until July 2006 and the micro segmentation of networks required by that solution made firewalls an expensive and very complex solution. Again, especially at the scalability that used to be available.
• Application security is critical since a firewall is likely going to allow traffic on the correct port and protocol through to the web servers so IIS/ASP.NET/Applications must deal with these requests gracefully. I realize there are other options/features of firewalls/IPS that provide other options.

Interestingly, they don't use a firewall, squid or other "scalable" architecture.

Powered by ScribeFire.