AWS認定資格 WEB問題集&徹底解説

ソリューションアーキテクト – アソシエイト

AWS Fargate の概要と試験出題ポイントは?

AWSサービスの一つであるAWS Fargateはどんな内容なのでしょうか?また、AWS認定資格のソリューションアーキテクト-アソシエイト(SAA)に合格するためには、サービスのどんなポイントを押さえておけばよいのでしょうか?
ここでは、そんなあなたの疑問に回答していきたいと思います

AWS Fargate 徹底解説 | AWS認定試験の頻出ポイントまとめ

1. サービス概要

AWS Fargateは、コンテナを実行するためのサーバーレスコンピューティングエンジンです。 EC2インスタンスのプロビジョニング・パッチ管理・スケーリングなどのインフラ管理をAWSに委ねることで、 開発者はコンテナ化されたアプリケーションの構築とデプロイに専念できます。

FargateはAmazon ECS(Elastic Container Service)とAmazon EKS(Elastic Kubernetes Service)の起動タイプ(Launch Type)として動作します。 オーケストレーション層にECS/EKSを選択し、その実行基盤としてFargateを指定することで、 ノード管理なしのコンテナ実行環境を実現します。

主なユースケースは、マイクロサービスAPIバックエンド、Webアプリケーション、バッチ/スケジュールジョブ、 機械学習推論、サーバーレスコンテナ環境での開発/ステージング環境です。

2. 主な特徴と機能

2.1 サーバーレスコンテナ(EC2管理不要)

Fargateでは、EC2インスタンスのプロビジョニング・スケーリング・パッチ適用・セキュリティグループ管理が不要です。 タスク定義にCPU/メモリを指定するだけで、Fargateが自動的に必要なキャパシティを確保・解放します。 各Fargateタスクは専用の分離されたカーネルで実行され、他のタスクとのリソース共有がありません(セキュリティの隔離性が高い)。

2.2 ECS との統合

ECSでFargateを使う場合、起動タイプ「FARGATE」を指定してサービスまたはスタンドアロンタスクを起動します。

  • タスク定義: CPUとメモリ(組み合わせは事前定義済み)、コンテナイメージ、ポートマッピング、環境変数、IAMタスクロールを設定。
  • サービス: 指定した数のタスクを常時維持(Auto Scalingと連携してスケール)。
  • スタンドアロンタスク: バッチ処理・定期ジョブに最適。EventBridgeスケジュールと組み合わせて定時実行。

2.3 EKS との統合

EKSでFargateを使う場合、Fargate Profileを定義して、条件に一致するPodをFargate上で実行します。 EC2ノードグループとFargateを混在させることも可能(例: 通常ワークロードはFargate、GPUが必要なワークロードはEC2)。

2.4 リソース設定(CPU・メモリ)

Fargateタスクは以下のCPU/メモリの組み合わせから選択します(ECS Fargate):

  • 0.25 vCPU: 0.5GB〜2GB
  • 0.5 vCPU: 1GB〜4GB
  • 1 vCPU: 2GB〜8GB
  • 2 vCPU: 4GB〜16GB
  • 4 vCPU: 8GB〜30GB
  • 8 vCPU / 16 vCPU: 大容量ワークロード向け(2023年以降対応)

2.5 Fargate Spot

Fargate Spotは、スポットキャパシティを使ってFargateタスクを最大70%割引で実行できる機能です。 中断可能なバッチ処理やCI/CDパイプライン、テスト実行などに適しています。 容量不足や価格上昇時にAWSからタスク停止通知(2分前)が来るため、グレースフルシャットダウンの実装が必要です。

2.6 ネットワーキング(awsvpc モード)

FargateタスクはECSのawsvpcネットワークモードを使用します(必須)。 各タスクに専用のElastic Network Interface(ENI)とプライベートIPアドレスが割り当てられ、 セキュリティグループをタスク単位で設定できます。 パブリックIPの割り当ては任意(プライベートサブネット + NATゲートウェイでのアウトバウンド接続も可能)。

2.7 ストレージ

  • エフェメラルストレージ: デフォルト20GB(最大200GBまで拡張可能)。タスク終了時に削除される一時領域。
  • Amazon EFS統合: タスク定義でEFSボリュームをマウントすることで永続ストレージを実現。ステートフルなコンテナに対応。

