Microsoft Azure for SAP Workloads Specialty
最終確認：2026年5月
AZ-120 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
本番用SAP HANAデータベースのVMを選択します。
大規模データベース（4TB超）にはMv2シリーズまたはMシリーズVMを使用します。小規模な本番用HANAデータベース（4TB未満）にはSAP認定のEdsv5シリーズVMを使用します。
理由: Mシリーズ/Mv2シリーズは、大規模メモリワークロード向けにSAP認定されています。Edsv5シリーズは、小規模なHANAインスタンス向けの費用対効果の高い認定オプションを提供します。他のシリーズ（D、F、L）は本番用HANAデータベースには認定されていません。
SAP NetWeaverアプリケーションサーバーのVMを選択します。
Edsv5シリーズまたはDdsv5シリーズVMを使用します。SAP EarlyWatch AlertレポートまたはSAP Quick SizerからのSAPS要件に基づいてサイズを決定します。
理由: EシリーズおよびDシリーズVMは、SAPアプリケーションサーバーワークロードに適したバランスの取れたCPU対メモリ比を提供し、NetWeaver向けにSAP認定されています。
SAPアプリケーションサーバーとデータベースサーバー間のネットワークレイテンシを最小限に抑えます。
関連するすべてのVM（アプリサーバー、ASCS/ERS、データベース）を単一の近接配置グループ (Proximity Placement Group: PPG) 内にデプロイします。
理由: PPGは、VMを同じデータセンターに物理的に共存させ、アプリケーション層とデータベース層の間でSAPが求めるサブミリ秒のレイテンシ要件を満たすために、ネットワークのラウンドトリップタイムを最小限に抑えます。
SAP HANAスケールアウトデプロイメントの/hana/sharedボリュームに共有ファイルシステムを提供します。
NFSプロトコルでAzure NetApp Files (ANF) を使用します。
理由: ANFは、HANAスケールアウト構成に必要なSAP認定の高性能共有NFSストレージソリューションです。Managed Disksのようなブロックストレージはこの目的には使用できません。
/sapmntおよびグローバルトランスポートディレクトリ（/usr/sap/trans）用の高可用性共有ファイルシステムを提供します。
Azure NetApp Files (NFS) またはAzure Files Premium (NFS) を使用します。Windowsの場合は、Azure Files Premium (SMB) またはSOFSクラスターを使用します。
理由: これらのサービスは、必要なパフォーマンスとプロトコルサポート（Linux用NFS、Windows用SMB）を備えたマネージドで高可用性のファイル共有を提供し、個別のファイルサーバークラスターを構築および管理する必要がなくなります。
高いIOPSとサブミリ秒のレイテンシを必要とする本番用SAP HANAの/hana/dataおよび/hana/logボリュームのストレージを設計します。
Azure Ultra DiskまたはPremium SSD v2マネージドディスクを使用します。MシリーズVM上の/hana/logには、Write Acceleratorを備えたPremium SSDも有効なオプションです。
理由: Ultra DiskおよびPremium SSD v2は、本番用HANAワークロード向けにSAPが定義する厳格なIOPS、スループット、およびサブミリ秒のレイテンシKPIを満たします。標準ストレージ層はサポートされていません。
SAPワークロード向けにセキュアなネットワークアーキテクチャを設計し、本番環境と非本番環境を分離します。
ハブ＆スポークトポロジを使用します。各環境（本番、QA、開発）用に専用のスポークVNetにSAPシステムをデプロイします。サブネット間の厳格なトラフィックルールを適用するためにNetwork Security Group (NSG) を使用します。
理由: これにより、VNetレベルでの強力なネットワーク分離とNSGによるきめ細かなトラフィック制御が提供され、セキュリティのベストプラクティスとAzureランディングゾーンのコンセプトに準拠します。
一貫性と自動化のために、Infrastructure as Code (IaC) アプローチを使用してAzure上にSAPランドスケープをデプロイします。
TerraformとAnsibleを活用する公式のSAP on Azure Deployment Automation Frameworkを使用します。または、カスタムのBicepまたはTerraformモジュールを構築します。
理由: このフレームワークは、ランドスケープ全体（コントロールプレーン、ワークロードゾーン、SAPシステム）をデプロイするための事前構築されたSAP検証済みテンプレートを提供し、手作業を減らし、ベストプラクティスへの準拠を保証します。
インターネット経由でSAP Fioriまたは他のWebベースのSAPアプリケーションを外部ユーザーに安全に公開します。
Web Application Firewall (WAF) が有効なAzure Application Gatewayを使用します。
理由: App Gatewayは、レイヤー7ロードバランシング、SSL終端、および一般的なWeb脆弱性からのWAF保護を提供し、WebベースのSAPアプリケーションにとって理想的でセキュアなエントリポイントとなります。
Azure VMの容量を超える非常に大規模なSAP HANAデータベース（12TB超のメモリ）をデプロイします。
SAP HANA on Azure Large Instances (HLI) を使用します。接続には、ExpressRouteゲートウェイを介してHLIスタンプをAzure VNetに接続するExpressRoute回線が必要です。
理由: HLIは、現在の仮想化インフラストラクチャの規模を超える、最大のHANAワークロードに必要な massive memoryとパフォーマンスを提供する専用のベアメタルサーバーです。
Availability ZonesにSAPシステムをデプロイしつつ、各ゾーン内のレイテンシを最小限に抑えます。
各Availability Zoneのリソース用に個別のProximity Placement Group (PPG) を作成します。各PPGをそれぞれのゾーンにピン留めします。
理由: 単一のPPGはゾーンをまたぐことはできません。このアプローチにより、ゾーン*内*でのリソースの低レイテンシ共存が保証されつつ、ゾーン*間*での高可用性を実現します。
複数のリージョンにわたるSAPデプロイメント向けに、標準化され、パッチ適用済みで事前構成されたVMイメージを作成および配布します。
Azure Image Builderを使用して、再現可能なイメージ作成プロセスを定義します。結果として得られるマネージドイメージをAzure Compute Galleryを使用して保存およびレプリケートします。
理由: これにより、バージョン管理された自動化された「ゴールデンイメージ」ファクトリが提供され、手動で各新規VMを構成する場合と比較して、一貫性が確保され、デプロイ時間が短縮されます。
SAP VMをパブリックインターネットに公開することなく、セキュアなRDP/SSH管理アクセスを提供します。
SAP仮想ネットワーク内の専用サブネットにAzure Bastion (Standard SKU) をデプロイします。Azure portalまたはネイティブクライアントを介してVMに接続するためにBastionを使用します。
理由: Bastionは、セキュアなマネージドジャンプボックスとして機能し、SAP VM上のパブリックIPアドレスや管理アクセス用の複雑なVPN設定の必要性を排除し、攻撃対象領域を削減します。
顧客管理の暗号化キーを使用してSAPデータボリュームを暗号化します。
Azure Key Vaultに保存された顧客管理キー (CMK) を使用するAzure Disk Encryptionを使用します。これは、多層防御のためにSAP HANAネイティブ暗号化と組み合わせることができます。
理由: この構成により、顧客はデータ暗号化キーを完全に制御でき、キーのライフサイクル管理に関する厳格なコンプライアンスおよびセキュリティ要件を満たします。
オンプレミスにある非HANAデータベース（例：Oracle、Db2）を使用するSAPシステムを、Azure上のSAP HANAに移行します。
Database Migration Option (DMO) を備えたSAP Software Update Manager (SUM) を使用します。最小限のダウンタイムで済ませるには、「DMO with System Move」またはnZDT (near-Zero Downtime) オプションを使用します。
理由: DMOは、データベース変換、システムアップグレード、データ移行を単一の最適化されたプロセスに統合します。これはこのタスクの標準的なSAPツールであり、従来のexport/importと比較してダウンタイムを最小限に抑えます。
オンプレミスにあるSAP HANAシステムを、可能な限り短いダウンタイムでAzureに移行します。
SAP HANA System Replication (HSR) を使用して、データをターゲットのAzure VMに継続的にレプリケートします。メンテナンスウィンドウ中に、最終的な短いカットオーバー（テイクオーバー）を実行します。
理由: HSRは、最終的な同期とテイクオーバーのみが必要なため、ダウンタイムを数分に短縮します。バックアップ/リストアまたはexport/importの方法では、大規模データベースの場合、数時間のダウンタイムが発生します。
ネットワーク帯域幅が不十分な場合、初期移行ロードのために、オンプレミスからAzureへ大量のSAPデータ（10TB超）を転送します。
初期のバルクデータ転送にはAzure Data Boxを使用します。その後の差分同期にはExpressRouteまたはVPNを使用します。
理由: Data Boxは、限られた帯域幅を介したネットワークベースの転送よりも高速なオフライン転送方法を提供し、初期のロード時間を大幅に短縮します。
簡素化されたガイド付きエクスペリエンスを使用して、Azure上にSAP S/4HANAシステムをデプロイおよび管理します。
Azure Center for SAP solutions (ACSS) を使用します。前提条件には、`Microsoft.Workloads`プロバイダーの登録と、必要なアクセス許可を持つユーザー割り当てマネージドIDの作成が含まれます。
理由: ACSSは、ベストプラクティスをバンドルすることでデプロイを効率化し、Azure portalで基本的な管理（起動/停止、監視）および品質チェックのためのシングルペインオブグラスを提供します。
新規または移行されたSAPシステムに適したAzure VMサイズを決定します。
新規実装にはSAP Quick Sizerツールを使用します。移行の場合は、既存システムからのSAP EarlyWatch Alertレポートを分析して、現在のSAPSとメモリ使用量を取得します。これらをSAP認定のAzure VMにマッピングします。
理由: これらのSAPネイティブツールは、最も正確なワークロード特性評価（SAPS、メモリ、I/O）を提供し、Azureリソースを正しく選択し、パフォーマンスとサポート可能性を確保するために不可欠です。
顧客管理のAzure環境を、RISE with SAP経由でデプロイされたSAP S/4HANAシステムと統合します。
SAPは基盤となるAzureインフラストラクチャを別のサブスクリプションで管理します。VNetピアリングを使用して、お客様のAzure VNetからSAP管理VNetへの接続を確立します。
理由: RISEはSAPが提供するマネージドサービスです。VNetピアリングは、RISE環境とAzure内の他の顧客ワークロード間の標準的でセキュアなプライベートネットワーク統合パスを提供します。
Azure内のすべてのSAPデプロイメント全体で企業標準とセキュリティのベストプラクティスを適用します。
Azure Policyを使用して、特定のVM SKUの要求、マネージドディスク暗号化、NSG関連付け、または必須タグ付けなどのルールを適用します。`DeployIfNotExists`効果を使用して、SAP用のVM拡張機能を自動的にインストールします。
理由: Azure Policyは、自動化された大規模なガバナンスを提供し、手動チェックや個別のテンプレート構成に依存することなく、すべてのデプロイメントが準拠していることを保証します。
デプロイされたAzureインフラストラクチャが正しく構成されており、稼働開始前にSAPサポート要件を満たしていることを検証します。
SAP用Azure VM拡張機能（拡張監視）をインストールし、有効にします。GitHubからSAP on Azure Quality Checkツールを実行します。
理由: VM拡張機能はSAPサポートに必須です。Quality Checkツールは、既知のベストプラクティスと要件のリストに対して、構成（ストレージ、ネットワーク、OS設定）を積極的に検証します。
Azure VM上のSAP HANAデータベース向けに、アプリケーション整合性のある自動バックアップソリューションを実装します。
SAP認定のBackintインターフェースを介して統合されるAzure Backup for SAP HANAを使用します。ポイントインタイムリカバリのために、完全/差分バックアップと頻繁なログバックアップを含むポリシーを構成します。
理由: Azure Backupは、カスタムスクリプトや個別のバックアップインフラストラクチャを必要とせずに、バックアップのスケジュール設定、保持、管理を自動化するネイティブで統合された認定ソリューションを提供します。
Azure上で実行されるSAPランドスケープ向けに、包括的な一元化された監視を実装します。
Azure Monitor for SAP Solutionsをデプロイします。SAP HANA、NetWeaver、OS (Linux)、および高可用性クラスターのテレメトリ用のプロバイダーを構成します。
理由: これはSAP向けに設計されたネイティブのAzureサービスです。インフラストラクチャからアプリケーションまで、SAPスタック全体の監視を一元化する豊富なSAP対応テレメトリと視覚化を提供します。
ダウンタイムを最小限に抑えて、高可用性SAPクラスターにOSまたはSAPカーネルパッチを適用します。
ローリングアップデートアプローチを使用します。セカンダリノードをメンテナンスモードにし、パッチを適用し、再起動します。制御されたクラスターフェールオーバーを実行して、パッチが適用されたノードをプライマリにします。最後に、以前のプライマリノードにパッチを適用します。
理由: このローリングアプローチにより、メンテナンスプロセス全体を通してSAPサービスが一方のノードで利用可能な状態に保たれ、ビジネスサービスの中断を最小限に抑えます。
SAPシステムのコピー作成またはリフレッシュ（例：PRDからQASシステムをリフレッシュ）のプロセスを自動化します。
Azure Connectorを備えたSAP Landscape Management (LaMa) を使用します。
理由: LaMaは、Azureインフラストラクチャタスク（VMの停止/開始、ディスクスナップショット）およびSAP固有のコピー後自動化（BDLS）を含むエンドツーエンドプロセスをオーケストレーションし、手作業を大幅に削減します。
本番環境に影響を与えることなく、SAP災害復旧計画を検証します。
Azure Site Recoveryの「テストフェールオーバー」機能を使用します。これにより、レプリケートされたVMが隔離されたVNetに起動されます。HSRの場合、スナップショットベースのリストアを隔離されたシステムまたは専用の第三のレプリケーションターゲットに適用します。
理由: 隔離されたネットワークでのテストは、IPアドレスの競合や本番システムまたは進行中のレプリケーションとの干渉を防ぎ、DRランブックの安全かつ徹底的な検証を可能にします。
Azure上で成長するSAPシステム向けに、将来のリソース要件（CPU、メモリ、ストレージ）を計画します。
Azure MonitorメトリックとLog Analyticsを使用して履歴使用傾向を分析します。このデータを予測に利用します。ストレージに関しては、Azure Managed Disksをオンラインで動的にサイズ変更する機能を活用します。
理由: 履歴データに基づいたプロアクティブな容量管理は、パフォーマンスの低下を防ぎ、ジャストインタイムのプロビジョニングを可能にし、大幅な先行オーバープロビジョニングと比較してコストを最適化します。
完全なSAPランドスケープを実行するためのAzureコストを最小限に抑えます。
本番ワークロードには1年または3年のAzure Reserved Instancesを使用します。非本番システムには、Azure Automationを介して自動開始/停止スケジュールを実装します。対象となるライセンスにはAzure Hybrid Benefitを使用します。
理由: Reserved Instancesは、予測可能で24時間365日稼働するワークロードに対して大きな割引を提供します。自動シャットダウンは、非本番環境のアイドル期間中のコンピューティングコストを削減します。この組み合わせは、両方の主要なコスト要因に対処します。
SAPワークロードのAzureコストを、特定のビジネスユニット、プロジェクト、またはSAPシステム (SID) に追跡および割り当てます。
すべてのAzureリソースに必須のタグ付け戦略を実装します。`CostCenter`、`Environment`、`SAP-SID`、`BusinessOwner`などのタグを使用します。Azure Cost Managementを使用してコストを分析します。
理由: タグ付けは、リソースを分類するためのネイティブなAzureメカニズムです。一貫したタグ付けにより、詳細なコスト分析とチャージバックが可能になり、不可欠な財務可視性が提供されます。
Azure内のSAP VM間の断続的なネットワーク接続またはレイテンシの問題を診断します。
Azure Network Watcherツール、特にConnection Monitorを使用してパスとレイテンシをテストし、NSGフローログを使用してブロックされたトラフィックを分析および特定します。
理由: Network Watcherは、Azureプラットフォームレベルでネットワークの問題を特定するためのプロアクティブなツールとリアクティブなツールを提供します。これは、ゲストOS内からのみでは診断が難しい場合があります。
アプリケーションが正常にシャットダウンされることを確認しながら、SAP VMのOSパッチ適用を自動化します。
Azure Update Managerをプレ/ポストスクリプトとともに使用します。プレスクリプトはSAPアプリケーションとデータベースを停止し、ポストスクリプトはパッチ適用が完了した後にそれらを再起動します。
理由: これにより、Azureのパッチ管理の自動化とSAPに必要なアプリケーション認識が組み合わされ、実行中のシステムにパッチを適用することによって発生する可能性のあるデータの一貫性の欠如を防ぎます。
SUSE/RHEL Linux VM上のSAP Central Services (ASCS/ERS) またはSAP HANAの高可用性を実装します。
Pacemakerクラスターを構成します。スプリットブレインシナリオを防ぐためのSTONITH（フェンシング）には`fence_azure_arm`エージェントを使用し、マネージドIDを介して認証します。
理由: PacemakerはLinuxでSAPがサポートするクラスタリングソリューションです。`fence_azure_arm`は、Azure APIを介して障害が発生したノードを確実に分離するためのAzureネイティブメカニズムであり、安定したクラスターには必須です。
Windows Server VM上のSAP Central Services (ASCS/ERS) の高可用性を実装します。
Windows Server Failover Cluster (WSFC) を構成します。クラスター共有ストレージには、Azure Shared DisksまたはSIOS DataKeeperのようなサードパーティ製のレプリケーションソリューションを使用します。
理由: WSFCはWindowsクラスタリングの標準です。Azure Shared Disksはネイティブの共有ブロックストレージを提供し、SIOSは「共有なし」クラスターを作成します。どちらもクラウドにおける従来のSANの必要性を置き換えます。
SAP HANAの高可用性 (HA) および災害復旧 (DR) 戦略を設計します。
HA（同一リージョン内）には、VMをAvailability Zonesにデプロイし、同期 (SYNC) SAP HANA System Replication (HSR) を使用します。DR（リージョン間）には、非同期 (ASYNC) HSRを使用します。
理由: 同期レプリケーションはRPOゼロを提供しますが、低レイテンシ（2ms未満）を必要とするため、ゾーンを跨ぐHAに最適です。非同期レプリケーションは、より高いリージョン間レイテンシを許容できるため、DRの選択肢となります。
SAP HAクラスター（ASCS/ERSまたはHANA）の仮想IPアドレスを管理するためにAzure Load Balancerを構成します。
Azure Standard Load Balancerを使用します。ロードバランシングルールでFloating IP (Direct Server Return) を有効にします。クラスターによって監視される特定のポート（例：ASCSの場合は620xx）でヘルスプローブを構成します。
理由: ゾーン冗長性にはStandard SKUが必要です。クラスターの仮想IPが正しく機能するにはFloating IPが必要です。特定のヘルスプローブは、トラフィックがアクティブノードにのみ送信されることを保証します。
SAP ASCS高可用性クラスターにおけるEnqueue Replication Server (ERS) の目的を理解します。
ERSインスタンスは、アクティブなASCSインスタンスからのSAPロックテーブルのレプリカを維持します。
理由: ASCSインスタンスがフェールオーバーした場合、新しく起動されたASCSインスタンスはERSからレプリケートされたロックテーブルを取得します。これにより、トランザクションロックが保持され、ユーザーは中断することなく作業を継続できます。
多層SAPランドスケープ向けの完全な災害復旧ソリューションを設計します。
データベース層にはネイティブデータベースレプリケーション（例：HANAの非同期HSR）を使用します。アプリケーション層（ASCS/ERSおよびアプリケーションサーバー）にはAzure Site Recovery (ASR) を使用します。
理由: この「ベストオブブリード」アプローチは、ネイティブレプリケーションを介してデータベースのアプリケーション整合性を確保しつつ、ASRはアプリケーションサーバーVMをレプリケートおよびフェールオーバーするための費用対効果が高く自動化された方法を提供します。
Azure VM上のMicrosoft SQL Serverで実行されるSAPデータベースの高可用性を実装します。
SQL Server Always On Availability Groupsを使用し、通常は同一リージョン内のHA向けに同期コミットモードとWSFCを組み合わせて使用します。
理由: Always On AGは、SQL Server向けに推奨され、完全にサポートされているHA/DRソリューションであり、データベースレベルのレプリケーションと自動フェールオーバー機能を提供します。
2ノードPacemakerクラスターのクォーラムメカニズムとしてSBD (STONITH Block Device) を実装します。
小さなAzure Shared Diskを構成し、両方のクラスターノードにアタッチします。または、3番目のVMに専用のiSCSIターゲットサーバーをセットアップします。
理由: `fence_azure_arm`が主要なフェンシングエージェントである一方で、SBDは特に3番目の投票ノードがないクラスターでスプリットブレインを防ぐための追加のウィットネス/クォーラムメカニズムを提供します。
