Облако AWS
Попробовать Amazon CloudFront бесплатно

Информацию обо всех новых возможностях сервиса Amazon CloudFront см. на странице новых возможностей »

Глобальная сеть периферийных местоположений Amazon CloudFront

Для снижения задержки при доставке контента конечным пользователям Amazon CloudFront использует глобальную сеть из 134 точек присутствия (123 периферийных местоположения и 11 периферийных серверов кэширования в регионах) в 61 городе и 28 странах. Где находятся периферийные местоположения Amazon CloudFront.

Глобальная сеть периферийных местоположений Amazon CloudFront

Периферийные местоположения: Ашберн, Вирджиния (3); Атланта, Джорджия (3); Бостон, Массачусетс; Чикаго, Иллинойс (2); Даллас и Форт‑Уэрт, Техас (5); Денвер, Колорадо (2); Хэйвард, Калифорния; Джэксонвилл, Флорида; Лос‑Анджелес, Калифорния (4); Майами, Флорида (3); Миннеаполис, Миннесота; Монреаль, Квебек; Нью‑Йорк, штат Нью‑Йорк (3); Ньюарк, Нью‑Джерси (3); Пало‑Альто, Калифорния; Филадельфия, Пенсильвания; Феникс, Аризона; Сан‑Хосе, Калифорния (2); Сиэтл, Вашингтон (3); Саут‑Бенд, Индиана; Сент‑Луис, Миссури; Торонто, Онтарио

Периферийные серверы кэширования в регионах: Вирджиния, Огайо, Орегон

Периферийные местоположения: Амстердам, Нидерланды (2); Берлин, Германия; Копенгаген, Дания; Дублин, Ирландия; Франкфурт, Германия (8); Хельсинки, Финляндия; Лондон, Великобритания (7); Мадрид, Испания (2); Манчестер, Великобритания; Марсель, Франция; Милан, Италия; Мюнхен, Германия; Осло, Норвегия; Палермо, Италия; Париж, Франция (3); Прага, Чешская Республика; Стокгольм, Швеция (3); Вена, Австрия; Варшава, Польша; Цюрих, Швейцария

Периферийные серверы кэширования в регионах: Франкфурт, Германия; Лондон, Великобритания

Периферийные местоположения: Бангалор, Индия; Ченнаи, Индия (2); Гонконг, Китай (3); Куала‑Лумпур, Малайзия; Мумбаи, Индия (2); Манила, Филиппины; Нью‑Дели, Индия; Осака, Япония; Сеул, Южная Корея (4); Сингапур (3); Тайбэй, Тайвань (3); Токио, Япония (9)

Периферийные серверы кэширования в регионах: Мумбаи, Индия; Сингапур; Сеул, Южная Корея; Токио, Япония

Периферийные местоположения: Мельбурн, Перт, Сидней

Периферийные серверы кэширования в регионах: Сидней

Периферийные местоположения: Сан‑Паулу, Бразилия (2); Рио‑де‑Жанейро, Бразилия (2)

Периферийные серверы кэширования в регионах: Сан‑Паулу, Бразилия

Периферийные местоположения: Йоханнесбург, ЮАР; Кейптаун, ЮАР

Джеймс Хэмилтон
3:54
Конференция re:Invent 2016. Introduction to Amazon Global Network and CloudFront PoPs with James Hamilton
Джеймс Хэмилтон

Динамический и индивидуально настроенный контент

Amazon CloudFront можно использовать для доставки любого контента, в том числе динамических элементов сайта, которые меняются в зависимости от конечного пользователя. CloudFront позволяет настроить несколько серверов‑источников и разнообразные варианты работы кэша на основе шаблонов URL‑путей сайта. Можно также задать минимальное значение срока хранения (также известное как «время жизни», или TTL) вплоть до нуля секунд, опознавать запросы пользователей на основе используемого устройства и страны, в которой конечный пользователь получает доступ к вашему контенту (геотаргетинг), и указывать, какие параметры строки запроса, файлы cookie или стандартные заголовки HTTP‑запросов нужно перенаправлять на собственный (отличный от S3) сервер источника. Кроме того, интеграция с Lambda@Edge позволяет специальным образом или индивидуально настраивать контент для конечных пользователей, выполняя его обработку в ближайшем местоположении за счет создания функций AWS Lambda, их развертывания в глобальной сети CloudFront и выполнения в ответ на события CloudFront.

Возможности безопасности

Amazon CloudFront можно настроить на принудительное установление сквозных HTTPS‑подключений от конечного пользователя до источника.  Интеграция CloudFront с AWS Certificate Manager позволяет создавать бесплатные собственные сертификаты SSL или использовать имеющиеся, развертывая их за считаные минуты. CloudFront поддерживает расширенные протоколы и шифры, а также расширенные возможности SSL, такие как Session Tickets, OCSP Stapling и Perfect Forward Secrecy. Можно также использовать шифрование на уровне поля для дополнительного шифрования конфиденциальных данных в форме HTTPS, чтобы информацию могли просматривать только определенные компоненты и сервисы исходной инфраструктуры. Используя CloudFront, можно также безопасно передавать частный контент, используя подписанные URL‑адреса и подписанные заверителями файлы cookie, а также использовать удостоверения доступа к источнику (OAI), чтобы ограничить доступ к определенной корзине Amazon S3. CloudFront интегрирован с AWS WAF, брандмауэром интернет‑приложений, который помогает защитить приложения от распространенных сетевых эксплойтов, и с AWS Shield, управляемым сервисом защиты от DDoS‑атак, который обеспечивает безопасность интернет‑приложений на AWS. Защита AWS Shield Standard предоставляется всем пользователям CloudFront бесплатно. CloudFront соответствует требованиям HIPAA и PCI DSS, он позволяет регистрировать изменения в настройках баз раздачи для целей аудита с помощью AWS CloudTrail.

Возможности потоковой передачи

Amazon CloudFront поддерживает множество протоколов потоковой передачи мультимедиа, обеспечивающих передачу аудио и видео как в режиме прямой трансляции, так и по требованию. CloudFront можно использовать для прямых видеотрансляций и доставки видео по требованию (VOD) с использованием технологий HLS, MPEG‑DASH или Microsoft Smooth Streaming. При этом нет необходимости устанавливать мультимедийные серверы и управлять ими. CloudFront интегрирован с мультимедийными сервисами AWS из семейства полностью управляемых сервисов AWS Elemental, которые упрощают создание надежных процессов облачной обработки видео с качеством на уровне вещательных компаний. Эти сервисы обеспечивают преобразование видеофайлов (AWS Elemental MediaConvert), обработку видео в режиме реального времени (AWS Elemental MediaLive), своевременное сжатие видео (AWS Elemental MediaPackage), высокопроизводительное оптимизированное хранение видео (AWS Elemental MediaStore) и вставку рекламы в видеопотоки на стороне сервера (AWS Elemental MediaTailor).

Отчеты и аналитика

Amazon CloudFront предлагает различные решения для создания отчетов, например для получения подробных сведений по статистике кэша, отслеживания использования CloudFront с помощью Amazon CloudWatch в режиме, близком к режиму реального времени, отслеживания самых популярных объектов, настройки предупреждений на основании рабочих метрик, а также для того, чтобы узнать больше о конечных пользователях и о том, с каких доменов они пришли на сайт. Можно также получать информацию о трафике, передаваемом из базы раздачи Amazon CloudFront, включив бесплатное ведение журналов доступа CloudFront. Подробнее об отчетах и аналитике в CloudFront.

Вопрос: Что такое Amazon CloudFront?

Amazon CloudFront – это веб‑сервис, предоставляющий компаниям и разработчикам интернет‑приложений простой и экономичный способ распространения контента с высокой скоростью передачи данных и низкими задержками. Подобно другим сервисам AWS, Amazon CloudFront основан на принципах самообслуживания с оплатой по факту использования без каких‑либо долгосрочных обязательств или минимальных платежей. При использовании CloudFront файлы доставляются конечным пользователям через глобальную сеть периферийных местоположений.

Вопрос: В каких целях можно использовать Amazon CloudFront?

Amazon CloudFront предоставляет простой API, позволяющий вам:

  • распространять контент с низкими задержками и высокой скоростью передачи данных путем обслуживания запросов с использованием сети периферийных местоположений по всему миру;
  • начать работу без заключения контрактов и минимальных обязательств.

Вопрос: Как начать работу с Amazon CloudFront?

Нажмите «Создать бесплатный аккаунт» на странице сведений об Amazon CloudFront. При выборе в качестве источника файлов для Amazon CloudFront другого сервиса AWS следует зарегистрироваться в этом сервисе до создания баз раздачи CloudFront.

Вопрос: Как можно использовать CloudFront?

Для использования Amazon CloudFront требуется предпринять следующие шаги.

  • Для статических файлов: сохраните их окончательные версии на одном или нескольких серверах источников. Можно использовать для этого корзины Amazon S3. Для динамически создаваемого и индивидуально настраиваемого контента можно использовать в качестве сервера источника Amazon EC2 или любой другой веб‑сервер. Серверы источника хранят или генерируют контент для последующего распространения с помощью Amazon CloudFront.
  • Зарегистрируйте серверы источника в Amazon CloudFront, используя простой вызов API. Этот вызов вернет доменное имя CloudFront.net, которое можно использовать для распространения контента с серверов источника с помощью сервиса Amazon CloudFront. Например, можно зарегистрировать корзину Amazon S3 с именем bucketname.s3.amazonaws.com в качестве источника статического контента и инстанс Amazon EC2 с именем dynamic.myoriginserver.com в качестве источника динамического контента. После этого с помощью API или Консоли управления AWS можно создать базу раздачи Amazon CloudFront, которая вернет имя вида abc123.cloudfront.net в качестве доменного имени базы раздачи.
  • Доменное имя cloudfront.net либо созданный на его основе псевдоним CNAME можно использовать в интернет‑приложениях, проигрывателях мультимедиа или на веб‑сайтах. Все запросы, включающие доменное имя cloudfront.net или имя CNAME, перенаправляются к ближайшему периферийному местоположению для обеспечения максимальной производительности при доставке контента. При выполнении запроса периферийное местоположение пытается найти локальную копию файла. Если такой копии нет, Amazon CloudFront получает ее с сервера источника. Полученная копия сохраняется в этом периферийном местоположении для обслуживания дальнейших запросов.

Вопрос: За счет чего Amazon CloudFront обеспечивает повышенную производительность?

Amazon CloudFront использует глобальную сеть периферийных местоположений и периферийные серверы кэширования в регионах, чтобы обеспечить хранение копий объектов как можно ближе к конечным пользователям. Amazon CloudFront следит, чтобы запрос конечного пользователя обслуживался ближайшим к нему периферийным местоположением. В результате такого подхода запросы пользователя проходят минимальное расстояние, что положительно сказывается на производительности. Amazon CloudFront поддерживает постоянное соединение с серверами‑источниками, чтобы как можно быстрее получать файлы, копий которых нет в периферийных местоположениях или на периферийных серверах кэширования в регионах. Наконец, Amazon CloudFront использует для ускорения доставки контента пользователям дополнительную оптимизацию, например расширенное исходное окно перегрузки протокола TCP.

Вопрос: Как Amazon CloudFront помогает сократить расходы при распространении контента через Интернет?

Как и другие сервисы AWS, Amazon CloudFront не требует минимальных обязательств и оплачивается только по факту использования. В отличие от самостоятельного хостинга Amazon CloudFront избавляет от расходов и сложностей, связанных с поддержкой сети кэширующих серверов, распределенных по всему Интернету, и не требует избыточных ресурсов для обслуживания пиковых нагрузок. Amazon CloudFront использует принцип объединения одновременных клиентских запросов одного и того же файла в пределах периферийного местоположения, выполняя единственный запрос на сервер источника для получения копии этого файла. Это снижает нагрузку на сервер, уменьшая потребность в масштабировании инфраструктуры источника, что обеспечивает дополнительную экономию.

Кроме того, при использовании источников AWS (Amazon S3, Amazon EC2 и т. п.) с 1 декабря 2014 года не взимается плата за исходящую передачу данных в Amazon CloudFront. Это касается передачи данных из всех регионов AWS в любые периферийные местоположения CloudFront по всему миру.

Вопрос: За счет чего Amazon CloudFront может ускорить веб‑сайт в целом?

Amazon CloudFront использует стандартные заголовки управления кэшированием, установленные клиентами для файлов с целью разделения статического и динамического контента. Доставка всего контента с использованием единой базы раздачи Amazon CloudFront обеспечивает оптимизацию производительности для сайта или интернет‑приложения в целом. При использовании источников AWS вы получаете ряд преимуществ: это интеграция Amazon CloudFront с другими сервисами AWS, а также удобство использования и повышение производительности и надежности, поскольку AWS получает возможность отслеживать и корректировать маршруты до источников, проводить мониторинг работоспособности системы и быстро реагировать на любые проблемы. Еще одним преимуществом является возможность использования разных источников для разных типов контента, например Amazon S3 для статических объектов, Amazon EC2 для динамического контента и собственных источников для стороннего контента. Оплата при этом будет начисляться только за использованные ресурсы.

Вопрос: В чем отличие Amazon CloudFront от Amazon S3?

Amazon CloudFront предпочтителен для распространения часто запрашиваемого статического контента, например популярных изображений на веб‑сайтах, видеоматериалов, медиафайлов или программного обеспечения для загрузки. В этом случае доставка с использованием периферийных местоположений имеет очевидные преимущества.

Вопрос: В чем отличие Amazon CloudFront от традиционных решений для доставки контента?

Amazon CloudFront позволяет быстро начать использовать преимущества высокопроизводительной доставки контента без предварительного заключения контрактов и высоких расходов. Amazon CloudFront предоставляет разработчикам доступ на основе модели самообслуживания с низкими ценами и оплатой ресурсов по факту использования. Дополнительные преимущества разработчикам обеспечивает тесная интеграция с другими сервисами AWS. Предлагаемое решение просто интегрируется с серверами источника сервисов Amazon S3, Amazon EC2 и Elastic Load Balancing, предоставляя разработчикам мощное сочетание надежного хранения с высокопроизводительной доставкой. Amazon CloudFront также интегрирован с сервисами Amazon Route 53 и AWS CloudFormation для дополнительной оптимизации производительности и упрощения настройки.

Вопрос: Какие типы контента поддерживает Amazon CloudFront?

Amazon CloudFront поддерживает любые файлы, которые могут быть переданы по HTTP. Сюда относятся динамические веб‑страницы (HTML или PHP) и распространенные форматы статических файлов, включенных в интернет‑приложение, например изображения для веб‑сайта, аудио‑, видео‑ и другие медиафайлы, а также программное обеспечение для загрузки. Amazon CloudFront также поддерживает прямые трансляции или потоковую передачу мультимедийных материалов по требованию через HTTP.

Вопрос: Работает ли Amazon CloudFront с серверами источника вне AWS?

Да. Amazon CloudFront работает с любыми серверами‑источниками, хранящими окончательные оригинальные версии контента, как статического, так и динамического. За использование собственных источников дополнительная плата не взимается.

Вопрос: Предлагает ли Amazon CloudFront Соглашение об уровне обслуживания (SLA)?

Да. Соглашение об уровне обслуживания Amazon CloudFront предусматривает компенсацию в том случае, если уровень бесперебойной работы за любой учетный период был ниже согласованного. Дополнительные сведения можно найти по ссылке.

Вопрос: Можно ли использовать Консоль управления AWS с сервисом Amazon CloudFront?

Да. Консоль управления AWS можно использовать для настройки сервиса Amazon CloudFront и управления им с помощью простого интерактивного веб‑интерфейса. Консоль управления AWS поддерживает большинство возможностей Amazon CloudFront, что позволяет использовать доставку Amazon CloudFront с низкими задержками без разработки кода или установки специального ПО. Доступ к Консоли управления AWS бесплатно предоставляется по адресу https://console.aws.amazon.com.

Вопрос: Какие инструменты и библиотеки работают с Amazon CloudFront?

Для управления базами раздачи Amazon CloudFront предлагаются различные инструменты и библиотеки для разных языков программирования, доступные в нашем центре ресурсов.

Вопрос: Может ли начало зоны (example.com вместо www.example.com) указывать на базу раздачи Amazon CloudFront?

Да. Используя Amazon Route 53, полномочный DNS‑сервис AWS, можно настроить псевдоним, связывающий начало зоны, или корневой домен (example.com), соответствующего имени DNS с базой раздачи Amazon CloudFront. После этого Amazon Route 53 будет возвращать по имени псевдонима соответствующий IP‑адрес (или адреса) базы раздачи CloudFront. В Route 53 плата за обслуживание запросов псевдонимов, привязанных к базам раздачи CloudFront, не взимается. В отчете об использовании Amazon Route 53 такие запросы будут указаны как «Intra‑AWS‑DNS‑Queries».

Вопрос: Что представляет собой периферийный сервер кэширования CloudFront в регионе?

CloudFront доставляет контент через всемирную сеть центров обработки данных, называемых периферийными местоположениями. Периферийные серверы кэширования в регионах являются связующими звеньями между серверами‑источниками и периферийными местоположениями, которые обеспечивают передачу контента конечным пользователям по всему миру. Это помогает повысить производительность для конечных пользователей, одновременно снижая операционные нагрузки и стоимость масштабирования серверов‑источников.

Вопрос: Как работают периферийные серверы кэширования в регионах?

Периферийные серверы кэширования Amazon CloudFront в регионах добавлены в нескольких местоположениях по всему миру, в максимальной близости к конечным пользователям. Каждый из них является связующим звеном между сервером‑источником и периферийными местоположениями, которые обеспечивают передачу контента конечным пользователям по всему миру. По мере угасания интереса пользователей к тому или иному объекту он удаляется из отдельных периферийных местоположений, освобождая место для более популярного контента. Периферийные серверы кэширования в регионах обладают более объемным кэшем, чем отдельные периферийные местоположения, поэтому на ближайших серверах кэширования в регионах объекты сохраняются дольше. Это позволяет хранить большую часть контента в непосредственной близости от конечных пользователей, сокращает количество вынужденных повторных обращений CloudFront к серверам‑источникам и повышает общее качество обслуживания. Например, периферийные местоположения CloudFront в Европе при поиске объектов теперь обращаются к периферийному серверу кэширования во Франкфурте и только потом отправляют запрос к серверу‑источнику. Периферийные серверы кэширования в регионах в настоящее время используются только для обработки запросов к пользовательским серверам‑источникам. Запросы к источникам в S3 идут в обход региональных серверов кэширования.

Вопрос: Периферийные серверы кэширования в регионах используются сервисом по умолчанию?

Да. Для использования этой возможности не требуется дополнительная настройка раздач CloudFront, она включена по умолчанию для всех новых и ранее созданных баз раздачи. Дополнительная плата за использование этой возможности не взимается.

Вопрос: Где находятся периферийные сетевые местоположения Amazon CloudFront?

Для доставки контента Amazon CloudFront использует глобальную сеть периферийных местоположений и периферийных серверов кэширования в регионах. Полный список местоположений Amazon CloudFront см. по ссылке.

Вопрос: Можно ли ограничить доставку контента только некоторыми странами (или наоборот, отключить доставку контента в некоторые страны)?

Да, возможность географического ограничения позволяет задать список стран, из которых будет доступен определенный контент. Как вариант, можно задать список стран, пользователи из которых не будут иметь доступа к контенту. В обоих случаях на запрос из страны, для которой действует ограничение, CloudFront возвращает ответ с кодом HTTP 403 (Forbidden).

Вопрос: Насколько точна ваша база данных географического распределения IP‑адресов?

Точность отнесения IP‑адреса к какой‑либо стране зависит от региона. По последним данным, общая точность соответствия нашей базы IP‑адресов странам составляет 99,8 %.

Вопрос: Можно ли возвращать конечным пользователям собственные сообщения об ошибках?

Да, вы можете создать собственные сообщения об ошибках (например, файлы HTML или изображения .jpg) с логотипами и контентом для ответов HTTP с кодами 4xx и 5xx. После этого можно настроить Amazon CloudFront на возврат пользователям таких сообщений, когда источник возвращает CloudFront заданные коды ошибок.

Вопрос: Сколько времени Amazon CloudFront хранит файлы в периферийных местоположениях?

По умолчанию (при отсутствии заголовка управления кэшированием) каждое периферийное местоположение при получении запроса проверяет наличие обновленной версии файла, если с момента предыдущей проверки прошло более 24 часов. Это время называется сроком действия объекта. С помощью заголовков управления кэшированием для файлов источника срок действия можно устанавливать от нуля секунд до любого нужного значения. Amazon CloudFront использует эти заголовки для определения, как часто следует проверять источник на наличие обновленной версии файла. Если срок действия ноль секунд, Amazon CloudFront будет проверять файл на сервере источника при каждом запросе. Если файлы изменяются не слишком часто, рекомендуется установить больший срок действия, а для управления обновлениями таких файлов реализовать систему управления версиями.

Вопрос: Как удалить какой‑либо элемент из периферийного местоположения Amazon CloudFront?

Для удаления файла из периферийного местоположения имеется несколько возможностей. Можно просто удалить файл из источника, и когда в периферийных местоположениях истечет срок действия, заданный в HTTP‑заголовке каждого объекта, он будет удален. Для удаления из всех периферийных местоположений Amazon CloudFront оскорбительных или потенциально вредоносных материалов, удалить которые требуется до истечения срока действия, можно использовать API Invalidation. Стоимость запросов на такое удаление см. по ссылке.

Вопрос: Имеются ли ограничения на количество создаваемых запросов API Invalidation?

При удалении отдельных объектов можно создавать запросы API Invalidation, выполняющиеся одновременно не более чем для 3000 объектов на одну базу раздачи. Это может быть один запрос на удаление до 3000 объектов, или до 3000 запросов по одному объекту на каждый, или любая комбинация запросов и объектов, суммарно не превышающая 3000 объектов.

