Тут я оставляю заметки при подгтовке к экзамену AWS Certified Cloud Practitioner - CLF-C01

Cloud Computing

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

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

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

Обзор глобальной инфраструктуры AWS

  • Регион (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 минут.

Basic Developer Business Enterprise
Только нетехническая поддержка по e-mail с 8:00 до 18:00 в TZ клиента по e-mail, в чатах и по телефону 24/7 по e-mail, в чатах и по телефону 24/7
Простая техподержка сервисов AWS. SLA - 24 часа Простая техподержка сервисов AWS. SLA - 24 часа Простая техподержка сервисов AWS. SLA - 24 часа
Реакция на системные проблемы - 12 часов Реакция на системные проблемы - 12 часов Реакция на системные проблемы - 12 часов
Реакция на проблемы продукционных систем - 4 часа Реакция на проблемы продукционных систем - 4 часа
Реакция на отказы продукционных систем - 1 час Реакция на отказы продукционных систем - 1 час
Реакция на отказы 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-шки и учетки в них
  • У каждой UO-шки может быть только одна родительская OU-шка.
  • Каждая учетка может входить только в одну OU-шку.

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

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

Вообще - нихрена непонятно на первый взгляд. Надо почитать тут: 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 и балансировщики) под нужды приложения. Разработчику достаточно залить код, а Banstalk создаст необходимую для работы приложения инфраструктуру. Сам сервис - бесплатен, но ресурсы им создаваемые - нет!

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

  • 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.

Технологии AWS

В иерархии 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 политик

В свою очередь 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 Simple Storage Service (S3)

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

Максимальный размер объекта в 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, Route53, CloudFront

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

Elastic IP Address

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

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

  • Security Groups
  • Network Access Control Lists (NACLs)

Security Groups

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

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

Network Access Control Lists (NACLs)

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

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

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

VPC tansit gateway

Если число взаимодейтсвующих 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.internalus-east-1) и ipv4-private-address.region.compute.internal (в остальных регионах).
  • Public DNS hostnames - указывают на публичный IP-адрес ресурса в интернете. Имеют вид - ipv4-public-address.compute-1.amazonaws.comus-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 создается путем описания высокроуровневых абстракций.

AWS Compute Services

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

  • семейства (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-ключами. Действия администраторов записываются для дальнейшего аудита.

Сервисы AWS Databases

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 часа.

Реализация отказоустойчивых БД - Multi AZ

Классический кластер 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

Amazon Aurora 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 БД в облако для отказоустойчивости.

Отказоустойчивость и эластичность AWS - (HA and Elasticity)

  • Вертикальная и горизонтальная масштабируемость
  • Модель 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 направляет запросы.

Health Checks

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

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

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

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

  • Обеспечивает очень низкие задержки.
  • Интересен тем, что может сохранять IP-адрес клиента во входящих запросах.
  • Поддерживает статические и elastic IP-адреса (по одному на AZ).
Enter your comment. Wiki syntax is allowed:
C W᠎ M D X
 
  • devops/aws_certified_cloud_practitioner.txt
  • Last modified: 2022/05/17 15:26
  • by admin