Amazon SAA-C03: Контейнеры и оркестрация — Руководство по подготовке

By Laurynas Brazys · 19 July 2026 · #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. Задачи (tasks) — это единицы, состоящие из одного или нескольких контейнеров с общим жизненным циклом; сервисы (services) — это долгоживущие управляемые наборы задач, управляемые планировщиком. Amazon EKS запускает Kubernetes, соответствующий upstream-версии, за фиксированную плату $0.10 в час за кластер. Это правильный выбор, когда рабочие нагрузки должны оставаться переносимыми, использовать Kubernetes API или экосистему CNCF (Helm, CRDs, Operators). Уровень управления — API server, etcd, controller manager, scheduler — обновляется, резервируется и обеспечивается высокой доступностью в трех зонах доступности силами AWS.

Оба оркестратора поддерживают два режима вычислений. AWS Fargate запускает каждую задачу или под на изолированных микро-ВМ Firecracker; здесь не нужно патчить AMI, настраивать поставщиков емкости Auto Scaling Group, принимать решения о bin-packing или иметь хосты с доступом по SSH. Оплата производится за vCPU-секунды и ГБ-секунды задачи. Тип запуска EC2 / управляемые группы узлов (managed node groups) означает, что вы владеете инстансами, со всей вытекающей отсюда гибкостью и операционной нагрузкой.

Fargate — это правильный выбор по умолчанию, когда в сценарии делается акцент на «бессерверности», «минимальных операционных издержках» или «отсутствии необходимости управлять инфраструктурой», при условии, что рабочая нагрузка соответствует его ограничениям: максимум 16 vCPU / 120 ГБ памяти на задачу, отсутствие GPU, привилегированных контейнеров, DaemonSets, HostPort/HostNetwork и кастомизации на уровне хоста Windows. Выбирайте управляемые группы узлов или тип запуска EC2, когда вам нужны GPU, DaemonSets с доступом к хосту, кастомные AMI, контейнеры Windows Server с GMSA, эффективность bin-packing на субсекундном уровне или агрессивная оптимизация затрат на основе Spot.

Классическая ловушка — выбирать узлы EC2, потому что они «кажутся» дешевле. Для нагрузок с пиками или низкой утилизацией Fargate часто оказывается дешевле, если учесть простаивающие мощности плюс инженерное время на обновление AMI, вывод узлов из эксплуатации и настройку автомасштабирования кластера — все это Fargate устраняет.

Определения задач, их размещение и поставщики емкости

Каноническое определение задачи (task definition) для ECS Fargate включает в себя основные элементы — размеры CPU/памяти, роль выполнения (execution role) для загрузки образов и записи логов, сетевой режим 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

В ECS с EC2 стратегии размещения задач (task placement strategies) определяют, как задачи распределяются по инстансам. Они применяются последовательно:

Ограничения размещения (placement constraints), такие как distinctInstance или memberOf с использованием языка запросов кластера, дополнительно сужают круг подходящих инстансов.

Поставщики емкости (Capacity providers) отделяют сервисы от «сырых» Auto Scaling Groups. FARGATE и FARGATE_SPOT — это управляемые поставщики; кастомные поставщики оборачивают ASG и включают управляемое масштабирование, чтобы ECS корректировал желаемое количество инстансов в ASG на основе числа запущенных задач. Стратегия поставщика емкости распределяет задачи по весу и базовому количеству — например, гарантируя запуск двух задач на Fargate on-demand и распределяя остальные в соотношении 1:4 с Fargate Spot для нагрузок, устойчивых к прерываниям:

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

Автомасштабирование: поды, задачи и узлы

Fargate избавляет от управления узлами, но он не масштабирует количество задач или подов автоматически. Это различие — самое распространенное заблуждение о Fargate: бессерверный подход относится к уровню хостов, а не к желаемому количеству экземпляров вашего сервиса. Вы по-прежнему отвечаете за автомасштабирование на уровне сервиса.

Для ECS используйте Application Auto Scaling. Отслеживание цели (Target tracking) — это идиоматичный выбор по умолчанию, поскольку он автоматически создает алармы CloudWatch для масштабирования (scale-out и scale-in) и учитывает периоды восстановления (cooldowns). Разумными метриками являются 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"}}'

