Amazon SAA-C03: Управление, эксплуатация, наблюдаемость и затраты — Руководство по подготовке

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

Часть AWS SAA-C03 — Полное руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

CloudWatch: метрики, пространства имён, дашборды и оповещения

CloudWatch — это стандартный уровень телеметрии для сервисов AWS, но его полезность полностью зависит от знания, в какое пространство имён сервис публикует свои данные. Пространство имён (namespace) — это контейнер для метрик, который предотвращает конфликты между сервисами. Например, AWS/Lambda содержит метрики Invocations, Errors и Throttles для функций, в то время как AWS/Events содержит Invocations, FailedInvocations, TriggeredRules и MatchedEvents для правил EventBridge. Это различие имеет решающее значение при диагностике событийно-ориентированных конвейеров. Если правило EventBridge вызывает сторонний API через API destination, и трафик не доходит до следующего этапа, ответ следует искать не в AWS/Lambda, а в AWS/Events. Проверка TriggeredRules покажет, сработал ли вообще шаблон правила, а Invocations/FailedInvocations — была ли вызвана цель и был ли вызов успешным. Поиск в метриках Lambda только потому, что это более знакомый сервис, упускает из виду тот факт, что правило могло вообще не сработать на входящее событие.

Разрешение метрик (metric resolution) — это настройка для каждого ресурса, имеющая финансовые последствия. Базовый мониторинг отправляет метрики каждые пять минут без дополнительной платы, что достаточно для долго работающих стабильных нагрузок, но слишком медленно для реакций автомасштабирования, обнаружения всплесков или расчёта SLO, требующих поминутного разрешения. Детальный мониторинг сокращает этот интервал до одной минуты (и до одной секунды для пользовательских метрик высокого разрешения), и его включают, когда группам масштабирования нужно реагировать быстро. Это платная функция, поэтому она не включена по умолчанию.

Каждый сервис по умолчанию отправляет стандартный набор метрик, но гипервизор не может «заглянуть» внутрь гостевой ОС. Метрики CPUUtilization, NetworkIn и DiskReadOps для EC2 видны без дополнительных усилий; для получения данных об утилизации памяти и проценте использования файловой системы требуется агент CloudWatch — это единственный способ их получить. Пользовательские метрики приложений также поступают через агент или с помощью вызова PutMetricData.

Оповещения (alarms) должны отделять полезный сигнал от шума. Одно оповещение «CPU > 50%» будет постоянно срабатывать во время обычных всплесков нагрузки и приучит операторов его игнорировать. Составные оповещения (composite alarms) объединяют состояния дочерних оповещений с помощью логического выражения, чтобы операторы получали уведомления только тогда, когда возникает действительно требующее вмешательства состояние. Для рабочей нагрузки, где кратковременные всплески CPU безвредны, но продолжительная нагрузка на процессор в сочетании с повышенным количеством операций чтения с диска (IOPS) указывает на реальную проблему:

HighCPUAlarm:
  MetricName: CPUUtilization
  Threshold: 50
  EvaluationPeriods: 3
  Period: 60
  ComparisonOperator: GreaterThanThreshold

HighDiskReadAlarm:
  MetricName: DiskReadOps
  Threshold: 1000
  EvaluationPeriods: 3
  Period: 60

CompositeAlarm:
  AlarmRule: >
    ALARM("HighCPUAlarm") AND ALARM("HighDiskReadAlarm")
  AlarmActions:
    - arn:aws:sns:us-east-1:111122223333:ops-pager

Дочерние оповещения могут по-прежнему переходить в состояние ALARM внутри системы, но только составное оповещение вызовет SNS. Два независимых оповещения, каждое из которых уведомляет дежурного инженера, воссоздают проблему шума; одно оповещение с более высоким порогом упустит корреляцию.

