Forwarded from Go Library
The perfect start to your new Go project
Effortlessly generate the ideal application scaffold for your Go project, customized to your needs and saving yourself hours of time and thinking.https://autostrada.dev
Forwarded from ДевОпс Інженер 🇺🇦 (Oleg Mykolaichenko)
AWS Multi-account Strategy
Абсолютно очевидним є тренд на декомпозицію одного величезного аккаунту з мільйоном сервісів на маленькі, і гранулярні AWS Accounts. Спершу звучить дико, але абсолютно точно має свій сенс.
Сенс рекомендації: працювати в одному аккаунті - це зло, навіть якщо у вас достатньо сегментації на рівні VPC, або EKS кластерів під енв - це аж ніяк не може бути безпечно, і, певною мірою, досить юзабельно.
Стратегічний вектор: account per app per env 😳
Хайлевельно, виходить ось така кухня:
1. Рекомендовано юзати примітив Organizations, всередині якого нарізати аккаунти
2. Нарізати аккаунти запропоновано через Control Tower
Бенефіти:
- повна сегментація аккаунтів (dev трафік ніяк не пролізе в prod, якщо звичайно не накрутити додаткових Transit Gateway, VPCe, etc)
- більш гнучкий рівень контролю доступів (видаємо команді, яка розробляє сервіс доступ в аккаунти з їх респонсібіліті)
- біллінг рахувати набагато простіше (дуже легко відповісти на питання, скільки грошей коштувала апка)
- security by design
Мінуси:
- доведеться платити декілька разів за ті ж кластери, VPC, Internet/NAT gateway - їх кількість кратно збільшиться
- складність менеджменту цією кухнею кратно зростає (збільшується складність --> складніші тули і підходи —> ріст зарплати 💸 —> більший донат на оборону України)
Цікаво, що цей підхід Amazon рекомендує всім корпоративним юзерам AWS, і дуже активно використовує сам. Чим ближче ви до MANGA компаній, тим більш корисним вам буде такий досвід.
Тепер посилання для продовження занурення в концепцію:
📄 Whitepaper:
https://docs.aws.amazon.com/pdfs/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/transitioning-to-multiple-aws-accounts.pdf
📄 Мікро-дока:
https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html
📄 AWS Control Tower Account Factory for Terraform:
https://github.com/aws-ia/terraform-aws-control_tower_account_factory
Як в GCP - не в курсі, колись давно бачив сегментацію на рівні Projects. Хто шарить як там в GCP - поділіться, пліз, в коментарях.
Абсолютно очевидним є тренд на декомпозицію одного величезного аккаунту з мільйоном сервісів на маленькі, і гранулярні AWS Accounts. Спершу звучить дико, але абсолютно точно має свій сенс.
Сенс рекомендації: працювати в одному аккаунті - це зло, навіть якщо у вас достатньо сегментації на рівні VPC, або EKS кластерів під енв - це аж ніяк не може бути безпечно, і, певною мірою, досить юзабельно.
Стратегічний вектор: account per app per env 😳
Хайлевельно, виходить ось така кухня:
1. Рекомендовано юзати примітив Organizations, всередині якого нарізати аккаунти
2. Нарізати аккаунти запропоновано через Control Tower
Бенефіти:
- повна сегментація аккаунтів (dev трафік ніяк не пролізе в prod, якщо звичайно не накрутити додаткових Transit Gateway, VPCe, etc)
- більш гнучкий рівень контролю доступів (видаємо команді, яка розробляє сервіс доступ в аккаунти з їх респонсібіліті)
- біллінг рахувати набагато простіше (дуже легко відповісти на питання, скільки грошей коштувала апка)
- security by design
Мінуси:
- доведеться платити декілька разів за ті ж кластери, VPC, Internet/NAT gateway - їх кількість кратно збільшиться
- складність менеджменту цією кухнею кратно зростає (збільшується складність --> складніші тули і підходи —> ріст зарплати 💸 —> більший донат на оборону України)
Цікаво, що цей підхід Amazon рекомендує всім корпоративним юзерам AWS, і дуже активно використовує сам. Чим ближче ви до MANGA компаній, тим більш корисним вам буде такий досвід.
Тепер посилання для продовження занурення в концепцію:
📄 Whitepaper:
https://docs.aws.amazon.com/pdfs/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/transitioning-to-multiple-aws-accounts.pdf
📄 Мікро-дока:
https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html
📄 AWS Control Tower Account Factory for Terraform:
https://github.com/aws-ia/terraform-aws-control_tower_account_factory
Як в GCP - не в курсі, колись давно бачив сегментацію на рівні Projects. Хто шарить як там в GCP - поділіться, пліз, в коментарях.
AWS Application Migration Service: Move and improve your on-premises and cloud-based applications | by Ashish Kasaudhan | ashishkasaudhan | Jan, 2023 | Medium
https://medium.com/ashishkasaudhan/aws-application-migration-service-move-and-improve-your-on-premises-and-cloud-based-applications-370944d37566
https://medium.com/ashishkasaudhan/aws-application-migration-service-move-and-improve-your-on-premises-and-cloud-based-applications-370944d37566
Medium
AWS Application Migration Service Move and improve your on-premises and cloud-based applications
Cloud Migration
Forwarded from Nikita
чат, видели?
https://canarytokens.org/
https://canarytokens.org/
Canarytokens
Know. Before it matters
Canarytokens is a free tool that helps you discover you’ve been breached by having attackers announce themselves.
The tokens allow you to implant traps around your network and notifies you as soon as they are triggered.
The tokens allow you to implant traps around your network and notifies you as soon as they are triggered.