2.8 Graviton(ARM)対応

Fargate on AWS Graviton(ARM64アーキテクチャ)をサポート。x86-64比で最大20%コスト削減・高パフォーマンス。 タスク定義でCPUアーキテクチャ(X86_64 / ARM64)を指定します。

3. アーキテクチャおよび技術要素

  1. コンテナイメージ: Amazon ECRまたは外部レジストリからコンテナイメージを取得。ECRプライベートリポジトリ+VPCエンドポイントでセキュアに取得可能。
  2. タスク定義: CPUとメモリ、コンテナイメージURI、ポート、環境変数、IAMタスクロール、ログ設定(CloudWatch Logsへ)を定義。
  3. ECSサービス/EKS Fargate Profile: タスク起動の制御・スケーリングを担うオーケストレーション層。
  4. awsvpcネットワーク: 各タスクに専用ENI+IPが割り当て。セキュリティグループはタスク単位で制御。
  5. ロードバランシング: ALB/NLBとターゲットグループを使ってトラフィックを各タスクに分散。
  6. オートスケーリング: ECSサービスのAuto Scaling(ターゲット追跡、ステップスケーリング)でタスク数をスケール。

Fargateは、EC2インスタンスクラスターの代わりにAWS管理のインフラ上でコンテナを分離実行します。 ノードグループ・クラスターキャパシティの管理が不要で、DevOpsの負担を大幅に軽減します。

4. セキュリティと認証・認可

  • IAMタスクロール: タスク定義に割り当てるIAMロール。コンテナ内のアプリケーションがS3・DynamoDB等のAWSサービスにアクセスする際の権限を制御。EC2のインスタンスプロファイルに相当。
  • IAM実行ロール(Task Execution Role): ECSエージェントがECRからイメージを取得・CloudWatch Logsにログを送信するための権限。タスクロールとは別のロール。
  • タスク単位セキュリティグループ(awsvpc): 各タスクに独立したSGを付与し、最小権限のネットワークアクセス制御を実現。
  • VPC統合: プライベートサブネット内での実行でインターネット直接露出を回避。NATゲートウェイ経由でアウトバウンドアクセス。
  • Secrets Manager / Parameter Store統合: 環境変数として機密情報をハードコードせず、起動時に安全に注入。
  • コンテナイメージのスキャン: Amazon ECRのイメージスキャン機能で脆弱性を事前検出(プッシュ時スキャン)。
  • ネットワーク暗号化: Fargate上のコンテナ間通信にTLSを使用することを推奨。

5. 料金形態

Fargateはタスクが実際に実行された時間と割り当てたリソースに対して課金されます:

  • vCPU時間: 割り当てたvCPU数 × タスク実行時間(秒単位)で課金。
  • メモリ時間: 割り当てたメモリ量(GB)× タスク実行時間(秒単位)で課金。
  • エフェメラルストレージ: 20GB超の分について課金(デフォルト20GBは無料)。
  • Fargate Spot: 通常Fargateより最大70%割引。中断リスクあり。
  • OS/アーキテクチャ: LinuxとWindowsで料金が異なる。Graviton(ARM)はx86より安価。

EC2と比べて、インフラ管理コスト(人件費)を削減できますが、 常時稼働のワークロードではEC2リザーブドインスタンスが安価な場合があります。

6. よくあるアーキテクチャ・設計パターン

  • マイクロサービスAPIバックエンド: 各サービスをFargateタスクとしてデプロイ。ALBのパスベースルーティングで各サービスに振り分け。Fargate + ECS + ALBの標準構成。
  • バッチ/定期ジョブ: EventBridgeスケジュールからECSタスクを直接起動。終了するとコスト0。Fargate Spotで大幅コスト削減。
  • CI/CDパイプライン: CodePipeline + CodeBuildでビルド→ECRにプッシュ→ECSサービスを更新(ローリングデプロイ/Blue/Green)。インフラ管理レスで素早くデプロイ。
  • Fargate + EFS(永続ストレージ): CMSやアップロードファイルをEFSに永続化。タスク再起動後もデータが保持される。
  • EKS on Fargate(サーバーレスKubernetes): Kubernetesの利便性を維持しながらノード管理を排除。Fargate ProfileでPodを選択的にFargate上で実行。

