diff --git a/translations/ru.md b/translations/ru.md
index 6a6d614..104a4de 100644
--- a/translations/ru.md
+++ b/translations/ru.md
@@ -2412,15 +2412,15 @@ SNS
 	-	🔸**Время жизни:** Нет никаких [гарантий](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 минут, ответ будет более гранулированным. А если же будет произведен запрос данных за последние два дня, выборка данных будет более грубой. Не расчитывайте на то, что вы получите все записи данных. **Будут** пропущенные интервалы.
 	-	❗**Управление жизненным циклом:** Не пытайтесь применять какие нибудь модные инструменты управления спотовыми инстансами до тех пор, пока это не станет абсолютно необходимым. Если вы используете всего несколько машин и цена вас полностью устраивает, а уровень отказов мал, не пытайтесь оптимизровать. Те страдания, которые вы испытаете в процессе создания/поддержки этого решения, не стоит нескольких сотен долларов экономии. 
--	**Reserved Instances:** allow you to get significant discounts on EC2 compute hours in return for a commitment to pay for instance hours of a specific instance type in a specific AWS region and availability zone for a pre-established time frame (1 or 3 years). Further discounts can be realized through “partial” or “all upfront” payment options.
-	-	Consider using Reserved Instances when you can predict your longer-term compute needs and need a stronger guarantee of compute availability and continuity than the (typically cheaper) Spot market can provide. However be aware that if your architecture changes your computing needs may change as well so long term contracts can seem attractive but may turn out to be cumbersome.
-	-	There are two types of Reserved Instances - [Standard and Convertible](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-types.html). If you purchase excess Standard Reserved Instances, you may offer to “sell back” unused Reserved Instances via the [Reserved Instance Marketplace](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-market-selling-guide.html), this allows you to potentially recoup the cost of unused EC2 compute instance hours by selling them to other AWS customers.
-	-	Instance reservations are not tied to specific EC2 instances - they are applied at the billing level to eligible compute hours as they are consumed across all of the instances in an account.
-	-	📜There have been scattered reports of Convertible RI purchases needing to be exercised in a block-- namely, if you buy five convertible RIs in one purchase, you can't convert just two of them. Reach out to your account manager for clarification if this may impact you.
--	If you have multiple AWS accounts and have configured them to roll charges up to one account using the “Consolidated Billing” feature, you can expect *unused* Reserved Instance hours from one account to be applied to matching (region, availability zone, instance type) compute hours from another account.
--	If you have multiple AWS accounts that are linked with Consolidated Billing, plan on using reservations, and want unused reservation capacity to be able to apply to compute hours from other accounts, you’ll need to create your instances in the availability zone with the same *name* across accounts. Keep in mind that when you have done this, your instances may not end up in the same *physical* data center across accounts - Amazon shuffles availability zones names across accounts in order to equalize resource utilization.
--	Make use of dynamic [Auto Scaling](#auto-scaling), where possible, in order to better match your cluster size (and cost) to the current resource requirements of your service.
--	If you use RHEL instances and happen to have existing RHEL on-premise Red Hat subscriptions, then you can leverage Red Hat's [Cloud Access program](https://www.redhat.com/en/technologies/cloud-computing/cloud-access) to migrate a portion of your on-premise subscriptions to AWS, and thereby saving on AWS charges for RHEL subscriptions. You can either use your own self-created RHEL AMI's or Red Hat provided [Gold Images](https://access.redhat.com/articles/2962171) that will be added to your private AMI's once you sign up for Red Hat Cloud Access.
+-	**Зарезервированные инстансы:** позволяют вам получить значительные скидки на цену вычислительного часа 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.
 
 Дополнительные материалы
 ---------------