No. You serve the static assets from a CDN, but the authentication and dynamic content generation need to scale very quickly when you have an in rush of traffic. This is the perfect use case for Amazon AWS (GovCloud, specifically).

EDIT: Disclaimer: I did not work on Healthcare.gov, but did study up on the entire architecture while trying for a gig on the recovery team.

How many servers are we talking here, anyway? Like 1 rack's worth or what?

It's highly variable because of the way health insurance in the US works.

There's an "enrollment" period where you can switch/reenroll in your plan. It only lasts a few weeks to a few months in the end of the year. During that period, load is immense.

Outside that period, there's extremely low traffic, as only people who have "qualifying events" are eligible to shop for insurance - if you get married, divorced, lose a job, etc.

Letting someone else figure out what to do with 95% of your server capacity for 10ish months out of the year is a pretty decent cost savings for the government, I'd imagine.

The government has their own amazon cloud, but to the point I think it actually would be better to use a virtualized setup because then you can scale power as needed and not have to worry too much about bringing servers online. Then when the inevitable slow period comes you can scale down significantly. This is my experience at least.