Initial draft - Add guide - Importing Stack Resources #290

docs/getting-started/getting-started-aws/connect-an-account/index.md

@@ -22,7 +22,7 @@ Switch back to the Guardrails console **Account Import** browser tab you opened
 
 ## Step 2: Update account details
 
-Paste the role ARN you obtained from step 7 in the previous guide into the **IAM Role ARN** field.  Also, enter the AWS account ID into the **Account ID** field.
+Paste the role ARN you obtained from step 7 in the previous guide into the **IAM Role ARN** field and enter the AWS account ID into the **Account ID** field.
 
 <p><img alt="ready-to-connect" src="/images/docs/guardrails/getting-started/getting-started-aws/connect-an-account/ready-to-connect.png"/></p>
 

docs/getting-started/getting-started-aws/prepare-account/index.md

@@ -24,13 +24,17 @@ Login to your Guardrails console and select the **CONNECT** option from the home
 
 <p><img alt="locate-top-level-connect" src=" /images/docs/guardrails/getting-started/getting-started-aws/prepare-account/locate-top-level-connect.png"/></p>
 
+Select **AWS**.
+
+<p><img alt="locate-top-level-connect" src=" /images/docs/guardrails/getting-started/getting-started-aws/prepare-account/initial-connect-screen.png"/></p>
+
 ## Step 2: Download the CloudFormation template
 
 Guardrails needs an IAM role that grants permission to discover [resources](/guardrails/docs/reference/glossary#resource) in your account and to monitor changes via event handlers. The CloudFormation template downloaded in this step has the minimum permissions necessary to create that role.
 
 Select **AWS Account** from the left navigation and then click the blue **Download CloudFormation Template** button to download the CloudFormation template you will use to create the required IAM role in your AWS account.
 
-<p><img alt="initial-connect-screen" src=" /images/docs/guardrails/getting-started/getting-started-aws/prepare-account/initial-connect-screen.png"/></p>
+<p><img alt="initial-connect-screen" src=" /images/docs/guardrails/getting-started/getting-started-aws/prepare-account/download-cloudformation-template.png"/></p>
 
 > [!IMPORTANT]
 > Leave this browser tab open while we do the next steps in a different tab. Closing and reopening this page will cause a new random ExternalID to be generated.

docs/getting-started/getting-started-azure/connect-subscription/index.md

@@ -21,6 +21,10 @@ Login to your Guardrails console and select the **CONNECT** option from the home
 
 <p><img alt="login" src="/images/docs/guardrails/getting-started/getting-started-azure/connect-subscription/login.png"/></p>
 
+Select **Azure**.
+
+<p><img alt="login" src="/images/docs/guardrails/getting-started/getting-started-azure/connect-subscription/select-azure.png"/></p>
+
 ## Step 2: Select Azure Subscription
 
 <p><img alt="connect-1" src="/images/docs/guardrails/getting-started/getting-started-azure/connect-subscription/connect-1.png"/></p>

docs/guides/configuring-guardrails/activity-retention/index.md

@@ -0,0 +1,67 @@
+---
+title: Workspace Activity Retention
+sidebar_label: Workspace Activity Retention
+---
+
+# Configuring Workspace Activity Retention
+
+In this guide, you will:
+
+- Set up the Guardrails *Turbot > Workspace > Retention > Activity Retention* policy to manage the lifecycle of activity records associated with resources or controls.
+- Understand how activity retention impacts storage usage and workspace performance.
+
+Guardrails' [Activity Retention](https://hub.guardrails.turbot.com/mods/turbot/policies/turbot/activityRetention) policy controls the duration for which activity records such as actions, events, or notifications, are kept within your workspace. Properly configured retention periods optimize storage, enhance performance, and satisfy compliance and auditing requirements.
+
+## Prerequisites
+
+- **Turbot/Admin** permissions at the Turbot resource level.
+- Familiarity with the Guardrails console.
+
+## Step 1: Navigate to the Policy
+
+Log in to the Guardrails console using your local credentials or via SAML-based login. Select **Policies** from the top navigation menu, then search for the policy named `Turbot > Workspace > Retention > Activity Retention`.
+
+![Navigate to Policies](/images/docs/guardrails/guides/configuring-guardrails/activity-retention/navigate-to-policies.png)
+
+Click **New Policy Setting** in the top-right corner of the policy details page.
+
+## Step 2: Configure the Policy
+
+Select the **Resource** or **Folder** at which you wish to set the retention policy.
+> [!IMPORTANT]
+> It is recommended to set this policy at the `Turbot` (root) level. Applying this policy at a lower level (e.g., individual folder or resource) may result in errors like:
+>
+> ```
+> Error creating policy setting
+> Internal Error: Create failed: Resource (aaa - Customer Simulated Environments) is not valid. Aborting policy setting create.
+> ```
+
+Under **Settings**, choose the appropriate retention period based on your organization's operational needs. Refer to [Retention Options](#retention-options) for details.
+
+![New Policy Setting](/images/docs/guardrails/guides/configuring-guardrails/activity-retention/new-policy-setting.png)
+
+Click **Update** to save the new policy setting.
+
+## Step 3: Review
+
+- [ ] Return to the **Policies** tab and confirm the policy has been correctly applied by verifying the **Current Setting**.
+
+![Verify Policy](/images/docs/guardrails/guides/configuring-guardrails/activity-retention/verify-activity-retention-policy.png)
+
+## Retention Options
+
+1. **30 days**: For maximum UI performance.
+2. **60 days**: A balanced approach recommended for most environments.
+3. **90 days (default)**: Default retention duration.
+4. **180, 365 days**: Suitable for meeting compliance requirements or specific organizational needs.
+
+## Next Steps
+
+- Explore additional ways to [Configure Guardrails](/guardrails/docs/guides/configuring-guardrails).
+
+## Troubleshooting
+
+| Issue                          | Description                                                                                             | Guide                                                                                               |
+| ------------------------------ | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
+| Permission Issues              | Confirm that you have the necessary (`Turbot/Admin`) permissions to modify policies.                     | [Permissions & Roles](/guardrails/docs/concepts/iam/permissions#permissions) |
+| Further Assistance                       | If you continue to encounter issues, please open a ticket with us and attach the relevant information to assist you more efficiently.                                                 | [Open Support Ticket](https://support.turbot.com)   |

docs/guides/configuring-guardrails/index.md

@@ -8,6 +8,7 @@ This section provides how-to guides for common tasks that will help you effectiv
 
 | Guide | Description |
 | - | -
+| [Workspace Activity Retention](guides/configuring-guardrails/activity-retention) | Learn how to set up Workspace activity retention in Guardrails console
 | [Install Mod](guides/configuring-guardrails/install-mod) | Learn how to install mod in Guardrails console
 | [Update Mod](guides/configuring-guardrails/update-mod) |  Learn how to uninstall mod in Guardrails console
 | [Uninstall Windows](guides/configuring-guardrails/uninstall-mod) | Learn how to update mod in Guardrails console

docs/guides/hosting-guardrails/disaster-recovery/architecture-options/index.md

@@ -0,0 +1,102 @@
+---
+title: Architecture Options
+sidebar_label: Architecture Options
+---
+
+# Architecture Options
+
+In this guide, you will:
+
+- Explore architectural considerations for deploying Turbot Guardrails.
+- Understand different options available based on organizational risk and availability requirements.
+
+
+Turbot Guardrails is a comprehensive governance platform that automates discovery, compliance, security, and operational remediation tasks across cloud environments. Due to its critical role as a security and compliance control plane, it's essential to configure Guardrails with high availability and disaster recovery in mind.
+
+This document outlines various architectural options to help you select an approach aligned with your organization's specific high availability (HA) and disaster recovery (DR) needs, based on your risk tolerance and operational requirements.
+
+
+| Tier     | Account       | Region          | Availability Zone | Availability | RTO | RPO | Use Cases                                    |
+|----------|---------------|-----------------|-------------------|--------------|-----|-----|----------------------------------------------|
+| Tier1   | Single-account | Single-region   | Single-AZ         | 99%          | 4 Hr | 4 Hr | Development and non-prod environments        |
+| Tier2   | Single-account | Single-region   | Multi-AZ          | 99.9%        | 4 Hr | 4 Hr | Production without rapid DR requirements     |
+| Tier3   | Single-account | Multi-region    | Multi-AZ          | 99.9%        | 2 Hr | 2 Hr | Production requiring rapid DR                |
+| Tier4   | Multi-account  | Multi-region    | Multi-AZ          | 99.99%       | 0 Hr | 0 Hr | Mandated zero downtime DR                    |
+
+<!-- - **Tier 1** – Single-account, single-region, single availability zone.
+
+  - 99% Availability
+  - RTO: 4 Hr.
+  - RPO: 4 Hr.
+  - Use cases: Development and non-prod environments
+
+- **Tier 2** – Single-account, single-region, multi-availability zone.
+
+  - 99.9% Availability
+  - RTO: 4 Hr.
+  - RPO: 4 Hr.
+  - Use cases: Production deployments without need for rapid DR
+
+- **Tier 3** – Single-account, multi-region, multi-availability zone.
+
+  - 99.9% Availability
+  - RTO: 2 Hr.
+  - RPO: 2 Hr.
+  - Use cases: Production deployments with need for rapid DR
+
+- **Tier 4** – Multi-account, multi-region, multi-availability zone.
+  - 99.99% Availability
+  - RTO: 0 Hr.
+  - RPO: 0 Hr.
+  - Use cases: Mandated zero downtime DR -->
+
+## Tier 1: Development
+
+**Key Characteristics**: Single-account, single-region, single availability zone.
+
+This deployment option is appropriate for non-production and development workspaces, where high-availability and disaster recovery are not important for the accounts monitored by guardrails.
+
+This is the lowest cost infrastructure deployment option available.
+
+![Tier 1 DR Architecture](/images/docs/guardrails/guides/hosting-guardrails/disaster-recovery/architecture-options/tier-1.png)
+
+This deployment uses one primary RDS instance without a failover configuration. Recovery can be performed from RDS point-in-time backups.
+
+## Tier 2: High Availability
+
+**Key Characteristics**: Single-account, single-region, multi-availability zone.
+
+This deployment option is appropriate for all production usage. It is the most cost-effective deployment option for production use cases and has the capability to achieve 4hr RPO/RTO in all circumstances except the loss of an entire AWS Region.
+
+![Tier 2 DR Architecture](/images/docs/guardrails/guides/hosting-guardrails/disaster-recovery/architecture-options/tier-2.png)
+
+The changes in this deployment vs the **Tier 1 DR** architecture are:
+
+1. The ECS compute cluster is deployed across multiple availability zones.
+2. Lambda are deployed across multiple availability zones.
+3. An RDS failover instance is deployed in a second availability zone.
+4. An Elasticache failover instance is deployed in a second availability zone.
+
+## Tier 3: Multi-Region
+
+**Key Characteristics**: Single-account, multi-region, multi-availability zone.
+
+This deployment option is appropriate when regulatory requirements demand that a multi-region solution be implemented, or when requirements drive less than a 4hr RTO/RPO. It has the benefit of being resilient to the loss of an entire AWS Region.
+
+![Tier 3 DR Architecture](/images/docs/guardrails/guides/hosting-guardrails/disaster-recovery/architecture-options/tier-3.png)
+
+The key difference between this deployment is that a second Turbot Guardrails deployment is created in the standby region. The compute cluster will be set to be dormant, and no inbound events will be received by the cluster. On declaration of a disaster, DNS will be changed to send events to this region, while the database is recovered from a cross region RDS snapshot. Once the DB is recovered, the workspace is enabled, and events will start processing from the queue.
+
+To use this pattern, [cross-region RDS backups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReplicateBackups.html) must be configured in this account to ensure the DB can be restored in the target region without access to KMS in the primary region. This option also requires the use of AWS API Gateway, and a public DNS endpoint and SSL certificate to allow redirection of inbound real-time events between regions.
+
+## Tier 4: Multi-Account
+
+**Key Characteristics**: Multi-account, multi-region, multi-availability zone.
+
+The **Tier 4** deployment option should be considered for any organization with zero RTO/RPO requirements. This deployment option allows for instantaneous failover between two active Guardrails environments. We use the “Change Window” feature of guardrails to prevent one of the implementations from executing any enforcements. Upon declaration of an emergency, the standby environment change window can be removed allowing that environment to become the primary and enforce changes.
+
+In normal day to day operation, both environments consume cloud events and maintain independent CMDB databases. This pattern results in both doubling the infrastructure and per control usage costs for Guardrails if employed.
+
+![Tier 4 DR Architecture](/images/docs/guardrails/guides/hosting-guardrails/disaster-recovery/architecture-options/tier-4.png)
+
+Care must be made in this configuration to ensure that policy packs and account onboarding/offboarding is done across both environments in tandem, using the Guardrails Terraform provider to maintain consistency between the deployments. Custom scripting may be necessary to periodically check to ensure both environments are identical in configuration, to meet your organizations DR requirements.