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.Новые фичи CloudFormation и CDK:
https://www.youtube.com/watch?v=PVW8TRvmHhU
#CloudFormation #CDK #reInvent #video
https://www.youtube.com/watch?v=PVW8TRvmHhU
#CloudFormation #CDK #reInvent #video
YouTube
AWS re:Invent 2021 - What's new with AWS CloudFormation and AWS CDK
Join this session to learn about new features to up-level your infrastructure-as-code (IaC) experiences on AWS. It covers working with AWS CloudFormation modules and AWS CDK constructs to make working with AWS easier; CloudFormation registry and Construct…
Очередная, уже третья за последнюю неделю уязвимость Log4j
https://logging.apache.org/log4j/2.x/security.html
В результате потребуется обновление до Log4j 2.17.0. и это значит, что все репорты по решению проблемы с обновлением до Log4j 2.16 придётся повторить.
Лучи поддержки всем, кому и так приходится сейчас тяжело из-за срочных обновлений, так ещё и во второй (или более) раз.
Хронология уязвимостей Log4j:
•
•
•
#security
CVE-2021-45105:https://logging.apache.org/log4j/2.x/security.html
В результате потребуется обновление до Log4j 2.17.0. и это значит, что все репорты по решению проблемы с обновлением до Log4j 2.16 придётся повторить.
Лучи поддержки всем, кому и так приходится сейчас тяжело из-за срочных обновлений, так ещё и во второй (или более) раз.
Хронология уязвимостей Log4j:
•
10 декабря CVE-2021-44228 - исправлена в 2.15.0•
11 декабря CVE-2021-45046 - исправлена в 2.16.0•
16 декабря CVE-2021-45105 - исправлена в 2.17.0#security
Telegram
aws_notes
Weekly Summary on AWS (December 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…
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…
Advanced Amazon VPC design and new capabilities:
https://www.youtube.com/watch?v=fi3vcenH6UY
🔸 VPC networking overview
🔸 IPv6 only subnets
🔸 DNS64
🔸 NAT64
🔸 Resource-based instance naming
🔸 IPv6 targets for ALB/NLB
🔸 IPAM (IP Address Manager)
🔸 VPC enhanced routing
🔸 Private NATGW
🔸 S3 Interface Endpoint
🔸 PrivateLink: ALB + NLB integration
🔸 TGW Connect
🔸 TGW intra-region peering
🔸 Direct Connect overview
🔸 Direct Connect MACsec
🔸 Direct Connect + Local Zones
🔸 Direct Connect SiteLink
🔸 AWS Cloud WAN
🔸 Network Access Analyzer
🔸 VPC Reachability Analyzer
#VPC #TGW #IPv6 #reInvent #video
https://www.youtube.com/watch?v=fi3vcenH6UY
🔸 VPC networking overview
🔸 IPv6 only subnets
🔸 DNS64
🔸 NAT64
🔸 Resource-based instance naming
🔸 IPv6 targets for ALB/NLB
🔸 IPAM (IP Address Manager)
🔸 VPC enhanced routing
🔸 Private NATGW
🔸 S3 Interface Endpoint
🔸 PrivateLink: ALB + NLB integration
🔸 TGW Connect
🔸 TGW intra-region peering
🔸 Direct Connect overview
🔸 Direct Connect MACsec
🔸 Direct Connect + Local Zones
🔸 Direct Connect SiteLink
🔸 AWS Cloud WAN
🔸 Network Access Analyzer
🔸 VPC Reachability Analyzer
#VPC #TGW #IPv6 #reInvent #video
YouTube
AWS re:Invent 2021 - Advanced Amazon VPC design and new capabilities
Amazon VPC gives you complete control over your AWS virtual networking environment. Have you ever wondered how new Amazon VPC features affect the way you design your AWS networking infrastructure or change existing architectures that you use today? This session…
Forwarded from Около DevOps
https://aws.amazon.com/blogs/aws/amazon-kinesis-data-streams-on-demand-stream-data-at-scale-without-managing-capacity/
Интересная фича на ReInvent’е была анонсирована, теперь можно датастримы переключить с режима Provisioned ранее единственно возможного, который поднимает кластер и работает в нем постоянно, вне зависимости от того, шлешь ты эти данные через стрим или нет в текущий момент, платить все равно придется, на OnDemand, который позволяет включить автоскейлинг данного кластера в зависимости от потребляемых ресурсов
Интересная фича на ReInvent’е была анонсирована, теперь можно датастримы переключить с режима Provisioned ранее единственно возможного, который поднимает кластер и работает в нем постоянно, вне зависимости от того, шлешь ты эти данные через стрим или нет в текущий момент, платить все равно придется, на OnDemand, который позволяет включить автоскейлинг данного кластера в зависимости от потребляемых ресурсов
Amazon
Amazon Kinesis Data Streams On-Demand – Stream Data at Scale Without Managing Capacity | Amazon Web Services
Today we are launching Amazon Kinesis Data Streams On-demand, a new capacity mode. This capacity mode eliminates capacity provisioning and management for streaming workloads. Kinesis Data Streams is a fully-managed, serverless service for real-time processing…