AZ-900 — Azure のコア サービス：練習問題90問

Step 1: 要件の整理 — 要求は高帯域幅、予測可能なパフォーマンス（レイテンシとスループットの安定）、高い SLA、そして専用回線の使用が可能である点です。これらはインターネット経由の接続では限界があるため、代替手段を検討する必要があります。

Step 2: サービスの照合 — ExpressRoute は Azure とオンプレミス間を専用回線（キャリアや交換ポイントを経由）で繋ぎ、インターネットを経由しないためトラフィックの予測可能性、セキュリティ要件、帯域幅の保証が得られます。ExpressRoute は高スループットの SKU を選べ、Microsoft の一部サービス（例: Azure Storage など）への最適化も可能です。さらに SLA や帯域幅オプションが明確で、企業のバックアップ・データセンター接続・高パフォーマンスアプリケーションに向いています。

Step 3: 選択理由の確定 — 専用回線で高帯域を確保し、インターネットの変動要因を排除した接続が必要なため ExpressRoute が最適です。Site-to-Site VPN は構築が容易でコストも低めですが、インターネットの影響を受けやすく SLA やパフォーマンスが限定的です。Point-to-Site は個別クライアント接続用であり企業の回線需要には不適合です。Azure Virtual WAN はネットワークの集中管理や複数拠点接続に有用ですが、専用回線で高帯域を保証するという点では ExpressRoute が一次選択です。 Trap: よくある誤解は「VPN でも十分高速なら問題ない」という点です。インターネット経由の VPN はベストエフォート型であり、需要の変動やパケットロスの影響で予測可能なパフォーマンスを保証できません。ミッションクリティカルなトラフィックには不向きです。 Why each wrong answer fails: - Site-to-Site VPN（IPsec over Internet）: 設定が容易で低コストですがトラフィックはインターネット経由となるため帯域幅・レイテンシの予測可能性が低く、SLA も限定的です。高帯域かつ安定性を求める要件には不十分です。 - Point-to-Site VPN: 個々のユーザーや開発者が Azure リソースに接続する用途に適した SSL/IPsec ベースの接続であり、大量の本番トラフィックや回線全体の接続には適していません。 - Azure Virtual WAN: 仮想 WAN は広域ネットワークの集約と管理を容易にしますが、専用回線（ExpressRoute）による高帯域・専用接続の提供そのものを代替するものではありません。Virtual WAN は接続トポロジーの管理で有用ですが、要件で求める「専用回線による高帯域・予測可能な性能」という点で ExpressRoute が最適です。

Step 1: 要件の明確化 — 要件は「非同期のタスク連携（メッセージング）」と「キー/属性ベースの NoSQL ストレージ」です。それぞれに特化したサービスを用いることでスケーラビリティと管理性が向上します。

Step 2: サービス特性の比較と適合性 — Azure Queue Storage は軽量でスケーラブルなメッセージングサービスで、ワーカーへの非同期タスク送信・受信に適しています。Azure Table Storage はキー/属性 (パーティションキー+行キー) による NoSQL ストレージで、スキーマレスかつ高速な読み書きを低コストで提供します。これらを組み合わせることで、Web アプリから Queue にジョブを投げ、バックエンドプロセスが Queue をポーリングして処理し、その処理結果や状態を Table Storage に保存する、といったアーキテクチャが良く使われます。

