Вопросы и ответы по Amazon CloudFront

gRPC

gRPC – это современная платформа удаленного вызова процедур (RPC) с открытым исходным кодом, которая обеспечивает двунаправленную связь между клиентом и сервером через длительное соединение HTTP/2. Используя постоянное открытое соединение, клиент и сервер могут отправлять друг другу данные в режиме реального времени без необходимости часто возобновлять соединения в поисках новых данных для обмена. gRPC хорошо подходит для случаев использования, где важны низкие задержки и высокая скорость передачи данных, таких как приложения для связи в режиме реального времени и онлайн-игры.

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

Amazon CloudFront обменивается данными через gRPC при соблюдении следующих условий:

  1. в вашей базе раздачи включен протокол HTTP/2;
  2. при поведении кэша включены запросы POST и gRPC;
  3. клиент отправляет заголовок content-type со значением application/grpc через соединение HTTP/2.
  1. Безопасность. gRPC применяет протокол HTTP/2, который обеспечивает сквозное шифрование трафика от клиента до ваших исходных серверов. Кроме того, при использовании gRPC вы получаете AWS Shield стандартный без дополнительной оплаты, а AWS WAF можно настроить для защиты трафика gRPC от атак.
  2. Более высокая производительность. gRPC использует двоичный формат сообщений, называемый буферами протоколов, который меньше традиционных полезных данных, таких как JSON, используемый в Обработке запросов на основе передачи состояния. Обработка буферов протоколов требует меньше ресурсов процессора, поскольку данные представлены в двоичном формате, что означает более быстрый обмен сообщениями. Это приводит к повышению общей производительности.
  3. Встроенная поддержка потоковой передачи. Потоковая передача является встроенной частью платформы gRPC. Она поддерживает семантику потоковой передачи как на стороне клиента, так и на стороне сервера. Это значительно упрощает создание потоковых сервисов или клиентов. gRPC на CloudFront поддерживает следующие комбинации потоковой передачи:
    • односторонняя (без потоковой передача);
    • передача между клиентом и сервером;
    • передача между сервером и клиентом;
    • двусторонняя передача.

Сейчас это невозможно. CloudFront поддерживает gRPC только через HTTP/2.

Безопасность

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

  1. Контроль доступа к источникам (OAC). Контроль доступа к источникам CloudFront (OAC) – это функция безопасности, которая ограничивает доступ к вашим источникам Amazon Simple Storage Service (S3), источникам AWS Elemental и URL-адресам функций Lambda, гарантируя доступ к контенту только CloudFront.
  2. Источники VPC. Источники виртуального частного облака CloudFront (VPC) позволяют использовать Amazon CloudFront для доставки контента из приложений, размещенных в частной подсети VPC. Балансировщики нагрузки приложений (ALB), балансировщики сетевой нагрузки (NLB) и инстансы EC2 в частных подсетях можно использовать в качестве источников VPC в CloudFront

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

  1. Настраиваемые заголовки источников. С помощью CloudFront вы можете добавлять собственные заголовки к входящим запросам, а затем настроить источник для проверки конкретных значений заголовков, фактически ограничивая доступ только к тем запросам, которые маршрутизируются через CloudFront. Этот метод создает дополнительный уровень аутентификации, значительно снижая риск несанкционированного прямого доступа к вашему источнику.
  2. Список разрешенных IP-адресов. Вы можете настроить группу безопасности или брандмауэр источника, чтобы разрешить входящий трафик только из диапазонов IP-адресов CloudFront. Для вашего удобства AWS поддерживает и регулярно обновляет эти диапазоны IP-адресов. Для получения подробной информации о внедрении списка разрешенных IP-адресов ознакомьтесь с нашей подробной документацией по адресу: https://docs.thinkwithwp.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list. В этом ресурсе содержится пошаговое руководство по использованию управляемых списков префиксов AWS для оптимальной конфигурации безопасности.
  3. Шифрование сертификатов SSL/TLS. Вы можете настроить CloudFront на использование исключительно HTTPS-подключений к источнику для обеспечения комплексной защиты данных благодаря зашифрованной связи между вашей базой раздачей CloudFront и источником.

Источники VPC

