konokenj.cdk-api-mcp-server 0.40.0__py3-none-any.whl → 0.41.0__py3-none-any.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- cdk_api_mcp_server/__about__.py +1 -1
- cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/README.md/README.md +364 -16
- cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/aws-apigatewayv2/README.md +144 -0
- cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/aws-apigatewayv2/integ.usage-plan.ts +80 -0
- cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/aws-lambda/README.md +2 -2
- cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/aws-route53/integ.delete-existing-record-set.ts +0 -1
- cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/aws-s3-deployment/integ.bucket-deployment-cross-stack-ssm-source.ts +91 -0
- cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/aws-signer/integ.signing-profile.ts +5 -0
- cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/aws-stepfunctions-tasks/README.md +9 -3
- cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/core/README.md +2 -1893
- cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/cx-api/FEATURE_FLAGS.md +25 -0
- cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/cx-api/README.md +24 -1
- {konokenj_cdk_api_mcp_server-0.40.0.dist-info → konokenj_cdk_api_mcp_server-0.41.0.dist-info}/METADATA +2 -2
- {konokenj_cdk_api_mcp_server-0.40.0.dist-info → konokenj_cdk_api_mcp_server-0.41.0.dist-info}/RECORD +17 -15
- {konokenj_cdk_api_mcp_server-0.40.0.dist-info → konokenj_cdk_api_mcp_server-0.41.0.dist-info}/WHEEL +0 -0
- {konokenj_cdk_api_mcp_server-0.40.0.dist-info → konokenj_cdk_api_mcp_server-0.41.0.dist-info}/entry_points.txt +0 -0
- {konokenj_cdk_api_mcp_server-0.40.0.dist-info → konokenj_cdk_api_mcp_server-0.41.0.dist-info}/licenses/LICENSE.txt +0 -0
cdk_api_mcp_server/__about__.py
CHANGED
|
@@ -48,7 +48,6 @@ For CDK apps, declare them under the `dependencies` section. Use a caret so you
|
|
|
48
48
|
}
|
|
49
49
|
```
|
|
50
50
|
|
|
51
|
-
|
|
52
51
|
### Use in your code
|
|
53
52
|
|
|
54
53
|
#### Classic import
|
|
@@ -155,6 +154,86 @@ new MyStack(app, 'MyStack', {
|
|
|
155
154
|
For more information on bootstrapping accounts and customizing synthesis,
|
|
156
155
|
see [Bootstrapping in the CDK Developer Guide](https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html).
|
|
157
156
|
|
|
157
|
+
### STS Role Options
|
|
158
|
+
|
|
159
|
+
You can configure STS options that instruct the CDK CLI on which configuration should it use when assuming
|
|
160
|
+
the various roles that are involved in a deployment operation.
|
|
161
|
+
|
|
162
|
+
Refer to [the bootstrapping guide](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping-env.html#bootstrapping-env-roles) for further context.
|
|
163
|
+
|
|
164
|
+
These options are available via the `DefaultStackSynthesizer` properties:
|
|
165
|
+
|
|
166
|
+
```ts
|
|
167
|
+
class MyStack extends Stack {
|
|
168
|
+
constructor(scope: Construct, id: string, props: StackProps) {
|
|
169
|
+
super(scope, id, {
|
|
170
|
+
...props,
|
|
171
|
+
synthesizer: new DefaultStackSynthesizer({
|
|
172
|
+
deployRoleExternalId: '',
|
|
173
|
+
deployRoleAdditionalOptions: {
|
|
174
|
+
// https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters
|
|
175
|
+
},
|
|
176
|
+
fileAssetPublishingExternalId: '',
|
|
177
|
+
fileAssetPublishingRoleAdditionalOptions: {
|
|
178
|
+
// https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters
|
|
179
|
+
},
|
|
180
|
+
imageAssetPublishingExternalId: '',
|
|
181
|
+
imageAssetPublishingRoleAdditionalOptions: {
|
|
182
|
+
// https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters
|
|
183
|
+
},
|
|
184
|
+
lookupRoleExternalId: '',
|
|
185
|
+
lookupRoleAdditionalOptions: {
|
|
186
|
+
// https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters
|
|
187
|
+
},
|
|
188
|
+
})
|
|
189
|
+
});
|
|
190
|
+
}
|
|
191
|
+
}
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
> Note that the `*additionalOptions` property does not allow passing `ExternalId` or `RoleArn`, as these options
|
|
195
|
+
> have dedicated properties that configure them.
|
|
196
|
+
|
|
197
|
+
#### Session Tags
|
|
198
|
+
|
|
199
|
+
STS session tags are used to implement [Attribute-Based Access Control](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) (ABAC).
|
|
200
|
+
|
|
201
|
+
See [IAM tutorial: Define permissions to access AWS resources based on tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html).
|
|
202
|
+
|
|
203
|
+
You can pass session tags for each [role created during bootstrap](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping-env.html#bootstrapping-env-roles) via the `*additionalOptions` property:
|
|
204
|
+
|
|
205
|
+
```ts
|
|
206
|
+
class MyStack extends Stack {
|
|
207
|
+
constructor(parent: Construct, id: string, props: StackProps) {
|
|
208
|
+
super(parent, id, {
|
|
209
|
+
...props,
|
|
210
|
+
synthesizer: new DefaultStackSynthesizer({
|
|
211
|
+
deployRoleAdditionalOptions: {
|
|
212
|
+
Tags: [{ Key: 'Department', Value: 'Engineering' }]
|
|
213
|
+
},
|
|
214
|
+
fileAssetPublishingRoleAdditionalOptions: {
|
|
215
|
+
Tags: [{ Key: 'Department', Value: 'Engineering' }]
|
|
216
|
+
},
|
|
217
|
+
imageAssetPublishingRoleAdditionalOptions: {
|
|
218
|
+
Tags: [{ Key: 'Department', Value: 'Engineering' }]
|
|
219
|
+
},
|
|
220
|
+
lookupRoleAdditionalOptions: {
|
|
221
|
+
Tags: [{ Key: 'Department', Value: 'Engineering' }]
|
|
222
|
+
},
|
|
223
|
+
})
|
|
224
|
+
});
|
|
225
|
+
}
|
|
226
|
+
}
|
|
227
|
+
```
|
|
228
|
+
|
|
229
|
+
This will cause the CDK CLI to include session tags when assuming each of these roles during deployment.
|
|
230
|
+
Note that the trust policy of the role must contain permissions for the `sts:TagSession` action.
|
|
231
|
+
|
|
232
|
+
Refer to the [IAM user guide on session tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_permissions-required).
|
|
233
|
+
|
|
234
|
+
- If you are using a custom bootstrap template, make sure the template includes these permissions.
|
|
235
|
+
- If you are using the default bootstrap template from a CDK version lower than XXXX, you will need to rebootstrap your enviroment (once).
|
|
236
|
+
|
|
158
237
|
## Nested Stacks
|
|
159
238
|
|
|
160
239
|
[Nested stacks](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-nested-stacks.html) are stacks created as part of other stacks. You create a nested stack within another stack by using the `NestedStack` construct.
|
|
@@ -226,7 +305,7 @@ other.
|
|
|
226
305
|
> **This feature is currently experimental**
|
|
227
306
|
|
|
228
307
|
You can enable the Stack property `crossRegionReferences`
|
|
229
|
-
in order to access resources in a different stack
|
|
308
|
+
in order to access resources in a different stack *and* region. With this feature flag
|
|
230
309
|
enabled it is possible to do something like creating a CloudFront distribution in `us-east-2` and
|
|
231
310
|
an ACM certificate in `us-east-1`.
|
|
232
311
|
|
|
@@ -257,7 +336,7 @@ new cloudfront.Distribution(stack2, 'Distribution', {
|
|
|
257
336
|
});
|
|
258
337
|
```
|
|
259
338
|
|
|
260
|
-
When the AWS CDK determines that the resource is in a different stack
|
|
339
|
+
When the AWS CDK determines that the resource is in a different stack *and* is in a different
|
|
261
340
|
region, it will "export" the value by creating a custom resource in the producing stack which
|
|
262
341
|
creates SSM Parameters in the consuming region for each exported value. The parameters will be
|
|
263
342
|
created with the name '/cdk/exports/${consumingStackName}/${export-name}'.
|
|
@@ -522,15 +601,20 @@ new CustomResource(this, 'MyMagicalResource', {
|
|
|
522
601
|
resourceType: 'Custom::MyCustomResource', // must start with 'Custom::'
|
|
523
602
|
|
|
524
603
|
// the resource properties
|
|
604
|
+
// properties like serviceToken or serviceTimeout are ported into properties automatically
|
|
605
|
+
// try not to use key names similar to these or there will be a risk of overwriting those values
|
|
525
606
|
properties: {
|
|
526
607
|
Property1: 'foo',
|
|
527
|
-
Property2: 'bar'
|
|
608
|
+
Property2: 'bar',
|
|
528
609
|
},
|
|
529
610
|
|
|
530
611
|
// the ARN of the provider (SNS/Lambda) which handles
|
|
531
612
|
// CREATE, UPDATE or DELETE events for this resource type
|
|
532
613
|
// see next section for details
|
|
533
|
-
serviceToken: 'ARN'
|
|
614
|
+
serviceToken: 'ARN',
|
|
615
|
+
|
|
616
|
+
// the maximum time, in seconds, that can elapse before a custom resource operation times out.
|
|
617
|
+
serviceTimeout: Duration.seconds(60),
|
|
534
618
|
});
|
|
535
619
|
```
|
|
536
620
|
|
|
@@ -560,7 +644,7 @@ Legend:
|
|
|
560
644
|
- **Language**: which programming languages can be used to implement handlers.
|
|
561
645
|
- **Footprint**: how many resources are used by the provider framework itself.
|
|
562
646
|
|
|
563
|
-
|
|
647
|
+
#### A note about singletons
|
|
564
648
|
|
|
565
649
|
When defining resources for a custom resource provider, you will likely want to
|
|
566
650
|
define them as a *stack singleton* so that only a single instance of the
|
|
@@ -844,6 +928,17 @@ new CfnOutput(this, 'OutputName', {
|
|
|
844
928
|
});
|
|
845
929
|
```
|
|
846
930
|
|
|
931
|
+
You can also use the `exportValue` method to export values as stack outputs:
|
|
932
|
+
|
|
933
|
+
```ts
|
|
934
|
+
declare const stack: Stack;
|
|
935
|
+
|
|
936
|
+
stack.exportValue(myBucket.bucketName, {
|
|
937
|
+
name: 'TheAwesomeBucket',
|
|
938
|
+
description: 'The name of an S3 bucket',
|
|
939
|
+
});
|
|
940
|
+
```
|
|
941
|
+
|
|
847
942
|
[cfn-stack-output]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html
|
|
848
943
|
|
|
849
944
|
### Parameters
|
|
@@ -1105,7 +1200,7 @@ regionTable.findInMap(Aws.REGION, 'regionName');
|
|
|
1105
1200
|
```
|
|
1106
1201
|
|
|
1107
1202
|
An optional default value can also be passed to `findInMap`. If either key is not found in the map and the mapping is lazy, `findInMap` will return the default value and not render the mapping.
|
|
1108
|
-
If the mapping is not lazy or either key is an unresolved token, the call to `findInMap` will return a token that resolves to
|
|
1203
|
+
If the mapping is not lazy or either key is an unresolved token, the call to `findInMap` will return a token that resolves to
|
|
1109
1204
|
`{ "Fn::FindInMap": [ "MapName", "TopLevelKey", "SecondLevelKey", { "DefaultValue": "DefaultValue" } ] }`, and the mapping will be rendered.
|
|
1110
1205
|
Note that the `AWS::LanguageExtentions` transform is added to enable the default value functionality.
|
|
1111
1206
|
|
|
@@ -1146,6 +1241,75 @@ new CfnDynamicReference(
|
|
|
1146
1241
|
|
|
1147
1242
|
[cfn-dynamic-references]: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html
|
|
1148
1243
|
|
|
1244
|
+
## RemovalPolicies
|
|
1245
|
+
|
|
1246
|
+
The `RemovalPolicies` class provides a convenient way to manage removal policies for AWS CDK resources within a construct scope. It allows you to apply removal policies to multiple resources at once, with options to include or exclude specific resource types.
|
|
1247
|
+
|
|
1248
|
+
```typescript
|
|
1249
|
+
declare const scope: Construct;
|
|
1250
|
+
declare const parent: Construct;
|
|
1251
|
+
declare const bucket: s3.CfnBucket;
|
|
1252
|
+
|
|
1253
|
+
// Apply DESTROY policy to all resources in a scope
|
|
1254
|
+
RemovalPolicies.of(scope).destroy();
|
|
1255
|
+
|
|
1256
|
+
// Apply RETAIN policy to all resources in a scope
|
|
1257
|
+
RemovalPolicies.of(scope).retain();
|
|
1258
|
+
|
|
1259
|
+
// Apply SNAPSHOT policy to all resources in a scope
|
|
1260
|
+
RemovalPolicies.of(scope).snapshot();
|
|
1261
|
+
|
|
1262
|
+
// Apply RETAIN_ON_UPDATE_OR_DELETE policy to all resources in a scope
|
|
1263
|
+
RemovalPolicies.of(scope).retainOnUpdateOrDelete();
|
|
1264
|
+
|
|
1265
|
+
// Apply RETAIN policy only to specific resource types
|
|
1266
|
+
RemovalPolicies.of(parent).retain({
|
|
1267
|
+
applyToResourceTypes: [
|
|
1268
|
+
'AWS::DynamoDB::Table',
|
|
1269
|
+
bucket.cfnResourceType, // 'AWS::S3::Bucket'
|
|
1270
|
+
rds.CfnDBInstance.CFN_RESOURCE_TYPE_NAME, // 'AWS::RDS::DBInstance'
|
|
1271
|
+
],
|
|
1272
|
+
});
|
|
1273
|
+
|
|
1274
|
+
// Apply SNAPSHOT policy excluding specific resource types
|
|
1275
|
+
RemovalPolicies.of(scope).snapshot({
|
|
1276
|
+
excludeResourceTypes: ['AWS::Test::Resource'],
|
|
1277
|
+
});
|
|
1278
|
+
```
|
|
1279
|
+
|
|
1280
|
+
### RemovalPolicies vs MissingRemovalPolicies
|
|
1281
|
+
|
|
1282
|
+
CDK provides two different classes for managing removal policies:
|
|
1283
|
+
|
|
1284
|
+
- RemovalPolicies: Always applies the specified removal policy, overriding any existing policies.
|
|
1285
|
+
- MissingRemovalPolicies: Applies the removal policy only to resources that don't already have a policy set.
|
|
1286
|
+
|
|
1287
|
+
```typescript
|
|
1288
|
+
// Override any existing policies
|
|
1289
|
+
RemovalPolicies.of(scope).retain();
|
|
1290
|
+
|
|
1291
|
+
// Only apply to resources without existing policies
|
|
1292
|
+
MissingRemovalPolicies.of(scope).retain();
|
|
1293
|
+
```
|
|
1294
|
+
|
|
1295
|
+
### Aspect Priority
|
|
1296
|
+
|
|
1297
|
+
Both RemovalPolicies and MissingRemovalPolicies are implemented as [Aspects](#aspects). You can control the order in which they're applied using the priority parameter:
|
|
1298
|
+
|
|
1299
|
+
```typescript
|
|
1300
|
+
declare const stack: Stack;
|
|
1301
|
+
|
|
1302
|
+
// Apply in a specific order based on priority
|
|
1303
|
+
RemovalPolicies.of(stack).retain({ priority: 100 });
|
|
1304
|
+
RemovalPolicies.of(stack).destroy({ priority: 200 }); // This will override the RETAIN policy
|
|
1305
|
+
```
|
|
1306
|
+
|
|
1307
|
+
For RemovalPolicies, the policies are applied in order of aspect execution, with the last applied policy overriding previous ones. The priority only affects the order in which aspects are applied during synthesis.
|
|
1308
|
+
|
|
1309
|
+
#### Note
|
|
1310
|
+
|
|
1311
|
+
When using MissingRemovalPolicies with priority, a warning will be issued as this can lead to unexpected behavior. This is because MissingRemovalPolicies only applies to resources without existing policies, making priority less relevant.
|
|
1312
|
+
|
|
1149
1313
|
### Template Options & Transform
|
|
1150
1314
|
|
|
1151
1315
|
CloudFormation templates support a number of options, including which Macros or
|
|
@@ -1239,6 +1403,27 @@ const stack = new Stack(app, 'StackName', {
|
|
|
1239
1403
|
});
|
|
1240
1404
|
```
|
|
1241
1405
|
|
|
1406
|
+
### Receiving CloudFormation Stack Events
|
|
1407
|
+
|
|
1408
|
+
You can add one or more SNS Topic ARNs to any Stack:
|
|
1409
|
+
|
|
1410
|
+
```ts
|
|
1411
|
+
const stack = new Stack(app, 'StackName', {
|
|
1412
|
+
notificationArns: ['arn:aws:sns:us-east-1:123456789012:Topic'],
|
|
1413
|
+
});
|
|
1414
|
+
```
|
|
1415
|
+
|
|
1416
|
+
Stack events will be sent to any SNS Topics in this list. These ARNs are added to those specified using
|
|
1417
|
+
the `--notification-arns` command line option.
|
|
1418
|
+
|
|
1419
|
+
Note that in order to do delete notification ARNs entirely, you must pass an empty array ([]) instead of omitting it.
|
|
1420
|
+
If you omit the property, no action on existing ARNs will take place.
|
|
1421
|
+
|
|
1422
|
+
> [!NOTE]
|
|
1423
|
+
> Adding the `notificationArns` property (or using the `--notification-arns` CLI options) will **override**
|
|
1424
|
+
> any existing ARNs configured on the stack. If you have an external system managing notification ARNs,
|
|
1425
|
+
> either migrate to use this mechanism, or avoid specfying notification ARNs with the CDK.
|
|
1426
|
+
|
|
1242
1427
|
### CfnJson
|
|
1243
1428
|
|
|
1244
1429
|
`CfnJson` allows you to postpone the resolution of a JSON blob from
|
|
@@ -1287,16 +1472,16 @@ Set the context key `@aws-cdk/core:stackResourceLimit` with the proper value, be
|
|
|
1287
1472
|
|
|
1288
1473
|
### Template Indentation
|
|
1289
1474
|
|
|
1290
|
-
The AWS CloudFormation templates generated by CDK include indentation by default.
|
|
1291
|
-
Indentation makes the templates more readable, but also increases their size,
|
|
1475
|
+
The AWS CloudFormation templates generated by CDK include indentation by default.
|
|
1476
|
+
Indentation makes the templates more readable, but also increases their size,
|
|
1292
1477
|
and CloudFormation templates cannot exceed 1MB.
|
|
1293
1478
|
|
|
1294
1479
|
It's possible to reduce the size of your templates by suppressing indentation.
|
|
1295
1480
|
|
|
1296
1481
|
To do this for all templates, set the context key `@aws-cdk/core:suppressTemplateIndentation` to `true`.
|
|
1297
1482
|
|
|
1298
|
-
To do this for a specific stack, add a `suppressTemplateIndentation: true` property to the
|
|
1299
|
-
stack's `StackProps` parameter. You can also set this property to `false` to override
|
|
1483
|
+
To do this for a specific stack, add a `suppressTemplateIndentation: true` property to the
|
|
1484
|
+
stack's `StackProps` parameter. You can also set this property to `false` to override
|
|
1300
1485
|
the context key setting.
|
|
1301
1486
|
|
|
1302
1487
|
## App Context
|
|
@@ -1341,7 +1526,7 @@ new App({
|
|
|
1341
1526
|
cdk synth --context @aws-cdk/core:newStyleStackSynthesis=true
|
|
1342
1527
|
```
|
|
1343
1528
|
|
|
1344
|
-
|
|
1529
|
+
#### `cdk.json`
|
|
1345
1530
|
|
|
1346
1531
|
```json
|
|
1347
1532
|
{
|
|
@@ -1351,7 +1536,7 @@ _cdk.json_
|
|
|
1351
1536
|
}
|
|
1352
1537
|
```
|
|
1353
1538
|
|
|
1354
|
-
|
|
1539
|
+
#### `cdk.context.json`
|
|
1355
1540
|
|
|
1356
1541
|
```json
|
|
1357
1542
|
{
|
|
@@ -1359,7 +1544,7 @@ _cdk.context.json_
|
|
|
1359
1544
|
}
|
|
1360
1545
|
```
|
|
1361
1546
|
|
|
1362
|
-
|
|
1547
|
+
#### `~/.cdk.json`
|
|
1363
1548
|
|
|
1364
1549
|
```json
|
|
1365
1550
|
{
|
|
@@ -1398,7 +1583,7 @@ generated CloudFormation templates against your policies immediately after
|
|
|
1398
1583
|
synthesis. If there are any violations, the synthesis will fail and a report
|
|
1399
1584
|
will be printed to the console or to a file (see below).
|
|
1400
1585
|
|
|
1401
|
-
>
|
|
1586
|
+
> [!NOTE]
|
|
1402
1587
|
> This feature is considered experimental, and both the plugin API and the
|
|
1403
1588
|
> format of the validation report are subject to change in the future.
|
|
1404
1589
|
|
|
@@ -1436,7 +1621,7 @@ validation.
|
|
|
1436
1621
|
> etc. It's your responsibility as the consumer of a plugin to verify that it is
|
|
1437
1622
|
> secure to use.
|
|
1438
1623
|
|
|
1439
|
-
By default, the report will be printed in a human
|
|
1624
|
+
By default, the report will be printed in a human-readable format. If you want a
|
|
1440
1625
|
report in JSON format, enable it using the `@aws-cdk/core:validationReportJson`
|
|
1441
1626
|
context passing it directly to the application:
|
|
1442
1627
|
|
|
@@ -1450,6 +1635,18 @@ Alternatively, you can set this context key-value pair using the `cdk.json` or
|
|
|
1450
1635
|
`cdk.context.json` files in your project directory (see
|
|
1451
1636
|
[Runtime context](https://docs.aws.amazon.com/cdk/v2/guide/context.html)).
|
|
1452
1637
|
|
|
1638
|
+
It is also possible to enable both JSON and human-readable formats by setting
|
|
1639
|
+
`@aws-cdk/core:validationReportPrettyPrint` context key explicitly:
|
|
1640
|
+
|
|
1641
|
+
```ts
|
|
1642
|
+
const app = new App({
|
|
1643
|
+
context: {
|
|
1644
|
+
'@aws-cdk/core:validationReportJson': true,
|
|
1645
|
+
'@aws-cdk/core:validationReportPrettyPrint': true,
|
|
1646
|
+
},
|
|
1647
|
+
});
|
|
1648
|
+
```
|
|
1649
|
+
|
|
1453
1650
|
If you choose the JSON format, the CDK will print the policy validation report
|
|
1454
1651
|
to a file called `policy-validation-report.json` in the cloud assembly
|
|
1455
1652
|
directory. For the default, human-readable format, the report will be printed to
|
|
@@ -1546,6 +1743,157 @@ warning by the `id`.
|
|
|
1546
1743
|
Annotations.of(this).acknowledgeWarning('IAM:Group:MaxPoliciesExceeded', 'Account has quota increased to 20');
|
|
1547
1744
|
```
|
|
1548
1745
|
|
|
1746
|
+
### Acknowledging Infos
|
|
1747
|
+
|
|
1748
|
+
Informational messages can also be emitted and acknowledged. Use `addInfoV2()`
|
|
1749
|
+
to add an info message that can later be suppressed with `acknowledgeInfo()`.
|
|
1750
|
+
Unlike warnings, info messages are not affected by the `--strict` mode and will never cause synthesis to fail.
|
|
1751
|
+
|
|
1752
|
+
```ts
|
|
1753
|
+
Annotations.of(this).addInfoV2('my-lib:Construct.someInfo', 'Some message explaining the info');
|
|
1754
|
+
Annotations.of(this).acknowledgeInfo('my-lib:Construct.someInfo', 'This info can be ignored');
|
|
1755
|
+
```
|
|
1756
|
+
|
|
1757
|
+
## Aspects
|
|
1758
|
+
|
|
1759
|
+
[Aspects](https://docs.aws.amazon.com/cdk/v2/guide/aspects.html) is a feature in CDK that allows you to apply operations or transformations across all
|
|
1760
|
+
constructs in a construct tree. Common use cases include tagging resources, enforcing encryption on S3 Buckets, or applying specific security or
|
|
1761
|
+
compliance rules to all resources in a stack.
|
|
1762
|
+
|
|
1763
|
+
Conceptually, there are two types of Aspects:
|
|
1764
|
+
|
|
1765
|
+
- **Read-only aspects** scan the construct tree but do not make changes to the tree. Common use cases of read-only aspects include performing validations
|
|
1766
|
+
(for example, enforcing that all S3 Buckets have versioning enabled) and logging (for example, collecting information about all deployed resources for
|
|
1767
|
+
audits or compliance).
|
|
1768
|
+
- **Mutating aspects** either (1.) add new nodes or (2.) mutate existing nodes of the tree in-place. One commonly used mutating Aspect is adding Tags to
|
|
1769
|
+
resources. An example of an Aspect that adds a node is one that automatically adds a security group to every EC2 instance in the construct tree if
|
|
1770
|
+
no default is specified.
|
|
1771
|
+
|
|
1772
|
+
Here is a simple example of creating and applying an Aspect on a Stack to enable versioning on all S3 Buckets:
|
|
1773
|
+
|
|
1774
|
+
```ts
|
|
1775
|
+
class EnableBucketVersioning implements IAspect {
|
|
1776
|
+
visit(node: IConstruct) {
|
|
1777
|
+
if (node instanceof s3.CfnBucket) {
|
|
1778
|
+
node.versioningConfiguration = {
|
|
1779
|
+
status: 'Enabled'
|
|
1780
|
+
};
|
|
1781
|
+
}
|
|
1782
|
+
}
|
|
1783
|
+
}
|
|
1784
|
+
|
|
1785
|
+
const app = new App();
|
|
1786
|
+
const stack = new MyStack(app, 'MyStack');
|
|
1787
|
+
|
|
1788
|
+
// Apply the aspect to enable versioning on all S3 Buckets
|
|
1789
|
+
Aspects.of(stack).add(new EnableBucketVersioning());
|
|
1790
|
+
```
|
|
1791
|
+
|
|
1792
|
+
### Aspect Stabilization
|
|
1793
|
+
|
|
1794
|
+
The modern behavior is that Aspects automatically run on newly added nodes to the construct tree. This is controlled by the
|
|
1795
|
+
flag `@aws-cdk/core:aspectStabilization`, which is default for new projects (since version 2.172.0).
|
|
1796
|
+
|
|
1797
|
+
The old behavior of Aspects (without stabilization) was that Aspect invocation runs once on the entire construct
|
|
1798
|
+
tree. This meant that nested Aspects (Aspects that create new Aspects) are not invoked and nodes created by Aspects at a higher level of the construct tree are not visited.
|
|
1799
|
+
|
|
1800
|
+
To enable the stabilization behavior for older versions, use this feature by putting the following into your `cdk.context.json`:
|
|
1801
|
+
|
|
1802
|
+
```json
|
|
1803
|
+
{
|
|
1804
|
+
"@aws-cdk/core:aspectStabilization": true
|
|
1805
|
+
}
|
|
1806
|
+
```
|
|
1807
|
+
|
|
1808
|
+
### Aspect Priorities
|
|
1809
|
+
|
|
1810
|
+
Users can specify the order in which Aspects are applied on a construct by using the optional priority parameter when applying an Aspect. Priority
|
|
1811
|
+
values must be non-negative integers, where a higher number means the Aspect will be applied later, and a lower number means it will be applied sooner.
|
|
1812
|
+
|
|
1813
|
+
By default, newly created nodes always inherit aspects. Priorities are mainly for ordering between mutating aspects on the construct tree.
|
|
1814
|
+
|
|
1815
|
+
CDK provides standard priority values for mutating and readonly aspects to help ensure consistency across different construct libraries.
|
|
1816
|
+
Note that Aspects that have same priority value are not guaranteed to be executed
|
|
1817
|
+
in a consistent order.
|
|
1818
|
+
|
|
1819
|
+
```ts
|
|
1820
|
+
/**
|
|
1821
|
+
* Default Priority values for Aspects.
|
|
1822
|
+
*/
|
|
1823
|
+
class AspectPriority {
|
|
1824
|
+
/**
|
|
1825
|
+
* Suggested priority for Aspects that mutate the construct tree.
|
|
1826
|
+
*/
|
|
1827
|
+
static readonly MUTATING: number = 200;
|
|
1828
|
+
|
|
1829
|
+
/**
|
|
1830
|
+
* Suggested priority for Aspects that only read the construct tree.
|
|
1831
|
+
*/
|
|
1832
|
+
static readonly READONLY: number = 1000;
|
|
1833
|
+
|
|
1834
|
+
/**
|
|
1835
|
+
* Default priority for Aspects that are applied without a priority.
|
|
1836
|
+
*/
|
|
1837
|
+
static readonly DEFAULT: number = 500;
|
|
1838
|
+
}
|
|
1839
|
+
```
|
|
1840
|
+
|
|
1841
|
+
If no priority is provided, the default value will be 500. This ensures that aspects without a specified priority run after mutating aspects but before
|
|
1842
|
+
any readonly aspects.
|
|
1843
|
+
|
|
1844
|
+
Correctly applying Aspects with priority values ensures that mutating aspects (such as adding tags or resources) run before validation aspects. This allows users to avoid misconfigurations and ensure that the final
|
|
1845
|
+
construct tree is fully validated before being synthesized.
|
|
1846
|
+
|
|
1847
|
+
### Applying Aspects with Priority
|
|
1848
|
+
|
|
1849
|
+
```ts
|
|
1850
|
+
class MutatingAspect implements IAspect {
|
|
1851
|
+
visit(node: IConstruct) {
|
|
1852
|
+
// Modifies a resource in some way
|
|
1853
|
+
}
|
|
1854
|
+
}
|
|
1855
|
+
|
|
1856
|
+
class ValidationAspect implements IAspect {
|
|
1857
|
+
visit(node: IConstruct) {
|
|
1858
|
+
// Perform some readonly validation on the cosntruct tree
|
|
1859
|
+
}
|
|
1860
|
+
}
|
|
1861
|
+
|
|
1862
|
+
const stack = new Stack();
|
|
1863
|
+
|
|
1864
|
+
Aspects.of(stack).add(new MutatingAspect(), { priority: AspectPriority.MUTATING } ); // Run first (mutating aspects)
|
|
1865
|
+
Aspects.of(stack).add(new ValidationAspect(), { priority: AspectPriority.READONLY } ); // Run later (readonly aspects)
|
|
1866
|
+
```
|
|
1867
|
+
|
|
1868
|
+
### Inspecting applied aspects and changing priorities
|
|
1869
|
+
|
|
1870
|
+
We also give customers the ability to view all of their applied aspects and override the priority on these aspects.
|
|
1871
|
+
The `AspectApplication` class represents an Aspect that is applied to a node of the construct tree with a priority.
|
|
1872
|
+
|
|
1873
|
+
Users can access AspectApplications on a node by calling `applied` from the Aspects class as follows:
|
|
1874
|
+
|
|
1875
|
+
```ts
|
|
1876
|
+
declare const root: Construct;
|
|
1877
|
+
const app = new App();
|
|
1878
|
+
const stack = new MyStack(app, 'MyStack');
|
|
1879
|
+
|
|
1880
|
+
Aspects.of(stack).add(new MyAspect());
|
|
1881
|
+
|
|
1882
|
+
let aspectApplications: AspectApplication[] = Aspects.of(root).applied;
|
|
1883
|
+
|
|
1884
|
+
for (const aspectApplication of aspectApplications) {
|
|
1885
|
+
// The aspect we are applying
|
|
1886
|
+
console.log(aspectApplication.aspect);
|
|
1887
|
+
// The construct we are applying the aspect to
|
|
1888
|
+
console.log(aspectApplication.construct);
|
|
1889
|
+
// The priority it was applied with
|
|
1890
|
+
console.log(aspectApplication.priority);
|
|
1891
|
+
|
|
1892
|
+
// Change the priority
|
|
1893
|
+
aspectApplication.priority = 700;
|
|
1894
|
+
}
|
|
1895
|
+
```
|
|
1896
|
+
|
|
1549
1897
|
## Blueprint Property Injection
|
|
1550
1898
|
|
|
1551
1899
|
The goal of Blueprint Property Injection is to provide builders an automatic way to set default property values.
|
|
@@ -18,6 +18,7 @@
|
|
|
18
18
|
- [WebSocket API](#websocket-api)
|
|
19
19
|
- [Manage Connections Permission](#manage-connections-permission)
|
|
20
20
|
- [Managing access to WebSocket APIs](#managing-access-to-websocket-apis)
|
|
21
|
+
- [Usage Plan and API Keys](#usage-plan-and-api-keys)
|
|
21
22
|
|
|
22
23
|
## Introduction
|
|
23
24
|
|
|
@@ -589,3 +590,146 @@ new apigwv2.HttpStage(this, 'Stage', {
|
|
|
589
590
|
detailedMetricsEnabled: true,
|
|
590
591
|
});
|
|
591
592
|
```
|
|
593
|
+
## Usage Plan and API Keys
|
|
594
|
+
|
|
595
|
+
A usage plan specifies who can access one or more deployed WebSocket API stages, and the rate at which they can be accessed. The plan uses API keys to
|
|
596
|
+
identify API clients and meters access to the associated API stages for each key. Usage plans also allow configuring throttling limits and quota limits that are
|
|
597
|
+
enforced on individual client API keys.
|
|
598
|
+
|
|
599
|
+
The following example shows how to create and associate a usage plan and an API key for WebSocket APIs:
|
|
600
|
+
|
|
601
|
+
```ts
|
|
602
|
+
const apiKey = new apigwv2.ApiKey(this, "ApiKey");
|
|
603
|
+
|
|
604
|
+
const usagePlan = new apigwv2.UsagePlan(this, "UsagePlan", {
|
|
605
|
+
usagePlanName: "WebSocketUsagePlan",
|
|
606
|
+
throttle: {
|
|
607
|
+
rateLimit: 10,
|
|
608
|
+
burstLimit: 2
|
|
609
|
+
}
|
|
610
|
+
});
|
|
611
|
+
|
|
612
|
+
usagePlan.addApiKey(apiKey);
|
|
613
|
+
```
|
|
614
|
+
|
|
615
|
+
To associate a plan to a given WebSocketAPI stage:
|
|
616
|
+
|
|
617
|
+
```ts
|
|
618
|
+
const api = new apigwv2.WebSocketApi(this, 'my-api');
|
|
619
|
+
const stage = new apigwv2.WebSocketStage(this, 'my-stage', {
|
|
620
|
+
webSocketApi: api,
|
|
621
|
+
stageName: 'dev',
|
|
622
|
+
});
|
|
623
|
+
|
|
624
|
+
const usagePlan = new apigwv2.UsagePlan(this, 'my-usage-plan', {
|
|
625
|
+
usagePlanName: 'Basic',
|
|
626
|
+
});
|
|
627
|
+
|
|
628
|
+
usagePlan.addApiStage({
|
|
629
|
+
api: api,
|
|
630
|
+
stage: stage,
|
|
631
|
+
});
|
|
632
|
+
```
|
|
633
|
+
Existing usage plans can be imported into a CDK app using its id.
|
|
634
|
+
|
|
635
|
+
```ts
|
|
636
|
+
const usagePlan: apigwv2.IUsagePlan = apigwv2.UsagePlan.fromUsagePlanId(this, 'imported-usage-plan', '<usage-plan-id>');
|
|
637
|
+
```
|
|
638
|
+
|
|
639
|
+
The name and value of the API Key can be specified at creation; if not provided, a name and a value will be automatically generated by API Gateway.
|
|
640
|
+
|
|
641
|
+
```ts
|
|
642
|
+
// Auto-generated name and value
|
|
643
|
+
const autoKey = new apigwv2.ApiKey(this, 'AutoKey');
|
|
644
|
+
|
|
645
|
+
// Explicit name and value
|
|
646
|
+
const explicitKey = new apigwv2.ApiKey(this, 'ExplicitKey', {
|
|
647
|
+
apiKeyName: 'MyWebSocketApiKey',
|
|
648
|
+
value: 'MyApiKeyThatIsAtLeast20Characters',
|
|
649
|
+
});
|
|
650
|
+
```
|
|
651
|
+
|
|
652
|
+
Existing API keys can also be imported into a CDK app using its id.
|
|
653
|
+
|
|
654
|
+
```ts
|
|
655
|
+
const importedKey = apigwv2.ApiKey.fromApiKeyId(this, 'imported-key', '<api-key-id>');
|
|
656
|
+
```
|
|
657
|
+
|
|
658
|
+
The "grant" methods can be used to give prepackaged sets of permissions to other resources. The
|
|
659
|
+
following code provides read permission to an API key.
|
|
660
|
+
|
|
661
|
+
```ts
|
|
662
|
+
import * as iam from 'aws-cdk-lib/aws-iam';
|
|
663
|
+
|
|
664
|
+
const user = new iam.User(this, 'User');
|
|
665
|
+
const apiKey = new apigwv2.ApiKey(this, 'ApiKey', {
|
|
666
|
+
customerId: 'test-customer',
|
|
667
|
+
});
|
|
668
|
+
apiKey.grantRead(user);
|
|
669
|
+
```
|
|
670
|
+
|
|
671
|
+
### Adding an API Key to an imported WebSocketApi
|
|
672
|
+
|
|
673
|
+
API Keys for WebSocket APIs are associated through Usage Plans, not directly to stages. When you import a WebSocketApi, you need to create a Usage Plan that references the
|
|
674
|
+
imported stage and then associate the API key with that Usage Plan.
|
|
675
|
+
|
|
676
|
+
```ts
|
|
677
|
+
declare const webSocketApi: apigwv2.IWebSocketApi;
|
|
678
|
+
|
|
679
|
+
const importedStage = apigwv2.WebSocketStage.fromWebSocketStageAttributes(this, 'imported-stage', {
|
|
680
|
+
stageName: 'myStage',
|
|
681
|
+
api: webSocketApi,
|
|
682
|
+
});
|
|
683
|
+
|
|
684
|
+
const apiKey = new apigwv2.ApiKey(this, 'MyApiKey');
|
|
685
|
+
|
|
686
|
+
const usagePlan = new apigwv2.UsagePlan(this, 'MyUsagePlan', {
|
|
687
|
+
apiStages: [{ api: webSocketApi, stage: importedStage }],
|
|
688
|
+
});
|
|
689
|
+
|
|
690
|
+
usagePlan.addApiKey(apiKey);
|
|
691
|
+
```
|
|
692
|
+
|
|
693
|
+
### Multiple API Keys
|
|
694
|
+
|
|
695
|
+
It is possible to specify multiple API keys for a given Usage Plan, by calling `usagePlan.addApiKey()`.
|
|
696
|
+
|
|
697
|
+
When using multiple API keys, you may need to ensure that the CloudFormation logical ids of the API keys remain consistent across deployments. You can set the logical id as part of the `addApiKey()` method
|
|
698
|
+
|
|
699
|
+
```ts
|
|
700
|
+
declare const usagePlan: apigwv2.UsagePlan;
|
|
701
|
+
declare const apiKey: apigwv2.ApiKey;
|
|
702
|
+
|
|
703
|
+
usagePlan.addApiKey(apiKey, {
|
|
704
|
+
overrideLogicalId: 'MyCustomLogicalId',
|
|
705
|
+
});
|
|
706
|
+
```
|
|
707
|
+
|
|
708
|
+
### Rate Limited API Key
|
|
709
|
+
|
|
710
|
+
In scenarios where you need to create a single api key and configure rate limiting for it, you can use `RateLimitedApiKey`.
|
|
711
|
+
This construct lets you specify rate limiting properties which should be applied only to the api key being created.
|
|
712
|
+
The API key created has the specified rate limits, such as quota and throttles, applied.
|
|
713
|
+
|
|
714
|
+
The following example shows how to use a rate limited api key :
|
|
715
|
+
|
|
716
|
+
```ts
|
|
717
|
+
declare const api: apigwv2.WebSocketApi;
|
|
718
|
+
declare const stage: apigwv2.WebSocketStage;
|
|
719
|
+
|
|
720
|
+
const key = new apigwv2.RateLimitedApiKey(this, 'rate-limited-api-key', {
|
|
721
|
+
customerId: 'test-customer',
|
|
722
|
+
apiStages: [{
|
|
723
|
+
api: api,
|
|
724
|
+
stage: stage
|
|
725
|
+
}],
|
|
726
|
+
quota: {
|
|
727
|
+
limit: 10000,
|
|
728
|
+
period: apigwv2.Period.MONTH
|
|
729
|
+
},
|
|
730
|
+
throttle: {
|
|
731
|
+
rateLimit: 100,
|
|
732
|
+
burstLimit: 200
|
|
733
|
+
}
|
|
734
|
+
});
|
|
735
|
+
```
|