Step 3: 運用設計と利点 — Queue と Table はコスト効率が高く、スケールアウトが容易です。メッセージングの再試行や可視性タイムアウト、Table のパーティション設計などを考慮すれば高負荷にも耐える設計が可能です。Blob や Files は別の用途で使い分けます（後述）。 Trap: common misconception — 「Blob Storage はなんでも入れられるため、メッセージや軽量の状態ストレージとしても使えばよい」という誤解。Blob は大きなバイナリオブジェクト向けで、メッセージングや高速なキー/属性クエリには向きません。 Why each wrong answer fails: - Blob Storage（選択肢1）: Blob は非構造化データ（大きなファイル、バイナリオブジェクト、ログのアーカイブ等）に最適ですが、軽量メッセージングやスキーマレスなキー/属性の高速クエリ用途には適していません。メッセージの取り扱いや小さなレコードの高速検索は Queue/Table の方が適切です。 - Queue Storage（選択肢2、正解）: Queue は非同期ジョブ送信/受信に設計されたサービスで、要件の「非同期タスク連携」に適します。 - Table Storage（選択肢3、正解）: Table はキー/属性ベースの NoSQL ストレージで、スキーマを縛らないデータやメタデータの保存に適しているため、要件に合致します。 - File Storage（選択肢4）: Azure Files は SMB/NFS ファイル共有が必要なシナリオ向けで、メッセージングや NoSQL 的なキー/属性クエリには不向きです。ファイル共有をマウントする必要があるレガシーアプリ向けであり、本シナリオには適しません。 結論: 非同期処理のキューイングには Azure Queue Storage、キー/属性ベースの NoSQL 保存には Azure Table Storage を使うのが最適です。

Step 1: 要件整理 — セッション情報や設定情報は通常小さなレコードで、構造が頻繁に変わる可能性があり、スキーマレス（柔軟なスキーマ）が望まれる。高速な読み書きとコスト効率も重要です。

Step 2: サービスの特徴確認 — Azure Table Storage はスキーマレスな NoSQL のテーブル格納を提供し、パーティションキーと行キーによる高速なアクセス（スキャンよりも特定キーへの直接アクセス）を可能にします。サイズが小さく頻繁に読み書きされるデータ向けにコスト効率も良好です。Blob は大きなオブジェクト保存向け、Files はファイル共有、Queue はメッセージングであり、いずれもキー・値型の小さなレコードをスキーマレスで効率的に扱う目的には適していません。（注：Cosmos DB など他の NoSQL オプションもあるが、本問では Azure ストレージサービスに限定）

Step 3: 結論 — 要件に最も合致するのは Azure Table Storage。パーティションキー/行キーによりアクセスが速く、コストも低めでスキーマ変更の柔軟性があるため、セッションや設定情報の保存に向いています。 Trap: 「Table Storage は古いサービスだから避けるべき」と考える誤解がありますが、シンプルでコスト効率が重要なユースケースでは適切な選択肢です。一方でグローバル分散や厳密な SLA、複雑なクエリが必要であれば Cosmos DB を検討する必要があります。 Why each wrong answer fails: - Azure Blob Storage（選択肢 1）: 大きなバイナリデータやドキュメント向けで、個々のレコードをキー・値で高速に読み書きする用途には不向き。小さな構造化データの頻繁な読み書きにはオーバーヘッドが大きい。 - Azure Files（選択肢 3）: ファイル共有として設計されており、テーブル形式やキー・値アクセスのパターンに最適化されていない。ファイルシステム機能が必要なケース向け。 - Azure Queue Storage（選択肢 4）: メッセージングサービスであり、データ永続化のために使うことはできるが、クエリやキーによるランダムアクセス、データの更新やスキーマレスなテーブル格納要求には適していない。 結論: スキーマレスなキー・値データを低コストで高速に扱うニーズには Azure Table Storage が最適である。

Step 1: 概念の確認 リージョンはユーザーが Azure のリソースを配置するための地理的に定義された場所で、通常は複数のデータセンター（フォールト ドメイン）を含む集合です。これにより地理的な近接性やデータ主権の要件を満たします。

Step 2: リージョン ペアの役割 Azure は各リージョンを“リージョン ペア”として別のリージョンと組にしており、これによりプラットフォームの更新（メンテナンス）や大規模障害時の回復計画が調整されます。ペアリングは同一の地理的枠組み内で行われ、データのレプリケーション（例：GRS のようなジオ冗長ストレージ）や災害復旧の観点で優位性がある設計です。

