Fixed broken links

content/blog/adopting-existing-cloud-resources-into-pulumi/index.md

@@ -36,7 +36,7 @@ We'll review referencing existing resources, and then dive deeper into how you c
 For referencing existing resources, Pulumi offers several tools.
 
 * The `.get` methods available on every resource let you [get all the details for a resource]({{< relref "/docs/reference/pkg/aws/ec2/vpc#look-up" >}}) from the cloud provider based just on its `id`.
-* The `StackReference` resource lets you reference outputs of another stack for use as inputs to a stack, which is very useful for [organizing projects and stacks]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}).
+* The `StackReference` resource lets you reference outputs of another stack for use as inputs to a stack, which is very useful for [organizing projects and stacks]({{< relref "/docs/guides/organizing-projects-stacks" >}}).
 * [`terraform.state.RemoteStateReference()`]({{< relref "/blog/using-terraform-remote-state-with-pulumi" >}}), [`aws.cloudformation.getStack()`]({{< relref "/docs/reference/pkg/aws/cloudformation/getstack" >}}) and [`azure.core.TemplateDeployment.get()`]({{< relref "/docs/reference/pkg/azure/core/templatedeployment#look-up" >}}) let you reference outputs from existing Terraform, CloudFormation and ARM deployments respectively.
 
 Together, these make it easy to reference existing infrastructure regardless of how it was provisioned.

content/blog/architect-aws-application-infra-with-pulumi-stack-references/index.md