Пошаговое (Step scaling) и запланированное (scheduled scaling) масштабирование остаются доступными для нелинейных кривых отклика или известных временных окон трафика.

Для EKS на узлах EC2 масштабирование подов осуществляется с помощью Horizontal Pod Autoscaler (HPA), который регулирует количество реплик на основе CPU, памяти или кастомных метрик. HPA сам по себе не может добавлять узлы — он с радостью увеличит количество реплик сверх емкости кластера, после чего новые поды переходят в состояние Pending с событиями FailedScheduling. Поэтому HPA на EC2 всегда должен использоваться в паре с Kubernetes Cluster Autoscaler или Karpenter. Забыть об этой паре — частая ошибка проектирования: HPA сообщает «масштабировано до 20 реплик», в то время как половина из них застряла в состоянии ожидания. Минимальная конфигурация 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 эта проблема исчезает — каждый под становится своей собственной микро-ВМ, так что измерение масштабирования узлов полностью устраняется. Именно поэтому Fargate — правильный выбор для пиковых нагрузок с непредсказуемым количеством подов.

Профили Fargate и их функциональные ограничения

Профиль Fargate в EKS — это селектор (пространство имен плюс необязательные метки подов), который указывает EKS планировать соответствующие поды в Fargate, а не на узле:

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

Критически важный нюанс заключается в том, что EKS на Fargate не поддерживает весь набор функций Kubernetes:

• DaemonSets не запускаются. Поскольку нет узла для запуска демонов, сборщики логов, такие как fluentd DaemonSets, должны быть заменены на sidecar-контейнеры или встроенный маршрутизатор логов Fluent Bit.
• Привилегированные контейнеры, HostPort и HostNetwork недоступны.
• Постоянное хранилище ограничено EFS через драйвер CSI. EBS не поддерживается, так как тома EBS требуют подключения к конкретному инстансу EC2.
• Нагрузки, требующие GPU, не поддерживаются.
• Сервисы типа NodePort и service mesh, использующие привилегированные init-контейнеры, не работают.

Предположение о паритете функций приводит к сбоям при миграции StatefulSets, которым нужен EBS, ingress-контроллеров, использующих hostPort, или нагрузок для инференса на GPU.

Ingress: ALB против NLB через AWS Load Balancer Controller

AWS Load Balancer Controller — это контроллер Kubernetes, который преобразует объекты Ingress и Service в реальные ALB и NLB. Для микросервисов HTTP/HTTPS с маршрутизацией на основе пути или хоста создайте один Ingress класса alb. Один ALB, обслуживающий множество сервисов (через alb.ingress.kubernetes.io/group.name), значительно дешевле, чем один ALB на сервис, и является каноническим экономически эффективным паттерном:

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 }}}

Используйте NLB (Service типа LoadBalancer с аннотацией service.beta.kubernetes.io/aws-load-balancer-type: external и типом цели nlb-ip) для TCP, UDP, сквозной передачи TLS (pass-through), требований к статическому IP или экстремальной пропускной способности на уровне 4. Размещение прокси для базы данных gRPC-over-HTTP/2 или обычного TCP за ALB допустимо только для gRPC (ALB поддерживает HTTP/2 и gRPC); ALB не может терминировать произвольный TCP или любой UDP. Попытка обслуживать игровой UDP-трафик через ALB — это несоответствие протоколов, которое должно быть выявлено на этапе проектирования.

IAM на уровне подов с помощью IRSA

IAM Roles for Service Accounts (IRSA) — это правильный механизм для предоставления разрешений AWS API отдельным подам. Прикрепление профиля инстанса узла для предоставления подам доступа к S3 является неверным подходом, поскольку каждый под на узле наследует эти разрешения, нарушая принцип наименьших привилегий. IRSA работает путем федерации OIDC-провайдера кластера с IAM: создайте OIDC-провайдер один раз, а затем создайте IAM-роль, политика доверия которой доверяет этому провайдеру для конкретного субъекта namespace:serviceaccount.

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, и поды, которые его монтируют, получают кратковременные учетные данные STS через спроецированный токен. Пропуск связывания с OIDC-провайдером или отсутствие аннотации незаметно приводит к использованию роли узла — это тонкая регрессия в безопасности, которую легко пропустить при проверке.

