Amazon ANS-C01: Доставка контента и периферийные сети — Руководство по подготовке

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

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

Основные концепции

Доставка контента и периферийные сети (edge networking) разделяют две связанные обязанности: транспортировка клиентского трафика с низкой задержкой и работа в качестве распределенного уровня кэширования/вычислений вблизи конечных пользователей. CloudFront — это HTTP(S) CDN и платформа для периферийных вычислений, которая кэширует HTTP-ответы, терминирует TLS на периферии и может выполнять код в периферийных точках (edge locations) с помощью Lambda@Edge (полная среда выполнения Lambda, реплицированная в регионы) или CloudFront Functions для легковесного JavaScript на этапах запроса/ответа от зрителя (viewer request/response). Поведение CloudFront определяется объектами конфигурации распределения (distribution), создаваемыми с помощью CreateDistribution и настраиваемыми с помощью объектов CachePolicy и OriginRequestPolicy. Поля политики кэширования, такие как DefaultTTL, MinTTL и MaxTTL, а также набор заголовков, cookie и строк запроса, включенных в ключ кэша, определяют коэффициент попадания в кэш и нагрузку на источник (origin). Средства контроля источника включают S3 OAC/OAI для частных источников S3 (CreateCloudFrontOriginAccessControl) и подписанные URL или подписанные cookie (CreateKeyGroup, CreatePublicKey и процесс подписи URL) для защиты частного контента.

Global Accelerator и Anycast работают ниже уровня HTTP. Global Accelerator анонсирует два статических Anycast IP-адреса из периферийной сети AWS и направляет TCP/UDP потоки к работоспособным региональным конечным точкам (Network Load Balancers, Application Load Balancers, инстансы EC2 или Elastic IPs). Поскольку Global Accelerator работает на уровнях L3/L4, он сохраняет сквозное шифрование TLS при конфигурации для сквозной передачи TCP (TCP pass-through) и улучшает глобальную маршрутизацию, используя внутреннюю магистральную сеть AWS для «последней мили» до региональных конечных точек. Для протоколов, отличных от HTTP, или когда необходимо сохранить истинное сквозное шифрование и взаимную аутентификацию TLS (mTLS) между клиентом и бэкендом, каноническим шаблоном является путь сквозной передачи TCP с использованием Global Accelerator перед Network Load Balancer (NLB): NLB работают на уровне L4, масштабируются до миллионов соединений и могут регистрировать IP-адреса подов или узлов в Amazon EKS в качестве целевых объектов (IP targets).

Функции Lambda@Edge связываются с поведением (behaviors) CloudFront и должны быть развернуты (CreateFunction с Publish) и ассоциированы в LambdaFunctionAssociations распределения для триггеров viewer-request, origin-request, origin-response и viewer-response. Поскольку Lambda@Edge реплицируется в несколько периферийных регионов, версии и семантика публикации имеют большое значение; используйте версионированные объекты Lambda и тщательно управляйте развертываниями, чтобы избежать несогласованного поведения во время обновлений.

Ключевые сервисы и конфигурация

Конфигурация распределения CloudFront зависит от трех тесно связанных объектов: самого распределения (CreateDistribution / UpdateDistribution), объектов CachePolicy, которые определяют ключ кэша и TTL (CreateCachePolicy), и объектов OriginRequestPolicy, которые определяют, какие заголовки/cookie/строки запроса отправляются источнику (CreateOriginRequestPolicy). Для частного контента в S3 используйте CreateCloudFrontOriginAccessControl или устаревший механизм origin access identity, и дополнительно защищайте доступ с помощью подписанных URL / подписанных cookie, используя CreateKeyGroup и CreatePublicKey; SDK или утилиты cloudfront-signing генерируют подписанный URL или документ политики и подпись RSA. Операции инвалидации выполняются с помощью CreateInvalidation для выборочного удаления кэшированных объектов.

