• Бизнес тратится только на то что нужно для работы - капитальные вложения в инфраструктуру CAPEX (capital expense) превращаются в операционные расходы OPEX (operating expense) на облачные ресурсы.
• Экономия на масштабе - вместо покупки инфрастурктуры по ритейловым ценам облачные провайдеры предлагают более низкие цены за счет масштаба и специализации.
• Гибкое планирование. Необходимые ресурсы можно приобрести именно когжа они нужны и отказаться от них если они стали не нужны.
• Скорость и гибкость. Вместо заказа, покупки, исталляции и эксплуатаци собственной инфрастурктуры можно получить то же самое в пару кликов и за несколько секунд.
• Отсутствие затрат на датацентр, который надо строить, запитывать, охлаждать, мониторить и т.д.
• Глобальность и отказоустойчивость. Облачные провайдеры готовы предоставить ресурсы в тех регионах, где они нужны - максимально близко к пользователям, а также - обеспечить отказоустойчивость на уровне глобаьных регионов.

Cloud Computing выгодно отличается от банальной виртуализации:

• Развитые интерфейсы API для управления ресурсами
• Наличие инструментов CLI
• Возможность управлять более сложными ресурсами (базы данных, брокеры сообщений и т.д.), а не банальным виртуалкам.

• IaaS - Инфрастурктура как сервис. То есть предоставление доступа к виртуальным аппаратным ресурсам, хранилищам и сетям.
• Paas - Платформа как сервис. Предоставление ресурсов, решающих конкретные задачи в рамках решений работающих в облаке. То есть это managed базы данных, брокеры сообщений, объектные хранилища.
• SaaS - ПО как сервис. Это законченные решения, предоставляемые конечным пользователям. Например - Microsoft Office 365 или Google Workspace.

• Регион (AWS region) - это большой кластер датацентров в пределах географического региона.
• Зона доступности (Availability Zone) - это логически и физически сгруппированные датацентры в рамках региона. AZ удаленны друг от друга не более чем на 100 км для синхронной репликации.

Всего у AWS есть 77 зон доступности в 24 регионах (это наверное на 2021 год).
В каждом регионе есть две или более зоны доступности. Крупные регионы содержат до шести зон. Основным регионом считается N.Virginia - us-east-1. В нем сервисы появляются раньше всех.
Регионы позволяют:

• Разместить ресурсы ближе к конечным потребителям, тем самым уменьшив задержки.
• Обеспечить соотвествие местному законодательству в области хранения и обработки данных.
• Обеспечить отказоустойчивость.

Зоны доступности позволяют:

• Обеспечить отказоустойчивость в рамках региона (близкое расположение зон и хорошие каналы между ними позволяют использовать синхронную репликацию данных между сервисами в нескольких зонах).

Они расположены близко к регионам (но не зависят от них).
Используются для кеширования наиболее востребованных статических ресурсов.
В том числе - и для кеширования объектов выгружаемых/загружаемых из/в хранилищ(а) S3 (Amazon S3 Transfer Acceleration).
Также - существуют Region Edge Locations в рамках регионов, которые обладают большими объемами.

Объекты большинства сервисов привязаны к регионам. Например - если создается сервер или кластер базы данных, то при создании необходимо указать регион, а в дальнейшем указывать регион при обращении к данному объекту. Это связано с физической инфрастурктурой, задействованной в работе объекта.
Однако, есть и глобальные сервисы:

• AWS IAM - сервис управления учетными записями и привилегиями.
• Amazon Cloud Front - сервис CDN, используемый для доставки статичного контента. Запрашиваемы ресурсы динамически кешируются в наиболее близкой к потребителю локации.
• Amazon Route 53 - DNS-сервис
• Amazon S3 - бакеты в рамках сервиса привязаны к регионам, но сам сервис - глобален. То есть в консоли сервиса видны бакеты из всех регионов.

Сервисы размещаемые у заказчика (On-Premises) для создания гибридной инфраструктуры:

• Amazon Snow Family - SnowBall Edge Devices, SnowCone и Snowmobile. Это сервис перемещения данных от заказчика в облако AWS. Заказчику привозят дисковые корзины, на которые он копирует данные, а потом они физически уезжают в облако AWS. Также предоставляются некоторые вычислительные ресурсы, для анализа и необходимой обработки копируемых данных.
• Amazon Storage Gateway - по сути является кешем и предоставляет бесшовную интеграцию с облачным хранилищем S3. Приложения заказчика обращаются к Storage Gateway, а он - либо выгружает “холодные” данные на облако, тем самым расширяя доступный объем хранилища, либо, если скорости работы с облаком недостаточно - обеспечивает резервное копирование в облако.
• Amazon Outposts - это стойки 42U (немного меньше стандартных 48U) с оборудованием и софтом для управления, совместимым с облачным AWS, но размещаемые в датацентре заказчика. На этом оборудовании могут рабоать как просто машины EC2, так и хранилища, базы RDS, а также - Elastic Container Services (ECS), Elastic Kubernetes Services (EKS), Elastic MapReduce (EMR).

Только базовая поддержка по e-mail, в чатах и по телефону 24/7 при проблемах с аккаунтом, а также доступ к открытой документации и форумам.
Семь базовых проверок Trusted Advisor Tool. Мониторинг и оповещение через - Personal Health Dashboard

Рекомендуется для экспериментов и тестирования.
Базовая поддержка по технической части компонентов AWS и юзкейсам.
Только по e-mail в рабочее время.
Количество тикетов - не ограничено.
Время реакции - 24 часа для обычных вопросов и 12 часов для системных проблем. В остальном - то же что и в Basic-плане.

Рекомендуется для продукционных сред.
Техническая поддержка по e-mail, в чатах и по телефону 24/7.
Время реакции - зависит от проблемы, но, к примеру, если упала продукционная система, то можно ожидать поддежки от Cloud Engineer в течение часа.
Работа с проблемами взаимодействия между сервисами AWS и сторонним ПО.
За дополнительные деньги доступен инструмент Infrastructure Event Management, который позволяет проанализировать инфрастурктуру, оценить её готовность и выявить риски перед серьезными мероприятиями типа запуска в прод или миграциями.
Доступен полный набор проверок Trusted Advisor и рекомендаций по их мотивам:

• Cost Optimization
• Security
• Fault Tolerance
• Performance
• Service Limits

Начинается с $15000 в месяц.
Доступен персональный менеджер - Technical Account Manager (TAM), который активно мониторит состояние инфраструктуры и предлагает решения проблем.
Доступны Well-Archtected Review грамотными специалистами.
Техническая поддержка по e-mail, в чатах и по телефону 24/7.
Время реакции для business critical проблем - 15 минут.

Раньше была доступна на https://status.aws.amazon.com , а сейчаc редиректит на https://phd.aws.amazon.com
Показывает состояние сервисов во всех регионах.
Позволяет настроить какие-то реакции на события.

Amazon рекомендует создавать столько учеток, сколько необходимо. Для эффективнго управления учетками предуемотрен ряд инструментов.
Использование мультиаккаунтного подхода позволяет:

• Обеспечить административное разделение ресурсов для лучшего контроля и планирования.
• Обеспечить явную изоляцию ресурсов и исключить их взаимное автообнаружение.
• Устранить избыточные манипуляции с учетками пользователей. Например - вместо того, чтобы создавать отдельные дублирующие учетки пользователей в каждом проекте AWS, можно слить учетки всех пользователей в одну AWS Identity Management Account и раздавать права с помощью cross-account разрешений и политик.
• Обеспечить изолированные учетки для аудита или восстановления.

AWS Landing Zone - уже устаревший инструмент, замененный AWS Control Tower. Представляет собой гайдлайн для планирования и реализации лучших практик мультиаккаунтного окружения.

Данный инструмент позволяет создавать мультиаккаунтные окружения (landing zones) с помощью шаблонов, включающих следующие элементы:

• Собственно сама AWS Organization и многоучеточное окружение
• Настраивать SSO
• Федерацию различных каталогов с помощью SSO
• Централизованное логирование

Окружение, созданное с помощью AWS Control Tower использует рекомендуемые политики и подходы - guardrails.

AWS Organization - бесплатный сервис, для централизованного управления учетками.
Каждый инстанс сервиса AWS Organization содержит одну основную management (master) учетку и позволяет создать учетки пользователей.
Сходные по функционалу учетки могут быть объединены в Organization Unit и управляться как единое целое.
К OU-шкам (или отдельным учеткам) могут применяться Service Control Policies. котрые определяют конкретные права на ресурсы.

AWS Organization позволяет централизованно следить за расходами на ресурсы для каждой учетки отдельно и вцелом для всех учеток.
Отвественной за платежи является вляделец management-учетки.
Объединение счетов позволяет поользоваться скидками за большие объемы ресурсов.

Иерархия учеток (и распространения привилегий) строится на нескольких простых принципах:

• Политики примененные к OU-шке распространяются на вложенные элементы - OU-шки и учетки в них
• У каждой OU-шки может быть только одна родительская OU-шка.
• Каждая учетка может входить только в одну OU-шку.

Обязательно должны существовать пара OU-шек с учетками:

• Infrastructure Services - учетки для доступа к общим инфраструктурными сервисам - сетевым, репам образов и прочее.
• Security Services - OU-шка с учетками для доступа к логам и security-сервисам

Вообще - нихрена непонятно на первый взгляд. Надо почитать тут: https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/recommended-ous.html

AWS Free Tier Account - обычная стандартная учетка, которая имеет досступ ко множеству сервисов AWS бесплатно 12 месяцев с момента регистрации. С ограничениями по потребляемым ресурсам.
Также - есть доступ к ряду инструментов и сервисов:

• AWS Cloud Formation - сервис и тулзы для IaC.
• Amazon Elastic Beanstalk - сервис оркестрации, который создает и настраивает ресурсы (например - S3 и балансировщики) под нужды приложения. Разработчику достаточно залить код, а Amazon Elastic Beanstalk создаст необходимую для работы приложения инфраструктуру. Сам сервис - бесплатен, но ресурсы им создаваемые - нет!

Сервисы, в которых можно создавать бесплатные ресурсы (с учетом некоторых ограничений):

• Amazon CloudWatch - сервис для мониторинга ресурсов и приложений. Бесплытные - 10 метрик, 10 оповещений и миллион вызовов API.
• Amazon Lambda - бессерверные вычисления. Кода, запускаемый в ответ на события. Бесплатно - миллион вызовов API и 3.2 миллиона секунд машинного времени в месяц.
• AWS Organizations

Сервисы с бесплатным пробным 30-девным периодом:

• Amazon Workspaces - сервис VDI (Windows и Linux). Стандартный план предполагает две виртуалки 80GB на систему и 50Gb на данные. В месяц - 40 часов. Период - два месяца.
• Amazon Detective - сервис оценки и визуализации потенциальных проблем с безопасностью.
• Redshift - сервис хранения и анализа больших объемов структурированных и неструктурированных данных. 2 месяца триал включает ежемесячные 750 часов работы инстанса DC2.Large.

В иерархии IAM есть соедующие учетки:

• root user - основная учетка аккаунта. Не должна использоваться для повседнейвных операций.
• additional users - непривилегированные пользователи, имеющие набор привилегий, свойственный их задачам. А также - сервисные учетки для автоматизации.

Позволяет защитить учетки от подбора или воровства паролей.
Используют принцип - для аутентификации должны использоваться две сущности - одна которую пользователь знает (пароль), вторая - нечто что принадлежит пользователю и есть у него прямо сейчас (источник второго фактора SMS или OTP).
Управление вторым фактором происходит в разделе Secure Credentials.

Настраивают сложность паролей.
Настройки в разделе Account Settings (в меню справа в консоли IAM)

Подобны паре логин-пароль и используются для программного (из aws cli или SDK) доступа к платформе (в отличие от логина-пароля и второго фактора, используемых при доступе к web-консоли).
Каждая пользовательская учетка может иметь два access key.

Позволяют объединять пользовательские учетки в группы и назначать привилегии (привязывать политики) на группу, что имеет эффект на всех пользователей в группе.
Добавление пользователя в группу распространяет на него все политики. привязанные к этой группе.

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

Политики представляют собой json-документы.
Политики позволяют реализовать принцип “наименьших привилегий” (least privileges) и давать необходимый минимум прав.
Когда пользователь обращается к ресурсу, то IAM вычисляет результирующую политику для его учетки и ролей этой учетки и принимает решение о предоставлении доступа.
Шесть типов политик:

• Identity-based - эти политики привязываются к пользователям, группам и ролям и дают им права. Действуют в рамках аккаунта (то есть невозможно привязать политику к пользователю из другого аккаунта), однако - можно назначить роль пользователю из другого аккаунта. Таким образом - реализовать авторизацию внешних пользователей для доступа к ресурсам вашей учетки.
• Resource-based - политики привязываются к ресурсам. В них прописано какие пользователи (группы, роли) имеют доступ к данному ресурсу. Анонимный доступ - *.
• Permission Boundaries - привязываются к юзеру или роли и задают максимум привилегий, которе могут быть заданы с помощью Identity-based-политик.
• Organization Services Control Policies (SCPs) - задают максимальный уровень привилегий для пользователей в организации. Сами по себе не дают никаких прав, но задают максимально доступный ровень.
• Access Control lists - задают права для доступа к конкретным экземплярам ресурсов (например - бакетам S3) для внешних (не находящихся в данном аккаунте) пользователям и ролям. Похожи на Resource-based-политики, но задаваемый в ACL набор привилегий ограничен. ACL представляют собой не json-документы.
• Session Policies - позволяют дать прав конкретной сессии про программном доступе.

В свою очередь Identity-based-политики делятся на:

