diff --git a/docs/learn/concepts.mdx b/docs/learn/concepts.mdx
index 455c68afc..a1a7cab03 100644
--- a/docs/learn/concepts.mdx
+++ b/docs/learn/concepts.mdx
@@ -6,17 +6,13 @@ import Intro from '@site/src/components/Intro';
import Steps from '@site/src/components/Steps';
import StepNumber from '@site/src/components/StepNumber';
import Step from '@site/src/components/Step';
-import ReactPlayer from 'react-player';
+import GettingStartedSlides from '@site/docs/slides/_getting-started.mdx';
Your platform ensures consistent service delivery every time. A well-designed platform seamlessly integrates with your monitoring, security, and compliance systems, building on your established foundation. Automated software delivery pipelines deploy new services quickly and easily. The reference architecture supports AWS EKS, Amazon ECS, and Lambda functions.
-
-
-
- AI generated voice
-
+
diff --git a/docs/resources/legacy/setup-videos/development.mdx b/docs/resources/legacy/setup-videos/development.mdx
new file mode 100644
index 000000000..9e6b868e9
--- /dev/null
+++ b/docs/resources/legacy/setup-videos/development.mdx
@@ -0,0 +1,38 @@
+---
+title: "Development Videos"
+sidebar_label: "Development"
+description: "Overview videos for component development"
+---
+import Intro from '@site/src/components/Intro';
+import Steps from '@site/src/components/Steps';
+import Step from '@site/src/components/Step';
+import StepNumber from '@site/src/components/StepNumber';
+import PrimaryCTA from '@site/src/components/PrimaryCTA';
+import ReactPlayer from 'react-player';
+
+:::warning Legacy Content
+These videos are preserved for reference but may not reflect current implementation details.
+See the [Component Development](/learn/component-development) documentation for up-to-date information.
+:::
+
+
+This video covers how to develop custom Terraform components using Cloud Posse's
+conventions and integrate them with the reference architecture.
+
+
+
+
+ ## Component Development
+
+ Learn how to build custom Terraform components that integrate with the Cloud Posse
+ reference architecture. This covers component structure, using Cloud Posse modules,
+ integrating with Atmos stacks, and following conventions for consistent infrastructure.
+
+
+
+ AI generated voice
+
+
+ View Current Documentation
+
+
diff --git a/docs/resources/legacy/setup-videos/foundation-setup.mdx b/docs/resources/legacy/setup-videos/foundation-setup.mdx
new file mode 100644
index 000000000..47471e229
--- /dev/null
+++ b/docs/resources/legacy/setup-videos/foundation-setup.mdx
@@ -0,0 +1,87 @@
+---
+title: "Foundation Setup Videos"
+sidebar_label: "Foundation Setup"
+description: "Overview videos for setting up your AWS foundation"
+---
+import Intro from '@site/src/components/Intro';
+import Steps from '@site/src/components/Steps';
+import Step from '@site/src/components/Step';
+import StepNumber from '@site/src/components/StepNumber';
+import PrimaryCTA from '@site/src/components/PrimaryCTA';
+import ReactPlayer from 'react-player';
+
+:::warning Legacy Content
+These videos are preserved for reference but may not reflect current implementation details.
+See the [Foundation Layer](/layers/foundation) for up-to-date documentation.
+:::
+
+
+These videos cover the foundational elements of the Cloud Posse Reference Architecture,
+including project setup, account management, identity configuration, and network architecture.
+
+
+
+
+ ## Introduction to Toolchain
+
+ Learn about the essential tools Cloud Posse uses to manage infrastructure as code.
+ This guide covers the Geodesic Toolbox Container for standardizing development environments,
+ the Atmos framework for implementing conventions and workflows, Terraform for managing
+ cloud infrastructure, and GitHub Actions for CI/CD automation.
+
+
+
+ AI generated voice
+
+
+ View Current Documentation
+
+
+
+ ## Account Management
+
+ Review how Cloud Posse designs and manages AWS Account architectures using Atmos and Terraform,
+ aligning with the AWS Well-Architected Framework. This covers provisioning the Terraform state
+ backend, organizing accounts into Organizational Units (OUs), applying Service Control Policies
+ (SCPs), and configuring account-level settings.
+
+
+
+ AI generated voice
+
+
+ View Current Documentation
+
+
+
+ ## Identity and Authentication
+
+ Learn how Cloud Posse sets up fine-grained access control for an entire organization using
+ Permission Sets, IAM roles, and AWS IAM Identity Center (SSO). This addresses the challenges
+ of managing access across multiple AWS accounts with a solution that ensures precise control,
+ easy role switching, and compatibility with different identity providers.
+
+
+
+ AI generated voice
+
+
+ View Current Documentation
+
+
+
+ ## Network and DNS
+
+ Understand Cloud Posse's approach to designing robust and scalable Network and DNS architectures
+ on AWS, with a focus on symmetry, account-level isolation, security, and reusability. Covers
+ account isolation, connecting multiple accounts using Transit Gateways, deploying AWS Client VPN
+ for remote network access, and differentiating between DNS service discovery and branded vanity domains.
+
+
+
+ AI generated voice
+
+
+ View Current Documentation
+
+
diff --git a/docs/resources/legacy/setup-videos/platform-setup.mdx b/docs/resources/legacy/setup-videos/platform-setup.mdx
new file mode 100644
index 000000000..68b964173
--- /dev/null
+++ b/docs/resources/legacy/setup-videos/platform-setup.mdx
@@ -0,0 +1,83 @@
+---
+title: "Platform Setup Videos"
+sidebar_label: "Platform Setup"
+description: "Overview videos for setting up your AWS platform"
+---
+import Intro from '@site/src/components/Intro';
+import Steps from '@site/src/components/Steps';
+import Step from '@site/src/components/Step';
+import StepNumber from '@site/src/components/StepNumber';
+import PrimaryCTA from '@site/src/components/PrimaryCTA';
+import ReactPlayer from 'react-player';
+
+:::warning Legacy Content
+These videos are preserved for reference but may not reflect current implementation details.
+See the [Platform Layer](/layers/platform) for up-to-date documentation.
+:::
+
+
+These videos cover the platform elements of the Cloud Posse Reference Architecture,
+including software delivery, GitOps automation, container orchestration, and monitoring.
+
+
+
+
+ ## Software Delivery / Release Engineering
+
+ Learn about Cloud Posse's approach to CI/CD and release engineering. This covers the
+ philosophy behind treating pipelines as software, using GitHub Actions for automation,
+ and implementing consistent deployment patterns across environments.
+
+
+
+ AI generated voice
+
+
+ View Current Documentation
+
+
+
+ ## GitOps with Terraform
+
+ Understand how to implement GitOps for Terraform using GitHub Actions. This covers
+ plan/apply workflows, drift detection, and the integration with Atmos for managing
+ infrastructure deployments through pull requests.
+
+
+
+ AI generated voice
+
+
+ View Current Documentation
+
+
+
+ ## ECS Platform
+
+ Learn about Amazon ECS (Elastic Container Service) as a container orchestration solution.
+ This covers the benefits of ECS over Kubernetes for simpler deployments, cluster configuration,
+ service deployment, and integration with the reference architecture.
+
+
+
+ AI generated voice
+
+
+ View Current Documentation
+
+
+
+ ## Monitoring and SRE
+
+ Understand Cloud Posse's approach to monitoring and observability. This covers integrating
+ with Datadog, setting up monitors, implementing SLIs/SLOs, and building a monitoring-as-code
+ approach using Terraform.
+
+
+
+ AI generated voice
+
+
+ View Current Documentation
+
+
diff --git a/docs/resources/legacy/setup-videos/setup-videos.mdx b/docs/resources/legacy/setup-videos/setup-videos.mdx
new file mode 100644
index 000000000..9f0d2fc8c
--- /dev/null
+++ b/docs/resources/legacy/setup-videos/setup-videos.mdx
@@ -0,0 +1,21 @@
+---
+title: "Legacy Setup Videos"
+sidebar_label: "Setup Videos"
+description: "AI-generated overview videos for the Cloud Posse Reference Architecture"
+---
+import Intro from '@site/src/components/Intro';
+import DocCardList from '@theme/DocCardList';
+
+:::warning Legacy Content
+These AI-generated overview videos were created during the initial documentation development.
+They provide high-level overviews but may not reflect the latest implementation details.
+
+**For current documentation**, please refer to the main documentation sections for each layer.
+:::
+
+
+These videos provide AI-narrated overviews of the Cloud Posse Reference Architecture.
+They are organized by the major setup phases: Foundation, Platform, and Development.
+
+
+
diff --git a/docs/slides/_getting-started.mdx b/docs/slides/_getting-started.mdx
new file mode 100644
index 000000000..dcb911c76
--- /dev/null
+++ b/docs/slides/_getting-started.mdx
@@ -0,0 +1,627 @@
+{/*
+ Getting Started with the Reference Architecture - Slide Content
+
+ This file contains the slide content for the "Getting Started" presentation.
+ It can be imported and embedded in other MDX files using:
+
+ import GettingStartedSlides from '@site/docs/slides/_getting-started.mdx';
+
+*/}
+
+import {
+ SlideDeck,
+ Slide,
+ SlideTitle,
+ SlideSubtitle,
+ SlideContent,
+ SlideList,
+ SlideCode,
+ SlideImage,
+ SlideSplit,
+ SlideNotes,
+} from '@site/src/components/SlideDeck';
+
+
+
+{/* Slide 1: Title */}
+
+ Getting Started with the Reference Architecture
+ The "Big Picture" Overview
+
+ Welcome to the introduction to the Cloud Posse toolchain. In this presentation,
+ we'll cover the big picture of the Cloud Posse reference architecture.
+
+
+
+{/* Slide 2: Goals */}
+
+ Goals for Today
+
+
Training Handoff Layout and Schedule
+
Terminology
+
Conventions
+
Repository Layout
+
Toolbox
+
+
+ At this point, you may be wondering, "when can I start to use my infrastructure?"
+ And "when will I learn how to develop Components?" Or "How can I get help?"
+ We'll answer all these questions and more in this handoff.
+ We are going to cover the basics of Cloud Posse's toolchain and the structure of these handoffs,
+ including the recommended listening order.
+
+
+
+{/* Slide 3: Handoff Schedule */}
+
+ What to Expect: Training & Handoff Order
+
+
+
Kick Off
+
Introduction to Toolset
+
Identity and Authentication
+
Component Development
+
Account Management
+
DNS & Network Architecture
+
ECS/EKS Clusters
+
+
+
Atmos GitOps Workflows
+
Monitoring
+
Alerting
+
Release Engineering
+
Final Call (Sign-off)
+
+
+ This schedule is open for customization to best suit your needs
+
+ This is the general idea of what to expect in handoffs.
+ Each of these topics starts with a brief presentation and should address the most common questions we receive from customers.
+ We recommend attending the weekly customer workshops for an open-ended discussion on any of these topics.
+ Of course, this schedule depends on the specifics of your engagement.
+
+
+
+{/* Slide 4: Terminology Section Title */}
+
+ Terminology
+
+ So let's begin by covering our terminology.
+ Cloud Posse has coined a few terms that we use across our architecture and with Atmos
+ to refer to a number of unique practices.
+
+
+
+{/* Slide 5: Stacks */}
+
+ Stacks
+
+
+
Written as YAML
+
Configures Terraform variables and Atmos settings
+
Defines Instances of Components
+
Found under stacks/
+
+
+{`components:
+ terraform:
+ cloudtrail:
+ settings:
+ github:
+ actions_enabled: false
+ vars:
+ enabled: true
+ name: cloudtrail
+ cloudtrail_bucket_environment_name: ue2
+ cloudtrail_bucket_stage_name: audit
+ cloudwatch_logs_retention_in_days: 90
+ is_organization_trail: true`}
+
+
+
+ Stacks are a way to express the complete infrastructure needed for a deployment.
+ Think of a Stack like an architectural "Blueprint" composed of one or more Components
+ and defined using a standardized YAML configuration.
+ This abstraction layer helps orchestrate loosely coupled components, or Terraform root modules.
+ They enable scalable infrastructure-as-code configurations that can inherit and deep-merge
+ settings to minimize config duplication and manual effort.
+ Please note that Cloud Posse's definition of "stacks" is unique and differs from the
+ interpretations by HashiCorp, Spacelift, Terragrunt, and others.
+
+
+
+{/* Slide 6: Components */}
+
+ Components
+
+
+
Reusable building blocks of Infrastructure-as-Code
+
Terraform "root" modules
+
Details in a follow-up call
+
+
+{`components/terraform
+.
+├── account
+├── account-map
+├── account-settings
+├── acm
+├── argocd-repo
+├── aurora-postgres
+
+─────────────────────────────────────
+
+components/terraform/datadog-monitor
+├── README.md
+├── component.yaml
+├── context.tf
+├── main.tf
+├── outputs.tf
+├── providers.tf
+├── variables.tf
+└── versions.tf`}
+
+
+
+ A Terraform root module is a top-level module that specifies a state backend
+ and is typically the location where you would run Terraform commands.
+ Components are opinionated, self-contained, reusable blocks of Infrastructure-as-Code
+ designed to address specific problems or use cases.
+ These components are configured within one or more stacks.
+ We will thoroughly dive into Components with the Component Development handoff.
+
+
+
+{/* Slide 7: Modules */}
+
+ Modules
+
+
+
Any Terraform module that is called from another module
+
A child module does not have Terraform State
+
Called from Components
+
Cloud Posse open source modules live in our GitHub Org
+
+
+{`module "eks" {
+ source = "cloudposse/stack-config/yaml//modules/remote-state"
+ version = "1.3.1"
+
+ component = var.eks_component_name
+
+ context = module.this.context
+}`}
+
+
+
+ A module is a Terraform concept. Technically, they are called child modules,
+ but we'll frequently just refer to them as modules.
+ Modules are like packages that group multiple resources used together,
+ consisting of collections of Terraform files organized within a single source.
+ They can call other modules, and unlike terraform root modules or components,
+ they don't have state because they don't define provider configuration.
+ Cloud Posse maintains an open source collection of modules in our GitHub organization.
+
+
+
+{/* Slide 8: Conventions Section Title */}
+
+ Conventions
+
+ At Cloud Posse, we also have a few conventions that may be outside the industry norm.
+ When we refer to the following terms, this is what we mean.
+
+
+
+{/* Slide 9: Environment */}
+
+ Environment
+
+
+
+
Represents the shorthand notation of the AWS Region where resources are deployed
+
Either short or fixed notation
+
us-east-1 in short is use1
+
us-east-1 in fixed is ue1
+
Fixed is always 3 letters
+
Short is 3-4 letters typically
+
+
+
+{`# Short
+region: us-east-1
+environment: use1
+
+# Fixed
+region: us-east-1
+environment: ue1`}
+
+
+
+ The term "Environment" is frequently overloaded. At Cloud Posse, an Environment is the
+ location where resources are deployed. In most cases this is an AWS region.
+ Specifically, an environment uses the shorthand notation for a region.
+ For example, if the region is US east 1, then the environment is "USE1" or "UE1".
+ We use either a "short" or "fixed" notation, but our default recommendation is to use "short" notation.
+ Short is easier to understand and is therefore preferred.
+
+
+
+{/* Slide 10: Stage */}
+
+ Stage
+
+
+
+
A classification for different life cycles in infrastructure management
+
In industry, usually referred to as environment
+
Examples: Dev, Staging, Prod, Auto
+
Grouped by tenant
+
+
+
+{`core: # Tenant (OU)
+ artifacts # Stage
+ audit # Stage
+ auto # Stage
+ dns # Stage
+ identity # Stage
+ network # Stage
+ root # Stage
+ security # Stage
+plat: # Tenant (OU)
+ dev # Stage
+ staging # Stage
+ prod # Stage
+ sandbox # Stage`}
+
+
+
+ A stage at Cloud Posse is a classification for different life cycles in infrastructure management,
+ such as the typical Development, Production, Staging, or QA.
+ But also stages like "audit" or "security".
+ It is recommended to allocate at least one account per stage to maintain clear boundaries and isolation.
+ In our industry, the term "Environment" frequently describes what Cloud Posse refers to as "Stage."
+ Furthermore, we group these stages by "tenant".
+
+
+
+{/* Slide 11: Tenant */}
+
+ Tenant
+
+
+
+
A tenant is a logical grouping of stages
+
Typically mirrors AWS Organizational Units (OUs)
+
We typically have 2: Core and Platform (plat)
+
Can have multiple Platform tenants with the same stages
+
+
+
+{`core: # Tenant
+ artifacts # Stage
+ audit # Stage
+ auto # Stage
+ dns # Stage
+ identity # Stage
+ network # Stage
+ root # Stage
+ security # Stage
+plat: # Tenant
+ dev # Stage
+ staging # Stage
+ prod # Stage
+ sandbox # Stage`}
+
+
+
+ A tenant consists of a logical group of stages. By convention, a tenant is almost always 1 to 1
+ with an AWS Organizational Unit, also referred to as an "OU".
+ With our reference architecture, we deploy 2 tenants: core and platform.
+ The core tenant includes all management accounts. These accounts are singletons and will never need to be duplicated.
+ The platform or "plat" tenant includes accounts related to your application platform, such as dev, staging, prod.
+ You may want to create multiple platform tenants, each with a new set of accounts if you want to isolate a new application platform.
+
+
+
+{/* Slide 12: Repository Layout Section Title */}
+
+ Repository Layout
+
+ Now let's go over the layout of your infrastructure repository itself.
+
+
+
+{/* Slide 13: Documentation */}
+
+ Documentation
+
+
Setup docs include how to get started with different layers of architecture
+
Component READMEs describe getting started with that individual component
+
+
+
+{`infrastructure/
+├── Makefile
+├── README.md
+├── components/
+│ ├── docker/
+│ └── terraform/*/README.md
+├── docs/
+│ ├── adr/
+│ └── setup/
+├── rootfs/
+└── stacks/`}
+
+
+
+ We include documentation in a number of places. The latest documentation for everything we do
+ at Cloud Posse is at "docs.cloudposse.com".
+ The first place to find a high level overview is the README.
+ We include all Architecture Design Records or "ADRs" under "docs/adr".
+ We also include some setup documentation with specific values used in your organization.
+ Finally, we have the READMEs for every component.
+
+
+
+{/* Slide 14: Terraform Configuration */}
+
+ Terraform Configuration
+
+
+
+
Terraform Configuration:components/terraform/ and stacks/
+
Components holds Terraform code
+
Stacks holds your Organization's configuration for your components
+
+
+
+{`infrastructure/
+├── Makefile
+├── README.md
+├── components/
+│ ├── docker/
+│ └── terraform/
+├── docs/
+├── rootfs/
+└── stacks/`}
+
+
+
+ Configuration for Terraform lives in two places. First, all Terraform code itself lives under
+ "components/terraform".
+ Each component in this directory is currently pulled from the upstream library of components
+ using vendoring, but you can create your own custom components as well.
+ The unique configuration for each component in your Organization lives under "stacks".
+ This approach ensures a clear separation of configuration from code, maximizing the reusability of components.
+
+
+
+{/* Slide 15: Stack Layout */}
+
+ Stack Layout
+
+
+
catalog defines baseline configurations for components
+
orgs defines all stacks to deploy
+
The orgs file structure mirrors your AWS account structure
+
Configurable via atmos.yaml
+
+
+{`infrastructure/stacks/
+├── catalog
+├── orgs
+│ └── acme
+│ ├── _defaults.yaml
+│ ├── core
+│ └── plat
+│ ├── _defaults.yaml
+│ ├── dev
+│ │ ├── _defaults.yaml
+│ │ ├── global-region
+│ │ │ ├── baseline.yaml
+│ │ │ └── identity.yaml
+│ │ └── us-east-2
+│ │ ├── baseline.yaml
+│ │ ├── ecs.yaml
+│ │ └── network.yaml
+│ ├── prod
+│ ├── sandbox
+│ └── staging`}
+
+
+
+ "Stacks" include the account architecture and the catalog of all components.
+ The Stack Catalog is used to define a component's default configuration for a specific organization.
+ Think of it as where to store the baseline configurations and establish best practices.
+ Then import a stack catalog into the stack manifest for a given account.
+ By importing the stack catalog into the stack file, you can deploy that component into the account
+ and add or override configuration that is unique to this account.
+
+
+
+{/* Slide 16: Toolset Section Title */}
+
+ Toolset
+
+ To get started developing, Cloud Posse has a few tools that we use across all engagements.
+
+
+
+{/* Slide 17: Atmos */}
+
+ Atmos
+
+
Simplify complex architectures with DRY configuration
+
Is and always will be FREE and Open Source
+
+
+ We recommend getting started by reviewing the official documentation for Atmos at "atmos.tools".
+ However, we will cover Atmos development with the Component Development handoff.
+
+
+
+{/* Slide 18: Atmos Workflows */}
+
+ Atmos Workflows
+
+
+
Workflows are a way of combining multiple commands into one executable unit of work
+
Supports Atmos commands and shell scripting
+
Automates running sequences of commands
+
Can call other workflows
+
+
+{`atmos workflow deploy/eks -s acme-ue1-dev
+
+workflows:
+ deploy/eks:
+ description: |
+ Deploy EKS
+ steps:
+ - command: terraform deploy vpc
+ - command: terraform deploy eks
+ - command: terraform deploy \\
+ eks/alb-controller`}
+
+
+
+ Workflows combine multiple commands into a single executable unit of work,
+ which we rely on heavily when deploying the initial infrastructure.
+ They are excellent for documenting the steps or process to bring up some infrastructure.
+ However, once deployed, usage of workflows may be less common.
+ Workflows are entirely optional and have zero impact on your ability to deploy components.
+
+
+
+{/* Slide 19: Atmos Vendoring */}
+
+ Atmos Vendoring
+
+
+
Allows keeping Components up to date with Cloud Posse latest reference architecture
+
Vendored in with simple command to pull Terraform files
+
Included GitHub Actions can create PRs to keep components up-to-date
+
+
+{`atmos vendor pull -c foobar
+
+components/terraform/foobar
+├── README.md
+├── component.yaml
+├── context.tf
+├── main.tf
+├── outputs.tf
+├── providers.tf
+├── remote-state.tf
+├── variables.tf
+└── versions.tf`}
+
+
+
+ Vendoring is what we refer to as the process of pulling in some version of a given component
+ from our upstream library of components.
+ We reuse the same components across all engagements, thereby ensuring reusability.
+ These are free and open source and also shared by the community.
+ The "component.yaml" file defines which upstream component and version to pull.
+ Separately, we include a GitHub action to regularly open Pull Requests whenever there is a new version available.
+
+
+
+{/* Slide 20: Geodesic */}
+
+ Geodesic
+
+
Universal DevOps toolbox
+
make all and make run
+
Docker Image with pre-installed toolset
+
Allows Customization
+
Simply an interactive shell
+
+
+
+
+
Host
+
Container
+
+
+
+
+
~/ ($HOME dir)
+
/localhost/
+
+
+
$PROJECT_ROOT/rootfs/
+
/
+
+
+
+
+ Geodesic is a universal toolbox distributed as a Docker image, and designed to solve the common
+ issue of "it works on my machine". When every developer uses Geodesic to plan and apply Terraform,
+ every developer has the same tools pre-installed.
+ Furthermore, Geodesic allows for customization. You can create unique aliases, commands,
+ and startup scripts either for your personal use or across your organization.
+
+
+
+{/* Slide 21: Running Geodesic */}
+
+ Running Geodesic: make all
+
+ Geodesic is simple to start and run.
+
+
+ You can build your Geodesic image locally now by cloning the infrastructure repository and running make all.
+
+
+ You can build your Geodesic image locally now by cloning the infrastructure repository
+ and running "make all". This will build and launch the container with all the tools you need.
+
+
+
+{/* Slide 22: References & Next Steps */}
+
+ References & Next Steps
+
+