Дашборды объединяют виджеты метрик, виджеты логов и текст. Существует два способа предоставления доступа, и их путаница — частая ошибка. Если у пользователя уже есть аккаунт AWS, предоставьте ему IAM-сущность (или роль через кросс-аккаунтную наблюдаемость) с правами cloudwatch:GetDashboard и cloudwatch:GetMetricData. Если у пользователя нет аккаунта AWS — например, у менеджера по продукту или представителя заказчика — используйте встроенную функцию предоставления доступа к дашборду. Она создаёт ссылку, защищённую парой email/пароль, пулом пользователей Cognito или публичным URL (что редко бывает уместно). Отправка скриншотов по почте — это не наблюдаемость, а создание IAM-пользователя с доступом к консоли для человека, не работающего с AWS, нарушает принцип наименьших привилегий.

Кросс-аккаунтная наблюдаемость с помощью OAM

Переключаться между десятками аккаунтов для просмотра метрик непрактично. Кросс-аккаунтная наблюдаемость CloudWatch позволяет назначить мониторинговый аккаунт в качестве центрального приёмника (sink), а любое количество исходных аккаунтов — в качестве источников, которые делятся с ним метриками, логами и трассировками через ресурсы sink и link. Самый быстрый способ развёртывания в большом масштабе — это открыть консоль CloudWatch в мониторинговом аккаунте, создать sink и развернуть сгенерированный шаблон CloudFormation StackSet по всей организации для создания ресурсов AWS::Oam::Link в каждом исходном аккаунте:

Resources:
  ObservabilityLink:
    Type: AWS::Oam::Link
    Properties:
      LabelTemplate: "$AccountName"
      ResourceTypes:
        - AWS::CloudWatch::Metric
        - AWS::Logs::LogGroup
        - AWS::XRay::Trace
      SinkIdentifier: arn:aws:oam:us-east-1:111122223333:sink/abc-123

Решить эту задачу с помощью кросс-аккаунтных IAM-ролей и ручных запросов технически возможно, но это не даст вам единых дашбордов, кросс-аккаунтных запросов Metrics Insights или автоматического добавления меток с именами аккаунтов, которое обеспечивают OAM-связи.

Container Insights и распределённая трассировка

Для контейнеризированных рабочих нагрузок канонической функцией CloudWatch является Container Insights. На EKS она разворачивает агент CloudWatch (или ADOT collector) в виде DaemonSet, а также Fluent Bit для пересылки логов. Агент собирает метрики cAdvisor и kubelet и отправляет их в пространства имён ECS/ContainerInsights и ContainerInsights (CPU/память на уровне пода, узла, пространства имён и кластера), в то время как Fluent Bit отправляет stdout/stderr в лог-группы, такие как /aws/containerinsights/<cluster>/application, /dataplane и /host. Можно развернуть собственный стек Prometheus/Grafana, но управляемый подход — это Container Insights плюс Logs Insights:

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "payments"
| filter log like /ERROR/
| stats count() by kubernetes.pod_name

Метрики говорят вам, что что-то работает медленно; трассировки говорят где. X-Ray инструментирует каждый сервис на пути запроса, передавая идентификатор трассировки через заголовок X-Amzn-Trace-Id и отправляя сегменты и подсегменты демону X-Ray или в ADOT collector. Карта сервисов (service map) визуализирует узлы и связи с указанием задержки, процента ошибок и сбоев. Без X-Ray всплеск p99 отобразится как метрика в CloudWatch без указания причины.

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()  # instruments boto3, requests, sqlalchemy, etc.

@xray_recorder.capture('checkout')
def checkout(order_id): ...

Container Insights, X-Ray и CloudWatch Logs — это три кита наблюдаемости микросервисов.

Три потока логов: CloudTrail, VPC Flow Logs, CloudWatch Logs

Любая стратегия наблюдаемости (observability) в AWS разделяет три различных потока логов: активность API на уровне управления (CloudTrail), сетевая активность на уровне данных (VPC Flow Logs) и вывод приложений/ОС (CloudWatch Logs). Каждый из них отвечает на свой вопрос при расследовании инцидентов, и их путаница является распространенной ошибкой проектирования.

