DataHubの統合では、DoiTチームが非常にハンズオンで、私たちが前に進めるよう、最初の取り込みスクリプトとパイプラインまで組んでくれたほどです。
Kyle Espinola, プラットフォームエンジニアリング責任者
AWSコミットメント最適化
AWS Savings Plans。大きな賭けは、もう不要。
EC2、Fargate、Lambdaに対応するAWS Compute Savings Plansと、Aurora、RDS、DynamoDBなどに対応するDatabase Savings Plansを、小さなステップで自動的に購入。各ステップは時間単位の使用状況と照合されます。
Compute Savings Plans · Database Savings Plans · 自律実行または承認ベース
AWS · Savings Plans · last 90 days
Effective Savings Rate
32.8%
▲ 6 pts this quarter
Coverage
84%
Utilization
99.3%
CommittedHourly usage
Purchase schedule · laddered
Compute Savings Plan · EC2, FargateOct 1 · $18/hr · 1 yrExecuted
Compute Savings Plan · LambdaOct 15 · $3/hr · 1 yrApproved
Database Savings Plan · Aurora, RDSNov 1 · $6/hr · 1 yrAwaiting approval
Next step, if usage holdsNov 15 · sized at the timePlanned
Each step is checked against fresh hourly usage before it executes.
ラダー方式の仕組み
小さなステップで。 大きな賭けはしない。
1つの予測と1つの有効期限にカバレッジを集中させるのではなく、Savings Planをラダー(段階)方式で購入し、次のステップに進む前に、各ステップを最新のAWS使用状況と照合します。
無料削減分析を受けるEffective Savings Rate · last 6 months
31.4%, and climbing
18.2%
21.5%
24.9%
27.3%
29.8%
31.4%
Coverage
82%
Utilization
99.1%
Saved this quarter
$412K
One view of ESR, coverage and utilization across clouds.
対象のAWSサービス
Compute Savings PlansとDatabase Savings Plansを、1つのワークフローで。
5つのコンピューティングサービスと、12のデータベース・キャッシュ・検索・移行サービスを、同じラダー型プランから最適化。カバレッジは、対応する世代、エンジン、デプロイタイプ、リージョンに関するAWSの適用条件に従います。
Compute Savings Plans5 services
Amazon EC2
AWS Fargate
Amazon ECS
Amazon EKS
AWS LambdaDatabase Savings Plans12 services
Amazon Aurora
Amazon RDSAurora Serverless v2Aurora DSQL
DynamoDB
DocumentDB
Neptune
Keyspaces
Timestream
ElastiCache for Valkey
OpenSearch Service
AWS DMS他のツールは一括前払いを迫る
だから、ラダー方式。
初日に購入した3年のSavings Planは、EC2、Fargate、Lambdaの使用量が決して減らないことを前提にしています。ラダー方式なら各ステップを小さく、常に最新の状態に保てるため、カバレッジがワークロードに追従します。
The big bet
“Buy three years of coverage today.”
Based onOne forecast
If usage dropsYou pay anyway
Utilization74% by month 9
PerfectScale for Commitments
“Buy what holds, then buy again.”
Based onHourly usage, every hour
If usage dropsThe next step shrinks
Utilization99.1%
財務
資金が動く前に承認。
FinOps
報告できるESR。
エンジニアリング
ペナルティなしでスケールダウン。
経営層
ロックインなしの削減。
コミットメントの全サイクル
AWSコミットメントの全サイクルを、1か所で
Compute Savings Plans
EC2、Fargate、Lambdaを1時間ごとに再評価。
Database Savings Plans
Aurora、RDS、DynamoDB、Valkey、DocumentDB、Neptuneなどに対応。
購入前の影響確認
コミット前に予測カバレッジと履歴を確認。
自律実行または承認ベース
しきい値と上限を設定し、購入の実行方法を選択。
リスクを考慮したペース制御
AWSコミットメントのカバレッジが拡大する速度をコントロール。
実効削減率(ESR)
使用率と無駄を差し引いた、実際に達成できる割引率。
数時間で推奨案を提示
AWSコミットメント最適化の仕組み
1
請求データを接続。
クラウドの請求アカウントを連携すると、使用状況の分析がすぐに始まります。
2
ガードレールを設定。
支出上限、ペース、カバレッジ目標、承認ルールを設定します。
3
ラダーで段階購入。
購入は小さなステップで実行され、各ステップは最新の使用状況と照合されます。
SOC 2 Type 2、ISO 27001、FinOps認定プラットフォーム。
無料削減分析を受ける公開されている製品情報を2026年7月31日時点で確認。「公開情報なし」は、ベンダーによる対応の明示が確認できなかったことを意味します。
AWSコミットメント管理を並べて比較
| Capability | PerfectScale | ProsperOps | Opsima | nOps |
|---|---|---|---|---|
| コミットメントのカバレッジ | ||||
| Compute Savings Plans | EC2、Fargate、Lambda | EC2、Fargate、Lambda | EC2、Fargate、Lambda | EC2、Fargate、Lambda |
| 同一プラットフォームでのGoogle Cloudコミットメント管理 | Google Cloud CUD | マルチクラウド | 非対応 OpsimaはGoogle Cloud対応を今後提供予定としています。 | Google Cloud CUD |
| Database Savings Plansの対象サービス | ||||
| Amazon AuroraおよびAmazon RDSインスタンス | 対応 | Early Access | RDSとAuroraを記載 Database Savings Plansの自動化は明示的に文書化されていません。 | 対応 |
| Aurora Serverless v2 | 対応 | Early Access | Auroraを記載 Serverless v2への対応は個別に明示されていません。 | 対応 |
| Aurora DSQL | 対応 | Early Access | 公開情報なし | 対応 |
| DynamoDB | 対応 | Early Access | DynamoDBを記載 Database Savings Plansの自動化は明示的に文書化されていません。 | 対応 |
| ElastiCache for Valkey(インスタンスおよびサーバーレス) | 対応 | Early Access | ElastiCacheを記載 Valkeyおよびサーバーレスの対象範囲は個別に明示されていません。 | 対応 |
| Amazon DocumentDB(インスタンスおよびサーバーレス) | 対応 | Early Access | 公開情報なし | 対応 |
| Amazon Neptune(インスタンス、サーバーレス、Analytics) | 対応 | Early Access | 公開情報なし | 対応 |
| Amazon Keyspaces | 対応 | Early Access | 公開情報なし | 対応 |
| Amazon Timestream | 対応 | Early Access | 公開情報なし | 対応 |
| AWS DMS(インスタンスおよびサーバーレス) | 対応 | Early Access | 公開情報なし | 対応 |
| Amazon OpenSearch Service | 対応 | Early Access | OpenSearchを記載 Database Savings Plansの自動化は明示的に文書化されていません。 | 対応 |
| 自動化とガバナンス | ||||
| 購入実行前の承認 | 購入ごとの承認(任意) | 設定可能なガードレール 公開資料では自律的な実行が強調されています。 | 自律型マネージドモデル 公開資料ではハンズオフの実行が強調されています。 | 自律実行ファースト 公開資料ではフルオートパイロットが強調されています。 |
| 完全自律型の最適化 | 利用可能 | 利用可能 | 利用可能 | 利用可能 |
| 段階的なコミットメント購入 | インテリジェントなラダー方式 | Adaptive Laddering | ダイナミックレイヤリング | アダプティブレイヤリング |
| 支出とリスクのガードレール | 上限、しきい値、ペース制御 | リスクと予算のコントロール | マネージドリスクポリシー | リスクを考慮した自動化 |
| 再評価とレポーティング | ||||
| 使用状況の継続的な再評価 | 1時間ごと | 継続的 | 継続的 | 1時間ごと |
| 実効削減率(ESR)のレポート | ESR、使用率、カバレッジ | ESRダッシュボード | 増分削減ダッシュボード | ESRと純削減額のトレンド |
| コミットメント管理のその先へ | ||||
| フルFinOpsプラットフォーム | Cloud Intelligence™ コスト可視化、配賦、ガバナンス、最適化、クラウドの専門知識。 | FinOps自動化プラットフォーム 料金最適化、ワークロード連携、レポーティング、ショーバック。 | AWSコミットメント専業 公開されている製品資料は料金最適化に特化しています。 | FinOpsプラットフォーム コスト管理、配賦、コミットメント、ワークロード最適化。 |
| クラウドリソースのタグ付けに依存しないコスト帰属 | Attribute™ タグのカバレッジを必要とせず、コストを顧客やビジネスディメンションにマッピング。 | Intelligent Showback コミットメントのコストと削減額をアカウント、リソースタイプ、リージョン別に配賦。 | AWSネイティブの配賦 公開されているガイダンスは、AWSの請求ディメンション、カテゴリ、タグに依存しています。 | 自動配賦 請求とワークロードのメタデータを用いて、タグなしコストや共有コストを配賦。 |
| Kubernetesワークロードの最適化 | PerfectScale for Kubernetes Podのライトサイジング、ビンパッキング、オートスケーリング、継続的な最適化。 | Flexera Ocean経由 Kubernetesワークロードとコミットメントの統合最適化。 | 料金最適化のみ インフラを変更せずにEKSのコンピューティングコミットメントをカバー。 | EKS最適化 ノード、Pod、料金の最適化。 |
| Snowflakeワークロードの最適化 | PerfectScale for Snowflake ウェアハウスの自動最適化、ワークロードインサイト、コスト可視化。 | 記載なし | 記載なし | コスト可視化と配賦 Snowflakeコストの取り込みは文書化されていますが、ワークロード自動化は文書化されていません。 |
| Databricksワークロードの最適化 | PerfectScale for Databricks コンピューティングコストの自動削減、ワークロードインサイト、DBUの可視化。 | 記載なし | 記載なし | コスト可視化と配賦 Databricksコストの取り込みは文書化されていますが、ワークロード自動化は文書化されていません。 |
| BigQueryワークロードの最適化 | PerfectScale for BigQuery 予約、スロット、クエリ最適化のインサイトとワークロード可視化。 | Alvinとのパートナーシップ経由 パートナー主導によるBigQueryのクエリと予約の最適化。 | 記載なし | コスト可視化と配賦 Google Cloudのコスト分析は文書化されていますが、ワークロード自動化は文書化されていません。 |
Native capabilityPartial / preview / via integrationNot available
What they say
IBMとAWSのプライベート接続こそ、確実に成功させなければならない部分であり、自分たちだけで進めるよりも速く動きたいと考えていました。DoiTは選択肢を一緒に検討し、ルーティングを妨げていたサブネットの重複を突き止めて、接続を安定させてくれました。それがすべての突破口になったのです。
DevOps Lead, Software Projects
Attribute™のプラットフォームはまさに唯一無二です。今では、ワークロード・テナント単位でクラウド支出を明確に把握できるようになりました。このインサイトは、サービスをさらに拡大していくうえで、すでに実効性のあるコスト削減と強力な知見につながっています。
Paul White, Shasta Cloud エンジニアリング担当VP
DoiTとは長年にわたって協業していますが、DoiT Cloud Intelligenceの機能は年々充実しています。Cloud AnalyticsやReportsといった機能を自社のFinOpsプロセスに組み込んでおり、今では私たちの業務の中核になっています。
Martin Lee, オペレーションディレクター
DoiTのおかげで、実証段階から本番運用へと踏み出す確信を持てました。現実の業務で使えるAIを、正しい形で構築する方法を教えてくれたのです。
Milad Rezazadeh, CTO
Frequently asked
questions
PerfectScaleはどのAWSコミットメントを管理しますか?
PerfectScaleは、Amazon EC2、AWS Fargate、AWS Lambda向けのCompute Savings Plansを管理します。さらに、AuroraおよびRDSインスタンス、Aurora Serverless v2、Aurora DSQL、DynamoDB、ElastiCache for Valkey(インスタンスおよびサーバーレス)、DocumentDB(インスタンスおよびサーバーレス)、Neptune(インスタンス、サーバーレス、Analytics)、Keyspaces、Timestream、DMS(インスタンスおよびサーバーレス)、Amazon OpenSearch Serviceを対象とするDatabase Savings Plansも管理します。
AWSにおいて、PerfectScaleはProsperOpsとどう違いますか?
どちらの製品も、Compute Savings Plansと幅広いDatabase Savings Plansのカバレッジに対応しています。ProsperOpsは2026年6月にDatabase Savings Plansの自動化をEarly Accessとして発表しました。PerfectScaleは一般提供されており、さらにCloud Intelligence™内で購入ごとの承認(任意)を利用できます。
PerfectScaleはOpsimaとどう違いますか?
Opsimaの現在の製品ページには、EC2、ECSとFargate、Lambda、RDS、Aurora、ElastiCache、OpenSearch、DynamoDBが記載されています。Database Savings Plansの全対象サービスやデプロイバリエーションのすべてが公開されているわけではありません。PerfectScaleは対応範囲の全体を文書化しており、承認ベースの実行(任意)に加えて、AWSとGoogle Cloudの両方のコミットメント管理を提供します。
PerfectScaleはnOpsとどう違いますか?
どちらの製品も、Compute Savings Plansと幅広いDatabase Savings Plansのカバレッジを公開文書に記載しています。PerfectScaleの違いは、購入ごとの承認(任意)と、Cloud Intelligence™およびDoiTのクラウド専門知識との連携にあります。
自律的な購入を必ず有効にする必要がありますか?
いいえ。各購入の前に承認を必須にすることも、完全に自律実行させることもできます。承認しきい値、支出上限、ペース制御により、チームが安心できる運用モデルを適用できます。
AWSの使用状況が変化した場合はどうなりますか?
PerfectScaleは1時間ごとに使用状況を再評価します。段階的な購入により、プラン全体をある時点の予測に固定するのではなく、次のステップを増やす、減らす、一時停止するといった判断の機会が繰り返し得られます。