1. Managed AWS Policies - дефолтные политики, которые создает AWS и управляет ими. Задают типичные привилегии. КОнечные пользователи не могут их изменить.
2. Customer Managed Policies - политики, которые создает и редактирует пользователь.
3. Inline policies - политики, существующие как часть субъекта IAM (пользователя, группы или роли) и неотделимы от него. Эти политики существуют, пока существует субьект IAM.

{
  "Version": "2012-10-07",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}

• Version - всегда “2012-10-07”
• Statement - собственно список параметров (объектов и разрешений) политики
• Effect - что политика делает. Разрешает или Запрещает.
• Action - список действий.
• Resource - ARN ресурса (или вайлдкард как тут).

Может быть в форматах:

arn : partition : service : region : account-id : resource-id
arn : partition : service : region : account-id : resource-type/resource-id
arn : partition : service : region : account-id : resource-type : resource-id

• partition - Группа клиентов AWS. Для большинства стандартных клиентов - aws. Для Китая - aws-cn. Могут быть и другие
• service - название сервиса (продукта) AWS. s3 или acm и т.д.
• region - Регион, где существует данный ресурс. Для глобальных сервсов может быть и пустым, тогда заменяется на дополнительную :.
• account-id - 12-знаковый номер учетки, в которой создан ресурс. Может быть пустым, тогда заменяется на дополнительную :.
• resource-type - тип сесурса - user или instance и т.д
• resource-id - имя (идентификатор) ресурса
• Condition - дополнительные условия применения политики. Например - для ограничения доступа с определенных IP-адресов.

Тулза для проверки политик: https://policysim.aws.amazon.com
Там все просто:

• слева вибираешь пользователя, видишь привязанные к нему политики и можешь их включать/отключать
• справа выбираешь сервис и действие.
• жмешь Run Simulation, чтобы увидеть deny или allow

Пользовательские учетные записи - это идентификаторы, назначенные людям или сервисам (для программного доступа к ресурсам).
В то же время роли - могут рассматриваться как самостоятельный тип идентификаторов, имеющих собственный набор политик и привилегий. Роль может быть назначена субъекту для выполнения некоторых задач.
Например:

• Экземпляру сервиса AWS можно назначить роль для доступа к экземплярам других сервисов в пределах данного аккаунта. Например - инстансу EC2 для работы с базой данных.
• Пользователю из одного аккаунта можно назначить роль для доступа к ресурсам другого аккаунта.
• Учетной записи пользователи из внешних провайдеров (Active Directory LDAP, OpenID Google,facebook или Amazon) можно назначить роль и тем самым дать прав на заданные сервисы и ресурсы в аккаунте AWS. При этом создавать учетку пользователя в аккаунте AWS не нужно.

Одним из ключевых свойств ролей является автоматическая ротация учетных данных при доступе внешних пользователей к ресурсам.
Таким образом - исключается долговременное хранение учетных данных на клиентах и обеспечивается нужный уровень безопасности.
Данный функционал обеспечивает Security Token Service (STS), который выдает обновляемые короткоживущие токены при назначении роли, а также контролирует их прозрачное.
Временные учетные данные включают в себя:

• access key ID
• secret access key
• security token

Вот этот самый security token и есть обновляемая короткоживущая часть кредов.
При создании роли содается политика доверия (trust policy), которая описывает субъектов, имеющих право получить данную роль. Кроме того, субъект должен иметь разрешение на получение данной роли.
Использование ролей - предпочтительный способ назначения привилегий, вместо создания отдельных учеток для внешних пользователей.

AWS позволяет строить различные отчеты об учетных записях и выгружать их в CSV

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

Следует избегать использования root-учетки для работы с CLI, поскольку учетные данные в этом случае хранятся локально.

Надо скачать и установить отсюда: https://aws.amazon.com/cli/

После установки надо запустить:

aws configure

И предоставить следующие данные:

• access key ID
• secret access key
• дефолтный region

В итоге - эти данные попадут в файл ~/.aws/credentials:

[default]
aws_access_key_id = ...............
aws_secret_access_key = ............

В данном случае [default] - это имя профиля AWS. Их может быть несколько, а переключаться между ними можно задавая значение переменной AWS_PROFILE:

export AWS_PROFILE=another_profile

Amazon S3 - надежное объектное хранилище. Надежность на уровне “11 девяток”.
Объекты организованы в контейнеры - бакеты. Внутри контейнера струкрутры нет.
Имена бакетов должны быть уникальны в пределах всей инфраструктуры AWS.
Доступ к объектам (файлам) бакета может быть осуществлен одним из способов:

• Virtual hosted-style endpoints: https://___BUCKET_NAME___.s3.amazonaws.com/___FILE_NAME___
• Website endpoint: s3-website -(dash) Region (http://___BUCKET_NAME___.s3-website-Region.amazonaws.com/___FILE_NAME___) или s3-website .(dot) Region (http://___BUCKET_NAME___.s3-website.Region.amazonaws.com/___FILE_NAME___)

Максимальный размер объекта в Amazon S3 - 5Tb (терабайт).
Имя файла (объекта) обычно называется key, а его содержимое - value

• уникальны в пределах всей инфраструктуры AWS
• не менее 3 и не более 63 символов длиной
• могут содержать только маленькие буквы, цифры, точки и тире
• могут начинаться только с цифры или буквы
• не могут быть подобны IP-адресам (192.168.1.1 - не валидно)
• бакеты, доступ к которым происходит с помощью Amazon S3 Transfer Acceleration не могут содержать в названии точки.
• Бакеты не могут быть вложенными.

Точки в именах могут использоваться только при Web-style доступе, который осуществляется по незащищенному протоколу HTTP. Virtual hosted-style endpoints предполагает использование HTTPS и имена с точками не проходят через SNI. Если совершенно необходимо использовать точки в именах бакетов при доступе по HTTPS, то можно использовать какой-то балансировщик, который будет терминировать SSL. Например - Amazon Cloud-Front.

• длина до 1024 байт
• Могут содержать буквы, цифры и спецсимволы - !-_.*()

В интерфейсе есть кнопка Create folder, которая позволяет создать как-бы иерархию директорий в бакете, однако структура объектов всё-равно остается плоской.
Это достигается за счет использования префиксов (имен директорий) и разделителей / в именах ключей. То есть ключ (имя объекта в бакете) может содержать в себе привычную структуру директорий, которая отобразится в интерфейсе.

AWS ограничивает IOPS не на уровне бакета, а на уровне префиксов. То есть если вам доступны 5500 IOPS для методов GET/HEAD, то для получения скорости на уровне 27500 IOPS достаточно использовать 5 различных префиксов в именах ключей.

При создании бакета обяхательно указывать регион, где данные физически будут расположены.
AWS НИКОГДА не реплицирует данные в другие регионы. Физически данные всегда в том регионе, где создан бакет. Однако, пользовватель может настроить репликацию в другой бакет в другом регионе.

По дефолту - права на объекты в бакете есть только у создавшей его учетки.
Основных способов раздачи прав на объекты S3 два:

• resource-based-политика (bucket-policy)
• Списки доступа (ACLs)

Также ограниченно могут использоваться IAM-политики.
Deny - всегда сильнее, чем Allow. Но взаимоисключающими не являются.

JSON-документ.
Раздает права (в том числе и анонимный доступ) как на саму корзинку, так и на объекты в ней.
Могут давать права юзерам и ролям из других аккаунтов.

Считаются legacy и вместо них всегда лучше использовать политики.
Не могут давать доступ отдельным юзерам (только аккаунту целиком).
Есть случаи, когда ACL всё еще используется

На первый взгляд - могут использоваться для раздачи прав на ресурсы S3. Однако - не могут быть привязаны напрямую к ресурсу.
Вместо этого - следует создавать роль, давать ей права на ресурсы S3, создавать политику доверия (чтобы пользователь мог принять роль).
Также - IAM-политики не могут использоваться для раздачи анонимного доступа, так как всегда должны быть привязаны к какому-то субъекту (айдентити).

различаются по следующим параметрам:

• Скорость доступа
• Постоянная/непостоянная доступность
• Стоимость

Стоимость в свою очередь определяется параметрами:

• Стоимость собственно хранения (в долларах в месяц за гигабайт)
• Количество запросов на запись/извлечение
• использование ускорения доставки
• использование обработки и аналитики, в том числе и Lambda-функциями
• возможность потери части данных

Стоимость закачки данных В S3 - бесплатно!
важно понимать, что в пределах одного бакета могут храниться объекты на хранилищах разных классов. То есть создавать для каждого класса отдельный бакет не нужно.

• Amazon S3 Standard - дефолтный класс. Обеспечивает 11 девяток надежности и 4 девятки доступности. Данные реплицируются как минимум на три зоны доступности в регионе.
  

Хранение стоит дешевле, однако есть плата за извлечение. Минимальный размер обхекта - 128kB (То есть даже пустой файл занимает 128kB).

• Amazon S3 Standard Infrequent Access (S3 Standard IA) - для хранения важных, но нечасто нужных данных. Идеальны для бекапов или Disaster Recovery
• Amazon S3 One Zone Infrequent Access (S3 One Zone IA) - Данные хранятся только в одной AZ в регионе. Доступность падает до 99.5%. Если в зоне проблемы - данные могут быть некоторое время недоступны. Теоретически - возможны безвозвратные потери. Рекомендуется для вторых бекапов и восстановимых данных.

Не предполагают мгновенного доступа к данным, а доступ по запросу - извлечение может занимать от нескольких минут, до 12 часов и более.

• Amazon Glacier - для долговременного хранения и нечастого достап по запросу. Данные подготавливаются в течение нескольких часов (до 12).
• Amazon Glacier Deep Archive - самый недорогой способ хранения старых данных. Извлечение может занимать 12 часов и более.

Класс хранилища Intelligent Tiering мониторит частоту обращений к обектам и делает следующее:

• Если объект не запрашивался 30 дней - его класс хранения изменяется на более дешевый Standard IA
• Опционально можно подключить и архивные классы хранения. Объекты не запрашиваемые 90 дней - переезжают в Amazon Glacier. А после 180 дней - Glacier Deep Archive.

Amazon Outposts - 42U стойки с железом на площадке заказчика с AWS-совместимым набором управляющего софта.
При использовании аутпостов доступен еще один класс хранения - S3 Outposts.
S3 Outposts позволяет:

• хранить от 48 до 96 терабайт данных
• до 100 бакетов на 1 аутпост

Защита от случайного (нежелательного) удаления/изменения объектов.

• По дефолту - выключена. Включается на уровне бакета для всех объектов в нем.
• При загрузке нового объекта с именем уже существующего - старый помечается как предыдущая версия, а новый - как текущая.
• При удалении - фактически объект помечается как удаленный специальным маркером, но не удаляется. Для восстанволения - нужно просто удалить маркер.
• Версионирование может быть выключено (дефолт), включено или включено, но приостановлено.

После включения версионирования - выключить его невозможно. Но можно приостановить.

Асинхронная репликация данных между бакетами бывает двух видов:

• Cross-Region Replication (CRR) - для обеспечения лучше йдоступности данных или отказоустойчивости
• Same-Region Replication (SRR) - для аггрегации данных из нескольких бакетов в один или репликациями между окружениями (dev - prod)

Для работы репликации должно быть включено версионирование.
Реплицировать можно как бакеты одного аккаунта, так и между аккаунтами. Также - реплика может иметь другой класс хранения.
Можно реплицировать из одного бакета во многие. И наоборот - из многих - в один.

Механизм оптимизации стоимости хранения данных.
Может быть применен к бакету или просто набору объектов с помощью префикса.
Настраиваются правила. Два типа действий:

• изменение класса хранилища в зависимости от востребованности данных
• удаление, когда данные остаются невостребованными по истечение некоторого срока

Данные могут храниться в зашифрованном виде.
Шифрование может происходить как на стороне клиента, так и на стороне сервера Amazon S3.
При шифровании на стороне клиента - все заботы о шифровании/дешифровании лежат на клиенте.
при шифровании на стороне сервера возможны три взаимоисключающих механизма:

• Server-side Encryption with Amazon S3 Managed Keys - SSE-S3. Каждый объект шифруется уникальным ключем, а ключи в свою очередь шифруются master-ключем. AWS автоматически управляет ключами и ротирует их.
• Server-side Encryption with Customer Managed Keys - SSE-CMKs. Ключи хранятся в AWS Key Management Service (SSE-KMS). То же самое, что и SSE-S3, только можно управлять ключами и аудировать их использование.
• Server-side Encryption with Customer Provided Keys - SSE-CPKs. Amazon S3 шифрует данные с помощью предоставленных клиентом ключей. Идеально для соотвествия регуляторным требованиям.

Файлики можно хостить на S3, предоставляя к ним анонимный доступ.
Таким образом можно хостить как просто файлы, так и целые сайты.

Позволяет ускорить доступ клиентов к объектам в AWS S3 с помощью Amazon Cloud Front Edge Locations - точек доступа к AWS S3 (как на аплоад, так и на скачивание).

Хранит данные в виде архивов zip или tar.
В одном архиве может быть либо один либо несколько объектов.
Размер одного архива - до 40 ТБ (при том что один объект может быть размером до 5ТБ).

Программное решение (виртуалка). Таже доступно в виде предконфигурированного физического сервера.
Обеспечивает прозрачный доступ к данным на инфрраструктуре AWS S3.
Виртуалки устанавливаются на стороне заказчика, а для доступа к данным серверы заказчика обращаются по протоколам:

• NFS/SMB
• Virtual Transport Layer (VTL)
• iSCSI

Сам Amazon Storage Gateway подключается к AWS S3 через интернет с помощью IPSec VPN или AWS Direct Connect. Сценарии использования:

• File Gateway - позволяет обращаться к файлам по протоколу SMB/NFS. Данные также кешируются локально. Хранятся либо в AWS S3, либо - Amazon FSx.
• Volume Gateway - позволяет создавать тома, доступные по iSCSI. Может работать в режимах Cache mode, когда локально хранятся только “горячие данные” остальное ассинхронно реплицируется на S3. Stored Mode - все данные тома хранятся локально и ассинхронно реплицируются на S3 для бекапа. Tape Gateway - предоставляет интерфейс к виртуальным ленточным библиотекам для бекапов (которые лежат на S3).

Иногда данных много и залить их через интернет в облако невозможно.
Тогда на помощь приходят продукты Snow Family

Программно-аппаратные комплексы двух видов:

• SnowBall Edge Computing Optimized - для обработки данных перед миграцией. 52vCPU, 208Gb Ram, опционально Nvidia Tesla, 42Tb HDD, 7.68 SSD.
• SnowBall Edge Storage Optimized - чисто для данных. 80Тб HDD, 1Tb SSD, 40vCPU, 80Gb RAM

Малленький девайс. 2 кг. 8Тб диск, пара ядер CPU и 4 Gb RAM.

Для эксабайтных масштабов.
Приезжает 45-футовый защищенный контейнер.
До 100 Петабайт данных. С полной технической поддержкой миграции.

AWS VPC - это виртуальная облачная сеть.
Область действия VPC - в пределах Региона AWS. То есть ресурсы могут размещаться в любой AZ региона.
При создании VPC нужно задать один из диапазонов адресов для частных сетей.

Внутри VPC должны быть созданы подсети с непересекающимися диапазонами адресов.
То есть если VPC назначен CIDR 10.0.0.0/16, то подсети могут иметь CIDR - 10.0.1.0/24 и 10.0.2.0/24 .
Каждая подсеть существует в пределах одной зоны доступности (AZ).

У дефолтных VPC и подсетей доступ в интернеты есть.
Чтобы у кастомных VPC был доступ в интернет - должен быть задеплоен шлюз (internet gateway) и соответствующие маршруты.
С публичными адресами история такая:

• автоматически назначаемые публичные адреса нестатичны и могут меняться после рестарта машины.
• если динамические публичные адреса не подходят, то нужно прописывать Elastic IP Address

• Статичные. Существуют пока существует аккаунт.
• Могут быть переданы от одного инстанса EC2 к другому.
• Бесплатны, но только пока запущена машина EC2 с этим адресом. Если инстанс остановлен - за адрес взымается почасовая оплата.

Обеспечение безопасности - одна из основных функций VPC.
Достигается - правилами файерволов, отделяющих одни подсети от других.
Имеются два механизма реализации безопасности:

• Security Groups
• Network Access Control Lists (NACLs)

Это наборы правил файервола для входящего и исходящего трафика, которые привязываются к инстансам EC2.
Работают именно на уровне инстансов, но не подсетей.
К каждому инстансу должна быть привязана хотя бы одна Security Group.
Максимум можно привязать пять Security Group к одному инстансу EC2.
Дефолтные Security Group разрешают любые исходящие подключения, а входящие подключения только от инстансов с такой же Security Group.
Важно понимать, что Security Groups являются statefull, что означает что если разрешен входящий трафик к какому-то сервису, то автоматически разрешается и ответный (исходящий) трафик сервиса, независимо от явно заданных исходящих разрешений.
Несколько важных свойств Security Groups:

• Конфигурируются только правила allow. Правил deny просто нету.
• Отдельные правила для входящего и исходящего трафика.
• Трафик фильтруется по протоколам и портам.
• В правилах в качестве source/destination могут быть заданы как диапазоны IP-адресов, так и другие Security Groups

Это другой тип правил файервола - ограничивает трафик к целым подсетям.
По-дефолту - разрешено всё, поскольку ограничения действуют на уровне Security Groups
Не являются statefull, что означает необходимость явно конфигурировать как правила для входящего трафика к сервисам, так и ответного исходящего от сервисов.

Для предоставления доступа в интернет для инстансов, работающих в непубличных (не имеющих прямой связи с интернетом) сетях используется NAT.
Сервис NAT должен быть помещен в публичную сеть и иметь Elastic IP.
Должны быть сконфигурированы соответсвующие маршруты.
Если инстансы используют IPv6, то доступ в интернет для них настраивается с помощью egress-only internet gateway.

Для быстрого взаимодействия между сервисами из разных VPC можно настроить VPC peering.
В этом случае - трафик не ходит через относительно медленный интернет, а ходит по быстрым и надежным внутренним каналам AWS.
Пиринг может быть настроен как между VPC в одном аккаунте, так для VPC из разных аккаунтов. Как в пределах одного региона, так и между регионами.

Если число взаимодейтсвующих VPC больше двух, то сетевая топология может быть довольно сложной.
Для ее упрощения существует VPC transit gateway, реализующий топологию “звезда”.

К инфраструктуре AWS можно подключить on-premise ресурсы с помощью IPSec VPN.
Для этого надо создать и настроить Virtual Private Gateway и подключить его к VPC.
На стороне on-premise поддерживаются различное оборудование - Cisco, Juniper, Check Point и прочие.
После настройки собственно канала - нужно настроить маршруты.
Существует аппаратное ограничение на скорость зашифрованного IPSec VPN - 1.26 Gbps.

Способ подключения on-premise инфраструктуры AWS по выделенным каналам.
Это дорого и круто - прокладывается оптика до ближайшего узла партнеров Amazon Direct Connect.
Доступны скорости подключения до 100 Gbps.

Основные функции AWS Route53:

• Регистрация доменных имен
• DNS-роутинг
• Health-чеки

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

Для создания DNS-записей, указывающих на ресурсы надо создать Hosted Zone.
Hosted Zone - это контейнер для хранения записей и управления ими.
Существует два типа зон AWS Route53:

• Public hosted zone - зоны доступные из интернета и предназначены для роутинга входящего трафика из интернета.
• Private hosted zone - частные зоны доступные только внутри VPC.

При создании ресурса он получает DNS-имя, которое доступно с помощью Amazon Route53 Resolver.
Существуют два типа DNS-записей ресурсов:

• Private DNS hostnames - указывают на приватный IP-адрес ресурса внутри VPC. Имеют вид - ipv4-private-address.ec2.internal (в us-east-1) и ipv4-private-address.region.compute.internal (в остальных регионах).
• Public DNS hostnames - указывают на публичный IP-адрес ресурса в интернете. Имеют вид - ipv4-public-address.compute-1.amazonaws.com (в us-east-1) и ipv4-public-address.region.compute.amazonaws.com (в остальных регионах).

• Simple routing policy - один ресурс, одна запись. Состояние ресурсов не контролируется
• Failover routing policy - Одна запись указывает на несколько (основной и резервные) экземпляры ресурсов, а их состояние контролируется health-чеками. Схема Active-Passive
• Geolocation Routing Policy - При поступлении DNS-запроса от клиента - по его IP определяется его географическое положение и он направляется на блжайший к нему ресурс.
• Latency Routing Policy - маршрутизация на основе сетевых задержек. Позволяет обеспечить доступ к ресурсам с минимальными задержками.
• Weighted routing policy - позволяет направить указанные доли запросов на заданные ресурсы. Используется для регулирования нагрузок при миграциях.

Проверки состояния ресурсов.

• Проверки состояния эндпонитов. Мониторят указанный эндпоинт (DNS-имя или ip-адрес)
• Проверки состония других health-чеков. Проверка общего состояния пула ресурсов. Позволяют задать пороговые значения доступности для группы эндпоинтов и выполнять действия, если количество работоспособных эндпоинтов ниже заданного.
• Реакция на события CloudWatch - Cloudwatch может мониторить метрики приложений (например - количество доступных инстансов за балансировщиком). В свою очередь - Route53 может мониторить тот же поток данных, что и CloudWatch и независимо от него реагировать (например - помечать ресурс как unhealthy в зависимости от количества доступных метрик). Для реакции даже не обязательно, чтобы CloudWatch переходил в состояние Alarm - Route53 анализирует данные и автономно.

Политики роутинга могут быть довольно сложными.
Например - можно по Latency роутить трафик между несколькими регионами, затем - по Weighted между инстансами.
Каждая такая конфигурация - является собственно политикой траффика, которая создается с помощью визуального редактора Route53.
Важно понимать, что политики трафика Route53 могут быть созданы только для публичных DNS-зон.
Дополнительно к основным политикам доступны следующие:

• Geoproximity routing policy - роутинг трафика в зависимости от географического расположения ресурсов и клиентов.
• Route53 Resolver - позволяет создавать правила и форвардить запросы получаемые Route53 DNS на DNS-серверы on-premise.

Amazon CloudFront предоставляет инструменты для организации динамической сети распространения контента CDN.
Запрашиваемые объекты доставляются с помощью Edge Locations (и кешируются там), расположенных наиболее близко к клиенту.
Для включения этого функционала надо создать distribution endpoint и задать источник (бакет S3, инстанс ec2, балансер) и тип контента.
В результате получится URL (HTTP или HTTPS), который можно отдавать пользователям.
Контент может быть:

• статика (HTML, CSS, JS, картинки)
• Видео в различных форматах
• Live-контент - видеоконференции и прочее.

Стоимость дистрибуци трафика зависит от качества инфраструктуры в регионе.

• Дефолтный и самый дорогой класс дистрибуции - глобальный, когда контент может быть кеширован на любом из существующих EdgeLocation.
• Второй по стоимости класс включает только регионы USA,Canada, Europe, Hong Kong, Philippines, South Korea, Taiwan, Singapore, Japan, India, South Africa, Middle East.
• Самый недорогой класс включает только регионы - USA, Canada, Europe.

Managed-сервис для создания быстрых и безопасных API, предоставляющих доступ к облачным ресурсам - базам данных, микросервисам, Lambda-функциям и прочим.
API создается путем описания высокроуровневых абстракций.

Инстансы делятся на:

• семейства (family) - по типу нагрузки. Например - general-purpose
• В пределах семейства существуют типы (types) - определяющие конкретные свойства предоставляемого аппаратного обеспечения. Например - T2 или M5
• В пределах каждого типа доступны разные размеры (sizes) - определяющие конкретные объемы предоставляемых ресурсов. Например - t2.micro (1vCPU, 1GiB RAM) или t2.xlarge (4vCPU, 16GiB).

Инстансы привязаны к конкретным зонам доступности (AZ). То есть при создании инстанса нужно указать подсеть VPC, которая как раз и привязана к AZ.
Каждый инстан может иметь:

• один или несколько дисков (томов) EBS (Elastic Block Storage)
• один или несколько сетевых адаптеров (NICs)

При создании инстанса используеся какой-то образ ОС - Amazon Machine Image (AMI).

• General Purpose - сбалансированные конфигурации для различных нагрузок.
• Compute Optimized - для высокопроизводительных вычислений. HPC.
• Memory Optimized - оптимизированы для нагрузок, активно использующих оперативную память.
• Accelerated Computing - инстансы с аппаратными ускорителями (GPU и другие).
• Storage Optimized - оптимизированы для нагрузок, требующих больших объемов и постоянной высокой пропускной способности локального хранилища.

Также доступны выделенные виртуалки и хосты - Dedicated Instances и Dedicated Hosts. Они нужны для соответствя регулятивным нормам, когда недопустима работа ПО на разделямых аппаратных ресурсах.

• Dedicated Instances - виртуалки, работающие на хосте, который используется только одним заказчиком.
• Dedicated Hosts - хост, используемый только одник заказчиком. Может быть полезен, когда прикладное ПО лицензируется на каждый процессор или сокет.

AMIs - образы дисков виртуальных машин.
Бывают двух типов:

• снепшот диска EBS
• целиком инстанс (Instance). Например AMI macOS будет в виде аппаратного Mac-mini.
  

Если в составе AMI есть лицензируемуе ПО, то стоимость лицензии входит в стоимость эксплуатации инстанса.
AMI существуют в пределах региона. То есть если нужно создать инстанс с заданным AMI - то этот AMI должен существовать в этом регионе. Однако - AMI можно копировать между регионами.
Источники AMI:

• AWS Marketplace - образы, поддерживаемые AWS. В том числе и от внешних вендоров - Citrix, F5, Oracle и других. Стоимость инстанса складывается из стоимости собственно аппаратуры инстанса EС2 и стоимости лиценции ПО.
• Community AMIs - образы, соданные сообществом. Поставляются as-is.
• Можно создавать свои AMI для быстрого разворачивания и распространять их.

Тома подключаются к инстансам как правило по iSCSI.
Тома независят от инстансов и могут быть отсоединены и присоединены к другому инстансу.
Можно создавать снепшоты. Первый - полный, последующие - инкрементные. Снепшоты можно копировать между регионами и между аккаунтами.

Есть две категории дисков EBS:

• SSD - ориентированы на высокие IOPS
• HDD - могут дать высокую линейную скорость.

В свою очередь SSD также имеют типы:

• gp2 - дефолтный тип. Подходит для большинства нагрузок. Размеры - от 1GB до 16TB. До 16000 IOPS. Надежность 99.9%. Минимальный уровень производительности - 3 IOPS/GB, минимум - 100IOPS, Масимум - 3000 IOPS для томов меньше 1TB.
• gp3 - более новая версия general-purpose томов. Обеспечивает 3000 IOPS и 125MB/s для томов любого размера. За дополнительную плату можно получить 16000 IOPS. Размеры - от 1GB до 16TB. Отлично подходит для SQL-баз данных.
• io1 - Быстрые SSD-диски. Размеры - от 4GB до 16TB. От 50 IOPS/GB, до 64000 IOPS. До 1000 MB/s. Максимум производительности достижим для инстансов на базе AWS Nitro.
• io2 - последняя версия SSD EBS томов. 100X надежности (99.999%) и 10X производительноси - 500 IOPS/GB Размеры - от 4GB до 16TB. Хорош для любых высоких нагрузок. До 64000 IOPS и 1000 MB/s для инстансов на базе AWS Nitro.
• io2 Block Express - 4X относительно io2. 4000 MB/s, 256000 IOPS, 1000 IOPS/GB. Размеры - от 4GB до 16TB.

HDD представлены типами:

• st1 - low-cost HDD. При базовой производительности 40 MB/s на 1TB, могут выдавать до 250 MB/s на 1 TB объема. Максимальная скорость - до 500 Mb/s. Размеры - от 125GB до 16TB. Не могут быть загрузочными томами. Типичные нагрузки - MapReduce, Kafka, логи и прочее.
• sc1 - Cold HDD. Самый медленные и дешевые тома. В базе выдают 12 МB/s на 1 TB объема. До 80 MB/s на 1 TB. Максимальная скорость - до 250 Mb/s. Размеры - от 125GB до 16TB. Не могут быть загрузочными томами.

Еще один тип хранилища - instance store представляет собой временный диск, размещенный на локальном диске фзического хоста, на котором работает инстанс EC2.
При выключении машины - этот том уничтожается, а при старте - снова создается (поскольку машина практически никогда повторно не стартует на том же хосте).
Такми образом - instance store - это временное хранилище, обеспечивающее минимальные задержки, по сравнению с EBS (который всегда SAN).
Важно понимать, что перезагрузка инстанса не приводит к уничтожению ланных на instance store, поскольку в этом случае машина остается запущенной на прежнем хосте и не переезжает на новый.
Надежность instance store - не гарантируется.

Принципы ценообразования:

• On-Demand - дефолтная опция. Почасовая оплата за время работы инстанса. При прочих равных - самый дорогой вариант, в случае использования 24*7*365.
  
• Reserved Instance - дает большие скидосы (до 72% по сравнению с On-Demand). Фактически - это ценовое соглашение, которое дает право на запуск инстанса оговоренной конфигурации в заданном регионе течение оговоренного срока (1 или три года) по зафиксированной сниженной цене. Как только запускается инстанс подходящий под параметры соглашения - на него действует оговоренная в соглашении цена. Само заключние соглашения предполагает некоторую плату, независимо от того создаются ли подподающие под него инстансы или нет.

Для Reserved Instance доступны две опции:

• Standard Reserved Pricing - самые крупные скидки (до 72%) на срок 1 или 3 года. Некоторые параметры инстансов можно менять - AZ, размер, тип сети.
• Convertible Reserved Pricing - скидки до 54%, по сравнению с On-Demand. Можно менять семейство машинок, ОС и другие параметры.

Также - для Reserved Instance доступны скидки в зависимости от предоплаты:

• All Upfront - оплата за весь срок соглашения вперед.
• Partial Upfront - частичная оплата вперед с последующей сниженной почасовой.
• No Upfront - без оплаты вперед, с почасовой оплатой, но по-прежнему с некоторыми скидками относительно On-Demand.

Ненужные Reserved-инстансы можно перепродать на Reserved Instance Marketplace (только Standard Reserved). Также, если нужен инстанс на срок меньше стандартный 1 или 3 года - можно подыскать его на маркете. Для продажи инстанса на маркете он должне быть оплачен быть во владении не менее 30 дней.

У AWS есть резервные EC2 инстансы, не задействованные в данный момент, которые можно использовать с большой (до 90%) скидкой.
Недостатком использования этих инстансов является то, что они могут быть остановлены в любой момент (по мере роста потребности в On-Demand инстансах).
При остановке инстанс раньше мог быть только удален, но теперь появились и другие опции - выключение или гибернация.
Цены устанавливаются фактически по правилам аукциона. То есть при создании такого инстанса есть текущая цена и задается максимальная цена, которую клиент готов платить за инстанс. Если потреность в инстансах растет и текущие цены превышают заданную максимальную - инстанс останавливается.
По мере падения спотовых цен - при достижении максимальной цены - инстанс снова запускается.
Таким образом - спотовые инстансы могут быть остановлены в трех случаях:

• Масксимальная цена, предложенная клиентом, становится ниже актуальной спотовой.
• Доступность инстансов - все инстансы могут быть востребованы On-demand.
• Ограничения - недоступность инстансов в конкретной AZ.

Пред остановкой, за 2 минуты, Amazon CloudWatch генерирует Event, который может быть обработан Lambda-функцией или Amazon SimpleNotifications (SNS).

AWS EFS позволяет создавать файловые хранилища, подключаемые к инстансам по сети. Основные фичи:

• Использование в качестве разделяемого централизованного файлохранилища для инстансов EC2 на базе Linux
• Доступны для On-Premise серверов через VPN или AWS Direct Connect.
• Могут быть увеличены или уменьшены по запросу без потери данных.
• Тома EFS привязаны к региону. То есть доступны из любой AZ в регионе.
• Не могут быть использованы в качестве загрузочных томов.
• Н могут быть использованы инстансами EC2 на базе Windows

Amazon Lightsail - это полностью сконфигурированные VPS со всем необходимым на борту для какой-то задачи:

• WordPress
• Drupal
• LAMP
• etc…

Деплоится легко и быстро, имеет фиксированную стоимость в месяц (от $3.5 за 1vCPU, 512MiB RAM, 20Gb SSD и 1TB трафика в месяц). Также доступны и дополнительные опции - статические IP, DNS, доступ по SSH/RDS и прочее.
Можно сделать снепшот и проапгрейдить Lightsail до стандартного EC2-инстанса.

AWS ECS - сервис запуска Docker-контейнеров в облаке.
Терминология:

• ECS Cluster - логическая группа EC2-инстансов на которых крутятся контейнеры. Существует в пределах региона на нескольких AZ.
• ECS Container Instances - EC2-инстансы, на которых работает Docker и Tasks (контейнеры).
• Task - контейнер.
• Task Definition - описание параметров запуска контейнера. Образ, ресурсы, сеть, IAM-роли.
• Elastic Container Registry (ECR) - хранилище образов.
• ECS Service - задает необходимое количество работающих экземпляров каждой Task и перезапускает их по мере надобности.

• Amazon Fargate - позволет развернуть ECS-инсталляцию без необходимости настройки отдельных EC2-инстансов. То есть просто упаковыевется приложение, указываются необходимые ресурсы (CPU, память и прочее), а дальше Fargate полностью берет на себя все заботы о запуске, масштабировании и дальнейшем управлении инстансами кластера и приложением.
• EC2 - Если надо управлять инстансами самостоятельно. Настраивать, апгрейдить и прочее.

Managed-кластеры k8s.
При создани кластера выбирается тип EC2-инстансов для worker-нод.
После создания кластера нужно установить необходидмые addons - CNI (calico), LoadBalancer Controller для публичных IP-адресов, возможно - Ingress (nginx).

Само понятие Serverless для клиента означает отсутствие необходимости взаимодествия с серверами, и их ОС. Клиент просто предоставляет код для запуска, а AWS обеспечивает и настраивает всю инфраструктуру, необходимую для его исполнения.
AWS Lambda - это Function as a Service.

• клиент создает код функции на одном из поддерживаемых языков (Python, Node.js и прочие) и загружает в AWS Lambda
• создает триггер, который в ответ на событие или по расписанию будет запускать Lambda-функцию

Например - по событию загрузки изображения на S3 - триггер запускает Lambda-функцию, которая добавляет ватермарк и выгружает в другой бакет.
Или - по расписаню включать и выключать EC2-инстансы.
Оплата AWS Lambda - только за время фактической работы.

Используется для запуска большого (тысячи) количества вычислительных заданий.
Вся работа по инициализации вычислительных ресурсов (инстансы EC2 или ECS) выполняется автоматически.
Оплаа - за фактически использованные ресурсы.

Средства создания гибридных облаков.

Предоставляет доступ к managed файловой системе Lustre, которая способна обеспечить миллионы IOPS и пропускную способность в десятки гигабайт в секунду.
Интегрируется с Amazon S3 для организации долговременного хранения.

Managed файловые шары с поддержкой SMB для Windows-инфрастурктур.
Поддердивает AD и DFS.

Для уменьшения поверхности атаки применяются Bastion Hosts и Session Manager.

• Bastion Hosts - это специально настроенные EC2-инстансы, которые используются исключительно для доступа к инстансам в приватных сетях. Доступ к самим jump-хостам может ограничиваться по диапазону адресов или с помощью VPN.
• Session Manager - это консоль в браузере, для работы которой не надо открывать порты на Security Groups и управлять SSH-ключами. Действия администраторов записываются для дальнейшего аудита.

Amazon дает возможность создавать managed-базы данных. традиционные реляционные (RDS) или неструктуриованные NoSQL.

Поддерживаются шесть движков БД:

• MySQL
• PostgreSQL
• MariaDB
• Microsoft SQL Server
• Oracle
• Amazon Aurora

При создании инстанса:

• выбирается тип EC2-инстансов кластера - это влияет на производительность
• создается кластер (одно- или многонодовый), в котором можно создать одну или несколько БД

Инстансы могут быть:

• Стандартные (m-класса). Подходят для большинства нагрузок. От 2 до 96 CPU, до 384 GiB RAM
• Memory-optimized (r и x-классы) - Подходят для нагруженных приложений. От 4 до 128 CPU. До 3904 GiB RAM.
• Burstable (t-классы) - Для непродукционных БД. Обеспечивают базовый уровень производительности с возможностью кратковременных всплесков нагрузки. От 1 до 8 CPU, до 32 GiB RAM

EBS-тома могут быть:

• General Purpose SSD - подходит для большинства БД. От 20GiB до 64TiB (до 16TiB для MS SQL). IOPS зависят от объема. Минимум - 100 IOPS, дальше - по 3 IOPS на GiB. То есть 60GiB покажут 180 IOPS. Тома меньше 1TiB кратковременно дают повышенную производительность (burst) при необходимости.
• Provisioned IOPS SSD - Рекомендованный тип. Объем - до 64 TiB. Необходимый уровень IOPS задается вручную. Bust - нету.
• Magnetic - легаси. Не рекомендовано. До 1000 IOPS и до 3TiB объем.

Можно апгрейдить тип хранилища, но это может потребовать кратковременной остановки БД.

• Инстанс Amazon RDS существует в рамках региона.
• Деплоится в существующий VPC, в заданную подсеть в заданной AZ.
• Кластеры RDS являются Active-Passive. То есть Master-нода, которая пишет данные - всегда одна.
• Доступ к инстансу RDS регулируется с помощью Security Groups и NACLs

Сценарии поключения к инстансу Amazon RDS могут включать:

• Подключение в рамках VPC. Настраивается Security Group на порт инстанса.
• Подключене из другого VPC (другой регион, другой аккаунт). Настраивается VPC Peering (VPC Transit Gateway) и правила Secuity Groups
• Подключение через интернет. Инстанс RDS размещается в публичной подсети. Небезопасно.
• Из частной on-premise сети. Через VPN или Direct Connect

Для выбора оптимальной стратегии резервирования важно определить два параметра:

• RTO (Recovery Time Objective) - допустимое время восстановления после отказа.
• RPO (Recovery Point Objective) - допустимые потери данных в результате сбоя.

Например - нужно восстановиться за 1 час (RTO) и потерять данные записанные в БД не более чем за 2 часа (RPO).
Логично, что чтобы реализовать RPO 2 часа нужно делать бекапы каждый 2 часа.

Классический кластер Active-Passive:

• В двух AZ расположены master-нода и standby-реплика. Репликация - синхронная.
• При выходе из строя master-ноды - происходит автоматический переход роли master к реплике. Во время перехода - возможно отсутствие доступа к БД (до двух минут).
• Старый master уничтожается, вместо него поднимается новая нода - копия реплики. Запускается репликация.

Таким образом можно снизить RTO и RPO практически до нескольких минут.
Переключение между master и standby нодами может быть полезно и в случаях необходимости технических работ на master-ноде (апгрейд, изменение конфигурации).

• Amazon RDS выполняет автоматическое регулярное резервное копирование через заданные интервалы времени в заданные для этого “окна”.
• Механизм создания резервных копий - снепшоты. Первый - полный, последующие - инкрементные.
• Retention - определяет количество хранимых копий. от 1 до 35 дней. 0 - значит бекапы выключены.
• AWS RDS чрез заданный интервал (обычно 5 минут) сохраняет на S3 логи транзакций. Таким образом - с помщью бекапа и логов транзакций можно восстановить состояние БД на любой момент (в пределах retention) с точностью до заданного интервала (LastRestorableTime)

Полезно перед масштабными изменениями в БД.

Можно включить репликацию бекапов в другой регион, на случай серьезного дизастера.

При создании снепшота БД в конфигурации, когда есть только одна master-нода, может происходить “замирание” ввода-вывода на несколько секунд.
Это стоит учитывать при выборе “окна” для создания резервных копий.
В конфигурации Multi-AZ такого не происходит, поскольку снепшот для бекапа снимается со standby-ноды

В кластере Active-Passive запросы обрабатывает только master-нода. Обратиться к standby-ноде невозможно - она только реплицирует данные и ждет дизастера.
Если необходимо - для повышения производительности можно настроить ноды-реплики “только для чтения”.

• Они пригодны для приложений, которые не пишут в БД. Например - аналитика.
• Репликация - Ассинхронная. То есть возможны задержки в обновлении данных, относительно боевого мастера.
• Возможна репликация в другие регионы.
• Для каждого инстанса AWS RDS можно настроить до 5 read-only реплик
• Read-only реплику при необходимости можно промотировать до полноценной master-ноды.

Amazon Aurora - проприетарная разработка Amazon.
Эта БД совместима с MySQL и PostgreSQL, но в пять раз быстрее, чем MySQL и в три раза быстрее, чем PostgreSQL
отказоустойчивая конфигурация - минимум три ноды (в разных AZ).
Объемы БД - до 128TiB
Репликация - до 15 read-only реплик.
Деплоится в виде DB-кластеров, в котором используются два типа инстансов, а также общее хранилище - cluster volume (размещенный на нескольких storage-nodes в нескольких AZ):

• Primary DB instance - операции чтения-записи. Только этот инстанс может писать в cluster volume. Может быть только одна.
• Aurora replica - только для чтения, до 15 штук.

Доступна как в классическом серверном варианте, так и serverless

• Автоматическое масштабирование кластера в зависимости от нагрузки.
• Данные всегда зашифрованы
• Идеально подходит для приложений с непредсказуемой нагрузкой

• Fully-Managed бессерверная NoSQL БД.
• Существует в рамках региона.
• Динамически подстраивается под нагрузку.
• Расчитано на миллионы записей и тысячи запросов в секунду.

• Таблицы (Tables) - Подобны таблицам в SQL-базах. Также есть Primary Key, который должне быть уникальным в пределах таблицы.
• Items - аналогичны записям в SQL. В таблице может быть один или больше Items, каждый состоит из какого-то количества аттрибутов (attributes). Размер Item - до 400KB.
• Аттрибуты (attributes) - Пары ключ-значение (key-value). Ключи - подобны названиям колонок в SQL.

В отличие от SQL - не нужно заранее определять схему и типы данных в колонках.
Ключи (за исключением Primary) можно добавлять/удалять в любой момент.
Значения ключей могут иметь следующие типы:

• Scalar - Просто значение. Строка, число, двоичная строка, булево значение или null.
• Set - Набор скалярных значений. Наборы строк, бинарных строк, набор чисел.
• Document - JSON-структура, которая может включать вложенные аттрибуты. Документы могут быть двух типов: JSON List и JSON Map.

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

• RCU (read capacity units) - единицы производительности на чтение
• WCU (write capacity units) - единицы производительности на запись

Дальше - в зависимости от значений Amazon определит необходимые параметры инстанса.
Доступны две опции:

• On-Demand - динамическое выделение ресурсов в зависимости от нагрузки
• Provisioned - для предсказуемых нагрузок. Задается предполагаемое количество операций чтения и записи в секунду. Всегда можно включить auto-scaling, для адаптации к текущей нагрузке.

Предназначен для извлечения данных из других (реляционных) БД и построения аналитики по созданным датасетам - OLAP operations (OnLine Analitical Processing).
Клиентам Amazon такде доступно BI-приложение (business intelligence).
Является колоночной (column storage) БД (в противовес реляционным, где каждая запись - ряд). Это позволяет при чтении снизить количество операций IO в три раза, по сравнению с реляционными БД.
Архитектура - кластер:

• Leader node - выделенная нода, через которую происходит взаимодйствие с БД RedShift. Компилирует код запросов и распределяет задания по вычислительным нодам.
• Compute node - до 128 нод в кластере. Получают задачи, отправляют назад результаты. Бывают трех типов:
  • Dense compute nodes - До 326TB данных на HDD
  • Dense storage nodes - до 2PB на SSD
  • RA3 instances - новое поколение на базе Nitro. Используют managed storage (в отличие от предыдущих). Хранилища отделены от вычислителей, в свою очередь хранение горячих данных - на локальных SSD, холодных - на S3. Поата - только за фактически использованный объем.

Сервис реализующий SQL запросы к данным, хранимым в AWS S3.
Например - у вас много нечасто нужных данных в S3.
Вместо того, чобы импортировать их в дорогостоящие инстансы RedShift и затем обращаться к ним - можно сразу обращаться к данным в S3.

сервис кеширования горячих данных в памяти.
Доступны два варианта:

• Amazon Elasticache for Redis - кластер из одной ил нескольких кеш-нод. Для кеширования сложных объектов. Умеет Multi-AZ, шифрование, отказоустойчивость
• Amazon Elasticache for Memcached - Для кеширования простых объктов (типов данных).

Fully managed БД Графов
Хранит данные в виде нод, их аттрибутов и связей между ними.
Поддерживает многие широко применяемые модели:

• Property Graph
• W3C's RDF

И языки:

• Apache TinkerPro
• Gremlin
• SPARQL

Применяется при анализе “больших данных”:

• фрод детекш
• графы знаний
• исследование лекарств
• сетевая безопасность

Fully Managed Blockhain от Amazon.

• Неизменный и прозрачный. Непрерывный журнал транзакций.
• Криптографически валидируемый.
• Простой в использовании. Язык PartiQL
• Серверлесс - необхоимые для текущей нагрузки мощности выделяются автоматически.

Сервис для миграции on-premise БД в облако. Поддерживаются как гомогенные миграции - MySQL → MySQL, так и гетерогенные - Oracle → MS SQL или MS SQL → Amazon Aurora.
Во время миграции БД остается работоспособной, уменьшая даунтайм.
Может использоваться для непрерывной репликации on-premise БД в облако для отказоустойчивости.

• Вертикальная и горизонтальная масштабируемость
• Модель Open System Interconnection (OSI)
• Балансировка трафика с помощью Amazon Elastic Load Balancing (ELB)
• Реализация эластичности с помощью AWS Auto Scaling
• Проектирование мультирегиональных отказоустойчивых решений.

Вертикальная - апгредим ресурсы инстансов.
Горизонтальная - увеличиваем количество инстансов

• требует остановки инстанса
• может занимать много (часы) времени
• не обеспечвает отказоустойчивости

• повышает отказоустойчивость
• может быть реализована автоматически

Ну что про нее сказать - она самая!!!

ELB - работает в пределах региона и не может балансировать между регионами.
В качестве бекендов могут выступать:

• инстансы EC2
• IP-адреса
• контейнеры
• Lambda-функции
• и прочие сущности…

• Любой ELB рекомендуется размещать более чем в одной AZ. В таком случае - в каждой AZ будет нода балансировщика (load balancer node), которая будет распределять трафик по инстансам в этой зоне.
• Если есть ELB, то размещать инстансы в публичных сетях нет необходимости. Клиенты ходят только через ELB.

Балансировщики ELB бывают двух видов:

• Internet-facing load balancer - доступен в internet, имеет DNS-имя.
• Internal load balancer - балансируют ресурсы внутри приватных сетей VPC.

Для того, чтобы инстанс ELB мог принимать запросы - для него должна быть настроена соответствующая Security Group с правилами для входящих подключений.
Для того, чтобы инстанс ELB мог обращаться к бекэнд-серверам - для них должна быть настроена соответствующая Security Group с правилами для входящих подключений.
Типы балансировщиков:

• Application Load Balancer (ALB)
• Network Load Balancer (NLB)
• Gateway Load Balancer (GWLB)
• Classic Load Balancer (CLB)

Это L7-балансировщик (application layer).
Работает с протоколами HTTP и HTTPS.
Поддерживает:

• Path-based роутинг - для распределения запросов в зависимости от URI в запросе
• Host-Based роутинг - для распределения в зависимости от содержимого заголовка HOST в запросе
• Множество приложений на одном EC2 инстансе
• В качестве бекэндов могут выступать Lambda-функции и контейнеры и многое другое

Состоит из:

• listener - сервис, который на иснове правил респределяет запросы. Правил может быть одно или более.
• target groups - группы (одна или более) инстансов (или контейнеров, Lambda-функцй и т.д.), на которые listener направляет запросы.

Поддердивается проверка состояния бекэнд-инстнсов в target groups
Неработоспособные инстансы удаляютяс из баланссировки до момента восстановления

ALB интегрируется с WAF, который фильтрует поступающие запросы для защиты от типичных атак:

• SQL-инъекции
• cross-site-scripting (XSS)
• и других

Балансировщик L4 - балансирует как TCP, так и UDP протоколы.
Свойства:

• Обеспечивает очень низкие задержки.
• Интересен тем, что может сохранять IP-адрес клиента во входящих запросах.
• Поддерживает статические и elastic IP-адреса (по одному на AZ).
• В качестве target-ов выступают IP-адреса, а значит можно балансировать и ресурсы вне VPC, например - on-premise
• Одн инстанс NLB позволяет балансировать различные ресурсы/протоколы, принимая подключения на разных портах.
• Поддерживаются приложения в контейнерах (Amazon ECS)

Amazon GWLB выступает в качестве единой точки входя для траффика, который должен быть проанализирован различными внешними инструментами (файерволы, IDSes/IPSec - intrusion detection/prevention). Инструменты доступны на Amazon Marketplace в виде virtual appliances.

• Работает на третьем (Layer 3) модели OSI
• С IPSec/IDSec-приложениями взаимодействует по протоколу GENEVE (Generic Network Virtualization Encapsulation) на порту 6081
• Является statefull-сервисом, то есть трафик ходит как к IPSec/IDSec-приложениям, так и от них.

CLB - первая реализация балансировщика в AWS.

• Не подходит для продукционных задач, но пригоден для тестирования, либо - для приложений, использующих EC2-Classic network mode
• Работает на 4 и 7-уровнях OSI
• Не предоставляет всех функций ALB, либо производительностb NLB.
• Балансирует трафик по EC2-нодам в предалх региона (на одну AZ либо на многие)

Эластичность - предполагает автоматическое масштабирование облачных ресурсов по мере роста/уменьшения нагрузки.
Масштабирование происходит в ответ на события, например - это превышение/уменьшение значений каких-либо метрик (например - загрузка CPU), либо - таймер.
Auto Scaling - это региональный сервис, который работает с метриками и EC2-инстансами в пределах региона AWS.

Для реализации автоматического масштабирования настраиваются Auto Scaling Groups - они описывают коллекцию (fleet) EC2-инстансов и параметров масштабирования:

• Минимальное число EC2-инстансов в группе.
• Желательное (desired) число инстансов в группе. Сервис будет всегда стремиться автоматически поддерживать это число EC2-инстансов.
• Максимальное число EC2-инстансов в группе. Нужно для избежания ненужных расходов, например - в случае бага в ПО, который приводит к бесполезной высокой нагрузке на CPU.

Сервис Auto Scaling выполняет автоматические health-чеки (выполлянемые через ELB или самим AutoScale) и реагирует на их результаты действиями, прописанными в политиках масштабирования.

Для настройки AWS Auto Scaling создаются либо Launch Template, либо - Launch Configuration - спецификации EC2-инстансов:

• Образ Amazon Machine Image (AMI)
• тип инстанса (конфиг железа)
• SSH-ключи для доступа к инстансу
• Спецификации Block Storage
• Скрипты для провижининга EC2-инстансов (bootstrapping). Это скрипты на Bash либо PowerShell

Чем отличаются Launch Configuration и Launch Template:

• Launch Configuration - это первая реализация шаблонов с параметрами инстансов. В настоящий момент не рекомендованы к использованию. Шаблон может быть использован в нескольких AutoScale Groups, но в пределах одной AutoScale Group может испрльзоваться только одна Launch Configuration. После создания Launch Configuration изменить ее параметры нельзя, а можно только пересоздать её.
• Launch Template - актуальная реализация шиблонов для AWS Auto Scale. Аналогичен Launch Configuration, однако может иметь несколько различных версий, содержать базовый шаблон и несколько дополнительных на разные случаи, запускать как On-Demand, так и спотовые инстансы, запускать различные конфигурации инстансов. Также - поддерживает новые фичи типа ESB volumes gp3 и io2, ESB volume tagging, elastic inference, Dedicated Hosts.

Масштабирование триггерится в ответ на события. Это все настраивается в политиках масштабирования (scale policy):

• Поддержание заданного числа инстансов. Вышедшие из строя инстансы удаляются и заменяются на свежие.
• Масштабирование вручную
• Масштабирование по расписанию.
• Динамическое масштабирование (по требованию). В ответ на значения метрик.

В свою очередь динамическое масштабирование может быть таким:

• Слежение за целевыми показателями - Target Tracking Scale policy. Пытается поддерживать значение заданной метрики на заданном уровне.
• Пошаговое (не плавное) масштабирование (Step scaling) - количество подключаемых дополнительно EC2-инстансов зависит от фактического превышения значения метрики над заданным. Чем больше превышение, тем больше шаг масштабирования.
• Простое масштабирование (simple scaling) - масштабируемся до заданного размера в зависимости от значения одной метрики.
• Масштабирование с предсказанием (Predictive Scaling) - масштабирование на основании предсказания уровня нагрузки, запланированных (scheduled) действий, превышения максимальной емкости - когда можно настроить автоматичсекое увеличение максимального разрешенного количества инстансов, в зависимости от условий.

Эффективные механизмы обеспечения высокодоступных решений - Amazon ELB и Amazon Auto Scaling - работают только в пределах региона AWS.
Однако, обеспечить высокую доступность на случай выхода из строя целого региона можно с помощью Amazon Route 53 и Amazon Cloud Front.

• Amazon Route 53 позволяет настроить мультирегиональную active/passive-конфигурацию с помощью failover-роутинга
• В запасном регионе может работать минимум EC2-инстансов, обеспечивая подхват нагрузки, если health-чеки основного региона на Amazon Route 53 покажут, что он сдох. А также - политики AWS Auto Scale, которые промасштабируют инфраструктуру при возрастании нагрузки.

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

• app-to-app (A2A) messaging - передачи сообщений между приложениями
• app-to-person (A2P) messaging - передачи сообщений от приложений к пользователям
• проектирования event-driven приложений
• связи сервисов в бессерверных инфраструктурах

Сервисы AWS для интеграции приложений включают в себя:

• Amazon Simple Notification Services (SNS) - сервис простых push-сообщений сервисам или непосредственно пользователям
• Amazon Simple Queue Services (SQS) и Amazon MQ - сервисы очередей сообщений
• Amazon EventBridge - сервис для построения event-driven приложений
• Amazon Step-Functions и Amazon Simple Workflow Service (SWF) - для организации приложений на основе бессерверной инфраструктуры

Это сервис для push-сообщений сервисам или непосредственно пользователям.
Работает по принципу издатель/подписчик (publisher/subscriber). Каждый издатель может отправить сообщение одному или нескольким подписчикам.
Пример использования - необходимо получать оповещения о загрузке объектов в S3.

• настраиваются оповещения S3 event notifications на событие s3:ObjectCreated:*
• Создается SNS topic, в который отправляются эти оповещения
• На даный топик создается подписка, с e-mail адресом

В результате - при заливке объектов в S3 на почту приходит сообщение. Это A2P.
В качестве подписчика пожет выступать Lambda-функция, которая может что-то делать с загруженным объектом. Это A2A.

Для получения сообщений подписчики должны предоставлять один из заданных типов эндпоинтов.
A2A Endpoints:

• Amazon SQS - сообщение в очередь сообщений.
• HTTP(S) - сообщение в какой-то REST API
• AWS Lambda - сообщение Lamda-функции
• Amazon Kinesis Data Firehose - сообщения могут быть переданы в S3, Elasticsearch, RedShift или куда-то еще

A2P Endpoints:

• e-mail
• SMS на мобилку
• мобильные push-сообщения

Чтобы сообщение было доставлено - нужно создать topic, куда издатель (publisher) его отправит и на который подпишутся подписчики (subscribers).
Для издателей настраиваются политики доступа к топикам - то есть в примере в S3 - бакету нужно дать права с помощью IAM-политики на публикацию сообщений в топике. Политика назначается на топик.
Правила наименования топиков:

• до 256 символов
• могут содержать дефисы и подчеркивания

ARN выглядит так: arn:aws:sns:eu-west-2:123456789789:new-object-upload-alert

• Standard - дефолтный тип. Используется, когда порядок доставки сообщений и возможные дубли - не важны. Поддерживаются все протоколы.
• FIFO - Обеспечивают строгий порядок доставки сообщений без дублей. Поддерживается только эндпоинтами Amazon SQS.

Amazon SNS Fanout - это механизм репликации сообщений множеству подписчиков.
Работает - параллельно и ассинхронно.
Реализуется с помощью Amazon Kinesis Data Firehose
Пример - нужно чтобы сообщения от Lambda-функции, которая обрабатывает заказ билета передавались Lambda-функции, которая обрабатывает платеж и далее - в Amazon Redshift для истории.

• Lambda-функция продажи билета отправляет сообщение в SNS topic.
• Сообщение реплицируется в две точки - очередь SNS и Amazon Kinesis Data Firehose.
• Из очереди сообщений - его забирает Labmda-функция обработки платежей.
• Amazon Kinesis Data Firehose передает сообщение в кластер RedShift. Путь такой - сначала данные копируются в бакет S3, а затем - выполняется команда Amazon RedShift COPY

Платим только за сообщения.

• Standard topics - платим за вызовы API в месяц. Например - мобильные push-сообщения - $0.5 за миллион сообщений в месяц. Объем сообщений - до 256KB, для мобильных SMS - 64KB.
• FIFO topics - платим за всё - за опубликованные сообщения, за доставленные сообщения и за объем переданных данных.

Брокеры очередей сообщений Amazon SQS и Amazon MQ - позволяют перейти от монолитных приложений к микросервисам. Amazon SQS и Amazon MQ представляют дополнительный высоконадежный слой взаимодействия между элементами приложений, что в итоге позволяет:

• посылать и обрабатывать сообщения в/из очереди независимо
• ассинхронно
• масштабировать разные элементы приложения независимо

Пример сценария, использующего Amazon SQS - приложение конвертирующее видео-файлы в разные разрешения и форматы:

• Пользователи заливают файлики на web-серврах, количество которых автоматичсеки масштабируется в зависимости от нагрузки
• Файлы попадают в бакет S3
• При появлении нового файла сообщение с помощью Amazon SNS отправляется в несколько очередей Amazon SQS в режиме Fanout
• Очереди SQS хранят сообщения до момента, когда они будут прочитаны одним из серверов приложений
• Сервера приложений читают сообщения, в которых указано какой файл и в какой формат нужно сконвертировать
• Файлики конвертируются и складываются куда надо

В то время,как Amazon SNS является источником push-событий, Amazon SQS - это pull-based платформа, где чтение сообщений инициируется серверами приложений.
Сообщения в amazon SQS могут храниться некоторое время (дефолт 4 дня, до 14 дней).

• Standard queue - поддерживают практически неограниченное количество API-запросов в секунду (SendMessage, ReceiveMessage, DeleteMessage) и предназначены для сообщений, которые должны быть доставлены хотя бы один раз. Не исключены дубли. Порядок доставки сообщений - не гарантируется. Глубина очереди не может превышать 120 000 записей.
• FIFO queue - исключают дубли и порядок доставки. Скорость - до 300 сообщений в секунду. Более высокие скорости достиживмы в пакетом режиме - до 3000 сообщзщений в секунду (пачками по 10 сообщений).

Сообщения в Amazon SQS могут быть зашифрованы с помощью ключей Amazon KMS (Key management Service).

Платим только за сообщения и взаимодействия с S3 и KMS.

RabbitMQ-совместимый брокер сообщений.
Ориентирован на клиентов, мигрирующих в облако. Не имеет других преимуществ перед Amazon SNS и Amazon SQS, которые предпочтительны для новых приложений.
Поддерживает API JMS и протоколы:

• AMPQ 0-9-1
• AMPQ 1.0
• MQTT
• OpenWire
• STOMP

Amazon EventBridge - это шина событий, для обработки сообщений поступающих в реальном времени и реакции на них.
Amazon EventBridge - это новая версия инструмента, ранее называвшегося Amazon CloudWatch Events.
В качестве обработчиков могут выступать:

• AWS Lambda
• Kinesis
• HTTP(S) эндпоинты
• шины событий в других аккаунтах
• SNS топики
• таски ECS
• SQS-очереди

События генерируются в ответ на изменение состояния ресурса (например - EC2-инстанса, события AutoScale).
Amazon EventBridge путем создания правил, описывающих шаблоны событий и таргеты, куда будет отправлено оповещение.
Amazon EventBridge может запускать действия по таймеру.
В отличие от Amazon CloudWatch Events, который имел только одну дефолтную шину событий (для событий AWS и кастомных), Amazon EventBridge позволяет создавать кастомные шины, который могут быть выделены для обработки катомных событий от приложений. Также Amazon EventBridge поддерживает интеграцию с внешними приложениямитакими как ZenDesk, PagerDuty, Datadog.
Терминология Amazon EventBridge:

• События (Events) - изменения состояния ресурсов (приложений, AWS-ресурсов, внешних приложений).
• Правила (Rules) - шаблоны событий, которые подлежат обработке. Содержат также шаблоны JSON-данных, отправляемых в обработчик (target)
• Обработчики (targets) - Реагируют на события и выполняют действия.
• Шины событий (Event Buses) - они (дефолтная и кастомные) получают события от источников и содержат правила и обработчики.

Это еще два сервиса, реализующие взаимодействие между компонентами приложений, позволяющие создавать бессерверные решения.

Amazon Step Functions - связывают различные элементарные обработчики данных (Lambda-функции, контейнеры ECS) в единый WorkFlow.
Amazon Step Functions - позволяют описывать и визуализировать workflow прикладных задач в виде отдельных блоков - конечных автоматов, называемых states, каждый из которых на входе получает даные, в том числе и интерактивно от пользователя, а затем принимает решение на их основе и передаёт дальше по цепочке следующему state или внешнему обработчику типа Lambda-функции.
State бывают следующих видов:

• Success or Fail state - остановка/продолжение обработки в зависимости от входных данных
• Wait State - ожидание в течение заданного времени
• Parallel State - создание параллельных ветвей исполнения
• Map State - осуществляется обработка списка входящих параметров
• Choise state - выбор ветки исполнения на основе входящих данных
• Task state - выполнение обработки анных с помощью других сервисов AWS, например - Lambda-функций

Amazon Step Functions используют JSON-объекты Amazon State Language (ASL) для описания конечных автоматов.

• Standard workflow - предполагает однократное исполнение, подходит для интерактивных задач, может длиться до 1 года. Оплата - за каждый переход от одного state к следующему. Предоставляют доступ к истории исполнения и визуальный отладчик.
• Express Workflow - Подходят для автоматических задач. Исполнение в течение максимум 5 минут. Оплата - за количество и длительность исполнения. История исполнений передается в Amazon CloudWatch

Amazon SWF - еще один, наряду с Amazon Step Functions сервис компоновки сложных задач из элементарных обработчиков (workers), работащих на инстансах EC2 или on-premise.
Основное отличие Amazon SWF от Amazon Step Functions - это способ описания workflow.

• Amazon Step Functions - это простое декларативное JSON-описание взаимодействия между обработчиками внутри AWS.
• Amazon SWF - предполагает написание программы на любом языке, которая получит состояние предыдущего обработчика и передаст следующему. Позволяет использовать внешние, сервисы.

Amazon Kinesis - fully-managed сервис для немедленной обработки данных по мере их поступления.
Включает в себя 4 основых сервиса:

• Amazon Kinesis Data Firehose
• Amazon Kinesis Data Streams
• Amazon Kinesis Data Analytics
• Amazon Kinesis Video Streams

Amazon Kinesis Data Firehose - по функционалу напоминает Logstash от Elastic, но не обеспечивает кеширования.
Amazon Kinesis Data Firehose - сервис для приема данных и передачи их в:

• Сервисы Amazon - S3, RedShift, Elasticsearch
• Внешние сервисы - DataDog, New Relic, MongoDB, Splunk

Amazon Kinesis Data Firehose позволяет:

• выполнять пакетные операции над поступающими данными - сжатие, преобразование, шифрование. Это снижает общую стоимость обработки и хранения.
  
• преобразовывать в открытые форматы - Apache Parquet, Apache ORC

Оплата - только за количество обработанных данных. Без резервирования и предоплат.

Amazon Kinesis Data Streams - real-time сервис для получения и стриминга данных в кастомные приложения (Lambda-функции или AWS S3). В отличие от Amazon Kinesis Data Firehose, который ориентирован на стриминг данных в хранилища.
Свойства Amazon Kinesis Data Streams:

• Типичное время обработки сообщения - 70ms
• высокая доступность - собираемые данные реплицируются в три AZ.
• в отличие от Amazon Kinesis Data Firehose, Kinesis Data Streams может хранить собранные данные от дефолтных 24 часов, до 7 (retention) или даже 365 (long term retention) дней.
• предназначен для - real-time дашбордов, детектинга аномалий, анализа цен в реальном времени
• транзакции обрабатываются в шардами, количество которых опредеяет доступную скорость обработки. Производительность каждой шарды - на чтение до 5 транзакций, до 2 MB данных на шарду в секунду. На запись - до 1000 сообщений, до 1MB данных в секунду.
• Оплата - почасовая за зарезервированные шарды (пропускную способность), независимо от того, используются ли все зарезервированные шарды или нет

На первый взгляд может показаться, что Amazon SQS и Kinesis Data Streams абсолютно одинаковые, однако это не так. Amazon SQS - это слой взаимодействия между компонентами приложений, очередь сообщений, с издателями и подписчиками. А Kinesis Data Streams - это просто стриминг сообщений, аналог logstash с резервируемой и гарантированной пропускной способностью, а также хранением при необходимости.

Сервис построения приложений для анализа данных, собираемых Amazon Kinesis Data Streams или Managed Streaming for Kafka (MSK).
Позволяет использовать стандартные способы обращения к БД - с помощью языков Java, Python, Scala, SQL, а также отрытого фреймворка дял потокой обработки данных - Apache Flink.
Для разработки приложений потоковой обработки доступна среда Kinesis Data Analytics Studio.

Amazon Kinesis Video Streams - сервис хранения, каталогизации, воспроизведения и анализа видеопотоков.
В качестве хранилища использует S3.
Amazon Rekognition - сервис анализа видеопотоков для выявления объектов, лиц, сцен, текста, изображений.
Например - можно организовать стриминг с камер возле дверей домов, распознавать людей, которые стучатся в дверь и уведомлять пользователей.

Часто, данные выгружаются на S3 потому что они нужны нечасто и держать их в одной из баз Amazon RDS или NoSQL нецелесообранзно.
Для быстрого и удобного доступа к таким данным используется fully-mnaged бессерверный сервис Amazon Athena, который позволяет выполнять SQL-запросы к данным хранящимся на S3.
Формат хранения данны на S3 может быть как структурированным, так и неструктурированным - CSV, JSON, ORC, Apache Parquet.
Кроме того, Amazon Athena предоставляет драйвер JDBC для взаимодейтсия с популярными BI-приложениями.
Процесс доступа предполагает создание (автоматически или вручную) базы данных и таблиц с даными на основе метаданных, которые указывают Amazon Athena формат данных на S3.
Результаты запросов могут быть выгружены на S3.

OpenSearch - это Managed-сервис от Amazon реализующий все прелести Elasticsearch. Используется свой дистрибутив - OpenDistro
Доступны Kibana и Logstash.
OpenSearch может получать данные из Amazon Kinesis Data Firehose, Amazon CloudWatch Logs, и AWS IoT

Сервисы для объединения данных из различных источников - БД, стримингов, S3 и прочих.

Amazon Glue - это serverless managed ETL-сервис (Extract, Transform, Load).
Он позволяет извлекать, преобразовывать и загружать данные из обних хранилищ в другие, тем самым объединяя и обогащая данные.
Amazon Glue содержит Data Catalog - центральное хранилище метаданных, которое хранит сведения о данных (например - опредения таблиц).
Для обнаружения данных и сбора сведений об их структуре и типах используется crawler.
Crawler сканирует источники, обнаруживает данные и сохраняет информацию о них в Data Catalog.
Затем - собранные метаданные используются для построения ETL-скриптов, преобразующих данные в нужные форматы.
Для работы с Amazon Glue используется AWS Glue console которая может:

• Создавать определения Glue-объектов (jobs, crawlers, tables и прочих)
• Планировать запуски crawler'ов
• Определять тригеры для запуска job'ов
• Искать и фильровать объекты в Glue
• Редактировать ETL-скрипты

Биллинг - на основании ресурсов и времени их использования, почасовой (с посекундным разрешением), а также на основании количества использованного места для хранения метаданных в AWS Glue Data Catalog.

.

Fully Managed, serverless BI-сервис для формирования и публикации интерактивных BI-дашбордов.
Может использовать данные из сервисов AWS, БД on-premises, из сервисов SaaS и B2B-данные.
Дашборды могут быть использоваться как на PC, так и на мобильных девайсах.
QuickSight интегрируется с ML-сервисами (ML Insights) для глубокого анализа, выявления отклонений и аномалий в данных.
Также - итоги анализа могут быть сформулированы обобщены в виде описания на естественном языке.
Биллинг - по числу пользователей этих дашбордов.

AWS EMR - это managed Hadoop framework.
Может использоватьс с инструментами Apache Spark, Apache Hive, Apache HBase, Apache Flink, Apache Hudi и Presto.
Включает в себя свою IDE - EMR Studio., которая поддерживает разработку на R, Python, Scala и PySpark.
Рабочие нагрузки можно запускать на EC2-инстансах и в кластерах k8s - AWS EKS, а также on-premises с помощью AWS Outpost.
Биллинг - за каждый инстанс, посекундный с минимальным интервалом использования 1 минута.

web-сервис для автоматизации переноса и преобразования данных из различных источников (on-premise и других) в сервисы AWS (S3, RDS, DynamoDB, EMR).
Например - настроить автоматическую архивацию логов web-сервера в S3 и затем - запускать EMR-job для анализа и генерации репортов.

Managed-сервис для организации поиска в web-приложениях.
Поддерживает 34 языка и разные сложные поисковые запросы для поиска по сайтам.

В даном разделе рассматриваются:

• Деплоймент приложений с помощью Amazon Elastic Beanstalk
• Infratructure As A code с помощью Amazon CloudFormation
• Оркестрация конфигураций с помощью Chef и Puppet на базе AWS OpsWorks
• Автоматизация с помощью AWS Lambda

Сервис Amazon Elastic Beanstalk позволяет полностью автоматически выполнять:

• создание и конфигурацию инфраструктуры для приложений
• Масшатбирование
• настройку балансировщиков
• настройку мониторинга

Подерживаются приложения на следующих языках:

• Go
• Java
• .NET
• Node.js
• PHP
• Python
• и некоторые другие

Amazon Elastic Beanstalk полностью обеспечивает создание и настройку инфраструктуры, также поддердиваются контейнеризированные прилжения.
В процессе разворачивания инфраструктуры можно задавать ее параметры - типы инстансов EC2, их количество, а также параметры автоскейлинга, а после разворачивания - можно менять параметры и апдейтить приложение.

• Environment - это все инфраструктурные компоненты, которые создает Elastic Beanstalk во время деплоймента. Каждый environment может исполнять только одну версию приложения, а для работы нескольких версий одновременно - можно создать несколько environment. Параметры каждого можно менять, например - для апгрейда приложения.
• Environment tier - тип окружения, который определяется свойствами публикуемого приложения. Их два - web server environment и worker environment

Позволяет автоматизировать публикацию web-фронтендов.
Настраивает ec2-инстансы в нейскольких AZ, автоскейлинг для них, балансировщики нагрузки, а также - весь стек, необходимый для работы приложения.
Например публикация .NET приложения для Windows подразумевает настройку Windows-based инстансов EC2 и заданую версию IIS.
Также - приложение автоматически публикуется, для чего создается DNS-запись вида app-name.region.elasticbeanstalk.com, на которую можно ссылаться с помощью CNAME-записей.
На созданных EC2-инстансах деплоится host manager (HM), который:

• Деплоит приложение
• Собирает метрики с серверов
• Генерирует события
• Мониторит лог-файлы приложения на предмет критических ошибок
• Мониторит состояние сервера приложений
• Накатывает патчи на EC2-инстансы
• Ротрует логи приложения и вываливает их на S3.

Этот тип окружений предназначен для деплоя backend-слоя.
Elastic Beanstalk деплоит:

• один или несколько инстансов EC2
• AutoScaling Group
• IAM-роль
• Балансировщик
• При необходимости - разворачивается очередь Amazon SQS

На каждый EC2-инстанс деплоится демон, который читает сообщения из очереди SQS и отправляет прочитанные данные в приложение.

Amazon CloudFormation - использует JSON-темплейты (можно YAML) для описания инфраструктуры, в коорые можно подставлять некоторые значения для изменения параметров.
Темплейты используются для разворачивания стеков - CloudFormation stacks

CloudFormation stack - это контейнер, который группирует создаваемые ресурсы и позволяет обращаться с ними как с единым целым.
Стеков в рамках инсталляции может быть много и они могут взаимодействовать между собой.

При внесении изменений в ресурсы, задеплоенные с помощью CloudFormation формируются change set'ы, которые позволяют оценить изменения вносимые в конфигурацию и принять решение о файтическом изменении.
Это полезно, для избежания катастрофических последствий для инфраструктуры.
Например, если в темплейте поменять имя базы данных, то применение темплейта будет подразумевать удаление базы со старым именем и создание новой базы с новым именем.

Если в инфраструктуру вносятся изменения НЕ с помощью CloudFormation, то может возникать разница между тем, что описано в темплейтах и тем, что есть на самом деле.
Это может приводить к тому, что дальнейшее применение изменений с помощью CloudFormation может оказаться невозможным.
Для исправления этой ситуации существует механизм drift detection, который демонстрирует расхождения между фактической конфигурацией и тем что описано в темплейтах.

AWS OpsWorks for Puppet Enterprise и AWS OpsWorks for Chef Automate - это managed-сервисы, которые позволяют управлять конфигурациями инстансов EC2.

В рамках AWS стеком (stack) называется некоторый набор разнообразных ресурсов, управляемый как единое целое.
AWS OpsWorks Stack позволяет не толко создать и настроить ресурсы, но и мониторить их, при этом нет необходимости поддерживать инфраструктуру Chef для управления конфигурацией.
AWS OpsWorks Stack представлен двумя слоями (layers):

• application layer - ресурсы необходимые собственно для работы приложения - инстансы EC2 и изх настройки - security groups и прочее
• load balancing layer - балансировщики нарузки, которые распределяют трафик по инстансам EC2

Кроме того, стек AWS OpsWorks может быть расширен сервисыми слоями (service layers):

• Amazon RDS layer - базы данных
• Elastic Load Balancing layer - слой балансировщиков для организации отказоустойчивости и распределения нагрузки по нескольким AZ
• Amazon ECS layer - слой для организации кластера и запуска в нем контейнеризированных приложений

Amazon CloudWatch - предназначн для мониторинга, сбора, хранения и анализа метрик с ресурсов AWS, а также on-premises.
Все ресурсы AWS отдают метрики в CloudWatch. Базовый набор метрик - бесплатен, сложные метрики - за деньги.
Типичные задачи решаемые с помощью CloudWatch:

• Мониторинг состояния инфрастурктуры - метрик и логов. Визуализация, собранных данных.
• Проактивные реакции - настройка оповещений и действий в ответ на достижения метриками заданных значений.
• Анализ логов

Некоторые регулярно собираемые значения.
Каждая запись значения имеет таймстамп, а если его нет, то CloudWatch поставит ее сам.

• Встроенные метрики - доступны “из коробки”. Например CPU, ввод-вывод и прочие.
• Кастомные метрики - например время загрузки страниц веб-приложения или потребление памяти. Метрики могут собираться с помощью CloudWatch Agent (устанавливается на инстанс), либо пушиться c помощью метода CloudWatch API PutMetricData.

Записи метрики существуют в пределах региона AWS, но могут быть доступны в cross-account и cross-region дашбоардах.
Срок хранения - 15 месяцев. Старые записи автоматически уничтожаются.

Средства визуализации собранных данных метрик.
Функционал CloudWatch Dashboards интегрирован с AWS Organizations и таким образом является глобальным - межрегиональным и межаккаунтным.

Средства реагирования на достижение мертиками заданных значений.
Alarm может иметь одно из трех состояний:

• OK - значение метрики в пределах нормальных значений.
• Alarm - достигнут заданный предел.
• Insufficient Data - возвращается когда значений метрики недостаточно для принятия решения.

Возможные реакции на alarm:

• Отправка сообщения через Simple Notification Service (SNS) - application-to-person - A2P (человеку) или application-to-application A2A (приложению)
• Auto Scaling Action - сообщение для увеличения(уменьшения) числа EC2-инстансов.
• EC2 action - действие с инстансом EC2, именно - запуск, остановка, рестарт, уничтожение, recovery (миграция на другой хост).
• Публикация отметки на дашборд

Средство аггрегации логов, с ресурсов:

• EC2-инстансы
• CloudTrail logs
• Route53 DNS
• VPC flow
• внешние ресурсы (логи приложений, логи ОС и прочие)

Время хранения логов настраивается (от 1 дня до 10 лет), но может быть и не ограниченным.
Логи могут архивироваться на S3 Glacier.
В подсистеме логирования можно выделить сущности:

• События (Log Events) - запись о каком-то событии с меткой времени.
• Потоки журналов (Log Streams) - Cloudwatch группирует последовательности записей логов от одного источника в потоки.
• Группы журналов (Log Groups) - это несколько log streams с одинаковыи настройками (retention, access control).
• Фильтры метрик (Metric Filters) - инструмент для извлечения метрик из логов, которые в дальнейшем могут использоваться в качестве кастомных метрик CloudWatch. Таким образом можно визуализировать определенные события и настроить реакцию на на них с помощью Alarms.

CloudWatch Events - это устаревающий инструмент, который в настоящее время заменяется Amazon EventBridge.
Это инструмент, который позволяет создать правила, описывающие событие (запись в логах, время и т.д.), на которое можно настроить реакцию.
Реакция на возникновение события - практичесски в реальном времени, без задерджек.
Реакцию можно настроить на любую операцию API write. Примерами событий могут являться - выключение инстанса EC2, логин пользователя через IAM и прочее.
В качестве реакции могут выступать:

• Lambda-функция
• действие с инстансом EC2
• сообщение в очередь SQS или SNS
• ECS task
• и другое.

Например - можно настроить выполнение Lambda-функции в ответ на событие загрузки файла на S3.

Amazon CloudTrail - это средство аудита, которое может логировать все обращения к AWS API, таким образом фиксируя все действия пользователей и алгоритмов.
По-дефолту - включен. Время хранения записей - 90 дней.
Для просмотра собранного доступен CloudTrail Dashboard.
Логируются следующие разновидности событий:

• Management Events (control plane events) - события записи/чтения AWS API
• Data Events - операции над данными (напрмиер - в S3 или таблицах DynamoDB). Слежение за данными нужно включать специально.
• Insight events - события связанные с необычными всплескми активности. Например - неожиданно возросшее число удалений из S3.

Trail - это специальный (отличный от дефолтного) конфиг CloudTrail, который фиксирует указанные события и хранит их заданный срок.
События пишутся в AWS S3, CloudWatch Logs и CloudWatch Events . Можно писать в один бакет, либо - в несколько.
В рамках одного Trail можно настроить хранение событий либо из одного региона, либо - из всех регионов (дефолтный вариант). При добавлении нового региона - его события автоматически добавляются в All Regions Trail.
Большинство событий - региональные и пишутся в том регионе, где произошли, а события глобальных сервисов (например - IAM) пишутся в дефолтный регион US East N.Virginia
Может быть настроен глобальный аудит в рамках корневого аккаунта организации - AWS Organization Trail, который будет фиксировать действия всех аккаунтов.

AWS Config - инструмент change management:

• конфиг ресурсов
• история конфига
• взаимосвязи между ресурсами

Сущности, существующие в рамках AWS Config:

• Configuration Item - это снепшот состояния конфигурации в заданный момент времени для одного заданного ресурса. Создается в момент внесения изменений и представляет собой файл JSON-diff между старым и новым состояниями.
• Configuration History - это набор Configuration Item за заданный период времени - отражает историю изменений ресурса за указанный период.
• Configuration Recorder - собственно сущность, которая фиксирует изменения. Должен быть включен в заданном регионе для всех или только для заданных типов ресурсов.
• Configuration Snapshot - это набор Configuration Item для всех ресурсов. Отражает состояние всех ресурсов инфрастурктуры AWS.
• Configuration Stream - набор Configuration Item, которые возникают по мере создания/изменения/удаления ресурсов и отправляются в топик Amazon SNS.

Инструмент для централизованного управления AWS. Ранее известен как SSM.
Позволяет декаларативно с помощью JSON-документов (есть много готовых темплейтов, но можно создавать и свои) приводить русурсы AWS к описанному в них сосотоянию.
Например - документ AWS-CreateRdsSnapshot позволяет быстро и просто создать снепшот базы данных.
Вот некоторые доступные операции:

• Run Command - запуск shell-скриптов на EC2-инстансах под linux.
• State Management - позволяет поддерживать конфиг инстансов в заданном сосотоянии. Например - состояние антивируса или файервола.
• Inventory - позволяет собирать (инвентаризировать) информацию о софте на инстансах.
• Maintenance Window - позволяет планировать обслуживание инстансов.
• Patch Manager - автоматический деплой патчей.
• Automation - автоматизация различных задач - обновление AMIs, создание снепшотов дисков, сброс паролей. запуск и уничтожение EC2-инстансов и всякое другое
• Parameter Store - способ хранеия и доставки секретов (паролей и прочего).
• Distributor - инструмент для создания и распространения дистрибутивов приложений.
• Session Manager - способ доступа к shell инстансов, без необходимости открывать порты, SSH-ключи или настраивать бастионы.
• Incident Manager - инструмент для расследования инцидентов и оповещения заинтересантов.

Сервис анализа конфигураций на соответствие best practice.
Модет выдавать репорты следующих категорий:

• Cost Optimization - поиск неиспользуемых, но оплачиваемых ресурсов.
• Performance - Поиск узких мест в плане производительности. Например - инстанс с высокимим запросами к диску имеет медленный gp2 диск.
• Security - анализ настроек безопасности. Например - не включен MFA.
• Fault Tolerance - анализ конфигурации на отказоустойчивость. Например - не включен Multi-AZ там где должен быть.
• Service Limits - укащывает на скорое достижение лимитов. Например - при включенном AutoScaling.

Инфраструктуру принято оценивать по пяти критериям

Приложения должны быть устойчивы к отказам отдельных элементов инфраструктуры.
Также - важно время восстановления после отказа.
В рамках облачной инфраструктуры все компоненты рассматриваются как бастрозаменяемые. То есть архитектура должна это учитывать и вместо починки вышедшего из строя инстанса нужно стремиться просто поднимать новый.

При проектировани инфраструктуры важно стремиться к заданому уровню производительности при оптимальной цене.
Также следует закладывать возможность расширения ресурсов при возрастающей нагрузке.
Следует планировать распределение ресурсов с учетом особенностей досиупа к приложениям - например - с учетом географии пользователей.

При проектировани облачных решений важно уделять внимание безопасности.
То есть - обеспечивать аутентификацию и авторизацию, проверку целостности данных и кода.
Назначение привилегий всегда должно быть основано на принципе минимально необходимых привилегий.
Решения должны включать в себя планы создания резервных копий и восстановления после сбоев.
Важно уделять внимание аудиту событий в инфрастурктуре.

Способность быстро и эффективно вносить обратимые изменения в конфигурацию в любой момент времени с помощью IaC.
Проведение тестов отказа элементов инфраструктуры и отработка реакции на их.
Выявление и устранение рисков.

Анализ структуры расходов на облачную инфраструктуру и автоматическая оптимизация потребления в зависимости от текущих условий.
Использование managed-решений.

Базовый принцип обеспечения безопасности AWS - Shared Responsibility Model. Она формулируется так:

• AWS обеспечивает безопасность самого “облака”, а клиент обеспечивает безопасность ресурсов в облаке (путем корректной настройки).

Ответственность за:

• Физическую безопасность инфраструктуры
• Безопасность используемых протоколов
• Обеспечение отказоустойчивости путем резервирования физических компонентов инфрастурктуры
• Безопасность ПО, используемого для организации работы облака

Клиент несет ответственность за:

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

В зависимости от модели (IaaS, PaaS, SaaS) - объем ответственности клиента меняется.

AWS Artifact - это портал, содержащий отчеты о соответствии сервисов AWS требованиям регуляторов, а также сертификаты соответствия этим требованиям.
Документы, представленные на этом портале предназначены для предоставления аудиторам, проверяющим соответствие инфрастурктуры на базе AWS требованиям, предъявляемым к тем или иным приложениям.

Amazon разрешает клиентам проводить pen-testing приложений, развернутых в среде AWS.
Есть некоторые типы проверок, которые могут проводить только организации со специальными полномочиями. Например - имитация атак Distributed Denial of Service (DDoS) разрешена только партнерам AWS Partner Network (APN).
Network Stress testing может осуществляться силами клиента, но с запросом соответствующего разрешения от AWS.

Передача данных по сети - должна проходить в зашифрованном виде по протоколам Secure Socket Layer/Transport Layer Security SSL/TLS.
Хранимые данные могут быть зашифрованы с помощью ключей и одного из признанных алгоритмов шифрования - Tripple DES или AES-256.
AWS может брать на себя задачи управления ключами шифрования - с помощью сервиса Key Management Service (KMS). С помощью KMS клиент создает Customer Master Keys (CMKs), которые зранятся в KMS и используются для шифрования.
Ключи могут быть мультирегиональными - то есть данные. зашифрованные в одном регионе, могут быть переданы и расшифрованы в другом.
Есть два типа ключей:

• Customer-managed CMKs - клиент создает их и управляет ими (ротирует, назначает политики использования, тегирует, назначает алиасы).
• AWS managed CMKs - ключами полностью управляет AWS.

AWS KMS интегрирован с CloudTrail и обеспечивает аудит использования ключей.

безопасность хранящихся на S3 данных может быть обеспечена следующими способами:

• Server-Side Encryption - шифрование выполняет AWS при сохранении данных на диски и расшифровывает при считывании.
• Client-Side Encryption - шифрование выполняется клиентом перед выгрузкой данных в S3 и клиент полностью контролирует ключи и средства шифрования.
• Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3) - каждый объект шифруется уникальным ключем, а затем этот ключ шифруется мастер-ключем. AWS полностью берет на себя ротацию и обслуживание этих ключей.
• Server-Side Encryption with CMKs Stored in AWS KMS (SSE-KMS) - аналогично SSE-S3, но ключи хранятся в KMS, что позволяет контролировать их использвание (кто и как использовал). Ключи уникальны для аккаунта, сервиса и региона.
• Server-Side Encryption with Customer-Provided Keys (SSE-C) - ключами управляет клиент, а AWS шифрует данные на S3.

