SAP × AWS / Azure / GCP クラウド構築 2026：ハイパースケーラー上での SAP 運用

SAP S/4HANA をクラウドで動かしたい、というご相談は、ここ2〜3年で急増しています。背景にあるのは、オンプレ機材の保守期限、SAP HANA 認定ハードウェアの選定難、災害対策コストの肥大化、そして「2027年問題」と呼ばれる SAP ECC のメインストリームサポート終了です。経営判断として「クラウド化する」とは決まったものの、選択肢が多すぎて何を選べばよいかわからない、という現場の声を Aurant は数多く受けています。

本記事では、SAP × クラウドの主要4選択肢（RISE with SAP / SAP on AWS / SAP on Azure / SAP on GCP）について、それぞれの位置付け、選定の判断軸、料金感、運用設計、コスト最適化、移行スケジュール、そして見落とされがちな失敗パターンまでを、論理ステップで整理していきます。

1. SAP × クラウドとは — 4つの選択肢の全体像

SAP S/4HANA をクラウドで動かす場合、大きく分けて2つのアプローチがあります。1つ目は「SAP 公式マネージドサービス」（RISE with SAP）を契約する道、2つ目は「ハイパースケーラー上で SAP を自社運用する」（SAP on AWS / Azure / GCP）道です。一見似ていますが、責任分界点が大きく異なります。

RISE with SAP では、インフラ・OS・データベース・SAP ベース層までを SAP 側が責任を持って運用します。利用企業は業務アプリ層（カスタマイズ・帳票・連携）に集中できます。一方、SAP on AWS / Azure / GCP は、ハイパースケーラーが提供する SAP 認定インフラを借りて、自社で SAP の運用を担当します。SAP Basis 専門人材を社内に抱えるか、SI パートナーに委託する必要があります。

選定の本質は、「自社で SAP Basis を運用できるか、運用の責任を SAP に預けるか」の判断です。これを最初に決めないと、ハイパースケーラー選定の議論に進んでも結論が出ません。

2. なぜクラウド化が進むのか — オンプレ運用の4つの限界

SAP のオンプレ運用が限界を迎えている理由は、現場感では4つあります。1点目はハードウェア維持費の上昇で、SAP HANA 認定サーバ（IBM Power、HPE Superdome、Dell PowerEdge）の保守費が年率 5〜10% で上昇しています。5年で 25〜50% コスト増になる計算で、経営判断として無視できないレベルです。

2点目は DR / BCP の対応コストです。災害対策として遠隔地にもう1セット環境を持つと、初期投資・運用費が単純に2倍になります。クラウドであれば、別リージョンへのレプリケーションを比較的安価に組めます。3点目はスケーリングの困難で、月末月初・年度末などの繁忙期だけ性能を上げる、という柔軟な対応がオンプレでは難しいという問題があります。

4点目はアップグレードの長期計画です。SAP HANA / S/4HANA は2〜3年に1回のメジャーアップデートがあり、その度に大規模なハードウェア検証・移行プロジェクトが発生します。クラウドであれば SAP 公式ツールでの自動アップグレードが組めるため、運用負荷が大きく下がります。これら4つの理由が積み重なって、ここ数年で「SAP のクラウド化は避けられない」という共通認識が業界内で形成されてきました。

主な3.択肢の判断フロー — 既存スタックで素直に決めます

4つの選択肢のうち、自社にどれが合うかは、現在の SAP 利用状況と既存クラウド資産で機械的に絞れます。次のフローチャートに従えば、ほぼ自動的に推奨選択肢が決まります。判断軸を曖昧にしたまま「ベンダー比較会」をやると、各社の営業に振り回されて結論が出ません。

4. RISE with SAP — SAP 公式マネージドの安定性とロックイン

RISE with SAP は、SAP がハイパースケーラー上で SAP S/4HANA Cloud を完全マネージド提供する SaaS 型サービスです。「SAP のことは SAP に任せたい」企業に最適で、ECC からの移行込みでパッケージ化されているのが大きな特徴です。日本国内では、特に従業員 1,000人〜10,000人規模の中堅大手企業で採用が増えています。

料金は年額数千万〜数億円規模で、ユーザ数とモジュール構成で決まります。中規模で年額 3,000〜8,000万円、大規模で年額 1〜3億円が標準的なレンジです。一見高額ですが、自社で SAP Basis 専門人材を雇うと年額 1,200〜2,000万円/人 × 3〜5名 = 4,000万〜1億円の固定費になるため、トータルコストでは合理的です。

注意点が2つあります。1つ目はカスタマイズの制約で、RISE は「Fit-to-Standard」を前提としており、既存の独自カスタマイズを全部持ち込もうとすると追加コストや断念が発生します。2つ目はベンダーロックインで、いったん RISE を始めると、SAP 以外への乗り換えコストが極めて高くなります。3〜5年スパンで考える前提が必要です。

5. SAP on AWS — SAP HANA 公式認定 / 高 Memory インスタンス

AWS は SAP HANA 公式認定インスタンスが豊富で、SAP × クラウドのデファクトスタンダードに最も近い位置にいます。注目すべきはEC2 High Memory インスタンス（最大 24TB メモリ）で、最大級の SAP HANA システムを単一インスタンスで動かせます。これは Azure / GCP に対する大きな技術的優位性です。

