近年AWS,Azure,GoogleCloud,OCI,国産系クラウドなど、クラウドサービスを利用するケースが年々増えています。
会社の業務遂行にあたって完全にクラウドを使わない企業は少なくなってきている状況です。
例えば総務省が出している令和6年版のデータから「企業におけるクラウドサービスの利用状況」を見ると2023年時点で何かしらでクラウドサービスを利用していることがわかります。
もちろんこのクラウドサービスは人事,財務会計,給与系といったSaaS系、Google WorkSpace,Microsoft365,Slackなどのグループウェア系のSaaSなども含まれているでしょうが、世の中的にクラウド利用率が高まっているのは事実です。
出典：https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r06/html/datashu.html#f00281
今回はIaaS,PaaSに関して、OCIに言及してクラウドコストを削減する方法を自分なりに検討してみました。
あくまでも私見とはなりますがその点、ご理解の上読んでいただければと思います。
アイデア的にはAWS,Azure,GoogleCloudなど他のパブリッククラウドでも転用できるものもあると思います。
パブリッククラウド従事者にとって当たり前な情報も数多くあると思いますが、コスト削減のアイデアの一助となれば幸いです。
※本記事はあくまでもアイデア出しのため、具体的な設定方法などは記述していないことご了承ください。
費用削減・最適化手法一覧
| No | 費用削減・最適化手法 |
|---|---|
| 1 | 不要リソースの自動検出・クリーンアップ |
| 2 | インスタンスの適正サイズ化と最適化 |
| 3 | バースト可能インスタンスの活用 |
| 4 | インスタンスの自動起動・停止による稼働時間最適化 |
| 5 | ストレージ費用削減のための最適化手法 |
| 6 | サーバーレスやコンテナ技術の利用 |
| 7 | ネットワーク通信コストの最適化 |
| 8 | タグ付けや課金単位の明確化によるコスト管理 |
| 9 | Oracle Cloud Advisorを使ったコスト最適化 |
| 10 | 予算機能でのコスト予実管理とアラート活用 |
| 11 | OCI提供の運用管理系ソフトウェアの活用 |
| 12 | Infrastructure as Code（IaC）による環境構築と運用効率化 |
| 13 | IaaSとPaaSの使い分けとコスト比較 |
| 14 | 適切なインフラ構成の選定 |
| 15 | マルチクラウド・ハイブリッド環境の活用と注意点 |
費用削減・最適化の具体的な手法
不要リソースの自動検出・クリーンアップ
クラウドコスト削減には自動起動・停止も効果的ですが、最も無駄なコスト原因は利用していない不要リソースの放置です。
リソースが不要になった場合、放置するとリソース利用料が発生し続け、無駄な支出に。
手動で削除も可能だが、リソース数が膨大な環境では管理負荷が大きいため、OCIのPython SDKやCLIを活用して以下のリソースを定期的に検出・自動削除する仕組みを構築することが推奨。
- 停止中の不要なコンピュートインスタンス
- 未アタッチのブロックボリューム（ディスク）
- 古いデータベースリソースやスナップショット
これにより、コスト削減だけでなく不要リソースの放置によるセキュリティリスクの低減にも寄与できます。
インスタンスの適正サイズ化と最適化
CPUやメモリの使用状況を定期的に監視し、過剰にプロビジョニングされたインスタンスを適切なサイズに縮小する。
OCIのフレキシブル・シェイプやオートスケーリング機能を活用して、需要に応じたリソース調整を行うことで無駄を削減可能。
・フレキシブル・シェイプについて
スペックに関してユーザ側で任意のCPU × メモリの組み合わせが可能。
インスタンス起動後でもリサイズも可能。
他社には多数のスペックの組み合わせがあるが、あくまでも選択肢の中から選択する必要がある点と比較しても自由度が高い。
（=必要分のスペックにすることで余分なリソース使用量を支払う必要がない点でもコストメリットがあると言える）
参考：https://speakerdeck.com/ocise/ociji-shu-zi-liao-konpiyutosabisu-gai-yao?slide=9
バースト可能インスタンスの活用
通常のCPU使用率が低く、時折CPUスパイクが発生するようなワークロードでコストを最適化できる仮想マシン（VM）インスタンス。
ベースラインとなるCPU使用率（12.5%または50%）を選択し、この割合分のOCPU料金＋メモリ料金で利用できる点が特徴。
・メリット：
通常時のCPU消費が低いワークロードでコストを大幅に削減可能。
ベースライン12.5%を選択すれば、通常料金の1/4。50%を選択すれば、OCPU料金を通常料金の1/2に削減可能。
Windows OSライセンス費用もベースライン同様に減るため、Windowsインスタンスでもコスト圧縮が期待できる。
・デメリット：
ベースラインを超える分のバーストは「物理ホストや全体のリソース状況次第」であり、必要な時に必ずバーストできる保証がない。
常に安定してフルOCPU分のパフォーマンスが必要な業務システムや本番環境には不向き。
参考：https://speakerdeck.com/ocise/ociji-shu-zi-liao-konpiyutosabisu-gai-yao?slide=27
インスタンスの自動起動・停止による稼働時間最適化
Compute、各種データベースに関して、使用しない時間帯（夜間・休日など）にインスタンス等のリソースを停止し、稼働時間を削減する。
これにより、OCPU時間に関わる課金を大幅に節約可能。
※検証、開発環境での利用を推奨
OCI CLIとcron/タスクスケジューラを使った自動化
管理用の小型サーバ（例: OCI Always Freeインスタンス）にOCI CLIをインストール
下記コマンドをシェルスクリプト化し、Linuxならcron、Windowsならタスクスケジューラなどで実行時間（夜間停止・朝起動など）を設定
- 起動・停止コマンド例：Computeの起動停止
- 起動：
oci compute instance action --action START --instance-id <インスタンスOCID> - 停止：
oci compute instance action --action SOFTSTOP --instance-id <インスタンスOCID>
- 起動：
・メリット：
柔軟性が高く、細かいカスタマイズや複雑なロジックにも対応可能
複数クラウドや他サービスとの連携自動化も容易
・デメリット：
管理用のサーバやcron環境の維持が必要（その分のコストや障害リスクあり）
スケジュールの修正や追加が煩雑になりやすい
【参考】過去にWindowsでやったことがあるので実施したい場合は参考にしてください。
OCI Resource Scheduler サービスの活用
OCI Web管理コンソールからスケジュールポリシーを作成し、対象リソースを自動的に起動・停止が可能です。
・メリット：
専用サーバやcron環境なしでOCIサービスだけで簡単に自動化できる点
・デメリット：
利用可能な対象リソース限られている点
→現在のサポート状況はコンピュート / コンピュート・インスタンス・プール / Autonomous Databases / Function
独自要件や複雑な制御には柔軟性がやや低い
関数サービスやAPI連携自動化
OCI FunctionsなどサーバレスでLambda的な仕組みを使い、時間トリガでインスタンス起動・停止のAPIを自動実行
他サービスと連携したイベント駆動（例："業務終了"のSlackボタン押下等）も組み合わせ可能
・メリット：
スケーラビリティや冗長性に優れる
他のOCIサービスや外部連携のトリガと合わせやすい
・デメリット：
関数作成やAPI仕様把握、セキュリティ管理などの学習コストが必要
他と手法と比べると実装難易度が高い
ストレージ費用削減のための最適化手法
オブジェクトストレージ
AWSで言うところのS3
オブジェクトストレージについて頻繁にアクセスするデータはスタンダードストレージ、アクセス頻度の低いデータはアーカイブストレージや自動階層化のブロックボリュームを利用し、ストレージコストを削減する。
オブジェクトのライフサイクル機能を使うことで「指定した日数が経過したオブジェクトを自動的にアーカイブ or 削除」することも可能。
ログデータ等で利用することでコストの微減につながる。
参考：https://speakerdeck.com/ocise/ociji-shu-zi-liao-obuziekutosutorezi-gai-yao?slide=19
ブロックボリューム
AWSでいうところのEBS。
ブロックボリュームについては容量とVPU(=性能)を再確認。
大きく4段階の性能に分けることができる。
価格の安い"より低いコスト"であっても性能としてはAWS gp3のデフォルトIOPSと同程度の性能のため、費用を抑えるためにはブロックボリュームの性能についても検討する必要あり。
※ブートボリュームはデフォルトの"バランス"のみサポート
参考：https://speakerdeck.com/ocise/ociji-shu-zi-liao-burotukuboriyumu-gai-yao?slide=12
サーバーレスやコンテナ技術の利用
処理に応じてOracle FunctionsやOracle Kubernetes Engine（OKE）、Container Instancesを活用し、使用状況に合わせた柔軟なリソース利用でコスト最適化を図る。
・Functions
「Oracle Functions」はサーバ管理不要のFaaS環境で、コードの実行時間とリクエスト数に応じた従量課金制。
バックグラウンド処理やイベント駆動型処理に適し、使わない時間帯は課金されないためコスト効率が良い。
運用や開発工数が削減できる一方、コールドスタート遅延や実行回数の制限には注意が必要。
・Oracle Kubernetes Engine (OKE)
OKEはマネージドKubernetes環境を提供し、コンテナアプリを柔軟にスケール可能。
必要な分だけリソースを割り当てるため過剰なリソース投資を防止し、複雑なワークロードに最適。
ただしKubernetesの運用管理には専門知識が必要。
・Container Instances
OCI Container Instancesはサーバレスコンテナ実行環境で、サーバー管理不要で即座にコンテナを起動可能。
シンプルかつ迅速、特に短期間のバッチやテスト環境、軽量なマイクロサービスの実行に適している。
Kubernetesほど複雑でなく、手軽に使えるサーバレスコンテナ環境を提供。
エフェメラルストレージ15GB 等、いくつか制限事項があるため、ワークロードに適しているか要検討。
ネットワーク通信コストの最適化
OCIは比較的ネットワークコストは他社クラウドと比較して安価ではありますが、ユースケースにより再提起なものを検討する必要があります。
インターネット接続、VPN接続、FastConnectの3パターンあり。
参考：https://speakerdeck.com/ocise/ociji-shu-zi-liao-wai-bu-jie-sok-gai-yao?slide=3
インターネット接続
グローバルIP通信で、性能はベストエフォートとなる。
必要となるインターネット・ゲートウェイの利用料は無償。
別途、外部データ転送料金の対象に含まれるが、1テナンシあたり10TB/月までは無償枠あり。（VPNと同枠）
VPN接続（IPsec VPN）
IPsec VPNを通じてオンプレミスネットワークをVCNにセキュアに接続するマネージドVPNサービス。
VPNのサービス料金は無償。
別途、外部データ転送料金の対象に含まれるが、1テナンシあたり10TB/月までは無償枠あり。（インターネット接続と同枠）
性能はベストエフォートとなるが、コスト面ではFastConnectに比べると軍配があがる。
ユースケースに応じて選択する必要あり。
FastConnect（閉域網サービス）
オンプレミスとOCI間のデータ転送コストが無償。
別途、FastConnect利用のためのポート料金(定額)が発生するが予測可能な課金体系。
セキュリティ面 / 性能面で閉域網サービスが必須の場合はFastConnect一択。
ただし、そうではない場合はVPN接続も検討に。
タグ付けや課金単位の明確化によるコスト管理
OCIではリソースに「タグ」を付与して管理でき、これがコストの細分化や可視化に役立ちます。
・タグは部門、プロジェクト、環境（開発・テスト・本番）などで分類可能。
・組織全体で統一されたタグ付けルール（スキーマ）を策定し、タグの漏れを防ぐために自動付与や強制適用を導入することが重要。
・タグ情報に基づき、コスト分析や予算管理、課金割当を正確に行えるため、どの部門やプロジェクトがどれだけコストを使っているか明確になる。
・タグ管理は運用ガバナンスの強化にもつながり、無駄なリソース利用防止にも効果的。
参考：https://speakerdeck.com/ocise/oci-kosutoguan-li?slide=7
Oracle Cloud Advisorを使ったコスト最適化
OCIの無償ツール「Cloud Advisor」を使うことでコストの適正化を図ることができます。
AWSでいうところのTrusted Advisorです。
Cloud Advisorの機能
-
リソース効率の分析
テナンシ内の全OCIリソースを毎日スキャン。不十分に活用されているリソースや、オーバープロビジョニング、設定ミスなどの非効率を自動検出。 -
コスト削減提案
未使用のインスタンスや過剰サイズのリソースの縮小・削除、不要なディスクの解放など、具体的な施策・見積効果を提案。 -
ダッシュボード画面による高い可視性
各種ガイドをダッシュボードで表示。
各推奨事項を画面からそのまま直接実装/実行することが可能。
参考：https://speakerdeck.com/ocise/oci-kosutoguan-li?slide=37
予算機能でのコスト予実管理とアラート活用
予算機能を設定し、コストの予実管理で無駄使いを早期発見。
コンパートメント単位・タグ単位で月額などの予算枠を設定し、消費状況を通知させることが可能。
例えば定点監視的な使い方とし閾値を30%,60%,90%等いくつか作成しておくことで、想定通りの利用推移になっているかを監視することが可能。
参考：https://speakerdeck.com/ocise/oci-kosutoguan-li?slide=33
OCI提供の運用管理系ソフトウェアの活用
OCIには各種サービスの監視、ログ収集、セキュリティ対策、バックアップのサービスが提供されています。
多くのサービスは無償、利用も簡単で比較的導入もしやすいです。
オンプレミスで使っていたサービスをそのまま利用する場合、運用は変わらず、運用のしやすさは一定担保されると思います。
ただし各種ソフトウェア用のComputeやライセンス費用、（ここでは言及しませんが運用管理費用）が発生します。
無償で利用できる運用管理系サービスはクラウドベンダーが提供しているものを積極的に使っていくことを推奨します。
（特にMonitoring,Logging,Notificationsなどは汎用的で便利なサービスだと個人的には思います）
Infrastructure as Code（IaC）による環境構築と運用効率化
以下一般論となりますが、IaCを利用するメリットです。
・自動化による効率向上・工数削減
手動作業を大幅に省け、多くの工数・オペレーションコストを削減できます。これ自体が間接的なコストダウン効果となります。
・一貫性のある環境構築
IaCを使えば、全てのリソース構成がコード化され、再現性・追跡性が大幅に向上します。
これにより意図しないリソース追加や設定ミスが減り、不要なコスト増を未然に防ぐことが可能。
・バージョン管理・運用の標準化
IaCファイルはGit等でバージョン管理でき、変更履歴のトレースやレビューも容易。
複数担当者でも標準化された方法で環境を再現できるため、属人化や運用ミスによる余計な課金リスクが減少します。
参考：https://speakerdeck.com/ocise/ociji-shu-zi-liao-risosumaneziya-resource-manager-gai-yao?slide=3
IaaSとPaaSの使い分けとコスト比較
誤解を恐れずに言うと、PaaSサービスは利便性が高い反面、一般的にIaaSよりコストが高くなる傾向があります。たとえば、MySQL、PostgreSQL、OpenSearch、Redisなどのデータベースや検索エンジンは、OCIのPaaSで提供されていますが、同じ構成をIaaSで自分たちで構築した場合、請求金額は低く抑えられます。
ただし、IaaSは環境構築や継続的な安定運用に専門知識と工数が必要なため、構築コスト・運用コストが増加します。
そのため、コスト面だけ重視するのであれば、大胆にIaaSを選ぶのも有効と記載させていただきます。
ただし、運用効率を考慮するとPaaSの利便性や管理の簡便さは無視できません。
利用予定のPaaSをIaaSで構築できる技術力やナレッジがある場合の選択肢として検討してください。
特にOCIのComputeリソースは、フレキシブル・シェイプ機能によってCPUやメモリを自由にカスタマイズできるため、IaaS環境であってもリソースを最適化してコストを削減しやすい特徴があります。
信頼性を担保するインフラ設計とコスト最適化
冗長化（レプリケーションや多重化）やディザスタリカバリ（DR）は、インフラ設計における信頼性や可用性向上のために不可欠な要素ですが、同時にコストに大きな影響を及ぼします。
ビジネス要件に応じて、復旧時間目標（RTO）や復旧ポイント目標（RPO）に基づいて最適なDRレベルを選定することが重要。
例えば「常時アクティブ構成」、「ウォームスタンバイ（コールドスタンバイ）」、「定期的なバックアップのみ」といった段階的な冗長化手法を採用し、必要以上のインフラ投資を回避することがポイント。
また、冗長構成では縮退時の性能も十分に検討する必要あり。
障害発生時に想定される縮退状態での処理能力が業務要件を満たすかを確認し、不必要な過剰構成によるコスト浪費を防ぐことが重要。
OCIではフルスタックディザスタリカバリ（Full Stack DR）などのネイティブサービスを活用することで、大規模な環境でも効率的かつシンプルにDR計画を実装可能。
これにより、障害時の迅速な復旧や安定したサービス提供を実現しつつ、コストの最適化にも寄与。
参考：https://speakerdeck.com/oracle4engineer/fsdr-overview
マルチクラウド・ハイブリッド環境の活用と注意点
OCI単独だけでなく、AWSやAzureなど他クラウドと併用することでコストとパフォーマンスの最適化を図る戦略。
・コスト最適化
ワークロードごとに最適なクラウドを選択することでコスト効率を追求。
例：計算集約型はOCI、AIや分析はAWS/Azureなど。
複数クラウドの価格優位性を活かして全体でのコスト削減を狙うことが可能。
・リスク分散と可用性向上
単一クラウド障害時の影響を軽減。データやアプリを複数環境に分散し、業務継続性を確保。
・ベンダーロックイン回避
マルチクラウド戦略はベンダーロックインを回避することが可能。
必要に応じてクラウド間でのリソース移動や最適化を図り、リスク分散にもつながる。
※マルチクラウド利用における注意点として運用管理の複雑化、クラウド間のデータ連携については各クラウドの外部転送費用やネットワークレイテンシにも影響が出るため、それらも含めて検討する必要がある
最後に
最後に、本記事で紹介したクラウドコスト削減・最適化の手法は、どれも単発の施策ではなく継続的な取り組みが必要です。クラウド環境は日々変化し、使い方や技術も進化します。
そのため、定期的なリソースの見直しや運用の自動化、そして運用ルールの見直しを継続して行うことで、はじめて効果的なコスト最適化が実現できます。
また、クラウドの利便性を活かしつつコストを抑えるには、クラウドネイティブなサービスの活用と自社の業務・技術力に合った適切なリソース選定が重要です。
コスト削減は経営課題と直結しており、IT部門だけでなく経営層や現場部門とも連携しながら推進することが望まれます。
この記事が皆様のクラウド活用の一助となれば幸いです。