What is the difference between an Azure Web Site and an Azure Web Role

Question

What are the material differences between the new Azure Web Sites and the traditional Azure Web Roles for an ASP.NET MVC application? What reason would I choose a "web site" over a "web role" or vice versa?

Let's assume that I would need equal capacity in either case (e.g. 2 small instances). The prices seem comparable other than the fact that there is a 33% temporary discount for web sites while they are in their preview period.

Are there things that I can do with a "web site" that are difficulty or impossible with a web role? For example, does it become easy to put multiple web sites in a single set of VMs using "web sites"? Do I lose anything with a "web site" vs a "web role"? Ability to fine tune IIS? Ability to use the Cache service locally?

Answer 1

Web Roles give you several features beyond Web Apps (formerly Web Sites):

• Ability to run elevated startup scripts to install apps, modify registry settings, install performance counters, fine-tune IIS, etc.
• Ability to split an app up into tiers (maybe Web Role for front end, Worker Role for backend processing) and scale independently
• Ability to RDP into your VM for debugging purposes
• Network isolation
• Dedicated virtual IP address, which allows web role instances in a cloud service to access IP-restricted Virtual Machines
• ACL-restricted endpoints (added in Azure SDK 2.3, April 2014)
• Support for any TCP/UDP ports (Web Sites are restricted to TCP 80/443)

Web Apps have advantages over Web Roles though:

• Near-instant deployment with deployment history / rollbacks
• Visual Studio Online, github, local git, ftp, CodePlex, DropBox, BitBucket deployment support
• Ability to roll out one of numerous CMS's and frameworks, (like WordPress, Joomla, Django, MediaWiki, etc.)
• Use of SQL Database or MySQL
• Simple and fast to scale from free tier to shared tier to dedicated tier
• Web Jobs
• Backups of Web Site content
• Built-in web-based debugging tools (simple cmd/powershell debug console, process explorer, diagnostic tools like log streaming, etc.)

With the April 2014 and September 2014 rollouts, there are now some features common to both Web Apps and Web Roles (and Worker Roles), including:

• Staging+production slots
• Wildcard DNS, SSL certificates
• Visual Studio integration
• Traffic Manager support
• Virtual Network support

Here's a screengrab I took from the Web Sites gallery selection form:

I think Web Apps are a great way to get up and running quickly, where you can move from shared to reserved resources. Once you outgrow this, you can then move up to Web Roles and expand as you need.

Answer 2

EDIT 2014: For what it's worth, a lot of the info in this answer is no longer correct - see comments.

Add more to @David response:

With Windows Azure Websites, you don't have control over IIS or web Server because you are using a resources slice along with hundreds of other website on the same machine, you are sharing resources like any other so there is no control over IIS.

The big difference between a website shared and Azure web role is that a web-site is considered process bound while roles are VM bound.

Websites are stored on a content share which is accessible from all the "web servers" in the farm so there is no replication or anything like that required.

Windows Azure websites can not have their own host name instead they must use websitename.azurewebsites.net only and you sure can use CNAME setting in your DNS provider to route your request exactly same with previous Windows Azure Role only when they are running in reserved mode. CNAME setting is not supported for shared websites.