​​cfn-teleport

A command-line tool which can move CloudFormation resources between stacks.

https://github.com/udondan/cfn-teleport

cfn-teleport --source Stack1 --target Stack2 --resource Bucket21D68F7E8 --resource Bucket182C536A1 --yes

#CloudFormation

Уже третий эпизод - и только о AWS организациях!
В первой части поговорили о Organization Units, во второй - о service control policies (SCPs). В новом выпуске продолжаем обсуждать безопасность: начали с IAM Access Analyzer, затронули то, как работает SOO и работу c SSO через CLI. А на сладкое поделились с вами проверенными практиками написания SCP политик, способами защиты root account и MFA, а также описали важные шаги в случае, если MFA была утеряна.

Тема настолько обширная, что, кажется, будет продолжение в 4 выпуске. Будем рады ответить на вопросы!

#podcast
Послушать можно тут:
- Apple Podcasts
- Google Podcasts
- Spotify
- PodBean
- YandexMusic

Watch out for your kids!

​​⭐️ Top AWS Week Updates 2023 April 23-29

Прошедшая неделя была богата заметными AWS новостями.

🔹 Athena теперь имеет Provisioned Capacity, важная и полезная вещь. Однако попытка "включил и выключил — приключение на 20 минут" закончится аналогично, т.к. минимальная мощность 24 DPU, а время 8 часов, то есть около 60$.

🔸 В CloudWatch обновилась консоль и да, это важно. Вы ведь тоже ненавидите CloudWatch за те проклятые часы, когда накликанные дашборды уходили в небытиё из-за окончания сессии? Так вот, произошло чудо и туда таки завезли автосохранение (а в следующем году мог бы быть юбилей ненависти — 15 лет).

🔹 В FIS сервис завезли симуляцию переполнения диска — первая проблема по популярности (проблемы сети/DNS, понятно, вне конкуренции).

🔸 Пишущим на Java (мои соболезнования) в Lambda добавили поддержку Java 17.

🔹 Амазоновская Grafana проапдейтилась до 9.4 версии, ура! Кто кликал там всё вручную — придётся страдать и завидовать. Миграции не предусмотрено, просто при создании workspace можно выбрать версию 8.4 или 9.4.

🔸 Новость про поддержку в RDS инстансов m7g/r7g здесь была ещё 2 недели назад, но другим рассказали страшную правду лишь сейчас.

🔹 Амазоновская Kafka (MSK) теперь может работать cross-account и cross-VPC — реально круто.

🔸 В OpenSearch завезли OpenSearch Ingestion, просто супер. Что, уже можно выбрасывать свои костыли и всякие Лямбды для заброса логов с S3? Эээ, не спешите, посмотрите на ценник. $200 в месяц. Кому-то нормально, конечно, но если костыли работают очень давно, то это уже не костыли, а "исторически сложившаяся архитектура".

🔹 В RAM добавились кастомные политики расшаривания. То есть можно ограничить расшаренное в какой-то аккаунт, отдавая лишь кусочек нужного функционала. Не шибко применимо на сейчас, но супер круто на потом.

🔸 В S3 наконец-то сделали по дефолту ACL выключенным, а бакеты приватными, ура, свершилось! Хотя ещё в четверг пробовал, не было. Теперь можно удалять раздражающие блоки aws_s3_bucket_public_access_block и aws_s3_bucket_ownership_controls для каждого бакета.

🔹 Amazon Verified Access вышел в GA. Классный, крутой и полезный сервис. Если бы не цена. 200$ в месяц за то, что ваши девопсы не осилили настроить AWS ALB + SSO через Cognito — такое себе удовольствие.

🔸 В поддержку добавили корейский. Это не важно? Ну, как сказать. Тот нечастый случай, когда завидуешь гражданам КНДР.

🔹 В EC2 для AMD виртуалок завезли поддержку SEV-SNP. Если кому-то этот странный набор букв кажется не слишком важным, то, поверьте, это очень важно — расскажу в следующем посте.