При использовании знака подстановки (*) можно отправить запросы для одновременного аннулирования до 15 путей. Параллельно с этим можно выполнять запросы на удаление до 3000 отдельных объектов на базу раздачи, т. е. ограничение на использование API Invalidation со знаками подстановки не влияет на ограничение по удалению отдельных объектов. При превышении этих лимитов запросы API Invalidation будут возвращать ошибку, пока не завершится какой‑либо из уже выполняющихся запросов.

Удаление следует использовать только при непредвиденных обстоятельствах. Если заранее известно, что файлы потребуется часто удалять из кэша, рекомендуется реализовать систему управления версиями файлов либо установить для файлов непродолжительный срок действия.

Вопрос: Соответствует ли Amazon CloudFront стандарту PCI?

Да, Amazon CloudFront включен в перечень сервисов, которые соответствуют требованиям стандарта безопасности данных индустрии платежных карт (PCI DSS) уровня Level 1 для торгово‑сервисных предприятий (самого высокого уровня для поставщиков услуг). Подробнее см. в Руководстве для разработчиков.

Вопрос: Соответствует ли Amazon CloudFront требованиям HIPAA?

Да, AWS расширила свою программу соответствия требованиям HIPAA. Теперь сервис Amazon CloudFront включен в перечень сервисов, соответствующих требованиям HIPAA. Если вы заключили с AWS договор делового партнерства (BAA), можно использовать Amazon CloudFront для ускорения доставки закрытой медицинской информации (PHI). Подробную информацию см. на странице Соответствие требованиям HIPAA и в нашем Руководстве для разработчиков.

Вопрос: Соответствует ли Amazon CloudFront требованиям SOC?

Да, Amazon CloudFront соответствует требованиям SOC (System & Organization Control). Отчеты SOC представляют собой отчеты независимых сторонних экспертов, которые показывают, как AWS реализует ключевые механизмы управления и решает задачи соответствия требованиям. Подробную информацию см. на странице Соответствие AWS требованиям SOC и в нашем Руководстве для разработчиков.

Вопрос: Как можно запросить отчет AWS SOC 1, SOC 2 или SOC 3?

Отчеты AWS SOC 1 и SOC 2 можно получить с помощью AWS Artifact, портала самообслуживания для доступа по требованию к отчетам по соответствию AWS требованиям. Войдите в раздел AWS Artifact в Консоли управления AWS или см. подробности на странице Начало работы с AWS Artifact. Последняя версия отчета AWS SOC 3 находится в открытом доступе на веб‑сайте AWS.

Вопрос: Какие типы HTTP‑запросов поддерживает Amazon CloudFront?

В настоящее время Amazon CloudFront поддерживает запросы GET, HEAD, POST, PUT, PATCH, DELETE и OPTIONS.

Вопрос: Кэширует ли Amazon CloudFront ответы на запросы POST?

Amazon CloudFront не кэширует ответы на запросы POST, PUT, DELETE и PATCH. Эти запросы перенаправляются обратно на сервер источника. При этом можно разрешить кэширование ответов на запросы OPTIONS.

Вопрос: Как начать использовать HTTP/2?

При наличии готовой базы раздачи Amazon CloudFront можно перейти к использованию HTTP/2 с помощью API или Консоли управления. В Консоли управления нужно перейти на страницу «Distribution Configuration» (Конфигурация базы раздачи) и найти раздел «Supported HTTP Versions» (Поддерживаемые версии HTTP). В этом разделе можно выбрать между HTTP/2, HTTP/1.1 и HTTP/1.0. Для новых баз раздачи Amazon CloudFront использование HTTP/2 активировано по умолчанию.

Вопрос: Как быть, если источник не поддерживает HTTP/2?

В настоящий момент Amazon CloudFront поддерживает HTTP/2 для доставки контента в браузеры и клиентские приложения пользователей. Для взаимодействия периферийных местоположений и серверов‑источников Amazon CloudFront продолжает использовать HTTP/1.1.

Вопрос: Обеспечивает ли Amazon CloudFront поддержку HTTP/2 без использования TLS?

В данный момент это невозможно. Однако большинство современных браузеров поддерживают HTTP/2 только с использованием зашифрованного подключения. Подробнее об использовании SSL в Amazon CloudFront см. по ссылке.

Вопрос: Можно ли настроить базу раздачи CloudFront для доставки контента по протоколу HTTPS с использованием собственного доменного имени?

По умолчанию доставка контента конечным пользователям по HTTPS происходит с использованием в URL‑адресах доменного имени базы раздачи CloudFront, например https://dxxxxx.cloudfront.net/image.jpg. Для доставки контента по HTTPS с использованием собственного доменного имени и собственного сертификата SSL можно применить одну из возможностей поддержки собственных сертификатов SSL. Подробнее.

Вопрос: Что такое шифрование на уровне поля?

Шифрование на уровне поля – это возможность CloudFront, которая позволяет безопасно загружать данные, предоставленные пользователем, например номера кредитных карт, на серверы источника. Используя эту возможность, можно дополнительно зашифровать конфиденциальные данные в форме HTTPS с использованием собственных специальных ключей шифрования для каждого поля, прежде чем запрос PUT/POST будет перенаправлен на источник. Это гарантирует, что конфиденциальные данные могут быть дешифрованы и просмотрены только определенными компонентами или сервисами в стеке приложений. Подробнее о шифровании на уровне поля см. в разделе Field‑Level Encryption нашей документации.

Вопрос: Если SSL/TLS‑шифрование с CloudFront уже используется, требуется ли дополнительное шифрование на уровне поля?

Многие интернет‑приложения собирают конфиденциальные данные пользователей, такие как номера кредитных карт, которые затем обрабатываются сервисами приложений, запущенными на инфраструктуре сервера‑источника. Все эти интернет‑приложения используют SSL/TLS‑шифрование между конечным пользователем и CloudFront, а также между CloudFront и источником. На сервере‑источнике можно запустить несколько микросервисов, которые выполняют критические операции на основании вводимых пользователем данных. Однако обычно конфиденциальная информация должна использоваться только небольшой группой этих микросервисов, и это означает, что большинство компонентов могут без всякой надобности получить прямой доступ к этим данным. Простая ошибка программирования, например запись не той переменной, может привести к тому, что номер кредитной карты клиента будет записан в файл.  

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

 

Вопрос: В чем разница между собственными сертификатами SSL с индикацией имени сервера (SNI) и собственными сертификатами SSL с выделенными IP‑адресами в Amazon CloudFront?

Собственный сертификат SSL с выделенным IP‑адресом назначает в каждом периферийном местоположении CloudFront выделенный IP‑адрес для передачи защищенного контента SSL. Поскольку между IP‑адресами и сертификатами SSL существует взаимно‑однозначное соответствие, собственный сертификат SSL с выделенным IP‑адресом работает с браузерами и другими клиентами, не поддерживающими SNI. В соответствии с текущей стоимостью IP‑адресов, стоимость собственного сертификата SSL с выделенным IP‑адресом составляет 600 USD в месяц с пропорциональным почасовым распределением.