Step 3: 可用性ゾーンの説明 可用性ゾーンは、単一リージョン内に存在する物理的に分離された複数の場所（独立電源・冷却・ネットワークを持つデータセンター）であり、ゾーン冗長配置によりリージョン内の障害から保護します。ゾーンはリージョン内でのフォールト分離を提供しますが、リージョンをまたいだ冗長性は提供しません。 Trap: よくある誤解 “可用性ゾーン＝リージョン間冗長”や“リージョン ペアで全サービスが自動フェイルオーバーする”と考えることが多いですが、実際には冗長化の方式や自動フェイルオーバーの挙動はサービスや設定（例えばペアリング、レプリケーション設定、フェイルオーバー構成）に依存します。 Why each wrong answer fails: 1) リージョンは地理的に分離された物理的な場所である — 正しい。リージョンは複数のデータセンターの集合体として定義されます。 2) リージョン ペアは同一地理で更新や障害対応を調整する目的でペア化されている — 正しい。Microsoft はリージョンペアを用いて更新の順序付けや復旧手順をサポートします。 3) 可用性ゾーンは複数リージョンに跨る冗長化単位である — 誤り。可用性ゾーンは必ず単一リージョン内の物理的に分離された場所を指し、リージョン間の冗長化は提供しません。リージョン間冗長化はリージョン ペアとサービスレベルの複製設定に依存します。 4) リージョン ペアによりすべてのサービスで自動的にフェイルオーバーが常時有効になる — 誤り。リージョン ペアはプラットフォームの保護や復旧作業を容易にしますが、サービスごとのレプリケーション設定や顧客が設定するフェイルオーバーの構成により挙動は異なります。たとえばストレージの GRS はプライマリからセカンダリへレプリケートしますが、自動で書き込み可能なフェイルオーバーが常に発生するわけではありません。

Step 1: シナリオ要件確認 — ログは「直近の運用ログ」で頻繁アクセスがあるため低レイテンシかつ高い取り出し頻度に対応するストレージが必要。さらに一部アプリは SMB を使うため、SMB 互換のファイル共有が必要。

Step 2: サービスの適合性評価 — Azure Blob Storage はアクセス階層（Hot/Cool/Archive）によりコストとパフォーマンスを最適化でき、頻繁アクセスには Hot を使うのが妥当。Azure Files は SMB（および NFS）をサポートする完全マネージドなファイル共有で、オンプレミスからのマウントや lift-and-shift に適している。Archive 階層は低頻度で長期保存するデータ向けで、復元に時間がかかるため即時アクセスには不適。Queue はメッセージング用でログ保管や SMB 共有には向かない。

Step 3: 実運用設計 — Blob Hot に保存したログは必要に応じて CDI やライフサイクルルールで古いログを Cool/Archive に移行。Azure Files は接続方式（オンプレミスAD統合、マウントの認証）や Azure File Sync を使ったキャッシュ/同期戦略を検討します。 Trap: 「すべてのファイルは Blob に放り込めばよい」と思い込む点。Blob は HTTP(S) ベースのオブジェクトストレージで SMB のネイティブマウントは提供していません。オンプレミスの既存アプリケーションが SMB を前提に動作する場合は Azure Files を選ぶ必要があります。 Why each wrong answer fails: - Azure Blob Storage（Archiveアクセス階層）: Archive はコストが非常に低い代わりに取り出し（復号・復元）に時間と追加コストが発生し、直近のログのような頻繁にアクセスするデータには適していません。 - Azure Queue Storage（Queue）: Queue はメッセージングサービスであり、ログの長期保管やファイル共有の代替にはなりません。SMB マウントを必要とするアプリケーションには無力です。 Why each correct answer is right: - Azure Blob Storage（Hotアクセス階層）: Hot 階層は頻繁にアクセスされるデータ向けに最適化されており、ログの即時解析やダッシュボード表示などに向いています。CDN と組み合わせたりライフサイクルを設定して古いログをアーカイブする設計も可能です。 - Azure Files（File、SMB サポート）: Azure Files は SMB プロトコルをネイティブサポートしており、オンプレミスのサーバーからそのままマウントして使用できるため、既存アプリケーションの移行コストを下げられます。 結論: 直近の頻繁アクセスログには Blob の Hot 階層、SMB による共有が必要なアプリには Azure Files を採用するのが最適です。ライフサイクルと認証・同期戦略を合わせて設計してください。

