Why do you need a primary and a secondary access key for Windows Azure storage?

When you create a storage account on Windows Azure, you will notice in the developer portal that you receive both a primary and a secondary access key:

WindowsAzureStorage

Why do you need both a primary and a secondary access key for Windows Azure storage?  You can access the storage with only one key.  For example, in my ServiceConfiguration.cscfg file, I am using only the primary key to access the storage successfully:

 <ConfigurationSettings>
  <Setting name="DataConnectionString" value="DefaultEndpointsProtocol=https;AccountName=jenguestbook;AccountKey=g2bEcrOw4xN0sNcw/2hc16UrCl02mcr/zoQKgupYA3uN+x9RtVuyaKOGJ8/jwgUTI67nR4smkKLomdNBjDyRQw==" />
  <Setting name="DiagnosticsConnectionString" value="DefaultEndpointsProtocol=https;AccountName=jenguestbook;AccountKey=g2bEcrOw4xN0sNcw/2hc16UrCl02mcr/zoQKgupYA3uN+x9RtVuyaKOGJ8/jwgUTI67nR4smkKLomdNBjDyRQw==" />
</ConfigurationSettings>

(To try this scenario for yourself, you can download the Windows Azure Training Kit, which contains the Guest Book application that I’m using here.  Don’t forget to change the configuration settings for both the web and the worker role.)

So why do we have two access keys?  It’s for rolling key changes.  If you want to change the key (which is probably a good idea to do every once in a while in case it gets leaked somehow), you would have some downtime if there was only one key available.  The scenario would be to change the key (which would break your running app) and then update the configuration of your application (which would fix your app again, but there is downtime in between). 

With two keys, you can first update your configuration file to use the secondary key, then regenerate the primary key and update your application’s configuration to use that – with no downtime!