​​Рекомендации по реализации микросервисной архитектуры на AWS:

https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html

Документ AWS Whitepaper «Implementing Microservices on AWS» описывает подходы к реализации масштабируемой и надёжной микросервисной архитектуры, в том числе с использованием serverless подхода. Описываются подходы для мониторинга распределённых по сервисам окружений и реализации асинхронной работы.

#design #best_practices

​​AWS Architecture Monthly Magazine

Хочется чего-нибудь почитать по AWS, возможно, в пути или где вообще нет интернета? Может быть у вас всегда с собой Kindle или же, как я, предпочитаете бумажный вариант?

Есть классное место. Уже несколько месяцев читаю и наслаждаюсь. Ведь это не просто ссылка, которая растворится через какое-то время в вашей ленте. Это можно распечать, засунуть в рюкзак, забыть, а потом получить в лесу, или на даче без связи, истинное удовольствие.

https://aws.amazon.com/architecture/architecture-monthly/

Реально качественные статьи, тематическая подборка по для каждого месяца, лучшие авторы и рекомендации экспертов, подборка видео по теме, решения и описание референсной архитектуры — всё на самом высшем уровне. В pdf версии ссылки кликабельные (в бумажной, к сожалению, нет😀).

Очень рекомендую. Начиная с мая 2021-го года вёрстка и наполнение радикально изменились — каждый месяц увеличивается объём и качество. В AWS вспомнили про нас, кто любит читать бумагу и электронные книжки. Надеюсь, на выходе можно будет подписаться на регулярное издание и получать по (физической) почте.

На картинке журналы AWS Architecture Monthly, cкачать pdf:

▫️ November 2021 IoT for the Edge
▫️ October 2021 Aerospace
▫️ September 2021 Advertising Technology
▫️ August 2021 Sustainability

#design

Плохие практики — VPC с двумя AZ подзонами или сколько правильно иметь AZ в VPC

Как показал опрос, 20% читателей используют фиксированные 2 AZ для разворота VPC. И действительно, для простоты и экономии, казалось бы, логично, использовать две AZ подзоны. Кучи примеров с такими настройками, презентаций, видео. Также многие просто руководствуются требованиями в документации, например, это минимальная рекомендация для ALB:

You must select at least two Availability Zone subnets.

Другие считают, что всё равно некоторые AWS регионы имеют лишь две AZ подзоны, потому логично ориентироваться на минимум для своих deployment скриптов, который подойдёт для всех.

Две (минимум) AZ

Попробуем разобраться в деталях, почему использовать лишь 2 AZ — плохая практика.

1️⃣ Во-первых, на текущий момент (начало 2022-го года) все AWS Regions имеют 3 AZ и больше.

2️⃣ Во-вторых, сами по себе AZ подзоны (как подсети для VPC) не стоят денег, потому в качестве экономического фактора не валидны.

3️⃣ В-третьих, это минимальное значение может стать крайне проблематичным в случае реального падения одной из AZ подзон.

Показательный случай был совсем недавно, 22 декабря 21-го года, когда упала USE1-AZ4 в N.Virginia после отключения электричества в её датацентре. По результатам падения, один из обладателей конфигурации с 2 AZ написал пост на Reddit, где пытался разобраться, почему 2 AZ не спасли от ошибок по таймауту.

Главные вывод следующий. Наблюдая проблемы в процессе их развития, он не мог быстро отреагировать на них, например, просто временно отключив одну из подсетей ALB (упавшей AZ4). А не смог он этого сделать как раз потому что минимальное значение подсетей для ALB, как было указано выше — 2 AZ! И потому ALB не дал возможности выбросить упавшую подзону.

Три AZ

Итого, если в VPC всего лишь 2 AZ, то нет возможности быстро/временно переконфигурировать сервисы, удалив из них проблемную AZ. Потому нормальным значением правильно считать 3 AZ или больше.

Максимум AZ

Про максимальное количество также стоит сказать. Кроме достаточно логичного, что в зависимости от используемого IaC, это может быть просто не шибко удобно по количеству кода, есть проблема другого характера. Некоторые AZ очень старые и уже давно не обновляются, в результате чего не имеют современных инстансов и можно получить ошибку "Your requested instance type is not supported in your requested Availability Zone":

https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-type-not-supported-az-error/

Такая точно есть в N.Virginia и если нет возможности обрабатывать данную ошибку, то можно использовать лишь 5 AZ.

Сколько нужно AZ

А если добавить Local Zones, которые можно/нужно подключать, то управление и выбор подзон нонче правильно выносить в отдельный процесс, который нужно иметь возможность гибко конфигурировать.

#VPC #design

Полезный пост с описанием моментов по созданию мультирегиональных приложений:

https://aws.amazon.com/blogs/architecture/creating-a-multi-region-application-with-aws-services-part-2-data-and-replication/

When building a distributed system, consider the consistency, availability, partition tolerance (CAP) theorem. This theorem states that an application can only pick 2 out of the 3, and tradeoffs should be considered.
▫️ Consistency – all clients always have the same view of data
▫️ Availability – all clients can always read and write data
▫️ Partition Tolerance – the system will continue to work despite physical partitions

#design