Step 1: 要件の整理 — レガシーアプリは特権ドライバーおよびカーネルモジュールを要求し、OS レベルでの完全な管理アクセス（例えばカーネル設定やドライバのインストール、デバイスの直接管理）が必要です。これらは抽象化されたマネージド環境では一般に許されません。

Step 2: サービス適合性の評価 — Azure Virtual Machines はユーザーに仮想マシンの OS 層へのフルアクセス権を提供するため、ドライバーインストールやカーネル調整が可能です。VM ならば、必要な特権ユーザー権限での操作とカスタムサポートが行えます。対照的に、App Service や Functions はプラットフォームによる抽象化が強く、OS への直接アクセスやカーネルモジュールの導入は一般に不可能です。AKS もノードに対する一定の制御はありますが、マネージド環境下ではカーネルのカスタマイズや特権ドライバーの扱いに制約があり、サポート対象外となるケースが多いです。

Step 3: 選択理由の確定 — 必要な OS レベルの操作を行えるのは VM のみであり、したがって Azure Virtual Machines を選択します。移行後は Azure のバックアップ、拡張ネットワーク、サイズ変更、リージョン配置などの管理機能も利用可能です。コスト面では常時稼働の VM は従量課金されますが、要件を満たすためには妥当です。 Trap: よくある誤解は「コンテナやPaaSを使えば管理が楽だからどんなアプリでも移行できる」という点です。PaaS やサーバーレスは管理負荷を下げますが、OS そのもののカスタマイズが必要なアプリには不適切です。 Why each wrong answer fails: - Azure App Service: App Service はプラットフォームが OS の多くを管理し、カーネルやドライバーへの直接アクセスは提供されません。特権ドライバーやカーネル拡張を必要とするアプリは App Service では動作しません。 - Azure Kubernetes Service（AKS）: AKS はコンテナオーケストレーション向けで、ノード（VM）に SSH で入れる場合もありますが、マネージドな制約やサポートポリシー上、カーネルの深い変更や特権ドライバーを導入することは通常推奨されません。また、コンテナ自体はホストカーネルを共有するため、ホストのカーネル変更が必要なアプリは適合しません。 - Azure Functions（サーバーレス）: Functions はアプリコードに焦点を当てるサーバーレス実行環境で、基盤 OS へのアクセスは完全に抽象化されています。したがって、カーネル拡張や特権ドライバーを必要とするアプリは動作しません。

Step 1: 要件を分解します。求められているのは「外部公開の .NET Web アプリ」「運用でOSやインフラ保守を最小化」「HTTPS 終端」「自動スケーリングが組み込みで利用可能」であり、これらは PaaS の特性に合致します。

Step 2: 各選択肢と要件を照合します。Azure App Service は Web アプリ向けに設計された PaaS で、プラットフォーム管理（OS パッチ適用、インフラの管理）、組み込みの HTTPS 証明書管理、オートスケール、デプロイスロットなどの Web 固有機能を提供します。したがって要件に最も合致します。

Step 3: リスクと運用コストを評価します。App Service を使えばチームはアプリケーション開発に集中でき、インフラ運用の負担を軽減できます。必要に応じて App Service Environment（専用環境）や容量プランを調整して SLA とコストをバランスできます。 Trap: 多くの受験者が「コンテナ＝管理要らず」と誤解します。確かにコンテナは柔軟ですが、ACI や AKS を選ぶとコンテナのライフサイクル、イメージ管理、場合によってはオーケストレーションの運用が必要になり、OS パッチの完全回避や Web 固有機能の簡易提供という点では App Service が上回ります。 Why each wrong answer fails: Azure Virtual Machines（IaaS）: VM は最も柔軟ですが、OS パッチ、セキュリティ更新、インフラ運用は利用者の責任です。HTTPS 終端や自動スケールは自分で設定・管理する必要があり、運用負担が増えます。 Azure Container Instances（ACI）: ACI は単一コンテナの素早い実行に向きますが、フルマネージドな Web アプリホスティングや継続的な HTTP/S トラフィックの管理、組み込みのスケーリング機能という点で App Service ほど機能が豊富ではありません。ACI は主にバッチや一時的なコンテナに適します。 Azure Kubernetes Service（AKS）: AKS は大規模なコンテナオーケストレーションに最適で高い柔軟性を提供しますが、コントロールプレーンの管理は一部マネージドでも、クラスタ運用、ポッド管理、ネットワーク、Ingress 設定、アップグレード等の運用作業が必要です。OS レベルやランタイムに関する管理負担は App Service より高くなります。 総括: 要件（低運用負荷、組み込みの HTTPS と自動スケール、.NET Web アプリ）に対して最も適切なのは Azure App Service であり、よって選択肢の中で正解となります。

