При использовании #DNS #Alias нужно учитывать, что #HostedZoneId разный для разных Alias Target.
Для #CloudFront он фиксированный Z2FDTNDATAQYW2:

aliasSite:
  Type: AWS::Route53::RecordSet
  Properties:
    HostedZoneName: !Join ['', [!Ref MainDomain, '.']]
    Name:           !Ref MainDomain
    Type:           A
    AliasTarget:
      DNSName:      !Ref CnameSite
      HostedZoneId: Z2FDTNDATAQYW2

Для #LoadBalancer нужно получать его через #GetAtt, для #ELB это:

HostedZoneId1:
Value: !GetAtt [elbExt, 'CanonicalHostedZoneNameID']

Для #ALB это:

HostedZoneId1:
Value: !GetAtt [albExt, 'CanonicalHostedZoneID']

Для #alias на другую #RecordSet нужно получать #HostedZoneId домена:

def Result = sh( script: 'aws route53 list-hosted-zones-by-name --dns-name '+gos.MainDomain, returnStdout: true )
def ResultJson = readJSON ( text: Result )
Stack['dns']['params']['HostedZoneIdDomain'] = ResultJson['HostedZones'][0]['Id'].split('/')[2]

Если свежесозданный #CloudFront отдаёт #error 307 при доступе в (также свежесозданный) бакет, находящийся не в дефолтном регионе (N.Virginia), то не стоит искать ошибку в вашем шаблоне — это лаг самого Амазона на создание DNS бакета в своём в регионе и тут придётся просто ждать (5-45 минут, в зависимости от текущего здоровья Амазона).
Когда он разродится, ошибка исчезнет сама (чтобы это увидеть быстрей - потребуется инвалидация кэша).

Ситуация не возникает по понятным причинам (время проходит и так), когда всё создаётся ручками. Чтобы как-то нивелировать проблему, желательно максимально разнести по времени процессы создания бакета и клаудфронта и/или, если окружение поднимается-удаляется (например, для тестов), то не удалять бакет (пустой бакет денег не ест).

S3 bucket naming

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

только маленькие буквоцифры и дефис

Например:

company1-some-project-us-west-2
myproject33-dev

Никаких нижних подчёркиваний или больших букв, неправильно:

SuperBucket98
my_storage

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

Также крайне нежелательно использовать разрешённые пока точки, очень-приочень не рекомендуется:

cool.site.net
some.domain6

Точки были актуальны в дикие времена нешифрованного HTTP. А теперь, когда везде требуется шифрование HTTPS, смысла использовать такие бакеты (с точками) для хостинга сайтов нет - всё равно придётся ради SSL-сертификата положить сверху #CloudFront.

Некоторые полезные вещи, например, вышеупомянутый #s3 #acceleration - не прокатит для бакета с точками. И другие вдруг потребовавшиеся в будущем. Потому - никаких точкобакетов!

Итого: правильный бакет — right-bucket-name-from-3-to-64-symbols-length

⁠Ошибка CloudFront - Status Code: 409; Error Code: CNAMEAlreadyExists

Одна из (не)весёлых ситуаций. Вы создаете себе #CloudFront на свой родной тёплый ламповый домен и вдруг #error:

One or more aliases specified for the distribution includes an incorrectly configured DNS record that points to another CloudFront distribution. You must update the DNS record to correct the problem. For more information, see https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-restrictions (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: a679d06c-aaee-11e9-8a2d-edaa84658d9b)

Как? Что? Где? Когда??? Кто сидел на моей кровати?!? Мой домен — кто мог создать на него дистрибуцию???

Нервный гуглинг вас приведёт на официальную страницу данной проблемы:

https://aws.amazon.com/premiumsupport/knowledge-center/resolve-cnamealreadyexists-error/

Там красиво всё. Объяснения причины - кто же занял ваш домен - найти не получится. А прочитав последний пункт мазохисты получат истинное удовольствие:

