AccountFactory edify: Concepts and Guides files plus 2 addit files

Architecture/index.md

@@ -0,0 +1,41 @@
+# Account Factory Architecture
+
+## Overview
+
+Account Factory uses Gruntwork's [AWS Control Tower Multi Account Factory](/reference/modules/terraform-aws-control-tower/control-tower-multi-account-factory/) and Pipelines to automated account creation, baselining, and IAM policy management.
+
+In your `infrastructure-live-root` repository, the `_new-account-requests` directory acts as input for the Gruntwork Control Tower Module. The module, functioning within your management account, employs AWS Control Tower to efficiently provision new accounts and manage existing ones.
+
+Pipelines tracks each provisioned account as a new base directory containing Terragrunt units in your `infrastructure-live-root` repository.
+
+![Architecture Overview Diagram](/img/accountfactory/architecture.png)
+
+## Account vending
+
+Account Vending starts by triggering the Account Factory Workflow which generates a Pull Request against `infrastructure-live-root`, adding a file to the `_new-account-requests` directory. Pipelines detects these new account requests and runs terragrunt plan/apply commands on the `control-tower-multi-account-factory` unit in the management account.
+
+After creating the account(s), Pipelines provisions resources such as IaC-controlled OIDC-authenticated roles. TThese roles, combined with IAM policies that define the scope of permissible changes, allow Pipelines to deploy infrastructure updates within the account.
+
+Once this infrastructure is added to the repository, Pipelines deploys the resources into the AWS account and runs account baselines in the logs, security, and shared accounts to complete the provisioning process.
+
+```mermaid
+sequenceDiagram
+  Account Factory Workflow ->> Infra Live Repository: Create account request file;
+  Infra Live Repository ->> Pipelines: Trigger Account Requested;
+  Pipelines ->> AWS Control Tower Module: Execute terragrunt to create account
+  AWS Control Tower Module ->> Pipelines: Account Created
+  Pipelines ->> Infra Live Repository: Add Account Infrastructure
+  Infra Live Repository ->> Pipelines: Trigger Account Added
+  Pipelines ->> Core Accounts: Execute terragrunt to baseline account
+```
+## IAM roles
+
+Newly created accounts include IAM policies that define the scope of changes Pipelines is authorized to perform within AWS. Pipelines automatically assumes the necessary roles for each account when it detects changes. Detailed information about the provisioned roles can be found [here](/2.0/docs/pipelines/architecture/security-controls#roles-provisioned-by-devops-foundations).
+
+## Delegated repositories
+
+Delegated repositories enhance the architecture of infrastructure management by introducing additional layers of access control. When delegated repositories are created, Pipelines continues to monitor new account security baselines within the `infrastructure-live-root` repository, while other infrastructure resources are managed in a new repository specific to the delegated account(s). 
+
+Pipelines inherits updated IAM roles from the `infrastructure-live-access-control` repository to deploy infrastructure in these delegated repositories. This setup enables the central platform team to define and restrict the scope of changes individual teams can make via Pipelines in delegated repositories.
+
+![Delegated Architecture Overview Diagram](/img/accountfactory/delegated-architecture.png)

Architecture/logging.md

@@ -0,0 +1,69 @@
+# Logging
+
+Gruntwork Account Factory configures [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) for all accounts in your [AWS Organization](https://aws.amazon.com/organizations/). CloudTrail helps you determine _who_ did _what_ and _when_ in each of your AWS accounts.
+
+## Where you can find logs
+
+Gruntwork Account Factory automatically configures AWS CloudTrail to log all operations in your AWS accounts. By default, CloudTrail maintains your data for 90 days and is queryable using the AWS Console CloudTrail UI.
+
+Account Factory sets up CloudTrail to forward all events from all of your AWS accounts to an S3 bucket in your `logs` AWS account with a default rule to expire objects after 1 year. After logs reach S3, you can set up an additional tool for [querying the logs](#querying-data).
+
+### CloudTrail
+
+The CloudTrail UI in each AWS account provides access to logs. To access the CloudTrail UI, navigate to the AWS Console, search `CloudTrail` in the search bar, select CloudTrail from the search results, and then select **Event History** from the left side panel.
+
+### S3
+
+S3 receives CloudTrail logs approximately every 5 minutes. If AWS Control Tower created your S3 bucket, it will be named `aws-controltower-logs-<logs account id>-<primary Control Tower region>`. At the top level of the bucket is a single prefix with a random ID, which contains additional prefixes to distinguish between logs for CloudTrail and AWS Config. Find CloudTrail logs for each account in the prefix `<random id>/AWSLogs/<random id>/`.
+
+For each account, CloudTrail delivers logs to region, year, month, and day-specific prefixes in the bucket. For example, logs for an account with the id `123456789012` on September 26th, 2023 in the `us-west-2` region would be in a prefix named `123456789012/us-west-2/2023/09/26`.
+
+If you configured your logs bucket while setting up AWS Control Tower, you will need access to the KMS key you created to encrypt the objects before you download any objects. See [Logs bucket access](#logs-bucket-access) for more information.
+
+For more information about querying data in S3, see [querying in S3](#querying-in-s3).
+
+## Data access
+
+Granting access to the audit logs requires security configurations in the originating account (e.g., the account in which the events are occurring) and the `logs` account. The originating account contains the CloudTrail trail itself, which should only be viewable by account administrators. The `logs` account contains the AWS S3 bucket that contains synchronized CloudTrail logs from all logs.
+
+### CloudTrail access
+
+Access to CloudTrail is controlled by AWS IAM policies that are assigned to individual IAM users (not recommended) or IAM roles that can be assumed by users (recommended) in AWS accounts.
+
+:::tip
+Gruntwork recommends that only those with administrative access to an AWS account have access to view CloudTrail logs, as they contain a record of every single API operation that was performed in the account, which may expose the name or configuration of resources an individual user may otherwise not have access to.
+:::
+
+Furthermore, you should define the configuration of CloudTrail trails as code, with all changes reviewed in a pull request before being applied automatically by [Gruntwork Pipelines](/2.0/docs/pipelines/concepts/overview).
+
+See [Identity-based policy examples for AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/security_iam_id-based-policy-examples.html) to learn more about granting access to CloudTrail.
+
+### Logs bucket access
+
+Access to the logs bucket requires the user to have access to the centralized `log` account by assuming an AWS IAM role (preferred) or by having an IAM user in the account. In addition, the role or user must have S3 permissions for the S3 bucket containing the CloudTrail events.
+
+Access to the objects containing CloudTrail events in S3 is controlled by IAM policies assigned to IAM users or roles. Further, to download the object, any IAM role or user needs permission to perform `kms:Decrypt` on the KMS key that was configured for object encryption when setting up the CloudTrail trail.
+
+:::tip
+Gruntwork recommends that only a select group of trusted individuals on your security team have direct access to objects in the S3 bucket. Whenever possible, the data should be accessed by [querying](#querying-data) it using the CloudTrail UI or a query service such as [Amazon Athena](https://aws.amazon.com/athena/).
+:::
+
+## Querying data
+
+You can query CloudTrail data in two ways - in the originating account or from the `logs` account. Querying in the originating account is done using the CloudTrail UI, which is helpful for quick checks that do not require in-depth analysis of usage and trends. If you need support for performing analytics to observe usage and trends, Gruntwork recommends querying the data in the S3 bucket in the `logs` account using a query service like [Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html).
+
+### Querying in CloudTrail
+
+CloudTrail supports simple queries based on pre-set lookup attributes, including the event source, event name, user name, and resource type. You can find a complete list of filters in [filtering CloudTrail events](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html#filtering-cloudtrail-events). The filters in CloudTrail allow you to perform coarse-grained queries over a single attribute filter and time range and view details on individual events. Using the CloudTrail UI can be a quick way to retrieve a lot of information, such as all the users that have performed a specific API call (e.g., ListBuckets). However, it is ineffective when analyzing data to understand usage patterns across multiple attributes, such as the usage of Gruntwork Pipelines by all users in your GitHub organization.
+
+You can also [download events](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html#downloading-events) from CloudTrail in CSV or JSON format and perform more in-depth analysis of events in another system such as a query service or using a script on your local machine.
+
+### Querying in S3
+
+If you configure CloudTrail to output all logs to an S3 bucket, you can take two approaches to perform queries on the data - downloading the data directly (not recommended) and setting up a query service like [Amazon Athena](https://aws.amazon.com/athena/) to allow for more in-depth analysis of your data (recommended).
+
+Amazon Athena is a popular query service because it is integrated into the AWS Console, and lets you perform queries on data in S3 directly. Furthermore, because CloudTrail logs have a known structure and prefix scheme in S3, you can set up [Athena with partition projection](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html#create-cloudtrail-table-partition-projection), which will automatically create new partitions in Athena, reducing the work required to ensure data partitioning for optimal query support. We recommend Athena because of its convenience; you can use any query service you choose to analyze the data as long as the tool can pull data out of S3. See [example queries](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html#query-examples-cloudtrail-logs) and [tips for querying CloudTrail logs](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html#tips-for-querying-cloudtrail-logs) for more information on analyzing CloudTrail data using Athena.
+
+:::warning
+While it is possible to download CloudTrail event data from S3, it is generally not recommended. Finding data requires downloading potentially many objects and writing scripts to parse and analyze them. Once the data is outside S3, it is impossible to know what analysis is performed. Query services like AWS Athena or similar allow you to see the history of queries performed and who performed the query.
+:::

Architecture/network-topology.md

@@ -0,0 +1,29 @@
+# About Network Topology
+
+The Network Topology component focuses on implementing best-practices network architecture for your organization.
+
+The standard network architecture includes:
+
+- The Virtual Private Cloud (VPC) itself
+- Subnets, isolated subdivisions within the VPC, are organized into three "tiers": public, private app, and private persistence
+- Route tables, which define routing rules for subnets
+- Internet Gateways, to manage traffic between public subnets and the Internet
+- Network Address Translation Gateways (NAT Gateways), to handle traffic between private subnets and the Internet
+- VPC peering connections to a management VPC, to allow for centralized network routing
+- DNS forwarding, for communication with a management VPC
+- Optional tags for an EKS cluster
+
+## Out-of-the-box setup
+
+Gruntwork generates the IaC code required to implement an opinionated, standard, recommended VPC configuration. Details are available in the [VPC service catalog module](/reference/services/networking/virtual-private-cloud-vpc).
+
+## Extending the standard VPC
+
+You can expand the configuration using "building block" modules from the VPC topic in the Gruntwork IaC Library. These modules enable additional functionality such as:
+
+- [Enabling IPv6](/reference/modules/terraform-aws-vpc/vpc-app/#ipv6-design)
+- [Adding a Transit Gateway](/reference/modules/terraform-aws-vpc/transit-gateway/)
+- [Enabling DNS forwarding](/reference/modules/terraform-aws-vpc/vpc-dns-forwarder/)
+- [Setting up Tailscale](/reference/services/security/tailscale-subnet-router)
+
+This process involves working directly with the OpenTofu/Terraform modules in the Gruntwork IaC Library.

concepts/delegated-repositories.md

@@ -0,0 +1,47 @@
+# Delegated Repositories
+
+::: note 
+
+Account Factory-created Delegated Repositories are only available to DevOps Foundations Enterprise customers.
+
+:::
+
+As enterprises scale their usage of IaC across multiple teams, the need to enforce least-privilege access control to both IaC source code and its CI/CD processes becomes increasingly important. Gruntwork recommends leveraging multiple source code repositories to establish clear boundaries that enforce least-privilege access control. 
+
+This approach involves a structured pattern that includes: 
+
+-  **Centralized `infrastructure-live-root` repository**  
+   Governed by the core platform team, this repository contains IaC for essential security and shared infrastructure. Examples include account creation, central logging/auditing, and networking controls (e.g., GuardDuty, SecurityHub, Macie, Transit Gateway).
+
+-  **Team-specific delegated repositories**  
+   Named using a convention such as `infrastructure-live-$TEAM_NAME`, these repositories enable individual teams to manage their own IaC. The core platform team creates delegated repositories through the Account Factory. The `infrastructure-live-access-control` system controls access to these repositories, granting teams permissions specific to their infrastructure responsibilities.
+
+By adopting this pattern, core platform teams can:
+
+- Centrally manage compliance and security infrastructure.
+- Define and enforce which teams are authorized to deploy specific types of infrastructure, ensuring alignment with architecture board-approved plans.
+- Oversee shared and per-team infrastructure tags for consistency and governance.
+- Enforce least-privilege access policies, restricting teams to access only the IaC and deployment capabilities necessary for their responsibilities.
+
+## Delegated repository creation
+
+Delegated repositories can be optionally created by the [Account Factory](/2.0/docs/accountfactory/concepts) as part of the account provisioning process. The workflow for vending a delegated account follows these automated steps:
+
+```mermaid
+sequenceDiagram
+  participant Account Factory
+  participant Infrastructure Live Root
+  participant Infrastructure Live Access Control
+  participant New Delegated Repository
+  participant AWS
+  Account Factory->>AWS: Create Account
+  AWS->>Account Factory: Created Account ID
+  Account Factory->>Infrastructure Live Root: Generate IaC code <br />to install account baselines
+  Infrastructure Live Root->>AWS: Deploy baseline IaC code into new account via Pipelines
+  Account Factory->>Infrastructure Live Access Control: Generate IAC Code to setup permissions for new delegated repository
+  Infrastructure Live Access Control->>AWS: Deploy permissions IaC code into new account via Pipelines
+  Account Factory->>New Delegated Repository: Create new repository
+  Note over New Delegated Repository: New Team writes IaC for their application
+  New Delegated Repository->>AWS: Deploy application using roles<br /> managed by Infrastructure Live Access Control
+
+```

concepts/index.md

@@ -0,0 +1,29 @@
+# Gruntwork Account Factory
+
+Gruntwork Account Factory lets you create new AWS accounts with best-practice baselines.
+
+Enterprise customers get dedicated Infrastructure as Code repositories for new accounts during the vending process. As a result, central platform teams can automate AWS account creation and delegate infrastructure management to individual teams for scalability and autonomy.
+
+This approach empowers developer teams to self-service deploy infrastructure within the confines of IAM roles managed in a centralized access control repository. The result is a combination of least privilege access to AWS resources and flexible, self-service infrastructure deployment
+
+Gruntwork Account Factory uses Gruntwork Pipelines as its foundation. Account creation requests are tracked in Git as Infrastructure as Code (IaC), triggering Terragrunt plans and applies to set up and baseline the accounts. By following this approach, account provisioning follows the same review and collaboration steps as other infrastructure changes, using pull requests for validation
+
+## Account baselines
+
+Gruntwork Account Factory does more than create AWS accounts—it also provisions a set of customizable baseline resources to prepare accounts for immediate use in production workloads.
+
+These baselines include:
+
+1. Security configurations for services such as [GuardDuty](https://aws.amazon.com/guardduty/), [SecurityHub](https://aws.amazon.com/security-hub/), and [Macie](https://aws.amazon.com/macie/), following best practices.
+2. Networking configurations aligned with best practices for [AWS VPCs](https://aws.amazon.com/vpc/).
+3. IAM roles designed for least privilege access, enabling CI/CD pipelines to manage AWS resources using [GitHub OIDC](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
+
+
+## White glove support
+
+Enterprise customers benefit from tailored white glove support to customize account baselines and the vending process according to their needs. This support includes:
+
+1. Adjusting security configurations within the account baseline and ensuring compliance with frameworks like CIS from the outset.
+2. Modifying networking configurations in the account baseline, including support for [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) setups and integration of network inspection appliances like [AWS Network Firewall](https://aws.amazon.com/network-firewall/).
+3. Customizing access control for delegated infrastructure management repositories, automatically assigning specific teams the necessary permissions to manage IaC for newly created accounts.
+