Step 1: 要件は「OS 管理/パッチをしたくない」「CI/CD を使いたい」「自動スケールが必要」「ウェブアプリをホストする」という点です。これらは PaaS 型のマネージドサービスが最適です。

Step 2: Azure App Service は Web Apps を PaaS として提供し、基盤 OS のパッチ適用やインフラ管理を Microsoft が代行します。GitHub Actions、Azure DevOps などの CI/CD と統合でき、デプロイメントスロットを使ったブルー/グリーンやカナリアデプロイが可能です。自動スケール（水平スケール）やスケジュールに基づくスケール設定も簡単に行えます。App Service はランタイム（.NET、Node.js、Java、Python など）に最適化された機能を備えており、典型的なウェブアプリ運用の運用負荷を大きく軽減します。

Step 3: 実運用では、App Service のプラン選定（価格やインスタンス数）、スロットを利用した安全なデプロイ、診断ログ/Application Insights の組み込みを検討します。コンテナ化されたアプリも App Service 上で動かすことが可能ですが、複雑なコンテナオーケストレーションが必要なら AKS を検討します。 Trap: 「コンテナなら何でも管理不要」と思い込む人がいますが、AKS のようなフルマネージドとはいえクラスター運用（ノードのアップデートやクラスタ設定）は必要になるため、完全に OS 管理を放棄できるわけではありません。 Why each wrong answer fails: - Virtual Machines (VM): VM は IaaS であり、OS のパッチ管理、セキュリティ更新、スケーリングの管理がユーザー側の責任です。完全に運用負荷を排除したい要件には合いません。 - Azure Kubernetes Service (AKS): AKS はコンテナオーケストレーションのための優れたサービスですが、クラスタやノードの構成・管理、オーケストレーションの知識と運用が必要です。完全に OS レベルの管理を避けたい、かつシンプルなウェブアプリ運用をしたい場合は過剰です。 - Azure Container Instances (ACI): ACI はコンテナをサーバーレスで起動できるため管理は少ないですが、長期稼働のウェブアプリに対してはスケール制御や CI/CD 統合、SSL/TLS 組み込み、デプロイメントスロットといった App Service のウェブアプリ向け運用機能が不足します。軽量なジョブや一時的なコンテナ実行には向きますが、フル機能のウェブアプリ運用には App Service がより適しています。 まとめ: OS 管理を避けつつ、CI/CD 統合や自動スケール、デプロイメントスロットなどウェブアプリ運用に必要な機能を重視するなら、App Service が最も適切な選択です。

Step 1: 要件の整理 — レガシーアプリがカーネルレベルのドライバーやカスタム OS 設定に依存している点、そしてファイルは複数サーバーから SMB で共有される点を確認。

Step 2: サービス特性の確認 — Virtual Machines（VM）はフル制御の仮想マシン環境を提供し、カーネルに近いレベルでの設定やカスタムドライバーの導入が必要なワークロードに対応できる。一方、Azure Files は SMB/NFS をサポートするマネージドなファイル共有を提供し、複数の VM から同時にマウントして共有ファイルにアクセスできる。App Service は PaaS で管理は楽だが OS レベルのカスタマイズはできず、多くのレガシー要件には合わない。Blob Storage はオブジェクトストレージで SMB 共有を提供しない（ただし File Sync 等で代替的な構成はあるが、SMB の直接共有用途には Azure Files が適する）。

