ExamRoll
Japanese
EnglishFrenchSpanishDeutschPortuguese (Brazil)ItalianDutchPolishRussianTurkishJapaneseKoreanChinese SimplifiedChinese TraditionalPortuguese (Portugal)CzechIndonesianSlovakThaiVietnameseSwedish
試験に合格する →

Amazon SAA-C03: コンテナとオーケストレーション — 学習ガイド

By Laurynas Brazys · · #amazon #saa-c03 #certification #exam-prep #study-guide

こちらの一部です： AWS SAA-C03 — 完全学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

ECSとEKS、EC2とFargateの選択

AWS上のコンテナワークロードにおける最初のアーキテクチャ決定は、オーケストレーターとコンピューティングモードの選択です。Amazon ECSはAWS独自のオーケストレーターで、IAM、ALB/NLB、CloudWatch、Service Discovery、VPCネットワーキングと緊密に統合されています。コントロールプレーン料金はかからず、Kubernetes固有のツールを必要としないチームにとっては、本番環境への最速のパスです。タスクはライフサイクルを共有する1つ以上のコンテナの単位であり、サービスはスケジューラによって管理される長期間実行されるタスクのセットです。Amazon EKSはアップストリーム準拠のKubernetesをクラスターあたり1時間0.10ドルの固定料金で実行します。ワークロードのポータビリティを維持する必要がある場合、Kubernetes APIを使用する場合、またはCNCFエコシステム（Helm、CRD、Operator）を活用する場合に正しい選択です。コントロールプレーン（APIサーバー、etcd、コントローラーマネージャー、スケジューラー）は、AWSによってパッチ適用、バックアップ、および3つのAZにわたる高可用性が実現されます。

どちらのオーケストレーターも2つのコンピューティングモードを受け入れます。AWS Fargateは、各タスクまたはポッドを分離されたFirecrackerマイクロVM上で実行します。パッチを適用するAMIも、調整するAuto Scaling Groupキャパシティプロバイダーも、ビンパッキングの決定も、SSHでアクセス可能なホストもありません。タスクのvCPU秒とGB秒ごとに料金を支払います。EC2起動タイプ / マネージドノードグループは、インスタンスを自身で所有することを意味し、それに伴う柔軟性と運用上の負担が伴います。

Fargateは、「サーバーレス」、「最小限の運用オーバーヘッド」、「管理するインフラストラクチャがない」といったシナリオで正しいデフォルト選択です。ただし、ワークロードがその制約（タスクあたり最大16 vCPU / 120 GBメモリ、GPUなし、特権コンテナなし、DaemonSetsなし、HostPort/HostNetworkなし、Windowsホストレベルのカスタマイズなし）に適合する場合に限ります。GPU、ホストアクセスを必要とするDaemonSets、カスタムAMI、GMSAを使用するWindows Serverコンテナ、秒単位未満のビンパッキング効率、または積極的なSpotベースのコスト最適化が必要な場合は、マネージドノードグループまたはEC2起動タイプを選択します。

要件適切な選択
Kubernetes API + アップストリームツールEKS
最もシンプルなAWSネイティブのオーケストレーターECS
インフラストラクチャ管理が不要Fargate（どちらのオーケストレーターでも）
GPU、DaemonSets、カスタムカーネルモジュールマネージドノードグループ / EC2
GMSAを使用するWindowsコンテナEC2起動タイプ
スケールしたSpotベースのコスト最適化Spotを利用したマネージドノードグループ
EKSでのEBSバックの永続ボリュームマネージドノードグループ
バースト的で予測不可能なポッドFargate

よくある罠は、EC2ノードが「安く感じる」という理由で選択してしまうことです。スパイクのある、または使用率の低いワークロードの場合、アイドル状態のキャパシティ、AMIのパッチ適用、ノードのドレイニング、クラスターオートスケーラーの設定にかかるエンジニアリング時間を考慮すると、Fargateの方が安価になることがよくあります。これらはすべてFargateが不要にするものです。

