Почему я не могу выбрать оплату по фактическому использованию при создании CloudFront в консоли?

AWS обновил консоль CloudFront, предложив только тарифные планы с фиксированной оплатой (Бесплатный и Pro от $15 в месяц). Оплата по фактическому использованию по-прежнему доступна через API CloudFront и команду AWS CLI create-distribution; консоль просто не отображает этот вариант.

В чём разница между тарифами CloudFront по мере использования и фиксированными тарифами?

Оплата только за использованные ресурсы (передача данных и запросы), с бесплатным уровнем 1 ТБ и 10 млн запросов в месяц. Плоские тарифные планы (Free/Pro/Business/Premium) включают WAF, защиту от DDoS, Route 53 и фиксированные квоты без превышений.

Нужно ли существующее распределение CloudFront для использования этого метода?

Да. Вы экспортируете конфигурацию существующего распределения (например, созданного до изменения консоли или через CLI), изменяете CallerReference и, при необходимости, алиасы/исходный адрес, а затем создаёте новое распределение из этой конфигурации. Новое распределение по умолчанию использует оплату по факту использования при создании через API/CLI.

Можно ли сохранить Lambda@Edge (например, для S3 веб-сайта index.html) при клонировании конфигурации?

Да. Конфигурация распределения включает LambdaFunctionAssociations. Пока Lambda находится в том же аккаунте (или доступна через общий доступ), клонированная конфигурация сохраняет триггер origin-request (или другой) для добавления index.html к запросам каталогов.

Что мне нужно изменить в экспортированной конфигурации перед созданием нового дистрибутива?

Вы должны установить уникальный идентификатор CallerReference (например, новую строку или временную метку). Также следует обновить Aliases и Origins, если новый сайт использует другой домен или корзину S3; в противном случае можно очистить Aliases для создания распределения без пользовательского домена сначала.

Создайте AWS CloudFront по модели оплаты по фактическому использованию (не бесплатный тариф)

Создайте CloudFront с оплатой по фактическому использованию через AWS CLI.

Содержимое страницы

План AWS Free не работает для меня, и Pay-as-you-go скрыт для новых распределений CloudFront в консоли AWS.

Когда вы хостите сайты на основе Hugo на AWS, вы обычно помещаете корзину за CloudFront и прикрепляете функцию Lambda@Edge, чтобы запросы к каталогам (например, /blog/) перенаправлялись на /blog/index.html для источников стиля сайта S3. Затем вы можете использовать hugo deploy или развертывание с помощью AWS CLI для синхронизации построенного сайта. Однако есть один нюанс: вам нужна распределение CloudFront, которое использует эту Lambda, и, если вы хотите избежать фиксированных планов с абонентской платой, платное использование по факту. В консоли больше нет возможности выбрать этот вариант — только бесплатные или профессиональные планы.

Документация не соответствует фактическим поставкам

Эта статья показывает, как создать распределение платное использование путем повторного использования конфигурации существующего распределения с помощью AWS CLI и скриптов в папке scripts этой статьи.

Когда консоль предлагает только Бесплатный или Про

Amazon ввел фиксированные тарифные планы CloudFront (Бесплатный, Про, Бизнес, Премиум), которые объединяют CDN с WAF, защитой от DDoS, Route 53 и другими услугами за фиксированную ежемесячную плату без превышений. В консоли CloudFront, при создании нового распределения, вы теперь видите только варианты Бесплатный или Про (и выше). План Про начинается с $15/месяц; нет видимого варианта платное использование.

Платное использование по-прежнему является стандартным, когда вы создаете распределение через API CloudFront или AWS CLI (create-distribution). Поэтому, если у вас уже есть распределение, созданное ранее (или через CLI), и вы хотите еще одно с таким же поведением — например, источник сайта S3 плюс Lambda@Edge для index.html — вы можете экспортировать конфигурацию этого распределения, изменить ее и создать новое распределение. Новое будет платным использованием, если вы не прикрепите его к фиксированному плану позже.

Что вам нужно

Существующее распределение CloudFront, чью конфигурацию вы можете скопировать (например, одно, используемое для другого сайта Hugo, или одно, созданное до изменения консоли).
AWS CLI, установленный и настроенный с учетными данными, которые могут запускать cloudfront:GetDistributionConfig и cloudfront:CreateDistribution.
jq (или аналогичный инструмент) для редактирования JSON-конфигурации.

Примерные скрипты, используемые ниже, находятся в папке scripts этой статьи: current-distribution-config.json, new-distribution-config.json, updated-distribution-config.json и final-distribution-config.json.

Шаг 1: Получите конфигурацию существующего распределения

Получите полную конфигурацию распределения (включая ETag) и сохраните ее:

# Замените ABCDEFG на ID вашего существующего распределения
aws cloudfront get-distribution-config --id ABCDEFG > current-distribution-config.json

