Update ru.md

translations/ru.md

@@ -765,15 +765,15 @@ S3
 		-	🔸Если вы используете ресурсы с разных доменов, как например шрифты, внутри ваших файлов 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), таким образом инвалидация не потребуется.
--	**Data lifecycles:**
-	-	When managing data, the understanding the lifecycle of the data is as important as understanding the data itself. When putting data into a bucket, think about its lifecycle — its end of life, not just its beginning.
-	-	🔹In general, data with different expiration policies should be stored under separate prefixes at the top level. For example, some voluminous logs might need to be deleted automatically monthly, while other data is critical and should never be deleted. Having the former in a separate bucket or at least a separate folder is wise.
-	-	🔸Thinking about this up front will save you pain. It’s very hard to clean up large collections of files created by many engineers with varying lifecycles and no coherent organization.
-	-	Alternatively you can set a lifecycle policy to archive old data to Glacier. [Be careful](https://alestic.com/2012/12/s3-glacier-costs/) with archiving large numbers of small objects to Glacier, since it may actually cost more.
-	-	There is also a storage class called [**Infrequent Access**](https://aws.amazon.com/s3/storage-classes/#Infrequent_Access) that has the same durability as Standard S3, but is discounted per GB. It is suitable for objects that are infrequently accessed.
--	**Data consistency:** Understanding [data consistency](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) is critical for any use of S3 where there are multiple producers and consumers of data.
-	-	Creation and updates to individual objects in S3 are **atomic**, in that you’ll never upload a new object or change an object and have another client see only part half the change.
-	- The uncertainty lies with *when* your clients and other clients see updates.
+-	**Жизненные циклы данных:**
+	-	При управлении данными понимание жизненного цикла данных так же важно, как и понимание самих данных. Когда вы помещаете данные в бакет, подумайте об их жизненном цикле - окончании, а не только начале.
+	-	🔹Как правило, данные с разными политиками истечения срока действия должны храниться под отдельными префиксами в начале. Например, некоторые объемные лог файлы должны автоматически удаляться ежемесячно, в то время, как другие данные критичны и никогда не должны удаляться. Хранение ранних данных в отдельном бакете или в отдельной папке - весьма разумно. 
+	-	🔸Если подумать об этом заранее - это поможет избежать многих проблем в будущем. Очень сложно чистить большие наборы файлов созданные многими инженерами с разными жизненными циклами и отсутствием какой-либо цельной организации.
+	-	Также вы можете настроить политику жизненного цикла для архивации старых данных в 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)**, таким образом у вас никогда не будет ситуации, что вы обновляете иил загружаете новый объект, а другой клиент видит только часть изменений. 
+	- Неопределенность заключается в том, *когда* вы и ваши клиенты увидят обновления.
 	-	**New objects:** If you create a new object, you’ll be able to read it instantly, which is called **read-after-write consistency**.
 		-	Well, with the additional caveat that if you do a read on an object before it exists, then create it, [you get eventual consistency](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) (not read-after-write).
 		-	This does not apply to any list operations; newly created objects are [not guaranteed to appear in a list operation right away](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel)