​​Новый AWS регион в 2024-м году — Окленд, Новая Зеландия:

https://aws.amazon.com/ru/blogs/aws/in-the-works-aws-region-in-new-zealand/

#AWS_Regions

​​В новых иконках от AWS добавили AWS Account:

https://aws.amazon.com/architecture/icons/

#Organizations #design

Если у вас есть лишние пять миллиардов долларов, то можно заказать себе AWS Region:

https://anz-resources.awscloud.com/new-aws-region-in-aotearoa-new-zealand/aws-investment-in-new-zealand-aws-economic-impact-study

Примерно во столько обойдётся по данной отчётности (в переводе с новозеландских) свежеобъявленный AWS регион в Новой Зеландии.

#AWS_Regions

​​К – качество.

#пятничное

«You Build It, You Run It» vs «Девопс-инженер – суровая правда жизни»

Умные люди здесь жарко дискутировали на сотню комментариев, что же правильней-реальней.

▪️ Точка зрения 1. DevOps — это (отдельный) человек (девопс-инженер или несколько, команда, несколько команд), который занимается CI/CD процессом.

▪️ Точка зрения 2. DevOps — это подход «You Build It, You Run It».

Кроме этого, конечно, к обоим можно добавить, что это культура, набор лучших практик и так далее.

Однако главный вопрос: девопс — это отдельные специально обученный человек (люди), который(-е) "делают девопс" или же при таком подходе это лишнее звено. А в "правильном варианте" практики девопса воплощают разные члены команды, в первую очередь сами разработчики (кто разрабатывает, тот же деплоит, обновляет, мониторит и так далее).

Я (категорически) придерживаюсь варианта «You Build It, You Run It», понимая, что в «обычном случае» это не так. Однако считаю, что нужно добавить "пока" плюс, опять же, всегда правильно помнить и напоминать, как оно должно быть.

Поделитесь, пожалуйста, своим взглядом на эту проблему («You Build It, You Run It — this is real DevOps») в комментариях.

⁉️ Опрос «DevOps — это (отдельный) человек (люди)» vs «You Build It, You Run It».

#devops

​​Статья про то, как автор пытался получить список удалённых секретов, однако полезна описанием работы AWS SDK:

https://alexwlchan.net/2021/07/listing-deleted-secrets/#how-the-language-specific-aws-sdks-work

How the language-specific AWS SDKs work
At time of writing, AWS has nine language-specific SDKs which have to support over 200 different services. Each SDK contains a client for each service, and the methods on those clients mirror the underlying HTTP APIs. It would be impractical to maintain those clients by hand – so they don’t.
Instead, AWS publish “service models” that describe each service. These models are JSON files that contain a complete description of the endpoints, the models, the documentation text, and so on. These models are used to autogenerate the service-specific clients in the SDKs, reducing the effort required to keep everything up-to-date. This approach has also allowed other people to write SDKs in languages that AWS don’t support, like Haskell and Clojure.

#SDK #Secrets #Python

​​13 октября пройдёт онлайн митап AWS User Group Ukraine

В программе следующие доклады:

🔹 «Deep dive into AWS Lambda»
🔸 Спикер: Александр Драгунов (Senior Partner Solutions Architect, AWS)

🔹 «How bizzabo leverage aws to make scalable architecture»
🔸 Спикер: Daniel Doppelt (System Architect, Bizzabo)

Модератор — Егор Шадрин (Startup Solutions Architect, AWS).

📆 13 октября в 19:00 (GMT+3) онлайн

Регистрируйтесь 👉 https://bit.ly/39ysCKR

Направляем трафик напрямую от NLB к ALB без дополнительных костылей:

https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/

Today, we are launching ALB as a Target of NLB to simplify this process. This new feature allows AWS customers to directly register an ALB as an NLB target, eliminating the need to actively manage changing ALB IP addresses. This is achieved by making use of a newly introduced Application Load Balancer-type target group for NLB.

#NLB #ALB

​​EC2 Global View

Здесь (AWS Console → EC2 → EC2 Global View) можно видеть все свои EC2 виртуалки, EBS Volumes и VPC сразу по всем AWS регионам в одном месте:

https://console.aws.amazon.com/ec2globalview/home

#EC2 #AWS_Console #AWS_Regions

Ransomware Risk Management on AWS Using the NIST Cyber Security Framework (CSF)
 
https://d1.awsstatic.com/whitepapers/Security/ransomware-risk-management-on-aws-using-csf.pdf
 