3. After the TXT record is created and you've added an SSL certificate to the distribution, contact AWS Support.

— Што-а-а?!??? У вас косяк, а мне в саппорт?!?

И, кстати, да - это возможно лишь при наличии платной подписки. Занавес.

===

Расслабтесь. В Амазоне не всё работает как должно. Да оно вам и не должно.

Обозначенная проблема имеет простое решение, включать временно платную подписку для обращения в саппорт (да, так можно) не потребуется. Просто создайте дистрибуцию БЕЗ (совсем) CNAME. А после создания добавьте нужный CNAME. Всё - просто в два этапа, а не сразу (как, в принципе, должно и раньше могло работать).

Почему сразу не срабатывает - это к Амазону (в техподдержку). Конечно, беда, если это нужно делать в CloudFormation шаблоне - придётся наворачивать костыли с разбиением на этапы создания плюс обновления. Но решить можно без хитрых спеллов и челобитной.

#i_love_aws

Сustom CNAME для CloudFront со своим сертификатом

Сказка. В тридевятом проекте, в тридесятом аккаунте жил-был environment. Порождённый богом CloudFormation он рос здоровым, занимался спортом, не курил, пользовался секретами и регулярно бэкапился. И всё у него было хорошо.

Но пришло лето и сказал царь - а давайте обновим вон того в углу, полгода не трогали, скукотища и, вообще, что-то давно мы уже два дня как не страдали. И достал дед Вопс свой пайплайн, и закинул его в бакет. Тянет-потянет - и вытянул чудо эдакое неведомое:

com.amazonaws.services.cloudfront.model.InvalidViewerCertificateException: The certificate that is attached to your distribution was not issued by a trusted Certificate Authority. For more details, see: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-requirements (Service: AmazonCloudFront; Status Code: 400; Error Code: InvalidViewerCertificate; Request ID: 336e6167-b7a6-11e9-b5c2-3166fadb8c22)

Чешет темя дед — как же ж так, то ж зимой ещё работало, а теперича уже нет.
Полез дед в интернет, а там Амазон ему и говорит человеческим голосом:

Amazon CloudFront enhances the security for adding alternate domain names to a distribution

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

Загрустил дед, что ж ему с сертификатом-то своим самоподписанным делать, как теперь его в CloudFront запихать?

В общем пошёл дед по форумам, по закоулкам. Ходил день, ходил ночь, по серверам заморским и на кухню в холодильник. Но нашёл таки управу на Амазона хитрого.

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

И пошёл к царю, рассказать про битву страшную и показать зелье сваренное супротив Амазона хитрого. И сказал ему царь - ну, спасибо, тебе, дед, заколебались тебя ждать, где так долго шлялся-то?

===

Мораль из этой сказки следующая. Даже правильные вещи, сделанные правильно по всем правильным правилам #best_practices могут перестать работать. Амазон постоянно ужесточает правила работы и требования к безопасности. То, что раньше делалось, сегодня уже даст ошибку. При этом предыдущие вещи сделанные по каким-то правилам продолжат работать, но вот создать новые так же (или обновить работающие) уже не получится.

===

п.с. Итого. Создать Custom CNAME для #CloudFront со своим сертификатом нельзя (теперь). Однако проверка "трастовости" сертификата происходит лишь при создании CNAME. А значит можно сначала создать с "нормальным", а потом поменять на свой.


Ссылки по теме:

• https://aws.amazon.com/blogs/networking-and-content-delivery/continually-enhancing-domain-security-on-amazon-cloudfront/
• https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-invalid-viewer-certificate/
• https://aws.amazon.com/premiumsupport/knowledge-center/custom-ssl-certificate-cloudfront/
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/troubleshooting-distributions.html

#сказка

CloudFront и формат написания S3 бакета

1. В уже совсем древние времена все бакеты адресовались как:

s3.amazonaws.com/my-bucket

2. Потом формат мигрировал в "поддоменный" вариант:

my-bucket.s3.amazonaws.com

3. После активного размножения регионов добавился "региональный" формат:

my-bucket.s3.some-region.amazonaws.com

===

1.
Первый вариант уже давно depricated и если у вас старый код, который достался в наследство и его нужно завести - смотрите связанные с этим проблемы. Для нового его использовать нельзя.

2.
Второй вариант вполне работоспособен на сегодня. Если бакет не в регионе us-east-1 (N.Virgina - дефолтный регион), то амазон сам определит где он и средиректит запрос в нужный регион, т.е. переделает его в формат третьего варианта.

Кстати, такое поведение (редирект) "под капотом" может давать хитрые ошибки для свежесозданных бакетов. Это когда вы всё делаете через CloudFormation. В таком случае из-за того, что информация о редиректе созданного в другом регионе бакета обновляется не сразу (а окружение через CloudFormation может подняться/обновиться быстро), то вы получаете ошибку 307 — т.к. редирект уже есть, а записи куда редиректится ещё нет. Через некоторое время (до получаса) всё отработает как надо, но паника может наступить раньше очистки кэша.

3.
Третий вариант ранее работал наравне со вторым. Однако теперь это уже не так. В случае работы с новым регионом me-south-1 (Bahrain) работает только третий вариант.

my-dubai-bucket.s3.me-south-1.amazonaws.com

Аналогично будет с Италией и всеми последующими новыми регионами.

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

Первоисточник:

Another option might be to use the following more general format, but be aware that this format doesn't work for Regions launched in 2019 or later


#CloudFront #S3 #AWS_Region

⁠Три новых Edge locations для CloudFront открылись недавно поблизости - в Венгрии, Румынии и Болгарии.

Львовщина, Ивано-Франковщина и Одесса радуются - Амазон подобрался совсем близко. Остальные же могут покрутить следующую ссылку, надеясь, что разноцветные отметки переползут когда-то и на их территорию:

https://www.google.com/maps/d/viewer?mid=1cj0vZ2YZJNp39MHIbstZT3QKPkl3Xgw2

#CloudFront

⁠Amazon CloudFront = 5 минут!

Вы пробовали создать-обновить CloudFront? Попробуйте, он стал быстр, как м̶о̶л̶н̶и̶я̶ ̶г̶е̶п̶а̶р̶д̶ ̶л̶а̶н̶ь̶ — просто очень быстр! Всего 5 минут вместо 25-30 (а то и 40-50) минут раньше. Это ж просто праздник какой-то!

В реальности под капотом большинство endpoints обновляется вообще за секунды и условно пять минут нужно ждать подтверждения от 100% Edge locations, которых становится всё больше.

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

#CloudFront

​​Real-time логи для CloudFront:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/real-time-logs.html

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

Платно, но недорого — по центу за миллион строк лога.

#CloudFront

​​TLS 1.3 для CloudFront:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html

#CloudFront #security

Amazon CloudFront Functions:

https://aws.amazon.com/blogs/aws/introducing-cloudfront-functions-run-your-code-at-the-edge-with-low-latency-at-any-scale/

Вопрос, который как-то поднимал — где же на самом деле исполняется Lambda@Edge — и который вызвал некоторое удивление, теперь официально подтверждён:

Lambda@Edge functions are executed in a regional edge cache (usually in the AWS region closest to the CloudFront edge location reached by the client).

И получается, что CloudFront Functions — это просто как бы "true" Lambda@Edge. И это хорошо. 😀

#CloudFront

Итоги недели на AWS (24-30 октября 2021)

RDS for MySQL
▪️ Поддержка GTID (Global Transaction ID) based replication.
▪️ Задержка для реплик Delayed Replication. Актуально для некоторых DR сценариев. Например, быстрого отката после дропа главной базы - чтобы это сразу же не попадало в реплику DR окружения.