get-distribution-config возвращает обертку объекта с ETag и DistributionConfig. Для создания нового распределения вы передаете только внутренний DistributionConfig, поэтому мы извлекаем его:

jq '.DistributionConfig' < current-distribution-config.json > new-distribution-config.json

На этом этапе new-distribution-config.json выглядит следующим образом (сокращенно). Он включает CallerReference, Aliases, Origins, DefaultRootObject и DefaultCacheBehavior с Lambda@Edge. Для примера домена сайта я указал micro.com:

{
  "CallerReference": "8b2b19eb-6d41-4fc0-8d04-a1313e23e2d7",
  "Aliases": {
    "Quantity": 1,
    "Items": ["micro.com"]
  },
  "DefaultRootObject": "index.html",
  "Origins": {
    "Quantity": 1,
    "Items": [
      {
        "Id": "micro.com.s3.us-west-2.amazonaws.com",
        "DomainName": "micro.com.s3-website-us-west-2.amazonaws.com",
        "OriginPath": "",
        "CustomOriginConfig": {
          "HTTPPort": 80,
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "http-only"
        }
      }
    ]
  },
  "DefaultCacheBehavior": {
    "TargetOriginId": "micro.com.s3.us-west-2.amazonaws.com",
    "ViewerProtocolPolicy": "redirect-to-https",
    "LambdaFunctionAssociations": {
      "Quantity": 1,
      "Items": [
        {
          "LambdaFunctionARN": "arn:aws:lambda:us-east-1:...your-lambda-arn",
          "EventType": "origin-request",
          "IncludeBody": false
        }
      ]
    }
  }
}

Шаг 2: Установите уникальный CallerReference

Каждое распределение должно иметь уникальный CallerReference. Использование того же значения, что и у другого распределения, заставит API отклонить запрос. Используйте новую строку или временную метку:

NEW_CALLER_REF="new-distr-$(date +%s)"
jq --arg ref "$NEW_CALLER_REF" '.CallerReference = $ref' new-distribution-config.json > updated-distribution-config.json

Шаг 3: Настройте псевдонимы и источники (опционально)

Если новый сайт использует другой домен или корзину S3, обновите Aliases и Origins в updated-distribution-config.json в соответствии (например, новый конечная точка сайта корзины и список псевдонимов). Если вы хотите распределение без пользовательского домена на данный момент, очистите псевдонимы:

jq '.Aliases = {"Quantity": 0, "Items": []}' updated-distribution-config.json > final-distribution-config.json

Если вам нужно указать на другую конечную точку сайта S3, отредактируйте раздел Origins в том же файле (например, измените Id и DomainName на имя хоста сайта новой корзины, и установите DefaultCacheBehavior.TargetOriginId на тот же Id).

Шаг 4: Создайте новое распределение

Создайте распределение из окончательной конфигурации:

aws cloudfront create-distribution --distribution-config file://final-distribution-config.json

Ответ включает Id, ARN, DomainName и Status нового распределения. Новое распределение использует платное использование по умолчанию. Затем вы можете указать свой DNS (или Route 53) на новый домен CloudFront, и если вы используете его для Hugo, развернуть с помощью Hugo deploy или AWS CLI как обычно.

Быстрая справка: полный скрипт

Склеенные вместе (используя существующий ID распределения и очищая псевдонимы), процесс выглядит следующим образом:

# 1) Экспорт и извлечение DistributionConfig
aws cloudfront get-distribution-config --id EABCDEFGZ > current-distribution-config.json
jq '.DistributionConfig' < current-distribution-config.json > new-distribution-config.json

# 2) Уникальный CallerReference
NEW_CALLER_REF="new-distr-$(date +%s)"
jq --arg ref "$NEW_CALLER_REF" '.CallerReference = $ref' new-distribution-config.json > updated-distribution-config.json

# 3) Опционально: нет пользовательского домена
jq '.Aliases = {"Quantity": 0, "Items": []}' updated-distribution-config.json > final-distribution-config.json

# 4) Создание (платное использование) распределения
aws cloudfront create-distribution --distribution-config file://final-distribution-config.json

Платное использование vs фиксированные тарифы (кратко)

Платное использование: Вы платите за передачу данных и запросы; бесплатный уровень CloudFront включает 1 ТБ передачи данных и 10 млн HTTP/HTTPS запросов в месяц. Нет ежемесячной платы за план.
Фиксированные тарифные планы: Документированы здесь. Бесплатный план имеет более низкие лимиты (например, 1 млн запросов, 100 ГБ); Про начинается с $15/месяц с большей емкостью и встроенными WAF, Route 53 и т.д. Нет превышений.

Если ваш трафик вписывается в бесплатный уровень платного использования и вам не нужны встроенные функции фиксированного плана, создание распределений через CLI, как описано выше, сохраняет вас на платном использовании, в то время как консоль показывает только Бесплатный/Про.