update titles and sidebar lables. swizzle doccard components

docs/layers/accounts/accounts.mdx

@@ -8,12 +8,12 @@ import KeyPoints from '@site/src/components/KeyPoints';
 import ReactPlayer from "react-player";
 
 <Intro>
-This chapter presents how Cloud Posse designs and managed AWS Account architectures. We will explain how Cloud Posse provisions and manages AWS Accounts, the reasoning behind our decisions, and how this architecture will better align your organization with the [AWS Well-Architected Framework](https://docs.aws.amazon.com/pdfs/wellarchitected/latest/userguide/wellarchitected-ug.pdf)
+This chapter presents how Cloud Posse designs and manages AWS Account architectures. We will explain how Cloud Posse provisions and manages AWS Accounts, the reasoning behind our decisions, and how this architecture will better align your organization with the [AWS Well-Architected Framework](https://docs.aws.amazon.com/pdfs/wellarchitected/latest/userguide/wellarchitected-ug.pdf)
 </Intro>
 
 <KeyPoints>
-- Why to leverage multiple AWS accounts within an AWS Organization to ensure IAM-level isolation and to align with the AWS Well-Architected Framework, but without using AWS Control Tower
-- How we organize accounts into organizational units (OUs) to manage access and apply Service Control Policies (SCPs) to provide guard rails, ensuring proper segmentation and isolation of workloads across different environments such as core, platform, and sandbox accounts.
+- Why to leverage multiple AWS accounts within an AWS Organization
+- How we organize accounts into organizational units (OUs) to manage access and apply Service Control Policies (SCPs) to provide guard rails
 - The set of components we use to provision, configure, and manage AWS accounts, including account-level settings, service control policies, and Terraform state backends, using native Terraform with Atmos
 </KeyPoints>
 

docs/layers/accounts/design-decisions/decide-on-aws-account-flavors-and-organizational-units.mdx

@@ -1,6 +1,7 @@
 ---
 title: "Decide on AWS Account Flavors and Organizational Units"
 sidebar_label: "AWS Account Flavors and OUs"
+description: "Decide how to organize workloads for isolation and management"
 refarch_id: REFARCH-55
 ---
 import Intro from '@site/src/components/Intro';

docs/layers/accounts/design-decisions/decide-on-aws-organization-strategy.mdx

@@ -1,6 +1,7 @@
 ---
 title: "Decide on AWS Organization Strategy"
 sidebar_label: "AWS Organization Strategy"
+description: Decide whether to create or reuse AWS Organizations
 refarch_id: REFARCH-471
 ---
 import Intro from '@site/src/components/Intro';

docs/layers/accounts/design-decisions/decide-on-aws-support.mdx

@@ -1,15 +1,16 @@
 ---
 title: "Decide on AWS Support"
 sidebar_label: "AWS Support"
+description: "Decide which accounts need AWS Support"
 refarch_id: REFARCH-417
 ---
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
 
-# Decide on AWS Support
-
+<Intro>
 AWS Support is always enabled on a per-account basis. With an AWS Enterprise Agreement, AWS support is already included
 from a billing perspective for all accounts, but it still needs to be enabled on a per-account basis.
+</Intro>
 
 :::caution
 

docs/layers/accounts/design-decisions/decide-on-email-address-format-for-aws-accounts.mdx

@@ -1,6 +1,7 @@
 ---
 title: "Decide on Email Address Format for AWS Accounts"
 sidebar_label: "Email Address Format for AWS Accounts"
+description: "Decide what emails will be used for AWS Accounts"
 refarch_id: REFARCH-51
 ---
 import Intro from '@site/src/components/Intro';

docs/layers/accounts/design-decisions/decide-on-mfa-solution-for-aws-root-accounts.mdx

@@ -1,6 +1,7 @@
 ---
 title: "Decide on MFA Solution for AWS Root Accounts"
 sidebar_label: "MFA Solution for AWS Root Accounts"
+description: "Decide on MFA Solution for AWS Root Accounts"
 refarch_id: REFARCH-50
 ---
 import Intro from '@site/src/components/Intro';

docs/layers/accounts/design-decisions/decide-on-terraform-state-backend-architecture.mdx

@@ -1,6 +1,7 @@
 ---
 title: "Decide on Terraform State Backend Architecture"
 sidebar_label: "Terraform State Backend Architecture"
+description: Decide how to organize Terraform State across accounts
 refarch_id: REFARCH-522
 ---
 import Intro from '@site/src/components/Intro';

docs/layers/application-cicd/application-cicd.mdx

@@ -1,9 +1,9 @@
 ---
 title: "Quick Start"
 sidebar_label: "Quick Start"
-description: "Get started with Cloud Posse's Release Engineering."
 sidebar_position: 0
 sidebar_class_name: hidden
+description: "Get started with Cloud Posse's Release Engineering."
 ---
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
@@ -16,9 +16,10 @@ For more, see [What is DevOps](https://aws.amazon.com/devops/what-is-devops/).
 
 :::
 
-
-
-<ReactPlayer controls url='https://docs.cloudposse.com/assets/refarch/handoffs/release-engineering.mp4' />
+<figure>
+  <ReactPlayer controls url='https://docs.cloudposse.com/assets/refarch/handoffs/release-engineering.mp4' />
+  <figcaption>AI generated voice</figcaption>
+</figure>
 
 ## The Problem
 

docs/layers/application-cicd/design-decisions/decide-on-strategy-for-preview-environments-e-g-review-apps.mdx

@@ -7,8 +7,6 @@ refarch_id: REFARCH-425
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
 
-# Decide on Strategy for Preview Environments (e.g. Review Apps)
-
 ## Considerations
 
 - Use as few AWS proprietary services (E.g DynamoDB, SNS, SQS) because provisioning terraform for ephemeral environments is very slow, complicated and therefore not recommended

docs/layers/application-cicd/design-decisions/decide-on-terraform-configuration-pattern-for-application-reposi.mdx

@@ -7,8 +7,6 @@ refarch_id: REFARCH-514
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
 
-# Decide on Terraform Configuration Pattern for Application Repositories
-
 ## Context and Problem Statement
 
 The infrastructure monorepo that exists within an organization is responsible for configuring the core infrastructure of the organization: AWS accounts, VPCs, Kubernetes clusters, Route53, etc. However, AWS resources and/or other dependencies specific to a single application — such as a single S3 bucket — is not in the scope of the infrastructure monorepo, and should be managed externally, such that developers responsible for the application in question can manage its dependencies via infrastructure-as-code.

docs/layers/application-cicd/dockerized-ecs-ecspresso/06-ecspresso.mdx

@@ -5,10 +5,7 @@ sidebar_label: Ecspresso
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
 
-# Ecspresso
-
-This setup guide will help you get started with [ecspresso](https://github.com/kayac/ecspresso). It features an example
-app, which demonstrates how your GitHub Actions work with your infrastructure repository.
+This setup guide will help you get started with [ecspresso](https://github.com/kayac/ecspresso). It features an example app, which demonstrates how your GitHub Actions work with your infrastructure repository.
 
 :::caution Default Workflows Placement
 

docs/layers/bonus-tutorials/bonus-tutorials.mdx

@@ -1,5 +1,6 @@
 ---
 title: "How-to Guides"
+description: Tutorials with easy-to-follow steps.
 sidebar_class_name: hidden
 ---
 import Intro from '@site/src/components/Intro'

docs/layers/bonus-tutorials/design-decisions/archived-decisions/archived-decisions.mdx

@@ -1,6 +1,7 @@
 ---
 title: "Archived Decisions"
-confluence: https://cloudposse.atlassian.net/wiki/spaces/REFARCH/pages/1184432667/Archived+Decisions
+sidebar_label: "Archived Decisions"
+description: "These Design Decisions have been superseded and are no longer used."
 sidebar_position: 10
 ---
 

docs/layers/bonus-tutorials/design-decisions/archived-decisions/decide-on-rds-requirements.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Decide on RDS requirements"
-confluence: https://cloudposse.atlassian.net/wiki/spaces/REFARCH/pages/1173520412/REFARCH-363+-+Decide+on+RDS+requirements
+sidebar_label: "RDS Requirements"
 sidebar_position: 100
 refarch_id: REFARCH-363
 ---

docs/layers/bonus-tutorials/design-decisions/archived-decisions/decide-on-status-page-requirements.mdx

@@ -1,14 +1,14 @@
 ---
 title: "Decide on Status Page Requirements"
-confluence: https://cloudposse.atlassian.net/wiki/spaces/REFARCH/pages/1171947803/REFARCH-467+-+Decide+on+Status+Page+Requirements
+sidebar_label: "Status Page Requirements"
 sidebar_position: 100
 refarch_id: REFARCH-467
 ---
 
 # Decide on Status Page Requirements
 
 ## Problem
-The business may be obligated or want to communicate transparently to customers' the availability of all services affecting the platforms/products stability.
+The business may be obligated or want to communicate transparently to customers the availability of all services affecting the platforms/products stability.
 
 ## Solution
 Use [StatusPage.io](http://StatusPage.io) by Atlassian to integrate with OpsGenie and other dependent services to communicate overall availability.

docs/layers/bonus-tutorials/design-decisions/decide-on-api-gateway-requirements.mdx

@@ -1,16 +1,16 @@
 ---
 title: "Decide on API Gateway Requirements"
+sidebar_label: "API Gateway"
 sidebar_position: 100
 refarch_id: REFARCH-540
 ---
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
 
-# Decide on API Gateway Requirements
-
 ## Context and Problem Statement
 
 ## Overview
+
 Amazon API Gateway is an AWS service designed to simplify publishing highly-scalable REST, HTTP, and WebSocket APIs. These API Gateways act as a central point of access at the edge and can access backend services running on EC2, EKS, ECS, Lambda, and AWS Services directly, such as DynamoDB, S3, or SQS. The API Gateway has several benefits over a conventional ALB in that it’s optimized for APIs: namely, it can authenticate requests, cache, rate-limiting, feature flagging, a/b testing, rewrite requests/responses, aggregate requests, etc. It’s arguably a simpler alternative to using something like a Service Mesh.
 
 ## Common Scenarios

docs/layers/bonus-tutorials/design-decisions/decide-on-cloudfront-requirements.mdx

@@ -1,14 +1,14 @@
 ---
 title: "Decide on CloudFront Requirements"
+sidebar_label: "CloudFront Requirements"
 sidebar_position: 100
 refarch_id: REFARCH-530
 ---
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
 
-# Decide on CloudFront Requirements
-
 ## Context and Problem Statement
+
 A CDN such as CloudFront speeds up the user experience primarily in 2 ways.
 
 1. **Caching.** By caching content on a server closer to the user (called the “edge server”), the user can benefit from the much shorter connection path to the nearby server, obtaining responses much more quickly.

docs/layers/bonus-tutorials/design-decisions/decide-on-cognito-requirements.mdx

@@ -1,19 +1,20 @@
 ---
 title: "Decide on Cognito Requirements"
+sidebar_label: "Cognito Requirements"
 sidebar_position: 100
 refarch_id: REFARCH-525
 ---
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
 
-# Decide on Cognito Requirements
-
 ## Overview
+
 Amazon Cognito provides authentication, authorization, and user management for your web and mobile apps. Users can sign in directly with a user name and password stored in Cognito or through a third party such as a SAML IdP, OIDC, Facebook, Amazon, Google, or Apple.
 
 There are two main components to Amazon Cognito: User Pools and Identity Pools. User Pools are directories of your applications’ users while Identity Pools are used to grant application users access to other AWS services such as S3. User Pools and Identity Pools can be used together or separately, depending on your needs.
 
 ## Common Scenarios
+
 There are several common use cases for Cognito, some of the most common of which are detailed below. To configure the Cognito component, we’ll need to know as much as possible about your configuration. Ideally, you’ve already set it up previously and can share the precise configuration you’re using.
 
 ### App Authentication and Authorization

docs/layers/bonus-tutorials/design-decisions/decide-on-iam-roles-for-github-action-runners.mdx

@@ -1,14 +1,14 @@
 ---
 title: "Decide on IAM Roles for GitHub Action Runners"
+sidebar_label: "IAM Roles for GitHub Action Runners"
 sidebar_position: 100
 refarch_id: REFARCH-305
 ---
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
 
-# Decide on IAM Roles for GitHub Action Runners
-
 ## Problem
+
 In order for GitHub Actions runners to be able to access AWS resources, they need to be able to assume an IAM role.
 The trust relationship of this IAM role depends on how the Runners are hosted:
 

docs/layers/bonus-tutorials/design-decisions/decide-on-kinesis-requirements.mdx

@@ -1,18 +1,18 @@
 ---
 title: "Decide on Kinesis Requirements"
+sidebar_label: "Kinesis Requirements"
 sidebar_position: 100
 refarch_id: REFARCH-527
 ---
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
 
-# Decide on Kinesis Requirements
-
 ## Context and Problem Statement
 
 Amazon Kinesis collects, processes, and analyzes real-time, streaming data to get timely insights and react quickly to new information. It provides key capabilities to cost-effectively process streaming data at any scale, along with the flexibility to choose the tools that best suit the requirements of your application. Frequently, it’s used to ingest real-time data such as video, audio, application logs, website clickstreams, and IoT telemetry data for machine learning, analytics, and other applications. With Kinesis, information can be acted on as soon as it arrives, so apps can respond instantly instead of waiting until all data is collected before processing.
 
 ## Considered Options
+
 Kinesis has 4 major use-cases: streaming, firehose, analytics, and video. We have experience working with streams and firehose, but not the newer analytics and video offerings.
 
 **AWS Kinesis Data Streams** is for real-time data streaming. It can continuously capture gigabyte-scale data every second from multiple sources. It’s basically Amazon’s proprietary alternative to Kafka.

docs/layers/bonus-tutorials/design-decisions/decide-on-kms-requirements.mdx

@@ -1,15 +1,16 @@
 ---
 title: "Decide on KMS Requirements"
+sidebar_label: "KMS Requirements"
 sidebar_position: 100
 refarch_id: REFARCH-532
 ---
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
 
-# Decide on KMS Requirements
 AWS Key Management Service (AWS KMS) makes it easy to create and manage cryptographic keys and control their use across various AWS services and in your applications. AWS KMS is a secure and resilient service that uses hardware security modules that have been validated under FIPS 140-2, or are in the process of being validated, to protect your keys. AWS KMS is integrated with AWS CloudTrail to provide you with logs of all key usage to help meet your regulatory and compliance needs.
 
 ## Context and Problem Statement
+
 Best practice, security certifications, and compliance regulations require that data be “encrypted at rest.” AWS provides options for encrypting data at rest virtually anywhere AWS provides for data storage. However, there remain considerations regarding managing the encryption _keys_ for the encrypted data.
 
 Consideration should begin with a review of governmental, industry, and corporate compliance requirements, standards, and goals regarding encryption at rest, auditability, data localization, data preservation and recovery, high availability, and disaster recovery. Cloud Posse does not provide advice on compliance requirements, it is up to the client to determine their own needs. For example, here is AWS' approach to HIPAA compliance, summarized:

docs/layers/bonus-tutorials/design-decisions/decide-on-transactional-email-smtp-provider-for-operational-email.mdx

@@ -1,19 +1,20 @@
 ---
 title: "Decide on Transactional Email (SMTP) Provider for Operational Emails"
+sidebar_label: "Transactional Email (SMTP) Provider"
 sidebar_position: 100
 refarch_id: REFARCH-79
 ---
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
 
-# Decide on Transactional Email (SMTP) Provider for Operational Emails
-
 ## Problem
+
 We’ll want to have an SMTP email gateway that’s used by services like Alert Manager, Sentry, Printunl, et al to send emails.
 
 ## Considered Options
 
 #### AWS SES
+
 Our recommended option is to provision an SES gateway using our [https://github.com/cloudposse/terraform-aws-ses](https://github.com/cloudposse/terraform-aws-ses) module for this.
 
 It’s also worth noting is that every AWS SES starts in Sandbox. Sending emails via it (emails not verified in AWS SES) is only allowed after support requests (so requires some human intervention to automate).
@@ -39,9 +40,11 @@ SES is also only available in the following regions:
 This will use the vanity branded domain in [Decide on Vanity (Branded) Domain](/reference-architecture/fundamentals/design-decisions/foundational-platform/decide-on-vanity-branded-domain) if SES is used for customer-facing emails. If these are for internal domains then we can use the service discovery domains.
 
 #### Mailgun
+
 The other option we typically recommend is mailgun. It’s very economical and easy to integrate with. There’s also a terraform provider for managing mailgun configurations.
 
 #### Bring-your-own
+
 We’ll happily integrate with whatever SMTP system your company uses today.
 
 :::caution

docs/layers/bonus-tutorials/design-decisions/design-decisions.mdx

@@ -1,46 +1,26 @@
 ---
 title: "Design Decisions"
+sidebar_label: "Design Decisions"
 sidebar_position: 200
 ---
 import Intro from '@site/src/components/Intro';
 import KeyPoints from '@site/src/components/KeyPoints';
+import DocCardList from '@theme/DocCardList'
 
-# Design Decisions
-Design Decisions are architectural considerations for how to approach or implement some sort of functionality. Each Design Decision references the corresponding REFARCH ticket in jira. The decision outcomes should be documented as Architectural Design Records (ADRs).
+<Intro>
+Design Decisions are architectural considerations for how to approach or implement some sort of functionality. The decision outcomes should be documented as Architectural Design Records (ADRs).
+</Intro>
 
-See [https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1173454868](https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1173454868) for adding design decisions to this reference architecture as well as [How to write ADRs](/reference-architecture/how-to-guides/tutorials/how-to-write-adrs) .
+See [how to document a new design decision](/layers/bonus-tutorials/how-to-document-a-new-design-decision) to this reference architecture as well as [How to write ADRs](/reference-architecture/how-to-guides/tutorials/how-to-write-adrs) .
 
 :::note
 This is our entire reference catalog of Design Decisions and not all may be relevant to the scope of a particular engagement.
 
 :::
 
-## Recently Updated
-
 ## All Decisions
 
 They are broken down in the following way:
 
-- [Cold Start](/reference-architecture/fundamentals/design-decisions/cold-start)
-- [Foundational Infrastructure](/reference-architecture/fundamentals/design-decisions/foundational-infrastructure)
-- [Foundational Platform](/reference-architecture/fundamentals/design-decisions/foundational-platform)
-- [Foundational Monitoring Platform](/reference-architecture/fundamentals/design-decisions/foundational-monitoring-platform)
-- [Foundational Release Engineering](/reference-architecture/fundamentals/design-decisions/foundational-release-engineering)
-- [Foundational Incident Management](/reference-architecture/fundamentals/design-decisions/foundational-incident-management)
-- [Foundational Benchmark Compliance](/reference-architecture/fundamentals/design-decisions/foundational-benchmark-compliance)
-- [Foundational Application Dependencies](/reference-architecture/fundamentals/design-decisions/foundational-application-dependencies)
-- [Archived Decisions](/reference-architecture/fundamentals/design-decisions/archived-decisions)
-- [Decide on Datadog Log Forwarding Requirements](/reference-architecture/fundamentals/design-decisions/decide-on-datadog-log-forwarding-requirements)
-- [Decide on Terraform State Backend Architecture](/reference-architecture/fundamentals/design-decisions/decide-on-terraform-state-backend-architecture)
-- [Decide on Cognito Requirements](/reference-architecture/fundamentals/design-decisions/decide-on-cognito-requirements)
-- [Decide on Kinesis Requirements](/reference-architecture/fundamentals/design-decisions/decide-on-kinesis-requirements)
-- [Decide on CloudFront Requirements](/reference-architecture/fundamentals/design-decisions/decide-on-cloudfront-requirements)
-- [Decide on KMS Requirements](/reference-architecture/fundamentals/design-decisions/decide-on-kms-requirements)
-- [Decide on Strategy for Continuous Deployment](/reference-architecture/fundamentals/design-decisions/decide-on-strategy-for-continuous-deployment)
-- [Decide on CI/CD Platform](/reference-architecture/fundamentals/design-decisions/decide-on-ci-cd-platform)
-- [Decide on Strategy for Managing and Orchestrating Secrets](/reference-architecture/fundamentals/design-decisions/decide-on-strategy-for-managing-and-orchestrating-secrets)
-- [Decide on API Gateway Requirements](/reference-architecture/fundamentals/design-decisions/decide-on-api-gateway-requirements)
-- [Decide on IPv4 and IPv6 support](/reference-architecture/fundamentals/design-decisions/decide-on-ipv4-and-ipv6-support)
-- [Decide on IAM Roles for GitHub Action Runners](/reference-architecture/fundamentals/design-decisions/decide-on-iam-roles-for-github-action-runners)
-
+<DocCardList/>