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

Solution 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.

Solution 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.

Solution 3:

I've just posted a comprehensive blog post on this very subject at http://robdmoore.id.au/blog/2012/06/09/windows-azure-web-sites-vs-web-roles/.

An excerpt from my conclusion: If you need enormous scale, SSL, Asian or West US data centres, a non-standard configuration (of IIS, ports, diagnostics, security certs or start up scripts), RDP or cost-effective Worker Roles (combined with your Web Role) then you are going to have to stick to Web Roles for now.

Otherwise, Web Sites is a great option!

Solution 4:

Azure Web Role is like a virtual private host. You get a VM that acts as your web server, and you own that VM instance.

Azure Web Sites are like an elastic shared hosting service. You deploy your app to a web server that is not controlled by you and which also servers other users' sites. You can scale your site up and down (at some extra charge) to make it more elastic as your resource needs shift.