AWS コストの最適化: クラウド インフラストラクチャの請求額を 30 ~ 50% 節約
平均的な組織は、クラウド支出の 32% をアイドル状態または過剰にプロビジョニングされたリソースに無駄にしています。 AWS に月額 5,000 ドルを費やしている企業の場合、年間 19,200 ドルが無駄になります。クラウドのコストの最適化は、手を抜くことではなく、実際に使用した分だけ支払うことです。
このガイドでは、今月の費用を節約する即効性のある方法から、時間の経過とともに節約効果がさらに高まるアーキテクチャの変更まで、AWS のコスト削減戦略の全範囲をカバーしています。
重要なポイント
- インスタンス タイプを実際のリソース使用量に一致させることで、適切なサイジングだけでも 20 ~ 40% を節約できます
- リザーブドインスタンスと Savings Plan は、予測可能なワークロードに対して 30 ~ 60% の割引を提供します
- スポット インスタンスにより、フォールト トレラントなワークロードのコンピューティング コストが 60 ~ 90% 削減されます。
- ストレージ ライフサイクル ポリシーにより、S3 コストの無制限な増加を防止します
コスト最適化フレームワーク
優先順位
最小限の労力で最大の ROI を実現するには、次の順序で最適化します。
- 無駄を排除 (即時、リスクなし)
- 適切なサイズのインスタンス (1 ~ 2 週間、低リスク)
- 価格モデルを使用する (予約プラン、スポットプラン、貯蓄プラン)
- アーキテクチャの最適化 (数か月、エンジニアリングが必要)
ステップ 1: 無駄を排除する
未使用のリソースを見つける
# Find unattached EBS volumes (you are paying for storage with no use)
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query 'Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType}' \
--output table
# Find unused Elastic IPs
aws ec2 describe-addresses \
--query 'Addresses[?AssociationId==null].{IP:PublicIp,AllocationId:AllocationId}' \
--output table
# Find idle load balancers (no targets)
aws elbv2 describe-target-groups \
--query 'TargetGroups[*].{ARN:TargetGroupArn,Name:TargetGroupName}' \
--output table
# Find stopped instances still consuming EBS
aws ec2 describe-instances \
--filters Name=instance-state-name,Values=stopped \
--query 'Reservations[*].Instances[*].{ID:InstanceId,Type:InstanceType,StopTime:StateTransitionReason}' \
--output table
一般的な廃棄物発生源
| 廃棄物発生源 | 一般的な月額費用 | 修正 |
|---|---|---|
| アタッチされていない EBS ボリューム | 1 巻あたり $10 ~ 100 | 削除またはスナップショットを作成して削除 |
| EBS でインスタンスを停止 | インスタンスごとに 20 ~ 200 ドル | AMI を終了または作成する |
| 未使用の Elastic IP | 各$3.60 | リリース |
| 古いスナップショット | $0.05/GB | ライフサイクル ポリシー |
| 特大の NAT ゲートウェイ | ゲートウェイあたり 32 ドル以上 | 統合、VPC エンドポイントの使用 |
| アイドル状態の RDS インスタンス | 50 ~ 500 ドル以上 | dev インスタンスを停止または終了する |
ステップ 2: 適切なサイズ設定
実際の使用状況を分析する
# Get average CPU utilization over the last 14 days
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--start-time $(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%S) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
--period 3600 \
--statistics Average Maximum \
--output json
適切なサイジングの決定マトリックス
| 平均CPU | ピークCPU | アクション |
|---|---|---|
| <10% | <30% | 2 段階のダウンサイズ (例: XL から Medium) |
| 10-30% | <60% | サイズを 1 段階小さくします (例: xlarge からlarge) |
| 30-60% | <80% | 現在の適切なサイズ |
| >60% | >80% | アップサイジングまたは自動スケーリングを検討してください。 |
インスタンスタイプの最適化
| 現在のインスタンス | 適切なサイズ | 毎月の節約 |
|---|---|---|
| m5.xlarge ($140) | m5.large ($70) | $70 (50%) |
| r5.2xlarge ($365) | r6g.xlarge ($146) | $219 (60%) |
| t3.large ($60) | t3.medium ($30) | $30 (50%) |
| c5.xlarge ($124) | c6g.large ($62) | $62 (50%) |
Graviton (ARM) インスタンス (r6g、c6g、m6g) に移行すると、ほとんどのワークロードで同等以上のパフォーマンスが得られ、さらに 20% のコスト削減が実現します。
ステップ 3: 価格モデル
リザーブドインスタンスと Savings Plan の比較
| 特集 | リザーブドインスタンス | 節約計画を計算する | EC2 貯蓄プラン |
|---|---|---|---|
| 割引 | 30-60% | 30-54% | 40-60% |
| 柔軟性 | 特定のインスタンス タイプ/リージョン | 任意のインスタンス ファミリ/リージョン | 特定のインスタンス ファミリ/リージョン |
| コミットメント | 1 年または 3 年 | 1 年または 3 年 | 1 年または 3 年 |
| こんな方に最適 | 安定した予測可能なワークロード | 混合ワークロード | 特定のインスタンス ファミリ |
推奨事項: 柔軟性を高めるために、Compute Savings Plan から始めてください。自信を持って最低限のベースライン使用量を守るようにしてください。
スポットインスタンス
スポット インスタンスでは 60 ~ 90% の割引が提供されますが、2 分前の通知で中断される場合があります。
こんな方におすすめ:
- CI/CD ビルド ランナー
- バッチ処理とデータ パイプライン
- 開発およびステージング環境
- ロード バランサの背後にあるステートレス Web サーバー (オンデマンド フォールバックあり)
良くないこと:
- データベース
- 単一インスタンスのアプリケーション
- チェックポイントを設定しないステートフル ワークロード
# Launch template with Spot Instance
Resources:
SpotFleet:
Type: AWS::EC2::SpotFleet
Properties:
SpotFleetRequestConfigData:
AllocationStrategy: lowestPrice
TargetCapacity: 5
LaunchSpecifications:
- InstanceType: t3.large
ImageId: ami-0123456789abcdef0
- InstanceType: t3.xlarge
ImageId: ami-0123456789abcdef0
- InstanceType: m5.large
ImageId: ami-0123456789abcdef0
ステップ 4: ストレージの最適化
S3 ライフサイクル ポリシー
{
"Rules": [
{
"ID": "ArchiveOldBackups",
"Status": "Enabled",
"Filter": {
"Prefix": "backups/"
},
"Transitions": [
{
"Days": 30,
"StorageClass": "STANDARD_IA"
},
{
"Days": 90,
"StorageClass": "GLACIER"
},
{
"Days": 365,
"StorageClass": "DEEP_ARCHIVE"
}
],
"Expiration": {
"Days": 730
}
}
]
}
S3 ストレージ クラスの料金
| ストレージクラス | GB/月あたりの料金 | 検索 | 最適な用途 |
|---|---|---|---|
| 標準 | $0.023 | インスタント | アクティブなデータ |
| 標準-IA | $0.0125 | インスタント ($0.01/GB 取得) | 月間アクセス |
| 氷河インスタント | $0.004 | インスタント ($0.03/GB 取得) | 四半期ごとのアクセス |
| 氷河 | $0.004 | 1~12時間 | 年間アクセス |
| ディープアーカイブ | $0.00099 | 12時間 | コンプライアンス、長期 |
EBS の最適化
# Convert gp2 volumes to gp3 (20% cheaper, better performance)
for vol_id in $(aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 --query 'Volumes[*].VolumeId' --output text); do
echo "Converting $vol_id from gp2 to gp3"
aws ec2 modify-volume --volume-id "$vol_id" --volume-type gp3
done
ステップ 5: 自動スケーリング
スケジュールベースのスケーリング
ほとんどの B2B アプリケーションでは、営業時間外のトラフィックが 70% 減少します。
# Scale down at night
aws autoscaling put-scheduled-action \
--auto-scaling-group-name production-asg \
--scheduled-action-name scale-down-night \
--recurrence "0 20 * * 1-5" \
--desired-capacity 2 \
--min-size 1
# Scale up in the morning
aws autoscaling put-scheduled-action \
--auto-scaling-group-name production-asg \
--scheduled-action-name scale-up-morning \
--recurrence "0 7 * * 1-5" \
--desired-capacity 5 \
--min-size 3
開発環境のスケジュール設定
勤務時間外に非実稼働環境を停止します。
# Stop dev/staging instances at 7 PM
aws ec2 stop-instances --instance-ids i-dev123 i-staging456
# Start at 8 AM
aws ec2 start-instances --instance-ids i-dev123 i-staging456
毎月の節約: 開発インスタンスを 1 日あたり 24 時間ではなく 10 時間実行すると、58% 節約されます。
月次コストの見直しチェックリスト
- AWS Cost Explorer で異常がないか確認します
- 未使用のリソース (ボリューム、IP、スナップショット) を確認します。
- 適切なサイジングの推奨事項を検証する (AWS Compute Optimizer)
- リザーブドインスタンス/Savings Plan の対象範囲を確認する
- S3 ストレージの増加とライフサイクル ポリシーの有効性を確認する
- データ転送コストを確認します (通常、合計請求額の 10 ~ 15%)
- 自動スケーリングのしきい値が現在のトラフィック パターンと一致することを確認します
- 失敗したデプロイメントから孤立したリソースを確認します
よくある質問
AWS のコスト削減にとって最も手っ取り早い方法は何ですか?
使用されていないリソースを削除します。ほとんどの AWS アカウントでは、接続されていない EBS ボリューム、未使用の Elastic IP、古いスナップショット、停止したインスタンスに月額数百ドルがかかっています。これには 1 時間もかからず、すぐにお金を節約できます。 2 番目に早い方法は、gp2 EBS ボリュームを gp3 に変換することです。20% 低いコストで同等以上のパフォーマンスを実現します。
Savings Plan またはリザーブド インスタンスを使用する必要がありますか?
ほとんどの企業向けの節約プランを計算します。リザーブド インスタンスと同等の割引が提供されますが、柔軟性が高く、特定のインスタンス タイプに固定されません。 EC2 リザーブドインスタンスは、1 ~ 3 年間のインスタンス タイプが確実である場合にのみ使用してください。
プロジェクトまたはチームごとに AWS のコストを追跡するにはどうすればよいですか?
AWS リソースタグを使用します。すべてのリソースに project、team、environment、および cost-center タグを付けます。請求コンソールでコスト配分タグを有効にします。タグごとにグループ化された Cost Explorer レポートを作成して、プロジェクトごとの支出を確認します。タグ付けされていないリソースにフラグを立てる AWS Config ルールを使用してタグ付けを強制します。
コンテナへの移行は費用対効果が高くなりますか?
コンテナーを使用すると、サーバーごとに 1 つのアプリケーションを実行する場合と比較して、リソース使用率が 30 ~ 50% 向上します。 ECS Fargate と EKS はコンテナ管理を簡素化しますが、タスクごとの料金が追加されます。ほとんどの SMB にとって、EC2 と Docker Compose は、シンプルさとコストの最適なバランスを提供します。実装の詳細については、Docker 導入ガイド を参照してください。
次に何が起こるか
コストの最適化は、1 回限りのプロジェクトではなく、継続的に実施されます。毎月のコストレビューをスケジュールし、コスト監視を 生産アラート 設定に統合します。完全なインフラストラクチャ戦略については、中小企業向けの DevOps ガイド を参照してください。
AWS のコスト最適化コンサルティングについては ECOSIRE にお問い合わせ、コスト最適化が組み込まれたマネージド インフラストラクチャについては Odoo サポート サービス をご覧ください。
ECOSIRE が発行 -- 企業のクラウド インフラストラクチャ支出の最適化を支援します。
執筆者
ECOSIRE Research and Development Team
ECOSIREでエンタープライズグレードのデジタル製品を開発。Odoo統合、eコマース自動化、AI搭載ビジネスソリューションに関するインサイトを共有しています。
関連記事
最新のアプリケーションの API ゲートウェイ パターンとベスト プラクティス
スケーラブルな Web アーキテクチャ向けに、レート制限、認証、リクエスト ルーティング、サーキット ブレーカー、API バージョン管理などの API ゲートウェイ パターンを実装します。
CDN パフォーマンスの最適化: グローバル配信を高速化するための完全ガイド
キャッシュ戦略、エッジ コンピューティング、画像の最適化、マルチ CDN アーキテクチャにより CDN パフォーマンスを最適化し、グローバル コンテンツ配信を高速化します。
CI/CD パイプラインのベスト プラクティス: 信頼性の高いデプロイメントへの方法を自動化する
実稼働ワークフローでのテスト、ステージング、デプロイの自動化、ロールバック戦略、セキュリティ スキャンのベスト プラクティスを使用して、信頼性の高い CI/CD パイプラインを構築します。