chore: Replaced All Atlassian Links (#726)

milldr · web-flow · commit 9f07e32c8b82 · 2025-02-14T21:48:46.000-06:00
diff --git a/docs/layers/accounts/design-decisions/decide-on-aws-account-flavors-and-organizational-units.mdx b/docs/layers/accounts/design-decisions/decide-on-aws-account-flavors-and-organizational-units.mdx
@@ -246,7 +246,7 @@ It is advised to keep the names of accounts as short as possible because of reso
     <p>
       The “$tenant” account is a symbolic account representing dedicated account
       environment. It’s architecture will likely resemble prod. This relates to{" "}
-      <a href="https://cloudposse.atlassian.net/wiki/spaces/REFARCH/pages/1171718320">
+      <a href="/layers/accounts/design-decisions/decide-on-aws-account-flavors-and-organizational-units/">
         this link
       </a>
     </p>
diff --git a/docs/layers/accounts/design-decisions/decide-on-mfa-solution-for-aws-root-accounts.mdx b/docs/layers/accounts/design-decisions/decide-on-mfa-solution-for-aws-root-accounts.mdx
@@ -72,6 +72,4 @@ authenticate with **LastPass** using TOTP/Authenticator apps. That's not what we
 
 ## Related Tasks
 
-- [REFARCH-62 - Setup Root Account Root Credentials MFA](https://cloudposse.atlassian.net/browse/REFARCH-62)
-
-- [REFARCH-291 - Setup Child Accounts Master Credentials & MFA](https://cloudposse.atlassian.net/browse/REFARCH-291)
+- [REFARCH-62 - Setup Root Account Root Credentials MFA](/layers/accounts/prepare-aws-organization/#set-up-mfa-on-root-account)
diff --git a/docs/layers/accounts/tutorials/deprecated-cold-start-components.mdx b/docs/layers/accounts/tutorials/deprecated-cold-start-components.mdx
@@ -70,7 +70,6 @@ component.
 
 <Note>
 `sso` project must be completed so the identity providers exist. If identity providers are added or deleted,
-[https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=992116823](https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=992116823) must also be updated.
 </Note>
 
 Refer to the `full_account_map` you saved from `account-map` and copy the account ID (number) for the `identity` account
diff --git a/docs/layers/accounts/tutorials/how-to-create-superadmin-user.mdx b/docs/layers/accounts/tutorials/how-to-create-superadmin-user.mdx
@@ -11,13 +11,11 @@ import KeyPoints from '@site/src/components/KeyPoints';
 The `SuperAdmin` user is necessary for performing administrative functions that IAM roles cannot, ensuring secure and controlled access to the root account while minimizing risks. These are the step-by-step instructions for creating a `SuperAdmin` user in AWS, including setting permissions, enabling MFA, and securely storing credentials in 1Password.
 </Intro>
 
-[REFARCH-73 - Provision SuperAdmin User for Root Level IAM Management](https://cloudposse.atlassian.net/browse/REFARCH-73)
+[REFARCH-73 - Provision SuperAdmin User for Root Level IAM Management](/layers/accounts/prepare-aws-organization/#create-the-superadmin-iam-user)
 
 ### Prerequisites
 
-1. [REFARCH-31 - Provision 1Password with Shared Vault](https://cloudposse.atlassian.net/browse/REFARCH-31)
-
-2. [REFARCH-60 - Register Pristine AWS Root Account](https://cloudposse.atlassian.net/browse/REFARCH-60)
+[Follow the prerequisites steps in the How-to Get Started guide](/layers/project/#0-prerequisites)
 
 ## Basic Instructions
 
diff --git a/docs/layers/accounts/tutorials/how-to-register-pristine-aws-root-account.mdx b/docs/layers/accounts/tutorials/how-to-register-pristine-aws-root-account.mdx
@@ -11,15 +11,15 @@ import KeyPoints from '@site/src/components/KeyPoints';
 Step-by-step instructions for setting up a new AWS root account, including prerequisites such as deciding on an email address format, provisioning a shared 1Password vault, and gathering necessary contact and billing information.
 </Intro>
 
-[REFARCH-60 - Register Pristine AWS Root Account](https://cloudposse.atlassian.net/browse/REFARCH-60)
+[REFARCH-60 - Register Pristine AWS Root Account](/layers/accounts/tutorials/how-to-register-pristine-aws-root-account/)
 
 ### Prerequisites
 
-1. [REFARCH-51 - Decide on Email Address Format for AWS Accounts](https://cloudposse.atlassian.net/browse/REFARCH-51)
+1. [REFARCH-51 - Decide on Email Address Format for AWS Accounts](/layers/accounts/design-decisions/decide-on-email-address-format-for-aws-accounts/)
 
-2. [REFARCH-31 - Provision 1Password with Shared Vault](https://cloudposse.atlassian.net/browse/REFARCH-31)
+2. [REFARCH-31 - Provision 1Password with Shared Vault](/layers/project/design-decisions/decide-on-1password-strategy/)
 
-3. [REFARCH-471 - Decide on AWS Organization Strategy](https://cloudposse.atlassian.net/browse/REFARCH-471)
+3. [REFARCH-471 - Decide on AWS Organization Strategy](/layers/accounts/design-decisions/decide-on-aws-organization-strategy/)
 
 4. Company primary contact information
 
diff --git a/docs/layers/accounts/tutorials/manual-configuration.mdx b/docs/layers/accounts/tutorials/manual-configuration.mdx
@@ -593,7 +593,6 @@ Learn more about the [account-settings](/components/library/aws/account-settings
 
 GSuite integration requires collaboration between a GSuite administrator and a DevOps engineer with `root` account
 access. You should have previously installed the IdP metadata files and configured the
-[https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1384546305](https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1384546305)
 component in `gbl-identity.yaml` .
 
 In the Geodesic shell, execute the following commands:
@@ -623,9 +622,7 @@ fine-grained role delegation across the account hierarchy. This component was pr
 was renamed as part of refactoring to better convey how it should be used.
 
 **NOTE:** [aws-saml](/components/library/aws/aws-saml/) project must be completed so the identity providers exist. If
-identity providers are added or deleted,
-[https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1384382465](https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1384382465)
-must also be updated.
+identity providers are added or deleted.
 
 This component requires `SuperAdmin` role to run. Use `assume-role` (or `assume-role-saml` for SAML auth) to assume the
 role.
@@ -724,8 +721,7 @@ couple of steps.
 
 ### Provision `aws-team-roles` component
 
-The
-[https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1384480783](https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1384480783)
+The `aws-team-roles`
 component creates the delegated IAM roles in the member accounts allowing the `identity` account to assume roles into
 the member accounts.
 
diff --git a/docs/layers/alerting/design-decisions/decide-on-incident-ruleset.mdx b/docs/layers/alerting/design-decisions/decide-on-incident-ruleset.mdx
@@ -69,5 +69,3 @@ Tag based approach would mean any monitor that sends an alert with a tag `incide
 - [How to Implement Incident Management with OpsGenie](/layers/alerting/opsgenie/)
 
 - [How to Implement SRE with Datadog](/layers/monitoring/datadog)
-
-- [REFARCH-519 - Decide on Default Priority to Incident Mappings](https://cloudposse.atlassian.net/browse/REFARCH-519)
diff --git a/docs/layers/alerting/opsgenie/opsgenie.mdx b/docs/layers/alerting/opsgenie/opsgenie.mdx
@@ -1,7 +1,6 @@
 ---
 title: "How to Implement Incident Management with OpsGenie"
 sidebar_label: "OpsGenie"
-confluence: https://cloudposse.atlassian.net/wiki/spaces/REFARCH/pages/1192231154/How+to+Implement+Incident+Management+with+OpsGenie
 sidebar_position: 10
 description: Standardize incident management with clear escalations and response processes
 ---
diff --git a/docs/layers/data/design-decisions/decide-on-rds-technology-and-architecture.mdx b/docs/layers/data/design-decisions/decide-on-rds-technology-and-architecture.mdx
@@ -39,8 +39,6 @@ An RDS Aurora Cluster can be deployed into each VPC. The Aurora DB Cluster must
 
 For more information, see: [Creating a DB Cluster (Amazon Aurora)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.CreateInstance.html).
 
-[https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1184661505](https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1184661505)
-
 [https://aws.amazon.com/rds/aurora/faqs/](https://aws.amazon.com/rds/aurora/faqs/)
 
 :::caution
@@ -65,8 +63,6 @@ For more information, see: [Getting Started with Amazon Aurora Global Databases]
 > Major version upgrades can contain database changes that are not backward-compatible with previous versions of the database. This functionality can cause your existing applications to stop working correctly. As a result, Amazon Aurora doesn't apply major version upgrades automatically.
 > [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.PostgreSQL.html#USER_UpgradeDBInstance.PostgreSQL.MajorVersion](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.PostgreSQL.html#USER_UpgradeDBInstance.PostgreSQL.MajorVersion)A transit gateway connection will be required between all regions and accounts participating in the Global Database.
 
-[https://cloudposse.atlassian.net/wiki/spaces/REFARCH/pages/1175978124](/layers/data/design-decisions/decide-on-the-backup-aws-region-for-aurora-global-cluster)
-
 ### **Option 4:** Amazon Aurora Serverless
 
 Amazon Aurora is also offered as Aurora Serverless. This is an on-demand autoscaling configuration that scales automatically horizontally based on usage, and shuts down when it is not in use.
diff --git a/docs/layers/data/design-decisions/todo-decide-on-rds-instance-requirements.mdx b/docs/layers/data/design-decisions/todo-decide-on-rds-instance-requirements.mdx
@@ -19,7 +19,7 @@ import KeyPoints from "@site/src/components/KeyPoints";
 ## Considered Options
 
 :::caution
-RDS Global Databases are only compatible with RDS Aurora. See [https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1184661505](https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1184661505).
+RDS Global Databases are only compatible with RDS Aurora.
 :::
 
 ## References
diff --git a/docs/layers/identity/tutorials/leapp/leapp.mdx b/docs/layers/identity/tutorials/leapp/leapp.mdx
@@ -183,7 +183,6 @@ Setup some environment variables, use your `LEAPP_IDP_URL` and
 ```
 # your IDP URL by right clicking on the Google AWS icon and clicking "Copy Link"
 export LEAPP_IDP_URL="https://accounts.google.com/o/saml2/initsso?idpid=snip&spid=snip&forceauthn=false"
-# Customer environment variables from https://cloudposse.atlassian.net/wiki/spaces/CP/pages/920879105/How+to+Set+Up+Customer+AWS+Access+with+SAML
 export LEAPP_IDP_ARN="arn:aws:iam::1234567890:saml-provider/identity"
 export LEAPP_ROLE_ARN="arn:aws:iam::1234567890:role/identity"
 export LEAPP_PROFILE_NAME="my-identity-profile"
diff --git a/docs/layers/network/design-decisions/decide-on-service-discovery-domain.mdx b/docs/layers/network/design-decisions/decide-on-service-discovery-domain.mdx
@@ -57,7 +57,7 @@ the new accounts since they do not yet exist.
 When registering a new domain, we have the option of using Route53’s built-in registrar or using your existing
 registrar. Many enterprise-scale organizations use MarkMonitor to manage their domain portfolio. Our convention is to
 use the `dns` account (see
-[REFARCH-55 - Decide on AWS Account Flavors and Organizational Units](https://cloudposse.atlassian.net/browse/REFARCH-55))
+[REFARCH-55 - Decide on AWS Account Flavors and Organizational Units](https://docs.cloudposse.com/layers/accounts/design-decisions/decide-on-aws-account-flavors-and-organizational-units))
 as the registrar. Note, the AWS Route53 Registrar cannot be automated with terraform and ClickOps is still required for
 domain registration.
 
diff --git a/docs/layers/software-delivery/design-decisions/decide-on-branching-strategy.mdx b/docs/layers/software-delivery/design-decisions/decide-on-branching-strategy.mdx
@@ -1,7 +1,6 @@
 ---
 title: "Decide on Branching Strategy"
 sidebar_label: "Branching Strategy"
-confluence:
 sidebar_position: 100
 description: Branching strategies for your software delivery
 tags:
diff --git a/docs/learn/conventions.mdx b/docs/learn/conventions.mdx
@@ -261,7 +261,7 @@ Naming things is hard. We’ve made it easier by defining a programmatically con
 
 [https://github.com/cloudposse/terraform-null-label](https://github.com/cloudposse/terraform-null-label)
 
-Here’s video from our [https://cloudposse.atlassian.net/wiki/spaces/CP/pages/1170014234](https://cloudposse.atlassian.net/wiki/spaces/CP/pages/1170014234) where we talk about it.
+Here’s video where we talk about it.
 
 <ReactPlayer
     url='https://www.youtube.com/watch?v=V2b5F6jt6tQ'
diff --git a/docs/learn/maintenance/tutorials/how-to-document-a-new-design-decision.mdx b/docs/learn/maintenance/tutorials/how-to-document-a-new-design-decision.mdx
@@ -16,8 +16,6 @@ During the course of building and managing infrastructure, lots of decisions are
 
 Design Decisions are anything we need to confirm architecturally or strategically before performing the implementation. They should include as much context as possible about what options are considered or ruled out. As part of this process, we’ll want to ask the right questions so we gather the necessary requirements for implementation. Once a decision is made, an should be written to capture the decision. Learn [How to write ADRs](/learn/maintenance/tutorials/how-to-write-adrs).
 
-Design Decision should be created in the [Reference Architecture project](https://cloudposse.atlassian.net/jira/software/c/projects/REFARCH/boards/24/roadmap) in Jira and have the context defined in the Reference Architecture space in Confluence. There’s a specific way to do this so that the interlinking works appropriately. What follows are the instructions for how to do that.
-
 ## Process
 
 1. **Identify the layer that the Design Decision is associated with.**
@@ -43,13 +41,7 @@ Design Decision should be created in the [Reference Architecture project](https:
 
       ```
 
-3. The result should look like this:
-    <img src="/assets/refarch/cleanshot-2021-10-13-at-11.55.47@2x-20211013-165605.png" /><br/>
-
-3. **After hitting “Save” you should see something that looks like this:**
-   <img src="/assets/refarch/cleanshot-2021-10-13-at-12.00.51@2x-20211013-170108.png" /><br/>
-
-4. **Clicking on the title will take you to the confluence page. Add all the context there.**
+1. Store this document with the other Design Decisions in your repository, typically under `docs/adrs/`.
 
 ### Step 2: Create a Document
 
diff --git a/docs/learn/maintenance/tutorials/how-to-write-adrs.mdx b/docs/learn/maintenance/tutorials/how-to-write-adrs.mdx
@@ -80,7 +80,7 @@ If using `prettier` in `.pre-commit.yaml` then add the toc to the file exclusion
 
 ### What is the Source of Truth
 
-The source of truth for ADRs is primarily the corresponding Design Decisions. We can also borrow from our ADRs to our repo [https://github.com/cloudposse/adr](https://github.com/cloudposse/adr) and the Design Decisions context from our Reference Architecture confluence.
+The source of truth for ADRs is primarily the corresponding Design Decisions. We can also borrow from our ADRs to our repo [https://github.com/cloudposse/adr](https://github.com/cloudposse/adr) and the Design Decisions context from our Reference Architecture.
 
 ### Why do we use a sequential numbering system?
 
diff --git a/docs/resources/adrs/adopted/use-aws-region-codes.mdx b/docs/resources/adrs/adopted/use-aws-region-codes.mdx
@@ -8,7 +8,7 @@ import KeyPoints from '@site/src/components/KeyPoints';
 
 ## Problem
 
-The AWS Public Cloud spans **25 geographic regions** around the world, with announced plans for 8 more AWS Regions in Australia, India, Indonesia, Israel, New Zealand, Spain, Switzerland, and United Arab Emirates (UAE). Regions play a big factor in naming conventions for multi-region infrastructures for disambiguation and resource residency. See [Decide on Regional Naming Scheme](/layers/project/design-decisions/decide-on-regional-naming-scheme), [https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1176010884](https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1176010884), [Decide on Namespace Abbreviation](/layers/project/design-decisions/decide-on-namespace-abbreviation) for context. Our [Terraform](/resources/legacy/fundamentals/terraform) is used to define programmatically consistent resource names with deterministic fields separated by a common delimiter (typically `-`), including a field for region (which we call `environment`). Since the AWS regions include a `-`, we do not want our region code to include it. Additionally, many AWS resource names are restricted to 32 or 64 characters making it all the more important to conserve characters for disambiguation of resource names.
+The AWS Public Cloud spans **25 geographic regions** around the world, with announced plans for 8 more AWS Regions in Australia, India, Indonesia, Israel, New Zealand, Spain, Switzerland, and United Arab Emirates (UAE). Regions play a big factor in naming conventions for multi-region infrastructures for disambiguation and resource residency. See [Decide on Regional Naming Scheme](/layers/project/design-decisions/decide-on-regional-naming-scheme), [Decide on Namespace Abbreviation](/layers/project/design-decisions/decide-on-namespace-abbreviation) for context. Our [Terraform](/resources/legacy/fundamentals/terraform) is used to define programmatically consistent resource names with deterministic fields separated by a common delimiter (typically `-`), including a field for region (which we call `environment`). Since the AWS regions include a `-`, we do not want our region code to include it. Additionally, many AWS resource names are restricted to 32 or 64 characters making it all the more important to conserve characters for disambiguation of resource names.
 
 <img src="/assets/refarch/cleanshot-2021-11-04-at-23.01.23@2x-20211105-040142.png" /><br/>
 
diff --git a/docs/resources/adrs/adopted/use-ssm-over-asm-for-infrastructure.mdx b/docs/resources/adrs/adopted/use-ssm-over-asm-for-infrastructure.mdx
@@ -93,6 +93,6 @@ After ASM was built, SSM was enhanced to provide similar capabilities, although
 
 - [Use Environment Variables for Configuration (12 Factor)](/resources/adrs/adopted/use-environment-variables-for-configuration-12-factor)
 
-- [REFARCH-210 - Decide Whether to Use RDS IAM Authentication](https://cloudposse.atlassian.net/browse/REFARCH-210)
+- [REFARCH-210 - Decide Whether to Use RDS IAM Authentication](/layers/data/design-decisions/decide-whether-to-use-rds-iam-authentication/)
 
 
diff --git a/docs/resources/legacy/code-of-conduct.mdx b/docs/resources/legacy/code-of-conduct.mdx
@@ -1,6 +1,5 @@
 ---
 title: "Code of Conduct"
-confluence: https://cloudposse.atlassian.net/wiki/spaces/REFARCH/pages/1176076927/Code+of+Conduct
 sidebar_position: 100
 ---
 
diff --git a/docs/resources/legacy/design-decisions/decide-on-cloudfront-requirements.mdx b/docs/resources/legacy/design-decisions/decide-on-cloudfront-requirements.mdx
@@ -67,9 +67,10 @@ If you intend to also serve static assets behind a CDN, see _Option 2._
 
 ### Option 2: Origin Acceleration for Static Assets in S3 (e.g. Images, CSS)
 
-The most common pattern we deploy is supporting [https://cloudposse.atlassian.net/wiki/spaces/CP/pages/1225752577](https://cloudposse.atlassian.net/wiki/spaces/CP/pages/1225752577). We’ll need to know if this is a pattern you intend to utilize, as it has an impact on the strategies for CI/CD. Each strategy will at a minimum require a different terraform component.
+The most common pattern we deploy is supporting [`aws-spa-s3-cloudfront`](https://github.com/cloudposse-terraform-components/aws-spa-s3-cloudfront). We’ll need to know if this is a pattern you intend to utilize, as it has an impact on the strategies for CI/CD. Each strategy will at a minimum require a different terraform component.
 
 :::caution
+
 If you intend to serve static assets behind a CDN, this is the only advisable way of doing it. Rolling updates associated with deployments to Kubernetes or ECS means that serving static assets from your application servers will likely yield inconsistent results during deployments.
 
 :::
diff --git a/docs/resources/legacy/fundamentals/leapp.mdx b/docs/resources/legacy/fundamentals/leapp.mdx
@@ -13,6 +13,4 @@ Leapp is a Desktop Dev Tool that handles the management and security of your clo
 
 ### Reference
 
-- [https://cloudposse.atlassian.net/l/c/YUPa00cx](https://cloudposse.atlassian.net/l/c/YUPa00cx)  ... existing AWS role settings.
-
-
+- [How to Log into AWS](https://docs.cloudposse.com/layers/identity/how-to-log-into-aws/)
diff --git a/docs/resources/legacy/fundamentals/terraform.mdx b/docs/resources/legacy/fundamentals/terraform.mdx
@@ -67,7 +67,7 @@ Naming things is hard. We’ve made it easier by defining a programmatically con
 
 [https://github.com/cloudposse/terraform-null-label](https://github.com/cloudposse/terraform-null-label)
 
-Here’s video from our [https://cloudposse.atlassian.net/wiki/spaces/CP/pages/1170014234](https://cloudposse.atlassian.net/wiki/spaces/CP/pages/1170014234) where we talk about it.
+Here’s video where we talk about it.
 
 <ReactPlayer
     url='https://www.youtube.com/watch?v=V2b5F6jt6tQ'
diff --git a/docs/resources/legacy/helm.mdx b/docs/resources/legacy/helm.mdx
@@ -109,8 +109,6 @@ Usage of the `helmfile` provider is primarily advised for customers with a sizab
 ### ArgoCD
 TL;DR: Even if you use ArgoCD, you’ll still need something that manages ArgoCD itself, any integrations with other kubernetes clusters, GitHub, and your IdP. For this reason we deploy ArgoCD with terraform and your apps _optionally_ with ArgoCD.
 
-See [https://cloudposse.atlassian.net/wiki/spaces/CP/pages/1168113701](https://cloudposse.atlassian.net/wiki/spaces/CP/pages/1168113701)
-
 ## Learning Resources
 - [https://helm.sh/docs/learn/quickstart/](https://helm.sh/docs/learn/quickstart/)
 