Если попытаться отразить все аспекты безопасности из данного документа в сервисах AWS, то получится следующий (длинный) список.
 
🔹 Basic
Use antivirus software at all times.
▪️ Marketplace
Keep computers fully patched.
▪️ SSM Patch Manager
Block access to ransomware sites.
▪️ Route 53 Resolver DNS Firewall
▪️ Network Firewall
▪️ NACL
Allow only authorized apps.
▪️ SSM State Manager
Use standard user accounts
▪️ IAM
Make an incident recovery plan.
▪️ AWS Security Incident Response Guide
Backup and restore.
▪️ EBS Snapshots
▪️ Backup
▪️ CloudEndure Disaster Recovery
▪️ CodeCommit
Keep your contacts.
▪️ AWS Security Incident Response Guide
 
🔸 NIST Practice Guide goals
Backup
▪️ EBS Snapshots
▪️ Backup
▪️ CloudEndure Disaster Recovery
▪️ CodeCommit
Corruption testing
▪️ Config Rules
▪️ SSM State Manager
Denylisting
▪️ EC2 Security Groups
▪️ Route 53 Resolver DNS Firewall
▪️ Network Firewall
▪️ VPC endpoints
▪️ WAF
▪️ WAF Security Automations
▪️ WAF-Managed Rules
▪️ NACL
Event detection
▪️ GuardDuty
▪️ Macie
▪️ Network Firewall
Forensics and analytics
▪️ Detective
▪️ GuardDuty
▪️ Network Firewall
Integrity monitoring
▪️ ECR
▪️ Macie
▪️ Config Rules
▪️ Lambda function versioning
▪️ SSM State Manager
Inventory
▪️ ECR
▪️ Config
▪️ IAM credential report
▪️ SSM Inventory
Logging
▪️ Athena
▪️ CloudWatch
▪️ CloudWatch Logs
▪️ CloudWatch Logs Insights
▪️ OpenSearch Service
▪️ GuardDuty
▪️ Inspector
▪️ Lookout for Metrics
▪️ Macie
▪️ Route 53 Public Zone Logs and Resolver Query Logs
▪️ S3 Server Access Logs
▪️ VPC Flow Logs
▪️ Audit Manager
▪️ CloudTrail
▪️ CloudTrail Insights
▪️ Config
▪️ Config Rules
▪️ Security Hub
▪️ SSM Inventory
▪️ IAM Credential Report
▪️ SSM Session Logs
Mitigation and containment
▪️ EC2 Security Groups
▪️ Nitro Enclaves
Network protection
▪️ CloudFront
▪️ EC2 Security Groups
▪️ GuardDuty
▪️ Route 53 Resolver DNS Firewall
▪️ ALB
▪️ Firewall Manager
▪️ Network Firewall
▪️ Shield
▪️ WAF
▪️ WAF Automation
▪️ WAF-Managed Rules
▪️ NACL
Policy enforcement
▪️ Inspector
▪️ Config Rules
▪️ Lambda
▪️ SSM document
▪️ SSM Patch Manager
▪️ SSM State Manager
Reporting
▪️ SNS
Secure storage
▪️ Access Analyzer for S3
▪️ EBS
▪️ KMS
▪️ Macie
▪️ IAM
▪️ S3 Access Control Lists
▪️ S3 Bucket Policies
▪️ S3 Access Points
▪️ S3 Query string authentication
▪️ PrivateLink for S3
▪️ Storage Gateway
▪️ VPC endpoints
▪️ EFS
▪️ S3 Block Public Access
▪️ S3 Encryption
▪️ S3 MFA delete
▪️ S3 Object Lock
▪️ S3 Versioning
Virtual infrastructure
▪️ EBS snapshots
▪️ Backup
Vulnerability management
▪️ ECR image scanning
▪️ Inspector
▪️ Security Hub
 
Очень полезный документ, самые объёмные пункты по логированию, защите сети и шифрованию данных.
 
#security #NIST #devsecops

Лямбда-arm64 на Graviton2 — быстрее и дешевле:

https://aws.amazon.com/blogs/aws/aws-lambda-functions-powered-by-aws-graviton2-processor-run-your-functions-on-arm-and-get-up-to-34-better-price-performance/

Lambda functions powered by Graviton2 are designed to deliver up to 19 percent better performance at 20 percent lower cost.

Для Лямбд без зависимостей простое переключение на ARM даст неплохую экономию.

