@aws-cdk/aws-elasticloadbalancingv2
Advanced tools
The CDK Construct Library for AWS::ElasticLoadBalancingV2
The @aws-cdk/aws-elasticloadbalancingv2 package provides constructs for
configuring application and network load balancers.
For more information, see the AWS documentation for Application Load Balancers and Network Load Balancers.
You define an application load balancer by creating an instance of
ApplicationLoadBalancer, adding a Listener to the load balancer
and adding Targets to the Listener:
import ec2 = require('@aws-cdk/aws-ec2');
import elbv2 = require('@aws-cdk/aws-elasticloadbalancingv2');
import autoscaling = require('@aws-cdk/aws-autoscaling');
// ...
const vpc = new ec2.VpcNetwork(...);
// Create the load balancer in a VPC. 'internetFacing' is 'false'
// by default, which creates an internal load balancer.
const lb = new elbv2.ApplicationLoadBalancer(this, 'LB', {
vpc,
internetFacing: true
});
// Add a listener and open up the load balancer's security group
// to the world. 'open' is the default, set this to 'false'
// and use `listener.connections` if you want to be selective
// about who can access the listener.
const listener = lb.addListener('Listener', {
port: 80,
open: true,
});
// Create an AutoScaling group and add it as a load balancing
// target to the listener.
const asg = new autoscaling.AutoScalingGroup(...);
listener.addTargets('ApplicationFleet', {
port: 8080,
targets: [asg]
});
The security groups of the load balancer and the target are automatically updated to allow the network traffic.
It's possible to route traffic to targets based on conditions in the incoming
HTTP request. Path- and host-based conditions are supported. For example,
the following will route requests to the indicated AutoScalingGroup
only if the requested host in the request is example.com:
listener.addTargets('Example.Com Fleet', {
priority: 10,
hostHeader: 'example.com',
port: 8080,
targets: [asg]
});
priority is a required field when you add targets with conditions. The lowest
number wins.
Every listener must have at least one target without conditions.
Network Load Balancers are defined in a similar way to Application Load Balancers:
import ec2 = require('@aws-cdk/aws-ec2');
import elbv2 = require('@aws-cdk/aws-elasticloadbalancingv2');
import autoscaling = require('@aws-cdk/aws-autoscaling');
// Create the load balancer in a VPC. 'internetFacing' is 'false'
// by default, which creates an internal load balancer.
const lb = new elbv2.NetworkLoadBalancer(stack, 'LB', {
vpc,
internetFacing: true
});
// Add a listener on a particular port.
const listener = lb.addListener('Listener', {
port: 443,
});
// Add targets on a particular port.
listener.addTargets('AppFleet', {
port: 443,
targets: [asg]
});
One thing to keep in mind is that network load balancers do not have security groups, and no automatic security group configuration is done for you. You will have to configure the security groups of the target yourself to allow traffic by clients and/or load balancer instances, depending on your target types. See Target Groups for your Network Load Balancers and Register targets with your Target Group for more information.
Application and Network Load Balancers organize load balancing targets in Target
Groups. If you add your balancing targets (such as AutoScalingGroups, ECS
services or individual instances) to your listener directly, the appropriate
TargetGroup will be automatically created for you.
If you need more control over the Target Groups created, create an instance of
ApplicationTargetGroup or NetworkTargetGroup, add the members you desire,
and add it to the listener by calling addTargetGroups instead of addTargets.
addTargets() will always return the Target Group it just created for you:
const group = listener.addTargets('AppFleet', {
port: 443,
targets: [asg1],
});
group.addTarget(asg2);
Health checks are configured upon creation of a target group:
listener.addTargets('AppFleet', {
port: 8080,
targets: [asg],
healthCheck: {
path: '/ping',
intervalSecs: 60,
}
});
The health check can also be configured after creation by calling
configureHealthCheck() on the created object.
No attempts are made to configure security groups for the port you're configuring a health check for, but if the health check is on the same port you're routing traffic to, the security group already allows the traffic. If not, you will have to configure the security groups appropriately:
listener.addTargets('AppFleet', {
port: 8080,
targets: [asg],
healthCheck: {
port: 8088,
}
});
listener.connections.allowFrom(lb, new TcpPort(8088));
Constructs that want to be a load balancer target should implement
IApplicationLoadBalancerTarget and/or INetworkLoadBalancerTarget, and
provide an implementation for the function attachToXxxTargetGroup(), which can
call functions on the load balancer and should return metadata about the
load balancing target:
public attachToApplicationTargetGroup(targetGroup: ApplicationTargetGroup): LoadBalancerTargetProps {
targetGroup.registerConnectable(...);
return {
targetType: TargetType.Instance | TargetType.Ip
targetJson: { id: ..., port: ... },
};
}
targetType should be one of Instance or Ip. If the target can be
directly added to the target group, targetJson should contain the id of
the target (either instance ID or IP address depending on the type) and
optionally a port or availabilityZone override.
Application load balancer targets can call registerConnectable() on the
target group to register themselves for addition to the load balancer's security
group rules.
If your load balancer target requires that the TargetGroup has been
associated with a LoadBalancer before registration can happen (such as is the
case for ECS Services for example), take a resource dependency on
targetGroup.listenerDependency() as follows:
// Make sure that the listener has been created, and so the TargetGroup
// has been associated with the LoadBalancer, before 'resource' is created.
resourced.addDependency(targetGroup.listenerDependency());
0.11.0 (2018-10-11)
IMPORTANT NOTE: This release includes a breaking change in the toolkit <=> app protocol. This means that in order to synthesize CDK apps that use this version, the globally installed CDK toolkit must also be updated:
$ npm i -g aws-cdk
$ cdk --version
0.11.0 (build ...)
Like always, you will also need to update your project's library versions:
Language | Update?
--------------------------- | ------------------------------------------------------------------------------------------------------------------
JavaScript/TypeScript (npm) | npx npm-check-updates -u
Java (maven) | mvn versions:use-latest-versions
.NET (NuGet) | nuget update
framework: The cdk.App constructor doesn't accept any arguments, and app.run() does not return a string anymore. All AWS CDK apps in all languages would need to be modified to adhere to the new API of the cdk.App construct.
Instead of:
const app = new App(process.argv); // ERROR
// add stacks
process.stdout.write(app.run()); // ERROR
The new usage is:
const app = new App();
// add stacks
app.run();
framework: The CDK is no longer shipped with built-in support for JSX. You can still use JSX but you will have to manually configure it.
aws-iam: PolicyDocument, PolicyStatement and all PolicyPrincipal classes moved from the @aws-cdk/cdk module and into the @aws-cdk/aws-iam module.
aws-codepipeline-api: Artifact.subartifact method of the CodePipeline API was renamed to Artifact.atPath.
constructor signature of TagManager has changed. initialTags is now passed inside a props object.
util: @aws-cdk/util is no longer available
aws-elasticloadbalancingv2: Adds classes for modeling Application and Network Load Balancers. AutoScalingGroups now implement the interface that makes constructs a load balancing target. The breaking change is that Security Group rule identifiers have been changed in order to make adding rules more reliable. No code changes are necessary but existing deployments may experience unexpected changes.
aws-cloudformation: this renames all CloudFormation Actions for CodePipeline to bring them in line with Actions defined in other service packages.
aws-codepipeline, aws-codecommit, aws-s3: change the names of the source Actions from XxxSource to XxxSourceAction. This is to align them with the other Actions, like Build. Also, CodeBuild has the concept of Sources, so it makes sense to strongly differentiate between the two.
FAQs
The CDK Construct Library for AWS::ElasticLoadBalancingV2
The npm package @aws-cdk/aws-elasticloadbalancingv2 receives a total of 21,578 weekly downloads. As such, @aws-cdk/aws-elasticloadbalancingv2 popularity was classified as popular.
We found that @aws-cdk/aws-elasticloadbalancingv2 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
Node.js will be enforcing stricter semver-major PR policies a month before major releases to enhance stability and ensure reliable release candidates.
Security News
Research
Socket's threat research team has detected five malicious npm packages targeting Roblox developers, deploying malware to steal credentials and personal data.
Security News
vlt introduced its new package manager and a serverless registry this week, innovating in a space where npm has stagnated.