@@ -37,7 +37,7 @@ $ tree -d -L 1
 ```
 
 This means all of the work required for the networking components can be in the network project. We can use
-[Stack References]({{< relref "/docs/intro/concepts/organizing-stacks-projects#inter-stack-dependencies" >}}) in Pulumi
+[Stack References]({{< relref "/docs/intro/concepts/stack#stackreferences" >}}) in Pulumi
 to expose any required information from the networking layer, to the database and application layers.
 
 Let's create the networking project.

content/blog/architecture-as-code-microservices/index.md

@@ -27,7 +27,7 @@ Pulumi is organized around [Projects]({{< relref "/docs/intro/concepts/project"
 
 Monolithic stacks are a common way to structure a project. A single project defines the infrastructure and resources for an entire service. However, Pulumi also supports deploying microservices as individual stacks within a project. Because microservices represent a specific business capability, having stacks for each service allows teams to work independently of each other. Separate stacks can enforce security policies through Role-Based Access Control, and each service can be built and deployed independently of other components.
 
-Microservices deployed as stacks communicate with each other through the [StackReference]({{< relref "/docs/intro/concepts/organizing-stacks-projects#inter-stack-dependencies" >}}) resource, which makes stack exports such as networking, environmental variables, and even Kubernetes configuration available to stacks in the project. The `StackReference` constructor takes as input a string of the form `<organization>/<project>/<stack>`, and lets services access the outputs of that stack. The following section walks through a microservices example that deploys a database on AWS RDS, a REST application in AWS Fargate, and an AWS Application Load Balancer.
+Microservices deployed as stacks communicate with each other through the [StackReference]({{< relref "/docs/intro/concepts/stack#stackreferences" >}}) resource, which makes stack exports such as networking, environmental variables, and even Kubernetes configuration available to stacks in the project. The `StackReference` constructor takes as input a string of the form `<organization>/<project>/<stack>`, and lets services access the outputs of that stack. The following section walks through a microservices example that deploys a database on AWS RDS, a REST application in AWS Fargate, and an AWS Application Load Balancer.
 
 ## A Microservices Application Infrastructure
 

content/blog/build-publish-containers-iac/index.md

@@ -1873,7 +1873,7 @@ Also note the base and versioned image URLs are exported as stack outputs. These
 
 1. As we see here, the CLI will print them after each deployment.
 2. The CLI can fetch them on-demand, e.g., 'pulumi stack output fullImageName', making it easy to script access to these container images.
-3. The [Pulumi `StackReference` component]({{< relref "/docs/intro/concepts/organizing-stacks-projects#inter-stack-dependencies" >}}) can be used to depend on this stack from another, allowing us to build higher levels of infrastructure that consume these images.
+3. The [Pulumi `StackReference` component]({{< relref "/docs/intro/concepts/stack#stackreferences" >}}) can be used to depend on this stack from another, allowing us to build higher levels of infrastructure that consume these images.
 
 As an example of (2) in action, let's run the image locally using the exported image name:
 

content/blog/continuous-delivery-with-gitlab-and-pulumi-on-amazon-eks/index.md

@@ -55,7 +55,7 @@ suited in a production setup giving users more flexibility and
 boundaries between their teams. We will use this structure in our
 example below. For more information on Pulumi projects and stacks,
 please refer to our documentation
-[here]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}).
+[here]({{< relref "/docs/guides/organizing-projects-stacks" >}}).
 
 ### Use Tags to group Pulumi Stacks as Environments:
 

content/blog/easy-serverless-apps-and-infrastructure-real-events-real-code/index.md

@@ -288,7 +288,7 @@ We've given the function's ID, `zipTpsReports-19d51dc`, which allows
 Pulumi to locate it in your account and reuse it. This can make it easy
 to incrementally adopt Pulumi one piece at a time, collaborate between
 teams, or stitch together resources
-[managed by different stacks]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}).
+[managed by different stacks]({{< relref "/docs/guides/organizing-projects-stacks" >}}).
 
 ## More About Functions
 
@@ -363,7 +363,7 @@ For instance, it's common for the DevOps team to manage the physical
 cloud resources like queues, topics, and buckets, while the development
 team authors and manages the serverless functions attached to them. Read
 more about
-this [here]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}).
+this [here]({{< relref "/docs/guides/organizing-projects-stacks" >}}).
 
 ## More About Event Sources
 

content/blog/pulumi-2020-update/index.md

@@ -13,7 +13,7 @@ meta_image: "pulumi-1-0.png"
 
 ## .NET
 
-[Our .NET SDK]({{< relref "/docs/intro/languages/dotnet" >}}) has come a long way. We recently tidied up the API surface area to feel more familiar to .NET developers, added C# getting started guides for [AWS]({{< relref "/docs/get-started/aws?language=csharp" >}}), [Azure]({{< relref "/docs/get-started/azure?language=csharp" >}}), [GCP]({{< relref "/docs/get-started/aws?language=csharp" >}}), and [Kubernetes]({{< relref "/docs/get-started/aws?language=csharp" >}}), and added many new examples. We also closed the gap on core Pulumi features missing from the initial release, including [aliases]({{< relref "/docs/intro/concepts/resources#aliases" >}}), [transformations]({{< relref "/docs/intro/concepts/resources#transformations" >}}), [StackReference]({{< relref "/docs/intro/concepts/organizing-stacks-projects#inter-stack-dependencies" >}}), and .NET versions of the [Kubernetes](https://github.com/pulumi/pulumi-kubernetes), [Docker](https://github.com/pulumi/pulumi-docker), and [Terraform remote state](https://github.com/pulumi/pulumi-terraform) packages.
+[Our .NET SDK]({{< relref "/docs/intro/languages/dotnet" >}}) has come a long way. We recently tidied up the API surface area to feel more familiar to .NET developers, added C# getting started guides for [AWS]({{< relref "/docs/get-started/aws?language=csharp" >}}), [Azure]({{< relref "/docs/get-started/azure?language=csharp" >}}), [GCP]({{< relref "/docs/get-started/aws?language=csharp" >}}), and [Kubernetes]({{< relref "/docs/get-started/aws?language=csharp" >}}), and added many new examples. We also closed the gap on core Pulumi features missing from the initial release, including [aliases]({{< relref "/docs/intro/concepts/resources#aliases" >}}), [transformations]({{< relref "/docs/intro/concepts/resources#transformations" >}}), [StackReference]({{< relref "/docs/intro/concepts/stack#stackreferences" >}}), and .NET versions of the [Kubernetes](https://github.com/pulumi/pulumi-kubernetes), [Docker](https://github.com/pulumi/pulumi-docker), and [Terraform remote state](https://github.com/pulumi/pulumi-terraform) packages.
 
 The remaining areas to improve for the .NET SDK include making the API documentation available in C# (details are below in the "still to come" section), migrating to .NET Core 3.1, and enabling you to test your infrastructure using familiar C# tools more easily.
 

content/blog/testing-your-infrastructure-as-code-with-pulumi/index.md

@@ -565,7 +565,7 @@ comprehensive guide.
 
 A very powerful capability this unlocks is the ability to spin up
 ephemeral environments solely for purposes of acceptance testing.
-Pulumi's concept of [projects and stacks]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}) is
+Pulumi's concept of [projects and stacks]({{< relref "/docs/guides/organizing-projects-stacks" >}}) is
 designed to make it very easy to stand up entirely isolated and
 independent environments, and to tear them down, all in either a few
 easy CLI gestures, or by using the integration testing framework.

content/blog/using-terraform-remote-state-with-pulumi/index.md

@@ -19,7 +19,7 @@ by different teams. For example, it's common to see an application team
 deploying into a VPC owned and managed by a network operations team.
 
 Pulumi supports
-[this kind of workflow]({{< relref "/docs/intro/concepts/organizing-stacks-projects#inter-stack-dependencies" >}})
+[this kind of workflow]({{< relref "/docs/intro/concepts/stack#stackreferences" >}})
 natively using the [`StackReference`]({{< relref "/docs/reference/pkg/nodejs/pulumi/pulumi#StackReference" >}})
 type from the Pulumi SDK. Integration with the most popular
 cloud-specific tools have been supported by Pulumi since the earliest

content/docs/get-started/aws/create-project.md

@@ -80,7 +80,7 @@ Next, you will be asked for the name of a stack. Hit `ENTER` to accept the defau
 
 Finally, you will be prompted for some configuration values for the stack. For AWS projects, you will be prompted for the AWS region. You can accept the default value or choose another value like `us-west-2`.
 
-> What are [projects]({{< relref "/docs/intro/concepts/project" >}}) and [stacks]({{< relref "/docs/intro/concepts/stack" >}})? Pulumi projects and stacks let you organize Pulumi code. Consider a Pulumi _project_ to be analogous to a GitHub repo---a single place for code---and a _stack_ to be an instance of that code with a separate configuration. For instance, _Project Foo_ may have multiple stacks for different development environments (Dev, Test, or Prod), or perhaps for different cloud configurations (geographic region for example). See [Organizing Projects and Stacks]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}) for some best practices on organizing your Pulumi projects and stacks.
+> What are [projects]({{< relref "/docs/intro/concepts/project" >}}) and [stacks]({{< relref "/docs/intro/concepts/stack" >}})? Pulumi projects and stacks let you organize Pulumi code. Consider a Pulumi _project_ to be analogous to a GitHub repo---a single place for code---and a _stack_ to be an instance of that code with a separate configuration. For instance, _Project Foo_ may have multiple stacks for different development environments (Dev, Test, or Prod), or perhaps for different cloud configurations (geographic region for example). See [Organizing Projects and Stacks]({{< relref "/docs/guides/organizing-projects-stacks" >}}) for some best practices on organizing your Pulumi projects and stacks.
 
 {{% choosable language "javascript,typescript" %}}
 After some dependency installations from `npm`, the project and stack will be ready.

content/docs/get-started/azure/create-project.md

@@ -83,7 +83,7 @@ First, you will be asked for a project name and description. Hit `ENTER` to acce
 
 Next, you will be asked for the name of a stack. Hit `ENTER` to accept the default value of `dev`.
 
-> What are [projects]({{< relref "/docs/intro/concepts/project" >}}) and [stacks]({{< relref "/docs/intro/concepts/stack" >}})? Pulumi projects and stacks let you organize Pulumi code. Consider a Pulumi _project_ to be analogous to a GitHub repo---a single place for code---and a _stack_ to be an instance of that code with a separate configuration. For instance, _Project Foo_ may have multiple stacks for different development environments (Dev, Test, or Prod), or perhaps for different cloud configurations (geographic region for example). See [Organizing Projects and Stacks]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}) for some best practices on organizing your Pulumi projects and stacks.
+> What are [projects]({{< relref "/docs/intro/concepts/project" >}}) and [stacks]({{< relref "/docs/intro/concepts/stack" >}})? Pulumi projects and stacks let you organize Pulumi code. Consider a Pulumi _project_ to be analogous to a GitHub repo---a single place for code---and a _stack_ to be an instance of that code with a separate configuration. For instance, _Project Foo_ may have multiple stacks for different development environments (Dev, Test, or Prod), or perhaps for different cloud configurations (geographic region for example). See [Organizing Projects and Stacks]({{< relref "/docs/guides/organizing-projects-stacks" >}}) for some best practices on organizing your Pulumi projects and stacks.
 
 Next, you will be prompted for some configuration values for the stack.
 

content/docs/get-started/gcp/create-project.md

@@ -80,7 +80,7 @@ Next, you will be asked for the name of a stack. Hit `ENTER` to accept the defau
 
 Finally, you will be prompted for some configuration values for the stack. For Google Cloud projects, you will be prompted for the Google Cloud region. You can accept the default value or choose another value like `us-west1`.
 
-> What are [projects]({{< relref "/docs/intro/concepts/project" >}}) and [stacks]({{< relref "/docs/intro/concepts/stack" >}})? Pulumi projects and stacks let you organize Pulumi code. Consider a Pulumi _project_ to be analogous to a GitHub repo---a single place for code---and a _stack_ to be an instance of that code with a separate configuration. For instance, _Project Foo_ may have multiple stacks for different development environments (Dev, Test, or Prod), or perhaps for different cloud configurations (geographic region for example). See [Organizing Projects and Stacks]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}) for some best practices on organizing your Pulumi projects and stacks.
+> What are [projects]({{< relref "/docs/intro/concepts/project" >}}) and [stacks]({{< relref "/docs/intro/concepts/stack" >}})? Pulumi projects and stacks let you organize Pulumi code. Consider a Pulumi _project_ to be analogous to a GitHub repo---a single place for code---and a _stack_ to be an instance of that code with a separate configuration. For instance, _Project Foo_ may have multiple stacks for different development environments (Dev, Test, or Prod), or perhaps for different cloud configurations (geographic region for example). See [Organizing Projects and Stacks]({{< relref "/docs/guides/organizing-projects-stacks" >}}) for some best practices on organizing your Pulumi projects and stacks.
 
 {{% choosable language "javascript,typescript" %}}
 After some dependency installations from `npm`, the project and stack will be ready.

content/docs/get-started/kubernetes/create-project.md

@@ -79,7 +79,7 @@ First, you will be asked for a project name and description. Hit `ENTER` to acce
 
 Next, you will be asked for the name of a stack. You can hit `ENTER` to accept the default value of `dev`.
 
-> What are [projects]({{< relref "/docs/intro/concepts/project" >}}) and [stacks]({{< relref "/docs/intro/concepts/stack" >}})? Pulumi projects and stacks let you organize Pulumi code. Consider a Pulumi _project_ to be analogous to a GitHub repo---a single place for code---and a _stack_ to be an instance of that code with a separate configuration. For instance, _Project Foo_ may have multiple stacks for different development environments (Dev, Test, or Prod), or perhaps for different cloud configurations (geographic region for example). See [Organizing Projects and Stacks]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}) for some best practices on organizing your Pulumi projects and stacks.
+> What are [projects]({{< relref "/docs/intro/concepts/project" >}}) and [stacks]({{< relref "/docs/intro/concepts/stack" >}})? Pulumi projects and stacks let you organize Pulumi code. Consider a Pulumi _project_ to be analogous to a GitHub repo---a single place for code---and a _stack_ to be an instance of that code with a separate configuration. For instance, _Project Foo_ may have multiple stacks for different development environments (Dev, Test, or Prod), or perhaps for different cloud configurations (geographic region for example). See [Organizing Projects and Stacks]({{< relref "/docs/guides/organizing-projects-stacks" >}}) for some best practices on organizing your Pulumi projects and stacks.
 
 {{% choosable language "javascript,typescript" %}}
 After some dependency installations from `npm`, the project and stack will be ready.

content/docs/guides/adopting/_index.md

@@ -45,7 +45,7 @@ In these cases, new infrastructure can coexist with old infrastructure in two wa
 
 * [**Resource Getters**]({{< relref "/docs/intro/concepts/resources#resource-get" >}}) available on every resource let you read all the details for a resource from the cloud provider based just on its ID.
 
-* [**Stack References**]({{< relref "/docs/intro/concepts/organizing-stacks-projects#inter-stack-dependencies" >}}) let you reference outputs of another Pulumi stack for use as inputs to a stack, which is very useful for [organizing projects and stacks]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}).
+* [**Stack References**]({{< relref "/docs/intro/concepts/stack#stackreferences" >}}) let you reference outputs of another Pulumi stack for use as inputs to a stack, which is very useful for [organizing projects and stacks]({{< relref "/docs/guides/organizing-projects-stacks" >}}).
 
 * **External State References** let you reference outputs from a non-Pulumi stack for use as inputs to a Pulumi stack. Many infrastructure as code tools have the notion of "outputs," which are simply values exported for easy consumption. This might be VPC IDs, auto-assigned IP addresses, and so on. Examples include [Terraform state files and workspaces]({{< relref "from_terraform" >}}), [AWS CloudFormation stacks]({{< relref "from_aws" >}}), and [Azure Resource Manager (ARM) deployments]({{< relref "from_azure" >}}).
 

content/docs/guides/continuous-delivery/_index.md

@@ -96,7 +96,7 @@ sensitive information. See [Managing Secrets with Pulumi]({{< relref "managing-s
 ### Managing Complex Environments
 
 Most real-world environments are complex. Perhaps you have a networking stack that's independent from your data
-and application stacks. Pulumi [supports "stack references"]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}), which
+and application stacks. Pulumi [supports "stack references"]({{< relref "/docs/guides/organizing-projects-stacks" >}}), which
 permit one stack to depend upon another. This facilitates continuous delivery and integration at scale.
 
 ### Using Branches for Environments

content/docs/guides/crosswalk/aws/lambda.md

@@ -330,7 +330,7 @@ Lastly, it's possible to use Pulumi stacks to actually break apart your cloud re
 independently deployable pieces. This allows teams to leverage features like RBAC. For instance, it's common for the
 DevOps team to manage the physical cloud resources like queues, topics, and buckets, while the development team
 authors and manages the serverless functions attached to them. For more information on this idea, see
-[Organizing Projects and Stacks]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}})
+[Organizing Projects and Stacks]({{< relref "/docs/guides/organizing-projects-stacks" >}})
 
 ## Easy Lambda Log Consumption
 

content/docs/guides/crosswalk/kubernetes/playbooks.md

@@ -69,7 +69,7 @@ At the core of this architecture is a simple idea: that we should separate resou
 loosely-coupled, independently-manageable sets, based on risk and functionality.
 
 We suggest splitting infrastructure up into (roughly) six [Pulumi
-stacks]({{< relref "/docs/intro/concepts/organizing-stacks-projects" >}}) of resources.
+stacks]({{< relref "/docs/guides/organizing-projects-stacks" >}}) of resources.
 
 ### 1. Identity