AWS automatic deployment with Organizational Units (OUs) is a feature primarily managed through AWS CloudFormation StackSets. You can use organizational units (OUs) to group accounts together to administer as a single unit. This greatly simplifies the management of your accounts. Once enabled, auto-deployment is triggered when accounts are added to a target organization or OU, removed from a target organization or OU, or moved between target OUs, and this would reflect on your Druva management console automatically.
AWS CloudFormation StackSets are a crucial tool to enable automated deployment across accounts and OUs, and bring the following advantages:
Deployment Target: Instead of targeting individual AWS accounts, you configure a StackSet to target a specific Organizational Unit (OU).
Automatic Deployment: When you enable Auto-Deployment on a service-managed StackSet, AWS CloudFormation performs two key actions:
It automatically deploys the specified CloudFormation stack to every existing account in the targeted OU and its child OUs.
Crucially, whenever a new account is added to that target OU, removed, or moved, the StackSet is automatically updated without manual intervention. Any changes to the OU will automatically reflect on your AWS Workloads (CloudRanger) management console.
Before you begin
Define Organizational Units: To get started with auto-deployment, you must first create a logical structure of Organizational Units (OUs). Ensure that you have the Organizational Units defined on your AWS management console. For detailed information, refer to the AWS documentation.
Enable Trusted Access: Enable trusted access between AWS Organizations and CloudFormation StackSets. This grants StackSets the necessary permissions to manage resources in member accounts using a service-linked role.
Enable Auto Deployment
Create a new CloudFormation StackSet or import Stacks from the AWS management account, and then select the deployment option Deploy Stacks in organizational units (OUs) with service-managed permissions.
Log into your AWS Workloads (CloudRanger) console and navigate to the Organization in which you wish to add new accounts. Click Add New Account on the top right.
Copy or download the CloudFormation template to manually create the stack and provision the access role for your AWS environment.
Click Launch AWS Console to be automatically directed to the CloudFormation section of your AWS account.
Click StackSets on the left navigation menu and then click Create StackSet.
Select the Upload a template file option if you have downloaded the CloudFormation template in the previous step.
Alternatively, you may copy the CloudFormation URL and paste this into Amazon S3 template URL Click Next.On the Set deployment options page, specify the following:
Under Add stacks to stack set, select Deploy new stacks.
Under Deployment locations, select Deploy Stacks in Organizational Units. Enter the Organizational Unit ID in the Organization numbers textbox.
📝 Note
Each Organisational Unit (OU) has a standardized alphanumeric ID. For detailed information on creating and managing OUs, refer to the AWS documentation.Click Next.
7. Verify the details under Review and click Submit.
📝 Note
Automatic deployments are enabled by default when you create a StackSet with an Organizational Unit (OU). You can then enable or disable the automatic deployment on the StackSet. For more information, refer to the AWS documentation.
Update Organizational Units and Scenarios
AWS CloudFormation StackSets with service-managed permissions provide a robust framework for automating multi-account deployments. By integrating directly with AWS Organizations, they eliminate the need for you to manually create the necessary IAM roles in every target account.
Scenario 1: Adding a new Account to a Targeted Organizational Unit
If you add a new AWS Account to an Organizational Unit that is enabled as part of the auto deployment, the new Account will automatically reflect on your AWS Workloads (CloudRanger) management console.
Adding an Account to an OU that a StackSet is targeting triggers the following, if Automatic Deployment is enabled on the StackSet:
Event detection: When an Account is moved into or added to the OU, AWS Organizations notifies the AWS CloudFormation Stackset.
Auto-deployment trigger: The StackSets initiates a Create Stacks operation within the new account in the specified Regions.
Resource provisioning: A new CloudFormation stack, based on the StackSet's template, is deployed into the new member account.
Drift protection and consistency: The new account now has the same baseline infrastructure, including IAM roles, security configurations, or networking components, as the other Accounts in the OU.
Scenario 2: Account removal from an Organizational Unit
If an AWS Account is removed from an Organizational Unit that is enabled as part of the auto deployment, the Account will no longer be available on your AWS Workloads (CloudRanger) management console.
❗Important
If an AWS Account is removed from an OU that is enabled as part of the auto deployment, it will also be removed from your Druva management console. However, all existing recovery points are preserved, and will still remain available, until the original retention period expires.
Default scenario: delete Stacks
Detection : AWS Organizations notifies AWS CloudFormation that the account is no longer in the targeted OU.
Automatic cleanup trigger: The StackSet automatically triggers a Delete Stacks operation for that account.
Resource deletion: The CloudFormation stack and all resources are terminated from the removed account.
Alternative scenario: Retaining Stacks
When creating or editing the StackSet, you can set the Account removal behavior to Retain stacks.
Stack management: The StackSet stops managing the stack instance in the removed account.
Resource deletion: The CloudFormation stack and its resources are not deleted and remain in the account, allowing you to manage them manually.
📝 Note
You can choose to add the AWS Account back by manually deploying the Cloud Formation template for the individual account. Alternatively, if the AWS Account was inadvertently removed, just add the Account back to the originalOU, and this will reflect on AWS Workloads (CloudRanger) management console, as long as the OU is still configured for auto deployment.
Scenario 3: Account Moved between two Organizational Units
If an AWS Account is moved from one Organizational Unit to another, the account will reflect based on whether the second OU is also configured for auto deployment.
Use Case: OU1 is enabled for auto deployment on AWS Workloads (CloudRanger). Account A is configured as part of OU1, and is now moved from OU1 to a new OU2.
Case 1: If OU2 is not enabled as part of auto deployment, then Account A will no longer be available on your AWS Workloads (CloudRanger) management console
Case 2: If OU2 is also enabled as part of auto deployment, then Account A will continue to reflect on your AWS Workloads (CloudRanger) management console, since both Organizational Units are configured for auto deployment.