Источники виртуального частного облака (VPC) CloudFront – это новая функция, которая позволяет применять CloudFront для доставки контента из приложений, размещенных в частной подсети VPC. При использовании источников VPC приложения можно размещать в частной подсети VPC, доступной только через базы раздачи CloudFront. Это отменяет требование о наличии в источнике имени службы доменных имен (DNS), разрешаемого извне. Источники VPC можно настроить с помощью приложений, которые работают на инстансах Балансировщика нагрузки приложений (ALB), Балансировщика сетевой нагрузки (NLB) и EC2. Источники VPC доступны только в коммерческих регионах AWS. С полным списком поддерживаемых регионов AWS можно ознакомиться здесь.

Если вы хотите повысить безопасность своих веб-приложений при сохранении высокой производительности и глобальной масштабируемости, вам следует использовать источники VPC вместе с CloudFront. Применяя источники VPC, вы можете ограничить доступ к своим источникам в VPC только своим базам раздачи CloudFront без сложных конфигураций, таких как секретные заголовки или списки управления доступом. Источники VPC также позволяют оптимизировать затраты на IPv4, предоставляя бесплатную маршрутизацию к источникам в частной подсети с внутренними IP-адресами IPv4. Источники VPC идеально подходят, если вы хотите упростить управление безопасностью, что позволяет вам сосредоточиться на развитии основного бизнеса, а не на управлении сложными мерами безопасности.

  1. Безопасность. При использовании источников VPC, вы можете повысить уровень безопасности приложения, путем размещения балансировщиков нагрузки и инстансов EC2 в частных подсетях, превратив CloudFront в единственную точку входа. Запросы пользователей передаются из CloudFront в источники VPC по частному безопасному соединению, что обеспечивает дополнительную безопасность ваших приложений.
  2. Управление. Источники VPC сокращают эксплуатационные издержки, необходимые для безопасного подключения источника CloudFront, позволяя перемещать источники в частные подсети без публичного доступа и необходимости внедрения списков контроля доступа, общих секретных заголовков или других механизмов ограничения доступа к источникам. Это упрощает защиту их веб-приложений с помощью CloudFront без необходимости вкладывать средства в недифференцированную разработку.
  3. Масштабируемость и производительность. Благодаря источникам VPC клиенты могут использовать периферийные местоположения CloudFront по всему миру и магистральные сети AWS, обеспечивая такие же масштабы и производительность, как и другие существующие методы доставки контента, и при этом улучшая безопасность. Решение упрощает управление безопасностью и доставку приложений клиентам по всему миру, делая использование CloudFront более легким в качестве единого входа для ваших приложений.

Источники виртуального частного облака (VPC) CloudFront позволяют использовать CloudFront для доставки контента из приложений, размещенных в частной подсети VPC, с помощью Балансировщиков нагрузки приложений и Балансировщиков сетевой нагрузки, а также инстансов EC2. Блокирование публичного доступа Amazon VPC (VPC BPA) – это простой декларативный элемент управления, который официально блокирует входящий и исходящий трафик VPC по предоставленным AWS интернет-путям. Когда решение Блокирования публичного доступа VPC BPA включено в подсети с источником VPC, активные подключения CloudFront к этой подсети прерываются. Новые подключения к подсети не отправляются либо направляются в другую подсеть, где находится источник VPC, а BPA не включен, либо отключаются, если во всех подсетях, где находится источник VPC, включен BPA.

Источники VPC поддерживают Балансировщики нагрузки приложений и Балансировщики сетевой нагрузки, а также инстансы EC2.

Нет, IPv6 не поддерживается частными источниками VPC. При использовании источников VPC вам нужны частные адреса IPv4, которые являются бесплатными и не взимают сборов за использование IPv4.

Потоковая передача