#top #week

​​Confidential Computing

Confidential Computing, если говорить упрощённо, это способ запуска своей виртуалки или приложения таким образом, что остальные части — гипервизор, хостовая ОС или условный BIOS (в общем, всё, что "выше" и можно подвести под термин "Cloud Provider") — не имеют доступа к вашей информации. Реализуется это на уровне процессора, когда память шифруется на лету, т.е. в DRAM сохраняется уже в зашифрованном виде и расшифровывается при чтении. Ключи шифрования не покидают процессор и вы можете проконтролировать этот процесс.

История

Intel в 2015-м году выпустил первые процессоры с Intel SGX, технологией, позволяющей на программном уровне внутри ОС или виртуалки создать шифрованную область, которая аппаратно защищена от любых других процессов.

AMD выбрала другой путь и в 2016-м выпустила процессоры с AMD SEV, шифрующие всю память на уровне виртуалки. Это намного удобней — нет специальных драйверов и разработки на уровне приложений. Кроме того такой подход позволяет обезопасить уже имеющиеся нагрузки (легаси) да и просто "облачней".

Каждый из конкурирующих вариантов имел проблемы. Intel SGX ломали столько раз, что Intel даже задеприкейтила эту технологию, начиная с десктопных процессоров 11-го поколения. AMD SEV не шифровал регистры при переключении, потому через год появился AMD SEV-ES. Проигрывая Intel по части отсутствия контроля целостности памяти, в 20-м году с выходом Zen3 появился функционал AMD SEV-SNP, который закрыл эту проблему.

Intel тоже активно работал, штопая дыры и клепая версии Intel SGX. Первая позволяла защитить лишь маленькую область данных 128/256МБ, потому появилась Intel SGX Scalable, увеличив объём до 1 ТБ. Технология Intel SGX осталась в серверных процессорах и имеет на текущий момент уже третью версию драйвера. Догоняя AMD в популярном подходе шифрования на уровне виртуалки, она выпустила Intel TDX, доступный в последнем поколении серверных процессоров.

Итого на сегодня для реализации Confidential Computing для x86 имеем:
▫️ AMD SEV-SNP, построенная на базе AMD SEV и AMD SEV-ES — начиная с Zen3 (2021)
▫️ Intel TDX, построенная на базе Intel SGX — начиная с 4th Gen Intel Xeon Scalable processors (2022)

▪️ А что же для ARM? У ARM давно есть технология TrustZone, однако она имеет ограничения схожие с Intel SGX. В будущих процессорах ARM v9 это будет реализовано с помощью ARM CCA (Confidential Computing Architecture), то есть на текущий момент это лишь планы (2023+).
▪️ Наконец, Nvidia тоже с недавнего времени старается решить этот вопрос и год назад реализовала функционал Confidential Computing в NVIDIA H100 Tensor Core GPU (2022).

Итого, четыре крупных игрока, три из которых уже имеют решения для Confidential Computing.

А что же AWS? Амазон пошёл другим путём, по принципу сходным с Intel SGX, реализовав технологию AWS Nitro Enclaves, позволяющую создать защищённую область внутри EC2 виртуалки. Её тоже можно удалённо аттестировать, однако в отличие от Intel, у AWS имеется техническая возможность получить доступ к данным внутри, поэтому реализовать ZeroTrust подход невозможно, т.к. в трастовых всегда будет AWS как провайдер. В том числе поэтому спектр применения AWS Nitro Enclaves достаточно узкий.

👉 Продолжение следует.

#ConfidentialComputing

​​☁️ Confidential Computing на AWS

29 апреля 2023 компания AWS официально вступила в клуб Confidential Computing.

https://aws.amazon.com/about-aws/whats-new/2023/04/amazon-ec2-amd-sev-snp/
 
Многие годы скептики переезда в облака и, в частности, в AWS, имели три железных аргумента:

