diff --git a/translations/ru.md b/translations/ru.md
index ae0d69a..983d940 100644
--- a/translations/ru.md
+++ b/translations/ru.md
@@ -2323,7 +2323,7 @@ SNS
 -	При правильном использовании регионы и зоны обеспечивают высокую доступность. Возможно, вы захотите использовать других провайдеров для еще более значительного снижения бизнес-рисков (то есть не привязывать свою компанию к одному поставщику), но надежность AWS в различных регионах крайне высока.
 -	**Несколько регионов:** Использование нескольких регионов является сложным, поскольку по сути это похоже на управление совершенно отдельными инфраструктурами. Это необходимо для критически важных для бизнеса услуг с высоким уровнем резервирования. Однако для многих приложений (например, для вашего стартапа ориентирующегося на средний класс потребителей) развертывание обширной избыточности по регионам может оказаться излишним.
 -	Этот блог [High Scalability](http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html) является хорошим руководством, призванным помочь вам понять, нужно ли вам растягивать ваше приложение на несколько регионов.
--	🔹**Multiple AZs:** Using AZs wisely is the primary tool for high availability!
+-	🔹**Несколько зон доступности(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.