# ベストプラクティス 17.5 – コスト効率を高める目的でオンデマンドキャパシティの使用を検討する オンデマンド料金モデルは、短めの運用時間、短期プロジェクト、試験的運用が必要となる、または (例えばパフォーマンステストのために) 短期間だけ容量を拡張する必要がある SAP ワークロードに適しています。使用している SAP アーキテクチャのどこでオンデマンド料金が利用できるかを特定します。 **提案 17.5.1 – 年中無休 24 時間体制を必要としない SAP システムでのオンデマンドの利用を評価する** オンデマンド料金モデルとその他の料金モデルを利用した場合の損益分岐点に基づいて ([信頼性]: [ベストプラクティス 18.1 - Amazon EC2 の利用可能な支払いおよび契約オプションを理解する](best-practice-18-1.md) )、オンデマンドの方が低コストかどうかを評価します。この評価では、Savings Plan 契約全体も考慮に入れます。 一般的なユースケースとしては、営業時間または短期のビジネス実験 (トライアルアップグレード、概念実証など) 以外には必要でない非本番稼働システムが挙げられます。 + SAP on AWS ブログ: [SAP システムの起動停止自動化を AWS Systems Manager で実現](https://aws.amazon.com/blogs/awsforsap/automate-start-or-stop-of-distributed-sap-hana-systems-using-aws-systems-manager/) **提案 17.5.2 - ピーク負荷に備えてスケジュールされたスケーリングオプションと動的スケーリングオプションを評価する** オンデマンドキャパシティは、通常、容量要件が短期間だけ急上昇したピークの SAP ワークロードで使用されます。以下の点を考慮してください。 + 期間、月末、年末、季節性ピークなど、使用パターンが既知である場合のピークには、スケジュールベースの SAP アプリケーションサーバースケーリングを使用します。 + ピークがより不確実でユーザー負荷に合わせてリアルタイムでスケーリングする必要があるアプリケーション層には、動的スケーリングを適用します。SAP 対応で、必要なガバナンスとコントロールを備えたメカニズムを検討します。 **注記:** アプリケーション層の動的スケーリングを評価する際は、ステートフルな SAP コンポーネントが原因で SAP アプリケーションサーバーがシャットダウンされた場合にユーザー接続とバッチジョブ影響が受ける影響を考慮します。この要件への対処には、AWS、SAP、APN パートナーの開発によるツールが役立ちます。 + AWS ドキュメント: [Systems Manager オートメーションアクションのリファレンス](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-actions.html) + SAP ドキュメント: [SAP Landscape Management (SAP 環境管理)](https://www.sap.com/products/landscape-management.html) + SAP on AWS ブログ: [Using AWS to enable SAP Application Auto Scaling (AWS を使用した SAP アプリケーションのオートスケーリングの有効化)](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/)