Плагин VPC CNI дополняет это, назначая каждому поду маршрутизируемый ENI/IP-адрес в подсети VPC. Затем поды могут напрямую взаимодействовать с RDS, ElastiCache или VPC-эндпоинтами, используя группы безопасности, а CloudTrail видит реальный IP-адрес пода для аудита.

Постоянное и эфемерное хранилище

Выбор хранилища зависит от режима доступа, долговечности и типа запуска.

EBS (через драйвер EBS CSI в EKS или подключенный к задаче EBS в ECS) предоставляет блочные тома с доступом ReadWriteOnce для stateful-нагрузок с одним подом, таких как основной узел Postgres. EFS предоставляет хранилище NFS с доступом ReadWriteMany, которое является региональным, многозональным и может быть смонтировано многими подами одновременно — это правильный выбор, когда в требованиях упоминается «высокодоступное, отказоустойчивое, совместно используемое несколькими контейнерами» или общие артефакты ML. FSx for Lustre предназначен для высокопроизводительных вычислений (HPC); FSx for NetApp ONTAP и FSx for Windows File Server — для корпоративных нагрузок NFS/SMB.

Задачи Fargate по умолчанию получают 20 ГБ эфемерного хранилища, с возможностью конфигурации до 200 ГБ через ephemeralStorage.sizeInGiB на платформе 1.4.0+. Предположение, что у Fargate всегда «много временного пространства», — это ловушка: контейнер от стороннего поставщика, который записывает 50 ГБ промежуточных файлов, может поместиться в расширенное эфемерное хранилище, но если требуется 50 ГБ общего или постоянного хранилища между перезапусками задачи или между задачами, то эфемерное хранилище не подходит, так как оно уничтожается при остановке задачи и никогда не является общим. 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 подключите EFS через StorageClass:

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 для stateful-нагрузки с забвением установки драйвера EFS CSI и StorageClass — поды запускаются, но PersistentVolumeClaims вечно остаются в состоянии Pending. И наоборот, выбор узлов EC2 исключительно для подключения EBS, когда требуется общее хранилище с множественной записью, также является ошибкой; EBS io2, подключенный к одному узлу, не может быть разделен между зонами доступности.

Сканирование образов и жизненный цикл в ECR

Amazon ECR предлагает два режима сканирования. Базовое сканирование использует базу данных с открытым исходным кодом Clair и запускается при загрузке образа (on push) или по запросу бесплатно. Расширенное сканирование интегрировано с Amazon Inspector, непрерывно отслеживает CVE как в ОС, так и в языковых пакетах, и сообщает о результатах в Security Hub. Для задачи «сканировать на CVE, сканировать новые образы при создании, с минимальными изменениями в рабочих процессах» правильным действием будет включение сканирования при загрузке (scan on push) на уровне репозитория — изменения в конвейере не требуются, так как событие push запускает сканирование:

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; стоимость устранения последствий отсутствия сканирования значительно превышает почти нулевую стоимость его включения.

Политики жизненного цикла ограничивают затраты на хранение и обеспечивают гигиену тегов:

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

Миграция рабочих нагрузок Kubernetes + MongoDB

При переносе (lift-and-shift) локального стека Kubernetes + MongoDB в AWS с ограничениями «не изменять код приложения» и «минимальные операционные издержки» напрашиваются два решения. Во-первых, вычислительный уровень переносится в EKS, поскольку совместимость с Kubernetes API означает, что манифесты и Helm-чарты переносятся без изменений; используйте профили Fargate для сервисов без состояния, чтобы избавиться от необходимости управлять узлами.

Во-вторых, саму MongoDB не следует переносить на самоуправляемые инстансы EC2 или в StatefulSets — это вновь возлагает на вас операционные задачи, такие как резервное копирование, шардирование, обработка отказов и установка исправлений. Используйте Amazon DocumentDB (с совместимостью с MongoDB), который поддерживает сетевой протокол MongoDB версий 3.6/4.0/5.0, поэтому существующие драйверы и строки подключения будут работать с минимальными изменениями.

