DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

AWSコスト削減の実現：リソース最適化戦略の包括ガイド

タグ付け、適正化、スケジューリング、ストレージライフサイクルルール、スポット利用、Savings PlansでAWSの無駄を削減

AWSコスト削減の実現：リソース最適化戦略の包括ガイド

AWSのコスト削減は、通常、シンプルな問題から始まります。それは、誰も所有せず、誰も使用せず、起動後に誰もリサイズしていないリソースに対して支払いをしていることです。リソース最適化は、推測することなくその無駄を見つけるための再現可能な方法を提供します。

このガイドでは、実践的なAWSリソース最適化に焦点を当てます。タグ付け、コストと使用状況レポート、適正化、インスタンススケジューリング、スポットインスタンス、S3ライフサイクルルール、およびコミットメント割引について説明します。

AWSコスト最適化の基本原則

AWSにおける効果的なコスト管理は、可視性、説明責任、最適化という3つの基本原則に基づいています。リソースの使用状況と関連コストを明確に可視化できなければ、説明責任は不可能であり、最適化の取り組みは散発的で効果が薄くなります。

1. 包括的なタグ付けによる可視性の実現

タグは、AWSリソースに添付するキーと値のペアです。これらは、コストの整理、追跡、管理に不可欠です。一貫性のあるタグ付け戦略を実装することは、詳細なコスト分析のために必須です。

実践可能なタグ付け戦略：

  • 必須タグ： Environment（例：Prod、Staging、Dev）、Owner、Projectなどの必須タグを実装します。これにより、AWS Cost and Usage Reports（CUR）をフィルタリングして、どのチームやアプリケーションがコストを牽引しているかを正確に把握できます。
  • コスト配分タグ： 請求コンソールで特定のタグを有効にして、コスト配分タグとして使用します。これにより、コストレポートにタグが表示されるようになります。

タグ付け実装の例（概念）：

リソース タグキー タグ値
EC2インスタンス Environment Production
RDSデータベース Project CustomerPortalV2
S3バケット Owner security-team

ベストプラクティス： サポートされている場合にリクエストタグを要求するService Control Policiesなどの予防的制御と、フォローアップの是正が必要なリソースに対するAWS Configルールなどの事後的制御を使用して、タグ付けを強制します。

2. コストと使用状況レポート（CUR）による説明責任の確立

AWS Cost Explorerは優れた可視化を提供しますが、Cost and Usage Report（CUR）は最も詳細な明細レベルのデータを提供します。CURデータを定期的に分析することは、外れ値を見つけるための鍵となります。多くの場合、データはS3バケットにエクスポートされ、Amazon Athenaなどのサービスを使用して分析されます。

適正化：リソースを需要に合わせる

クラウドの無駄の最も重大な原因の1つは、過剰プロビジョニングです。つまり、実際のワークロードが必要とするよりも大きなインスタンスやデータベースを実行していることです。

AWS Compute Optimizerの活用

AWS Compute Optimizerは、サポートされているリソース設定と使用率メトリクスを分析し、適正化の推奨事項を提供します。EC2の場合、CloudWatchエージェントまたはサポートされている統合を通じてメモリメトリクスが利用可能な場合、CPU、ネットワーク、ディスク、およびメモリメトリクスを使用できます。

Compute Optimizerが適正化にどのように役立つか：

  • EC2推奨事項： 使用率が一貫して低い場合、より低いインスタンスタイプまたはファミリー（例：M5.xlargeからM5.largeへの移行）を提案します。
  • メモリ対応推奨事項： CPU使用率は低いがメモリ使用率が高いワークロードの場合、メモリメトリクスが利用可能であれば、より適したファミリーを推奨できます。

適正化に関する注意： 常にパフォーマンスの余裕を考慮してください。インスタンスの使用率が一貫して80％以上の場合、適正化によってピーク負荷時にパフォーマンスのボトルネックが発生する可能性があります。適切なバッファを残す目標使用率を目指してください。

EBSボリュームの適正化

インスタンスと同様に、EBSボリュームは、より低いティアで十分な場合でも、多くの場合、高いサイズまたはプロビジョンドIOPS（io2/gp3）でプロビジョニングされたままになります。CloudWatchのVolumeReadOps、VolumeWriteOps、VolumeQueueLengthメトリクスを確認して、より小さいボリュームサイズに安全にダウングレードできるか、またはプロビジョンドIOPS（io2）からGeneral Purpose SSD（gp3）に切り替えられるかを確認します。gp3では、パフォーマンススケーリングを分離できます。

スケジューリングとライフサイクル管理によるコンピュート支出の最適化

非本番環境（Dev、Test、QA）が営業時間中にのみ実行される場合、それらを24時間365日支払うことは不要な無駄です。

