Microsoft副社長のScott Guthrie氏は，Windows Azureに関連する一連のアップデートを発表した。市場のリーダであるAWSとの差を埋めるだけでなく，一部の領域においてはそれを凌駕するものだ。新しいデータベースエクスポートサービスは，待望のバックアップ機能 – 価格的な疑問の余地はあるが – を実現する。そして最新のTraffic ManagerはAWSの同等機能を越えて，クロスリージョンのロードバランスエクスペリエンスを提供する。
Guthrie氏は自身のブログ記事で，新機能であるWindows Azure SQL Databaseのスケジュールバックアップを紹介した。
要望の多かった機能のひとつに，ユーザがSQLデータベースを，定期的かつすべて自動的に，ストレージアカウントにエクスポートできるようにする，というものがありました。本日からこれが，Windows Azureの組み込み機能として提供されます。SQL Databaseのトランザクション一貫性を持ったコピーを，任意のスケジュール定義に従って，自動化された定期的な方法で，ストレージアカウント内の.bacpacファイルにエクスポートすることが可能になります。
この新しいエクスポートサービスは，１日１回の頻度でスケジュールすることができる。エクスポートを保持する日数はユーザが指定する。エクスポートしたコピーから，新たなデータベースを生成することも可能だ。
Windows Azure SQL Databseは，SQL Serverデータベースのスケールとメンテナンスの方法を設定可能な，マネージドデータベースである。しかしながらこのサービスには，自動バックアップやリストアといった，高度な管理機能が欠落していた。手作業でデータベースをコピーする方法や，フォールトトレランス設計の際に参考となるリソースはこれまでもあったが，今回の新機能は，Windows Azureユーザが障害計画を定義する上で，いくらかの安心を与えてくれるだろう。しかしながら，このソリューション設計には，実は相当な費用が必要なのだ。Guthrie氏はアーキテクチャと，ユーザ課金の影響について説明している。
自動エクスポートが実行されると，Windows Azureは.bacpacファイルを生成する前に，まずデータベースを一時データベースにフルコピーします。エクスポートのトランザクション一貫性を保障するには，これが唯一の方法なのです(このデータベースは，エクスポートが完了すれば自動的に削除されます)。しかしその結果として，エクスポート実行時には，このデータベースコピーに対する課金が発生します。データベースの課金は日単位ですので，エクスポートを毎日行うとすると，理論的にはデータベースコストが２倍になる結果になります。ただし週単位の実行ならば，もっと少なくなります。
バックアッププロセスに必要な，この一時的データベースの料金に加えて，バックアップ用のストレージ費用や，ネットワーク帯域への課金(データベースがWindows Azureストレージアカウントとは違うリージョンに配置されていた場合)などもユーザが支払うことになる。Guthrie氏の記事へのコメントでも，この機能に関する費用の高さに対しては，"がっかりした"，"あんまりだ" など，不満の声があがっている。このサービスの価格モデルは，Amazon RDS(Relational Database Service)の提示しているものとは違う。Amazon RDS - 同じくマネージドデータベースのプラットフォーム - では，これよりもはるかに少ない費用で，もっと多彩なバックアップおよびリストア機能が提供されている。RDSデータベースには，デフォルトで有効なバックアップがあり，ポイント・イン・タイムのリストアがサポートされている。AWSでは，バックアップサービス自体には課金されない。また，バックアップが提供されたデータベースのサイズの100%より小さければ，ストレージにも課金されない。
さらにMicrosoftは，Windows Azure SQL Databaseの新しい"プレミアム"ティアも公開した。事前に用意されたリソースを使用することで，クラウドアプリケーションに予測可能なパフォーマンスを提供するものだ。Guthrie氏は，ユーザがこのティアを購入するおもな理由を３つ挙げた。
- 高ピークロード - 処理を実行する上で多くのCPU，メモリ，あるいはI/Oを要するアプリケーション。例えば，データベース操作で複数のCPUコアを長時間使用することが分かっていれば，そのアプリケーションはプレミアムデータベースを使用する候補になります。
- 大量のコンカレントリクエスト - データベースアプリケーションの中には，多数のコンカレントリクエストを扱うものがあります。一方で，通常のWeb EditionあるいはBusiness EditionのSQL Databaseには，コンカレントリクエストに最大180という制限があります。これより多くのコネクションを要するアプリケーションは，プレミアムデータベースを使用して，必要なリクエストの最大数を扱うのに適切な予約サイズを用意する必要があります。
- 予測可能なレイテンシ - アプリケーションによっては，最小限の時間内でのデータベースのレスポンスを保証する必要があります。広範なユーザオペレーションの一部として，あるストアドプロシージャがコールされた場合，その99%は20ミリ秒以下でコールから戻らなければならない，という要件があるかも知れません。この種のアプリケーションならば，コンピュータパワーの占有的な使用が保証されることで，プレミアムデータベースのメリットを享受できるでしょう。
現在プレビューモードでディスカウント提供されているこのサービスには，データベース予約サイズによって２種類が提供されている。P1サイズでは1CPUコア，150IOPS，8GBメモリ，最大2,000のアクティブセッションが提供される。より大きなP2サイズでは2CPUコア，300IOPS，16GBメモリ，最大4,000のアクティブセッションになる。Microsoftでは，ユーザがプレミアムデータベースを選択，および管理するための資料となるホワイトペーパも公開している。これに対してAmazon RDS内のSQL Serverデータベースでは，一貫したパフォーマンスが必要なデータベース用に，10,000までの "予測可能なIOPS" を持つことができる。
Microsoftが十分な優位性を確立した領域のひとつとして，地理的に分散した，高可用性のWebアプリケーションが実現可能な点がある。Windows Azure Traffic Manager - 登場から２年近くを経ているが，今回からWindows Azure Portal内で使用可能になった - は，AWS ELB(Elastic Load Balancing)よりも豊富な機能を備えた，高度なロードバランサを提供する。単一リージョン内のアベイラビリティゾーンを対象に，ラウンドロビン方式のロードバランシングのみをサポートしているELBとは異なり，Windows Azure Traffic Managerでは，任意のWindows Azureリージョンのクラウドサービスにトラフィックを振り向けることが可能だ。Microsoftはさらに，Traffic Managerプロファイルで指定可能な，Performance，Failover，Failoverという，３通りの異なるルーティング方法をサポートしている。Performance方式では，アプリケーションのホストに対して，地理的にもっとも近いロケーションにトラフィックを振り向ける。Failover方式はトラフィックをひとつのデータセンタにルートして，別のものをバックアップとして使用する。またRound Robin方式は，クラウドサービス全体に対して平均的にロードを分散する方法だ。公平のために言えば，AWSでもELBとAmazon Route 53(DNS)サービスを組み合わせることで，この機能全体を提供している。しかしMicrosoftはそれをシンプルにして，クラウドサービスの設定やそのトラフィックのルーティングに関して，単一でアクセスの容易なロケーションを提供しているのだ。
最後にMicrosoftは，先日発表したAuto Scaleサービスの改良についてもいくつか発表している。まず，Windows Azureのmobile-backend-as-a-serviceでオートスケーリングがサポートされるようになった。Guthrie氏は，Mobile Serviceがニーズに応じてスケールアップして，それが毎朝リセットされている点について説明した。
この機能を有効にすると，あなたのモバイルサービスに関わるAPIコールの日毎のやりとりを，Windows Azureが定期的にチェックします。それが設定したAPI許容量の90%を越える場合は，(別途設定したインスタンスの最大数に達するまで)ユニットを追加することによってスケールアップを計ります。
毎日の開始時刻(UTC)には，Windows Azureは設定済の最小値までスケールダウンします。これによって，実行中のMobile Serviceインスタンスの数を最小源にすることが可能になり - 費用を削減することが可能になりました。
Windows AzureのAuto Scaleサービスの提供する機能は，Windows Azure Service Bus Queuesのルールに深く関連している。キューがフルになった – メッセージバックログに対して，処理するサービスの数が少なすぎる – 場合，仮想マシンあるいはクラウドサービスを処理するシステムが自動的に立ち上がる仕組みだ。