@epilot360/icons 0.0.1 → 0.0.2

package/iac/node_modules/aws-cdk-lib/aws-apigatewayv2/README.md

@@ -0,0 +1,32 @@
+# AWS::ApiGatewayV2 Construct Library
+
+
+This module is part of the [AWS Cloud Development Kit](https://github.com/aws/aws-cdk) project.
+
+```ts nofixture
+import * as apigateway from 'aws-cdk-lib/aws-apigatewayv2';
+```
+
+<!--BEGIN CFNONLY DISCLAIMER-->
+
+There are no official hand-written ([L2](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_lib)) constructs for this service yet. Here are some suggestions on how to proceed:
+
+- Search [Construct Hub for ApiGatewayV2 construct libraries](https://constructs.dev/search?q=apigatewayv2)
+- Use the automatically generated [L1](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_l1_using) constructs, in the same way you would use [the CloudFormation AWS::ApiGatewayV2 resources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ApiGatewayV2.html) directly.
+
+
+> An experimental construct library for this service is available in preview. Since it is not stable yet, it is distributed
+> as a separate package so that you can pin its version independently of the rest of the CDK. See the package:
+>
+> <span class="package-reference">@aws-cdk/aws-apigatewayv2-alpha</span>
+
+<!--BEGIN CFNONLY DISCLAIMER-->
+
+There are no hand-written ([L2](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_lib)) constructs for this service yet. 
+However, you can still use the automatically generated [L1](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_l1_using) constructs, and use this service exactly as you would using CloudFormation directly.
+
+For more information on the resources and properties available for this service, see the [CloudFormation documentation for AWS::ApiGatewayV2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ApiGatewayV2.html).
+
+(Read the [CDK Contributing Guide](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and submit an RFC if you are interested in contributing to this construct library.)
+
+<!--END CFNONLY DISCLAIMER-->

package/iac/node_modules/aws-cdk-lib/aws-appconfig/README.md

@@ -0,0 +1,27 @@
+# AWS::AppConfig Construct Library
+
+
+This module is part of the [AWS Cloud Development Kit](https://github.com/aws/aws-cdk) project.
+
+```ts nofixture
+import * as appconfig from 'aws-cdk-lib/aws-appconfig';
+```
+
+<!--BEGIN CFNONLY DISCLAIMER-->
+
+There are no official hand-written ([L2](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_lib)) constructs for this service yet. Here are some suggestions on how to proceed:
+
+- Search [Construct Hub for AppConfig construct libraries](https://constructs.dev/search?q=appconfig)
+- Use the automatically generated [L1](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_l1_using) constructs, in the same way you would use [the CloudFormation AWS::AppConfig resources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_AppConfig.html) directly.
+
+
+<!--BEGIN CFNONLY DISCLAIMER-->
+
+There are no hand-written ([L2](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_lib)) constructs for this service yet. 
+However, you can still use the automatically generated [L1](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_l1_using) constructs, and use this service exactly as you would using CloudFormation directly.
+
+For more information on the resources and properties available for this service, see the [CloudFormation documentation for AWS::AppConfig](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_AppConfig.html).
+
+(Read the [CDK Contributing Guide](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and submit an RFC if you are interested in contributing to this construct library.)
+
+<!--END CFNONLY DISCLAIMER-->

package/iac/node_modules/aws-cdk-lib/aws-appflow/README.md

@@ -0,0 +1,27 @@
+# AWS::AppFlow Construct Library
+
+
+This module is part of the [AWS Cloud Development Kit](https://github.com/aws/aws-cdk) project.
+
+```ts nofixture
+import * as appflow from 'aws-cdk-lib/aws-appflow';
+```
+
+<!--BEGIN CFNONLY DISCLAIMER-->
+
+There are no official hand-written ([L2](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_lib)) constructs for this service yet. Here are some suggestions on how to proceed:
+
+- Search [Construct Hub for AppFlow construct libraries](https://constructs.dev/search?q=appflow)
+- Use the automatically generated [L1](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_l1_using) constructs, in the same way you would use [the CloudFormation AWS::AppFlow resources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_AppFlow.html) directly.
+
+
+<!--BEGIN CFNONLY DISCLAIMER-->
+
+There are no hand-written ([L2](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_lib)) constructs for this service yet. 
+However, you can still use the automatically generated [L1](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_l1_using) constructs, and use this service exactly as you would using CloudFormation directly.
+
+For more information on the resources and properties available for this service, see the [CloudFormation documentation for AWS::AppFlow](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_AppFlow.html).
+
+(Read the [CDK Contributing Guide](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and submit an RFC if you are interested in contributing to this construct library.)
+
+<!--END CFNONLY DISCLAIMER-->

package/iac/node_modules/aws-cdk-lib/aws-appintegrations/README.md

@@ -0,0 +1,27 @@
+# AWS::AppIntegrations Construct Library
+
+
+This module is part of the [AWS Cloud Development Kit](https://github.com/aws/aws-cdk) project.
+
+```ts nofixture
+import * as appintegrations from 'aws-cdk-lib/aws-appintegrations';
+```
+
+<!--BEGIN CFNONLY DISCLAIMER-->
+
+There are no official hand-written ([L2](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_lib)) constructs for this service yet. Here are some suggestions on how to proceed:
+
+- Search [Construct Hub for AppIntegrations construct libraries](https://constructs.dev/search?q=appintegrations)
+- Use the automatically generated [L1](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_l1_using) constructs, in the same way you would use [the CloudFormation AWS::AppIntegrations resources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_AppIntegrations.html) directly.
+
+
+<!--BEGIN CFNONLY DISCLAIMER-->
+
+There are no hand-written ([L2](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_lib)) constructs for this service yet. 
+However, you can still use the automatically generated [L1](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_l1_using) constructs, and use this service exactly as you would using CloudFormation directly.
+
+For more information on the resources and properties available for this service, see the [CloudFormation documentation for AWS::AppIntegrations](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_AppIntegrations.html).
+
+(Read the [CDK Contributing Guide](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and submit an RFC if you are interested in contributing to this construct library.)
+
+<!--END CFNONLY DISCLAIMER-->

package/iac/node_modules/aws-cdk-lib/aws-applicationautoscaling/README.md

@@ -0,0 +1,246 @@
+# AWS Auto Scaling Construct Library
+
+
+**Application AutoScaling** is used to configure autoscaling for all
+services other than scaling EC2 instances. For example, you will use this to
+scale ECS tasks, DynamoDB capacity, Spot Fleet sizes, Comprehend document classification endpoints, Lambda function provisioned concurrency and more.
+
+As a CDK user, you will probably not have to interact with this library
+directly; instead, it will be used by other construct libraries to
+offer AutoScaling features for their own constructs.
+
+This document will describe the general autoscaling features and concepts;
+your particular service may offer only a subset of these.
+
+## AutoScaling basics
+
+Resources can offer one or more **attributes** to autoscale, typically
+representing some capacity dimension of the underlying service. For example,
+a DynamoDB Table offers autoscaling of the read and write capacity of the
+table proper and its Global Secondary Indexes, an ECS Service offers
+autoscaling of its task count, an RDS Aurora cluster offers scaling of its
+replica count, and so on.
+
+When you enable autoscaling for an attribute, you specify a minimum and a
+maximum value for the capacity. AutoScaling policies that respond to metrics
+will never go higher or lower than the indicated capacity (but scheduled
+scaling actions might, see below).
+
+There are three ways to scale your capacity:
+
+* **In response to a metric** (also known as step scaling); for example, you
+  might want to scale out if the CPU usage across your cluster starts to rise,
+  and scale in when it drops again.
+* **By trying to keep a certain metric around a given value** (also known as
+  target tracking scaling); you might want to automatically scale out an in to
+  keep your CPU usage around 50%.
+* **On a schedule**; you might want to organize your scaling around traffic
+  flows you expect, by scaling out in the morning and scaling in in the
+  evening.
+
+The general pattern of autoscaling will look like this:
+
+```ts
+declare const resource: SomeScalableResource;
+
+const capacity = resource.autoScaleCapacity({
+  minCapacity: 5,
+  maxCapacity: 100
+});
+
+// Then call a method to enable metric scaling and/or schedule scaling
+// (explained below):
+//
+// capacity.scaleOnMetric(...);
+// capacity.scaleToTrackMetric(...);
+// capacity.scaleOnSchedule(...);
+```
+
+## Step Scaling
+
+This type of scaling scales in and out in deterministic steps that you
+configure, in response to metric values. For example, your scaling strategy
+to scale in response to CPU usage might look like this:
+
+```plaintext
+ Scaling        -1          (no change)          +1       +3
+            │        │                       │        │        │
+            ├────────┼───────────────────────┼────────┼────────┤
+            │        │                       │        │        │
+CPU usage   0%      10%                     50%       70%     100%
+```
+
+(Note that this is not necessarily a recommended scaling strategy, but it's
+a possible one. You will have to determine what thresholds are right for you).
+
+You would configure it like this:
+
+```ts
+declare const capacity: ScalableAttribute;
+declare const cpuUtilization: cloudwatch.Metric;
+
+capacity.scaleOnMetric('ScaleToCPU', {
+  metric: cpuUtilization,
+  scalingSteps: [
+    { upper: 10, change: -1 },
+    { lower: 50, change: +1 },
+    { lower: 70, change: +3 },
+  ],
+
+  // Change this to AdjustmentType.PercentChangeInCapacity to interpret the
+  // 'change' numbers before as percentages instead of capacity counts.
+  adjustmentType: appscaling.AdjustmentType.CHANGE_IN_CAPACITY,
+});
+```
+
+The AutoScaling construct library will create the required CloudWatch alarms and
+AutoScaling policies for you.
+
+### Scaling based on multiple datapoints
+
+The Step Scaling configuration above will initiate a scaling event when a single
+datapoint of the scaling metric is breaching a scaling step breakpoint. In cases
+where you might want to initiate scaling actions on a larger number of datapoints
+(ie in order to smooth out randomness in the metric data), you can use the
+optional `evaluationPeriods` and `datapointsToAlarm` properties:
+
+```ts
+declare const capacity: ScalableAttribute;
+declare const cpuUtilization: cloudwatch.Metric;
+
+capacity.scaleOnMetric('ScaleToCPUWithMultipleDatapoints', {
+  metric: cpuUtilization,
+  scalingSteps: [
+    { upper: 10, change: -1 },
+    { lower: 50, change: +1 },
+    { lower: 70, change: +3 },
+  ],
+
+  // if the cpuUtilization metric has a period of 1 minute, then data points
+  // in the last 10 minutes will be evaluated
+  evaluationPeriods: 10,
+
+  // Only trigger a scaling action when 6 datapoints out of the last 10 are
+  // breaching. If this is left unspecified, then ALL datapoints in the 
+  // evaluation period must be breaching to trigger a scaling action
+  datapointsToAlarm: 6
+});
+```
+
+## Target Tracking Scaling
+
+This type of scaling scales in and out in order to keep a metric (typically
+representing utilization) around a value you prefer. This type of scaling is
+typically heavily service-dependent in what metric you can use, and so
+different services will have different methods here to set up target tracking
+scaling.
+
+The following example configures the read capacity of a DynamoDB table
+to be around 60% utilization:
+
+```ts
+import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
+
+declare const table: dynamodb.Table;
+
+const readCapacity = table.autoScaleReadCapacity({
+  minCapacity: 10,
+  maxCapacity: 1000
+});
+readCapacity.scaleOnUtilization({
+  targetUtilizationPercent: 60
+});
+```
+
+## Scheduled Scaling
+
+This type of scaling is used to change capacities based on time. It works
+by changing the `minCapacity` and `maxCapacity` of the attribute, and so
+can be used for two purposes:
+
+* Scale in and out on a schedule by setting the `minCapacity` high or
+  the `maxCapacity` low.
+* Still allow the regular scaling actions to do their job, but restrict
+  the range they can scale over (by setting both `minCapacity` and
+  `maxCapacity` but changing their range over time).
+
+The following schedule expressions can be used:
+
+* `at(yyyy-mm-ddThh:mm:ss)` -- scale at a particular moment in time
+* `rate(value unit)` -- scale every minute/hour/day
+* `cron(mm hh dd mm dow)` -- scale on arbitrary schedules
+
+Of these, the cron expression is the most useful but also the most
+complicated. A schedule is expressed as a cron expression. The `Schedule` class has a `cron` method to help build cron expressions.
+
+The following example scales the fleet out in the morning, and lets natural
+scaling take over at night:
+
+```ts
+declare const resource: SomeScalableResource;
+
+const capacity = resource.autoScaleCapacity({
+  minCapacity: 1,
+  maxCapacity: 50,
+});
+
+capacity.scaleOnSchedule('PrescaleInTheMorning', {
+  schedule: appscaling.Schedule.cron({ hour: '8', minute: '0' }),
+  minCapacity: 20,
+});
+
+capacity.scaleOnSchedule('AllowDownscalingAtNight', {
+  schedule: appscaling.Schedule.cron({ hour: '20', minute: '0' }),
+  minCapacity: 1
+});
+```
+
+## Examples
+
+### Lambda Provisioned Concurrency Auto Scaling
+
+```ts
+import * as lambda from 'aws-cdk-lib/aws-lambda';
+
+declare const code: lambda.Code;
+
+const handler = new lambda.Function(this, 'MyFunction', {
+  runtime: lambda.Runtime.PYTHON_3_7,
+  handler: 'index.handler',
+  code,
+
+  reservedConcurrentExecutions: 2,
+});
+
+const fnVer = handler.currentVersion;
+
+const target = new appscaling.ScalableTarget(this, 'ScalableTarget', {
+  serviceNamespace: appscaling.ServiceNamespace.LAMBDA,
+  maxCapacity: 100,
+  minCapacity: 10,
+  resourceId: `function:${handler.functionName}:${fnVer.version}`,
+  scalableDimension: 'lambda:function:ProvisionedConcurrency',
+})
+
+target.scaleToTrackMetric('PceTracking', {
+  targetValue: 0.9,
+  predefinedMetric: appscaling.PredefinedMetric.LAMBDA_PROVISIONED_CONCURRENCY_UTILIZATION,
+})
+```
+
+### ElastiCache Redis shards scaling with target value
+
+```ts
+const shardsScalableTarget = new appscaling.ScalableTarget(this, 'ElastiCacheRedisShardsScalableTarget', {
+  serviceNamespace: appscaling.ServiceNamespace.ELASTICACHE,
+  scalableDimension: 'elasticache:replication-group:NodeGroups',
+  minCapacity: 2,
+  maxCapacity: 10,
+  resourceId: 'replication-group/main-cluster',
+});
+
+shardsScalableTarget.scaleToTrackMetric('ElastiCacheRedisShardsCPUUtilization', {
+  targetValue: 20,
+  predefinedMetric: appscaling.PredefinedMetric.ELASTICACHE_PRIMARY_ENGINE_CPU_UTILIZATION,
+});
+```

package/iac/node_modules/aws-cdk-lib/aws-applicationinsights/README.md

@@ -0,0 +1,27 @@
+# AWS::ApplicationInsights Construct Library
+
+
+This module is part of the [AWS Cloud Development Kit](https://github.com/aws/aws-cdk) project.
+
+```ts nofixture
+import * as applicationinsights from 'aws-cdk-lib/aws-applicationinsights';
+```
+
+<!--BEGIN CFNONLY DISCLAIMER-->
+
+There are no official hand-written ([L2](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_lib)) constructs for this service yet. Here are some suggestions on how to proceed:
+
+- Search [Construct Hub for ApplicationInsights construct libraries](https://constructs.dev/search?q=applicationinsights)
+- Use the automatically generated [L1](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_l1_using) constructs, in the same way you would use [the CloudFormation AWS::ApplicationInsights resources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ApplicationInsights.html) directly.
+
+
+<!--BEGIN CFNONLY DISCLAIMER-->
+
+There are no hand-written ([L2](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_lib)) constructs for this service yet. 
+However, you can still use the automatically generated [L1](https://docs.aws.amazon.com/cdk/latest/guide/constructs.html#constructs_l1_using) constructs, and use this service exactly as you would using CloudFormation directly.
+
+For more information on the resources and properties available for this service, see the [CloudFormation documentation for AWS::ApplicationInsights](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ApplicationInsights.html).
+
+(Read the [CDK Contributing Guide](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and submit an RFC if you are interested in contributing to this construct library.)
+
+<!--END CFNONLY DISCLAIMER-->