Первые впечатления о прошедшем re:Invent 2021
Честно говоря не так много ожидал от него и главное получил.
В первую очередь это, конечно, Graviton 3, о котором будет отдельный пост.
Во вторую, бэкап для S3 — очень уж его не хватало для полноты картины. Теперь набор бэкапов на AWS реально крут, спасибо команде AWS Backup (хотя вот я-то помню, что-то кто-то обещал ещё и для MS AD 😀 ).
В принципе всё. Новостей для Organizations не было — проехали, не привыкать.
Не оправдали ожидания AI Ops — выход DevOps Guru для RDS лишь под Aurora — сиротски смотрелся на этом фронте по сравнению с прошлыми реинвентами.
Буйство анонсов в ML (читай – SageMaker) ожидаемо. Интересно и важно ответить большое обновление на IoT фронте — обратите внимание, спустя некоторое время тема снова поднимается в топ и заслуженно.
Неожиданно для меня выход (а точней вход 😀 со стороны AWS) темы 5G — AWS Private 5G. Задним числом такое можно было бы спрогнозировать. Реально круто и стратегически правильно, снимаю шляпу!
Outposts 1U/2U — вообще круть. Жаль у нас такое не купить, но небольшим конторам получить себе личный кусок AWS в стойку за 600€/месяц (64vCPU/Graviton2/128GB) — просто сказка!
5 новых Serverless сервисов (Redshift/Kafka/EMR/Kinesis/SageMaker) — ожидаемо и круто, что тут скажешь. Несложно спрогнозировать, что это направление будет развиваться.
По части безопасности было также не так много, как предполагал. Всего два анонса — круто смотрящийся AWS Shield Advanced с прикрученными ML плюшками автоматической борьбы с вражеским трафиком. Плюс оживление Inspector без приставки v2, которую я добавил в своих постах, но смысл именно такой — сильно обновлённый. Ему прикрутили контейнеры (не прошло и...) плюс немало интересных штук по безопасности — нужно посмотреть-попробовать, чтобы вынести вердикт.
CDK v2 с monorepo и Construct Hub — форсили лишь для рекламы (как и в прошлый раз на реинвенте). Люди давно пользуются, но вдруг кто не знал — полезно.
Новые языки — Swift/Rust/Kotlin для AWS SDK — всё понятно, давно пора.
Сервисы для миграции продолжают плодиться — также ничего удивительного. Лишь отмечу в этом сегменте, вдруг не заметили — программу AWS Mainframe Modernization — для перевода ламповых COBOL и PL/I на современные рельсы.
В принципе и всё. Итого, с одной стороны — полсотни новых сервисов!
(Посчитать сервисы точно очень сложно, т.к. уже давно не очевидно, что нужно считать новым сервисом и можно ли к ним приравнивать новую фичу существующего сервиса, но весьма, важную, например. Потому тут достаточно субъективный подсчёт, в любом случае, это несколько десятков).
Например, чтобы сравнить — Яндекс.Облако на текущий момент имеет те же 50 сервисов.
С другой стороны — всё же, считаю реинвент итерационным. AWS Private 5G — это ах!, Graviton 3 — это ух! и всё. Инновации ждём в следующий раз.
Между тем, всё же, проявления кардинального изменения стратегии AWS на этом реинвенте были. Может, не всем заметные, но это факт. Однако об этом уже в следующий раз.
#reInvent
Честно говоря не так много ожидал от него и главное получил.
В первую очередь это, конечно, Graviton 3, о котором будет отдельный пост.
Во вторую, бэкап для S3 — очень уж его не хватало для полноты картины. Теперь набор бэкапов на AWS реально крут, спасибо команде AWS Backup (хотя вот я-то помню, что-то кто-то обещал ещё и для MS AD 😀 ).
В принципе всё. Новостей для Organizations не было — проехали, не привыкать.
Не оправдали ожидания AI Ops — выход DevOps Guru для RDS лишь под Aurora — сиротски смотрелся на этом фронте по сравнению с прошлыми реинвентами.
Буйство анонсов в ML (читай – SageMaker) ожидаемо. Интересно и важно ответить большое обновление на IoT фронте — обратите внимание, спустя некоторое время тема снова поднимается в топ и заслуженно.
Неожиданно для меня выход (а точней вход 😀 со стороны AWS) темы 5G — AWS Private 5G. Задним числом такое можно было бы спрогнозировать. Реально круто и стратегически правильно, снимаю шляпу!
Outposts 1U/2U — вообще круть. Жаль у нас такое не купить, но небольшим конторам получить себе личный кусок AWS в стойку за 600€/месяц (64vCPU/Graviton2/128GB) — просто сказка!
5 новых Serverless сервисов (Redshift/Kafka/EMR/Kinesis/SageMaker) — ожидаемо и круто, что тут скажешь. Несложно спрогнозировать, что это направление будет развиваться.
По части безопасности было также не так много, как предполагал. Всего два анонса — круто смотрящийся AWS Shield Advanced с прикрученными ML плюшками автоматической борьбы с вражеским трафиком. Плюс оживление Inspector без приставки v2, которую я добавил в своих постах, но смысл именно такой — сильно обновлённый. Ему прикрутили контейнеры (не прошло и...) плюс немало интересных штук по безопасности — нужно посмотреть-попробовать, чтобы вынести вердикт.
CDK v2 с monorepo и Construct Hub — форсили лишь для рекламы (как и в прошлый раз на реинвенте). Люди давно пользуются, но вдруг кто не знал — полезно.
Новые языки — Swift/Rust/Kotlin для AWS SDK — всё понятно, давно пора.
Сервисы для миграции продолжают плодиться — также ничего удивительного. Лишь отмечу в этом сегменте, вдруг не заметили — программу AWS Mainframe Modernization — для перевода ламповых COBOL и PL/I на современные рельсы.
В принципе и всё. Итого, с одной стороны — полсотни новых сервисов!
(Посчитать сервисы точно очень сложно, т.к. уже давно не очевидно, что нужно считать новым сервисом и можно ли к ним приравнивать новую фичу существующего сервиса, но весьма, важную, например. Потому тут достаточно субъективный подсчёт, в любом случае, это несколько десятков).
Например, чтобы сравнить — Яндекс.Облако на текущий момент имеет те же 50 сервисов.
С другой стороны — всё же, считаю реинвент итерационным. AWS Private 5G — это ах!, Graviton 3 — это ух! и всё. Инновации ждём в следующий раз.
Между тем, всё же, проявления кардинального изменения стратегии AWS на этом реинвенте были. Может, не всем заметные, но это факт. Однако об этом уже в следующий раз.
#reInvent
Бывает время, когда можно увидеть ресурсы, которые используют AWS в N.Virginia:
https://downdetector.com
Началось с падения консоли в N.Virginia, после стало ясно, что это не просто так.
https://status.aws.amazon.com/
https://downdetector.com
Началось с падения консоли в N.Virginia, после стало ясно, что это не просто так.
https://status.aws.amazon.com/
Таки снова сетевики (о вчерашнем падении консоли, а после и EC2, Connect, DynamoDB, Glue, Athena, Timestream, Chime и некоторые другие в
The root cause of this issue is an impairment of several network devices in the
https://status.aws.amazon.com/
Итого по времени недоступности/проблем, часов (примерно):
N.Virginia):The root cause of this issue is an impairment of several network devices in the
US-EAST-1 Region.https://status.aws.amazon.com/
Итого по времени недоступности/проблем, часов (примерно):
AWS Console 8
DynamoDB 7
AWS Support 7
Connect 9.5
AWS Batch 13
===
API requests 5.5-8
Что весьма много. В очередной раз посоветую прислушаться к рекомендациям Reliability Pillar → Multi-Region Scenarios. А пока ждём постмортем.Telegram
aws_notes
Бывает время, когда можно увидеть ресурсы, которые используют AWS в N.Virginia:
https://downdetector.com
Началось с падения консоли в N.Virginia, после стало ясно, что это не просто так.
https://status.aws.amazon.com/
https://downdetector.com
Началось с падения консоли в N.Virginia, после стало ясно, что это не просто так.
https://status.aws.amazon.com/
AWS Cloud WAN & Direct Connect SiteLink - короткое демо:
https://www.youtube.com/watch?v=ZJjrwI2L964
Не сильно подробное видео (16 минут) с реинвента, где было обсуждение деталей работы свежеанонсированных сервисов.
#CloudWAN #DirectConnectSiteLink
https://www.youtube.com/watch?v=ZJjrwI2L964
Не сильно подробное видео (16 минут) с реинвента, где было обсуждение деталей работы свежеанонсированных сервисов.
#CloudWAN #DirectConnectSiteLink
YouTube
AWS re:Invent 2021: AWS On Air ft. Cloud WAN & Direct Connect SiteLink | AWS Events
AWS On Air hosts Kunal Batra, Sr. Developer Advocate and Kris Howard, Mgr, Developer Relations EEM, Santiago Riesco, PM for Direct Connect SiteLink and Nick Matthews, PM for AWS Cloud WAN discuss how traffic goes from Direct Connect PoP to Direct Connect…
Well-Architected Framework — Sustainability Pillar:
https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html
Малозаметное и при этом принципиальное, на мой взгляд, событие произошло на re:Invent 2021. В наборе Well-Architected Framework появилась ещё одна, шестая по счёту, Pillar для обеспечения "устойчивости" окружения.
Невозможно точно перевести данный термин, проще (и даже правильней), если бы её назвали Green Pillar — в продолжение зелёных технологий, защиты окружающей среды, заботы о будущем планеты и прочих вещей в рамках «green transformation» тренда.
Для начала расскажу про "малозаметную" часть данной Pillar, а в следующем посте обсудим принципиальность.
Итак, кому будет лень читать про Sustainability Pillar, я всё прочитал и вот краткая выжимка рекомендаций оттуда:
▪️ Покупайте макбуки и айфоны
▪️ Выбирайте для ваших нагрузок AWS регионы с ветряками
▪️ Переписывайте всё на Rust
▪️ Кэшируйте
▪️ Удаляйте ненужные данные
▪️ Классифицируйте данные и используйте Lifecycles
▪️ Сжимайте данные перед отправкой
▪️ Создавайте ПО с обратной совместимостью версий, чтобы клиентам не нужно было покупать новые девайсы (и чтобы на старых хватало места)
▪️ Обновляйте библиотеки и другое ПО
▪️ Обновляйте ОС
▪️ Используйте Graviton, Spot и Burstable инстансы
▪️ Используйте managed сервисы (Амазона, понятно)
▪️ Используйте SSM и CloudShell вместо бастионов
Интересно отметить про обратную совместимость (типа – делай как я! – Amazon S3 имеет версию апишки от 2006-го года).
Ещё более интересно отметить про рекомендацию использовать Graviton (энергоэффективность), Spot (более эффективное расходование простаивающих ресурсов) и Burstable (аналогично). И если с энергоэффективностью Graviton понятно (при этом это правда 😀), то интересно отметить рекомендацию использовать споты и
Использование managed AWS сервисов – за вас уже позаботится обо всём (и во всех смыслах) сам Амазон, потому правильней выбирать именно их, т.к. самостоятельно добиться такой эффективности очень сложно.
Кратко и шуточно (при этом по делу) получится как-то так. Однако проблема глубокая и важная, потому достойна отдельного обсуждения, без деталей конкретных рекомендаций описанных сейчас.
#WellArchitectedFramework #Sustainability
https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html
Малозаметное и при этом принципиальное, на мой взгляд, событие произошло на re:Invent 2021. В наборе Well-Architected Framework появилась ещё одна, шестая по счёту, Pillar для обеспечения "устойчивости" окружения.
Невозможно точно перевести данный термин, проще (и даже правильней), если бы её назвали Green Pillar — в продолжение зелёных технологий, защиты окружающей среды, заботы о будущем планеты и прочих вещей в рамках «green transformation» тренда.
Для начала расскажу про "малозаметную" часть данной Pillar, а в следующем посте обсудим принципиальность.
Итак, кому будет лень читать про Sustainability Pillar, я всё прочитал и вот краткая выжимка рекомендаций оттуда:
▪️ Покупайте макбуки и айфоны
▪️ Выбирайте для ваших нагрузок AWS регионы с ветряками
▪️ Переписывайте всё на Rust
▪️ Кэшируйте
▪️ Удаляйте ненужные данные
▪️ Классифицируйте данные и используйте Lifecycles
▪️ Сжимайте данные перед отправкой
▪️ Создавайте ПО с обратной совместимостью версий, чтобы клиентам не нужно было покупать новые девайсы (и чтобы на старых хватало места)
▪️ Обновляйте библиотеки и другое ПО
▪️ Обновляйте ОС
▪️ Используйте Graviton, Spot и Burstable инстансы
▪️ Используйте managed сервисы (Амазона, понятно)
▪️ Используйте SSM и CloudShell вместо бастионов
Интересно отметить про обратную совместимость (типа – делай как я! – Amazon S3 имеет версию апишки от 2006-го года).
Ещё более интересно отметить про рекомендацию использовать Graviton (энергоэффективность), Spot (более эффективное расходование простаивающих ресурсов) и Burstable (аналогично). И если с энергоэффективностью Graviton понятно (при этом это правда 😀), то интересно отметить рекомендацию использовать споты и
T-инстансы — такого раньше не было.Использование managed AWS сервисов – за вас уже позаботится обо всём (и во всех смыслах) сам Амазон, потому правильней выбирать именно их, т.к. самостоятельно добиться такой эффективности очень сложно.
Кратко и шуточно (при этом по делу) получится как-то так. Однако проблема глубокая и важная, потому достойна отдельного обсуждения, без деталей конкретных рекомендаций описанных сейчас.
#WellArchitectedFramework #Sustainability
Sustainability Pillar как документальное проявление глобального тренда
Предположу, что не все разделяют "зелёный подход" и его важность. Важность в общем смысле влияния на окружающую среду или климат, а теперь и влияние на выбор ноутбуков для работников компании или типа используемых виртуалок.
У кого-то это может вызвать усмешку или даже раздражение. Лично я отношусь к этому – учёту собственного воздействия на окружающую среду и заботе о будущем планеты – серьёзно. Но главное, что к этому очень серьёзно относится сама Amazon.
Кто не в курсе, компания Amazon – один из мировых лидеров в продвижении и реализации идей заботы об окружающей среде, климата, возобновляемых источников энергии для IT отрасли и т.п. Инициативу Amazon под названием The Climate Pledge уже поддержало более 200 компаний:
https://sustainability.aboutamazon.com/about/the-climate-pledge
Стоит полистать, чтобы понять, как крупнейшие компании мира берут на себя обязательства, которые затратны по определению и при этом являются долгосрочными. Это новое, революционное изменение. Ранее не всем очевидное, а теперь уже в составе конкретных рекомендаций по выбору архитектуры новых проектов и процесса улучшения имеющихся. Чтобы учитывать собственное воздействие, чтобы минимизировать ущерб, повысить эффективность, а при этом сделать архитектуру грамотней, инфраструктуру надёжней и при этом экономичней.
И раньше, до появления Sustainability Pillar это правильно было делать и так делали. Однако какие-то моменты требовали слишком больших вложений, которые никогда не окупились бы, потому проще было (и есть) платить больше.
С одной стороны – это прямая выгода для AWS, когда у него есть миллионы спонсоров, которые платят за годами неиспользуемые прожорливые виртуалки, забытые диски, бессмысленные логи, никому не нужные снэпшоты.
С другой стороны – это неэффективное расходование средств (даже если это ваши средства, дающие прибыль), увеличение потребления электроэнергии без полезной нагрузки в общем смысле этого слова, генерация бессмысленного паразитного трафика (при этом весьма недешёвого для клиентов) и дальнейшее умножение облачной энтропии.
Теперь настал этап, когда продавец товара, продавец сервиса, который искренне заинтересован в более общих и для кого-то абстрактных вещах, чем просто прибыль, которой многие по привычке объясняют всё и вся – теперь провайдеры сервиса хотят, чтобы их потребители использовали имеющееся максимально эффективно. Если не работает стимул для себя (мне, как клиенту, проще и выгодней заплатить), то возможно сработает момент ответственности за будущее.
И по моему мнению он сработает. Он уже работает для Amazon и появление Sustainability Pillar ровно этому доказательство. Сейчас это рекомендации, как вам заботиться о себе же в виде эффективности используемых ресурсов, в виде документации по способу разработки архитектуры. Рекомендации в виде подсказок в различных сервисах, в том числе платных, т.к. они позволяют существенно сэкономить.
Потом этом могут быть всё более навязчивые (в хорошем смысле 😀) и бесплатные сервисы по контролю за ресурсами с автоматическим удалением/остановкой. Такая себе кнопка "Проверить всё и удалить ненужное".
Подведя итог, хочу ещё раз отметить важность этого малозаметного события. Обратите внимание на должности разработчиков документа Sustainability Pillar:
▫️ VP Sustainability Architecture
▫️ Principal Sustainability Solutions Architect
▫️ Sustainability Tech Leader
Так что всё очень серьёзно. И потому, если вы работаете в компаниях-проектах, руководство которых разделяет Sustainability подход, возможно в числе тех сотен подписавшихся – смело можете теперь форсить переход на Serverless архитектуру, отвечая на дурацкие вопросы типа "Зачем? Что это нам даст?" гордым «Чтобы бороться с потеплением!» 😁
#Sustainability
Предположу, что не все разделяют "зелёный подход" и его важность. Важность в общем смысле влияния на окружающую среду или климат, а теперь и влияние на выбор ноутбуков для работников компании или типа используемых виртуалок.
У кого-то это может вызвать усмешку или даже раздражение. Лично я отношусь к этому – учёту собственного воздействия на окружающую среду и заботе о будущем планеты – серьёзно. Но главное, что к этому очень серьёзно относится сама Amazon.
Кто не в курсе, компания Amazon – один из мировых лидеров в продвижении и реализации идей заботы об окружающей среде, климата, возобновляемых источников энергии для IT отрасли и т.п. Инициативу Amazon под названием The Climate Pledge уже поддержало более 200 компаний:
https://sustainability.aboutamazon.com/about/the-climate-pledge
Стоит полистать, чтобы понять, как крупнейшие компании мира берут на себя обязательства, которые затратны по определению и при этом являются долгосрочными. Это новое, революционное изменение. Ранее не всем очевидное, а теперь уже в составе конкретных рекомендаций по выбору архитектуры новых проектов и процесса улучшения имеющихся. Чтобы учитывать собственное воздействие, чтобы минимизировать ущерб, повысить эффективность, а при этом сделать архитектуру грамотней, инфраструктуру надёжней и при этом экономичней.
И раньше, до появления Sustainability Pillar это правильно было делать и так делали. Однако какие-то моменты требовали слишком больших вложений, которые никогда не окупились бы, потому проще было (и есть) платить больше.
С одной стороны – это прямая выгода для AWS, когда у него есть миллионы спонсоров, которые платят за годами неиспользуемые прожорливые виртуалки, забытые диски, бессмысленные логи, никому не нужные снэпшоты.
С другой стороны – это неэффективное расходование средств (даже если это ваши средства, дающие прибыль), увеличение потребления электроэнергии без полезной нагрузки в общем смысле этого слова, генерация бессмысленного паразитного трафика (при этом весьма недешёвого для клиентов) и дальнейшее умножение облачной энтропии.
Теперь настал этап, когда продавец товара, продавец сервиса, который искренне заинтересован в более общих и для кого-то абстрактных вещах, чем просто прибыль, которой многие по привычке объясняют всё и вся – теперь провайдеры сервиса хотят, чтобы их потребители использовали имеющееся максимально эффективно. Если не работает стимул для себя (мне, как клиенту, проще и выгодней заплатить), то возможно сработает момент ответственности за будущее.
И по моему мнению он сработает. Он уже работает для Amazon и появление Sustainability Pillar ровно этому доказательство. Сейчас это рекомендации, как вам заботиться о себе же в виде эффективности используемых ресурсов, в виде документации по способу разработки архитектуры. Рекомендации в виде подсказок в различных сервисах, в том числе платных, т.к. они позволяют существенно сэкономить.
Потом этом могут быть всё более навязчивые (в хорошем смысле 😀) и бесплатные сервисы по контролю за ресурсами с автоматическим удалением/остановкой. Такая себе кнопка "Проверить всё и удалить ненужное".
Подведя итог, хочу ещё раз отметить важность этого малозаметного события. Обратите внимание на должности разработчиков документа Sustainability Pillar:
▫️ VP Sustainability Architecture
▫️ Principal Sustainability Solutions Architect
▫️ Sustainability Tech Leader
Так что всё очень серьёзно. И потому, если вы работаете в компаниях-проектах, руководство которых разделяет Sustainability подход, возможно в числе тех сотен подписавшихся – смело можете теперь форсить переход на Serverless архитектуру, отвечая на дурацкие вопросы типа "Зачем? Что это нам даст?" гордым «Чтобы бороться с потеплением!» 😁
#Sustainability
Theclimatepledge
Be the planet’s turning point
There’s no time for business as usual. Join the world’s top companies—and take action now to reach net-zero carbon emissions by 2040.
Подробный постмортем падения AWS на несколько часов 7 декабря 2021:
https://aws.amazon.com/message/12721/
Кому нужна выжимка:
• Проблема была во внутренней сети AWS, где крутятся мониторинг и control plain некоторых сервисов. Поэтому сами сервисы не падали, но невозможно было внести изменения, что для некоторых сервисов, например, API Gateway оказалось равным проблемам его работоспособности (делается фикс такого поведения).
• Задержка с отображением проблем на странице статуса в том числе связана с недоступностью мониторинга в результате падения внутренней сети. Так как инженеры AWS долгое время не могли узнать (без мониторинга), что на самом деле происходит.
• Интересно отметить, что причиной послужил код, который уже несколько лет успешно крутится в проде, просто его поведение, когда он масштабируется, не было оттестировано (теперь протестировали – нет, не работает). Автоскелинг выключили, мощности хватает, как дотестируют, включат автоскелинг обратно (может быть).
Дополнительно отмечу для себя интересный факт, что S3 и DynamoDB ресурсы, которые, как и другие, не страдали во время инцидента, однако вот те, что подключены через VPC Endpoint – были недоступны. Причём, как понимаю (чего нет в постмортеме) – речь именно о (бесплатных) Gateway VPC Endpoints, в то время как (платные) Interface endpoints – не пострадали.
Итого: приятно читать столь детальный отчёт, проливающий свет на внутреннюю кухню AWS.
#postmortem
https://aws.amazon.com/message/12721/
Кому нужна выжимка:
• Проблема была во внутренней сети AWS, где крутятся мониторинг и control plain некоторых сервисов. Поэтому сами сервисы не падали, но невозможно было внести изменения, что для некоторых сервисов, например, API Gateway оказалось равным проблемам его работоспособности (делается фикс такого поведения).
• Задержка с отображением проблем на странице статуса в том числе связана с недоступностью мониторинга в результате падения внутренней сети. Так как инженеры AWS долгое время не могли узнать (без мониторинга), что на самом деле происходит.
• Интересно отметить, что причиной послужил код, который уже несколько лет успешно крутится в проде, просто его поведение, когда он масштабируется, не было оттестировано (теперь протестировали – нет, не работает). Автоскелинг выключили, мощности хватает, как дотестируют, включат автоскелинг обратно (может быть).
Дополнительно отмечу для себя интересный факт, что S3 и DynamoDB ресурсы, которые, как и другие, не страдали во время инцидента, однако вот те, что подключены через VPC Endpoint – были недоступны. Причём, как понимаю (чего нет в постмортеме) – речь именно о (бесплатных) Gateway VPC Endpoints, в то время как (платные) Interface endpoints – не пострадали.
Итого: приятно читать столь детальный отчёт, проливающий свет на внутреннюю кухню AWS.
We want to apologize for the impact this event caused for our customers. While we are proud of our track record of availability, we know how critical our services are to our customers, their applications and end users, and their businesses. We know this event impacted many customers in significant ways. We will do everything we can to learn from this event and use it to improve our availability even further.#postmortem
Amazon
Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region
Уязвимость Apache Log4j2 (
https://aws.amazon.com/security/security-bulletins/AWS-2021-005/
▫️ Amazon Linux 1 —
▫️ Amazon Linux 2 —
▫️ Amazon Linux 2022 (preview) — fixed
▫️ AWS WAF / Shield —
Защита от
▫️ CloudFront, ALB, AppSync или API Gateway можно защитить с помощью WAF у которого включён
▫️ OpenSearch Service — все ресурсы в процессе обновления на защищённую версию (не требует действий).
▫️ Lambda — не использует Log4j2 в AWS managed runtimes и образах. Однако пользователи, использующие aws-lambda-java-log4j2 должны обновиться на версию
▫️ AWS CloudHSM — требуется обновить CloudHSM JCE SDK до версии 3.4.1. Версии SDK 3.4.0 и древнее подвержены уязвимости
#security
CVE-2021-44228) и сервисы AWS:https://aws.amazon.com/security/security-bulletins/AWS-2021-005/
▫️ Amazon Linux 1 —
OK▫️ Amazon Linux 2 —
OK▫️ Amazon Linux 2022 (preview) — fixed
▫️ AWS WAF / Shield —
updatedЗащита от
CVE-2021-44228 добавлена в AWS managed rule AWSManagedRulesKnownBadInputsRuleSet.▫️ CloudFront, ALB, AppSync или API Gateway можно защитить с помощью WAF у которого включён
AWSManagedRulesKnownBadInputsRuleSet.▫️ OpenSearch Service — все ресурсы в процессе обновления на защищённую версию (не требует действий).
▫️ Lambda — не использует Log4j2 в AWS managed runtimes и образах. Однако пользователи, использующие aws-lambda-java-log4j2 должны обновиться на версию
1.3.0 и передеплоить свои Лямбды.▫️ AWS CloudHSM — требуется обновить CloudHSM JCE SDK до версии 3.4.1. Версии SDK 3.4.0 и древнее подвержены уязвимости
CVE-2021-44228.#security
Amazon
Apache Log4j2 Security Bulletin (CVE-2021-44228)
Weekly Summary on AWS (December
🔹 AppSync + custom domain names for AppSync GraphQL endpoints
🔹 Route 53 + DeleteDomain (it was only in the AWS Console before) and ListPrices
🔹 SSM + maximum session timeout and annotate reason for starting the session
🔹 EKS + new EBS CSI add-on 👍
🔹 AWS Network Firewall + AWS Managed Rules
🔹 Redshift + single-node RA3.xlplus cluster
🔹 AWS Toolkit for VS Code + Amazon ECS Exec
🔹 App2Container + .NET on Linux
🔹 FSx for NetApp ONTAP
• Data compression for capacity pool storage
• Minimum throughput capacity is now 128 MB/s
🔹 Amazon Location Service
• Suggestions API (autocomplete)
• Metadata
🔹 Comprehend Medical
• SNOMED CT API
• Reduced pricing across all APIs by up to 90%
🔹 Amazon Pinpoint + one-time password
🔹 AWS WAF + logs directly to S3 bucket
🔹 CloudFormation
• AWS::FSx::FileSystem
• AWS::Lex::Bot
• AWS::Lex::BotAlias
• AWS::Lex::BotVersion
• AWS::Lex::ResourcePolicy
🔸 AWS Wavelength + Germany
#AWS_week
5-11)🔹 AppSync + custom domain names for AppSync GraphQL endpoints
🔹 Route 53 + DeleteDomain (it was only in the AWS Console before) and ListPrices
🔹 SSM + maximum session timeout and annotate reason for starting the session
🔹 EKS + new EBS CSI add-on 👍
🔹 AWS Network Firewall + AWS Managed Rules
🔹 Redshift + single-node RA3.xlplus cluster
🔹 AWS Toolkit for VS Code + Amazon ECS Exec
🔹 App2Container + .NET on Linux
🔹 FSx for NetApp ONTAP
• Data compression for capacity pool storage
• Minimum throughput capacity is now 128 MB/s
🔹 Amazon Location Service
• Suggestions API (autocomplete)
• Metadata
🔹 Comprehend Medical
• SNOMED CT API
• Reduced pricing across all APIs by up to 90%
🔹 Amazon Pinpoint + one-time password
🔹 AWS WAF + logs directly to S3 bucket
🔹 CloudFormation
• AWS::FSx::FileSystem
• AWS::Lex::Bot
• AWS::Lex::BotAlias
• AWS::Lex::BotVersion
• AWS::Lex::ResourcePolicy
🔸 AWS Wavelength + Germany
#AWS_week
Forwarded from Человек и машина
#машины_aws
Чем дилетанты отличаются от неудачников:
- Дилетанты осознают свои возможности и учатся
- Неудачники улюлюкают и устраивают клоунаду в Твиттере
Очевидно, дилетантам надо помогать и наставлять, а неудачников гнать и насмехаться.
Понедельничное чтиво для моих любимых дилетантов : мой набор трюков, как не тратить лишних денег на AWS.
Чем дилетанты отличаются от неудачников:
- Дилетанты осознают свои возможности и учатся
- Неудачники улюлюкают и устраивают клоунаду в Твиттере
Очевидно, дилетантам надо помогать и наставлять, а неудачников гнать и насмехаться.
Понедельничное чтиво для моих любимых дилетантов : мой набор трюков, как не тратить лишних денег на AWS.
Medium
Easy way to save money on AWS
Unless you like overspending
Update V2 (новая версия отчёта
https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
▫️ S3 —
▫️ OpenSearch —
▫️ Lambda —
▪️ AWS CloudHSM — требуется обновить CloudHSM JCE SDK до версии 3.4.1. Версии SDK 3.4.0 и древнее подвержены уязвимости
▫️ EC2 - Amazon Linux 1/2 —
▫️ API Gateway —
▪️ AWS Greengrass — нужно обновить Stream Manager до версии 2.0.14+ (1.10.5+ для версий 1.10.х и 1.11.5 для версий 1.11.х) и Secure Tunneling до версии 1.0.6+.
▫️ CloudFront —
▫️ Beanstalk —
▫️ EMR —
▫️ Lake Formation —
▫️ AWS SDK for Java —
▫️ AMS (AWS Managed Services) —
▫️ Amazon Neptune —
▪️ NICE DCV — серверы требуют апгрейда на новую версию EnginFrame, либо обновления библиотеки Log4j2 отдельно через саппорт.
▫️ Kafka —
▫️ AWS Glue —
▫️ RDS —
▫️ Amazon Connect —
▫️ DynamoDB —
▫️ Keyspaces (Cassandra) —
▫️ Amazon MQ —
▫️ Kinesis Data Analytics —
▫️ AWS WAF / Shield —
▫️ ALB и AppSync можно защитить с помощью WAF у которого включён
#security
2021/12/13) — Уязвимость Apache Log4j2 (CVE-2021-44228) и сервисы AWS:https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
▫️ S3 —
completed patching everything.▫️ OpenSearch —
is deploying update R20211203-P2.▫️ Lambda —
OK, не пострадала, лишь пользователи, aws-lambda-java-log4j2 должны обновиться на версию 1.3.0 и пересоздать свои Лямбды.▪️ AWS CloudHSM — требуется обновить CloudHSM JCE SDK до версии 3.4.1. Версии SDK 3.4.0 и древнее подвержены уязвимости
CVE-2021-44228.▫️ EC2 - Amazon Linux 1/2 —
OK, Amazon Linux 2022 - fixed▫️ API Gateway —
is updating (не требует действий)▪️ AWS Greengrass — нужно обновить Stream Manager до версии 2.0.14+ (1.10.5+ для версий 1.10.х и 1.11.5 для версий 1.11.х) и Secure Tunneling до версии 1.0.6+.
▫️ CloudFront —
updated. Обработка запросов не на Java, потому не пострадала.▫️ Beanstalk —
OK. Аналогично EC2, для дефолтных настроек Amazon Linux 1/2 — OK. Если же ставились свои версии, то нужно обновить самостоятельно.▫️ EMR —
OK, при запуске в дефолтной конфигурации не пострадал. Кластеры версий EMR 5/6 с разрешением для недоверенных источников — подвержены уязвимости. Патч в процессе создания.▫️ Lake Formation —
updated.▫️ AWS SDK for Java —
OK.▫️ AMS (AWS Managed Services) —
OK, сервис относится к инфраструктуре заказчиков, а не приложений. Потому для своих приложений, подвержённых уязвимости — их нужно обновить самостоятельно.▫️ Amazon Neptune —
OK, напрямую не использует Log4j2, потому пользователи кластеров не пострадали. Однако некоторые зависимости используют, потому все кластеры будут обновлены (автоматически, не требует действий).▪️ NICE DCV — серверы требуют апгрейда на новую версию EnginFrame, либо обновления библиотеки Log4j2 отдельно через саппорт.
▫️ Kafka —
OK, текущие версии MSK кластеров не используют проблемную версию Log4j2. Некоторые компоненты MSK обновляются по ходу.▫️ AWS Glue —
updated. При использовании не дефолтных конфигов — требуется обновить скрипты самостоятельно.▫️ RDS —
OK, базы не используют Log4j2. Сами сервисы под капотом могут использовать, обновляются автоматически (действий не требуется).▫️ Amazon Connect —
updated.▫️ DynamoDB —
updated.▫️ Keyspaces (Cassandra) —
updated.▫️ Amazon MQ —
updated.▫️ Kinesis Data Analytics —
is updating (новое уже пропатченное, обновить можно через UpdateApplication API).▫️ AWS WAF / Shield —
updated.▫️ ALB и AppSync можно защитить с помощью WAF у которого включён
AWSManagedRulesKnownBadInputsRuleSet.#security
👍1
Через полчаса начнётся вебинар, посвященный возможностям AWS в области AI/ML:
https://aws.softline.com/events/rabota-s-dannymi-v-oblake-amazon-web-services-na-i
https://aws.softline.com/events/rabota-s-dannymi-v-oblake-amazon-web-services-na-i
Открыт новый AWS Region — Джакарта, Индонезия :
https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-jakarta-region/
Третий на текущий момент в Asia Pacific:
Итого на теперь всего — 26 регионов.
#AWS_Regions
https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-jakarta-region/
Третий на текущий момент в Asia Pacific:
ap-southeast-3.Итого на теперь всего — 26 регионов.
#AWS_Regions
Amazon
Now Open – AWS Asia Pacific (Jakarta) Region | Amazon Web Services
The AWS Region in Jakarta, Indonesia, is now open and you can start using it today. The official name is Asia Pacific (Jakarta) and the API name is ap-southeast-3. The AWS Asia Pacific (Jakarta) Region is the tenth active AWS Region in Asia Pacific and mainland…
Почему НУЖНО использовать CloudFormation:
https://www.cloudar.be/awsblog/do-use-aws-cloudformation/
Наш ответ Чемберлену Статья-ответ на «Почему НЕ нужно использовать CloudFormation». Аргументированная позиция с очевидным выводом – плюсы и минусы есть у обоих и выбирать стоит под задачу.
#CloudFormation #Terraform
https://www.cloudar.be/awsblog/do-use-aws-cloudformation/
#CloudFormation #Terraform
Update V4 (новая версия отчёта
https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
Отличия по сравнению с предыдущими версиями отчёта:
▫️ Step Functions —
▫️ SWF (Simple Workflow Service) —
▫️ SNS —
▫️ OpenSearch Service —
▫️ MemoryDB for Redis —
▫️ MWAA (Airflow) —
▪️ Kinesis Data Streams —
▪️ IoT SiteWise Edge —
▫️ ElastiCache —
▫️ API Gateway —
▫️ Directory Service —
▫️ Redshift —
▫️ KMS —
▫️ Cloud Directory —
▫️ RDS Oracle —
▫️ Single Sign-On —
▫️ Secrets Manager —
▫️ CloudWatch —
▫️ DocumentDB —
▫️ Timestream —
▪️ WorkSpaces/AppStream 2.0 — свежие версии не подвержены уязвимости. Если WorkDocs Sync клиент не обновлялся давно — обновить до версии 1.2.905.1+ самостоятельно.
▫️ Inspector v1 (Classic) —
▫️ Inspector v2 —
▪️ Kinesis —
#security
2021/12/15) — Уязвимость Apache Log4j2 (CVE-2021-44228) и сервисы AWS:https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
Отличия по сравнению с предыдущими версиями отчёта:
▫️ Step Functions —
updated.▫️ SWF (Simple Workflow Service) —
updated.▫️ SNS —
patched (внешняя часть, для пользователей), внутреняя (подкапотная) — in progress.▫️ OpenSearch Service —
ready патч R20211203-P2 готов и висит в консоли, его можно применить самостоятельно либо он вскоре применится автоматически.▫️ MemoryDB for Redis —
updated.▫️ MWAA (Airflow) —
updated.▪️ Kinesis Data Streams —
is updating. KCL (Kinesis Client Library) 2.x не имеет проблем, всем использующим KCL 1.x нужно обновиться на 1.14.5+ самостоятельно.▪️ IoT SiteWise Edge —
ready патченые версии OPC-UA collector (v2.0.3), Data processing pack (v2.0.14) и Publisher (v2.0.2) нужно задеплоить на свои ресурсы самостоятельно.▫️ ElastiCache —
updated.▫️ API Gateway —
updated.▫️ Directory Service —
updated.▫️ Redshift —
updated.▫️ KMS —
updated.▫️ Cloud Directory —
updated.▫️ RDS Oracle —
updated.▫️ Single Sign-On —
updated.▫️ Secrets Manager —
updated.▫️ CloudWatch —
updated.▫️ DocumentDB —
updated.▫️ Timestream —
updated.▪️ WorkSpaces/AppStream 2.0 — свежие версии не подвержены уязвимости. Если WorkDocs Sync клиент не обновлялся давно — обновить до версии 1.2.905.1+ самостоятельно.
▫️ Inspector v1 (Classic) —
updated. И теперь Inspector Classic умеет определять уязвимость CVE-2021-44228 (Log4Shell) в различных линуксах.▫️ Inspector v2 —
updated. И теперь Inspector v2 умеет определять уязвимости CVE-2021-44228 (Log4Shell) и IN1-JAVA-ORGAPACHELOGGINGLOG4J-2314720 - org.apache.logging.log4j:log4j-core в различных линуксах и ECR образах.▪️ Kinesis —
ready нужно установить новую версию агента самостоятельно!#security
Сервисы AWS активно обновляются для устранения уязвимости Log4j2. На текущий момент уже около 70 отчиталось об окончании работ по апдейту
https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
Кому важно следить за процессом, сделал
табличку с сортировкой сервисов по алфавиту. На картинке краткая версия, ссылка на полную версию документа:
https://docs.google.com/spreadsheets/d/1y6KPvRNZkHNADvL1dQJQyXlz_Z4OeKM2ONUkS12xEO0/edit?usp=sharing
#security
CVE-2021-44228.https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
Кому важно следить за процессом, сделал
табличку с сортировкой сервисов по алфавиту. На картинке краткая версия, ссылка на полную версию документа:
https://docs.google.com/spreadsheets/d/1y6KPvRNZkHNADvL1dQJQyXlz_Z4OeKM2ONUkS12xEO0/edit?usp=sharing
#security
Using AWS security services to protect against, detect, and respond to the Log4j vulnerability:
https://aws.amazon.com/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/
Protect:
🔸 WAF (Web Application Firewall)
🔸 Route 53 Resolver DNS Firewall
🔸 Network Firewall
🔸 EC2 IMDSv2
Detect:
🔸 Inspector
🔸 GuardDuty
🔸 Security Hub
🔸 VPC flow logs
Respond:
🔸 SSM Patch Manager
🔹 Container mitigation
🔹 Mitigation strategies
▪️ remove the JndiLookup class from the classpath:
▪️ https://logging.apache.org/log4j/2.x/
#security
https://aws.amazon.com/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/
Protect:
🔸 WAF (Web Application Firewall)
🔸 Route 53 Resolver DNS Firewall
🔸 Network Firewall
🔸 EC2 IMDSv2
Detect:
🔸 Inspector
🔸 GuardDuty
🔸 Security Hub
🔸 VPC flow logs
Respond:
🔸 SSM Patch Manager
🔹 Container mitigation
🔹 Mitigation strategies
▪️ remove the JndiLookup class from the classpath:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class▪️ https://logging.apache.org/log4j/2.x/
#security
Weekly Summary on AWS (December
Log4j2 CVE-2021-44228 related updates
▪️ WAF + AWSManagedRulesKnownBadInputsRuleSet updated with Log4JRCE protection support
Multiple versions during this week.
• Added the rule
• Released version 1.3 of
• Released version 1.4 of the rule
• Released version 1.5 to tune the matching criteria.
• Released version 1.8 of the rule
▪️ IoT Greengrass Core
• 1.11.5 — to fix Log4j for
• 1.10.5 — to fix Log4j for
▪️ IoT SiteWise
• OPC-UA collector 2.0.3 with Log4j fix
• Data processing pack 2.0.14 with Log4j fix
• Publisher 2.0.2 with Log4j fix
▪️ CloudHSM — CloudHSM JCE SDK version 3.4.2 — with Log4j updated to version 2.16.0.
▪️ Amazon Linux — Hotpatch for Apache Log4j
▪️ EMR — Approach to mitigate CVE-2021-44228
▪️ Kinesis — Amazon Kinesis Agent v2.0.4 with log4j 2.16.0
▪️ Lambda —
▪️ NICE — EnginFrame update instruction with Log4j fix
Other updates
🔹 Amazon Detective + Organizations
🔸 New! AWS Region — Jakarta, Indonesia
#AWS_week
12-18)Log4j2 CVE-2021-44228 related updates
▪️ WAF + AWSManagedRulesKnownBadInputsRuleSet updated with Log4JRCE protection support
Multiple versions during this week.
• Added the rule
Log4JRCE version 1.2 in response to the recently disclosed security issue within Log4j. For information see CVE-2021-44228. This rule inspects common URI paths, query strings, the first 8KB of the request body, and common headers. The rule uses double URL_DECODE_UNI text transformations.• Released version 1.3 of
Log4JRCE to tune the matching criteria and to inspect additional headers.• Released version 1.4 of the rule
Log4JRCE to tune the matching criteria and to inspect additional headers.• Released version 1.5 to tune the matching criteria.
• Released version 1.8 of the rule
Log4JRCE to improve header inspection and matching criteria. ▪️ IoT Greengrass Core
• 1.11.5 — to fix Log4j for
1.11.x versions• 1.10.5 — to fix Log4j for
1.10.x versions▪️ IoT SiteWise
• OPC-UA collector 2.0.3 with Log4j fix
• Data processing pack 2.0.14 with Log4j fix
• Publisher 2.0.2 with Log4j fix
▪️ CloudHSM — CloudHSM JCE SDK version 3.4.2 — with Log4j updated to version 2.16.0.
▪️ Amazon Linux — Hotpatch for Apache Log4j
yum install log4j-cve-2021-44228-hotpatch▪️ EMR — Approach to mitigate CVE-2021-44228
▪️ Kinesis — Amazon Kinesis Agent v2.0.4 with log4j 2.16.0
▪️ Lambda —
aws-lambda-java-log4j2 library v1.4.0 with Log4j fix ▪️ NICE — EnginFrame update instruction with Log4j fix
Other updates
🔹 Amazon Detective + Organizations
🔸 New! AWS Region — Jakarta, Indonesia
#AWS_week
Патч для Amazon Linux 1/2 рекомендуемый:
Amazon Linux 1 (AL1) and Amazon Linux 2 (AL2) by default use a log4j version that is not affected by CVE-2021-44228 or CVE-2021-45046. However, customers may be running their own log4j version on AL1 or AL2. To help customers who are running a JDK8, JDK11, JDK15, or JDK17 Java Virtual Machine (JVM) mitigate CVE-2021-44228 or CVE-2021-45046, Amazon Linux released a new package that includes the recently announced Hotpatch for Apache Log4j. Customers that bring their own log4j version can install this package by running yum install log4j-cve-2021-44228-hotpatch.