Конфигурация Global Accelerator создается с помощью API-вызовов create-accelerator, create-listener и create-endpoint-group. Прослушиватель (listener) может быть настроен на TCP:443 для gRPC или на любой другой TCP-порт и будет перенаправлять потоки в группы конечных точек (endpoint groups), которые указывают на региональный NLB или ALB. Когда Global Accelerator используется для сквозной передачи TCP с сохранением сквозного TLS и mTLS, его следует использовать в паре с Network Load Balancer, у которого есть TCP-прослушиватели на порту 443 и целевые группы (target groups), регистрирующие IP-адреса подов (target type ip) или порты узлов (node ports). В Kubernetes EKS это обычно достигается путем создания Service типа LoadBalancer с аннотациями, такими как service.beta.kubernetes.io/aws-load-balancer-type: “nlb” и service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”, или с помощью AWS Load Balancer Controller для создания NLB с типом цели (target type) ip. Сохраняйте исходный IP-адрес клиента для логирования, установив externalTrafficPolicy: Local в Service или используя сквозную передачу NLB (NLB passthrough), которая сохраняет исходный IP-адрес.

Принудительное применение правил на сетевом уровне между Global Accelerator и региональными конечными точками использует управляемые AWS списки префиксов (prefix lists) для снижения административных издержек. Вызов AWS CLI aws ec2 describe-managed-prefix-lists выводит список управляемых списков префиксов; тот, что назван com.amazonaws.globalaccelerator, можно использовать в правилах групп безопасности (AuthorizeSecurityGroupIngress с –source-prefix-list), чтобы разрешить трафик к ALB/NLB только от акселератора. Там, где ALB терминирует TLS, используйте заголовки X-Forwarded-For для логирования IP-адреса клиента; при использовании сквозной передачи NLB с Global Accelerator IP-адреса клиентов сохраняются нативно, а бэкенды должны самостоятельно обрабатывать терминирование TLS/mTLS.

Архитектурные шаблоны и компромиссы

Когда требуется кэширование контента, вычисления на периферии и HTTP-ответы с низкой задержкой, CloudFront является подходящим инструментом. CloudFront должен терминировать TLS на периферии, когда конфиденциальность источника (origin) не требуется; используйте CachePolicy и OriginRequestPolicy для минимизации запросов к источнику, исключая из ключа кэша заголовки и cookie, где это безопасно. Для динамической персонализации, которая все еще может выигрывать от кэширования, используйте нормализацию ключа кэша (варьируя его по минимальному набору заголовков или подписанных cookie) и проектируйте инвалидацию кэша через версионированные ключи объектов, а не через частые вызовы CreateInvalidation.

Для протоколов, требующих сквозного (end-to-end) TLS, а также для потоков HTTP/2 и gRPC, которые не должны расшифровываться до бэкенда (для mTLS), используйте путь TCP/L4 с Global Accelerator + NLB в режиме TLS passthrough. Компромисс заключается в потере возможностей CloudFront по HTTP-кэшированию и вычислениям на периферии; однако Global Accelerator предоставляет статические IP-адреса anycast, улучшенную маршрутизацию и региональную отказоустойчивость. ALB поддерживает HTTP/2 и gRPC, когда ALB терминирует TLS, что позволяет использовать маршрутизацию на уровне приложения (на основе хоста/пути) и интеграцию с WAF, но терминирование на ALB нарушает сквозной mTLS и переносит управление сертификатами на балансировщик нагрузки. Для массовых одновременных подключений NLB лучше масштабируются на уровне L4 — NLB оптимизированы для высокой скорости соединений и сохраняют IP-адрес источника, в то время как ALB предназначены для маршрутизации на уровне HTTP и таких функций, как правила прослушивателя (listener rules) для маршрутизации на уровне хоста/пути и интеграции с Cognito/OIDC.

Средства контроля безопасности и шаблоны региональной изоляции требуют тщательного выбора между общим VPC peering, Transit Gateway, PrivateLink и эндпоинтами Load Balancer. PrivateLink обеспечивает гранулярный контроль доступа на уровне сервиса и хорошо масштабируется для множества потребителей, поскольку каждый потребитель создает интерфейсный эндпоинт (interface endpoint) в своем VPC. Transit Gateway подходит для централизации с высокой пропускной способностью, но ему не хватает гранулярного контроля на уровне отдельных сервисов и видимости на уровне SNI/хоста, которые предоставляет эндпоинт PrivateLink. При проектировании необходимо учитывать лимиты маршрутизации, меж-аккаунтные разрешения и возможность применять группы безопасности (security groups) на границе сервиса.

Распространенные ошибки и критерии принятия решений

