DEVELOPER’s BLOG
技術ブログ
AWSコスト削減を叶える18個のチェック項目
はじめに
今回は、アクセルユニバースのインフラエンジニアがAWSアカウントのコスト削減を実施する際に利用しているチェックリストをご紹介いたします。
AWSコスト削減チェックリスト
私たちアクセルユニバースのAWSコスト削減チェックリストは
- チェック対象リソース/サービス
- コスト削減観点(状態)
- 手段
の3つの項目から構成されています。 私たちインフラエンジニアはこのチェックリストを元に「クラウド支出の最適化(FinOps)」におけるコストの最適化を実践しております。
| No. | チェック対象 | コスト削減観点(状態) | 手段 |
| 1 | Amazon S3 | 不要な過去ログが溜まっていないか？ | ライフサイクルルールの設定 |
| 2 | Amazon S3 | アクセス頻度と保持期間を予測できていない or 考慮しておらず不適切なストレージクラスを選択してはいないか？ | Standard以外のストレージクラスの選択 |
| 3 | リージョン | 低レイテンシーよりもコスト最適化を優先するか？ | 利用料が安いアメリカのリージョンの選択 |
| 4 | インスタンス | 開発環境等の常時稼働不要なサーバはないか？ | 夜間・土日の停止設定・時間帯ベースのスケーリングを活用 |
| 5 | Amazon EC2 | 既にFargateが常時稼働しているにも拘らず改めてバッション用のEC2を構築してはいないか？ |
バッションとしてのFargateの利用・EC2インスタンスの停止 ※ただし操作ミスなどへの考慮が必要 |
| 6 | Amazon EC2 | 本番環境等の常時稼働必須なサーバはあるか？ | Reserved InstancesやSavings Plansの予約購入 |
| 7 | Amazon RDS | 本番環境等の常時稼働必須なサーバはあるか？ | Reserved Instancesの予約購入 |
| 8 | Amazon ElastiCache | 本番環境等の常時稼働必須なサーバはあるか？ | リザーブドノードの予約購入 |
| 9 | AMI | 最新以外のスナップショットも保存されてはいないか？ | 検討後不要とされたスナップショットの削除 |
| 10 | Amazon EBS | ボリュームタイプに過不足はないか？ | ボリュームタイプの見直し |
| 11 | Amazon VPC |
どのリソースとも紐づけられていないIPアドレスを固定しては いないか？ |
不要なElastic IPアドレスの解放 |
| 12 | Amazon CloudFront |
年間を通して「これ以上は常に使っている」という使用量の 最低ラインが把握できているか？ |
CloudFront Security Savings Bundleの利用 |
| 13 | Amazon CloudWatch | 吐き出されたログが溜まりっぱなしではないか？ |
CloudWatch Logsへの保持期間設定 ※非機能要件への考慮が必要 |
| 14 | AWS Lambda | 必要以上にコンピューティングリソースを構築していないか？ | トリガーやイベント発生検知の設定 |
| 15 | NAT Gateway | 意味もなくNAT Gatewayを通してはいないか？ | 代替手段としてのVPCエンドポイントの利用 |
| 16 | AWS Config | 記録の不要なリソースはあるか？ | 記録対象外リソースとしての指定 |
| 17 | AWS Systems Manager Resource Scheduler | Systems ManagerにてEC2インスタンスの管理をしているか？ | EC2インスタンスへのスケジュールの指定 |
| 18 | AWS Cost Optimization Hub | コスト削減に対する対応が不適切ではないか？ | コスト最適化に関する適切な戦略の特定・推奨 |
こんなお悩みはありませんか？
- クラウド化は実施したが想定よりコストがかかっている...
- コスト削減可能性を感じているが多忙で調査に手が回らない...
そのお悩みアクセルユニバースが解決します！
アクセルユニバースでは、素早くお手頃、でも根本的にAWSコストの最適化を実現します。 AWSコスト削減サービスをお求めの方はこちらまで
関連記事
目次 はじめに：EOL管理、やった方がいいのはわかっているけど...... １.EOL管理には、３つの壁がある ２.Amazon Inspectorと生成AIで実現する、第三の選択肢 ３.実際にやってみました ４.低コスト・低負担で運用を続けられる 結論：EOL管理は、思っているほど大変じゃない はじめに：EOL管理、やった方がいいのはわかっているけど...... EOL(End of Life)をしっかり管理することは、ソフトウェアの
マルチクラウドやハイブリッド環境が当たり前になったいま、SREやDevOpsチームの皆様は、こんな悩みを抱えていないでしょうか。 サービスと環境が増え続け、全体像が誰の頭にもない 各社クラウド・オンプレが入り組み、障害原因の切り分けに時間がかかりすぎる デプロイ起因の障害はコード変更まで追うのが大変 こうした課題を打破するのが、2026年3月に一般提供開始された「AWS DevOps Agent」です。 本記事では、その概要とAIエージェントを真の戦力にす
「生成AIで月◯万時間の削減！」 そんな華々しい成果をニュースで見かけて自社でも生成AIを導入したものの、次のような壁にぶつかっていませんか？ 個人の利用止まりで、組織の業務フロー自体は変わっていない 一部の層はAIを使ってくれるが、全社的に広がっていかない 業務プロセスのどこにAIを組み込むべきか具体化しない こうした悩みは、AI導入におけるアプローチの「前提」に原因があります。 本記事では、この壁を破る新たな手法「AI BPR（AI-driven B
深夜のアラート対応、障害調査のログ突き合わせ、セキュリティ検知のトリアージ。毎月の報告書は「異常なし」なのに、同じインシデントが繰り返される。そんなシステム運用に疲弊していませんか。 原因は担当者の能力でも姿勢でもなく、体制にあります。安定を守る責任が重いほど、改善に割く余力は構造的になくなっていくためです。このことを改善する方法がSRE(Site Reliability Engineering)ですが、必要なエンジニアリングコストの高さが導入の壁でした