WEB問題集
Azure Storage Account の「Network Routing Preference」設定で「Microsoft Network Routing」を選ぶ意味はどれですか?
解説
【正解: A】の理由
Storage Account の Network Routing Preference (Microsoft Network Routing vs Internet Routing) は、クライアント → Storage 通信の経路を制御します。「Microsoft Network Routing」を選ぶと、Microsoft バックボーン経由で通信し、低レイテンシ + Microsoft 内部ネットワークでの通信保護を実現します。Internet Routing は通常のインターネット経路 (ISP 経由) で、コストは安いが経路セキュリティは劣ります。
【Routing Preference 比較】
| 項目 | Microsoft Routing | Internet Routing |
|---|---|---|
| 経路 | Microsoft バックボーン | インターネット (ISP) |
| レイテンシ | 低 (最適化) | 変動 |
| セキュリティ | Microsoft 内部 | ISP 経由 (公開) |
| コスト | 標準 | 低 |
| SLA | ○ | 限定的 |
【参考】
【Storage Routing オプション影響】
| 項目 | Microsoft Routing | Internet Routing |
|---|---|---|
| レイテンシ | 低 | 変動 (ISP 依存) |
| セキュリティ | Microsoft 内部 | ISP 経由 |
| コスト | 標準 | 低 |
| SLA | ○ | 限定的 |
【ユース ケース別推奨】
- 本番 + 機密データ → Microsoft Routing 必須
- テスト + コスト重視 → Internet Routing 可
- 地理的に分散したクライアント → Microsoft Routing で安定 レイテンシ
各 Azure PaaS サービスを、VNet 統合の主要方式にマッチさせてください。
- App Service Premium V3 (Outbound を VNet 内 PaaS に送信)
- Azure SQL Managed Instance (専用サブネットに直接デプロイ)
- Azure Storage Blob (オンプレからプライベート IP でアクセス)
- Azure SQL Database (Public Disable + プライベート IP のみ)
解説
【正しいマッチング完全版】
- App Service Premium V3 (Outbound を VNet 内 PaaS に送信) → Regional VNet Integration
- Azure SQL Managed Instance (専用サブネットに直接デプロイ) → Subnet Delegation (SQL MI)
- Azure Storage Blob (オンプレからプライベート IP でアクセス) → Private Endpoint (Storage)
- Azure SQL Database (Public Disable + プライベート IP のみ) → Private Endpoint (SQL DB)
【正解マッチング】
| サービス | VNet 統合方式 | 選択理由 |
|---|---|---|
| App Service Premium V3 | Regional VNet Integration | |
| Azure SQL Managed Instance | Subnet Delegation (SQL MI) | |
| Azure Storage Blob | Private Endpoint (Storage) | |
| Azure SQL Database | Private Endpoint (SQL DB) |
【選択フロー】
- サービス インスタンスを VNet 内に配置? → Subnet Delegation
- サービスに プライベート IP でアクセス? → Private Endpoint
- サービスから VNet 内リソースにアクセス? → Regional VNet Integration
- VNet 内のみアクセス + Public DNS 維持? → Service Endpoint
【参考】
Azure DNS の Alias レコード (Alias Record Set) の利点はどれですか?
解説
【正解: A】の理由
Azure DNS Alias レコードは Azure リソースを直接参照する特殊なレコード。Public IP、Front Door、Traffic Manager、CDN 等の Azure リソースが IP 変更されても DNS レコードが自動追従。CNAME と異なり Zone Apex (例: contoso.com) でも利用可能 (CNAME は RFC で Zone Apex 禁止)。
【Alias vs CNAME】
| 項目 | Alias | CNAME |
|---|---|---|
| Zone Apex | ○ | × (RFC 違反) |
| Azure リソース 自動追従 | ○ | × |
| 外部ドメイン参照 | × | ○ |
| レコード タイプ | A/AAAA/CNAME 互換 | CNAME |
【典型ユース ケース】
- contoso.com の Zone Apex を Front Door に向ける (CNAME 不可なので Alias)
- Public IP リソースを参照する DNS A レコード (IP 変更時に自動追従)
- Traffic Manager Profile を Zone Apex から参照
【参考】
【Alias レコードの自動追従】
| Azure リソース | Alias 対応 |
|---|---|
| Public IP Address | ○ |
| Front Door | ○ |
| Traffic Manager Profile | ○ |
| CDN Endpoint | ○ |
| Storage Static Website | ○ (Endpoint 経由) |
【Alias vs A レコードの違い】
- A レコード: IP 直接記述、変更時に手動更新
- Alias レコード: Azure リソース参照、変更時に自動追従
- Apex 利用 (例: contoso.com の Front Door 参照) は Alias のみ可
Azure VNet ピアリング (Regional + Global) に関する次の各記述について、正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。
注: 正解 1 つにつき 1 点が与えられます。
| ステートメント | はい | いいえ |
|---|---|---|
VNet ピアリングは推移的で、A↔B と B↔C のピアリングがあれば A↔C は直接通信できる VNet ピアリングは非推移的なため、A↔B と B↔C のピアリングがあっても A↔C は直接通信できません。そのため、Hub-Spoke で Spoke 間通信を実現するには Hub に NVA と UDR を配置するか、Virtual Network Manager を採用します。 | ||
Allow gateway transit を Hub 側で true、Use remote gateways を Spoke 側で true にすることで、Spoke が Hub の Gateway を利用できる Hub 側で Allow gateway transit を有効化し、Spoke 側で Use remote gateways を有効化すると、Spoke が Hub の VPN / ExpressRoute Gateway を共有利用できます。このため、Gateway を保有するのは Hub のみで済み、コストと運用負荷を大幅に削減できます。 | ||
ピアリング先 VNet のアドレス空間が重複しているとピアリング作成は成功するが通信時にエラーになる ピアリング作成時に対向 VNet のアドレス空間が重複している場合、ピアリング作成自体が失敗します。そのため、通信時のエラーではなく作成時の検証段階で問題が検出される仕組みとなっています。 |
解説
【正解一覧】
| ステートメント | 正解 |
|---|---|
| VNet ピアリングは推移的で、A↔B と B↔C のピアリングがあれば A↔C は直接通信できる | いいえ |
| Allow gateway transit を Hub 側で true、Use remote gateways を … | はい |
| ピアリング先 VNet のアドレス空間が重複しているとピアリング作成は成功するが通信時にエラーになる | いいえ |
【各判定の詳細】
- 「VNet ピアリングは推移的で、A↔B と B↔C のピアリングがあれば A↔C は直接通信できる」→ いいえ: VNet ピアリングは非推移的なため、A↔B と B↔C のピアリングがあっても A↔C は直接通信できません。そのため、Hub-Spoke で Spoke 間通信を実現するには Hub に NVA と UDR を配置するか、Virtual Network Manager を採用します。
- 「Allow gateway transit を Hub 側で true、Use remote g…」→ はい: Hub 側で Allow gateway transit を有効化し、Spoke 側で Use remote gateways を有効化すると、Spoke が Hub の VPN / ExpressRoute Gateway を共有利用できます。このため、Gateway を保有するのは Hub のみで済み、コストと運用負荷を大幅に削減できます。
- 「ピアリング先 VNet のアドレス空間が重複しているとピアリング作成は成功するが通信時にエラーになる」→ いいえ: ピアリング作成時に対向 VNet のアドレス空間が重複している場合、ピアリング作成自体が失敗します。そのため、通信時のエラーではなく作成時の検証段階で問題が検出される仕組みとなっています。
【参考】
Azure VNet 内の VM がデフォルトで使用する DNS 解決サービスはどれですか?
解説
【正解: A】の理由
Azure VNet 内の VM は既定で Azure が提供する仮想 DNS リゾルバ (Azure-provided DNS) を使用し、その IP は 168.63.129.16 です。この IP は Azure のすべての VNet で共通で、内部用の予約アドレスです。VNet 内の名前解決 (azurewebsites.net 等の Azure サービス) や インターネット名前解決を担当します。
【DNS カスタマイズ オプション】
| レベル | 設定方法 |
|---|---|
| VNet レベル | VNet > DNS サーバー > カスタム |
| NIC レベル | NIC > DNS サーバー (VNet をオーバーライド) |
| VM OS レベル | OS 設定 (DHCP オーバーライド) |