diff --git a/translations/ru.md b/translations/ru.md
index 983d940..6a39520 100644
--- a/translations/ru.md
+++ b/translations/ru.md
@@ -2324,21 +2324,21 @@ SNS
 -	**Несколько регионов:** Использование нескольких регионов является сложным, поскольку по сути это похоже на управление совершенно отдельными инфраструктурами. Это необходимо для критически важных для бизнеса услуг с высоким уровнем резервирования. Однако для многих приложений (например, для вашего стартапа ориентирующегося на средний класс потребителей) развертывание обширной избыточности по регионам может оказаться излишним.
 -	Этот блог [High Scalability](http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html) является хорошим руководством, призванным помочь вам понять, нужно ли вам растягивать ваше приложение на несколько регионов.
 -	🔹**Несколько зон доступности(AZ):** Разумное использование AZ - первый инструмент в обеспечении высокой доступности!
-	-	A typical single-region high availability architecture would be to deploy in two or more availability zones, with load balancing in front, as in [this AWS diagram](http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_ftha_04.pdf).
-	-	The bulk of outages in AWS services affect one zone only. There have been rare outages affecting multiple zones simultaneously (for example, the [great EBS failure of 2011](http://aws.amazon.com/message/65648/)) but in general most customers’ outages are due to using only a single AZ for some infrastructure.
-	-	Consequently, design your architecture to minimize the impact of AZ outages, especially single-zone outages.
-	-	Deploy key infrastructure across at least two or three AZs. Replicating a single resource across more than three zones often won’t make sense if you have other backup mechanisms in place, like S3 snapshots.
-	-	A second or third AZ should significantly improve availability, but additional reliability of 4 or more AZs may not justify the costs or complexity (unless you have other reasons like capacity or Spot market prices).
-	-	💸Watch out for **cross-AZ traffic costs**. This can be an unpleasant surprise in architectures with large volume of traffic crossing AZ boundaries.
-	-	Deploy instances evenly across all available AZs, so that only a minimal fraction of your capacity is lost in case of an AZ outage.
-	-	If your architecture has single points of failure, put all of them into a single AZ. This may seem counter-intuitive, but it minimizes the likelihood of any one SPOF to go down on an outage of a single AZ.
--	**EBS vs instance storage:** For a number of years, EBSs had a poorer track record for availability than instance storage. For systems where individual instances can be killed and restarted easily, instance storage with sufficient redundancy could give higher availability overall. EBS has improved, and modern instance types (since 2015) are now EBS-only, so this approach, while helpful at one time, may be increasingly archaic.
--	Be sure to [use and understand CLBs/ALBs](#load-balancers) appropriately. Many outages are due to not using load balancers, or misunderstanding or misconfiguring them.
+	-	Типичной архитектурой высокой доступности для одного региона является развертывание в двух или более зонах доступности с балансировкой нагрузки, как на [этом изображении от 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). Многие отказы были вызваны из-за не использования балансировщиков нагрузки или неправильного понимания их работы и, следовательно, неправильной настройке.
 
-### High Availability Gotchas and Limitations
+### Ошибки и ограничения, связанные с высокой доступностью
 
--	🔸**AZ naming** differs from one customer account to the next. Your “us-west-1a” is not the same as another customer’s “us-west-1a” — the letters are assigned to physical AZs randomly per account. This can also be a gotcha if you have multiple AWS accounts. Note that Zone IDs are consistent between accounts, and can be used to reliably align between AWS accounts.
--	🔸💸**Cross-AZ traffic** is not free. At large scale, the costs add up to a significant amount of money. If possible, optimize your traffic to stay within the same AZ as much as possible.
+-	🔸**Наименование зон доступности** различается от одного пользовательского аккаунта к другому. Ваша зона “us-west-1a” не та же самая, как зона “us-west-1a” у другого клиента — буквы назначаются физической зоне доступности произвольно для каждого аккаунта. Это может привести к ошибкам, если вы используете различные аккаунты AWS. Имейте ввиду, что ID зоны доступности остаются одинаковыми во всех аккаунтах и это может быть использовано для надежного ориентирования при работе между разными аккаунтами AWS.
+-	🔸💸**Траффик между зонами доступности** не бесплатен. В больших масштабах, это может добавить серьезный объем затрат. Если возможно, оптимизируйте передачу данных так, чтобы трафик циркулировал в пределах одной зоны доступности настолько, насколько это возможно.
 
 Billing and Cost Management
 ---------------------------