konokenj.cdk-api-mcp-server 0.45.0__py3-none-any.whl → 0.47.0__py3-none-any.whl

cdk_api_mcp_server/__about__.py

@@ -1,4 +1,4 @@
 # SPDX-FileCopyrightText: 2025-present Kenji Kono <konoken@amazon.co.jp>
 #
 # SPDX-License-Identifier: MIT
-__version__ = "0.45.0"
+__version__ = "0.47.0"

cdk_api_mcp_server/resources/aws-cdk/constructs/@aws-cdk/aws-elasticache-alpha/README.md

@@ -0,0 +1,421 @@
+# ElastiCache CDK Construct Library
+<!--BEGIN STABILITY BANNER-->
+
+---
+
+![cdk-constructs: Experimental](https://img.shields.io/badge/cdk--constructs-experimental-important.svg?style=for-the-badge)
+
+> The APIs of higher level constructs in this module are experimental and under active development.
+> They are subject to non-backward compatible changes or removal in any future version. These are
+> not subject to the [Semantic Versioning](https://semver.org/) model and breaking changes will be
+> announced in the release notes. This means that while you may use them, you may need to update
+> your source code when upgrading to a newer version of this package.
+
+---
+
+<!--END STABILITY BANNER-->
+
+This module has constructs for [Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/WhatIs.html).
+
+* The `ServerlessCache` construct facilitates the creation and management of serverless cache.
+* The `User` and `UserGroup` constructs facilitate the creation and management of users for the cache.
+
+## Serverless Cache
+
+Amazon ElastiCache Serverless is a serverless option that automatically scales cache capacity based on application traffic patterns. You can create a serverless cache using the `ServerlessCache` construct:
+
+```ts
+const vpc = new ec2.Vpc(this, 'VPC');
+ 
+const cache = new elasticache.ServerlessCache(this, 'ServerlessCache', {
+  vpc,
+});
+```
+
+### Connecting to serverless cache
+
+To control who can access the serverless cache by the security groups, use the `.connections` attribute.
+
+The serverless cache has a default port `6379`.
+
+This example allows an EC2 instance to connect to the serverless cache:
+
+```ts
+declare const serverlessCache: elasticache.ServerlessCache;
+declare const instance: ec2.Instance;
+ 
+// allow the EC2 instance to connect to serverless cache on default port 6379
+serverlessCache.connections.allowDefaultPortFrom(instance);
+```
+
+### Cache usage limits
+
+You can configure usage limits on both cache data storage and ECPU/second for your cache to control costs and ensure predictable performance.
+
+**Configuration options:**
+
+* **Maximum limits**: Ensure your cache usage never exceeds the configured maximum
+* **Minimum limits**: Reserve a baseline level of resources for consistent performance
+* **Both**: Define a range where your cache usage will operate
+
+For more infomation, see [Setting scaling limits to manage costs](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Scaling.html#Pre-Scaling).
+
+```ts
+declare const vpc: ec2.Vpc;
+ 
+const serverlessCache = new elasticache.ServerlessCache(this, 'ServerlessCache', {
+  engine: elasticache.CacheEngine.VALKEY_LATEST,
+  vpc,
+  cacheUsageLimits: {
+    // cache data storage limits (GB)
+    dataStorageMinimumSize: Size.gibibytes(2), // minimum: 1GB
+    dataStorageMaximumSize: Size.gibibytes(3), // maximum: 5000GB
+    // rate limits (ECPU/second)
+    requestRateLimitMinimum: 1000, // minimum: 1000
+    requestRateLimitMaximum: 10000, // maximum: 15000000
+  },
+});
+```
+
+### Backups and restore
+
+You can enable automatic backups for serverless cache.
+When automatic backups are enabled, ElastiCache creates a backup of the cache on a daily basis.
+
+Also you can set the backup window for any time when it's most convenient.
+If you don't specify a backup window, ElastiCache assigns one automatically.
+
+For more information, see [Scheduling automatic backups](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/backups-automatic.html).
+
+To enable automatic backups, set the `backupRetentionLimit` property. You can also specify the snapshot creation time by setting `backupTime` property:
+
+```ts
+declare const vpc: ec2.Vpc;
+ 
+const serverlessCache = new elasticache.ServerlessCache(this, 'ServerlessCache', {
+  backup: {
+    // enable automatic backups and set the retention period to 6 days
+    backupRetentionLimit: 6,
+    // set the backup window to 9:00 AM UTC
+    backupTime: events.Schedule.cron({
+      hour: '9',
+      minute: '0',
+    }),
+  },
+  vpc,
+});
+```
+
+You can create a final backup by setting `backupNameBeforeDeletion` property.
+
+```ts 
+declare const vpc: ec2.Vpc;
+ 
+const serverlessCache = new elasticache.ServerlessCache(this, 'ServerlessCache', {
+  engine: elasticache.CacheEngine.VALKEY_LATEST,
+  backup: {
+    // set a backup name before deleting a cache
+    backupNameBeforeDeletion: "my-final-backup-name",
+  },
+  vpc,
+});
+```
+
+You can restore from backups by setting snapshot ARNs to `backupArnsToRestore` property:
+
+```ts
+declare const vpc: ec2.Vpc;
+ 
+const serverlessCache = new elasticache.ServerlessCache(this, 'ServerlessCache', {
+  engine: elasticache.CacheEngine.VALKEY_LATEST,
+  backup: {
+    // set the backup(s) to restore
+    backupArnsToRestore: ['arn:aws:elasticache:us-east-1:123456789012:serverlesscachesnapshot:my-final-backup-name'],
+  },
+  vpc,
+});
+```
+
+### Encryption at rest
+
+At-rest encryption is always enabled for Serverless Cache. There are two encryption options:
+
+* **Default**: When no `kmsKey` is specified (left as `undefined`), AWS owned KMS keys are used automatically
+* **Customer Managed Key**: Create a KMS key first, then pass it to the cache via the `kmsKey` property
+
+### Customer Managed Key for encryption at rest
+
+ElastiCache supports symmetric Customer Managed key (CMK) for encryption at rest.
+
+For more information, see [Using customer managed keys from AWS KMS](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/at-rest-encryption.html#using-customer-managed-keys-for-elasticache-security).
+
+To use CMK, set your CMK to the `kmsKey` property:
+
+```ts
+import { Key } from 'aws-cdk-lib/aws-kms';
+ 
+declare const kmsKey: Key;
+declare const vpc: ec2.Vpc;
+ 
+const serverlessCache = new elasticache.ServerlessCache(this, 'ServerlessCache', {
+  engine: elasticache.CacheEngine.VALKEY_LATEST,
+  serverlessCacheName: 'my-serverless-cache',
+  vpc,
+  // set Customer Managed Key
+  kmsKey,
+});
+```
+
+### Metrics and monitoring
+
+You can monitor your serverless cache using CloudWatch Metrics via the `metric` method.
+
+For more information about serverless cache metrics, see [Serverless metrics and events for Valkey and Redis OSS](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/serverless-metrics-events-redis.html) and [Serverless metrics and events for Memcached](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/serverless-metrics-events.memcached.html).
+
+```ts
+declare const serverlessCache: elasticache.ServerlessCache;
+ 
+// The 5 minutes average of the total number of successful read-only key lookups in the cache.
+const cacheHits = serverlessCache.metricCacheHitCount();
+ 
+// The 5 minutes average of the total number of bytes used by the data stored in the cache.
+const bytesUsedForCache = serverlessCache.metricDataStored();
+ 
+// The 5 minutes average of the total number of ElastiCacheProcessingUnits (ECPUs) consumed by the requests executed on the cache.
+const elastiCacheProcessingUnits = serverlessCache.metricProcessingUnitsConsumed();
+ 
+// Create an alarm for ECPUs.
+elastiCacheProcessingUnits.createAlarm(this, 'ElastiCacheProcessingUnitsAlarm', {
+  threshold: 50,
+  evaluationPeriods: 1,
+});
+```
+
+### Import an existing serverless cache
+
+To import an existing ServerlessCache, use the `ServerlessCache.fromServerlessCacheAttributes` method:
+
+```ts
+declare const securityGroup: ec2.SecurityGroup;
+ 
+const importedServerlessCache = elasticache.ServerlessCache.fromServerlessCacheAttributes(this, 'ImportedServerlessCache', {
+  serverlessCacheName: 'my-serverless-cache',
+  securityGroups: [securityGroup],
+});
+```
+
+## User and User Group
+
+Setup required properties and create:
+
+```ts
+const newDefaultUser = new elasticache.NoPasswordUser(this, 'NoPasswordUser', {
+  userId: 'default',
+  accessControl: elasticache.AccessControl.fromAccessString("on ~* +@all"),
+})
+ 
+const userGroup = new elasticache.UserGroup(this, 'UserGroup', {
+  users: [newDefaultUser],
+});
+```
+
+### RBAC
+
+In Valkey 7.2 and onward and Redis OSS 6.0 onward you can use a feature called Role-Based Access Control (RBAC). RBAC is also the only way to control access to serverless caches.
+
+RBAC enables you to control cache access through user groups. These user groups are designed as a way to organize access to caches.
+
+For more information, see [Role-Based Access Control (RBAC)](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Clusters.RBAC.html).
+
+To enable RBAC for ElastiCache with Valkey or Redis OSS, you take the following steps:
+
+* Create users.
+* Create a user group and add users to the user group.
+* Assign the user group to a cache.
+
+### Create users
+
+First, you need to create users by using `IamUser`, `PasswordUser` or `NoPasswordUser` construct.
+
+With RBAC, you create users and assign them specific permissions by using `accessString` property.
+
+For more information, see [Specifying Permissions Using an Access String](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Clusters.RBAC.html#Access-string).
+
+You can create an IAM-enabled user by using `IamUser` construct:
+
+```ts
+const user = new elasticache.IamUser(this, 'User', {
+  // set user engine
+  engine: elasticache.UserEngine.REDIS,
+    
+  // set user id
+  userId: 'my-user',
+ 
+  // set username
+  userName: 'my-user',
+ 
+  // set access string
+  accessControl: elasticache.AccessControl.fromAccessString("on ~* +@all"),
+});
+```
+
+> NOTE: IAM-enabled users must have matching user id and username. For more information, see [Limitations](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/auth-iam.html). The construct can set automatically the username to be the same as the user id.
+
+If you want to create a password authenticated user, use `PasswordUser` construct:
+
+```ts
+const user = new elasticache.PasswordUser(this, 'User', {
+  // set user engine
+  engine: elasticache.UserEngine.VALKEY,
+  
+  // set user id
+  userId: 'my-user-id',  
+    
+  // set access string
+  accessControl: elasticache.AccessControl.fromAccessString("on ~* +@all"),
+ 
+  // set username
+  userName: 'my-user-name',
+ 
+  // set up to two passwords
+  passwords: [
+    // "SecretIdForPassword" is the secret id for the password
+    SecretValue.secretsManager('SecretIdForPassword'),
+    // "AnotherSecretIdForPassword" is the secret id for the password
+    SecretValue.secretsManager('AnotherSecretIdForPassword'),
+  ],
+});
+```
+
+You can also create a no password required user by using `NoPasswordUser` construct:
+
+```ts
+const user = new elasticache.NoPasswordUser(this, 'User', {
+  // set user engine  
+  engine: elasticache.UserEngine.REDIS, 
+    
+  // set user id
+  userId: 'my-user-id',
+ 
+  // set access string
+  accessControl: elasticache.AccessControl.fromAccessString("on ~* +@all"),
+ 
+  // set username
+  userName: 'my-user-name',
+});
+```
+
+### Default user
+
+ElastiCache automatically creates a default user with both a user ID and username set to `default`. This default user cannot be modified or deleted. The user is created as a no password authentication user.
+
+This user is intended for compatibility with the default behavior of previous Redis OSS versions and has an access string that permits it to call all commands and access all keys.
+
+To use this automatically created default user in CDK, you can import it using `NoPasswordUser.fromUserAttributes` method. For more information on import methods, see the [Import an existing user and user group](#import-an-existing-user-and-user-group) section.
+
+To add proper access control to a cache, replace the default user with a new one that is either disabled by setting the `accessString` to `off -@all` or secured with a strong password.
+
+To change the default user, create a new default user with the username set to `default`. You can then swap it with the original default user.
+
+For more information, see [Applying RBAC to a Cache for ElastiCache with Valkey or Redis OSS](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Clusters.RBAC.html#rbac-using).
+
+If you want to create a new default user, `userName` must be `default` and `userId` must not be `default` by using `NoPasswordUser` or `PasswordUser`:
+
+```ts
+// use the original `default` user by using import method
+const defaultUser = elasticache.NoPasswordUser.fromUserAttributes(this, 'DefaultUser', {
+  // userId and userName must be 'default'
+  userId: 'default',
+});
+ 
+// create a new default user
+const newDefaultUser = new elasticache.NoPasswordUser(this, 'NewDefaultUser', {
+  // new default user id must not be 'default'
+  userId: 'new-default',
+  // new default username must be 'default'
+  userName: 'default',
+  // set access string
+  accessControl: elasticache.AccessControl.fromAccessString("on ~* +@all"),
+});
+```
+
+> NOTE: You can't create a new default user using `IamUser` because an IAM-enabled user's username and user ID cannot be different.
+
+### Add users to the user group
+
+Next, use the `UserGroup` construct to create a user group and add users to it.
+Ensure that you include either the original default user or a new default user:
+
+```ts
+declare const newDefaultUser: elasticache.IUser;
+declare const user: elasticache.IUser;
+declare const anotherUser: elasticache.IUser;
+ 
+const userGroup = new elasticache.UserGroup(this, 'UserGroup', {
+  // add users including default user
+  users: [newDefaultUser, user],
+});
+ 
+// you can also add a user by using addUser method
+userGroup.addUser(anotherUser);
+```
+
+### Assign user group
+
+Finally, assign a user group to cache:
+
+```ts
+declare const vpc: ec2.Vpc;
+declare const userGroup: elasticache.UserGroup;
+ 
+const serverlessCache = new elasticache.ServerlessCache(this, 'ServerlessCache', {
+  engine: elasticache.CacheEngine.VALKEY_LATEST,
+  serverlessCacheName: 'my-serverless-cache',
+  vpc,
+  // assign User Group
+  userGroup,
+});
+ 
+```
+
+### Grant permissions to IAM-enabled users
+
+If you create IAM-enabled users, `"elasticache:Connect"` action must be allowed for the users and cache.
+
+> NOTE: You don't need grant permissions to no password required users or password authentication users.
+
+For more information, see [Authenticating with IAM](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/auth-iam.html).
+
+To grant permissions, you can use the `grantConnect` method in `IamUser` and `ServerlessCache` constructs:
+
+```ts
+declare const user: elasticache.IamUser;
+declare const serverlessCache: elasticache.ServerlessCache;
+declare const role: iam.Role;
+ 
+// grant "elasticache:Connect" action permissions to role
+user.grantConnect(role);
+serverlessCache.grantConnect(role);
+```
+
+### Import an existing user and user group
+
+You can import an existing user and user group by using import methods:
+
+```ts
+const stack = new Stack();
+ 
+const importedIamUser = elasticache.IamUser.fromUserId(this, 'ImportedIamUser', 'my-iam-user-id');
+ 
+const importedPasswordUser = elasticache.PasswordUser.fromUserAttributes(stack, 'ImportedPasswordUser', {
+  userId: 'my-password-user-id',
+});
+ 
+const importedNoPasswordUser = elasticache.NoPasswordUser.fromUserAttributes(stack, 'ImportedNoPasswordUser', {
+  userId: 'my-no-password-user-id',
+});
+ 
+const importedUserGroup = elasticache.UserGroup.fromUserGroupAttributes(this, 'ImportedUserGroup', {
+  userGroupName: 'my-user-group-name'
+});
+```

cdk_api_mcp_server/resources/aws-cdk/constructs/@aws-cdk/custom-resource-handlers/README.md

@@ -1,83 +1,20 @@
-# CDK Handler Framework
+# Type definitions copied from 'aws-cdk-lib'
 
-The CDK handler framework is an internal framework used to code generate constructs that extend a lambda `Function`, lambda `SingletonFunction`, or core `CustomResourceProvider` construct and prohibit the user from directly configuring the `handler`, `runtime`, `code`, and `codeDirectory` properties.  In doing this, we are able to establish best practices, runtime enforcement, and consistency across all handlers we build and vend within the aws-cdk.
+`aws-cdk-lib` depends on this package; but this package depends on some
+types defined in `aws-cdk-lib`.
 
-## CDK Handler Framework Concepts
+This cyclic dependency leads to a non-executable build graph. In order to
+break the cycle, we're just copying some types over from `aws-cdk-lib`.
 
-This framework allows for the creation of three component types:
-1. `ComponentType.FUNCTION` - This is a wrapper around the lambda `Function` construct. It offers the same behavior and performance as a lambda `Function`, but it restricts the consumer from configuring the `handler`, `runtime`, and `code` properties.
-2. `ComponentType.SINGLETON_FUNCTION` - This is a wrapper around the lambda `SingletonFunction` construct. It offers the same behavior and performance as a lambda `SingletonFunction`, but it restricts the consumer from configuring the `handler`, `runtime`, and `code` properties.
-3. `ComponentType.CUSTOM_RESOURCE_PROVIDER` - This is a wrapper around the core `CustomResourceProvider` construct. It offers the same behavior and performance as a `CustomResourceProvider` and can be instantiated via the `getOrCreate` or `getOrCreateProvider` methods. This component restricts the consumer from configuring the `runtime` and `codeDirectory` properties.
+I readily admit this is not a great long-term solution, but those types have
+been stable for years and are unlikely to change. The correct solution would
+probably be to externalize them into a separate package, but even the most
+simple solution of that accord would require bundling the types into
+`aws-cdk-lib` with `bundledDependencies` and that requires us writing a
+replacement for `npm pack`, because by default NPM will refuse to bundle
+`bundledDependencies` that have been symlinked into a local workspace (in fact,
+it will silently ignore them).
 
-Code generating one of these three component types requires adding the component properties to the [config](./config.ts) file by providing `ComponentProps`. The `ComponentProps` are responsible for code generating the specified `ComponentType` with the `handler`, `runtime`, `code`, and `codeDirectory` properties set internally. `ComponentProps` includes the following properties:
-- `type` - the framework component type to generate.
-- `sourceCode` - the source code that will be excuted by the framework component.
-- `runtime` - the runtime that is compatible with the framework component's source code. This is an optional property with a default node runtime that will be the latest available node runtime in the `Stack` deployment region. In general, you should not configure this property unless a `runtime` override is absolutely necessary.
-- `handler` - the name of the method with the source code that the framework component will call. This is an optional property and the default is `index.handler`.
-- `minifyAndBundle` - whether the source code should be minified and bundled. This an optional property and the default is `true`. This should only be set to `false` for python files or for typescript/javascript files with a require import.
+We can build our own replacement for `npm pack`, or we can do a little
+copy/paste.  I'm opting for the latter.
 
-The [config](./config.ts) file is structured with the top level mapping to an aws-cdk module, i.e., aws-s3, aws-dynamodb, etc. Each service can contain one or more component modules. Component modules are containers for handler framework components and will be rendered as a code generated file. Each component module can contain one or more `ComponentProps` objects. The following example shows a more structural breakdown of how the [config](./config.ts) file is configured:
-
-```ts
-const config = {
-  'aws-s3': { // the aws-cdk-lib module
-    'replica-provider': [ // the component module
-      // handler framework component defined as a `ComponentProps` object
-      {
-        // the handler framework component type
-        type: ComponentType.FUNCTION,
-        // the source code that the component will use
-        sourceCode: path.resolve(__dirname, '..', 'aws-dynamodb', 'replica-handler', 'index.ts'),
-        // the handler in the source code that the component will execute
-        handler: 'index.onEventHandler',
-      },
-    ],
-  },
-  'aws-stepfunctions-tasks': {
-    // contains multiple component modules
-    'eval-nodejs-provider': [
-      {
-        type: ComponentType.SINGLETON_FUNCTION,
-        sourceCode: path.resolve(__dirname, '..', 'aws-stepfunctions-tasks', 'eval-nodejs-handler', 'index.ts'),
-      },
-    ],
-    'role-policy-provider': [
-      {
-        type: ComponentType.SINGLETON_FUNCTION,
-        sourceCode: path.resolve(__dirname, '..', 'aws-stepfunctions-tasks', 'role-policy-handler', 'index.py'),
-        runtime: Runtime.PYTHON_3_9,
-        // prevent minify and bundle since the source code is a python file
-        minifyAndBundle: false,
-      },
-    ],
-  },
-};
-```
-
-Code generation for the component modules is triggered when this package - `@aws-cdk/custom-resource-handlers` - is built. Importantly, this framework is also responsible for minifying and bundling the custom resource providers' source code and dependencies. A flag named `minifyAndBundle` can be configured as part of the `ComponentProps` to prevent minifying and bundling the source code for a specific provider. This flag is only needed for python files or for typescript/javascript files containing require imports.
-
-Once built, all generated code and bundled source code will be written to `@aws-cdk/custom-resource-handlers/dist`. The top level field in the [config](./config.ts) file defining individual aws-cdk modules will be used to create specific directories within `@aws-cdk/custom-resource-handlers/dist` and each component module will be a separate code generated file within these directories named `<component-module>.generated.ts`. As an example, the sample [config](./config.ts) file above would create the following file structure:
-
-|--- @aws-cdk
-|   |--- custom-resource-handlers
-|   |   |--- dist
-|   |   |   |--- aws-s3
-|   |   |   |   |--- replica-handler
-|   |   |   |   |   |--- index.js
-|   |   |   |   |--- replica-provider.generated.ts
-|   |   |   |--- aws-stepfunctions-tasks
-|   |   |   |   |--- eval-nodejs-handler
-|   |   |   |   |   |--- index.js
-|   |   |   |   |--- role-policy-handler
-|   |   |   |   |   |--- index.py
-|   |   |   |   |--- eval-nodejs-provider.generated.ts
-|   |   |   |   |--- role-policy-provider.generated.ts
-
-The code generated handler framework components are consumable from `aws-cdk-lib/custom-resource-handlers/dist` once `aws-cdk-lib` is built. The file structure of `aws-cdk-lib/custom-resource-handlers/dist` will have the same structure as `@aws-cdk/custom-resource-handlers/dist` with the exception of `core`. To prevent circular dependencies, all handler framework components defined in `core`and any associated source code will be consumable from `aws-cdk-lib/core/dist/core`.
-
-## Creating a Handler Framework Component
-
-Creating a new handler framework component involves three steps:
-1. Add the source code to `@aws-cdk/custom-resource-handlers/lib/<aws-cdk-lib-module>`
-2. Update the [config](./config.ts) file by specifying all required `ComponentProps`.
-3. At this point you can directly build `@aws-cdk/custom-resource-handlers` with `yarn build` to view the generated component in `@aws-cdk/custom-resource-handlers/dist`. Alternatively, you can build `aws-cdk-lib` with `npx lerna run build --scope=aws-cdk-lib --skip-nx-cache` to make the generated component available for use within `aws-cdk-lib`

cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/aws-cloudfront-origins/README.md

@@ -597,6 +597,20 @@ new cloudfront.Distribution(this, 'myDist', {
 });
 ```
 
+You can specify the IP address type for connecting to the origin:
+
+```ts
+const origin = new origins.HttpOrigin('www.example.com', {
+  ipAddressType: cloudfront.OriginIpAddressType.IPV6, // IPv4, IPv6, or DUALSTACK
+});
+
+new cloudfront.Distribution(this, 'Distribution', {
+  defaultBehavior: { origin },
+});
+```
+
+The `ipAddressType` property allows you to specify whether CloudFront should use IPv4, IPv6, or both (dual-stack) when connecting to your origin.
+
 The origin can be customized with timeout settings to handle different response scenarios:
 
 ```ts

cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/aws-cloudfront-origins/integ.http-origin.ts

@@ -1,13 +1,16 @@
 import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
 import * as cdk from 'aws-cdk-lib';
 import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';
+import { IntegTest } from '@aws-cdk/integ-tests-alpha';
 
 const app = new cdk.App();
 
 const stack = new cdk.Stack(app, 'cloudfront-http-origin');
 
 new cloudfront.Distribution(stack, 'Distribution', {
-  defaultBehavior: { origin: new origins.HttpOrigin('www.example.com') },
+  defaultBehavior: { origin: new origins.HttpOrigin('www.example.com', { ipAddressType: cloudfront.OriginIpAddressType.DUALSTACK }) },
 });
 
-app.synth();
+new IntegTest(app, 'http-origin-test-integ', {
+  testCases: [stack],
+});

cdk_api_mcp_server/resources/aws-cdk/constructs/aws-cdk-lib/aws-codedeploy/integ.deployment-config.ts

@@ -2,28 +2,17 @@ import * as cdk from 'aws-cdk-lib';
 import * as integ from '@aws-cdk/integ-tests-alpha';
 import * as codedeploy from 'aws-cdk-lib/aws-codedeploy';
 
-const app = new cdk.App({
-  postCliContext: {
-    '@aws-cdk/aws-lambda:useCdkManagedLogGroup': false,
-  },
-});
-const stack = new cdk.Stack(app, 'aws-cdk-codedeploy-lambda-config');
+const app = new cdk.App();
+const stack = new cdk.Stack(app, 'aws-cdk-codedeploy-ecs-config');
 
-new codedeploy.LambdaDeploymentConfig(stack, 'LinearConfig', {
+new codedeploy.EcsDeploymentConfig(stack, 'LinearConfig', {
   trafficRouting: codedeploy.TrafficRouting.timeBasedLinear({
     interval: cdk.Duration.minutes(1),
     percentage: 5,
   }),
 });
 
-new codedeploy.CustomLambdaDeploymentConfig(stack, 'CustomConfig', {
-  interval: cdk.Duration.minutes(1),
-  percentage: 5,
-  type: cdk.aws_codedeploy.CustomLambdaDeploymentConfigType.LINEAR,
-  deploymentConfigName: 'hello',
-});
-
-new integ.IntegTest(app, 'LambdaDeploymentConfigTest', {
+new integ.IntegTest(app, 'EcsDeploymentConfigTest', {
   testCases: [stack],
 });