CloudFront
▪️ Header для получения клиентского IP-адреса CloudFront-Viewer-Address.

DocumentDB
▪️ User-defined roles для RBAC.
▪️ Поддержка $literal, $map и $$ROOT.
▪️ Поддержка Geospatial запросов.
▪️ Вышла первая версия JDBC Driver v1.0.0.

AWS Migration Hub
▪️ Новый раздел Strategy Recommendations для анализа on-prem железяк и приложений для выработки стратегии их миграции в AWS.

SageMaker Autopilot
▪️ Поддержка timeseries данных.

EC2
▪️ Новый тип виртуалок DL1 для ML.
▪️ Виртуалки на Intel Ice Lake - C6i.
▪️ Автоподбор типов инстансов для ASG по параметрам ABS (Attribute-Based instance type Selection). Упрощает/улучшает подбор для spot-виртуалок.
▪️ Spot placement score - новая команда get-spot-placement-scores для получения рекомендаций по размещению spot-виртуалок по нужным параметрам с учётом подзон и AWS регионов. В ответе возвращается вероятность наличия spot-ресурсов по шкале от 1 до 10.
▪️ AMI образы виртуалок наконец-то можно шарить не только по аккаунтам, а сразу на целый OU или всю организацию.

Aurora
▪️ Babelfish for Aurora PostgreSQL — надстройка над PostgreSQL для возможности работы кода под Microsoft SQL Server.
▪️ Чтобы окончательно расстроить Microsoft SQL Server, Амазон выложил Babelfish в opensource. Статья в блоге по этому поводу с издевательским названием Goodbye Microsoft SQL Server, Hello Babelfish.

EKS
▪️ Поддержка Bottlerocket для Managed Node Groups.

AWS SAM
▪️ Мгновенное (единицы секунд) обновление кода Лямбды (без передеплоя) с помощью AWS SAM Accelerate. Видео с демонстрацией.

Fargate
▪️ Windows Containers для Fargate (на ECS).

===

⚠️Проголосуйте, пожалуйста, чтобы знать, какие подбирать события. 👇

Опрос — самые интересные AWS события недели 24-30 октября 2021.

#AWS_week

​​Добавление заголовков на ответы для CloudFront:

https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-cloudfront-introduces-response-headers-policies/

Теперь CORS, Cache-Control и прочие STS, CSP сотоварищи можно добавлять прямо в CloudFront с помощью response headers policies:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/understanding-response-headers-policies.html

Можно удалять свои Edge@Lambda и прочие велосипеды, прикрученные для реализации такого очевидного функционала.

#CloudFront

​​New CloudFront Edges:

Australia
🔹 Canberra
🔹 Perth

India
🔹 Ahmedabad
🔹 Bhubaneswar
🔹 Patna

England
🔹 Birmingham
🔹 Bristol
🔹 Hull
🔹 Manchester

Estonia
🔹 Tallinn 👍

New Zealand
🔹 Christchurch

Panama
🔹 Panama City

Peru
🔹 Lima

United States
🔸 Michigan?
🔸 Missouri?
🔸 Nevada?
🔸 New Jersey?
🔸 Tennessee?

Vietnam (new AWS Region?)
🔹 Hanoi
🔹 Ho Chi Minh

The data is taken from a public official document:

https://d1.awsstatic.com/whitepapers/compliance/AWS_SOC3.pdf

Pictured here is Tashkent, Uzbekistan, which is not listed on CloudFront Edges. 👀

#CloudFront

​​Weekly Summary on AWS (May 22-28)

