AWS Fargateの運用ノウハウ10選

こんにちは！
株式会社カンリーでSREをやっている井上です。

カンリーではワークロードとして主にAWS Fargate, AWS Batch, Lambda, Amplifyなどを利用しています。おおよそ3年ほど前（2022年頃）から作り始めたプロダクトはAWS Fargateを中心に構築しており、それに伴って運用ノウハウも多く蓄積されてきました。この記事ではAWS Fargateと付随するAWSサービスの運用ノウハウを紹介できればと思います！

【コスト・パフォーマンス】 アーキテクチャはARMを利用するほうがお得

OSをLinuxとする場合、デフォルトのアーキテクチャはX86_64となります。
X86_64とARMの料金は以下のとおりです。
（リージョンは東京、2025年10月時点）

Architecture	X86_64	ARM
1 時間あたりの vCPU 単位	USD 0.05056	USD 0.04045
1 時間あたりの GB 単位	USD 0.00553	USD 0.00442

ARMの方が約20%ほどコスト削減が可能なので、X86_64を使う特別な要件がなければこちらのほうがコストメリットが出ます。また、一般的にARMの方がパフォーマンス観点でも良いです。

カンリーではGitHub ActionsでCI/CDを実現していますが、ARM64のRunnerを準備してビルドしています。こちらもデフォルトでは用意がないので、新しく作る必要がある点はご注意ください。
なおビルドでもQEMUを利用するよりか高速です。

【コスト・可用性】 Fargate Spotインスタンスは思ったよりダウンする

Fargate Spotインスタンスはオンデマンドより70%ほどコスト削減が見込め、大変魅力的です。
ただよくダウンします。。。めっちゃ落ちます。。。
（経験則で定性的なので実際のところは不明です）

当然Fargate Spotインスタンスを設定するときには、Capacity Provider および Capacity Provider Strategyにて戦略を決定しますが、最低限ワークロードを維持するためにオンデマンドを設定しておくこととスケール時のSPOTとの組み合わせを考慮できるとよいかと思います。

【セキュリティ・コスト】 パブリックイメージの取得先はAmazon ECR Public Galleryから

サイドカーなどでパブリックイメージを直接利用するケースがあるかと思います。AWS Fargateの場合はタスク定義にてイメージを指定すると、そこからインターネットへイメージを取得しに行きます。
特に制限なければこの方式で問題ありませんが、Docker Hubで未認証ユーザーの場合はPull Rate Limitが適用されます。詳細はこちらです。

Amazon ECR Public Galleryのイメージに変更すると内部リソース（AWS Fargateも含む）のpull制限は10 回／秒／リージョンでDocker Hubよりも使いやすい制限になっています。詳細はこちらです。

なお、インターネットからイメージを取得することには変わりないので、Nat Gatewayなどの料金が高騰する可能性は残ります。それらは後述するPull Through Cacheを読んでみてください！

【セキュリティ】 Trivyを利用すればコンテナイメージの脆弱性をビルド時に検知できる

前述したとおり、カンリーではCI/CDをGitHub Actionsで実行しています。
ワークフローでイメージビルドしたあとにaquasecurity/trivy-actionにてscan-type: 'image'を利用して、デプロイするイメージをスキャンしています。
Amazon Inspectorなどでも代替できるかと思いますが、GitHub Actions上で低コストにて実現できる方法としてTrivyを採用しています。
なおTrivy (Aqua Security)はSecurityHubとも統合可能なため、AWS環境と一緒に脆弱性に対応できる点も魅力的です。

なおTrivy DBをghcr.ioからpullすると、上記と同じくRate Limitにて制限されるケースがあります。その場合は事前にTokenを生成して認証を通すか、Amazon ECR Public Galleryのイメージを使うことなどでも回避できます。
以下のように環境変数でイメージ取得先を変えることも可能です。

        env:
          TRIVY_DB_REPOSITORY: public.ecr.aws/aquasecurity/trivy-db
          TRIVY_JAVA_DB_REPOSITORY: public.ecr.aws/aquasecurity/trivy-java-db

【可用性】 オートスケールはポリシーを組み合わすことができる

AWS Fargateに限らず、スケーリングは可用性を実現するうえで最も簡単な手段かと思います。
Amazon ECSの場合は、Application Auto Scalingを利用してスケーリングが可能です。
Application Auto Scalingの種類には以下3つがありますが、リクエスト量やキャパシティによって変更できるのは上2つです。

