BBL-445 | how-it-works multiple sections updated: organization, relia…

…bility, security and storage
binbashar · Dec 6, 2020 · a81384e · a81384e
1 parent a88a1ad
commit a81384e
Show file tree

Hide file tree

Showing 7 changed files with 75 additions and 14 deletions.
diff --git a/docs/how-it-works/organization/billing.md b/docs/how-it-works/organization/billing.md
@@ -6,15 +6,21 @@ Each month AWS charges your payer **Root Account** for all the linked accounts i
 The following illustration shows an example of a consolidated bill.
 
 ![leverage-aws-org](../../assets/images/diagrams/aws-organizations-scp.png "Leverage"){: style="width:750px"}
-<figcaption>
-**Figure:** AWS Organization Multi-Account structure(just as reference). 
-- [ :ledger: **Source:** cloudnout.io ](https://cloudonaut.io/images/2020/04/aws-organizations-1.png)
+<figcaption style="font-size:15px">
+<b>Figure:</b> AWS Organization Multi-Account structure (just as reference).
+(Source: Andreas Wittig, 
+<a href="https://cloudonaut.io/aws-account-structure-think-twice-before-using-aws-organizations/">
+"AWS Account Structure: Think twice before using AWS Organizations"</a>,
+Cloudonaut.io Blog, accessed November 18th 2020).
 </figcaption>
 
 ![leverage-aws-org](../../assets/images/diagrams/aws-organizations-billing.png "Leverage"){: style="width:750px"}
-<figcaption>
-**Figure:** AWS Organization Multi-Account structure(just as reference). 
-- [ :ledger: **Source:** docs.aws.amazon.com ](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/useconsolidatedbilling-procedure.html)
+<figcaption style="font-size:15px">
+<b>Figure:</b> AWS Organization Multi-Account billing structure (just as reference).
+(Source: AWS, 
+<a href="https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/useconsolidatedbilling-procedure.html">
+"Consolidated billing process"</a>,
+AWS Documentation AWS Billing and Cost Management User Guide, accessed November 18th 2020).
 </figcaption>
 
 !!! info "Reference Architecture [**AWS Organizations**](https://aws.amazon.com/organizations/) features"

diff --git a/docs/how-it-works/organization/organization.md b/docs/how-it-works/organization/organization.md
@@ -55,7 +55,7 @@ The following block provides a brief explanation of the chosen AWS Organization
           and afterwards even imported into your [terraform code](https://www.terraform.io/docs/providers/aws/r/organizations_account.html#import).
     - [x] **Migration:** After having your baseline AWS Org reference cloud solutions architecture deployed
         (IAM, VPC, NACLS, VPC-Peering, DNS Cross-Org,
-        CloudTrail, etc.) you're ready to start progressively orchestrating new resources in order to segregate different
+        CloudTrail, etc) you're ready to start progressively orchestrating new resources in order to segregate different
         Environment and Services per account.
         This approach will allow you to start a **1 by 1 Blue/Green (Red/Black) migration without affecting any of your 
         services at all**. You would like to take advantage of an Active-Active DNS switchover approach (nice as DR exercise too). 

diff --git a/docs/how-it-works/reliability/backups.md b/docs/how-it-works/reliability/backups.md
@@ -21,7 +21,12 @@
     backup management, enabling you to meet your business and regulatory backup compliance requirements.
 
 ![leverage-aws-backup](../../assets/images/diagrams/aws-backup.png "Leverage"){: style="width:950px"}
-<figcaption>**Figure:** [AWS Backup](https://aws.amazon.com/backup/) service diagram (just as reference).</figcaption>
+<figcaption style="font-size:15px">
+<b>Figure:</b> AWS Backup service diagram (just as reference).
+(Source: AWS, 
+<a href="https://aws.amazon.com/backup/">"AWS Backup - Centrally manage and automate backups across AWS services"</a>,
+AWS Documentation, accessed November 18th 2020).
+</figcaption>
 
 ## ![leverage-aws-s3](../../assets/images/icons/aws-emojipack/Storage_AmazonS3.png "Leverage"){: style="width:30px"} S3 bucket region replication
 * ![leverage-aws-s3](../../assets/images/icons/aws-emojipack/Storage_AmazonS3_bucket.png "Leverage"){: style="width:20px"}

diff --git a/docs/how-it-works/reliability/dr.md b/docs/how-it-works/reliability/dr.md
@@ -37,3 +37,29 @@ After deciding RTO and RPO we have options available to achieve the time objecti
      between them in normal production status, you can adjust the DNS weighting and send all traffic to the AWS region
      that is available, this can even be performed automatically with Route53 or other DNS services that provide health
      check mechanisms as well as load balancing.
+
+![leverage-aws-dr](../../assets/images/diagrams/aws-route53-dns-dr.png "Leverage"){: style="width:800px"}
+<figcaption style="font-size:15px">
+<b>Figure:</b> 2 sets of app instances, each behind an elastic load balancer in two separate regions (just as reference).
+(Source: Randika Rathugamage, 
+<a href="https://medium.com/@randika/high-availability-with-route53-dns-failover-c13cb30cbe94">
+"High Availability with Route53 DNS Failover"</a>,
+Medium blogpost, accessed December 1st 2020).
+</figcaption>
+
+![leverage-aws-dr](../../assets/images/diagrams/aws-route53-dns-health-checks.png "Leverage"){: style="width:800px"}
+<figcaption style="font-size:15px">
+<b>Figure:</b> AWS calculated — or parent — health check, we can fail on any number of child health checks (just as reference).
+(Source: Simon Tabor, 
+<a href="https://medium.com/dazn-tech/how-to-implement-the-perfect-failover-strategy-using-amazon-route53-1cc4b19fa9c7">
+"How to implement the perfect failover strategy using Amazon Route53"</a>,
+Medium blogpost, accessed December 1st 2020).
+</figcaption>
+
+## Read more
+
+!!! info "AWS reference links"
+    Consider the following AWS official links as reference:
+
+    - :orange_book: [**AWS Documentation Amazon Route 53 Developer Guide | Configuring DNS failover**](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+
diff --git a/docs/how-it-works/reliability/high-availability.md b/docs/how-it-works/reliability/high-availability.md
@@ -7,7 +7,7 @@
     themselves trigger recovery is the way to move forward.
 
 ![leverage-aws-reliability](../../assets/images/diagrams/aws-reliability-ha-recovery-failure.png "Leverage"){: style="width:750px"}
-<figcaption>**Figure:** AWS HA architecture diagrams (just as reference).</figcaption>
+<figcaption style="font-size:15px">Figure: AWS HA architecture diagrams (just as reference).</figcaption>
 
 ## Recovery Procedures 
 
@@ -18,7 +18,7 @@
     the emergency shows just how reliable the system it.
 
 ![leverage-aws-reliability](../../assets/images/diagrams/aws-reliability-ha-recovery-procs.png "Leverage"){: style="width:750px"}
-<figcaption>**Figure:** AWS HA architecture diagrams (just as reference).</figcaption>
+<figcaption style="font-size:15px">Figure: AWS HA architecture diagrams (just as reference).</figcaption>
 
 ## Scalability and Availability
 
@@ -28,7 +28,7 @@
     the environment’s lifecycle.
 
 ![leverage-aws-reliability](../../assets/images/diagrams/aws-reliability-ha-recovery-scaling.png "Leverage"){: style="width:750px"}
-<figcaption>**Figure:** AWS HA scalable architecture diagrams (just as reference).</figcaption>
+<figcaption style="font-size:15px">Figure: AWS HA scalable architecture diagrams (just as reference).</figcaption>
 
 ## Helthchecks & Self-healing
 

diff --git a/docs/how-it-works/security/vpn.md b/docs/how-it-works/security/vpn.md
@@ -2,7 +2,6 @@
 
 ### To securely and scalable privately access AWS Cross Organization resources we’ll implement [Pritunl VPN Server](https://pritunl.com/)
 
-
 !!! danger "Security Directives"
     1. **Private HTTP endpoints** for Applications (FrontEnd + APIs), SSH, monitoring & logging (UI / Dashboards) among others. Eg: Jenkins, DroneCI, EFK, Prometheus, Spinnaker, Grafana.
     2. **K8s API via kubectl private endpoint** eg: avoiding emergency K8s API vulnerability patching. 
@@ -16,7 +15,13 @@
         3. Centralized access and audit logs.
 
 ![leverage-vpn](../../assets/images/diagrams/ref-architecture-vpn.png "Leverage"){: style="width:650px"}
-
+<figcaption style="font-size:15px">
+<b>Figure:</b> Securing access to a private network with Pritunl diagram.
+(Source: Pritunl, 
+<a href="https://docs.pritunl.com/docs/accessing-a-private-network">
+"Accessing a Private Network"</a>,
+Pritunl documentantion v1 Guides, accessed November 17th 2020).
+</figcaption>
 
 ### Read More
 - [x] [Pritunl - Open Source Enterprise Distributed OpenVPN, IPsec and WireGuard Server Specifications](https://drive.google.com/file/d/1piF0pZSTwcV4oHTIh_VsqZzEWTK5_zlv/view?usp=sharing) :cloud: :lock:
diff --git a/docs/how-it-works/storage/storage.md b/docs/how-it-works/storage/storage.md
@@ -12,10 +12,29 @@ As for EBS volumes, our recommendation is to create all encrypted by default. Ov
     * [x] **Access logs enabled:** TBD per bucket
     * [x] **MFA delete:** Yes on critical buckets
     * [x] **Replication to another region:** TBD per bucket
+
+| Storage class           | Designed for                                                                | Durability (designed for) | Availability (designed for)        | Availability Zones | Min storage duration | Min billable object size | Other considerations                                                                                                                                   |
+|-------------------------|-----------------------------------------------------------------------------|---------------------------|------------------------------------|--------------------|----------------------|--------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|
+| S3 Standard             | Frequently accessed data                                                    | 99.999999999%             | 99.99%                             | >= 3               | None                 | None                     | None                                                                                                                                                   |
+| S3 Standard-IA          | Long-lived, infrequently accessed data                                      | 99.999999999%             | 99.9%                              | >= 3               | 30 days              | 128 KB                   | Per GB retrieval fees apply.                                                                                                                           |
+| S3 Intelligent-Tiering  | Long-lived data with changing or unknown access patterns                    | 99.999999999%             | 99.9%                              | >= 3               | 30 days              | None                     | Monitoring and automation fees per object apply. No retrieval fees.                                                                                    |
+| S3 One Zone-IA          | Long-lived, infrequently accessed, non-critical data                        | 99.999999999%             | 99.5%                              | 1                  | 30 days              | 128 KB                   | Per GB retrieval fees apply. Not resilient to the loss of the Availability Zone.                                                                       |
+| S3 Glacier              | Long-term data archiving with retrieval times ranging from minutes to hours | 99.999999999%             | 99.99% (after you restore objects) | >= 3               | 90 days              | 40 KB                    | Per GB retrieval fees apply. You must first restore archived objects before you can access them. For more information, see Restoring archived objects. |
+| S3 Glacier Deep Archive | Archiving rarely accessed data with a default retrieval time of 12 hours    | 99.999999999%             | 99.99% (after you restore objects) | >= 3               | 180 days             | 40 KB                    | Per GB retrieval fees apply. You must first restore archived objects before you can access them. For more information, see Restoring archived objects. |
+| RRS (Not recommended)   | Frequently accessed, non-critical data                                      | 99.99%                    | 99.99%                             | >= 3               | None                 | None                     | None                                                                                                                                                   |
 
-## ![leverage-aws-s3](../../assets/images/icons/aws-emojipack/Storage_AmazonEBS.png "Leverage"){: style="width:25px"} EBS Volumes
+## ![leverage-aws-ebs](../../assets/images/icons/aws-emojipack/Storage_AmazonEBS.png "Leverage"){: style="width:25px"} EBS Volumes
 
 !!! Important "Tech specs"
     * [x] **Backups:** Periodic EBS snapshots with retention policy
     * [x] **Encryption:** Yes (by default)
     * [x] **Type:** SSD (gp2) by default, Throughput Optimized HDD (st1) for some database workloads, if needed.
+
+## Read more
+
+!!! info "Reference links"
+    Consider the following extra links as reference:
+
+    - :orange_book: [Amazon S3 FAQs](https://aws.amazon.com/s3/faqs/)
+    - :orange_book: [Amazon S3 storage classes - Developer Guide](https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-class-intro.html)
+    - :orange_book: [Amazon S3 Storage Classes](https://aws.amazon.com/s3/storage-classes/)