プレイブック

大規模な先行ハードウェア購入から従量課金モデルへIT支出を移行する。

→クラウドの消費ベースモデルを活用する。

理由: これにより、設備投資（CapEx）を予測可能な運用費（OpEx）に変換し、データセンターの調達と管理の必要性を排除する。

クラウドプロバイダーと顧客の間でのセキュリティおよび管理責任の分担を理解する。

→プロバイダーはクラウド*の*セキュリティに責任を負い、顧客はクラウド*における*セキュリティに責任を負う。顧客は常に自身のデータ、ID、エンドポイントを所有する。

理由: IaaSでは、顧客がOSとその上を管理する。PaaSでは、プロバイダーがOSを管理し、顧客がアプリケーションとデータを管理する。SaaSでは、プロバイダーがデータとアクセス設定を除くすべてを管理する。

リファレンス↗

制御、テナンシー、および場所の要件に基づいてデプロイモデルを選択する。

→パブリック（共有インフラ）、プライベート（専用インフラ、オンプレミスまたはホスト型）、またはハイブリッド（パブリックとプライベートの組み合わせ）を使用する。

理由: ハイブリッドは、規制やレイテンシーのためにオンプレミスシステムを維持しつつ、スケーラビリティと最新のサービスにパブリッククラウドを利用する上で重要である。プライベートは最大限の制御を提供する。

必要な管理制御レベルに基づいて適切なクラウドサービスモデルを選択する。

→OSを最大限に制御するにはIaaS（例：Azure VM）。インフラではなくコードに集中するにはPaaS（例：Azure App Service, Azure SQL）。すぐに使えるソフトウェアにはSaaS（例：Microsoft 365）を使用する。

理由: トレードオフは、制御と利便性である。IaaSからSaaSへ移行するにつれて、プロバイダーがスタックのより多くの部分を管理し、顧客の運用負担を軽減する。

動的で予測不能なトラフィックスパイクと、計画的で持続的な成長に対応する。

→リアルタイムの需要に合わせるために自動スケーリング（イン/アウト）にはElasticityを使用する。計画された容量増加（アウト/アップ）で予測される成長に対応するにはScalabilityを使用する。

理由: Elasticityは自動化され反応的であり、コスト最適化のための急増するワークロードに理想的である。Scalabilityは容量を追加するより広範な概念であり、手動または自動で実行できる。

リージョン内でのコンポーネント障害と、壊滅的なリージョン障害から保護する。

→データセンター障害に耐えるためにAvailability Zonesを使用して高可用性（HA）を実装する。リージョン災害に耐えるためにクロスリージョンレプリケーション（例：GRS）を使用してディザスターリカバリー（DR）を実装する。

理由: HAは最小限のサービス中断でサービスを維持することである。DRは大規模な障害後にサービスを復旧することである。HAは通常、高速フェールオーバーで自動化される。DRはしばしば正式な復旧プロセスを伴う。

特定のコンプライアンスとデータレジデンシーを必要とする政府機関向けにリソースをデプロイする。

→Azure Governmentのようなソブリンクラウドを使用する。

理由: これらは、厳選された担当者によって管理され、厳格な政府のコンプライアンス基準（例：FedRAMP, DoD）を満たすように設計された、物理的に分離されたAzureインスタンスである。

データセンターの障害に耐えられる回復性のあるアプリケーションを設計する。

→単一のAzureリージョン内の複数のAvailability Zonesにリソースをデプロイする。

理由: Availability Zonesは、独立した電源、冷却、ネットワークを備えた物理的に分離されたデータセンターである。これにより、クロスリージョンデプロイメントのレイテンシーなしに、リージョン内で高可用性が提供される。

リファレンス↗

統合された管理、アクセス制御、および課金のために、関連するAzureリソースをグループ化する。

→アプリケーションのすべてのリソースを単一のAzure Resource Groupに配置する。

理由: リソースグループはメタデータのコンテナーである。リソースグループを削除すると、その中のすべてのリソースが削除されるため、重要なライフサイクル管理境界となる。

ワークロードに適したコンピューティングサービスを選択する。

→完全な制御にはVM（IaaS）。Webアプリ/APIにはApp Service（PaaS）。イベント駆動型サーバーレスコードにはAzure Functions。コンテナーオーケストレーションにはAKS。単純なコンテナーインスタンスにはACIを使用する。