• ターゲット追跡スケーリング (Target Tracking Scaling)
• ステップスケーリング (Step Scaling)
• 予測スケーリング (Scheduled Scaling)

この2つは組み合わせて利用することも、個別で設定することも可能です。

カンリーではなるべく全体のCPUが50%になるようなターゲット追跡スケーリング、一気にトラフィックが発生した場合に備えたステップスケーリングを設定することでキャパシティの緩急に関わらず可用性を担保するオートスケールを実現しています。

なお組み合わせ時の挙動としてスケールアウト時は台数が多いポリシーが適用され、スケールイン時は台数が少ないポリシーが適用されます。

【可用性】 ヘルスチェックを適切に設定することでタスクの開始・終了をコントロールできる

タスクの開始はデプロイされてからターゲットにトラフィックが流れるまでHealthCheckIntervalSeconds x HealthyThresholdCountの秒数で計算されます。
デフォルトだと30s * 5回 = 150sになります。
デプロイの開始から完了までを早くしたい場合は、ヘルスチェックの間隔と回数を減らすことで短縮することができます。

タスクの終了はタスク定義のstopTimeout、ターゲットグループのderegistration_delayによって変わります。こちらはターゲットグループのタイムアウトも考慮しなければいけません。

より早く開始・終了させたい場合はこれらの値をチューニングしましょう。

【モニタリング】 タスクのエラーはイベントで検知する

タスクの状態変更はイベントが送信されたあとEventBridgeで検出することが可能です。
カンリーでは主に以下を検知させています。

• ECS Task State Change
  • SpotInterruption
• ECS Deployment State Change
  • CannotPullContainerError
  • ECS deployment circuit breaker: task failed to start.

SpotInterruptionはFargate Spotの停止を検知できます。
CannotPullContainerErrorはECRからpullできない場合に検知できます。
ECS deployment circuit breaker: task failed to start.はデプロイサーキットブレーカーが発動し、リビジョンが巻き戻ったことを検知できます。

このようなイベントを検知させることで、トラブルシュートにおける状況把握を確実にしレスポンスタイムの向上に寄与できるようになります。

【コスト】 VPC EndpointやPull Through Cacheは損益分岐点を考えて設定する

VPC EndpointのInterface型の料金は、以下のとおりです。
（リージョンは東京、2025年10月時点）

• 各 AZ の VPC エンドポイント 1 つあたりの料金 (USD/時間) -> 0.014 USD
• 処理データ 1 GB あたりの料金 (USD, 最初の 1 PB) -> 0.01 USD

Nat Gateway経由でインターネットに通信する場合と、VPC Endpoint経由で通信する場合とでは通信量200GBが損益分岐点になります。
そのため200GBを超えることが想定される場合にはVPC Endpointを設定しましょう。

またインターネット経由でパブリックイメージを取得する場合はPull Through Cacheも有効です。これは都度インターネットにイメージを取得しに行くのではなく、1度目だけ取得してキャッシュする仕組みです。24時間に一度最新版が無いか確認し、ある場合は更新してくれます。

ECRにキャッシュされるため、VPC Endpoint経由で取得すると1度目以外はNat Gatewayの通信量がかかりません。

なおVPC Endpointは、以下3つを設定してください。

• com.amazonaws.${region}.ecr.dkr
• com.amazonaws.${region}.ecr.api
• com.amazonaws.${region}.s3

【CI/CD】 SOCIv2を利用してデプロイ速度を向上させる

SOCIスナップショッターは、コンテナイメージの遅延読み込み (lazy loading) を可能にするcontainerdプラグインです。
従来の方法では全レイヤーをダウンロードしてからコンテナを起動していましたが、SOCIを使用することで必要な部分のみを先にダウンロードし、起動時間を大幅に短縮できます。

使用する場合は事前にSOCI Snapshotterを入手し、コンテナイメージとSOCIインデックスをECRにプッシュすればOKです。
詳細はこちらです。

カンリーの場合は15sくらいの改善が見受けられましたが、イメージ総量やどれくらいインデックスできるかで結果は変わりそうです。

【AI】 （おまけ） Amazon ECS MCP Serverを用いると簡単にデプロイができるらしい

AIによって自動でローカルにあるものをデプロイできるみたいです。
詳細はこちらをご確認ください。

おわりに

SREとしては信頼性を保つためにあらゆる観点からFargate運用のあり方を見直してきました。
これからもアップデートを続け、最適解を見つけ続けていこうと思っています！