1️⃣ Не доверяю этим вашим облакам, которые где-то там. Только настоящее железо у себя в серверной!

Появление AWS Outposts закрыло этот аргумент — можно поставить себе в серверную кусочек собственного и при этом настоящего AWS.

https://aws.amazon.com/outposts/

2️⃣ А ключи шифрования-то лежат у облачного провайдера, захочет — расшифрует!

Появление AWS XKS закрыло и этот аргумент — теперь в качестве AWS KMS можно использовать собственный ключ, который не будет покидать вашей серверной.

https://aws.amazon.com/blogs/aws/announcing-aws-kms-external-key-store-xks/

3️⃣ Всё равно провайдер, если захочет или если от него потребуют — получит доступ к вашим данным!

Появление поддержки AMD SEV-SNP закрыло и этот аргумент — создав виртуалку c6a/m6a/r6a в Ирландии или Огайо, её можно аттестовать и убедиться, что AWS не имеет доступа к данным в ней на аппаратном уровне.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snp-attestation.html

И это реально круто. 💪

💰 Круто и недорого — за поддержку AMD SEV-SNP придётся доплатить 10% от стоимости виртуалки, а значит минимальная обойдётся в 60$/месяц. Теперь можно выполнять даже самые жестокие требования регуляторов.

🌤️ Но главное, повторюсь, у скептиков переезда в AWS из-за опасений по части безопасности не осталось аргументов — есть любые варианты. Можно спорить о цене и других моментах, но вопрос с безопасностью железно закрыт во всех смыслах.

👉 Продолжение следует
Часть 1 - Confidential Computing

#ConfidentialComputing

Микросервисы → Монолит

Статья от Amazon Prime Video, где рассказывается, как удалось уменьшить расходы в десять раз после перехода с микросервисов на монолитную архитектуру:

https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

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

v.0.0.0

— Привет, Дмитро. Тут задача срочная прилетела — клиенту нужно запилить сервис по проверке качества роликов. А вы, помню, уже как-то что-то делали для тестирования видео?
— Было дело, накрапали костылик для внутренних нужд, чтобы отчёты слать аналитикам.
— Вот и отлично, приступайте.
— А какая нагрузка планируется?
— Подробностей не знаю, если что, чего-нибудь помощней поставим.
— Не, мы ж на Лямбдах всё написали.
— О, отлично, передам маркетингу — у нас будет Serverless-решение!

v.0.1.0

— Макс, что по нагрузке?
— Всё должно работать рилтайм и в перспективе держать тысячи параллельных задач на обработку.
— <censored>! Мы ж никогда пробовали на таких объёмах.
— Поздно, уже всё продано, продолжайте делать.
— А денег у клиента хватит?
— Деньги не проблема, главное сделать быстро!

v.1.0.0

— Дмитро, у нас проблемы. Клиент увидел счёт за прошлый месяц и офигел.
— Я предупреждал. И это лишь 5% от полной нагрузки.
— А почему так дорого?
— Так мы ж каждый кадр видео на S3 гоняем Лямбдами по несколько раз с помощью дорогущих Step Functions.
— И как это исправить?
— Никак, нужно всё переделывать. Проанализировать результаты под нагрузкой, попробовать различные варианты, спроектировать...
— ...А если нужно вчера?
— Ну, можно всё тупо засунуть в один контейнер и масштабировать как монолит с помощью ECS. Ещё и дешевле получится.
— О, супер, так и сделаем. И продадим как версию 2.0. А я напишу маркетингу, пусть они статейку накатают, как мы сэкономили клиенту кучу денег, перейдя на монолит с микросервисов. Все будут обсуждать только это и никто не вспомнит, как мы облажались с первой версией.

#serverless #monolith #design

Анализ статьи Amazon Prime Video

Во-первых, мои поздравления команде маркетинга Amazon — браво, великолепная работа! Кратко, минимум информации, точно в больное место и в результате каждый может сделать для себя (не)правильные выводы.