Отказоустойчивость с учетом требований к качеству мультимедиа (MQAR) — это встроенная функция Amazon CloudFront и мультимедийных сервисов AWS, которая обеспечивает автоматический выбор источника и экстренное переключение между регионами в зависимости от динамически генерируемой оценки качества видео. С помощью MQAR можно развернуть резервный рабочий процесс медиасервисов AWS в двух разных регионах AWS для надежной доставки данных о событиях в реальном времени. При включении в системе функции MQAR вы разрешаете CloudFront автоматически выбирать источник с наивысшим показателем качества. Показатель качества отражает предполагаемые проблемы с качеством потокового мультимедиа в ваших источниках, такие как пустые, замороженные, пропущенные или повторяющиеся кадры. Например, если источники AWS Elemental MediaPackage v2 развернуты в двух разных регионах AWS, и в одном из них показатель качества мультимедиа выше, чем в другом, CloudFront автоматически переключится на источник, который передает более высокую оценку. Эта функция обеспечивает непрерывный мониторинг для трансляции событий в прямом эфире и каналов с круглосуточными программами и призвана обеспечить зрителям высокое качество оказываемых услуг. Более подробные сведения о MQAR можно найти в Руководстве для разработчиков CloudFront.

Статические IP-адреса передачи по произвольному пути

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

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

При включении статических IP-адресов передачи по произвольному пути CloudFront вы получите 21 IP-адрес для IPv4. Вам нужно будет добавить все эти IP-адреса в любые соответствующие списки разрешений.

Нет, передача по произвольному пути CloudFront будет доступна только для IP-адресов, распределенных по географическим регионам.

По мере добавления CloudFront новых периферийных местоположений ваш список статических IP-адресов передачи по произвольному пути останется действительным. При необходимости мы сообщим ваши IP-адреса из новых периферийных местоположений.

Все функции CloudFront работают с передачей по произвольному пути с тремя заметными исключениями: 1) статические IP-адреса передачи по произвольному пути не будут поддерживать устаревшие клиенты, которые не поддерживают SNI; 2) при использовании статических IP-адресов передачи по произвольному пути необходимо применять ценовую категорию «Все»; и 3) при использовании статических IP-адресов передачи по произвольному пути необходимо отключить IPv6. Статические IP-адреса передачи по произвольному пути работают на этапе разрешения DNS, и как только запрос поступит на хост, все существующие функции и интеграции с другими сервисами AWS будут по-прежнему доступны вашим базам раздачи.

Вы можете использовать статистические IP-адреса передачи по произвольному пути с несколькими базами раздачи, но они должны находиться в одной учетной записи. Статические IP-адреса передачи по произвольному пути CloudFront можно связать между несколькими базами раздачи в учетной записи. Статический IP-адрес передачи по произвольному пути CloudFront будет поддерживать индикацию имени сервера (SNI), поэтому из любого количества баз раздачи, связанных с политикой статического IP-адреса, который передается по произвольному пути, будет возвращен правильный сертификат. Если вы хотите иметь разные статические IP-адреса для нескольких баз раздачи в своей учетной записи, то можете создать дополнительный список статических IP-адресов передачи по произвольному пути и связать его с определенными базами раздачи.

При создании новой базы раздачи в учетной записи с включенными статистическими IP-адресами передачи по произвольному пути вы должны точно связать новую базу раздачи с существующим списком статических IP-адресов, которые передаются по произвольному пути. По умолчанию она будет использовать динамические IP-адреса, пока вы не свяжете ее со своим списком статических IP-адресов.

