Update: Add bootstrap template v24 and v25

evzzk · evzzk · commit 57b92757d30a · 2024-12-11T11:00:03.000-10:00
diff --git a/v2/bootstrapping-env.md b/v2/bootstrapping-env.md
@@ -261,6 +261,8 @@ This section contains a list of the changes made in each version\.
 | 21 | 2\.149\.0 | Add condition to the file publishing role\. | 
 | 22 | 2\.160\.0 | Add sts:TagSession permissions to the trust policy of bootstrap IAM roles\. | 
 | 23 | 2\.161\.0 | Add cloudformation:RollbackStack and cloudformation:ContinueUpdateRollback permissions to the trust policy of the deploy IAM role\. This provides permissions for the cdk rollback command\. | 
+| 24 | 2\.165\.0 | Change the duration of days that noncurrent objects in the bootstrap bucket will be retained, from 365 to 30 days\. Since the new cdk gc command introduces the ability to delete objects in the bootstrap bucket, this new behavior ensures that deleted objects remain in the bootstrap bucket for 30 days instead of 365 days\. For more information on this change, see aws\-cdk PR [\#31949](https://github.com/aws/aws-cdk/pull/31949)\. | 
+| 25 | 2\.165\.0 | Add support to the bootstrap bucket for the removal of incomplete multipart uploads\. Incomplete multipart uploads will be deleted after 1 day\. For more information on this change, see aws\-cdk PR [\#31956](https://github.com/aws/aws-cdk/pull/31956)\. | 
 
 ## Upgrade from legacy to modern bootstrap template<a name="bootstrapping-template"></a>
 
diff --git a/v2/customize-synth.md b/v2/customize-synth.md
@@ -343,7 +343,7 @@ new DefaultStackSynthesizer(new DefaultStackSynthesizerProps
 
 To modify the security credentials used to provide permissions during CDK deployments, you can customize synthesis by using `[CliCredentialsStackSynthesizer](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CliCredentialsStackSynthesizer.html)`\. This synthesizer works with the default AWS resources that are created during bootstrapping to store assets, such as the Amazon S3 bucket and Amazon ECR repository\. Instead of using the default IAM roles created by the CDK during bootstrapping, it uses the security credentials of the actor initiating deployment\. Therefore, the security credentials of the actor must have valid permissions to perform all deployment actions\. The following diagram illustrates the deployment process when using this synthesizer:
 
-![\[\]](http://docs.aws.amazon.com/cdk/v2/guide/images/CliCredentialsStackSynthesizer-deploy-process_cdk_flowchart.svg)
+![\[\]](http://docs.aws.amazon.com/cdk/v2/guide/images/CliCredentialsStackSynthesizer-deploy-process_cdk_flowchart.png)
 
 When using `CliCredentialsStackSynthesizer`:
 + By default, CloudFormation performs API calls in your account using the permissions of the actor\. Therefore, the current identity must have permission to make necessary changes to the AWS resources in the CloudFormation stack, along with the permissions to perform necessary CloudFormation operations, such as `CreateStack` or `UpdateStack`\. Deployment capabilities will be limited to the permissions of the actor\.
diff --git a/v2/deploy.md b/v2/deploy.md
@@ -150,7 +150,7 @@ To deploy your application, we recommend that you use the CDK CLI `cdk deploy` c
 
 When you run `cdk deploy`, the CDK CLI initiates `cdk synth` to prepare for deployment\. The following diagram illustrates the app lifecycle in the context of a deployment:
 
-![\[\]](http://docs.aws.amazon.com/cdk/v2/guide/images/app-lifecycle_cdk-flowchart.svg)
+![\[\]](http://docs.aws.amazon.com/cdk/v2/guide/images/app-lifecycle_cdk-flowchart.png)
 
 During deployment, the CDK CLI takes the cloud assembly produced by synthesis and deploys it to an AWS environment\. Assets are uploaded to Amazon S3 and Amazon ECR and the CloudFormation template is submitted to AWS CloudFormation for deployment\.
 
@@ -162,7 +162,7 @@ By the time the AWS CloudFormation deployment phase starts, your CDK app has alr
 
 Before deployment can be performed, permissions must be established\. The following diagram illustrates the permissions that are used during a default deployment, when using the default bootstrapping process and stack synthesizer:
 
-![\[\]](http://docs.aws.amazon.com/cdk/v2/guide/images/default-deploy-process_cdk_flowchart.svg)
+![\[\]](http://docs.aws.amazon.com/cdk/v2/guide/images/default-deploy-process_cdk_flowchart.png)
 
 **Actor initiates deployment**  
 Deployments are initiated by an *actor*, using the CDK CLI\. An actor can either be a person, or a service such as AWS CodePipeline\.  
diff --git a/v2/ecs_example.md b/v2/ecs_example.md
@@ -1,6 +1,6 @@
 # Example: Create an AWS Fargate service using the AWS CDK<a name="ecs_example"></a>
 
-In this example, we show you how to create an AWS Fargate \(Fargate\) service running on an Amazon Elastic Container Service \(Amazon ECS\) cluster that's fronted by an internet\-facing Application Load Balancer from an image on Amazon ECR\.
+In this example, we show you how to create an AWS Fargate service running on an Amazon Elastic Container Service \(Amazon ECS\) cluster that's fronted by an internet\-facing Application Load Balancer from an image on Amazon ECR\.
 
 Amazon ECS is a highly scalable, fast, container management service that makes it easy to run, stop, and manage Docker containers on a cluster\. You can host your cluster on serverless infrastructure that's managed by Amazon ECS by launching your services or tasks using the Fargate launch type\. For more control, you can host your tasks on a cluster of Amazon Elastic Compute Cloud \(Amazon EC2\) instances that you manage by using the Amazon EC2 launch type\.
 
diff --git a/v2/featureflags.md b/v2/featureflags.md
@@ -4,7 +4,7 @@ The AWS CDK uses *feature flags* to enable potentially breaking behaviors in a r
 
 Feature flags are disabled by default\. Existing projects that do not specify the flag will continue to work as before with later AWS CDK releases\. New projects created using cdk init include flags enabling all features available in the release that created the project\. Edit `cdk.json` to disable any flags for which you prefer the earlier behavior\. You can also add flags to enable new behaviors after upgrading the AWS CDK\.
 
-A list of all current feature flags can be found on the AWS CDK GitHub repository in [https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/cx-api/FEATURE_FLAGS.md](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/cx-api/FEATURE_FLAGS.md)\. See the `CHANGELOG` in a given release for a description of any new feature flags added in that release\. 
+A list of all current feature flags can be found on the AWS CDK GitHub repository in [https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/cx-api/FEATURE_FLAGS.md](https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/cx-api/FEATURE_FLAGS.md)\. See the `CHANGELOG` in a given release for a description of any new feature flags added in that release\. 
 
 ## Reverting to v1 behavior<a name="featureflags_disabling"></a>
 
diff --git a/v2/home.md b/v2/home.md
@@ -41,7 +41,7 @@ Create your own constructs that are customized for your unique use cases and sha
 
 ## Example of the AWS CDK<a name="home-example"></a>
 
-The following is an example of using the AWS CDK Constructs Library to create an Amazon Elastic Container Service \(Amazon ECS\) service with AWS Fargate \(Fargate\) launch type\. For more details of this example, see [Example: Create an AWS Fargate service using the AWS CDK](ecs_example.md)\.
+The following is an example of using the AWS CDK Constructs Library to create an Amazon Elastic Container Service \(Amazon ECS\) service with AWS Fargate launch type\. For more details of this example, see [Example: Create an AWS Fargate service using the AWS CDK](ecs_example.md)\.
 
 ------
 #### [ TypeScript ]
diff --git a/v2/identifiers.md b/v2/identifiers.md
@@ -13,7 +13,7 @@ The most common identifier, `id`, is the identifier passed as the second argumen
 **Note**  
 The `id` of a stack is also the identifier that you use to refer to it in the [AWS CDK CLI reference](cli.md)\.
 
-Let's look at an example where we have two constructs with the identifier `amzn-s3-demo-bucket` in our app\. The first is defined in the scope of the stack with the identifier `Stack1`\. The second is defined in the scope of a stack with the identifier `Stack2`\. Because they're defined in different scopes, this doesn't cause any conflict, and they can coexist in the same app without issues\.
+Let's look at an example where we have two constructs with the identifier `MyBucket` in our app\. The first is defined in the scope of the stack with the identifier `Stack1`\. The second is defined in the scope of a stack with the identifier `Stack2`\. Because they're defined in different scopes, this doesn't cause any conflict, and they can coexist in the same app without issues\.
 
 ------
 #### [ TypeScript ]
@@ -27,7 +27,7 @@ class MyStack extends Stack {
   constructor(scope: Construct, id: string, props: StackProps = {}) {
     super(scope, id, props);
 
-    new s3.Bucket(this, 'amzn-s3-demo-bucket');
+    new s3.Bucket(this, 'MyBucket');
   }
 }
 
@@ -47,7 +47,7 @@ class MyStack extends Stack {
   constructor(scope, id, props = {}) {
     super(scope, id, props);
 
-    new s3.Bucket(this, 'amzn-s3-demo-bucket');
+    new s3.Bucket(this, 'MyBucket');
   }
 }
 
@@ -69,7 +69,7 @@ class MyStack(Stack):
     def __init__(self, scope: Construct, id: str, **kwargs):
 
         super().__init__(scope, id, **kwargs)
-        s3.Bucket(self, "amzn-s3-demo-bucket")
+        s3.Bucket(self, "MyBucket")
 
 app = App()
 MyStack(app, 'Stack1')
@@ -96,7 +96,7 @@ public class MyStack extends Stack {
     
     public MyStack(final Construct scope, final String id, final StackProps props) {
         super(scope, id, props);
-        new Bucket(this, "amzn-s3-demo-bucket");
+        new Bucket(this, "MyBucket");
     }
 }
 
@@ -126,7 +126,7 @@ public class MyStack : Stack
 {
     public MyStack(Construct scope, string id, IStackProps props) : base(scope, id, props)
     {
-        new Bucket(this, "amzn-s3-demo-bucket");
+        new Bucket(this, "MyBucket");
     }
 }
 
@@ -147,7 +147,7 @@ class Program
 
 The constructs in an AWS CDK application form a hierarchy rooted in the `App` class\. We refer to the collection of IDs from a given construct, its parent construct, its grandparent, and so on to the root of the construct tree, as a *path*\.
 
-The AWS CDK typically displays paths in your templates as a string\. The IDs from the levels are separated by slashes, starting at the node immediately under the root `App` instance, which is usually a stack\. For example, the paths of the two Amazon S3 bucket resources in the previous code example are `Stack1/amzn-s3-demo-bucket` and `Stack2/amzn-s3-demo-bucket`\.
+The AWS CDK typically displays paths in your templates as a string\. The IDs from the levels are separated by slashes, starting at the node immediately under the root `App` instance, which is usually a stack\. For example, the paths of the two Amazon S3 bucket resources in the previous code example are `Stack1/MyBucket` and `Stack2/MyBucket`\.
 
 You can access the path of any construct programmatically, as shown in the following example\. This gets the path of `myConstruct` \(or `my_construct`, as Python developers would write it\)\. Since IDs must be unique within the scope they are created, their paths are always unique within an AWS CDK application\.
 
@@ -274,7 +274,7 @@ string addr = myConstruct.Node.Addr;
 
 Unique IDs serve as the *logical identifiers* \(or *logical names*\) of resources in the generated AWS CloudFormation templates for constructs that represent AWS resources\.
 
-For example, the Amazon S3 bucket in the previous example that is created within `Stack2` results in an `AWS::S3::Bucket` resource\. The resource's logical ID is `Stack2amzn-s3-demo-bucket4DD88B4F` in the resulting AWS CloudFormation template\. \(For details on how this identifier is generated, see [Unique IDs](#identifiers_unique_ids)\.\)
+For example, the Amazon S3 bucket in the previous example that is created within `Stack2` results in an `AWS::S3::Bucket` resource\. The resource's logical ID is `Stack2MyBucket4DD88B4F` in the resulting AWS CloudFormation template\. \(For details on how this identifier is generated, see [Unique IDs](#identifiers_unique_ids)\.\)
 
 ### Logical ID stability<a name="identifiers_logical_id_stability"></a>
 
diff --git a/v2/resources.md b/v2/resources.md
@@ -337,10 +337,10 @@ The following example shows how to reference a bucket based on an existing bucke
 
 ```
 // Construct a proxy for a bucket by its name (must be same account)
-s3.Bucket.fromBucketName(this, 'amzn-s3-demo-bucket', 'amzn-s3-demo-bucket1');
+s3.Bucket.fromBucketName(this, 'MyBucket', 'amzn-s3-demo-bucket1');
 
 // Construct a proxy for a bucket by its full ARN (can be another account)
-s3.Bucket.fromBucketArn(this, 'amzn-s3-demo-bucket', 'arn:aws:s3:::amzn-s3-demo-bucket1');
+s3.Bucket.fromBucketArn(this, 'MyBucket', 'arn:aws:s3:::amzn-s3-demo-bucket1');
 
 // Construct a proxy for an existing VPC from its attribute(s)
 ec2.Vpc.fromVpcAttributes(this, 'MyVpc', {
@@ -353,10 +353,10 @@ ec2.Vpc.fromVpcAttributes(this, 'MyVpc', {
 
 ```
 // Construct a proxy for a bucket by its name (must be same account)
-s3.Bucket.fromBucketName(this, 'amzn-s3-demo-bucket', 'amzn-s3-demo-bucket1');
+s3.Bucket.fromBucketName(this, 'MyBucket', 'amzn-s3-demo-bucket1');
 
 // Construct a proxy for a bucket by its full ARN (can be another account)
-s3.Bucket.fromBucketArn(this, 'amzn-s3-demo-bucket', 'arn:aws:s3:::amzn-s3-demo-bucket1');
+s3.Bucket.fromBucketArn(this, 'MyBucket', 'arn:aws:s3:::amzn-s3-demo-bucket1');
 
 // Construct a proxy for an existing VPC from its attribute(s)
 ec2.Vpc.fromVpcAttributes(this, 'MyVpc', {
@@ -369,10 +369,10 @@ ec2.Vpc.fromVpcAttributes(this, 'MyVpc', {
 
 ```
 # Construct a proxy for a bucket by its name (must be same account)
-s3.Bucket.from_bucket_name(self, "amzn-s3-demo-bucket", "amzn-s3-demo-bucket1")
+s3.Bucket.from_bucket_name(self, "MyBucket", "amzn-s3-demo-bucket1")
 
 # Construct a proxy for a bucket by its full ARN (can be another account)
-s3.Bucket.from_bucket_arn(self, "amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket1")
+s3.Bucket.from_bucket_arn(self, "MyBucket", "arn:aws:s3:::amzn-s3-demo-bucket1")
 
 # Construct a proxy for an existing VPC from its attribute(s)
 ec2.Vpc.from_vpc_attributes(self, "MyVpc", vpc_id="vpc-1234567890abcdef")
@@ -383,10 +383,10 @@ ec2.Vpc.from_vpc_attributes(self, "MyVpc", vpc_id="vpc-1234567890abcdef")
 
 ```
 // Construct a proxy for a bucket by its name (must be same account)
-Bucket.fromBucketName(this, "amzn-s3-demo-bucket", "amzn-s3-demo-bucket1");
+Bucket.fromBucketName(this, "MyBucket", "amzn-s3-demo-bucket1");
 
 // Construct a proxy for a bucket by its full ARN (can be another account)
-Bucket.fromBucketArn(this, "amzn-s3-demo-bucket",
+Bucket.fromBucketArn(this, "MyBucket",
         "arn:aws:s3:::amzn-s3-demo-bucket1");
 
 // Construct a proxy for an existing VPC from its attribute(s)
@@ -399,10 +399,10 @@ Vpc.fromVpcAttributes(this, "MyVpc", VpcAttributes.builder()
 
 ```
 // Construct a proxy for a bucket by its name (must be same account)
-Bucket.FromBucketName(this, "amzn-s3-demo-bucket", "amzn-s3-demo-bucket1");
+Bucket.FromBucketName(this, "MyBucket", "amzn-s3-demo-bucket1");
 
 // Construct a proxy for a bucket by its full ARN (can be another account)
-Bucket.FromBucketArn(this, "amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket1");
+Bucket.FromBucketArn(this, "MyBucket", "arn:aws:s3:::amzn-s3-demo-bucket1");
 
 // Construct a proxy for an existing VPC from its attribute(s)
 Vpc.FromVpcAttributes(this, "MyVpc", new VpcAttributes
@@ -416,10 +416,10 @@ Vpc.FromVpcAttributes(this, "MyVpc", new VpcAttributes
 
 ```
 // Define a proxy for a bucket by its name (must be same account)
-s3.Bucket_FromBucketName(stack, jsii.String("amzn-s3-demo-bucket"), jsii.String("amzn-s3-demo-bucket1"))
+s3.Bucket_FromBucketName(stack, jsii.String("MyBucket"), jsii.String("amzn-s3-demo-bucket1"))
 
 // Define a proxy for a bucket by its full ARN (can be another account)
-s3.Bucket_FromBucketArn(stack, jsii.String("amzn-s3-demo-bucket"), jsii.String("arn:aws:s3:::amzn-s3-demo-bucket1"))
+s3.Bucket_FromBucketArn(stack, jsii.String("MyBucket"), jsii.String("arn:aws:s3:::amzn-s3-demo-bucket1"))
 
 // Define a proxy for an existing VPC from its attributes
 ec2.Vpc_FromVpcAttributes(stack, jsii.String("MyVpc"), &ec2.VpcAttributes{
@@ -553,15 +553,15 @@ Although you can use an external resource anywhere you'd use a similar resource
 
 The logical names of resources in AWS CloudFormation are different from the names of resources that are shown in the AWS Management Console after they're deployed by AWS CloudFormation\. The AWS CDK calls these final names *physical names*\.
 
-For example, AWS CloudFormation might create the Amazon S3 bucket with the logical ID `Stack2amzn-s3-demo-bucket4DD88B4F` from the previous example with the physical name `stack2amzn-s3-demo-bucket4dd88b4f-iuv1rbv9z3to`\.
+For example, AWS CloudFormation might create the Amazon S3 bucket with the logical ID `Stack2MyBucket4DD88B4F` from the previous example with the physical name `stack2MyBucket4dd88b4f-iuv1rbv9z3to`\.
 
-You can specify a physical name when creating constructs that represent resources by using the property *<resourceType>*Name\. The following example creates an Amazon S3 bucket with the physical name `amzn-s3-demo-bucket`\.
+You can specify a physical name when creating constructs that represent resources by using the property *<resourceType>*Name\. The following example creates an Amazon S3 bucket with the physical name `MyBucket`\.
 
 ------
 #### [ TypeScript ]
 
 ```
-const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
+const bucket = new s3.Bucket(this, 'MyBucket', {
   bucketName: 'amzn-s3-demo-bucket',
 });
 ```
@@ -570,7 +570,7 @@ const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
 #### [ JavaScript ]
 
 ```
-const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
+const bucket = new s3.Bucket(this, 'MyBucket', {
   bucketName: 'amzn-s3-demo-bucket'
 });
 ```
@@ -579,29 +579,29 @@ const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
 #### [ Python ]
 
 ```
-bucket = s3.Bucket(self, "amzn-s3-demo-bucket", bucket_name="amzn-s3-demo-bucket")
+bucket = s3.Bucket(self, "MyBucket", bucket_name="amzn-s3-demo-bucket")
 ```
 
 ------
 #### [ Java ]
 
 ```
-Bucket bucket = Bucket.Builder.create(this, "amzn-s3-demo-bucket")
+Bucket bucket = Bucket.Builder.create(this, "MyBucket")
         .bucketName("amzn-s3-demo-bucket").build();
 ```
 
 ------
 #### [ C\# ]
 
 ```
-var bucket = new Bucket(this, "amzn-s3-demo-bucket", new BucketProps { BucketName = "amzn-s3-demo-bucket" });
+var bucket = new Bucket(this, "MyBucket", new BucketProps { BucketName = "amzn-s3-demo-bucket" });
 ```
 
 ------
 #### [ Go ]
 
 ```
-bucket := s3.NewBucket(this, jsii.String("amzn-s3-demo-bucket"), &s3.BucketProps{
+bucket := s3.NewBucket(this, jsii.String("MyBucket"), &s3.BucketProps{
   BucketName: jsii.String("amzn-s3-demo-bucket"),
 })
 ```
@@ -616,7 +616,7 @@ In some cases, such as when creating an AWS CDK app with cross\-environment refe
 #### [ TypeScript ]
 
 ```
-const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
+const bucket = new s3.Bucket(this, 'MyBucket', {
   bucketName: core.PhysicalName.GENERATE_IF_NEEDED,
 });
 ```
@@ -625,7 +625,7 @@ const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
 #### [ JavaScript ]
 
 ```
-const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
+const bucket = new s3.Bucket(this, 'MyBucket', {
   bucketName: core.PhysicalName.GENERATE_IF_NEEDED
 });
 ```
@@ -634,31 +634,31 @@ const bucket = new s3.Bucket(this, 'amzn-s3-demo-bucket', {
 #### [ Python ]
 
 ```
-bucket = s3.Bucket(self, "amzn-s3-demo-bucket",
+bucket = s3.Bucket(self, "MyBucket",
                          bucket_name=core.PhysicalName.GENERATE_IF_NEEDED)
 ```
 
 ------
 #### [ Java ]
 
 ```
-Bucket bucket = Bucket.Builder.create(this, "amzn-s3-demo-bucket")
+Bucket bucket = Bucket.Builder.create(this, "MyBucket")
         .bucketName(PhysicalName.GENERATE_IF_NEEDED).build();
 ```
 
 ------
 #### [ C\# ]
 
 ```
-var bucket = new Bucket(this, "amzn-s3-demo-bucket", new BucketProps 
+var bucket = new Bucket(this, "MyBucket", new BucketProps 
     { BucketName = PhysicalName.GENERATE_IF_NEEDED });
 ```
 
 ------
 #### [ Go ]
 
 ```
-bucket := s3.NewBucket(this, jsii.String("amzn-s3-demo-bucket"), &s3.BucketProps{
+bucket := s3.NewBucket(this, jsii.String("MyBucket"), &s3.BucketProps{
   BucketName: awscdk.PhysicalName_GENERATE_IF_NEEDED(),
 })
 ```
diff --git a/v2/security-iam.md b/v2/security-iam.md

Original file line number	Diff line number	Diff line change
@@ -13,7 +13,7 @@ The most common identifier, `id`, is the identifier passed as the second argumen
`13`	`13`	`Note`
`14`	`14`	The `id` of a stack is also the identifier that you use to refer to it in the [AWS CDK CLI reference](cli.md)\.
`15`	`15`
`16`		-Let's look at an example where we have two constructs with the identifier `amzn-s3-demo-bucket` in our app\. The first is defined in the scope of the stack with the identifier `Stack1`\. The second is defined in the scope of a stack with the identifier `Stack2`\. Because they're defined in different scopes, this doesn't cause any conflict, and they can coexist in the same app without issues\.
	`16`	+Let's look at an example where we have two constructs with the identifier `MyBucket` in our app\. The first is defined in the scope of the stack with the identifier `Stack1`\. The second is defined in the scope of a stack with the identifier `Stack2`\. Because they're defined in different scopes, this doesn't cause any conflict, and they can coexist in the same app without issues\.
`17`	`17`
`18`	`18`	`------`
`19`	`19`	`#### [ TypeScript ]`
`@@ -27,7 +27,7 @@ class MyStack extends Stack {`
`27`	`27`	`constructor(scope: Construct, id: string, props: StackProps = {}) {`
`28`	`28`	`super(scope, id, props);`
`29`	`29`
`30`		`- new s3.Bucket(this, 'amzn-s3-demo-bucket');`
	`30`	`+ new s3.Bucket(this, 'MyBucket');`
`31`	`31`	`}`
`32`	`32`	`}`
`33`	`33`
`@@ -47,7 +47,7 @@ class MyStack extends Stack {`
`47`	`47`	`constructor(scope, id, props = {}) {`
`48`	`48`	`super(scope, id, props);`
`49`	`49`
`50`		`- new s3.Bucket(this, 'amzn-s3-demo-bucket');`
	`50`	`+ new s3.Bucket(this, 'MyBucket');`
`51`	`51`	`}`
`52`	`52`	`}`
`53`	`53`
`@@ -69,7 +69,7 @@ class MyStack(Stack):`
`69`	`69`	`def __init__(self, scope: Construct, id: str, **kwargs):`
`70`	`70`
`71`	`71`	`super().__init__(scope, id, **kwargs)`
`72`		`- s3.Bucket(self, "amzn-s3-demo-bucket")`
	`72`	`+ s3.Bucket(self, "MyBucket")`
`73`	`73`
`74`	`74`	`app = App()`
`75`	`75`	`MyStack(app, 'Stack1')`
`@@ -96,7 +96,7 @@ public class MyStack extends Stack {`
`96`	`96`
`97`	`97`	`public MyStack(final Construct scope, final String id, final StackProps props) {`
`98`	`98`	`super(scope, id, props);`
`99`		`- new Bucket(this, "amzn-s3-demo-bucket");`
	`99`	`+ new Bucket(this, "MyBucket");`
`100`	`100`	`}`
`101`	`101`	`}`
`102`	`102`
`@@ -126,7 +126,7 @@ public class MyStack : Stack`
`126`	`126`	`{`
`127`	`127`	`public MyStack(Construct scope, string id, IStackProps props) : base(scope, id, props)`
`128`	`128`	`{`
`129`		`- new Bucket(this, "amzn-s3-demo-bucket");`
	`129`	`+ new Bucket(this, "MyBucket");`
`130`	`130`	`}`
`131`	`131`	`}`
`132`	`132`
`@@ -147,7 +147,7 @@ class Program`
`147`	`147`
`148`	`148`	The constructs in an AWS CDK application form a hierarchy rooted in the `App` class\. We refer to the collection of IDs from a given construct, its parent construct, its grandparent, and so on to the root of the construct tree, as a path\.
`149`	`149`
`150`		-The AWS CDK typically displays paths in your templates as a string\. The IDs from the levels are separated by slashes, starting at the node immediately under the root `App` instance, which is usually a stack\. For example, the paths of the two Amazon S3 bucket resources in the previous code example are `Stack1/amzn-s3-demo-bucket` and `Stack2/amzn-s3-demo-bucket`\.
	`150`	+The AWS CDK typically displays paths in your templates as a string\. The IDs from the levels are separated by slashes, starting at the node immediately under the root `App` instance, which is usually a stack\. For example, the paths of the two Amazon S3 bucket resources in the previous code example are `Stack1/MyBucket` and `Stack2/MyBucket`\.
`151`	`151`
`152`	`152`	You can access the path of any construct programmatically, as shown in the following example\. This gets the path of `myConstruct` \(or `my_construct`, as Python developers would write it\)\. Since IDs must be unique within the scope they are created, their paths are always unique within an AWS CDK application\.
`153`	`153`
`@@ -274,7 +274,7 @@ string addr = myConstruct.Node.Addr;`
`274`	`274`
`275`	`275`	`Unique IDs serve as the logical identifiers \(or logical names\) of resources in the generated AWS CloudFormation templates for constructs that represent AWS resources\.`
`276`	`276`
`277`		-For example, the Amazon S3 bucket in the previous example that is created within `Stack2` results in an `AWS::S3::Bucket` resource\. The resource's logical ID is `Stack2amzn-s3-demo-bucket4DD88B4F` in the resulting AWS CloudFormation template\. \(For details on how this identifier is generated, see [Unique IDs](#identifiers_unique_ids)\.\)
	`277`	+For example, the Amazon S3 bucket in the previous example that is created within `Stack2` results in an `AWS::S3::Bucket` resource\. The resource's logical ID is `Stack2MyBucket4DD88B4F` in the resulting AWS CloudFormation template\. \(For details on how this identifier is generated, see [Unique IDs](#identifiers_unique_ids)\.\)
`278`	`278`
`279`	`279`	`### Logical ID stability<a name="identifiers_logical_id_stability"></a>`
`280`	`280`