Во-вторых, если у вас есть сомнения в компетенциях управляющих процессом разработки в Amazon, то сначала спросите, что по этому поводу думает Google ChatGPT или просто посмотрите список самых успешных IT компаний.

Целью команды Amazon Prime Video было максимально быстро получить рабочий вариант. С отлаженным процессом разработки на Serverless можно выдавать готовые решения за несколько спринтов, в том числе для сложных и нагруженных систем.

Главный плюс Serverless — не условная "бесплатность", это уже побочный эффект. Главный плюс — скорость разработки и возможность справляться с неизвестной или непрогнозируемой нагрузкой.

Анализ статьи с цитатами из текста

1️⃣ Была задача получить решение максимально быстро и они сделали это. Serverless прекрасно вписывается в этот подход и команда имеет опыт разработки Serverless решений.

«We designed our initial solution as a distributed system using serverless components (for example, AWS Step Functions or AWS Lambda), which was a good choice for building the service quickly.»

2️⃣ Они получили опыт эксплуатации первой тестовой версии и реальные данные по нагрузке. Выяснилось, что быстро разработанное Serverless-решение имеет ограничения по масштабированию да при этом ещё и дорогое.

«In theory, this would allow us to scale each service component independently. However, the way we used some components caused us to hit a hard scaling limit at around 5% of the expected load. Also, the overall cost of all the building blocks was too high to accept the solution at a large scale.»

3️⃣ На основе полученных данных они получили возможность сформировать конкретные требования как по масштабированию, так и по стоимости. В результате чего переработали решение, выбрав монолитную архитектуру вместо распределённой.

«We initially considered fixing problems separately to reduce cost and increase scaling capabilities. We experimented and took a bold decision: we decided to rearchitect our infrastructure.
We realized that distributed approach wasn’t bringing a lot of benefits in our specific use case, so we packed all of the components into a single process. This eliminated the need for the S3 bucket as the intermediate storage for video frames because our data transfer now happened in the memory. We also implemented orchestration that controls components within a single instance.»

4️⃣ Изменения затронули лишь исполнительную часть, общая схема не изменилась, поэтому переход Serverless → ECS был быстрым.

«Conceptually, the high-level architecture remained the same. We still have exactly the same components as we had in the initial design (media conversion, detectors, or orchestration). This allowed us to reuse a lot of code and quickly migrate to a new architecture.»

Выводы

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

Однако каждый может сделать и свои выводы — ещё раз респект маркетингу Amazon. Кстати, им точно стоит развить успех и помочь коллегам из AWS с придумыванием адекватных названий для сервисов.

P.S. Самая уместная (из немногих) статья по данной теме:

https://adrianco.medium.com/so-many-bad-takes-what-is-there-to-learn-from-the-prime-video-microservices-to-monolith-story-4bd0970423d4

#design #development #marketing

​​Подпрыгнувшие за последние пару месяцев цены на spot-виртуалки в цифрах:

https://pauley.me/post/2023/spot-price-trends/

Изменение spot-цен на популярные типы:

t3a +115%
t4g +105%
c5a +88%
t3 +87%
m4 +84%
c6g +62%
m6g +59%
c5 +35%

#EC2 #spot

​​🆕 EC2 i4g — storage-optimized Graviton instances:

https://aws.amazon.com/blogs/aws/new-storage-optimized-amazon-ec2-i4g-instances-graviton-processors-and-aws-nitro-ssds/

▪️ Up to 800K random write IOPS
▪️ Up to 1 million random read IOPS
▪️ Up to 5600 MB/second of sequential writes
▪️ Up to 8000 MB/second of sequential reads

#EC2

Cedar — будущая замена AWS IAM

Возможно у заголовка не хватает вопросительного знака в конце, но я воздержусь. Сегодня зарелизился Cedar policy language:

AWS Blog 🔗 https://aws.amazon.com/blogs/opensource/using-open-source-cedar-to-write-and-enforce-custom-authorization-policies/

🔗 https://www.cedarpolicy.com/
📚 https://docs.cedarpolicy.com/

Написанный на Rust, легковесный движок для авторизации ваших (любых) приложений. Можно было бы считать очередным-надцатым стандартом, если бы не одно, а точней, целых два НО:

https://www.cedarpolicy.com/en/integrations

Cedar УЖЕ используется в двух свежевышедших сервисах AWS Verified Access и Amazon Verified Permissions.

Так что очень стоит присмотреться и разобраться.

Примеры:

permit(
principal,
action == Action::"editPhoto",
resource
)
when {
principal.department == "HardwareEngineering"
&&
principal.jobLevel >= 5
}

forbid ( principal, action, resource )
unless {
context.authentication.usedMFA
};

#Cedar #security

​​AWS Console Private Access:

https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/console-private-access.html

With AWS Console Private Access, you can limit the use of the AWS Console to your trusted accounts from within your VPC and on-premises networks.

#AWS_Console

AWS Elastic Beanstalk:

▪️Классический дизайн
▪️Манёвренность
▪️Простота — сел и поехал!

#Beanstalk #пятничное

🚩 Issue #71 | 14 May 2023

▪️  App Mesh PrivateLink
▪️  Athena Apache Hudi 0.12.2
▪️  Aurora I/O-Optimized
▪️  Aurora MySQL and PostgreSQL Graviton3 based R7g instance family
▪️  Backup now supports User Notifications
▪️  CloudFront one-click security protections with WAF
▪️  CloudTrail Lake enhances query support for all Presto SQL SELECT functions
▪️  CodeWhisperer extension in JupyterLab and SageMaker Studio
▪️  Connect Contact Lens supervisor alerts on agent performance
▪️  Direct Connect in Atlanta Georgia and Lagos, Nigeria
▪️  EC2 I4g storage-optimized instances
▪️  ElastiCache for Redis enabling Cluster Mode configuration on existing clusters
▪️  EMR Serverless available in China Regions
▪️  Glue Crawler custom JDBC drivers
▪️  Glue large instance types | GA
▪️  IoT Core registry adds additional CloudFormation resource types
▪️  IoT SiteWise
      ▫️  auto compute aggregated asset property values 15-min intervals
      ▫️  enhances optimized storage in hot path data
▪️  IVS monitor the health of live streams with multiple hosts
▪️  Kinesis Data Firehose OpenSearch Service document ID
▪️  Lambda X-Ray tracing for SnapStart-enabled functions
▪️  Managed Service for Prometheus  +4 regions
▪️  Management Console Private Access | GA
▪️  Marketplace self-service listing feature for single AMI products
▪️  MemoryDB for Redis
      ▫️  IAM Authentication
      ▫️  Redis 7
      ▫️  simplifies creating new clusters in Console
▪️  Network Firewall ingress TLS inspection is now available in all regions
▪️  Open-Source Cedar language for access control
▪️  QuickSight
      ▫️  new scatterplot options
      ▫️  State Persistence + Bookmarks for embedded dashboards
      ▫️  VPC Connections via public APIs with Multi-AZ
▪️  RDS M6g and R6g database instances +4 regions
▪️  Redshift Data Sharing now available in China Regions
▪️  SageMaker
      ▫️  Autopilot training ML models with weights, +8 objective metrics
      ▫️  Canvas operationalize ML models in production
      ▫️  notebooks now support ml.p4d, ml.p4de and ml.inf1 instances
      ▫️  Serverless Inference Provisioned Concurrency
      ▫️  Studio CodeGuru Security plugin  | Preview
▪️  Service Management Connector provisioning with Terraform
▪️  SNS faster automatic deletion of unconfirmed subscriptions
▪️  Systems Manager optimize compute costs of the applications

​​Cloud Regions: AWS vs Azure vs Google vs Alibaba