タスク定義、配置、およびキャパシティプロバイダー

標準的なECS Fargateタスク定義は、CPU/メモリのサイジング、イメージのプルとログ書き込みのための実行ロール、awsvpcネットワークモード、CloudWatch Logsへの接続といった基本事項を定義します。

family: checkout-service
requiresCompatibilities: [FARGATE]
networkMode: awsvpc
cpu: "1024"
memory: "2048"
executionRoleArn: arn:aws:iam::111122223333:role/ecsTaskExecutionRole
containerDefinitions:
  - name: checkout
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/checkout:1.4.2
    portMappings: [{ containerPort: 8080 }]
    logConfiguration:
      logDriver: awslogs
      options:
        awslogs-group: /ecs/checkout
        awslogs-region: us-east-1

EC2上のECSでは、タスク配置戦略がタスクをインスタンス間にどのように分散させるかを決定します。これらは順に構成されます。

戦略動作一般的な用途
spreadフィールド（例: attribute:ecs.availability-zone）全体に均等に分散AZをまたいだ高可用性（HA）
binpackCPUまたはメモリによって最小限のインスタンスに集約コスト最適化
randomランダム配置ほとんどの場合不適切

distinctInstanceやクラスタークエリ言語を使用したmemberOfなどの配置制約により、候補がさらに制限されます。

キャパシティプロバイダーは、サービスを素のAuto Scaling Groupから切り離します。FARGATEとFARGATE_SPOTはマネージドプロバイダーです。カスタムプロバイダーはASGをラップし、マネージドスケーリングを有効にすることで、ECSがプロビジョニングされたタスクの数に基づいてASGの希望する数を調整できるようにします。キャパシティプロバイダーストラテジーは、重みとベースに基づいてタスクを分割します。例えば、オンデマンドのFargateタスクを2つ保証し、残りを中断耐性のあるワークロードのためにFargate Spotと1:4の比率で分割します。

capacityProviderStrategy:
  - capacityProvider: FARGATE
    base: 2
    weight: 1
  - capacityProvider: FARGATE_SPOT
    weight: 4

オートスケーリング: ポッド、タスク、およびノード

Fargateはノード管理を不要にしますが、タスクやポッドの数を自動的にスケールするわけではありません。この違いは、Fargateに関する最もよくある誤解の一つです。サーバーレスはホスト層に適用されるものであり、サービスの希望する数には適用されません。サービスレベルのオートスケーリングは依然としてユーザーの責任です。

ECSでは、Application Auto Scalingを使用します。ターゲット追跡は、スケールアウトおよびスケールインのCloudWatchアラームを自動的に作成し、クールダウン期間を尊重するため、慣用的なデフォルトです。適切なメトリクスは、ECSServiceAverageCPUUtilization、ECSServiceAverageMemoryUtilization、およびALBRequestCountPerTargetです。

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 --max-capacity 30

aws application-autoscaling put-scaling-policy \
  --policy-name cpu-target-50 \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
    '{"TargetValue":50.0,"PredefinedMetricSpecification":{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}}'

ステップスケーリングとスケジュールされたスケーリングは、非線形の応答曲線や既知のトラフィックウィンドウに対して引き続き利用可能です。

EC2ノード上のEKSでは、ポッドの次元はHorizontal Pod Autoscaler（HPA）によって処理されます。HPAはCPU、メモリ、またはカスタムメトリクスに基づいてレプリカ数を調整します。HPAだけではノードを追加できません。クラスターのキャパシティを超えてレプリカを増やしてしまい、その時点で新しいポッドはFailedSchedulingイベントとともにPending状態になります。そのため、EC2上のHPAは、常にKubernetes Cluster AutoscalerまたはKarpenterのいずれかと組み合わせる必要があります。この組み合わせを忘れることは頻繁に起こる設計ミスです。HPAは「20レプリカにスケールしました」と報告しますが、その半分はPending状態でスタックしています。最小限のCluster Autoscaler設定は、ASGタグを介してノードグループを検出します。

- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/prod-eks
- --balance-similar-node-groups
- --skip-nodes-with-system-pods=false

Fargateプロファイルではこの問題は発生しません。各ポッドが独自のマイクロVMになるため、ノードスケーリングの次元が完全になくなります。これこそが、バースト的で予測不可能なポッド数を持つワークロードに対してFargateが正しい選択である理由です。

Fargateプロファイルとその機能制限

EKSのFargateプロファイルは、EKSに対して、一致するPodをノード上ではなくFargate上でスケジュールするように指示するセレクター（namespaceとオプションのPodラベル）です。

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata: { name: microservices, region: us-east-1 }
fargateProfiles:
  - name: fp-app
    selectors:
      - namespace: app
        labels: { compute: fargate }

重要な注意点として、EKS on FargateはKubernetesの全機能セットをサポートしているわけではありません。

機能の同等性を前提とすると、EBSを必要とするStatefulSet、hostPortを使用するIngressコントローラー、またはGPU推論ワークロードの移行が失敗する原因となります。

Ingress: AWS Load Balancer ControllerによるALBとNLBの比較

AWS Load Balancer Controllerは、IngressおよびServiceオブジェクトを実際のALBおよびNLBに変換するKubernetesコントローラーです。パスベースまたはホストベースのルーティングを行うHTTP/HTTPSマイクロサービスの場合、albクラスの単一のIngressを作成します。1つのALBで多数のサービス（alb.ingress.kubernetes.io/group.name経由）をフロントに配置する構成は、サービスごとにALBを1つ用意するよりも劇的に安価であり、標準的なコスト効率の高いパターンです。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: shop
spec:
  rules:
  - http:
      paths:
      - path: /customers
        pathType: Prefix
        backend: { service: { name: customers, port: { number: 80 }}}
      - path: /orders
        pathType: Prefix
        backend: { service: { name: orders, port: { number: 80 }}}

TCP、UDP、TLSパススルー、静的IP要件、または極めて高いレイヤー4スループットには、NLB（service.beta.kubernetes.io/aws-load-balancer-type: externalとターゲットタイプnlb-ipを持つLoadBalancerタイプのService）を使用します。gRPC-over-HTTP/2やプレーンTCPのデータベースプロキシをALBの背後に置くことは、gRPCの場合にのみ問題ありません（ALBはHTTP/2とgRPCをサポートしています）。ALBは任意のTCPやUDPを終端することはできません。UDPゲームトラフィックをALB経由で提供しようとすることは、設計時に発見すべきプロトコルのミスマッチです。

IRSAによるPodレベルのIAM

IAM Roles for Service Accounts (IRSA)は、個々のPodにAWS API権限を付与するための正しいメカニズムです。PodにS3アクセス権を与えるためにノードのインスタンスプロファイルをアタッチするのは間違いです。なぜなら、ノード上のすべてのPodがその権限を継承してしまい、最小権限の原則に違反するからです。IRSAは、クラスターのOIDCプロバイダーをIAMとフェデレートする（連携させる）ことで機能します。まずOIDCプロバイダーを一度作成し、次にそのプロバイダーを特定のnamespace:serviceaccountサブジェクトに対して信頼する信頼ポリシーを持つIAMロールを作成します。

eksctl utils associate-iam-oidc-provider --cluster prod --approve

eksctl create iamserviceaccount \
  --cluster prod --namespace payments --name orders-sa \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess \
  --approve

サービスアカウントにeks.amazonaws.com/role-arn: arn:aws:iam::...:role/orders-roleというアノテーションを付け、それをマウントするPodはプロジェクションされたトークンを通じて、有効期間の短いSTS認証情報を取得します。OIDCプロバイダーの関連付けをスキップしたり、アノテーションを省略したりすると、静かにノードロールにフォールバックします。これはレビューで見逃しやすい、微妙なセキュリティの後退です。