AWS KMS исползует дял шифрования аппаратные модули hardware security modules (HSMs), соответствующие стандарту FIPS 140-2. Модули HSM - используются многими клиентами AWS одновременно, но если нужно иметь выделенный модуль шифрования, то достун сервис AWS Cloud HSM.

Сервис AWS CloudHSM предоставляет досиуп к выделеному аппаратному модулю шифрования. который доступен в VPC. В этому случае - все операции к ключами (генерация, хранение, импорт, экспорт, ротация) выполняются клиентом.
Поддерживаются как симметрчное, так и ассимметричное шифрование.
AWS CloudHSM совместим с популярными API и библиотеками - PKCS#11, Java Cryptography Extension (JCE), Microsoft CryptoNG (CNG).

Amazon WAF - это файервол приложений, который защищает приложения опубликованние через:

• Amazon CloudFront
• Amazon API Gateway
• Amazon Application Load Balancers (ALB)
• AWS AppSync GraphQL API

AWS WAF работает на Layer7 OSI, мониторит трафик HTTP/HTTPS и защищает от распространенных эксплоитов, а также от SQL-инъекций и XSS (cross-site scripting).
Настраивается с помощью web ACLs, которые задают правила проверок и реакции на результаты.
Биллинг - по числу правил web ACLs и HTTP(S)-запросов.

