From aa107159372bbb69173bf7280c351de9966d80d0 Mon Sep 17 00:00:00 2001 From: Nikolay Poida Date: Thu, 9 Apr 2020 02:13:01 +0600 Subject: [PATCH] Russian Translation (#1) Add Russian Translation of The Open Guide to Amazon Web Services --- translations/ru.md | 2464 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2464 insertions(+) create mode 100644 translations/ru.md diff --git a/translations/ru.md b/translations/ru.md new file mode 100644 index 0000000..2e88d31 --- /dev/null +++ b/translations/ru.md @@ -0,0 +1,2464 @@ +![Открытое руководство](../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) | [📘](#советы-по-eks) | [📙](#ошибки-и-ограничения-связанные-с-eks) | +| [EFS](#efs) | [📗](#основы-efs) | [📘](#советы-по-efs) | [📙](#ошибки-и-ограничения-связанные-с-efs) | +| [Elastic Beanstalk](#elastic-beanstalk) | [📗](#основы-elastic-beanstalk) | [📘](#советы-по-elastic-beanstalk) | [📙](#ошибки-и-ограничения-связанные-с-elastic-beanstalk) | +| [Elastic IPs](#elastic-ips) | [📗](#основы-elastic-ip) | [📘](#советы-по-elastic-ip) | [📙](#ошибки-и-ограничения-связанные-с-elastic-ip) | +| [ElastiCache](#elasticache) | [📗](#основы-elasticache) | [📘](#советы-по-elasticache) | [📙](#ошибки-и-ограничения-связанные-с-elasticache) | +| [EMR](#emr) | [📗](#основы-emr) | [📘](#советы-по-emr) | [📙](#ошибки-и-ограничения-связанные-с-emr) | +| [Fargate](#fargate) | [📗](#основы-fargate) | [📘](#советы-по-fargate) | [📙](#ошибки-и-ограничения-связанные-с-fargate) | +| [Glacier](#glacier) | [📗](#основы-glacier) | [📘](#советы-по-glacier) | [📙](#ошибки-и-ограничения-связанные-с-glacier) | +| [IoT](#iot) | [📗](##основы-iot) | [📘](#советы-по-iot) | [📙](#ошибки-и-ограничения-связанные-с-iot) | +| [Kinesis Firehose](#kinesis-firehose) | | | [📙](#ошибки-и-ограничения-связанные-с--kinesis-firehose) | +| [Kinesis Streams](#kinesis-streams) | [📗](#основы-kinesis-streams) | [📘](#советы-по-kinesis-streams) | [📙](#ошибки-и-ограничения-связанные-с-kinesis-streams) | +| [KMS](#kms) | [📗](#основы-kms) | [📘](#советы-по-kms) | [📙](#ошибки-и-ограничения-связанные-с-kms) | +| [Lambda](#lambda) | [📗](#основы-lambda) | [📘](#советы-по-lambda) | [📙](#ошибки-и-ограничения-связанные-с-lambda) | +| [Load Balancers](#балансировщики-нагрузкиload-balancers) | [📗](#основы-load-balancer) | [📘](#советы-по-load-balancer) | [📙](#ошибки-и-ограничения-связанные-с-load-balancer) | +| [Mobile Hub](#mobile-hub) | [📗](#основы-mobile-hub) | [📘](#советы-по-mobile-hub) | [📙](#ошибки-и-ограничения-связанные-с-mobile-hub) | +| [OpsWorks](#opsworks) | [📗](#основы-opsworks) | [📘](#советы-по-opsworks) | [📙](#ошибки-и-ограничения-связанные-с-opsworks) | +| [RDS](#rds) | [📗](#основы-rds) | [📘](#советы-по-rds) | [📙](#ошибки-и-ограничения-связанные-с-rds) | +| [RDS Aurora](#rds-aurora) | [📗](#основы-rds-aurora) | [📘](#rds-aurora-tips) | [📙](#rds-aurora-gotchas-and-limitations) | +| [RDS Aurora MySQL](#rds-aurora-mysql) | [📗](##основы-rds-aurora-mysql) | [📘](#советы-по-rds-aurora-mysql) | [📙](#ошибки-и-ограничения-связанные-с--rds-aurora-mysql) | +| [RDS Aurora PostgreSQL](#rds-aurora-postgresql) | [📗](#основы-rds-aurora-postgresql) | [📘](#советы-по-rds-aurora-postgresql) | [📙](#ошибки-и-ограничения-связанные-с-rds-aurora-postgresql) | +| [RDS MySQL и MariaDB](#rds-mysql-и-mariadb) | [📗](#основы-rds-mysql-и-mariadb) | [📘](#советы-по-rds-mysql-и-mariadb) | [📙](#ошибки-и-ограничения-связанные-с--rds-mysql-и-mariadb) | +| [RDS PostgreSQL](#rds-postgresql) | [📗](#основы-rds-postgresql) | [📘](#советы-по-rds-postgresql) | [📙](#ошибки-и-ограничения-связанные-с--rds-postgresql) | +| [RDS SQL Server](#rds-sql-server) | [📗](#основы-rds-sql-server) | [📘](#советы-по-rds-sql-server) | [📙](#ошибки-и-ограничения-связанные-с--rds-sql-server) | +| [Redshift](#redshift) | [📗](#основы-redshift) | [📘](#советы-по-redshift) | [📙](#ошибки-и-ограничения-связанные-с-redshift) | +| [Route 53](#route-53) | [📗](#основы-route-53) | [📘](#советы-по-route-53) | [📙](#ошибки-и-ограничения-связанные-с-route-53) | +| [S3](#s3) | [📗](#основы-s3) | [📘](#советы-по-s3) | [📙](#ошибки-и-ограничения-s3) | +| [Безопасность и IAM](#безопасность-и-iam) | [📗](#основы-безопасности-и-iam) | [📘](#советы-по-безопасности-и-iam) | [📙](#ошибки-и-ограничения-в-вопросе-обеспечения-безопасности-и-iam) | +| [SES](#ses) | [📗](#основы-ses) | [📘](#советы-по-ses) | [📙](#ошибки-и-ограничения-связанные-с-ses) | +| [SNS](#sns) | [📗](#основы-sns) | [📘](#советы-по-sns) | [📙](#ошибки-и-ограничения-связанные-с-sns) | +| [SQS](#sqs) | [📗](#основы-sqs) | [📘](#советы-по-sqs) | [📙](#ошибки-и-ограничения-связанные-с-sqs) | +| [Step Functions](#step-functions) | [📗](#основы-step-functions) | [📘](#советы-по-step-function) | [📙](#ошибки-и-ограничения-связанные-с-step-functions) | +| [WAF](#waf) | [📗](#основы-waf) | [📘](#советы-по-waf) | [📙](#ошибки-и-ограничения-связанные-с-waf) | +| [VPC, Сетевая безопасность и Группы безопасности](#vpc-сетевая-безопасность-и-группы-безопасности) | [📗](#основы-vpc) | [📘](#советы-по-vpc-и-сетевой-безопасности) | [📙](#ошибки-и-ограничения-связанные-с-vpc-и-сетевой-безопасностью) | + +**Особые темы** + +- [Высокая доступность](#высокая-доступность) +- [Платежи и управление расходами](#платежи-и-управление-расходами) +- [Дополнительные материалы](#дополнительные-материалы) + +**Правовая информация** + +- [Отказ от ответственности](#отказ-от-ответственности) +- [Информация о лицензии](#информация-о-лицензии) + +**Диаграммы и таблицы** + +[![Инструменты и услуги, представленные на рынке](../figures/aws-market-landscape-320px.png)](#инструменты-и-услуги-представленные-на-рынке) [![Стоимость передачи данных при работе с AWS](../figures/aws-data-transfer-costs-320px.png)](#aws-data-transfer-costs) + +- [Инфографика: Инструменты и услуги, представленные на рынке](#инструменты-и-услуги-представленные-на-рынке): Выборка сторонних компаний/продуктов +- [Инфографика: Стоимость передачи данных при работе с AWS](#затраты-на-передачу-данных-в-aws): Визуальный обзор расходов на передачу данных +- [Таблица: Матрица сервисов](#матрица-сервисов): Сравнение сервисов AWS с альтернативными вариантами +- [Таблица: Зрелось продуктов AWS и выпуски](#зрелость-продуктов-aws-и-выпуски): Релизы продуктов AWS +- [Таблица: Долговечность и надежность хранения, доступность и цена](#долговечность-и-надежность-хранения-доступность-и-цена): Количественное сравнение + +Почему открытое руководство? +------------------ + +Множество информации об 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. +- **Расходы:** Оплата и управление расходами настолько большие темы, что у нас есть [отдельный раздел на эту тему](#платежи-и-управление-расходами). +- 🔹**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](#vpc-сетевая-безопасность-и-группы-безопасности): Виртуальные сети, безопасность в сети, и ко-локейшн; используется автоматически + - [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)), которые обычно является первым инструментом в выборе средств для обеспечения [высокой доступности](#высокая-доступность)). Зоны доступности [физически разделены друг от друга](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, а вам это точно пригодится. Кроме того, вы можете также захотеть поставить какой-нибудь [сервис управления лог-файлами](#видимость) для поиска событий и доступа к этим лог-файлам. +- 🔹**Используйте 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 + +- 📒 [Домашняя страница](https://aws.amazon.com/s3/) ∙ [Руководство разработчика](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html) ∙ [ЧаВо](https://aws.amazon.com/s3/faqs/) ∙ [Расценки](https://aws.amazon.com/s3/pricing/) +- **S3** (Простой сервис хранения(Simple Storage Service)) это стандартный облачный сервис хранения данных AWS, предлагающий файловое (скорее “blob”) хранилище произвольного количества файлов любого размера от 0 до **5TB**. (До [2011 года](https://aws.amazon.com/releasenotes/Amazon-S3/1917932037969964) максимальный размер файла был 5 GB; большие файлы на текущий момент отлично поддерживаются посредством использования [поддержки разбиения на несколько частей](https://docs.aws.amazon.com/AmazonS3/latest/dev/mpuoverview.html).) +- Файлы или **объекты** помещаются в именованные **бакеты(buckets)** и хранятся под именами, также называемыми **ключами**. Основное содержимое - **значение**. +- Объекты создаются, удаляются или обновляются. Большие объекты могут быть потоковыми, но вы не можете изменять части значения; вам нужно обновить весь объект. Частичный доступ может работать через [S3 Select](https://aws.amazon.com/blogs/aws/s3-glacier-select/). +- У каждого объекта есть [**метаданные**](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html), которые включают в себя произвольные пары ключ-значение и используются аналогично заголовкам HTTP. Некоторые метаданные определяются системой, некоторые имеют значение при передаче HTTP-содержимого из контейнеров или CloudFront, вы также можете определить произвольные метаданные для своего собственного использования. +- **S3 URI:** Хотя часто имена бакетов и ключей предоставляются в API-интерфейсах по отдельности, обычной практикой является написание местоположения S3 в форме 's3://имя-бакета/путь/к/ключу' (где ключ и есть 'путь/к/ключу'). (Вам также встретятся префиксы 's3n://' и 's3a://' [в системах Hadoop](https://cwiki.apache.org/confluence/display/HADOOP2/AmazonS3).) +- **S3 и Glacier, EBS, EFS:** AWS предлагает несколько сервисов хранения данных, и некоторые, помимо S3, предлагают абстракцию файловой системы. [Glacier](#glacier) - это дешевое хранилище для архивирования и редкого доступа. [EBS](#ebs), в отличие от S3, позволяет произвольный доступ к содержимому файлов посредством традиционной файловой системы, но может быть одновременно подключен только к одному инстансу EC2. [EFS](#efs) - это сетевая файловая система, к которой может подключиться несколько инстансов, но стоит дороже. Смотрите [сравнительную таблицу](#долговечность-и-надежность-хранения-доступность-и-цена). + +### Советы по S3 + +- Для большинства практических целей можно считать емкость S3 неограниченной, как в общем размере файлов, так и по количеству объектов. Количество объектов в бакете также неограничено. Пользователи обычно имеют миллионы объектов. +- ❗**Разрешения:** + - 🔸Если вы храните бизнес-данные в Amazon S3, важно разумно управлять разрешениями. В 2017 году у компаний вроде[Dow Jones и Verizon](http://www.techrepublic.com/article/massive-amazon-s3-breaches-highlight-blind-spots-in-enterprise-race-to-the-cloud/) были утечки данных из-за слабо-настроенных конфигураций S3 для чувствительных данных. Исправление этого впоследствии может быть сложной задачей, если у вас множество файлов и внутренних пользователей. + - 🔸Существует три подхода выдачи разрешений на доступ к контенту в ваших бакетах Amazon S3. + + **Политики IAM** используют знакомую схему разрешений [IAM](#безопасность-и-iam) для контроля доступа к определенным операциям. + + **Политики бакета** позволяют выдавать разрешающие или запрещающие разрешения на весь бакет. Вы можете использовать их, когда размещаете веб-сайт в S3 для того, чтобы сделать бакет доступным общественности или запретить доступ к бакету по IP адресу. Amazon's [Примеры политик бакетов](http://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies.html) Amazon показывают несколько вариантов использования, когда эти политики могут вам пригодиться. + + **[Списки контроля доступа(Access Control Lists)](http://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html)** (ACL) могут быть применены к любому бакету и объекту, хранимому в S3. ACL предоставляют дополнительные разрешения помимом тех, которые описаны в политике бакета или IAM. ACL могут быть использованы для предоставления доступа другому пользователю AWS или преопределенной группе, например широкой общественности. Это мощный инструмент, но он может быть опасным потому, что вам необходимо проверить каждый объект, чтобы увидеть, кто имеет доступ к нему. + - 🔸[Предопределенные группы контроля доступа AWS](http://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#specifying-grantee-predefined-groups) разрешают доступ, который может быть не тем, что вы могли ожидать, исходя из их названия: + + **"Все пользователи" или "Все" предоставляет разрешения широкой публике**, а не только пользователям описанным в вашем аккаунте AWS. Если объект доступен Всем Пользователям, значит, что он может быть получен простым HTTP запросом вида `http://s3.amazonaws.com/bucket-name/filename`. Никакой авторизации или подписи не требуется для доступа данных в этой категории. + + **"Аутентифицированные пользователи" предоставляет разрешения любому с аккаунтом AWS**, опять же не ограничиваясь вашими личными пользователями. Так как каждый может зарегистрироваться в AWS, для любым целей и намерений, считайте, что **это тоже открыто для широкой публики**. + + **Группа "Доставка логов" используется AWS, чтобы писать логи в бакеты** и это вполне безопасно включать эту опцию на бакетах, для которых это необходимо. + + Обычным случаем использования данного ACL является использование в совокупности с функциональностью S3 [запрашивающий платит](http://docs.aws.amazon.com/AmazonS3/latest/dev/RequesterPaysBuckets.html). + - ❗ Разрешения бакета и разрешения объекта - две разные вещи, независимые друг от друга. Приватный объект в публичном бакете может быть виден в процессе просмотра бакета, но не может быть скачан. В то же время, публичный объект в приватном бакете не может быть увиден, потому что содержимое приватного бакета не может быть просмотрено, однако может быть скачан любым, кто знает его точный ключ. Пользователи, у которых нет доступа к установке разрешений бакета, все еще могут устанавливать публичные разрешения на объект если у них есть доступ к `s3:PutObjectAcl` и `s3:PutObjectVersionAcl` [разрешениям](http://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html). + - 🐥В августе 2017 года, AWS добавил [правила AWS Config для того, чтобы вы могли убедиться, что ваши бакеты S3 защищены](https://aws.amazon.com/blogs/aws/aws-config-update-new-managed-rules-to-secure-s3-buckets/). + + ❗Эти правила AWS Config проверяют только безопасность вашей политики бакетов и ACL на уровне бакетов. Вы по-прежнему можете создавать объектные ACL, которые предоставляют дополнительные разрешения, включая открытие файлов для всего мира. + - 🔹Создавайте новые бакеты, если у вас есть различные типы данных, с различной степенью критичности. Это намного проще и имеет меньшую вероятность допуска ошибок, нежели создание сложных правил и наборов разрешений. Как пример, если у вас есть данные только для администраторов, например логи, сложите их в новый бакет, к которому имеют доступ только администраторы. + - Для получения дополнительной информации смотрите: + + [Как обезопасить бакет Amazon S3](https://read.acloud.guru/how-to-secure-an-s3-bucket-7e2dbd34e81b) + + [Глубокое погружение в контроль доступа в S3](https://labs.detectify.com/2017/07/13/a-deep-dive-into-aws-s3-access-controls-taking-full-control-over-your-assets/). + + [Как работают разрешения S3?](https://brandonwamboldt.ca/understanding-s3-permissions-1662/). +- **Именование бакетов:** Бакеты создаются в глобальном пространстве имен (во всех регионах, даже если сам S3 хранит данные [в любом регионе, который бы вы не выбрали](https://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region), так что вы обнаружите, что множество имен для бакета уже выбрано. Создание бакета означает, что вы становитесь владельцем конкретного имени до тех пор пока не удалите его. Имена бакетов имеют [несколько ограничений](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html). + - Имена бакетов могут быть использованы как часть имени хоста, когда вы получаете доступ к бакету или его содержимому, вроде `.s3-us-east-1.amazonaws.com`, до тех пор пока имя соответствует стандарту [DNS имен](http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html). + - Обычной практикой является использование аббревиатуры или сокращения названия компании в качестве префикса (или суффикса, если вы предпочитаете иерархию в стиле DNS) для всех имен бакетов (но, пожалуйста, не используйте проверку этого в качестве меры безопасности - это крайне небезопасно и легко обойти!). + - 🔸Имена бакетов с '.' (точками) в них [может привести к несоответствию сертификатов](https://forums.aws.amazon.com/thread.jspa?threadID=169951), когда используется с SSL. Используйте '-' вместо этого, так как символ соответствует требованиям, как SSL, так и DNS. +- **Версионность:** S3 имеет [опциональную поддержку версионности](https://docs.aws.amazon.com/AmazonS3/latest/dev/ObjectVersioning.html), так что все версии объектов сохраняются в бакете. Это очень полезно, если вы хотите архивировать изменения и иметь возможность откатить ошибки (предупреждение: в нем отсутствует набор функций полноценных систем контроля версий, таких как Git). +- **Сохранность:** Сохранность данных в S3 экстремально высока, так как внутренне он сохраняет несколько реплик. Если вы случайно не удалили данные, вы можете расчитывать на то, что S3 не потеряет ваши данные. (AWS предлагает невероятный уровень сохранности данных - [99.999999999%](https://aws.amazon.com/s3/faqs/#How_durable_is_Amazon_S3), но это математический расчет основан на уровне независимых отказов и уровнях репликации, так что не он не являяется оценкой реальной вероятности. В любом случае у S3 [хорошие показатели](https://www.quora.com/Has-Amazon-S3-ever-lost-data-permanently) сохранности данных.) Имейте ввиду, что S3 *имеет намного более высокий* уровень сохранности, чем EBS! +- 💸**Расценки S3** зависят от [типа хранилища, запросов и передачи данных](https://aws.amazon.com/s3/pricing/). + - Передача данных в AWS бесплатна, но вы будете платить, когда передача данных будет с AWS. Передача с S3 на EC2 в *одном и том же регионе* бесплатна. Передача в другие регионы или в интернет в общем не является бесплатной. + - Удаление бесплатно. +- **S3 со сниженной отказоустойчивостью и нечастым доступом(S3 Reduced Redundancy and Infrequent Access):** Большинство людей использует класс стандартного хранения в S3, но существуют другие классы хранения с более низкой ценой: + - 🔸[Хранилище со сниженной отказоустойчивостью(Reduced Redundancy Storage (RRS))](https://aws.amazon.com/s3/reduced-redundancy/) фактически [устарело](https://www.lastweekinaws.com/blog/s3-reduced-redundancy-storage-is-dead/) и имело меньший уровень сохранности данных (99.99%, всего четыре девятки), нежели стандартный S3. Имейте ввиду, что он больше не рассматривается, как вариант снижения затрат на S3, так как он предлагает худшую отказоустойчивость за большие деньги, нежели стандартный S3. В результате, нет никаких причин использовать его. + - [Редкий доступ(Infrequent Access (IA))](https://aws.amazon.com/s3/storage-classes/#Infrequent_Access) позволяет вам получить более дешевое хранение в обмен на более дорогой доступ. Это отличный вариант для архивных данных, таки как логи, которые вы уже обработали, но возможно захотите просмотреть позднее. Чтобы получить представление об экономии средств при использовании Infrequent Access (IA), вы можете использовать этот [калькулятор S3 Infrequent Access](http://www.gulamshakir.com/apps/s3calc/index.html). + - [Интеллектуальное переключение уровней S3(S3 - Intelligent Tiering)](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/) - класс хранения предназначенный для оптимизации затрат за счет автоматического перемещения данных на самый экономически эффективный уровень доступа без ущерба для производительности или операционных издержек. + - [Одна зона - нечастный доступ - S3(S3 - One Zone - IA)](https://aws.amazon.com/s3/storage-classes/#__) предназначен для данных, доступ к которым осуществляется реже, но при необходимости требуется быстрый доступ. В отличие от других классов хранения S3, которые хранят данные как минимум в трех зонах доступности (AZ), S3 One Zone-IA хранит данные в одном AZ и стоит на 20% дешевле, чем S3 Standard-IA. + - [Glacier](#glacier) является отдельной альтернативой, обсуждаемой как отдельный продукт. + - Ознакомьтесь со [сравнительной таблицей](#долговечность-и-надежность-хранения-доступность-и-цена). +- ⏱**Производительность:** Максимизация производительности S3 означает улучшение общей пропускной способности с точки зрения пропускной способности и количества операций в секунду. + - S3 обладает высокой масштабируемостью, поэтому, в принципе, вы можете получить произвольно высокую пропускную способность. (Хороший пример - [S3DistCp](https://docs.aws.amazon.com/ElasticMapReduce/latest/ReleaseGuide/UsingEMR_s3distcp.html).) + - Однако, обычно вы ограничены пропускной способностью канала между источником и S3 и/или уровнем параллелизма операций. + - Пропускная способность, конечно, самая высокая между AWS и S3(внутри AWS), а также между инстансами EC2 и бакетами S3, которые находятся в одном регионе. + - Пропускная способность с EC2 зависит от типа инстанса. Обратите внимание на столбец “Сетевая производительность(Network Performance)” на [ec2instances.info](http://www.ec2instances.info/). + - Пропускная способность чрезвычайно высока при распределенном доступе к данным с множества инстансов EC2. Можно читать или записывать объекты в S3 с сотен или тысяч инстансов одновременно. + - Тем не менее, пропускная способность очень ограничена, когда объекты запрашиваются последовательно с одного инстанса. Отдельные операции занимают много миллисекунд, а пропускная способность для инстансов ограничена. + - Таким образом, для того, чтобы производить множество операций - необходимо использовать несколько рабочих потоков и соединений с отдельных иснстансов, а для еще более крупных задач - использовать множество инстансов EC2. + - **Загрузка несколькими частями:** Для больших объектов вы можете воспользоваться удобством возможности загрузки несколькими чамтями (начиная с минимального куска данных размером в 5 MB). + - **Большие скачивания:** Также вы можете скачать куски одного большого объекта параллельно, благодаря возможности использования заголовка HTTP GET range. + - 🔸**Разбиение списка по страницам:** Просмотр содержимого происходит путем получения 1000 ответов на запрос, таким образом для бакетов со многими миллионами объектов - просмотр займет долгое время. + - ❗**Префиксы ключей:** Ранее требовалась произвольная полсдеовательность в начале имени ключа, чтобы избежать горячих точек(снижения производительности), но теперь это [не является необходимым](https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/) по состоянию на июль 2018 года. + - Для данных вне AWS, [**DirectConnect**](https://aws.amazon.com/directconnect/) и [**S3 Transfer Acceleration**](https://aws.amazon.com/blogs/aws/aws-storage-update-amazon-s3-transfer-acceleration-larger-snowballs-in-more-regions/) могут помочь. За использование S3 Transfer Acceleration, вы [платите](https://aws.amazon.com/s3/pricing/) примерно столько же, сколько за 1-2 месяца хранения, за передачу в любом направлении при использовании ближайших входных точек. +- **Приложения для коммандной строки:** Существует несколько путей использования S3 из командной строки: + - Изначально, [**s3cmd**](https://github.com/s3tools/s3cmd) был лучшим иструментом для этой задачи. И он до сих пор массово используется. + - Обычный интерфейс командной строки [**aws**](https://aws.amazon.com/cli/) сейчас прекрасно поддерживает S3 и полезен в большинстве ситуаций. + - [**s4cmd**](https://github.com/bloomreach/s4cmd) - это обновленная замена, с большим акцентом на производительности с использованием многопоточности, что может быть полезно при работе с крупными файлами или большими наборами файлов, а также имеет поддержку Unix-подобного глоббинга, то есть замены символов звездочкой и вопросительным знаком. +- **Приложения с графическим интерфейсом(GUI applications):** Вы можете предпочитать работу с графическим интерфейсом, или вам необходима поддержка доступа через графический интерфейс для пользователей с меньшими техническими навыками. Вот несколько вариантов: + - [Консоль AWS](https://aws.amazon.com/console/) предлагает графический вариант использования S3. С предосторожностью предоставляйте ее использование не техническому персоналу, так как, без жестких разрешений, посредством консоли предоставляется доступ ко многим другим ресурсам и функциям AWS. + - [Transmit](https://panic.com/transmit/) хороший вариант на macOS для большинства случаев использования. + - [Cyberduck](https://cyberduck.io/) хороший вариант на macOS и Windows с поддержкой загрузки по частям, списков контроля доступа, версионностью, конфигурацией жизненного цикла, классами хранения и шифрованием на стороне сервера (SSE-S3 и SSE-KMS). +- **S3 и CloudFront:** S3 тесно интегрирован с CloudFront CDN. Ознакомьтесь с разделом посвященным CloudFront для получения подробной информации, также как и [S3 transfer acceleration](https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html). +- **Размещение статичных веб-сайтов:** + - У S3 есть [возможность размещения статичных веб-сайтов](http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html) которая является простой настройкой, которая включает настраиваемые страницы, начальную и страницу ошибки, а также имеет [поддержку перенаправления HTTP](http://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-redirect.html) к [общедоступному содержимому](http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteAccessPermissionsReqd.html) в S3. Это крайне простой способ размещать статичные данные или полностью статичный веб-сайт. + - Рассмотрите возможность использования CloudFront для большинства или для всех данных: + - Как любая сеть доставки контента, CloudFront серьезно повышает производительность. + - 🔸SSL поддерживается только для встроенного домена amazonaws.com в S3. S3 поддерживает обслуживания сайтов через [частные домены](http://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html), однако [не поддерживает SSL на частных доменах](http://stackoverflow.com/questions/11201316/how-to-configure-ssl-for-amazon-s3-bucket). В любом случае, [CloudFront позволяет вам обслуживать частные домены через https](http://docs.aws.amazon.com/acm/latest/userguide/gs-cf.html). Amazon предоставляет бесплатные SSL/TLS сертификаты с поддержкой SNI посредством Amazon Certificate Manager. [SNI не работает на устаревших браузерах/операционных системах](https://en.wikipedia.org/wiki/Server_Name_Indication#Support). В любом случае, вы можете предоставить свой собственный сертификат для использования в CloudFront для поддержки всех браузеров/операционных систем, но за плату. + - 🔸Если вы используете ресурсы с разных доменов, как например шрифты, внутри ваших файлов CSS, вам может быть необходимо [настроить CORS](https://docs.aws.amazon.com/AmazonS3/latest/dev/cors.html) для бакетов, обслуживающих эти ресурсы. + - Поскольку в настоящее время практически все переходит на SSL и вам, вероятно, нужен контроль над доменом, вы, вероятно, захотите настроить CloudFront со своим собственным сертификатом для S3 (и проигнорировать [этот пример от AWS ](http://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html) так как он не без SSL). + - Тем не менее, если вы это сделаете, вам нужно продумать инвалидацию файлов или обновления CloudFront. Возможно вы пожелаете [включить версии или хэши в именах файлов](https://abhishek-tiwari.com/CloudFront-design-patterns-and-best-practices), таким образом инвалидация не потребуется. +- **Жизненные циклы данных:** + - При управлении данными понимание жизненного цикла данных так же важно, как и понимание самих данных. Когда вы помещаете данные в бакет, подумайте об их жизненном цикле - окончании, а не только начале. + - 🔹Как правило, данные с разными политиками истечения срока действия должны храниться под отдельными префиксами в начале. Например, некоторые объемные лог файлы должны автоматически удаляться ежемесячно, в то время, как другие данные критичны и никогда не должны удаляться. Хранение ранних данных в отдельном бакете или в отдельной папке - весьма разумно. + - 🔸Если подумать об этом заранее - это поможет избежать многих проблем в будущем. Очень сложно чистить большие наборы файлов созданные многими инженерами с разными жизненными циклами и отсутствием какой-либо цельной организации. + - Также вы можете настроить политику жизненного цикла для архивации старых данных в Glacier. [Будьте аккуратны](https://alestic.com/2012/12/s3-glacier-costs/) при архивации большого количества маленьких объектов в Glacier, так как это может стоить еще дороже. + - Также существует класс хранения, называемый [**Нечастый доступ(Infrequent Access)**](https://aws.amazon.com/s3/storage-classes/#Infrequent_Access) который имеет тот же уровень сохранности данных, как и стандартный S3, но стоит дешевле за GB. Он подходит для объектов, к которым редко обращаются. +- **Согласованность данных:** Понимание [согласованности данных](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) крайне важно для любого использования S3, так как тут есть несколько производителей и потребителей данных. + - Создание и обновление индивидуальных объектов в S3 **атомарное(atomic)**, таким образом у вас никогда не будет ситуации, что вы обновляете иил загружаете новый объект, а другой клиент видит только часть изменений. + - Неопределенность заключается в том, *когда* вы и ваши клиенты увидят обновления. + - **Новые объекты:** Если вы создаете новый объект, вы сможете немедленно его прочитать, что называется **согласованность чтения-после-записи(read-after-write consistency)**. + - К слову, дополнительно необходимо предупредить, что если вы пытаетесь прочесть объект до его создания, а потом создаете его [вы получаете возможную согласованность](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) (не чтения-после-записи). + - Это не относится к операциям просмотра; впервые созданные объекты [не гарантированно сразу появятся при операциях просмотра содержимого бакетов](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) + - **Обновления объектов:** Если вы перезаписываете или удаляете объект, вы получаете только гарантированную **возможноую согласованность(eventual consistency)**, то есть изменение будет применено, но нет никаких гарантий когда. + - 🔹Для большинства случаев использования, принятие решения об использовании объектов S3, как **неизменных** (то есть предварительно приняв решение, что объекты будут либо создаваться, либо удаляться, но не обновляться) может крайне сильно упростить код, использующий объекты, путем исключения сложного управления состоянием объектов. + - 🔹Имейте ввиду, что [до 2015 года](https://aws.amazon.com/about-aws/whats-new/2015/08/amazon-s3-introduces-new-usability-enhancements/), регион'us-standard' имел более слабую модель возможной согласованности, а другие (более новые) регионы могли считывать после записи. Это наконец-то было исправлено - но вы можете почитать множество старых блогов, рассказывающих об этом. + - **Медленные обновления:** На практике, “возможная согласованность” обычно означает получение результата через секунд, за исключением редких случаев, когда согласованность возникает через минуты или даже [часы](http://www.stackdriver.com/eventual-consistency-really-eventual/). +- **S3 как файловая система:** + - В общем, API S3 имеет внутренние ограничения, которые делают сложным использование S3 в качестве POSIX-подобной файловой системы, при сохранении собственного объектного формата S3. Как пример, добавление данных в файл требует перезаписи, что крайне сильно снижает производительность, кроме того, невозможно атомарное переименование директорий, взаимное изолирование при работе с файлами и жесткие ссылки также не поддерживаются. + - [s3fs](https://github.com/s3fs-fuse/s3fs-fuse) это файловая система типа FUSE(filesystem in user environment - файловая система в пользовательском окружении) которая продолжает развитие и, несмотря ни на что, продолжает попытки улучшения, но имеет ограничения производительности и посему удивляет, что вообще поддерживается. + - [Riofs](https://github.com/skoobe/riofs) (на C) и [Goofys](https://github.com/kahing/goofys) (на Go) являются более поздними усилиями применить другой формат хранения данных в целях решения подобных проблем, и похоже являются улучшениями s3fs. + - [S3QL](https://github.com/s3ql/s3ql) ([обсуждение](https://news.ycombinator.com/item?id=10150684)) это реализация на Python, которая предлагает поддержку дедупликации данных, мгновенных снимков(снапшотов) и шифрование, но имеет ограничение на одновременное использование только одним пользователем. + - [ObjectiveFS](https://objectivefs.com/) ([обсуждение](https://news.ycombinator.com/item?id=10117506)) это коммерческое решение, которое поддерживает функционал файловой системы и конкурентные подключения. +- Если вы изначально используете VPC, рассмотрите возможность установки [выходной точки VPC(VPC Endpoint)](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html) для S3 в целях обеспечения возможности ресурсов размещенных в VPC легко получать доступ в S3 без дополнительных сетевых настроек или дополнительных узлов. +- **Межрегиональная репликация:** S3 имеет [возможность](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) репликации бакетов между регионами. Имейте ввиду, что S3 итак сильно реплицируется внутри одного региона, так что это обычно не является необходимым для сохранности данных, однако это может быть необходимо для соответствия правилам и стандартам (географически распределенное хранение даннных), снижения задержек или как стратегия по снижению затрат на передачу даннных между регионами путем зеркалирования часто используемых данных во втором регионе. +- **IPv4 и IPv6:** В течении долгого времени S3 поддерживал только IPv4 на стандартной выходной точке `https://BUCKET.s3.amazonaws.com`. Как бы там не было, [по состоянию на 11 августа 2016 года](https://aws.amazon.com/blogs/aws/now-available-ipv6-support-for-amazon-s3/) он теперь поддерживает как IPv4, так и IPv6! Чтобы использовать оба, вам необходимо [включить двойной стэк (dualstack)](http://docs.aws.amazon.com/AmazonS3/latest/dev/dual-stack-endpoints.html), либо используя предпочитаемый клиент API или напрямую, используя выходную точку `https://BUCKET.s3.dualstack.REGION.amazonaws.com`. Это также относится к S3 Transfer Acceleration. +- **Оповещения о событиях S3:** S3 может быть настроен для отправки [оповещений SNS](https://aws.amazon.com/blogs/aws/introducing-the-amazon-simple-notification-service/), [сообщений в SQS](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/Welcome.html), или вызова [функции AWS Lambda](http://docs.aws.amazon.com/lambda/latest/dg/welcome.html) в ответ на [события бакетов](http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html). +- 💸Ограничьте пользователям (или ролям IAM) доступ к только минимальным необходимым объектам и бакетам в S3, и ведите учет “разрешенных” путей. Иначе, S3 постепенно превращается в свалку, куда люди закидывают данные в различные расположения, которые потом годами не очищаются, что, в итоге, может обойтись очень дорого. +- Если бакет удаляется из S3, может потребоваться до 10 часов, пока бакет с тем же именем может быть создан заново. ([обсуждение](https://forums.aws.amazon.com/thread.jspa?threadID=37532)) + +### Ошибки и ограничения S3 + +- ❗Бакеты S3 находятся вне VPC и могут быть доступны с любого места в мире, если полтитики бакета не запрещают этого. Прочтите раздел о разрешениях тщательно, существует неисчислимое количество случаев, когда бакеты были случайно открыты широкой публике. +- 🔸В течении многих лет, существовал пресловутый лимит [**в 100 бакетов**](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_s3) на учетную запись, который не мог быть увеличин, и доставлял много проблем многим компаниям. По состоянию на 2015 год, вы можете [запросить увеличение лимита](https://aws.amazon.com/about-aws/whats-new/2015/08/amazon-s3-introduces-new-usability-enhancements/). Вы можете запросить увеличение лимита, но он все равно будет ограничен (обычно меньше 1000 на учетную запись). +- 🔸Будьте аккуратны, чтобы не делать неявных предположений о транзакционности или последовательности обновлений объектов. Никогда не думайте, что если вы измените последовательность объектов, клиенты увидят одинаковые изменения в одной и той же последовательности или если вы загрузите целую кучу файлов, то все они появятся сразу для всех клиентов. +- 🔸У S3 есть [**SLA**](https://aws.amazon.com/s3/sla/) гарантирующее 99.9% времени работоспособности. Если вы интенсивно используете S3, вы неизбежно увидите случайную ошибку при доступе или хранении данных при сбое дисков или другой инфраструктуры. Доступность обычно восстанавливается за секунды или минуты. Хотя доступность не очень высока, как уже упоминалось выше, сохранность данных отличная. +- 🔸После загрузки, любое изменение объекта приводит к полной перезаписи объекта, поэтому старайтесь избегать операций добавления данных в файлы. +- 🔸Последовательная согласованность данных, как обсуждалось выше, иногда может удивлять. Если в S3 существуют проблемы внутренней репликации, объект может быть виден по разному с набора машин, в зависимости от того, на какую выходную точку S3 они обращаются. Эта проблема обычно разрешается за секунды, однако мы наблюдали отдельные случаи, когда проблема растягивалась на 20-30 часов. +- 🔸**MD5 и загрузка по частям:** В S3, [заголовок ETag](http://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonResponseHeaders.html) является хэшем объекта. В большинстве случаев - это хэш MD5. В любом случае, это [в целом не так](http://stackoverflow.com/questions/12186993/what-is-the-algorithm-to-compute-the-amazon-s3-etag-for-a-file-larger-than-5gb) когда вы используете загрузку по частям. Одним из методов обхода - вычислить хэши MD5 самостоятельно и добавить их в отдельный заголовок (это может быть сделано с помощь [s4cmd](https://github.com/bloomreach/s4cmd)). +- 🔸**Затраты за незавершенную загрузку по частям:** Незавершенные загрузки по частям приводят к [затратам за хранение](http://docs.aws.amazon.com/AmazonS3/latest/dev/mpuoverview.html#mpuploadpricing) даже в том случае, если загрузка оборвалась и объект S3 не был создан. [Amazon](http://docs.aws.amazon.com/AmazonS3/latest/dev/mpuoverview.html#mpu-abort-incomplete-mpu-lifecycle-config) ([и](http://www.deplication.net/2016/06/aws-tip-save-s3-costs-with-abort.html) [другие](https://www.sumologic.com/aws/s3/s3-cost-optimization/)) рекомендуют использовать политики жизненного цикла, для очистки незавершенных загрузок и уменьшения затрат за храненеие данных. Имейте ввиду, что если у вас много таких случаев, возможно стоит разобраться почему загрузки часто обрываются. +- 🔸**Регион US Standard:** Ранее, регион us-east-1 (также известный, как регион US Standard) реплицировался между побережьями, что приводило к большой вариативности задержек. Начиная с 19 июня 2015 года [это уже не так](https://forums.aws.amazon.com/ann.jspa?annID=3112). Все регионы Amazon S3 теперь поддерживают согласованность данных чтение-после-записи. Amazon S3 также переименовал регион US Standard на US East (N. Virginia) чтобы соответствовать соглашению по именованию регионов AWS. +- 🔸**Регионы и версии аутентификации S3:** В новых регионах S3 [поддерживает только последнюю версию аутентификации](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingAWSSDK.html#specify-signature-version). Если файловая операция S3 через CLI или SDK не работает в одном регионе, но работает правильно в другом регионе, убедитесь, что вы используете последнюю [аутентификационную подпись](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html). + +### Долговечность и надежность хранения, доступность и цена + +В качестве иллюстрации сравнительных характеристик и цены в таблице ниже приведены S3 Standard, RRS, IA по сравнению с [Glacier](#glacier), [EBS](#ebs), [EFS](#efs), и инстанс EC2 d2.xlarge в регионе **Virginia** по состоянию на **сентябрь 2017 года**. + +| | Сохранность данных (в год) | Доступность “проектная” | Доступность согласно SLA | Цена за хранение (за TB в месяц) | GET или получение (за миллион) | Запись или архивация (за миллион) | +|-----------------|------------------------|-------------------------|------------------|--------------------------------------------------------------------------------------------------------------------------|-------------------------------|--------------------------------| +| **Glacier** | Одиннадцать 9ок | Мееедлеенно | – | $4 | $50 | $50 | +| **S3 IA** | Одиннадцать 9ок | 99.9% | **99%** | $12.50 | $1 | $10 | +| ~~**S3 RRS**~~ | ~~**99.99%**~~ | ~~99.99%~~ | ~~99.9%~~ | ~~$24 (первый TB)~~ | ~~$0.40~~ | ~~$5~~ | +| **S3 Standard** | Одиннадцать 9ок | 99.99% | 99.9% | $23 | $0.40 | $5 | +| **EBS** | **99.8%** | Не определено | 99.99% | $25/$45/**$100**/$125+ ([sc1/st1/**gp2**/io1](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)\) | | | +| **EFS** | “Высокая” | “Высокая” | – | $300 | | | +| **EC2 d2.xlarge instance store** | Не определено | Не определено | – | $25.44 | $0 | $0 | + +Особенно важные момент выделены **жирным шрифтом**. Источники: [Расценки S3](https://aws.amazon.com/s3/pricing/), [S3 SLA](https://aws.amazon.com/s3/sla/), [S3 ЧаВо](https://aws.amazon.com/s3/faqs/), [информация об RRS ](https://aws.amazon.com/s3/reduced-redundancy/) (имейте ввиду, что он устарел), [Расценки Glacier](https://aws.amazon.com/glacier/pricing/), [Доступность EBS и сохранность данных](https://aws.amazon.com/ebs/details/#Amazon_EBS_Availability_and_Durability), [Расценки EBS](https://aws.amazon.com/ebs/pricing/), [Расценки EFS](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)** являются сложными темами. Они могут варьироваться с полностью бесплатных (во время использования [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). + +### Советы по 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) с 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 + +- 📒 [Домашняя страница](https://aws.amazon.com/efs/) ∙ [Руководство пользователя](http://docs.aws.amazon.com/efs/latest/ug) ∙ [ЧаВо](https://aws.amazon.com/efs/faq/) ∙ [Расценки](https://aws.amazon.com/efs/pricing/) +- 🐥**EFS** это сетевая файловая система Amazon. Она представляет из себя сервер [NFSv4.1](https://en.wikipedia.org/wiki/Network_File_System#NFSv4). Любой клиент совместимый NFSv4 может подключить ее. +- Она разработана для обеспечения высокой доступности и надежности, и каждый объект файловой системы EFS избыточно хранится в нескольких зонах доступности. +- EFS предназначена для использования в качестве общего сетевого диска и может автоматически масштабироваться до петабайт хранимых данных и тысяч инстансов, подключенных к нему. +- EFS может предложить [более высокую пропускную способность](http://docs.aws.amazon.com/efs/latest/ug/performance.html) (множество гигабайт в секунду) более высокую надежность и доступность нежели EBS (смотрите [сравнительную таблицу](#долговечность-и-надежность-хранения-доступность-и-цена)), но при этом задержки будут выше. +- Цена EFS основана на объеме хранимых данных и стоит [намного дороже, чем EBS](#долговечность-и-надежность-хранения-доступность-и-цена); Это примерно в три раза больше по сравнению с томами общего назначения gp2 в EBS. +- ⏱ [Производительность](http://docs.aws.amazon.com/efs/latest/ug/performance.html) зависит от объема хранимых данных, как и цена: + - Как и EBS, EFS использует кредитную систему. Кредиты зарабатываются с частотой 50 KiB/s на GiB хранилища и потребляются для увеличения скорости во время чтения/записи файлов и метаданных. В отличии от EBS, операции на метаданных (размер файла, владелец, дата создания и т.д.) также потребляют кредиты. [Метрика BurstCreditBalance](http://docs.aws.amazon.com/efs/latest/ug/monitoring-cloudwatch.html#efs-metrics) в CloudWatch должна мониториться, чтобы убедиться, что файловая система не осталась без кредитов. + - Максимальный объем пропускной способности во время ускорения также зависит от размеров хранимых данных. До 1 TiB - пропускная способность может доходить до 100 MiB/s. Выше этого знанчения, 100 MiB/s добавляется за каждый хранимый TiB. Например, файловая система хранящая 5 TiB может разгоняться до скорости в 500 MiB/s. Максимальная пропускная способность на инстанс EC2 - 250 MiB/s. + - EFS имеет два режима производительности, которые могут быть выбраны когда создается файловая система. Первый "General Purpose", второй "Max I/O". Max I/O масштабируется больше, но ценой более высоких задержек. Если сомневаетесь, используйте General Purpose, который также является выбором по умолчанию. Если [метрика PercentIOLimit](http://docs.aws.amazon.com/efs/latest/ug/monitoring-cloudwatch.html#efs-metrics) в CloudWatch колеблется около 100%, рекомендуется Max I/O. Изменение режима производительности означает создание новой EFS и перенос данных. +- Высокая доступность достигается наличием [точек подключения в различных подсетях/зонах доступности](http://docs.aws.amazon.com/efs/latest/ug/images/overview-flow.png). + +### Советы по EFS + +- Поскольку EFS основана на NFSv4.1, любой каталог в EFS можно подключить напрямую, он не обязательно должен быть корневым каталогом. Одно приложение может подключить *fs-12345678:/prog1*, другое - *fs-12345678:/prog2*. +- [Разрешения на уровне групп и пользователей](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-nfs-permissions.html) можно использовать для контроля доступа к конкретным директориям на файловой системе EFS. +- ⏱ **Совместное использование файловых систем EFS:** Одна файловая система EFS может использоваться для нескольких приложений или служб, но это следует тщательно продумать: + + Плюсы: + - Поскольку производительность основана на общем размере хранимых файлов, размещение всего на одном диске повысит производительность для всех. Одно приложение, потребляющее кредиты быстрее, чем оно может накопить, может быть компенсировано другим приложением, которое просто хранит файлы в EFS и редко обращается к ним. + + Минусы: + - Поскольку кредиты используются совместно, если одно приложение использует их чрезмерно, это повлияет на другие. + - Компромисс сделан в отношении [безопасности](http://docs.aws.amazon.com/efs/latest/ug/security-considerations.html): все клиенты будут иметь сетевой доступ к диску. Кто-то с правами доступа root на одном инстансе клиента может подключить любой каталог в EFS, и у него будет доступ на чтение и запись ко всем файлам на диске, даже если у них нет доступа к приложениям, размещенным на других клиентах. Для EFS нет эквивалента no-root-squash. + +### Ошибки и ограничения, связанные с EFS + +- 🔸 Ряд функций NFSv4.1 [не поддерживается](http://docs.aws.amazon.com/efs/latest/ug/nfs4-unsupported-features.html) также существуют некоторые [лимиты](http://docs.aws.amazon.com/efs/latest/ug/limits.html) сервиса. +- 🔸 По состоянию на 08/2017, EFS предлагает возможность шифрования на уровне диска для новых дисков. Для файловых систем созданнных до этой даты, возможность шифрования может быть достигнута только переносом данных на новый том EFS. +- 🔸 Файловая система EFS [может быть подключена локально](https://aws.amazon.com/efs/faq/#on-premises) через Direct Connect. +- 🔸 Файловая система EFS не может быть подключена через сопряжение VPC или VPN, даже если VPN действует поверх Direct Connect. +- 🔸 Использование тома EFS в Windows не поддерживается. +- ⏱ Когда файл загружается в EFS, EFS может потребоваться несколько часов, чтобы обновить данные для выставления счетов и начисления кредитов. +- 🔸⏱ Операции с метаданными могут быть дорогостоящими с точки зрения массового потребления кредитов. При рекурсивном обходе дерева, содержащего тысячи файлов, можно легко увеличить потребление десятков или даже сотен мегабайт кредитов, даже если к файлам не притронулись. Команды типа ```find``` или ```chown -R``` могут оказать негативное влияние на производительность. + + +Балансировщики нагрузки(Load Balancers) +-------------- + +### Основы Load Balancer + +- AWS предлагает три продукта в области балансировки нагрузки - “Классические балансировщики нагрузки(Classic Load Balancers)” (CLBs), “Программные балансировщики нагрузки(Application Load Balancers)” (ALBs), и "Сетевые балансировщики нагрузки (Network Load Balancers)" (NLB). +- До появления ALB, “Классические балансировщики нагрузки” были известны, как “Эластичные балансировщики нагрузки(Elastic Load Balancers)” (ELBs), поэтому в более ранней документации, инструментах и публикациях в блогах все еще могут содержаться ссылки на “ELB”. +- CLB существуют с 2009 года, ALBs с 2016 года, NLBs были добавлены в AWS в 2017 году. +- CLB поддерживает балансировку нагрузки по TCP и HTTP. ALB поддерживает балансировку нагрузки только по HTTP. NLB поддерживает балансировку нагрузки по TCP на 4 уровне модели OSI. +- CLB и ALB может дополнительно терминировать SSL для одного сертификата SSL. +- Все они могут при необходимости выполнять активные проверки работоспособности инстансов и удалять их из пула назначения, если они стали не прошли проверку. +- CLB не поддерживает сложную, основанную на правилах, маршрутизацию. ALB поддерживает набор (на текущий момент не особо большой) вариантов маршрутизации, основанных на правилах. NLB предлагает самые широкие возможности маршрутизации. +- CLB может перенаправлять трафик только на один глобально настроенный порт в целевых инстансах, в то время как ALB может перенаправлять на порты, которые настроены для каждого инстанса, что лучше поддерживает маршрутизацию к службам в общих кластерах с динамическим назначением портов (например, ECS или Mesos). NLB поддерживает несколько портов на одном и том же IP-адресе; регистрацию целевых направлений по IP-адресам, включая целевые направления вне VPC, в котором находится балансировщик нагрузки; ECS может выбрать неиспользуемый порт для планирования таска, а затем зарегистрировать целевую группу, используя этот порт. +- CLB поддерживаются, как в EC2 Classic, так и в VPC, в то время как ALB поддерживаются только в VPC. +- ALB могут использовать в целевых группах группы инстансов и цели на основе IP в диапазонах RFC1918, что позволяет использовать их для направления траффика на локальные сервера через VPN или Direct Connect. + +### Советы по Load Balancer + +- Если у вас заранее нет какого-либо мнения относительно балансировки нагрузки и нет сложных требований по балансировке нагрузки на основе специфичной для конкретного приложения маршрутизации запросов, разумным будет использовать CLB или ALB. +- Если вы не хотите вообще думать о балансировке нагрузки, так как ваша архитектура крайне проста (скажем, только один сервер), все равно стоит поставить балансировщик нагрузки перед ним. Это даст вам большую гибкость во время обновления, так как вам не придется менять никакие настройки DNS, которые довольно таки долго распространяются, а также позволит вам делать некоторые вещи, типа терминации SSL гораздо легче. +- **CLB и ALB могут иметь множество IP адресов:** Внутренне балансировщик нагрузки AWS - это просто набор отдельных программных балансировщиков нагрузки, размещенных в EC2, с распределением траффика путем балансировки нагрузки по DNS. Этот пул может содержать множество IP-адресов, как минимум по одному на каждую зону доступности и в зависимости от уровня нагрузки. Также они поддерживают терминацию SSL, что является очень удобным. +- **Масштабирование:** CLB и ALB могут масштабироваться до очень высокой пропускной способности, однако масштабирование не является мгновенным процессом. Если вы ожидаете внезапного появления большого количества трафика, имеет смысл создать тестовую нагрузку, чтобы они заранее масштабировались. Вы также можете [связаться с Amazon](http://aws.amazon.com/articles/1636185810492479) чтобы они “прогрели” балансировщик нагрузки. +- **Клиентские IP-адреса:** В общем, если серверы хотят знать истинные IP-адреса клиентов, балансировщики нагрузки должны каким-то образом пересылать эту информацию. CLB добавляет стандартный заголовок [X-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For). При использовании CLB, как балансировщика нагрузки HTTP траффика, возможно таким образом получать клиентский IP-адрес. +- **Использование балансировщиков нагрузки при развертывании:** Один из распространенных шаблонов заключается в замене инстансов в балансировщике нагрузки после развертывания нового стека на последнюю версию, сохранения работоспособности старого стека в течение одного или двух часов и либо возврата к старому стеку в случае проблем, либо его сноса. +- **Замена сертификатов с сохранением ARN:** Замена серверных сертификатов IAM может быть сложной, так как стандартная практика - загрузить новый и обновить все ресурсы с новым ARN. В любом случае, вы можете сохранить тот же ARN используя вызов `update-certificate` следующим путем: + 1. Загрузить новый сертификат IAM с уникальным именем (например, fuzzy.com.new) + 2. Переименовать существующий сертификат (например, fuzzy.com в fuzzy.com.expired) + 3. Переименовать новый сертификат IAM на имя прошлого существующего сертификата (например, fuzzy.com.new в fuzzy.com) + 4. Передернуть CLB/ALB Listener чтобы подтянуть изменения: + * ALB: Вызовите modify-listener с существующими параметрами ALB Listener + * CLB: Вызовите create-load-balancer-listeners с существующими параметрами CLB listener + +### Ошибки и ограничения, связанные с Load Balancer + +- ❗CLB и ALBs не имеют **фиксированных публичных IP-адресов**, которые видны клиентам. Для большинства пользовательских приложений это не имеет значения, но ваши корпоративные клиенты могут этого захотеть. IP-адреса будут отличаться для каждого пользователя и непредсказуемо изменяться для одного клиента с течением времени (в пределах стандартных [диапазонов IP-адресов EC2](http://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)). И точно так же никогда не резолвите имя CLB в IP и не указывайте его в качестве значения записи A - оно будет работать некоторое время, а затем сломается! +- ❗Некоторые веб-клиенты или обратные прокси-серверы кешируют DNS-запросы в течение длительного времени, что создает проблему для CLB и ALB, поскольку они меняют свои IP-адреса. Это означает, что через несколько минут, часов или дней, ваши клиенты перестанут работать, пока вы не отключите кэширование DNS. Следите за [настройками Java](http://docs.oracle.com/javase/8/docs/api/java/net/InetAddress.html) и обязательно [настройте их правильно](http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-jvm-ttl.html). Другим примером может быть использование nginx в роли обратного прокси-сервера, который [обычно резолвит бэкенды только при запуске](https://www.jethrocarr.com/2013/11/02/nginx-reverse-proxies-and-dns-resolution/) (хотя есть [способ обойти эту проблему](https://tenzer.dk/nginx-with-dynamic-upstreams/)). +- ❗Пускай для вас не будет неожиданным, что IP-адреса будут перераспределяться между клиентами без длительного отстоя в пуле свободных адресов. Поэтому, как клиент, если вы кешируете IP-адрес и не используете SSL (для проверки сервера), вы можете получить не просто ошибки, а ответы от совершенно разных служб или компаний! +- 🔸Как оператор службы, работающей за CLB или ALB, последнее явление означает, что вы также можете видеть странные или ошибочные запросы клиентов других компаний. Это наиболее часто встречается у клиентов, использующих серверные API-интерфейсы (поскольку веб-браузеры обычно кешируют в течение ограниченного периода времени). +- ❗CLB и ALB требуется время для масштабирования, они не вытягивают внезапные всплески траффика. Таким образом, если вы ожидаете всплеск, вам необходимо “прогреть” балансировщик нагрузски постепенно посылая на него повышающиеся объемы траффика. +- ❗Тщательно настройте проверку работоспособности - если вы слишком агрессивны в отношении решения о том, когда удалять инстанс, и консервативны в отношении добавления его обратно в пул, служба, которую обслуживает ваш балансировщик нагрузки, может стать недоступной на несколько секунд или минут. Будьте крайне осторожны с этим, когда автоматическое масштабирование настроено на удаление инстансов, которые не прошли проверку балансировщика нагрузки. +- ❗CLB HTTPS listeners не поддерживают Индикацию имени сервера(Server Name Indication) (SNI). Если вам нужен SNI, вы можете обойти это ограничение используя сертификат с Subject Alternative Names (SAN) или используя TCP listener и терминируя SSL на бэкенде. +- 🔸 Существует ограничение на количество ALB, CLB и NLB на регион (отдельное для каждого). На конец 2017 года, ограничение по умолчанию для каждого - 20 на регион. Эти лимиты могут быть лекго повышены для ALB и CLB, но AWS довольно неохотно поднимает лимит для NLB. +- 🔸 Если вы используете сетевой балансировщик нагрузки(NLB) тогда клиенты EC2 не смогут подключиться к NLB, который находится в другом VPC (пиринг VPC) или VPN под управлением AWS, если только клиент EC2 не является экземпляром C5, i3.metal или M5. Для пиринга VPC оба VPC должны быть в одном и том же регионе. Тут описано [устранение неполадок](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 +- 📒 [Домашняя страница](https://aws.amazon.com/elasticbeanstalk/) ∙ [Руководство разработчика](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) ∙ [ЧаВо](https://aws.amazon.com/elasticbeanstalk/faqs/) ∙ [Расценки](https://aws.amazon.com/elasticbeanstalk/pricing/) +- **EB** (Elastic Beanstalk) - это PaaS (Платформа как сервис) которая помогает разработчикам создавать, развертывать и масштабировать веб-приложения +- EB управляет развертыванием, настройкой, выделением ресурсов, балансировкой нагрузки, автоматическим масштабированием, мониторингом и ведением логов. +- EB создает ресурсы AWS от вашего имени, но вы сохраняете полный доступ и контроль над основными ресурсами +- 💸 Использование EB бесплатно, но вы все равно будете платить полную стоимость базовых ресурсов AWS, созданных EB. + +### Советы по Elastic Beanstalk +- Чтобы ускорить развертывание перед запуском или на этапе разработки, отключите проверки работоспособности и установите `Deployment policy` значение `All at once` +- Если у вас есть конфигурация, которую вы хотите использовать повторно для нескольких приложений EB, вы можете сохранить текущую конфигурацию, используя `eb config save --cfg myEBConfig` +- По умолчанию, в EB нет аварийных оповещений. Вам необходимо добавить их самостоятельно, в соответствии с метриками, которые вы мониторите. +- По умолчанию, EB не включает [управляемые обновления платформы](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-platform-update-managed.html?icmpid=docs_elasticbeanstalk_console). Включите их в настройках, чтобы EB автоматически применял обновления в заранее установленный период обслуживания + +### Ошибки и ограничения, связанные с Elastic Beanstalk +- 🔸 Не редактируйте конфигурационные файлы [apache|nginx] вручную на инстансах ec2, так как они будут перезаписаны при каждом развертывании (вместо этого используйте [ebextensions](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions.html)) +- 🔸 После создания среды EB, больше не представляется возможным изменения тэга `Name` +- 🔸 EB иногда помещает в карантин инстансы, которые вызывают многократные проблемы развертывания. Несмотря на карантин, EB все равно будет развертываться на них при последующих развертываниях. Чтобы предотвратить такое поведение, указанные инстансы необходимо удалить (или устранить проблему) +- Загрузка файлов ограничена 10MB в большинстве конфигураций eb по умолчанию, обновите [конфигурационный файл nginx](https://stackoverflow.com/questions/18908426/increasing-client-max-body-size-in-nginx-conf-on-aws-elastic-beanstalk) чтобы исправить это +- Если вы редактируете `.elasticbeanstalk/saved_configs/`, знайте, что он не синхронизируется с конфигураций среды EB. Вам необходимо вручную подтянуть настройки и сохранить их для применения изменений. + +Elastic IPs +----------- + +### Основы Elastic IP + +- 📒 [Документация](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) ∙ [ЧаВо](https://aws.amazon.com/ec2/faqs/#Elastic_IP) ∙ [Расценки](https://aws.amazon.com/ec2/pricing/on-demand/#Elastic_IP_Addresses) +- **Elastic IPs** - это статичные IP адреса, которые вы можете арендовать у AWS и назначить инстансам EC2. + +### Советы по Elastic IP + +- 🔹**Предпочтите балансировщики нагрузки использованию Elastic IP:** Для развертываний на одном инстансе, вы можете просто назначить Elastic IP данному инстансу, назначить DNS имя данному адресу и считать это все вашим развертыванием. Однако в большинстве случаев вам стоило бы развернуть [балансировщик нагрузки](#балансировщики-нагрузкиload-balancers) вместо этого: + - Легко добавлять и удалять инстансы из группы балансировщика нагрузки. Кроме того, быстрее добавлять или удалять инстансы из группы балансировщика нагрузки, чем переназначать эластичный IP-адрес. + - Удобнее указывать записи DNS на балансировщик нагрузки, а не указывать их на конкретные IP-адреса, которыми вы управляете вручную. Можно также использовать алиасы Route 53, которыми проще управлять и изменять. + - Но в некоторых ситуациях вам необходимо закреплять IP-адреса инстансов EC2 и управлять ими, например, если клиенту нужен фиксированный IP-адрес. Эти ситуации требуют эластичных IP-адресов. +- Существует ограничение в 5 эластичных IP-адресов на аккаунт. Существует возможность [запросить больше](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase&limitType=service-code-elastic-ips-ec2-classic). +- Если эластичных IP-адрес не назначен действующему ресурсу, существует небольшая [почасовая оплата](https://aws.amazon.com/ec2/pricing/on-demand/#Elastic_IP_Addresses). +- Вам не надо платить [дополнительно](https://aws.amazon.com/ec2/pricing/on-demand/#Elastic_IP_Addresses) за использование эластичного IP-адреса, пока вы им пользуетесь. Однако во время простоя есть небольшие издержки, что является механизмом противодействия захвату большого количества IP адресов. + +### Ошибки и ограничения, связанные с Elastic IP + +- 🔸[Официально нет никакой возможности](https://forums.aws.amazon.com/thread.jspa?threadID=171550) получить последовательный блок IP адресов, что было бы неплохо при раздаче адресов внешним пользователям. Однако вам может повезти и вы получите адрес, которые являеются частью одного CIDR блока. Если вам это действительно важно, вы можете [принести свои собственные IP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html), что является более сложным, нежели то, что рассматривается в этом руководстве. + +Glacier +------- + +### Основы Glacier + +- 📒 [Домашняя страница](https://aws.amazon.com/glacier/) ∙ [Руководство разработчика](http://docs.aws.amazon.com/amazonglacier/latest/dev/) ∙ [ЧаВо](https://aws.amazon.com/glacier/faqs/) ∙ [Расценки](https://aws.amazon.com/glacier/pricing/) +- **Glacier** - это более дешевая альтернатива S3, для тех случаев, когда доступ к данным необходим редко, как например для архивирования. +- Это полезно только для данных, к которым редко обращаются. Обычно выполнение запроса извлечения занимает [3-5 часов] (https://aws.amazon.com/glacier/faqs/#dataretrievals). +- AWS [официально не разглашает](https://en.wikipedia.org/wiki/Amazon_Glacier#Storage) устройство хранения используемого Glacier; возможно это медленные жесткие диски или даже магнитные ленты. +- AWS выпустил еще более экономичное хранилище, называемое [Glacier Deep Archive](https://aws.amazon.com/blogs/aws/new-amazon-s3-storage-class-glacier-deep-archive/), которое предлагает время извлечения ~12 часов, но стоит примерно 1000 долларов за петабайт в месяц. + +### Советы по Glacier + +- Вы можете физически [отправить по почте](https://aws.amazon.com/blogs/aws/send-us-that-data/) ваши данные в Amazon, чтобы поместить в Glacier, на жестком диске USB или eSATA. + +### Ошибки и ограничения, связанные с Glacier + +- 🔸Получение файлов с Glacier происходит очень-очень медленно (обычно 3-5 часов и более). +- 🔸Из-за фиксированных накладных расходов на файл (вы платите за операции PUT или GET), загрузка и выгрузка множества маленьких файлов на / в Glacier может быть очень дорогой. Также необходимо учитывать хранение метаданных в размере 32кб дополнительно на файл. Следовательно, архивировать файлы перед загрузкой - хорошая идея. +- 💸Помните о стоимости за каждый объект архивирования данных S3 в Glacier. [Это стоит $ 0,05 за 1000 запросов](https://aws.amazon.com/s3/pricing/). Если у вас есть большое количество объектов S3 относительно небольшого размера, [потребуется время, чтобы достичь точки безубыточности относительно хранения в S3](https://alestic.com/2012/12/s3-glacier-costs/) (первоначальная стоимость архивирования по сравнению с более низкой ценой хранения). + +RDS +--- + +### Основы RDS + +- 📒 [Домашняя страница](https://aws.amazon.com/rds/) ∙ [Руководство пользователя](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/) ∙ [ЧаВо](https://aws.amazon.com/rds/faqs/) ∙ [Расценки](https://aws.amazon.com/rds/pricing/) (также смотрите [ec2instances.info/rds/](http://www.ec2instances.info/rds/)\) +- **RDS** - это управляемый сервис реляционных баз данных, позволяющий вам разворачивать и масштабировать базы данных намного проще. Он поддерживает [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/) и собственную СУБД AWS [Aurora](https://aws.amazon.com/rds/aurora/). +- RDS из коробки предлагает поддержку [высокой доступности и отказоустойчивости](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) для ваших баз данных. + +### Советы по RDS + +- Если вы ищете управляемые сервис с удобством RDS для других хранилищ данных, таких как MongoDB или Cassandra, возможно вам стоит предпочесть сторонние сервисы от провайдеров, таких как [mLab](https://mlab.com/), [Compose](https://www.compose.com/) или [InstaClustr](https://www.instaclustr.com/). +- 🔹Обязательно создайте новую [группу параметров](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html) и группу опций для своей базы данных, поскольку группа параметров по умолчанию не допускает динамических изменений конфигурации. +- RDS инстансы запускаются с часовым поясом UTC по умолчанию. Если необходимо, можно [сменить часовой пояс на другой](https://aws.amazon.com/premiumsupport/knowledge-center/rds-change-time-zone/). + +### Ошибки и ограничения, связанные с RDS + +- ⏱RDS инстансы запускаются на томах EBS (либо общего назначения(general-purpose) либо с выделенным IOPS(provisioned IOPS)) и, следовательно, ограничены производительностью EBS. +- 🔸Проверьте, какие функции базы данных вам нужны, так как не все, что вам нужно, доступно в RDS. Например, если вы используете Postgres, проверьте список [поддерживаемых функций и расширений](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#SQLServer.Concepts.General.FeatureSupport). Если необходимые вам функции не поддерживаются RDS, вам придется развернуть базу данных самостоятельно. +- 🔸Если вы используете поддержку отказоустойчивости, предлагаемую RDS, помните, что она основана на изменениях DNS, и убедитесь, что ваш клиент реагирует на эти изменения соответствующим образом. Это особенно важно для Java, учитывая то, как TTL его DNS-резолвера настроен по умолчанию(http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html). +- 🔸**Миграция баз данных в RDS:** При импорте вашей базы данных в RDS убедитесь, что вы учитываете настройки окна обслуживания. Если резервное копирование выполняется одновременно с импортом, импорт может занять значительно больше времени, чем вы ожидали. +- [Размеры баз данных ограничены](https://aws.amazon.com/about-aws/whats-new/2015/06/amazon-rds-increases-storage-limits-to-6TB-for-piops-and-gp2/) **6TB** для всех СУБД, за исключением SQL Server у которого лимит - **4TB** и Aurora, которая поддерживает базы данных до **64TB**. + +RDS MySQL и MariaDB +--------------------- + +### Основы RDS MySQL и MariaDB + +- RDS предлагает MySQL версий 5.5, 5.6, 5.7 и 5.8. +- RDS предлагает MariaDB версий 10.0, 10.1, 10.2 и 10.3. + +### Советы по RDS MySQL и MariaDB + +- MySQL RDS позволяет доступ к [бинарным логам](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html#USER_LogAccess.MySQL.BinaryFormat). +- Инстансы MySQL при развертывании в нескольких зонах доступности прозрачно реплицируют данные между зонами доступности используя DRBD. Автоматическое резервное копирование инстансов при развертывании в нескольких зонах доступности [запускается на резервном инстансе](https://www.percona.com/live/mysql-conference-2014/sessions/rds-mysql-tips-patterns-and-common-pitfalls) чтобы убрать возможность всплесков на основном сервере. +- 🔸**Performance Schema:** Хотя [Performance Schema](http://dev.mysql.com/doc/refman/en/performance-schema.html) включена по умолчанию в MySQL 5.6.6 и в более поздних версиях, она выключена по умолчанию в RDS. Если вы хотите включить Performance Schema, потребуется перезагрузка инстанса RDS. +- 🔸**MySQL или MariaDB или Aurora:** Если вы предпочитаете СУБД в стиле MySQL, но начинаете что-то новое, вам стоило бы рассмотреть Aurora и MariaDB. **Aurora** имеет повышенную доступонсть и являюется решением следующего поколения. Тем не менее Aurora [может и не быть](http://blog.takipi.com/benchmarking-aurora-vs-mysql-is-amazons-new-db-really-5x-faster/) намного быстрее MySQL для конкретных рабочих нагрузок. **MariaDB** - современный [комьюнити форк](https://en.wikipedia.org/wiki/MariaDB) MySQL, [похоже, что имеет преимущества над MySQL](http://cloudacademy.com/blog/mariadb-vs-mysql-aws-rds/) для многих целей, поддерживается RDS. + +### Ошибки и ограничения, связанные с RDS MySQL и MariaDB + +- 🔸**Никаких SUPER привилегий** RDS предоставляет несколько [хранимых процедур](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.SQLRef.html) для выполнения некоторых задач, которым требуются SUPER привилегии, например запуск и остановка репликации. +- 🔸Вы можете реплицировать на инстансы MySQL, не относящиеся к RDS, но [репликация на эти инстансы будет прерываться во время аварийного переключения между зонами доступности](https://www.percona.com/live/mysql-conference-2014/sessions/rds-mysql-tips-patterns-and-common-pitfalls). +- 🔸Отсуствует возможность ручной смены мастера на репликах, так что их все необходимо будет пересоздать после аварийного переключения мастера. +- 🔸Большинство глобальных опций доступно только в [группах параметров БД(DB parameter groups)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html). Некоторые переменные, которые были введены в более поздних точечных выпусках MySQL, такие как [avoid_temporal_upgrade](https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_avoid_temporal_upgrade) в MySQL 5.6.24, не доступны в группах параметров для версии 5.6.х в RDS и их использование требует обновления на MySQL 5.7.x. +- 🔸Функции RDS, такие как восстановление на конкретную точку времени и восстановление со снапшота не поддерживаются для таблиц MyISAM. Убедитесь, что вы заблокировали и очистили каждую таблицу MyISAM перед выполнением снапшота или операции резервного копирования, чтобы обеспечить консистентность. + +RDS PostgreSQL +-------------- + +### Основы RDS PostgreSQL + +- RDS предлагает PostgreSQL 9.3, 9.4, 9.5, 9.6 и 10. + +### Советы по RDS PostgreSQL + +- Недавно была добавлена поддержка логической репликации, [как публикации, так и подписки](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.version104). +- Поддерживает довольно большой диапазон родных [расширений](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions). +- RDS PostgreSQL 10 поддерживает собственный партишенинг и большинство основных функций и настроек. +- Поддерживает соединение через SSL. +- Поддерживает восстановление между зонами доступности и к конкретной точке во времени. + +### Ошибки и ограничения, связанные с RDS PostgreSQL +- Отсутствют суперпользовательские привилегии. RDS предоставляет роль `rds_superuser`, которая может выполнять большинство из необходимых операций, однако имеются некоторые ограничения. +- Добавление некоторых важных функций запаздывает по сравнению с PostgreSQL. +- По умолчанию RDS поставляется с SSD общего назначения, если вам необходима лучшая производительность, вам необходимо выбрать SSD с выделенными IOPS. +- Вы не можете использовать RDS, как реплику с внешнего сервера без использования логической репликации. +- Существуют параметры, которые нельзя изменить, и большинство параметров, которые можно изменить, можно изменить только с помощью групп параметров базы данных. +- Ввиду того, что у вас нет доступа на хост - сложнее решать проблемы производительности. +- Убедитесь, что все необходимые [расширения](https://www.postgresql.org/docs/current/static/view-pg-available-extensions.html) доступны. Если вы используете расширение, которого нет в списке, вам нужно будет найти обходной варант или развернуть собственную базу данных в EC2. +- Многие утилиты и элементы обслуживания Postgres требуют доступа из командной строки, что обычно можно выполнить с помощью внешнего сервера ec2. + +RDS SQL Server +-------------- + +### Основы RDS SQL Server + +- [RDS предлагает SQL Server 2008 R2, 2012, 2014, 2016 и 2017](https://aws.amazon.com/rds/sqlserver/) включая Express, Web, Standard и Enterprise. + +### Советы по RDS SQL Server + +- Недавно добавленная поддержка [резервныого копирования и восстановления в/из S3](https://www.brentozar.com/archive/2016/07/holy-cow-amazon-rds-sql-server-just-changed-everything/) делает привлекательным [вариантом восстановления в случае аварии](https://aws.amazon.com/blogs/aws/amazon-rds-for-sql-server-support-for-native-backuprestore-to-amazon-s3/) для локальных серверов. + +### Ошибки и ограничения, связанные с RDS SQL Server + +- 🔸Пользователь имеет только права db_owner для каждой базы в инстансе. +- 🔸Хранилище не может быть расширено для существующих баз данных. Если вам необходимо больше места, вам необходимо восстановить вашу базу данных на новом инстансе с большим хранилищем. +- 🔸**16TB** - ограничение максимального размера базы данных для всех версий, кроме Express. Также есть минимальное ограничение размера, 20GB для Web и Express, 200GB для Standard и Enterprise. +- 🔸Есть ограничение в [30 баз данных на инстанс](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html) + +RDS Aurora +---------- +### Основы RDS Aurora +Aurora - это облачная служба баз данных, предназначенная для предоставления распределенной, отказоустойчивой реляционной базы данных с самовосстанавливающимся хранилищем и автоматическим масштабированием до 64 ТБ. В настоящее время она выпускается в двух версиях: совместимая с MySQL и совместимая с PostgreSQL. + +RDS Aurora MySQL +---------------- + +### Основы RDS Aurora MySQL + +- Проприетарный форк MySQL от Amazon, созданный для масштабирования высококонкурентных рабочих нагрузок. В общем говоря, производительность отдельных запросов в Aurora не особенно повысится относительно MySQL и MariaDB, но Aurora создана для поддержки этого уровня производительности при обеспечении запуска гораздо большего количества запросов одновременно, чем может выдержать эквивалентный сервер MySQL или MariaDB. +- [Известные новые функции](http://www.slideshare.net/AmazonWebServices/amazon-aurora-amazons-new-relational-database-engine) включают в себя: + - Журнально-структурированное хранилище вместо B-tree для повышения производительности записи. + - Независимый буферный пул, так что инстансы баз данных могут быть перезапущены без очистки буфера. + - Базовое физическое хранилище представляет собой специализированный массив SSD, который автоматически поддерживает 6 копий ваших данных в 3 зонах доступности(AZ). + - Реплики только-для-чтения в Aurora используют один уровень хранения с мастером, что существенно снижает лаг реплики, устраняет необходимость записи и отправки бинарных логов для репликации с мастера, и позволяет производить аварийное переключение с мастера на реплику без потерь данных. Мастер и реплики для чтения, которые используют одно хранилище, совместно называются **кластер Aurora**. Реплики могут размещаться в масштабах до [5 регионов](https://aws.amazon.com/about-aws/whats-new/2018/09/amazon-aurora-databases-support-up-to-five-cross-region-read-replicas/). + +### Советы по RDS Aurora MySQL + +- Чтобы воспользоваться преимуществами более высокого уровня параллелизма в Aurora, приложения должны быть настроены с большими пулами соединений с базой данных и выполнять как можно больше запросов одновременно. Например, сервера Aurora тестировались в целях получения более высокой производительности на некоторых рабочих нагрузках OLTP с примерно [5,000 соединениями](http://www.slideshare.net/AmazonWebServices/amazon-aurora-amazons-new-relational-database-engine/31). +- [Aurora прекрасно масштабируется с несколькими CPU](https://www.percona.com/blog/2016/05/26/aws-aurora-benchmarking-part-2/) и может потребовать высокий класс инстанса для оптимальной производительности. +- Простейшим путем миграции на Aurora является восстановление базы данных из снапшота с MySQL 5.6 или 5.7. Следующим простейшим методом является восстановление дампа с MySQL совместимой СУБД, такой как MariaDB. Для [миграции с малым прерыванием работы](https://aws.amazon.com/blogs/aws/amazon-aurora-update-spatial-indexing-and-zero-downtime-patching/) с других MySQL-совместимых СУБД, вы можете настроить инстанс Aurora, как реплику вашей существующей СУБД. Если же ни один из этих вариантов не подошел, Amazon предлагает платный сервис миграции данных. +- Вы можете реплицировать данные [с кластера Aurora в MySQL или на другоой кластер Aurora](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Overview.Replication.MySQLReplication.html). Это требует включения опции бинарного логирования и работает не так, как родная репликация Aurora. +- Так как реплики Aurora являются [аналогом распределенного по различным зонам доступности резервного копирования](http://stackoverflow.com/a/32428651/129052) и могут быть сконфигурированы как цели для аварийного переключения без потери данных, существует малое количество сценариев, в которых вам потребуется создание распределенного по зонам доступности инстанса Aurora. + +### Ошибки и ограничения, связанные с RDS Aurora MySQL + +- 🔸[Aurora 1.x основана на MySQL 5.6.x](https://news.ycombinator.com/item?id=12415693) с некоторой подборкой более поздних функций MySQL. В ней отсутствуют большинство функций 5.7, а также некоторые онлайн-функции DDL, представленные в 5.6.17. +- 🔸[Aurora 2.x основана на MySQL 5.7.x](https://aws.amazon.com/about-aws/whats-new/2018/02/amazon-aurora-is-compatible-with-mysql-5-7/) +- Aurora не поддерживает транзакции GTID как в 5.6/Aurora 1.x, так и в 5.7/Aurora 2.x. +- Максимальный размер кластера Aurora - 64 TB + +RDS Aurora PostgreSQL +--------------------- + +### Основы RDS Aurora PostgreSQL + +- Проприетарный форк PostgreSQL от Amazon, созданный для масштабирования высококонкурентных рабочих нагрузок, но с сохранением легкости пользования. На текущий момент основана на PostgreSQL 9.6. +- Высокая пропускная способность (вплоть до трехкратного превышения показателей на том же оборудовании). +- Автоматическое масштабирование хранилища инкрементами по 10GB до 64TB. +- Реплики для чтения с низкой задержкой, которые используют совместно с мастером уровень хранилища, что серьезно снижает лаг реплики. +- Восстановление на любую точку времени. +- Быстрые снапшоты баз данных. + +### Советы по RDS Aurora PostgreSQL +- Aurora Postgres по умолчанию предполагает утилизацию большого количества соединения, поэтому пул соединений необходимо настроить соотвественным образом. +- Так как Aurora основана на PostgreSQL 9.6, в нем отсутствуют такие функции, как декларативное разбиение или логическая репликация. + +### Ошибки и ограничения, связанные с RDS Aurora PostgreSQL + +- Aurora PostgreSQL отстает от обычного RDS, когда дело доходит до доступных версий, поэтому, если вам нужны функции из последней версии PostgreSQL, вам может быть лучше использовать обычный RDS. +- Патчинг и исправление багов является отдельным от PostgreSQL. + +ElastiCache +----------- + +### Основы ElastiCache + +- 📒 [Домашняя страница](https://aws.amazon.com/elasticache/) ∙ [Руководство пользователя для Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/index.html) ∙ [Руководство пользователя для Memcached](https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/index.html) ∙ + [ЧаВо](https://aws.amazon.com/elasticache/faqs/) ∙ + [Расценки](https://aws.amazon.com/elasticache/pricing/) +- **ElastiCache** это управляемый сервис кэширования в памяти, который может быть использован для хранения временных данных в быстром кэше в памяти, обычно в целях того, чтобы избежать одинаковых вычислительных операций в то время, как данные могут быть взяты снова. +- Он поддерживает [Memcached](https://memcached.org) и + [Redis](https://redis.io) - открытое программное обеспечение для кэширования в памяти, они оба используют свои собственные API. +- Основное преимущество заключается в том, что AWS заботится о запуске, исправлении и оптимизации нод кэширования для вас, так что вам просто нужно запустить кластер и настроить его эндпоинт в вашем приложении, в то время как AWS возьмет на себя большую часть работы по запуску нод кэширования. + +### Советы по ElastiCache + +- Выберите + [движок](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/SelectEngine.html), конфигурацию кластера и [тип инстанса] http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/CacheNodes.SelectSize.html) исходя из потребностей вашего приложения. Документация подробно объясняет плюсы, минусы и ограничения каждого механизма, чтобы помочь вам выбрать наиболее подходящий для вашего приложения. В двух словах, Redis предпочтительнее для хранения более сложных структур данных, в то время как Memcached - это просто хранилище ключ/значение. Простота Memcached позволяет ему быть немного быстрее и позволяет масштабировать его при необходимости, но Redis имеет больше функций, которые вы можете использовать в своем приложении. +- Для Memcached AWS предоставляет расширенные SDK для определенных языков программирования, которые реализуют [автообнаружение](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/AutoDiscovery.html), функцию, не доступную в обычных библиотеках клиента memcached. + +### Ошибки и ограничения, связанные с ElastiCache + +- Поскольку в некоторых случаях изменение кластеров кэша может иметь некоторые ограничения, например, для целей [масштабирования](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Scaling.html), это может стать проблемой, если они были запущены с использованием CloudFormation в стеке, который также содержит другие ресурсы, и вам действительно необходимо изменить кэш.Во избежание перевода стеков CloudFormation в состояние без возможности обновления, рекомендуется запускать кластеры ElastiCache (как и любой другой ресурс с аналогичными ограничениями) в выделенных стеках, которые можно полностью заменить новыми стеками, имеющими желаемую конфигурацию. + + +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](#контейнера-и-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 +- 📒 [Домашняя страница](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](#контейнера-и-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 +- 📒 [Домашняя страница](https://aws.amazon.com/fargate/) ∙ [ЧаВо](https://aws.amazon.com/fargate/faqs/) ∙ [Расценки](https://aws.amazon.com/fargate/pricing/) +- **Fargate** позволяет вам управлять и разворачивать контйнера не задумываясь о запуске подлежащей вычислительной платформе +- Fargate выступает в роли нового бэкенда (в дополнению к старом бэкенду на EC2) на котором можно запускать задачи ECS и EKS +- Fargate и EC2 в данном контексте называются "Типы запуска(Launch Types)" +- Fargate позволяет вам рассматривать контейнера, как фундаментальные строительные блоки вашей инфраструктуры. + +### Советы по Fargate +- Fargate следует подобному образу мышления, как у Lambda, который позволяет вам сосредоточиться на приложениях, вместо работы с низлежащей инфраструктурой +- Fargate поддерживается CloudFormation, aws-cli и ecs-cli +- Задачи Fargate можно запускать совместно с любыми задачами, использующими тип запуска EC2 +- 💸Перед созданием большого развертывания на Fargate, обязательно оцените затраты и сравните их с альтернативным решением, использующим традиционное развертывание на EC2. Цены на Fargate могут в несколько раз превышать цены на инстансы EC2 эквивалентного размера. Для оценки возможных затрат на оба этих решения, ознакомьтесь с разценками на [EC2](https://aws.amazon.com/ec2/pricing/) и [Fargate](https://aws.amazon.com/fargate/pricing/). + +### Альтернативы Fargate и привязки +- 🚪[Azure Container Instances](https://azure.microsoft.com/en-us/services/container-instances/): Доступно в Microsoft Azure в предварительной версии, позволяет запускать приложения в контейнерах без управления виртуальными машинами + +### Ошибки и ограничения, связанные с Fargate +- По состоянию на апрель 2018 года, Fargate доступен в [нескольких регионах](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 +- По состоянию на явнварь 2019 год, Fargate может быть использован с ECS. Поддержка EKS [была изначально запланирована на 2018 год](https://aws.amazon.com/blogs/aws/aws-fargate/), но пока не запущена. +- Минимальные ресурсы, которые можно использовать для выполнения задачи ECS в Fargate - 0.25 vCPU и 0.5 GB памяти +- [Хранилище задач - эфемерно. Как только задача Fargate останавливается - хранилище удаляется.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-storage.html) + + +Lambda +------ + +### Основы Lambda + +- 📒 [Домашняя страница](https://aws.amazon.com/lambda/) ∙ [Руководство пользователя](http://docs.aws.amazon.com/lambda/latest/dg/) ∙ [ЧаВо](https://aws.amazon.com/lambda/faqs/) ∙ [Расценки](https://aws.amazon.com/lambda/pricing/) +- **Lambda** предсталвяет собой предложение бессерверных вычислений в AWS, позволяющее пользователям определять функции Lambda в различных средах выполнения, которые могут быть вызваны с помощью различных триггеров, включая уведомления SNS и вызовы API Gateway. Lambda - ключевой сервис в ['бессерверной' архитектуре AWS](https://aws.amazon.com/lambda/serverless-architectures-learn-more/), вместе с AWS API Gateway, AWS Batch и AWS DynamoDB. + +### Советы по Lambda + +- Идея лежащая в основе 'бессерверной' концепции , что пользователи не управляют развертыванием, масштабированием или обслуживанием физических машин, на которых размещен код их приложения. С Lambda, машина, которая фактически выполняет пользовательскую функцию, абстрагируется как ['контейнер'](http://docs.aws.amazon.com/lambda/latest/dg/lambda-introduction.html). При определении функции Lambda пользователи могут объявлять объем памяти, доступный для функции, что напрямую влияет на спецификацию физического оборудования контейнера Lambda. +- Изменение объема памяти доступного вашей Lambda функции также затронит объем [CPU](https://aws.amazon.com/lambda/faqs/) доступный ей. +- Хотя AWS не предоставляет жестких гарантий относительно повторного использования контейнера, в целом можно ожидать, что неизмененная Lambda функция будет повторно использовать «теплый» (ранее использовавшийся) контейнер, если вызывается вскоре после другого вызова. Пользователи могут использовать это как способ оптимизации своих функций путем интеллектуального кэширования данных приложения при инициализации. +- Lambda функция, которая не вызывалась некоторое время, может не иметь теплых контейнеров. В этом случае Lambda должна будет загрузить и инициализировать Lambda-код в сценарии «холодного запуска», что может добавить значительную задержку к вызовам Lambda-функций. +- Существует несколько стратегий, позволяющих избежать или смягчить «холодный» запуск, в том числе поддерживать контейнеры в тепле путем периодического вызова функций, а также предпочтение облегченным средам выполнения, таким как Node.Js, а не Java. +- Lambda интегрирована с AWS CloudWatch и во время работы отправляет логи и события в CloudWatc. +- Lambda предлагает готовую поддержку AWS X-Ray из коробки. X-Ray может помочь пользователям диагностировать проблемы при выполнении Lambda-функций, предлагая углубленный анализ потока выполнения их Lambda-кода. Это особенно полезно при разборе проблем, вызываемых другими сервисами AWS, так как X-Ray дает вам подробный и простой для анализа [график вызовов](http://docs.aws.amazon.com/lambda/latest/dg/lambda-x-ray.html#lambda-service-map). +- Используя [временные события CloudWatch](http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html#CronExpressions), пользователи могут использовать Lambda чтобы периодически запускать задачи, как в cron. +- События, отправленные в Lambda, которые не обрабатываются, могут управляться с помощью [Dead Letter Queue (DLQ) в SQS.](http://docs.aws.amazon.com/lambda/latest/dg/dlq.html) +- Больше о бессерверных вычислениях: + - [Martin Fowler's thoughts.](http://martinfowler.com/articles/serverless.html) + - [AWS Serverless Application Model (SAM)](https://github.com/awslabs/serverless-application-model), упрощение, построенное на основе CloudFormation, которое может помочь описывать, управлять и развертывать бессерверные приложения с использованием Lambda. + - [Serverless](https://github.com/serverless/serverless) - один из наиболее популярных фреймворков для создания бессерверных приложений используя AWS Lambda или другой вариант бессерверных вычислений and other serverless compute options. + - [Другие полезные фреймворки.](https://github.com/anaibol/awesome-serverless#frameworks) + +### Альтернативы Lambda и привязки + +- 🚪Другие облачные провайдеры также предоставляют подобные сервисы под разными именами, включая [Google Cloud Functions](https://cloud.google.com/functions/), [Azure Functions](https://azure.microsoft.com/en-us/services/functions/), и [IBM OpenWhisk](http://www.ibm.com/cloud-computing/bluemix/openwhisk/). Также, если вы используете Kubernetes, другой альтернативой Lambda является [OpenFaaS] (https://github.com/openfaas/faas) + +### Ошибки и ограничения, связанные с Lambda + +- 🔸Тестирование Lambda-функций, как локально, так и удаленно, может быть сложным. Для облегчения этой задачи доступно несколько инструментов, включая официально поддерживаемый [SAM Local](https://github.com/awslabs/aws-sam-local). +- 🔸Управление большим количеством функций Lambda - это сложный рабочий процесс, а инструменты для управления развертываниями Lambda все еще не совершенны. +- 🔸Официальный рабочий процесс AWS относительно управления функцией [версионности и псевднонимов](https://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html) полон боли. Один из вариантов - избежать создания версий Lambda, абстрагируя рабочий процесс развертывания от Lambda. Одним из способов достижения этого является развертывание приложения на последовательных этапах, с отдельной учетной записью AWS для каждого этапа, где каждая учетная запись должна знать только о последней версии, а откаты и обновления обрабатываются с помощью внешних инструментов. +- 🔸По состоянию на октябрь 2017 год, минимальная плата взымается за вызов Lambda за 100 миллисекунд, так что уменьшение срока запуска ниже этого времени ни принесет никаких преимуществ. +- 🔸При добавлении/удалении S3 бакетов в качестве триггеров для Lambda-функции может возникнуть эта ошибка: "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." В этом случае вы можете вручную удалить событие Lambda на вкладке "Events" в разделе "Properties" S3 бакета. +- 🔸Управление размером артефактов развертывания может быть проблемой, особенно при использовании Java. Вариантом смягчения этой проблемы является включение [proguard](https://www.guardsquare.com/en/proguard) и загрузка зависимостей в среду выполнения в /tmp. +- Когда вы используете DynamoDB, как триггер для вашей Lambda-функции, может возникнуть следующая ошибка: "PROBLEM: internal Lambda error. Please contact Lambda customer support." Обычно это просто означает, что Lambda не может обнаружить что-либо в потоке DynamoDB за последние 48 часов. Если проблема не устранена, удаление и повторное создание триггера может помочь. +- 🔸Если вашей Lambda-функции нужен доступ к ресурсам в VPC (например, ElastiCache или RDS), ее необходимо будет развернуть в нем. Это повышает время холодного старта, так как Эластичный сетевой интерфейс(Elastic Network Interface (ENI)) должен быть зарегистрирован в VPC для каждой конкурентной функции. AWS также имеет относительно низкий начальный предел (350) для числа ENI, которые могут быть созданы в VPC, однако его можно увеличить до 1000, если для поддержки AWS будет подготовлено хорошее обоснование. +- 🔸 Lambda также имеет несколько [**ресурсных ограничений(resource limits)**](http://docs.aws.amazon.com/lambda/latest/dg/limits.html) по состоянию на июнь 2017 года: + - **6MB** - размер полезной нагрузки запроса или ответа. + - **50 MB** - ограничение на размер сжатого .zip/.jar файла пакета развертывания. + - **250 MB** - ограничение на размер кода/зависимостей в пакете до сжатия. + - **500 MB** - ограничение локального хранилища в /tmp. + +### Примеры Lambda-кода + +- [Fan-out](https://github.com/awslabs/aws-lambda-fanout) Пример использования Lambda для “разветвления” или копирования данных из одной службы, в данном случае Kinesis, в несколько других служб данных AWS. Направлениями для разветвления данных в этом примере включают IoT, SQS и прочие. +- Этот [AWS limit monitor using Lambdas](https://github.com/awslabs/aws-limit-monitor) показывает использование нескольких Lambda-функций для мониторинга. +- Этот [Lambda ECS Worker Pattern](https://github.com/awslabs/lambda-ecs-worker-pattern) показывает использования Lambda в рабочем процессе, где данные берутся из S3 Lambda-функцией, отправляются в очередь, а затем передаются в ECS для дальнейшей обработки. +- [Secure Pet Store](https://github.com/awslabs/api-gateway-secure-pet-store) простое приложение на Java, которое использует Lambda и API Gateway с Cognito (для аутентификации пользователей). +- [aws-lambda-list](https://github.com/unixorn/aws-lambda-list) - список "надеюсь полезных AWS Lambda-функций и ресурсов о Lambda". Довольно таки много примеров кода; как обычно, никто не гарантирует, что код тестирован. Будьте бдительны. + +🚧 [*Пожалуйста помогите дополнить этот неполный раздел.*](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 +- 📒 [Домашняя страница](https://aws.amazon.com/step-functions/) ∙ [Руководство разработчика](http://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) ∙ [ЧаВо](https://aws.amazon.com/step-functions/faqs/) ∙ [Расценки](https://aws.amazon.com/step-functions/pricing/) +- **Step Functions** - это способ AWS по созданию конечных автоматов, которые управляют бессерверным рабочим процессом. + +### Советы по Step Function +- Многообразие структур поддерживается, включая ветвление, параллельные операции и ожидание. +- [Задачи(Tasks)](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-tasks.html) представляют из себя реальные рабочие узлы и часто, лямбда функции, но также могут быть еще и [Активности(Activities)](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-activities.html) которые являются внешне управляемыми задачами, реализованными так, как вам угодно. +- У конечных автоматов есть [данные](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-state-machine-data.html), которые "обрабатываются" пошагово и могут быть изменены или добавлены, по мере запусков конечного автомата. +- Лучше всего, если ваши задачи являются идемпотентными, отчасти потому, что вы можете повторно запустить конечный автомат с теми же входными данными во время отладки +- Консоль AWS облегчает изучение состояния выполнения на различных этапах. + - Консоль позволяет сделать это за несколько шагов: + - выберите вкладку "input" на неудачно запущенном задании + - скопируйте входные данные (JSON) + - выберите имя конечного автомата в "хлебных крошках"(навигационной цепочке сверху) + - запустите новое выполнение, вставив входные данные, которые вы скопировали ранее + +### Ошибки и ограничения, связанные с Step Functions +- Step Functions на уровне бесплатного использования позволяет производить 4000 переходов в месяц бесплатно. Впоследствии, оплата составляет $0.025 за тысячу переходов. +- Вы можете производить множество одновременных запусков, однако помните о лимитах троттлинга lambda. Раньше эти ограничения был на учетную запись, на регион, но недавно их стало возможным устанавливать на уровне lambda функций. +- Запуски Step Function ограничены 25,000 событий. Каждый шаг создает несколько событий. Это означает, что [цикл с использованием Lambda](https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-create-iterate-pattern-section.html) ограничен количеством итераций равным 3000, после чего продолжение возможно [путем нового запуска](https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-continue-new.html). + +Route 53 +-------- + +### Основы Route 53 + +- 📒 [Домашняя страница](https://aws.amazon.com/route53/) ∙ [Руководство разработчика](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) ∙ [ЧаВо](https://aws.amazon.com/route53/faqs/) ∙ [Расценки](https://aws.amazon.com/route53/pricing/) +- **Route 53** - это DNS сервис AWS. + +### Альтернативы Route 53 и привязки + +- Исторически, AWS не спешил проникать на рынок DNS (поскольку это часто обусловлено предполагаемой надежностью и долгосрочными отношениями с поставщиками), но Route53 дошел до зрелой стадии и [становится стандартным вариантом](https://www.datanyze.com/market-share/dns/) для многих компаний. Route 53 дешев, согласно историческим стандартам DNS, так как он имеет большую глобальную сеть, с географическим DNS и другими ранее считавшимися “премиальными” функциями. Это удобно, если вы уже используете AWS. +- ⛓Как правило, вы не привязаны к провайдеру DNS для простых случаев использования, но все чаще становитесь связанными, когда используете определенные функции такие, как географическая маршрутизация или записи Route 53 alias. +- 🚪Существует множество альтернативных провайдеров DNS, начиная от давних премиальных брендов, таких как [UltraDNS](https://www.neustar.biz/services/dns-services) и [Dyn](http://dyn.com/managed-dns/) до менее известных, более скромных брендов, таким как [DNSMadeEasy](http://www.dnsmadeeasy.com/). Большинство экспертов DNS скажут вам, что рынок достаточно непрозрачен, что надежность и производительность не очень хорошо соотносятся с ценой. +- ⏱Route 53 обычно находится посредине в тестах производительности, например [отчеты SolveDNS](http://www.solvedns.com/dns-comparison/). + +### Советы по Route 53 + +- 🔹Знайте о записи Route 53 “alias”: + - Route 53 поддерживает все стандартные типы запросов DNS, но также имейте ввиду, что [**наборы записей псевдонимов ресурсов**](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) не являются стандартной частью DNS, а является специфичной функцией Route 53. (Она доступна и у других провайдеров DNS, но каждый провайдер предлагает ее под своим именем.) + - Псевдонимы(Alias) - это что-то вроде внутренних имен (немного похоже CNAME), которые резолвятся внутри на серверной стороне. Например,традиционно вы могли использовать CNAME для указание на DNS имя CLB или ALB, но гораздо лучше сделать псевдоним на тот же балансировщик нагрузки. Эффект тот же, но в последнем случае внешне все, что видит клиент - это цель, на которую указывает запись. + - Часто целесообразно использовать псевдонимы в качестве альтернативы CNAME, поскольку их можно мгновенно обновить с помощью вызова API, не беспокоясь о распространении DNS. + - Вы можете использовать их с CLB/ALB или любым другим ресурсом AWS, который их поддерживает. + - Что смущает, это то, что у вас могут быть псевдонимы типов CNAME и A, в зависимости от типа цели, на которую указывает запись. + - Поскольку псевдонимы являются расширениями для обычных записей DNS, при экспорте вывод [файл зоны](https://en.wikipedia.org/wiki/Zone_file) будет включать дополнительные строки с нестандартными записями “ALIAS”. +- [**Маршрутизация на основе времени задержки(Latency-based routing)**](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-latency) позволяет пользователям по всему земному шару автоматически направляться в ближайший регион AWS, в котором вы работаете, таким образом время задержки уменьшается. +- Поймите, что регистрация домена и управление DNS(размещение зон) - это две отдельные услуги Route 53. Когда вы покупаете/переносите домен, Route 53 автоматически назначает ему четыре сервера имен (например, ns-2.awsdns-00.com). Route 53 также предлагает автоматически создать зону для управления DNS, но вы не обязаны управлять зоной DNS в том же аккаунте или вообще в Route 53; вам просто нужно создать запись NS в Route 53, указывающую на серверы, назначенные вашему домену. + - Один из вариантов использования - провести регистрацию домена (очень критичного) в [бастионном аккаунте(bastion account)](https://cloudonaut.io/your-single-aws-account-is-a-serious-risk/), а управлять зоной в другом аккаунте, который доступен для ваших приложений. + +### Ошибки и ограничения, связанные с Route 53 +- 🔸Приватные зоны отвечают только на DNS запросы, которые исходят из VPC. В результате, Route 53 не будет отвечать на запросы сделанные через VPN или Direct connect. Чтобы это обойти вам необходимо реализовать [решение DNS в гибридном облаке](https://d1.awsstatic.com/whitepapers/hybrid-cloud-dns-options-for-vpc.pdf) или использовать IP адреса выданные Simple AD для запросов к внутренней зоне. + + +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, которые никогда не истекают. + +VPC, Сетевая безопасность и Группы безопасности +------------------------------------------- + +### Основы VPC + +- 📒 [Домашняя страница](https://aws.amazon.com/vpc/) ∙ [Руководство пользователя](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide) ∙ [ЧаВо](https://aws.amazon.com/vpc/faqs/) ∙ [Группы безопасности](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) ∙ [Расценки](https://aws.amazon.com/vpc/pricing/) +- **VPC** (Виртуальное частное облако(Virtual Private Cloud)) - это виртуализированный сетевой уровень ваших систем AWS. +- Большая часть пользователей AWS должна иметь базовое понимание концепций VPC, но только некоторым потребуется разбираться во всех деталях. Конфигурации VPC могут быть простейшими или экстремально сложными, в зависимости от степени требований к вашей сети и безопасности. +- Все современные учетные записи AWS (которые созданы [после 2013-12-04](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html)) являются аккаунтами “EC2-VPC”, которые поддерживают VPC и все инстансы находятся в VPC по умолчанию. Более старые учетные записи могут до сих пор использовать режим “EC2-Classic”. Некоторые функции не работают без VPC, так что вы наверняка захотите [мигрировать](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html). + +### Советы по VPC и сетевой безопасности + +- ❗**Группы безопасности(Security Groups)** - первая линия обороны ваших серверов. Экстремально ограничиваейте набор открытых портов для всех входящих соединений. В общем, если вы используете CLB, ALB или любой другой балансировщик траффика, единственные порты, которые должны быть открыты - это порт 22 и любой порт, который использует ваше приложение. Политика доступа в группах безопасности - 'запрет по умолчанию'. +- **Гигиена портов:** Хорошей привычкой является выбор уникальных портов из необычного диапазона для каждого из разных типов продуктивных сервисов. Например, ваш фронтенд веб-сервер может использовать порт 3010, ваши бэкенд сервера - порты 3020 и 3021, а ваш инстанс Postgres обычный порт 5432. Затем убедитесь, что у вас есть детализированные группы безопасности для каждого набора серверов. Это делает вас дисциплинированным в отношении учета ваших сервисов, а также обеспечит дополнительную защиту от ошибок. Например, если у вас случайно есть дополнительный сервер Apache, работающий на порте 80 по умолчанию на внутреннем сервере, он не будет выставлен наружу. +- **Миграция с EC2-Classic**: Для миграции со старых развертываний EC2-Classic в современный EC2-VPC прочтите [эту статью](http://blog.kiip.me/engineering/ec2-to-vpc-executing-a-zero-downtime-migration/), она может помочь. + - Вы можете [переносить Elastic IP между EC2-Classic и EC2-VPC](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-eip-migration). +- Для основного использования AWS, вполне достаточного одного VPC по умолчанию. Но, по мере расширения, вам стоит рассмотреть более тщательное составление вашей сетевой топологии. Хороший обзор лучших практик - [тут](http://blog.flux7.com/blogs/aws/vpc-best-configuration-practices). +- Рассмотрите возможность управления доступом к вашим частным ресурсам AWS через [VPN](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpn-connections.html). + - Вы получаете прозрачность и контроль подключений и попыток подключения. + - Вы предоставляете меньшую площадь для атаки по сравнению с раскрытием отдельных (потенциально аутентифицированных) сервисов через общедоступный Интернет. + - Например, баг в парсере YAML, который используется на админстративном сайте Ruby on Rais, является гораздо менее серьезной проблемой, если админстративный сайт виден только из внутренней сети и доступен только через VPN. + - Другой распространенный шаблон (особенно по мере увеличения масштабов развертывания, ужесточения требований к безопасности или нормативных требований или увеличения размеров группы) - это обеспечение создания [узла бастиона](https://www.pandastrike.com/posts/20141113-bastion-hosts) за VPN, через который должны проходить все соединения SSH. + - Для дешевого VPN доступа к частным ресурсам AWS рассмотрите возможность использования программного обеспечения VPN «точка-сайт», такого как [OpenVPN](https://openvpn.net/). Он может быть установлен, как используя [официальный AMI](https://docs.openvpn.net/how-to-tutorialsguides/virtual-platforms/amazon-ec2-appliance-ami-quick-start-guide/), правда на бесплатной лицензии вы ограничены 2 одновременными пользователями, или может быть установлен используя пакет openvpn на Linux. Пакет для Linux допускает неограниченное количество одновременных пользователей, но установка менее проста. Этот [скрипт установки OpenVPN](https://github.com/Nyr/openvpn-install) поможет вам легко провести установку и добавить клиентские ключи. +- 🔹Подумайте об использовании других групп безопасности в качестве источников для правил групп безопасности вместо использования CIDR - таким образом, всем узлам в исходной группе безопасности и узлам в этой группе безопасности, и только им разрешен доступ. Это гораздо более динамичный и безопасный способ управления правилами групп безопасности. +- **Поточные логи VPC(VPC Flow Logs)** позволяет вам мониторить сетевой траффик, как входящий, так и исходящий, а также траффик внутри VPC. Логи сохраняются в группах логов CloudWatch и могут использоваться для мониторинга безопасности (с использованием сторонних инструментов), оценки производительности и расследования информационных инцидентов. + - Ознакомьтесь [с руководством пользователя по поточным логам VPC(VPC Flow Logs)](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html) для получения общей информации. + - Рассмотрите инструмент для коммандной строки и библиотеку для Python [flowlogs-reader](https://github.com/obsrvbl/flowlogs-reader) для получения и работы с поточными логами VPC. +- **IPv6** [доступен в VPC](https://aws.amazon.com/blogs/aws/new-ipv6-support-for-ec2-instances-in-virtual-private-clouds/). Наряду с этим объявлением, прошло представление [Интернет шлюза только-на-исход(Egress-Only Internet Gateway)](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/egress-only-internet-gateway.html). В тех случаях, когда можно использовать шлюзы NAT для включения только исходящего трафика для их VPC в IPv4, можно использовать интернет шлюз только-на-исход только для той же цели в IPv6. + +- По вашему запросу Amazon предоставляет блок CIDR IPv6 для вашего VPC - в настоящее время вы не можете подключить свой собственный блок IPv6, если так случилось, что он у вас уже есть. +- Новые и существующие VPC могут использовать IPv6. Существующие VPC должны быть настроены так, чтобы с ними ассоциировался блок CIDR IPv6, также, как и в новых VPC. + +### PrivateLink +- 📒[Домашняя страница](https://aws.amazon.com/privatelink/) ∙ [Руководство пользователя](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) ∙ [Расценки](https://aws.amazon.com/privatelink/pricing/) +- Одним из способов применения Private link является [интерфейс конечных точек VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) который разворачивает ENI в вашем VPC и подсетях, что позволяет получить прямой доступ к API AWS таким образом, как если бы они были бы доступны локально в вашем VPC без необходимости выхода в интернет. +- Другим вариантом использования является возможность открытия вашего сервиса другим учетным записям AWS через [сервис конечных точек VPC(VPC Endpoint Service)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) + +### Ошибки и ограничения, связанные с VPC и сетевой безопасностью +- 🔸VPC привязаны к одному региону в одной учетной записи. Подсети привязаны к одному VPC и ограничены одной зоной доступности. +- 🔸Группы безопасности привязаны к одному VPC. Если вы используете инфраструктуру в нескольких VPC, вы должны убедиться, что ваши инструменты конфигурации/развертывания учитывают это. +- 🔸[Конечные точки VPC](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html) на текущий момент доступны только для S3 и DynamoDB. Если требования безопасности включают необходимость блокировки исходящего траффика с вашей VPC, возможно вы захотите воспользоваться [DNS фильтрацией](https://aws.amazon.com/blogs/security/how-to-add-dns-filtering-to-your-nat-instance-with-squid/) для контроля исходящего траффика к другим сервисам. +- ❗Будьте аккуратны при выборе CIDR блока ip-адресов для VPC: Если вам будет необходимо использовать [ClassicLink](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-classiclink.html), убедитесь, что ваш частный диапазон IP-адресов [не пересекается](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-classiclink.html#classiclink-limitations) с диапазоном EC2 Classic. +- ❗Если вы собираетесь соединение между VPC, тщательно изучите стоимость [передачи данных между VPC](https://aws.amazon.com/vpc/faqs/#Peering_Connections), так как для отдельных рабочих нагрузок и интеграций, она может быть чрезмерно дорогой. +- ❗Для новых инстансов RDS требуется [группа подсетей](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.Subnets) в вашем VPC. Если вы используете [VPC по умолчанию](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/default-vpc.html), это не будет проблемой, так как VPC содержит подсеть для каждой зоны доступности в вашем регионе. В любом случае, если вы создаете свой VPC и планируете использование RDS, убедитесь, что у вас есть как минимум две подсети в VPC, чтобы выступать в виде группы подсетей. +- ❗Если вы удалили VPC по умолчанию, вы можете [пересоздать через CLI или через консоль](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/default-vpc.html#create-default-vpc). +- ❗Будьте крайне аккуратны с учетными данными VPN для подключения к VPC! Если они потеряны или скомпроментированы, конечная точка VPN должна быть удалена и пересоздана. Ознакомьтесь с инструкцией по [замене скомпроментированных учетных данных](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html#CompromisedCredentials). +- ❗Группы безопасности и таблицы маршрутов применяют записи отдельно для IPv4 и IPv6, поэтому необходимо убедиться, что записи добавлены для обоих протоколов соответственно. +- 💸Управляемый шлюзы NAT это удобная альтернатива управляемому вручную [инстансу NAT](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPCNATInstance.html), но они тарифицируются погигабайтно. Рассмотрите [альтернативные варианты](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-comparison.html) если вы передаете много терабайт из частных подсетей в интернет. Если вы передаете терабайты/петабайты данных с инстансов EC2 из частных подсетей в S3, избегайте [оплаты за обработку данных шлюзом NAT](https://aws.amazon.com/vpc/pricing/) путем установки шлюзовой конечной точки VPC и направляйте траффик в/из S3 через эту конечную точку, вместо того, чтобы пересылать данные через шлюз NAT. + +KMS +--- + +### Основы KMS + +- 📒 [Домашняя страница](https://aws.amazon.com/kms/) ∙ [Руководство разработчика](http://docs.aws.amazon.com/kms/latest/developerguide/) ∙ [ЧаВо](https://aws.amazon.com/kms/faqs/) ∙ [Расценки](https://aws.amazon.com/kms/pricing/) +- **KMS** (Сервис управления ключами(Key Management Service)) это безопасный сервис для создания, хранения и аудита использования криптографических ключей. +- **Интеграция сервисов:** KMS [интегрируется с другими сервисами AWS ](http://docs.aws.amazon.com/kms/latest/developerguide/service-integration.html): EBS, Elastic Transcoder, EMR, Redshift, RDS, SES, S3, WorkMail и Workspaces. +- **API шифрования:** [API шифровать](http://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html) и [API дешифровать API](http://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) позволяют вам зашифровывать и расшифровывать данные на стороне сервиса KMS, никогда не раскрывая содержимого мастер ключа. +- **Ключи данных:** API [GenerateDataKey](http://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#data-keys) генерирует новый ключ с мастер ключа. Содержимое ключа данных доступно вам, поэтому вы можете использовать его для шифрования и дешифрования данных любого уровня на уровне приложения. KMS не хранит, не управляет и не отслеживает ключи данных, вы несете ответственность за это в своем приложении. +- 🔹**Аудит использования:** Настройте CloudTrail для аудита вызовов API KMS. +- **Доступ:** Используйте [политики ключей(key policies)](http://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) и [политики IAM ](http://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html) для предоставления различного уровня доступов к KMS. Например, вы можете создать политику IAM которая только [позволяет пользователю шифровать и расшифровывать данные с конкретным ключем](http://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html#iam-policy-example-encrypt-decrypt-specific-cmks). + +### Советы по KMS + +- 🔹В компаниях очень распространено полное управление ключами с помощью собственных механизмов, но с самого начала гораздо предпочтительнее использовать такие службы, как KMS, так как это способствует более безопасному проектированию и улучшает политики и процессы управления ключами. +- Хорошая мотивация и обзор в [этой презентации от AWS](http://www.slideshare.net/AmazonWebServices/encryption-and-key-management-in-aws). +- Детальная информация о криптографии [в этой белой книге от AWS](https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf). +- [Эта публикация от Convox](https://convox.com/blog/encryption-at-rest) демонстрирует, почему и как использовать KMS для шифрования при хранении. + +### Ошибки и ограничения, связанные с KMS + +- 🔸 Encrypt API работает только с данными < 4KB. Большие объемы данных требуют создания и использования[ключа данных](http://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#data-keys) на уровне приложения. +- 🔸Аудит событий KMS не доступен через [CloudTrail Lookup Events API](http://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_LookupEvents.html). Их можно посмотреть в сырых файлах .json.gz, которые CloudTrail сохраняет в S3. +- 🔸Чтобы зашифровать загрузку нескольких частей на S3, политика ключей KMS должна разрешать “kms:Decrypt” и “kms:GenerateDataKey*” в дополнение к “kms:Encrypt”, иначе загрузка закончится неудачей с ошибкой “AccessDenied”. +- 🔸Ключи KMS зависят от региона - они хранятся и могут использоваться только в том регионе, в котором они созданы. Их нельзя перенести в другие регионы. +- 🔸Ключи KMS имеют политику ключей, которая должна предоставлять доступ к чему-либо для управления ключом. Если вы не предоставляете доступ к ключу при создании, вам нужно обратиться в службу поддержки, чтобы сбросить политику ключа [снизьте риски того, что ключ станет неуправляемым](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-root-enable-iam). +- 🔸Если вы используете политику ключей для предоставления доступа ролям или пользователям IAM, а затем удаляете пользователя/роль, воссоздание пользователя или роли не вернет разрешение на ключ. + + +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 + +- 📒 [Домашняя страница](https://aws.amazon.com/redshift/) ∙ [Руководство разработчика](http://docs.aws.amazon.com/redshift/latest/dg/) ∙ [ЧаВо](https://aws.amazon.com/redshift/faqs/) ∙ [Расценки](https://aws.amazon.com/redshift/pricing/) +- **Redshift** это управляемое AWS [хранилище данных](https://en.wikipedia.org/wiki/Data_warehouse), которое предоставляет возможности параллельной работы, масштабируемости и является столбчатым хранилищем. Он очень широко используется. Он [был создан](https://en.wikipedia.org/wiki/Amazon_Redshift) используя технологию [ParAccel](https://en.wikipedia.org/wiki/ParAccel) и предоставляет [Postgres](https://en.wikipedia.org/wiki/PostgreSQL)-совместимые интерфейсы. + +### Альтернативы Redshift и привязки + +- ⛓🚪Какое бы хранилище данных вы ни выбрали, ваш бизнес, вероятно, будет завязан на него на долгое время. Также (и не случайно) рынок хранилищ данных сильно фрагментирован. Выбор хранилища данных - это выбор, который нужно сделать осторожно, с исследованием и осознанием [рыночного ландшафта](https://www.datanami.com/2016/03/14/data-warehouse-market-ripe-disruption-gartner-says/) а также с учетом инструментов [бизнес аналитики](https://en.wikipedia.org/wiki/Business_intelligence), которые вы планируете использовать. + +### Советы по Redshift + +- Хотя Redshift в основном Postgres-совместим, его SQL диалект и профили производительности отличаются. +- Redshift поддерживает только [12 примитивных типов данных](https://docs.aws.amazon.com/redshift/latest/dg/c_Supported_data_types.html). ([Список неподдерживаемых типов Postgres](https://docs.aws.amazon.com/redshift/latest/dg/c_unsupported-postgresql-datatypes.html)\) +- Он имеет ноду-лидер и вычислительные ноды (лидер распределяет запросы по вычислительным). Обратите внимание, что некоторые функции [могут выполняться только на лидерской ноде.](https://docs.aws.amazon.com/redshift/latest/dg/c_SQL_functions_leader_node_only.html) +- 🔹Обязательно создайте новую [группу параметров кластера](http://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) и группу опций базы данных, так как группа параметров по умолчанию не позволяет динамических изменений конфигурации. +- Основные сторонние инструменты BI поддерживают интеграцию с Redshift (Прочтите публикацию [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) предоставляет превосходный список методов настройки производительности. +- [Amazon Redshift Utils](https://github.com/awslabs/amazon-redshift-utils) содержит полезные утилиты, скрипты и представления для упрощения работы с Redshift. +- Запускайте [VACUUM](http://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html) регулярно после большого количества удалений или обновлений, чтобы освободить пространство и повысить производительность запросов. +- Избегайте выполнения всеховатывающих команд[VACUUM](http://docs.aws.amazon.com/redshift/latest/dg/r_VACUUM_command.html) или [ANALYZE](http://docs.aws.amazon.com/redshift/latest/dg/r_ANALYZE.html) на уровне кластера. Проверки каждой таблицы для определения необходимости выполнения действия VACUUM или ANALYZE ресурсоемки. Выполняйте команды ANALYZE и VACUUM на тех объектах, которым это требуется. Используйте [Analyze & Vacuum Schema Utility](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AnalyzeVacuumUtility) чтобы сделать это. SQL-запрос для определения необходимости выполнения команд VACUUM или ANALYZE для таблицы, может быть найден тут - [Schema Utility README](https://github.com/awslabs/amazon-redshift-utils/blob/master/src/AnalyzeVacuumUtility/README.md), если вам необходимо создать собственный процесс обслуживания. +- Redshift предлагает различные варианты [сжатия столбцов](http://docs.aws.amazon.com/redshift/latest/dg/t_Compressing_data_on_disk.html) чтобы оптимизировать размер хранимых данных. AWS настоятельно рекомендует пользователям использовать [автоматическое сжатие](http://docs.aws.amazon.com/redshift/latest/dg/c_Loading_tables_auto_compress.html) на стадии [COPY](https://docs.aws.amazon.com/redshift/latest/dg/r_COPY.html), когда Redshift использует выборку данных для анализа параметров сжатия столбцов. В любом случае, автоматическое сжатие может быть применено только к пустой таблице, без каких либо данных. Поэтому убедитесь, что исходный пакет загрузки достаточно большой, чтобы предоставить Redshift репрезентативную выборку данных (размер выборки по умолчанию составляет 100 000 строк). +- Redshift использует столбцовое хранилище, следовательно, у него нет возможностей индексирования. В любом случае вы можете использовать [distribution key](http://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-best-dist-key.html) и [sortkey](http://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-sort-key.html) для повышения производительности. Redshift имеет два типа ключей сортировки: составной ключ сортировки и чередующийся ключ сортировки. +- Составной ключ сортировки составлен из всех столбцов, перечисленных в определении ключа сортировки. Это наиболее полезно, когда у вас есть запросы с операциями с использованием префикса ключа сортировки. +- С другой стороны, чередующийся ключ сортировки дает одинаковый вес каждому столбцу или подмножеству столбцов в ключе сортировки. Поэтому, если вы заранее не знаете, какие столбцы нужно выбрать для сортировки и фильтрации, это гораздо лучший выбор, чем составной ключ. [Тут](https://aws.amazon.com/blogs/aws/quickly-filter-data-in-amazon-redshift-using-interleaved-sorting/) пример чередующегося ключа сортировки. +- 🔸⏱ **Стратегии распределения:** Поскольку данные в Redshift физически распределяются между узлами, выбор правильного **ключа распределения** данных и [стиля распределения](http://docs.aws.amazon.com/redshift/latest/dg/c_choosing_dist_sort.html) является критичным для адекватной производительности запросов. Существуют три возможных выбора стиля распределния — **EVEN** (по умолчанию), **KEY** или **ALL**. Используйте KEY, чтобы сопоставить столбцы join key для таблиц, которые объединены в запросы. Используйте ALL для того, чтобы поместить данные в маленькие таблицы на всех нодах кластера. + +### Ошибки и ограничения, связанные с Redshift + +- ❗⏱Хотя Redshift может хорошо обрабатывать тяжелые запросы, он не масштабируется по горизонтали, то есть не обрабатывает несколько запросов параллельно. Поэтому, если вы ожидаете высокую параллельную нагрузку, рассмотрите возможность репликации или (если возможно) разделения ваших данных между несколькими кластерами. +- 🔸 Лидер-нода, которая управляет связью с клиентскими программами и всей связью с вычислительными узлами, является единой точкой отказа. +- ⏱Хотя большинство запросов Redshift хорошо распараллеливаются на уровне вычислительных узлов, на лидер-ноде выполняются определенные этапы, которые могут стать узким местом. +- 🔹Транзакции передачи данных Redshift очень дороги и запускаются сериями на уровне кластера. Поэтому, по возможности, рассмотрите возможность группировки нескольких команд изменения (COPY/INSERT/UPDATE) в одну транзакцию, когда это возможно. +- 🔹Redshift не поддерживает развертывания в нескольких зонах доступности. Построение кластеров в нескольких зонах доступности не является чем-то простым. [Тут](https://blogs.aws.amazon.com/bigdata/post/Tx13ZDHZANSX9UX/Building-Multi-AZ-or-Multi-Region-Amazon-Redshift-Clusters) есть пример с использованием Kinesis. +- 🔸Остерегайтесь хранить несколько небольших таблиц в Redshift. Способ размещения таблиц Redshift на диске делает его непрактичным. Минимальное место на диске необходимое для хранения таблицы (в MB) равно `nodes * slices/node * columns`. Например, в кластере из 16 нод, пустая таблица с 20 столбцами займет 640MB. +- ⏱ Производительность запросов значительно снижается во время получения данных. Настройки [WLM (Workload Management)](http://docs.aws.amazon.com/redshift/latest/dg/c_workload_mngmt_classification.html) помогают в некоторой степени. Однако, если вам нужна стабильная производительность чтения, подумайте о наличии реплики кластера (за дополнительную плату) и переключите их во время обновления. +- ❗ Никогда не изменяйте размер живого кластера. Операция изменения размера может занять несколько часов в зависимости от размера набора данных. В редких случаях операция также может зависнуть и, в итоге, у вас будет нефункциональный кластер. Более безопасный подход - создать новый кластер из снапшота, изменить размер нового кластера и удалить старый. +- 🔸Redshift имеет **зарезервированные ключевые слова**, которых нет в Postgres (полный список [тут](https://docs.aws.amazon.com/redshift/latest/dg/r_pg_keywords.html)). Остерегайтесь DELTA ([Delta Encodings](https://docs.aws.amazon.com/redshift/latest/dg/c_Delta_encoding.html)). +- 🔸Redshift не поддерживает многие функции Postgres, особенно несколько функций, связанных с датой/временем и агрегацией. Смотрите [полный список тут](https://docs.aws.amazon.com/redshift/latest/dg/c_unsupported-postgresql-functions.html). +- 🔸 Ограничения уникальности, первичного ключа и внешнего ключа для таблиц Redshift носят исключительно информативный характер и не применяются. Однако они используются оптимизатором запросов для создания планов запросов. Ограничения для столбцов `NOT NULL` применяются. Смотрите [тут](https://docs.aws.amazon.com/redshift/latest/dg/t_Defining_constraints.html) для получения большей информации об ограничениях. +- 🔸Сжатие ключа сортировки [может привести к значительному снижению производительности](https://aws.amazon.com/blogs/big-data/optimizing-for-star-schemas-and-interleaved-sorting-on-amazon-redshift/). Таким образом, если ваши запросы Redshift, включающие ключи сортировки, являются медленными, вам стоит рассмотреть возможность снятия сжатия для ключа сортировки. +- 🔹 [Выбор ключа сортировки](http://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html) очень важен, так как вы не сможете сменить ключ сортировки таблицы после создания. Если вам необходимо сменить ключ сортировки или распределения для таблицы, вам необходимо будет создать новую таблицу с новыми ключами и перенести данные запросом типа “insert into new_table select * from old_table”. +- ❗🚪 Когда переносите данные запросом типа “insert into x select from y”, вам потребуется иметь в два раза больше дискового пространства, чем таблица “y” занимает на дисках в кластере. Redshift сначала копирует данные на диск, а только потом в новую таблицу.[Здесь](https://www.periscopedata.com/blog/changing-dist-and-sort-keys-in-redshift.html) хорошая статья о том, как это происходит с большими таблицами. + +EMR +--- + +### Основы EMR + +- 📒 [Домашняя страница](https://aws.amazon.com/emr/) ∙ [Информация о выпуске](http://docs.aws.amazon.com/ElasticMapReduce/latest/ReleaseGuide/) ∙ [ЧаВо](https://aws.amazon.com/emr/faqs/) ∙ [Расценки](https://aws.amazon.com/emr/pricing/) +- **EMR** (раньше обозначал Elastic Map Reduce, но не теперь, поскольку теперь он далеко выходит за пределы функции map-Reduce) - это сервис, который предлагает управляемое развертывание [Hadoop](https://en.wikipedia.org/wiki/Apache_Hadoop), [HBase](https://en.wikipedia.org/wiki/Apache_HBase) и [Spark](https://en.wikipedia.org/wiki/Apache_Spark). Он уменьшает бремя самостоятельного управления и настройки этих сервисов. + +### Альтернативы EMR и привязки + +- ⛓Большая часть EMR основана на технологии с открытым исходным кодом, которую вы, в принципе, можете развернуть самостоятельно. Однако рабочие процессы и многие другие инструменты зависят от AWS. Переход от EMR к вашим собственным кластерам возможен, но не всегда тривиален. + +### Советы по EMR + +- EMR опирается на многие версии Hadoop и другого вспомогательного программного обеспечения. Не забудьте проверить [какие версии используются](https://docs.aws.amazon.com/ElasticMapReduce/latest/ReleaseGuide/emr-release-components.html). +- ⏱Развернутые EMR и Hadoop могут иметь значительный оверхэд по сравнению с эффективным процессингом на одной машие. Если у вас немного данных и производительность имеет значение, вам стоит рассмотреть альтернативы, как например в этой [публикации](http://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html). +- Разработчики на Python также могли б обратить внимание на [mrjob](https://github.com/Yelp/mrjob) от Yelp. +- Требуется определенное время для тонкой настройки производительности задач EMR, именно поэтому сторонние сервисы, такие как [Qubole’s data service](https://www.qubole.com/mapreduce-as-a-service/) завоевывают популярность, как метод повышения производительности и снижения затрат. + +### Ошибки и ограничения, связанные с EMR + +- 💸❗**Затраты на EMR** могут быстро накапливаться, так как используется множетсво инстансов, кроме того, эффективность может быть низкой, в зависимости от конфигурации кластера и выбора рабочих нагрузок, кроме того, инциденты вроде зависших задач могут быть весьма дорогостоящими. Посмотрите[раздел управления затратами EC2](#управление-затратами-на-ec2), особенно советы относительно спотовых инстансов. [Эта публикация](https://aws.amazon.com/blogs/big-data/strategies-for-reducing-your-amazon-emr-costs/) также дает дополнительные советы, однако была написана до перехода на посекундную тарификацию. +- 💸 Опасайтесь “двойных затрат”. С EMR вы платите за вычислительную емкость EC2 и сервисные платежи. В дополнение, EMR синхронизирует логи задач с S3, что означает, что вы платите за хранилище и **PUT запросы** по [расценкам S3 standard](https://aws.amazon.com/s3/pricing/#Request_Pricing). Хотя лог файлы имеют обыкновение быть относительно мелкими, каждая задача Hadoop, в зависимости от размера генерирует тысячи лог файлов, которые легко могут накинуть тысячи долларов к вашему счету от AWS. [Аггрегация логов YARN](http://hortonworks.com/blog/simplifying-user-logs-management-and-access-in-yarn/) не доступна в EMR. + +Kinesis Streams +--- + +### Основы Kinesis Streams + +- 📒 [Домашняя страница](https://aws.amazon.com/kinesis/streams/) ∙ [Руководство разработчика](https://docs.aws.amazon.com/streams/latest/dev/introduction.html) ∙ [ЧаВо](https://aws.amazon.com/kinesis/streams/faqs/) ∙ [Расценки](https://aws.amazon.com/kinesis/streams/pricing/) +- **Kinesis Streams** (который ранее назывался просто Kinesis, до выхода Kinesis Firehose и Kinesis Analytics) - это сервис, который позволяет вам использовать высокопроизводительные потоки данных для немедленной или отложенной обработки другими сервисами AWS. +- Субкомпонентны Kinesis Streams называются [**шарды(shards)**](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html). Каждый шард предоставляет возможность записи со скоростью 1MB/s и чтения со скоростью 2MB/s с максимальной частотой 5 операций чтения в секунду. Шарды в потоке можно уменьшать и увеличивать программно на основе множества метрик. +- Всем записям, введенным в Kinesis Stream, присваивается уникальный порядковый номер по мере их получения. Записи в потоке упорядочены по этому номеру, поэтому любой порядок времени сохраняется. +- [На этой странице](http://docs.aws.amazon.com/streams/latest/dev/key-concepts.html) обобщаются ключевые понятия и концепции Kinesis Streams. + +### Альтернативы Kinesis Streams и привязки + +- 🚪 Kinesis наиболее сравним с [Apache Kafka](https://kafka.apache.org/), решением по приему данных с открытым кодом. Возможно развернуть кластер Kafka на [инстансах EC2](#ec2) (или любом другом VPS), в любом случае вы будете нести ответственность за управление и поддержку как Zookeeper, так и Kafka в высокодоступной конфигурации. Confluent опубликовали хорошую статью с их рекомендациями, как это сделать [тут](http://www.confluent.io/blog/design-and-deployment-considerations-for-deploying-apache-kafka-on-aws/), внизу есть ссылки на несколько других блогов, которые они написали на эту тему. +- ⛓ Kinesis использует очень AWS-специфичные API, так что вы должны быть в курсе потенциальных будущих затрат по обратной миграции, если вы выберете его. +- Приложение, которое эффективно использует Kinesis Streams, будет масштабировать количество шардов вверх и вниз в зависимости от требуемой пропускной способности. (Имейте ввиду, что прямого эвкивалента этому в Apache Kafka нет.) + + +### Советы по Kinesis Streams + +- [KCL](https://docs.aws.amazon.com/streams/latest/dev/developing-consumers-with-kcl.html) (Библиотека клиента Kinesis(Kinesis Client Library))предоставляет скелетный интерфейс для программ на Java, Node, Python, Ruby и .NET, которые легко используют данные из потока Kinesis. Чтобы начать использовать данные из потока, вам нужно только предоставить файл конфигурации, указывающий на правильный поток Kinesis, и функции для инициализации потребителя, обработки записей и выключения потребителя. + - KCL использует таблицу DynamoDB для отслеживания обработанных записей. Это гарантирует, что все записи обрабатываются “хотя бы раз”. Заботой программиста является необходимость удостовериться, что программа может обрабатывать дважды обработанные записи. + - KCL также использует DynamoDB для отслеживания других “воркеров” KCL. Он автоматически распределяет доступные шарды Kinesis между всеми воркерами поровну. + +### Ошибки и ограничения, связанные с Kinesis Streams + +- 🔸⏱ Каждый шард Kinesis Streams позволяет совершать [5 операций чтения в секунду](http://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html). Если вы равномерно распределяете данные по множеству шардов, ваш предел частоты чтения для потока останется на уровне 5 операций чтения в секунду в совокупности, поскольку каждое приложение-потребитель должно будет проверять каждый отдельный шард на наличие новых записей. Это накладывает жесткое ограничение на количество различных приложений-потребителей, возможных на поток, из-за данной максимальной задержки чтения. + - Например, если у вас есть 5 приложений-потребителей, считывающих данные из одного потока с любым количеством шардов, они не могут читать с задержкой менее одной секунды, поскольку каждому из 5 потребителей потребуется опрашивать *каждый шард* каждую секунду, достигая предела 5 операций чтения в секунду. + - [Эта публикация](https://brandur.org/kinesis-in-production) является продолжением обсуждения производительности ии ограничений Kinesis в эксплуатации. +- 💸 **Kinesis Streams не включен в бесплатный уровень использования.** Убедитесь ,что вы отключили поток, если экспериментировали с ним в личном аккаунте, иначе это может привести к неожиданным издержкам (~$11 за шард-месяц.) + +Kinesis Firehose +--- + +### Ошибки и ограничения, связанные с Kinesis Firehose + +- 🔸 📜 Будучи пересылаемым с Firehose в Elasticsearch, документ в формате JSON не может содержать свойство “_id”. Firehose не будет пытаться доставить такие документы и в логах не будет отражено никаких ошибок. + + +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 + +* 📒 [Домашняя страница](https://aws.amazon.com/mobile/) ∙ [Руководство пользователя](https://docs.aws.amazon.com/mobile-hub/latest/developerguide/) ∙ [ЧаВо](https://aws.amazon.com/mobile/faqs/) ∙ [Расценки](https://aws.amazon.com/mobile/pricing/) +- **Mobile Hub** оркестрирует несколько сервисов для создания серверной части в AWS для мобильных и веб-приложений. +- Каждый _проект_ в Mobile Hub имеет один _бэкенд_ состоящий из настраиваемых функций, и одно или более _приложений_. + - Функции включают в себя Аналитику(Analytics), Облачную логику(Cloud Logic), Разговорных ботов(Conversational Bots), Хостинг и стриминг(Hosting and Streaming), Базы данных NoSQL(NoSQL Database), Хранилище пользовательских данных(User Data Storage) и Авторизацию пользователей(User Sign-In). Каждая функция использует один или два сервиса, для предоставления куска функциональности. + - Используемые сервисы включают в себя, [API Gateway](#api-gateway), [CloudFront](#cloudfront), Cognito, [Device Farm](#device-farm), [DynamoDB](#dynamodb), [Lambda](#lambda), Lex, Pinpoint и [S3](#S3). + - Существуют SDK для Android (Java), iOS (Swift), Web (JS) и React Native (JS). Также имеется CLI для приложений JavaScript. + +### Советы по Mobile Hub +- [Консоль Mobile Hub](https://console.aws.amazon.com/mobilehub/home#/) содержит наборы для старта и учебные пособия для различных платформ. +- CLI позволяет проводить локальную разработку Lambda-кода (по умолчанию на JS) с использованием команд `awsmobile {pull|push}` для синхронизации локальной папки с облаком и обратно. +- Mobile Hub сам по себе бесплатен, но каждый используемый сервис имеет свою модель оплаты и расценок. + +### Ошибки и ограничения, связанные с Mobile Hub +- 🔸Функция Cloud API позволяет импортировать существующую функцию Lambda вместо определения новой, но с CLI есть некоторые косяки. Для подробной информации смотрите в GitHub [issues](https://github.com/aws/awsmobile-cli/issues). +- ❗Mobile Hub использует CloudFormation под капотом и сильно тупит, когда сервис меняется вне консоли Mobile Hub. + +IoT +--- + +### Основы IoT + +* 📒 [Домашняя страница](https://aws.amazon.com/iot/) ∙ [Руководство пользователя](https://docs.aws.amazon.com/iot/latest/developerguide/) ∙ [ЧаВо](https://aws.amazon.com/iot/faqs/) ∙ [Расценки](https://aws.amazon.com/iot/pricing/) +- **IoT** - это платформа, позволяющая клиентам, таким как устройства IoT или программные приложения ([примеры](http://internetofthingswiki.com/iot-applications-examples/541/)) связываться с облаком AWS. +- Клиенты, также называемые **устройствами** (или **вещами**) включают в себя обширный диапазон различных типов устройств. В общем есть три категории типов устройств, которые могут взаимодействовать с сервисами IoT путем отсылки сообщений по IoT протоколу, используя брокер сообщений типа Pub/Sub, называемый IoT **Device Gateway**: + * Только отправка сообщений: Как пример - [AWS IoT Button](https://aws.amazon.com/iot/button/) для [маячка eddystone](http://developer.estimote.com/eddystone/). + * Отправка, прием и обработка сообщений: Например, простая плата обработки, типа **Raspberry Pi** ([руководство по быстрому старту](http://docs.aws.amazon.com/iot/latest/developerguide/iot-device-sdk-c.html)), или устройство от AWS, как например [Echo или Echo Dot](https://developer.amazon.com/echo), которые спроектированы для работы с [AWS Alexa skills kit](https://developer.amazon.com/alexa-skills-kit) (программироуемые голосовой сервис от AWS). +- У AWS есть полезное [руководство по быстрому старту](http://docs.aws.amazon.com/iot/latest/developerguide/iot-gs.html) (используя консоль) и [слайдовая презентация](http://www.slideshare.net/AmazonWebServices/connecting-to-aws-iot) по базовым темам. +* **Терминология IoT:** + * AWS [**IoT Things**](http://docs.aws.amazon.com/iot/latest/developerguide/iot-thing-management.html) (метаданные для устройств в хранятся в [реестре](http://docs.aws.amazon.com/iot/latest/developerguide/iot-thing-management.html)), а также позволяет хранить состояние устройства в документе формата JSON, который зовется [**тенью устройства(device shadow)**](http://docs.aws.amazon.com/iot/latest/developerguide/iot-thing-shadows.html). Метаданные устройства также могут храниться в [**Типах вещей IoT(IoT Thing Types)**](http://docs.aws.amazon.com/iot/latest/developerguide/thing-types.html). Это помогает в управлении метаданными устройства, позволяя повторно использовать описание и конфигурацию устройства для более чем одного устройства. Имейте ввиду, что типы вещей IoT могут устаревать, но не меняться - они неизменны. + * AWS [**IoT Certificates**](http://docs.aws.amazon.com/iot/latest/developerguide/attach-cert-thing.html) (аутентификация устройств) - является логическим сопоставлением уникального сертификата логическому представлению устройства. Это сопоставление может быть сделано в консоли. Вдобавок, публичный ключ сертификата должен быть скопирован на физическое устройство. Это касается аутентификации устройств на конкретном шлюзе устройств AWS (Device Gateway) (брокере сообщений). Вы можете назначать IoT устройствам IoT сертификаты от AWS или вы можете [развернуть свой собственный центр сертификации CA (Certificate Authority) в AWS](http://docs.aws.amazon.com/iot/latest/developerguide/device-certs-your-own.html), выпускать свои собственные сертификаты и назначать эти сертификаты на устройства через консоль AWS или командную строку. + * AWS [**IoT Policies**](http://docs.aws.amazon.com/iot/latest/developerguide/authorization.html) (авторизация устройства/темы)- это файлы в формате JSON, которые ассоцииированы с одним или несколькими сертификатами AWS IoT. Таким образом назначенным устройствам разрешается публиковать и/или подписываться на сообщения из одного или более топиков MQTT. + * AWS [**IoT Rules**](http://docs.aws.amazon.com/iot/latest/developerguide/iot-rules.html) являются SQL-подобными запросами, которые позволяют повторно использовать некоторые или все данные сообщений устройства, как описано в [этой презентации, в которой обобщаются шаблоны проектирования для правил IoT](http://www.slideshare.net/AmazonWebServices/programming-the-physical-world-with-device-shadows-and-rules-engine-66486454). + * Представленная ниже [инфографика](https://aws.amazon.com/iot/how-it-works/) обобщает поток сообщений между сервисами AWS IoT: + +![Как работает AWS IoT](https://d0.awsstatic.com/IoT/diagrams/awsiot-how-it-works_HowITWorks_1-26.png "Как работает AWS IoT") + +### IoT Greengrass + +* 📒 [Домашняяя страница](https://aws.amazon.com/greengrass/) +* 🐥**Greengrass** это программная платформа, которая расширяет возможности AWS IoT, позволяя выполнять функции Lambda непосредственно на локальных устройствах. Это также позволяет устройствам IoT иметь возможность безопасного обмена данными в локальной сети без необходимости подключения к облаку. + * Greengrass включает в себя локальный менеджер сообщений, который может буферизовать сообщения в случае потери связи, чтобы сохранить входящие и исходящие в облако сообщения. Лямбда-функции, развернутые локально, могут запускаться локальными событиями, сообщениями из облака или другими источниками. + * Greengrass включает безопасную аутентификацию и авторизацию устройств в локальной сети, а также между локальной сетью и облаком AWS. Он также обеспечивает безопасное обновление программного обеспечения функций Lambda. +* Greengrass включает в себя менеджер сообщений, окружение Lambda, локальная копия сервиса для теней устройств и агент для уплавления групповой конфигурацией Greengrass. +* **Группы Greengrass(Greengrass groups)** - это контейнера, для настроек, подписок и назначенных лямбда функций для выбранных IoT устройств. В группе Greengrass устройство является либо ядром Greengrass, либо устройством IoT, которое будет подключено к этому конкретному ядру Greengrass. +* Greengrass Core SDK позволяет функциям Lambda взаимодействовать с ядром AWS Greengrass, на котором они запускаются, чтобы публиковать сообщения, взаимодействуют с сервисом теней устройств, или вызывают другую развернутую функцию Lambda. +* AWS Greengrass Core SDK поддерживает отправку только сообщений MQTT с QoS = 0. +* Размещенное ниже [изображение](http://docs.aws.amazon.com/greengrass/latest/developerguide/what-is-gg.html) показывает архитектуру сервисов AWS IoT Greengrass: + +![IoT Greengrass](http://docs.aws.amazon.com/greengrass/latest/developerguide/images/greengrass.png) + + +### Альтернативы IoT и привязки + +- AWS, Microsoft и Google имеют все представленные IoT-специфичные наборы облачных сервисов с конца 2015 года. AWS был первым, выведя свои сервисы IoT в [широкую доступность](https://aws.amazon.com/blogs/aws/aws-iot-now-generally-available/) в декабре 2015 года. Microsoft выпустили свой набор сервисов IoT в Azure в [феврале 2016 года](https://azure.microsoft.com/en-us/updates/generally-available-microsoft-azure-iot-hub/). Google аннонсировал, но не выпустил свои IoT сервисы [Android Things](https://developer.android.com/things/index.html) и [Weave](https://developers.google.com/weave/). +- Причинами возникновения привязки могут стать [протокола](http://www.postscapes.com/internet-of-things-protocols/) (для примера - MQTT, AMQP), формат сообщений(например JSON или Hex...) и безопасность (сертификаты). + +### Советы по IoT + +- **Начните с кнопок:** Одним из способов начать - является использование [**AWS IoT Button**](https://aws.amazon.com/iot/button/). AWS предлагает большое число примеров кода для использования с их IoT кнопкой, вы можете зайти в консоль, кликнуть по ссылке “connect AWS IoT button” и попадете в консоль AWS Lambda. Тут вы можете ввести серийный номер вашей кнопки для сопоставления с Lambda. (На момент написания данного текста, кнопки AWS IoT продавались только в США.) +- **Соединения и протокола:** Важно понимать особенности устройств, которые вы хотите подключить к сервису AWS IoT,включая то, как вы будете обеспечивать безопасность соединения с устройством, протокола устройства и так далее. Поставщики облачных услуг существенно различаются в поддержке общих протоколов IoT, таких как MQTT, AMQP, XMPP. AWS IoT поддерживает **защищенный MQTT**, **WebSockets** и **HTTPS**. +- Поддержка обработки сертификатов для **безопасности устройств** является ключевым отличием в этой области. В августе 2016, AWS добавило функцию [регистрации сертификатов точно-в-срок](https://aws.amazon.com/blogs/iot/just-in-time-registration-of-device-certificates-on-aws-iot/) для IoT устройств в своих сервисах. +- **Совместно с другими сервисами:** Обычной практикой является совместное использования с другими сервисами AWS, такими как AWS Lambda, Kinesis и DynamoDB, хотя это не означает, что это обязательно. Образцы эталонных архитектур приложений IoT приведены в этом [скринкасте](https://www.youtube.com/watch?v=0Izh6ySpwb8/). +- **Инструменты тестирования:** + * Чтобы было легко начать, AWS включило легковесный MQTT клиент в состав консоли AWS IoT. Тут вы можете создать и протестировать отправку и прием сообщений в различные топики MQTT и из них. + * При локальном тестировании, при использовании MQTT, может быть полезно загрузить и использовать инструмент с открытым кодом [Mosquitto broker](https://mosquitto.org/download/) для локального тестирования с устройствами и/или симуляторами устройств. + * Можно использовать [симулятор загрузки MQTT](https://github.com/awslabs/aws-iot-mqtt-load-generator) для нагрузочного тестирования вашего IoT решения. + +### Ошибки и ограничения, связанные с IoT + +- 🔸**Протокола IoT:** Очень важно убедиться в точной поддержке устройством типов протокола IoT для передачи сообщений. Для примера, один из наиболее используемых IoT протоколов - [MQTT](https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_mqtt_the_protocol_for_internet_of_things?lang=en). В MQTT существует [три возможных уровня QoS](https://dzone.com/articles/internet-things-mqtt-quality). AWS IoT поддерживает MQTT [QoS 0] (http://docs.aws.amazon.com/iot/latest/developerguide/protocols.html) (запустить и забыть или не более одного раза) и QoS 1 (хотя бы один раз или включает подтверждение), но *не* QoS 2 (запустить ровно один раз, требуется 4-этапное подтверждение). Это важно для понимания того, сколько кода вам придется написать для решения ваших конкретных задач. Вот [презентация о ньюансах соединения](http://www.slideshare.net/AmazonWebServices/overview-of-iot-infrastructure-and-connectivity-at-aws-getting-started-with-aws-iot). +- 🔸Экосистема связующая политики IoT и ассоциированные с ними устройства с ролями и пользователями AWS IAM - незрелая. Дополнительная разработка в целях обеспечения требований безопасности является обычной практикой. +- ❗Частой ошибкой является непонимание важности **безопасности** IoT **устройств**. Необходимо назначить уникальный сертификат (публичный ключ) на *каждое* устройство. Вы можете выпустить свои сертификаты и загрузить их в AWS или вы можете использовать выпущенные AWS сертификаты IoT устройств. Было бы великолепно прочесть и понять собственное руководство AWS по этой [теме](http://www.slideshare.net/AmazonWebServices/best-practices-of-iot-in-the-cloud). +- 🔸Может быть только один **AWS IoT Gateway** (точка подключения) на один AWS аккаунт. В реальных сценариях вам, вероятно, потребуется завести несколько учетных записей AWS, чтобы разделить трафик устройств для разработки, тестирования и эксплуатации. Что интересно, имейте ввиду, что [Azure IoT Gateway](https://azure.microsoft.com/en-us/documentation/articles/iot-hub-protocol-gateway/) поддерживает конфигурацию нескольких точек подключения, так что один аккаунт Azure может быть использован с разделением точек подключения для разработки, тестирования и эксплуатации. +- 🔸**Ограничения:** Ознакомьтесь с [ограничениями](http://docs.aws.amazon.com/iot/latest/developerguide/iot-limits.html), включая размер сообщения устройства, его тип, частоту, количество правил AWS IoT. + +### Примеры кода IoT + +- [Simple Beer Service](https://github.com/awslabs/simplebeerservice) - удивительно полезный пример кода, использующий AWS IoT, Lambda и т.д. +- [IoT-elf](https://github.com/awslabs/aws-iot-elf) - пример на чистом Python, использующий AWS IoT SDK. +- [IoT Button projects](https://www.hackster.io/AmazonWebServices/products/aws-iot-button) на Hackster включает в себя множество различных примеров кода для различных проектов. +- [5 примеров кода IoT](https://github.com/awslabs/aws-iot-examples/): симулятор устройства, образец MQTT, своевременная регистрация, симулятор грузовика, симулятор данных прогноза. +- [Простой пример голоса AWS Alexa](https://developer.amazon.com/public/community/post/TxDJWS16KUPVKO/New-Alexa-Skills-Kit-Template:-Build-a-Trivia-Skill-in-under-an-Hour) является быстрым стартом в использовании голосовых возможностей Alexa и Lambda. +- Некоторые примеры на Raspberry Pi включают в себя [Beacon project](https://github.com/araobp/beacon/blob/master/README.md), [Danbo](https://libraries.io/github/awslabs/aws-iot-demo-for-danbo), и [GoPiGo](https://github.com/awslabs/aws-iotbot). + +SES +--- + +### Основы SES + +- 📒 [Домашняя страница](https://aws.amazon.com/ses/) ∙ [Документация](https://aws.amazon.com/documentation/ses/) ∙ [ЧаВо](https://aws.amazon.com/ses/faqs/) ∙ [Расценки](https://aws.amazon.com/ses/pricing/) +- **SES** (или простой сервис электронной почты (Simple Email Service)) - это сервис, который открывает выходные точки SMTP для прямой интеграции с вашим приложением. + +### Советы по SES + +- 🔹**Обработка отказов:** Убедитесь, что вы решаете эту проблему по мере возникновения. Возможность отправки писем может быть отключена, если SES увидит [большое количество отказов](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/best-practices-bounces-complaints.html). +- 🔹**Учетные данные:** Многие разработчики путаются между [учетными данными SES](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/using-credentials.html) и ключами AWS API. Убедитесь, что ввели [учетные данные SMTP](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-credentials.html), когда используете API SMTP. + +### Ошибки и ограничения, связанные с SES + +- 🔸**Доступ в интернет:** Выходные точки SMTP SES находятся в сети Интернет и не будут доступны из места, где интернет недоступен (например, в частной подсети без маршрута на шлюз NAT в таблице маршрутизации). В этом случае, установите инстанс и разверните на нем SMTP релей в подсети с доступом в интернет, а также настройте ваше приложения для отправки почтовых сообщений через этот инстанс, а не через SES. На релее должно быть настроено [правило перенаправления, для отправки всех почтовых сообщений в SES](http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-smtp-existing-server.html)). ❗Если вы используете прокси сервер вместо NAT, убедитесь, что прокси поддерживает 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 + +- 📒 [Домашняя страница](https://aws.amazon.com/opsworks/) ∙ [Документация](https://aws.amazon.com/documentation/opsworks/) ∙ [ЧаВо](https://aws.amazon.com/opsworks/faqs/) ∙ Расценки: [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 - это сервис управления конфигурацией, который использует [Chef](https://www.chef.io/chef/) или [Puppet](https://www.puppet.com). Он разделен на три различных сервиса: + - [OpsWorks Stacks](https://aws.amazon.com/opsworks/stacks/): Служба позволяет настраивать и запускать стеки, соответствующие потребностям вашего приложения, и позволяет автоматизировать развертывание приложений. Запуск Chef может быть выполнен вручную командой Execute Cookbooks, в ином случае, кукбуки выполняются только как часть событий жизненного цикла.. + - Стеки OpsWorks отличаются от стандартных служб управления конфигурациями тем, что они также позволяют выполнять некоторую автоматизацию инфраструктуры и приложений (например, создание инстансов Amazon EC2 и развертывание приложений через кукбуки Chef). + - [OpsWorks for Chef Automate](https://aws.amazon.com/opsworks/chefautomate/): Эта служба запускает выделенный сервер Chef Automate в вашем аккаунте, который можно использовать для подключения нод, загрузки кукбуков и настройки систем. Автоматический патчинг, резервное копирование, обновления ОС и минорные обновления версий Chef предоставляются как часть службы. Существует API AWS для подключения/отключения нод. Запуск Chef может быть запланирован на нодах путем использования [chef-client cookbook](https://supermarket.chef.io/cookbooks/chef-client). + - [OpsWorks for Puppet Enterprise](https://aws.amazon.com/opsworks/puppetenterprise/): Эта служба запускает выделенный сервер Puppet Master в вашем аккаунте, который можно использовать для подключения нод, загрузки модулей и настройки систем. AАвтоматический патчинг, резервное копирование, обновления ОС и минорные обновления версий Puppet предоставляются как часть службы. Существует API AWS для подключения/отключения нод. По умолчанию, агент Puppet запускается на подключенных нода автоматически каждые 30 минут. +- OpsWorks для Chef Automate и OpsWorks для Puppet Enterprise предназначен исключительно для управления конфигурацией и не предоставляет инфраструктуру кроме Chef Server/Puppet Master, которые создаются в нашей учетной записи. +- Все три сервиса OpsWorks поддерживают управление как Amazon EC2 так и локальной инфраструктуры, в любом случае отдельные моменты реализации слегка различаются. + - OpsWorks Stacks позволяет вам регистрировать инстансы и устанавливать агент OpsWorks Agent для присоединения к стэку. + - OpsWorks для Chef Automate и OpsWorks для Puppet Enterprise позволяет вам подключать новую или существующую инфраструктуру используя либо API opsworks-cm:AssociateNode либо поддерживаемый поставщиком метод для подключения нод к Chef Server или Puppet Enterprise. +- Хотя OpsWorks позволяет вам работать с обычными рецептами Chef и модулями Puppet во время создания стэка, создание собственных рецептов потребует знаний синтакса Chef или Puppet. Код Chef/Puppet не поддерживается поддержкой AWS. +- По состоянию на декабрь 2016 года, OpsWorks Stacks поддерживает Chef версий [12, 11.10.4, 11.4.4 and 0.9.15.5](http://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook.html). +- По состоянию на декабрь 2016 года, OpsWorks для Chef Automate использует [Chef Server версии 12.11.1](http://docs.aws.amazon.com/opsworks/latest/userguide/welcome_opscm.html) Это текущая стабильная Chef. +- [Berkshelf](http://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-chef11-10.html#workingcookbook-chef11-10-berkshelf) может быть использован со стэками Chef версии 11.10 или более поздней для управления кукбуками и их соответствующими зависимостями. В любом случае, в стэках Chef 12.x, Berkshelf должен быть установлен администратором стэка. +- Запуск вашей собственной среды Chef может быть определенной альтернативой для рассмотрения - некоторые соображения перечислены [в этой статье Bitlancer.](http://www.bitlancer.com/blog/2015/10/05/opsworks-vs-chef.html) + +### Альтернативы OpsWorks и привязки + +- Основные конкуренты в управлении конфигурациями включают: + - [Chef](https://chef.io) + - [Puppet](https://puppet.com) + - [Ansible](https://www.ansible.com). + +### Советы по OpsWorks + +- OpsWorks Stacks и OpsWorks для Chef Automate используют кукбуки Chef для конфигурации. Chef предоставляет бесплатные тренинги для обучения синтаксису, лучшим практикам и т.д. на [https://learn.chef.io](https://learn.chef.io). +- OpsWorks для Puppet Enterprise использует манифесты Puppet для конфигурации. Puppet предоставляет очень полезную виртуальную машину, которую можно скачать на [https://learn.puppet.com/](https://learn.puppet.com/). + +### Ошибки и ограничения, связанные с OpsWorks + +- OpsWorks Stacks не доступен в следующих регионах: + - Montreal + - GovCloud + - Beijing +- OpsWorks для Chef Automate и OpsWorks для Puppet Enterprise недоступны в следующих регионах: + - 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 + +- 📒 [Домашняя страница](https://aws.amazon.com/sqs/) ∙ [Документация](https://aws.amazon.com/documentation/sqs/) ∙ [ЧаВо](https://aws.amazon.com/sqs/faqs/) ∙ [Расценки](https://aws.amazon.com/sqs/pricing/) +- SQS - это высокомасштабируемая, полностью управляемая служба очереди сообщений от AWS. +- SQS поддерживает модель извлечения, когда источники передают сообщения в *очередь*, а потребители извлекают сообщения из очереди. +- SQS предоставляет тайм-аут видимости сообщения, в течение которого обрабатываемое сообщение не будет доставлено другим потребителям. Если потребитель не удаляет сообщение после обработки, оно становится доступным для других потребителей по истечении времени ожидания видимости сообщения. Этот параметр называется VisibilityTimeout. +- Каждое сообщение может иметь до 10 пользовательских полей или атрибутов. +- SQS позволяет источникам устанавливать задержку до 15 минут, прежде чем сообщения будут доставлены потребителям. Этот параметр называется DelaySeconds. +- Существует два типа очередей, которые поддерживает SQS - + - Стандартные очереди(Standard Queues) + - Гарантирует **как минимум одну** доставку сообщеинй. + - Не сохраняет порядок очереди доставки сообщений. + - Очередь типа первый пришел, первый ушел(FIFO Queues) + - Гарантирует **только одну** доставку сообщения + - Гарантирует сохранность порядка доставки сообщений +- SQS поддерживает гранулярный доступ к вызовам различных API и очередям через политики IAM. +- Сообщения, которые не обрабатываются, могут быть помещены в очередь недоставленных сообщений. + +### Альтернативы SQS и привязки + +- Альтернативы SQS включают [Kafka](https://kafka.apache.org/), [RabbitMQ](https://www.rabbitmq.com/), [ActiveMQ](http://activemq.apache.org/) и другие. +- В Google Cloud Platform есть Pub/Sub, а в Azure есть Azure Queue Service. +- [SQS vs SNS](#альтернативы-sns-и-привязки) + +### Советы по SQS + +- SNS может быть использован совместно с SQS для построения механизма “fan out”, путем подписки очереди SQS на тему SNS. +- SQS поддерживает шифрование посредством AWS KMS. +- Тревоги Cloudwatch могут быть созданы путем использования [различных метрик SQS](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/sqs-metricscollected.html) для запуска автоматического масштабирования и/или отправки оповещений. + +### Ошибки и ограничения, связанные с SQS + +- 🔸 SQS не имеет конечной точки в VPC (в отличии от S3 и DynamoDB), таким образом доступ к SQS происходит через общедоступные выходные точки API SQS. +- 🔸 Очереди FIFO(Первый пришел, первый ушел) ограничены частотой вызовов в 300 вызовов API в секунду. +- 🔸 Очереди FIFO не могут быть подписаны на тему SNS. +- 🔸 Стандартные очереди могут доставлять дубликаты сообщений независимо от окна видимости. Если ваш выбор - единовременная доставка, используйте очереди FIFO или создайте дополнительную прослойку для устранения дубликатов. +- 🔸 Вы можете отправлять/получать сообщения пакетами, однако в пакете может быть не более 10 сообщений. + + +SNS +--------------------- + +### Основы SNS + +- 📒 [Домашняя страница](https://aws.amazon.com/sns/) ∙ [Документация](https://aws.amazon.com/documentation/sns/) ∙ [ЧаВо](https://aws.amazon.com/sns/faqs/) ∙ [Расценки](https://aws.amazon.com/sns/pricing/) +- **SNS** (Простой сервис уведомлений(Simple Notification Service)) - это высоко-масштабируемый полностью управляемый сервис сообщений на базе публикаций/подписок, который также может быть использован для мобильных уведомлений. +- SNS может передавать сообщения подписчикам посредством транспортных протоколов [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), и [HTTP/S](http://docs.aws.amazon.com/sns/latest/dg/SendMessageToHttp.html). +- Источники сообщений публикуют их в Темы SNS(SNS Topics), в которых может быть много подписчиков. +- Каждая подписка имеет соответствующий [протокол](http://docs.aws.amazon.com/sns/latest/api/API_Subscribe.html), который используется для оповещения подписчика. +- Копия сообщения направляется каждому подписчику посредством соотвествующего протокола. +- SNS также может [вызывать функции lambda](http://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html). + +### Альтернативы SNS и привязки + +- Популярными альтернативами SNS являются [Kafka](https://kafka.apache.org/), [Notification Hubs](https://azure.microsoft.com/en-us/services/notification-hubs/) в Azure, и [Pub/Sub](https://cloud.google.com/pubsub/docs/overview) в Google Cloud. +- **SNS и SQS:** + - SNS и SQS оба являются высокомасштабируемыми, полностью управляемыми сервисами сообщений предоставляемыми AWS. + - SQS поддерживает модель *Вытаскивания данных(pull)*, в то время, как SNS поддерживает модель *Отправки данных(push)*. Потребители должны запрашивать данные из очереди SQS, в то время, как им приходят сообщения с Темы SNS. + - Сообщение SQS предназначено для обработки только одним подписчиком, в то время, как Темы SNS имеют множество подписчиков. + - После обработки, сообщение SQS удаляется из очереди, для того, чтобы избежать повторной обработки. + - Сообщение SNS *направляется* всем подписчикам темы одновременно и это делает невозможным удаление сообщения из Темы. + - SNS поддерживает массу транспортных протоколов доставки сообщений подписчикам, в то время, как подписчики SQS могут запрашивать сообщения из очереди только через HTTPS. + +### Советы по SNS + +- Архитектура [Fan-out](http://docs.aws.amazon.com/sns/latest/dg/SNS_Scenarios.html) может быть достигнута путем назначения нескольких подписчиков на тему. Это особенно полезно, когда события должны распространяться на несколько изолированных систем. +- Темы SNS могут быть использованы для передачи [вебхуков](https://en.wikipedia.org/wiki/Webhook) с [поддержкой откладывания](http://docs.aws.amazon.com/sns/latest/dg/DeliveryPolicies.html) подписчикам через HTTP/S. +- [Очереди SQS](http://docs.aws.amazon.com/sns/latest/dg/SendMessageToSQS.html) могут быть подписаны на темы SNS. +- SNS используется для управления уведомлениями для других сервисов AWS, таких как уведомления [групп автоматического масштабирования(Autoscaling Groups)](http://docs.aws.amazon.com/autoscaling/latest/userguide/ASGettingNotifications.html)' , [Тревоги CloudWatch](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), и т.д. +- SNS часто используется, как “клей” между несопоставимыми системами, такими, как GitHub и сервисы AWS. + +### Ошибки и ограничения, связанные с SNS + +- 🔸 Подписчики SNS подключающиеся по HTTP/S должны иметь доступ к общедоступным выходным точкам, так как SNS не поддерживает частные выходные точки (типа тех, которые находятся в частных подсетях внутри VPC). +- 📜 В сценарии fan-out [SQS с включенным шифрованием на стороне сервера(SSE-enabled SQS)](http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.html) подписанные на тему SNS [не получат](https://lobster1234.github.io/2017/10/14/fan-out-with-sns-and-sqs-gotcha/) сообщений, посланных в тему. + +Высокая доступность +----------------- + +Этот раздел охватывает советы и информацию по достижению [высокой доступности](https://en.wikipedia.org/wiki/High_availability). + + + +### Советы по высокой доступности + +- AWS предлагает два уровня отказоустойчивости, [регионы и зоны доступности (AZs)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones). +- При правильном использовании регионы и зоны обеспечивают высокую доступность. Возможно, вы захотите использовать других провайдеров для еще более значительного снижения бизнес-рисков (то есть не привязывать свою компанию к одному поставщику), но надежность AWS в различных регионах крайне высока. +- **Несколько регионов:** Использование нескольких регионов является сложным, поскольку по сути это похоже на управление совершенно отдельными инфраструктурами. Это необходимо для критически важных для бизнеса услуг с высоким уровнем резервирования. Однако для многих приложений (например, для вашего стартапа ориентирующегося на средний класс потребителей) развертывание обширной избыточности по регионам может оказаться излишним. +- Этот блог [High Scalability](http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html) является хорошим руководством, призванным помочь вам понять, нужно ли вам растягивать ваше приложение на несколько регионов. +- 🔹**Несколько зон доступности(AZ):** Разумное использование AZ - первый инструмент в обеспечении высокой доступности! + - Типичной архитектурой высокой доступности для одного региона является развертывание в двух или более зонах доступности с балансировкой нагрузки, как на [этом изображении от AWS](http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_ftha_04.pdf). + - Большая часть простоев в сервисах AWS затрагивает только одну зону. Однако в истории были редкие перебои, затрагивающие несколько зон одновременно (например, [великий отказ EBS 2011 года](http://aws.amazon.com/message/65648/)), но, как правило, перебои в работе большинства клиентов связаны с использованием только одной зоны доступности в определенных вариантах развертывания инфраструктуры. + - Следовательно, проектируйте свою архитектуру так, чтобы минимизировать влияние отказов в зонах доступности, особенно отказов в одной зоне. + - Разворачивайте ключевую инфраструктуру, как минимум, в двух или трех зонах доступности . Репликация одного ресурса в более чем трех зонах часто не имеет смысла, если у вас есть другие механизмы резервного копирования, такие как снапшоты в S3. + - Использование второй или третьей зоны доступности должно значительно улучшить доступность, но дополнительная надежность из-за использования четырех или более зон доступности, может не оправдать затраты или сложность инфраструктуры (кроме случаев, если у вас нет других причин, таких как емкость или рыночные цены на спот инстансы). + - 💸Помните о **затратах на передачу данных между зонами доступности**. Это может стать неприятным сюрпризом в архитектурах с большими объемами передачи траффика между границами зон доступности. + - Распределяйте инстансы равномерно по всем доступным зонам доступности, так что в случае отказа зоны доступности вы потеряете только минимальную часть вашей общей емкости. + - Если ваша архитектура содержит точки отказа, поместите их все в одну зону доступности. Это может выглядеть нелогичным, но это уменьшает вероятность падения инфраструктуры изза выхода из строя одной зоны доступности. +- **EBS и хранилище на инстансе:** В течении долгих лет, у EBS был худший показатель доступности, нежели у хранилища на инстансе. Для систем, где индивидуальные инстансы могли быть уничтожены и перезапущены легко и быстро, хранилища на инстансах с достаточной отказоустойчивостью, показывали более высокий уровень доступности. Однако, с тех пор, EBS был значительно улучшен, и современные типы инстансов (с 2015 года) идут только с поддержкой EBS, так что этот подход, хотя и был в свое вермя полезен, на сегодня сильно устарел. +- Убедитесь, что вы правильно [понимаете и используете CLB/ALB](#балансировщики-нагрузкиload-balancers). Многие отказы были вызваны из-за не использования балансировщиков нагрузки или неправильного понимания их работы и, следовательно, неправильной настройке. + +### Ошибки и ограничения, связанные с высокой доступностью + +- 🔸**Наименование зон доступности** различается от одного пользовательского аккаунта к другому. Ваша зона “us-west-1a” не та же самая, как зона “us-west-1a” у другого клиента — буквы назначаются физической зоне доступности произвольно для каждого аккаунта. Это может привести к ошибкам, если вы используете различные аккаунты AWS. Имейте ввиду, что ID зоны доступности остаются одинаковыми во всех аккаунтах и это может быть использовано для надежного ориентирования при работе между разными аккаунтами AWS. +- 🔸💸**Траффик между зонами доступности** не бесплатен. В больших масштабах, это может добавить серьезный объем затрат. Если возможно, оптимизируйте передачу данных так, чтобы трафик циркулировал в пределах одной зоны доступности настолько, насколько это возможно. + +Платежи и управление расходами +--------------------------- + +### Прозрачность расходов и выставления счетов + +- AWS предлагает [**бесплатный уровень**](https://aws.amazon.com/free/) услуг, который позволяет очень ограниченное использование ресурсов без оплаты. Например, микро инстанс и небольшой объем хранилища бесплатно. Многие сервисы доступны на бесплатном уровне только в течении 12 месяцев с момента регистрации аккаунта, однако другие сервисы предлагают бесплатное использование на неопределенный срок. (Если у вас есть старый аккаунт, но вы начинаете новый проект, зарегистрируйте новый аккаунт, чтобы получить право на бесплатный уровень.) [AWS Activate](https://aws.amazon.com/activate/) расширяет этот уровень до десятков тысяч долларов бесплатных кредитов для стартапов в [определенных фондах или акселераторах](https://aws.amazon.com/activate/portfolio-detail/). +- Вы можете установить [**уведомления о расходах**](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free-tier-alarms.html), чтобы быть оповещенным о неожиданных затратах, таких как затраты, превышающие бесплатный уровень. Вы можете настроить их [гранулярно](https://wblinks.com/notes/aws-tips-i-wish-id-known-before-i-started/#billing). +- AWS предлагает [Обозреватель затрат(Cost Explorer)](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) - инструмент для обеспечения прозрачности затрат. +- К сожалению, консоли AWS и инструментов для выставления счетов не всегда достаточно, чтобы обеспечить хороший обзор затрат. Для больших учетных записей консоль биллинга AWS может быть тормозить или падать из-за таймаута. +- **Инструменты:** + - 🔹Включите [отчеты о затратах(billing reports)](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/detailed-billing-reports.html) и установите инструмент с открытым исходным кодом, для помощи в управлении и контроле использование ресурсов AWS. [**Teevity Ice**](https://github.com/Teevity/ice) (созданный в Netflix) - возможно то, что вам следует попробовать в первую очередь. Можно попробовать [docker-ice](https://github.com/jonbrouse/docker-ice) - докеризированную версию, которая облегчает установку. + - 🔸Одна из проблем с Ice заключается в том, что он не покрывает амортизированную стоимость зарезервированных инстансов. + - Другие инструменты включают [Security Monkey](https://github.com/Netflix/security_monkey) и [Cloud Custodian](https://github.com/capitalone/cloud-custodian). + - Используйте [Простой ежемесячный калькулятор AWS(AWS Simple Monthly Calculator)](https://calculator.s3.amazonaws.com/index.html), чтобы получить оценку стоимости использования услуг AWS на основе определенной информации, которую вы предоставляете. Ежемесячные платежи будут зависеть от фактического использования вами сервисов AWS и могут отличаться от оценок, предоставленных калькулятором. +- **Сторонние сервисы:** Некоторые компании предлагают услуги, разработанные, чтобы помочь вам получить представление о расходах или снизить расходы на оплату услуг AWS, например [Cloudability](https://www.cloudability.com/), [CloudHealth Technologies](https://www.cloudhealthtech.com/), и [ParkMyCloud](http://www.parkmycloud.com/). Некоторые из них взимают оплату в размере процента вашего счета, что может быть дорого. Ознакомьтесь с [рыночным ландшафтом](#инструменты-и-услуги-представленные-на-рынке). +- Доверенный советник AWS ([AWS Trusted Advisor])(https://aws.amazon.com/premiumsupport/trustedadvisor/) - является еще одним сервисом, который может помочь разобраться с проблемой затрат. +- Не стесняйтесь спрашивать у своего менеджера аккаунта рекомендации по уменьшению ваших затрат. Это их работа, чтобы вы были довольны использованием AWS. +- **Тэгирование для прозрачности затрат:** По мере роста инфраструктуры ключевой частью управления расходами является понимание того, где они лежат. Крайне рекомендуется [тэгировать ресурсы](https://aws.amazon.com/blogs/aws/resource-groups-and-tagging/), и по мере роста сложности инфраструктуры, эффективно группировать их. Если вы [правильно настроите распределение счетов](http://aws.amazon.com/blogs/aws/aws-cost-allocation/), вы сможете получить прозрачность затрат исходя из огранизации, продукта, отдельного инженера или любым другим удобным вам путем. +- Если вам необходимо произвести свой анализ сырых платежных данных или вам надо передать их в сторонний сервис анализа затрат, [включите](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/detailed-billing-reports.html#turnonreports) функцию [детализированного платежного отчета(detailed billing report)](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/detailed-billing-reports.html#detailed-billing-report). +- Несколько учетных записей Amazon могут быть связаны в платежных целях используя функцию [Консолидированное выставление счетов(Consolidated Billing)](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html). Крупные предприятия могут иметь сложную бухгалтерскую структуру, в зависимости от владения и процессов одобрения. +- Несколько учетных записей Amazon могут управляться централизовано посредством [AWS Organizations](https://aws.amazon.com/organizations/). + +### Затраты на передачу данных в AWS + +- Для развертываний, в которых используется значительный сетевой трафик, значительная часть затрат AWS приходится на передачу данных. Кроме того, стоимость передачи данных в пределах зоны доступности, внутри регионов, между регионами, а также из AWS в Интернет и обратно значительно варьируется в зависимости от выбора варианта развертывания. +- Некоторые из наиболее распространенных ошибкок: + - 🔸*Траффик между зонами доступности:* Имейте ввиду, что траффик EC2 между зонами доступности, по факту такой же, как и между регионами. Например, развертывание кластера Cassandra в нескольких зонах доступности может быть полезно для обеспечения [высокой доступности](#высокая-доступность), но может нанести ущерб, за счет затрат на передачу данных. + - 🔸*Использование публичных IP-адресов без необходимости:* Если вы используете Elastic IP или общедоступный IP-адрес инстанса EC2, вы будете нести дополнительные расходы, даже если к нему обращаются локально в пределах AZ. + - 🔸*Обработка данных управляемым шлюзом NAT:* Управляемы шлюзы NAT используются чтобы пропускать траффик из приватных подсетей по цене 4.5¢ в виде платежа за обработку данных поверх стоимости передачи данных. После определенного момента, запуск NAT на своих инстансах становится более экономически выгодным. + - 🔸*Некоторые сервисы не тарифицируют передачу данных между зонами доступности:* Многие сервисы AWS, которые вы по существу не рассматриваете, предлагают скрытую ценность по причине бесплатной передачи данных между зонами доступности. EFS, RDS, MSK и другие - выступают примером этого. +- Это изображение дает обзор: + +![Затраты на передачу данных в AWS](../figures/aws-data-transfer-costs.png) + +### Управление затратами на EC2 + +- В EC2 существует компромисс между инженерными усилиями (больше анализа, больше инструментов, более сложные архитектуры) и расходами на AWS. Если ваши затраты на EC2 малы, эти усилия обычно не обходятся дороже того инженерного времени, которое потребуется для того, чтобы сделать так, чтобы все работало. Однако, если расходы начнут превышать заработную плату инженера, могут потребоваться серьезные инвестиции. +- Более крупные инстансы не обязательно имеют более высокую цену на спотовом рынке, поэтому вам следует рассмотреть доступные варианты и определить, какие инстансы будут наиболее экономически эффективными для ваших работ. Изучите [Советника по ставкам(Bid Advisor)](https://aws.amazon.com/ec2/spot/bid-advisor/). +- 🔹**Спотовые инстансы:** + - [Спотовые инстансы EC2](https://aws.amazon.com/ec2/spot/) - это способ получить ресурсы EC2 со значительной скидкой - часто на порядок дешевле, чем стандартные цены на ресурсы по требованию - если вас устраивает возможность того, что они могут быть отключены с малым временем после предупреждения или вообще без предупреждения. + - Используйте спотовые инстансы для получения весьма серьезных скидок в любых случаях, когда вы используете ресурсы, которые могут быть перезагружены и не нуждаются в поддержке постоянного состояния в течении долгосрочного периода. + - Огромная экономия, которую вы можете получить с помощью спотовых инстансов, достигается за счет значительного увеличения сложности при подготовке и определении необходимости доступности вычислительных мощностей. + - Amazon поддерживает спотовые цены на колеблющемся уровне, ориентированном на рынок, основываясь на своих запасах неиспользованных мощностей. Цены обычно низкие, но возможны [весьма высокие всплески цен](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html#spot-bid-limit). Посмотрите [историю цен](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances-history.html), чтобы иметь представление об этом. + - Вы устанавливаете высокую цену предложения, чтобы указать, насколько много вы готовы платить, но платите только по действующей ставке, а не по ставке, которую вы указали. Если рыночная ставка превышает вашу ставку, ваш инстанс будет отключен. + - Цены устанавливаются как по инстансам, так и по зонам доступности. Цены на один и тот же тип инстанса могут широко различаться в различных зонах доступности в одно и то же время. Разные типы инстансов могут иметь совершенно разные цены, даже для одновременно запущенных типов инстансов в одной и той же зоне. + - Сравните цены между типами инстансов в целях заключения наилучшей сделки. + - Используйте спотовые инстансы всегда, когда это возможно. Установка высокой цены предложения гарантирует, что ваши машины будут работать в подавляющем большинстве случаев за небольшую долю от обычной цены. + - Вы можете получить уведомление об отключении за две минуты по причине превышения цены предложения путем опроса [метаданных вашего спот инстанса](https://aws.amazon.com/blogs/aws/new-ec2-spot-instance-termination-notices/), а также путем просмотра [событий отключения в CloudWatch](https://aws.amazon.com/about-aws/whats-new/2018/01/amazon-ec2-spot-two-minute-warning-is-now-available-via-amazon-cloudwatch-events/). + - Убедитесь, что то, что вы используете, хорошо адаптируется к спотовым инстансам, прежде чем вкладывать значительные средства в инструменты для управления конкретной конфигурацией. +- **Спотовый флот(Spot fleet):** + - Вы можете добиться еще больших сокращений затрат в то же время, как и улучшения стабильности парка инстансов, по отношению к обычному использованию спортовых инстансов посредством использования [спотового флота(парка инстансов)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html) чтобы делать ставки на инстансы среди различных типов инстансов, зон доступности, а также (путем запроса нескольких спотовых флотов) регионов. + - Использование спотовых флотов преследует цель поддержки заданной (и взвешенной по типу инстанса) полной вычислительной емкости в кластере серверов. Если спотовая цена одной комбинации типа инстанса и зоны доступности поднимается выше взвешенной ставки, он будет отключать запущенные инстансы и поднимать новые инстансы другого типа и местоположения, чтобы поддерживать целевую емкость без превышения целевой стоимости кластера. +- **Лучшие практики использования спотовых инстансов:** + - **Профилирование приложений:** + - Профилируйте ваше приложение, чтобы выяснить его характеристики во время выполнения. Это поможет понять минимальные требования к ресурсам процессора, памяти и диска. Наличие этой информации очень важно, прежде чем пытаться оптимизировать расходы на спотовые ресурсы. + - Как только вы определите минимальные требования приложения, вы сможете делать ставки на различные варианты типов инстансов, вместо того, чтобы ротировать инстансы одного типа (это дает большие шансы получения спотового инстанса для запуска вашего приложения). Например, если вы знаете, что четырех ядер достаточно для запуска вашей задачи, вы можете выбрать тип инстанса, у которого количество ядер равно или более четырех, а также имеет минимальную цену на спот рынке, исходя из исторических данных. Это поможет вам выставить ставку на инстансы с самой большой скидкой (менее запрашиваемые на текущий момент веремени). + - **Мониторинг и прогнозирование цены спот инстансов:** + - Цены на спот инстансы колеблются в зависимости от типа инстанса, времени суток, региона и зоны доступности. Инструменты, такие как AWS API и AWS CLI позволяют описывать метаданные спотовой цены с указанием времени, типа инстанса, а также региона/зоны доступности. + - Основываясь на истории цен спот инстансов, вы могли бы потенциально создать множество алгоритмов, которые помогут вам выбрать тип экземпляра исходя из стратегии **оптимизации расходов**, **максимального повышения доступности** или **обеспечения предсказуемой производительности**. + - Вы также можете отследить количество случаев, когда инстанс определенного типа был забран (из-за превышения ставки), и построить график на доске, чтобы улучшить свой алгоритм в зависимости от времени суток. + - **Утилизация ресурсов спотовых машин:** + - Для выполнения нагрузок с всплесками утилизации (таких как spark или map reduce), которые основаны на расписании и где отказ не является критическим - спотовые инстансы являются наилучшим кандидатом. + - Время, необходимое для удовлетворения ставки на спот рынке и получения инстанса, может варьироваться от 2 до 10 минут в зависимости от типа инстанса и наличия машин в этой зоне доступности. + - Если вы используете инфраструктуру с сотнями задач, с вероятностью резких нагрузок, рекомендуется начать объединять инстансы, чтобы оптимизировать затраты, производительность и, что наиболее важно, время на приобретение инстансов. + - Объединение в пул подразумевает создание и обслуживание спот инстансов таким образом, чтобы после выполнения задачи они не отключались. Это способствует повторному использованию спот инстансов для исполнения различных задач. Это, конечно, связано с накладными расходами на управление жизненным циклом. + - Пул имеет свой собственный набор показателей, которые можно отслеживать для оптимизации использования ресурсов, эффективности и стоимости. + - Типичные реализации пула позволяют оптимизировать затраты на 45-60% и сократить время создания спот инстанса на 40%. + - Отличный пример реализации пула, описанный Netflix ([часть 1](http://techblog.netflix.com/2015/09/creating-your-own-ec2-spot-market.html), [часть 2](http://techblog.netflix.com/2015/11/creating-your-own-ec2-spot-market-part-2.html)\) +- **Возможные ошибки в управление спотовыми ресурсами** + - 🔸**Время жизни:** Нет никаких [гарантий](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) времени жизни спотового инстанса. Это основывается чисто на основе ставок. Если кто-то перебивает вашу ставку, то он забирает инстанс. Спотовые инстансы не подходят для задач, критичных ко времени работы или имеющих жесткий SLA. Инстансы будут отключены из-за повышения спроса в текущий момент времени. AWS предоставляет [двухминутное предупреждение](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html#spot-instance-termination-notices) перед тем, как Amazon отключит ваши спотовые EC2 инстансы. + - 🔹**Возврат данных от API:** - API Spot price возвращает данные о ценах спотовых инстансов с различной гранулярностью в зависимости от временного диапазона, указанного в запросе при вызове API. Таким образом, если были запрошены данные за последние 10 минут, ответ будет более гранулированным. А если же будет произведен запрос данных за последние два дня, выборка данных будет более грубой. Не расчитывайте на то, что вы получите все записи данных. **Будут** пропущенные интервалы. + - ❗**Управление жизненным циклом:** Не пытайтесь применять какие нибудь модные инструменты управления спотовыми инстансами до тех пор, пока это не станет абсолютно необходимым. Если вы используете всего несколько машин и цена вас полностью устраивает, а уровень отказов мал, не пытайтесь оптимизровать. Те страдания, которые вы испытаете в процессе создания/поддержки этого решения, не стоит нескольких сотен долларов экономии. +- **Зарезервированные инстансы:** позволяют вам получить значительные скидки на цену вычислительного часа EC2 в обмен на обязательство оплачивать вычислительные часы инстансов определенного типа в конкретной зоне доступности и регионе AWS, и в течение заранее установленного периода времени (1 или 3 года). Дополнительные скидки могут быть получены путем “частичной” или “полной” предоплаты. + - Рассмотрите возможность использования зарезервированных инстансов, когда вы можете спрогнозировать свои потребности в вычислениях в долгосрочном периоде и нуждаетесь в более надежной гарантии доступности и непрерывности вычислений, чем может обеспечить (как правило, более дешевый) спотовый рынок. Однако имейте в виду, что если ваша архитектура изменится, ваши вычислительные потребности также могут измениться, поэтому, хотя долгосрочные контракты могут показаться привлекательными, они могут оказаться громоздкими и неудобными. + - Существует два типа зарезервированных инстансов - [Стандартный и изменяемый(Standard and Convertible)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-types.html). Если вы купили лишние стандартные зарезервированные инстансы, вы можете предложить неиспользованные зарезервированные инстансы “на продажу” путем размещения на [рынке зарезервированных инстансов(Reserved Instance Marketplace)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-market-selling-guide.html), это позволяет вам частично компенсировать стоимость неиспользованных вычислительных часов инстансов EC2 путем продажи другим клиентам AWS. + - Зарезервированные инстансы не привязаны к конкретным инстансам EC2 - они применяются на уровне выставления счетов к соответсвующим вычислительным часам, поскольку они потребляются всеми соответствующими инстансами в учетной записи. + - 📜Были разрозненные сообщения о том, что покупки изменяемых зарезервированных инстансов должны осуществляться в блоке, а именно: если вы покупаете изменяемых зарезервированных инстансов за одну покупку, вы не сможете конвертировать только два из них. Обратитесь к менеджеру своего аккаунта за разъяснениями, если это может повлиять на вас. +- Если у вас несколько учетных записей AWS и вы настроили их на списание затрат с одной учетной записи, используя функцию “Консолидированного выставления счетов(Consolidated Billing)”, вы можете ожидать, что *неиспользованные* вычислительные часы зарезервированных инстансов с одной учетной записи будут списаны на соответствующие (по региону, зоне доступности, типу инстанса) вычислительные часы с другого аккаунта. +- Если у вас есть несколько учетных записей AWS, связанных функцией консолидированного выставления счетов, и вы планируете использовать зарезервированные инстансы и, в то же время, хотите использовать неиспользованную зарезервированную емкость вычислительных часов с других учетных записей, вам необходимо создать ваши инстансы в зоне доступности, с тем же *именем*, что и в других учетных записях. Помните, что когда вы это сделаете, ваши инстансы могут оказаться не в тех же *физических* дата центрах, что и в других учетных записях - Amazon перемешивает названия зон доступности в разных учетных записях, в целях равномерного распределения ресурсов. +- Используйте динамическое [автоматическое масштабирование](#auto-scaling-автоматическое-масштабирование), где возможно, в целях обеспечения лучшего соответствия размеров (и цены) вашего кластера к конкретным требованиям к ресурсам вашего сервиса. +- Если вы используете инстансы на RHEL и так случилось, что у вас есть действующая подписка Red Hat, тогда вы можете участвовать в программе [Red Hat's Cloud Access](https://www.redhat.com/en/technologies/cloud-computing/cloud-access), чтобы перенести часть ваших локальных подписок в AWS и, таким образом сократить расходы на оплату подписок RHEL в AWS. Также вы можете использовать свои собсвенные AMI на основе RHEL или представленные Red Hat [золотые образы(Gold Images)](https://access.redhat.com/articles/2962171), которые будут добавлены в ваши частные AMI сразу после регистрации в 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/).