CloudTrail записывает каждый вызов AWS API — кто его инициировал (userIdentity), с какого IP, для какого ресурса, с какими параметрами и был ли он успешным. Это единственный сервис, который надежно связывает изменение с конкретным субъектом IAM. Распространенное заблуждение заключается в том, что CloudWatch Logs — это подходящее место для поиска активности API; CloudWatch Logs собирает вывод приложений/системы, а не аудиторские данные на уровне субъектов. CloudTrail может доставлять свои события в CloudWatch Logs для фильтрации метрик в реальном времени, но исходная аудиторская запись создается в CloudTrail.

В среде AWS Organizations правильным шаблоном является организационный trail, созданный из управляющей учетной записи (или учетной записи делегированного администратора), который автоматически подключает новые учетные записи-участники и направляет события в единый бакет S3 в выделенной учетной записи для архивации логов:

CentralTrail:
  Type: AWS::CloudTrail::Trail
  Properties:
    IsOrganizationTrail: true
    IsMultiRegionTrail: true
    IncludeGlobalServiceEvents: true
    EnableLogFileValidation: true       # SHA-256 digest chain
    S3BucketName: org-cloudtrail-logs
    KMSKeyId: !Ref TrailKmsKey

Для бакета назначения требуется версионирование, политика бакета, ограничивающая s3:PutObject для субъекта-службы CloudTrail, шифрование SSE-KMS, меж-аккаунтный доступ только на чтение для аудиторов и, в идеале, S3 Object Lock в режиме соответствия (compliance mode) для гарантий WORM (write-once, read-many). Валидация файлов логов создает подписанные файлы дайджестов, что позволяет обнаружить несанкционированные изменения. События управления включены по умолчанию на 90 дней; для хранения дольше этого срока требуется trail. События данных (уровень объектов S3, вызовы Lambda, уровень элементов DynamoDB) включаются опционально из-за их объема и стоимости. Для специализированных запросов к историческим данным CloudTrail Lake или Athena поверх бакета с trail-ами позволяют выполнять SQL-запросы:

SELECT userIdentity.arn, eventTime, requestParameters
FROM cloudtrail_logs
WHERE eventName = 'AuthorizeSecurityGroupIngress'
  AND eventTime BETWEEN '2024-01-08' AND '2024-01-12';

VPC Flow Logs собирают метаданные об IP-трафике — 5-кортеж, байты, пакеты, действие (ACCEPT/REJECT) и статус лога — для VPC, подсети или ENI. Они не захватывают содержимое пакетов (payloads). Целями доставки могут быть CloudWatch Logs, S3 или Kinesis Data Firehose. Выбирайте S3 для архивации; выбирайте CloudWatch Logs, когда вам нужны метрические фильтры для запуска оповещений о подозрительных паттернах трафика; выбирайте Firehose, когда требуется аналитика почти в реальном времени. Канонический конвейер для аналитики почти в реальном времени для VPC с NLB, ASG и базами данных:

ENIs → VPC Flow Logs (delivery: Kinesis Data Firehose)
      → Firehose delivery stream (optional Lambda transform)
      → Amazon OpenSearch Service (index: vpc-flow-*)
      → OpenSearch Dashboards

Альтернативный путь CloudWatch Logs → фильтр подписки → Firehose → OpenSearch работает, но добавляет лишний шаг и затраты. S3 — неправильный выбор, когда требование — «почти в реальном времени». Самая пагубная ловушка — это полное отсутствие VPC Flow Logs: при возникновении инцидента безопасности не будет записей об источнике/назначении/порте и видимости ACCEPT в сравнении с REJECT. Та же логика применима к логам доступа ALB — они включаются опционально, доставляются в S3, и без них нет записей на уровне запросов о IP-адресах клиентов, кодах ответа, задержках целевых групп или user-агентах. Вместе Flow Logs (L3/L4) и логи доступа ALB (L7) составляют основу для расследования инцидентов, связанных с трафиком.

