Metadata-Version: 2.1
Name: aws-cdk.aws-applicationautoscaling
Version: 1.65.0
Summary: The CDK Construct Library for AWS::ApplicationAutoScaling
Home-page: https://github.com/aws/aws-cdk
Author: Amazon Web Services
License: Apache-2.0
Project-URL: Source, https://github.com/aws/aws-cdk.git
Description: ## AWS Auto Scaling Construct Library
        
        <!--BEGIN STABILITY BANNER-->---
        
        
        ![cfn-resources: Stable](https://img.shields.io/badge/cfn--resources-stable-success.svg?style=for-the-badge)
        
        ![cdk-constructs: Stable](https://img.shields.io/badge/cdk--constructs-stable-success.svg?style=for-the-badge)
        
        ---
        <!--END STABILITY BANNER-->
        
        **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:
        
        ```python
        # Example automatically generated without compilation. See https://github.com/aws/jsii/issues/826
        capacity = resource.auto_scale_capacity(
            min_capacity=5,
            max_capacity=100
        )
        
        # Enable a type of metric scaling and/or schedule scaling
        capacity.scale_on_metric(...)
        capacity.scale_to_track_metric(...)
        capacity.scale_on_schedule(...)
        ```
        
        ### 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:
        
        ```
         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:
        
        ```python
        # Example automatically generated without compilation. See https://github.com/aws/jsii/issues/826
        capacity.scale_on_metric("ScaleToCPU",
            metric=service.metric_cpu_utilization(),
            scaling_steps=[{"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.
            adjustment_type=autoscaling.AdjustmentType.CHANGE_IN_CAPACITY
        )
        ```
        
        The AutoScaling construct library will create the required CloudWatch alarms and
        AutoScaling policies for you.
        
        ### 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:
        
        ```python
        # Example automatically generated without compilation. See https://github.com/aws/jsii/issues/826
        read_capacity = table.auto_scale_read_capacity(
            min_capacity=10,
            max_capacity=1000
        )
        read_capacity.scale_on_utilization(
            target_utilization_percent=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:
        
        ```python
        # Example automatically generated without compilation. See https://github.com/aws/jsii/issues/826
        capacity = resource.auto_scale_capacity(
            min_capacity=1,
            max_capacity=50
        )
        
        capacity.scale_on_schedule("PrescaleInTheMorning",
            schedule=autoscaling.Schedule.cron(hour="8", minute="0"),
            min_capacity=20
        )
        
        capacity.scale_on_schedule("AllowDownscalingAtNight",
            schedule=autoscaling.Schedule.cron(hour="20", minute="0"),
            min_capacity=1
        )
        ```
        
        ## Examples
        
        ### Lambda Provisioned Concurrency Auto Scaling
        
        ```python
        # Example automatically generated without compilation. See https://github.com/aws/jsii/issues/826
        handler = lambda_.Function(self, "MyFunction",
            runtime=lambda_.Runtime.PYTHON_3_7,
            handler="index.handler",
            code=lambda_.InlineCode("\nimport json, time\ndef handler(event, context):\n    time.sleep(1)\n    return {\n        'statusCode': 200,\n        'body': json.dumps('Hello CDK from Lambda!')\n    }"),
            reserved_concurrent_executions=2
        )
        
        fn_ver = handler.add_version("CDKLambdaVersion", undefined, "demo alias", 10)
        
        apigateway.LambdaRestApi(self, "API", handler=fn_ver)
        
        target = applicationautoscaling.ScalableTarget(self, "ScalableTarget",
            service_namespace=applicationautoscaling.ServiceNamespace.LAMBDA,
            max_capacity=100,
            min_capacity=10,
            resource_id=f"function:{handler.functionName}:{fnVer.version}",
            scalable_dimension="lambda:function:ProvisionedConcurrency"
        )
        s
        target.scale_to_track_metric("PceTracking",
            target_value=0.9,
            predefined_metric=applicationautoscaling.PredefinedMetric.LAMBDA_PROVISIONED_CONCURRENCY_UTILIZATION
        )
        ```
        
Platform: UNKNOWN
Classifier: Intended Audience :: Developers
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: JavaScript
Classifier: Programming Language :: Python :: 3 :: Only
Classifier: Programming Language :: Python :: 3.6
Classifier: Programming Language :: Python :: 3.7
Classifier: Programming Language :: Python :: 3.8
Classifier: Typing :: Typed
Classifier: Development Status :: 5 - Production/Stable
Classifier: License :: OSI Approved
Classifier: Framework :: AWS CDK
Classifier: Framework :: AWS CDK :: 1
Requires-Python: >=3.6
Description-Content-Type: text/markdown