🔸 AMG + version 8.4 & creating Grafana API tokens
🔸 Backup Audit Manager + S3 & Storage Gateway
🔸 CloudFront + CloudFront-Viewer-TLS header
🔸 Config + CloudWatch
🔸 Comprehend + 14 new PII entity types
🔸 DataSync
➖ GCP
➖ Azure
🔸 EC2
➖ c7g Graviton3 instances 🔥
➖ m6id/c6id 7.6TB Local NVMe instances 💥
➖ p4de NVIDIA A100 GPUs instances 💥
➖ Stop protection 👈
🔸 ECS Auto Scaling + changes for Capacity Providers
🔸 ElastiCache for Redis & MemoryDB for Redis + JSON
🔸 ElastiCache for Memcached 1.6.12 + in-transit encryption
🔸 FSx for Lustre + root squash
🔸 IoT Device Management + Active Jobs Limit 1000 → 100 000
🔸 Lambda + PowerShell 👀
🔸 Lightsail + ECR
🔸 Personalize + offline metrics for recommenders
🔸 SSM + port forwarding to remote hosts 👍
🔸 Transit Gateway Network Manager + Multi-Account Support

🔹 AppSync + new console
🔹 ElastiCache for Memcached 1.6.12
🔹 Genomics CLI v1.5.0
🔹 Launch Wizard + SQL Server using FSx for NetApp ONTAP
🔹 Wavelength Zone
➖ Nashville and Tampa
➖ Seoul

#AWS_week

CloudFront KeyValueStore for CloudFront Functions 🎉

CloudFront KeyValueStore is a secure, global, low-latency key value datastore that allows read access from within CloudFront Functions, enabling advanced customizable logic at the CloudFront edge locations.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/kvs-with-functions.html

Use cases:

▫️ URL rewrites or redirects.
▫️ A/B testing and feature flags.
▫️ Access authorization.

Supported values:

◽ String
◽ Byte-encoded string
◽ JSON

#CloudFront

​​CloudFront embedded POPs

https://aws.amazon.com/cloudfront/faqs/#Embedded_Points_of_Presence

🔸CloudFront embedded POPs differ from CloudFront POPs based on where they are deployed and the content they deliver. CloudFront embedded POPs are deployed directly in ISP and MNO networks, unlike CloudFront POPs that are deployed within the AWS network.
🔹CloudFront embedded POPs are designed to deliver cacheable content that is accessed by many end viewers simultaneously such as large scale live video streaming, video on demand, and game downloads.

💰There is no additional charge for using CloudFront embedded POPs.
⚠️You don't have to choose between CloudFront embedded POPs or CloudFront POPs - CloudFront's routing system dynamically utilizes both CloudFront POPs.

#CloudFront

Добрая пятничная история

Пару недель назад AWS выкатил поддержку CloudFront OAC для Lambda function URLs, чтобы можно было удобно ходить в приватные Лямбды.

Сначала все обрадовались, полезное дело, безопасности, все дела, но после выяснилось, что работают лишь GET запросы, а на POST/PUT отдаётся ошибка.

Потом все расстроились, потому что зря обрадовались — ведь это не фича, а баг.

Но один хороший человек упоролся и выяснил, что если посчитать SHA256 хэш и добавить его в заголовок x-amz-content-sha256, то и POST/PUT тоже работают.

https://twitter.com/rooToTheZ/status/1788606025265975505

Он написал запрос на обновление AWS документации для CloudFront и теперь там:

ℹ️ Note
If you use PUT or POST methods with your Lambda function URL, your user must provide a signed payload to CloudFront. Lambda doesn't support unsigned payloads.

В итоге расстроились и те, кто обрадовался, когда другие расстроились, потому что рано обрадовались.

Какая же здесь мораль? Документация — важна. Грамотно задокументированный баг всегда можно сделать фичей.

#CloudFront #Lambda

​​Global CDN Services Market About $5B in 2023, Expected To Grow 3% In 2024, Driven by AWS

https://www.streamingmediablog.com/2024/07/cdn-market-size.html

#CDN #CloudFront #info

CloudFront подешевел — больше не учитываются запросы, заблокированные WAF.

https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-cloudfront-charges-requests-blocked-aws-waf/

— А что, раньше за это деньги брали?!
— Да. Но теперь совершенно бесплатно!

#CloudFront