CloudWatch Logs получает логи приложений, Lambda и ОС через CloudWatch agent. Его мощь заключается в метрических фильтрах: выражениях-шаблонах, которые сканируют входящие события и инкрементируют пользовательскую метрику при совпадении, что затем вызывает срабатывание оповещения (alarm):

# Metric filter detecting inbound SSH sessions from Flow Logs
[version, account, eni, source, dest, srcport, destport=22,
 protocol=6, packets, bytes, start, end, action=ACCEPT, status]

Параллельный фильтр для порта 3389 охватывает RDP. Сбор логов без оповещений обеспечивает возможность расследования постфактум, а не предотвращение инцидентов.

Для больших парков серверов стандартом является разветвление логов в конвейер обработки через фильтр подписки на лог-группе, который направляет совпадающие события в Kinesis Data Stream, Firehose или Lambda почти в реальном времени:

{
  "filterPattern": "",
  "destinationArn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/logs-to-os"
}

Ловушка заключается в отправке необработанных логов в хранилище без конвейера обработки: выгрузка в S3 без каталога Glue, индекса OpenSearch и рабочей группы Athena означает, что логи существуют, но с ними невозможно работать во время инцидента. Для наблюдаемости (observability) требуется интерфейс для выполнения запросов, а не просто надежно сохраненные байты. Лог-группам также требуются явные политики хранения — по умолчанию установлено «никогда не истекает», что незаметно расходует деньги — и их можно экспортировать в S3 для долгосрочного архивирования с правилами жизненного цикла.

Обнаружение событий на уровне API с минимальными накладными расходами

Для особо важных событий плоскости управления — CreateImage, AuthorizeSecurityGroupIngress, StopLogging, ConsoleLogin без MFA — шаблоном с наименьшими накладными расходами является CloudTrail → правило EventBridge → SNS. EventBridge нативно получает каждое событие управления из CloudTrail, и правилу с шаблоном события не требуется связующий код на Lambda:

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["CreateImage"]
  }
}

Отправка CloudTrail в CloudWatch Logs с применением метрического фильтра также работает, но добавляет лог-группу, фильтр, оповещение и затраты, поэтому проигрывает по операционным накладным расходам, когда требование — просто «оповестить о вызове API X».

AWS Config: Непрерывный контроль конфигурации и отклонений

Config и CloudTrail часто путают, но они отвечают на принципиально разные вопросы. CloudTrail записывает, кто и что вызывал; Config записывает, как ресурс выглядит сейчас и как он менялся со временем. Ожидать, что Config будет логировать вызовы API — это классический неверный ответ. Config не знает, что пользователь вызвал PutBucketAcl; он знает, что в 14:03:22 ACL бакета изменился из состояния A в состояние B. Чтобы определить субъект (principal), сопоставьте запись об изменении в Config с событием CloudTrail в тот же момент времени (в консоли Config есть прямая ссылка на него).

Правила Config оценивают ресурсы на соответствие желаемому состоянию. Управляемые правила (Managed rules) охватывают стандартные проверки (restricted-ssh, s3-bucket-public-read-prohibited, required-tags, ec2-instance-no-public-ip, s3-bucket-versioning-enabled, desired-instance-type), а пользовательские правила (custom rules) выполняются как функции Lambda или используют CloudFormation Guard. Правила срабатывают при изменении конфигурации и по расписанию, помечают ресурсы как COMPLIANT (соответствующий) или NON_COMPLIANT (несоответствующий) и могут запускать автоматическое исправление через документы SSM Automation. Это ответ с низкими операционными издержками на вопросы «как обнаружить открытый SSH» или «как обнаружить экземпляры завышенного размера» — правила уже существуют и нативно интегрируются с SNS и Security Hub. Предложение периодических ручных аудитов, сканирований по расписанию или самописных сканеров потребует от вас создания и поддержки кода, который в Config уже есть «из коробки».

Config публикует результаты проверок в SNS. Для автоматизации исправлений настройте правило EventBridge, которое будет реагировать на событие изменения соответствия и вызывать документ SSM Automation или функцию Lambda:

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Агрегаторы (Aggregators) объединяют данные о соответствии со всей организации; пакеты соответствия (conformance packs) объединяют правила для фреймворков, таких как PCI-DSS или HIPAA. Workload Discovery on AWS (ранее AWS Perspective) — это решение на базе Config, которое визуализирует связи между ресурсами и генерирует архитектурные диаграммы. Это канонический ответ, когда в вопросе требуется инструмент для инвентаризации, способный построить диаграмму существующей среды. Config является обязательным условием.

Security Hub, GuardDuty и Control Tower

Security Hub — это плоскость агрегации для результатов проверок безопасности (findings). Он получает данные от GuardDuty (обнаружение угроз на основе VPC Flow Logs, DNS и CloudTrail), Inspector (данные об уязвимостях), Macie, IAM Access Analyzer и Config, а затем нормализует все в формат AWS Security Finding Format (ASFF). Включение Security Hub также активирует стандарты безопасности, в первую очередь стандарт AWS Foundational Security Best Practices (FSBP) — десятки автоматических проверок (MFA для root-пользователя, публичные S3, незашифрованные EBS, многорегиональный CloudTrail), которые «под капотом» реализованы через правила Config.

В масштабе организации назначьте делегированный аккаунт администратора (delegated administrator account) для Security Hub (а также для GuardDuty и Config), включите сервис и стандарт FSBP для всей организации с опцией «auto-enable new accounts» (автоматически включать для новых аккаунтов) и направляйте результаты через EventBridge в SNS, отбирая события Security Hub Findings - Imported с фильтром по ARN стандарта FSBP и Compliance.Status = FAILED. Создание собственных Lambda для парсинга CloudTrail или дашбордов для каждого аккаунта добавляет операционную нагрузку, которую Security Hub уже берет на себя.

Ключевое концептуальное различие: Security Hub — это сервис для обнаружения и агрегации, а не для предотвращения. Предотвращение отклонений (drift) — это задача AWS Control Tower, который организует правильно спроектированную многоаккаунтную среду (landing zone). Account Factory создает новые аккаунты с базовыми настройками сети, логирования и IAM. Управление реализуется через «ограждения» (guardrails) трех типов:

Проактивные контроли оценивают шаблоны CloudFormation до развертывания стека и отказываются создавать, например, незашифрованный экземпляр RDS. Security Hub лишь сообщит вам о существовании незашифрованного экземпляра уже после того, как он будет запущен. Если в требовании говорится «предотвратить», думайте о Control Tower. Если «обнаружить, уведомить или агрегировать» — думайте о Security Hub или Config.

Macie: Обнаружение конфиденциальных данных

Macie использует машинное обучение и сопоставление с образцом для выявления конфиденциальных данных — PII (персональные данные), финансовые данные, учетные данные — внутри объектов S3. Критическая ловушка — предполагать, что Macie защищает данные. Это не так. Macie обнаруживает и сообщает. Правильное использование:

1. Включите Macie в целевом аккаунте/регионе.
2. Настройте задание по обнаружению конфиденциальных данных (sensitive data discovery job), указав целевые бакеты/префиксы/теги и расписание.
3. Направьте результаты через EventBridge (source: aws.macie) в SNS для уведомлений, в Lambda для исправления (карантин, ужесточение политики бакета) или в Security Hub.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Без задания по обнаружению Macie ничего не найдет. Без связки EventBridge → SNS результаты останутся незамеченными в консоли Macie.

Organizations, SCP и политики тегов

