メインコンテンツまでスキップ

「aws」タグの記事が2件件あります

全てのタグを見る

· 約7分
片所 宏介

こんにちは。サービス開発部技術基盤部門のSREエンジニアの片所です。

今回は、私が実施したAWSのコストカット施策について紹介したいと思います。 リーディングマークでは、サービスの成長とともにAWSの利用料が増大していました。特に、Amazon Inspectorの利用料が想定以上に高く、ECRのスキャン回数が大きな要因となっていました。 本記事では、ECRのスキャン回数を最適化し、Inspectorのコストを75%削減した具体的な方法を共有します。

AWSにおけるコスト面の課題について​

弊社のプロダクトは、日々多くのユーザーの皆様にご利用いただき、着実に成長を続けています。この成長に応えるべく、開発チームは常にスピード感を持って新機能の開発や既存機能の改善に取り組んでいます。

しかし、サービスの拡大と開発の加速に伴い、私たちはある課題に直面しました。それは、AWSの利用料の慢性的な増加です。特に以下の要因が大きく影響していました。

  1. トラフィックの増加に伴うリソース使用量の増大
  2. 新機能開発や検証のための環境の増設・リソースの増加

1の要因については利用企業の増加（2024年5月時点で約3000社、2025年1月時点で約4000社に増加）に伴うものであるということやインフラ構成の大幅な見直しが必要な可能性があるため、より迅速にコストを最適化するために2の要因に対して優先的に取り組むことにしました。

そのためにまず、AWS利用料の詳細な分析を行いました。その結果、RDSやECSといった主要サービスの次に、Amazon Inspector（以下、Inspector）の利用料が大きな割合を占めていました。Inspectorは弊社のプロダクトに対するセキュリティ面での重要な役割を果たしていますが、その利用料が予想以上に高額であることが判明しました。 そこで、セキュリティレベルを維持しながら、いかにInspectorのコストを最適化できるかという課題に取り組むことにしました。

Amazon Inspectorとは何か​

Inspectorは、Amazon EC2、AWS Lambda関数、Amazon ECRの脆弱性を検出するためのセキュリティサービスです。 弊社では、主にECRの脆弱性スキャンに利用していました。しかし、スキャン頻度と対象リソース数によって利用料が大きく変動するため、最適化の余地がありました。

コストが増大してしまった原因​

ECRにタグなしの古いイメージ（中には１年以上前のものも）が多数残っており、これらが自動で定期的にスキャンされていたため、Inspectorのコストが大幅に増加していました。 主な原因としては、開発初期にイメージのローテーションを実装していなかったことが挙げられます。

今回実施したコストカット方法について​

そこで今回私はコスト削減のために、開発チームと協議のうえ、不要なイメージを削除するライフサイクルポリシーを導入することにしました。 具体的には、ECRのリポジトリ上の「pushから7日以上経過し、タグが付いていないイメージ」を自動削除する設定を行いました。

手順について​

ECRのライフサイクルポリシーを利用し、タグなしのイメージを7日後に自動削除する設定を行いました。 具体的な設定手順については、AWS公式ドキュメントも参考にしてください。https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/LifecyclePolicies.html

*実際に行った設定

note

実装した結果​

この方法を実施した結果、Inspectorの月間利用料を75%削減することに成功しました。また、ECRの利用料も84%削減され、大幅なコスト最適化を実現しました！

note

まとめ​

今回はECRのライフサイクルポリシーを活用し、不要なイメージの削除を自動化することで、InspectorとECRのコストを大幅に削減しました。

Inspectorは強力なセキュリティツールですが、運用方法によってはコストが増大してしまうリスクがあります。セキュリティレベルを維持しつつコストを抑えた運用を行いたい場合は、スキャン回数の最適化をどのように実現するかが重要になります。 もし同様の課題を抱えている方がいれば、一度スキャン頻度やECRの管理方法を見直してみることをおすすめします！

· 約4分
山田 哲也

こんにちは！最近 Terraform にハマっている山田です。

Terraform を使っていて、レシピ集的なものを作ったら結構需要がありそうだなと思ったので、早速記事にしてみることにしました。

今回は、AWS Systems Manager のセッションマネージャーを使ってログイン可能な EC2 インスタンスを作成する Terraform のレシピを紹介したいと思います！

前提知識​

セッションマネージャーとは​

セッションマネージャーは AWS Systems Manager の機能の一つで、EC2 インスタンスに対して SSH などのポートを開けずにブラウザや AWS CLI からインスタンスにログインできる機能です。

SSH の場合ポート以外にもキーペアの管理やセキュリティグループの設定が必要ですが、セッションマネージャーを使うことでこれらの設定を省略することができて非常に便利です。また、よりセキュアに EC2 を利用することができるようになります。

AWS CLI では以下のようなコマンドを実行することで EC2 にログインすることができます。

aws ssm start-session --target <インスタンスID>

Terraform コード​

プロバイダーの設定​

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

IAM ロールとインスタンスプロファイルの定義​

ここでは IAM ロールとインスタンスプロファイルを定義しています。

ポイントは AmazonSSMManagedInstanceCore ポリシーをアタッチすることで、これによってセッションマネージャーを利用することができるようになります。

resource "aws_iam_role" "ec2_role" {
  name = "sample-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Principal = {
          Service = "ec2.amazonaws.com"
        },
        Action = "sts:AssumeRole"
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "ec2_role_policy_attach" {
  role       = aws_iam_role.ec2_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

resource "aws_iam_instance_profile" "ec2_instance_profile" {
  name = "sample-profile"
  role = aws_iam_role.ec2_role.name
}

EC2 インスタンスの定義​

iam_instance_profile に先ほどのインスタンスプロファイルを割り当てることで、セッションマネージャーを使ってログイン可能なインスタンスを作成することができます。

resource "aws_instance" "example" {
  ami                  = "ami-0f36779931e4e31ce"
  instance_type        = "t4g.medium"
  iam_instance_profile = aws_iam_instance_profile.ec2_instance_profile.name

  tags = {
    Name = "ec2-ssm-sample"
  }
}

アウトプットの設定​

アウトプットでインスタンス ID を出力しておくと、terraform apply 後にインスタンス ID がコンソールに表示されるので AWS CLI でログインする際に便利です。

output "instance_id" {
  value = aws_instance.example.id
}

これでコードの作成は完了です！

terraform の実行とログイン​

最後に terraform apply を実行して EC2 インスタンスを作成したら、以下のコマンドでログインできるか確認してみてください。

aws ssm start-session --target <インスタンスID>

今回は内容は以上となります。次回もお楽しみに！