東京・大阪リージョンの両方で SAP HANA 認定インスタンスが利用可能なため、国内 DR 構成も組みやすくなります。AWS の他サービス（S3、Lambda、Aurora、Glue）との統合が強く、SAP のデータを AWS のデータレイクに連携して分析する構成が組みやすいのも特徴です。

料金面では、Reserved Instance（1年/3年契約）で最大 60〜70% の割引が利きます。本番環境を Reserved Instance、開発・テスト環境を On-Demand で運用する分け方が標準的です。中規模 SAP 環境（ユーザ 500人）で、月額 100〜300万円が目安になります。

6. SAP on Azure — Microsoft 365 統合と Azure for SAP Workloads

Azure はAzure for SAP Workloadsとして、SAP 専用のリソース最適化サービスを提供しています。SAP HANA 認定インスタンス（M シリーズ、Mv2 シリーズ）は最大 12TB メモリで、AWS の High Memory インスタンスより少なめですが、多くの企業の SAP 規模には十分です。

Azure を選ぶ最大の理由はMicrosoft 365 / Power BI / Azure Active Directory との統合です。社内認証を Azure AD に統一している企業や、Power BI で全社レポートを構築している企業では、SAP データを直接 Power BI で可視化できる利点があります。Microsoft 365 + Azure + Dynamics 365 の Microsoft スタック全体を使う企業に最も自然な選択肢です。

日本リージョン（東日本・西日本）も整備されており、Microsoft 公式パートナーが多数あります。日本国内では NTT データ、富士通、ABeam Consulting などが SAP on Azure の主要 SI です。

7. SAP on GCP — BigQuery 統合の優位性

Google Cloud は近年、BigQuery 統合を武器に SAP 利用企業のシェアを拡大しています。SAP S/4HANA のデータを BigQuery に直接ストリーミングして BI / 機械学習で活用する構成が組みやすく、データドリブン経営を進めたい企業に刺さります。

SAP 公式のDatasphere（旧 SAP Data Warehouse Cloud）と BigQuery の連携も強化されており、SAP データと外部データ（広告データ、ウェブ行動データ）を BigQuery で統合分析する構成が現実的になっています。日本国内では、Google Cloud Japan のサポート体制が AWS / Azure に比べて発展途上ですが、Google 系パートナー（クラスメソッド、トップゲート等）が SAP 案件にも対応しています。

8. 移行プロジェクトの段階 — 12〜24ヶ月の標準フロー

Aurant が支援する SAP クラウド移行プロジェクトでは、Phase 3 のデータ移行で想定外の時間がかかるケースが頻発します。10TB 規模のデータを物理回線で転送する場合、SAP 公式の Migration Tool でも数日〜1週間かかります。データ転送計画は Phase 1 の段階で詳細に詰めておく必要があります。

9. クラウドコスト最適化 — 30〜50% 削減の具体策

SAP のクラウド運用コストは、適切に最適化すれば30〜50% の削減が現実的に可能です。具体策は4つあります。1点目は Reserved Instance / Savings Plan の活用で、本番環境のように常時稼働するワークロードは1年/3年契約で 40〜70% 安くなります。

2点目は開発・テスト環境の夜間自動停止です。営業時間外（夜21時〜翌朝7時）と土日に停止すれば、稼働時間が約 1/3 になり、料金もそれに比例します。3点目はスナップショットの世代管理で、不要な古いスナップショットを定期的に削除します。意外に蓄積していて、月額数十万円分のストレージ料金を払い続けているケースがあります。

4点目は SAP のリソースサイジング見直しです。オンプレ時代の「念のため大きめ」サイジングをそのままクラウドに持ち込むと、過剰スペックでコストが膨らみます。AWS / Azure / GCP のモニタリングツールで実際の使用率を見て、3〜6ヶ月運用してからダウンサイジングするのが現実的です。

10. 失敗パターン — 「Lift-and-Shift で終わる」「コスト最適化なし」

SAP クラウド移行が失敗する典型は2つあります。1つ目は Lift-and-Shift で終わるパターンで、オンプレ構成をそのままクラウドに持ち上げただけで満足し、クラウドネイティブな機能（自動スケーリング、サーバーレス、マネージドサービス）を活用しないケースです。これだと「クラウドに引っ越したけど何も改善していない」状態になり、経営層から「クラウド化の意味は?」と問われます。

2つ目はコスト最適化なしで、On-Demand のまま運用してオンプレ時代より高コストになるケースです。Aurant が見てきた中では、適切な最適化なしのクラウド SAP 環境は、オンプレ時代より 1.5〜2倍のコストになることがあります。Reserved Instance、夜間停止、リソースサイジングの3点セットは、Go-Live 後3ヶ月以内に必ず実施します。

11. まとめ — 自社にとっての判断軸

判断のコツは、「既存スタックでクラウド選定」「SAP Basis 運用責任を最初に決める」「Reserved Instance + 夜間停止でコスト最適化」の3点です。クラウド選定は技術判断より経営判断の側面が大きく、3〜5年の TCO で評価するのが現実的です。Aurant Technologies では SAP × クラウド構築のアセスメントから移行支援まで一貫してご提供しています。お気軽にご相談ください。