理由: 選択は、制御、管理オーバーヘッド、およびアーキテクチャパターン（例：モノリス、マイクロサービス、イベント駆動型）間のトレードオフに依存する。

オートスケーリング、サービスディスカバリ、ローリングアップデートを必要とする複雑なコンテナ化されたマイクロサービスアプリケーションを実行する。

→Azure Kubernetes Service (AKS)を使用する。

理由: AKSは、フルスケールのコンテナーオーケストレーションのためのマネージドKubernetesサービスである。クラスター管理と複雑なサービス間相互作用が必要な場合は、ACIよりもこれを使用する。

インフラ管理なしで、短期間のタスク（例：バッチジョブ）のために単一のシンプルなコンテナーを実行する。

→Azure Container Instances (ACI)を使用する。

理由: ACIは、Azureでコンテナーを実行する最も速くシンプルな方法である。サーバーレスで秒単位で課金され、オーケストレーションの必要がないタスクに理想的である。

オンプレミスデータセンターからAzureへの専用でプライベートな高帯域幅接続を確立する。

→Azure ExpressRouteを使用する。

理由: ExpressRouteはパブリックインターネットを介さないため、インターネット経由でトンネルを張るVPN Gatewayよりも高い信頼性、セキュリティ、および低いレイテンシーを提供する。

リファレンス↗

ネットワークレベルとアプリケーションレベルのルールに基づいてバックエンドVMにトラフィックを分散する。

→Layer 4 (TCP/UDP)の分散にはAzure Load Balancerを使用する。SSLオフロードやURLベースのルーティングなどのLayer 7 (HTTP/HTTPS)機能にはAzure Application Gatewayを使用する。

理由: HTTPヘッダー、パス、またはホスト名に基づいてルーティング決定を行う必要がある場合はApplication Gatewayを選択する。Load Balancerは非HTTPトラフィックに対してよりシンプルで高速である。

グローバルなWebトラフィックを最適なバックエンドにルーティングし、CDNキャッシングを提供し、WAFで保護する。

→Azure Front Doorを使用する。

理由: Front DoorはLayer 7で動作するグローバルなエントリポイントであり、グローバルロードバランシング、CDN、WAF、DDoS保護を単一のサービスに統合する。

画像、動画、バックアップ、ログファイルなどの大量の非構造化データを保存する。

→Azure Blob Storageを使用する。

理由: Blob Storageは、オブジェクトデータ向けに非常にスケーラブルで費用対効果が高い。Azure Files（SMBファイル共有用）やAzure Disk Storage（VMディスク用）とは異なる。

データのアクセス頻度に基づいてストレージコストを最小化する。

→Blob Storageのアクセス層（Hot（頻繁アクセス）、Cool/Cold（低頻度アクセス）、およびArchive（まれなアクセス、長期保存））を使用する。

理由: Archive層はストレージコストが最も低いが、アクセスコストとレイテンシー（再ハイドレーションに数時間）が最も高い。階層化を自動化するにはライフサイクル管理ポリシーを使用する。

ハードウェア、データセンター、またはリージョン障害から保護するためのデータレプリケーション戦略を選択する。

→LRS（単一データセンター）、ZRS（1つのリージョン内のAZ間）、GRS（セカンダリリージョンへ）、GZRS（プライマリでZRS + セカンダリでLRS）を使用する。

理由: ZRSはデータセンター障害から保護する。GRS/GZRSはリージョン災害から保護する。トレードオフは、より高い回復性のためのより高いコストである。

VNet内のVMが、トラフィックをMicrosoftネットワーク外に出すことなくPaaSサービス（Azure SQLやStorageなど）にアクセスできるようにする。

→VMのVNet内にPaaSサービス用のPrivate Endpointを作成する。

理由: Private EndpointはPaaSサービスにVNetからのプライベートIPアドレスを付与し、すべてのトラフィックがパブリックインターネットではなくプライベートなMicrosoftバックボーンを介して流れることを保証する。

オンプレミスのWindowsファイルサーバーを、SMBプロトコル経由でアクセス可能なマネージドクラウドサービスに移行する。

→Azure Filesを使用する。

理由: Azure Filesは、クラウドまたはオンプレミスVMによってマウントできる完全にマネージドされたファイル共有を提供し、従来のファイルサーバーの直接的な代替となる。

