# AWS (Amazon Web Services) - краткое руководство
## Идеология и архитектура
AWS это "облачная" платформа, уровень абстракции над "обычными" устройствами вроде сервера, файлового хранилища, роутера, фаервола, а так же это набор дополнительных средств, (отчасти) облегчающих жизнь системному администратору и DevOps'у.
AWS имеет датацентры в разных частях света и именует их "регионы" (Regions), в каждом регионе есть несколько "зон доступности" (AZ, Availability Zones) - это несоклько независитмых датацентров, расположенных рядом и выполняющих функции дублирования друг друга на случай отказа (но можно использовать их ресурсы и незавиисмо). Это дублирование не скрыто от пользователя: например, при создании [EC2](#EC2-(Elastic-Compute-Cloud))-экземпляра требуется явно указать в какой из имеющихся в данном регионе зон достпуности он будет размещён (есть опция "выбрать автоматически" -- AWS сам выберет зону исходя и наименьшей загруженности).
Между зонами доступности связь проста, а вот между регионами или стороними (по отношению к AWS) системами - строится с помощью специальных сервисов.
Для управления ресурсами AWS есть два инструмента:
1. [Веб-сайт ("консоль")](aws.amazon.com/console/)
2. [Утилита командной строки ("CLI")](aws.amazon.com/cli/)
Наличие **CLI** позволяет автоматизировать действия на AWS с помощью скриптов и стороннего ПО, например [GitLab CI\CD](docs.gitlab.com/ee/ci/) или [Jenkins](https://ru.wikipedia.org/wiki/Jenkins_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B5_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D0%B5)).
## AWS Console
Это отправная точка раюоты с AWS через веб-интрфейс. Выглядит так:
В левом верхнем углу кнопка Services ("Сервисы") вызывает меню сервисов:
Сервисы сгруппированы по категориям, но можно эт угруппировку и отключить: переключатель в правом верхнем углу:
Сервисы, к которым чаще всего обращаетесь - перечислены в колонке слева:
Выбрав конкретный сервис, попадаем на сраницу работы с ним. Каждый сервис имеет свою ==Dashboard== -- она содержит статистику по использованию ресурсов сервиса и ссылки для быстрого перехода в конкретным опциям/параметрам. Пример для сервиса [VPC](#VPC-(Virtual-Private-Cloud)):
На странице каждого сервиса, слева, расположен список всех "подсервисов". Далее в этом руководстве для их именования будет использован формат ==Сервис.Подсервис==, пример: `VPC.Subnets`.
## Сервисы
На AWS система строится из "сервисов". Они бывают разные: для построения сетевой инфраструктуры, для CI/CD, разного рода вспомогательные.
Сервисы являются сложными структурами и содержат "подсервисы" (официального названия для этого типа элементов нет).
### Сеть и доставка контента
#### VPC (Virtual Private Cloud)
Основой сетевой инфраструктуры является VPC. Оно группирует, в частности, вичислительные инстансы, pаздаёт IP-адреса (т.е. выполняет функции DHCP-сервера), параметры DNS.
При создании VPC задаётся лишь часть параметров - остальные можно посмотреть/изменить после, с помощью **Консоли**:
* Имя
* Диапазон IP-адресов (маска должна быть в диапазоне ==16-28==), принадлежащих этому облаку (VPC это своего рода VPN, только исключительно между **Зонами Доступности** одного **Региона**).
* DNS hostnames - включает раздачу имён машинам, имеющим публичные IP-адреса. При запросе из внешнего мира эти имена будут резолвиться в публичные адреса, а изнутри VPC - в приватные.
* DNS resolution - "включает" внутренний DNS Амазона (_наверное_)
* [Таблица маршрутизации](#VPC.Route_Table)
* [Network ACL](#VPC.Network_ACLs)
```mermaid
graph LR
subgraph vpc1["VPC A"]
vpc("Route Table, ACLs<br>& Security Groups")
subgraph zoneA["Availability Zone A"]
subgraph subnetA1["Subnet 1"]
machine1("Machine #1")
machine2("Machine #2")
machine1 --> machine2
machine2 --> machine1
end
subgraph subnetA2["Subnet 2"]
machine3("Machine #3")
machine4("Machine #4")
machine3 --> machine4
machine4 --> machine3
end
end
subgraph zoneB["Availability Zone B"]
subgraph subnetB1["Subnet 1"]
machine5("Machine #5")
machine6("Machine #6")
machine5 --> machine6
machine6 --> machine5
end
subgraph subnetB2["Subnet 2"]
machine7("Machine #7")
machine8("Machine #8")
machine7 --> machine8
machine8 --> machine7
end
end
end
machine1 --> vpc
machine2 --> vpc
machine3 --> vpc
machine4 --> vpc
machine5 --> vpc
machine6 --> vpc
machine7 --> vpc
machine8 --> vpc
```
##### VPC.Subnets
В каждой зоне доступности создаётся "подсеть" (subnet). У подсети четыре параметра:
* Имя
* VPC, которой она принадлежит
* Зона доступности, в которой она расположена
* Диапазон IP-адресов (должен быть внутри диапазона выбранного ==VPC==, маска в пределах ==16-28==), подсеть может быть такого же размера как и само VPC.
##### VPC.Route_Table
Фактически, VPC служит ==маршрутизатором== ("роутером") для входящих в него подсетей. Внутри подсети экземпляры EC2 могут свободно обмениваться информацией, а для выхода за пределы нужна, как минимум, маршрутизация. Настраивается гибко, с указанием в качестве "цели" различных VPC-подсервисов.
##### VPC.Network_ACLs
==Access Control List== это набор правил для фаервола, состоит из двух таблиц: одна для входящего трафика, а вторая для исходящего. Фильтрует на основе IP-адресов, типов протоколов (на выбор даются более дюжины) и номеров портов. Работает по принципу "_запрещено всё, что не разрешено_": всегда есть неудаляемое и неизменяемое правило с низшим приоритетом, которое запрещает весь трафик. Поверх этого правила накладываются пользовательские, разрешающие тот или иной трафик.
##### VPC.Security_Groups
Ссылка на [EC2.Security_Groups](#EC2.Security_Groups).
##### VPC.Internet_Gateways
По-умолчанию машины изолированы от интернета (в обе стороны). Есть несколько способов это исправить. Первый и "простейший" это Internet Gateways - он просто позволяет указывать себя в таблице маршрутизации в качестве "назначения", позволяя таким образом маршрутизировать трафик за пределы VPC. Но работает он только если у машины (экземпляра EC2) есть IPv6-адрес, или белый IPv4-адрес, или [Elastic IP](#VPC.Elastic_IPs).
##### VPC.Egress_Only_Internet_Gateways
Этот шлюз нужен исключительно для машин, у который IPv6-адреса. Он даёт им выход в интернет, но режет все входящие запросы (так что, фактически, это комбинация `VPC.Internet_Gateways` и `VPC.Network_ACLs`).
##### VPC.NAT_Gateways
Это "классический" способ дать машинам выход в интернет (для **исходящих** запросов). При создании этого шлюза ему нужно указать к какой подсети он будет принадлежать и каким [Elastic IP](#VPC.Elastic_IPs) он будет представлен в интернете. Этот подсервис примерним только для IPv4-трафика (IPv6 как раз создавался чтобы убрать потребность в трансляции адресов).
##### VPC.Transit_Gateways
Этот шлюз позволяет соедить VPC с другой VPC или с VPN или ещё с чем-то.
##### VPC.Elastic_IPs
Это публичный ("белый") IPv4 адрес, который можно динамически привязывать к разным объектам: экземпляру EC2, NAT Gateway, балансировщику нагрузки и т.д.
##### VPC.Peering_Connections
Своего рода VPN. Позволяет наладить связь между отдельными VPC, в том числе приназлежащзие разным аккаунтам и даже разным **Регионам**. Без неё все VPC изолированы друг от друга.
### Вычисления
#### EC2 (Elastic Compute Cloud)
EC2 это VPS/VDS (virtual private server/virtual dedicated server), вычислительный узел, имеющий сетевой интерфейс и ПЗУ (в котором хранится ОС и разные пользовательские файлы).
Амазон предоставляет разнообразные "машины", отличающеся производительностью (количество ядер CPU, объём ОЗУ, скорость сетевых интерфейсов), а так же их физическим расположением (можно выбрать виртуалки на одной хостовой машине, можно выбрать в одной стойке/кластере - тема требует отдельного изучения).
Аренда машин бывает трёх типов: ==on-demand==, ==reserved== и ==spot==.
Первый вариант это "обычная" аренда: выбрал параметры, нажал Launch и всё, ресурсы в твоём распоряжении и никуда не денутся, пока ты сам их не терминируешь.
Второй вариант это, насколько я понял, некая форма "твоего обещания амазону" что ты будешь в будущем исопльзолвать вот такие вот машины, за это он на них тебе сделает скидку, потому что эта информация позволит ему более эффективно выделять ресурсы остальным пользоывателям. Т.е. ты сначала "резервируешь" некие машины, а потом такие же создаёшь on-demand и получаешь небольшую скидку.
А третий вариант это использование "временно свободных" ресурсов AWS. Они выдаются лишь на время, причём неизвестное. Когда эти ресурсы понадобятся AWS'у он уведомит конкретный запущенный экземпляр (нужно самому постоянно опрашивать http://169.254.169.254/latest/meta-data/spot/termination-time) и через две минуты терминирует машину, после чего в другом (свободном) месте запустит такую же, только ничего не знающую о своих "предыдущих жизнях". Этот вариант может быть "_до 90% дешевле чем on-demand_" и отлично подходит для временных задач вроде сборки проекта или периодической обработки большого объёма данных. Ещё возможен режим когда ты устанавливаешь максимальную цену за машину и когда она первышает этот порог - Амазон останавливает или вообще терминирует твой инстанс. Настроек куча, нюансов ещё больше.
Для каждой запускаемой машины есть возможность выполнить некий скрипт при её первом запуске. Это называется **User data** и представляет собой скрипт для Bash или любого другого интерпретатора, присутствующего в системе на момент первого запуска. Этот скрипт запускается с правами супер-пользователя. Пример:
Этот скрипт не хранится непосредственно на инстансе, а подсовывается ему средствами встроенной Амазонвоской утилиты.
Вся информация об экземпляре может быть им получена запросом на http://169.254.169.254/latest/meta-data/ - в том числе и этот самый скрипт: http://169.254.169.254/latest/user-data
Экземпляр EC2 ("EC2 Instance") создаётся на основе "образа" виртуальной машины - есть набор готовых (разнообразные дистрибутивы Линукса, в том числе от самого амазона, даже Виндовс есть), а можно загрузить свой собственный образ от QEMU. Так же, можно создать образ на основе уже имеющихся машин (а можно и просто делать их "снапшоты", т.е. бэкапы).
##### EC2.Instances
Здесь отображается список созданных/запущенных экземпляров EC2. Отсюда же осуществляется управление ими: создание, перезапуск, остановка, удаление, изменение некоторых настроек.
##### EC2.Launch_Templates
Шаблон для создания экземпляра EC2. Избавляет от необходимости каждый раз вручную указывать все параматры (например, имя образа ОС, выделяемые ресурсы), имеет "версионность".
##### EC2.Volumes
Позволяет управлять жёсткими дисками экземпляров. Можно создавать дополнительные и подключать их к уже работающим экземпляроам EC2. Можно создать том сразу сраскатанным на него образом (например, бэкапом чего-то). Можно включить опцию шифрования данных.
##### EC2.Snapshots
Это бэкапы [томов](#EC2.Volumes). Из них можно создавать новые тома, а можно преобразовать в AMI (начальный образ для запуска экземпляра EC2).
##### EC2.Security_Groups
Это фаервол, по-сути такой же как и [VPC.Network_ACLs](#VPC.Network_ACLs). В чём разница - тема для диссертации.
##### EC2.Elastic_IPs
Просто ссылка на [VPC.Elastic_IPs](#VPC.Elastic_IPs).
##### EC2.Key_Pairs
Каждый экземпляр EC2 на Амазоне по умолчанию имеет SSH-сервер и дефолтного пользователя, которому добавлен один какой-то SSH-ключ, чтобы вы могли попасть на эту машину и провести необходимые действия "изнутри". Все ключи "хранятся" тут и из можно добавлять/удалять. А так же, при создании экземпляра EC2 можно вместо выбора уже имеющихся ключей прям там (в окне "создавания") создать новый ключ, приватную чатсь которого вам тут же будет предложено сказать (ссылка одноразовая и живёт всего пару минут).
##### EC2.Network_Interfaces
Показывет списолв всех сетевых интерфейсов, которые есть у всех экземпляров EC2. Можно добавить новый и затем "присоединить" его к одному из экземпляров, **НО**: все сетевый интерфейсы одного экземпляра EC2 должна принадлежать одной и той же подсети! (Так что я не понимаю, зачем машине более одного интерфейса:confused:)
##### EC2.Placement_Groups
"Группы размещения" позволяют задать особенности выделедния конкретных аппаратных ресурсов в датацентрах, например, выделять виртуалки на одном хосте, или на хостах в одной стойке, ну и так далее.
##### EC2.Load_Balancers
Наверное, самый интересный подраздел. :smirk:
Амазон имеет собственный "подсервис" для балансировки сетевых запросов к EC2 (и не только). Эти балансировщики есть трёх видов:
1. **Classic Load Balancer** - самый старый и не рекомендуемый к использованию.
2. **Network Load Balancer** - балансер уровня TCP/UDP. Сам может обсжуливать ==TLS== (таким образом снижая нагрузку на EC2)
3. **Application Load Balancer** - работает на уровне HTTP(S), тоже умеет в ==TLS==. Имеет дополнительные "фишки" вроде маршрутизации в зависимости от HTTP-маршрутов, заголовков. Позволет реализовывать "заглушки" (например, перенаправлять HTTP на HTTPS). Дешевле чем сетевой балансер.
Балансеры могут работать в двух режимах: ==internal== ("внутренний") и ==internet-facing== (принимает запросы из интернета).
Один балансер может обслуживать по одной подсети из нескольких зон доступности внутри только одного VPC (т.е. VPC только одно, зон доступнготси сколько угодно, в каждой из них толдько одна подсеть).
Сертификаты для балансеров могут храниться в двух местах: IAM (учётная запись пользователя) и ACM (AWS Certificate Manager). Самоподписанный сертификат можно загрузить только в IAM (в ACM он вроде как тоже загружается, но при этом балансер его в упор не видит). Так же, при использовании TLS нужно указать что-то типо режима:
Балансеру тоже назначается ["группа защиты"](#EC2.Security_Groups).
Главный параметр балансера это ["целевая группа"](#EC2.Target_Groups)
##### EC2.Target_Groups
Задаёт логическую группировку экземпляров EC2, которые принимают участие в балансировке. В параметрах целевой группые задаются параметры проверки "живости" каждой из машин - протокол, порт, таймаут, количество повторов.
"Цели" указываются либо по IP-адресу, либо как экземпляры EC2 (выбираешь их из списка).
На вкладке **Monitoring** можно посмотреть статистику "живости", разных запросов и т.п.
##### EC2.Auto_Scaling_Groups
Амазон имеет собственный подсервис для реализации горизонтального масщтабирования EC2. Работает это незамысловато: создаёшь группу масштабирования, указываешь сколько и каких нод в ней должно быть, указываешь условия для добавления/удаления нод (нагрузка на процессор/сеть/т.п.), указываешь [Launch Configuration](#EC2.Launch_Configuration) или [Launch Template](#EC2.Launch_Templates) (второе предпочтительнее) и далее _оно_ живёт само, стараясь блюсти гармонию между обслуживанием клиентов и потраченными деньгами. :relieved: (без всяких докеров/куберов и прочей нечисти)
При таком подходе только одно неудобство: [CI](https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BF%D1%80%D0%B5%D1%80%D1%8B%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B8%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B0%D1%86%D0%B8%D1%8F) - экземпляры EC2 запускаются на основе [шаблона](#EC2.Launch_Templates), в котором указан конкретный образ, так что при необходимости "обновить ПО" нужно сначала создать новый образ (AMI), затем создать новый шаблон запуска (можно на основе существующего) и затем отредактировать группу автомасштабирования, указав в ней новый шаблон автозапуска - после этого вновь запускаемые экземпляры будут иметь "новую" конфигурацию, однако уже запущенные останутся неизменными. Чтобы обновить все машины, нужно (как мне посоветовали в тех.поддержке) принудительно создавать события "добавить машину"/"удалить машину" (да, эти события можно генерить вручную, как бы эмулируя реальные события), таким образом поочерёдно старые экземпляры будут заменены новыми. :neutral_face: костыль, но иначе никак - разве что юзать [k8s](ru.wikipedia.org/wiki/Kubernetes) (ну или через SSH на каждой машине "ручками" обновлять нужные файлы, или же вообще использовать докер по SSH заставить его пересоздать контейнеры, используя новые версии образов).
Группа автомасштабирования может распространяться сразу на несколько подсетей (в том числе в разных регионах).
##### EC2.Launch_Configuration
Это как шаблон, только изначально было заточено под группы автомасштабирования. Сейчас рекомендуется именно шаблоны - ка кболее универсальное и, вроде как, удобное средство.
### Хранилища
#### EBS (Elastic Block Store)
ESB это, фактически, жёстий диск, который подключается к экземпляру EC2 и только к нему. Бывают двух типов: HDD и SSD (HDD удельно дешевле, но медленнее). Собственно, вот [оно](#EC2.Volumes).
#### EFS (Elastic File System)
EFS это NAS (сетевое хранилище данных), доступ к которому осуществляется с экземпляров EC2 посредством NFS (Network File System, версия 4). Доступ возможен только с Линукс-машин. Размер не ограничен. Оплата почасовая за каждый хранимый гигабайт.
#### S3 (Simple Storage Service)
S3 это NAS с HTTP(s)-интерфейсом. Посредством REST можно как скачивать файлы, так и загружать. Гибкая настройка правил доступа. Умеет хранить историю изменения файлов (по-умолчанию эта функция отключена).
Sign in with Wallet
Connect another wallet