Собственный сертификат SSL с использованием Server Name Indication (SNI) основан на SNI‑расширении протокола безопасности транспортного уровня (TLS) и позволяет нескольким доменам передавать SSL‑трафик через один IP‑адрес путем указания имени хоста, к которому подключается пользователь. Как и при использовании собственных сертификатов SSL с выделенными IP‑адресами, в этом случае CloudFront доставляет контент из каждого периферийного местоположения Amazon CloudFront с таким же уровнем безопасности. Собственный сертификат SSL с SNI работает с последними версиями современных браузеров, включая Chrome версии 6 и новее (при запуске под Windows XP либо OS X 10.5.7 и новее), Safari версии 3 и новее (при запуске под Windows Vista либо Mac OS X 10.5.6 и новее), Firefox 2.0 и новее либо Internet Explorer 7 и новее (при запуске под Windows Vista или более новой ОС). Более старые браузеры не поддерживают SNI и не смогут установить соединение с CloudFront для загрузки контента по HTTPS. Собственный сертификат SSL с индикацией имени сервера не требует дополнительной оплаты, кроме стандартных расценок на запросы и передачу данных через CloudFront.

Вопрос: Что такое Server Name Indication?

Server Name Indication (SNI) – это расширение протокола безопасности транспортного уровня (TLS). Оно позволяет связать домен (имя сервера) в запросе SSL с подходящим сертификатом для SSL‑соединения. В результате для нескольких серверов можно использовать один IP‑адрес. SNI требует, чтобы браузер поддерживал добавление имени сервера; эта возможность имеется в большинстве современных браузеров, но отсутствует в ряде устаревших. Подробнее см. в разделе «SNI» Руководства по CloudFront для разработчиков или в статье Википедии об SNI.

Вопрос: Интегрирован ли CloudFront с AWS Certificate Manager?

Да, можно получить сертификаты SSL/TLS и связать их с базами раздачи CloudFront за считаные минуты. Просто создайте сертификат, используя новый сервис AWS Certificate Manager (ACM), затем с помощью пары щелчков мышью выполните его развертывание в базе раздачи CloudFront и позвольте ACM автоматически управлять обновлением сертификата. ACM предоставляет возможности получения и развертывания сертификатов, а также управления ими без дополнительной платы.

При этом CloudFront продолжает поддерживать сертификаты, полученные от сторонних центров сертификации и загруженные в хранилище сертификатов сервиса IAM.

Вопрос: Поддерживает ли Amazon CloudFront управление доступом для платного или частного контента?

Да, Amazon CloudFront имеет возможность поддержки частного контента. Если такая возможность активирована, Amazon CloudFront доставляет файлы только при получении запроса с соответствующей подписью безопасности. Подробнее об этой возможности см. в Руководстве по CloudFront для разработчиков.

Вопрос: Как можно защитить свои интернет‑приложения, доставляемые через CloudFront, от DDoS‑атак?

Всем клиентам AWS бесплатно предоставляется сервис AWS Shield Standard. AWS Shield – это управляемый сервис для защиты от атак типа «распределенный отказ в обслуживании» (DDoS). Сервис защищает интернет‑приложения, работающие на AWS. AWS Shield Standard защищает всех клиентов AWS от типичных и частых атак на третий и четвертый уровни инфраструктуры, включая SYN/UDP‑флуд, атаки отражения и прочие, что помогает обеспечить высокую доступность клиентских приложений на AWS.

AWS Shield Advanced – дополнительный платный сервис, доступный клиентам с уровнем поддержки AWS Support «Корпоративный» или «Для бизнеса». AWS Shield Advanced обеспечивает защиту более высокого уровня от масштабных и сложных атак, нацеленных на интернет‑приложения на базе сервисов Elastic Load Balancing (ELB), Amazon CloudFront и Amazon Route 53.

Вопрос: Как защитить интернет‑приложения при доставке с помощью CloudFront?

Базу раздачи CloudFront можно интегрировать с брандмауэром интернет‑приложений AWS WAF, который обеспечивает защиту от атак, позволяя задавать различные правила на основе IP‑адресов, заголовков HTTP и собственных строк URI. На основании созданных правил AWS WAF выполняет блокировку, разрешение или отслеживание (подсчет) сетевых запросов, направленных в адрес интернет‑приложения. Подробнее об этом см. в Руководстве по AWS WAF для разработчиков.

Вопрос: Можно ли добавлять или изменять заголовки запросов, перенаправляемых к источнику?

Да, Amazon CloudFront можно настроить на добавление собственных заголовков к запросам, перенаправляемым к источнику, или замену значений существующих заголовков этих запросов. Заголовки также помогают подтвердить, что запросы, направленные к источнику, были отправлены из CloudFront. Можно настроить источник так, чтобы он принимал только запросы с указанными собственными заголовками. Кроме того, если используется несколько баз раздачи CloudFront с одним источником, можно использовать собственные заголовки для обозначения запросов, отправленных различными базами раздачи к источнику. Наконец, собственные заголовки можно использовать для определения правильных заголовков CORS, возвращаемых для запросов. Собственные заголовки можно настроить через API CloudFront или Консоль управления AWS. Дополнительная плата за эту возможность не взимается. Подробнее о том, как настраивать собственные заголовки, см. по ссылке.

Вопрос: Как Amazon CloudFront обрабатывает значения HTTP cookie?

Amazon CloudFront поддерживает доставку динамического контента, индивидуально настраиваемого с помощью значений HTTP cookie. Для использования этой возможности необходимо настроить перенаправление сервисом Amazon CloudFront всех или некоторых значений cookie на пользовательский сервер источника. В дальнейшем Amazon CloudFront учитывает перенаправленные значения cookie при нахождении уникального объекта в своем кэше. В результате конечные пользователи могут одновременно воспользоваться преимуществами индивидуальной настройки контента с помощью cookie и высокой производительностью, которую обеспечивает сервис Amazon CloudFront. Можно дополнительно указать, требуется ли записывать значения cookie в журналы доступа Amazon CloudFront.

Вопрос: Как Amazon CloudFront обрабатывает параметры строки запроса в URL?

Строка запроса может быть дополнительно настроена как часть ключа кэширования для идентификации объектов в кэше Amazon CloudFront. Это позволяет создавать динамические веб‑страницы (например, результаты поиска) с использованием определенного времени кэширования на периферийных серверах.

Вопрос: Можно ли указать, какие параметры запроса допустимо использовать в ключе кэширования?

Да. Возможность создания белых списков строк запроса позволяет без труда настроить Amazon CloudFront для использования в ключе кэширования только определенных параметров. При этом источнику будут по‑прежнему пересылаться все параметры.

Вопрос: Есть ли ограничение на количество параметров запроса, которое можно включить в белый список?

Да. Amazon CloudFront можно настроить на включение в белый список до 10 параметров запроса.

Вопрос: Какие типы параметров поддерживаются?

Amazon CloudFront поддерживает параметры запроса в формате URI, как это определено в разделе 3.4 стандарта RFC 3986. Это подразумевает поддержку параметров запроса, включенных в строку HTTP GET после знака «?» и разделенных символом «&».

Вопрос: Поддерживает ли CloudFront сжатие gzip?

Да, CloudFront может автоматически сжимать текст и бинарные данные. Чтобы использовать эту возможность, укажите в настройках кэша автоматическое сжатие объектов с помощью CloudFront и убедитесь, что ваш клиент добавляет условие Accept‑Encoding: gzip в заголовок запроса (в последних версиях большинства браузеров это настроено по умолчанию). Дополнительную информацию об этой возможности см. в Руководстве для разработчиков.

Вопрос: Что такое потоковая передача? В каких случаях она может быть предпочтительна?

