diff --git a/translations/ru.md b/translations/ru.md index 8b13789..4eb2d69 100644 --- a/translations/ru.md +++ b/translations/ru.md @@ -1 +1,2492 @@ +![Открытое руководство](../figures/signpost-horiz1-1600.jpg) +Открытое руководство по Amazon Web Services +===================================== + +[![Slack чат](https://img.shields.io/badge/Chat-Slack-ff69b4.svg "Join us. Anyone is welcome!")](https://join.slack.com/t/og-aws/shared_invite/enQtODM2NjY1NDQ2MTgxLWYwY2VjZDBiOGU1YTJjOWUwNTY3NjEyODA0NzY1N2MxNjhhZmYwZTU0NjNhMjNlNGVjODdlNTI4N2Y1YWIwNGE) ⇦ Присоединяйтесь к нам + +[Авторы](../AUTHORS.md) ∙ [Рекомендации по дополнению материала](../CONTRIBUTING.md) + +Содержание +----------------- + +**Цель создания данного руководства** + +- [Почему открытое руководство?](#почему-открытое-руководство) +- [Содержание](#содержание-1) +- [Расшифровка обозначений](#расшифровка-обозначений) + +**Что такое AWS** + +- [Общая информация](#общая-информация) +- [Обучение и карьерное развитие](#обучение-и-карьерное-развитие) +- [Управление AWS](#управление-aws) +- [Управление серверами и приложениями](#управление-серверами-и-приложениями) + +| Сервис AWS | Основные данные | Советы | Известные ошибки и ограничения | +|---------------------------------------|--------------------------------|-------------------------------|------------------------------------------------| +| [ALB](#alb) | [📗](#основы-alb) | [📘](#советы-по-alb) | [📙](#ошибки-и-ограничения-связанные-с-alb) | +| [AMIs](#amis) | [📗](#основы-ami) | [📘](#советы-по-ami) | [📙](#ошибки-и-ограничения-связанные-с-ami) | +| [API Gateway](#api-gateway) | [📗](#основы-api-gateway) | [📘](#советы-по-api-gateway) | [📙](#ошибки-и-ограничения-связанные-с-api-gateway) | +| [Auto Scaling](#auto-scaling-автоматическое-масштабирование) | [📗](#основы-auto-scaling) | [📘](#советы-по-автоматическому-масштабированию) | [📙](#ошибки-и-ограничения-связанные-с-автоматическим-масштабированием) | +| [Batch](#batch) | [📗](#основы-batch) | [📘](#советы-по-batch) | +| [Certificate Manager](#менеджер-сертификатовcertificate-manager) | [📗](#основы-менеджера-сертификатов) | [📘](#советы-по-менеджеру-сертификатов) | [📙](#ошибки-и-ограничения-связанные-с-менеджером-сертификатов) | +| [CLB (ELB)](#классический-балансировщик-нагрузкиclb) | [📗](#основы-clb) | [📘](#советы-по-clb) | [📙](#ошибки-и-ограничения-связанные-с-clb) | +| [CloudFront](#cloudfront) | [📗](#основы-cloudfront) | [📘](#советы-по-cloudfront) | [📙](#ошибки-и-ограничения-связанные-с-cloudfront) | +| [CloudFormation](#cloudformation) | [📗](#основы-cloudformation) | [📘](#советы-по-cloudformation) | [📙](#ошибки-и-ограничения-связанные-с-cloudformation) | +| [CloudWatch](#cloudwatch) | [📗](#основы-cloudwatch) | [📘](#советы-по-cloudwatch) | [📙](#ошибки-и-ограничения-связанные-с-cloudwatch) | +| [Device Farm](#device-farm) | [📗](#основы-device-farm) | [📘](#советы-по-device-farm) | [📙](#ошибки-и-ограничения-связанные-с-device-farm) | +| [DirectConnect](#directconnect) | [📗](#основы-directconnect) | [📘](#советы-по-directconnect) | | +| [DynamoDB](#dynamodb) | [📗](#основы-dynamodb) | [📘](#советы-по-dynamodb) | [📙](#ошибки-и-ограничения-связанные-с-dynamodb) | +| [EBS](#ebs) | [📗](#основы-ebs) | [📘](#советы-по-ebs) | [📙](#ошибки-и-ограничения-связанные-с-ebs) | +| [EC2](#ec2) | [📗](#основы-ec2) | [📘](#советы-по-ec2) | [📙](#ошибки-и-ограничения-ec2) | +| [ECS](#ecs) | [📗](#основы-ecs) | [📘](#советы-по-ecs) | | +| [EKS](#eks) | [📗](#eks-basics) | [📘](#eks-tips) | [📙](#eks-gotchas-and-limitations) | +| [EFS](#efs) | [📗](#efs-basics) | [📘](#efs-tips) | [📙](#efs-gotchas-and-limitations) | +| [Elastic Beanstalk](#elastic-beanstalk) | [📗](#elastic-beanstalk-basics) | [📘](#elastic-beanstalk-tips) | [📙](#elastic-beanstalk-gotchas-and-limitations) | +| [Elastic IPs](#elastic-ips) | [📗](#elastic-ip-basics) | [📘](#elastic-ip-tips) | [📙](#elastic-ip-gotchas-and-limitations) | +| [ElastiCache](#elasticache) | [📗](#elasticache-basics) | [📘](#elasticache-tips) | [📙](#elasticache-gotchas-and-limitations) | +| [EMR](#emr) | [📗](#emr-basics) | [📘](#emr-tips) | [📙](#emr-gotchas-and-limitations) | +| [Fargate](#fargate) | [📗](#fargate-basics) | [📘](#fargate-tips) | [📙](#fargate-gotchas-and-limitations) | +| [Glacier](#glacier) | [📗](#glacier-basics) | [📘](#glacier-tips) | [📙](#glacier-gotchas-and-limitations) | +| [IoT](#iot) | [📗](#iot-basics) | [📘](#iot-tips) | [📙](#iot-gotchas-and-limitations) | +| [Kinesis Firehose](#kinesis-firehose) | | | [📙](#kinesis-firehose-gotchas-and-limitations) | +| [Kinesis Streams](#kinesis-streams) | [📗](#kinesis-streams-basics) | [📘](#kinesis-streams-tips) | [📙](#kinesis-streams-gotchas-and-limitations) | +| [KMS](#kms) | [📗](#kms-basics) | [📘](#kms-tips) | [📙](#kms-gotchas-and-limitations) | +| [Lambda](#lambda) | [📗](#lambda-basics) | [📘](#lambda-tips) | [📙](#lambda-gotchas-and-limitations) | +| [Load Balancers](#load-balancers) | [📗](#load-balancer-basics) | [📘](#load-balancer-tips) | [📙](#load-balancer-gotchas-and-limitations) | +| [Mobile Hub](#mobile-hub) | [📗](#mobile-hub-basics) | [📘](#mobile-hub-tips) | [📙](#mobile-hub-gotchas-and-limitations) | +| [OpsWorks](#opsworks) | [📗](#opsworks-basics) | [📘](#opsworks-tips) | [📙](#opsworks-gotchas-and-limitations) | +| [RDS](#rds) | [📗](#rds-basics) | [📘](#rds-tips) | [📙](#rds-gotchas-and-limitations) | +| [RDS Aurora](#rds-aurora) | [📗](#rds-aurora-basics) | [📘](#rds-aurora-tips) | [📙](#rds-aurora-gotchas-and-limitations) | +| [RDS Aurora MySQL](#rds-aurora-mysql) | [📗](#rds-aurora-mysql-basics) | [📘](#rds-aurora-mysql-tips) | [📙](#rds-aurora-mysql-gotchas-and-limitations) | +| [RDS Aurora PostgreSQL](#rds-aurora-postgresql) | [📗](#rds-aurora-postgresql-basics) | [📘](#rds-aurora-postgresql-tips) | [📙](#rds-aurora-postgresql-gotchas-and-limitations) | +| [RDS MySQL and MariaDB](#rds-mysql-and-mariadb) | [📗](#rds-mysql-and-mariadb-basics) | [📘](#rds-mysql-and-mariadb-tips) | [📙](#rds-mysql-and-mariadb-gotchas-and-limitations) | +| [RDS PostgreSQL](#rds-postgresql) | [📗](#rds-postgresql-basics) | [📘](#rds-postgresql-tips) | [📙](#rds-postgresql-gotchas-and-limitations) | +| [RDS SQL Server](#rds-sql-server) | [📗](#rds-sql-server-basics) | [📘](#rds-sql-server-tips) | [📙](#rds-sql-server-gotchas-and-limitations) | +| [Redshift](#redshift) | [📗](#redshift-basics) | [📘](#redshift-tips) | [📙](#redshift-gotchas-and-limitations) | +| [Route 53](#route-53) | [📗](#route-53-basics) | [📘](#route-53-tips) | [📙](#route-53-gotchas-and-limitations) | +| [S3](#s3) | [📗](#s3-basics) | [📘](#s3-tips) | [📙](#s3-gotchas-and-limitations) | +| [Безопасность и IAM](#безопасность-и-iam) | [📗](#основы-безопасности-и-iam) | [📘](#советы-по-безопасности-и-iam) | [📙](#ошибки-и-ограничения-в-вопросе-обеспечения-безопасности-и-iam) | +| [SES](#ses) | [📗](#ses-basics) | [📘](#ses-tips) | [📙](#ses-gotchas-and-limitations) | +| [SNS](#sns) | [📗](#sns-basics) | [📘](#sns-tips) | [📙](#sns-gotchas-and-limitations) | +| [SQS](#sqs) | [📗](#sqs-basics) | [📘](#sqs-tips) | [📙](#sqs-gotchas-and-limitations) | +| [Step Functions](#step-functions) | [📗](#step-functions-basics) | [📘](#step-functions-tips) | [📙](#step-functions-gotchas-and-limitations) | +| [WAF](#waf) | [📗](#основы-waf) | [📘](#советы-по-waf) | [📙](#ошибки-и-ограничения-связанные-с-waf) | +| [VPCs, Network Security, and Security Groups](#vpcs-network-security-and-security-groups) | [📗](#vpc-basics) | [📘](#vpc-and-network-security-tips) | [📙](#vpc-and-network-security-gotchas-and-limitations) | + +**Особые темы** + +- [Высокая доступность](#high-availability) +- [Платежи и управление расходами](#billing-and-cost-management) +- [Дополнительные материалы](#дополнительные-материалы) + +**Правовая информация** + +- [Отказ от ответственности](#отказ-от-ответственности) +- [Информация о лицензии](#информация-о-лицензии) + +**Диаграммы и таблицы** + +[![Инструменты и услуги, представленные на рынке](../figures/aws-market-landscape-320px.png)](#инструменты-и-услуги-представленные-на-рынке) [![Стоимость передачи данных при работе с AWS](../figures/aws-data-transfer-costs-320px.png)](#aws-data-transfer-costs) + +- [Инфографика: Инструменты и услуги, представленные на рынке](#инструменты-и-услуги-представленные-на-рынке): Выборка сторонних компаний/продуктов +- [Инфографика: Стоимость передачи данных при работе с AWS](#aws-data-transfer-costs): Визуальный обзор расходов на передачу данных +- [Таблица: Матрица сервисов](#матрица-сервисов): Сравнение сервисов AWS с альтернативными вариантами +- [Таблица: Зрелось продуктов AWS и выпуски](#зрелость-продуктов-aws-и-выпуски): Релизы продуктов AWS +- [Таблица: Долговечность и надежность хранения, доступность и цена](#storage-durability-availability-and-price): Количественное сравнение + +Почему открытое руководство? +------------------ + +Множество информации об AWS уже написано. Большинство изучает AWS читая блоги или “[руководство по началу работы](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html)” и ссылаясь на [официальную документацию AWS](https://aws.amazon.com/documentation/). Тем не менее, поиск достоверной и, связанной с практическим использованием, информации не так то прост. Официальная документация AWS является прекрасным, но очень обширным ресурсом, который мало кто читает полностью, по причине отсутствия времени, кроме того, он не содержит ничего, кроме официальных фактов и не учитывает опыт практикующих инженеров. Информация в блогах или на [Stack Overflow](http://stackoverflow.com/questions/tagged/amazon-web-services) также не всегда актуальна. + +Это руководство создано инженерами для инженеров использующих AWS. Мы поставили цель создать полезный, актуальный спсравочник, который объединяет ссылки, советы, рекомендации и лучшие практики. Идея создания данного руководства возникла в ходе обсуждений под пиво у [нескольких инженеров](../AUTHORS.md) которые широко применяли AWS в своей практике. + +Перед использованием данного руководства, пожалуйста прочтите [**информацию о лицензии**](#информация-о-лицензии) и [**отказ от ответственности**](#отказ-от-ответственности). + +### Помоги, пожалуйста! + +**Это ранняя черновая версия** Это наша первая попытка собрать и скомпоновать информацию, поэтому она еще далеко не исчерпывающая и может содержать пропуски или ошибки. + +[![Slack чат](https://img.shields.io/badge/Chat-Slack-ff69b4.svg "Join us. Anyone is welcome!")](https://join.slack.com/t/og-aws/shared_invite/enQtODM2NjY1NDQ2MTgxLWYwY2VjZDBiOGU1YTJjOWUwNTY3NjEyODA0NzY1N2MxNjhhZmYwZTU0NjNhMjNlNGVjODdlNTI4N2Y1YWIwNGE) + +Ты можешь помочь [**присоединившись к Slack чату**](https://join.slack.com/t/og-aws/shared_invite/enQtODM2NjY1NDQ2MTgxLWYwY2VjZDBiOGU1YTJjOWUwNTY3NjEyODA0NzY1N2MxNjhhZmYwZTU0NjNhMjNlNGVjODdlNTI4N2Y1YWIwNGE) (мы любим общаться об AWS в общем и целом, даже если тебе нечего сообщить и ты хочешь спросить - обсуждения помогают сообществу и этому руководству развиваться) и [**внося дополнения к данному руководству**](CONTRIBUTING.md). Это руководство *открыто для дополнения*, в отличии от блога, оно может продолжать развиваться. Как и в любом open source проекте, мы объединяем усилия и проверяем информацию, чтобы быть уверенными в высоком качестве информации. + +Содержание +----- + +- На текущий момент это руководство охватывает отдельные “основные(core)” сервисы AWS, такие как EC2, S3, Балансировщики нагрузки, EBS и IAM, а также некоторые подробности и советы при работе с остальными сервисами. Мы ожидаем, что с течением времени охват расширится. +- Это не пошаговое руководство, а скорее коллекция различной информации, которую вы можете прочитать и возвращаться к ней в при необходимости. Информация будет полезна, как начинающим, так и опытным инженерам. +- Мы хотим, чтобы это руководство было: + - **Кратким:** Старайтесь излагать информацию компактно и используйте ссылки + - **Практическим:** Основные факты, конкретные детали, советы, отловленные ошибки и прочие “общественные знания” + - **Актуальным:** Мы можем регулярно обновлять его, и каждый может внести посильный вклад в улучшение + - **Заставляющим задуматься:** Цель данного руководства - быть полезным, нежели просто изложить сухие факты. Мнение с рациональным зерном всегда приветствуется. Предложения, заметки и мнения, основанные на реальном опыте работы с AWS могут быть чрезвычайно ценными. (Мы верим, что это возможно с помощью руководства подобного формата, в отличии от некоторых [других мест](http://meta.stackexchange.com/questions/201994/is-there-a-place-to-ask-opinion-based-questions).) +- Это руководство не было проспонсировано ни AWS, ни связанным с AWS вендорами. Оно написано инженерами для инженеров, которые используют AWS в своей работе. + +Расшифровка обозначений +------ + +- 📒 Обозначает официальную документацию и страницы AWS +- 🔹 Важный или часто пропускаемый совет +- ❗ “Серьезная” ошибка (используется в тех случаях, когда риски, затраты времени или ресурсов значительны: критические риски безопасности, ошибки, грозящие значительными финансовыми затратами или плохие архитектурные решения, которые принципиально сложно исправить) +- 🔸 “Обычная” ошибка, ограничение, или странность (используется в тех случаях, когда ошибка вызывает неработоспособность, поломку или когда масштабирование происходит некорректно) +- 📜 Недокументированная особенность(фича) (народная информация) +- 🐥 Относительно новые (и, возможно, незрелые) сервисы и особенности(фичи) +- ⏱ Обсуждение производительности +- ⛓ Привязка: Продукты или решения, которые скорее всего привяжут вас к AWS таким образом, что переход на не-AWS альтернативу будет дорогостоящим с точки зрения инженерных усилий. +- 🚪 Альтернативные не-AWS варианты +- 💸 Вопросы стоимости, обсуждения и проблемы +- 🕍 Мягкое предупреждение, связанное с тем, что “универсальное решение” или модный фреймворк могут потребовать значительного времени, чтобы разобраться и понять, как это работает, при этом результат может не соответствовать потребностям в точности; в отличии от точечного решения(собор(иконка) является отсылкой к [Метафоре Рэймонда](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)\) +- 📗📘📙 Цвета обозначают основы, советы, отловленные ошибки соответственно. +- 🚧 Области где требуется исправление или улучшение (возможно с ссылкой на проблему, если можете — помогите!) + +Общая информация +------------------- + +### Когда использовать AWS + +- [AWS](https://en.wikipedia.org/wiki/Amazon_Web_Services) - доминирующий на мировом рынке провайдер облачных услуг. + - В общем и целом, “[облачные вычисления](https://en.wikipedia.org/wiki/Cloud_computing)” могут относиться к одному из трех типов облака: “публичное,” “частное,” и/или “гибридное.” AWS является провайдером публичных облачных сред, таким образом, каждый может их использовать. Частные облака обычно разворачиваются внутри одной (обычно большой) организации. Множество компаний по всему миру использует так называемый гибрид частного и публичного облака. + - Основными сервисами, предоставляемыми AWS являются [инфраструктура как сервис](https://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29) (IaaS) — то есть виртуальные машины и сопутствующая инфраструктура. Другие модели облачных сервисов включают в себя [платформу как сервис](https://en.wikipedia.org/wiki/Cloud_computing#Platform_as_a_service_.28PaaS.29) (PaaS), которая представляет из себя платформу для развертывания клиентских приложений без оглядки на инфраструктуру, а также [программное обеспечение как сервис](https://en.wikipedia.org/wiki/Cloud_computing#Software_as_a_service_.28SaaS.29) (SaaS), котороая представляет из себя облачные приложения. Кроме того, AWS предлагает новые модели облачных сервисов. + - С точки зрения бизнеса, при использовании инфраструктуры, как сервис, вы получаете новую парадигму — это [операционные расходы(OpEx), а не капитальные расходы(CapEx)](http://www.investopedia.com/ask/answers/020915/what-difference-between-capex-and-opex.asp) (за исключением случаев [забронированной инфраструктуры(Reserved Instances)](https://aws.amazon.com/ec2/purchasing-options/reserved-instances/), которая в таком случае является капитальным расходом(CapEx). +- Доход AWS за 12 месяцев составил [**$32.5 миллиарда долларов США**](https://ir.aboutamazon.com/static-files/ca9f2d27-46e7-4006-86f1-0c6ccb026a04) по данным на третитй квартал 2019 года, исходя из официальных данных или примерно **12%** от всего дохода Amazon.com за тот же период. +- **Главные причины использовать AWS:** + - Если ваша компания создает системы и/или продукты, которым необходимо масштабирование + - и у вас есть технические ноу-хау + - и вы хотите использовать наиболее гибкие инструменты + - и вы еще не сильно привязаны к какой-либо иной инфраструктуре + - и у вас нет каких-либо внутренних, регуляторных или нормативных причин, по которым вы не можете использовать публичное облачное решение + - и вы не завязаны на решения только от Microsoft :) + - и у вас нет явных причин использовать именно Google Cloud + - и вы можете себе позволить, дискутировать или договариваться о больших или меньших затратах + - ... тогда, судя по всему, AWS это неплохой вариант для рассмотрения. +- Каждая из вышеперечисленных причин может указывать на ситуации, когда другие услуги предпочтительнее. На практике многие, если не большинство, технические стартапы, а также ряд современных крупных компаний могут или уже получают выгоду от использования AWS. Многие крупные предприятия частично переносят внутреннюю инфраструктуру на Azure, Google Cloud и AWS. +- **Расходы:** Оплата и управление расходами настолько большие темы, что у нас есть [отдельный раздел на эту тему](#billing-and-cost-management). +- 🔹**EC2 и другие сервисы:** Большинство пользователей AWS наиболее знакомы с [EC2](#ec2), флагманским продуктом AWS - виртуальными серверами, и возможно некоторыми другими, такими как S3 и CLB(классическими балансировщиками нагрузки). Однако продукты AWS на текущий момент выходят далеко за рамки классической модели IaaS и зачастую компании не всегда понимают или видят ценность в использовании многочисленных продуктов AWS ввиду [быстрого роста](#какие-сервисы-использовать) количества сервисов, их новизны и сложности, путаницы с названиями, и боязни ⛓привязки к проприетарным технологиям AWS. И, хотя все вышеперечисленное может звучать устрашающе, крайне важно для лиц, принимающих технические решения в компании, понимать всю широту услуг предоставляемых AWS и принимать обоснованные решения. (Мы надеемся, что данное руководство поможет в этом.) +- 🚪**AWS и другие облачные провайдеры:** В то время, как AWS является ведущим IaaS провайдером (31% рынка исходя [из оценки рынка за 2016 год](https://www.srgresearch.com/articles/aws-remains-dominant-despite-microsoft-and-google-growth-surges)), существует значительная конкуренция на рынке и альтернативные решения, которые больше подходят некоторым компаниям. [Этот отчет от Gartner](https://www.gartner.com/doc/reprints?id=1-2G2O5FC&ct=150519&st=sb) содержит хороший обзор основных игроков на рынке облачных услуг: + - [**Google Cloud Platform**](https://cloud.google.com/). GCP пришел на рынок позже AWS, но обладает обширными ресурсами и на текущий момент используется многими компаниями, в том числе некоторыми крупными корпорациями. GCP постепенно занимает свою нишу на рынке. Не все сервисы AWS имеют аналоги в GCP. И наоборот: В частности, GCP предлагает некоторые более продвинутые, основанные на машинном обучении, сервисы, такие как [Vision](https://cloud.google.com/vision/), [Speech](https://cloud.google.com/speech/), и [Natural Language](https://cloud.google.com/natural-language/) APIs. Обычно это не является распространенной практикой, когда действующий проект запущенный на одной платформе переключается на другую, однако такое случается: [Spotify мигрировал](http://www.wsj.com/articles/google-cloud-lures-amazon-web-services-customer-spotify-1456270951) с AWS на Google Cloud. Обсуждение сравнительных выгод можно найти [на Quora](https://www.quora.com/What-are-the-reasons-to-choose-AWS-over-Google-Cloud-or-vice-versa-for-a-high-traffic-web-application). Особо следует отметить тот факт, что VPC в GCP [глобальны по умолчанию](https://cloud.google.com/vpc/) с подсетями в регионах, в то время как VPC в AWS располагаются в строго определенном регионе. Это дает преимущество GCP в том случае, если вы изначально проектируете приложения с распределенной гео-репликацией. Также возможно [совместное использование одного VPC в GCP](https://cloud.google.com/compute/docs/shared-vpc/) между несколькими проектами (что примерно аналогично разным AWS аккаунтам), в то время, как в AWS вы должны их обеспечить их соединение. Также возможно [связать VPC в GCP](https://cloud.google.com/compute/docs/vpc/vpc-peering) таким же способом, как это сделано в AWS. + - [**Microsoft Azure**](https://azure.microsoft.com/en) де-факто является выбором компаний и команд, ориентированных на стек технологий Microsoft, кроме того Azure уделяет огромное внимание технологиям Linux. + - В **Китае**, доля AWS относительно мала. На рынке доминирует [Alibaba Cloud](https://www.alibabacloud.com/), ранее именовавшийся [Aliyun](https://intl.aliyun.com/). + - Отдельные очень крупные компании могут в свою очередь пожелать сократить расходы путем перехода на собственную инфраструктуру. Например, [Dropbox мигрировал](https://news.ycombinator.com/item?id=11282948) на собственную инфраструктуру. + - Другие облачные провайдеры, такие как [Digital Ocean](https://www.digitalocean.com/) предлагают похожие сервисы, иногда значительно более простые в использовании, более клиенто-ориентированную поддержку или более низкие цены. В любом случае, ни один из них не соответствует AWS по широте ассортимента, доминации на рынке, осведомленности клиентов о компании и продуктах. + - Традиционные хостинг провайдеры, такие как [Rackspace](https://www.rackspace.com/) также предлагают облачные решения. +- 🚪**AWS и PaaS:** Если ваша цель запустить простой сервис, которые делает что-то относительно простое и вы хотите минимизировать трудозатраты на обслуживание инфраструктуры, рассмотрите как вариант развертывания [платформу-как-сервис](https://en.wikipedia.org/wiki/Platform_as_a_service) такую как [Heroku](https://www.heroku.com/). Подход AWS к PaaS модели, как например, Elastic Beanstalk, возможно слишком сложен, в особенности для простых случаев использования. +- 🚪**AWS и Web-хостинг:** Если ваша главная цель - разместить веб-сайт или блог и вы не собираетесь создавать веб-приложение или какой-либо сложные сервис, возможно вам стоит рассмотреть размещение на площадке одного из мириадов [хостинг провайдеров](https://www.google.com/search?q=web+hosting). +- 🚪**AWS vs. managed hosting:** Традиционно многие компании платят провайдерам [управляемого хостинга](https://en.wikipedia.org/wiki/Dedicated_hosting_service),чтобы те обслуживали оборудование в своих ЦОД для них, а затем создают и развертывают программное обеспечение на базе арендованного физического оборудования. Это имеет смысл для тех предприятий, которые хотят иметь возможность прямого контроля аппаратного обеспечения, по причине развертывания легаси систем, а также в целях обеспечения необходимой производительности или в целях соответствия определенным ограничениям и правилам, в то же время технологические компании и ИТ-стартапы считают такой вариант размещения старомодным и не нужным. +- **Сложность:** AWS позволит вам строить и масштабировать системы до размеров крупнейших компаний, однако сложность сервисов при использовании в таких масштабах требует значителнього уровня знаний и опыта. Даже для очень простых случаев использования может потребоваться значительно больше знаний, чтобы сделать все “правильно” в AWS, нежели в более простой среде, как например Heroku или Digital Ocean. (Это руководство может помочь!) +- **Географическое местоположение:** AWS имеет центры обработки данных в [в более чем дюжине географических местоположений](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-available-regions), известных как **регионы(regions)**, в Европе, Восточной Азии, Северной и Южной Америке, а теперь и в Австралии и Индии. Также имеется значительно большее количество **точек доступа(edge locations)** по всему миру для снижения задержек при доступе к сервисам, например CloudFront. + - Посмотрите [текущий список](https://aws.amazon.com/about-aws/global-infrastructure/) регионов и точек доступа, включающий в том числе и планируемые. + - Если ваша инфраструктура должна располагаться в определенной физической близости к другим сервисам по причине определенной зависимости от задержек или пропускной способности (например, задержка до рекламного обменника), возможность использования AWS может зависеть от местоположения. +- ⛓**Привязка:** Так как вы используете AWS, важно понимать, когда вы используете сервисы AWS, которые не имеют эквивалентных аналогов где-либо. + - Привязка может быть вполне приемлимой для вашей компании или может стать значительным риском. Крайне важно с точки зрения бизнеса сделать осознанный выбор, учитывая стоимость, эксплуатационные качества, непрерывность бизнеса, и конкурентные риски связанные с привязкой к AWS. С другой стороны AWS настолько доминирующий и надежный вендор, что многие компании используют AWS в полной мере. Однако, некоторые могут рассказывать истории об [опасностях “облачной тюрьмы” когда издержки возрастают](http://firstround.com/review/the-three-infrastructure-mistakes-your-company-must-not-make/). + - Как правило, чем больше сервисов AWS вы используете, тем больше ваша привязка к AWS — то есть, больше технических ресурсов (времени и денег) потребуется для перехода к другому провайдеру в будущем. + - Основные сервисы, такие как виртуальные сервера и стандартные базы данных, обычно довольно таки легко перенести на других провайдеров или в локальный дата-центр. Другие же, такие как балансировщики нагрузки и IAM, являются специфичными в AWS, однако имеются похожие эквивалетные сервисы предлагаемые другими провайдерами. Ключевым моментом, который необходимо учитывать, является вопрос, проектируют ли инженера системы на основе конкретных сервисов AWS, которые не являются открытыми, или же на основе взаимозаменяемых сервисов. Например, Lambda, API Gateway, Kinesis, Redshift, и DynamoDB не имеют похожих эквивалентов, как коммерческих, так и открытых, в то время как EC2, RDS (MySQL или Postgres), EMR, и ElastiCache более или менее имеют. (Более подробно [тут](#какие-сервисы-использовать), где такие сервисы помечены значком ⛓.) +- **Использование AWS с другими облачными провайдерами:** Многие пользователи объединяют использование AWS с другими не-AWS сервисами. Например, легаси системы или критичные к раскрытию данных могут находиться на арендованном у хостинг провайдера оборудовании, в то время, как остальные системы находятся в AWS. Или компания может использовать S3, а у другого провайдера находятся системы, которые делают все остальное. Как бы там не было, маленькие стартапы или проекты, начинающиеся с нуля, обычно используют только AWS или Google Cloud. +- **Гибридные облака:** На крупных предприятиях обычно используется так называемое [гибридное развертывание](https://aws.amazon.com/enterprise/hybrid/) включающее в себя частное облако или локальные сервера и AWS — или другие корпоративные облачные провайдеры, такие как [IBM](https://www.ibm.com/it-infrastructure/us-en/hybrid-cloud/)/[Bluemix](http://www.ibm.com/cloud-computing/bluemix/hybrid/), [Microsoft](https://www.microsoft.com/en-us/cloud-platform/hybrid-cloud)/[Azure](https://azure.microsoft.com/en-us/overview/azure-stack/), [NetApp](http://www.netapp.com/us/solutions/cloud/hybrid-cloud/), or [EMC](http://www.emc.com/en-us/cloud/hybrid-cloud-computing/index.htm). +- **Основные клиенты:** Кто использует AWS и Google Cloud? + - [Список клиентов AWS](https://aws.amazon.com/solutions/case-studies/) включает в себя большое количество мейнстримных онлайн бизнесов и крупных брендов, таких как Netflix, Pinterest, Spotify (переезжает на Google Cloud), Airbnb, Expedia, Yelp, Zynga, Comcast, Nokia, и Bristol-Myers Squibb. + - [Список клиентов Azure](https://azure.microsoft.com/en-us/case-studies/) включает в себя такие компании, как NBC Universal, 3M и Honeywell Inc. + - [Список клиентов Google Cloud](https://cloud.google.com/customers/) также довольно таки большой и включает в себя несколько мэйнстриных сайтов, таких как [Snapchat](http://www.businessinsider.com/snapchat-is-built-on-googles-cloud-2014-1), Best Buy, Domino’s, и Sony Music. + +### Какие сервисы использовать + +- AWS предлагает *множество* различных сервисов — [около сотни](https://aws.amazon.com/products/) на момент последнего подсчета. +- Большинство клиентов интенсивно использует некоторое количество сервисов, некоторое количество не настолько интенсивно и не использует остальные вообще. Какие сервисы вы будете использовать - полностью зависит от конкретного случая использования. Выбор варьируется от компании к компании. +- **Незрелые и непопулярные сервисы:** Только от того, что AWS звучит, как многообещающий сервис, это вовсе не означает, что вы должны его использовать. Некоторые сервисы имеют довольно-таки узкую область применения, некоторые незрелые или сильно навороченные, или имеют ограничения, так что создание собственного решения может быть лучше. Мы попытаемся дать вам понимание, путем разбиения сервисов по категориям. +- **Инфраструктура, которую необходимо знать:** В большинстве своем обычные малые и средние компании сосредоточатся в первую очередь на следующих сервисах. Если вы управляете использованием ресурсов в AWS, вы должны хотя бы немного во всем этом разбираться. (Даже если вы их не используете, вам следует изучить их достаточно для того, чтобы сделать осознанный выбор) + - [IAM](#безопасность-и-iam): Пользовательские учетные записи и доступы(Вам следует подумать об учетных записях и доступа на самой ранней стадии!) + - [EC2](#ec2): Виртуальные сервера и сопутствующие компоненты, включая: + - [AMIs](#amis): Образы виртуальных машин + - [Load Balancers](#load-balancers): CLBs и ALBs + - [Autoscaling](#auto-scaling): Масштабирование емкости(добавление и удаление серверов в зависимости от нагрузки) + - [EBS](#ebs): Сетевые диски + - [Elastic IPs](#elastic-ips): Назначаемые IP адреса + - [S3](#s3): Хранилище файлов + - [Route 53](#route-53): DNS и регистрация доменов + - [VPC](#vpcs-network-security-and-security-groups): Виртуальные сети, безопасность в сети, и ко-локейшн; используется автоматически + - [CloudFront](#cloudfront): CDN для размещения контента + - [CloudWatch](#cloudwatch): Оповещения, уведомления, мониторинг +- **Управляемые сервисы:** Существующие программные решения, которые вы можете развернуть сами, но таким образом, что они управляются AWS: + - [RDS](#rds): Управляемая реляционная база данных (управляемые базы данных MySQL, Postgres, и разработка Amazon - Aurora ) + - [EMR](#emr): Управляемый Hadoop + - [Elasticsearch](https://aws.amazon.com/elasticsearch-service/): Управляемый Elasticsearch + - [ElastiCache](https://aws.amazon.com/elasticache/): Управляемый Redis и Memcached +- **Опциональная, но важная инфраструктура:** Эти ключевые и полезные инфраструктурные компоненты менее широко известны и реже используются. У вас могут быть вполне обоснованные причины использовать альтернативные варианты, поэтому необходимо крайне аккуратно оценить, удовлетворяют ли данные сервисы ваши потребности: + - ⛓[Lambda](#lambda): Выполнение небольших, полностью управляемых задач, так называемая “serverless” технология + - [CloudTrail](https://aws.amazon.com/cloudtrail/): Логирование и аудит AWS API вызовов (важно, но часто игнорируется) + - ⛓🕍[CloudFormation](#cloudformation): Шаблонная конфигурация коллекций ресурсов AWS + - 🕍[Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/): Полностью управляемая платформа (PaaS) для развертывания упакованных приложений на языках Java, .NET, PHP, Node.js, Python, Ruby, Go, и Docker + - 🐥[EFS](#efs): Сетевая файловая система совместимая с NFSv4.1 + - ⛓🕍[ECS](#ecs): Управление Docker контейнерами/кластерами (к слову, Docker также может быть запущен в других сервисах, без использования ECS) + - 🕍 [EKS](#eks): Управление Docker контейнерами/кластерами на основе оркестратора Kubernetes (K8) + - ⛓[ECR](https://aws.amazon.com/ecr/): Приватные реестр Docker образов + - 🐥[Config](https://aws.amazon.com/config/): Инвентаризация ресурсов AWS, история изменений, оповещения об изменениях + - 🐥[X-Ray](https://aws.amazon.com/xray/): Анализ трейсов и отладка для распределенных приложений, таких как микросервисы +- **Специализированная инфраструктура:** Эти услуги ориентированы на конкретные случаи применения, таким образом необходимо произвести оценку, подходят ли они в вашей ситуации. Многие из них также имеют проприетарную архитектуру, таким образом привязывая вас к AWS. + - ⛓[DynamoDB](#dynamodb): NoSQL хранилище ключ-значение с низкими задержками + - ⛓[Glacier](#glacier): Медленная и дешевая альтернатива S3 + - ⛓[Kinesis](https://aws.amazon.com/kinesis/): Потоковый сервис(распределенные логи) + - ⛓[SQS](https://aws.amazon.com/sqs/): Сервис очереди сообщений + - ⛓[Redshift](#redshift): Хранилище данных + - 🐥[QuickSight](https://aws.amazon.com/quicksight/): Сервис бизнес-аналитики + - [SES](https://aws.amazon.com/ses/): Отправляйте или принимайте сообщения в целях маркетинга или транзакций + - ⛓[API Gateway](https://aws.amazon.com/api-gateway/): Проксирование, управление и обеспечение безопасности вызовов API + - ⛓[IoT](#iot): Управление двунаправленной связью через HTTP, WebSockets и MQTT между AWS и клиентами (часто, но не обязательно такими “вещами”, как устройства или датчики) + - ⛓[WAF](https://aws.amazon.com/waf/): Интернет ориентированный межсетевой экран использующийся CloudFront для отражения атак + - ⛓[KMS](#kms): Безопасное хранение и управление ключами шифрования + - [Inspector](https://aws.amazon.com/inspector/): Аудит безопасности + - [Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/): Автоматические советы по снижению издержек или внесению улучшений + - 🐥[Certificate Manager](https://aws.amazon.com/certificate-manager/): Управление SSL/TLS сертификатами для сервисов AWS + - 🐥⛓[Fargate](https://aws.amazon.com/fargate/): Управление Docker контейнерами, бэкенд для ECS и EKS +- **Комплексные сервисы:** Они также специфичны, но являются полноценными услугами, которые призваны решить сложные проблемы, однако могут привязать к себе. Полезность зависит от ваших требований. Если у вас есть большие или значительные потребности, возможно это может быть решено на уровне внутренних систем и инженерных команд. + - [Machine Learning](https://aws.amazon.com/machine-learning/): Классификация и модели машинного обучения + - [Lex](https://aws.amazon.com/lex/): Автоматическое распознавание речи (ASR) и понимание языка (NLU) + - [Polly](https://aws.amazon.com/polly/): Движок перевода текста в речь в облаке + - [Rekognition](https://aws.amazon.com/rekognition/): Сервис распознавания изображений + - ⛓🕍[Data Pipeline](https://aws.amazon.com/datapipeline/): Управляемый сервис трансформации данных + - ⛓🕍[SWF](https://aws.amazon.com/swf/): Управляемый менеджер состояний для распределенного рабочего потока(workflow) + - ⛓🕍[Lumberyard](https://aws.amazon.com/lumberyard/): 3D игровой движок +- **Разработка приложений/мобильных приложений:** + - [SNS](https://aws.amazon.com/sns/): Управление push уведомлениями и другими уведомлениями конечных пользователей + - ⛓🕍[Cognito](https://aws.amazon.com/cognito/): Аутенфикация пользователей через Facebook, Twitter и т.д. + - [Device Farm](https://aws.amazon.com/device-farm/): Тестирование облачных устройств + - [Mobile Analytics](https://aws.amazon.com/mobileanalytics/): Решение для аналитики использования приложений + - 🕍[Mobile Hub](https://aws.amazon.com/mobile/): Комплексная управляемая среда для мобильной разработки +- **Корпоративные сервисы:** Эти сервисы актуальны в случае, если у вас есть значительные потребности корпоративных облачных или гибридных сервисов. Многие небольшие компании и стартапы используют другие решения, такие как Google Apps или Box. Более крупные компании могут также использовать собственные не-AWS IT решения. + - [AppStream](https://aws.amazon.com/appstream/): Приложения Windows в облаке, с доступом с множества различных устройств + - [Workspaces](https://aws.amazon.com/workspaces/): Виртуальный рабочий стол Windows в облаке, с доступом с множества различных устройств + - [WorkDocs](https://aws.amazon.com/workdocs/) (бывший Zocalo): Корпоративный документооборот + - [WorkMail](https://aws.amazon.com/workmail/): Корпоративный почтовый сервис с функцией календаря + - [Directory Service](https://aws.amazon.com/directoryservice/): Microsoft Active Directory в облаке + - [Direct Connect](https://aws.amazon.com/directconnect/): Выделенное сетевое соединение между офисом или дата центром и AWS + - [Storage Gateway](https://aws.amazon.com/storagegateway/): Соединение между локальным офисом и файловым хранилищем в AWS + - [Service Catalog](https://aws.amazon.com/servicecatalog/): Управление каталогами IT сервисов и проверка соответствию требованиям +- **Сервисы, которые вам, возможно, не нужно знать:** В конце скажем о том, что согласно нашему опросу, нижеприведенные сервисы не используются широко и часто по хорошим причинам: + - [Snowball](https://aws.amazon.com/importexport/): Если вам необходимо переместить петабайты данных в/из Amazon используя физическое устройство, прочтите о нем. + - [Snowmobile](https://aws.amazon.com/snowmobile/): Устройства это прекрасно, но если вам необходимо отправить в Amazon данные в масштабах экзабайт, ничто не сможет быть лучше чем трейлер набитый дисками. + - [CodeCommit](https://aws.amazon.com/codecommit/): Git. Вы скорее всего уже используете GitHub или какое-то свое решение ([Stackshare](http://stackshare.io/stackups/github-vs-bitbucket-vs-aws-codecommit) предоставляет неофициальную статистику). + - 🕍[CodePipeline](https://aws.amazon.com/codepipeline/): Непрерывная интеграция. У вас наверняка уже есть другое решение. + - 🕍[CodeDeploy](https://aws.amazon.com/codedeploy/): Развертывание кода на серверах EC2. И снова, у вас наверняка есть другое решение. + - 🕍[OpsWorks](https://aws.amazon.com/opsworks/): Управление развертыванием используя Chef или (на ноябрь 2017) Puppet Enterprise. +- [AWS in Plain English](https://www.expeditedssl.com/aws-in-plain-english) предлагает более дружественное объяснение, для чего нужны все остальные сервисы. + +### Инструменты и услуги, представленные на рынке + +Сейчас на рынке столько облачных и ориентированных на “большие данные” корпоративных компаний, что редко кто может угнаться за этим. + +Мы собрали инфографику из некоторых сервисов. Она далека от завершения, но пытается подчеркнуть сервисы, популярные среди практикующих работу с AWS - сервисы которые помогают работать конкретно с AWS или дополняют работу с ним, а также те инструменты, которые должен изучить каждый, работающий с AWS. + +![Популярные услуги и сервисы среди использующих AWS](../figures/aws-market-landscape.png) + +🚧 *Есть предложения по улучшению? Пожалуйста, [сообщите о проблеме](CONTRIBUTING.md).* + + +### Общие понятия + +- 📒 [**Общий справочник AWS**](https://docs.aws.amazon.com/general/latest/gr/Welcome.html) покрывает огромное количество общих понятий и концепций связанных с многими сервисами. +- AWS позволяет производить развертывания в [**регионах(regions)**](https://docs.aws.amazon.com/general/latest/gr/rande.html), которые являются географически распределенными и изолированными месторасположениями, что позволяет снизить задержки и предлагает дополнительную отказоустойчивость. Регионы содержат зоны доступности (availability zones(AZs)), которые обычно является первым инструментом в выборе средств для обеспечения [высокой доступности](#high-availability)). Зоны доступности [физически разделены друг от друга](https://www.youtube.com/watch?v=JIQETrFC_SQ&feature=youtu.be&t=1428) даже в одном и том же регионе, но [могут быть растянуты на несколько физических дата-центров](https://blog.rackspace.com/aws-101-regions-availability-zones). И хотя они связаны между собой каналами с низкой задержкой, стихийные бедствия, влияющие на одну из них, не должны затронуть другие. +- У каждого сервиса есть API **endpoints или точки приема запроса** для каждого региона. Точки приема запроса различаются от сервиса к сервису, кроме того, не все сервисы доступны в каждом регионе.Данные можно почерпнуть в [этих таблицах](https://docs.aws.amazon.com/general/latest/gr/rande.html). +- [**Названия ресурсов Amazon(Amazon Resource Names (ARNs))**](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) это специальным образом отформатированные идентификаторы для идентификации ресурсов. Они начинаются с 'arn:' и используется во многих сервисах, в частности для политик в IAM. + +### Матрица сервисов + +Многие сервисы AWS как минимум могут быть сравнимы с предложениями Google Cloud иили внутренними сервисами Google. Также часто вы можете собрать подобный сервис используя программное обеспечение с открытым кодом. Эта таблица является попыткой перечислить эти грубые соответствия. (Помните, что эта таблица несовершенна, так как почти в каждом случае есть некоторые различия в функциях и особенностях!) + +| Сервис | AWS | Google Cloud | Google Internal | Microsoft Azure | Другие провайдеры | “Построй сам” на открытом коде | Openstack | +|-------------------------------|------------------------------------------------------------------------------|------------------------------|-----------------|------------------------------------|-----------------------------------|------------------------------------------------------------|------------------------------------------------------------| +| Virtual server | EC2 | Compute Engine (GCE) | | Virtual Machine | DigitalOcean | OpenStack | Nova | +| PaaS | Elastic Beanstalk | App Engine | App Engine | Web Apps | Heroku, AppFog, OpenShift | Meteor, AppScale, Cloud Foundry, Convox | +| Serverless, microservices | Lambda, API Gateway | Functions | | Function Apps | PubNub Blocks, Auth0 Webtask | Kong, Tyk | Qinling | +| Container, cluster manager | ECS, EKS, Fargate | Container Engine, Kubernetes | Borg or Omega | Container Service | | Kubernetes, Mesos, Aurora | Zun | +| Object storage | S3 | Cloud Storage | GFS | Storage Account | DigitalOcean Spaces | Swift, HDFS, Minio | Swift | +| Block storage | EBS | Persistent Disk | | Storage Account | DigitalOcean Volumes | NFS | Cinder | +| SQL datastore | RDS | Cloud SQL | | SQL Database | | MySQL, PostgreSQL | Trove (stores NoSQL as well) | +| Sharded RDBMS | | Cloud Spanner | F1, Spanner | Azure Database for PostgreSQL - Hyperscale (Citus) | | Crate.io, CockroachDB | +| Bigtable | | Cloud Bigtable | Bigtable | | | HBase | +| Key-value store, column store | DynamoDB | Cloud Datastore | Megastore | Tables, DocumentDB | | Cassandra, CouchDB, RethinkDB, Redis | +| Memory cache | ElastiCache | App Engine Memcache | | Redis Cache | | Memcached, Redis | +| Search | CloudSearch, Elasticsearch (managed) | | | Search | Algolia, QBox, Elastic Cloud | Elasticsearch, Solr | +| Data warehouse | Redshift | BigQuery | Dremel | SQL Data Warehouse | Oracle, IBM, SAP, HP, many others | Greenplum | +| Business intelligence | QuickSight | Data Studio 360 | | Power BI | Tableau | | +| Lock manager | [DynamoDB (weak)](https://gist.github.com/ryandotsmith/c95fd21fab91b0823328) | | Chubby | Lease blobs in Storage Account | | ZooKeeper, Etcd, Consul | +| Message broker | SQS, SNS, IoT | Pub/Sub | PubSub2 | Service Bus | | RabbitMQ, Kafka, 0MQ | +| Streaming, distributed log | Kinesis | Dataflow | PubSub2 | Event Hubs | | Kafka Streams, Apex, Flink, Spark Streaming, Storm | +| MapReduce | EMR | Dataproc | MapReduce | HDInsight, DataLake Analytics | Qubole | Hadoop | +| Monitoring | CloudWatch | Stackdriver Monitoring | Borgmon | Monitor | | Prometheus(?) | +| Tracing | X-Ray | Stackdriver Trace | | Monitor (Application Insights) | DataDog, New Relic, Epsagon | Zipkin, Jaeger, Appdash +| Metric management | | | Borgmon, TSDB | Application Insights | | Graphite, InfluxDB, OpenTSDB, Grafana, Riemann, Prometheus | +| CDN | CloudFront | Cloud CDN | | CDN | Akamai, Fastly, Cloudflare, Limelight Networks | Apache Traffic Server | +| Load balancer | CLB/ALB | Load Balancing | GFE | Load Balancer, Application Gateway | | nginx, HAProxy, Apache Traffic Server | +| DNS | Route53 | DNS | | DNS | | bind | +| Email | SES | | | | Sendgrid, Mandrill, Postmark | | +| Git hosting | CodeCommit | Cloud Source Repositories | | Visual Studio Team Services | GitHub, BitBucket | GitLab | +| User authentication | Cognito | Firebase Authentication | | Azure Active Directory | | oauth.io | +| Mobile app analytics | Mobile Analytics | Firebase Analytics | | HockeyApp | Mixpanel | | +| Mobile app testing | Device Farm | Firebase Test Lab | | Xamarin Test Cloud | BrowserStack, Sauce Labs, Testdroid | +| Managing SSL/TLS certificates | Certificate Manager | | | | Let's Encrypt, Comodo, Symantec, GlobalSign | +| Automatic speech recognition and natural language understanding | Transcribe (ASR), Lex (NLU) | Cloud Speech API, Natural Language API | | Cognitive services | AYLIEN Text Analysis API, Ambiverse Natural Language Understanding API |Stanford's Core NLP Suite, Apache OpenNLP, Apache UIMA, spaCy | +| Text-to-speech engine in the cloud | Polly | | | |Nuance, Vocalware, IBM | Mimic, eSpeak, MaryTTS | +| Image recognition | Rekognition | Vision API | |Cognitive services | IBM Watson, Clarifai |TensorFlow, OpenCV | +| OCR (Text recognition) | Textract (documents), Rekognition (photographs) | Cloud Vision API | | Computer Vision API | | Tesseract | +| Language Translation | Translate | Translate | | Translator Text API | | Apertium | +| File Share and Sync | WorkDocs | Google Docs | |OneDrive | Dropbox, Box, Citrix File Share |ownCloud | +| Machine Learning | SageMaker, DeepLens, ML | ML Engine, Auto ML | |ML Studio | Watson ML | | +| Data Loss Prevention | Macie | Cloud Data Loss Prevention | | Azure Information Protection | | | + +🚧 [*Пожалуйста помогите заполнить таблицу*](CONTRIBUTING.md) + +Выбранные ресурсы более детализированно: + +- Google internal: [MapReduce](http://research.google.com/archive/mapreduce.html), [Bigtable](http://research.google.com/archive/bigtable.html), [Spanner](http://research.google.com/archive/spanner.html), [F1 vs Spanner](http://highscalability.com/blog/2013/10/8/f1-and-spanner-holistically-compared.html), [Bigtable vs Megastore](http://perspectives.mvdirona.com/2008/07/google-megastore/) + +### Зрелость продуктов AWS и выпуски + +Важно знать зрелость каждого продукта AWS. Это почти полный список дат первых выпусков, которые ссылаются на [примечания к выпуску](https://aws.amazon.com/releasenotes/). Наиболее молодые сервисы идут в списке первыми. Не все сервисы доступны во всех регионах; смотрите [эту таблицу](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). + +| Сервис | Первый выпуск | Доступность | Поддержка CLI | Соответствие HIPAA | Соответствие PCI-DSS | +|------------------------------------------------------------------------------------------------------------|------------------|-------------------------------------------------------------------------------|:-----------:|:---------------:|:-----------------:| +| 🐥[X-Ray](https://aws.amazon.com/releasenotes/AWS-X-Ray?browse=1) | 2016-12 | General |✓ |✓ |✓ | +| 🐥[Lex](https://aws.amazon.com/releasenotes/Amazon-Lex?browse=1) | 2016-11 | Preview | | | | +| 🐥[Polly](https://aws.amazon.com/releasenotes/Amazon-Polly?browse=1) | 2016-11 | General |✓ |✓ |✓ | +| 🐥[Rekognition](https://aws.amazon.com/releasenotes/Amazon-Rekognition?browse=1) | 2016-11 | General |✓ |✓ |✓ | +| 🐥[Athena](http://docs.aws.amazon.com/athena/latest/ug/what-is.html) | 2016-11 | General |✓ |✓ |✓ | +| 🐥[Batch](http://docs.aws.amazon.com/batch/latest/userguide/what-is-batch.html) | 2016-11 | General |✓ |✓ |✓ | +| 🐥[Database Migration Service](https://aws.amazon.com/releasenotes/AWS-Database-Migration-Service?browse=1) | 2016-03 | General | | ✓ | ✓ | +| 🐥[Certificate Manager](https://aws.amazon.com/blogs/aws/new-aws-certificate-manager-deploy-ssltls-based-apps-on-aws/) | 2016-01 | General | ✓ |✓ |✓ | +| 🐥[IoT](https://aws.amazon.com/blogs/aws/aws-iot-now-generally-available/) | 2015-08 | General | ✓ |✓ |✓[13](#user-content-pci-iot) | +| 🐥[WAF](https://aws.amazon.com/releasenotes/AWS-WAF?browse=1) | 2015-10 | General | ✓ | ✓ | ✓ | +| 🐥[Data Pipeline](https://aws.amazon.com/releasenotes/AWS-Data-Pipeline?browse=1) | 2015-10 | General | ✓ | | | +| 🐥[Elasticsearch](https://aws.amazon.com/releasenotes/Amazon-Elasticsearch-Service?browse=1) | 2015-10 | General | ✓ |✓ |✓ | +| 🐥[Aurora](https://aws.amazon.com/releasenotes/2775579329314699) | 2015-07 | General | ✓ | ✓[3](#user-content-hipaa-aurora) | ✓[3](#user-content-hipaa-aurora) | +| 🐥[Service Catalog](https://aws.amazon.com/releasenotes/AWS-Service-Catalog?browse=1) | 2015-07 | General | ✓ |✓ |✓ | +| 🐥[Device Farm](https://aws.amazon.com/releasenotes/AWS-Device-Farm?browse=1) | 2015-07 | General | ✓ | | | +| 🐥[CodePipeline](https://aws.amazon.com/releasenotes/AWS-CodePipeline?browse=1) | 2015-07 | General | ✓ |✓ | | +| 🐥[CodeCommit](https://aws.amazon.com/releasenotes/AWS-CodeCommit?browse=1) | 2015-07 | General | ✓ |✓ |✓ | +| 🐥[API Gateway](https://aws.amazon.com/releasenotes/Amazon-API-Gateway?browse=1) | 2015-07 | General | ✓ | ✓[1](#user-content-hipaa-apigateway) | ✓ | +| 🐥[Config](https://aws.amazon.com/releasenotes/AWS-Config?browse=1) | 2015-06 | General | ✓ |✓ | ✓ | +| 🐥[EFS](https://aws.amazon.com/releasenotes/Amazon-EFS?browse=1) | 2015-05 | General | ✓ |✓ |✓ | +| 🐥[Machine Learning](https://aws.amazon.com/releasenotes/AmazonML?browse=1) | 2015-04 | General | ✓ | | | +| [Lambda](https://aws.amazon.com/releasenotes/AWS-Lambda?browse=1) | 2014-11 | General | ✓ |✓ | ✓ | +| [ECS](https://aws.amazon.com/ecs/release-notes/) | 2014-11 | General | ✓ | ✓ | ✓ | +| [EKS](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) | 2018-06 | General | ✓[12](#user-content-eks-cli) |✓ |✓ | +| [KMS](https://aws.amazon.com/releasenotes/AWS-KMS?browse=1) | 2014-11 | General | ✓ |✓ | ✓ | +| [CodeDeploy](https://aws.amazon.com/releasenotes/AWS-CodeDeploy?browse=1) | 2014-11 | General | ✓ |✓ | | +| [Kinesis](https://aws.amazon.com/releasenotes/Amazon-Kinesis?browse=1) | 2013-12 | General | ✓ |✓ | ✓[11](#user-content-pci-kinesis) | +| [CloudTrail](https://aws.amazon.com/releasenotes/AWS-CloudTrail?browse=1) | 2013-11 | General | ✓ |✓ | ✓ | +| [AppStream](https://aws.amazon.com/releasenotes/Amazon-AppStream?browse=1) | 2013-11 | Preview | |✓ | | +| [CloudHSM](https://aws.amazon.com/releasenotes/AWS-CloudHSM?browse=1) | 2013-03 | General | ✓ |✓ | ✓ | +| [Silk](https://aws.amazon.com/releasenotes/Amazon-Silk?browse=1) | 2013-03 | Obsolete? | | | | +| [OpsWorks](https://aws.amazon.com/releasenotes/AWS-OpsWorks?browse=1) | 2013-02 | General | ✓ |✓ | ✓ | +| [Redshift](https://aws.amazon.com/releasenotes/Amazon-Redshift?browse=1) | 2013-02 | General | ✓ | ✓ | ✓ | +| [Elastic Transcoder](https://aws.amazon.com/releasenotes/Amazon-Elastic-Transcoder?browse=1) | 2013-01 | General | ✓ | | | +| [Glacier](https://aws.amazon.com/releasenotes/Amazon-Glacier?browse=1) | 2012-08 | General | ✓ | ✓ | ✓ | +| [CloudSearch](https://aws.amazon.com/releasenotes/Amazon-CloudSearch?browse=1) | 2012-04 | General | ✓ | | | +| [SWF](https://aws.amazon.com/releasenotes/Amazon-SWF?browse=1) | 2012-02 | General | ✓ |✓ | ✓ | +| [Storage Gateway](https://aws.amazon.com/releasenotes/AWS-Storage-Gateway?browse=1) | 2012-01 | General | ✓ |✓ |✓ | +| [DynamoDB](https://aws.amazon.com/releasenotes/Amazon-DynamoDB?browse=1) | 2012-01 | General | ✓ | ✓ | ✓ | +| [DirectConnect](https://aws.amazon.com/releasenotes/AWS-Direct-Connect?browse=1) | 2011-08 | General | ✓ | ✓ | ✓ | +| [ElastiCache](https://aws.amazon.com/releasenotes/Amazon-ElastiCache?browse=1) | 2011-08 | General | ✓ |✓[14](#user-content-pci-elasticache) |✓[14](#user-content-pci-elasticache) | +| [CloudFormation](https://aws.amazon.com/releasenotes/AWS-CloudFormation?browse=1) | 2011-04 | General | ✓ |✓ | ✓ | +| [SES](https://aws.amazon.com/releasenotes/Amazon-SES?browse=1) | 2011-01 | General | ✓ |✓ | | +| [Elastic Beanstalk](https://aws.amazon.com/releasenotes/AWS-Elastic-Beanstalk?browse=1) | 2010-12 | General | ✓ |✓ | ✓ | +| [Route 53](https://aws.amazon.com/releasenotes/Amazon-Route-53?browse=1) | 2010-10 | General | ✓ |✓ | ✓ | +| [IAM](https://aws.amazon.com/releasenotes/AWS-Identity-and-Access-Management?browse=1) | 2010-09 | General | ✓ | | ✓ | +| [SNS](https://aws.amazon.com/releasenotes/Amazon-SNS?browse=1) | 2010-04 | General | ✓ | ✓ | ✓ | +| [EMR](https://aws.amazon.com/releasenotes/Elastic-MapReduce?browse=1) | 2010-04 | General | ✓ | ✓ | ✓ | +| [RDS](https://aws.amazon.com/releasenotes/Amazon-RDS?browse=1) | 2009-12 | General | ✓ |✓[2](#user-content-hipaa-rds) |✓[9](#user-content-pci-rds) | +| [VPC](https://aws.amazon.com/releasenotes/Amazon-VPC?browse=1) | 2009-08 | General | ✓ | ✓ | ✓ | +| [Snowball](https://aws.amazon.com/releasenotes/AWS-ImportExport?browse=1) | 2015-10 | General | ✓ | ✓ |✓[15](#user-content-pci-snowball) | +| [Snowmobile](https://aws.amazon.com/snowmobile/) | 2016-11 | General | |✓ |✓ | +| [CloudWatch](https://aws.amazon.com/releasenotes/CloudWatch?browse=1) | 2009-05 | General | ✓ |✓ | ✓ | +| [CloudFront](https://aws.amazon.com/releasenotes/CloudFront?browse=1) | 2008-11 | General | ✓ | ✓[4](#user-content-hipaa-cloudfront) | ✓ | +| [Fulfillment Web Service](https://aws.amazon.com/releasenotes/Amazon-FWS?browse=1) | 2008-03 | Obsolete? | | | | +| [SimpleDB](https://aws.amazon.com/releasenotes/Amazon-SimpleDB?browse=1) | 2007-12 | ❗[Nearly obsolete](https://forums.aws.amazon.com/thread.jspa?threadID=121711) | ✓ | | ✓ | +| [DevPay](https://aws.amazon.com/releasenotes/DevPay?browse=1) | 2007-12 | General | | | | +| [Flexible Payments Service](https://aws.amazon.com/releasenotes/Amazon-FPS?browse=1) | 2007-08 | Retired | | | | +| [EC2](https://aws.amazon.com/releasenotes/Amazon-EC2?browse=1) | 2006-08 | General | ✓ | ✓[5](#user-content-hipaa-ec2sysmgr),[6](#user-content-hipaa-ec2ebs),[7](#user-content-hipaa-ec2elb) | ✓[6](#user-content-hipaa-ec2ebs),[7](#user-content-hipaa-ec2elb),[10](#user-content-pci-asg) | +| [SQS](https://aws.amazon.com/releasenotes/Amazon-SQS?browse=1) | 2006-07 | General | ✓ | ✓ | ✓ | +| [S3](https://aws.amazon.com/releasenotes/Amazon-S3?browse=1) | 2006-03 | General | ✓ | ✓[8](#user-content-hipaa-s3) | ✓ | +| [Alexa Top Sites](https://aws.amazon.com/alexa-top-sites/) | 2006-01 | General ❗HTTP-only | | | | +| [Alexa Web Information Service](https://aws.amazon.com/awis/) | 2005-10 | General ❗HTTP-only | | | | + +##### Примечания +**1**: Исключая Amazon API Gateway caching
+**2**: Только для RDS MySQL, Oracle, и PostgreSQL
+**3**: Только для MySQL-совместимой Aurora
+**4**: Исключая Lambda@Edge
+**5**: Включает в себя EC2 Systems Manager
+**6**: Включая Elastic Block Storage (EBS)
+**7**: Включая Elastic Load Balancing
+**8**: Включая S3 Transfer Acceleration
+**9**: Включая RDS MySQL, Oracle, PostgreSQL, SQL Server и MariaDB
+**10**: Включая Автоматическое масштабирование(Auto-Scaling)
+**11**: Data Analytics, Streams, Video Streams и Firehose
+**12**: Kubernetes использует свой CLI для управления подами и службами, называемый kubectl. AWS CLI необходима только для работы с Kubernetes Master
+**13**: IoT Core (включая управление устройствами) и Greengrass
+**14**: Только ElastiCache с Redis
+**15**: Snowball и Snowball Edge
+ + +### Соответствие стандартам и регулирующим документам + +- Многие приложения имеют строгие требования относительно надежности, безопасности и приватности данных. Страница [AWS Compliance](https://aws.amazon.com/compliance/) содержит все детали о сертификациях AWS в области соответствия, включая **PCI DSS Level 1**, **SOC 1,2, and 3**, **HIPAA**, и **ISO 9001**. +- Безопасность в облаке - сложная тема, основывающаяся на [модели распределенной ответственности(shared responsibility model)](https://aws.amazon.com/compliance/shared-responsibility-model/), где некоторые элементы соответствия достигаются за счет усилий AWS, а некоторые за счет ваших усилий и вашей компании. +- Некотороые сторонние поставщики предлагаю помощь в обеспечении соответствия, безопасности и проведения аудита на AWS. Если у вас есть существенная потребность, то помощь - это хорошая идея. +- С континентального **Китая**, сервисы AWS расположеннные вне Китая [в большинстве своем доступны](https://en.greatfire.org/aws.amazon.com), за исключением отдельных временных разрывов доступа. Также имеются сервисы AWS расположенные [в Китае](https://www.amazonaws.cn/en/). + +### Получение помощи и поддержки + +- **Форумы:** Для решения многих проблем, возможно стоит сначала поискать решение в интернете или попросить помощи на [дискуссионных форумах](https://forums.aws.amazon.com/index.jspa), так как скорее всего - это уже известная проблема. +- **Премиум поддержка:** AWS предлагает несколько уровней [премиум поддержки](https://aws.amazon.com/premiumsupport/). + - Первый уровень, называемый "Поддержка разработчиков" позволяет вам открывать тикеты в службе поддержки с временем обработки от 12 до 24 часов, расценки на данный уровень начинаются с $29 в месяц, но как только ваши месячные расходы превышают $1000, оплата за данный уровень поддержки составит 3% от ваших общих расходов. + - Более высокие уровни поддержки довольно таки дороги и могут увеличить сумму в счете на 10%. Многие крупные и эффективные компании никогда не платят за такие уровни поддержки. Они больше полезны для средних и крупных компаний, которым необходимо крайне быстрое решение сложных и глубоких проблем. + - Имейте в виду, что гибкая архитектура может снизить потребность в поддержке. Вы не должны полагаться на то, чтобы AWS часто решало ваши проблемы. Например, если вы с легкостью можете переразвернуть новый сервер, возможно не так уж и срочно стоит решать редкую или даже уникальную проблему на уровне ядра, которая затрагивает только один инстанс EC2. Если у вас есть недавние снапшоты томов EBS, возможно восстановить том будет быстрее, нежели поддержка устранит проблему со старым томом. Если у вас есть какая-либо проблема в одной зоне доступности, в таком случае вы можете положиться на отказоустойчивую стенд-бай зону или смигировать сервисы в другую зону доступности. + - Крупные клиенты также получают доступ к корпоративной поддержке AWS, со специально выделенным техническим менеджером по работе с клиентами(TAM - Technical account manager) и SLA с более коротким временем реакции. + - Определенно есть некоторые контраргументы относительно полезности платной поддержки. Сотрудники службы поддержки не всегда обладают достаточной информацией и полномочиями для решения определенного рода проблем, которые могут у вас возникать. Часто скорость и возможность решения проблем зависит от взаимоотношений с вашим аккаунт менеджером. +- **Аккаунт менеджер:** Если вы тратите значительные средства ( тысячи долларов в месяц), вам может быть назначен ( или вы можете запросить самостоятельно) выделенный аккаунт менеджер. + - Это действительно великолепный ресурс, даже если вы не платите за премиум поддержку. Выстройте с ними хорошие отношения и используйте их для решения вопросов, проблем и получения рекомендаций. + - Назначьте ответственного за контакты с AWS со стороны своей компании, для избежания путаницы и двойной работы. +- **Контакты:** Основная точка контакта с AWS [тут](https://aws.amazon.com/contact-us/). Многие технические вопросы могут быть решены посредством этих каналов связи. +- **Консультанты и компании предоставляющие управляющие услуги:** Для получения дополнительной помощи на местах, AWS установила отношения со многими [партнерами-консалтерами](https://aws.amazon.com/partners/consulting/) и [партнерами по управлению услугами(ИТ управляющие компании)](https://aws.amazon.com/partners/msp/). Крупные консалтеры недешевы, однако, в зависимости от ваших потребностей, могут снизить ваши затраты в долгосрочном периоде путем более эффективного проектирования вашей архитектуры или предложения конкретный опыт, например безопасность. Поставщики управляемых услуг предоставляют долгосрочное полное управление облачными ресурсами. +- **AWS Professional Services:** AWS предоставляет [консультационные услуги](https://aws.amazon.com/professional-services/) самостоятельно или совместно с партнерами. + +### Ограничения и другие заметки + +- 🔸Многие ресурсы в Amazon имеют [**определенные ограничения**](http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) при использовании. В действительности это полезно, таким образом вы не понесете больших расходов случайно. Чтобы запросить увеличение квот, необходимо оставить заявку в службе поддержки. Некоторые ограничения легко увеличить, некоторые нет. (Некоторые из них отмечены в разделах ниже.) В дополнение, не все ограничения опубликованы. + - **Получение информации о текущих ограничениях и их использовании:** Информация об ограничении для сервиса может быть доступна с API сервиса, Trusted Advisor, из них обоих или ни из одного из них (в это случае вам необходимо связаться с поддержкой). [Эта страница](http://awslimitchecker.readthedocs.io/en/latest/limits.html) из документации инструмента awslimitchecker предоставляет хороший обзор возможных средств для получения информации для каждого ограничения. [Этот инструмент](https://github.com/jantman/awslimitchecker) также является очень полезным для автоматизации проверок ограничений. +- 🔸[**Условия обслуживания AWS**](https://aws.amazon.com/service-terms/) обширны. Большая часть - шаблонна, однако имеются довольно таки важные заметки и ограничения по каждому сервису. В частности, есть ограничение на использование многих сервисов AWS в **жизненно важных системах**. (Те, кто ценит юридический юмор, могут рассмотреть пункт 57.10.) + +### Сопутствующие темы + +- [OpenStack](https://www.openstack.org/) это альтернативное AWS частное облако используемое крупными компаниями, которые хотят избежать использования предлагаемых публичных облачных решений. + +Обучение и карьерное развитие +------------------------------- + +### Сертификации + +- **Сертификации:** AWS предлагают [**сертификации**](https://aws.amazon.com/certification/) для профессионалов в IT, которые хотят продемонстрировать свои знания. + - [Certified Cloud Practitioner](https://aws.amazon.com/certification/certified-cloud-practitioner/) + - [Certified Solutions Architect Associate](https://aws.amazon.com/certification/certified-solutions-architect-associate/) + - [Certified Developer Associate](https://aws.amazon.com/certification/certified-developer-associate/) + - [Certified SysOps Administrator Associate](https://aws.amazon.com/certification/certified-sysops-admin-associate/) + - [Certified Solutions Architect Professional](https://aws.amazon.com/certification/certified-solutions-architect-professional/) + - [Certified DevOps Engineer Professional](https://aws.amazon.com/certification/certified-devops-engineer-professional/) + - [Certified Security – Specialty](https://aws.amazon.com/certification/certified-security-specialty/) + - [Certified Big Data – Specialty](https://aws.amazon.com/certification/certified-big-data-specialty/) + - [Certified Advanced Networking – Specialty](https://aws.amazon.com/certification/certified-advanced-networking-specialty/) + - [Certified Machine Learning – Specialty](https://aws.amazon.com/certification/certified-machine-learning-specialty/) + - [Certified Alexa Skill Builder – Specialty](https://aws.amazon.com/certification/certified-alexa-skill-builder-specialty/) + +Сертификации младшего звена(Associate) ранее были обязательным требования для сдачи экзаменов профессионального уровня, сейчас это не так. + +- **Получение сертификата и статуса:** Если вы заинтересованы в обучении и прохождении сертификационных экзаменов с получением статуса сертифицированного специалиста, [этот практический обзор](https://gist.github.com/leonardofed/bbf6459ad154ad5215d354f3825435dc) расскажет вам многое из того, что вам необходимо знать. Официальная страница обучения и сертификации AWS [тут](https://aws.amazon.com/training/), также есть страница с ответами на ЧАсто задаваемые ВОпросы [ЧАВО](https://aws.amazon.com/certification/faqs/). +- **Тренинги для сертификации:** AWS предлагает собственные тренинги (в основном проводящиеся инструктором на базе предприятия заказчика), кроме того, множество сторонних компаний предлагают свои коммерческие тренинги (обычно в виде видео-курсов), к примеру [A Cloud Guru](https://acloud.guru/aws-cloud-training), [CloudAcademy](https://cloudacademy.com/library/amazon-web-services/) and [Linux Academy](https://linuxacademy.com/library/topics/AWS/type/Course/). +- **Необходима ли вам сертификация?** Если вы работаете на ключевых технических ролях в не-технологических компаниях, или, и даже в особенности, если вы работаете в консалтерских компаниях - сертификат является важным документом, подтверждающим вашу экспертизу. С другой стороны, во многих технологических компаниях и стартапах, сертификаты не обязательны. (На деле, справедливо это или нет, некоторые HR-менеджера и нанимающие специалисты из Силиконовой Долины считают сертификаты “плохим” фактором в резюме.) + +Сертификаты необходимы для доступа в ложи сертифицированных специалистов на официальных мероприятиях AWS, таких как [Summits](https://aws.amazon.com/events/summits/) и [re:Invent](https://reinvent.awsevents.com). В ложах обычно предоставляются розетки электропитания, кресла, ну и к слову, кофе у них гораздо лучше. + +Управление AWS +------------ + +### Управление состоянием инфраструктуры и изменениями + +Серьезной проблемой в использовании AWS при построении сложных систем (и с DevOps в целом) является эффективное управление состоянием инфраструктуры на протяжении всего времени использования. В целом это сводится к трем основным целям состояния инфраструктуры: + +- **Видимость**: Знаете ли вы состояние вашей инфраструктуры (какие сервисы вы используете и как именно)? Знаете ли вы также, когда вы или кто-либо из вашей команды вносит изменения? Можете ли вы определить проблемы, неправильные настройки и инциденты связанные с вашими сервисами? +- **Автоматизация**: Можете ли вы перенастроить вашу инфраструктуру, чтобы повторить прошлые конфигурации или масштабировать текущую без большого количества ручной работы или знаний, которые есть только у кого-то в голове? Можете ли вы реагировать на инциденты быстро и легко или вообще автоматически? +- **Гибкость**: Можете ли вы улучшить свою конфигурацию или масштабировать ее новыми способами без значительных усилий? Можете ли вы добавить сложности используя те же самые инструменты? Делитесь ли вы знаниям о конфигурации, пересматриваете и улучшаете ее со своей командой? + +Много из того, о чем пойдет речь ниже о том, как лучшим образом ответить на все эти вопросы. + +Есть несколько подходов по развертыванию инфраструктуры в AWS, начиная с консоли до сложных инструментов автоматизации, сторонних служб, цель которых помочь достичь видимости, автоматизации и гибкости. + +### Управление конфигурацией AWS + +Поначалу большинство людей экспериментируют с AWS через веб-интерфейс, AWS Console. Но использование консоли(AWS Console) - в основном ручной процесс, что часто работает против автоматизации и гибкости. + +Так что, если вы не собираетесь управлять AWS вручную, что же вам делать? К сожалению, тут нет простого, универсального ответа - каждый подход имеет свои плюсы и минусы, и подходы разных компаний различаются очень широко и включают в себя прямое использование API (и построение своих инструментов поверх самостоятельно), использование утилит в командной строке, а также сторонних решений и сервисов. + +### AWS Console + +- [AWS Console](https://aws.amazon.com/console/) позволяет вам контролировать большинство (но не весь) функционала AWS через веб-интерфейс. +- В идеале консоль AWS стоит использовать только в некоторых конкретных случаях: + - Она отлично подходит для использования в режиме только для чтения. Если вы пытаетесь понять состояние вашей системы, вход в консоль и ее просмотр будет очень полезен. + - Это также разумно для очень маленьких систем и команд (для примера, один инженер устанавливает один сервер, который не часто меняется и перенастраивается). + - Это также может быть полезно для действий, которые вы делаете крайне редко, например реже раза в месяц (как пример, одноразовая настройка VPC, вы возможно не вернетесь к ней в течении года). В таком случае использование консоли будет простейшим подходом. +- ❗**Подумайте прежде чем использовать консоль:** AWS консоль удобна, но является врагом автоматизации, The AWS Console is convenient, but also the enemy of automation, воспроизводимости и командных коммуникаций. Если вы, скорее всего, будете делать одну и ту же вещь множество раз, избегайте консоли. Проявите интерес к какой нибудь автоматизации или хотя бы наметьте путь к автоматизации, о которой речь пойдет ниже. Использование консоли не только исключает автоматизацию, что в свою очередь ведет к пустым потерям времени в дальнейшем, но также ведет к предотвращению нормального документирования, ясности и стандартизации процессов для вас и вашей команды. + +### Инструменты командной строки + +- [**Интерфейс командной строки AWS**](https://aws.amazon.com/cli/) (AWS CLI), используемые через комманду **aws**, это самый простой способ автоматизировать управление AWS. +- Не стоит недооценивать его мощь. Его преимущество заключается в том, что он постоянно поддерживается в хорошем состоянии - он покрывает большую часть всех сервисов AWS и регулярно обновляется. +- В общем, выбирайте командную строку, вместо консоли во всех случаях, когда это возможно. +- 🔹Даже в случае отсутствия более изящных инструментов, вы можете **написать простые скрипты на Bash** которые вызывают *aws* с конкретными аргументами, а потом сохранить их в Git. Это простейший, но очень эффективный способ документировать выполненные операции. Это повышает автоматизацию, позволяет проводить код-ревью и делиться с командой, что дает остальным хороший старт для будущей работы. +- 🔹Если вы хотите работать интерактивно (а не через скрипты), попробуйте использовать инструмент [**aws-shell**](https://github.com/awslabs/aws-shell) от AWS. Он прост в использовании, с автозавершением команд и цветным интерфейсом, но также работает в командной строке. Если вы используете [SAWS](https://github.com/donnemartin/saws), предыдущую версию данной программы, [вам стоит перейти на aws-shell](https://github.com/donnemartin/saws/issues/68#issuecomment-240067034). + +### API-интерфейсы и наборы средств разработки(SDK) + +- **Наборы средств разработки(SDK)** для использования API-интерфейсов в AWS APIs доступны в большинстве основных языков, причем [Go](https://github.com/aws/aws-sdk-go), [iOS](https://github.com/aws/aws-sdk-ios), [Java](https://github.com/aws/aws-sdk-java), [JavaScript](https://github.com/aws/aws-sdk-js), [Python](https://github.com/boto/boto3), [Ruby](https://github.com/aws/aws-sdk-ruby) и [PHP](https://github.com/aws/aws-sdk-php) наиболее широко используются. AWS поддерживает свой [шорт-лист](https://aws.amazon.com/tools/#sdk), однако [список awesome-aws](https://github.com/donnemartin/awesome-aws#sdks-and-samples) наиболее полный и актуальный. К сведению, [поддержка C++](https://github.com/donnemartin/awesome-aws#c-sdk) является [относительно новой](https://aws.amazon.com/blogs/aws/introducing-the-aws-sdk-for-c/). +- **Логика повторов:** Важным аспектом при использовании SDK, котороый необходимо учитывать, являяется обработка ошибок; при интенсивном использовании, может произойти множество отказов и ошибок, начиная с ошибок программирования и троттлинга(пропуска запросов), до связанных с AWS отказов сервисов. SDK обычно реализуют [**экспоненциальный откат(плавное и мультипликативное снижение частоты запросов для нахождения не затрагивающей работоспособность системы частоты запросов)**](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) для решения этой проблемы, однако это требует понимания и настройки время от времени для некоторых приложений. Например, часто является полезным оповещение об одних типах ошибок и отсутствие оповещения о других. +- ❗Не используйте API напрямую. Несмотря на то, что документация AWS содержит в себе множество инфорамции о API, все равно лучше использовать SDK на вашем предпочитаемом языке программирования для доступа к API-интерфейсам. SDK более зрелые, надежные и более хорошо поддерживаются, нежели то, что вы напишете сами. + +### Boto + +- Хорошим способом автоматизировать операции в AWS пользователем - является использование [**Boto3**](https://github.com/boto/boto3), также известного, как [Amazon SDK for Python](http://aws.amazon.com/sdk-for-python/). [**Boto2**](https://github.com/boto/boto) - прошлая версия этой библиотеки широко использовалась в течении многих лет, но сейчас есть более новая версия с официальной поддержкой от Amazon, так что есть смысл предпочесть Boto3 для новых проектов. +- Boto3 содержит множество API, которые работают либо на высоком, либо на низком уровне, ниже пояснения об обоих уровнях: + - Низкоуровневые API (Клиентские API) сопоставляются с API-интерфейсами облачных сервисов AWS , и все сервисные операции поддерживаются клиентами. Клиенты генерируются из файлов описания сервисов в формате JSON. + - Высокоуровневая опция - Ресурсные API, позволяет вам избежать вызова сети на низком уровне, а вместо этого предоставляет объектно-ориентированный способ взаимодействия с облачными сервисами AWS. +- У Boto3 есть множество полезных [**функций**](https://boto3.readthedocs.io/en/latest/guide/index.html#general-feature-guides), например *ожидания(waiters)*, которая предоставляет такую структуру, которая позволяет коду ожидать изменений в облаке прежде, чем продолжать выполнение, например, когда вы создаете EC2 инстанс и хотите дождаться пока инстанс запустится, чтобы запустить следующую задачу. +- Если вы пишете Bash скрипт с одной или более CLI команд, возможно вы делаете это неправильно. Остановитесь и подумайте о написании Boto скрипта вместо этого. Тут имеются следующие преимущества: + - Легкая проверка кодов ответа, таким образом успех каждого шага зависит от успеха предыдущих. + - Получайте интересующие вас фрагменты данных из ответов, такие как идентификатор инстанса или DNS имя. + - Добавьте полезную информацию об окружении (например, пометьте(тэгируйте) свои инстансы с помощью git-ревизий или вставьте последний идентификатор сборки в ваш скрипт инициализации). + +### Общая видимость + +- 🔹[**Пометка ресурсов(тегирование)**](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) - это весьма важная практика, особенно при росте организации, для лучшего понимания использования ресурсов. Например, посредством автоматизации и соглашения об именовании, вы можете добавлять пометки(тэги): + - Для организации или разработчиков, которые “владеют” этим ресурсом + - Для продукта, который расположен на данном ресурсе + - Для маркировки жизненного цикла ресурса, к примеру временных ресурсов или тех, которые должны быть отключены и удалены в будущем + - Для того, чтобы различать критично важную для производства инфраструктуру(например, обслуживающие системы или бэкенд) + - Для того, чтобы различать системы со специальными требованиями по безопасности или требованиям соотвествиям стандартам и политикам + - Для того, чтобы (после включения) [распределить стоимость в счетах](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html). Имейте ввиду, что использование меток(тэгов) для распределения стоимости работает только на перспективной основе; вы не можете задним числом применить их к ресурсам, счета на которые уже выставлены. + - В течении многих лет существовал пресловутый лимит на 10 меток(тэгов) на ресурс, который нельзя было увеличить, что причиняло серьезные страдания многим компаниям. По состоянию на 2016 год, лимит [был увеличен](https://aws.amazon.com/blogs/security/now-organize-your-aws-resources-by-using-up-to-50-tags-per-resource/) до 50 меток(тэгов) на ресурс. + - 🔹В 2017 AWS представило возможность [форсированного применения меток(тэгирования)](https://aws.amazon.com/blogs/aws/new-tag-ec2-instances-ebs-volumes-on-creation/) при создании инстансов и томов, что сделало бесполезными некоторые сторонние инструменты, такие как [Cloud Custodian](https://github.com/capitalone/cloud-custodian). + - 🔸 Метки(тэги) чувствительны к регистру; 'environment' и 'Environment' - это две разных метки(тэга). Автоматизация при установке меток(тэгов) скорее всего единственный разумный вариант в значительных масштабах. + - 🔸 В консоли ASG есть баг, пробелы после имени метки(тэга) сохраняются. Таким образом если вы введете "Name " с пробелом на конце, вы не получите ожидаемого результата. Также существует возможность, что баг существует в других местах и SDK. Удостоверьтесь, что вы не добавляете пробелы в конце имени метки, кроме случаев, когда вам это действительно необходимо. (По состоянию на июль 2018 года) + +Управление серверами и приложениями +--------------------------------- + +### AWS и конфигурация серверов + +Это руководство посвящено AWS, а не DevOps или управлению конфигурацией серверов в общем. Но прежде чем углубляться в AWS, стоит отметить, что в дополнение к управлению конфигурацией ваших ресурсов AWS существует давняя проблема управления конфигурацией для самих серверов. + +### Философия + +- В принципах [**Двеннадцати-факторного приложения**](http://12factor.net/) от Heroku перечислены некоторые общепринятые рекомендации по развертыванию приложений. +- **Домашние любимцы и скот:** Относитесь к серверам [как к скоту, а не как к домашнему любимцу](https://www.engineyard.com/blog/pets-vs-cattle). Таким образом, проектируйте систему так, как будто инфраструктура одноразовая. Таким образом неожиданная потеря сервера не должна вызывать серьезного беспокойства. +- Концепция [**неизменной инфраструктуры**](http://radar.oreilly.com/2015/06/an-introduction-to-immutable-infrastructure.html) является продолжением этой идеи. +- Минимизируйте размещение приложений на EC2 инстансах. В целом, инстансы могут умереть или быть выключены, или удалены с минимальным влиянием на приложения. Данные вашего приложение должны быть перемещены в RDS, S3, DynamoDB, EFS, или любое другое хранилище данных, не зависящее от инстанса. EBS также является вариантом, хотя это не должен быть загрузочный том, а также EBS потребует ручного или автоматического переподключения. + +### Управление конфигурацией серверов + +- Существует [большой набор](https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software) инструментов с открытым кодом, для управления конфигурацией серверных инстансов. +- Они, как правило, не зависят от конкретной облачной инфраструктуры и работают с множеством различных вариаций Linux дистрибутивов (или, во многих случаях, с множеством операционных систем). +- Лидирующими инструментами управления конфигурациями являются [Puppet](https://github.com/puppetlabs/puppet), [Chef](https://github.com/chef/chef), [Ansible](https://github.com/ansible/ansible), и [Saltstack](https://github.com/saltstack/salt). Они не являются предметом данного руководства, но мы можем упомянуть их, поскольку они относятся к AWS. + +### Контейнера и AWS + +- [Docker](http://blog.scottlowe.org/2014/03/11/a-quick-introduction-to-docker/) aи тенденция контейнеризации меняет способ развертывания многих серверов и служб в целом. +- Контейнеры предназначены для того, чтобы известным способом упаковать ваши приложения и все их зависимости. Когда вы создаете контейнер, вы включаете каждую библиотеку или двоичный файл, которые нужны вашему приложению, помимо ядра. Большим преимуществом этого подхода является легкость тестирования и проверки контейнера локально, не беспокоясь о разнице конфигурации между вашим локальным компьютером и серверами, на которых вы развертываете приложение. +- Следствием этого подхода является то, что вам требуется меньшее количество образов виртуальных машин AWS(AMI) и загрузочных скриптов; для большинства развертываний единственным загрузочным скриптом, который вам понадобится, является шаблон который подтягивает экспортированный образ Docker-контейнера и запускает его. +- Компании, использующие [микросервисные инфраструктуры](http://martinfowler.com/articles/microservices.html) часто выбирают контейнерное развертывание. +- AWS запустил [ECS](https://aws.amazon.com/ecs/) - сервис управляющий кластерами Docker в конце 2014 года, хотя многие люди до сих пор используют Docker непосредственно напрямую. Подробности смотрите в [разделе ECS](#ecs). +- AWS запустил [EKS](https://aws.amazon.com/eks/) сервис управляющий кластерами Kubernetes в середине 2018 года, хотя многие люди до сих пор разворачивают кластера используя ECS или самостоятельно используют непосредственно Docker. Подробности смотрите в [разделе EKS ](#eks). + +### Видимость + +- Храните и отслеживайте метаданнные инстанса (такие как идентификатор инстанса, зона доступности, и т.д.) и информацию о развертывании (идентификатор сборки приложения, ревизия Git, и т.д.) в ваших лог-файлах и отчетах. [**Сервис метаданных инстансов(instance metadata service)**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) может помочь собрать часть необходимых данных о ресурсах AWS. +- **Используйте сервисы управления лог-файлами:** Обязательно настройте способ просмотра и управления логами вне серверов. + - Облачные сервисы, такие как [Sumo Logic](https://www.sumologic.com/), [Splunk Cloud](http://www.splunk.com/en_us/cloud.html), [Scalyr](https://www.scalyr.com/), [LogDNA](https://www.logdna.com/), и [Loggly](https://www.loggly.com/) самые простые в настройке и использовании (а также самые дорогие, что может быть факторов против их использования, в зависимости от количества логов, которые необходимо хранить). + - Основные альтернативы с открытым исходным кодом включают [Elasticsearch](https://github.com/elastic/elasticsearch), [Logstash](https://github.com/elastic/logstash), и [Kibana](https://github.com/elastic/kibana) (так называемый “[Elastic Stack](https://www.elastic.co/webinars/introduction-elk-stack)”) и [Graylog](https://www.graylog.org/). + - Если вы можете себе это позволить (например, у вас мало данных или много денег) и у вас нет особых потребностей, имеет смысл использовать хостинговые сервисы, когда это возможно, поскольку установка ваших собственных масштабируемых систем обработки логов занимает много времени. +- **Отслеживание и визуализация метрик:** AWS Консоль может показать вам простые графики из CloudWatch, вы также можете пожелать отслеживать и визуализировать многие виды метрик, как из CloudWatch, так и из вашего приложения. Собирайте и экспортируйте полезные метрики везде, где можете (и если объем логов достаточно управляем, вы можете себе это позволить). + - Сервисы вроде [Librato](https://www.librato.com/), [KeenIO](https://keen.io/), и [Datadog](https://www.datadoghq.com/) имеют более интересные функции и более удобные пользовательские интерфейсы, что может сохранить много времени. (Более детальное сравнение [тут](http://blog.takipi.com/production-tools-guide/visualization-and-metrics/).) + - Используйте [Prometheus](https://prometheus.io) или [Graphite](https://github.com/graphite-project/graphite-web) как базы данных временных рядов для ваших метрик (оба варианта с открытым исходным кодом). + - [Grafana](https://github.com/grafana/grafana) может визуализировать с помощью инструментальных панелей(дашбордов) сохраненные метрики из обеих баз данных временных рядов (также с открытым исходным кодом). + +### Советы по управлению серверами + +- ❗**Настройки часового пояса на серверах**: Кроме случаев *абсолютной необходимости*, всегда **устанавливайте часовой пояс на серверах в [UTC](https://en.wikipedia.org/wiki/Coordinated_Universal_Time)** (смотрите инструкции к вашему дистрибутиву, например [Ubuntu](https://www.digitalocean.com/community/tutorials/how-to-set-up-timezone-and-ntp-synchronization-on-ubuntu-14-04-quickstart), [CentOS](https://www.vultr.com/docs/setup-timezone-and-ntp-on-centos-6) или [Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html) Linux). Многочисленные распределенные системы зависят от времени для синхронизации и координации, а UTC [предоставляет](https://blog.serverdensity.com/set-your-server-timezone-to-utc/) универсальную базовую плоскость: она не зависит от сезонных изменений времени и изменений локального времени. Это также избавит вас от головной боли при отладке [проблем с часовыми поясами](http://yellerapp.com/posts/2015-01-12-the-worst-server-setup-you-can-make.html) и предоставит вам согласованную временную шкалу событий в ваших системах логирования и аудита событий. +- **NTP и точное время:** Если вы не используете Amazon Linux (который поставляется предварительно сконфигурированным), вы должны быть уверены что [сконфигурировали NTP на серверах правильно](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html#configure_ntp), чтобы избежать расхождения времени (что может вызвать всевозможные проблемы, от прерывания вызовов API до вводящих в заблуждение записях в лог-файлах). Это должно быть частью автоматической настройки для каждого сервера. Если же расхождение времени в значительной степени (обычно >1000 секунд) уже произошло, помните, что NTP не вернет его назад, так что вам придется перевести его вручную (например, [вот так](http://askubuntu.com/questions/254826/how-to-force-a-clock-update-using-ntp) на Ubuntu). +- **Тестирование неизменной инфраструктуры:** Если вы хотите проактивно тестировать способность ваших сервисов справляться с внезапным отказом или падением инстансов, было бы полезным производить падение случайного инстанса в рабочее время, что поможет выявить любые подобные проблемы в то время, когда инженера доступны для идентификации и решения проблем. [Simian Army от Netflix](https://github.com/Netflix/SimianArmy) (в особенности, [Chaos Monkey](https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey)) очень популярный инструмент подобного рода. Альтернативным вариантом является [chaos-lambda](https://github.com/bbc/chaos-lambda) от BBC - это легковесный инструмент работающий на AWS [Lambda](#lambda). + +Безопасность и IAM +---------------- + +Сначала мы рассмотрим основы безопасности, так как настройка учетных записей пользователей - это то, что вы обычно должны делать на ранних этапах настройки системы. + +### Основы безопасности и IAM + +- 📒 IAM [Домашняя страница](https://aws.amazon.com/iam/) ∙ [Руководство пользователя](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) ∙ [ЧаВо](https://aws.amazon.com/iam/faqs/) +- [Блог **Безопасность в AWS**](https://blogs.aws.amazon.com/security) - один из лучших источников новостей и информации о безопасности в AWS. +- **IAM** - сервис управления учетными записями и разрешениями в AWS. +- Управление безопасностью и контроль доступа в AWS является крайне критичным, поэтому каждый администратор AWS должен использовать и понимать IAM, по крайней мере, на базовом уровне. +- [Учетные записи в IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) включают пользователей (людей или сервисы, использующие AWS), группы (контейнера для наборов пользователей и их разрешений) и роли (контейнера для разрешений назначенных для сервисных инстансов AWS). [Разрешения](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_permissions.html) для этих учетных записей управляются [политиками](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html). Вы можете использовать предустановленные AWS политики или собственные политики, которые вы можете создать самостоятельно. +- IAM управляет различными видами аутентификации как для пользователей, так и для программных сервисов, которым может потребоваться аутентификация с помощью AWS, включая: + - [**Пароли**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords.html) для входа в консоль. Они представляют из себя пары имя пользователя - пароль для реальных пользователей. + - [**Ключи доступа**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html), которые вы можете использовать для инструментов, использующих интерфейс командной строки. Это две строки, одна из которых “идентификатор”, состоящая из заглавных букв строка типа 'AXXXXXXXXXXXXXXXXXXX', а вторая - секрет, состоящая из 40 знаков разно-регистровая строка формата base64. Обычно они устанавливаются для сервисов, а не только для пользователей. + - 📜 Ключи, которые начинаются с AKIA - обычные. Ключи, которые начинаются с ASIA - временные/сессионные ключи из STS, и требуют дополнительного параметра "SessionToken" помимо идентификатора и секрета. Более подробно в документации сказано [о полном списке префиксов ключей доступа](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-prefixes). + - [**Мульти-факторная аутенфикация (MFA)**](https://aws.amazon.com/iam/details/mfa/), - настоятельно рекомендуемая практика использования брелка с токеном или приложения на смартфоне в качестве второго уровня защиты для аутентификации пользователя. +- IAM позволяет осуществлять сложный и детальный(гранулярный) контроль над разрешениями, разделять пользователей на группы, назначать разрешения ролям и т. д. Существует [язык политик](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html), который позволяет кастомизировать политики в целях осуществления детального(гранулярного) контроля. + - Отличный общий обзор концепций политики IAM - [Политики IAM в двух словах](http://start.jcolemorrison.com/aws-iam-policies-in-a-nutshell/). + - 🔸Язык описания политик имеет довольно сложный и подверженный ошибка синтаксис JSON, что может привести к путанице, поэтому, пока вы не эксперт, разумным выбором является использование авторитетных примеров или предустановленных политик [управляемых AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html). +- С начала, политики IAM могут показаться простыми, но с ростом систем, политики также будут усложняться и должны управляться с осторожностью. + - 🔹Убедитесь, что одному человеку (возможно, с замещающим человеком) в вашей организации официально поручено управление политиками IAM, а также чтобы каждый администратор работал с этим человеком для проверки изменений. Это имеет большое значение для предотвращения случайных ошибок в настройках, которые могут повлечь серьезные последствия. +- Лучшей практикой является выдача пользователям и сервисам тех минимальных привилегий и разрешений, которые необходимы им для выполнения их задач. [Принцип минимальных привилегий](https://en.wikipedia.org/wiki/Principle_of_least_privilege) - одна из основ качественного обеспечения безопасности. Организуйте всех пользователей и группы IAM в соответствии с необходимыми уровнями доступа. +- IAM использует [иерархию разрешений](http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html), включая: + 1. Явный запрет: Наиболее ограничивающая политика имеет высший приоритет. + 2. Явное разрешение: Разрешения доступа к любому ресурсу должны быть явно выданы. + 3. Неявный запрет: Все, что явно не разрешено - запрещено по умолчанию. +- Вы можете тестировать политики разрешений с использованием инструмента [симулятора политик AWS IAM](https://policysim.aws.amazon.com/home/index.jsp). Это в особенности полезно, когда вы пишите собственные политики. + + +### Советы по безопасности и IAM + +- 🔹Используйте IAM для создания индивидуальных пользовательских учетных записей **с самого начала используйте учетные записи IAM для всех пользователей**. Это займет какое-то количество трудозатрат, но не особо большое. + - Таким образом, вы определяете разных пользователей и группы с разными уровнями привилегий (если хотите, выбирайте из предложенных Amazon по умолчанию, администратора, опытного пользователя и т.д.). + - Это позволяет производить отзыв учетных записей, что может быть критичным в некоторых ситуациях. Если сотрудник увольняется или ключи скомпроментированы, вы можете отозвать учетные записи с небольшими усилиями. + - Вы можете использовать [службу федерации Active Directory](https://blogs.aws.amazon.com/security/post/Tx71TWXXJ3UI14/Enabling-Federation-to-AWS-using-Windows-Active-Directory-ADFS-and-SAML-2-0) для использования учетных записей вашей организации в AWS. +- ❗**Включите Мульти-факторную аутенфикацию [MFA](https://aws.amazon.com/iam/details/mfa/)** в настройках вашей учетной записи. + - Вам следует всегда использовать мульти-факторную аутенфикацию(MFA) и чем раньше - тем лучше, чем больше пользователей будет, тем больше времени это займет. + - Увы, принудительное включение не может быть произведено в программном обеспечении, так что вам придется создавать административную политику. + - Большинство пользователей может использовать Google Authenticator (на [iOS](https://itunes.apple.com/us/app/google-authenticator/id388497605) или [Android](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2)) для двух-факторной аутентификации. Для основной(root) учетной записи, стоило бы приобрести устройство в виде брелка, который генерирует токены. +- ❗Максимально ограничьте использование привилигерованных учетных данных IAM. Помните, что в облаке потеря привилигированных учетных данных IAM может, по существу, означать «игра окончена» для ваших развертываний, ваших пользователей или всей вашей компании. + - **НЕ ИСПОЛЬЗУЙТЕ [основную(Root) учетную запись](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)** в любых других ситуациях, кроме первичного создания своей учетной записи. Создайте учетные записи IAM для пользователей и/или IAM роли для ваших приложений. + - Максимально ограничьте доступ и возможность использования основной(Root) учетной записи. В идеале она всегда должна быть в оффлайне. В случае крайней необходимости ее использования, она должна быть привязана к физическому устройству мультифакторной аутенфикации, храниться в оффлайне в защищенном месте и использоваться крайне редко. +- ❗**Включите CloudTrail:** Одним из первых дел, которые вы должны сделать - [включить CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html). Даже если вы не повернуты на безопасности, нет никаких причин не делать этого с самого начала, таким образом у вас всегда будет информация о том, что происходит у вас в AWS, а вам это точно пригодится. Кроме того, вы можете также захотеть поставить какой-нибудь [сервис управления лог-файлами](#visibility) для поиска событий и доступа к этим лог-файлам. +- 🔹**Используйте IAM роли для EC2:** Вместо того, чтобы создавать учетные записи пользователей в IAM и потом вставлять чувствительные данные типа логин/пароль в конфигурацию приложения, лучше стоит [определить и назначить роли EC2 инстансов](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) таким образом приложения будут получать данные из [метаданных инстанса](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html). +- Назначьте роли IAM по областям применения - например, для разработки, стейджинга и эксплуатации. Если вы настраиваете роль, она должна быть привязана к определенной области, чтобы у вас было четкое разделение прав доступа. Это позволит избежать таких случаев, когда например система в разработке цепляется к боевой базе данных. +- **Лучшие практики:** [Список лучших практик AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) стоит того, чтобы прочитать его в полном объеме. +- **Справочник по IAM:** [Этот интерактивный справочник по действиям IAM, эффектам и ресурсам](https://iam.cloudonaut.io/) было бы прекрасно иметь под рукой, когда начинаешь писать новые или пытаешься понять существующие политики IAM. +- **Использование нескольких учетных записей AWS:** Решите, необходимо ли вам использование нескольких учетных записей AWS и [изучите](https://dab35129f0361dca3159-2fe04d8054667ffada6c4002813eccf0.ssl.cf1.rackcdn.com/downloads/pdfs/Rackspace%20Best%20Practices%20for%20AWS%20-%20Identity%20Managment%20-%20Billing%20-%20Auditing.pdf) как организовать доступ между ними. Факторы к рассмотрению: + - Количество пользователей + - Важность изоляции + - Лимиты ресурсов + - Детальность разрешений(гранулярность) + - Безопасность + - Лимиты API + - Нормативные вопросы + - Рабочие нагрузки + - Размер инфраструктуры + - “Добавленная стоимость” использования нескольких учетных записей: Внутренние Внутренние инструменты управления сервисами AWS могут нуждаться в индивидуальной сборке или адаптации. + - 🔹Имеет смысл использовать раздельные учетные записи AWS для независимых частей вашей инфраструктуры, если вы планируете большую частоту вызовов AWS API, так как AWS [троттлит(пропускает) вызовы](http://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate) на уровне учетной записи AWS. +- [**Inspector**](https://aws.amazon.com/inspector/) - сервис автоматической оценки безопасности от AWS, помогающий выявить общие угрозы безопасности. Этот сервис позволяет проверить, что вы придерживаетесь определенных мер безопасности и может помочь с соблюдением требований регуляторов и стандартов. +- [**Trusted Advisor**](https://aws.amazon.com/blogs/aws/trusted-advisor-console-basic/) проверяет соотвествие различным лучшим практикам, кроме того предлагает некоторые проверки безопасности, в основном использования IAM, конфигурации групп безопасностии использования мультифакторной аутенфикации(MFA). При использовании уровней платной поддержки, Trusted Advisor также раскрывает результаты дополнительных проверок относительно других областей, как например оптмизацию использования зарезервированных инстансов. +- **Используйте KMS для управления ключами**: AWS предлагает [KMS](#kms) для защищенного управления ключами шифрования, что обычно является более лучшим варииантом, нежели самостоятельное обеспечение безопасности ключей. Смотрите [ниже](#kms). +- [**AWS WAF**](https://aws.amazon.com/waf) - это файрвол веб-приложений, позволяющий вам защитить ваши приложения от стандартных атак. +- **Аудит безопасности:** + - [Security Monkey](https://github.com/Netflix/security_monkey) это инструмент с открытым исходным кодом, предназначенный для помощи при проведении аудита безопасности. + - [Scout2](https://github.com/nccgroup/Scout2) это инструмент с открытым исходным кодом, использующий AWS API для оценки состояния безопасности среды. Scout2 стабилен и активно поддерживается. + - 🔹**Экспорт и настройки аудита безопасности:** Вы можете проверить политики безопасности, просто экспортировав настройки через AWS API, например используя Boto скрипт, вроде [SecConfig.py](https://gist.github.com/jlevy/cce1b44fc24f94599d0a4b3e613cc15d) (с вот [этого доклада 2013 года](http://www.slideshare.net/AmazonWebServices/intrusion-detection-in-the-cloud-sec402-aws-reinvent-2013)) и затем пересмотреть их и в последующем мониторить изменения вручную или автоматически. + +### Ошибки и ограничения в вопросе обеспечения безопасности и IAM + +- ❗**Не делитесь учетными данными пользователей:** Замечательно возможностью для новичков в AWS является создание одной учетной записи и одного набора учетных данных (ключ доступа или пароль), и затем использовать их какое-то время, распространяя среди инженеров, да и вообще всех в компании. Это легко. Но *не делайте этого*. Это небезопасная практика по многим причинам, но, в частности, если вы это сделаете, у вас будет меньше возможностей для отзыва учетных данных для каждого пользователя или для каждого сервиса (например если работник уволился или ключ скомпроментирован), что может привести к серьезным проблемам. +- ❗**Троттлинг(пропуск) метаданных инстанса:** [Сервис метаданных инстанса](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) имеет определенное ограничение по частоте вызовов API. И если вы широко используете роли IAM (как и должны!) и у вас много сервисов, вы с легкостью достигнете глобальных ограничений на учетную запись. + - Одним из решений является написание скриптов кэширующих и заново использующих учетные данные локально на короткий период (скажем 2 минуты). Например, они могут быть прописаны в файл ~/.aws/credentials, но также должны обновляться автоматически. + Но будьте осторожны, чтобы не кэшировать учетные данные слишком долго, так как [они истекают](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials). (Обратите внимание, что [динамические метаданные](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#dynamic-data-categories) также меняются с течением времени и не должны быть закэшированы в течении долгого времени.) +- 🔸Некоторые операции IAM медленнее чем API вызовы других сервисов (несколько секунд), ввиду того, что AWS необходимо распространить их глобально на все регионы. +- ❗Время работы API IAM исторически было ниже, нежели API метаданных инстанса. Остерегайтесь включения зависимости от API IAM в критичные части или подсистемы, например если вы производите валидацию членства пользователя в группе IAM, при этом не обращаете внимания на возможность прекэширования членства в группе или возможное существование бэкдора, может произойти ситуация, когда вы перестанете блокировать любых пользователей, когда API недоступен. +- ❗**Не вносите учетные данные и, тем более, секреты в git репозитории.** Существуют автоматические боты, сканирующие GitHub в поисках учетных данных. Используйте скрипты или инструменты, такие как [git-secrets](https://github.com/awslabs/git-secrets) для предотвращения того, что кто-либо из вашей команды внесет чувствительную информацию в ваш git репозиторий. + +S3 +-- + +### S3 Basics + +- 📒 [Homepage](https://aws.amazon.com/s3/) ∙ [Developer guide](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html) ∙ [FAQ](https://aws.amazon.com/s3/faqs/) ∙ [Pricing](https://aws.amazon.com/s3/pricing/) +- **S3** (Simple Storage Service) is AWS’ standard cloud storage service, offering file (opaque “blob”) storage of arbitrary numbers of files of almost any size, from 0 to **5TB**. (Prior to [2011](https://aws.amazon.com/releasenotes/Amazon-S3/1917932037969964) the maximum size was 5 GB; larger sizes are now well supported via [multipart support](https://docs.aws.amazon.com/AmazonS3/latest/dev/mpuoverview.html).) +- Items, or **objects**, are placed into named **buckets** stored with names which are usually called **keys**. The main content is the **value**. +- Objects are created, deleted, or updated. Large objects can be streamed, but you cannot modify parts of a value; you need to update the whole object. Partial data access can work via [S3 Select](https://aws.amazon.com/blogs/aws/s3-glacier-select/). +- Every object also has [**metadata**](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html), which includes arbitrary key-value pairs, and is used in a way similar to HTTP headers. Some metadata is system-defined, some are significant when serving HTTP content from buckets or CloudFront, and you can also define arbitrary metadata for your own use. +- **S3 URIs:** Although often bucket and key names are provided in APIs individually, it’s also common practice to write an S3 location in the form 's3://bucket-name/path/to/key' (where the key here is 'path/to/key'). (You’ll also see 's3n://' and 's3a://' prefixes [in Hadoop systems](https://cwiki.apache.org/confluence/display/HADOOP2/AmazonS3).) +- **S3 vs Glacier, EBS, and EFS:** AWS offers many storage services, and several besides S3 offer file-type abstractions. [Glacier](#glacier) is for cheaper and infrequently accessed archival storage. [EBS](#ebs), unlike S3, allows random access to file contents via a traditional filesystem, but can only be attached to one EC2 instance at a time. [EFS](#efs) is a network filesystem many instances can connect to, but at higher cost. See the [comparison table](#storage-durability-availability-and-price). + +### S3 Tips + +- For most practical purposes, you can consider S3 capacity unlimited, both in total size of files and number of objects. The number of objects in a bucket is essentially also unlimited. Customers routinely have millions of objects. +- ❗**Permissions:** + - 🔸If you're storing business data on Amazon S3, it’s important to manage permissions sensibly. In 2017 companies like [Dow Jones and Verizon](http://www.techrepublic.com/article/massive-amazon-s3-breaches-highlight-blind-spots-in-enterprise-race-to-the-cloud/) saw data breaches due to poorly-chosen S3 configuration for sensitive data. Fixing this later can be a difficult task if you have a lot of assets and internal users. + - 🔸There are 3 different ways to grant permissions to access Amazon S3 content in your buckets. + + **IAM policies** use the familiar [Identity and Authentication Management](#security-and-iam) permission scheme to control access to specific operations. + + **Bucket policies** grant or deny permissions to an entire bucket. You might use this when hosting a website in S3, to make the bucket publicly readable, or to restrict access to a bucket by IP address. Amazon's [sample bucket policies](http://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies.html) show a number of use cases where these policies come in handy. + + **[Access Control Lists](http://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html)** (ACLs) can also be applied to every bucket and object stored in S3. ACLs grant additional permissions beyond those specified in IAM or bucket policies. ACLs can be used to grant access to another AWS user, or to predefined groups like the general public. This is powerful but can be dangerous, because you need to inspect every object to see who has access. + - 🔸AWS' [predefined access control groups](http://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#specifying-grantee-predefined-groups) allow access that may not be what you'd expect from their names: + + **"All Users", or "Everyone", grants permission to the general public**, not only to users defined in your own AWS account. If an object is available to All Users, then it can be retrieved with a simple HTTP request of the form `http://s3.amazonaws.com/bucket-name/filename`. No authorization or signature is required to access data in this category. + + **"Authenticated Users" grants permissions to anyone with an AWS account**, again not limited to your own users. Because anyone can sign up for AWS, for all intents and purposes **this is also open to the general public**. + + **"Log Delivery" group is used by AWS to write logs to buckets** and should be safe to enable on the buckets that need it. + + A typical use case of this ACL is used in conjunction with the [requester pays](http://docs.aws.amazon.com/AmazonS3/latest/dev/RequesterPaysBuckets.html) functionality of S3. + - ❗ Bucket permissions and object permissions are two different things and independent of each other. A private object in a public bucket can be seen when listing the bucket, but not downloaded. At the same time, a public object in a private bucket won't be seen because the bucket contents can't be listed, but can still be downloaded by anyone who knows its exact key. Users that don't have access to set bucket permissions can still make objects public if they have `s3:PutObjectAcl` or `s3:PutObjectVersionAcl` [permissions](http://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html). + - 🐥In August 2017, AWS added [AWS Config rules to ensure your S3 buckets are secure](https://aws.amazon.com/blogs/aws/aws-config-update-new-managed-rules-to-secure-s3-buckets/). + + ❗These AWS Config rules only check the security of your bucket policy and bucket-level ACLs. You can still create object ACLs that grant additional permissions, including opening files to the whole world. + - 🔹Do create new buckets if you have different types of data with different sensitivity levels. This is much less error prone than complex permissions rules. For example, if data is for administrators only, like log data, put it in a new bucket that only administrators can access. + - For more guidance, see: + + [How to Secure an Amazon S3 Bucket](https://read.acloud.guru/how-to-secure-an-s3-bucket-7e2dbd34e81b) + + [Deep dive into S3 access controls](https://labs.detectify.com/2017/07/13/a-deep-dive-into-aws-s3-access-controls-taking-full-control-over-your-assets/). + + [How do S3 permissions work?](https://brandonwamboldt.ca/understanding-s3-permissions-1662/). +- **Bucket naming:** Buckets are chosen from a global namespace (across all regions, even though S3 itself stores data in [whichever S3 region](https://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region) you select), so you’ll find many bucket names are already taken. Creating a bucket means taking ownership of the name until you delete it. Bucket names have [a few restrictions](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html) on them. + - Bucket names can be used as part of the hostname when accessing the bucket or its contents, like `.s3-us-east-1.amazonaws.com`, as long as the name is [DNS compliant](http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html). + - A common practice is to use the company name acronym or abbreviation to prefix (or suffix, if you prefer DNS-style hierarchy) all bucket names (but please, don’t use a check on this as a security measure — this is highly insecure and easily circumvented!). + - 🔸Bucket names with '.' (periods) in them [can cause certificate mismatches](https://forums.aws.amazon.com/thread.jspa?threadID=169951) when used with SSL. Use '-' instead, since this then conforms with both SSL expectations and is DNS compliant. +- **Versioning:** S3 has [optional versioning support](https://docs.aws.amazon.com/AmazonS3/latest/dev/ObjectVersioning.html), so that all versions of objects are preserved on a bucket. This is mostly useful if you want an archive of changes or the ability to back out mistakes (caution: it lacks the featureset of full version control systems like Git). +- **Durability:** Durability of S3 is extremely high, since internally it keeps several replicas. If you don’t delete it by accident, you can count on S3 not losing your data. (AWS offers the seemingly improbable durability rate of [99.999999999%](https://aws.amazon.com/s3/faqs/#How_durable_is_Amazon_S3), but this is a mathematical calculation based on independent failure rates and levels of replication — not a true probability estimate. Either way, S3 has had [a very good record](https://www.quora.com/Has-Amazon-S3-ever-lost-data-permanently) of durability.) Note this is *much* higher durability than EBS! +- 💸**S3 pricing** depends on [storage, requests, and transfer](https://aws.amazon.com/s3/pricing/). + - For transfer, putting data into AWS is free, but you’ll pay on the way out. Transfer from S3 to EC2 in the *same region* is free. Transfer to other regions or the Internet in general is not free. + - Deletes are free. +- **S3 Reduced Redundancy and Infrequent Access:** Most people use the Standard storage class in S3, but there are other storage classes with lower cost: + - 🔸[Reduced Redundancy Storage (RRS)](https://aws.amazon.com/s3/reduced-redundancy/) has been [effectively deprecated](https://www.lastweekinaws.com/blog/s3-reduced-redundancy-storage-is-dead/), and has lower durability (99.99%, so just four nines) than standard S3. Note that it no longer participates in S3 price reductions, so it offers worse redundancy for more money than standard S3. As a result, there's no reason to use it. + - [Infrequent Access (IA)](https://aws.amazon.com/s3/storage-classes/#Infrequent_Access) lets you get cheaper storage in exchange for more expensive access. This is great for archives like logs you already processed, but might want to look at later. To get an idea of the cost savings when using Infrequent Access (IA), you can use this [S3 Infrequent Access Calculator](http://www.gulamshakir.com/apps/s3calc/index.html). + - [S3 - Intelligent Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/) storage class is designed to optimize costs by automatically moving data to the most cost-effective access tier, without performance impact or operational overhead. + - [S3 - One Zone - IA](https://aws.amazon.com/s3/storage-classes/#__) is for data that is accessed less frequently, but requires rapid access when needed. Unlike other S3 Storage Classes which store data in a minimum of three Availability Zones (AZs), S3 One Zone-IA stores data in a single AZ and costs 20% less than S3 Standard-IA. + - [Glacier](#glacier) is a third alternative discussed as a separate product. + - See [the comparison table](#storage-durability-availability-and-price). +- ⏱**Performance:** Maximizing S3 performance means improving overall throughput in terms of bandwidth and number of operations per second. + - S3 is highly scalable, so in principle you can get arbitrarily high throughput. (A good example of this is [S3DistCp](https://docs.aws.amazon.com/ElasticMapReduce/latest/ReleaseGuide/UsingEMR_s3distcp.html).) + - But usually you are constrained by the pipe between the source and S3 and/or the level of concurrency of operations. + - Throughput is of course highest from within AWS to S3, and between EC2 instances and S3 buckets that are in the same region. + - Bandwidth from EC2 depends on instance type. See the “Network Performance” column at [ec2instances.info](http://www.ec2instances.info/). + - Throughput of many objects is extremely high when data is accessed in a distributed way, from many EC2 instances. It’s possible to read or write objects from S3 from hundreds or thousands of instances at once. + - However, throughput is very limited when objects accessed sequentially from a single instance. Individual operations take many milliseconds, and bandwidth to and from instances is limited. + - Therefore, to perform large numbers of operations, it’s necessary to use multiple worker threads and connections on individual instances, and for larger jobs, multiple EC2 instances as well. + - **Multi-part uploads:** For large objects you want to take advantage of the multi-part uploading capabilities (starting with minimum chunk sizes of 5 MB). + - **Large downloads:** Also you can download chunks of a single large object in parallel by exploiting the HTTP GET range-header capability. + - 🔸**List pagination:** Listing contents happens at 1000 responses per request, so for buckets with many millions of objects listings will take time. + - ❗**Key prefixes:** Previously randomness in the beginning of key names was necessary in order to avoid hot spots, but that is [no longer necessary](https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/) as of July, 2018. + - For data outside AWS, [**DirectConnect**](https://aws.amazon.com/directconnect/) and [**S3 Transfer Acceleration**](https://aws.amazon.com/blogs/aws/aws-storage-update-amazon-s3-transfer-acceleration-larger-snowballs-in-more-regions/) can help. For S3 Transfer Acceleration, you [pay](https://aws.amazon.com/s3/pricing/) about the equivalent of 1-2 months of storage for the transfer in either direction for using nearer endpoints. +- **Command-line applications:** There are a few ways to use S3 from the command line: + - Originally, [**s3cmd**](https://github.com/s3tools/s3cmd) was the best tool for the job. It’s still used heavily by many. + - The regular [**aws**](https://aws.amazon.com/cli/) command-line interface now supports S3 well, and is useful for most situations. + - [**s4cmd**](https://github.com/bloomreach/s4cmd) is a replacement, with greater emphasis on performance via multi-threading, which is helpful for large files and large sets of files, and also offers Unix-like globbing support. +- **GUI applications:** You may prefer a GUI, or wish to support GUI access for less technical users. Some options: + - The [AWS Console](https://aws.amazon.com/console/) does offer a graphical way to use S3. Use caution telling non-technical people to use it, however, since without tight permissions, it offers access to many other AWS features. + - [Transmit](https://panic.com/transmit/) is a good option on macOS for most use cases. + - [Cyberduck](https://cyberduck.io/) is a good option on macOS and Windows with support for multipart uploads, ACLs, versioning, lifecycle configuration, storage classes and server side encryption (SSE-S3 and SSE-KMS). +- **S3 and CloudFront:** S3 is tightly integrated with the CloudFront CDN. See the CloudFront section for more information, as well as [S3 transfer acceleration](https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html). +- **Static website hosting:** + - S3 has a [static website hosting option](http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html) that is simply a setting that enables configurable HTTP index and error pages and [HTTP redirect support](http://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-redirect.html) to [public content](http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteAccessPermissionsReqd.html) in S3. It’s a simple way to host static assets or a fully static website. + - Consider using CloudFront in front of most or all assets: + - Like any CDN, CloudFront improves performance significantly. + - 🔸SSL is only supported on the built-in amazonaws.com domain for S3. S3 supports serving these sites through a [custom domain](http://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html), but [not over SSL on a custom domain](http://stackoverflow.com/questions/11201316/how-to-configure-ssl-for-amazon-s3-bucket). However, [CloudFront allows you to serve a custom domain over https](http://docs.aws.amazon.com/acm/latest/userguide/gs-cf.html). Amazon provides free SNI SSL/TLS certificates via Amazon Certificate Manager. [SNI does not work on very outdated browsers/operating systems](https://en.wikipedia.org/wiki/Server_Name_Indication#Support). Alternatively, you can provide your own certificate to use on CloudFront to support all browsers/operating systems for a fee. + - 🔸If you are including resources across domains, such as fonts inside CSS files, you may need to [configure CORS](https://docs.aws.amazon.com/AmazonS3/latest/dev/cors.html) for the bucket serving those resources. + - Since pretty much everything is moving to SSL nowadays, and you likely want control over the domain, you probably want to set up CloudFront with your own certificate in front of S3 (and to ignore the [AWS example on this](http://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html) as it is non-SSL only). + - That said, if you do, you’ll need to think through invalidation or updates on CloudFront. You may wish to [include versions or hashes in filenames](https://abhishek-tiwari.com/CloudFront-design-patterns-and-best-practices) so invalidation is not necessary. +- **Data lifecycles:** + - When managing data, the understanding the lifecycle of the data is as important as understanding the data itself. When putting data into a bucket, think about its lifecycle — its end of life, not just its beginning. + - 🔹In general, data with different expiration policies should be stored under separate prefixes at the top level. For example, some voluminous logs might need to be deleted automatically monthly, while other data is critical and should never be deleted. Having the former in a separate bucket or at least a separate folder is wise. + - 🔸Thinking about this up front will save you pain. It’s very hard to clean up large collections of files created by many engineers with varying lifecycles and no coherent organization. + - Alternatively you can set a lifecycle policy to archive old data to Glacier. [Be careful](https://alestic.com/2012/12/s3-glacier-costs/) with archiving large numbers of small objects to Glacier, since it may actually cost more. + - There is also a storage class called [**Infrequent Access**](https://aws.amazon.com/s3/storage-classes/#Infrequent_Access) that has the same durability as Standard S3, but is discounted per GB. It is suitable for objects that are infrequently accessed. +- **Data consistency:** Understanding [data consistency](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) is critical for any use of S3 where there are multiple producers and consumers of data. + - Creation and updates to individual objects in S3 are **atomic**, in that you’ll never upload a new object or change an object and have another client see only part half the change. + - The uncertainty lies with *when* your clients and other clients see updates. + - **New objects:** If you create a new object, you’ll be able to read it instantly, which is called **read-after-write consistency**. + - Well, with the additional caveat that if you do a read on an object before it exists, then create it, [you get eventual consistency](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) (not read-after-write). + - This does not apply to any list operations; newly created objects are [not guaranteed to appear in a list operation right away](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) + - **Updates to objects:** If you overwrite or delete an object, you’re only guaranteed **eventual consistency**, i.e. the change will happen but you have no guarantee of when. + - 🔹For many use cases, treating S3 objects as **immutable** (i.e. deciding by convention they will be created or deleted but not updated) can greatly simplify the code that uses them, avoiding complex state management. + - 🔹Note that [until 2015](https://aws.amazon.com/about-aws/whats-new/2015/08/amazon-s3-introduces-new-usability-enhancements/), 'us-standard' region had had a weaker eventual consistency model, and the other (newer) regions were read-after-write. This was finally corrected — but watch for many old blogs mentioning this! + - **Slow updates:** In practice, “eventual consistency” usually means within seconds, but expect rare cases of minutes or [hours](http://www.stackdriver.com/eventual-consistency-really-eventual/). +- **S3 as a filesystem:** + - In general S3’s APIs have inherent limitations that make S3 hard to use directly as a POSIX-style filesystem while still preserving S3’s own object format. For example, appending to a file requires rewriting, which cripples performance, and atomic rename of directories, mutual exclusion on opening files, and hardlinks are impossible. + - [s3fs](https://github.com/s3fs-fuse/s3fs-fuse) is a FUSE filesystem that goes ahead and tries anyway, but it has performance limitations and surprises for these reasons. + - [Riofs](https://github.com/skoobe/riofs) (C) and [Goofys](https://github.com/kahing/goofys) (Go) are more recent efforts that attempt adopt a different data storage format to address those issues, and so are likely improvements on s3fs. + - [S3QL](https://github.com/s3ql/s3ql) ([discussion](https://news.ycombinator.com/item?id=10150684)) is a Python implementation that offers data de-duplication, snap-shotting, and encryption, but only one client at a time. + - [ObjectiveFS](https://objectivefs.com/) ([discussion](https://news.ycombinator.com/item?id=10117506)) is a commercial solution that supports filesystem features and concurrent clients. +- If you are primarily using a VPC, consider setting up a [VPC Endpoint](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html) for S3 in order to allow your VPC-hosted resources to easily access it without the need for extra network configuration or hops. +- **Cross-region replication:** S3 has [a feature](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) for replicating a bucket between one region and another. Note that S3 is already highly replicated within one region, so usually this isn’t necessary for durability, but it could be useful for compliance (geographically distributed data storage), lower latency, or as a strategy to reduce region-to-region bandwidth costs by mirroring heavily used data in a second region. +- **IPv4 vs IPv6:** For a long time S3 only supported IPv4 at the default endpoint `https://BUCKET.s3.amazonaws.com`. However, [as of Aug 11, 2016](https://aws.amazon.com/blogs/aws/now-available-ipv6-support-for-amazon-s3/) it now supports both IPv4 & IPv6! To use both, you have to [enable dualstack](http://docs.aws.amazon.com/AmazonS3/latest/dev/dual-stack-endpoints.html) either in your preferred API client or by directly using this url scheme `https://BUCKET.s3.dualstack.REGION.amazonaws.com`. This extends to S3 Transfer Acceleration as well. +- **S3 event notifications:** S3 can be configured to send an [SNS notification](https://aws.amazon.com/blogs/aws/introducing-the-amazon-simple-notification-service/), [SQS message](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/Welcome.html), or [AWS Lambda function](http://docs.aws.amazon.com/lambda/latest/dg/welcome.html) on [bucket events](http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html). +- 💸Limit your individual users (or IAM roles) to the minimal required S3 locations, and catalog the “approved” locations. Otherwise, S3 tends to become the dumping ground where people put data to random locations that are not cleaned up for years, costing you big bucks. +- If a bucket is deleted in S3, it can take up to 10 hours before a bucket with the same name can be created again. ([discussion](https://forums.aws.amazon.com/thread.jspa?threadID=37532)) + +### S3 Gotchas and Limitations + +- ❗S3 buckets sit outside the VPC and can be accessed from anywhere in the world if bucket policies are not set to deny it. Read the permissions section above carefully, there are countless cases of buckets exposed to the public. +- 🔸For many years, there was a notorious [**100-bucket limit**](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_s3) per account, which could not be raised and caused many companies significant pain. As of 2015, you can [request increases](https://aws.amazon.com/about-aws/whats-new/2015/08/amazon-s3-introduces-new-usability-enhancements/). You can ask to increase the limit, but it will still be capped (generally below ~1000 per account). +- 🔸Be careful not to make implicit assumptions about transactionality or sequencing of updates to objects. Never assume that if you modify a sequence of objects, the clients will see the same modifications in the same sequence, or if you upload a whole bunch of files, that they will all appear at once to all clients. +- 🔸S3 has an [**SLA**](https://aws.amazon.com/s3/sla/) with 99.9% uptime. If you use S3 heavily, you’ll inevitably see occasional error accessing or storing data as disks or other infrastructure fail. Availability is usually restored in seconds or minutes. Although availability is not extremely high, as mentioned above, durability is excellent. +- 🔸After uploading, any change that you make to the object causes a full rewrite of the object, so avoid appending-like behavior with regular files. +- 🔸Eventual data consistency, as discussed above, can be surprising sometimes. If S3 suffers from internal replication issues, an object may be visible from a subset of the machines, depending on which S3 endpoint they hit. Those usually resolve within seconds; however, we’ve seen isolated cases when the issue lingered for 20-30 hours. +- 🔸**MD5s and multi-part uploads:** In S3, the [ETag header in S3](http://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonResponseHeaders.html) is a hash on the object. And in many cases, it is the MD5 hash. However, this [is not the case in general](http://stackoverflow.com/questions/12186993/what-is-the-algorithm-to-compute-the-amazon-s3-etag-for-a-file-larger-than-5gb) when you use multi-part uploads. One workaround is to compute MD5s yourself and put them in a custom header (such as is done by [s4cmd](https://github.com/bloomreach/s4cmd)). +- 🔸**Incomplete multi-part upload costs:** Incomplete multi-part uploads accrue [storage charges](http://docs.aws.amazon.com/AmazonS3/latest/dev/mpuoverview.html#mpuploadpricing) even if the upload fails and no S3 object is created. [Amazon](http://docs.aws.amazon.com/AmazonS3/latest/dev/mpuoverview.html#mpu-abort-incomplete-mpu-lifecycle-config) ([and](http://www.deplication.net/2016/06/aws-tip-save-s3-costs-with-abort.html) [others](https://www.sumologic.com/aws/s3/s3-cost-optimization/)) recommend using a lifecycle policy to clean up incomplete uploads and save on storage costs. Note that if you have many of these, it may be worth investigating whatever's failing regularly. +- 🔸**US Standard region:** Previously, the us-east-1 region (also known as the US Standard region) was replicated across coasts, which led to greater variability of latency. Effective Jun 19, 2015 this is [no longer the case](https://forums.aws.amazon.com/ann.jspa?annID=3112). All Amazon S3 regions now support read-after-write consistency. Amazon S3 also renamed the US Standard region to the US East (N. Virginia) region to be consistent with AWS regional naming conventions. +- 🔸**S3 authentication versions and regions:** In newer regions, S3 [only supports the latest authentication](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingAWSSDK.html#specify-signature-version). If an S3 file operation using CLI or SDK doesn't work in one region, but works correctly in another region, make sure you are using the latest [authentication signature](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html). + +### Storage Durability, Availability, and Price + +As an illustration of comparative features and price, the table below gives S3 Standard, RRS, IA, in comparison with [Glacier](#glacier), [EBS](#ebs), [EFS](#efs), and EC2 d2.xlarge instance store using **Virginia region** as of **Sept 2017**. + +| | Durability (per year) | Availability “designed” | Availability SLA | Storage (per TB per month) | GET or retrieve (per million) | Write or archive (per million) | +|-----------------|------------------------|-------------------------|------------------|--------------------------------------------------------------------------------------------------------------------------|-------------------------------|--------------------------------| +| **Glacier** | Eleven 9s | Sloooow | – | $4 | $50 | $50 | +| **S3 IA** | Eleven 9s | 99.9% | **99%** | $12.50 | $1 | $10 | +| ~~**S3 RRS**~~ | ~~**99.99%**~~ | ~~99.99%~~ | ~~99.9%~~ | ~~$24 (first TB)~~ | ~~$0.40~~ | ~~$5~~ | +| **S3 Standard** | Eleven 9s | 99.99% | 99.9% | $23 | $0.40 | $5 | +| **EBS** | **99.8%** | Unstated | 99.99% | $25/$45/**$100**/$125+ ([sc1/st1/**gp2**/io1](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)\) | | | +| **EFS** | “High” | “High” | – | $300 | | | +| **EC2 d2.xlarge instance store** | Unstated | Unstated | – | $25.44 | $0 | $0 | + +Especially notable items are in **boldface**. Sources: [S3 pricing](https://aws.amazon.com/s3/pricing/), [S3 SLA](https://aws.amazon.com/s3/sla/), [S3 FAQ](https://aws.amazon.com/s3/faqs/), [RRS info](https://aws.amazon.com/s3/reduced-redundancy/) (note that this is considered deprecated), [Glacier pricing](https://aws.amazon.com/glacier/pricing/), [EBS availability and durability](https://aws.amazon.com/ebs/details/#Amazon_EBS_Availability_and_Durability), [EBS pricing](https://aws.amazon.com/ebs/pricing/), [EFS pricing](https://aws.amazon.com/efs/pricing/), [EC2 SLA](https://aws.amazon.com/ec2/sla/) + +EC2 +--- + +### Основы EC2 + +- 📒 [Домашняя страница](https://aws.amazon.com/ec2/) ∙ [Документация](https://aws.amazon.com/documentation/ec2/) ∙ [ЧаВо](https://aws.amazon.com/ec2/faqs/) ∙ [Расценки](https://aws.amazon.com/ec2/pricing/) (также смотрите [ec2instances.info](http://www.ec2instances.info/)\) +- **EC2** (Elastic Compute Cloud) это предложение самого фундаментального компонента облачных вычислений от AWS: [виртуальный частный сервер](https://en.wikipedia.org/wiki/Virtual_private_server). На этих “инстансах” можно запускать [большинство операционных систем Linux, BSD и Windows](https://aws.amazon.com/ec2/faqs/#What_operating_system_environments_are_supported). Под капотом используется сильно модифицированная виртуализация [Xen](https://en.wikipedia.org/wiki/Xen). К слову, новые классы инстансов, использующие KVM производный гипервизор, названный [Nitro](http://www.brendangregg.com/blog/2017-11-29/aws-ec2-virtualization-2017.html), уже были представлены. На текущий момент, его использование ограничено типами инстансов C5 и M5. В заключение, существует "bare metal" гипервизор доступный на [i3.metal инстансах](https://aws.amazon.com/about-aws/whats-new/2018/05/announcing-general-availability-of-amazon-ec2-bare-metal-instances/) +- Термин “EC2” иногда используется для обозначения самих серверов, но технически относится и ко всей совокупности вспомогательных услуг, таких как балансировка нагрузки (CLB/ALB/NLB), IP-адреса (EIP), загрузочные образы (AMI), группы безопасности и сетевые диски (EBS) (которые мы обсудим отдельно в этом руководстве). +- **💸[Расценки на EC2](https://aws.amazon.com/ec2/pricing/)** и **[управление затратами](#ec2-cost-management)** являются сложными темами. Они могут варьироваться с полностью бесплатных (во время использования [AWS free tier](https://aws.amazon.com/free/)) до больших денег, в зависимости от вашего использования. Расценки зависят от типа инстанса, тарифицируются посекундно или почасово, меняются в зависимости от региона и зависят от варианта покупки инстанса, как например, [По требованию](https://aws.amazon.com/ec2/pricing/on-demand/), на [Spot рынке](https://aws.amazon.com/ec2/spot/) или предзаказ ([зарезервированных инстансов](https://aws.amazon.com/ec2/pricing/reserved-instances/)). +- **Производительность сети:** Для некоторых типов инстансов, AWS использует общие темы типа Малая, Средняя и Высокая в отношении сетевой производительности. Пользователи произвели [замеры](http://stackoverflow.com/questions/18507405/ec2-instance-typess-exact-network-performance) чтобы понять, что из себя представляют данные термины. + +### Альтернативы EC2 и привязки + +- Запуск EC2 аналогичен запуску набора физических серверов, до тех пор пока вы не выполняете автоматическое масштабирование или слишком сложную настройку кластера. Если вы просто запускаете набор статических экземпляров, миграция на другой VPS или выделенный сервер не должна быть слишком сложной. +- 🚪**Альтернативы EC2:** Прямыми альтернативами являются Google Cloud, Microsoft Azure, Rackspace, DigitalOcean, собственное предложение AWS Lightsail и другие поставщики VPS, некоторые из которых предлагают аналогичные API для настройки и удаления инстансов. (Смотри сравнение [выше](#когда-использовать-aws).) +- **Должны ли вы использовать Amazon Linux?** AWS поощряет использование их собственной операционной системы [Amazon Linux](https://aws.amazon.com/amazon-linux-ami/), которая эволюционировала из [Red Hat Enterprise Linux (RHEL)](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux) и [CentOS](https://en.wikipedia.org/wiki/CentOS). Она используется многими, но [есть и скептики](https://www.exratione.com/2014/08/do-not-use-amazon-linux/). Что бы вы не делали, обдумывайте решение тщательно. Это правда, что Amazon Linux тщательно протестирован и лучше поддерживается в маловероятном случае возникновения серьезных проблем с ОС и виртуализацией в EC2. Но в общем, многие компании вполне нормально используют стандартные, не-Amazon Linux дистрибутивы, такие как Ubuntu или CentOS. Использование стандартного дистрибутива Linux означает, что у вас аналогично воспроизводимая среда, если вы используете другого хостинг-провайдера вместо (или в дополнение к) AWS. Это также полезно, если вы хотите протестировать развертывания на локальных компьютерах разработчиков, работающих под управлением того же стандартного дистрибутива Linux (данная практика становится еще более распространенной с Docker. Amazon теперь поддерживает официальный [базовый образ Docker Amazon Linux ](http://docs.aws.amazon.com/AmazonECR/latest/userguide/amazon_linux_container_image.html), направленный на содействие локальной разработке в сопостовимой среде, хотя это пока все достаточно новое, так что может считаться экспериментальным). Имейте ввиду, что в данный момент тестируемый [Amazon Linux 2](https://aws.amazon.com/about-aws/whats-new/2017/12/introducing-amazon-linux-2/) поддерживает явное локальное развертывание. +- **Расценки EC2:** Смотри [раздел об этом](#ec2-cost-management). + +### Советы по EC2 + +- 🔹**Выбор региона:** Когда вы начинаете использовать AWS, сначала определитесь какие [регионы](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-available-regions) вы хотите использовать. Многие люди в Северной Америке автоматически выбирают регион us-east-1 (N. Virginia), который стоит по умолчанию, но стоит подумать заранее, идеально ли подходит он вашим требованиям. Вы явно захотите оценить доступность сервисов (некоторые сервисы [доступны не во всех регионах](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)), затраты (также [варьируются в зависимости от региона](https://aws.amazon.com/ec2/pricing/) до 10-30% (как правило самые низкие в us-east-1 для сравнения)), а также соотвествие нормативным требованиям (различные страны например, имеют различные правила в отношении конфиденциальности данных). +- **Типы инстансов:** Инстансы EC2 бывают разных типов, в соответствии с возможностями виртуальной машины в архитектуре и скорости процессора, оперативной памяти, размерах и типах дисков (SSD или магнитных) и пропускной способности сети. + - Выбор типа инстанса является сложным, поскольку существует очень много типов. Вдобавок существуют разные поколения, выпущеные [за долгие годы](https://aws.amazon.com/blogs/aws/ec2-instance-history/). + - 🔹Используйте список на сайте [**ec2instances.info**](http://www.ec2instances.info/) чтобы оценить затраты и особенности. [Собственный список типов инстансов Amazon](https://aws.amazon.com/ec2/instance-types/) сложно использовать, и там не указаны особенности и цены вместе, что делает его вдвойне сложным. + - Цены сильно варьируются, поэтому используйте [**ec2instances.info**](http://www.ec2instances.info/) определить набор машин, которые отвечают вашим потребностям и [**ec2price.com**](http://ec2price.com/) чтобы найти самый дешевый тип в регионе, в котором вы работаете. В зависимости от времени работы и региона может оказаться гораздо дешевле арендовать инстанс с *большим* объемом памяти или ЦП, чем инстанс с минимальной конфигурацией. + - **Выключайте** ваши инстансы, когда они не используются. Для многих ситуаций, таких как тестирование или стэйджинг, вам не нужны инстансы работающие 24/7, и вам не нужно платить за EC2, когда они отключены. Учитывая, что затраты рассчитываются на основе использования, это простой механизм для экономии затрат. Это может быть достигнуто посредством использования [Lambda and CloudWatch](https://aws.amazon.com/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/), решения с открытым кодом [cloudcycler](https://github.com/fairfaxmedia/cloudcycler), или SaaS решение типа [GorillaStack](https://www.gorillastack.com). (Примечание: если вы выключаете инстанс с эфемерным корневым томом, данные будут утрачены. Поэтому, для приложений с сохранением состояния безопаснее выключать инстансы с EBS томом.) +- [**Выделенные инстансы**](https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/) и [**выделенные хосты**](https://aws.amazon.com/ec2/dedicated-hosts/) - это выделенное оборудование, вместо обычных виртуальных инстансов. Они значительно дороже, нежели виртуальные инстансы, но [могут предпочитаться](https://aws.amazon.com/ec2/dedicated-hosts/) по причинам производительности, соответствия, финансовой модели или лицензирования. +- **32 bit и 64 bit:** Несколько micro, small и medium инстансов пока доступны для использования 32-битной архитектуры. В наше время вы будете использовать 64-битные инстансы EC2 (“amd64”), хотя мелкие инстансы пока поддерживают 32-бита (“i386”). Используйте 64-битную архитектуру, кроме случаев, когда у вас есть наследственные ограничения или другая хорошая причина чтобы использовать 32-битную. +- **HVM и PV:** Есть два вида технологии виртуализации используемой EC2, [железная виртуальная машина (HVM) и паравиртуализация (PV)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html). Исторически, PV был основным типом, но [сейчас HVM становится стандартом](https://www.opswat.com/blog/aws-2015-why-you-need-switch-pv-hvm). Если вы хотите использовать новейшие типы инстансов, вы должны использовать HVM. Смотрите [матрицу типов инстансов](https://aws.amazon.com/amazon-linux-ami/instance-type-matrix/) для подробностей. +- **Операционные системы:** Чтобы использовать EC2, вам необходимо выбрать базовую операционную систему. Это может быть Windows или Linux, например Ubuntu или [Amazon Linux](https://aws.amazon.com/amazon-linux-ami/). Это делается посредством AMI, которые более раскрыты в отдельном разделе ниже. +- **Лимиты:** Вы не можете создать произвольное количество инстансов. Лимиты количества инстансов EC2 по умолчанию на аккаунт варьируются по типам инстансов, как описано в [этом списке](http://aws.amazon.com/ec2/faqs/#How_many_instances_can_I_run_in_Amazon_EC2). +- ❗**Используйте защиту от удаления:** Для любых инстансов, которые важны и долго работают (в частности, не являются частью автомасштабирования), [включайте защиту от удаления](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination). Это важная линия защиты от ошибок пользователя, таких как случайное удаления многих инстансов вместо одного из-за человеческой ошибки. +- **Управление ключами SSH:** + - Когда вы запускаете инстанс, вам необходимо настроить хотя бы одну [пару ключей ssh](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) для первоначальной настройки, чтобы позволить вам подключиться по ssh в первый раз. + - Помимо начальной настройки, вы должны сами управлять ключами в инстансах, назначая индивидуальные ключи отдельным пользователям или службам в зависимости от ситуации. + - Избегайте повторного использования оригинальных ключей, кроме как администраторами, при создании новых инстансов. + - Не делитесь ни с кем ключами и [добавьте индивидуальные ssh ключи](http://security.stackexchange.com/questions/87480/managing-multiple-ssh-private-keys-for-a-team) конкретным пользователям. +- **Поддержка GPU:** Вы можете арендовать инстансы с поддержкой графического процессора в EC2 для использования в целях машинного обучения или рендеринга графики. + + - Сейчас доступно [три типа](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cluster_computing.html) инстансов с поддержкой графического процессора: + - Тип P3 предлагает графические процессоры NVIDIA Tesla V100 в конфигурации 1, 4 или 8 GPU для использования в целях машинного обучения, научных и других высокопроизводительных вычислительных задач. + - Тип P2 предлагает графические процессоры NVIDIA Tesla K80 в конфигурации 1, 8 или 16 GPU для использования в целях машинного обучения, научных и других высокопроизводительных вычислительных задач. + - Тип G3 предлагает графические процессоры NVIDIA Tesla M60 в конфигурации 1, 2 или 4 GPU для использования в целях рендеринга графики и обработки видео. + - AWS предлагает два различных AMI, которые используются с GPU ориентированными приложениями. В частности, они нацелены на рабочие задачи глубокого обучения, но также предоставляют доступ к более урезанным базовым образам только для поддержки драйверов. + - AWS предлагает Amazon Linux [Deep Learning AMI](https://aws.amazon.com/marketplace/pp/B077GF11NF?qid=1536363169916&sr=0-3&ref_=srh_res_product_title) (на базе Amazon Linux) а также Ubuntu [Deep Learning AMI](https://aws.amazon.com/marketplace/pp/B077GCH38C). Оба образа идут с большинством драйверов NVIDIA и сопутствующим программным обеспечением (CUDA, CUBLAS, CuDNN, TensorFlow, PyTorch, и т.д.) дабы снизить барьер использования. + - ⛓ Имейте ввиду, что использование этих AMI может привести к привзяке, так как у вас нет прямого доступа к конфигурации или версиям программного обеспечения. + - 🔸 Компендиум включенных фреймворков может привести к длительному времени запуска инстансов и сложным для понимания средам. + - 🔹Как в случае с любыми дорогими типами инстансов EC2, [спот инстансы могут предложить значительную экономию](#ec2-cost-management) с GPU-ориентированными задачами, когда прерывания не критичны. +- Все текущие типы инстансов EC2 могут использовать преимущества адресации IPv6, если они запускаются в подсети с выделенным диапазоном CIDR в VPC с поддержкой IPv6. + +### Ошибки и ограничения EC2 + +- ❗Никогда не используйте ssh пароли. Просто не делайте этого; они слишком небезопасны, а последствия компроментации слишком серьезны. Используйте вместо этого ключи. [Прочтите это](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2) и полностью отключите парольный доступ на вашем ssh сервере, удостоверившись, что параметр 'PasswordAuthentication no' прописан в конфигурационном файле /etc/ssh/sshd_config. Если вы бережно заботитесь об управлении приватными ключами ssh, где бы они не хранились, это значительное улучшение безопасности по сравнению с аутентификацией на основе пароля. +- 🔸Для всех [новых типов инстансов](https://aws.amazon.com/amazon-linux-ami/instance-type-matrix/), когда выбираете AMI для использования, удостоверьтесь, что вы выбрали HVM AMI, или он просто не заработает. +- ❗При создании инстанса и использовании новой пары ключей ssh [убедитесь, что права доступа для ключа ssh указаны правильно](http://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue). +- 🔸Иногда определенные инстансы EC2 могут быть запланированы для вывода из эксплуатации AWS из-за “обнаруженной деградации подлежащего оборудования”, в этом случае вам будет предоставлено пару недель для миграции на новый инстанс. + - Если корневой том на вашем инстансе является томом EBS, вы можете просто выключить и включить инстанс, таким образом он переместится на рабочее оборудование, таким образом вы можете сами контролировать время данного процесса. Имейте ввиду, что вы потеряете данные на ([эфемерных дисках](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)) если тип вашего инстанса подразумевает хранение данных на дисках инстанса. + - Публичный IP адрес инстанса(если таковой имеется) скорее всего изменится если вы не используете Elastic IPs. Это может быть проблемой, если другие системы зависят от IP адресов. +- 🔸Периодически вы можете обнаружить, что ваш сервер или балансировщик нагрузки получает трафик (предположительно) предыдущего сервера EC2, который работал с тем же IP-адресом, который вы получили сейчас (это может не иметь значения, или это можно исправить путем перехода на другой инстанс). +- ❗Если API EC2 является критичным компонентом вашей инфраструктуры(например для автоматической замены серверов, пользовательских алгоритмов масштабирования и т.д.) и вы работает в крупных масштабах или делаете множество вызовов API EC2, удостоверьтесь, что вы понимаете, что это может вас подвести (вызовы к API [ограничены по частоте](http://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate) и ограничения не опубликованы и не подлежат изменениям) таким образом, учитывайте эту возможность при разработке и тестировании. +- ❗Многие новые типы инстансов EC2 либо используют только EBS, либо поддерживаются локальными дисками NVMe, назначенными этому инстансу. При планировании их использования обязательно учитывайте производительность и затраты EBS. +- ❗Если вы работаете в значительном масштабе, вы можете разделить вызовы API, которые перечисляют все ваши ресурсы, и вместо этого оперировать либо отдельными ресурсами, либо подмножеством всего списка. API EC2 может вернуть таймаут! Попробуйте использовать [фильтры](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) чтобы ограничивать то, что возвращается. +- ❗⏱ Инстансы также бывают двух видов: **Инстансы с постоянной производительностью** (например, M3, C3 и R3) и [**Инстансы с разгоняющейся производительностью**](https://aws.amazon.com/ec2/instance-types/#burst) (например, T2). Инстанс T2 получает кредиты CPU постоянно, частота зависит от размера инстанса. Инстансы T2 накапливают кредиты CPU когда простаивают, и используют кредиты CPU, когда активны. Как бы там не было, как только кредиты закончатся, вы заметите серьезную просадку в производительности. Если вам нужна постоянная высокая производительность CPU для приложений типа обработки видео, вебсайтов с высокой нагрузкой или высокопроизводительных вычислений, рекомендуется использовать инстансы с постоянной производительностью. +- Пользовательские данные инстанса [ограничены 16 KB](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-add-user-data). (Это ограничение применяется к данным в сыром виде, не закодированным в base64.) Если необходимо больше данных, они могут быть скачаны с S3 посредством использования скрипта в пользовательских данных. +- Совсем новые аккаунты могут не иметь возможности запускать некоторые типы инстансов, например инстансы с GPU, из-за изначально установленного “мягкого ограничения”, равного нулю. Этот лимит может снят путем запроса в поддержку. Ознакомьтесь [с сервисными ограничениями AWS](http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) для понимания методов подачи запроса в поддержку. Имейте ввиду, что данный лимит на текущий момент [не документирован](http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_ec2). +- Поскольку множество инстансов совместно запускается на одном и том же физическом оборудовании, первые пользователи облачных технологий столкнулись с так называемой [проблемой шумных соседей](https://searchcloudcomputing.techtarget.com/definition/noisy-neighbor-cloud-computing-performance). Ощущение того, что ты не получаешь того, за что платишь приводит к [фрустрации у пользователей](https://twitter.com/technicallyjosh/status/668963405831651328), как бы там не было, "кража" не самое лучшее слово, которое описывает, что происходит на самом деле, на основе [детального объяснения того, как ядро определяет украденное время](https://support.cloud.engineyard.com/hc/en-us/community/posts/203751578-Explanation-of-Steal-Time). Для того, чтобы избежать воздействия эффекта украденного времени на ваше приложение, лучшим вариантом является [правильный дизайн вашей облачной архитектуры](https://www.infoworld.com/article/3073503/cloud-computing/debunking-the-clouds-noisy-neighbor-myth.html). +- AWS [представила выделенную аренду](https://aws.amazon.com/blogs/aws/amazon-ec2-dedicated-instances/) в 2011 году. Это позволяет клиентам размещать все ресурсы на едином сервере. Некоторые видят в этом решение [проблемы шумных соседей](https://www.infoworld.com/article/3008225/cloud-computing/amazon-dedicated-hosts-bye-bye-to-noisy-cloud-neighbors.html) так как только один клиент использует процессорную мощность. Однако этот подход идет с серьезным риском, в случае если оборудованию потребуется любой тип обслуживания. Если у клиента есть 20 запущенных инстансов в распределенной аренде и один подлежащий сервер требует обслуживания, инстансы только на этом сервере будут отключены.А вот если у клиента 20 инстансов запущено в выделенной аренде, тогда при обслуживании подлежащего оборудования - все 20 инстансов будут отключены. +- 🔸Только тип инстанса **i3.metal** предоставляет возможность запускать эмуляторы Android x86 в AWS на текущий момент. + + + +CloudWatch +------------------- + +### Основы CloudWatch + +* 📒 [Домашняя страница](https://aws.amazon.com/cloudwatch/) ∙ [Документация](https://aws.amazon.com/documentation/cloudwatch/) ∙ [ЧаВо](https://aws.amazon.com/cloudwatch/faqs/) ∙ [Расценки](https://aws.amazon.com/cloudwatch/pricing/) +* **CloudWatch** мониторит ресурсы и приложения, собирает логи, и шлет уведомления. +* Мониторинг CloudWatch - это стандартный механизм отслеживания ресурсов AWS. Широкий диапазон [**метрик и измерений**](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) доступен в CloudWatch, позволяя вам создавать временные графики, **[тревоги](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)**, и **[панели мониторинга](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)**. + * Аварийная тревога - наиболее практичное использование CloudWatch, позволяющее запускать уведомления от любого заданного показателя. + * Тревоги могут включать [оповещения SNS](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html), [действия автоматического масштабирования](http://docs.aws.amazon.com/autoscaling/latest/userguide/policy_creating.html), или [действия связанные с EC2](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html). + * Тревоги также поддерживают возможность [оповещения, когда количество M из N источников данных пересекает порог оповещения](https://aws.amazon.com/about-aws/whats-new/2017/12/amazon-cloudwatch-alarms-now-alerts-you-when-any-m-out-of-n-metric-datapoints-in-an-interval-are-above-your-threshold/). + * Публикуйте и делитесь графиками метрик путем создания [настраиваемых панелей мониторинга](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/). + * Мониторинг и создание отчетов по [оповещениям ошибок проверки состояния системы инстанса](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html#creating_status_check_alarms). +* **Использование CloudWatch Events:** + * События(Events) создают механизм для автоматизации действий в различных сервисах на AWS. Вы можете создать [правила событий](http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html) для состояний инстанса, AWS API, Автоматического масштабирования(Auto Scaling), AWS Systems Manager Run Command, развертываний или расписаний (вспомните Cron). + * [Запущенные события(Triggered events)](http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/CWE_GettingStarted.html) могут вызывать функции Lambda, посылать сообщения SNS/SQS/Kinesis, или делать что-то с инстансом (удалять, перезапускать, останавливать, или делать снапшоты томов). + * Пользовательские данные могут быть посланы целям в формате JSON, особенно это полезно, когда запускаешь Lambda. +* **Использование CloudWatch Logs:** + * [CloudWatch Logs](http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) - это система для потокового хранения логов. Путем хранения логов в AWS вы получаете неограниченное платное хранилище, кроме того, вы имеете возможность направлять потоки логов напрямую в ElasticSearch или в свои Lambda. + * [Log-агент, установленный](http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html) на ваши сервера будет собирать логи все время и посылать их в CloudWatch Logs. + * Вы можете [экспортировать данные логов в S3](http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) или направить потоки в другие сервисы AWS. + * CloudWatch Logs может быть [зашифрована используя ключи, управляемые KMS](http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html). +* **Детальный мониторинг:** [Детальный мониторинг](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) должен быть включен для инстансов EC2 для получения гранулярных метрик и [оплачивается с CloudWatch](https://aws.amazon.com/cloudwatch/pricing/). + +### Альтернативы CloudWatch и привязки + +* CloudWatch предлагает довольно базовую функциональность, которая не создает значительную (дополнительную) привязку к AWS. Большинство метрик, предоставляемых сервисом, могут быть получены через API, которые могут быть импортированы в другие средства сбора или визуализации (многие предоставляют специальный сервис по импорту данных с CloudWatch). +* 🚪 Альтернативы мониторингового сервиса CloudWatch включают в себя - [NewRelic](http://newrelic.com/), [Datadog](http://datadog.com/), [Sumo Logic](http://sumologic.com/), [Zabbix](http://zabbix.com/), [Nagios](http://nagios.org/), [Ruxit](http://ruxit.com/), [Elastic Stack](https://www.elastic.co/elk-stack), варианты с открытым кодом, такие как [StatsD](https://github.com/etsy/statsd) or [collectd](https://collectd.org/) с [Graphite](https://graphiteapp.org/) и многие другие. +* 🚪 Альтернативы по хранению логов CloudWatch включают в себя - [Splunk](http://splunk.com/), [Sumo Logic](http://sumologic.com/), [Loggly](http://loggly.com/), [LogDNA](https://logdna.com/), [Logstash](https://www.elastic.co/products/logstash), [Papertrail](https://papertrailapp.com/), [Elastic Stack](https://www.elastic.co/elk-stack) и другие решения по централизованному хранению логов. + +### Советы по CloudWatch + +* Некоторые из наиболее распространненых случаев применения CloudWatch - **[оповещения о превышении затрат](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html)**, **оповещение, что инстанс** **или [балансировщик нагрузки упал/поднялся](http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)**, и **оповещения об использовании дискового пространства**. +* Вы можете использовать [EC2Config](http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/UsingConfig_WinAMI.html#send_logs_to_cwl) для мониторинга метрик памяти и дискового пространства на инстансах под управлением Windows. Для Linux существуют [примеры скриптов](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html), которые делают то же самое. +* Вы можете [опубликовать свои собственные метрики](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) используя API AWS. [Включает дополнительные затраты](https://aws.amazon.com/cloudwatch/pricing/). +* Вы можете направить потоковые логи с CloudWatch Logs в Lambda или кластер ElasticSearch путем создания [подписок](http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html) на группы логов(Log Groups). +* Не забудьте воспользоваться Не забудьте воспользоваться преимуществом [всегда бесплатных услуг CloudWatch](https://aws.amazon.com/free/#Amazon_CloudWatch). + +### Ошибки и ограничения, связанные с CloudWatch + +* 🔸Метрики в CloudWatch снимаются на уровне [гипервизора](https://forums.aws.amazon.com/message.jspa?messageID=403578). Гипервизор не имеет доступа к информации на уровне операционной системы, таким образом отдельные метрики (в основном утилизация памяти) не доступна пока не передана в CloudWatch с агента, установленного внутри инстанса. +* 🔸Вы не можете использовать [более одной метрики на оповещение](https://forums.aws.amazon.com/thread.jspa?threadID=94984). +* 🔸Оповещения получаемые в случае тревоги не содержат контекстной информации; они содержат информацию о пределе, состоянии тревоги и времени. +* 🔸По умолчанию, разрешение метрик в CloudWatch равно 1 минуте. Если вам необходимо посылать несколько знанчений метрики в пределах одной и той же минуты, они будут собраны в минимум, максимум, среднее и общее(суммарное) значение в минуту. +* 🐥В июле 2017 года, была добавлена новая [опция высокого-разрешения](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html#high-resolution-metrics) для метрик и аварийных оповещений CloudWatch. Эта функция позволяет вам записывать данные метрик с разрешением в одну секунду и оценивать состояние тревоги CloudWatch каждые 10 секунд. + - Это [информационное сообщение, представляющее данную возможность](https://aws.amazon.com/blogs/aws/new-high-resolution-custom-metrics-and-alarms-for-amazon-cloudwatch/) описывает, как опубликовать метрику высокого разрешения в CloudWatch. Имейте ввиду, когда вы вызываете `PutMetricData` API, `StorageResolution` является атрибутом каждого элемента, который вы посылаете в массив `MetricData`, а не прямой параметр вызова `PutMetricData`. +* 🔸Данные метрик хранятся в CloudWatch [15 месяцев](https://aws.amazon.com/blogs/aws/amazon-cloudwatch-update-extended-metrics-retention-user-interface-update/), начиная с ноября 2016 года (раньше было 14 дней). Минимальная гранулярность вырастает через 15 дней. + +AMIs +---- + +### Основы AMI + +- 📒 [Руководство пользователя](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) +- **AMIs** Образы машин Amazon(Amazon Machine Images) - неизменяемые образы, которые используются для запуска предварительно сконфигурированных EC2 инстансов. Они бывают двух видов - общедоступные и частные. Общедоступные AMI либо доступны бесплатно (общие или созданные сообществом AMI) или покупаются и продаются на [**AWS Marketplace**](http://aws.amazon.com/marketplace). +- Многие производители операционных систем публикуют готовые к использованию базовые AMI. Например для Ubuntu, смотри [Поиск Ubuntu AMI](https://cloud-images.ubuntu.com/locator/ec2/). У Amazon конечно же есть список [AMI Amazon Linux](https://aws.amazon.com/amazon-linux-ami/). + +### Советы по AMI + +- AMIs создаются независимо, на основе того, как они будут развернуты. Вы должны подобрать AMI, которые соответствуют вашему развертыванию, когда используете или создаете их: + - EBS или хранилище на инстансе + - PV или HVM [типы виртуализации](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html) + - 32 битная (“i386”) или 64 битная (“amd64”) архитектура +- Как описано выше, современные развертывания будут обычно использовать **64-битную HVM с EBS**. +- Вы можете создать свой собственный AMI путем создания [мгновенного снимка состояния(снапшота)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html) EC2 инстанса, который вы сконфигурировали. +- [AMI с EBS хранилищем](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ComponentsAMIs.html#storage-for-the-root-device) содержит необходимые образу данные на томе EBS, и не требует дополнительных операций по извлечению данных с S3, что приводит к тому, что инстансы с EBS загружаются быстрее, нежели инстансы с внутренним хранилищем. +- **AMI различаются в разных регионах**, таким образом вы должны найти необходимый AMI в вашем регионе, или скопировать ваши AMI между регионами при помощи функции [AMI Copy](https://aws.amazon.com/about-aws/whats-new/2013/03/12/announcing-ami-copy-for-amazon-ec2/). +- Как и при работе с другими ресурсами AWS, будет мудрым выбором [использовать метки(тэги)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) для обеспечения версионности AMI и управления их жизненным циклом. +- Если вы создаете свои собственные AMI, всегда есть некоторые сложности в выбори того, сколько и чего вы хотите установить, сконфигурировать и “впечь” в эти образы. + - Если вы вкладываете меньший объем в ваш AMI (например, только клиент управления конфигурацией, который загружает, устанавливает и настраивает программное обеспечение на новых инстансах EC2 при их запуске) позволяет вам сократить временные затраты на автоматизацию создания AMI и управления жизненным циклом AMI (у вас скорее всего будет возможность использовать меньшее количество AMI и вам не придется часто их обновлять), но это приводит к более долгому ожиданию прежде чем инстансы будут готовы к использовани, что, в свою очередь, приводит к более высокой вероятности сбоев установки или конфигурации во время запуска. + - Если вы вкладываете больший объем в ваш AMIs (например, предустанавливаете, но не полностью настраиваете базовое программное обеспечение, вместе с клиентом управления конфигурацией, который подгружает конфигурационные настройки во время загрузки) приводит к более быстрому запуску и меньшему количеству возможностей появления ошибок во время установки программного обеспечения и его конфигурирования во время запуска инстанса, однако в то же время повышает необходимость создания и управления быстрого конвеера по созданию AMI. + - Если вы вкладываете еще больший объем в ваш AMIs (например, устанавливаете все необходимое программное обеспечение, а также настраиваете конфигурацию для конкретного окружения) приводит к быстрому запуску и гораздо меньшей вероятности сбоев во время запуска инстанса, но (без принятия во внимание дополнительные переразвертываний и перенастройки) может потребовать трудозатратных обновлений AMI в целях обновления программного обеспечения или конфигурирования, также как и более сложный процесс автоматизации создания AMI. +- Какой вариант вы предпочтете, зависит от того, как быстро вам необходимо масштабировать Which option you favor depends on how quickly you need to scale up емкость, а также от размера и зрелости вашей команды и продукта. + - Когда инстансы загружаются быстро, автоматически масштабируемые сервисы требуют меньшего количества встроенных запасных мощностей и могут быстрее масштабироваться в ответ на внезапное повышение нагрузки. Когда вы создаете сервис с автоматическим масшабированием, позаботьтесь о вложении как можно большего количества предустановок и настроек в ваш AMI и готовьте их с поддержкой хранилища EBS. + - AПо мере того, как системы становятся больше, обычно требуется более сложное управление AMI, такое как многоэтапный процесс создания AMI, в котором несколько (в идеале один) общих базовых AMI редко пересобираются, для обновления компонентов, общих для всех развернутых служб, а затем, более часто, запускается сборка AMI “для уровня сервиса” AMI которая включает в себя установку программного обеспечения и настройку для определенного сервиса. +- Больше размышлений относительно стратегий создания AMI [тут](http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html). +- Используйте инструменты вроде [Packer](https://packer.io/) для упрощения и автоматизации создания AMI. +- Если вы используете инстансы на RHEL и так случилось, что у вас действующая подписка Red Hat на использование RHEL в локальном дата-центре, тогда вы можете использовать программу Red Hat [Cloud Access](https://www.redhat.com/en/technologies/cloud-computing/cloud-access) чтобы перенести часть ваших подписок в AWS, таким образом AWS не будет выставлять вам повторные счета за использование RHEL подписок. Вы можете использовать либо самостоятельно созданные RHEL AMI или предоставленные Red Hat [Золотые образы(Gold Images)](https://access.redhat.com/articles/2962171) которые будут добавлены в ваш частный каталог AMI, как только вы подпишетесь на программу Red Hat Cloud Access. + +### Ошибки и ограничения, связанные с AMI + +- 🔸**Версии пакета Amazon Linux:** [По умолчанию](https://aws.amazon.com/amazon-linux-ami/faqs/#lock), инстансы на основе Amazon Linux AMI настроены на использование последних версий пакетов в репозитории Amazon. Это значит, что версии устанавливаемых пакетов не заблокированы и могут измениться, в том числе может произойти ситуация, когда программное обеспечение будет сломано при обновлении в будущем. Если вы готовите AMI с уже примененными обновлениями, это вряд-ли вызовет проблемы в запущенных сервисах, чьи инстансы базируются на этих AMI – проблема возникнет на ранней стадии создания процесса сборки AMI, и должна быть исправлена или устранена до момента генерации AMI. Существует функция “блокировка при запуске(lock on launch)”, которая позволяет жестко закрепить использвование инстансами на Amazon Linux репозитория с конкретными мажорными версиями Amazon Linux AMI, снижая вероятность того, что проблемы и поломки, вызванные изменением версий по инициативе Amazon затронут время установки пакета, однако цена - отсутствие обновления пакетов.Сочетание использования функции «блокировка при запуске» с процессом усовершенствования Amazon Linux AMI по вашему усмотрению может обеспечить более жесткий контроль над поведением и временем обновления. +- **Настройки Cloud-Init по умолчанию:** Часто пользователи создают AMI после проведения кастомизации (неважно вручную или с использованием инструментов, таких как Packer или Ansible). Если вы не придали значения настройкам cloud-init, которые относятся к системным службам(например sshd, и т.д.) которые вы настроили, вы можете заметить, что изменения, которые вы внесли не актуальны после первого запуска вашего нового AMI, так как cloud-init их перезаписал. + + В некоторых дистрибутивах используются другие файлы, нежели в других дистрибутивах, но все они обычно расположены в `/etc/cloud/`, независимо от дистрибутива. Вам следует пересмотреть эти файлы крайне внимательно, с учетом выбранного дистрибутива, перед созданием вашего собственного AMI. [Полный справочник по cloud-init](https://cloudinit.readthedocs.io/en/latest/) доступен на сайте cloud-init. Это расширенный механизм настройки, поэтому перед любым серьезным использованием протестируйте любые изменения, внесенные в эти файлы, в изолированной среде(песочнице). + +Auto Scaling (Автоматическое масштабирование) +------------ + +### Основы Auto Scaling + +- 📒 [Домашняя страница](https://aws.amazon.com/autoscaling/) ∙ [Руководство пользователя](http://docs.aws.amazon.com/autoscaling/latest/userguide/) ∙ [ЧаВо](https://aws.amazon.com/ec2/faqs/#Auto_Scaling) ∙ [Расценки](https://aws.amazon.com/autoscaling/pricing/) at no additional charge +- [**Группы Автоматического Масштабирования(Auto Scaling Groups (ASGs))**](https://aws.amazon.com/autoscaling/) используются для контроля количества инстансов в сервисе, сокращая ручную работу на создание или удаление инстансов EC2. +- Они могут быть сконфигурированы посредством [Политик Масштабирования(Scaling Policies)](http://docs.aws.amazon.com/autoscaling/latest/userguide/policy_creating.html) для автоматического увеличения или уменьшения количества инстансов на основании метрик, такиих как утилизация CPU или на основе расписания. +- Есть три основных способа использования ASG - динамический (автоматическая настройка количества инстансов на основе метрик таких, как загрузка процессора), статическая (поддержка определенного количества инстансов все время), по расписанию (поддержка различного количества инстансов в разное время суток или дней недели). +- 💸ASG [не оплачивается дополнительно](https://aws.amazon.com/autoscaling/pricing/); вы платите только за низлежащие EC2 инстансы и сервисы CloudWatch. + +### Советы по автоматическому масштабированию + +- 💸 Лучшее соответствие размера кластера вашим текущим требованиям к ресурсам за счет использования ASG может привести к значительной экономии средств для многих типов рабочих нагрузок. +- Совместное использование ASG с CLB - общая схема, используемая для того, чтобы справляться с изменениями объема трафика, который получает сервис. +- Динамическое автоматическое масштабирование проще всего использовать с горизонтально масштабируемыми сервисами без требования сохранения состояния. +- Даже если вы не используете ASG для динамического увеличения или уменьшения количества экземпляров, вам следует серьезно рассмотреть возможность хранения всех инстансов внутри ASG - учитывая количество целевых инстансов, ASG будет работать, чтобы гарантировать, что число запущенных инстансов будет равно этому целевому значению, заменяя инстансы, если они умирают или помечены как нездоровые. Это приводит к постоянной емкости и лучшей стабильности вашего сервиса. +- Сервис масштабирования может быть [сконфигурирован уничтожать](http://docs.aws.amazon.com/autoscaling/latest/userguide/healthcheck.html) инстансы, которые помечены балансировщиками нагрузки, как нездоровые. + +### Ошибки и ограничения, связанные с автоматическим масштабированием + +- 🔸**Параметр ReplaceUnhealthy :** По умолчанию, ASGs убьет инстансы, которые не отвечают. Это возможно для тех инстансов, процессор которых загружен полностью на несколько минут и которые не отвечают на запросы, таким образом, ASG с настроенным по умолчанию [параметром ReplaceUnhealthy](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-suspend-resume-processes.html#process-types) заменит их. Есть смысл отключить эту настройку, в случаях если инстансы управляемые ASG часто работают с высокой нагрузкой на процессор. В таком случае, определение и уничтожение нездоровых инстансов перейдет под вашу ответственность. + +EBS +--- + +### Основы EBS + +- 📒 [Домашняя страница](https://aws.amazon.com/ebs/) ∙ [Руководство пользователя](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) ∙ [ЧаВо](https://aws.amazon.com/ebs/faqs/) ∙ [Расценки](https://aws.amazon.com/ebs/pricing/) +- **EBS** (Elastic Block Store) предоставляет блочное хранилище данных. Да, он предлагает тома хранилища данных, которые могут быть подключены, как файловые системы, как традиционные сетевые диски. +- Тома EBS могут быть подключены только к одному инстансу EC2 на момент времени. В отличии от EFS, который может быть подключен между многими серверами, но стоит дороже ([сравнение](http://stackoverflow.com/questions/29575877/aws-efs-vs-ebs-vs-s3-differences-when-to-use)). + +### Советы по EBS + +- ⏱**RAID:** Используйте [RAID диски](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html) для [повышенной производительности](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html). +- ⏱Стоило бы прочитать [публикацию AWS о характеристиках ввода-вывода EBS](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html) также как и их [советы по производительности](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html#d0e86148). +- ⏱Можно [выделить IOPS](http://aws.amazon.com/ebs/details/) (что означает - платить за определенный уровень операций ввода-вывода в секунду), чтобы обеспечить определенный уровень производительности диска. +- ⏱Один том gp2 EBS позволяет в максимуме достигнуть 16k IOPS. Для того, чтобы выжать максимум производительности из тома gp2 EBS, он должен быть максимального размера и быть подключенным к EBS-optimized инстансу EC2. +- 💸Стандартные и gp2 тома EBS повышают характеристику IOPS с размером. Возможно, имеет смысл просто увеличить объем, вместо того, чтобы явно платить за лучшую производительность. Это может во многих случаях сократить расходы на 2/3. +- Стандартный размер блока для тома EBS - 16kb. + +### Ошибки и ограничения, связанные с EBS + +- ❗EBS достаточно надежен для обычного жесткого диска (средняя годовая частота отказов [между 0.1% - 0.2%](http://aws.amazon.com/ebs/details/#availabilityanddurability)). С другой стороны, это очень плохо, если у вас нет резервных копий. В отличии от EBS, надежность S3 экстремально высокая. *Если вы заботитесь о своих данных, делайте их резервную копию на S3 с использованием снапшотов.* +- 🔸EBS предоставляет [**SLA**](http://aws.amazon.com/ec2/sla/) с показателем работоспособности в **99.99%**. Смотрите примечания о высокой доступности ниже. +- ❗Тома EBS имеют [**тип тома**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) указывающий на физический тип хранилища. “Стандартный” тип (**st1** or **sc1**) в реальности обычный диск на вращающихся пластинах, которые могут обеспечить только сотни IOPS — совсем не то, что вам обычно нужно, кроме случаев, когда вы хотите сильно урезать издержки. Современные типы основанные на SSD **gp2** или **io1** обычно тот вариант, который вам нужен. +- ❗Когда восстанавливаешь снапшот для создания EBS тома, блоки считываются медленно с S3 поначалу. Во избежание первоначального периода высоких задержек, вы можете использовать `dd` или `fio` согласно [официальной документации](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.html). + +EFS +--- + + +### EFS Basics + +- 📒 [Homepage](https://aws.amazon.com/efs/) ∙ [User guide](http://docs.aws.amazon.com/efs/latest/ug) ∙ [FAQ](https://aws.amazon.com/efs/faq/) ∙ [Pricing](https://aws.amazon.com/efs/pricing/) +- 🐥**EFS** is Amazon’s network filesystem. It’s presented as an [NFSv4.1](https://en.wikipedia.org/wiki/Network_File_System#NFSv4) server. Any compatible NFSv4 client can mount it. +- It is designed to be highly available and durable and each EFS file system object is redundantly stored across multiple availability zones. +- EFS is designed to be used as a shared network drive and it can automatically scale up to petabytes of stored data and thousands of instances attached to it. +- EFS can offer [higher throughput](http://docs.aws.amazon.com/efs/latest/ug/performance.html) (multiple gigabytes per second) and better durability and availability than EBS (see [the comparison table](#storage-durability-availability-and-price)), but with higher latency. +- EFS is priced based on the volume of data stored, and costs [much more than EBS](#storage-durability-availability-and-price); it's in the ballpark of three times as much compared to general purpose gp2 EBS volumes. +- ⏱ [Performance](http://docs.aws.amazon.com/efs/latest/ug/performance.html) is dependent on the volume of data stored, as is the price: + - Like EBS, EFS uses a credit based system. Credits are earned at a rate of 50 KiB/s per GiB of storage and consumed in bursts during reading/writing files or metadata. Unlike EBS, operations on metadata (file size, owner, date, etc.) also consume credits. The [BurstCreditBalance metric](http://docs.aws.amazon.com/efs/latest/ug/monitoring-cloudwatch.html#efs-metrics) in CloudWatch should be monitored to make sure the file system doesn't run out of credits. + - Throughput capacity during bursts is also dependent on size. Under 1 TiB, throughput can go up to 100 MiB/s. Above that, 100 MiB/s is added for each stored TiB. For instance, a file system storing 5 TiB would be able to burst at a rate of 500 MiB/s. Maximum throughput per EC2 instance is 250 MiB/s. + - EFS has two performance modes that can only be set when a file system is created. One is "General Purpose", the other is "Max I/O". Max I/O scales higher, but at the cost of higher latency. When in doubt, use General Purpose, which is also the default. If the [PercentIOLimit metric](http://docs.aws.amazon.com/efs/latest/ug/monitoring-cloudwatch.html#efs-metrics) in CloudWatch hovers around 100%, Max I/O is recommended. Changing performance mode means creating a new EFS and migrating data. +- High availability is achieved by having [mount targets in different subnets / availability zones](http://docs.aws.amazon.com/efs/latest/ug/images/overview-flow.png). + +### EFS Tips + +- With EFS being based on NFSv4.1, any directory on the EFS can be mounted directly, it doesn't have to be the root directory. One application could mount *fs-12345678:/prog1*, another *fs-12345678:/prog2*. +- [User and group level permissions](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-nfs-permissions.html) can be used to control access to certain directories on the EFS file system. +- ⏱ **Sharing EFS filesystems:** One EFS filesystem can be used for multiple applications or services, but it should be considered carefully: + + Pros: + - Because performance is based on total size of stored files, having everything on one drive will increase performance for everyone. One application consuming credits faster than it can accumulate might be offset by another application that just stores files on EFS and rarely accesses them. + + Cons: + - Since credits are shared, if one application over-consumes them, it will affect the others. + - A compromise is made with regards to [security](http://docs.aws.amazon.com/efs/latest/ug/security-considerations.html): all clients will have to have network access to the drive. Someone with root access on one client instance can mount any directory on the EFS and they have read-write access to all files on the drive, even if they don't have access to the applications hosted on other clients. There isn't a no-root-squash equivalent for EFS. + +### EFS Gotchas and Limitations + +- 🔸 A number of NFSv4.1 features are [not supported](http://docs.aws.amazon.com/efs/latest/ug/nfs4-unsupported-features.html) and there are some [limits](http://docs.aws.amazon.com/efs/latest/ug/limits.html) to the service. +- 🔸 As of 2017-08, EFS offers disk level encryption for new drives. For file systems created before that date, encryption can only be achieved by moving the data to a new EFS volume. +- 🔸 An EFS file system [can be mounted on premises](https://aws.amazon.com/efs/faq/#on-premises) over Direct Connect. +- 🔸 An EFS file system can NOT be mounted over VPC peering or VPN, even if the VPN is running on top of Direct Connect. +- 🔸 Using an EFS volume on Windows is not supported. +- ⏱ When a file is uploaded to EFS, it can take hours for EFS to update the details for billing and burst credit purposes. +- 🔸⏱ Metadata operations can be costly in terms of burst credit consumption. Recursively traversing a tree containing thousands of files can easily ramp up to tens or even hundreds of megabytes of burst credits being consumed, even if no file is being touched. Commands like ```find``` or ```chown -R``` can have an adverse impact on performance. + + +Load Balancers +-------------- + +### Load Balancer Basics + +- AWS has 3 load balancing products - “Classic Load Balancers” (CLBs), “Application Load Balancers” (ALBs), and "Network Load Balancers" (NLB). +- Before the introduction of ALBs, “Classic Load Balancers” were known as “Elastic Load Balancers” (ELBs), so older documentation, tooling, and blog posts may still reference “ELBs”. +- CLBs have been around since 2009, ALBs in 2016, NLBs were added in 2017 to AWS. +- CLBs support TCP and HTTP load balancing. ALBs support HTTP load balancing only. NLBs support TCP layer 4 load balancing. +- CLBs and ALBs can optionally handle termination for a single SSL certificate. +- All can optionally perform active health checks of instances and remove them from the destination pool if they become unhealthy. +- CLBs don't support complex / rule-based routing. ALBs support a (currently small) set of rule-based routing features. NLBs have most extensive routing options. +- CLBs can only forward traffic to a single globally configured port on destination instances, while ALBs can forward to ports that are configured on a per-instance basis, better supporting routing to services on shared clusters with dynamic port assignment (like ECS or Mesos). NLBs support multiple ports on same IP; registering targets by IP address, including targets outside the VPC for the load balancer; ECS can select unused port for scheduling a task then register a target group using this port. +- CLBs are supported in EC2 Classic as well as in VPCs while ALBs are supported in VPCs only. +- ALBs can target groups of instances and IP based targets in the RFC1918 ranges allowing you to use on premise destinations via VPN or Direct Connect. + +### Load Balancer Tips + +- If you don’t have opinions on your load balancing up front, and don’t have complex load balancing needs like application-specific routing of requests, it’s reasonable just to use a CLB or ALB for load balancing instead. +- Even if you don’t want to think about load balancing at all, because your architecture is so simple (say, just one server), put a load balancer in front of it anyway. This gives you more flexibility when upgrading, since you won’t have to change any DNS settings that will be slow to propagate, and also it lets you do a few things like terminate SSL more easily. +- **CLBs and ALBs have many IPs:** Internally, an AWS load balancer is simply a collection of individual software load balancers hosted within EC2, with DNS load balancing traffic among them. The pool can contain many IPs, at least one per availability zone, and depending on traffic levels. They also support SSL termination, which is very convenient. +- **Scaling:** CLBs and ALBs can scale to very high throughput, but scaling up is not instantaneous. If you’re expecting to be hit with a lot of traffic suddenly, it can make sense to load test them so they scale up in advance. You can also [contact Amazon](http://aws.amazon.com/articles/1636185810492479) and have them “pre-warm” the load balancer. +- **Client IPs:** In general, if servers want to know true client IP addresses, load balancers must forward this information somehow. CLBs add the standard [X-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For) header. When using a CLB as an HTTP load balancer, it’s possible to get the client’s IP address from this. +- **Using load balancers when deploying:** One common pattern is to swap instances in the load balancer after spinning up a new stack with your latest version, keep old stack running for one or two hours, and either flip back to old stack in case of problems or tear it down. +- **Rotating Certificates while retaining ARN:** Rotating IAM Server Certificates can be difficult as the standard practice is to upload a new one then update all resources with the new ARN. You can however retain the same ARN using the `update-certificate` call with the following process: + 1. Upload a new IAM Server Certificate with a unique name (e.g fuzzy.com.new) + 2. Rename the existing IAM Server Certificate (e.g fuzzy.com to fuzzy.com.expired) + 3. Rename the new IAM Server Certificate to the name of the previously existing certificate (e.g fuzzy.com.new to fuzzy.com) + 4. Jiggle the CLB/ALB Listener to pick up the change: + * ALB: Invoke modify-listener with the existing details for the ALB Listener + * CLB: Invoke create-load-balancer-listeners with the existing details for the CLB listener + +### Load Balancer Gotchas and Limitations + +- ❗CLBs and ALBs have **no fixed external IP** that all clients see. For most consumer apps this doesn’t matter, but enterprise customers of yours may want this. IPs will be different for each user, and will vary unpredictably for a single client over time (within the standard [EC2 IP ranges](http://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)). And similarly, never resolve a CLB name to an IP and put it as the value of an A record — it will work for a while, then break! +- ❗Some web clients or reverse proxies cache DNS lookups for a long time, which is problematic for CLBs and ALBs, since they change their IPs. This means after a few minutes, hours, or days, your client will stop working, unless you disable DNS caching. Watch out for [Java’s settings](http://docs.oracle.com/javase/8/docs/api/java/net/InetAddress.html) and be sure to [adjust them properly](http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-jvm-ttl.html). Another example is nginx as a reverse proxy, which [normally resolves backends only at start-up](https://www.jethrocarr.com/2013/11/02/nginx-reverse-proxies-and-dns-resolution/) (although there is [a way to get around this](https://tenzer.dk/nginx-with-dynamic-upstreams/)). +- ❗It’s not unheard of for IPs to be recycled between customers without a long cool-off period. So as a client, if you cache an IP and are not using SSL (to verify the server), you might get not just errors, but responses from completely different services or companies! +- 🔸As an operator of a service behind a CLB or ALB, the latter phenomenon means you can also see puzzling or erroneous requests by clients of other companies. This is most common with clients using back-end APIs (since web browsers typically cache for a limited period). +- ❗CLBs and ALBs take time to scale up, it does not handle sudden spikes in traffic well. Therefore, if you anticipate a spike, you need to “pre-warm” the load balancer by gradually sending an increasing amount of traffic. +- ❗Tune your healthchecks carefully — if you are too aggressive about deciding when to remove an instance and conservative about adding it back into the pool, the service that your load balancer is fronting may become inaccessible for seconds or minutes at a time. Be extra careful about this when an autoscaler is configured to terminate instances that are marked as being unhealthy by a managed load balancer. +- ❗CLB HTTPS listeners don't support Server Name Indication (SNI). If you need SNI, you can work around this limitation by either providing a certificate with Subject Alternative Names (SANs) or by using TCP listeners and terminating SSL at your backend. +- 🔸 There is a limit on the number of ALBs, CLBs and NLBs per region (separately). As of late 2017, the default limit for each is 20 per region. These limits can be easily raised for ALB and CLB, but AWS is quite reluctant to raise the limit on NLBs. +- 🔸 If using a Network Load Balancer (NLB) then EC2 clients cannot connect to an NLB that resides in another VPC (VPC Peering) or AWS managed VPN unless the EC2 client is a C5, i3.metal or M5 instance type. For VPC peering, both VPCs must be in the same region. See [Troubleshooting](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-troubleshooting.html#target-not-in-service). + +Классический балансировщик нагрузки(CLB) +--- + +### Основы CLB + +- 📒 [Домашняя страница](https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/) ∙ [Руководство пользователя](https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/developer-resources/) ∙ [ЧаВо](https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/faqs/) ∙ [Расценки](https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/pricing/) +- Классические балансировщики нагрузки, ранее известные как Эластичные балансировщики нагрузки - это балансировщики нагрузки работающие по протоколам HTTP и TCP, которые управляются и масштабируются Amazon. + +### Советы по CLB + +- **Лучшие практики:** [Эта статья](http://aws.amazon.com/articles/1636185810492479) является обязательной к прочтению, если вы широко используете CLBs и содержит массу информации. + +### Ошибки и ограничения, связанные с CLB + +- В общем и целом, CLB не такие “умные” как некоторые балансировщики нагрузки, и у них нет этих прикольных особенностей и детального контроля, который есть у традиционных железных балансировщиков нагрузки. В большинстве случаев, связанных с безсессионными приложениями или сеансами на основе файлов cookie через HTTP или терминацию SSL, они работают хорошо. +- 🔸По умолчанию, CLB откажет маршрутизировать траффик от балансировщика нагрузки в одной зоне доступности(AZ) на бэкенд инстанс в другой. В случае если последний инстанс в зоне доступности(AZ) будет недоступент - это [вызовет ошибку 503](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/ts-elb-error-message.html#ts-elb-errorcodes-http503), даже есть живые инстансы есть в других зонах. Если у вас запущено менее двух бэкенд инстансов на зону доступности(AZ), вам почти наверняка необходимо [включить меж-зонную балансировку нагрузки](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-crosszone-lb.html#enable-cross-zone). +- 🔸Сложные правила для направления траффика не поддерживаются. Например, вы не можете направлять траффик на основании регулярных выражений в URL, как это делает [HAProxy](http://www.haproxy.org/). +- **Основные имена DNS:** Когда-то давным-давно, вы не могли назначать CLB на основную запись DNS (например example.com вместо foo.example.com) потому что требовалась A запись вместо CNAME. Теперь это стало возможным с использованием записи Route 53 alias напрямую указывающей на балансировщик нагрузки. +- 🔸CLB использует [HTTP keep-alives](https://en.wikipedia.org/wiki/HTTP_persistent_connection) на внутренней стороне. Это может привести к неожиданному эффекту: Запросы от разных клиентов, каждый из которых использует собственное TCP соединение на внешней стороне, могут дойти одним TCP соединением на внутренней стороне. Никогда не предполагайте, что несколько запросов на одном и том же TCP-соединении поступают от одного и того же клиента! +- 🔸 Траффик между CLB и бэкинстансами в одной подсети **обязательно** подчиняются правилам [Сетевого списка доступа(Network ACL)](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html), в то время как (траффик между EC2 в одной подсети - не проверяется на соответствие NACL). Если правило по умолчанию '0.0.0.0/0 ALLOW' удалено из NACL, назначенного на подсеть, правило разрешающее траффик на порты проверки на работоспособность и приложения должно быть добавлено. +- По состоянию на 2016 год, CLB запущенный в VPCs не поддерживает IPv6 адресацию. CLB запущенный в окрущении EC2-Classic поддерживает IPv4 и IPv6 [с использованием DNS имени с префиксом "dualstack"](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses). + +ALB +--- + +### Основы ALB + +- 📒 [Домашняя страница](https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/) ∙ [Руководство пользователя](https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/developer-resources/) ∙ [ЧаВо](https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/faqs/) ∙ [Расценки](https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/pricing/) +- 🐥**Вебсокеты и HTTP/2** [теперь поддерживаются](https://aws.amazon.com/blogs/aws/new-aws-application-load-balancer/). +- 🐥**Интернет протокол версии 6 (IPv6)** [теперь поддерживается](https://aws.amazon.com/about-aws/whats-new/2017/01/announcing-internet-protocol-version-6-ipv6-support-for-elastic-load-balancing-in-amazon-virtual-private-cloud-vpc/). +- 🐥**Балансировка нагрузки по IP** [теперь поддерживается](https://aws.amazon.com/about-aws/whats-new/2017/08/elastic-load-balancing-application-load-balancer-now-supports-load-balancing-to-ip-addresses-as-targets-for-aws-and-on-premises-resources/). +- До появления программного балансировщика нагрузки(Application Load Balancer), вам было рекомендовано использовать TCP вместо HTTP, (как описано [тут](http://www.quora.com/When-will-Amazon-ELB-offer-SPDY-support)) и использовать [не понятный, но полезный протокол проксирования](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html) ([дополнительно можно прочесть тут](https://chrislea.com/2014/03/20/using-proxy-protocol-nginx/)), чтобы передавать IP-адреса клиентов через балансировщик нагрузки работающий по TCP. + +### Советы по ALB + +- Используйте ALB для маршрутизации запросов к сервисам, размещенным в общих кластерах с динамическим назначением портов. (таким как ECS или Mesos). +- ALB поддерживает [маршрутизацию на основе HTTP host](http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#host-conditions) (посылаем HTTP запрос на “api.mydomain.com” -> {target-group-1}, “blog.mydomain.com” -> {target group 2}) также как и [маршрутизацию на основе HTTP пути](http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#path-conditions) (посылаем HTTP запрос на “/api/*” -> {target-group-1}, “/blog/*” -> {target group 2}). + +### Ошибки и ограничения, связанные с ALB + +- 🔸ALB поддерживает HTTP/2 через HTTPS (не поддерживает HTTP/2 открытым текстом). +- 🔸ALB поддерживает HTTP/2 для внешних клиентов, а не для внутренних ресурсов (инстансов/контейнеров). +- ALB поддерживает маршрутизацию HTTP, но не поддерживает TCP маршрутизацию на основе номера порта. +- Инстансы в таргет группах ALB должны иметь один, фиксированный порт для проверки работоспособности(health-check) (проверки работоспособности на уровне “EC2 инстанса”) или порт проверки работоспособности(health-check) для цели должен быть таким же, как и порт приложения (проверки работоспособности на уровне “приложения”) - вы не можете сконфигурировать порт проверки работоспособности для каждой цели, который бы отличался от порта приложения. +- ALB работает только при использовании VPC (и не доступно для EC2 Classic) +- Если в таргет группе нет живой цели, все запросы направляются ко всем членам таргет группы. Например, если вы настроили листенер на таргет группу, содержащую один сервис с долгой фазой инициализации(во время которой, все проверки на работоспособность не пройдут), запросы все равно будут достигать сервиса, несмотря на то, что он все еще загружается. +- 📜 Кроме того ALB [теперь поддерживает SNI(расширение TLS позволяющее передавать имя хоста с которым он хочет соединиться)](https://aws.amazon.com/about-aws/whats-new/2017/10/elastic-load-balancing-application-load-balancers-now-support-multiple-ssl-certificates-and-smart-certificate-selection-using-server-name-indication-sni/), однако поддерживается только 25 HTTPS сертификатов на балансировщик нагрузки. Это ограничение не описано [здесь](http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html), так что возможно, что это изменится. + +Elastic Beanstalk +---------------- + +### Elastic Beanstalk Basics +- 📒 [Homepage](https://aws.amazon.com/elasticbeanstalk/) ∙ [Developer guide](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) ∙ [FAQ](https://aws.amazon.com/elasticbeanstalk/faqs/) ∙ [Pricing](https://aws.amazon.com/elasticbeanstalk/pricing/) +- **EB** (Elastic Beanstalk) is a PaaS (Platform as a Service) that helps developers create, deploy and scale web applications +- EB handles deployment, configuration, provisioning, load balancing, auto-scaling, monitoring, and logging +- EB creates AWS resources on your behalf but you retain full access and control of the underlying resources +- 💸 There is no cost to use EB but you will still be charged the full cost of the underlying AWS resources created by EB + +### Elastic Beanstalk Tips +- To speed up deployment before launch or in a dev stage, turn off health checks and set the `Deployment policy` to `All at once` +- If you have a configuration you want to re-use for multiple EB apps, you can save the current configuration using `eb config save --cfg myEBConfig` +- By default, EB doesn't have any alarms. You'll need to add them yourself on metrics that you're monitoring. +- By default, EB doesn't enable [managed platform updates](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-platform-update-managed.html?icmpid=docs_elasticbeanstalk_console). Enable them in configuration to have EB automatically apply updates during a pre-specified maintenance window + +### Elastic Beanstalk Gotchas and Limitations +- 🔸 Don't edit [apache|nginx] conf files manually on ec2 instances as they will be re-written on each deployment (use [ebextensions](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions.html) instead) +- 🔸 After creating an EB environment, it's no longer possible to change the `Name` tag +- 🔸 EB will sometimes quarantine instances that cause multiple deployment issues. Despite being quarantined, EB will still deploy to them on subsequent deployments. To prevent this behavior, said instances will need to be terminated (or the underlying issue fixed) +- File uploads are capped at 10MB for most default eb configurations - update [nginx config](https://stackoverflow.com/questions/18908426/increasing-client-max-body-size-in-nginx-conf-on-aws-elastic-beanstalk) to change +- If you edit `.elasticbeanstalk/saved_configs/`, be aware that this is not kept in sync with the EB environment config. You'll need to manually fetch and save for changes to take effect + +Elastic IPs +----------- + +### Elastic IP Basics + +- 📒 [Documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) ∙ [FAQ](https://aws.amazon.com/ec2/faqs/#Elastic_IP) ∙ [Pricing](https://aws.amazon.com/ec2/pricing/on-demand/#Elastic_IP_Addresses) +- **Elastic IPs** are static IP addresses you can rent from AWS to assign to EC2 instances. + +### Elastic IP Tips + +- 🔹**Prefer load balancers to elastic IPs:** For single-instance deployments, you could just assign elastic IP to an instance, give that IP a DNS name, and consider that your deployment. Most of the time, you should provision a [load balancer](#load-balancers) instead: + - It’s easy to add and remove instances from load balancers. It’s also quicker to add or remove instances from a load balancer than to reassign an elastic IP. + - It’s more convenient to point DNS records to load balancers, instead of pointing them to specific IPs you manage manually. They can also be Route 53 aliases, which are easier to change and manage. + - But in some situations, you do need to manage and fix IP addresses of EC2 instances, for example if a customer needs a fixed IP. These situations require elastic IPs. +- Elastic IPs are limited to 5 per account. It’s possible to [request more](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase&limitType=service-code-elastic-ips-ec2-classic). +- If an Elastic IP is not attached to an active resource there is a small [hourly fee](https://aws.amazon.com/ec2/pricing/on-demand/#Elastic_IP_Addresses). +- Elastic IPs are [no extra charge](https://aws.amazon.com/ec2/pricing/on-demand/#Elastic_IP_Addresses) as long as you’re using them. They have a (small) cost when not in use, which is a mechanism to prevent people from squatting on excessive numbers of IP addresses. + +### Elastic IP Gotchas and Limitations + +- 🔸There is [officially no way](https://forums.aws.amazon.com/thread.jspa?threadID=171550) to allocate a contiguous block of IP addresses, something you may desire when giving IPs to external users. Though when allocating at once, you may get lucky and have some be part of the same CIDR block. If this is important to you, you may want to [bring your own IP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html), which is more involved than this guide will go into. + +Glacier +------- + +### Glacier Basics + +- 📒 [Homepage](https://aws.amazon.com/glacier/) ∙ [Developer guide](http://docs.aws.amazon.com/amazonglacier/latest/dev/) ∙ [FAQ](https://aws.amazon.com/glacier/faqs/) ∙ [Pricing](https://aws.amazon.com/glacier/pricing/) +- **Glacier** is a lower-cost alternative to S3 when data is infrequently accessed, such as for archival purposes. +- It’s only useful for data that is rarely accessed. It generally takes [3-5 hours](https://aws.amazon.com/glacier/faqs/#dataretrievals) to fulfill a retrieval request. +- AWS [has not officially revealed](https://en.wikipedia.org/wiki/Amazon_Glacier#Storage) the storage media used by Glacier; it may be low-spin hard drives or even tapes. +- AWS has released an even more cost effective storate tier called [Glacier Deep Archive](https://aws.amazon.com/blogs/aws/new-amazon-s3-storage-class-glacier-deep-archive/) that offers ~12 hour retrieval latencies, but costs roughly a thousand dollars per month per petabyte. + +### Glacier Tips + +- You can physically [ship](https://aws.amazon.com/blogs/aws/send-us-that-data/) your data to Amazon to put on Glacier on a USB or eSATA HDD. + +### Glacier Gotchas and Limitations + +- 🔸Getting files off Glacier is glacially slow (typically 3-5 hours or more). +- 🔸Due to a fixed overhead per file (you pay per PUT or GET operation), uploading and downloading many small files on/to Glacier might be very expensive. There is also a 32k storage overhead per file. Hence it’s a good idea is to archive files before upload. +- 💸Be aware of the per-object costs of archiving S3 data to Glacier. [It costs $0.05 per 1,000 requests](https://aws.amazon.com/s3/pricing/). If you have large numbers of S3 objects of relatively small size, [it will take time to reach a break-even point](https://alestic.com/2012/12/s3-glacier-costs/) (initial archiving cost versus lower storage pricing). + +RDS +--- + +### RDS Basics + +- 📒 [Homepage](https://aws.amazon.com/rds/) ∙ [User guide](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/) ∙ [FAQ](https://aws.amazon.com/rds/faqs/) ∙ [Pricing](https://aws.amazon.com/rds/pricing/) (see also [ec2instances.info/rds/](http://www.ec2instances.info/rds/)\) +- **RDS** is a managed relational database service, allowing you to deploy and scale databases more easily. It supports [Oracle](https://aws.amazon.com/rds/oracle/), [Microsoft SQL Server](https://aws.amazon.com/rds/sqlserver/), [PostgreSQL](https://aws.amazon.com/rds/postgresql/), [MySQL](https://aws.amazon.com/rds/mysql/), [MariaDB](https://aws.amazon.com/rds/mariadb/), and Amazon’s own [Aurora](https://aws.amazon.com/rds/aurora/). +- RDS offers out of the box support for [high availability and failover](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) for your databases. + +### RDS Tips + +- If you're looking for the managed convenience of RDS for other data stores such as MongoDB or Cassandra, you may wish to consider third-party services from providers such as [mLab](https://mlab.com/), [Compose](https://www.compose.com/), or [InstaClustr](https://www.instaclustr.com/). +- 🔹Make sure to create a new [parameter group](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html) and option group for your database since the default parameter group does not allow dynamic configuration changes. +- RDS instances start with a default timezone of UTC. If necessary, this can be [changed to a different timezone](https://aws.amazon.com/premiumsupport/knowledge-center/rds-change-time-zone/). + +### RDS Gotchas and Limitations + +- ⏱RDS instances run on EBS volumes (either general-purpose or provisioned IOPS), and hence are constrained by EBS performance. +- 🔸Verify what database features you need, as not everything you might want is available on RDS. For example, if you are using Postgres, check the list of [supported features and extensions](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#SQLServer.Concepts.General.FeatureSupport). If the features you need aren't supported by RDS, you'll have to deploy your database yourself. +- 🔸If you use the failover support offered by RDS, keep in mind that it is based on DNS changes, and make sure that your client reacts to these changes appropriately. This is particularly important for Java, given how its DNS resolver’s TTL is [configured by default](http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html). +- 🔸**DB migration to RDS:** While importing your database into RDS ensure you take into consideration the maintenance window settings. If a backup is running at the same time, your import can take a considerably longer time than you would have expected. +- [Database sizes are limited](https://aws.amazon.com/about-aws/whats-new/2015/06/amazon-rds-increases-storage-limits-to-6TB-for-piops-and-gp2/) to **6TB** for all database engines except for SQL Server which has a **4TB** limit and Aurora which supports up to **64TB** databases. + +RDS MySQL and MariaDB +--------------------- + +### RDS MySQL and MariaDB Basics + +- RDS offers MySQL versions 5.5, 5.6, 5.7 and 5.8. +- RDS offers MariaDB versions 10.0, 10.1, 10.2 and 10.3. + +### RDS MySQL and MariaDB Tips + +- MySQL RDS allows access to [binary logs](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html#USER_LogAccess.MySQL.BinaryFormat). +- Multi-AZ instances of MySQL transparently replicate data across AZs using DRBD. Automated backups of multi-AZ instances [run off the backup instance](https://www.percona.com/live/mysql-conference-2014/sessions/rds-mysql-tips-patterns-and-common-pitfalls) to reduce latency spikes on the primary. +- 🔸**Performance Schema:** While [Performance Schema](http://dev.mysql.com/doc/refman/en/performance-schema.html) is enabled by default in MySQL 5.6.6 and later, it is disabled by default in all versions of RDS. If you wish to enable Performance Schema, a reboot of the RDS instance will be required. +- 🔸**MySQL vs MariaDB vs Aurora:** If you prefer a MySQL-style database but are starting something new, you probably should consider Aurora and MariaDB as well. **Aurora** has increased availability and is the next-generation solution. That said, Aurora [may not be](http://blog.takipi.com/benchmarking-aurora-vs-mysql-is-amazons-new-db-really-5x-faster/) that much faster than MySQL for certain workloads. **MariaDB**, the modern [community fork](https://en.wikipedia.org/wiki/MariaDB) of MySQL, [likely now has the edge over MySQL](http://cloudacademy.com/blog/mariadb-vs-mysql-aws-rds/) for many purposes and is supported by RDS. + +### RDS MySQL and MariaDB Gotchas and Limitations + +- 🔸**No SUPER privileges.** RDS provides some [stored procedures](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.SQLRef.html) to perform some tasks that require SUPER privileges such as starting or stopping replication. +- 🔸You can replicate to non-RDS instances of MySQL, but [replication to these instances will break during AZ failovers](https://www.percona.com/live/mysql-conference-2014/sessions/rds-mysql-tips-patterns-and-common-pitfalls). +- 🔸There is no ability to manually CHANGE MASTER on replicas, so they must all be rebuilt after a failover of the master. +- 🔸Most global options are exposed only via [DB parameter groups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html). Some variables that were introduced in later MySQL dot releases such as [avoid_temporal_upgrade](https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_avoid_temporal_upgrade) in MySQL 5.6.24 are not made available in RDS's 5.6.x parameter group and making use of them requires an upgrade to MySQL 5.7.x. +- 🔸RDS features such as Point-In-Time restore and snapshot restore are not supported on MyISAM tables. Ensure you lock and flush each MyISAM table before executing a snapshot or backup operation to ensure consistency. + +RDS PostgreSQL +-------------- + +### RDS PostgreSQL Basics + +- RDS offers PostgreSQL 9.3, 9.4, 9.5, 9.6, and 10. + +### RDS PostgreSQL Tips +- Recently Logical Replication is being supported, [both as subscriber and publisher](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.version104). +- Supports a relatively large range of native [extensions](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions). +- RDS PostgreSQL 10 Supports native partitioning and most of the major features and tunables. +- Supports connections over SSL. +- Supports multi A-Z and Point-in-time recovery. + + +### RDS PostgreSQL Gotchas and Limitations +- No superuser privileges. RDS provides a role `rds_superuser` that can do most of the needed operations but there are some limitations. +- Some major features are delayed compared to open source PostgreSQL. +- By default RDS is spec’d with general purpose SSD , if you need better performance you have to spec provisioned IOPS SSD. +- You can't use RDS as a replica outside RDS without using logical replication. +- There are settings that cannot be changed and most of the settings that can change can only be changed using database parameter groups. +- It’s harder to troubleshoot performance problems since you have no access to the host. +- Be sure to verify that all the [extensions](https://www.postgresql.org/docs/current/static/view-pg-available-extensions.html) you need are available. If you are using an extension not listed there, you will need to come up with a work around, or deploy your own database in EC2. +- Many Postgres utilities and maintenance items expect command line access, that can usually be satisfied by using an external ec2 server. + +RDS SQL Server +-------------- + +### RDS SQL Server Basics + +- [RDS offers SQL Server 2008 R2, 2012, 2014, 2016 and 2017](https://aws.amazon.com/rds/sqlserver/) including Express, Web, Standard and Enterprise. + +### RDS SQL Server Tips + +- Recently added support for [backup and restore to/from S3](https://www.brentozar.com/archive/2016/07/holy-cow-amazon-rds-sql-server-just-changed-everything/) which may make it an attractive [DR option](https://aws.amazon.com/blogs/aws/amazon-rds-for-sql-server-support-for-native-backuprestore-to-amazon-s3/) for on-premises installations. + +### RDS SQL Server Gotchas and Limitations + +- 🔸The user is granted only db_owner privileges for each database on the instance. +- 🔸Storage cannot be expanded for existing databases. If you need more space, you must restore your database on a new instance with larger storage. +- 🔸There is a **16TB** database size limit for non-Express editions. There is also a minimum storage size, 20GB for Web and Express, 200GB for Standard and Enterprise. +- 🔸Limited to [30 databases per instance](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html) + +RDS Aurora +---------- +### RDS Aurora Basics +Aurora is a cloud only database service designed to provide a distributed, fault-tolerant relational database with self-healing storage and auto-scaling up to 64TB per instance. It currently comes in two versions, a MySQL compatible system, and a PostgreSQL compatible system. + +RDS Aurora MySQL +---------------- + +### RDS Aurora MySQL Basics + +- Amazon’s proprietary fork of MySQL intended to scale up for high concurrency workloads. Generally speaking, individual query performance under Aurora is not expected to improve significantly relative to MySQL or MariaDB, but Aurora is intended to maintain performance while executing many more queries concurrently than an equivalent MySQL or MariaDB server could handle. +- [Notable new features](http://www.slideshare.net/AmazonWebServices/amazon-aurora-amazons-new-relational-database-engine) include: + - Log-structured storage instead of B-trees to improve write performance. + - Out-of-process buffer pool so that databases instances can be restarted without clearing the buffer pool. + - The underlying physical storage is a specialized SSD array that automatically maintains 6 copies of your data across 3 AZs. + - Aurora read replicas share the storage layer with the write master which significantly reduces replica lag, eliminates the need for the master to write and distribute the binary log for replication, and allows for zero-data-loss failovers from the master to a replica. The master and all the read replicas that share storage are known collectively as an **Aurora cluster**. Read replicas can span up to [5 regions](https://aws.amazon.com/about-aws/whats-new/2018/09/amazon-aurora-databases-support-up-to-five-cross-region-read-replicas/). + +### RDS Aurora MySQL Tips + +- In order to take advantage of Aurora’s higher concurrency, applications should be configured with large database connection pools and should execute as many queries concurrently as possible. For example, Aurora servers have been tested to produce increasing performance on some OLTP workloads with [up to 5,000 connections](http://www.slideshare.net/AmazonWebServices/amazon-aurora-amazons-new-relational-database-engine/31). +- [Aurora scales well with multiple CPUs](https://www.percona.com/blog/2016/05/26/aws-aurora-benchmarking-part-2/) and may require a large instance class for optimal performance. +- The easiest migration path to Aurora is restoring a database snapshot from MySQL 5.6 or 5.7. The next easiest method is restoring a dump from a MySQL-compatible database such as MariaDB. For [low-downtime migrations](https://aws.amazon.com/blogs/aws/amazon-aurora-update-spatial-indexing-and-zero-downtime-patching/) from other MySQL-compatible databases, you can set up an Aurora instance as a replica of your existing database. If none of those methods are options, Amazon offers a fee-based data migration service. +- You can replicate [from an Aurora cluster to MySQL or to another Aurora cluster](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Overview.Replication.MySQLReplication.html). This requires binary logging to be enabled and is not as performant as native Aurora replication. +- Because Aurora read replicas are the [equivalent of a multi-AZ backup](http://stackoverflow.com/a/32428651/129052) and they can be configured as zero-data-loss failover targets, there are fewer scenarios in which the creation of a multi-AZ Aurora instance is required. + +### RDS Aurora MySQL Gotchas and Limitations + +- 🔸[Aurora 1.x is based on MySQL 5.6.x](https://news.ycombinator.com/item?id=12415693) with some cherry-picking of later MySQL features. It is missing most 5.7 features as well as some online DDL features introduced in 5.6.17. +- 🔸[Aurora 2.x is based on MySQL 5.7.x](https://aws.amazon.com/about-aws/whats-new/2018/02/amazon-aurora-is-compatible-with-mysql-5-7/) +- Aurora does not support GTID transactions in either the 5.6/Aurora 1.x or the 5.7/Aurora 2.x release lines. +- Aurora maximum cluster size is 64 TB + +RDS Aurora PostgreSQL +--------------------- + +### RDS Aurora PostgreSQL Basics + +- Amazon’s proprietary fork of PostgreSQL, intended to scale up for high concurrency workloads while maintaining ease of use. Currently based on PostgreSQL 9.6. +- Higher throughput (up to 3x with similar hardware). +- Automatic storage scale in 10GB increments up to 64TB. +- Low latency read replicas that share the storage layer with the master which significantly reduces replica lag. +- Point in time recovery. +- Fast database snapshots. + +### RDS Aurora PostgreSQL Tips +- Aurora Postgres by default is supposed to utilize high connection rates and for this reason connection pooling must be configured accordingly. +- Because Aurora is based on PostgreSQL 9.6, it lacks features like declarative partitioning or logical replication. + +### RDS Aurora PostgreSQL Gotchas and Limitations +- Aurora PostgreSQL falls behind normal RDS when it comes to available versions, so if you need features from the latest PostgreSQL version you might be better off with plain RDS. +- Patching and bug fixing is separate from open source PostgreSQL. + +ElastiCache +----------- + +### ElastiCache Basics + +- 📒 [Homepage](https://aws.amazon.com/elasticache/) ∙ [User + guide for Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/index.html) ∙ [User + guide for Memcached](https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/index.html) ∙ + [FAQ](https://aws.amazon.com/elasticache/faqs/) ∙ + [Pricing](https://aws.amazon.com/elasticache/pricing/) +- **ElastiCache** is a managed in-memory cache service, that can be used to + store temporary data in a fast in-memory cache, typically in order to avoid + repeating the same computation multiple times when it could be reused. +- It supports both the [Memcached](https://memcached.org) and + [Redis](https://redis.io) open source in-memory cache software and exposes + them both using their native access APIs. +- The main benefit is that AWS takes care of running, patching and optimizing + the cache nodes for you, so you just need to launch a cluster and configure + its endpoint in your application, while AWS will take of most of the operational + work of running the cache nodes. + +### ElastiCache Tips + +- Choose the + [engine](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/SelectEngine.html), + clustering configuration and [instance + type](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/CacheNodes.SelectSize.html) + carefully based on your application needs. The documentation explains in + detail the pros, cons and limitations of each engine in order to help you + choose the best fit for your application. In a nutshell, Redis is + preferable for storing more complex data structures, while Memcached is just a + plain key/value store. The simplicity of Memcached allows it to be slightly + faster and allows it to scale out if needed, but Redis has more features which + you may use in your application. +- For Memcached AWS provides enhanced SDKs for certain programming languages + which implement + [auto-discovery](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/AutoDiscovery.html), + a feature not available in the normal memcached client libraries. + +### ElastiCache Gotchas and Limitations + +- Since in some cases changing the cache clusters may have some restrictions, + like for + [scaling](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Scaling.html) + purposes, it may become a problem if they were launched using CloudFormation + in a stack that also contains other resources and you really need to change + the cache. In order to avoid getting your CloudFormation stacks in a + non-updateable state, it is recommended to launch ElastiCache clusters (just + like any other resource with similar constraints) in dedicated stacks which + can be replaced entirely with new stacks having the desired configuration. + + +DynamoDB +-------- + +### Основы DynamoDB + +- 📒 [Домашняя страница](https://aws.amazon.com/dynamodb/) ∙ [Руководство разработчика](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/) ∙ [ЧаВо](https://aws.amazon.com/dynamodb/faqs/) ∙ [Расценки](https://aws.amazon.com/dynamodb/pricing/) +- **DynamoDB** - это [NoSQL](https://en.wikipedia.org/wiki/NoSQL) база данных, которая фокусируется на скорости, гибкости и масштабируемости. +- DynamoDB оплачивается на основе комбинации пропускной способности и объема хранения данных. + +### Альтернативы DynamoDB и привязки + +- ⛓ В отличие от технологий, лежащих в основе многих других продуктов Amazon, DynamoDB является проприетарным продуктом AWS без совместимой с интерфейсом альтернативы, доступной в качестве проекта с открытым исходным кодом.Если вы тесно связываете свое приложение с его API и набором функций, его замена потребует значительных усилий. +- Наиболее часто используемая альтернатива DynamoDB - [Cassandra](http://cassandra.apache.org/). + +### Советы по DynamoDB + +- Существует [**локальная версия DynamoDB**](https://aws.amazon.com/blogs/aws/dynamodb-local-for-desktop-development/) предоставляемая для использования в разработке. +- [DynamoDB Streams](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html) предоставляет упорядоченный поток изменений в таблице. Используйте его для репликации, резервного копирования или извлечения событий из данных. +- DynamoDB может использоваться [в качестве простой службы блокировки](https://gist.github.com/ryandotsmith/c95fd21fab91b0823328). +- Индексация DynamoDB может включать **первичные ключи**, которые могут быть либо хеш-ключом с одним атрибутом, либо диапазоном составного хеш-ключа. Вы также можете запросить атрибуты не первичного ключа, используя [**вторичные индексы**] (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html). +- **Типы данных:** DynamoDB поддерживает три [типа данных](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.DataTypes.html) – **число**, **строка**, и **двоичные(binary)** – как в скалярных, так и в многозначных множествах. DynamoDB также может поддерживать [**JSON**](https://aws.amazon.com/blogs/aws/dynamodb-update-json-and-more/). +- По состоянию на конец 2017 года, DynamoDB поддерживает как [глобальные таблицы](https://aws.amazon.com/dynamodb/global-tables/), так и [функциональность резервного копирования и восстановления](https://aws.amazon.com/dynamodb/backup-restore/). + +### Ошибки и ограничения, связанные с DynamoDB + +- 🔸 DynamoDB не предоставляет простой способ массовой загрузки данных(это возможно через [Data Pipeline](http://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-importexport-ddb-part1.html)) и моет привести к [печальным последствиям](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.AvoidExcessivePTIncreases). Поскольку для обновления существующих или создания новых строк необходимо использовать обычные служебные API-интерфейсы, обычно для ускорения импорта временно увеличивают пропускную способность записи в целевой таблице. Но когда емкость записи таблицы увеличивается, DynamoDB может выполнить необратимое разделение партиций, лежащих в основе таблицы, распределяя полную емкость таблицы равномерно между новыми таблицами. Позднее, когда емкость будет снижена, емкость каждой партиции также будет снижена, однако количество партиций останется тем же, что приведет к снижению емкости каждой партиции. Это приводит таблицу в состояние, когда хотспоты могут перегрузить отдельную партицию. +- 🔸 Важно удостовериться, что [ресурсные лимиты](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html#limits-data-types) DynamoDB совместимы с вашим набором данных и рабочей нагрузкой. Например, максимальный размер значения, которое может быть добавлено в таблицу DynamoDB - 400 KB (большие данные могут храниться в S3 и хранить URL в DynamoDB). +- 🔸 Работа с **данными временного ряда** в DynamoDB может быть сложной задачей. Глобальный вторичный индекс совместно с понижающейся выборкой временных меток может выступать в роли возможного решения, как описано [тут](https://blogs.aws.amazon.com/bigdata/post/Tx3KPZDXIBJEQ4B/Scaling-Writes-on-Amazon-DynamoDB-Tables-with-Global-Secondary-Indexes). +- 🔸 DynamoDB не [позволяет](https://forums.aws.amazon.com/thread.jspa?threadID=90137) пустой строке быть значением атрибута. Наиболее часто используемый способ обхода - использовать заменяемое значение взамен пустого поля. +- 🔸 Когда настраиваешь [гранулированные политики доступа](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/specifying-conditions.html) к таблицам DynamoDB, убедись, что включил их вторичные индексы в политику. + + +ECS +--- + +### Основы ECS + +- 📒 [Домашняя страница](https://aws.amazon.com/ecs/) ∙ [Руководство разработчика](http://docs.aws.amazon.com/AmazonECS/latest/developerguide/) ∙ [ЧаВо](https://aws.amazon.com/ecs/faqs/) ∙ [Расценки](https://aws.amazon.com/ecs/pricing/) +- **ECS** (EC2 Container Service) это относительно новый сервис (запущен в конце 2014 года), который управляет кластерами сервисов, развернутых через Docker. +- Посмотрите раздел [Контейнеры и AWS](#containers-and-aws) для получения дополнительной информации о контейнерах. +- Применение ECS растет, особенно в компаниях, использующих микросервисы. +- Самостоятельное развертывание Docker напрямую на машинах в EC2 также остается одним из основных подходов использования Docker в AWS. Использование ECS не обязательно и ECS пока не является доминантным способом использования Docker в AWS. +- Также возможно использования [Elastic Beanstalk с Docker](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html), что является целесообразным если вы уже используете Elastic Beanstalk. +- Использование Docker может изменить способ развертывания ваших сервисов в EC2 или Elastic Beanstalk, но это не меняет радикально то, как используется большинство других служб. +- [ECR](https://aws.amazon.com/ecr/) (EC2 Container Registry) - это управляемый Amazon реестр образов Docker. Хотя его использование проще, нежели развертывание своего реестра, у него отсуствуют некоторые особенности, которые могут потребоваться некоторым пользователям: + - Не поддерживается межрегиональная репликация образов. + - Если вам необходимо быстрое развертывание больших образов на весь флот инстансов, вам необходимо положить ваш образ в региональный реестр. + - Не поддерживает пользовательские домены / сертификаты. +- Работоспособность контейнеров мониторится [CLB](#классический-балансировщик-нагрузкиclb) или [ALB](#alb). Они также используются для доступа к контейнеризированным сервисам. При использовании ALB вам не нужно обрабатывать конфликты портов (то есть сервисы, предоставляющие один и тот же порт на одном и том же хосте), поскольку целевые группы ALB могут быть напрямую связаны со службами на основе ECS. +- [Руководство автостопщика по AWS ECS и Docker](http://start.jcolemorrison.com/the-hitchhikers-guide-to-aws-ecs-and-docker/) написанное J. Cole Morrison является великолепной статьей по представлению концепций AWS ECS. + + + +### Советы по ECS + +- **Драйверы логов(коллекторы):** ECS поддерживает множество драйверов логов (awslogs, splunk, fluentd, syslog, json, ... ). Используйте [`awslogs`](http://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html) для CloudWatch (сначала убедитесь, что группа для логов создана). [Такие драйвера, как fluentd по умолчанию выключены](https://github.com/aws/amazon-ecs-agent/issues/535). Вы можете установить агента и включить драйвер путем добавления `ECS_AVAILABLE_LOGGING_DRIVERS='["awslogs","fluentd"]'` в `/etc/ecs/ecs.config`. +- [Этот блог от Convox](https://convox.com/blog/ecs-challenges) (и [комментарии](https://news.ycombinator.com/item?id=11598058)) перечисляют ряд общих проблем с ECS по состоянию на начало 2016 года. +- Можно оптимизировать очистку диска на ECS. По умолчанию неиспользуемые контейнеры удаляются через 3 часа, а неиспользуемые образы - через 30 минут. Эти настройки можно изменить путем добаления `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION=10m` и `ECS_IMAGE_CLEANUP_INTERVAL=10m` в `/etc/ecs/ecs.config`. [Больше информации по оптимизации очистки диска в ECS](https://aws.amazon.com/blogs/compute/optimizing-disk-usage-on-amazon-ecs/). + +### Альтернативы ECS и привязки + +- [Kubernetes](https://kubernetes.io): Обширная контейнерная платформа. Доступна как сервис на Google Cloud (https://cloud.google.com/container-engine/) и AWS (https://tectonic.com/). У AWS есть руководство по быстрому старту Kubernetes (https://aws.amazon.com/quickstart/architecture/heptio-kubernetes/) разработанное совместно с Heptio. +- [Nomad](https://www.nomadproject.io/): Оркестратор/Планировщик, тесно связанный со стэком Hashicorp (Consul, Vault и т.д.). + +🚧 [*Пожалуйста помогите дополнить этот незавершенный раздел*](CONTRIBUTING.md) + +EKS +--- + +### Основы EKS Basics +- 📒 [Домашняя страница](https://aws.amazon.com/eks/) ∙ [Руководство пользователя](http://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) ∙ [ЧаВо](https://aws.amazon.com/eks/faq/) ∙ [Расценки](https://aws.amazon.com/eks/pricing/) +- EKS (Elastic Kubernetes Service) - это новый сервис (запущен в июне 2018 года) который предоставляет управляемые высокодоступные отказоустойчивые мастер-ноды Kubernetes, для развертывания сервисов и под K8s на нодах Kubernetes на базе инстансов EC2. +- Посмотрите раздел [Контейнеры и AWS](#containers-and-aws) для получения дополнительной информации о контейнерах. +- EKS - это решение AWS для нативного размещения Kubernetes на AWS. Это не замена ECS, а в ответ на большое доминирование на рынке Kubernetes. +- EKS не запускает ноды EC2 и должен быть установлен и настроен либо вручную, либо через Cloudformation (или другим решением для автоматизации) +- Управление EKS осуществляется через утилиту kubectl и конфигурационными файлами Kube. Эти файлы должны быть настроены так, чтобы соединяться с мастером K8s с URL и сертификатом. AWS CLI может автоматически сгенерировать конфигурационный файл, который требуется kubectl для связи с кластером.[1](#user-content-eks-aws-cli-create-kubeconfig) +- Аутенфикация EKS интегрирована с ролями/разрешениями IAM. AWS CLI содержит интегрированную под-комманду для генерации токенов аутенфикации. [2](#user-content-eks-aws-cli-get-token) Раньше это делалось с использользованием специального плагина для kubectl называемого [aws-iam-authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator) (ранее heptio-authenticator-aws). +- EKS предоставляет [Calico](https://docs.aws.amazon.com/eks/latest/userguide/calico.html) от Tigera для защиты рабочих нагрузок в кластере используя сетевые политики Kubernetes. + +### Советы по EKS +- Множество кластеров поддержиивается при использвовании разных файлов kubeconfig. +- У AWS есть [руководство по быстрому старту Kubernetes ](https://aws.amazon.com/quickstart/architecture/heptio-kubernetes/) разработанное совместно с Heptio. + +### Альтернативы EKS и привязки +- [ECS](#ecs): это нативная платформа оркестрации контейнеров в Amazon, выпущенная в 2014 году. Если вы не используете контейнеры на сегодняшний день и хотите начать, ECS - отличный продукт. +- [Kubernetes](https://kubernetes.io): Обширная контейнерная платформа. Доступна как сервис на [Google Cloud](https://cloud.google.com/container-engine/), [AWS](https://aws.amazon.com/eks/), [Digital Ocean](https://www.digitalocean.com/products/kubernetes/) и [Azure](https://azure.microsoft.com/en-us/services/kubernetes-service/). +- [Nomad](https://www.nomadproject.io/): Оркестратор/Планировщик, тесно связанный со стэком Hashicorp (Consul, Vault и т.д.). + +### Ошибки и ограничения, связанные с EKS +- Конфигурации подов и сервисов могут быстро потреблять IP адреса внутри VPC. Надлежащий уход и обслуживание должны применяться, чтобы избежать истощения IP пространства. +- На текущий момент не существует интегрированного мониторинга в CloudWatch для под или сервисов EKS, таким образом вам необходимо развернуть мониторинговую систему, которая поддерживает Kubernetes, такую как Prometheus. +- Автоматическое масштабирование на основе CPU/памяти ноды ограничено, так как вы не будете знать о ожидающих сервисах/подах, которые не могут запуститься. Использование [cluster-autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) может быть полезным для масштабирования на основе использования ресурсов ноды и незапланированных под. +- [Prometheus](https://prometheus.io/) - это очень популярное мониторинговое решения для K8s, метрики и тревоги можно использовать для отсылки событий в Lambda, SQS или другое решения для действий по автоматическому масштабированию. + +### Примечания +**1**: https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html
+**2**: https://aws.amazon.com/about-aws/whats-new/2019/05/amazon-eks-simplifies-kubernetes-cluster-authentication/
+ +Fargate +------- + +### Fargate Basics +- 📒 [Homepage](https://aws.amazon.com/fargate/) ∙ [FAQ](https://aws.amazon.com/fargate/faqs/) ∙ [Pricing](https://aws.amazon.com/fargate/pricing/) +- **Fargate** allows you to manage and deploy containers without having to worry about running the underlying compute infrastructure +- Fargate serves as a new backend (in addition to the legacy EC2 backend) on which ECS and EKS tasks can be run +- Fargate and EC2 backends are called "Launch Types" +- Fargate allows you to treat containers as fundamental building blocks of your infrastructure + +### Fargate Tips +- Fargate follows a similar mindset to Lambda, which lets you focus on applications, instead of dealing with underlying infrastructure +- Fargate is supported by CloudFormation, aws-cli and ecs-cli +- Fargate tasks can be launched alongside tasks that use EC2 Launch Type +- 💸Before creating a large Fargate deployment, make sure to estimate costs and compare them against alternative solution that uses traditional EC2 deployment - Fargate prices can be several times those of equivalently-sized EC2 instances. To evaluate both solutions based on potential costs, refer to pricing for [EC2](https://aws.amazon.com/ec2/pricing/) and [Fargate](https://aws.amazon.com/fargate/pricing/). + +### Fargate Alternatives and Lock-in +- 🚪[Azure Container Instances](https://azure.microsoft.com/en-us/services/container-instances/): Available on Microsoft Azure in preview version, allows to run applications in containers without having to manage virtual machines + +### Fargate Gotchas and Limitations +- As of April 2018, Fargate is available in [multiple regions](https://aws.amazon.com/about-aws/whats-new/2018/04/aws-fargate-now-available-in-ohio--oregon--and-ireland-regions/): us-east-1, us-east-2, us-west-2, and eu-west-1 +- As of January 2019, Fargate can only be used with ECS. Support for EKS [was originally planned for 2018](https://aws.amazon.com/blogs/aws/aws-fargate/), but has yet to launch. +- The smallest resource values that can be configured for an ECS Task that uses Fargate is 0.25 vCPU and 0.5 GB of memory +- [Task storage is ephemeral. After a Fargate task stops, the storage is deleted.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-storage.html) + + +Lambda +------ + +### Lambda Basics + +- 📒 [Homepage](https://aws.amazon.com/lambda/) ∙ [Developer guide](http://docs.aws.amazon.com/lambda/latest/dg/) ∙ [FAQ](https://aws.amazon.com/lambda/faqs/) ∙ [Pricing](https://aws.amazon.com/lambda/pricing/) +- **Lambda** is AWS' serverless compute offering, allowing users to define Lambda functions in a selection of runtimes that can be invoked via a variety of triggers, including SNS notifications and API Gateway invocations. Lambda is the key service that enables ['serverless' architecture on AWS](https://aws.amazon.com/lambda/serverless-architectures-learn-more/), alongside AWS API Gateway, AWS Batch, and AWS DynamoDB. + +### Lambda Tips + +- The idea behind 'serverless' is that users don't manage provisioning, scaling, or maintenance of the physical machines that host their application code. With Lambda, the machine that actually executes the user-defined function is abstracted as a ['container'](http://docs.aws.amazon.com/lambda/latest/dg/lambda-introduction.html). When defining a Lambda function, users are able to declare the amount of memory available to the function, which directly affects the physical hardware specification of the Lambda container. +- Changing the amount of memory available to your Lambda functions also affects the amount of [CPU power](https://aws.amazon.com/lambda/faqs/) available to it. +- While AWS does not offer hard guarantees around container reuse, in general it can be expected that an unaltered Lambda function will reuse a warm (previously used) container if called shortly after another invocation. Users can use this as a way to optimize their functions by smartly caching application data on initialization. +- A Lambda that hasn't been invoked in some time may not have any warm containers left. In this case, the Lambda system will have to load and initialize the Lambda code in a 'cold start' scenario, which can add significant latency to Lambda invocations. +- There are a few strategies to avoiding or mitigating cold starts, including keeping containers warm by periodic triggering and favoring lightweight runtimes such as Node as opposed to Java. +- Lambda is integrated with AWS CloudWatch and provides a logger at runtime that publishes CloudWatch events. +- Lambda offers out-of-the-box opt-in support for AWS X-Ray. X-Ray can help users diagnose Lambda issues by offering in-depth analysis of their Lambda's execution flow. This is especially useful when investigating issues calling other AWS services as X-Ray gives you a detailed and easy-to-parse [visualization of the call graph](http://docs.aws.amazon.com/lambda/latest/dg/lambda-x-ray.html#lambda-service-map). +- Using [timed CloudWatch events](http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html#CronExpressions), users can use Lambda to run periodic jobs in a cron-like manner. +- Events sent to Lambda that fail processing can be managed using a [Dead Letter Queue (DLQ) in SQS.](http://docs.aws.amazon.com/lambda/latest/dg/dlq.html) +- More on serverless: + - [Martin Fowler's thoughts.](http://martinfowler.com/articles/serverless.html) + - [AWS Serverless Application Model (SAM)](https://github.com/awslabs/serverless-application-model), a simplification built on top of CloudFormation that can help to define, manage, and deploy serverless applications using Lambda. + - [Serverless](https://github.com/serverless/serverless), one of the most popular frameworks for building serverless applications using AWS Lambda and other serverless compute options. + - [Other helpful frameworks.](https://github.com/anaibol/awesome-serverless#frameworks) + +### Lambda Alternatives and Lock-in + +- 🚪Other clouds offer similar services with different names, including [Google Cloud Functions](https://cloud.google.com/functions/), [Azure Functions](https://azure.microsoft.com/en-us/services/functions/), and [IBM OpenWhisk](http://www.ibm.com/cloud-computing/bluemix/openwhisk/). Also if your are running Kubernetes another Lambda alternative is [OpenFaaS](https://github.com/openfaas/faas) + +### Lambda Gotchas and Limitations + +- 🔸Testing Lambdas, locally and remotely, can be a challenge. Several tools are available to make this easier, including the officially supported [SAM Local](https://github.com/awslabs/aws-sam-local). +- 🔸Managing lots of Lambda functions is a workflow challenge, and tooling to manage Lambda deployments is still immature. +- 🔸AWS’ official workflow around managing function [versioning and aliases](https://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html) is painful. One option is to avoid Lambda versioning by abstracting your deployment workflow outside of Lambda. One way this can be accomplished is by deploying your application in successive stages, with a distinct AWS account per stage, where each account only needs to be aware of the latest version, and rollbacks and updates are handled by external tooling. +- 🔸As of Oct 2017, the minimum charge for a Lambda invocation is 100ms, so there is no cost-benefit to reducing your run time below that. +- 🔸While adding/removing S3 buckets as triggers for Lambda function, this error may occur: "There was an error creating the trigger: Configuration is ambiguously defined. Cannot have overlapping suffixes in two rules if the prefixes are overlapping for the same event type." In this case, you can manually remove the Lambda event in the "Events" tab in the "Properties" section of the S3 bucket. +- 🔸Managing the size of your deployment artifact can be a challenge, especially if using Java. Options to mitigate this include [proguard](https://www.guardsquare.com/en/proguard) and loading dependencies at runtime into /tmp. +- When using DynamoDB as a trigger for your Lambda functions, this error may occur: "PROBLEM: internal Lambda error. Please contact Lambda customer support." This usually just means that Lambda can't detect anything in the DynamoDB stream within the last 48 hours. If the issue persists, deleting and recreating your trigger may help. +- 🔸If your lambda needs access to resources in a VPC (for example ElastiCache or RDS), it will need to be deployed within it. This will increase cold-start times as an Elastic Network Interface (ENI) will have to be registered within the VPC for each concurrent function. AWS also has a relatively low initial limit (350) on the number ENI's that can be created within an VPC, however this can be increased to the 1000s if a good case is made to AWS support. +- 🔸 Lambda has several [**resource limits**](http://docs.aws.amazon.com/lambda/latest/dg/limits.html) as of 2017-06: + - A **6MB** request or response payload size. + - A **50 MB** limit on the compressed .zip/.jar file deployment package size. + - A **250 MB** limit on the code/dependencies in the package before compression. + - A **500 MB** limit on local storage in /tmp. + +### Lambda Code Samples + +- [Fan-out](https://github.com/awslabs/aws-lambda-fanout) is an example of using Lambda to “fan-out” or copy data from one service, in this case Kinesis, to multiple other AWS data services. Destinations for fan-out data in the sample include IoT, SQS and more. +- This [AWS limit monitor using Lambdas](https://github.com/awslabs/aws-limit-monitor) shows use of multiple Lambdas for monitoring. +- This [Lambda ECS Worker Pattern](https://github.com/awslabs/lambda-ecs-worker-pattern) shows use of Lambda in a workflow where data from S3 is picked up by the Lambda, pushed to a queue, then sent to ECS for more processing. +- The [Secure Pet Store](https://github.com/awslabs/api-gateway-secure-pet-store) is a sample Java application which uses Lambda and API Gateway with Cognito (for user identity). +- [aws-lambda-list](https://github.com/unixorn/aws-lambda-list) is a list of "hopefully useful AWS lambdas and lambda-related resources". Quite a few code samples here; as usual, not guaranteed tested. Caveat Emptor. + +🚧 [*Please help expand this incomplete section.*](CONTRIBUTING.md) + +API Gateway +----------- + +### Основы API Gateway + +- 📒 [Домашняя страница](https://aws.amazon.com/api-gateway/) ∙ [Руководство разработчика](http://docs.aws.amazon.com/apigateway/latest/developerguide/) ∙ [ЧаВо](https://aws.amazon.com/api-gateway/faqs/) ∙ [Расценки](https://aws.amazon.com/api-gateway/pricing/) +- **API Gateway** предоставляет масштабируемый, защищенный интерфейс для сервисных API, и может работать с Lambda, Elastic Beanstalk, или обычными EC2 сервисами. +- Позволяет развертывать “serverless” приложения созданные в Lambda. +- 🔸Переключение между развертываниями после обновлений может быть сложным. Отстутвуют встроенные механизмы по переносу одного доменного имени с одного API Gateway на другой. Поэтому может потребоваться создать дополнительный промежуточный слой (даже другой API-Gateway), чтобы обеспечить плавный переход от одного развертывания к другому. + +### Альтернативы API Gateway и привязки + +- [Kong](https://getkong.org) это локальный шлюз API и микросервисов с открытым исходным кодом на nginx с Lua. Kong расширяем с помощью “плагинов”. +- [Tyk](https://tyk.io) это шлюз API написанный на год Go и доступен в облачных, частных или гибридных средах. + +### Советы по API Gateway + +- 🔹До ноября 2011 года, вы могли посылать и принимать данные только открытым текстом(таким образом бинарные данные было необхоидмо кодировать в base64), но бинарные данные [теперь](https://aws.amazon.com/about-aws/whats-new/2016/11/binary-data-now-supported-by-api-gateway/) поддерживаются. +- API Gateway поддерживает спецификацию OpenApi (также известную, как [Swagger](https://swagger.io/)). Это позволяет вам описывать ваш API без учета языка и использовать различные инструменты для генерации кода, поддерживающего ваш API. +- Создание клиентов чрезвычайно просто - либо через консоль AWS, либо с помощью API get-sdk. +- API Gateway интегрируется с CloudWatch из-коробки, позволяя легко логировать запросы и ответы. + - Обратите внимание, что если ваш запрос или ответ слишком велики, CloudWatch будет обрезать лог. Для полного логирования запросов/ответов, убедитесь что вы это сделали в ваших интеграциях (например Lambda). + - Хорошей практикой при вызове API-интерфейсов API Gateway является регистрация идентификатора запроса на клиенте. Позже вы сможете сослаться на эти идентификаторы запросов в CloudWatch для упрощения отслеживания и отладки. +- Есть множество способов обезопасить свои API, включая встроенную поддержку [AWS Cognito](http://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html). Для большинства случаев применения, Cognito самый простейший путь аутенфицировать пользователей. + - Хотя вы можете использовать собственное решения используя [собственную службу авторизации](http://docs.aws.amazon.com/apigateway/latest/developerguide/use-custom-authorizer.html), обычно в этой роли выступает Lambda, где вы определяете может ли быть принят запрос или нет. +- Хотя API Gateway хорошо подходит для разработки в стиле REST, вполне разумно также реализовать API-интерфейс в стиле RPC в API Gateway. В зависимости от случаев применения, это может привести к значительному упрощению структуры API и к более плавной работе клиентов. + - API в стиле RPC особенно полезны при разработке сервисов, которые находятся глубже в стеке и не предоставляют контент непосредственно пользователям. + + +### Ошибки и ограничения, связанные с API Gateway + +- 🔸API Gateway поддерживает только шифрованные (https) входные точки, и не поддерживает незашифрованный HTTP. (Это возможно хорошая штука.) +- 🔸API Gateway не поддерживает мульти-регионное развертывание для высокой доступности. Это сервис, который разворачивается в одном регионе, но поставляется с глобальной точкой входа, которыа обслуживаются AWS edge locations (как и CloudFront distribution). Вы не можете иметь несколько API Gateway с одним именем хоста в разных регионах AWS и использовать Route 53 для распределения траффика. Больше информации [в этом сообщении на форуме](https://forums.aws.amazon.com/thread.jspa?messageID=735342򳡮). +- 🔸Таймаут интеграции: Любые способы интеграции (например Lambda, HTTP) в API Gateway имеют таймауты, как описано [здесь](http://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-limits). В отличии от некоторых лимитов, эти таймауты не могут быть увеличены. +- 🔸API Gateway возвращает статус код 504 в случае любой сетевой или низкоуровневой транспортной проблемы. Когда это происходит, вы можете увидеть сообщение в логах CloudWatch для данного запроса, которое включает в себя сообщение: `Execution failed due to an internal error`. Одной из возможных причин этой ошибки является то, что, несмотря на то, что ваш внутренний(бэкенд) сервер работает и работает, он может делать что-то за пределами спецификации HTTP (например, не отправлять правильно сформированные фрагментированные сообщения). Вы можете протестировать это, ткнувшись в ваш внутренний сервер(бэкенд) напрямую, командой `curl --raw -S -i ` и посмотреть, на что он ругается. +- 🔸Поддержка AWS X-Ray существует, но неудобна в использовании. Если у вас есть другие сервисы AWS, вызывающие API Gateway, ваша трассировка на этом, похоже, закончится. API Gateway также не будет виден, как нода в карте сервисов. [Больше информации тут](http://docs.aws.amazon.com/xray/latest/devguide/xray-services-apigateway.html). +- 🔸Будьте осторожны, используя функцию экспорта. Получившийся в результате шаблон Swagger часто не полный и не интегрируется нормально с расширениями Swagger для таких вещей, как CORS. +- 🔸Многие изменения в ресурсах API Gateway необходимо 'развернуть' с помощью консоли или вызова API. К сожалению, API Gateway ужасен в оповещении пользователя, когда изменения размещаются для развертывания и какие изменения требуют развертывания. Если вы что-то изменили в своем API, а изменения не вступили в силу, есть вариант, что вам просто нужно его развернуть. + - В частности, когда разворачиваешь API Gateway как часть стэка CloudFormation, изменения автоматически не развернутся, пока разворачиваемый ресурс сам не будет изменен. Вы можете обойти эту проблему, всегда меняя ресурс развертывания в обновлении CloudFormation или запуская пользовательский ресурс, обеспечивающий подтверждение развертывание. + - В качестве альтернативы, используя определение [модели Serverless приложений](https://github.com/awslabs/serverless-application-model) для ресурсов API Gateway, вы всегда можете быть уверены, что API развернется во время обновления стэка, так как SAM будет генерировать новое развертывание каждый раз. +- 🔸API Gateway не поддерживает вложенные параметры запроса для запросов метода. +- 🔸API Gateway ограничивает количество ресурсов 3 сотнями, как описано [здесь](http://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-limits). Это следует учитывать, когда вы начинаете использовать API Gateway как платформу, на которой ваша команда / организация развертывает на этом же API Gateway. + +🚧 [*Пожалуйста помогите дополнить этот неполный раздел*](CONTRIBUTING.md) + +Step Functions +------ + +### Step Functions Basics +- 📒 [Homepage](https://aws.amazon.com/step-functions/) ∙ [Developer guide](http://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) ∙ [FAQ](https://aws.amazon.com/step-functions/faqs/) ∙ [Pricing](https://aws.amazon.com/step-functions/pricing/) +- **Step Functions** is AWS’ way to create state machines that manage a serverless workflow. + +### Step Functions Tips +- A variety of structures are supported including branching, parallel operations and waits +- [Tasks](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-tasks.html) represent the real work nodes and are frequently Lambda functions, but can be [Activities](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-activities.html) which are externally driven tasks implemented any way you like. +- State machines have [data](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-state-machine-data.html) that "flows" through the steps and can be modified and added to as the state machine executes. +- It's best if your tasks are idempotent, in part because you may want to re-run the state machine with the same input data during debugging +- The AWS Console facilitates your examining the execution state at various steps. + - The console lets you do this with a few steps: + - select the "input" tab from the failed execution + - copy the input data (JSON) + - select the state machine name in the breadcrumbs + - start a new execution, pasting the input data you copied previously + +### Step Functions Gotchas and Limitations +- Step Functions are free tier eligible up to an initial 4000 transitions per month. Thereafter, the charge is $0.025 per 1000 state transitions. +- You can have many, simultaneous, executions, but be aware of lambda throttling limits. This has been per-account, pre-region, but recently became settable per-lambda. +- Step Function executions are limited to 25,000 events. Each step creates multiple events. This means that [iterating a loop using Lambda](https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-create-iterate-pattern-section.html) is limited to an iteration count of around 3000 before needing to [continue as a new execution](https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-continue-new.html). + +Route 53 +-------- + +### Route 53 Basics + +- 📒 [Homepage](https://aws.amazon.com/route53/) ∙ [Developer guide](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) ∙ [FAQ](https://aws.amazon.com/route53/faqs/) ∙ [Pricing](https://aws.amazon.com/route53/pricing/) +- **Route 53** is AWS’ DNS service. + +### Route 53 Alternatives and Lock-In + +- Historically, AWS was slow to penetrate the DNS market (as it is often driven by perceived reliability and long-term vendor relationships) but Route 53 has matured and [is becoming the standard option](https://www.datanyze.com/market-share/dns/) for many companies. Route 53 is cheap by historic DNS standards, as it has a fairly large global network with geographic DNS and other formerly “premium” features. It’s convenient if you are already using AWS. +- ⛓Generally you don’t get locked into a DNS provider for simple use cases, but increasingly become tied in once you use specific features like geographic routing or Route 53’s alias records. +- 🚪Many alternative DNS providers exist, ranging from long-standing premium brands like [UltraDNS](https://www.neustar.biz/services/dns-services) and [Dyn](http://dyn.com/managed-dns/) to less well known, more modestly priced brands like [DNSMadeEasy](http://www.dnsmadeeasy.com/). Most DNS experts will tell you that the market is opaque enough that reliability and performance don’t really correlate well with price. +- ⏱Route 53 is usually somewhere in the middle of the pack on performance tests, e.g. the [SolveDNS reports](http://www.solvedns.com/dns-comparison/). + +### Route 53 Tips + +- 🔹Know about Route 53’s “alias” records: + - Route 53 supports all the standard DNS record types, but note that [**alias resource record sets**](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) are not standard part of DNS, but a specific Route 53 feature. (It’s available from other DNS providers too, but each provider has a different name for it.) + - Aliases are like an internal name (a bit like a CNAME) that is resolved internally on the server side. For example, traditionally you could have a CNAME to the DNS name of a CLB or ALB, but it’s often better to make an alias to the same load balancer. The effect is the same, but in the latter case, externally, all a client sees is the target the record points to. + - It’s often wise to use alias record as an alternative to CNAMEs, since they can be updated instantly with an API call, without worrying about DNS propagation. + - You can use them for CLBs/ALBs or any other resource where AWS supports it. + - Somewhat confusingly, you can have CNAME and A aliases, depending on the type of the target. + - Because aliases are extensions to regular DNS records, if exported, the output [zone file](https://en.wikipedia.org/wiki/Zone_file) will have additional non-standard “ALIAS” lines in it. +- [**Latency-based routing**](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-latency) allows users around the globe to be automatically directed to the nearest AWS region where you are running, so that latency is reduced. +- Understand that domain registration and DNS management (hosted zones) are two separate Route 53 services. When you buy/transfer a domain, Route 53 automatically assigns four name servers to it (e.g. ns-2.awsdns-00.com). Route 53 also offers to automatically create a hosted zone for DNS management, but you are not required do your DNS management in the same account or even in Route 53; you just need to create an NS record pointing to the servers assigned to your domain in Route 53. + - One use case would be to put your domain registration (very mission critical) in a [bastion account](https://cloudonaut.io/your-single-aws-account-is-a-serious-risk/) while managing the hosted zones within another account which is accessible by your applications. + +### Route 53 Gotchas and Limitations +- 🔸Private Hosted Zone will only respond to DNS queries that originate from within a VPC. As a result Route53 will not respond to request made via a VPN or Direct connect. To get around this you will need to implement [Hybrid Cloud DNS Solutions](https://d1.awsstatic.com/whitepapers/hybrid-cloud-dns-options-for-vpc.pdf) or use the Simple AD provided IP addresses to query the hosted zone. + + +CloudFormation +-------------- + +### Основы CloudFormation + +- 📒 [Домашняя страница](https://aws.amazon.com/cloudformation/) ∙ [Руководство разработчика](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/) ∙ [ЧаВо](https://aws.amazon.com/cloudformation/faqs/) ∙ [Расценки](https://aws.amazon.com/cloudformation/pricing/), использование Cloudformation дополнительно не оплачивается. +- **CloudFormation** позволяет вам управлять наборами ресурсов из сервисов AWS сгруппированными, в **[стэки(stacks)](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3917)**. CloudFormation позволяет вам описывать эти стэки файлами шаблонов используя [JSON](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html#aws-properties-ec2-instance-syntax.json) или [YAML](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html#aws-properties-ec2-instance-syntax.yaml). CloudFormation вляется одним из основных сервисов, лежащих в основе применяемых в AWS [принципов инфраструктура, как код](https://d0.awsstatic.com/whitepapers/DevOps/infrastructure-as-code.pdf) и является критичной, в целях обеспечения повторяющихся и целостных развертываний инфраструктуры. +- 💸CloudFormation сам по себе [дополнительно не оплачивается](https://aws.amazon.com/cloudformation/pricing/); вы платите только за использованные ресурсы. + +### Альтернативы CloudFormation и привязки + +- Hashicorp’s [Terraform](https://www.terraform.io/intro/vs/cloudformation.html) - это сторонняя альтернатива, которая птакже может поддерживать другие облачные платформы/провайдеров, включая [Azure](https://www.terraform.io/docs/providers/azure/) и [OpenStack](https://www.terraform.io/docs/providers/openstack/). +- 🔸Некоторые функции AWS могут быть недоступны в Terraform (например, ElastiCache с несколькими AZ с использованием Redis), и вам, возможно, придется прибегнуть к встроенным шаблонам CloudFormation. +- [Pulumi](https://www.pulumi.com/) позволяет командам определять и создавать собственную облачную инфраструктуру, как код в любом облаке на любом языке. От контейнеров до serverless, от Kubernetes до инфраструктуры. + +### Советы по CloudFormation + +- Проверяйте ваш стэк в другом аккаунте AWS. CloudFormation действительно хорош, когда необходимо произвести множество развертываний одного стэка в различных регионах и аккаунтах AWS. Обычной практикой является последовательное развертывание стэков, и в результат успешного окончания всех стадий - перевод в боевую(продуктивную) среду. +- Избегайте ситуаций, когда синтаксические ошибки будут поедать ваше время во время развертывания, путем запуска `validate-template`. +- CloudFormation иногда медленно обновляется, и некоторые новые сервисы(а также новые возможности старых сервисов) не сразу же можно описать в шаблоне. Если вам необходимо развернуть ресурс или функцию, которая пока не поддерживается шаблоном, CloudFormation позволяет запускать произвольный код(используя [Lambda](#lambda)) во время создания или обновления стэка через [собственные ресурсы(custom resources)](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html). +- Собственные ресурсы превращают CloudFormation в, по-настоящему, мощный инструмент,поскольку вы можете довольно легко выполнять всевозможные полезные действия, такие как тесты работоспособности, первоначальная настройка таблиц Dynamo или S3, очистка старых журналов CloudWatch и т. д. + - Для написания собственных ресурсов на Java, [cfnresponse](https://github.com/SunRun/cfn-response-java) весьма сподручен. + - Для написания собственных ресурсов на Javascript, AWS предоставляет хороший справочник в [документации.](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/walkthrough-custom-resources-lambda-lookup-amiids.html) +- CloudFormation предлагает визуальный [дизайнер шаблонов](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/working-with-templates-cfn-designer-walkthrough-createbasicwebserver.html) который может быть очень полезен, пока вы осваиваетесь с синтаксисом шаблона. +- Посредством использования [StackSets](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html), пользователи могут описать и развернуть целостное продуктовое приложение, состоящее из множества стэков (один сервис на стэк) в одном шаблоне CloudFormation. +- Если вы разрабатываете serverless приложение(например, используя Lambda, API Gateway) CloudFormation предлагает упрощенный формат шаблона, называемый [SAM](https://github.com/awslabs/serverless-application-model). +- ❗Используйте ограничивающую [политику стэка(stack policy)](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/protect-stack-resources.html)! Без нее вы можете случайно удалить живые производственные ресурсы, что может привести к длительному простою. +- ❗Включите [защиту от отключения(termination protection)](https://aws.amazon.com/about-aws/whats-new/2017/09/aws-cloudformation-provides-stack-termination-protection/) на всех ваших стэках, чтобы избежать дорогостоящих инцидентов! +- [Справочник по шаблонам](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-reference.html) CloudFormation - незаменим, когда разбираешься, что возможно, а что нет в CloudFormation. +- [Troposphere](https://github.com/cloudtools/troposphere) - Библиотека для языка Python, которая облегчает создание шаблонов CloudFormation. + - На текущий момент поддерживаются типы ресурсов [AWS](https://github.com/cloudtools/troposphere#currently-supported-aws-resource-types) и [OpenStack](https://github.com/cloudtools/troposphere#currently-supported-openstack-resource-types). + - Troposphere пытается поддерживать все ресурсы, которые можно описать в шаблонах CloudFormation. + - Встроена проверка на [ошибки](https://github.com/cloudtools/troposphere#examples-of-the-error-checking-full-tracebacks-removed-for-clarity). + - [awacs](https://github.com/cloudtools/awacs) является рекомендуемым дополнением, которое позволяет генерировать политику доступа AWS в формате JSON путем написания кода на Python. +- [stacker](http://stacker.readthedocs.io/en/latest/) - приложение, написанное на Python, которое облегчает описание, конфигурацию, оркестрацию и управление зависимостями в стэках CloudFormation средах описываемых множеством пользователей. +- Если вы создаете различные стэки с одинаковыми слоями, будет полезным создать отдельные шаблоны для различных слоев, которые вы потом можете использовать путем использования [AWS::CloudFormation::Stack](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-stack.html). +- 🔸Избегайте жесткого определения параметров ресурса, которые могут измениться. Максимально используйте параметры стека и используйте значения параметров по умолчанию. +- 🔹До [2016 года](https://aws.amazon.com/about-aws/whats-new/2016/09/aws-cloudformation-introduces-yaml-template-support-and-cross-stack-references/), CloudFormation использовал только неудобный формат JSON, который затруднял как чтение, так и отладку. Чтобы эффективно с ним работать, обычно привлекались дополнительные инструменты, включая конвертацию в YAML, но теперь [YAML поддерживается напрямую](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-formats.html). +- По возможности экспортируйте соответствующие [физические идентификаторы](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-name.html) из ваших стэков путем описания [выходных данных(Outputs) в вашем шаблоне CloudFormation](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html). Это имена назначенные созданным ресурсам. Выходные данные могут быть получены от вызова API `DescribeStack`, и быть импортированы в другие стэки, как часть [недавно добавленных](https://aws.amazon.com/about-aws/whats-new/2016/09/aws-cloudformation-introduces-yaml-template-support-and-cross-stack-references/) [кросс-стековых ссылок](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/walkthrough-crossstackref.html). + -Обратите внимание, что импорт выходных данных из одного стэка в другой, создает жесткую зависимость, отслеживаемую CloudFormation. Вы не сможете удалить стэк, поставляющий выходные данные, пока не будут удалены стэки, использующие эти данные в качестве входных. +- CloudFormation может быть настроен для [отсылки оповещений через SNS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-add-tags.html) относительно изменений состоянияЮ включая программную поддержку ситуаций, когда сборка стэка заканчивается неудачно, простое почтовое сообщение с оповещением будет отправлено, чтобы соответствующие люди были проинформированы. +- CloudFormation позволяет использовать[**условия**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/conditions-section-structure.html) во время создания стэка. + - Один из распространенных способов использования этой возможности - поддержка шаблонов CloudFormation для нескольких сред - путем их настройки для использования операторов if-else со значением [переданного параметра] (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) (например, “env”), специфичные для среды значения для таких вещей, как идентификаторы VPC, идентификаторы SecurityGroup и имена AMI, можно передавать в повторно используемые универсальные шаблоны. +- **Храните ваши шаблоны CloudFormation в системе контроля версий!** В облаке приложение - это комбинация написанного кода и инфраструктуры, в которой оно работает. Путем хранения **и того и того** в системе контроля версий, всегда легко откатиться на рабочее состояние. +- Избегайте явного именования ваших ресурсов (например, таблиц в DynamoDB). При развертывании нескольких стеков в одной учетной записи AWS эти имена могут вступать в противоречие, что может замедлить тестирование. Предпочитайте использование ссылок на ресурсы вместо явных имен. +- Для тех вещей, которые не должны быть когда-либо удалены, вы можете выставить явную политику удаления(DeletionPolicy) на ресурсы, это предотвратит удаление ресурсов даже в том случае, если сам CloudFormation стэк удален. Это полезно для любого, кто поддерживает такие ресурсы, где пересоздание может стоить больших трудозатрат, например таблицы DynamoDB, или вещи, которые смотрят в окружающий мир, например API API Gateway. + +### Ошибки и ограничения, связанные с CloudFormation + +- 🔸Стек CloudFormation может оказаться в самых разных состояниях. Сообщения об ошибках, как правило, малоинформативны, и часто для получения рабочего шаблона требуется несколько циклов наблюдения-настройки-повторного развертывания. Внутренний конечный автомат для [всех меняющихся состояний](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-describing-stacks.html) чрезвычайно непрозрачен. +- 🔸Некоторые межрегиональные операции невозможны в CloudFormation без использования собственного ресурса, например такие как [межрегиональная подписка SNS](https://github.com/serverless/serverless/issues/3676). +- 🔸Хотя использование ресурсов, созданных вручную, совместно с ресурсами, созданными CloudFormation, нецелесообразно, иногда это неизбежно. Если это возможно, переведите ВСЁ управление ресурсами на шаблоны CloudFormation и предоставьте доступ только для чтения в консоль. +- ❗Изменения в ресурсах входящих в стэк, сделанные за пределами CloudFormation может потенциально привести к зависанию стэка в режиме UPDATE\_ROLLBACK\_FAILED. Стэки в таком состоянии могут быть восстановлены путем использования [команды continue-update-rollback](https://aws.amazon.com/blogs/devops/continue-rolling-back-an-update-for-aws-cloudformation-stacks-in-the-update_rollback_failed-state/). Эта команда может быть вызвана из консоли или из CLI. Параметр [--resources-to-skip](http://docs.aws.amazon.com/cli/latest/reference/cloudformation/continue-update-rollback.html), использующийся в CLI может быть полезен, если команда continue-update-rollback выполнилась неудачно. Новая функция [Drift Detection](https://aws.amazon.com/blogs/aws/new-cloudformation-drift-detection/) может быть использована для определения внешних изменений в стэке. +- 🔸CloudFormation - полезен, но сложен и имеет множество болевых точек. Многие компании находят альтернативные решения, но многие компании используют его, но только со значительными дополнительными инструментами. +- 🔸CloudFormation может быть очень медленным, в особенности для таких вещей, как раздачи CloudFront и записи CNAME в Route53. +- 🔸Сложно собрать хорошую конфигурацию CloudFormation с текущего состояния. AWS предлагает [определенный трюк, чтобы сделать это](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-cloudformer.html), но он очень кривой. + - CloudFormer также не обновлялся годами (по состоянию на октябрь 2017 года), не поддерживает шаблонирование многих новых сервисов, и не полностью описывает даже текущие сервисы, потому что они были обновлены. Как пример, таблицы DynamoDB описанные в CloudFormer не содержат определений TTL или конфигурацию автоматического масштабирования. Существует сторонняя версия этого инструмента с большим количеством поддерживаемых ресурсов, именуемая [Former2](https://github.com/iann0036/former2). +- 🔸Многие пользователи вообще не используют CloudFormation из-за его ограничений или из-за того, что считают другие решения более предпочтительными. Часто есть другие способы достижения тех же целей, такие как управляемые вами скрипты (Boto, Bash, Ansible и т.д.), которые создают инфраструктуру, или решения на основе Docker. ([Convox](https://convox.com/)). +- 🔸Развертывание больших стэков (например, большого количества ресурсов) может быть проблематичным по причине неинтуитивных лимитов API. Например, в API Gateway `CreateDeployment` API имеет лимит по умолчанию - [3 запроса в минуту](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html) по состоянию на 1/12/2018. Этот предел легко превышается даже в стеках CloudFormation среднего размера. Создание оповещений CloudWatch другой часто превышаемый лимит (`PutMetricAlarm`, 3 tps по состоянию на 1/12/2018), особенно когда создается много политик масштабирования для DynamoDB. Одним из путей обхода этого лимита является включение условия 'DependsOn' в цепочку создания ресурса в шаблоне CloudFormation. +- 🔸Создание/удаление стэков может быть не идеально чистым. Некоторые ресурсы оставляют после себя следы в вашем AWS аккаунте даже после удаления. Например, Lambda оставляется после себя лог группы в CloudWatch, которые никогда не истекают. + +VPCs, Network Security, and Security Groups +------------------------------------------- + +### VPC Basics + +- 📒 [Homepage](https://aws.amazon.com/vpc/) ∙ [User guide](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide) ∙ [FAQ](https://aws.amazon.com/vpc/faqs/) ∙ [Security groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) ∙ [Pricing](https://aws.amazon.com/vpc/pricing/) +- **VPC** (Virtual Private Cloud) is the virtualized networking layer of your AWS systems. +- Most AWS users should have a basic understanding of VPC concepts, but few need to get into all the details. VPC configurations can be trivial or extremely complex, depending on the extent of your network and security needs. +- All modern AWS accounts (those created [after 2013-12-04](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html)) are “EC2-VPC” accounts that support VPCs, and all instances will be in a default VPC. Older accounts may still be using “EC2-Classic” mode. Some features don’t work without VPCs, so you probably will want to [migrate](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html). + +### VPC and Network Security Tips + +- ❗**Security groups** are your first line of defense for your servers. Be extremely restrictive of what ports are open to all incoming connections. In general, if you use CLBs, ALBs or other load balancing, the only ports that need to be open to incoming traffic would be port 22 and whatever port your application uses. Security groups access policy is 'deny by default'. +- **Port hygiene:** A good habit is to pick unique ports within an unusual range for each different kind of production service. For example, your web frontend might use 3010, your backend services 3020 and 3021, and your Postgres instances the usual 5432. Then make sure you have fine-grained security groups for each set of servers. This makes you disciplined about listing out your services, but also is more error-proof. For example, should you accidentally have an extra Apache server running on the default port 80 on a backend server, it will not be exposed. +- **Migrating from Classic**: For migrating from older EC2-Classic deployments to modern EC2-VPC setup, [this article](http://blog.kiip.me/engineering/ec2-to-vpc-executing-a-zero-downtime-migration/) may be of help. + - You can [migrate Elastic IPs between EC2-Classic and EC2-VPC](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-eip-migration). +- For basic AWS use, one default VPC may be sufficient. But as you scale up, you should consider mapping out network topology more thoroughly. A good overview of best practices is [here](http://blog.flux7.com/blogs/aws/vpc-best-configuration-practices). +- Consider controlling access to you private AWS resources through a [VPN](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpn-connections.html). + - You get better visibility into and control of connection and connection attempts. + - You expose a smaller surface area for attack compared to exposing separate (potentially authenticated) services over the public internet. + - e.g. A bug in the YAML parser used by the Ruby on Rails admin site is much less serious when the admin site is only visible to the private network and accessed through VPN. + - Another common pattern (especially as deployments get larger, security or regulatory requirements get more stringent, or team sizes increase) is to provide a [bastion host](https://www.pandastrike.com/posts/20141113-bastion-hosts) behind a VPN through which all SSH connections need to transit. + - For a cheap VPN to access private AWS resources, consider using a point-to-site software VPN such as [OpenVPN](https://openvpn.net/). It can either be installed using the [official AMI](https://docs.openvpn.net/how-to-tutorialsguides/virtual-platforms/amazon-ec2-appliance-ami-quick-start-guide/), though you are limited to 2 concurrent users on the free license, or it can be installed using the openvpn package on linux. The linux package allows for unlimited concurrent users but the installation is less straightforward. This [OpenVPN installer script](https://github.com/Nyr/openvpn-install) can help you install it and add client keys easily. +- 🔹Consider using other security groups as sources for security group rules instead of using CIDRs — that way, all hosts in the source security group and only hosts in that security group are allowed access. This is a much more dynamic and secure way of managing security group rules. +- **VPC Flow Logs** allow you to monitor the network traffic to, from, and within your VPC. Logs are stored in CloudWatch Logs groups, and can be used for security monitoring (with third party tools), performance evaluation, and forensic investigation. + - See the [VPC Flow Logs User Guide](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html) for basic information. + - See the [flowlogs-reader](https://github.com/obsrvbl/flowlogs-reader) CLI tool and Python library to retrieve and work with VPC Flow Logs. +- **IPv6** [is available in VPC](https://aws.amazon.com/blogs/aws/new-ipv6-support-for-ec2-instances-in-virtual-private-clouds/). Along with this announcement came the introduction of the [Egress-Only Internet Gateway](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/egress-only-internet-gateway.html). In cases where one would use NAT Gateways to enable egress-only traffic for their VPC in IPv4, one can use an Egress-Only Internet Gateway for the same purpose in IPv6. + +- Amazon provides an IPv6 CIDR block for your VPC at your request - at present you cannot implement your own IPv6 block if you happen to own one already. +- New and existing VPCs can both use IPv6. Existing VPCs will need to be configured to have an IPv6 CIDR block associated with them, just as new VPCs do. + +### PrivateLink +- 📒[Homepage](https://aws.amazon.com/privatelink/) ∙ [User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) ∙ [Pricing](https://aws.amazon.com/privatelink/pricing/) +- One of the uses for Private link is [Interface VPC Endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) deploys an ENI into your VPC and subnets which allows you direct access to the AWS API's as if the were accessible locally in your VPC without having to go out to the internet. +- Another use case would be to expose a service of your own to other accounts in AWS through a [VPC Endpoint Service](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) + +### VPC and Network Security Gotchas and Limitations +- 🔸VPCs are tied to one Region in one Account. Subnets are tied to one VPC and limited to one Availability Zone. +- 🔸Security groups are tied to one VPC. If you are utilizing infrastructure in multiple VPCs you should make sure your configuration/deployment tools take that into account. +- 🔸[VPC Endpoints](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html) are currently only available for S3 and DynamoDB. If you have a security requirement to lockdown outbound traffic from your VPC you may want to use [DNS filtering](https://aws.amazon.com/blogs/security/how-to-add-dns-filtering-to-your-nat-instance-with-squid/) to control outbound traffic to other services. +- ❗Be careful when choosing your VPC IP CIDR block: If you are going to need to make use of [ClassicLink](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-classiclink.html), make sure that your private IP range [doesn’t overlap](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-classiclink.html#classiclink-limitations) with that of EC2 Classic. +- ❗If you are going to peer VPCs, carefully consider the cost of [data transfer between VPCs](https://aws.amazon.com/vpc/faqs/#Peering_Connections), since for some workloads and integrations, this can be prohibitively expensive. +- ❗New RDS instances require a [subnet group](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.Subnets) within your VPC. If you’re using the [default VPC](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/default-vpc.html) this isn’t a concern, it will contain a subnet for each availability zone in your region. However, if you’re creating your own VPC and plan on using RDS, make sure you have at least two subnets within the VPC to act as the subnet group. +- ❗If you delete the default VPC, you can [recreate it via the CLI or the console](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/default-vpc.html#create-default-vpc). +- ❗Be careful with VPC VPN credentials! If lost or compromised, the VPN endpoint must be deleted and recreated. See the instructions for [Replacing Compromised Credentials](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html#CompromisedCredentials). +- ❗Security Groups and Route Tables apply entries separately for IPv4 and IPv6, so one must ensure they add entries for both protocols accordingly. +- 💸Managed NAT gateways are a convenient alternative to +manually managing [NAT instances](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPCNATInstance.html), but they do come at a cost per gigabyte. Consider [alternatives](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-comparison.html) if you're transferring many terabytes from private subnets to the internet. If you transfer terabytes/petabytes of data from EC2 instances in private subnets to S3, avoid the [NAT gateway data processing charge](https://aws.amazon.com/vpc/pricing/) by setting up a Gateway Type VPC Endpoint and route the traffic to/from S3 through the VPC endpoints instead of going through the NAT gateways. + +KMS +--- + +### KMS Basics + +- 📒 [Homepage](https://aws.amazon.com/kms/) ∙ [Developer guide](http://docs.aws.amazon.com/kms/latest/developerguide/) ∙ [FAQ](https://aws.amazon.com/kms/faqs/) ∙ [Pricing](https://aws.amazon.com/kms/pricing/) +- **KMS** (Key Management Service) is a secure service for creating, storing and auditing usage of cryptographic keys. +- **Service integration:** KMS [integrates with other AWS services](http://docs.aws.amazon.com/kms/latest/developerguide/service-integration.html): EBS, Elastic Transcoder, EMR, Redshift, RDS, SES, S3, WorkMail and Workspaces. +- **Encryption APIs:** The [Encrypt](http://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html) and [Decrypt API](http://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) allow you to encrypt and decrypt data on the KMS service side, never exposing the master key contents. +- **Data keys:** The [GenerateDataKey](http://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#data-keys) API generates a new key off of a master key. The data key contents are exposed to you so you can use it to encrypt and decrypt any size of data in your application layer. KMS does not store, manage or track data keys, you are responsible for this in your application. +- 🔹**Auditing:** Turn on CloudTrail to audit all KMS API events. +- **Access:** Use [key policies](http://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) and [IAM policies](http://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html) to grant different levels of KMS access. For example, you create an IAM policy that only [allows a user to encrypt and decrypt with a specific key](http://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html#iam-policy-example-encrypt-decrypt-specific-cmks). + +### KMS Tips + +- 🔹It’s very common for companies to manage keys completely via home-grown mechanisms, but it’s far preferable to use a service such as KMS from the beginning, as it encourages more secure design and improves policies and processes around managing keys. +- A good motivation and overview is in [this AWS presentation](http://www.slideshare.net/AmazonWebServices/encryption-and-key-management-in-aws). +- The cryptographic details are in [this AWS whitepaper](https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf). +- [This blog from Convox](https://convox.com/blog/encryption-at-rest) demonstrates why and how to use KMS for encryption at rest. + +### KMS Gotchas and Limitations + +- 🔸The Encrypt API only works with < 4KB of data. Larger data requires generating and managing a [data key](http://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#data-keys) in your application layer. +- 🔸KMS audit events are not available in the [CloudTrail Lookup Events API](http://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_LookupEvents.html). You need to look find them in the raw .json.gz files that CloudTrail saves in S3. +- 🔸In order to encrypt a multi-part upload to S3, the KMS Key Policy needs to allow “kms:Decrypt” and “kms:GenerateDataKey*” in addition to “kms:Encrypt”, otherwise the upload will fail with an “AccessDenied” error. +- 🔸KMS keys are region specific — they are stored and can only be used in the region in which they are created. They can't be transferred to other regions. +- 🔸KMS keys have a key policy that must grant access to something to manage the key. If you don't grant anything access to the key on creation, then you have to reach out to support to have the key policy reset [Reduce the Risk of the Key Becoming Unmanagable](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-root-enable-iam). +- 🔸If you use a key policy to grant access to IAM roles or users and then delete the user/role, recreating the user or role won't grant them permission to the key again. + + +CloudFront +---------- + +### Основы CloudFront + +- 📒 [Домашняя страница](https://aws.amazon.com/cloudfront/) ∙ [Руководство разработчика](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/) ∙ [ЧаВо](https://aws.amazon.com/cloudfront/faqs/) ∙ [Расценки](https://aws.amazon.com/cloudfront/pricing/) +- **CloudFront** это [сеть доставки контента (CDN)](https://en.wikipedia.org/wiki/Content_delivery_network) в AWS. +- Его основное назначение - снижение задержки для конечных пользователей за счет доступа к кэшируемому контенту путем размещения его в [более чем 60 глобальных выходных точках(edge location)](http://aws.amazon.com/cloudfront/details/). + +### Альтернативы CloudFront и привязки + +- 🚪Рынок CDN [сильно фрагментирован](https://www.datanyze.com/market-share/cdn/). CloudFront был создан, чтобы быть лидером, но есть много альтернатив, которые могут лучше удовлетворить конкретные потребности. + +### Советы по CloudFront + +- 🐥**IPv6** [поддерживается](https://aws.amazon.com/about-aws/whats-new/2016/10/ipv6-support-for-cloudfront-waf-and-s3-transfer-acceleration/). Это конфигурируемая настройка и она включена по умолчанию на каждой новой распределенной раздаче контента CloudFront. Поддержка IPv6 также распространяется на использование WAF с CloudFront. +- 🐥**HTTP/2** [теперь поддерживается](https://aws.amazon.com/about-aws/whats-new/2016/09/amazon-cloudfront-now-supports-http2/)! Клиенты [должны поддерживать TLS 1.2 и SNI](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesSupportedHTTPVersions). +- В то время, как в основном пользователи просматривают и скачивают контент (методы GET или HEAD), CloudFront также поддерживает ([с 2013 года0](https://aws.amazon.com/blogs/aws/amazon-cloudfront-content-uploads-post-put-other-methods/)) загрузку данных (POST, PUT, DELETE, OPTIONS, и PATCH). + - Вы должны подключить эти методы, указав [разрешенные HTTP методы](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesAllowedHTTPMethods) когда вы создаете раздачу. + - Что интересно, стоимость приема (загруженных) данных [обычно ниже](https://aws.amazon.com/cloudfront/pricing/), нежели за отправку (скачанных) данных. +- В базовой версии CloudFront [поддерживает SSL](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html) через [расширение TLS - SNI](https://en.wikipedia.org/wiki/Server_Name_Indication), которое поддерживается всеми современными веб-браузерами. Если вам необходимо поддерживать старые браузеры, вы будете вынуждены платить несколько сотен долларов за выделенные IP адреса. + - 💸⏱Помните, что инвалидация требует осторожности. CloudFront [поддерживает инвалидацию](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html) объектов с пограничных точек(edge locations), но обычно требуется какое-то количество времени на обработку запроса на всех пограничных точках и стоит $0.005 за запрос, после первой 1000 запросов. (Некоторые другие CDN работают лучше в этом плане.) +- В наши дни все должны использовать TLS, если это возможно. [Таблица Ильи Григорика](https://istlsfastyet.com/#cdn-paas) предлагает хороший обзор возможностей, касающихся производительности TLS в CloudFront. +- Альтернативой инвалидации, которой часто проще и быстрее управлять, является настройка раздачи на [кэширование со строками запросов](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html) и последующего добавления уникальных строк запросов с версиями к ресурсам, которые часто обновляются. +- ⏱Для хорошей производительности, рекомендуется [включить сжатие](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html) на раздачах CloudFront если источником выступает S3 или другой источник, которые содержит несжатый контент. + +### Ошибки и ограничения, связанные с CloudFront + +- 🔸Если вы используете S3 в качестве резервного хранилища, помните, что конечные точки для хостинга веб-сайтов и для общего S3 разные. Например: “bucketname.s3.amazonaws.com” - это конечная точка для стандартного, но, чтобы иметь поддержку перенаправления и страниц ошибок, вам необходимо использовать конечную точку для опции хостинга вебсайтов, например, “bucketname.s3-website-us-east-1.amazonaws.com” (ну или соответствующего региона). +- 🔸По умолчанию, CloudFront не пересылает заголовки 'HTTP Host:' к вашим источникам. Это может быть проблематично для вашего источника, если вы запускаете несколько сайтов, переключаемых заголовками хостов. Вы можете [включить пересылку заголовков хоста](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-headers-behavior) в настройках поведения кэширования по умолчанию. +- 🔸4096-битные SSL сертификаты: CloudFront не поддерживает 4096-битные SSL сертификаты по состоянию на 2016 год. Если вы используете SSL сертификат выпущенный третьей стороной, вам необходимо удостовериться, что он 2048-битный. Больше информации в [продолжающемся обсуждении](https://forums.aws.amazon.com/thread.jspa?threadID=148783). +- Несмотря на то, что соединения от клиентов на пограничные сервера CloudFront могут использовать IPv6, [соединение с сервером источником будет продолжать использовать IPv4.](https://aws.amazon.com/about-aws/whats-new/2016/10/ipv6-support-for-cloudfront-waf-and-s3-transfer-acceleration/) + +DirectConnect +------------- + +### Основы DirectConnect + +- 📒 [Домашняя страница](https://aws.amazon.com/directconnect/) ∙ [Руководство пользователя](http://docs.aws.amazon.com/directconnect/latest/UserGuide/) ∙ [ЧаВо](https://aws.amazon.com/directconnect/faqs/) ∙ [Расценки](https://aws.amazon.com/directconnect/pricing/) +- **Direct Connect** это частное, выделенное соединение с вашей сети в AWS. + +### Советы по DirectConnect + +- Если ваш дата-центр имеет [партнерские отношения](https://aws.amazon.com/directconnect/partners/) с AWS, установка канала крайне упрощена. +- Используйте для гарантированной производительности и целостности сети (**1 Gbps** или **10 Gbps** на канал). +- Используйте чтобы связать ко-локейшн, корпоративную или физическую сеть датацентра с вашей VPC. + - Пример: Растянуть корпоративный LDAP и/или Kerberos на инстансы EC2, запущенные в VPC. + - Пример: Сделать сервисы, которые размещены вне AWS по финансовым, нормативным или наследственным причинам, доступными из VPC. + +Redshift +-------- + +### Redshift Basics + +- 📒 [Homepage](https://aws.amazon.com/redshift/) ∙ [Developer guide](http://docs.aws.amazon.com/redshift/latest/dg/) ∙ [FAQ](https://aws.amazon.com/redshift/faqs/) ∙ [Pricing](https://aws.amazon.com/redshift/pricing/) +- **Redshift** is AWS’ managed [data warehouse](https://en.wikipedia.org/wiki/Data_warehouse) solution, which is massively parallel, scalable, and columnar. It is very widely used. It [was built](https://en.wikipedia.org/wiki/Amazon_Redshift) using [ParAccel](https://en.wikipedia.org/wiki/ParAccel) technology and exposes [Postgres](https://en.wikipedia.org/wiki/PostgreSQL)-compatible interfaces. + +### Redshift Alternatives and Lock-in + +- ⛓🚪Whatever data warehouse you select, your business will likely be locked in for a long time. Also (and not coincidentally) the data warehouse market is highly fragmented. Selecting a data warehouse is a choice to be made carefully, with research and awareness of [the market landscape](https://www.datanami.com/2016/03/14/data-warehouse-market-ripe-disruption-gartner-says/) and what [business intelligence](https://en.wikipedia.org/wiki/Business_intelligence) tools you’ll be using. + +### Redshift Tips + +- Although Redshift is mostly Postgres-compatible, its SQL dialect and performance profile are different. +- Redshift supports only [12 primitive data types](https://docs.aws.amazon.com/redshift/latest/dg/c_Supported_data_types.html). ([List of unsupported Postgres types](https://docs.aws.amazon.com/redshift/latest/dg/c_unsupported-postgresql-datatypes.html)\) +- It has a leader node and computation nodes (the leader node distributes queries to the computation ones). Note that some functions [can be executed only on the lead node.](https://docs.aws.amazon.com/redshift/latest/dg/c_SQL_functions_leader_node_only.html) +- 🔹Make sure to create a new [cluster parameter group](http://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) and option group for your database since the default parameter group does not allow dynamic configuration changes. +- Major third-party BI tools support Redshift integration (see [Quora](https://www.quora.com/Which-BI-visualisation-solution-goes-best-with-Redshift)). +- [Top 10 Performance Tuning Techniques for Amazon Redshift](https://blogs.aws.amazon.com/bigdata/post/Tx31034QG0G3ED1/Top-10-Performance-Tuning-Techniques-for-Amazon-Redshift) provides an excellent list of performance tuning techniques. +- [Amazon Redshift Utils](https://github.com/awslabs/amazon-redshift-utils) contains useful utilities, scripts and views to simplify Redshift ops. +- [VACUUM](http://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html) regularly following a significant number of deletes or updates to reclaim space and improve query performance. +- Avoid performing blanket [VACUUM](http://docs.aws.amazon.com/redshift/latest/dg/r_VACUUM_command.html) or [ANALYZE](http://docs.aws.amazon.com/redshift/latest/dg/r_ANALYZE.html) operations at a cluster level. The checks on each table to determine whether VACUUM or ANALYZE action needs to be taken is wasteful. Only perform ANALYZE and VACUUM commands on the objects that require it. Utilize the [Analyze & Vacuum Schema Utility](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AnalyzeVacuumUtility) to perform this work. The SQL to determine whether a table needs to be VACUUMed or ANALYZEd can be found in the [Schema Utility README](https://github.com/awslabs/amazon-redshift-utils/blob/master/src/AnalyzeVacuumUtility/README.md) if you wish to create your own maintenance process. +- Redshift provides various [column compression](http://docs.aws.amazon.com/redshift/latest/dg/t_Compressing_data_on_disk.html) options to optimize the stored data size. AWS strongly encourages users to use [automatic compression](http://docs.aws.amazon.com/redshift/latest/dg/c_Loading_tables_auto_compress.html) at the [COPY](https://docs.aws.amazon.com/redshift/latest/dg/r_COPY.html) stage, when Redshift uses a sample of the data being ingested to analyze the column compression options. However, automatic compression can only be applied to an empty table with no data. Therefore, make sure the initial load batch is big enough to provide Redshift with a representative sample of the data (the default sample size is 100,000 rows). +- Redshift uses columnar storage, hence it does not have indexing capabilities. You can, however, use [distribution key](http://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-best-dist-key.html) and [sortkey](http://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-sort-key.html) to improve performance. Redshift has two types of sort keys: compounding sort key and interleaved sort key. +- A compound sort key is made up of all columns listed in the sort key definition. It is most useful when you have queries with operations using the prefix of the sortkey. +- An interleaved sort key on the other hand gives equal weight to each column or a subset of columns in the sort key. So if you don't know ahead of time which column(s) you want to choose for sorting and filtering, this is a much better choice than the compound key. [Here](https://aws.amazon.com/blogs/aws/quickly-filter-data-in-amazon-redshift-using-interleaved-sorting/) is an example using interleaved sort key. +- 🔸⏱ **Distribution strategies:** Since data in Redshift is physically distributed among nodes, choosing the right data **distribution key** and [distribution style](http://docs.aws.amazon.com/redshift/latest/dg/c_choosing_dist_sort.html) is crucial for adequate query performance. There are three possible distribution style settings — **EVEN** (the default), **KEY**, or **ALL**. Use KEY to collocate join key columns for tables which are joined in queries. Use ALL to place the data in small-sized tables on all cluster nodes. + +### Redshift Gotchas and Limitations + +- ❗⏱While Redshift can handle heavy queries well, it does not scale horizontally, i.e. does not handle multiple queries in parallel. Therefore, if you expect a high parallel load, consider replicating or (if possible) sharding your data across multiple clusters. +- 🔸 The leader node, which manages communications with client programs and all communication with compute nodes, is the single point of failure. +- ⏱Although most Redshift queries parallelize well at the compute node level, certain stages are executed on the leader node, which can become the bottleneck. +- 🔹Redshift data commit transactions are very expensive and serialized at the cluster level. Therefore, consider grouping multiple mutation commands (COPY/INSERT/UPDATE) commands into a single transaction whenever possible. +- 🔹Redshift does not support multi-AZ deployments. Building multi-AZ clusters is not trivial. [Here](https://blogs.aws.amazon.com/bigdata/post/Tx13ZDHZANSX9UX/Building-Multi-AZ-or-Multi-Region-Amazon-Redshift-Clusters) is an example using Kinesis. +- 🔸Beware of storing multiple small tables in Redshift. The way Redshift tables are laid out on disk makes it impractical. The minimum space required to store a table (in MB) is nodes * slices/node * columns. For example, on a 16 node cluster an empty table with 20 columns will occupy 640MB on disk. +- ⏱ Query performance degrades significantly during data ingestion. [WLM (Workload Management)](http://docs.aws.amazon.com/redshift/latest/dg/c_workload_mngmt_classification.html) tweaks help to some extent. However, if you need consistent read performance, consider having replica clusters (at the extra cost) and swap them during update. +- ❗ Never resize a live cluster. The resize operation can take hours depending on the dataset size. In rare cases, the operation may also get stuck and you'll end up having a non-functional cluster. The safer approach is to create a new cluster from a snapshot, resize the new cluster and shut down the old one. +- 🔸Redshift has **reserved keywords** that are not present in Postgres (see full list [here](https://docs.aws.amazon.com/redshift/latest/dg/r_pg_keywords.html)). Watch out for DELTA ([Delta Encodings](https://docs.aws.amazon.com/redshift/latest/dg/c_Delta_encoding.html)). +- 🔸Redshift does not support many Postgres functions, most notably several date/time-related and aggregation functions. See the [full list here](https://docs.aws.amazon.com/redshift/latest/dg/c_unsupported-postgresql-functions.html). +- 🔸 Uniqueness, primary key, and foreign key constraints on Redshift tables are informational only and are not enforced. They are, however, used by the query optimizer to generate query plans. `NOT NULL` column constraints are enforced. See [here](https://docs.aws.amazon.com/redshift/latest/dg/t_Defining_constraints.html) for more information on defining constraints. +- 🔸Compression on sort key [can result in significant performance impact](https://aws.amazon.com/blogs/big-data/optimizing-for-star-schemas-and-interleaved-sorting-on-amazon-redshift/). So if your Redshift queries involving sort key(s) are slow, you might want to consider removing compression on a sort key. +- 🔹 [Choosing a sort key](http://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html) is very important since you can not change a table’s sort key after it is created. If you need to change the sort or distribution key of a table, you need to create a new table with the new key and move your data into it with a query like “insert into new_table select * from old_table”. +- ❗🚪 When moving data with a query that looks like “insert into x select from y”, you need to have twice as much disk space available as table “y” takes up on the cluster’s disks. Redshift first copies the data to disk and then to the new table. [Here](https://www.periscopedata.com/blog/changing-dist-and-sort-keys-in-redshift.html) is a good article on how to this for big tables. + +EMR +--- + +### EMR Basics + +- 📒 [Homepage](https://aws.amazon.com/emr/) ∙ [Release guide](http://docs.aws.amazon.com/ElasticMapReduce/latest/ReleaseGuide/) ∙ [FAQ](https://aws.amazon.com/emr/faqs/) ∙ [Pricing](https://aws.amazon.com/emr/pricing/) +- **EMR** (which used to stand for Elastic Map Reduce, but not anymore, since it now extends beyond map-reduce) is a service that offers managed deployment of [Hadoop](https://en.wikipedia.org/wiki/Apache_Hadoop), [HBase](https://en.wikipedia.org/wiki/Apache_HBase) and [Spark](https://en.wikipedia.org/wiki/Apache_Spark). It reduces the management burden of setting up and maintaining these services yourself. + +### EMR Alternatives and Lock-in + +- ⛓Most of EMR is based on open source technology that you can in principle deploy yourself. However, the job workflows and much other tooling is AWS-specific. Migrating from EMR to your own clusters is possible but not always trivial. + +### EMR Tips + +- EMR relies on many versions of Hadoop and other supporting software. Be sure to check [which versions are in use](https://docs.aws.amazon.com/ElasticMapReduce/latest/ReleaseGuide/emr-release-components.html). +- ⏱Off-the-shelf EMR and Hadoop can have significant overhead when compared with efficient processing on a single machine. If your data is small and performance matters, you may wish to consider alternatives, as [this post](http://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html) illustrates. +- Python programmers may want to take a look at Yelp’s [mrjob](https://github.com/Yelp/mrjob). +- It takes time to tune performance of EMR jobs, which is why third-party services such as [Qubole’s data service](https://www.qubole.com/mapreduce-as-a-service/) are gaining popularity as ways to improve performance or reduce costs. + +### EMR Gotchas and Limitations + +- 💸❗**EMR costs** can pile up quickly since it involves lots of instances, efficiency can be poor depending on cluster configuration and choice of workload, and accidents like hung jobs are costly. See the [section on EC2 cost management](#ec2-cost-management), especially the tips there about Spot instances. [This blog post](https://aws.amazon.com/blogs/big-data/strategies-for-reducing-your-amazon-emr-costs/) has additional tips, but was written prior to the shift to per-second billing. +- 💸 Beware of “double-dipping”. With EMR, you pay for the EC2 capacity and the service fees. In addition, EMR syncs task logs to S3, which means you pay for the storage and **PUT requests** at [S3 standard rates](https://aws.amazon.com/s3/pricing/#Request_Pricing). While the log files tend to be relatively small, every Hadoop job, depending on the size, generates thousands of log files that can quickly add up to thousands of dollars on the AWS bill. YARN’s [log aggregation](http://hortonworks.com/blog/simplifying-user-logs-management-and-access-in-yarn/) is not available on EMR. + +Kinesis Streams +--- + +### Kinesis Streams Basics + +- 📒 [Homepage](https://aws.amazon.com/kinesis/streams/) ∙ [Developer guide](https://docs.aws.amazon.com/streams/latest/dev/introduction.html) ∙ [FAQ](https://aws.amazon.com/kinesis/streams/faqs/) ∙ [Pricing](https://aws.amazon.com/kinesis/streams/pricing/) +- **Kinesis Streams** (which used to be only called Kinesis, before Kinesis Firehose and Kinesis Analytics were launched) is a service that allows you to ingest high-throughput data streams for immediate or delayed processing by other AWS services. +- Kinesis Streams’ subcomponents are called [**shards**](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html). Each shard provides 1MB/s of write capacity and 2MB/s of read capacity at a maximum of 5 reads per second. A stream can have its shards programmatically increased or decreased based on a variety of metrics. +- All records entered into a Kinesis Stream are assigned a unique sequence number as they are captured. The records in a Stream are ordered by this number, so any time-ordering is preserved. +- [This page](http://docs.aws.amazon.com/streams/latest/dev/key-concepts.html) summarizes key terms and concepts for Kinesis Streams. + +### Kinesis Streams Alternatives and Lock-in + +- 🚪 Kinesis is most closely compared to [Apache Kafka](https://kafka.apache.org/), an open-source data ingestion solution. It is possible to set up a Kafka cluster hosted on [EC2 instances](#ec2) (or any other VPS), however you are responsible for managing and maintaining both Zookeeper and the Kafka brokers in a highly available configuration. Confluent has a good blog post with their recommendations on how to do this [here](http://www.confluent.io/blog/design-and-deployment-considerations-for-deploying-apache-kafka-on-aws/), which has links on the bottom to several other blogs they have written on the subject. +- ⛓ Kinesis uses very AWS-specific APIs, so you should be aware of the potential future costs of migrating away from it, should you choose to use it. +- An application that efficiently uses Kinesis Streams will scale the number of shards up and down based on the required streaming capacity. (Note there is no direct equivalent to this with Apache Kafka.) + + +### Kinesis Streams Tips + +- The [KCL](https://docs.aws.amazon.com/streams/latest/dev/developing-consumers-with-kcl.html) (Kinesis Client Library) provides a skeleton interface for Java, Node, Python, Ruby and .NET programs to easily consume data from a Kinesis Stream. In order to start consuming data from a Stream, you only need to provide a config file to point at the correct Kinesis Stream, and functions for initialising the consumer, processing the records, and shutting down the consumer within the skeletons provided. + - The KCL uses a DynamoDB table to keep track of which records have been processed by the KCL. This ensures that all records are processed “at least once”. It is up to the developer to ensure that the program can handle doubly-processed records. + - The KCL also uses DynamoDB to keep track of other KCL “workers”. It automatically shares the available Kinesis Shards across all the workers as equally as possible. + +### Kinesis Streams Gotchas and Limitations + +- 🔸⏱ Kinesis Streams’ shards each only permit [5 reads per second](http://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html). If you are evenly distributing data across many shards, your read limit for the Stream will remain at 5 reads per second on aggregate, as each consuming application will need to check every single shard for new records. This puts a hard limit on the number of different consuming applications possible per Stream for a given maximum read latency. + - For example, if you have 5 consuming applications reading data from one Stream with any number of shards, they cannot read with a latency of less than one second, as each of the 5 consumers will need to poll *each shard* every second, reaching the cap of 5 reads per second per shard. + - [This blog post](https://brandur.org/kinesis-in-production) further discusses the performance and limitations of Kinesis in production. +- 💸 **Kinesis Streams are not included in the free tier.** Make sure if you do any experimentation with it on a personal account, you shut down the stream or it may run up unexpected costs (~$11 per shard-month.) + +Kinesis Firehose +--- + +### Kinesis Firehose Gotchas and Limitations + +- 🔸 📜 When delivering from Firehose to Elasticsearch, the JSON document cannot contain an “_id” property. Firehose will not attempt to deliver those documents and won't log any error. + + +Device Farm +----------- + +### Основы Device Farm + +- 📒 [Домашняя страница](https://aws.amazon.com/device-farm/) ∙ [Руководство разработчика](http://docs.aws.amazon.com/devicefarm/latest/developerguide/) ∙ [ЧаВо](https://aws.amazon.com/device-farm/faq/) ∙ [Расценки](https://aws.amazon.com/device-farm/pricing/) +- **Device Farm** - это сервис AWS позволяющий тестировать мобильные приложения на реальных устройствах. +- Поддерживает устройства на iOS и Android (включая Kindle Fire), также как и мобильный веб. +- Поддерживает доступ к удаленным устройствам в целях обеспечения интерактивного тестирования/отладки. + +### Советы по Device Farm + +- [Блог AWS Mobile](https://aws.amazon.com/blogs/mobile/) содержит несколько примеров применения Device Farm для тестирования. +- Device Farm предлагает бесплатный тестовый период для пользователей, которые хотят оценить свои сервисы. +- Device Farm предлагает две ценовых модели: Оплата **за минуту использования устройства** полезна для случаев малого использования или для ситуаций, когда сложно предсказать объем использования. **Неограниченное тестирование** полезно в ситуациях, когда активное использование ожидается с самого начала. +- Чтобы минимизировать время ожидания доступности устройств, одним из подходов является создание нескольких пулов устройств с разными устройствами, а затем случайный выбор одного из неиспользуемых пулов устройств при каждом запуске. + +### Ошибки и ограничения, связанные с Device Farm + +- ❗Устройства не имеют SIM-карт, следовательно не могут быть использованы для тестирования функций связанынх с SIM-картами. +- 🔸Device Farm поддерживает тестирование для большинства популярных языков/фреймворков, но не для всех. Актуальный список поддерживаемых фреймворков и языков представлен на [этой странице](http://docs.aws.amazon.com/devicefarm/latest/developerguide/test-types-overview.html). +- 🔸API и CLI Device Farm довольно таки низко-уровневый и может потребовать разработки дополнительных инструментов или скриптов поверх них. +- 🔸AWS предоставляет несколько инструментов и плагинов для Device Farm, в любом случае это не покрывает все возможные случаи или платформы. Может потребоваться разработка специальных инструментов или плагинов для поддержки конкретных требований. +- ❗В общем, Device Farm не имеет Android устройств от китайских компаний, таких как Huawei, Meizu, Lenovo, и т.д. Актуальный список поддерживаемого оборудования размещен [здесь](https://aws.amazon.com/device-farm/device-list/). +- 🔸Доступность устройств неравномерна. Она зависит от нескольких факторов, включая популярность устройства. Обычно, более современные устройства подверженны большему спросу, таким образом время ожидание доступности для них будет выше, нежели для более старых устройств. + +Mobile Hub +---------- + +### Mobile Hub Basics + +* 📒 [Homepage](https://aws.amazon.com/mobile/) ∙ [User guide](https://docs.aws.amazon.com/mobile-hub/latest/developerguide/) ∙ [FAQ](https://aws.amazon.com/mobile/faqs/) ∙ [Pricing](https://aws.amazon.com/mobile/pricing/) +- **Mobile Hub** orchestrates multiple services to create an AWS backend for mobile and web applications. +- Each _project_ in Mobile Hub has one _backend_ made up of configurable features, plus one or more _applications_. + - Features include Analytics, Cloud Logic, Conversational Bots, Hosting and Streaming, NoSQL Database, User Data Storage and User Sign-In. Each feature uses one or two services to deliver a chunk of functionality. + - Services used include [API Gateway](#api-gateway), [CloudFront](#cloudfront), Cognito, [Device Farm](#device-farm), [DynamoDB](#dynamodb), [Lambda](#lambda), Lex, Pinpoint and [S3](#S3). + - Application SDKs exist for Android (Java), iOS (Swift), Web (JS) and React Native (JS). There is also a CLI for JavaScript applications. + +### Mobile Hub Tips +- The Mobile Hub [console](https://console.aws.amazon.com/mobilehub/home#/) has starter kits and tutorials for various app platforms. +- The CLI allows local development of Lambda code (JS by default) with `awsmobile {pull|push}` commands, to sync from cloud to folder, and back again. +- Mobile Hub itself is free, but each of the services has its own pricing model. + +### Mobile Hub Gotchas and Limitations +- 🔸The Cloud API feature allows importing an existing Lambda function instead of defining a new one, but there are some rough edges with the CLI. Check the GitHub [issues](https://github.com/aws/awsmobile-cli/issues). +- ❗Mobile Hub uses CloudFormation under the covers, and gets confused when a service is changed outside of the Mobile Hub console. + +IoT +--- + +### IoT Basics + +* 📒 [Homepage](https://aws.amazon.com/iot/) ∙ [User guide](https://docs.aws.amazon.com/iot/latest/developerguide/) ∙ [FAQ](https://aws.amazon.com/iot/faqs/) ∙ [Pricing](https://aws.amazon.com/iot/pricing/) +- **IoT** is a platform for allowing clients such as IoT devices or software applications ([examples](http://internetofthingswiki.com/iot-applications-examples/541/)) to communicate with the AWS cloud. +- Clients are also called **devices** (or **things**) and include a wide variety of device types. Roughly there are three categories of device types that interact with IoT services by sending message over an IoT protocol to the IoT Pub/Sub-style message broker, which is called the IoT **Device Gateway**: + * Send messages only: For example, the [AWS IoT Button](https://aws.amazon.com/iot/button/) on an [eddystone beacon](http://developer.estimote.com/eddystone/). + * Send, receive, and process messages: For example, a simple processing board, such as a **Raspberry Pi** ([quick start guide](http://docs.aws.amazon.com/iot/latest/developerguide/iot-device-sdk-c.html)), or an AWS device, such as [Echo or Echo Dot](https://developer.amazon.com/echo), which are designed to work with the [AWS Alexa skills kit](https://developer.amazon.com/alexa-skills-kit) (a programmable voice-enabled service from AWS). +- AWS has a useful [quick-start](http://docs.aws.amazon.com/iot/latest/developerguide/iot-gs.html) (using the Console) and a [slide presentation](http://www.slideshare.net/AmazonWebServices/connecting-to-aws-iot) on core topics. +* **IoT terms:** + * AWS [**IoT Things**](http://docs.aws.amazon.com/iot/latest/developerguide/iot-thing-management.html) (metadata for devices in a [registry](http://docs.aws.amazon.com/iot/latest/developerguide/iot-thing-management.html)) and can store device state in a JSON document, which is called a [**device shadow**](http://docs.aws.amazon.com/iot/latest/developerguide/iot-thing-shadows.html). Device metadata can also be stored in [**IoT Thing Types**](http://docs.aws.amazon.com/iot/latest/developerguide/thing-types.html). This aids in device metadata management by allowing for reuse of device description and configuration for more than one device. Note that IoT Thing Types can be deprecated, but not changed — they are immutable. + * AWS [**IoT Certificates**](http://docs.aws.amazon.com/iot/latest/developerguide/attach-cert-thing.html) (device authentication) are the logical association of a unique certificate to the logical representation of a device. This association can be done in the Console. In addition, the public key of the certificate must be copied to the physical device. This covers the authentication of devices to a particular AWS Device Gateway (or message broker). You can associate an AWS IoT certificate with an IoT device or you can [register your own CA (Certificate Authority) with AWS](http://docs.aws.amazon.com/iot/latest/developerguide/device-certs-your-own.html), generate your own certificate(s) and associate those certificates with your devices via the AWS Console or cli. + * AWS [**IoT Policies**](http://docs.aws.amazon.com/iot/latest/developerguide/authorization.html) (device/topic authorization) are JSON files that are associated to one or more AWS IoT certificates. This authorizes associated devices to publish and/or subscribe to messages from one or more MQTT topics. + * AWS [**IoT Rules**](http://docs.aws.amazon.com/iot/latest/developerguide/iot-rules.html) are SQL-like queries which allows for reuse of some or all device message data, as described in [this presentation, which summarizes design patterns with for IoT Rules](http://www.slideshare.net/AmazonWebServices/programming-the-physical-world-with-device-shadows-and-rules-engine-66486454). + * Shown below is a [diagram](https://aws.amazon.com/iot/how-it-works/) which summarizes the flow of messages between the AWS IoT services: + +![How AWS IoT Works](https://d0.awsstatic.com/IoT/diagrams/awsiot-how-it-works_HowITWorks_1-26.png "How AWS IoT Works") + +### IoT Greengrass + +* 📒 [Homepage](https://aws.amazon.com/greengrass/) +* 🐥**Greengrass** is a software platform that extends AWS IoT capabilities allowing Lambda functions to be run directly on local devices. It also enables IoT devices to be able to securely communicate on a local network without having to connect to the cloud. + * Greengrass includes a local pub/sub message manager that can buffer messages if connectivity is lost so that inbound and outbound messages to the cloud are preserved. Locally deployed Lambda functions can be triggered by local events, messages from the cloud, or other sources. + * Greengrass includes secure authentication and authorization of devices within the local network and also between the local network and the AWS cloud. It also provides secure, over-the-air software updates of Lambda functions. +* Greengrass core software includes a message manager object, Lambda runtime, local copy service for IoT Thing (or device) shadows, and a deployment agent to manage Greengrass group configuration. +* **Greengrass groups** are containers for selected IoT devices settings, subscriptions and associated Lambda functions. In a Greengrass group a device is either a Greengrass core or an IoT device which will be connected that particular Greengrass core. +* The Greengrass core SDK enables Lambda functions to interact with the AWS Greengrass core on which they run in order to publish messages, interact with the local Thing Shadows service, or invoke other deployed Lambda functions. +* The AWS Greengrass Core SDK only supports sending MQTT messages with QoS = 0. +* Shown below is a [diagram](http://docs.aws.amazon.com/greengrass/latest/developerguide/what-is-gg.html) which shows the architecture of AWS IoT Greengrass services: + +![IoT Greengrass](http://docs.aws.amazon.com/greengrass/latest/developerguide/images/greengrass.png) + + +### IoT Alternatives and Lock-in + +- AWS, Microsoft and Google have all introduced IoT-specific sets of cloud services since late 2015. AWS was first, moving their IoT services to [general availability](https://aws.amazon.com/blogs/aws/aws-iot-now-generally-available/) in Dec 2015. Microsoft released their set of IoT services for Azure in [Feb 2016](https://azure.microsoft.com/en-us/updates/generally-available-microsoft-azure-iot-hub/). Google has only previewed, but not released their IoT services [Android Things](https://developer.android.com/things/index.html) and [Weave](https://developers.google.com/weave/). +- Issues of lock-in center around your devices — [protocols](http://www.postscapes.com/internet-of-things-protocols/) (for example MQTT, AMQP), message formats (such as, JSON vs. Hex...) and security (certificates). + +### IoT Tips + +- **Getting started with Buttons:** One way to start is to use an [**AWS IoT Button**](https://aws.amazon.com/iot/button/). AWS provides a number of code samples for use with their IoT Button, you can use the AWS IoT console, click the “connect AWS IoT button” link and you'll be taken to the AWS Lambda console. There you fill out your button’s serial number to associate it with a Lambda. (As of this writing, AWS IoT buttons are only available for sale in the US.) +- **Connections and protocols:** It is important to understand the details of about the devices you wish to connect to the AWS IoT service, including how you will secure the device connections, the device protocols, and more. Cloud vendors differ significantly in their support for common IoT protocols, such as MQTT, AMQP, XMPP. AWS IoT supports **secure MQTT**, **WebSockets** and **HTTPS**. +- Support for **device security** via certificate processing is a key differentiator in this space. In August 2016, AWS added [just-in-time registrations](https://aws.amazon.com/blogs/iot/just-in-time-registration-of-device-certificates-on-aws-iot/) for IoT devices to their services. +- **Combining with other services:** It’s common to use other AWS services, such as AWS Lambda, Kinesis and DynamoDB, although this is by no means required. Sample IoT application reference architectures are in this [screencast](https://www.youtube.com/watch?v=0Izh6ySpwb8/). +- **Testing tools:** + * To get started, AWS includes a lightweight MQTT client in the AWS IoT console. Here you can create and test sending and receiving messages to and from various MQTT topics. + * When testing locally, if using MQTT, it may be helpful to download and use the open source [Mosquitto broker](https://mosquitto.org/download/) tool for local testing with devices and/or device simulators + * Use this [MQTT load simulator](https://github.com/awslabs/aws-iot-mqtt-load-generator) to test device message load throughout your IoT solution. + +### IoT Gotchas and Limitations + +- 🔸**IoT protocols:** It is important to verify the exact type of support for your particular IoT device message protocol. For example, one commonly used IoT protocol is [MQTT](https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_mqtt_the_protocol_for_internet_of_things?lang=en). Within MQTT there are [three possible levels of QoS in MQTT](https://dzone.com/articles/internet-things-mqtt-quality). AWS IoT supports MQTT [QoS 0](http://docs.aws.amazon.com/iot/latest/developerguide/protocols.html) (fire and forget, or at most once) and QoS 1(at least once, or includes confirmation), but *not* QoS 2 (exactly once, requires 4-step confirmation). This is important in understanding how much code you’ll need to write for your particular application message resolution needs. Here is a [presentation about the nuances of connecting](http://www.slideshare.net/AmazonWebServices/overview-of-iot-infrastructure-and-connectivity-at-aws-getting-started-with-aws-iot). +- 🔸The ecosystems to match **IAM users or roles** to **IoT policies** and their associated authorized AWS IoT devices are immature. Custom coding to enforce your security requirements is common. +- ❗A common mistake is to misunderstand the importance of IoT **device** **security**. It is imperative to associate *each* device with a unique certificate (public key). You can generate your own certificates and upload them to AWS, or you can use AWS generated IoT device certificates. It’s best to read and understand AWS’s own guidance on this [topic](http://www.slideshare.net/AmazonWebServices/best-practices-of-iot-in-the-cloud). +- 🔸There is only one **AWS IoT Gateway** (endpoint) per AWS account. For production scenarios, you’ll probably need to set up multiple AWS accounts in order to separate device traffic for development, test and production. It’s interesting to note that the [Azure IoT Gateway](https://azure.microsoft.com/en-us/documentation/articles/iot-hub-protocol-gateway/) supports configuration of multiple endpoints, so that a single Azure account can be used with separate pub/sub endpoints for development, testing and production +- 🔸**Limits:** Be aware of [limits](http://docs.aws.amazon.com/iot/latest/developerguide/iot-limits.html), including device message size, type, frequency, and number of AWS IoT rules. + +### IoT Code Samples + +- [Simple Beer Service](https://github.com/awslabs/simplebeerservice) is a surprisingly useful code example using AWS IoT, Lambda, etc. +- [IoT-elf](https://github.com/awslabs/aws-iot-elf) offers clean Python sample using the AWS IoT SDK. +- [IoT Button projects](https://www.hackster.io/AmazonWebServices/products/aws-iot-button) on Hackster include many different code samples for projects. +- [5 IoT code examples](https://github.com/awslabs/aws-iot-examples/): a device simulator, MQTT sample, just in time registration, truck simulator, prediction data simulator. +- [AWS Alexa trivia voice example](https://developer.amazon.com/public/community/post/TxDJWS16KUPVKO/New-Alexa-Skills-Kit-Template:-Build-a-Trivia-Skill-in-under-an-Hour) is a quick-start using Alexa voice capability and Lambda. +- Some Raspberry Pi examples include the [Beacon project](https://github.com/araobp/beacon/blob/master/README.md), [Danbo](https://libraries.io/github/awslabs/aws-iot-demo-for-danbo), and [GoPiGo](https://github.com/awslabs/aws-iotbot). + +SES +--- + +### SES Basics + +- 📒 [Homepage](https://aws.amazon.com/ses/) ∙ [Documentation](https://aws.amazon.com/documentation/ses/) ∙ [FAQ](https://aws.amazon.com/ses/faqs/) ∙ [Pricing](https://aws.amazon.com/ses/pricing/) +- **SES** (or Simple Email Service) is a service that exposes SMTP endpoints for your application to directly integrate with. + +### SES Tips + +- 🔹**Bounce Handling:** Make sure you handle this early enough. Your ability to send emails can be removed if SES sees [too many bounces](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/best-practices-bounces-complaints.html). +- 🔹**Credentials:** Many developers get confused between [SES credentials](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/using-credentials.html) and AWS API keys. Make sure to enter [SMTP credentials](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-credentials.html) while using the SMTP APIs. + +### SES Gotchas and Limitations + +- 🔸**Internet Access:** SES SMTP endpoints are on the Internet and will not be accessible from a location without Internet access (e.g. a private subnet without NAT gateway route in the routing table). In such a case, set up an SMTP relay instance in a subnet with Internet access and configure your application to send emails to this SMTP relay instance rather than SES. The relay should have a [forwarding rule to send all emails to SES](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-smtp-existing-server.html)). ❗If you are using a proxy instead of a NAT, confirm that your proxy service supports SMTP. + +Менеджер Сертификатов(Certificate Manager) +------------------- + +### Основы менеджера сертификатов + +- 📒 [Домашняя страница](https://aws.amazon.com/certificate-manager/) ∙ [Руководство пользователя](http://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) ∙ [ЧаВо](https://aws.amazon.com/certificate-manager/faqs/) ∙ [Расценки](https://aws.amazon.com/certificate-manager/pricing/) +- Используйте **Менеджер Сертификатов** чтобы управлять сертификатами SSL/TLS в других сервисах AWS. +- Поддерживается импорт существующих сертификатов, также как выпуск новых. + Предоставляет доменные валидированные (DV) сертификаты. [Валидация](http://docs.aws.amazon.com/acm/latest/userguide/gs-acm-validate.html) может быть выполнена двумя путями. Первый (и рекомендованный) способ - [через DNS](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-validate-dns.html). Если зона находится в Route 53 и у пользователя есть доступ, необходимая запись может быть добавлена в консоли в один клик в процессе запроса сертификата. Если зона не находится в Route 53 пользователь должен обновить DNS вручную. Также существует до сих пор предпочитаемый второй способ, который требует больше взаимодействия с пользователем, и происходит путем отсылки электронного почтового сообщения по трем контактным адресам, указанным в регистрационных данных домена в WHOIS и пяти стандартным адресам в домене, для каждого доменного имени, присутствующего в запросе. +- Менеджер Сертификатов Amazon будет пытаться автоматически [обновить](http://docs.aws.amazon.com/acm/latest/userguide/how-domain-validation-works.html) сертификат, выпущенный Amazon. Для начала он попытается соединиться с доменом по протоколу HTTPS и проверит, что сертификат используемый доменом, является тем же, который он пытается обновить. В случае неудачи, он проверит DNS запись, ранее использованную для валидации. В случае неудачи, Менеджер Сертификатов Amazon попытается провести ручную валидацию, отправив письма на электронные адреса всех доменов в сертификате. + +### Альтернативы Менеджеру Сертификатов и привязки + +- ⛓Сертификаты выпущенные Менеджером Сертификатов не могут быть использованы где либо, кроме сервисов, которые их поддерживают. Импортированные сертификаты, как бы там ни было, можно использовать где-угодно. + +### Советы по Менеджеру сертификатов + +- 🔹**Поддерживаемые сервисы:** Управляемые [Балансировщики Нагрузки](#load-balancers), [CloudFront](#cloudfront), [API Gateway](#api-gateway) и [Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/). +- 🔸Во время процесса валидации домена, если валидация по DNS была неудачна, Менеджер Сертификатов отправит электронное письмо каждому контактному адресу, указанному в регистрационных данных домена в WHOIS и до пяти административным адресатам. Некоторые анти-спам фильтры могут пометить такие письма как спам. Вам стоит проверить папку спам в своем почтовом ящике, если вы не получили письмо с подтверждением. +- 🔹 Хотите установить сертификат на тестовый домен, на котором нет почты? Используйте DNS валидацию вместо этого. +- 🔹Запомните, когда вы заказываете сертификат для вайлдкард(то есть любое значение для суб-доменов) домена, сертификат не будет работать для всех уровней ниже звездочки. Для примера одобрен и выпущен сертификат для `*.bar.example.com`. Он будет работать для `foo.bar.example.com`, но не `bar.example.com`. Также, скорее всего он не будет работать для `www.bar.foo.example.com`. Вам потребуется добавить каждый из этих доменов в запрос на создание сертификата. + +### Ошибки и ограничения, связанные с Менеджером сертификатов + +- 🔸Если вы хотите использовать **Менеджер Сертификатов** для CloudFront CDN, сертификат должен быть выпущен или импортирован в регионе us-east-1 (Северная Вирджиния). +- 🔸Сертификаты используемые с Эластичными Балансировщиками Нагрузки должны быть выпущены в том же регионе, что и балансировщик нагрузки. Сертификаты нельзя перемещать или копировать между регионами, по состоянию на июль 2017 года. Если домен использует балансировщики нагрузки в разных регионах - разные сертификаты должны быть запрошены для каждого региона. +- 🔸**IoT** имеет [свой способ](http://docs.aws.amazon.com/iot/latest/developerguide/create-device-certificate.html) установки сертификатов. +- 🔸По умолчанию, макисимальное количество доменов в сертификате - 10. Вы можете увеличить этот лимит максимум до 100 путем обращения в поддержку AWS. **Имейте ввиду** для каждого домена включенного в запрос на сертификат, вы должны нажать 'принять' в сообщении присланном на адрес в этом домене. Например вы запросили сертификат с 42 разными доменами и субдоменами, вам придется нажать 'принять' 42 раза по разным ссылкам. + - 🔹Если вы запросите увеличение лимита у службы поддержки AWS, они ответят на ваш запрос с просьбой подтвердить. Вы можете обойти это, написав в теле вашего первоначального запроса: +```"I acknowledge at the moment, there is no method to add or remove a name from a certificate. Instead, you must request a new certificate with the revised namelist and you must then re-approve all of the names in the certificate, even if they'd been previously approved."``` +- 🔸Нет никакой возможности на текущий момент добавить или удалить домен из существующего сертификата. Вы должны запросить новый сертификат и заново подтвердить для каждого из запрошенных доменов. + +WAF +------------------- + +### Основы WAF + +- 📒 [Домашняя страница](https://aws.amazon.com/waf/) ∙ [Документация](https://aws.amazon.com/documentation/waf/) ∙ [ЧаВо](https://aws.amazon.com/waf/faq/) ∙ [Расценки](https://aws.amazon.com/waf/pricing) +- WAF (Брандмауэр для интернет‑приложений) используется совместно со службами CloudFront и ALB для проверки и блокировки / разрешения веб-запросов на основе настраиваемых пользователем условий. +- HTTPS и HTTP запросы поддерживаются этим сервисом. +- Сила WAF заключается в обнаружении злонамеренных действий на основе сопоставления с шаблоном для таких атак, как инъекции SQL, XSS и т.д. +- WAF поддерживает проверку запросов [полученных как через IPv6, так и через IPv4](https://aws.amazon.com/about-aws/whats-new/2016/10/ipv6-support-for-cloudfront-waf-and-s3-transfer-acceleration/). + +### Советы по WAF + +- Получение истории вызовов API WAF может быть произведено через CloudTrail. Включить можно в консоли CloudTrail. +- Также возможно получение [полных логов проверки всех веб запросов](https://aws.amazon.com/about-aws/whats-new/2018/08/aws-waf-launches-new-comprehensive-logging-functionality/) + +### Ошибки и ограничения, связанные с WAF + +- По состоянию на май 2019 года, AWS WAF доступен в Amazon CloudFront и 12 коммерческих регионах AWS : US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), EU (Ireland), EU (Frankfurt), EU (London), EU (Stockholm), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Singapore), и Asia Pacific (Seoul). + + +OpsWorks +------------------- + +### OpsWorks Basics + +- 📒 [Homepage](https://aws.amazon.com/opsworks/) ∙ [Documentation](https://aws.amazon.com/documentation/opsworks/) ∙ [FAQ](https://aws.amazon.com/opsworks/faqs/) ∙ Pricing: [Stacks](https://aws.amazon.com/opsworks/stacks/pricing/), [Chef Automate](https://aws.amazon.com/opsworks/chefautomate/pricing/), [Puppet Enterprise](https://aws.amazon.com/opsworks/puppetenterprise/pricing/) +- OpsWorks is a configuration management service that uses [Chef](https://www.chef.io/chef/) or [Puppet](https://www.puppet.com) configuration management. It is broken out into three different services: + - [OpsWorks Stacks](https://aws.amazon.com/opsworks/stacks/): The service lets you configure and launch stacks specific to your application's needs, and allows you to automate application deployments. Chef runs can be performed manually via the Execute Cookbooks command, otherwise they are only run as part of lifecycle events. + - OpsWorks Stacks differs from standard configuration management services in that it also allows you to perform some infrastructure and application automation (such as creating Amazon EC2 instances and deploying applications via Chef cookbooks). + - [OpsWorks for Chef Automate](https://aws.amazon.com/opsworks/chefautomate/): This service launches a dedicated Chef Automate server in your account, which can be used to associate nodes, upload coobook code, and configure systems. Automated patching, backups, OS updates, and minor Chef version upgrades are provided as part of the service. An AWS API is provided for associating/disassociating nodes. Chef runs can be scheduled on nodes using the [chef-client cookbook](https://supermarket.chef.io/cookbooks/chef-client). + - [OpsWorks for Puppet Enterprise](https://aws.amazon.com/opsworks/puppetenterprise/): This service launches a dedicated Puppet Master in your account, which can be used to associate nodes, upload modules, and configure systems. Automated patching, backups, OS updates, and minor Puppet version upgrades are provided as part of the service. An AWS API is provided for associating/disassociating nodes. By default, the Puppet agent will run automatically every 30 minutes on associated nodes. +- OpsWorks for Chef Automate and OpsWorks for Puppet Enterprise are strictly designed for configuration management, and do not provision infrastructure outside the Chef Server/Puppet Master that is created in our account. +- All three OpsWorks services support managing both Amazon EC2 and on-premises infrastructure, however the implementation details differ slightly. + - OpsWorks Stacks allows you to register instances and install the OpsWorks Agent to connect to your stack. + - OpsWorks for Chef Automate and OpsWorks for Puppet Enterprise allow you to associate new or existing infrastructure using either the opsworks-cm:AssociateNode API action or the vendor-supported method for associating nodes to Chef Server or Puppet Enterprise. +- Although OpsWorks will let you work with common Chef recipes or Puppet modules when creating your stacks, creating custom recipes will require familiarity with Chef or Puppet syntax. Chef/Puppet code is not supported as part of AWS Support. +- As of December 2016, OpsWorks Stacks supports Chef versions [12, 11.10.4, 11.4.4 and 0.9.15.5](http://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook.html). +- As of December 2016, OpsWorks for Chef Automate uses [Chef Server version 12.11.1](http://docs.aws.amazon.com/opsworks/latest/userguide/welcome_opscm.html) This is the current stable version of Chef. +- [Berkshelf](http://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-chef11-10.html#workingcookbook-chef11-10-berkshelf)can be used with Chef stacks of version 11.10 and later for managing cookbooks and their respective dependencies. However, on Chef 12.x stacks, Berkshelf must be installed by the stack administrator. +- Running your own Chef environment may be an alternative to consider - some considerations are listed [in this Bitlancer article.](http://www.bitlancer.com/blog/2015/10/05/opsworks-vs-chef.html) + +### OpsWorks Alternatives and Lock-in + +- Major competitors in Configuration Management include: + - [Chef](https://chef.io) + - [Puppet](https://puppet.com) + - [Ansible](https://www.ansible.com). + +### OpsWorks Tips + +- OpsWorks Stacks and OpsWorks for Chef Automate use Chef cookbooks for configuration. Chef provides free training to learn syntax, best practices, etc. at [https://learn.chef.io](https://learn.chef.io). +- OpsWorks for Puppet Enterprise uses Puppet manifests for configuration. Puppet provides a very useful learning VM for download at [https://learn.puppet.com/](https://learn.puppet.com/). + +### OpsWorks Gotchas and Limitations + +- OpsWorks Stacks is not available in the following regions: + - Montreal + - GovCloud + - Beijing +- OpsWorks for Chef Automate and OpsWorks for Puppet Enterprise are not available in the following regions: + - Montreal + - Sao Paulo + - GovCloud + - London + - Paris + - Seoul + - Mumbai + +Batch +------------------- + +### Основы Batch + +- 📒 [Домашняя страница](https://aws.amazon.com/batch/) ∙ [Документация](https://aws.amazon.com/documentation/batch/) ∙ [ЧаВо](https://aws.amazon.com/batch/faqs/) ∙ [Расценки](https://aws.amazon.com/batch/pricing/) +- **AWS Batch** - сервис, предлагающий среду для выполнения пакетных вычислительных задач. Сервис динамически предоставляет оптимальное количество вычислительных ресурсов необходимых задачам на основе хи требованиям к ресурсам и может масштабироваться на сотни и тысячи [задач](http://docs.aws.amazon.com/batch/latest/userguide/jobs.html). +- Эти пакетные рабочие нагрузки имеют доступ ко всем другим сервисам и функциям AWS. +- AWS Batch, вместе со [спотовыми инстансами](https://aws.amazon.com/blogs/compute/cost-effective-batch-processing-with-amazon-ec2-spot/) может выполнять задачи, когда необходимые вычислительные мощности доступны, таким образом предоставляяя оптимальную загрузку вычислительных ресурсов. +- Пакетные нагрузки оборачиваются в [образ Docker](https://www.docker.com/). Эти образы вносятся в репозиторий [EC2 Container Registry](https://aws.amazon.com/ecr/) (ECR), или любой частный репозиторий, который может быть доступен с AWS. +-[Описание задачи(Job Definition)](http://docs.aws.amazon.com/batch/latest/userguide/job_definitions.html) включает в себя адрес образа Docker с рабочей нагрузкой, а также позволяет пользователям указать конкретные детали среды, такие как количество виртуальных процессоров, памяти, подключаемые тома, переменные окружения, параметры, стратегию повторов, свойства контейнера, а также IAM роль. +-[Вычислительные окружения](http://docs.aws.amazon.com/batch/latest/userguide/compute_environments.html) это кластера EC2, которые предоставляют вычислительную среду, для запуска пакетных рабочих нагрузок. +- AWS Batch предоставляет как управляемые, так и неуправляемые вычислительные окружения. Управляемые окружения разворачиваются и управляются AWS, в то время, как неуправляемые окружения управляются клиентами. +- Описания задач вносятся в [Очередь Задач(Job Queue(s))](http://docs.aws.amazon.com/batch/latest/userguide/job_queues.html) для запуска. Каждая очередь имеет приоритет, и, как минимум, одно вычислительное окружение, сопряженное с ней. +- AWS Batch использует [ECS](https://aws.amazon.com/ecs/) для запуска контейнеризированных задач. + +### Советы по Batch + +- AWS Batch поддерживает приоретизацию задач через приоритет очереди задач(Job Queue Priority). Чем выше номер - тем выше приоритет. +- AWS Batch поддерживает запуск вычислительного окружения в конкретном VPC и подсети. +- Вычислительное окружение - это то же самое, что и [ECS Кластер](http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_clusters.html). +- AWS Batch дополнительно не оплачивается. Вы платите только за сервисы AWS, которые используются - такие как инстансы EC2 и любые другие ресурсы, потребляющиеся при выполнении пакетного задания. +- Свяжите [Роли и политики IAM](http://docs.aws.amazon.com/batch/latest/userguide/IAM_policies.html) с вычислительным окружением, чтобы предоставить контейнерам доступ к другим ресурсам AWS. +- 🔹 Используйте неуправляемые вычислительные окружения, если вам нужны специализированные ресурсы, такие как выделенные хосты или [EFS](https://aws.amazon.com/efs/). + +SQS +------------------- + +### SQS Basics + +- 📒 [_Homepage_](https://aws.amazon.com/sqs/) ∙ [_Documentation_](https://aws.amazon.com/documentation/sqs/) ∙ [_FAQ_](https://aws.amazon.com/sqs/faqs/) ∙ [_Pricing_ ](https://aws.amazon.com/sqs/pricing/) +- SQS is a highly scalable, fully managed message queuing service from AWS. +- SQS supports the pull model, where the producers *queue* the messages, and the consumers pull messages off the queue. +- SQS provides a message visibility timeout, during which the message being processed will not be delivered to other consumers. If the consumer does not delete the message after processing, the message becomes available to other consumers upon reaching the message visibility timeout. This parameter is called VisibilityTimeout. +- Each message can have up to 10 custom fields, or attributes. +- SQS allows producers to set up to 15 minutes of delay before the messages are delivered to the consumers. This parameter is called DelaySeconds. +- There are two types of queues supported by SQS - + - Standard Queues + - Guarantee **at least once** delivery of the messages. + - Do not retain the order of delivery of the messages. + - FIFO Queues + - Guarantee **only once** delivery of the messages + - Guarantee the order of the delivery of the messages +- SQS supports fine grained access to various API calls and Queues via IAM policies. +- The messages that fail to process can be put in a dead letter queue. + +### SQS Alternatives and Lock-In + +- Alternatives to SQS include [Kafka](https://kafka.apache.org/), [RabbitMQ](https://www.rabbitmq.com/), [ActiveMQ](http://activemq.apache.org/) and others. +- Google Cloud Platform has Pub/Sub, and Azure has Azure Queue Service. +- [SQS vs SNS](#sns-alternatives-and-lock-in) + +### SQS Tips + +- SNS can be used in combination of SQS to build a “fan out” mechanism by having an SQS Queue subscribe to the SNS topic. +- SQS supports encryption using AWS KMS. +- Cloudwatch alarms can be creating using [various SQS metrics](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/sqs-metricscollected.html) to trigger autoscaling actions and/or notifications. + +### SQS Gotchas and Limitations + +- 🔸 SQS does not have a VPC endpoint (unlike S3 and DynamoDB), so SQS will need to be accessed using public SQS API endpoints. +- 🔸 FIFO Queues are limited to 300 API calls per second. +- 🔸 FIFO Queues cannot subscribe to an SNS topic. +- 🔸 Standard Queues can deliver duplicate messages regardless of the visibility window. If only-once delivery is your only choice, then use FIFO queues, or build an additional layer to de-dupe the messages. +- 🔸 You can send/receive messages in batch, however, there can only be maximum of 10 messages in a batch. + + +SNS +--------------------- + +### SNS Basics + +- 📒 [_Homepage_](https://aws.amazon.com/sns/) ∙ [_Documentation_](https://aws.amazon.com/documentation/sns/) ∙ [_FAQ_](https://aws.amazon.com/sns/faqs/) ∙ [_Pricing_](https://aws.amazon.com/sns/pricing/) +- **SNS** (Simple Notification Service) is a pub/sub based, highly scalable, and fully managed messaging service that can also be used for mobile notifications. +- SNS can push the messages down to the subscribers via [SMS](http://docs.aws.amazon.com/sns/latest/dg/SMSMessages.html), [Email](http://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html), [SQS](http://docs.aws.amazon.com/sns/latest/dg/SendMessageToSQS.html), and [HTTP/S](http://docs.aws.amazon.com/sns/latest/dg/SendMessageToHttp.html) transport protocols. +- Producers publish messages to a SNS Topics, which can have many subscribers. +- Each subscription has an associated [protocol](http://docs.aws.amazon.com/sns/latest/api/API_Subscribe.html), which is used to notify the subscriber. +- A copy of the message is sent to each subscriber using the associated protocol. +- SNS can also [invoke lambda functions](http://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html). + +### SNS Alternatives and Lock-In + +- Popular alternatives to SNS are [Kafka](https://kafka.apache.org/), [Notification Hubs](https://azure.microsoft.com/en-us/services/notification-hubs/) on Azure, and [Pub/Sub](https://cloud.google.com/pubsub/docs/overview) on Google Cloud. +- **SNS vs SQS:** + - Both SNS and SQS are highly scalable, fully managed messaging services provided by AWS. + - SQS supports a *pull* model, while SNS supports a *push* model. Consumers have to pull messages from an SQS Queue, while they're pushed the message from an SNS Topic. + - An SQS message is intended to be processed by only one subscriber, while SNS topics can have many subscribers. + - After processing, the SQS message is deleted from the queue by the subscriber to avoid being re-processed. + - An SNS message is *pushed* to all subscribers of the topic at the same time, and is not available for deletion at the topic. + - SNS supports multiple transport protocols of delivery of the messages to the subscribers, while SQS subscribers have to pull the messages off the queue over HTTPS. + +### SNS Tips + +- [Fan-out](http://docs.aws.amazon.com/sns/latest/dg/SNS_Scenarios.html) architecture can be achieved by having multiple subscribers for a topic. This is particularly useful when events have to be fanned out to multiple, isolated systems. +- SNS topics can be used to power [webhooks](https://en.wikipedia.org/wiki/Webhook) with [backoff support](http://docs.aws.amazon.com/sns/latest/dg/DeliveryPolicies.html) to subscribers over HTTP/S. +- [SQS queues](http://docs.aws.amazon.com/sns/latest/dg/SendMessageToSQS.html) can subscribe to SNS topics. +- SNS is used to manage notifications for other AWS services like [Autoscaling Groups](http://docs.aws.amazon.com/autoscaling/latest/userguide/ASGettingNotifications.html)' notifications, [CloudWatch Alarms](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), etc. +- SNS is frequently used as “glue” between disparate systems— such as GitHub and AWS services. + +### SNS Gotchas and Limitations + +- 🔸 HTTP/S subscribers of SNS topics need to have public endpoints, as SNS does not support calling private endpoints (like those in a private subnet within a VPC). +- 📜 In a fan-out scenario, [SSE-enabled SQS](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.html) subscribers of an SNS topic [will not receive](https://lobster1234.github.io/2017/10/14/fan-out-with-sns-and-sqs-gotcha/) the messages sent to the topic. + +High Availability +----------------- + +This section covers tips and information on achieving [high availability](https://en.wikipedia.org/wiki/High_availability). + + + +### High Availability Tips + +- AWS offers two levels of redundancy, [regions and availability zones (AZs)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones). +- When used correctly, regions and zones do allow for high availability. You may want to use non-AWS providers for larger business risk mitigation (i.e. not tying your company to one vendor), but reliability of AWS across regions is very high. +- **Multiple regions:** Using multiple regions is complex, since it’s essentially like managing completely separate infrastructures. It is necessary for business-critical services with the highest levels of redundancy. However, for many applications (like your average consumer startup), deploying extensive redundancy across regions may be overkill. +- The [High Scalability Blog](http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html) has a good guide to help you understand when you need to scale an application to multiple regions. +- 🔹**Multiple AZs:** Using AZs wisely is the primary tool for high availability! + - A typical single-region high availability architecture would be to deploy in two or more availability zones, with load balancing in front, as in [this AWS diagram](http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_ftha_04.pdf). + - The bulk of outages in AWS services affect one zone only. There have been rare outages affecting multiple zones simultaneously (for example, the [great EBS failure of 2011](http://aws.amazon.com/message/65648/)) but in general most customers’ outages are due to using only a single AZ for some infrastructure. + - Consequently, design your architecture to minimize the impact of AZ outages, especially single-zone outages. + - Deploy key infrastructure across at least two or three AZs. Replicating a single resource across more than three zones often won’t make sense if you have other backup mechanisms in place, like S3 snapshots. + - A second or third AZ should significantly improve availability, but additional reliability of 4 or more AZs may not justify the costs or complexity (unless you have other reasons like capacity or Spot market prices). + - 💸Watch out for **cross-AZ traffic costs**. This can be an unpleasant surprise in architectures with large volume of traffic crossing AZ boundaries. + - Deploy instances evenly across all available AZs, so that only a minimal fraction of your capacity is lost in case of an AZ outage. + - If your architecture has single points of failure, put all of them into a single AZ. This may seem counter-intuitive, but it minimizes the likelihood of any one SPOF to go down on an outage of a single AZ. +- **EBS vs instance storage:** For a number of years, EBSs had a poorer track record for availability than instance storage. For systems where individual instances can be killed and restarted easily, instance storage with sufficient redundancy could give higher availability overall. EBS has improved, and modern instance types (since 2015) are now EBS-only, so this approach, while helpful at one time, may be increasingly archaic. +- Be sure to [use and understand CLBs/ALBs](#load-balancers) appropriately. Many outages are due to not using load balancers, or misunderstanding or misconfiguring them. + +### High Availability Gotchas and Limitations + +- 🔸**AZ naming** differs from one customer account to the next. Your “us-west-1a” is not the same as another customer’s “us-west-1a” — the letters are assigned to physical AZs randomly per account. This can also be a gotcha if you have multiple AWS accounts. Note that Zone IDs are consistent between accounts, and can be used to reliably align between AWS accounts. +- 🔸💸**Cross-AZ traffic** is not free. At large scale, the costs add up to a significant amount of money. If possible, optimize your traffic to stay within the same AZ as much as possible. + +Billing and Cost Management +--------------------------- + +### Billing and Cost Visibility + +- AWS offers a [**free tier**](https://aws.amazon.com/free/) of service, that allows very limited usage of resources at no cost. For example, a micro instance and small amount of storage is available for no charge. Many services are only eligible for the free tier for the first twelve months that an account exists, but other services offer a free usage tier indefinitely. (If you have an old account but starting fresh, sign up for a new one to qualify for the free tier.) [AWS Activate](https://aws.amazon.com/activate/) extends this to tens of thousands of dollars of free credits to startups in [certain funds or accelerators](https://aws.amazon.com/activate/portfolio-detail/). +- You can set [**billing alerts**](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free-tier-alarms.html) to be notified of unexpected costs, such as costs exceeding the free tier. You can set these in a [granular way](https://wblinks.com/notes/aws-tips-i-wish-id-known-before-i-started/#billing). +- AWS offers [Cost Explorer](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html), a tool to get better visibility into costs. +- Unfortunately, the AWS console and billing tools are rarely enough to give good visibility into costs. For large accounts, the AWS billing console can time out or be too slow to use. +- **Tools:** + - 🔹Enable [billing reports](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/detailed-billing-reports.html) and install an open source tool to help manage or monitor AWS resource utilization. [**Teevity Ice**](https://github.com/Teevity/ice) (originally written by Netflix) is probably the first one you should try. Check out [docker-ice](https://github.com/jonbrouse/docker-ice) for a Dockerized version that eases installation. + - 🔸One challenge with Ice is that it doesn’t cover amortized cost of reserved instances. + - Other tools include [Security Monkey](https://github.com/Netflix/security_monkey) and [Cloud Custodian](https://github.com/capitalone/cloud-custodian). + - Use [AWS Simple Monthly Calculator](https://calculator.s3.amazonaws.com/index.html) to get an estimate of usage charges for AWS services based on certain information you provide. Monthly charges will be based on your actual usage of AWS services, and may vary from the estimates the Calculator has provided. +- **Third-party services:** Several companies offer services designed to help you gain insights into expenses or lower your AWS bill, such as [Cloudability](https://www.cloudability.com/), [CloudHealth Technologies](https://www.cloudhealthtech.com/), and [ParkMyCloud](http://www.parkmycloud.com/). Some of these charge a percentage of your bill, which may be expensive. See the [market landscape](#tools-and-services-market-landscape). +- AWS’s [Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) is another service that can help with cost concerns. +- Don’t be shy about asking your account manager for guidance in reducing your bill. It’s their job to keep you happily using AWS. +- **Tagging for cost visibility:** As the infrastructure grows, a key part of managing costs is understanding where they lie. It’s strongly advisable to [tag resources](https://aws.amazon.com/blogs/aws/resource-groups-and-tagging/), and as complexity grows, group them effectively. If you [set up billing allocation appropriately](http://aws.amazon.com/blogs/aws/aws-cost-allocation/), you can then get visibility into expenses according to organization, product, individual engineer, or any other way that is helpful. +- If you need to do custom analysis of raw billing data or want to feed it to a third party cost analysis service, [enable](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/detailed-billing-reports.html#turnonreports) the [detailed billing report](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/detailed-billing-reports.html#detailed-billing-report) feature. +- Multiple Amazon accounts can be linked for billing purposes using the [Consolidated Billing](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) feature. Large enterprises may need complex billing structures depending on ownership and approval processes. +- Multiple Amazon accounts can be managed centrally using [AWS Organizations](https://aws.amazon.com/organizations/). + +### AWS Data Transfer Costs + +- For deployments that involve significant network traffic, a large fraction of AWS expenses are around data transfer. Furthermore, costs of data transfer, within AZs, within regions, between regions, and into and out of AWS and the internet vary significantly depending on deployment choices. +- Some of the most common gotchas: + - 🔸*AZ-to-AZ traffic:* Note EC2 traffic between AZs is effectively the same as between regions. For example, deploying a Cassandra cluster across AZs is helpful for [high availability](#high-availability), but can hurt on network costs. + - 🔸*Using public IPs when not necessary:* If you use an Elastic IP or public IP address of an EC2 instance, you will incur network costs, even if it is accessed locally within the AZ. + - 🔸*Managed NAT Gateway data processing:* Managed NAT Gateways are used to let traffic egress from private subnets--at a cost of 4.5¢ as a data processing fee layered on top of data transfer pricing. Past a certain point, running your own NAT instances becomes far more cost effective. + - 🔸*Some services do cross-AZ traffic for free:* Many AWS services you'd not consider on their own merits offer a hidden value of free cross-AZ data transfer. EFS, RDS, MSK, and others are examples of this. +- This figure gives an overview: + +![AWS Data Transfer Costs](figures/aws-data-transfer-costs.png) + +### EC2 Cost Management + +- With EC2, there is a trade-off between engineering effort (more analysis, more tools, more complex architectures) and spend rate on AWS. If your EC2 costs are small, many of the efforts here are not worth the engineering time required to make them work. But once you know your costs will be growing in excess of an engineer’s salary, serious investment is often worthwhile. +- Larger instances aren’t necessarily priced higher in the spot market – therefore, you should look at the available options and determine which instances will be most cost effective for your jobs. See [Bid Advisor](https://aws.amazon.com/ec2/spot/bid-advisor/). +- 🔹**Spot instances:** + - EC2 [Spot instances](https://aws.amazon.com/ec2/spot/) are a way to get EC2 resources at significant discount — often many times cheaper than standard on-demand prices — if you’re willing to accept the possibility that they be terminated with little to no warning. + - Use Spot instances for potentially very significant discounts whenever you can use resources that may be restarted and don’t maintain long-term state. + - The huge savings that you can get with Spot come at the cost of a significant increase in complexity when provisioning and reasoning about the availability of compute capacity. + - Amazon maintains Spot prices at a market-driven fluctuating level, based on their inventory of unused capacity. Prices are typically low but can [spike](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html#spot-bid-limit) very high. See the [price history](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances-history.html) to get a sense for this. + - You set a bid price high to indicate how high you’re willing to pay, but you only pay the going rate, not the bid rate. If the market rate exceeds the bid, your instance may be terminated. + - Prices are per instance type and per availability zone. The same instance type may have wildly different price in different zones at the same time. Different instance types can have very different prices, even for similarly powered instance types in the same zone. + - Compare prices across instance types for better deals. + - Use Spot instances whenever possible. Setting a high bid price will assure your machines stay up the vast majority of the time, at a fraction of the price of normal instances. + - Get notified up to two minutes before price-triggered shutdown by polling [your Spot instances’ metadata](https://aws.amazon.com/blogs/aws/new-ec2-spot-instance-termination-notices/), or by watching for [the termination CloudWatch event](https://aws.amazon.com/about-aws/whats-new/2018/01/amazon-ec2-spot-two-minute-warning-is-now-available-via-amazon-cloudwatch-events/). + - Make sure your usage profile works well for Spot before investing heavily in tools to manage a particular configuration. +- **Spot fleet:** + - You can realize even bigger cost reductions at the same time as improvements to fleet stability relative to regular Spot usage by using [Spot fleet](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html) to bid on instances across instance types, availability zones, and (through multiple Spot Fleet Requests) regions. + - Spot fleet targets maintaining a specified (and weighted-by-instance-type) total capacity across a cluster of servers. If the Spot price of one instance type and availability zone combination rises above the weighted bid, it will rotate running instances out and bring up new ones of another type and location up in order to maintain the target capacity without going over target cluster cost. +- **Spot usage best practices:** + - **Application profiling:** + - Profile your application to figure out its runtime characteristics. That would help give an understanding of the minimum cpu, memory, disk required. Having this information is critical before you try to optimize spot costs. + - Once you know the minimum application requirements, instead of resorting to fixed instance types, you can bid across a variety of instance types (that gives you higher chances of getting a spot instance to run your application).E.g., If you know that 4 cpu cores are enough for your job, you can choose any instance type that is equal or above 4 cores and that has the least Spot price based on history. This helps you bid for instances with greater discount (less demand at that point). + - **Spot price monitoring and intelligence:** + - Spot Instance prices fluctuate depending on instance types, time of day, region and availability zone. The AWS CLI tools and API allow you to describe Spot price metadata given time, instance type, and region/AZ. + - Based on history of Spot instance prices, you could potentially build a myriad of algorithms that would help you to pick an instance type in a way that **optimizes cost**, **maximizes availability**, or **offers predictable performance**. + - You can also track the number of times an instance of certain type got taken away (out bid) and plot that in graphite to improve your algorithm based on time of day. + - **Spot machine resource utilization:** + - For running spiky workloads (spark, map reduce jobs) that are schedule based and where failure is non critical, Spot instances become the perfect candidates. + - The time it takes to satisfy a Spot instance could vary between 2-10 mins depending on the type of instance and availability of machines in that AZ. + - If you are running an infrastructure with hundreds of jobs of spiky nature, it is advisable to start pooling instances to optimize for cost, performance and most importantly time to acquire an instance. + - Pooling implies creating and maintaining Spot instances so that they do not get terminated after use. This promotes re-use of Spot instances across jobs. This of course comes with the overhead of lifecycle management. + - Pooling has its own set of metrics that can be tracked to optimize resource utilization, efficiency and cost. + - Typical pooling implementations give anywhere between 45-60% cost optimizations and 40% reduction in spot instance creation time. + - An excellent example of Pooling implementation described by Netflix ([part1](http://techblog.netflix.com/2015/09/creating-your-own-ec2-spot-market.html), [part2](http://techblog.netflix.com/2015/11/creating-your-own-ec2-spot-market-part-2.html)\) +- **Spot management gotchas** + - 🔸**Lifetime:** There is [no guarantee](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) for the lifetime of a Spot instance. It is purely based on bidding. If anyone outbids your price, the instance is taken away. Spot is not suitable for time sensitive jobs that have strong SLA. Instances will fail based on demand for Spot at that time. AWS provides a [two-minute warning](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html#spot-instance-termination-notices) before Amazon EC2 must terminate your Spot instance. + - 🔹**API return data:** - The Spot price API returns Spot prices of varying granularity depending on the time range specified in the api call.E.g If the last 10 min worth of history is requested, the data is more fine grained. If the last 2 day worth of history is requested, the data is more coarser. Do not assume you will get all the data points. There **will** be skipped intervals. + - ❗**Lifecycle management:** Do not attempt any fancy Spot management unless absolutely necessary. If your entire usage is only a few machines and your cost is acceptable and your failure rate is lower, do not attempt to optimize. The pain for building/maintaining it is not worth just a few hundred dollar savings. +- **Reserved Instances:** allow you to get significant discounts on EC2 compute hours in return for a commitment to pay for instance hours of a specific instance type in a specific AWS region and availability zone for a pre-established time frame (1 or 3 years). Further discounts can be realized through “partial” or “all upfront” payment options. + - Consider using Reserved Instances when you can predict your longer-term compute needs and need a stronger guarantee of compute availability and continuity than the (typically cheaper) Spot market can provide. However be aware that if your architecture changes your computing needs may change as well so long term contracts can seem attractive but may turn out to be cumbersome. + - There are two types of Reserved Instances - [Standard and Convertible](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-types.html). If you purchase excess Standard Reserved Instances, you may offer to “sell back” unused Reserved Instances via the [Reserved Instance Marketplace](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-market-selling-guide.html), this allows you to potentially recoup the cost of unused EC2 compute instance hours by selling them to other AWS customers. + - Instance reservations are not tied to specific EC2 instances - they are applied at the billing level to eligible compute hours as they are consumed across all of the instances in an account. + - 📜There have been scattered reports of Convertible RI purchases needing to be exercised in a block-- namely, if you buy five convertible RIs in one purchase, you can't convert just two of them. Reach out to your account manager for clarification if this may impact you. +- If you have multiple AWS accounts and have configured them to roll charges up to one account using the “Consolidated Billing” feature, you can expect *unused* Reserved Instance hours from one account to be applied to matching (region, availability zone, instance type) compute hours from another account. +- If you have multiple AWS accounts that are linked with Consolidated Billing, plan on using reservations, and want unused reservation capacity to be able to apply to compute hours from other accounts, you’ll need to create your instances in the availability zone with the same *name* across accounts. Keep in mind that when you have done this, your instances may not end up in the same *physical* data center across accounts - Amazon shuffles availability zones names across accounts in order to equalize resource utilization. +- Make use of dynamic [Auto Scaling](#auto-scaling), where possible, in order to better match your cluster size (and cost) to the current resource requirements of your service. +- If you use RHEL instances and happen to have existing RHEL on-premise Red Hat subscriptions, then you can leverage Red Hat's [Cloud Access program](https://www.redhat.com/en/technologies/cloud-computing/cloud-access) to migrate a portion of your on-premise subscriptions to AWS, and thereby saving on AWS charges for RHEL subscriptions. You can either use your own self-created RHEL AMI's or Red Hat provided [Gold Images](https://access.redhat.com/articles/2962171) that will be added to your private AMI's once you sign up for Red Hat Cloud Access. + +Дополнительные материалы +--------------- + +Этот раздел охватывает несколько необычайно полезных и «обязательных для ознакомления» ресурсов или списков. + +- AWS + - [AWS In Plain English](https://www.expeditedssl.com/aws-in-plain-english): Удобно излагаемый обзор сервисов AWS. + - [Awesome AWS](https://github.com/donnemartin/awesome-aws): Отслеживаемый список продуктов и сервисов AWS. + - [AWS Tips I Wish I'd Known Before I Started](https://wblinks.com/notes/aws-tips-i-wish-id-known-before-i-started/): Сборник советов от [Rich Adams](https://richadams.me/) + - [AWS Whitepapers](https://aws.amazon.com/whitepapers/): Сборник официальных WhitePapers от AWS включающий в себя лучшие практики по организации доступности, безопасности и оптимизации расходов. + - [Last Week in AWS](https://lastweekinaws.com): Еженедельник, освещающий последние события в AWS. + - [AWS Geek](https://www.awsgeek.com): Блог AWS Community Hero Jerry Hargrove, с заметками и нарисованными от руки диаграммами о различных сервисах AWS. +- Книги + - [Amazon Web Services in Action](https://www.manning.com/books/amazon-web-services-in-action) + - [AWS Lambda in Action](https://www.manning.com/books/aws-lambda-in-action) + - [Serverless Architectures on AWS](https://www.manning.com/books/serverless-architectures-on-aws) + - [Serverless Single Page Apps](https://pragprog.com/book/brapps/serverless-single-page-apps) + - [The Terraform Book](https://terraformbook.com/) + - [AWS Scripted 2 book series](https://www.amazon.com/gp/product/B016QBB0GO?ref=series_rw_dp_labf) + - [Amazon Web Services For Dummies](https://www.amazon.com/dp/1118571835) + - [AWS System Administration](http://shop.oreilly.com/product/0636920027638.do) + - [Python and AWS Cookbook](http://shop.oreilly.com/product/0636920020202.do) + - [Resilience and Reliability on AWS](http://shop.oreilly.com/product/0636920026839.do) + - [AWS documentation as Kindle ebooks](https://www.amazon.com/Amazon-Web-Services/e/B007R6MVQ6) +- Общие ссылки на руководства + - [AWS Well Architected Framework Guide](https://d0.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf): Официальное руководство по лучшим практикам по вопросам cloud архитектуры в AWS. + - [Awesome Microservices](https://github.com/mfornos/awesome-microservices): Отслеживаемый список инструментов и технологий для микросервисных архитектур. Стоит просмотреть, чтобы узнать о популярных проектах с открытым исходным кодом.. + - [Is it fast yet?](https://istlsfastyet.com/): Обзор производительности сервисов на основе TLS от Ilya Grigorik + - [High Performance Browser Networking](https://hpbn.co/): Полная, современная книга о производительности веб-сети; презентация в части HTTP / 2 [тут](https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/edit?usp=sharing). + +Отказ от ответственности +---------- + +Авторы и соавторы данного произведения не могут гарантировать достоверность информации представленной в данном документе. Пожалуйста, удостоверьтесь, что вы понимаете, что информация представленная здесь, представлена бесплатно, и между вами и авторами данного документа/проекта нет никаких соглашений и контрактов. Авторы и добровольные участники проекта не несут никакой ответственности за любые потери, повреждения или сбои, вызванные ошибками или упущениями в информации, содержащейся в данном документе или как-то связанной с ним, независимо от того, вызваны ли такие ошибки или упущения халатностью, несчастным случаем или любой другой причиной. + +Информация о лицензии +------- + +[![Creative Commons License](https://i.creativecommons.org/l/by-sa/4.0/88x31.png)](http://creativecommons.org/licenses/by-sa/4.0/) + +Это произведение лицензировано согласно [Creative Commons Attribution-ShareAlike 4.0 International License](http://creativecommons.org/licenses/by-sa/4.0/).