@aws-cdk/aws-applicationautoscaling
Advanced tools
The CDK Construct Library for AWS::ApplicationAutoScaling
@aws-cdk/aws-applicationautoscaling is an AWS CDK library that allows you to configure application auto-scaling for various AWS resources. It provides constructs for defining scaling policies and targets, enabling you to automatically adjust capacity based on demand.
Auto-scaling for DynamoDB
This feature allows you to set up auto-scaling for a DynamoDB table. The code sample demonstrates how to create a DynamoDB table and configure auto-scaling for its read capacity based on utilization.
const app = new cdk.App();
const stack = new cdk.Stack(app, 'AutoScalingStack');
const table = new dynamodb.Table(stack, 'MyTable', {
partitionKey: { name: 'id', type: dynamodb.AttributeType.STRING },
billingMode: dynamodb.BillingMode.PROVISIONED,
});
const readScaling = table.autoScaleReadCapacity({
minCapacity: 1,
maxCapacity: 10,
});
readScaling.scaleOnUtilization({
targetUtilizationPercent: 75,
});Auto-scaling for ECS Services
This feature allows you to set up auto-scaling for ECS services. The code sample demonstrates how to create an ECS Fargate service and configure auto-scaling based on CPU utilization.
const app = new cdk.App();
const stack = new cdk.Stack(app, 'AutoScalingStack');
const cluster = new ecs.Cluster(stack, 'Cluster', {
vpc,
});
const taskDefinition = new ecs.FargateTaskDefinition(stack, 'TaskDef');
const container = taskDefinition.addContainer('WebContainer', {
image: ecs.ContainerImage.fromRegistry('amazon/amazon-ecs-sample'),
memoryLimitMiB: 512,
});
const service = new ecs.FargateService(stack, 'Service', {
cluster,
taskDefinition,
});
const scaling = service.autoScaleTaskCount({
minCapacity: 1,
maxCapacity: 10,
});
scaling.scaleOnCpuUtilization('CpuScaling', {
targetUtilizationPercent: 50,
});Auto-scaling for Lambda Functions
This feature allows you to set up auto-scaling for Lambda functions. The code sample demonstrates how to create a Lambda function and configure auto-scaling based on utilization.
const app = new cdk.App();
const stack = new cdk.Stack(app, 'AutoScalingStack');
const fn = new lambda.Function(stack, 'MyFunction', {
runtime: lambda.Runtime.NODEJS_14_X,
handler: 'index.handler',
code: lambda.Code.fromAsset('lambda'),
});
const alias = new lambda.Alias(stack, 'Alias', {
aliasName: 'prod',
version: fn.currentVersion,
});
const scaling = alias.addAutoScaling({
minCapacity: 1,
maxCapacity: 10,
});
scaling.scaleOnUtilization({
utilizationTarget: 0.75,
});The aws-sdk package provides a comprehensive set of tools for interacting with AWS services, including auto-scaling. However, it requires more manual setup and configuration compared to the higher-level abstractions provided by @aws-cdk/aws-applicationautoscaling.
The serverless framework allows you to deploy and manage serverless applications on AWS and other cloud providers. It includes support for auto-scaling Lambda functions and other resources, but it is more focused on serverless architectures compared to the broader scope of @aws-cdk/aws-applicationautoscaling.
Terraform is an infrastructure as code tool that allows you to define and provision infrastructure using a declarative configuration language. It supports auto-scaling for various AWS resources, but it uses a different approach and syntax compared to the AWS CDK.
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.
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:
The general pattern of autoscaling will look like this:
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(...);
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:
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.
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:
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
});
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:
import * as dynamodb from '@aws-cdk/aws-dynamodb';
declare const table: dynamodb.Table;
const readCapacity = table.autoScaleReadCapacity({
minCapacity: 10,
maxCapacity: 1000
});
readCapacity.scaleOnUtilization({
targetUtilizationPercent: 60
});
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:
minCapacity high or
the maxCapacity low.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 timerate(value unit) -- scale every minute/hour/daycron(mm hh dd mm dow) -- scale on arbitrary schedulesOf 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:
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
});
import * as lambda from '@aws-cdk/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.addVersion('CDKLambdaVersion', undefined, 'demo alias', 10);
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,
})
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,
});
1.148.0 (2022-03-09)
s3:ObjectRestore:Delete to EventType for notification (#19250) (e0f863a), closes #19223watch logs always end with the 'truncated' message (#19241) (d3fdfe5), closes #18805FAQs
The CDK Construct Library for AWS::ApplicationAutoScaling
The npm package @aws-cdk/aws-applicationautoscaling receives a total of 137,779 weekly downloads. As such, @aws-cdk/aws-applicationautoscaling popularity was classified as popular.
We found that @aws-cdk/aws-applicationautoscaling demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 4 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
A malicious npm package disguised as a WhatsApp client is exploiting authentication flows with a remote kill switch to exfiltrate data and destroy files.
Security News
PyPI now supports digital attestations, enhancing security and trust by allowing package maintainers to verify the authenticity of Python packages.
Security News
GitHub removed 27 malicious pull requests attempting to inject harmful code across multiple open source repositories, in another round of low-effort attacks.