Ведение журналов и отчеты

  1. Стандартные журналы (журналы доступа). Стандартные журналы CloudFront содержат подробные записи о каждом запросе, направленном в базу раздачи. Они полезны для многих сценариев, включая аудит безопасности и доступа.
  2. Журналы в режиме реального времени. Журналы в режиме реального времени CloudFront мгновенно предоставляют информацию о запросах, отправленных для распределения (записи журналов доставляются в течение нескольких секунд после получения запросов). Вы можете выбрать частоту дискретизации журналов в режиме реального времени, то есть процент запросов, для которых в журнал добавляются записи.
  3. Ведение журналов периферийных функций. Журналы Amazon CloudWatch можно использовать для получения журналов периферийных функций, таких как Lambda@Edge и CloudFront. Доступ к журналам можно получить с помощью консоли CloudWatch или API Журналов CloudWatch. Дополнительные сведения см. в разделе Журналы периферийных функций.
  4. Ведение журнала активности в сервисе. AWS CloudTrail можно использовать для регистрации активности сервиса CloudFront (активности API) в своем аккаунте AWS. CloudTrail предоставляет запись действий API, предпринятых пользователем, ролью или сервисом AWS в CloudFront. Используя информацию, собранную CloudTrail, вы можете определить, какой запрос API был отправлен в CloudFront, IP-адрес, с которого был сделан запрос, кто и когда его отправил, а также дополнительные сведения. Подробнее см. в разделе Ведение журнала вызовов API Amazon CloudFront с помощью AWS CloudTrail.
  • Стандартные журналы CloudFront доставляются в выбранную вами корзину Amazon S3, Журналы Amazon CloudWatch и Amazon Data Firehose. Дополнительные сведения см. в разделе Использование стандартных журналов (журналов доступа).
  • Журналы CloudFront доставляются в выбранный вами Поток данных в Amazon Kinesis в режиме реального времени. За использование журналов CloudFront в реальном времени взимается плата дополнительно к стоимости использования Kinesis Data Streams. Дополнительные сведения см. в разделе Использование журналов в режиме реального времени.
  • Журналы периферийных функций CloudFront (Lambda@Edge и CloudFront) доставляются в Журналы Amazon CloudWatch

Стандартные журналы доступа CloudFront можно доставлять в Amazon S3, Amazon CloudWatch и Amazon Data Firehose. Вы можете выбрать формат выходного журнала (plain, w3c, JSON, csv и parquet), а также, какие поля хотите регистрировать и в каком порядке они должны быть включены в журналы. Для журналов, доставляемых в S3, можно также включить секционирование журналов, т. е. настроить автоматическое их разбиение на почасовой или ежедневной основе. Кроме того, вы можете доставлять журналы стандартного доступа в корзины S3 в Регион AWS Opt. Дополнительные сведения см. в разделе Журналы стандартного доступа руководства для разработчиков CloudFront.

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

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

Стандартные журналы CloudFront доставляются в вашу корзину S3. Также можно использовать интеграционную сборку сторонних решений, например DataDog и Sumologic, для создания информационных панелей из этих журналов.

Журналы в реальном времени записываются в вашем сервисе Kinesis Data Streams. Из Kinesis Data Streams журналы можно опубликовать в Amazon Kinesis Data Firehose. Amazon Kinesis Data Firehose поддерживает простую доставку данных в Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, а также таким поставщикам сервисов, как Datadog, New Relic и Splunk. Kinesis Firehose также поддерживает доставку данных на обычный адрес HTTP.

Чтобы узнать необходимое число сегментов, выполните следующие действия:

  1. Рассчитайте (или примерно оцените) количество запросов в секунду, которые получает ваша база раздачи CloudFront. Для расчета количества запросов в секунду можно использовать отчеты об использовании CloudFront или метрики CloudFront.
  2. Определите типичный размер одной записи журнала в реальном времени. Размер типичной записи, включающей все доступные поля, составляет около 1 КБ. Если вы не знаете размер записи вашего журнала, то можете включить журналы в реальном времени с низкой частотой дискретизации (например, 1 %), а затем рассчитать средний размер записи, используя данные мониторинга в Kinesis Data Streams (общее количество записей деленное на общее количество входящих байтов).
  3. Умножьте количество запросов в секунду (шаг 1) на размер типичной записи журнала в реальном времени (шаг 2) и определите объем данных в секунду, который ваша конфигурация журнала в реальном времени может отправить в Kinesis Data Stream.
  4. С помощью полученного значения объема данных в секунду, вычислите необходимое количество сегментов. Один сегмент может обрабатывать не более 1 МБ в секунду и не более 1000 запросов (записей журнала) в секунду. Рекомендуется при расчете количества необходимых сегментов добавить до 25 % в качестве буфера.

Предположим, что ваша база раздачи получает 10 000 запросов в секунду, а размер ваших записей журнала в реальном времени обычно составляет 1 КБ. Это означает, что ваша конфигурация журнала в реальном времени может генерировать 10 000 000 байт (10 000, умноженные на 1000), или 9,53 МБ в секунду. В этом случае вам понадобится всего 10 сегментов Kinesis. Однако, чтобы иметь некий буфер, желательно создать как минимум 12 сегментов.