В общем смысле потоковая передача означает доставку конечным пользователям видео‑ и аудиоматериалов для воспроизведения без необходимости предварительно загружать медиафайлы из Интернета. В число протоколов, используемых для потоковой передачи, входят несколько вариантов доставки посредством HTTP, например Apple HTTP Live Streaming (HLS), MPEG Dynamic Adaptive Streaming over HTTP (MPEG‑DASH), Adobe HTTP Dynamic Streaming (HDS) и Microsoft Smooth Streaming. Такие протоколы отличаются от протоколов доставки веб‑страниц и другого онлайн‑контента, поскольку доставляют мультимедийный контент в режиме реального времени: данные воспроизводятся на устройствах конечных пользователей по мере доставки. Потоковая передача имеет ряд потенциальных преимуществ как для поставщика контента, так и для конечных пользователей.

  • Она является более удобной с точки зрения управления просмотром. Например, при потоковой передаче зрителю проще заглянуть вперед или назад, чем при обычной загрузке видео.
  • Потоковая передача предоставляет больше контроля над контентом, поскольку после завершения просмотра файлы не остаются на стороне клиента или на локальном диске пользователя.
  • Потоковая передача может уменьшить издержки, поскольку доставляется только та часть медиафайла, которую зритель просматривает. При традиционной загрузке, напротив, зрителям чаще всего доставляется весь мультимедийный файл, даже если они просматривают только его часть.

Вопрос: Поддерживает ли Amazon CloudFront протоколы потоковой передачи видео по требованию (VOD)?

Да, Amazon CloudFront предоставляет несколько возможностей доставки видео по требованию. Если имеются медиафайлы, которые перед сохранением в Amazon S3 (или на пользовательском сервере источника) были преобразованы в HLS, MPEG‑DASH или Microsoft Smooth Streaming, например с помощью AWS Elemental MediaConvert, можно использовать базу раздачи веб‑контента Amazon CloudFront для потоковой передачи в этом формате без необходимости запуска каких‑либо мультимедийных серверов.

Кроме того, можно запустить на Amazon EC2 сервер стороннего производителя (например, Wowza Media Server, доступный на AWS Marketplace) для потоковой передачи, и этот сервер будет выполнять преобразование медиафайлов в формат, требуемый для потоковой передачи по HTTP. Такой сервер можно назначить в качестве источника для базы раздачи веб‑контента Amazon CloudFront. 

Подробнее см. на странице Видео по требованию (VOD) на AWS.

Вопрос: Поддерживает ли Amazon CloudFront потоковое вещание на различные платформы?

Да. Возможности прямой трансляции Amazon CloudFront можно использовать с любым сервисом подготовки видео в режиме реального времени, который дает на выходе видеопотоки на базе HTTP, например AWS Elemental MediaPackage или AWS Elemental MediaStore. MediaPackage – это сервис подготовки и своевременного сжатия видео, который позволяет поставщикам видеоконтента безопасно и надежно доставлять потоковое видео в нужном масштабе с использованием различных стандартов доставки и защиты контента. MediaStore – это работающий по HTTP сервис подготовки и хранения видео, который обеспечивает необходимую для прямых трансляций высокую производительность, мгновенную непротиворечивость и предсказуемую низкую задержку в сочетании с безопасностью и надежностью хранилища Amazon.

Подробнее см. на странице прямых видеотрансляций на AWS.

Вопрос: Можно ли работать с Amazon CloudFront, если ожидается пиковое использование в объеме более 10 ГБ/с или 15 000 запросов в секунду?

Да. Заполните форму запроса на повышение ограничений по ссылке, и в течение двух рабочих дней мы добавим ресурсов соответствующему аккаунту.

Вопрос: Имеется ли ограничение на количество баз раздачи Amazon CloudFront для одного аккаунта?

Чтобы узнать текущее ограничение на количество баз раздачи, которые можно создать с одного аккаунта AWS, обратитесь к разделу Лимиты Amazon CloudFront в общих справочных материалах по Amazon Web Services. Чтобы повысить лимит, заполните Форму запроса на повышение лимитов CloudFront.

Вопрос: Каков максимальный размер файла для доставки с помощью Amazon CloudFront?

Максимальный размер одного файла, доставляемого с помощью Amazon CloudFront, составляет 20 ГБ. Этот лимит действует для всех баз раздачи Amazon CloudFront.

Вопрос: Имеется ли доступ к журналам запросов контента, доставляемого посредством Amazon CloudFront?

Да. При создании или изменении базы раздачи CloudFront можно активировать ведение журналов доступа. После активации эта возможность автоматически записывает подробную информацию журнала в расширенном формате W3C в указанную корзину Amazon S3. Журналы доступа содержат подробные сведения о каждом запросе контента, включая название объекта, дату и время запроса, периферийное местоположение, обслужившее запрос, IP‑адрес клиента, источник ссылки, пользовательский агент, заголовок cookie и тип результата (например, для кэша: hit, miss или error).

Вопрос: Предлагает ли Amazon CloudFront готовые отчеты, с помощью которых можно изучать использование сервиса, аудиторию и распространяемый контент?

Да. Amazon CloudFront предлагает различные решения для создания отчетов, например для получения подробных сведений по статистике кэша, отслеживания использования CloudFront или определения, откуда пользователи просматривают контент, а также для настройки предупреждений в режиме реального времени на основании рабочих метрик. Доступ ко всем возможностям создания отчетов предоставляется в панели управления Amazon CloudFront «Reporting & Analytics», доступной в Консоли управления AWS. Подробнее о возможностях создания отчетов см. на странице отчетов и аналитики Amazon CloudFront.

Вопрос: Можно ли пометить базы раздачи тегами?

Да. Amazon CloudFront поддерживает теги для распределения расходов. Теги упрощают распределение расходов и оптимизацию затрат путем классификации и группировки ресурсов AWS. Например, можно использовать теги, чтобы сгруппировать ресурсы по администратору, по имени приложения, по центру затрат или по конкретному проекту. Подробную информацию о тегах для распределения расходов см. на странице Использование тегов для распределения расходов. При желании добавить теги для своих баз раздачи CloudFront см. страницу Добавление тегов в Amazon CloudFront.

Вопрос: Можно ли получить историю всех вызовов API Amazon CloudFront, сделанных из моего аккаунта, в целях аудита использования, безопасности или соответствия требованиям?

Да. Для сохранения истории всех вызовов API Amazon CloudFront своего аккаунта включите сервис AWS CloudTrail в соответствующем разделе Консоли управления AWS. Дополнительные сведения см. на главной странице CloudTrail.

Вопрос: Имеются ли возможности для мониторинга метрик и отправки предупреждений в режиме реального времени?

Осуществлять мониторинг, отправлять предупреждения и получать оповещения о текущей производительности баз раздачи Amazon CloudFront уже через несколько минут после запроса пользователя можно с помощью сервиса Amazon CloudWatch. CloudFront автоматически публикует в Amazon CloudWatch шесть рабочих метрик, каждая из которых имеет детализацию в 1 минуту. С помощью CloudWatch можно установить предупреждения для любых нетипичных параметров трафика в CloudFront. Для начала работы по отслеживанию активности CloudFront и установки предупреждений в CloudWatch см. пошаговые инструкции в Руководстве по Amazon CloudFront для разработчиков или просто перейдите в консоль управления Amazon CloudFront и выберите на навигационной панели «Monitoring & Alarming» (Мониторинг и предупреждения).

Вопрос: Что представляет собой Lambda@Edge?

