Главное за три года на AWS

Когда вы освоили AWS в достаточной мере, имеете не один год опыта, сдали на AWS сертификацию (всё это вместе или по отдельности), то можете работать, успешно, долго, на базе уже имеющегося опыта и знаний. Следить за обновлениями, которые выходят тысячами в год, от некогда до незачем — у вас в бэклоге и так на месяцы вперёд работы, куда тут отвлекаться.

Работая в таком ритме годами, с одной стороны, вы как бы приобретаете опыт и растёте, как профессионал в своей области. С другой, если совсем не следить за изменениями — деградируете в профессиональном аспекте. На выходе такой ситуации часто рождается конфликт между "old school подходом" (когда вы на базе своего опыта реализуете всё на "проверенных временем" схемах) и "хипстерскими" стильно-модно-молодёжными технологиями, которые пытаются продвигать новички в области вашей деятельности.

Не пытаясь холиварить на эту тему (old school против хипстеров — хотя сам на стороне последних), правильней лучше выбрать и рассказать про самое важное, что произошло за последние три года на Амазоне. Из тысячи апдейтов разной степени важности, выделить обязательные к ознакомлению, которые принципиально меняют подходы, работу AWS и работу с AWS.

---
Главное на AWS за 2017-2018-2019 — деньги (скидки)
---

Начнём с денег. Чтобы экономить на оплате постоянно работающих виртуалок, вот уже больше десяти лет использовались Reserved Instances. Это когда вы покупаете скидки на 1 или 3 года на какой-то тип виртуалок в каком-то регионе, взамен на гарантию, что будете пользоваться ими (верней - оплачивать) всё это время.

Так вот, Reserved Instances (RI) — всё, они в прошлом, их заменили Savings Plans:

https://aws.amazon.com/blogs/aws/new-savings-plans-for-aws-compute-services/

RI продолжают действовать, но смысла покупать новые нет, так как справедлива следующая формула перехода:

Standard RI = EC2 Instance Savings Plans (та же максимальная скидка 72%)

Convertible RI = Compute Savings Plans (та же максимальная скидка 66%)

Для тех, кто не имел опыта с RI — теперь незачем его получать. Смело берите (ориентируйтесь на) Compute Savings Plans и читайте уже про него. Кто захочет разобраться — вот подробное видео по Savings Plans:

https://www.youtube.com/watch?v=uQ9ry-9uUvo

В этом видео ещё нет того факта, что в этом году в Compute Savings Plans добавлены и Лямбды, что делает его (Compute Savings Plans) ещё более крутым.

Итого, главное по деньгам (скидкам) на AWS за последние 3 года — Reserved Instances умерли, да здравствует Savings Plans!

#главное #cost_optimization

RDS RI

В дополнение по RI нужно упомянуть про RDS Reserved Instances (RDS RI) — это как RI для EC2, только для RDS (спасибо, Кэп). Главное, что они разные (покупать-резервировать нужно отдельно и в разных местах, цены немножко отличаются) и по внедрению фич RDS RI отстают от EC2 RI. В частности потому RDS RI (как минимум пока) всё ещё актуальны (в отличие от EC2 RI, которые заменены на Savings Plans).

В 2017-м году RDS RI получили важное свойство (вслед за "обычными" RI) — Instance Size Flexibility:

https://aws.amazon.com/rds/reserved-instances/#Reserved_Instance_Size_Flexibility

Это если вы сейчас купите трёхлетнюю скидку на базу db.m5.xlarge, а через годик набегут клиенты и потребуется её мощность увеличить, например, до db.m5.2xlarge, то у вас будут следующие варианты:

1. Докупить ещё одну скидку на 1 или 3 года на такую же db.m5.xlarge и они вдвоём будут давать скидку на db.m5.2xlarge. То есть скидки db.m5.xlarge+db.m5.xlarge=db.m5.2xlarge

2. Ничего не делать и тогда к счёту вашей будущей db.m5.2xlarge применится скидка лишь на её половину (но применится, а не пропадёт).

Также стоит отметить важное свойство RI (справедливо и для EC2 RI, и для RDS RI, и для Savings Plans), что скидки применяются на все аккаунты вашей организации. То есть будучи купленными в мастер-аккаунте, все доступные скидки применятся и для всех подаккаунтов.

Итого по RDS RI — отдельный тип RI, скидка "самомасштабируется" по всей линейке одного семейства (одного региона) и применяется ко всем аккаунтам организации.

#главное #cost_optimization #RDS #RI

Главное на Амазоне за 2017-2018-2019 — AWS Organizations

От денег перейдём к организационной структуре. За это время с "верхнеуровневой" частью управления компанией на Амазоне поменялось ПОЛНОСТЬЮ ВСЁ — три года назад появился сервис AWS Organizations.

https://aws.amazon.com/organizations/

И если про AWS Organizations вы не слышали или если и слышали, то не особо вникали и не пользовались, то знайте — вы совсем не понимаете, как (теперь) работает AWS.

AWS Organizations — базовый элемент для обеспечения безопасности, современный проект вряд ли пройдёт аудит без использования Organizations, а при наличии каких-то Compliance требований вообще просто без шансов. Это опуская все моменты, которые AWS Organizations даёт по работе в увеличению эффективности работы - как на уровне управления командами и проектами, так и по части эффективного использования ресурсов и их оплаты.

Тут часто упоминались и будет упоминаться термин #Multi_Account_Strategy или просто "мульти-аккаунты", который есть немного жаргонное обозначение использования AWS Organizations. Кто не видел — можно посмотреть это видео по мультиаккаунтам.

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