Хорошая статья-сравнение параллельного запуска Lambda, App Runner и Fargate:

https://nathanpeck.com/concurrency-compared-lambda-fargate-app-runner/

🔸 Concurrency
🔹 Scaling

Lambda
🔸 Single concurrent request per Lambda function instance, but many separate Lambda function instances
🔹 Fully managed by AWS Lambda, default limit of 1000 concurrent executions. Scale out more function instances in under a second.

App Runner
🔸 Multiple concurrent requests per container, enforces a configurable hard limit such as 100 concurrent reqs/container
🔹 Fully managed by App Runner. Configure a concurrency limit per containerized process. Scale out more container instances in less than 1 min.

Fargate
🔸 Multiple concurrent requests per container, no built-in limits on concurrency per container
🔹 Managed by you. Scale out more container instances based on your desired metric: CPU, concurrency, or a custom metric. Scale out in less than 1 min.

#design

Network Infrastructure Security Guidance:

https://media.defense.gov/2022/Mar/01/2002947139/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDANCE_20220301.PDF

Contents
1. Introduction
2. Network architecture and design
3. Security maintenance
4. Authentication, authorization, and accounting
5. Administrator accounts and passwords
6. Remote logging and monitoring
7. Remote administration and network services
8. Routing
9. Interface ports
10. Notification banners
11. Conclusion

#security #network #design

​​AWS drawing and diagramming tools:

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

#design

Бесконечно можно смотреть на 🔥 огонь и обсуждать, как на ☁️ AWS установить 🗒️ Wordpress:

https://www.youtube.com/watch?v=PYyAl2RPdhM

#design #Wordpress

​​📓 AWS Fault Isolation Boundaries:

https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html

Очень полезный для понимания работы AWS на глобальном уровне документ. Важный при проектировании архитектуры и принципиально важный при построении Disaster Recovery схемы.

Основная мысль такая. Если падает us-east-1, где располагается control plane большинства глобальных сервисов, то операции по их созданию, изменению, удалению перестанут работать (могут перестать, полагаться на это нельзя). При этом сервисы в регионах с нагрузками будут работать. Поэтому нужно планировать Disaster Recovery схему так, чтобы она не зависела от control plane.

В переводе на сервисы это означает следующее.


🔹 Route 53

Route 53 задействован под капотом самого AWS при создании многих сервисов, которым он должен сделать DNS собственные записи, в том числе хелсчеки, поэтому при проблемах в us-east-1 у Route 53 может не быть возможности создать нужные записи и потому запросы на создание большинства популярных ресурсов вернут ошибку. Это верно как минимум для следующего списка (список не полный):

▪️ API Gateway
▪️ CloudFront
▪️ DynamoDB Accelerator (DAX)
▪️ Global Accelerator
▪️ ECS with DNS-based Service Discovery
▪️ EKS Kubernetes control plane
▪️ ElastiCache
▪️ ELB load balancers
▪️ Lambda URLs
▪️ MemoryDB for Redis
▪️ Neptune
▪️ OpenSearch
▪️ PrivateLink VPC endpoints
▪️ RDS/Aurora

👉 Рекомендация: для критичных Disaster Recovery схем нужно создавать ресурсы заранее. Не получится во время проблем в us-east-1 поднять RDS базу данных из бэкапа. Не получится создать балансеры, Redis или CloudFront.


🔸 S3

S3 региональный сервис, но из-за того, что у S3 все имена должны быть уникальные, то не получится создать или удалить бакет во время проблем в us-east-1. Кроме того все операции по изменению конфигурации бакета (bucket policy, настройки CORS, ACL, шифрования, репликации, логирования и др.) тоже зависят от us-east-1.

👉 Рекомендация: для критичных DR схем создавать S3 бакеты заранее. Не получится во время проблем в us-east-1 создать новый S3 бакет или срочно прикрутить к нему репликацию.


🔹 CloudFront

CloudFront используется для API Gateway with edge-optimized endpoints.

👉 Рекомендация: создавать заранее все нужные API Gateway with edge-optimized endpoints.


🔸 AWS STS

IAM сервис глобальный, получить временные credentials через STS можно из любого региона. Если у вас захардкожен us-east-1, то когда у него проблемы, вы получите ошибки, в то время как региональный STS будет работать.

👉 Рекомендация: изменить в AWS CLI / AWS SDK захардкоженный us-east-1 на регион с нагрузкой.


🔹 IAM Identity Center (AWS SSO) / Federated SAML

SSO может пострадать, если в том регионе, где он настроен, проблемы.

👉 Рекомендация: создайте IAM юзеров на случай, если вы, как я, слишком уж стараетесь соблюдать security best practices. По-другому зайти в систему во время проблем с SSO не получится, потому для критических случаев нужно создать рабочекрестьянского IAM user-а.

Ужас какой. Короче, типа — WiFi это конечно очень круто, но бухту кабеля и обжим всё-таки пока не выбрасывайте.


🔸 S3 Storage Lens

Дефолтная борда и её метрики располагаются в us-east-1, поэтому при проблемах они могут быть не доступны.

👉 Рекомендация: если для вас критичны S3 Storage Lens, то нужно создать свои собственные дашборды, указав при создании свой регион.

#design