多数のAzureサブスクリプション全体にガバナンス（ポリシー、RBAC）を適用し、アクセスを管理する。

→サブスクリプションをManagement Group階層に整理する。

理由: Management Groupはサブスクリプションの上位スコープである。管理グループレベルで適用されたポリシーとロール割り当ては、その中のすべてのサブスクリプションに継承される。

リファレンス↗

デプロイを特定のリージョンに制限したり、すべてのリソースにタグを要求したりするなど、組織の標準を強制する。

→Azure Policyを使用する。

理由: Policyはリソース構成に関するルールを強制する。これはガバナンスのためのものであり、RBACはユーザーのアクセス許可（アクション）を制御する。

ユーザーのアクションを制御することと、リソースのプロパティを制御することを区別する。

→ユーザーが実行できるアクションを定義するにはロールベースのアクセス制御（RBAC）を使用する（例：「共同作成者」はVMを作成できる）。許可される構成を定義するにはAzure Policyを使用する（例：「VMはDシリーズサイズのみに制限される」）。

理由: RBACは「誰が何ができるか」についてである。Policyは「何が許可されるか」についてである。これらは包括的なガバナンスのために連携して機能する。

管理者によってさえ、重要な本番リソースが誤って削除されるのを防ぐ。

→リソースまたはそのリソースグループに`CanNotDelete`リソースロックを適用する。

理由: リソースロックはRBAC権限を上書きする。所有者は、ロックが明示的に解除されるまで、ロックされたリソースを削除できない。`ReadOnly`ロックはあらゆる変更を防止する。

コスト追跡、自動化、または所有者識別のためにリソースを論理的に整理する。

→リソースにタグ（キーと値のペア）を適用する。

理由: タグは、リソースグループを横断してリソースをフィルタリングおよびグループ化するために使用されるメタデータであり、強力なコスト分析と管理を可能にする。

リソースグループに適用されたタグが、その中のリソースに表示されない。

→タグはリソースグループから自動的に継承されない。各リソースは明示的にタグ付けする必要がある。

理由: タグの継承を強制するには、「Modify」または「DeployIfNotExists」効果を持つAzure Policyを使用して、親リソースグループからタグを追加する。

将来のAzureコストを見積もることと、オンプレミスからの移行による節約を計算すること。

→特定のAzureサービスのコストを見積もるには料金計算ツールを使用する。オンプレミスコストとAzureコストを比較するには総所有コスト（TCO）計算ツールを使用する。

理由: 料金計算ツールは新規デプロイメントまたは新しいサービスの追加用である。TCO計算ツールは移行のためのビジネスケース構築用である。

現在のAzure支出を追跡し、支出アラートを設定し、節約の機会を見つける。

→Azure Cost Managementを使用する。支出のしきい値に達したときにアラートをトリガーするために予算を作成する。

理由: 予算は支出に関するプロアクティブな通知を提供し、コスト超過を防ぐのに役立つ。コスト管理分析は、支出の異常や傾向を特定するのに役立つ。

VMやデータベースのような予測可能で継続的に実行されるワークロードのコストを削減する。

→1年または3年間のAzure Reserved InstancesまたはSavings Plansを購入する。

理由: 予約は、長期コミットメントと引き換えに、従量課金制よりも大幅な割引（最大72%）を提供する。定常状態のワークロードに理想的である。

Azureインフラストラクチャを反復可能、一貫性があり、バージョン管理下でデプロイする。

→ARMテンプレート（JSON）またはBicepを使用した宣言型のInfrastructure as Code（IaC）を使用する。

理由: Bicepは、ARM JSONにトランスパイルされる、よりシンプルで簡潔なドメイン固有言語（DSL）であり、より良いオーサリング体験と読みやすさを提供する。

オンプレミスまたは他のクラウドで実行されているサーバーをAzureツールを使用して管理およびガバナンスする。

→非AzureサーバーをAzure Arcにオンボードする。

理由: Azure Arcは外部リソースをAzure Resource Managerに投影し、単一のコントロールプレーンからハイブリッドおよびマルチクラウド資産に対してAzure Policy、RBAC、監視を使用できるようにする。

リファレンス↗

すべてのアプリケーション向けに単一のクラウドベースのIDおよびアクセス管理ソリューションを提供する。