AWS Shield - защита от DDoS.
Доступна в двух вариантах:

• AWS Shield Stanard - бесплатная стандартная защита от наиболее распространенных атак. Может использоваться совместно с Amazon CloudFront и Route53.
• AWS Shield Advanced - обеспечивает дополнительную защиту от атак на инстансы EC2, балансировщики ELB, CloudFront, Global Accelerator, Route53. Поддерживается автоматическое обнаружение атак и попвещение. Предоставляется круглосуточная поддержка со стороны AWS Shield Response Team (SRT). СТоимость - от $3000 за AWS Organization, а также - в зависимости от объема исходящих данных и используемых сервисов. В стоимость входят услуги AWS WAF

AWS Inspector - проверяет инстансы EC2 с помощью двух наборов правил:

• Network reachability rules package - проверят доступность хоста ин Internet и открытые порты.
• Host Assessmentsrules package - проверка на опубликование уязвимости (CVE и CIS), и другие бест-практисы в части безопасности. Пароли рута и прочее.

Если нужна более развернутая информация о безопасности инстансов EC2 - на них предлагается установить AWS Inspector Agent. Он будет собирать информацию о ОС, приложениях, операциях на файловой системе и прочую телеметрию и выгружать ее на S3 в виде JSON-документов. Затем - на основании этих документов могут быть сформулированы рекомендации.
Установить AWS Inspector Agent удобно с помощью AWS System Manager Run Command.

