Microsoft Certified: Azure Solutions Architect Expert（AZ−305）の受験にあたり類似している機能や自分が迷ったことのメモです。学習時に不明だったことを記載しているため殴り書きのような形で2026年2月時点での整理ですが誰かの参考になれば幸いです。
記載ミスや認識に誤りなどございましたらコメントお願いいたします。
※投稿者は2月に試験を受けてギリギリですが合格することができました。
プライベートIP
各サブネットの先頭4つと最後の1つは（合計5つ）がAzureによって予約されている。
10.0.0.0/16 サブネットでは、予約済みアドレスは 10.0.0.0-10.0.0.3 と 10.0.255.255。
ゲートウェイサブネット
GatewaySubnetという名前のサブネットが必要。/29以上であれば作成はできるが、構成の要件によってはipが不足するので、/27以上が推奨されている。
なぜ「GatewaySubnet」という名前じゃないとダメなのか？
Azureの仮想ネットワーク（VNet）において、この名前は特別な予約語。
仕組み: Azureのシステムは、この名前のサブネットを見つけると「ここは VPN Gateway や ExpressRoute Gateway という『特殊なルーター（仮想マシン）』を配置するための専用エリアだ」と認識する。
制約:上記からこのサブネットには自分のVM（仮想マシン）などを配置することはできない。
なぜ /27（32個のIP）以上が推奨されるのか？（IPが不足する理由）
①Azureの予約IP
どのサブネットも、最初の3つと最後の1つの計 5つのIP はAzureが管理用に予約して使えない。
/29（8個）の場合、使えるのは 実質3個だけ。
②ゲートウェイの冗長化
高可用性（Active-Activeなど）を組むと、複数のIPを消費する。
③将来の拡張
後から「ExpressRouteも追加したい」「ゲートウェイのサイズを上げたい」となったとき、IPが足りないと一度ゲートウェイを削除して作り直すという大惨事になる。
試験でのポイント：「将来の拡張性」や「共存（VPNとExpressRouteの両方）」というキーワードが出たら、迷わず /27 以上 を選ぶ。
サイト間VPN接続
オンプレミスとサイト間VPNで接続する場合、オンプレミスのネットワークアドレスと重複させることはできない。
負荷分散オプションの整理
| 1 | 2 | 3 | 4 |
|---|---|---|---|
| Azure Front Door | Traffic Manager | Application Gateway | Azure Load Balancer |
| グローバル | グローバル | リージョン | リージョン |
| HTTP(S) | 非HTTP(S) | HTTP(S) | 非HTTP(S) |
| Web Application Firewall(WAF)、レート制限、SSL/TLSオフロード(TLS終端）、URLパスベースのルーティング、高速フェールオーバー、コンテンツキャッシュ（CDN）などのLayer7機能を提供。 | DNSベースのトラフィックロードバランサー。負荷分散はドメインレベルでのみ。DNSクエリに対する様々なルーティング方法 | Web Application Firewall(WAF)、SSL/TLSオフロード(TLS終端）、URLパスベースのルーティング、Cookieベースのセッションアフィニティ機能 | UDP,TCPによる負荷分散、超低遅延と高スループットのレイヤー4負荷分散サービス。 |
Azure Cache for Redis とAzure CDN
Azure Cache for Redisはユーザのセッション情報や即時性が求められる更新データを、キャッシュすることでパフォーマンスを向上できる。
主なメリット：DBの負荷軽減、応答の高速化
キャッシュ場所：アプリサーバーと同じリージョン内
Azure CDNは静的コンテンツ（JavaScript、css、画像ファイル）をキャッシュする。
主なメリット：ネットワーク遅延の解消、帯域節約
キャッシュ場所：世界中のエッジ（拠点）
Azure Cache for Redis は「サーバーの作業」を楽にする。
Azure CDN は「ユーザーの待ち時間」を減らす。
シナリオ：大規模な通販サイト（ECサイト）
Azure CDN を使う場所:
商品の画像、サイトのロゴ、CSS、商品紹介の紹介動画。
世界中のユーザーが、自分の近くの拠点からこれらをダウンロードして、サイトがパッと表示されるようにする。
Azure Cache for Redis を使う場所:
ユーザーの「ログイン状態（セッション）」。
「売れ筋ランキング」の計算結果（毎回DBで集計すると重いので）。
ショッピングカートの中身。
試験での考え方
「DB の負荷が高い」「クエリが遅い」 ＋ 「高速化したい」 👉 Azure Cache for Redis
「Web の画像や動画の表示が遅い」 ＋ 「ユーザーが世界中にいる」 👉 Azure CDN
Azure Data Lake Storage
Azure に組み込まれた、包括的でスケーラブル、かつコスト効率に優れたビッグデータ分析用のデータレイクソリューション。非構造化データ用に最適化されており、GRSを提供しているため低コスト。
Azure Cosmos DB はJSONデータとフェールオーバー用に最適化されているが、Data Lake Storage よりもはるかにコストがかかるためコスト最小化の観点だとAzure Data Lake Storageが選ばれる。
Azure Databricks
Apache Sparkに基づくビックデータ及び機械学習のプラットフォーム。
クラスターで「Azure Data Lake Storage 資格情報（クレデンシャル）パススルー」を有効にすると、そのクラスターで実行するコマンドは、ストレージにアクセスするためのサービス プリンシパルを構成しなくても（Microsoft EntraのIDを使って）、Azure Data Lake Storage のデータの読み取りと書き込みができるようになる。
Azure Databricksの価格レベルには、Standard とPremium があり、「Azure Data Lake Storage 資格情報（クレデンシャル）パススルー」を使用するには Premium プランが必要。
用語解説
Apache Spark ビックデータと機械学習のための非常に高速な分散処理フレームワーク
Azure API Management
バックエンドにあるAPIを安全に公開するための中継（ゲートウェイ）の役割があり、そのほか以下の機能を提供する。
① セキュリティと認証 (Security)
APIキーの管理: 「合言葉」を知っている人だけ通す。
OAuth 2.0 / OpenID Connect: Microsoft Entra ID（旧 Azure AD）などの認証を組み込める。
IP制限: 特定の会社以外からのアクセスを弾く。
② 流量制限 (Throttling / Rate Limiting)
「1分間に100回まで」といった制限をかけ、バックエンドのサーバーがパンクするのを防ぐ。
プラン作成: 「無料プランは月1,000回まで、有料プランは無制限」といった、APIのサブスクリプション販売が可能になる。
③ 変換 (Transformation)
古いものを新しく: バックエンドが古い「XML」形式でも、APIMが窓口で「JSON」に変換してスマートに見せることができる。
ヘッダーの書き換え: 認証情報を隠したり、URLを書き換えたりして、バックエンドの構造を外部に悟られないようにする。
④ キャッシュ (Caching)
同じリクエストが来たら、バックエンドへ聞きに行かず、APIMが回答を返す。これによりレスポンスが爆速になり、サーバーの負荷も減る。
Azure Web App for Containers
Azure App Service上でDockerコンテナ化したWebアプリケーションを、サーバーの構築・管理なしに展開・実行できるフルマネージドのPaaS。
主な特徴とメリット
①Dockerイメージのデプロイ: Dockerfileを管理するだけで、容易にコンテナアプリを動かせる。
②自動化された運用: OSのパッチ適用や容量管理が不要で、自動スケーリングに対応。
③App Service機能の利用: Azure App Service の利点である診断、ステージング環境、スロット機能、カスタムドメインなどをそのまま活用可能。
④多様なイメージソース: Azure Container Registry (ACR)、Docker Hub、およびプライベートリポジトリからのコンテナイメージをサポート。
⑤使いやすいURL: 既定のサブドメイン (*.azurewebsites.net) が自動付与される。
フルマネージドのPaaS。
Azure Container Instancesとの違い
| 機能 | Azure Container Instances (ACI) | Azure Web App for Containers |
|---|---|---|
| 主な用途 | 短時間のタスク、バッチ、シンプルな実行 | 本格的な Web サイト / API |
| 負荷分散 | なし（自分で LB を置く必要あり） | 標準装備（勝手にやってくれる） |
| HTTPS (TLS) | なし（自分で証明書を入れる） | マネージド TLS（ボタン1つで無料発行） |
| ドメイン | azurecontainer.io のみ | カスタムドメイン対応 |
| スロット | なし（いきなり本番） | デプロイスロット（テスト環境から一瞬で本番切替） |
便利なAzure Web App for Containersだが、以下の場合は別のサービスを検討する。
「1つのURLで、何百ものマイクロサービスを連携させたい」
👉 Azure Container Apps (KEDAによるスケーリングやDaprの利用が可能)
「コンテナ同士の複雑なネットワーク制御（Service Mesh）が必要」
👉 Azure Kubernetes Service (AKS)
設計者の視点：いつ Web App を選ぶ？
もし「Dockerコンテナで作った Web サイトを、一番ラクに、かつ安全に一般公開したい」と言われたら、Web App for Containers が最適解。
手間をかけたくない: インフラ（OSやネットワーク）を触りたくない。
セキュリティが大事: 証明書の管理を忘れて「サイトが見られなくなる」トラブルを防ぎたい。
スケーリングしたい: セール時に一瞬でサーバーを増やしたい。
まとめ
Azure Container Instances は「箱（コンテナ）を置くだけ」
Web App for Containers は「箱をWebサイトとして立派に運営するためのフルセット」
Azure Logic Apps
Azure Logic Apps→オンプレミスのデータへアクセスするためには最初にオンプレミスのサーバーに「オンプレミス データ ゲートウェイ」をインストールした後にAzureで「オンプレミス データ ゲートウェイ」というリソースを作成する。接続ゲートウェイと表現される場合もある。
Azure Cosmos DB
マルチモデル データベース。
NoSQL、MongoDB、Cassandra、Table、Gremlin、PostgreSQL の API を提供する。
グローバル分散と自動フェールオーバーも備わっている。
データベースのマルチモデルの性質により、移行時に重要なコードの再開発を行う必要がなくなる。
また、最終的な整合性がある読み取りおよび書き込みレプリカを提供し、非リレーショナルデータを格納できる。
Azure Cosmos DBをAzure Synapse Analyticsに接続するには、まず、Azure Cosmos DBアカウントでAzure Synapse Linkを有効にして、それらの間の接続を有効にする。
Cosmos DB 5段階の整合性の比較
| キーワード（問題文に出る言葉） | 選ぶべきレベル | 理由 |
|---|---|---|
| 「絶対に最新」「一分一秒の狂いも許さない」 | 厳密 | 読み取り時に必ず最新の書き込みを保証する |
| 「ラグ（遅延）を一定の範囲内に抑えたい」 | 有界整合性制約 | 「○分遅れまで」「○件前まで」と許容範囲を数値で指定できる |
| 「ユーザーが自分の変更をすぐ確認できる」 | セッション | 自分が書いたデータに対してのみ一貫性を保証する |
| 「更新の順番（1→2→3）が壊れては困る」 | 一貫性のあるプレフィックス | データの新しさは保証しないが、順序だけは死守する |
| 「正確さより速度」「多少の表示ズレはOK」 | 最終的 | 最も制約が緩く、スループット（処理能力）が最大 |
最も強力なのは「厳密（強固）」だが、複数のリージョンにまたがる構成の場合、書き込み待機時間のSLAは対象外となるため「有界整合性制約」が最も強力な整合性レベルとなる。
読み取り待機時間は「厳密（強固）」が最も強力な整合性レベル。
用語解説
※非リレーショナルデータ
リレーショナルデータベースのような固定テーブル構造を持たず、ドキュメント、キーバリュー、グラフなどで柔軟にデータを管理する方式。高スケーラビリティと高速な処理が特徴で、非構造化データや大規模データに適している。
JSON（ジェイソン）という形式で「{ "名前": "田中", "趣味": "キャンプ" }」のように、データの形をその場で変えられ、柔軟。
※読み取りおよび書き込みレプリカ
世界中にデータのコピー（分身）を置いて、どこでも読み書きできる」仕組み。
レプリカ: データの「コピー」のこと。
読み取りレプリカ: 日本のユーザーは日本のコピーを読み、アメリカのユーザーはアメリカのコピーを読む。これで「遠いから遅い」がなくなる。
書き込みレプリカ: 普通のDBは「書き込みは1箇所だけ」だが、Cosmos DBは世界中どこでも書き込みOKにできる。
Azure Cosmos DB Data Migration Tool
Azure Cosmos DB Data Migration Toolは、さまざまなソースからAzure Cosmos DBにデータをインポートするオープンソースのソリューション。
「今まで使っていたデータベースから、Cosmos DBへデータを移したい」という時に使える。
最大の特徴は、ソース（移行元）の豊富さ。
・Cosmos DB NoSQL
・JSON
・モンゴDB
・Azure テーブル API
・SQL サーバー
※このツールで「できないこと」
オンライン移行（同期）: このツールは「今あるデータをコピーする」だけ。コピー中に増えた新しいデータを追いかけて同期し続ける機能はない。
ダウンタイムゼロ: 同期機能がないため、移行中はアプリを止める（オフラインにする）必要がある。
Azure Migrate
オンプレミスや他社クラウドからAzureへの移行を支援してくれるサービス
Azure Database Migration Service (DMS)
オンプレミスのSQLServerをAzure SQL Managed Instance（SQL VM、SQL Database）へ移行できる。
これは「サービス」となり、移行のジョブを作成すれば、複数のデータベースを一つのプロジェクトとしてまとめて、裏側で一気に（並列に）移行できる。
| 移行シナリオ | 移行モード |
|---|---|
| SOL Server → Azure SQL Managed instance | オンライン/オフライン |
| SOL Server → Azure Virtual Machines 上の SQL Server | オンライン/オフライン |
| SOL Server → Azure SQL Database（プレビュー） | オフライン |
Data Migration Assistant（DMA）
Data Migration Assistant（DMA）は、オンプレミスのSQLServerの移行をサポートするツールで、互換性の問題を検出する「評価（アセスメント）」と、スキーマやデータなどをターゲットサーバに「移行」する2つの機能がある。
基本的にはデスクトップアプリ。1つ、または数個のデータベースを「手元で操作して」移すのには向いている。
Azure SQL Managed Instanceへのデータベース移行はサポートされていない。
次のような移行パターンで利用できる。
・SQLServer → 新しいバージョンのSQLServer（アップグレード）
・SQLServer → Azure VMのSQLServer
・SQLServer → Azure SQL Database
SQL Server Migration Assistant (SSMA)
SQL Server Migration Assistant (SSMA)は、SQLServer以外（Access、MySQL、Oracleなど）からSQL Serverへの移行をサポートするツール
DMA・DMS・SSMAの整理
| 状況 | 最適なツール |
|---|---|
| まず互換性を調べたい「評価（アセスメント）」 | DMA |
| 数個のDBをとりあえず移したい「移行」 | DMA |
| 50個など大量の DB を一気に移したい | DMS |
| 移行中のダウンタイムをゼロにしたい | DMS (オンラインモード) |
| SQLServer以外（Access、MySQL、Oracleなど）の別製品から移したい | SSMA |
Azure SQL Database
Azure SQL Database ではSQL Server の空間機能がサポートされていて、一般的な管理オーバーヘッドが最小限に抑えられる。
Azure SQL Managed Instanceでは管理オーバーヘッドが Azure SQL Database より高く、空間機能がサポートされている。
用語解説
※空間機能
図上の位置や図形の形を、データとして保存・計算するための機能
DBの中で一瞬で計算して距離を測ったり面積を出したりできる。（すごい）
活用例：
物流アプリ→トラックの現在地と配送先の位置関係を管理。
不動産・店舗検索→地図上で「この範囲内の物件を表示」といった検索を実現。
※管理オーバーヘッド
本来の仕事（アプリ開発やデータ分析）以外にかかる、運用・管理の手間やコスト
Azure SQL Managed Instance
共通言語ランタイム（CLR: Common Language Runtime）はSQL Server 2005以降で導入された機能であり、Visual Basic や C# を含む任意の.NET Framework言語を使用して、ストアドプロシージャ、ユーザー定義関数などを記述できる仕組み。
共通言語ランタイム（CLR: Common Language Runtime）はAzure SQL Database ではサポートされていない。
Azure SQL Databaseではシステムによって開始される自動バックアップのみサポートされているが、Azure SQL Managed InstanceではBACKUPコマンドによる手動バックアップを取得することが可能。
モデル比較表
| 種類 | 購入モデル | サービスレベル | コンピューティングレベル | レプリカ | ゾーン冗長構成 | 最大ストレージサイズ | mdf/ldfの場所 |
|---|---|---|---|---|---|---|---|
| SQL Database | 仮想コア | General Purpose | プロビジョニング済み | × | プレビュー | 4TiB | Azure Storage |
| サーバレス | × | プレビュー | 4TiB | ||||
| Hyperscale | - | ⚪︎ | ⚪︎ | 100TiB | |||
| Business Critical | - | ⚪︎ | ⚪︎ | 4TiB | ローカルSSD | ||
| DTU | Basic | - | × | × | 2GiB | Azure Storage | |
| Standard | - | × | × | 1TiB | |||
| Premium | - | ⚪︎ | ⚪︎ | 4TiB | |||
| SQL Managed Instance | - | Gneral Purpose | - | × | × | 16TiB | Azure Storage |
| Business Critical | - | ⚪︎ | プレビュー | 4TiB | ローカルSSD |
※I/O レイテンシーを最小限に抑える場合は高速なローカルSSDが使われている、Premium、またはBusiness Criticalを選ぶ。
※複数のDBを移行する場合はエラスティックプールを使用して複数のDBで共有することでコストを節約できる。
| 比較項目 | Azure 仮想マシン (VM) 上の SQL Server | Azure SQL Managed Instance (MI) | Azure SQL Database |
|---|---|---|---|
| カテゴリ | IaaS | PaaS (最高級) | PaaS (標準) |
| 管理の手間 | 最大 (OSの更新が必要) | 低い (OS管理不要) | 最小 (DBのみ管理) |
| 互換性 | 100% (オンプレと同じ) | ほぼ100% | 一部制限あり |
| インスタンス機能 | すべて使用可能 | 使用可能 (SQL Agent等) | なし (DB単体) |
| 主な使いどころ | OSレベルの設定が必要・超レガシー | 大規模な移行、複数DB連携 | 新規アプリ開発、SaaS開発 |
Azure SQL Databaseを選ぶときのキーワード
・「コスト最小化」「サーバーレス (Serverless)」-Azure SQL Managed Instanceにはサーバーレス（一時停止）プランがない。
・「100 TB の巨大データ (Hyperscale)」-超巨大な拡張性が必要なら SQL Database の Hyperscale。
・「モダンな SaaS アプリの開発」-インスタンスの概念に縛られず、DB 単位でスケールさせたい場合。
Azure SQL Managed Instanceを選ぶときのキーワード
・「SQL Server エージェント (SQL Agent)」が必要-SQL DB にはエージェントがいない。
・「複数データベースにまたがるクエリ (Cross-database queries)」-同じインスタンス内の DB 同士で JOIN したい。
・「最小限の変更でオンプレミスから移行したい」-アプリのコードを書き換えたくない（100%の互換性が欲しい）場合。
・「リンクサーバー (Linked Servers)」を使いたい-他のサーバーからデータを取ってくる機能は、MI しか持っていません。
例えで比較
Azure 仮想マシン (VM) 上の SQL Server(IaaS)
例え：一戸建て（持ち家）
特徴： 土地（OS）も建物（SQL本体）も全部自分のもの。壁を壊そうが、屋根を塗り替えようが自由。
大変なこと： 掃除、修繕（パッチ適用）、防犯（セキュリティ）も全部自分でやる。
Azure SQL Managed Instance(PaaS)
例え：分譲マンション
特徴： 部屋の中（SQLの機能）は一戸建て並みに自由。でも、共用部や建物の構造（OSやインフラ）は管理会社（Microsoft）がやってくれる。
いいとこ取り： オンプレミスのSQL Serverと機能がほぼ同じなので、**「古いアプリをそのまま移したい」**時に最強。
Azure SQL Database(PaaS)
例え：ホテル（またはシェアハウス）
特徴： 部屋のレイアウト（データベース単体）は使えるが、建物の構造をいじることはできない。
いいとこ取り： 掃除から修繕まで全部お任せ。使った分だけ払えばいい。最新のAI機能などもすぐ使える。
ストレージの視点で見る 3 つの構成
Always On フェールオーバー クラスター インスタンス (FCI)
ストレージ: 「共有ストレージ」が必須。
仕組み: 2台のサーバーが、1つの大きな外付けHDD（Azure 共有ディスクなど）を見合っている状態。
難点: Azure上で「共有ディスク」を正しく設定するのは手間がかかり、管理も大変です。
Always On 可用性グループ (AG)
ストレージ: 「共有ストレージ」は不要。
仕組み: それぞれのサーバーが自分のHDDを持っていて、ネットワーク経由でデータをコピーし合います。
利点: 共有ストレージがいらない分、FCIよりは柔軟ですが、Windowsクラスター（WSFC）の設定は依然として必要です。
ログ配布 (Log Shipping)
ストレージ: 「共有ストレージ」は不要。
仕組み: 自分のHDDにあるログファイルを、ただ相手に送るだけ。
利点: ストレージの共有も、クラスターの設定もいりません。だから**「管理作業が最小」**なのです。
サービス別：使える「高可用性・DR」の固定セット
| サービスの種類 | 使えるソリューション | 特徴 |
|---|---|---|
| Azure SQL Database | 自動フェールオーバーグループ | Azureポータルから設定するPaaS専用機能 |
| Azure SQL Managed Instance | 自動フェールオーバー グループ | SQL DBと同様。インスタンス丸ごと別リージョンへ。 |
| SQL Server on Azure VM (IaaS) | Always On 可用性グループ (AG) | Windows Serverのクラスター(WSFC)を組んで構築。 |
| オンプレミス ↔ Azure VM | ログ配布 (Log Shipping) | クラスター不要。ファイルを送るだけのシンプル設計。 |
判断基準
試験で「オンプレ ↔ Azure VM」のSQL移行・DR が出たら、こう考える。
①「管理を楽に、安く、確実に DR したい」👉ログ配布 (Log Shipping)
②「ダウンタイムをほぼゼロに、最新機能を使いこなしたい（ただし構築は大変）」👉Always On 可用性グループ (AG) ※FCI ではなく AG
③「OSごと全部面倒見てほしい」👉Azure Site Recovery (ASR)
「ログ配布」を選ぶ判断基準
オンプレミスから Azure への DR👉異なるネットワーク間でも構築が最も簡単だから。
管理作業を最小限にしたい👉クラスター構成（WSFC）が不要だから。
多少のデータ損失（数分）は許容できる👉ログの間隔を短くすれば被害を抑えられるから。
コストを抑えたい👉Enterprise 版ではなく Standard版の SQL Server でも使えるから。
SSIS、SSAS、SSRSの移行
Azure 仮想マシン上の SQL ServerはSSIS、SSAS、SSRS を維持するための唯一のオプション。
Managed Instance と Azure SQL Database では、SSIS、SSAS、SSRS はサポートされていない。
SQL Server Integration Services (SSIS)
SQL Server Analysis Services (SSAS)
SQL Server Reporting Services (SSRS)