chore: update outdated repo links and package paths (#26619)

Update some outdated repository links and package paths since [repo remodeling](#24376).

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

CONTRIBUTING.md

@@ -352,8 +352,8 @@ assertions against the deployed infrastructure.
 ```
 
 Examples:
-* [integ.destinations.ts](https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-lambda-destinations/test/integ.destinations.ts#L7)
-* [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
+* [integ.destinations.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk-testing/framework-integ/test/aws-lambda-destinations/test/integ.destinations.ts#L7)
+* [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk-testing/framework-integ/test/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
 
 **What if you cannot run integration tests**
 

INTEGRATION_TESTS.md

@@ -49,8 +49,8 @@ an integration test for the new feature can ensure that it works and avoid unnec
 
 **3. Involves configuring resource types across services (i.e. integrations)**
 For example, you are adding functionality that allows for service x to integrate with service y.
-A good example of this is the [aws-stepfunctions-tasks](./packages/@aws-cdk/aws-stepfunctions-tasks) or
-[aws-apigatewayv2-integrations](./packages/@aws-cdk/aws-apigatewayv2-integrations) modules. Both of these
+A good example of this is the [aws-stepfunctions-tasks](./packages/aws-cdk-lib/aws-stepfunctions-tasks) or
+[aws-apigatewayv2-integrations-alpha](./packages/@aws-cdk/aws-apigatewayv2-integrations-alpha) modules. Both of these
 have L2 constructs that provide functionality to integrate services.
 
 Sometimes these integrations involve configuring/formatting json/vtl or some other type of data.
@@ -82,8 +82,8 @@ Lambda Function would look like this:
 
 _integ.lambda.ts_
 ```ts
-import * as iam from '@aws-cdk/aws-iam';
-import * as cdk from '@aws-cdk/core';
+import * as iam from 'aws-cdk-lib/aws-iam';
+import * as cdk from 'aws-cdk-lib/core';
 import * as lambda from '../lib';
 import * as integ from '@aws-cdk/integ-tests-alpha';
 
@@ -230,11 +230,11 @@ to deploy the Lambda Function _and_ then rerun the assertions to ensure that the
 ### Assertions
 
 Sometimes it is necessary to perform some form of _assertion_ against the deployed infrastructure to validate that the
-test succeeds. A good example of this is the `@aws-cdk/aws-stepfunctions-tasks` module which creates integrations between
+test succeeds. A good example of this is the `aws-cdk-lib/aws-stepfunctions-tasks` module which creates integrations between
 AWS StepFunctions and other AWS services. 
 
-If we look at the [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
-integration test we can see that we are creating an `@aws-cdk/aws-events.EventBus` along with a `@aws-cdk/aws-stepfunctions.StateMachine`
+If we look at the [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk-testing/framework-integ/test/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
+integration test we can see that we are creating an `aws-cdk-lib/aws-events.EventBus` along with a `aws-cdk-lib/aws-stepfunctions.StateMachine`
 which will send an event to the `EventBus`. In a typical integration test we would just deploy the test and the fact that the
 infrastructure deployed successfully would be enough of a validation that the test succeeded. In this case though, we ideally
 want to validate that the _integration_ connecting `StepFunctions` to the `EventBus` has been setup correctly, and the only
@@ -269,8 +269,8 @@ Not every test requires an assertion. We typically do not need to assert CloudFo
 with Encryption, we do not need to assert that Encryption is set on the bucket. We can trust that the CloudFormation behavior works.
 Some things you should look for in deciding if the test needs an assertion:
 
-- Integrations between services (i.e. integration libraries like `@aws-cdk/aws-lambda-destinations`, `@aws-cdk/aws-stepfunctions-tasks`, etc)
-- Anything that bundles or deploys custom code (i.e. does a Lambda function bundled with `@aws-cdk/aws-lambda-nodejs` still invoke or did we break bundling behavior)
+- Integrations between services (i.e. integration libraries like `aws-cdk-lib/aws-lambda-destinations`, `aws-cdk-lib/aws-stepfunctions-tasks`, etc)
+- Anything that bundles or deploys custom code (i.e. does a Lambda function bundled with `aws-cdk-lib/aws-lambda-nodejs` still invoke or did we break bundling behavior)
 - IAM/Networking connections.
   - This one is a bit of a judgement call. Most things do not need assertions, but sometimes we handle complicated configurations involving IAM permissions or
     Networking access.

design/aws-ecs/aws-ecs-fargate-capacity-providers.md

@@ -103,11 +103,11 @@ This new field would be added to the BaseService, not only for better extensibil
 
 Implications Setting Launch Type
 
-Since it can be reasonably assumed that any CapacityProvideStrategies defined on the Service are what the customer intends to use on the Service, the LaunchType will *not* be set on the Service if CapacityProvideStrategies are specified. This is similar to how the LaunchType field is unset if the service uses an external DeploymentController (https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/base/base-service.ts#L374).
+Since it can be reasonably assumed that any CapacityProvideStrategies defined on the Service are what the customer intends to use on the Service, the LaunchType will *not* be set on the Service if CapacityProvideStrategies are specified. This is similar to how the LaunchType field is unset if the service uses an external DeploymentController (https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/base/base-service.ts#L587).
 
 On the other hand, this intent would not be as obvious with Default Capacity Provider Strategies defined a cluster. A *defaultCapacityProviderStrategy* specified on a cluster is used for any service that does not specify either a launchType or its own CapacityProviderStrategies. From the point of view of the ECS APIs, similar to how custom CapacityProvideStrategies defined on the Service are expected to supersede the defaultCapacityProviderStrategy on a cluster, the expected behavior for an ECS Service that specifies a launchType is for it to also ignore the Cluster’s defaultCapacityProviderStrategy.
 
-However, since the two Service constructs in the CDK (Ec2Service and FargateService) do not support having the launchType field passed in explicitly, it would not possible to infer whether the intent of the customer using one of these Service constructs is to use the implied launchType (currently set under the hood in the service’s constructor (https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/fargate/fargate-service.ts#L155)) or the defaultCapacityProviderStrategy.  For this reason, we will not be adding the  defaultCapacityProviderStrategy field on the Cluster construct for this iteration.
+However, since the two Service constructs in the CDK (Ec2Service and FargateService) do not support having the launchType field passed in explicitly, it would not possible to infer whether the intent of the customer using one of these Service constructs is to use the implied launchType (currently set under the hood in the service’s constructor (https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/fargate/fargate-service.ts#L134) or the defaultCapacityProviderStrategy.  For this reason, we will not be adding the  defaultCapacityProviderStrategy field on the Cluster construct for this iteration.
 
 _*Note*_: Future for support will be dependent on a re-design of the existing Service strategies. This will be treated in v2 of the ECS modules, likely with a single Service L2 construct and deprecation of the Ec2Service and FargateService constructs.
 

design/aws-ecs/aws-ecs-priv-registry-support.md

@@ -2,11 +2,11 @@
 
 To address issue [#1698](https://github.com/aws/aws-cdk/issues/1698), the ECS construct library should provide a way for customers to specify [`repositoryCredentials`](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html#ECS-Type-ContainerDefinition-repositoryCredentials) on their container.
 
-Minimally, this would mean adding a new string field on `ContainerDefinition`, however this doesn't provide any added value in terms of logical grouping or resource creation. We can instead modify the existing ECS CDK construct [`ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/container-image.ts) so that repository credentials are specified along with the image they're meant to access.
+Minimally, this would mean adding a new string field on `ContainerDefinition`, however this doesn't provide any added value in terms of logical grouping or resource creation. We can instead modify the existing ECS CDK construct [`ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/container-image.ts) so that repository credentials are specified along with the image they're meant to access.
 
 ## General approach
 
-The [`ecs.ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/container-image.ts) class already includes constructs for 3 types of images:
+The [`ecs.ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/container-image.ts) class already includes constructs for 3 types of images:
 
 * DockerHubImage
 * EcrImage

docs/DESIGN_GUIDELINES.md

@@ -193,7 +193,7 @@ exist in the CDK will be removed in the next CDK major version (CDKv2).
 
 AWS resources are organized into modules based on their AWS service. For
 example, the "Bucket" resource, which is offered by the Amazon S3 service will
-be available under the **@aws-cdk/aws-s3** module. We will use the “aws-” prefix
+be available under the **aws-cdk-lib/aws-s3** module. We will use the “aws-” prefix
 for all AWS services, regardless of whether their marketing name uses an
 “Amazon” prefix (e.g. “Amazon S3”). Non-AWS services supported by AWS
 CloudFormation (like the Alexa::ASK namespace) will be **@aws-cdk/alexa-ask**.
@@ -203,13 +203,13 @@ consistent with the AWS SDKs and AWS CloudFormation _[awslint:module-name]_.
 
 All major versions of an AWS namespace will be mastered in the AWS Construct
 Library under the root namespace. For example resources of the **ApiGatewayV2**
-namespace will be available under the **@aws-cdk/aws-apigateway** module (and
+namespace will be available under the **aws-cdk-lib/aws-apigateway** module (and
 not under “v2) _[awslint:module-v2]_.
 
 In some cases, it makes sense to introduce secondary modules for a certain
 service (e.g. aws-s3-notifications, aws-lambda-event-sources, etc). The name of
 the secondary module will be
-**@aws-cdk/aws-xxx-\<secondary-module\>**_[awslint:module-secondary]_.
+**aws-cdk-lib/aws-xxx-\<secondary-module\>**_[awslint:module-secondary]_.
 
 Documentation for how to use secondary modules should be in the main module. The
 README file should refer users to the central module

packages/@aws-cdk-testing/framework-integ/test/aws-cloudwatch/test/integ.alarm-and-dashboard.ts

@@ -1,6 +1,6 @@
 // Integration test to deploy some resources, create an alarm on it and create a dashboard.
 //
-// Because literally every other library is going to depend on @aws-cdk/aws-cloudwatch, we drop down
+// Because literally every other library is going to depend on aws-cdk-lib/aws-cloudwatch, we drop down
 // to the very lowest level to create CloudFormation resources by hand, without even generated
 // library support.
 

packages/@aws-cdk-testing/framework-integ/test/aws-cloudwatch/test/integ.math-alarm-and-dashboard.ts

@@ -1,6 +1,6 @@
 // Integration test to deploy some resources, create an alarm on it and create a dashboard.
 //
-// Because literally every other library is going to depend on @aws-cdk/aws-cloudwatch, we drop down
+// Because literally every other library is going to depend on aws-cdk-lib/aws-cloudwatch, we drop down
 // to the very lowest level to create CloudFormation resources by hand, without even generated
 // library support.
 

packages/@aws-cdk-testing/framework-integ/test/aws-codecommit/test/integ.codecommit-events.ts

@@ -10,7 +10,7 @@ const repo = new codecommit.Repository(stack, 'Repo', {
 });
 const topic = new sns.Topic(stack, 'MyTopic');
 
-// we can't use @aws-cdk/aws-events-targets.SnsTopic here because it will
+// we can't use aws-cdk-lib/aws-events-targets.SnsTopic here because it will
 // create a cyclic dependency with codebuild, so we just fake it
 repo.onReferenceCreated('OnReferenceCreated', {
   target: {

packages/@aws-cdk-testing/framework-integ/test/aws-eks/test/integ.eks-cluster-ipv6.ts

@@ -350,7 +350,7 @@ class EksClusterStack extends Stack {
 }
 
 // this test uses both the bottlerocket image and the inf1 instance, which are only supported in these
-// regions. see https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/aws-eks#bottlerocket
+// regions. see https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk-lib/aws-eks#bottlerocket
 // and https://aws.amazon.com/about-aws/whats-new/2019/12/introducing-amazon-ec2-inf1-instances-high-performance-and-the-lowest-cost-machine-learning-inference-in-the-cloud/
 const supportedRegions = [
   'us-east-1',

packages/@aws-cdk-testing/framework-integ/test/aws-eks/test/integ.eks-cluster.ts

@@ -323,7 +323,7 @@ class EksClusterStack extends Stack {
 }
 
 // this test uses both the bottlerocket image and the inf1 instance, which are only supported in these
-// regions. see https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/aws-eks#bottlerocket
+// regions. see https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk-lib/aws-eks#bottlerocket
 // and https://aws.amazon.com/about-aws/whats-new/2019/12/introducing-amazon-ec2-inf1-instances-high-performance-and-the-lowest-cost-machine-learning-inference-in-the-cloud/
 const supportedRegions = [
   'us-east-1',

packages/@aws-cdk/aws-apigatewayv2-alpha/README.md

@@ -44,7 +44,7 @@ As an API Gateway API developer, you can create APIs for use in your own client
 
 This module supports features under [API Gateway v2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ApiGatewayV2.html)
 that lets users set up Websocket and HTTP APIs.
-REST APIs can be created using the `@aws-cdk/aws-apigateway` module.
+REST APIs can be created using the `aws-cdk-lib/aws-apigateway` module.
 
 ## HTTP API
 

packages/@aws-cdk/aws-iot-actions-alpha/README.md

@@ -17,7 +17,7 @@
 
 This library contains integration classes to send data to any number of
 supported AWS Services. Instances of these classes should be passed to
-`TopicRule` defined in `@aws-cdk/aws-iot`.
+`TopicRule` defined in `aws-cdk-lib/aws-iot`.
 
 Currently supported are:
 

packages/@aws-cdk/aws-iot-alpha/README.md

@@ -76,4 +76,4 @@ new iot.TopicRule(this, 'TopicRule', {
 });
 ```
 
-See also [@aws-cdk/aws-iot-actions](https://docs.aws.amazon.com/cdk/api/latest/docs/aws-iot-actions-readme.html) for other actions.
+See also [@aws-cdk/aws-iot-actions-alpha](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-iot-actions-alpha-readme.html) for other actions.

packages/@aws-cdk/aws-iotevents-actions-alpha/README.md

@@ -15,8 +15,8 @@
 
 <!--END STABILITY BANNER-->
 
-This library contains integration classes to specify actions of state events of Detector Model in `@aws-cdk/aws-iotevents`.
-Instances of these classes should be passed to `State` defined in `@aws-cdk/aws-iotevents`
+This library contains integration classes to specify actions of state events of Detector Model in `@aws-cdk/aws-iotevents-alpha`.
+Instances of these classes should be passed to `State` defined in `@aws-cdk/aws-iotevents-alpha`
 You can define built-in actions to use a timer or set a variable, or send data to other AWS resources.
 
 This library contains integration classes to use a timer or set a variable, or send data to other AWS resources.

packages/@aws-cdk/aws-iotevents-alpha/README.md

@@ -27,7 +27,7 @@ The detector model need a reference to at least one AWS IoT Events input.
 AWS IoT Events inputs enable the detector to get MQTT payload values from IoT Core rules.
 
 You can define built-in actions to use a timer or set a variable, or send data to other AWS resources.
-See also [@aws-cdk/aws-iotevents-actions](https://docs.aws.amazon.com/cdk/api/v1/docs/aws-iotevents-actions-readme.html) for other actions.
+See also [@aws-cdk/aws-iotevents-actions-alpha](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-iotevents-actions-alpha-readme.html) for other actions.
 
 ```ts
 import * as iotevents from '@aws-cdk/aws-iotevents-alpha';

packages/@aws-cdk/aws-kinesisfirehose-alpha/README.md

@@ -498,7 +498,7 @@ Conversely to the above, Kinesis Data Firehose requires permissions in order for
 streams to interact with resources that you own. For example, if an S3 bucket is specified
 as a destination of a delivery stream, the delivery stream must be granted permissions to
 put and get objects from the bucket. When using the built-in AWS service destinations
-found in the `@aws-cdk/aws-kinesisfirehose-destinations` module, the CDK grants the
+found in the `@aws-cdk/aws-kinesisfirehose-destinations-alpha` module, the CDK grants the
 permissions automatically. However, custom or third-party destinations may require custom
 permissions. In this case, use the delivery stream as an `IGrantable`, as follows:
 

packages/@aws-cdk/aws-lambda-go-alpha/README.md

@@ -99,7 +99,7 @@ generally fall into two scenarios:
    If you are not vendoring then `go build` will be run without `-mod=vendor`
     since the default behavior is to download dependencies
 
-All other properties of `lambda.Function` are supported, see also the [AWS Lambda construct library](https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/aws-lambda).
+All other properties of `lambda.Function` are supported, see also the [AWS Lambda construct library](https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk-lib/aws-lambda).
 
 ## Environment
 

packages/@aws-cdk/aws-lambda-go-alpha/lib/types.ts

@@ -15,7 +15,7 @@ export interface BundlingOptions extends DockerRunOptions {
   /**
    * A custom bundling Docker image.
    *
-   * @default - use the Docker image provided by @aws-cdk/aws-lambda-go
+   * @default - use the Docker image provided by @aws-cdk/aws-lambda-go-alpha
    */
   readonly dockerImage?: DockerImage;
 

packages/@aws-cdk/aws-lambda-python-alpha/README.md

@@ -33,7 +33,7 @@ new python.PythonFunction(this, 'MyFunction', {
 });
 ```
 
-All other properties of `lambda.Function` are supported, see also the [AWS Lambda construct library](https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/aws-lambda).
+All other properties of `lambda.Function` are supported, see also the [AWS Lambda construct library](https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk-lib/aws-lambda).
 
 ## Python Layer
 

packages/@aws-cdk/aws-neptune-alpha/README.md

@@ -17,7 +17,7 @@
 
 Amazon Neptune is a fast, reliable, fully managed graph database service that makes it easy to build and run applications that work with highly connected datasets. The core of Neptune is a purpose-built, high-performance graph database engine. This engine is optimized for storing billions of relationships and querying the graph with milliseconds latency. Neptune supports the popular graph query languages Apache TinkerPop Gremlin and W3C’s SPARQL, enabling you to build queries that efficiently navigate highly connected datasets.
 
-The `@aws-cdk/aws-neptune` package contains primitives for setting up Neptune database clusters and instances.
+The `@aws-cdk/aws-neptune-alpha` package contains primitives for setting up Neptune database clusters and instances.
 
 ```ts nofixture
 import * as neptune from '@aws-cdk/aws-neptune-alpha';

packages/@aws-cdk/aws-servicecatalogappregistry-alpha/README.md

@@ -30,7 +30,7 @@ enables organizations to create and manage repositories of applications and asso
   - [Sharing an application](#sharing-an-application)
   - [Sharing an attribute group](#sharing-an-attribute-group)
 
-The `@aws-cdk/aws-servicecatalogappregistry` package contains resources that enable users to automate governance and management of their AWS resources at scale.
+The `@aws-cdk/aws-servicecatalogappregistry-alpha` package contains resources that enable users to automate governance and management of their AWS resources at scale.
 
 ```ts nofixture
 import * as appreg from '@aws-cdk/aws-servicecatalogappregistry-alpha';

packages/aws-cdk-lib/aws-appsync/README.md

@@ -1,7 +1,7 @@
 # AWS AppSync Construct Library
 
 
-The `@aws-cdk/aws-appsync` package contains constructs for building flexible
+The `aws-cdk-lib/aws-appsync` package contains constructs for building flexible
 APIs that use GraphQL.
 
 ```ts nofixture

packages/aws-cdk-lib/aws-autoscaling-common/README.md

@@ -1,8 +1,8 @@
 # AWS AutoScaling Common Library
 
 
-This is a sister package to `@aws-cdk/aws-autoscaling` and
-`@aws-cdk/aws-applicationautoscaling`. It contains shared implementation
+This is a sister package to `aws-cdk-lib/aws-autoscaling` and
+`aws-cdk-lib/aws-applicationautoscaling`. It contains shared implementation
 details between them.
 
 It does not need to be used directly.