Documentation updates (#75)

Co-authored-by: Kurtis Mash <24705116+kurtismash@users.noreply.github.com>

Author: paulschwarzenberger

docs/architecture.md

@@ -18,6 +18,8 @@ Each deployment orchestrates the creation of resources in both the Backup accoun
 - A Resource Access Manager (RAM) Share to share the Logically Air Gapped (LAG) Vault with the Workload accounts for recovery.
 - A Step Function to manage the copying of backups from the Standard Vault back to workload accounts for recovery.
 
+Additional resources are created in the central Backup account to support deployment to workload accounts, as detailed below.
+
 ## Resources in workload accounts
 
 Each deployment orchestrates the creation of resources in workload accounts through [CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). The module uses CloudFormation as it enables deployment to many AWS accounts without the need to configure and manage a Terraform provider for each account. StackSets work natively within AWS, reacting when accounts are moved between Organizations and Organizational Units to provision and destroy resources depending on their location within an Organization.

docs/usage-backing-up-your-resources.md

@@ -10,7 +10,7 @@ This document provides guidance on how to back up resources using this Terraform
 
 ### AWS Managed KMS Keys
 
-Immediate backups of resource types that are not "fully managed" by AWS Backup within the will retain the encryption configuration of the source resource, when backups are copied this will change to the encryption key of the destination Backup Vault. Backups of resources that are encrypted with an AWS managed KMS Key - a key with an alias starting `aws/` - [cannot be copied cross-account](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html#copy-encryption) so will fail to copy to the central account Backup Vault to be held immutably.
+Immediate backups of resource types that are not "fully managed" by AWS Backup will retain the encryption configuration of the source resource. When backups are copied, this will change to the encryption key of the destination Backup Vault. Backups of resources that are encrypted with an AWS managed KMS Key - a key with an alias starting `aws/` - [cannot be copied cross-account](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html#copy-encryption) so will fail to copy to the central account Backup Vault to be held immutably.
 
 ### Customer Managed KMS Keys
 

docs/usage-prerequisites.md

@@ -7,7 +7,7 @@ The module is designed to be deployed into a delegated administrator account wit
 - [All features are enabled](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) for your AWS Organization.
 - Trusted access [with AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html#integrate-enable-ta-backup) and [Resource Access Manager (RAM)](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-ram.html#integrate-enable-ta-ram) is enabled on your Organization.
 - [Backup Policies](https://docs.aws.amazon.com/organizations/latest/userguide/enable-policy-type.html) are enabled within your Organization.
-- ["Enable cross-account backup"](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html#prereq-cab) is turned on within your Organization.
+- [Enable cross-account backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html#prereq-cab) is turned on within your Organization.
 - [AWS Backup cross-account monitoring](https://docs.aws.amazon.com/aws-backup/latest/devguide/manage-cross-account.html#enable-cross-account) is enabled within your Organization.
 - The account you are deploying to has been [delegated to manage AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/manage-cross-account.html#backup-delegatedadmin).
 - The account you are deploying to has been [delegated to manage CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html).

docs/why-use-this-module.md

@@ -10,7 +10,7 @@ This module aims to simplify the process of deploying AWS Backup within an AWS O
 
 ## What about Vault Lock?
 
-Immutability within AWS Backup is achieved through the use of [Compliance mode](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html#backup-vault-lock-modes) vault locking. However, whilst this prevents the recovery points within the vault from being deleted, it does not extend the same protections to the KMS Key used to encrypt them. An malicious user would only need to delete this KMS Key to make the data within the backups inaccessible.
+Immutability within AWS Backup is achieved through the use of [Compliance mode](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html#backup-vault-lock-modes) vault locking. However, whilst this prevents the recovery points within the vault from being deleted, it does not extend the same protections to the KMS Key used to encrypt them. A malicious user would only need to delete this KMS Key to make the data within the backups inaccessible.
 
 Protecting a KMS Key is much more difficult. Although keys cannot be deleted immediately, they can be scheduled for deletion with only 7 days grace. Keys can be protected through [Key Policies](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html), such as removing the ability to schedule key deletions or update the key policy, but this is a known issue within AWS and has a well documented path to recover these abilities through opening a case with AWS Support.