Хорошая статья-сравнение параллельного запуска 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

​​📄 AWS Whitepaper — AWS Multi-Region Fundamentals:

https://docs.aws.amazon.com/pdfs/whitepapers/latest/aws-multi-region-fundamentals/aws-multi-region-fundamentals.pdf

🔹 This paper focuses on high availability and continuity of operations requirements, and helps you navigate the considerations for adopting a multi-Region architecture for a workload.
🔸 It describes fundamental concepts that apply to design, development, and deployment of a multi-Region workload, along with a prescriptive framework to help you determine whether a multi-Region architecture is the right choice for a particular workload.
🔹 You need to ensure a multi-Region architecture is the right choice for your workload, because these architectures are challenging, and it’s possible that, if not done correctly, the overall availability of the workload can decrease.

#design

​​📓 Choosing the right AWS service to deploy your website or web application in the AWS Cloud — AWS Prescriptive Guidance:

https://docs.aws.amazon.com/prescriptive-guidance/latest/website-deployment-services

▫️ Static: S3 + CloudFront
▫️ JS framework + CI/CD: Amplify
▫️ Serverless + low-cost: API Gateway + Lambda + S3
▫️ WordPress/Drupal/Joomla: LightSail
▫️ Containers: App Runner or ECS or Fargate
▫️ Kubernetes: EKS
▫️ On-premises: EKS Anywhere or ECS Anywhere
▫️ Old-style managed environment: Beanstalk
▫️ Self-managed: EC2

#design

​​📘 AWS Reference Architecture — Invoking Asynchronous External APIs:

https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/invoking-asynchronous-external-apis-ra.pdf

1️⃣ Set up Step Functions
2️⃣ Send the task token and the request payload
3️⃣ Use Lambda to poll SQS and trigger an express Step Functions workflow
4️⃣ (Optionally) Add dynamic delay inside Lambda controlled by AppConfig
5️⃣ Step Function invokes an API Gateway HTTP proxy API
6️⃣ Invoke the external third-party asynchronous service API
7️⃣ Store the workflow’s task token and the received job ID in DynamoDB
8️⃣ Receive the completed job ID in a callback webhook endpoint
9️⃣ Transform the external callbacks with API Gateway
🔟 Use Lambda to poll the callback SQS
1️⃣1️⃣ Pass the job ID to the next step, and invoke a Step Function processor to fetch the job’s results

#design

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

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

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

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

v.0.0.0

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

v.0.1.0

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

v.1.0.0

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

#serverless #monolith #design