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

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.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list. В этом ресурсе содержится пошаговое руководство по использованию управляемых списков префиксов AWS для оптимальной конфигурации безопасности.
3. Шифрование сертификатов SSL/TLS. Вы можете настроить CloudFront на использование исключительно HTTPS-подключений к источнику для обеспечения комплексной защиты данных благодаря зашифрованной связи между вашей базой раздачей CloudFront и источником.

Источники виртуального частного облака (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-адреса передачи по произвольному пути от 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 сегментов.