Step 3: 判断 — カーネルやドライバーに依存するアプリは VM へ移行してフル制御を確保し、共有ファイルは Azure Files を使って複数サーバーからの SMB アクセスを実現するのが最も合理的。これにより移行のリスクを下げつつ、クラウドのマネージドサービスの利点も活用できる。 Trap: 「すべて App Service に移せば管理が楽」という考え。App Service は多くのモダン Web ワークロードに優れるが、カーネルやドライバーなど低レベル要件を持つレガシーには不適。 Why each wrong answer fails: - Virtual Machines（正解）: フル OS 制御が可能で、カーネルやドライバーのカスタマイズが必要なレガシー環境に最適。 - App Service（Web Apps）: PaaS のため OS レベルの変更が制限される。カーネルモジュールやカスタムドライバーの導入が出来ないため、今回の要件には不向き。 - Blob Storage: 大きなオブジェクトストレージとしては有効だが SMB 共有を直接提供しないため、複数サーバーから SMB マウントする要件には合わない。 - File Storage（Azure Files）（正解）: SMB/NFS をサポートし、複数の VM から同時にマウントして共有ファイルを扱えるため、移行のファイル共有要件を満たす。 結論としては、レガシー要件を満たすために VM を利用し、共有ファイルは Azure Files に移行するのが最適な組み合わせです。

Step 1: 要件の明確化 — 要件は『素早く』『スケーラブルに』『OS のパッチやインフラ管理を避ける』ことです。これは PaaS（Platform as a Service）モデルの典型的なユースケースです。PaaS はアプリケーションのコードと設定に集中できるよう OS やミドルウェアの管理をクラウドプロバイダーが行います。

Step 2: サービス比較 — Azure には複数のコンピューティングサービスがあります。Azure App Service は Web アプリや API 向けの完全マネージド PaaS で、自動スケール、デプロイメントスロット、継続的デプロイ、自動パッチ適用が組み込まれています。AKS（Kubernetes）はコンテナオーケストレーションをフルサポートしますが、クラスタの管理（ノードの OS パッチやクラスタ設定）やコンテナ運用の複雑さが残ります。Virtual Machines は IaaS で OS 管理がユーザー責任です。ACI はシンプルにコンテナを起動できるマネージドサービスですが、Web アプリ向けの統合機能（簡易な認証、デプロイパイプライン、スロットなど）は App Service の方が充実しています。

Step 3: 選択と実運用の観点 — 要件通りなら Azure App Service が適切です。App Service により OS のセキュリティパッチ、ランタイムの更新、インフラ監視は Azure により提供され、デベロッパはアプリケーションロジックと設定に集中できます。スケーリング要件が非常に複雑で細かいコンテナオーケストレーションが必要な場合は AKS を検討しますが、通常の Web アプリであれば App Service がコスト・管理面で有利です。 Trap: ACI が『コンテナを管理しないので楽』という印象で App Service と混同されがちですが、ACI は単一/短命のコンテナ実行に優れますが、Web アプリ用の PaaS 機能や DevOps 統合、接続性などは App Service の方が手間が少ないです。 Why each wrong answer fails: - オプション 2（AKS）: AKS はコンテナオーケストレーションのため強力ですが、クラスタ管理やノードの OS パッチ適用、Kubernetes の運用知識が必要です。『できるだけ OS 管理を避けたい』という要件にはマッチしません。 - オプション 3（Virtual Machines）: VM は IaaS であり、OS やセキュリティパッチ、インフラの運用はユーザーが責任を持ちます。管理負荷が高く、要件に不適合です。 - オプション 4（ACI）: ACI は管理不要でコンテナを起動できますが、Web アプリ向けの高度な PaaS 機能（自動スロット、統合された認証、簡易なデプロイパイプライン等）は App Service に比べて限定的です。短期/単一コンテナやバッチには有利ですが、一般的な Web アプリ運用には App Service がより適しています。 総括: OS やインフラ管理の負担を最小にして Web アプリを素早く展開するには Azure App Service が最も適切な選択です。要件によっては ACI や AKS を検討しますが、それぞれ運用負荷や機能セットが異なります。

Step 1: 要件の確認 — お客様は「専用線で接続したい」「Azure を経由せず」「最高のスループットと信頼性を求める」という要件を持っています。ここでのキーワードは「専用線」「高スループット」「信頼性」です。