Частая ошибка — неправильное смешивание элементов управления кэшированием: разрешение заголовкам Cache-Control, установленным источником, управлять кэшированием на периферии, в то время как применяются и политики кэширования CloudFront, может привести к неожиданным значениям TTL; предпочитайте явное использование объектов CachePolicy и не полагайтесь исключительно на заголовки источника, если это не сделано намеренно. Другая ошибка — выбор ALB, когда требуется сквозной TLS или миллионы одновременных TCP-соединений; терминирование TLS на ALB препятствует mTLS и может стать узким местом при очень высокой конкурентности соединений. В конфигурациях безопасности, пытающихся ограничить доступ к интернет-ориентированному ALB, часто забывают заблокировать доступ с помощью списка префиксов Global Accelerator или правила WAF; без явных разрешающих правил ALB останется доступным через свой публичный DNS. Наконец, развертывания Lambda@Edge, не использующие версионированные Lambda-функции, могут вызывать несогласованное поведение во время выкатки, поскольку ассоциация в дистрибуции привязана к конкретной опубликованной версии.

Практическая задача: сценарий использования

Компания: AcmeTelemetrics — задача: глобальный парк IoT-вендинговых автоматов использует gRPC через TCP:443 для связи с бэкендом в us-east-1, работающим на Amazon EKS; требуется сквозное взаимное TLS (mTLS), чтобы трафик никогда не расшифровывался при передаче, поддержка тысяч одновременных подключений и статические IP-адреса, которые должны быть запрограммированы в автоматах.

Подход:

1. Создайте Global Accelerator (aws globalaccelerator create-accelerator) с двумя статическими IP-адресами anycast и TCP-прослушивателем на порту 443 (create-listener). Настройте группу эндпоинтов (endpoint group), которая нацелена на региональный Network Load Balancer в us-east-1 (create-endpoint-group).
2. Подготовьте NLB в us-east-1 с TCP-прослушивателем на порту 443 и целевой группой (target group) типа ip. В Kubernetes создайте сервис (Service) типа LoadBalancer с аннотациями service.beta.kubernetes.io/aws-load-balancer-type: “nlb” и service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”, установите externalTrafficPolicy: Local и зарегистрируйте IP-адреса подов в качестве целей, чтобы TLS проходил напрямую к подам.
3. Разверните gRPC-серверы в EKS и терминируйте TLS/mTLS в процессах подов. Храните сертификаты и доверенные материалы в Kubernetes Secrets; настройте сервер так, чтобы он требовал проверку клиентского сертификата для взаимного TLS (mutual TLS).
4. Заблокируйте прямой доступ к NLB, чтобы к нему мог обращаться только Global Accelerator, обновив группу безопасности NLB. Разрешите входящий трафик только из управляемого AWS списка префиксов Global Accelerator (его можно найти с помощью aws ec2 describe-managed-prefix-lists и сослаться на него в правилах группы безопасности), что не позволит автоматам обходить accelerator и обращаться к NLB напрямую.
5. Отслеживайте конкурентность подключений и масштабирование, настроив Kubernetes HorizontalPodAutoscaler и Cluster Autoscaler. Убедитесь, что параметры slow start и deregistration delay целевой группы NLB настроены для плавного сжатия (graceful scale-in) (modify-target-group-attributes). Используйте метрики CloudWatch от Global Accelerator, NLB и EKS для наблюдения за количеством подключений и их состоянием.

Обоснование со стороны AWS: Global Accelerator предоставляет статические IP-адреса anycast, необходимые для вендинговых автоматов, и маршрутизирует TCP-потоки по магистральной сети AWS к региональному NLB, повышая надежность и уменьшая задержку. NLB сохраняет исходное TCP-соединение клиента и его IP-адрес, а также поддерживает массовые одновременные подключения, позволяя подам выполнять терминирование mTLS без промежуточного терминирования TLS. Использование управляемого списка префиксов Global Accelerator в правилах групп безопасности предотвращает прямой обход accelerator и гарантирует, что трафик поступает только через IP-адреса anycast. Эта комбинация удовлетворяет требованиям к сквозному шифрованию, mTLS, высокой конкурентности, статическим IP-адресам и автомасштабированию в EKS.

← Сетевая безопасность и соответствие требованиям · Все домены · Производительность сети и мониторинг →

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

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