x86 128 MB $0.0000000021
arm64 128 MB $0.0000000017

🎉 Сразу с поддержкой в CloudFormation и CDK (хотя этого на момент написания поста нет в документации) — просто добавляем параметр Architectures: [arm64] в AWS::Lambda::Function.

p.s. Отдельно интересно, что архитектура задаётся как list, a не string, что может указывать на возможность задания сразу нескольких архитектур в будущем.

Updated, спасибо за пример @geekexport:
LambdaArmExample:
 Type: AWS::Serverless::Function
 Properties:
  Handler: ./dist/index.handler
  Timeout: 30
  MemorySize: 1024
  Architectures:
   - arm64

#Lambda #Graviton2

​​Сравнение производительности Lambda-x86 vs Lambda-arm64:

https://blog.thundra.io/a-performance-perspective-for-graviton-based-lambda-functions

In conclusion, we can see the benefit of AWS Graviton2 for both price and performance. 

#Lambda #cost_optimization

Поддержка Step Functions более чем 200 AWS сервисов:

https://aws.amazon.com/blogs/aws/now-aws-step-functions-supports-200-aws-services-to-enable-easier-workflow-automation/

Даже если вы не интересуетесь Step Functions, интересно обратить внимание на официальное подтверждение — в AWS больше 200 сервисов и больше 9 тысяч API Actions.

#Step_Functions

​​aws-allowlister — полный набор SCP политик под различные compliance:

https://github.com/salesforce/aws-allowlister

С помощью данной утилиты можно создать SCP правила, которые разрешат работу лишь с сервисами, поддерживаемыми конкретным compliance, например, получить простыню (Allow List), где перечислены все AWS сервисы, разрешённые с точки зрения HIPAA.

Таким образом можно навесить полученный SCP на какой-то AWS аккаунт (или OU) и протестировать в нём окружение, что даст гарантию его HIPAA совместимости.

#SCP #compliance #security

AWS Cloud Control API — универсальный набор API для Create/Read/Update/Delete/List (CRUDL) более чем 200 AWS сервисов:

https://aws.amazon.com/blogs/aws/announcing-aws-cloud-control-api/

Крутая вещь — можно использовать привычные CreateResource, GetResource, UpdateResource, DeleteResource, ListResource для любых AWS сервисов и их ресурсов.

aws cloudcontrol create-resource   \
 --type-name AWS::Lambda::Function \
 --desired-state '{"Code":{"S3Bucket":"my-bucket","S3Key":"index.zip"},"Role":"arn:aws:iam::123:role/lambda_basic_execution","Runtime":"python3.9","Handler":"index.lambda_handler"}' \
 --client-token xxx

aws cloudcontrol delete-resource   \
 --type-name AWS::Lambda::Function \
 --identifier xxx-xxx

p.s. Второй пост за сегодня, где официально упоминается 200+ AWS сервисов. Это жжж неспроста. 😀

#API

Серьёзные подвижки для работы в мульти-аккаунт окружении — возможность программно изменять почту для billing/operations/security в под-аккаунтах:

https://aws.amazon.com/blogs/mt/programmatically-managing-alternate-contacts-on-member-accounts-with-aws-organizations/

По умолчанию все сообщения по поводу AWS аккаунта — биллинг, проблемы безопасности (например, вас поломали и/или ваши виртуалки рассылают спам) — шлются на почту root-юзера. Однако можно задать альтернативные контакты - отдельные почты для billing/operations/security.

При программном создании под-аккаунтов эти поля не заполняются и чтобы получать данные сообщения раньше нужно было вручную изменять, для чего требовалось заполнять и другие поля root-юзера (в первую очередь - восстановить к нему пароль), что практически невозможно было автоматизировать и всегда было огромной проблемой.

Теперь же можно запустить баш-скрипт (в AWS огромное Bash-лобби 😁) из статьи и назначить всем подаккаунтам нужные почты (или одну на всех). Что реально круто. Обязательно воспользуйтесь!

#Organizations #security #multi_account_strategy

#event
AWS COMMUNITY CHALLENGE: VOTING

Сбор заявок закончился, пришло время перейти к голосованию за лучший способ развертывания WordPress в AWS.

Все видео от участников размещены на странице конкурса.
Голосуем за понравившийся вариант в ТГ до 15 октября.
Итоги подведем на следующем митапе (спойлер: конец октября).

Следите за новостями😉

↑↑↑ Проголосуйте, пожалуйста, здесь за лучший вариант. ↑↑↑