VPC CNIプラグインは、各PodにVPCサブネット内でルーティング可能なENI/IPアドレスを割り当てることで、これを補完します。これにより、Podはセキュリティグループを使用してRDS、ElastiCache、またはVPCエンドポイントと直接通信でき、CloudTrailは監査のためにPodの実際のIPを記録します。

永続ストレージとエフェメラルストレージ

ストレージの選択は、アクセスモード、耐久性、起動タイプに依存します。

EBS（EKSではEBS CSIドライバー経由、ECSではタスクにアタッチされたEBS経由で）Postgresプライマリのような単一Podのステートフルなワークロード向けにReadWriteOnceのブロックボリュームを提供します。EFSは、リージョナルでマルチAZに対応し、多数のPodから同時にマウント可能なReadWriteManyのNFSストレージを提供します。「高可用性、耐障害性、複数コンテナ間での共有」といった要件がある場合や、MLアーティファクトを共有する場合には、これが正しい選択です。FSx for Lustreは高スループットのHPCを処理します。FSx for NetApp ONTAPおよびFSx for Windows File Serverはエンタープライズ向けのNFS/SMBを処理します。

Fargateタスクはデフォルトで20GBのエフェメラルストレージを受け取りますが、プラットフォームバージョン1.4.0以降ではephemeralStorage.sizeInGiBで最大200GBまで設定可能です。Fargateには常に「十分なスクラッチスペース」があると想定するのは罠です。50GBの中間ファイルを書き込むベンダーコンテナは、拡張されたエフェメラルストレージに収まるかもしれませんが、要件がタスクの再起動後やタスク間で共有または永続化される50GBのストレージである場合、エフェメラルは不適切です。なぜなら、タスク停止時に破棄され、共有されることもないからです。FargateはEBSをサポートしていません。 Fargateワークロードが永続ストレージや共有ストレージを必要とする場合、EFSが実質的に唯一サポートされているオプションです。

ECSの場合、タスク定義でEFSを直接マウントします。アクセスポイントはタスクごとにPOSIX UID/GIDとルートディレクトリを強制し、単一のファイルシステム上で安全なマルチテナンシーを提供し、IAM認可はelasticfilesystem:ClientMountをスコープとします。

"volumes": [{
  "name": "scratch",
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-0abc123",
    "transitEncryption": "ENABLED",
    "authorizationConfig": {
      "accessPointId": "fsap-0def456",
      "iam": "ENABLED"
    }
  }
}],
"containerDefinitions": [{
  "name": "app",
  "mountPoints": [{
    "sourceVolume": "scratch",
    "containerPath": "/data"
  }]
}]

EKSの場合、StorageClassを介してEFSを接続します。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: efs-sc }
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-0123456789abcdef0
  directoryPerms: "700"

よくある罠として、ステートフルなワークロードにFargateを選択したものの、EFS CSIドライバーとStorageClassのインストールを忘れてしまうケースがあります。この場合、Podは起動しますが、PersistentVolumeClaimsが永遠にPending状態のままになります。逆に、要件が共有マルチライターストレージであるにもかかわらず、EBSをアタッチするためだけにEC2ノードを選択するのも間違いです。1つのノードにアタッチされたEBS io2は、AZをまたいで共有することはできません。

ECRのイメージスキャンとライフサイクル

Amazon ECRは2つのスキャンモードを提供しています。基本スキャンはオープンソースのClairデータベースを使用し、プッシュ時（またはオンデマンド）に無料で実行されます。拡張スキャンはAmazon Inspectorと統合され、OSとプログラミング言語パッケージの両方のCVEを継続的に監視し、検出結果をSecurity Hubに報告します。「CVEのスキャン、新規イメージ作成時のスキャン、ワークロードへの変更を最小限に」という要件に対して、正しいアクションは、リポジトリレベルでプッシュ時のスキャンを有効にすることです。プッシュイベントがスキャンをトリガーするため、パイプラインの変更は不要です。

