При конструировании DNS для #s3 бакет нужно быть максимально внимательным - неоднозначное толкование официальной документации, где говорится про «you can use either of these endpoints» в реальности может давать различные проблемы.
С одной стороны, используя вариант с
С одной стороны, используя вариант с
.s3.amazonaws.comдаёт в результате перенаправление, а значит изначально #error #307 и лишь потом нужный файл/страницу. Это может приводить к некорректной работе критическим к такому поведению вещей. Например, когда через s3 бакеты подтягиваются конфиг-файлы #nginx, то такое поведение даст ошибку «unexpected end of file, expecting ";" or "}" in /etc/nginx/conf.d/...», т.к. получив 307 он не будет делать ещё один запрос по новому location из ответа. Потому правильно использовать именно вариант типа:
!Join ['',[!Ref Bucket, '.s3-', !Ref 'AWS::Region' , '.amazonaws.com' ]]Однако бывает и противоположная ситуация, например, с регионом N.Virginia. Для #CloudFront #Origin (в том числе для Logging бакета)
DomainName вариант bucket.s3-us-east-1.amazonaws.com даёт стабильные #error 502 для #distribution. Правильный вариант с bucket.s3.amazonaws.com:Origins:#issue
- DomainName: !Join ['',[!Ref Bucket, '.s3.amazonaws.com' ]]
Amazon
Buckets overview - Amazon Simple Storage Service
Store all of your files, known as objects, within a uniquely named Amazon S3 bucket.
#CloudFront нельзя завести на #internal #LoadBalancer, т.к. он не умеет (не может) работать с элементами в #VPC, потому с #CloudFront — только #public (#internet-facing) #LoadBalancer.
При использовании #DNS #Alias нужно учитывать, что #HostedZoneId разный для разных Alias Target.
Для #CloudFront он фиксированный Z2FDTNDATAQYW2:
Для #LoadBalancer нужно получать его через #GetAtt, для #ELB это:
Для #ALB это:
Для #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 он фиксированный 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]
Amazon
Values specific for simple alias records - Amazon Route 53
When you create alias records, you specify the following values. For more information, see .
Если свежесозданный #CloudFront отдаёт #error 307 при доступе в (также свежесозданный) бакет, находящийся не в дефолтном регионе (N.Virginia), то не стоит искать ошибку в вашем шаблоне — это лаг самого Амазона на создание DNS бакета в своём в регионе и тут придётся просто ждать (5-45 минут, в зависимости от текущего здоровья Амазона).
Когда он разродится, ошибка исчезнет сама (чтобы это увидеть быстрей - потребуется инвалидация кэша).
Ситуация не возникает по понятным причинам (время проходит и так), когда всё создаётся ручками. Чтобы как-то нивелировать проблему, желательно максимально разнести по времени процессы создания бакета и клаудфронта и/или, если окружение поднимается-удаляется (например, для тестов), то не удалять бакет (пустой бакет денег не ест).
Когда он разродится, ошибка исчезнет сама (чтобы это увидеть быстрей - потребуется инвалидация кэша).
Ситуация не возникает по понятным причинам (время проходит и так), когда всё создаётся ручками. Чтобы как-то нивелировать проблему, желательно максимально разнести по времени процессы создания бакета и клаудфронта и/или, если окружение поднимается-удаляется (например, для тестов), то не удалять бакет (пустой бакет денег не ест).
S3 bucket naming
Придумывая имя для очередного бакета, чтобы не иметь проблем, настоятельно рекомендуется использовать следующие правила:
только маленькие буквоцифры и дефис
Например:
Также крайне нежелательно использовать разрешённые пока точки, очень-приочень не рекомендуется:
Некоторые полезные вещи, например, вышеупомянутый #s3 #acceleration - не прокатит для бакета с точками. И другие вдруг потребовавшиеся в будущем. Потому - никаких точкобакетов!
Итого: правильный бакет — right-bucket-name-from-3-to-64-symbols-length
Придумывая имя для очередного бакета, чтобы не иметь проблем, настоятельно рекомендуется использовать следующие правила:
только маленькие буквоцифры и дефис
Например:
company1-some-project-us-west-2Никаких нижних подчёркиваний или больших букв, неправильно:
myproject33-dev
SuperBucket98Это уже в прошлом и не разрешено, хотя старые бакеты такое могут иметь, потому не удивляйтесь.
my_storage
Также крайне нежелательно использовать разрешённые пока точки, очень-приочень не рекомендуется:
cool.site.netТочки были актуальны в дикие времена нешифрованного HTTP. А теперь, когда везде требуется шифрование HTTPS, смысла использовать такие бакеты (с точками) для хостинга сайтов нет - всё равно придётся ради SSL-сертификата положить сверху #CloudFront.
some.domain6
Некоторые полезные вещи, например, вышеупомянутый #s3 #acceleration - не прокатит для бакета с точками. И другие вдруг потребовавшиеся в будущем. Потому - никаких точкобакетов!
Итого: правильный бакет — right-bucket-name-from-3-to-64-symbols-length
Ошибка CloudFront - Status Code: 409; Error Code: CNAMEAlreadyExists
Одна из (не)весёлых ситуаций. Вы создаете себе #CloudFront на свой родной тёплый ламповый домен и вдруг #error:
Как? Что? Где? Когда??? Кто сидел на моей кровати?!? Мой домен — кто мог создать на него дистрибуцию???
Нервный гуглинг вас приведёт на официальную страницу данной проблемы:
https://aws.amazon.com/premiumsupport/knowledge-center/resolve-cnamealreadyexists-error/
Там красиво всё. Объяснения причины - кто же занял ваш домен - найти не получится. А прочитав последний пункт мазохисты получат истинное удовольствие:
— Што-а-а?!??? У вас косяк, а мне в саппорт?!?
И, кстати, да - это возможно лишь при наличии платной подписки. Занавес.
===
Расслабтесь. В Амазоне не всё работает как должно. Да оно вам и не должно.
Обозначенная проблема имеет простое решение, включать временно платную подписку для обращения в саппорт (да, так можно) не потребуется. Просто создайте дистрибуцию БЕЗ (совсем) CNAME. А после создания добавьте нужный CNAME. Всё - просто в два этапа, а не сразу (как, в принципе, должно и раньше могло работать).
Почему сразу не срабатывает - это к Амазону (в техподдержку). Конечно, беда, если это нужно делать в CloudFormation шаблоне - придётся наворачивать костыли с разбиением на этапы создания плюс обновления. Но решить можно без хитрых спеллов и челобитной.
#i_love_aws
Одна из (не)весёлых ситуаций. Вы создаете себе #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 он рос здоровым, занимался спортом, не курил, пользовался секретами и регулярно бэкапился. И всё у него было хорошо.
Но пришло лето и сказал царь - а давайте обновим вон того в углу, полгода не трогали, скукотища и, вообще, что-то давно мы уже два дня как не страдали. И достал дед Вопс свой пайплайн, и закинул его в бакет. Тянет-потянет - и вытянул чудо эдакое неведомое:
Чешет темя дед — как же ж так, то ж зимой ещё работало, а теперича уже нет.
Полез дед в интернет, а там Амазон ему и говорит человеческим голосом:
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
#сказка
Сказка. В тридевятом проекте, в тридесятом аккаунте жил-был 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
#сказка
Amazon
Amazon CloudFront enhances the security for adding alternate domain names to a distribution
🔥1
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.
Второй вариант вполне работоспособен на сегодня. Если бакет не в регионе
Кстати, такое поведение (редирект) "под капотом" может давать хитрые ошибки для свежесозданных бакетов. Это когда вы всё делаете через CloudFormation. В таком случае из-за того, что информация о редиректе созданного в другом регионе бакета обновляется не сразу (а окружение через CloudFormation может подняться/обновиться быстро), то вы получаете ошибку 307 — т.к. редирект уже есть, а записи куда редиректится ещё нет. Через некоторое время (до получаса) всё отработает как надо, но паника может наступить раньше очистки кэша.
3.
Третий вариант ранее работал наравне со вторым. Однако теперь это уже не так. В случае работы с новым регионом
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
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
Amazon
Use various origins with CloudFront distributions - Amazon CloudFront
You can use various different origins with Amazon CloudFront, including Amazon S3 buckets, Elastic Load Balancing load balancers, MediaStore containers, MediaPackage channels, and Amazon EC2 instances.
Три новых Edge locations для CloudFront открылись недавно поблизости - в Венгрии, Румынии и Болгарии.
Львовщина, Ивано-Франковщина и Одесса радуются - Амазон подобрался совсем близко. Остальные же могут покрутить следующую ссылку, надеясь, что разноцветные отметки переползут когда-то и на их территорию:
https://www.google.com/maps/d/viewer?mid=1cj0vZ2YZJNp39MHIbstZT3QKPkl3Xgw2
#CloudFront
Львовщина, Ивано-Франковщина и Одесса радуются - Амазон подобрался совсем близко. Остальные же могут покрутить следующую ссылку, надеясь, что разноцветные отметки переползут когда-то и на их территорию:
https://www.google.com/maps/d/viewer?mid=1cj0vZ2YZJNp39MHIbstZT3QKPkl3Xgw2
#CloudFront
Amazon CloudFront = 5 минут!
Вы пробовали создать-обновить CloudFront? Попробуйте, он стал быстр, как м̶о̶л̶н̶и̶я̶ ̶г̶е̶п̶а̶р̶д̶ ̶л̶а̶н̶ь̶ — просто очень быстр! Всего 5 минут вместо 25-30 (а то и 40-50) минут раньше. Это ж просто праздник какой-то!
В реальности под капотом большинство endpoints обновляется вообще за секунды и условно пять минут нужно ждать подтверждения от 100%
Не знаю, когда расскажут про эти выдающиеся результаты команды CloudFront официально, но это отличное завершение недели и есть повод за них выпить во всех смыслах. Браво!
#CloudFront
Вы пробовали создать-обновить 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
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/real-time-logs.html
Полезная штука для специфичных вещей и, возможно, отладки — чтобы сразу видеть логи.
Платно, но недорого — по центу за миллион строк лога.
#CloudFront
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 — и который вызвал некоторое удивление, теперь официально подтверждён:
И получается, что CloudFront Functions — это просто как бы "true" Lambda@Edge. И это хорошо. 😀
#CloudFront
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
Amazon
Introducing CloudFront Functions – Run Your Code at the Edge with Low Latency at Any Scale | Amazon Web Services
With Amazon CloudFront, you can securely deliver data, videos, applications, and APIs to your customers globally with low latency and high transfer speeds. To offer a customized experience and the lowest possible latency, many modern applications execute…
Итоги недели на AWS (
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 события недели
#AWS_week
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/
Теперь
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/understanding-response-headers-policies.html
Можно удалять свои Edge@Lambda и прочие велосипеды, прикрученные для реализации такого очевидного функционала.
#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
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