В конце апреля 2023-го года у Google случился инцидент с его регионом в Париже (europe-west9-a):

https://status.cloud.google.com/incidents/dS9ps52MUnxQfyDGPfkY

Стоит обратить внимание на сухую строчку:

Incident began at 2023-04-25 19:00 and ended at 2023-05-10 15:38 (all times are US/Pacific).

Штоа!? Две недели!? Целый регион!?

AWS подразумевает под Region нечто устойчивое к самым суровым проблемам, когда это по дефолту 3 AZ, где каждая AZ это один или несколько датацентров, разнесённых географически для исключения одинаковых локальных проблем и с разными источниками питания. В то время как конкуренты трактуют регионы и их более расплывчато.

В результате на момент написания поста имеем следующую картинку.

AWS — 31 regions:

https://aws.amazon.com/about-aws/global-infrastructure/

Azure — 60+ regions, more than any other cloud provider:

https://azure.microsoft.com/en-us/explore/global-infrastructure
https://datacenters.microsoft.com/globe/explore (крутая анимация, когда такое же было у AWS 😐)

Google — 37 regions:

https://cloud.google.com/about/locations/

Alibaba — 28 regions:

https://www.alibabacloud.com/global-locations

Что ж, если будет выбирать человек без знания предмета, то AWS получается совсем не лидер, а так, "один из", после двух фаворитов — Azure и Google.

Однако при знании предмета никак не вяжется вышеописанный инцидент (постмортем ещё ждём) в Париже у Google.

Ответ прячется в отделе маркетинга, когда регионом можно назвать и наличие лишь одной зоны, либо когда эти зоны располагаются без таких строгих требований, как в AWS.

В результате, если покопаться в документации каждого из провайдеров, поставив условие, что регион — это больше, чем 1 зона, то получается совсем другая картина.

AWS — 31
Azure — 28:

https://learn.microsoft.com/en-us/azure/reliability/availability-zones-service-support#azure-regions-with-availability-zone-support

Google — 24:

https://www.google.com/about/datacenters/locations/

Alibaba — 22:

https://www.alibabacloud.com/help/en/basics-for-beginners/latest/regions-and-zones#section-uzg-00a-mki

В результате ситуация с Cloud Regions смотрится по-другому.

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

#AWS_Regions

В новом выпуске подкаста мы в глубину погрузились в мир данных вместе с нашим гостем @skurmanov (Samat Kurmanov) - AWS Community Builder
Во время обсуждения мы проследили историю появления аналитических хранилищ данных, включая эволюцию от классических Data Warehouses до Data Lakes и современных Lakehouses. Samat подробно разъяснил основные особенности каждого из этих подходов, их преимущества и слабые стороны, а также ситуации, в которых они проявляют себя наилучшим образом.

Послушать можно тут:

#podcast
Послушать можно тут:
- Apple Podcasts
- Google Podcasts
- Spotify
- PodBean
- YandexMusic

🧡 9 Things I Love About AWS — Corey Quinn

https://www.lastweekinaws.com/blog/9-Things-I-Love-About-AWS/

1️⃣ Employees take my questions seriously
2️⃣ APIs are considered promises
3️⃣ There are immutable boundaries between regions
4️⃣ Peter DeSantis gives delightful re:Invent talks
5️⃣ The AWS Training & Certification team knows its stuff
6️⃣ Your company’s spend is irrelevant
7️⃣ Products solve a real customer problem
8️⃣ Its deadly serious about security
9️⃣ AWS’s community

​​🎉 Terraform v1.5.0 + декларативный импорт ресурсов:

https://github.com/hashicorp/terraform/releases

Добавляется блок import, который содержит id и to аргументы. Выполнение terraform plan покажет, что будет импортировано. После импорта блок можно import удалить, но можно и оставить — он просто будет игнорироваться, если указанные айдишники уже есть в стэйте.

#Terraform