Важно помнить об ограничениях совместимости. DocumentDB эмулирует API MongoDB, но не является MongoDB. Некоторые операторы агрегации, определенные типы индексов, семантика потоков изменений (change streams) и функции, появившиеся в новых версиях MongoDB, могут не работать. Правильным шагом перед миграцией является запуск инструмента проверки совместимости DocumentDB (compat.py) для вашего приложения, чтобы убедиться, что все операции поддерживаются. Выбор DynamoDB вместо этого потребовал бы переписывания модели данных; выбор RDS полностью нарушил бы документную модель. Оба варианта нарушают ограничение «не изменять код».

Гибридные варианты: ECS Anywhere и EKS Anywhere

ECS Anywhere регистрирует локальные серверы (или виртуальные машины других облаков) в качестве внешних инстансов в кластере ECS. Управляющая плоскость (control plane) остается в AWS; SSM Agent и ECS Agent на внешнем инстансе подключаются к ней через исходящие соединения. Один конвейер развертывания, одно определение задачи (task definition) и один набор IAM-ролей охватывают как облачные, так и локальные рабочие нагрузки.

EKS Anywhere устанавливает совместимый дистрибутив Kubernetes на вашем оборудовании (обычно vSphere или bare metal), опционально с возможностью обзора в консоли AWS через EKS Connector. Выбирайте ECS Anywhere для облегченного гибридного решения на основе определений задач; выбирайте EKS Anywhere, когда требования законодательства или задержек диктуют необходимость развертывания Kubernetes локально с теми же инструментами, что и у EKS в облаке. Оба варианта обеспечивают согласованность оркестрации — их основная ценность в том, что командам не нужно поддерживать две системы CI/CD или две ментальные модели.

Обзор нескольких кластеров с помощью EKS Connector

Организации часто используют сочетание кластеров EKS, самоуправляемых Kubernetes на EC2 и локальных кластеров. Amazon EKS Connector регистрирует любой совместимый кластер Kubernetes в консоли EKS, предоставляя единую панель мониторинга для узлов, рабочих нагрузок и метаданных кластера. По сути, это легковесный агент и канал SSM — решение с низкой нагрузкой для задачи «централизованный обзор всех кластеров». Создание аналогичного обзора с помощью локально размещенных Rancher, Anthos или кастомной федерации Prometheus/Grafana возможно, но гораздо дороже в эксплуатации и не интегрируется с IAM или доступом через консоль.

EKS Connector является строго слоем видимости; он не управляет и не обновляет удаленный кластер, что в точности соответствует требованию «централизованный обзор с минимальными издержками».

Собираем шаблоны воедино

Для рабочей нагрузки электронной коммерции с фронтендом за балансировщиком нагрузки, контейнеризированным средним уровнем и реляционным хранилищем, где критерием является «как можно меньше ручного вмешательства», канонический стек выглядит так: ALB → ECS на Fargate → Aurora Serverless v2. Каждый уровень устраняет необходимость владения инстансами: ALB полностью управляем, Fargate избавляет от хостов, а Aurora Serverless v2 масштабируется в ACU без необходимости подбирать размер инстансов.

Для платформы микросервисов, где команда «не может управлять дополнительной инфраструктурой», правильной комбинацией будет ECS или EKS с Fargate, а также полностью управляемый сервис данных. Выбор типа запуска EC2 или самоуправляемых групп узлов (node groups) противоречит этому ограничению, хотя технически рабочая нагрузка и будет выполняться.

Для переноса Kubernetes + MongoDB по принципу lift-and-shift решение сводится к EKS + DocumentDB: Kubernetes API сохраняет методы развертывания, DocumentDB сохраняет совместимость драйверов, а профили Fargate обеспечивают минимальные операционные издержки — при условии, что используемые функции Kubernetes и команды MongoDB входят в рамки поддерживаемых возможностей, описанных выше.

← Вычислительные ресурсы · Все домены · Бессерверные и событийно-ориентированные архитектуры →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Amazon →