インスタンススケジューリング

AWS Instance SchedulerまたはAmazon EventBridge（CloudWatch Events）によってトリガーされるカスタムLambda関数を使用して、定義されたスケジュール（例：午前9時開始、午後7時停止、月曜日から金曜日）に基づいてEC2インスタンスを自動的に停止および起動します。

例：夜間に開発サーバーを停止する（EventBridge/Lambdaを使用した概念）：

  1. EventBridgeルール： 毎日19:00 UTCにトリガーされる定期的なイベントをスケジュールします。
  2. ターゲットアクション： Lambda関数を呼び出します。
  3. Lambdaロジック（Pythonスニペット）： boto3 EC2クライアントを使用して、Environment: Devタグでインスタンスをフィルタリングし、stop_instances()を呼び出します。
import boto3

def lambda_handler(event, context):
    ec2_client = boto3.client('ec2')
    instance_ids = []
    
    # 自動シャットダウン用にタグ付けされたインスタンスをフィルタリング
    response = ec2_client.describe_instances(
        Filters=[
            {'Name': 'tag:Environment', 'Values': ['Dev', 'Test']},
            {'Name': 'instance-state-name', 'Values': ['running']}
        ]
    )
    
    for reservation in response['Reservations']:
        for instance in reservation['Instances']:
            instance_ids.append(instance['InstanceId'])
            
    if instance_ids:
        print(f"インスタンスを停止中: {instance_ids}")
        ec2_client.stop_instances(InstanceIds=instance_ids)
    else:
        print("停止する一致するインスタンスが見つかりませんでした。")

フォールトトレラントなワークロードのためのスポットインスタンスの活用

ステートレスでフォールトトレラントなワークロード（バッチ処理、コンテナ化されたマイクロサービス、CI/CDランナーなど）には、EC2スポットインスタンスを活用します。スポットインスタンスは、未使用のEC2キャパシティをオンデマンド価格と比較して最大90%割引で提供します。2分前の警告で中断される可能性がありますが、EC2 Fleetで設定されたAuto ScalingグループやAmazon EKS/ECSなどのマネージドサービスは、キャパシティをドレインし、代替を起動することで中断を自動的に処理できます。

ストレージとデータ転送コストの最適化

ストレージは、静かに蓄積されることがよくあります。S3ライフサイクルポリシーを管理し、適切なストレージクラスを選択することが重要です。

S3ライフサイクル管理

古くてアクセス頻度の低いデータを、高価なストレージティアに放置しないでください。

  • 移行ルール： 30日後にS3 StandardからS3 Standard-IA（低頻度アクセス）またはS3 Glacier Flexible Retrievalにデータを自動的に移動します。
  • 有効期限ルール： 指定された保持期間後にログや一時ファイルを完全に削除します（例：3年以上前のバックアップを削除）。

データベースの最適化

Amazon RDSを使用している場合は、基盤となるストレージタイプを確認します。

  • IOPSスケーリング： 古いプロビジョンドストレージ（Standardまたはio1）を使用している場合は、gp3への移行を評価します。gp3では、ストレージサイズとは独立してベースラインIOPSをプロビジョニングできるため、高いストレージが必要だがベースラインIOPSが低い場合に、多くの場合、大幅なコスト削減につながります。

コミットメントベースの節約：リザーブドインスタンスとSavings Plans

安定したベースラインインフラストラクチャを適正化したら、使用量をコミットしてボリューム割引を確保します。

AWS Savings Plans（推奨）

Savings Plansは、従来のリザーブドインスタンス（RI）と比較して、よりシンプルで柔軟な方法で大幅な割引（最大72%）を実現します。

  • Compute Savings Plans： インスタンスファミリー、サイズ、リージョン、オペレーティングシステムに関係なく、EC2、Fargate、Lambdaの使用量に自動的に適用されます。これは動的な環境に最適な選択肢です。
  • EC2 Instance Savings Plans： 特定のインスタンスファミリーとリージョンに紐付いた固定割引コミットメントを提供します。Compute Savings Plansよりも制限がありますが、安定したベース負荷には依然として非常に価値があります。

アクションステップ： Cost Explorerで1年および3年のコミットメントの可能性を分析します。経験則として、定常状態（常時オン）の使用量の100%をSavings Planでカバーすることをお勧めします。

継続的な最適化

コスト最適化は、1回限りのクリーンアップではありません。Compute OptimizerとCost Explorerを定期的に確認し、コスト配分タグを健全に保ち、非本番リソースをアイドル時に停止し、安定したベースライン使用量を理解した後にのみコミットメントを購入してください。次の有用なステップは、1つのアカウントまたはワークロードを選択し、それをきれいにタグ付けし、広範な変更を加える前に、その上位3つのコストドライバーを確認することです。