Learning AWS Day by Day — Day 82 — Disaster Recovery (DR) — Part 2
Disaster Recovery (DR) — Part 2
How to implement High Availability Vs How to implement Disaster Recovery:
The diagram shown (above) gives you very resilient High Availability architecture. S3 and Dynamodb or NoSQL database are not in AZ as these are designed in a way by AWS that they are automatically replicated across AZ. The data they store is replicated across multiple AZ, that gives you High Availability and high durability of that data already built in for you.
So, if there’s a flood one AZ goes down, still another AZ is up and running. These AZs are designed specifically so that they dont share fate, and other 2 AZs are fine. Other than this, what else can be done is use Backups.
If you have EBS attached and they are in zones, you should keep backups which give you disaster resiliency which is a disaster recovery strategy.
EBS -> Volumes -> Snapshots
Another example is human actions, like let’s say accidental deletion or data corruption or bad actor, in that case replication is not good, you will replicate corrupted data, so here we need point in time backups. You can see Dynamodb, so we can go back to last good state and restore the data. Similarly, S3 has it’s versioning concept.
DynamoDB -> Point in time deploy
S3 -> Versioning
Subscribe to my newsletter
Read articles from Saloni Singh directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Saloni Singh
Saloni Singh
• A Software Engineer with hands-on experience in AWS and Aws DevOps • Experience in CodePipeline using CodeCommit, CodeBuild and CodeDeploy • Experience with Terraform, Gitlab, Kubernetes, AWS DevOps, Helm charts, Golang, Python and NodeJS • Hands-on experience on AWS Migration projects including services - DMS, Glue, Aurora, Lambda, S3 • Possesses good knowledge on Bash Shell Scripting and Python Programming