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

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

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

Amazon CloudFront: что это и чем он полезен

Amazon CloudFront — это глобально распределенная сеть доставки контента, построенная на более чем 600 точках присутствия. Его задача — завершать TLS-соединение зрителя на ближайшем периферийном узле и либо немедленно отдавать кэшированные ответы, либо проксировать промахи кэша через частную магистральную сеть AWS к источнику. Выигрыш в производительности двоякий: попадания в кэш сокращают время полного оборота запроса до однозначных миллисекунд и полностью разгружают источник, в то время как промахи кэша все равно выигрывают от оптимизированного завершения TLS/TCP на периферии, поддержки HTTP/2 и HTTP/3, повторного использования keep-alive соединений с источником и транзита по магистральной сети, который позволяет избежать зашумленного публичного интернета.

Распространенное заблуждение заключается в том, что CloudFront ускоряет только статические ресурсы. Размещение ALB за CloudFront с политикой CachingDisabled все равно улучшает производительность динамических API, поскольку рукопожатие (handshake) зрителя завершается в локальной точке присутствия (PoP), а не проходит через весь интернет до региона источника. Совместите это со смешанной рабочей нагрузкой — скажем, /static/* раздается из S3, а /api/* из ALB — и одна дистрибуция сможет обрабатывать и то, и другое:

Distribution:
  Aliases: [www.example.com]
  ViewerCertificate: ACM cert in us-east-1
  Origins:
    - Id: s3-static
      DomainName: static-assets.s3.us-east-1.amazonaws.com
      S3OriginConfig:
        OriginAccessControlId: !Ref OAC
    - Id: alb-dynamic
      DomainName: alb-1234.us-east-1.elb.amazonaws.com
      CustomOriginConfig: { OriginProtocolPolicy: https-only }
  DefaultCacheBehavior:
      TargetOriginId: alb-dynamic
      CachePolicyId: CachingDisabled
      OriginRequestPolicyId: AllViewer
  CacheBehaviors:
    - PathPattern: /static/*
      TargetOriginId: s3-static
      CachePolicyId: CachingOptimized
    - PathPattern: /api/*
      TargetOriginId: alb-dynamic
      CachePolicyId: !Ref ShortTtlPolicy

Затем записи-псевдонимы (alias records) в Route 53 указывают www.example.com на d123.cloudfront.net дистрибуции — записи-псевдонимы бесплатны и разрешаются напрямую в anycast-IP-адреса CloudFront.

Сертификаты находятся в us-east-1

Для любой дистрибуции CloudFront, обслуживаемой на пользовательском домене, TLS-сертификат, обращенный к зрителю, в AWS Certificate Manager должен быть выпущен в регионе us-east-1 (N. Virginia), независимо от того, где находятся бакет-источник, ALB или пользователи. CloudFront — это глобальный сервис, чей управляющий уровень (control plane) закреплен в us-east-1; периферийные узлы запрашивают сертификат из этого региона. Запрос ACM-сертификата в eu-west-1, потому что ваш S3 бакет случайно находится там — это нерабочий паттерн, дистрибуция его никогда не увидит.

aws acm request-certificate \
  --domain-name media.example.com \
  --validation-method DNS \
  --region us-east-1

Если вы второй раз завершаете TLS-соединение между CloudFront и источником в виде ALB, то этот сертификат, обращенный к источнику, находится в регионе ALB. Только сертификат для зрителей привязан к us-east-1. То же правило применяется к пользовательским доменам для API Gateway типа edge-optimized (которые внутренне используют управляемую AWS дистрибуцию CloudFront): сертификат должен быть в us-east-1. В отличие от них, региональные эндпоинты API Gateway используют сертификат из собственного региона API.

Origin Access Control для источников S3

Использование CloudFront перед бакетом S3, оставляя при этом бакет публичным, лишает смысла всю затею: зрители обходят CloudFront, обращаясь напрямую к REST-эндпоинту S3, минуя WAF, гео-ограничения, подписанные URL и преимущества кэширования, а также потенциально раскрывая данные.

Современное решение — это Origin Access Control (OAC), которое заменяет устаревший Origin Access Identity (OAI). OAC использует подписывание SigV4, поддерживает SSE-KMS, работает во всех регионах S3 (включая запущенные после 2022 года) и поддерживает динамические запросы. Block Public Access остается включенным, ACL не требуются, а политика бакета предоставляет доступ на чтение только сервисному принципалу CloudFront, дополнительно ограничиваясь ARN конкретной дистрибуции:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::media-example-com/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
      }
    }
  }]
}

OAI все еще функционирует, но должен считаться устаревшим — для новых проектов всегда выбирайте OAC.

Корректность кэширования

Эффективность кэша зависит от заголовков Cache-Control и Expires, которые возвращает источник, в сочетании с минимальным/стандартным/максимальным TTL в политике кэширования CloudFront. Ресурсы с уникальными именами (fingerprinted), которые не изменяются, следует кэшировать агрессивно; HTML-оболочки, которые на них ссылаются, должны иметь короткий срок жизни, чтобы развертывания вступали в силу; аутентифицированный JSON вообще не должен кэшироваться в общем CDN:

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300      # HTML that changes
Cache-Control: private, no-store                      # authenticated JSON

Часто встречаются две симметричные ловушки. Во-первых, если источник не отдает заголовки кэширования, CloudFront использует стандартный TTL дистрибуции и может незаметно кэшировать динамические ответы на несколько часов. Во-вторых, повсеместное использование Cache-Control: no-cache для ресурсов, которые должны кэшироваться, заставляет каждый запрос идти к источнику и сводит на нет пользу от CDN.

Самая опасная ловушка — кэширование персонализированных ответов без правильных заголовков. Если /account/dashboard возвращает HTML, специфичный для пользователя А, но источник не указывает no-store, а политика кэширования не включает заголовок аутентификации или cookie в ключ кэша, то периферийный узел с радостью отдаст страницу пользователя А пользователю Б. Либо помечайте такие ответы как private, no-store, либо включайте идентификатор сессии в ключ кэша и смиритесь с более низким коэффициентом попаданий.

В сценарии оптимизации затрат, где группа Auto Scaling из EC2 On-Demand инстансов раздает статический контент, правильным решением будет перенести ресурсы в S3, поставить перед ними CloudFront с OAC и устранить или сократить ASG. Это смещает затраты с почасовой оплаты вычислений на оплату за доставку по запросу, что на порядки дешевле для статических рабочих нагрузок.

Подписанные URL, подписанные cookie и гео-ограничения

CloudFront поддерживает подписанные URL (ограниченный по времени и, опционально, по IP-адресу доступ к одному объекту — например, купленный для скачивания видеофайл, одноразовая ссылка на PDF) и подписанные cookie (доступ ко многим объектам, соответствующим шаблону пути — например, аутентифицированный подписчик просматривает каталог). Оба механизма используют доверенную группу ключей (trusted key group), чей публичный ключ загружен в CloudFront; приватный ключ используется для подписи политики, указывающей срок действия, диапазон IP-адресов источника или шаблон URL.

https://d123.cloudfront.net/premium/movie.mp4
  ?Expires=1735689600
  &Signature=...
  &Key-Pair-Id=APKAI...

Это отличается от пред-подписанного URL S3 (S3 presigned URL), который обходит CloudFront и предоставляет прямой доступ к бакету. Используйте подписанные URL CloudFront в паре с OAC, и бакет останется полностью приватным.

Гео-ограничение (Geo-restriction) применяет белые или черные списки на уровне стран на уровне дистрибуции, прежде чем запросы попадут в кэш или к источнику. Оно использует поддерживаемую CloudFront базу данных GeoIP и является дешевым, защищенным от обхода кэша механизмом для соблюдения лицензионных эмбарго. Для более тонкой логики (на уровне штатов, комбинаций заголовков) используйте CloudFront Function или Lambda@Edge; для полноценного движка правил — WAF.

AWS Global Accelerator

Global Accelerator — это не CDN, и он не кеширует данные. Он предоставляет два статических anycast IPv4-адреса (или BYOIP), анонсируемых из пограничных точек AWS (edge locations) по всему миру. TCP- или UDP-соединения клиентов входят в магистральную сеть AWS в ближайшей пограничной точке и маршрутизируются по приватной сети AWS к самой работоспособной конечной точке (ALB, NLB, EC2 или Elastic IP) в одном или нескольких регионах, сгруппированных в группы конечных точек с регуляторами трафика и весами.

Статические IP-адреса дают три конкретных преимущества: клиентам и белым спискам брандмауэров не требуются изменения, даже если архитектура бэкенда перестраивается; региональное аварийное переключение завершается за секунды за счет перенаправления трафика между группами конечных точек при изменении результатов проверок состояния, что полностью обходит проблему распространения DNS TTL; и TCP-рукопожатие завершается в пограничной точке, а дальняя передача данных происходит по магистральной сети AWS.

Выбирайте Global Accelerator, когда:

• Протокол не является HTTP: UDP для игр или VoIP, MQTT, SIP, SFTP, кастомный TCP.
• Вам нужны статические IP-адреса для корпоративных белых списков или мобильных приложений с жестко закодированными адресами.
• Вам необходимо региональное аварийное переключение менее чем за минуту для stateful-развертываний в режиме active-active.
• Рабочая нагрузка динамическая и некешируемая, поэтому CDN приносит мало пользы.

Выбирайте CloudFront, когда:

• Контент кешируемый (изображения, видеосегменты, статический HTML, ответы API с TTL).
• Вы хотите использовать вычисления на пограничных серверах через Lambda@Edge или CloudFront Functions.
• Вам нужны WAF, подписанные URL/cookies или шифрование на уровне полей в пограничной точке.

Две ловушки, которых следует избегать. Выбор CloudFront, чтобы «сделать наши игровые серверы быстрее по всему миру», — это ошибка, потому что игровой трафик использует UDP и не кешируется — здесь требуется Global Accelerator. И наоборот, выбор Global Accelerator для статического веб-сайта — это дорого (фиксированная почасовая плата плюс плата за гигабайт) и лишает преимуществ кеширования — CloudFront значительно сократил бы исходящий трафик из источника. Для глобально распределенного, но находящегося в одном регионе HTTP API, где пользователи готовы мириться с задержкой, обычной маршрутизации на основе задержки в Route 53 может быть достаточно, и это будет дешевле обоих вариантов.

Политики маршрутизации Route 53 для глобального трафика

Route 53 выбирает, в какую конечную точку будет разрешен запрос клиента; затем CloudFront или Global Accelerator обрабатывают соединение. В глобальных архитектурах преобладают три политики.

Маршрутизация на основе задержки (Latency-based routing) измеряет фактическую сетевую задержку от местоположения резолвера до каждого региона и возвращает самый быстрый. Используйте ее для идентичных стеков в нескольких регионах, когда вы хотите, чтобы пользователи направлялись в тот регион, который в данный момент является самым быстрым.

Геопроксимити-маршрутизация (Geoproximity routing) основана на координатах, а не на задержке: вы объявляете местоположение (или регион AWS) каждой конечной точки, и Route 53 направляет пользователей к географически ближайшей. Ее отличительной чертой является значение смещения (bias) (от -99 до +99), которое расширяет или сужает эффективную зону обслуживания — это полезно для постепенного переключения трафика во время запуска в новом регионе или для вывода региона из эксплуатации для обслуживания. Геопроксимити-маршрутизация требует использования потоков трафика Route 53 (traffic policies) и обычно используется в паре с региональным NLB или ALB в каждом регионе.

RecordSets:
  - Region: eu-west-1
    Endpoint: nlb-eu.example.internal
    Bias: +30       # expand EU service area during launch
  - Region: us-east-1
    Endpoint: nlb-us.example.internal
    Bias: 0
  - Region: ap-southeast-1
    Endpoint: nlb-ap.example.internal
    Bias: 0

Маршрутизация для отказоустойчивости (Failover routing) использует пару «основной/резервный» (primary/secondary), привязанную к проверкам состояния. Это аварийное переключение на уровне DNS, зависящее от TTL и кеширования резолверов, поэтому оно медленнее, чем переключение на уровне данных (data-plane) в Global Accelerator. Выбирайте failover routing для простых конфигураций active-passive, где допустима задержка в минуту на распространение DNS, и Global Accelerator, когда вам нужны секунды.

Эти политики можно комбинировать. Распространенный глобальный паттерн: записи Route 53 с маршрутизацией на основе задержки или геопроксимити указывают на Global Accelerator (для TCP/UDP) или CloudFront (для кешируемого HTTPS), а под ними в качестве подстраховки находятся записи для отказоустойчивости с проверками состояния. Такое многоуровневое построение не случайно: Route 53 выбирает регион, Global Accelerator или CloudFront выбирают пограничную точку и путь через магистральную сеть, а региональный балансировщик нагрузки выбирает целевой ресурс внутри региона.

Типы конечных точек API Gateway и пользовательские домены

API Gateway предлагает три типа конечных точек с различными топологиями:

Конечные точки типа Edge-optimized «заворачивают» API в дистрибутив CloudFront, управляемый AWS, который вы не можете настраивать напрямую. Это удобно для быстрого обеспечения глобального доступа, но ограничивает, когда вам нужны собственные поведения кеширования, правила WAF или политики запросов к источнику. Идиоматический паттерн для максимального контроля — это региональная конечная точка (Regional endpoint), перед которой находится управляемый клиентом дистрибутив CloudFront.

Размещение сертификата следует правилу CloudFront: для пользовательских доменов с конечными точками Edge-optimized требуется сертификат ACM в регионе us-east-1; для региональных конечных точек (Regional endpoints) сертификат требуется в том же регионе, что и API. HTTP API требуют как минимум TLS 1.2; REST API поддерживают политики безопасности до TLS 1.3.

Сертификаты ACM: выданные, проверенные, импортированные

ACM бесплатно выдает и автоматически продлевает публичные TLS-сертификаты и напрямую интегрируется с CloudFront, API Gateway, ALB, NLB и другими сервисами AWS. Валидация бывает двух видов: DNS-валидация (ACM предоставляет вам запись CNAME для размещения в Route 53 или у любого другого DNS-провайдера; пока запись существует, ACM автоматически продлевает сертификат бесконечно) или валидация по электронной почте (требует ручного подтверждения при каждом продлении, что делает автоматизацию хрупкой). DNS-валидация — это правильный выбор по умолчанию для любой производственной среды.

Сертификаты, выданные ACM, нельзя экспортировать и использовать вне интегрированных сервисов AWS. Когда нормативное или бизнес-требование предписывает использование определенного стороннего центра сертификации (CA) — например, для REST API, который должен иметь цепочку доверия до конкретного коммерческого издателя и применять TLS 1.3 — вы не можете использовать сертификат, выданный ACM. В этом случае получите сертификат от требуемого CA и импортируйте его в ACM, а затем прикрепите к пользовательскому домену регионального API Gateway с политикой безопасности TLS 1.3.

С импортом связана двойная ловушка: импортированные сертификаты не продлеваются автоматически (их нужно повторно импортировать до истечения срока действия, иначе эндпоинт полностью выйдет из строя), и ACM не проверяет цепочку сертификатов при импорте — неработающий промежуточный сертификат проявит себя только во время рукопожатия (handshake) с реальными клиентами. Перед развертыванием протестируйте полную цепочку на строгом клиенте.

S3 Transfer Acceleration в сравнении с CloudFront

CloudFront оптимизирует загрузки (downloads); S3 Transfer Acceleration оптимизирует выгрузки (uploads). Transfer Acceleration использует ту же пограничную сеть CloudFront в обратном направлении: запросы PUT поступают в ближайшую пограничную точку и передаются по магистральной сети AWS в регион целевого бакета. Этот сервис особенно эффективен, когда географически распределенные пользователи выгружают большие объекты в бакет, расположенный в одном регионе — например, инженеры на местах по всему миру загружают чертежи размером в несколько гигабайт в us-east-1.

Эти две функции могут сосуществовать на одном бакете: включите Transfer Acceleration и настройте дистрибуцию CloudFront с OAC для загрузок. Для небольших объектов или для клиентов, которые уже находятся недалеко от региона бакета, Transfer Acceleration увеличивает затраты без выгоды — используйте инструмент сравнения скорости S3 Transfer Acceleration для измерения производительности, прежде чем принимать решение. Чтобы ускорение работало, клиенты должны использовать эндпоинт s3-accelerate.

AWS WAF для защиты на 7-м уровне

AWS WAF проверяет HTTP(S)-запросы до того, как они достигнут защищаемого ресурса. Он применяется к дистрибуциям CloudFront, ALB, стадиям API Gateway, API AppSync, пулам пользователей Cognito, сервисам App Runner и инстансам Verified Access. Веб-ACL содержит правила, которые срабатывают на основе URI, заголовков, строк запроса, тела запроса (до 8 КБ по умолчанию, с возможностью расширения до 64 КБ для ALB/API Gateway), наборов IP-адресов и геолокации.

Самые распространенные стандартные блоки — это управляемые правила AWS (AWS Managed Rules): AWSManagedRulesCommonRuleSet и AWSManagedRulesKnownBadInputsRuleSet покрывают основные эксплойты из списка OWASP Top; AWSManagedRulesSQLiRuleSet и правила для сопоставления XSS противодействуют инъекциям. Пользовательские правила добавляют географическое сопоставление (белые/черные списки стран для соответствия требованиям), сопоставление с наборами IP-адресов и правила на основе частоты запросов (rate-based rules), которые подсчитывают запросы с одного IP-адреса источника за скользящее пятиминутное окно и блокируют его при превышении порога. Правила на основе частоты запросов — это первая линия защиты от HTTP-флуда и атак подбора учетных данных (credential stuffing):

{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 500,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority":0,"Type":"NONE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

Правила, связанные с регионами, имеют значение. Веб-ACL для CloudFront являются глобальными и должны создаваться в регионе us-east-1. Веб-ACL для региональных ресурсов (ALB, API Gateway и т.д.) создаются в том же регионе, где находится ресурс.

Чтобы защитить статический сайт на S3, вы не можете применить WAF напрямую к бакету — S3 не является ресурсом, поддерживаемым WAF. Правильный паттерн — это использование CloudFront + OAC перед бакетом, с веб-ACL, примененным к дистрибуции. Именно то, что бакет недоступен иначе как через CloudFront, и обеспечивает проверку всего трафика.

Firewall Manager для управления WAF в нескольких аккаунтах

Управление WAF в каждом аккаунте по отдельности не масштабируется. В рамках организации команда может развернуть новый ALB, не применив к нему корпоративный стандарт безопасности, и уровень соответствия требованиям незаметно снижается. AWS Firewall Manager решает эту проблему с помощью политик, действующих в масштабах всей организации и применяемых к аккаунтам и ресурсам, подпадающим под их действие.

Предварительные условия: AWS Organizations с включенными всеми функциями (all-features), назначенный аккаунт администратора Firewall Manager и включенный AWS Config в каждом аккаунте-участнике. Типы политик охватывают AWS WAF, AWS Shield Advanced, группы безопасности (аудит и использование), Network Firewall, Route 53 Resolver DNS Firewall и межсетевые экраны сторонних производителей.

Политика WAF может принудительно применять группу правил «first» (которая оценивается до правил, принадлежащих приложению), группу правил «last» (после них) или полностью заменять веб-ACL. Новые ALB или дистрибуции CloudFront, соответствующие области действия ресурсов, автоматически получают корпоративный набор правил, а несоответствующие ресурсы помечаются и — в зависимости от настроек исправления — автоматически корректируются. Каждый раз, когда в сценарии упоминается «несколько аккаунтов», «централизованное управление» или «единообразные правила WAF для всей организации», ответом будет Firewall Manager, а не настройка WAF в каждом аккаунте по отдельности.

Shield Standard и Shield Advanced

Считать, что один лишь WAF останавливает DDoS-атаки — это серьезная ошибка. WAF работает с запросами, которые до него доходят — он отлично справляется с флудом на уровне приложений, атаками с подстановкой учетных данных (credential stuffing) и известными сигнатурами эксплойтов — но крупные объемные атаки на уровнях 3/4 (SYN-флуд, UDP-отражение) поглощаются AWS Shield.

Shield Standard включен по умолчанию и не требует дополнительной платы. Он автоматически защищает от распространенных атак на уровнях L3/L4 и применяется к CloudFront, Route 53 и Global Accelerator, обеспечивая базовую защиту для ELB, EC2 и других ресурсов. Он не предоставляет детальной информации о конкретных атаках, доступа к команде Shield Response Team или защиты от затрат.

Shield Advanced (3000 долларов в месяц на организацию, с обязательством на один год) добавляет:

Предположение, что Shield Standard достаточен для «крупномасштабных DDoS-атак с защитой от затрат и экспертным реагированием», неверно именно потому, что в Standard отсутствуют видимость, защита от затрат и доступ к SRT. Когда источником (origin) является EC2 за ELB, а DNS обслуживается сторонним провайдером (поэтому трюки с alias-записями Route 53 недоступны), рекомендуемый подход — включить Shield Advanced на ELB и выставить приложение наружу через CloudFront (также защищенный Shield Advanced), чтобы переместить периметр защиты на границу сети (edge) и уменьшить поверхность атаки, достигающую региона.

Правильная многоуровневая архитектура защиты выглядит так: Shield для объемных атак L3/L4, WAF для фильтрации L7, CloudFront или Global Accelerator в качестве пограничной точки входа, к которой подключаются оба сервиса, и Firewall Manager для применения политики во всех аккаунтах.

← Сети и подключения · Все домены · Базы данных и кеширование →

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

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