Сервис Lambda@Edge позволяет запускать код в глобальных периферийных местоположениях AWS без выделения серверов и управления ими и обеспечивать ответ на запросы конечных пользователей с минимальной сетевой задержкой. Сервис позволяет загрузить код Node.js в AWS Lambda и настроить вызов конкретной функции в ответ на запросы сервиса Amazon CloudFront (т. е. при получении запроса пользователя, при перенаправлении запроса в адрес сервера‑источника, при возврате запроса от сервера‑источника, а также непосредственно перед отправкой ответа конечному пользователю). При получении запроса на контент код будет готов к исполнению в каждом периферийном местоположении AWS. В зависимости от количества запросов в периферийных местоположениях ресурсы для исполнения кода будут масштабироваться. Подробнее см. в нашей документации.

Вопрос: Как выполнять настройку контента с помощью Lambda@Edge?

Когда определена схема решения по доставке контента, которую требуется реализовать в периферийном местоположении CloudFront, требуется решить, к каким моделям работы кэша и к каким точкам в потоке запросов должны применяться те или иные алгоритмы (т. е. должны ли они применяться при получении запроса пользователя, при перенаправлении запроса в адрес сервера‑источника, при возврате запроса от сервера‑источника или непосредственно перед отправкой ответа конечному пользователю). После этого остается только создать функцию Lambda средствами Node.js в консоли Lambda или с помощью API сервиса и связать эту функцию с выбранным событием‑триггером CloudFront в соответствующей раздаче. Когда настройки будут сохранены, следующий запрос соответствующего уровня к базе раздачи активирует выполнение функции в периферийном местоположении CloudFront, а также масштабирование ресурсов, если потребуется. Подробнее см. в нашей документации.

Какие события в Amazon CloudFront могут использоваться как триггеры?

Функции могут быть автоматически запущены в ответ на следующие события Amazon CloudFront.

  • Запрос пользователя. Это событие возникает, когда конечный пользователь или устройство в Интернете отправляет в CloudFront запрос HTTP(S), который поступает в ближайшее к пользователю периферийное местоположение.
  • Ответ пользователю. Это событие возникает, когда сервер CloudFront в периферийном местоположении готов ответить конечному пользователю или устройству, сделавшему запрос.
  • Запрос источника. Это событие возникает, когда в кэше периферийного сервера CloudFront отсутствует запрошенный объект и запрос посетителя перенаправляется на веб‑сервер источника (например, Amazon EC2, Application Load Balancer или Amazon S3).
  • Ответ источника. Это событие возникает, когда сервер CloudFront в периферийном местоположении получает ответ от веб‑сервера источника.

Вопрос: Что такое IPv6?

Каждый сервер и устройство, подключенное к Интернету, имеют определенный числовой адрес протокола сети интернет (IP). Интернет развивается, количество пользователей растет, и появляется необходимость в новых IP‑адресах. IPv6 – это новая версия протокола сети Интернет, в которой используется большее пространство адресов по сравнению с ее предшественником, IPv4. В IPv4 длина каждого IP‑адреса составляла 32 бита; этого хватало для существования 4,3 миллиарда уникальных адресов. Пример адреса IPv4: 192.0.2.1. В IPv6 длина IP‑адреса составляет 128 бит, и этого достаточно для существования более чем 340 ундециллионов (10Е36) уникальных адресов. Пример адреса IPv6: 2001:0db8:85a3:0:0:8a2e:0370:7334

Вопрос: Как можно использовать протокол IPv6?

Amazon CloudFront поддерживает использование протокола IPv6. Приложения могут подключаться к периферийным местоположениям Amazon CloudFront без необходимости использования программного обеспечения или систем для преобразования адресов IPv4 в адреса IPv6. Это позволяет соблюдать государственные требования по переходу на IPv6, включая требования федерального правительства США, а также пользоваться расширяемостью, простотой управления сетью и дополнительными встроенными функциями поддержки обеспечения безопасности протокола IPv6.

Вопрос: Меняется ли производительность Amazon CloudFront при использовании протокола IPv6?

Нет, производительность Amazon CloudFront не зависит использования протоколов IPv4 или IPv6.

Вопрос: Все ли возможности Amazon CloudFront будут доступны при использовании протокола IPv6?

Все существующие на данный момент возможности Amazon CloudFront поддерживают работу с IPv6, но перед переходом баз раздачи на использование IPv6 следует внести два изменения во внутренние процессы обработки адресов IPv6.

  1. Если включены журналы Amazon CloudFront Access Logs, адреса пользователей IPv6 будут отображаться в поле «c‑ip», и мы рекомендуем проверить, правильно ли системы обработки журналов работают с адресами IPv6.
  2. При переносе баз раздачи Amazon CloudFront на IPv6 адреса IPv6 будут отображаться в отправляемом источнику заголовке X‑Forwarded‑For. Если система‑источник настроена на обработку только адресов IPv4, рекомендуем проверить, насколько корректно она будет обрабатывать адреса IPv6.

Помимо этого, при использовании белых списков IP заверителей следует использовать для URL заверителей базы раздачи IPv4, а для остального контента – базы раздачи IPv4/IPv6. Данная модель позволяет избежать проблемы, когда запрос на подпись приходит с адреса IPv4 и подписан соответствующим образом, а запрос на контент приходит с адреса IPv6, не входящего в белый список.

Подробная информация о поддержке IPv6 в Amazon CloudFront приведена в разделе IPv6 support on Amazon CloudFront Руководства по Amazon CloudFront для разработчиков.

Вопрос: Означает ли это, что если я хочу использовать IPv6 везде, то не смогу использовать раздачу URL заверителей по белым спискам IP?

Нет. Чтобы пользоваться IPv6 и URL заверителей по белым спискам IP, следует использовать две разных базы раздачи. На одной из баз раздачи следует отключить IPv6 и выделить ее исключительно для работы с URL заверителей по белым спискам IP. Вторую базу раздачи можно будет использовать для всего остального контента, как с IPv4, так и с IPv6.

Вопрос: Если включить IPv6, будет ли адрес IPv6 отображаться в журнале Access Logs?

Да, если журналы Amazon CloudFront Access Logs активированы, адрес IPv6 пользователя будет указан в поле «c‑ip». Перед переходом баз раздачи к использованию IPv6 следует убедиться, что системы обработки журналов поддерживают работу с адресами IPv6. В случае проблем из‑за влияния трафика IPv6 на способность инструментов или программного обеспечения обрабатывать IPv6 адреса в журналах доступа свяжитесь со службой поддержки разработчиков. Подробная информация приведена в документации Amazon CloudFront Access Logs.

Вопрос: Можно ли отключить IPv6 на всех новых базах раздачи?

Да, вы можете включить или отключить использование IPv6 на новых и существующих базах раздачи с помощью консоли Amazon CloudFront или API.

Вопрос: В каких ситуациях может быть полезно отключить IPv6?

По итогам обсуждений с клиентами мы пришли к выводу, что это может пригодиться лишь в случае проблем при внутренней обработке IP‑адресов. При включении IPv6 на базе раздачи Amazon CloudFront адреса IPv6 будут отображаться не только в детализированных журналах доступа, но и в отправляемом источнику заголовке X‑Forwarded‑For. Если система‑источник настроена на обработку только адресов IPv4, перед переключением баз раздачи на протокол IPv6 рекомендуем проверить, насколько корректно система‑источник будет обрабатывать адреса IPv6.

Вопрос: На базе раздачи включен IPv6, но поиск DNS не возвращает адресов IPv6. В чем дело?