aws ecr put-image-scanning-configuration \
  --repository-name payments-api \
  --image-scanning-configuration scanOnPush=true

その後、CI/CDはdescribe-image-scan-findingsを呼び出し、CRITICALまたはHIGHの件数に基づいてビルドを失敗させます。スキャンをスキップすると、パッチが適用されていないLog4j、OpenSSL、またはglibcのCVEが本番環境で実行されることを意味します。スキャンをしないことによる緩和コストは、それを有効にするためのほぼゼロのコストをはるかに上回ります。

ライフサイクルポリシーは、ストレージコストに上限を設け、タグの衛生状態（tag hygiene）を強制します。

{
  "rules": [{
    "rulePriority": 1,
    "selection": {
      "tagStatus": "untagged",
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 14
    },
    "action": { "type": "expire" }
  }]
}

Kubernetes + MongoDBワークロードの移行

自己ホスト型のKubernetes + MongoDBスタックを、「アプリケーションコードを変更しない」かつ「運用オーバーヘッドを最小限に抑える」という制約のもとでAWSにリフト＆シフトする場合、2つの決定事項が一致します。第一に、コンピューティングレイヤーはEKSに移行します。Kubernetes APIの互換性により、マニフェストやHelmチャートが変更なしで移植できるためです。ステートレスサービスにはFargateプロファイルを使用し、ノード管理を不要にします。

第二に、MongoDB自体をセルフマネージドのEC2やStatefulSetsにリホストすべきではありません。それは、バックアップ、シャーディング、フェイルオーバー、パッチ適用といった運用上の負担を再び生じさせるからです。Amazon DocumentDB (MongoDB互換) を使用します。これはMongoDB 3.6/4.0/5.0のワイヤープロトコルを解釈するため、既存のドライバーや接続文字列が最小限の変更で機能します。

互換性に関する注意点は重要です。DocumentDBはMongoDB APIのサーフェスをエミュレートしますが、MongoDBそのものではありません。特定の集計演算子、特定のインデックスタイプ、チェンジストリームのセマンティクス、そして新しいMongoDBバージョンで導入された機能は失敗する可能性があります。移行前の正しいステップは、DocumentDB互換性ツール（compat.py）をアプリケーションに対して実行し、すべてのオペレーションがサポートされていることを確認することです。代わりにDynamoDBを選択するとデータモデルの書き換えが必須になり、RDSを選択するとドキュメントモデルが完全に崩れてしまいます。どちらも「コード変更なし」という制約に違反します。

ハイブリッドオプション: ECS AnywhereとEKS Anywhere

ECS Anywhereは、オンプレミスのサーバー（または他クラウドのVM）を外部インスタンスとしてECSクラスターに登録します。コントロールプレーンはAWSに残り、外部インスタンス上のSSM AgentとECS Agentがアウトバウンドで接続します。1つのデプロイメントパイプライン、1つのタスク定義、そして1つのIAMロールセットで、クラウドとオンプレミスの両方のワークロードをカバーします。

EKS Anywhereは、準拠したKubernetesディストリビューションを自身のハードウェア（通常はvSphereまたはベアメタル）にインストールし、オプションでEKS Connectorを介してAWSコンソールでの可視性を確保します。軽量でタスク定義ベースのハイブリッドにはECS Anywhereを、規制やレイテンシーの制約からクラウドのEKSと同じツールでローカルにKubernetesが必要な場合はEKS Anywhereを選択します。どちらもオーケストレーションの一貫性を保ちます。その基本的な価値は、チームが2つのCI/CDシステムや2つのメンタルモデルを維持するのを避けられる点にあります。

EKS Connectorによるマルチクラスターの可視化

