【AZ-305】合格への道(DAY4) — インフラストラクチャ ソリューション設計
Microsoft Learn を教材にした AZ-305（Designing Microsoft Azure Infrastructure Solutions）4日間研修、最終日 DAY4 の受講メモです。
コンピューティング選定の続きから、メッセージング・キャッシュ・ネットワーク・移行設計・Well-Architected Framework、そして試験対策までを扱います。
講師の解説のうち「Learn の本文だけでは拾えない判断基準」を中心に、受講メモとして整理しました。
前提知識として、AZ-104合格後です。
⚠️ 本記事は受講メモをベースにした個人の整理です。正確な仕様・価格は必ず公式ドキュメントをご確認ください。
研修全体の構成
| 内容 | |
|---|---|
| DAY1 | ID・ガバナンス |
| DAY2 | ストレージアカウント、データベース |
| DAY3 | バックアップとサイトリカバリ |
| DAY4 | インフラストラクチャ ソリューション設計 |
0. コンピューティング選定の補足
Azure Container Apps はマイクロサービスを構築することが可能です。
参考: Azure Container Apps の概要
演習: ケーススタディ: コンピューティング
第1部: アプリケーション アーキテクチャを設計する
1-1. メッセージとイベントの違い
まずここを押さえないと、後続のサービス選定がブレます。
| 内容 | |
|---|---|
| イベント（Event） | 軽量。パブリッシャー（送信側）とサブスクライバー（受取側）を含む。トリガーとして使う。ブロードキャストを使うことが多い。一過性（送りっぱなしで、確実に受け取る保証はない） |
| メッセージ（Message） | 後で別のコンポーネントによって使用される。あるコンポーネントで生成された生データが含まれる。データへの参照だけでなく、データ自体が含まれている |
1-2. メッセージング ソリューションを設計する
Azure Queue Storage
汎用ストレージアカウントの中の「キュー」です。
- ファイル名や階層構造の概念はない。キューに対してデータを書き込むだけ
- キューを読んだ後、Azure Portal からデキュー（削除）も可能
- メッセージのデキューは先頭から処理して先頭から削除する
- Azure にはキュー専用の個別サービスがなく、ストレージアカウントの中にある
- エラー時などにキューの順序が変わる可能性がある
Service Bus
- 相手に対してのコミュニケーション追加機能が多い
- 高度なことが実現できる
- メッセージの読み取りと削除を同時に実現できたりする
Service Bus のパブリッシュ / サブスクライブ トピック: 複数のサブスクライバーがいる構成に対応。
使い分け
★ 価格は Azure Queue Storage の方が安い。
| 向いているケース | メッセージあたりの容量 | |
|---|---|---|
| Queue Storage | 単純キュー、サイズが 80GB を超えるキュー | 64KB |
| Service Bus | 先入れ先出しの保証が必要な場合 | 256KB（Premium ならさらに大きく） |
Service Bus の追加ポイント:
- At-Least-Once（PeekLock） / At-Most-Once（Receive And Delete）
- 複数のレシーバーを設けることが可能
- Service Bus は Functions を呼ぶことができる
1-3. Azure Event Hubs / Event Grid
Azure Event Hubs
- イベントを発生する側。順番などの概念はない
- レシーバーに通知可能
- モニターログや診断設定の際の「イベントハブへのストリーム」で使う
- データ量が多い場合に使う。イベントの情報をキャッチするだけ
- プログラムに直接イベントを送るのではなく、中継させる
Azure Event Grid
- リソースグループやサービスバスなどにイベントを Push する
- イベントドリブンで動作し、イベントの情報をキャッチして別サービスに Push できる
- Event Grid から Service Bus にキュー登録も可能
よくある組み合わせパターン
Azure Queue Storage + Azure Event Grid はよくあるパターンです。
Event Hubs が大量データを取り込む（Pull 型）
→ ストレージに保存
→ Event Grid に通知
→ Azure Functions が起動
→ ストレージに保存したデータを読み取り、次の処理へ
IoT Hub
- Pull 型
- IoT デバイスから入ってきたデータをストレージに保存する
- 短時間に大量の処理ができる
1-4. キャッシュ ソリューション（Azure Managed Redis）
データベースに対するキャッシュです。データベースから検索した結果を記録しておきたい場合に使います。
- SQL クエリ文を覚えて、一定時間は同じ結果を返す
- 時間設定も可能
- データベースの変更があればキャッシュをクリアすることも可能
- Redis はオンメモリデータベースなので、何でも入る
1-5. API Management
インターフェースがバラバラなアプリケーションへのアクセスを個別に制御するのは大変です。
そこでフロントエンドに API Management を置きます（入口）。あくまでも中間ポイントで、認証・認可の振り分けができます。
1-6. アプリケーション ライフサイクルを設計する
IaC（コードとしてのインフラストラクチャ）
サーバインフラを自動化すること。可能な場合は宣言型定義ファイルを使用します。
（＝具体的な作業手順ではなく、完成後のあるべき状態を書くこと）
| ツール | 内容 |
|---|---|
| ARM テンプレート（Azure Resource Manager テンプレート） | JSON 形式 |
| Bicep（Azure ネイティブ） | ARM テンプレートより少ないコードで記載可能 |
- ARM Template Viewer（VS Code 拡張機能）: Marketplace
- Bicep と ARM テンプレートの構文比較: Microsoft Learn
その他の関連サービス・ツール
- Azure Update Manager
- Azure Pipelines
- GitHub Actions
- Terraform
- Jenkins
Azure App Configuration
たとえばデータベースと Web サーバのタイムゾーンや言語はリソース毎に管理されているため、それを一元的に管理するサービスです。
Azure Automation
インフラ自動化に使うサービス。定期的なスクリプト実行、仮想マシンの起動・停止、構成管理、更新プログラムの管理などに利用します。
1-7. 演習で出てきた観点
- ストレージアカウントにデータを保存するとき、SAS を使って一時的な URL を作成する
- Azure Functions で処理時間が長く処理しきれない場合、Durable Functions を利用すると監視が可能。タイムアウトの制約も考慮できる
- メール送信用のサービスとして SendGrid が用意されている。Azure 経由で SendGrid を契約した方が無料プランの範囲が広い
- Azure Communication Services: 様々なプラットフォームに対して通知が可能（Teams、SNS、電話、メールなど）。Azure Functions から呼べる
- Logic Apps から Exchange Online 経由でメールを送るのも簡単
第2部: ネットワーク ソリューションを設計する
2-1. 多層防御の考え方
★ 一番大事なのはデータ。データが保持されていればビジネスは継続できる。 それをどう守るのか。
ネットワーク要件として集めるもの
- リージョン
- セグメントをどう分けるのか（セグメントとセキュリティは一緒に考える）
- 接続
- アクセス許可 など
2-2. Azure ネットワーク設計の基本形
部門毎に独立したネットワークを作る場合の選択肢:
- サブネットを管理する（サブネット毎にセキュリティ設定）
- VNet を分けて Peering でつなぐ（全社管理と部門管理）
- ハブ & スポークでネットワークを構成する
2-3. ネットワークトポロジ
① 単一の仮想ネットワーク
② ピアリングを使った複数のネットワーク
③ ハブスポーク トポロジ
★ Virtual WAN がないと、Peering だけでは VNet をホップできない。
2-4. 送信接続とルーティングを設計する
インターネット通信の4方式
| 方式 | 通信方向 | 備考 |
|---|---|---|
| VM に直接パブリック IP を割り当てる | 入り・出の両方 | Azure 非推奨 |
| Load Balancer にパブリック IP を割り当てる（Firewall でも可） | 入り・出の両方 | |
| NAT Gateway にパブリック IP を割り当てる | 出のみ | |
| Azure が内部で自動的にパブリック IP を割り当てる（暗黙の NAT / 既定の送信アクセス） | 出のみ | VNet 内のサブネットがプライベートサブネットでない場合に自動構成される。Azure 非推奨で将来的に廃止予定 |
コストの実感（講師談）
- NAT Gateway は意外とコストが高い。NAT Gateway 用のサブネットを作成する必要があり、月額2万円程度
- Load Balancer の方が安い。ただしバックエンドをあらかじめ登録する必要がある
2-5. ルーティング設計
- サブネットを作成するとシステムルートが作られ、サブネット間は自由に通信可能
- セキュリティ要件によりルーティングテーブルが必要になる
- ユーザー定義ルート
- BGP ルート
- システムルート
★ サービスエンドポイントもルーティングテーブルの設定で定義する。
ルートテーブルのネクストホップにVirtualNetworkServiceEndpointを設定する。
2-6. オンプレミス接続を設計する
Azure と外部を結ぶのは仮想ネットワークゲートウェイです。
- VPN ゲートウェイ（インターネット）
- ExpressRoute ゲートウェイ（キャリアネットワーク）
| 帯域 | 特徴 | |
|---|---|---|
| VPN 接続 | 最大 10Gbps | 構成が容易。オンプレミス側にも VPN デバイス（ゲートウェイ）が必要 |
| ExpressRoute | 10Gbps | ラウンドトリップが小さい |
| ExpressRoute Direct | 100Gbps | プロバイダから回線を借用するが、回線管理を自分でしなければいけない |
⚠️ ExpressRoute はデータを暗号化しない（盗聴のリスクが低いと判断されているため）。
社内のコンプライアンス要件に合わない可能性がある。
ExpressRoute と VPN の併用
VPN Gateway 間は暗号化されているので、VPN Gateway 間で通信しつつ、経路は ExpressRoute のネットワークにデータを流すという構成が取れます。
Azure Virtual WAN
通常のハブスポークは自社でハブを構築・管理しますが、Virtual WAN は Microsoft 管理のハブを使って接続やルーティングを簡素化するサービスです。
2-7. アプリケーション配信サービスを選ぶ
選定軸: トラフィックの種類 / グローバルかリージョンか / 可用性 / コスト / 機能と制限
| リージョンベース | グローバルベース | |
|---|---|---|
| 汎用（Web 以外） |
Azure Load Balancer L4（IP＆ポート番号） |
Traffic Manager DNS ベース |
| Web 専用 |
Application Gateway L7（ホスト名、URL 等） |
Azure Front Door L7（Azure インフラ） |
ポイント
- Web Application Firewall（WAF）は単独で組めない。 Application Gateway か Azure Front Door と一緒に使う必要がある
- Application Gateway は構成上インターネット接続が前提だが、つながなくても設定は可能
- グローバルベースのものを単独で使うことは少なく、リージョンベースのものと組み合わせて使う
- Front Door は WAF と CDN 統合が必要な場合に選ぶ
- リージョン跨ぎの意味は DR、および世界各地にサービス展開していて近いリージョンからクライアントに応答する用途
CDN（Content Delivery Network）の現状
| 状況 | |
|---|---|
| Front Door 内蔵 | 現行 |
| Azure CDN（Classic） | 廃止予定 |
| Edgio（← Verizon ← Edgecast） | 既に廃止 |
| Akamai | 既に廃止 |
2-8. アプリケーション保護サービスを設計する
サービスエンドポイント
- Azure のプライベートネットワークを通してアクセスする
- サブネットからエンドポイントにアクセスする（サブネットのルーティングテーブル）
- ExpressRoute の場合、プライベートピアリングとパブリックピアリングでつなぐ方法がある
- パブリックピアリングは Azure 上の PaaS サービスとつなぐことができる
Azure Private Link / プライベートエンドポイント
- Azure 上のサービスを VNet に引っ張ってきて使える
- そのためオンプレから VPN 経由でのプライベートアクセスが可能
- Private Link はプライベート IP アドレスを持つので使いやすい
- DNS の連携が必要。ホスト名でアクセスしなければいけない
ネットワークセキュリティグループ（NSG）
Azure Firewall
- Firewall 用の Firewall サブネットを作る
- VNet も分けることが多い。事業部の VNet とピアリングでつなぐケースも多い
Web Application Firewall
- 単独では利用不可
- Application Gateway または Azure Front Door と一緒に利用すること
DDoS Protection
DDoS 攻撃を防ぐサービス。
（例: SYN アタック — サーバ側でメモリ領域を確保させるため大量の SYN パケットを送り、サーバをダウンさせる攻撃）
| プラン | 内容 | 費用感（講師談） |
|---|---|---|
| DDoS インフラストラクチャ保護 | Azure データセンターを保護することが目的。強制適用でレポートなし | 無料 |
| DDoS ネットワーク保護 | インターネットからのアクセスに対する VNet 保護。パブリック IP 100個まで一律 | 40万円程度 |
| DDoS IP 保護 | パブリック IP 単位での保護 | 1IP あたり3万円程度 |
- DDoS 攻撃だと証明できれば、アウトバウンド通信料を免除してくれるプログラムがある
★ Load Balancer はマネージドサービスだが、DDoS Protection の機能が付いているわけではない。
パブリック IP アドレスを持つものには DDoS Protection の併用が望ましい。
参考: Load Balancer を DDoS 攻撃から保護する
Azure Bastion
- Azure ポータル認証
- SSL/TLS（443）でアクセスし、リモートデスクトップのポートは使わない
- Bastion を通るとプライベート IP でのアクセスとなる
- 仮想マシンにパブリック IP アドレスが不要になる
SKU レベル
| SKU | 内容 |
|---|---|
| Developer | 無料、迅速に利用可能 |
| Basic | 組織内 |
| Standard | 負荷分散、共有可能リンク |
| Premium | 動画記録 |
ジャストインタイム（JIT）ネットワークアクセス
Defender for Cloud で設定する機能です。
- 必要な時にだけポートを開放する
- 3389 および 22 以外のポートもサポート
- 使用されていない場合、ポートはブロックされる
- NSG および Azure Firewall と統合
- リモートデスクトップ経由でどうしてもつなぎたい要件がある場合に使う
第3部: 移行の設計
3-1. クラウド導入フレームワーク（CAF）
AZ-305 の範囲外ですが、プロジェクト管理の観点で押さえておくもの。
参考: クラウド導入フレームワークの概要
3-2. 移行戦略（5R）
| 戦略 | 内容 |
|---|---|
| rehost | IaaS |
| refactor | PaaS（App Service など。アプリケーションの中身は変えず、同じロジックのまま基盤を変える） |
| rearchitect | 最適化 |
| rebuild | 最初からやり直し |
| replace | SaaS（メールサーバを VM で立てる代わりに Exchange Online にする など） |
現状のシナリオを考えて戦略を立てます。
3-3. 移行ツールを選ぶ
データベース移行
- オフライン移行: データベースを止めて移行
- オンライン移行: データベースを動かしたまま移行
ファイル移行
- Azure File Sync: オンプレミスのファイルを Azure Files に移行するツール。オンプレミスのファイルサーバーと Azure Files を継続的に同期する
ファイルサーバそのものの移行
- Azure Storage Mover: ファイルとフォルダの両方に対応したストレージ移行サービス
物理搬送
- インポート/エクスポート サービス: 物理ディスクを搬送してデータ移行する。今後 Azure Data Box に移行される予定
- Data Box: オフラインとオンラインのデータ移行
コマンドでの移行
- AzCopy が速いため評判が良い
第4部: Microsoft Azure Well-Architected Framework
信頼性: 基本は冗長化を目指す
セキュリティ: 重要機能。リスク分析の結果として決めていくもの（コストがかかるため）
コスト最適化: クラウドによりコストを低減する施策
オペレーショナル エクセレンス: 使い方の良いものを選ぶ
パフォーマンス効率: 無駄なコストを排除しながらパフォーマンス効率を上げる
★ 柱の間のトレードオフは、最終的にビジネス上の判断。
第5部: 試験対策
出題形式について
- 操作問題は出ない（ただしプラクティステストには含まれる）
- 後戻りできない問題がある
- ケーススタディは「[ケース] + [問題群]」から抜粋される形式。AZ-305 では2〜3個出ると思われる
- 総問題数を確認し、開始時点の問題数から引くと、残りがケーススタディ分と分かる
プラクティステスト
DAY4 の重点ポイントまとめ
- イベント = トリガー・一過性 / メッセージ = データ本体を含む
- Queue Storage（安い・64KB・80GB超もOK）vs Service Bus（FIFO保証・256KB・Functions呼び出し可）
- WAF は単独で組めない。Application Gateway か Front Door とセット
- 配信サービスは「Web か否か × リージョンかグローバルか」の4象限で覚える
- Virtual WAN がないと Peering だけでは VNet をホップできない
- ExpressRoute は暗号化しない。要件次第で VPN と併用
- NAT Gateway は出方向のみ・意外と高い。Load Balancer の方が安い
- Load Balancer に DDoS Protection は付いていない
- 移行戦略の 5R、特に refactor はロジックを変えず基盤だけ変える
おわりに
4日間の研修はこれで終了です。全体を通して感じたのは、AZ-305 は個々のサービス知識よりも「要件からの逆引き」が問われる試験だということでした。
- どの層で守るのか（多層防御）
- どこまで分離するのか（管理グループ / サブスクリプション / リソースグループ）
- 何を優先するのか（Well-Architected Framework の柱のトレードオフ）
この3つの問いに、要件から即答できる状態を作るのが試験対策そのものだと感じています。
次はプラクティステストを回しながら、弱点を潰していきます。