Неверующие в докер не заметили, как вся индустрия де-факто переходит/перешла на использование контейнеризации чуть меньше, чем везде. И если для поддержки старых проектов понятно, то для реализации новых, без контейнеризации — это изначально закладывать отставание от других и последующую переделку.

Аналогично и AWS Organizations, не используя мульти-аккаунт подход — вы остаёте. Безопасность, эффективность, управляемость, а точней, их отсутствие (что невозможно на сегодняшнем Амазоне без AWS Organizations) — радикально уменьшают шансы на успех вашего стартапа.

Переход на мульти-аккаунт схему требует времени, ресурсов, знаний. Равно как и, в своё время, требовал затрат переход на Docker, CI/CD, IaC, Kubernetes и другие современные подходы, которые на выходе дают большую гибкость, скорость, эффективность.

Итого по организации. Три года назад завезли совсем другой Амазон. Если вы этого не заметили — разберитесь и используйте AWS Organizations. Без него сейчас никак. Он теперь такой же базовый, как S3.

#главное #Organizations

Главное на Амазоне за 2017-2018-2019 — Networking

От организации к сетевой составляющей. За это время в плане подходов к проектированию и обслуживанию сети организации на Амазоне поменялось ПОЛНОСТЬЮ ВСЁ — в 2018-м году появились сервис AWS Transit Gateway и фича Shared VPC:

https://aws.amazon.com/transit-gateway/

https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/

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

VPC Sharing позволяет кардинально упростить сетевую инфраструктуру в тех многих случаях, когда нет повышенных требований по её изоляции. Для средних и больших проектов подход с использованием Shared VPC даёт возможность уменьшить количество VPC на порядок при сохранении параметров безопасности и уменьшении расходов.

Если у вас используется VPN или Direct Connect доступ в Амазон, если у вас есть филиалы по миру или вы лишь планируете это сделать — обязательно разберитесь с возможностями, которые даёт Transit Gateway, это принципиально новый набор возможностей, это новый, совсем другой — глобальный Амазон. Вот хорошее видео по его работе и возможностям с последнего реинвента:

https://www.youtube.com/watch?v=9Nikqn_02Oc

Если у вас большое количество однотипных VPC, в которых крутится небольшое количество сервисов, то для упрощения и экономии их можно поднимать в общих Shared VPC. Это позволяет обуздать постоянно усложняющуюся архитектуру сети компании, сделать её понятной, управляемой и эффективной. Вот хорошее видео по Shared VPC с последнего реинвента:

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

И Transit Gateway, и Shared VPC плотно увязаны с мульти-аккаунт подходом, который, как говорилось ранее, теперь есть базовая сущность Амазона и потому неотрывно подразумевается и интегрирован в них.

Итого по планированию и работе с сетевой инфраструктурой компании — Shared VPC упрощает, а Transit Gateway упорядочивает и глобализирует. Это важно понять — Амазон давно стал глобальным, но теперь с помощью Transit Gateway он позволяет стать глобальным и вам, напрямую используя возможности AWS по глобализации своей сетевой инфраструктуры.

#главное #Transit_Gateway #Shared_VPC #networking

​​AWS Backup

Продолжая рубрику #главное на AWS за 2017-2018-2019, обязательно нужно сказать про появившийся в начале 2019-го сервис AWS Backup.

https://aws.amazon.com/backup

Он позволяет заменить кучи понаписанных своих вело-лямбд, которые выполняли каждодневные операции бэкапов основных сервисов. Теперь с помощью AWS Backup это просто и ооочень удобно.

Если за годы работы с AWS у вас появились свои решения для бэкапов и потому не обратили на него внимания — очень зря, обязательно посмотрите.

Из коробки он бэкапит EC2 виртуалки (делает амишки со всеми дисками или EBS отдельно), RDS базы данных, EFS (умеет в cold storage), диски AWS Storage Gateway и таблицы DynamoDB. Сразу можно делать копии в другие регионы, бэкапить по тэгу, настраивать расписание и прочие нужные в постоянной эксплутации вещи.

Отдельно рекомендуется начинающим — с помощью AWS Backup легко защить свои действия с инфраструктурой. А кому интересно разобраться в подробностях:

AWS re:Invent 2019: Deep dive on AWS Backup

#Backup

Главные AWS события за последний год (по версии Reddit)

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

1️⃣ AWS Public IPv4 Address Charge
Начиная с этого месяца (февраль 2024) за каждый публичный айпишник IPv4 придётся платить 3.6$ — столько же, сколько раньше платили за "простаивающий" (неиспользуемый) Elastic IP.

2️⃣ Amazon Linux 2023
Наследник Amazon Linux 2 не стал третьим, а задумывался как Amazon Linux 2021, после был переименован в Amazon Linux 2022, но что-то пошло не так из-за серьёзных изменений в RedHat 9 задержался и стал Amazon Linux 2023.

3️⃣ S3 Block Public Access and disabling S3 ACLs by default for all new S3 buckets
Начиная с апреля 2023 все новосозданные S3-бакеты являются приватными и чтобы создать в них публично доступные объекты вам придётся повозиться. А не наоборот, как было до этого без малого 20 лет.

4️⃣ Enable SSM for all EC2 in AWS Organizations
Теперь можно включить SSM на виртуалках оптом.

5️⃣ ALB + TLS 1.3
Лучше поздно, чем никогда.

6️⃣ Lambda response streaming
Можно слать ответы больше 6MB.

7️⃣ EC2-Classic всё
Тёплый ламповый EC2 уже больше не поднять.

8️⃣ Mountpoint for Amazon S3
Правильный способ примонтировать S3.

#главное