組織は、EKSクラスター、EC2上のセルフマネージドKubernetes、オンプレミスクラスターを混在させて運用することがよくあります。Amazon EKS Connectorは、準拠したあらゆるKubernetesクラスターをEKSコンソールに登録し、ノード、ワークロード、クラスターメタデータのための単一の管理画面を提供します。これは本質的に軽量なエージェントとSSMチャネルを組み合わせたものであり、「全クラスターの一元的なビュー」に対する低オーバーヘッドな答えです。セルフホストのRancher、Anthos、またはカスタムのPrometheus/Grafanaフェデレーションで同等の可視性を構築することも可能ですが、運用コストがはるかに高く、IAMやコンソールベースのアクセスと統合されません。

EKS Connectorは厳密には可視化レイヤーです。リモートクラスターの管理やアップグレードは行いません。これはまさに「最小のオーバーヘッドで一元的なビュー」が意味するところです。

パターンの組み合わせ

負荷分散されたフロントエンド、コンテナ化された中間層、リレーショナルストアを持つeコマースのワークロードで、「手動介入を可能な限り少なくする」ことが基準の場合、代表的なスタック構成はALB → ECS on Fargate → Aurora Serverless v2です。すべての階層でインスタンスレベルの管理が不要になります。ALBはフルマネージドであり、Fargateはホストを不要にし、Aurora Serverless v2はインスタンスのサイジングなしでACU単位でスケールします。

チームが「追加のインフラを管理できない」マイクロサービスプラットフォームの場合、正しい組み合わせはECSまたはEKS with Fargateと、フルマネージドのデータサービスです。EC2起動タイプやセルフマネージドのノードグループを選択することは、技術的にはワークロードが実行可能であっても、その制約に反します。

Kubernetes + MongoDBのリフト＆シフトについては、答えはEKS + DocumentDBに集約されます。Kubernetes APIはデプロイ方法を維持し、DocumentDBはドライバーの互換性を維持し、Fargateプロファイルは最小限の運用を維持します。ただし、ワークロードのKubernetes機能の使用状況とMongoDBコマンドのサーフェスが、前述のサポート範囲内に収まっていることが条件です。

← コンピューティング、Auto Scaling、インスタンス管理 · すべてのドメイン · サーバーレスとイベント駆動型アーキテクチャ →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

試験に合格する →

Amazonを閲覧 →

Related guides

オールインワンアクセス

1つのサブスクリプション。すべての試験。

すべてのプランで、無制限の回答検索、模擬試験、AI解説、および完全なリソースライブラリが利用可能 — 20以上の言語に対応。

月額
€24.87
Just €0.83/day
すべて含まれています：
  • ✓無制限の回答検索
  • ✓無制限の模擬試験
  • ✓AIを活用した解説
  • ✓完全なリソースライブラリ
  • ✓20以上の言語
  • ✓毎週のコンテンツ更新
  • ✓特典 & 紹介
  • ✓優先サポート
無料トライアルを開始

クレジットカード不要*

最も人気
6ヶ月
€119.87
Just €0.66/daySave 20%
すべて含まれています：
  • ✓無制限の回答検索
  • ✓無制限の模擬試験
  • ✓AIを活用した解説
  • ✓完全なリソースライブラリ
  • ✓20以上の言語
  • ✓毎週のコンテンツ更新
  • ✓特典 & 紹介
  • ✓優先サポート
無料トライアルを開始

クレジットカード不要*

ベストバリュー
12ヶ月
€179.87
Just €0.49/daySave 40%
すべて含まれています：
  • ✓無制限の回答検索
  • ✓無制限の模擬試験
  • ✓AIを活用した解説
  • ✓完全なリソースライブラリ
  • ✓20以上の言語
  • ✓毎週のコンテンツ更新
  • ✓特典 & 紹介
  • ✓優先サポート
無料トライアルを開始

クレジットカード不要*

✓ 無料プランが含まれています · ✓ いつでもキャンセル可能 · ✓ すべてのプランで製品の全機能が利用可能