Step 2: 各接続方式の比較 — サイト間 VPN（IPsec）はインターネット経由で暗号化トンネルを張る方式でコスト効率が高いが、インターネットの影響を受けるため帯域幅や遅延、信頼性が変動しやすい。ExpressRoute は通信事業者やパートナーを通じて Azure とオンプレミスを専用ネットワークで接続する方式で、インターネットを経由せず安定した高帯域・低遅延・高信頼性を提供する。VNet ピアリングは Azure 内の仮想ネットワーク同士を接続する機能であり、オンプレミスとの接続手段ではない。Azure Bastion はセキュアなリモート管理境界に関するサービスであり、ネットワーク接続手段ではない。

Step 3: 推奨の根拠 — 要件に合致するのは ExpressRoute です。ExpressRoute は 1 Gbps, 10 Gbps 等の専用帯域をサポートし、SLAs が高く、大きなデータ転送やハイブリッド構成に適しています。法規制やセキュリティ要件でインターネットを回避する必要がある場合にも有効です。 Trap: よくある間違いは「VPN を複数台で冗長化すれば ExpressRoute と同等の信頼性が得られる」と思うことです。しかしインターネット経由である限り帯域変動やセキュリティリスクの面で差があります。 Why each wrong answer fails: - サイト間 VPN（IPsec VPN）をインターネット経由で構成する: VPN は暗号化された通信を提供するが、インターネット回線に依存するため最高のスループットや常に安定した低遅延を保証できない。要件の「専用線、最高のスループット、信頼性」には不十分。 - VNet ピアリングを用いて仮想ネットワークを接続する: VNet ピアリングは Azure 内の VNet 間の接続であり、オンプレミスとの物理的専用接続を提供しないため当該要件を満たさない。 - Azure Bastion を使ってリモート管理する: Azure Bastion は VM への安全な RDP/SSH 接続を提供するマネージドサービスであり、拠点間通信の専用線や高スループット接続の機能ではない。 以上から、要件を満たす最良の選択肢は ExpressRoute です。

Step 1: 要件の確認 — ログやセッション情報のようにスキーマが固定化されておらず、キーや属性による高速なクエリ（パーティション/行キーなど）が必要で、かつコストを抑えたいという要件です。これらは NoSQL のキー/属性ストアが得意とする領域です。

Step 2: サービスの比較 — Azure Table Storage は Azure の NoSQL キー/属性型のストレージで、スキーマレスなデータモデル、パーティションキーと行キーによる効率的なクエリ、高いスケーラビリティと低コストを提供します。これにより大量のログやセッション情報の保存と検索が効率的に行えます。

Step 3: 結論 — スキーマレスなログ・セッション情報の格納と高速なキー検索を目的とするなら、Azure Table Storage が最も適切です。必要に応じて Cosmos DB Table API のようなより高度な SLA/機能を検討することも可能です。 Trap: よくある間違いは「Blob Storage に JSON をそのまま保存すればよい」と考えることです。Blob は大きなオブジェクトの保存には向きますが、属性に基づく高速なクエリやパーティションによるアクセス最適化は Table Storage の方が効率的です。 Why each wrong answer fails: - Azure Blob Storage: 非構造化オブジェクトの格納には適していますが、属性ベースの高速検索やスキーマレスなキー/属性ストアとしてのクエリ性能は提供していません。ログをファイル単位で保存することはできますが、個々のレコードに対する低レイテンシ検索には不向きです。 - Azure Files: ファイル共有を目的としたサービスで、表形式のキー/属性ストアや高速なクエリ機能を提供しません。ファイルシステムとしてマウントして使う用途に適していますが、NoSQL データ格納には適合しません。 - Azure Queue Storage: メッセージング用キューであり、データの検索や属性ベースのクエリという目的には向きません。キューは一時的なメッセージ保管に最適化されており、ログやセッションの永続的・効率的検索用途には不適です。 したがって、ログやセッションのようなスキーマレスなキー/属性データの格納と高速検索には Azure Table Storage が最適となります。