→Microsoft Entra ID（旧Azure AD）を使用する。

理由: Entra IDはIDコントロールプレーンであり、クラウドおよびオンプレミスアプリケーション向けにシングルサインオン（SSO）、多要素認証（MFA）、および条件付きアクセスを提供する。

信頼できないネットワークからサインインするユーザーにはMFAを要求するが、会社オフィスからは要求しない。

→Microsoft Entra Conditional Accessポリシーを構成する。

理由: 条件付きアクセスは「もし〜ならば、〜する」ポリシーエンジンとして機能する。ユーザー/場所/デバイスの条件が満たされた場合、アクセス制御（MFAの要求など）が適用される。

Azureリソース（VMやApp Serviceなど）が、コードにシークレットを保存することなく、別のAzureサービス（Key Vaultなど）に認証できるようにする。

→リソースにマネージドIDを割り当て、ターゲットサービスに対するRBAC権限を付与する。

理由: Azureは資格情報のライフサイクルを自動的に管理し、構成ファイルやコードからのシークレット漏洩のリスクを排除する。

アプリケーションのシークレット、キー、および証明書を安全に保存および管理する。

→Azure Key Vaultを使用する。

理由: Key Vaultは、シークレットの中央集中型でハードウェアによって保護され、監査されたリポジトリを提供し、アプリケーションにシークレットがハードコードされるのを防ぐ。

クラウドワークロードのセキュリティ体制を継続的に評価し、セキュアスコアを取得し、脅威保護を受ける。

→Microsoft Defender for Cloudを使用する。

理由: Defender for Cloudは、Azure、ハイブリッド、およびマルチクラウド環境全体でCloud Security Posture Management (CSPM)およびCloud Workload Protection (CWP)を提供する。

サブネット/NICレベルでネットワークトラフィックをフィルタリングすることと、VNet全体を集中管理すること。

→基本的なLayer 3/4ステートフルパケットフィルタリングにはNetwork Security Groups (NSG)を使用する。Layer 7フィルタリングと脅威インテリジェンスを備えた集中型で完全にステートフルなFirewall-as-a-ServiceにはAzure Firewallを使用する。

理由: NSGはシンプルで分散型である。Azure Firewallは高度な機能と集中型ポリシー管理を提供し、ハブ＆スポークトポロジでよく使用される。

管理ポート（RDP/SSH）をデフォルトで閉じておくことで、VMの攻撃対象領域を減らす。

→Microsoft Defender for CloudでJust-In-Time (JIT) VMアクセスを有効にする。

理由: JITは、要求に応じて管理ポートへの一時的なアクセスを限定された時間だけ許可し、その後自動的にポートを閉じる。これはポートを常に開いたままにするよりも安全である。

Azureインフラストラクチャの健全性を監視することと、アプリケーションコードのパフォーマンスを監視すること。

→プラットフォームのメトリックとログにはAzure Monitorを使用する。Application Performance Management (APM)にはApplication Insights（Azure Monitorの機能）を使用する。

理由: Azure Monitorはインフラストラクチャデータ（CPU、メモリ）を収集する。Application Insightsは、詳細なコードレベル診断（応答時間、依存関係、例外）を提供する。

Azureサービスの中断、計画メンテナンス、およびヘルスアドバイザリに関するパーソナライズされたアラートを受け取る。

→Azure Service Healthを使用する。

理由: Service Healthは、公開されているAzure Statusページとは異なり、サブスクリプション、リージョン、およびサービスに合わせてパーソナライズされている。これは自身のリソースの健全性ではなく、Azureプラットフォームの問題に関するものである。

Azureリソースを最適化するためのパーソナライズされた実行可能な推奨事項を受け取る。

→Azure Advisorの推奨事項を確認する。

理由: Advisorは構成と使用状況のテレメトリを分析し、信頼性、セキュリティ、パフォーマンス、コスト、運用上の優秀性の5つの柱にわたる推奨事項を提供する。

エンタープライズ内のすべてのAzureワークロードに対して、標準化され、統制され、スケーラブルな基盤を確立する。

→Azureランディングゾーンアーキテクチャを実装する。

理由: ランディングゾーンは、クラウド導入を安全に加速するために、管理グループ構造、ネットワーク、ID、およびガバナンスポリシーを含む、Cloud Adoption Frameworkからの規範的なフレームワークを提供する。