В AWS Organizations есть три типа политик, которые важны в данном контексте. Политики тегов (Tag policies) определяют разрешенные ключи тегов, регистр и значения — они сообщают о несоответствии и, в сочетании с условиями aws:ResourceTag/aws:RequestTag, могут применяться принудительно. Политики управления сервисами (Service Control Policies, SCP) определяют максимальные разрешения, доступные для участников организации. Политики резервного копирования (Backup policies) и политики отказа от использования ИИ (AI opt-out policies) дополняют этот набор.

Ключевая ментальная модель: SCP никогда не предоставляют разрешений. Они действуют как фильтр поверх того, что в противном случае мог бы разрешить IAM (политики удостоверений, политики ресурсов, границы разрешений). Участник должен иметь Allow в IAM, и SCP не должен содержать Deny (или должен включать действие в свой список Allow). Фраза «просто прикрепите SCP» никогда не является полным ответом на вопрос о разрешениях — без Allow в IAM участнику будет отказано по умолчанию, независимо от содержимого SCP.

Чтобы требовать наличие тегов при создании, объедините политики тегов с SCP, например, такой:

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": { "aws:RequestTag/CostCenter": "true" }
  }
}

Политика тегов объявляет схему; SCP запрещает создание без тега; политика IAM предоставляет разрешение на создание. Необходимы все три компонента. Правило required-tags в AWS Config обнаруживает и исправляет существующие несоответствующие ресурсы.

Systems Manager Automation и установка исправлений

Systems Manager (SSM) — это операционная основа для управления жизненным циклом парка EC2-инстансов и гибридных узлов. Для установки исправлений наиболее важны две конструкции: документы автоматизации (Automation documents) (декларативные сценарии в формате YAML/JSON, вызывающие AWS API или скрипты) и окна обслуживания (Maintenance Windows) (которые планируют запуск этих сценариев для целевых ресурсов, определенных по тегам или группам ресурсов, в рамках окна изменений с заданными порогами параллелизма и ошибок).

Канонический процесс установки исправлений — это выполнение документа команд AWS-RunPatchBaseline на инстансах, выбранных по тегу Patch Group, с использованием набора исправлений (Patch Baseline), который определяет правила утверждения для каждой ОС. Для инстансов за балансировщиком нагрузки прямой запуск AWS-RunPatchBaseline прерывает соединения в процессе установки исправлений, поскольку инстансы остаются в состоянии InService в целевой группе. Правильный подход — использовать AWSEC2-PatchLoadBalancerInstance, который:

1. Отменяет регистрацию инстанса в его целевой группе CLB или ALB.
2. Ожидает опустошения соединений / задержки отмены регистрации.
3. Запускает шаги сканирования и установки набора исправлений.
4. Перезагружает инстанс, если это требуется набором исправлений.
5. Повторно регистрирует инстанс и ожидает, пока проверка состояния целевого ресурса не вернет статус healthy.

Два предварительных условия приводят к сбоям типа «produces errors». Во-первых, IAM-роль, переданная как AutomationAssumeRole, должна включать разрешения elasticloadbalancing:DeregisterTargets, RegisterTargets и DescribeTargetHealth в дополнение к стандартным разрешениям SSM для установки исправлений. Во-вторых, инстанс должен быть управляемым узлом (managed node) — с запущенным SSM Agent и профилем инстанса, включающим политику AmazonSSMManagedInstanceCore. Без этого вызовы отмены регистрации завершатся ошибкой, или SSM не сможет «увидеть» инстанс.

schemaVersion: '0.3'
description: Patch instance behind ALB
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId: { type: String }
  TargetGroupArn: { type: String }
  AutomationAssumeRole: { type: String }
mainSteps:
  - name: deregister
    action: aws:executeAwsApi
    inputs:
      Service: elbv2
      Api: DeregisterTargets
      TargetGroupArn: '{{ TargetGroupArn }}'

← Безопасность · Все домены · Высокая доступность →

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

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