-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Description
Quick Update:
This is partly user error 🙏 (60%)
One of the core things I missed to begin with is that a NetworkLoadBalancer does not support Security Groups. Therefore they are fundamentally different from ApplicationLoadBalancer s.
However, there is still likely room to make the NetworkLoadBalancer a little more user friendly, specifically relating to the Security Group assigned to the instance.
Recap:
We are dealing with a NetworkLoadBalancer, therefore all of the security policies are defined at the instance level (not the load balancer level) (subnets aside). To change the ingress policy for the instance we either need access to the SecurityGroup of the AutoScalingGroup or the AutoScalingGroup itself (or add a new AutoScalingGroup). With either of these we are able to make the necessary changes (either edit the existing or add a new SecurityGroup) to enable access to the instances.
Problem:
The problem is that when you get the AutoScalingGroup from the cluster (cluster.autoscalingGroup), it returns a type of IAutoScalingGroup and not the AutoScalingGroup type. The IAutoScalingGroup does not have any reference to the underlying security groups and you are not able to add a new SecurityGroup.
All of these facts taken together make it very difficult to work with ECS & NetworkLoadBalancers from CDK.
Original Post:
It looks like there are a number of missing features from the NetworkLoadBalancer. Specifically, there are no security groups created by default when using the NetworkLoadBalancedEc2Service from the ecs-patterns package.
Reproduction Steps
First deploy the stack:
const app = new cdk.App();
const stack = new cdk.Stack(app, 'aws-ecs-network-lb', {
tags: { id: 'network-lb' }
});
// Create a cluster
const vpc = new ec2.Vpc(stack, 'Vpc', { maxAzs: 2 });
const cluster = new ecs.Cluster(stack, 'EcsCluster', { vpc });
cluster.addCapacity('DefaultAutoScalingGroup', {
instanceType: ec2.InstanceType.of(ec2.InstanceClass.T2, ec2.InstanceSize.MICRO)
});
// create a task definition with CloudWatch Logs
const logging = new ecs.AwsLogDriver({ streamPrefix: "task" })
// Create Task Definition
const taskDefinition = new ecs.Ec2TaskDefinition(stack, 'TaskDef');
const container = taskDefinition.addContainer('web', {
image: ecs.ContainerImage.fromRegistry('nginx:latest'),
memoryLimitMiB: 256,
logging
});
container.addPortMappings({
containerPort: 80,
hostPort: 80,
protocol: ecs.Protocol.TCP
});
// Create Service
const service = new ecs.Ec2Service(stack, "Service", {
cluster,
taskDefinition
});
// Create ALB
const lb = new elbv2.NetworkLoadBalancer(stack, 'LB', {
vpc,
internetFacing: true
});
const listener = lb.addListener('PublicListener', { port: 80 });
// Attach ALB to ECS Service
listener.addTargets('ECS', {
port: 80,
targets: [service],
// include health check (default is none)
healthCheck: {
interval: cdk.Duration.seconds(30)
}
});
new cdk.CfnOutput(stack, 'LoadBalancerDNS', { value: lb.loadBalancerDnsName, });
app.synth();Then look at the security groups associated with the EC2 instances. There are no ingress groups to allow traffic from the load balancer to the instance.
Error Log
N.A.
Environment
- CLI Version : 1.9.0
- Framework Version: 1.9.0
- OS : macOS 10.14.6
- Language : all
Other
Also given the issue described in #4267, I would expect to have this stack fail as well.
This is 🐛 Bug Report