Сервис проверки данных на наличие сенситивной информации. Например - персональных данных.
Сканирует данные на S3 и определет подозрительные паттерны, а также - мониторит доступ к данным на S3 и выявляет аномалии или неавторизованный доступ.

AWS GuardDuty - серсив обнаружения угроз с помощью анализа подозрительной активности аккаунтов AWS и приложений. Анализирует данные из логов - CloudTrail Logs, VPC Flow Logs, DNS.
Обнаруживает использование скомпроментированных учетных данных, взаимодейтстсвие с подозрительными IP и доменами, необычную активность учеток AWS.
Например - запуск EC2-инстансов в регионах, где обычно комапния не работает.
Обнаруживает криптовалютные майнеры, компроментацию бакетов S3 и прочее.

Биллинг - в зависимости от числа событий логов CloudTrail, VPC Flow, DNS.

Сервис помогает в расследовании инцидентов и поиске первопричин инцидентов - позволяет визуализировать, анализировать и сопоставлять логи CloudTrail, VPC Flow, результаты работы GuardDuty.

Сервис управления (получение, обновление) сертификатами. Интегрирован с балансировщиками и CloudFront.

Сервис AWS Secrets Manager немного напоминает AWS System Manager Parameter Store, однако не только модет хранить сенситивные данные, но и автоматически ротировать. например - пароли от баз Amazon RDS.
Или - токены для взаимной аутентификации приложений.
Кроме того - AWS Secrets Manager шифрует хранимые данные с помощью ключей Amazon KMS и обеспечивает репликацию секретов между регионами.
Биллинг - в зависимости от числа ключей и вызовов Secrets Manager API.