Сети Amazon CloudFront по всему миру обладают очень широкими возможностями подключения, но в некоторых из них доступ по протоколу IPv6 из любой точки еще не реализован. В долгосрочной перспективе очевидно, что весь Интернет перейдет на IPv6, однако в ближайшем будущем все оконечные устройства будут поддерживать подключения по IPv4. В тех частях Интернета, где возможности подключения для IPv4 шире, чем для IPv6, мы будем использовать IPv4.

Вопрос: Если я использую Route 53 в качестве DNS‑сервера, и создал псевдоним, указывающий на мою базу раздачи Amazon CloudFront, нужно ли обновлять запись псевдонима для использования IPv6?

Да, вы можете создать псевдонимы Route 53 для своей базы раздачи Amazon CloudFront, которые будут поддерживать как IPv4, так и IPv6. Для этого необходимо создать псевдонимы с использованием записей типа «A» и «AAAA» соответственно. Чтобы использовать только IPv4, достаточно только записи псевдонима типа «A». Подробная информация о наборах записей псевдонимов ресурса приведена в Руководстве по Amazon Route 53 для разработчиков.  

Вопрос: Как начисляется плата за использование Amazon CloudFront?

Плата за Amazon CloudFront начисляется по факту использования на основании четырех параметров: объема исходящих данных, количества запросов HTTP/HTTPS, количества вызовов API Invalidation и собственных сертификатов SSL с выделенными IP‑адресами, связанных с базой раздачи CloudFront.

Уровень бесплатного пользования AWS позволяет начать работу с Amazon CloudFront бесплатно. При регистрации новым клиентам AWS предоставляется возможность ежемесячно передавать исходящие данные в объеме 50 ГБ и выполнять 2 000 000 запросов HTTP и HTTPS в Amazon CloudFront бесплатно в течение одного года.

  • Исходящая передача данных в Интернет
    Плата начисляется на основании объема данных (в гигабайтах), переданных из периферийных местоположений Amazon CloudFront. Тарифы на передачу данных в Интернет для Amazon CloudFront можно посмотреть по ссылке. Обратите внимание, что объем переданных данных для определенных географических регионов подытоживается отдельно, а затем на основе ценовых уровней рассчитывается стоимость для каждой области. Если в качестве источника используются другие сервисы AWS, они оплачиваются отдельно, включая хранилище и вычислительное время. С 1 декабря 2014 года при использовании источников AWS (например, Amazon S3, Amazon EC2 и т. д.) плата за передачу данных из этих сервисов в Amazon CloudFront не взимается. Это касается передачи данных из всех регионов AWS в любые периферийные местоположения CloudFront по всему миру.
  • Исходящая передача данных к источнику
    Плата начисляется за объем данных (в гигабайтах), переданных из периферийных местоположений Amazon CloudFront к источнику (включая источники AWS и другие серверы источника). Тарифы на передачу данных к источнику для Amazon CloudFront можно посмотреть по ссылке.
  • Запросы HTTP/HTTPS
    Плата начисляется за количество запросов контента по HTTP/HTTPS, полученных Amazon CloudFront. Тарифы на запросы HTTP/HTTPS можно посмотреть по ссылке.
  • Запросы API Invalidation
    Плата начисляется за каждый путь в запросах на удаление. Путь, указанный в запросе API Invalidation, представляет собой URL‑адрес (или несколько URL‑адресов, если путь содержит знак подстановки) объекта, который необходимо удалить из кэша CloudFront. Без дополнительной платы можно запрашивать в Amazon CloudFront удаление до 1000 путей в месяц. Сверх этого плата начисляется за каждый путь, указанный в запросе на удаление. Тарифы на запросы API Invalidation можно посмотреть по ссылке.
  • Собственные сертификаты SSL с выделенными IP‑адресами
    Сервис начисляет 600 USD в месяц за каждый собственный сертификат SSL, связанный с одной или несколькими базами раздачи CloudFront, поддерживающими версию собственных сертификатов SSL для выделенных IP‑адресов. Данный месячный тариф пропорционально пересчитывается по часам. Например, если собственный сертификат SSL связан хотя бы с одной базой раздачи CloudFront всего на 24 часа (т. е. 1 сутки) в июне, суммарная стоимость использования сертификата SSL в июне составит (1 день/30 дней) * 600 USD = 20 USD. Чтобы воспользоваться поддержкой собственных сертификатов SSL с выделенными IP‑адресами, загрузите сертификат SSL и с помощью Консоли управления AWS свяжите его с базами раздачи CloudFront. Если с базой раздачи CloudFront требуется связать более двух собственных сертификатов SSL, опишите свой пример использования сервиса с указанием требуемого количества собственных сертификатов SSL в форме запроса на повышение лимитов CloudFront.

Уровни пользования для передачи данных рассчитываются отдельно для каждого географического региона. Если не указано иное, цены, приведенные выше, не включают применимых налогов, пошлин или других государственных сборов (если таковые применимы).

Вопрос: Ваши цены указаны с учетом налогов?

Если не указано иное, представленные здесь цены не включают применимые налоги и сборы, в том числе НДС и применимый налог с продаж. Для клиентов с платежным адресом в Японии использование сервисов AWS облагается потребительским налогом Японии. Подробнее.

Вопрос: Как оплачиваются ответы с кодом 304?

Код 304 – это ответ на условный запрос GET, соответственно, плата начисляется за запрос HTTP/HTTPS и исходящую передачу данных в Интернет. Хотя ответ 304 не содержит тела сообщения, его заголовок HTTP имеет некоторый размер, за передачу которого будет начислена плата по стандартным тарифам CloudFront на передачу данных. Объем передаваемых данных зависит от размера заголовка, связанного с передаваемым объектом.

Вопрос: Можно ли выбрать доставку контента только из недорогих регионов Amazon CloudFront?

Да, различные ценовые категории позволяют снизить цены на доставку контента из Amazon CloudFront. По умолчанию Amazon CloudFront сводит задержку для конечного пользователя до минимума, доставляя контент через всемирную сеть периферийных местоположений. Однако, так как мы взимаем большую плату за услуги, когда наши собственные расходы повышаются, за доставку контента конечным пользователям в некоторые местоположения с низкой задержкой придется платить больше. Ценовые категории позволяют снизить расходы на доставку, исключая более дорогостоящие периферийные местоположения Amazon CloudFront из баз раздачи Amazon CloudFront. В этих случаях Amazon CloudFront будет доставлять контент из периферийных местоположений в пределах местоположений из выбранной ценовой категории и взимать плату за передачу данных и запросы применимо к точке присутствия, из которой осуществлена доставка.

Если производительность – ваш основной приоритет, используйте настройки по умолчанию, и ваш контент будет доставляться всей нашей сетью местоположений. Однако для того, чтобы воспользоваться иной ценовой категорией, можно дополнительно настроить базу раздачи через Консоль управления AWS либо через API Amazon CloudFront. Если выбрана ценовая категория, не включающая все местоположения, некоторые пользователи, особенно в местоположениях за пределами этой ценовой категории, могут испытывать большие задержки, чем при доставке через все местоположения Amazon CloudFront.

Заметьте, что Amazon CloudFront может изредка отвечать на запросы на контент из периферийных местоположений за пределами вашей ценовой категории. Когда такое происходит, плата начисляется по тарифам местоположений выбранной ценовой категории.

Список местоположений для каждой ценовой категории см. по ссылке.

Попробовать Amazon CloudFront бесплатно