AI Services Opt-Out Policies – Designing a Multi-Account AWS Environment for Complex Organizations – SAP-C02 Study Guide

AI Services Opt-Out Policies

This type of policy lets you decide whether you allow AI services to collect data when they’re being used across your organization. Some AI services provided by AWS, such as Amazon Lex, Amazon Polly, Amazon Rekognition, and more (for a complete list, please consult the AWS documentation) may store and collect some data for service improvement. If you have concerns regarding compliance with regulations applying to the business domain in your organization (for instance, healthcare or finance), you may well avoid any issue by opting out systematically from sharing any data with such AI services.

On the other hand, if you don’t have any such regulatory or compliance issue, or if you only process anonymized data with such AI services, you can contribute to and accelerate the service’s improvement by opting in. This is what AWS Organizations AI services opt-out policies are about. You can set up such policies at an OU level or across your entire organization. An opt-out policy that is attached to an OU applies to all accounts belonging to that OU and all child OUs across all AWS Regions.

Backup Policies

Backup policies are meant to centrally manage and enforce backup plans across your entire organization, so that you don’t have to set this up account per account. This can help you simplify the backup process management overhead and enforce governance hygiene across all your accounts.

AWS Backup allows you to create backup plans specifying how to back up your AWS resources. A backup plan definition includes various settings, such as the backup vault to store the backup, the backup schedule (including the frequency and the time window during which it occurs), the life cycle for expiration or transition to cold storage, and the AWS Region where the resources to be backed up can be found. You can then apply a backup plan to groups of AWS resources identified by tags. Backup policies combine all components of the policy into policy documents written in JSON and can be attached to individual accounts, OUs, or your entire organization.

AWS Backup determines the policy to apply (or the effective backup policy) by applying inheritance rules from the top of your organization down to the account where it is being used.

Ensure that backup policies at each level are complete. You can define incomplete backup policies at parent OU levels, delegating the responsibility to child entities (OUs or accounts) to make those policies complete. This is, however, not an effective idea, especially in large organizations, where you easily risk ending up with an incomplete backup policy at child levels as well. An incomplete effective backup policy in one account would simply cause the backup process to fail to back up the account’s resources, leading to disastrous consequences. Thus, it is best to always define complete backup policies at every level so that child entities inherit default settings that they may (or may not) override, depending on your requirements regarding inheritance control operators.

Another best practice is to limit the number of backup plans per policy and have a single backup plan per backup policy. This will make it a lot easier to ensure proper functioning (and troubleshooting) of the backup policy. Should a change in one of your backup policies break things up at some point, its impact would be limited to the single backup plan attached to that policy. All your other backup plans would remain unaffected.

It is also recommended to increase your protection against accidental deletion of your backups by storing backup copies in a separate account, a separate Region, or both. For this, you can use the copy_actions instruction in the backup plan rules of your backup policies. Note that you can also use the $account implicit variable, representing the account where the backup is taking place, to more easily compile the Amazon Resource Name (ARN) of your target backup vault, either in the same Region or in another Region. Multiple backup policy examples are proposed in the AWS documentation, so make sure to check them out before rolling up your own.