Amazon Cognito - сервис аутентификации пользователей опубликованных приложений по протоколам OAuth, SAML, OpenID и прочие.
Внутри Amazon Cognito есть две сущности отвечающие за аутентификацию и авторизацию соотвественно:

• Amazon Cognito User pools - Это источник учеток. Congnito может сам хостить и аутентифицировать учетки или брать их из присоединенных источников (Apple, Google, Facebook, MS AD LDAP и прочие) и аутентифицировать там.
• Amazon Cognito Identity Pools - средство создания identity и раздачи прав на ресурсы AWS для пользователей, подлинность учетных данных которых были подтверждены в Cognito User Pool. Кроме того - может создавать временные identity для анонимных пользователей.

AWS Directory Service for Microsoft Active Directory (также известен как AWS Managed Microsoft AD) - это fully-managed Active Drectory на платформе AWS.
Позволяет использовать MS AD аутентификацию на всех сервисах AWS, которые это умеют.
В том числе Amazon Workspaces - VDI на базе linux и windows, также Amazon Worksdocs - облачный офисный пакет от Amazon, совместимый с продуктами Microsoft.

Пользователь платит за:

• вычислительные мощности
• хранение информации
• исходящий сетевой трафик

При проектировании решений следует принимать ко вниманию:

• Выбор модели ценообразования на вычислительные ресурсы - то есть определиться с тем нужны ли гарантированные инстансы On-Demand, или можно выбрать негарантированные Spot, которые позволят сэкономить до 72% стоимости. Либо - при заключении соглашения на обязательное минимальное количество потребляемых ресурсов можно ориентироваться на compute savings plans.
• Выбор правильного количества заказываемых ресурсов. Чтобы не переплачиваь нужно правильно понимать сколько чего нужно, Для этого AWS предоставляет специальные инструменты - AWS Cost Explorer, который позволяет выявить ресурсы с низкой утилизацией. Также с помощью AWS CloudFormation планировать включение/выключение инстансов по расписанию.
• Мониторинг и выявление фактического потребления на основе метрик CPU, ввода-вывода, памяти. В этом помогут CloudWatch для большинстава ресурсов и Amazon S3 analytics для выявлния паттернов обращения к ресурсам на S3.

Средство мониторинга и визуализации затрат. Позволяет увидеть на что тратятся деньги и спрогнозировать траты на год вперед.
Можно видеть затраты по часам и по разным типам ресурсов.
AWS Cost Explorer выдет рекомендации на основе которых можно резервировать ресурсы и таким образом экономить.
Также - позволяет выявлять аномалии в затратах и оповещать о них

Для выделения среди ресурсов групп и определения того какие из этих групп сколько стоят применяются теги. Теги бывают встроенные и пользовательские.

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

• Применять IAM-политики
• Service Control Policies
• Что-то делать непосредственно с инстансами (EC2 или RDS)

То есть, например при превышении бюджета можно запретить создание новых EC2-инстансов с помощью IAM-политики.