7. 設定・デプロイ手順(ハンズオン例)

  1. Amazon ECRにコンテナイメージをプッシュ(`docker build` → `docker push`)。
  2. ECSコンソールで「タスク定義の作成」→ 起動タイプ「FARGATE」、CPUとメモリを選択。
  3. コンテナ設定でイメージURI、ポートマッピング、環境変数、IAMタスクロールを設定。ログはCloudWatch Logsへ転送設定。
  4. ECSクラスターを作成(Fargateクラスターはインフラ不要)。
  5. ECSサービスを作成:タスク定義、希望タスク数、VPC/サブネット(プライベート推奨)、セキュリティグループ、ALBターゲットグループを設定。
  6. Auto Scaling設定でCPU使用率やカスタムメトリクスに基づきタスク数をスケールアウト/イン。
  7. デプロイ後、CloudWatch Logsでログを確認し、ALBのDNS名でアクセスを検証。

8. 試験で問われやすいポイント

8.1 FargateとEC2起動タイプの違い

  • Q: Fargateを使う最大のメリットは?
    A: EC2インスタンスのプロビジョニング・管理・パッチ適用が不要。サーバーレスでコンテナを実行でき、インフラ管理コストを削減。
  • Q: FargateとEC2起動タイプでコスト差が出るのはどんな場合?
    A: 常時稼働・高使用率ではEC2リザーブドインスタンスが安価な場合がある。変動負荷・バーストはFargateが有利。

8.2 ネットワークモードと IAM ロール

  • Q: FargateタスクのネットワークモードはEC2タイプと同じか?
    A: Fargateは必ずawsvpcモード(各タスクに専用ENIとIP)を使用。セキュリティグループをタスク単位で設定可能。
  • Q: コンテナ内からS3にアクセスするにはどのような設定が必要か?
    A: タスク定義にIAMタスクロール(Task Role)を設定し、適切な権限(s3:GetObject等)を付与する。
  • Q: タスクロールとタスク実行ロールの違いは?
    A: タスクロールはコンテナアプリがAWSサービスにアクセスする権限。実行ロール(Task Execution Role)はECSエージェントがECRからイメージ取得・CloudWatch Logsにログ送信するための権限。

8.3 Fargate Spot

  • Q: Fargate Spotが適するワークロードは?
    A: バッチ処理・テスト・CI/CDなど中断を許容できる処理。最大70%のコスト削減が可能。
  • Q: Fargate Spotのタスクが中断されるときどうなるか?
    A: 2分前に停止通知(SIGTERM)が送られる。グレースフルシャットダウンを実装して処理を安全に終了させる必要がある。

8.4 ECSサービス vs スタンドアロンタスク

  • Q: 常時起動のAPIサービスと定期バッチ処理、それぞれFargateでどう実現するか?
    A: 常時起動はECSサービス(希望タスク数を維持)。定期バッチはEventBridgeスケジュール→ECSタスク直接起動(スタンドアロンタスク)。

8.5 ストレージ

  • Q: Fargateタスクのデフォルトストレージは何GBか?
    A: 20GB(タスク停止時に削除されるエフェメラルストレージ)。最大200GBまで拡張可能。
  • Q: Fargateで永続ストレージを使うには?
    A: タスク定義でAmazon EFSボリュームをマウント。タスク再起動・入れ替え後もデータが保持される。

8.6 EKS on Fargate

  • Q: EKSでFargateを使う設定は?
    A: Fargate Profileを作成し、namespace/labelセレクターで条件を定義。条件に一致するPodがFargate上で実行される。
  • Q: EKS Fargateの制約は?
    A: DaemonSetは使用不可(ノードがないため)。StatefulSet + EBSボリュームは不可(EFSは可能)。特権コンテナは使用不可。

8.7 セキュリティ

  • Q: コンテナに機密情報(DBパスワード等)を安全に渡すには?
    A: Secrets ManagerまたはSSM Parameter Storeに格納し、タスク定義のsecrets/environmentで参照。ハードコード禁止。
  • Q: Fargateタスクのコンテナ間でリソースは共有されるか?
    A: 各タスクは専用の分離カーネルで実行され、他タスクとのリソース共有なし。高いセキュリティ分離性を持つ。