Cегодня истекли (уже) сертификаты rds-ca-2015, так надоевшие постоянными предупреждениями и просьбами, переходящими в требования, их обновить.

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

#RDS

Когда нужно в каком-то аккаунте почистить орды кем-то наделанных EBS снэпшотов и AMI-образов, то вручную кликать можно устать. Для автоматизации процесса подойдёт простая утилитка:

https://github.com/bonclay7/aws-amicleaner

#EBS #AMI

Amazon EKS + AWS KMS

Теперь куберовские секреты можно шифровать с помощью KMS:

https://aws.amazon.com/blogs/containers/using-eks-encryption-provider-support-for-defense-in-depth/

Давно востребованный и важный для различных compliance требований функционал.

#EKS #KMS

⁠Amazon CloudFront = 5 минут!

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

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

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

#CloudFront

Все сервисы AWS на одной странице-табличке вместе с ссылками на них:

https://www.awsgeek.com/AWS-Periodic-Table/

#info

Ответы на викторину по S3 + torrents — правда или ложь

Кто знает или читает историю AWS - тому ответ был известен заранее. :) А правильный ответ — да, S3 умеет торренты, соответствующий раздел в документации по ссылке с очевидным урлом:

https://docs.aws.amazon.com/AmazonS3/latest/dev/S3Torrent.html

#ответы

Disaster Tolerance vs Disaster Recovery

Длинная подробная статья о Disaster Tolerance подходе:

https://medium.com/cloudpegboard/disaster-tolerance-patterns-using-aws-serverless-services-fdfbe4163d84

Если заходит речь о бэкапах и каких-то их аспектов в частности или даже о Backup Strategy в общем, то всегда нужно помнить, что бэкап, который вы никогда не проверяли — бессмысленный бэкап, дающий лишь обманчивое ощущение защищённости.

Когда спрашивают "Что у нас с бэкапами?", всегда переводите вопрос в контекст "Что у нас с Disaster Recovery?" — бэкапы должны (периодически) проверяться путём подъёма полной версии вашего приложения/окружения в рамках DR плана.

В статье же рассматривается продолжение и развитие этого подхода — на вариант Disaster Tolerance, когда вы сразу закладываете в архитектуру устойчивость к проблемам падения региональных сервисов, так сказать, такой себе Netflix way.

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

#DR

⁠Amazon S3 Website Endpoints - ищем логику

Многие попадаются при написании своих скриптов для работы с S3 Website Endpoints:

https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints

Когда выясняется, что s3-website в одних регионах является поддоменом и пишется через точку, а в других через тире вместе с идентификатором региона:

s3-website.region.amazonaws.com
s3-website-region.amazonaws.com

После тщетных попыток понять задумку разработчиков всего этого, вырывается очевидный восклик: «Где логика?!?»

Давайте поищем её в истории AWS. Возьмём даты анонсов AWS регионов и упорядочим по времени их появления. В результате получится табличка - см. картинку.

Видно, что до 2013-го года использовался вариант s3-website-region.amazonaws.com, начиная с Франкфурта - используется s3-website.region.amazonaws.com.

Всё просто и логично. Почему с 2014-го стали использовать отдельный поддомен для региона — уже совсем другая история.

#s3

⁠Полезное видео для понимания тонкостей работы S3.

AWS re:Invent 2017: Deep Dive on Amazon S3 & Amazon Glacier Infrastructure, with spe (STG301)

Ссылка на начало видео, где немного рассказывается, как работает Amazon S3 под капотом (на картинке).

#s3 #video

⁠EC2 Local Zone Settings

Для региона Oregon, где имеется Local Zone (кто пропустил - почитайте про первую локальную зону в Лос-Анжелесе - если коротко, то это подзона с задержками в единицы миллисекунд для, например, игр в виртуальной реальности и прочих вещей, требовательных к latency), теперь можно её включить в консоли.

Сделать это не так просто - нужно найти плохозаметную кнопку Enable additional Local Zones на дашборде EC2 консоли (см. картинку) и после изменить статус на Enable.

Актуально только (пока) для Oregon (где есть локальная зона). Включить можно, а выключить лишь через поддержку. Потому, в общем случае, если вы не планируете её использовать напрямую, лучше не включать, чтобы случайно не поломать какие-то ваши скрипты подзоной в виде us-west-2-lax-1.

#AWS_Console #EC2

Новые тесты AWS Graviton 2

https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd

Если коротко, Graviton 2 рвёт AMD и Intel как тузик грелку прямо везде. Правда с поправкой на то, что все тесты синтетические (нет реальных бенчмарков), сравнивать 64 ядра Гравитона 2 с 32 ядра + 32 потока у старенького AMD первого поколения Zen — так себе практика (почему не Zen2 и что там делает Intel с 24 ядрами + 24 потоками — промолчим).

Но если отбросить подобные придирки — выглядит устрашающе и наверняка достойно, чтоб хотя бы попробовать лично и сделать собственный вывод.

#Graviton

⁠EKS + Kubernetes 1.15

https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html

Грустный комментарий, но это нужно зафиксировать — спустя релиза 1.15 прошло 9 месяцев. Значит, получается, 1.16 нужно ждать в июне.

Выдержка и ещё раз выдержка. Важное свойство для успешной работы с некоторыми сервисами AWS.

#EKS

Если вам (не) нравилась CoreOS, то попробуйте амазоновский вариант операционной системы для работы с контейнерами Bottlerocket OS:

https://aws.amazon.com/blogs/aws/bottlerocket-open-source-os-for-container-hosting/

На текущий момент она подразумевает работу с EC2 инстансами на Амазоне, но являясь открытой, в будущем будет возможность поднимать Bottlerocket OS на своём железе.

https://github.com/bottlerocket-os/bottlerocket

Кроме того, в процессе реализации поддержка ECS, а после и Firecracker:

https://github.com/orgs/bottlerocket-os/projects/1

В общем, можно сказать, что Амазон реагирует на критику в свой адрес и в результате всё активней движется в сторону Open Source.

#Bottlerocket

⁠Aurora PostgreSQL глобализировалась:

https://aws.amazon.com/about-aws/whats-new/2020/03/amazon-aurora-with-postgresql-compatibility-supports-amazon-aurora-global-database/

На текущий момент поддерживается лишь версия Aurora PostgreSQL 10.11, которую нужно создать или восстановить из снэпшота версии PostgreSQL 10.7 на инстансх db.r4 или db.r5 типа, а после создания добавить регионы (до четырёх штук - на картинке), получив таким образом глобальную работу.

#Aurora

CodeBuild и ECS

Когда из CodeBuild нужно работать с другим аккаунтом, и потребуется переключаться в роль с помощью флажка --profile, учтите , что обычный вариант не сработает и будет давать ошибку:

Error when retrieving credentials from Ec2InstanceMetadata: No credentials found in credential_source referenced in profile ***

Это потому, что вместо обычного:

credential_source = Ec2InstanceMetadata

В секции профиля файла ~/.aws/config нужно использовать:

credential_source = EcsContainer

И всё заработает.

Почему? Получается, видимо, потому, что CodeBuild под капотом использует ECS.

В принципе, логично, хоть и не видел подобного в документации (что тоже логично).

#CodeBuild

AWS Loft Moscow 2020 отменён (переносится)

«В связи с ухудшением ситуации с короновирусом (COVID-19) в России, компания Amazon Web Services приняла решение отложить проведение AWS Pop-up Loft Moscow, запланированного на 13-17 апреля 2020 года в Москве. Мы приняли это решение после тщательного анализа ситуации, так как здоровье и безопасность наших сотрудников, клиентов и партнеров являются нашим главным приоритетом. Мы планируем провести это мероприятие позднее в этом году.»

Allow + NotPrincipal

Стоит быть внимательным и не допускать использования связки Allow + NotPrincipal при написании S3 Bucket Policy, например, типа такого варианта:

{
 "Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "NotPrincipal": {"AWS": [
     "arn:aws:iam::111111111111:user/SomeUser1",
     "arn:aws:iam::222222222222:user/SomeUser2"
   ]},
   "Action": "s3:*",
   "Resource": [
     "arn:aws:s3:::my-bucket",
     "arn:aws:s3:::my-bucket/*"
   ]
 }]
}

Где вы как бы хотите запретить доступ в бакет каким-то юзерам из каких-то аккаунтов.

В результате они (эти два юзера из примера выше) туда, действительно, не получат доступа. Однако кроме этого, незаметно, в бакет my-bucket получат доступ не просто другие ваши пользователи, но и вообще все, включая гостей (anonymous users) из интернета!

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notprincipal.html#specifying-notprincipal-allow

Потому в общем случае всегда нужно использовать связку запретить+кроме (Deny+NotPrincipal).

#s3 #bucket_policy

⁠Когда вы желаете сэкономить на хранении данных в S3 с помощью перевода данных на S3 IA (Infrequent Access), который в два раза дешевле обычного (S3 Standard), обязательно учитывайте, что за получение данных из S3 IA взимается плата (1 цент каждый гигабайт в отличие от бесплатного трафика для S3 Standard).

Иначе может получиться как здесь:

https://fudless.xyz/aws/boom/

Для подсчёта выгодности - можно использовать специальный калькулятор S3 Standard vs S3 Infrequent Access:

https://www.gulamshakir.com/apps/s3calc/index.html

Аналогично в случае использования S3 Intelligent-Tiering — там сам Амазон автоматически переведёт данные из S3 IA в S3 Standard при первом же доступе к ним (и не получится так плачевно, как по первой ссылке), однако как раз и нужно учитывать, что транзит из одного типа в другой (Lifecycle Transition) также стоит денег:

https://aws.amazon.com/s3/pricing/

Итого: Амазон предлагает много разных и действенных способов сэкономить на хранилище данных в S3. Однако всё нужно применять, понимая, что делаешь.

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

#s3 #cost_optimization

⁠Тестов много не бывает - комплексное сравнение производительности различных подсистем AWS, Azure и GCP
у @tech_b0lt_Genona.

Если коротко, то AWS хорош, Azure неплох, а GCP растёт над собой.

#info #comparison