-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aws-ecs-patterns: Allow ScheduledFargateTask and ScheduledEc2Task to run on a public subnet #6312
Comments
I'm facing exactly the same problem, so thanks @floehopper for a great bug report! Were you able to work around that? I need to run a ~1 hour task once a month, so provisioning a NAT gateway is out of question. Have you considered creating a Thanks |
Thanks. It's good to know I'm not the only one!
Yes. I'm currently working round the problem by defining my own
I hadn't considered this, but now you mention it, it might be a sensible approach in my use cases, because I'm already creating a
I'm not very familiar with Step functions, so I'm not clear how this would help. |
@SoManyHs @pkandasamy91 I checked the "I may be able to implement this feature request" checkbox in the issue description as per the contribution guidelines. Is it worth me submitting a PR for this issue or are you unlikely to accept it...? |
I define my VPC as follows: def vpc(self) -> aws_ec2.Vpc:
return aws_ec2.Vpc(
self, 'VPC',
cidr='172.16.0.0/28', # 172.16.0.1 -> 172.16.0.14
subnet_configuration=[
aws_ec2.SubnetConfiguration(
name='Public',
subnet_type=aws_ec2.SubnetType.PUBLIC
)
],
max_azs=1,
nat_gateways=0
) Then the class you suggested: class ScheduledFargateTaskOnPublicSubnet(aws_ecs_patterns.ScheduledFargateTask):
def __init__(self, scope: core.Construct, id: str, *,
schedule: aws_applicationautoscaling.Schedule,
scheduled_fargate_task_definition_options: Optional[aws_ecs_patterns.ScheduledFargateTaskDefinitionOptions] = None,
scheduled_fargate_task_image_options: Optional[aws_ecs_patterns.ScheduledFargateTaskImageOptions] = None,
cluster: Optional[aws_ecs.ICluster] = None,
desired_task_count: Optional[jsii.Number] = None,
vpc: Optional[aws_ec2.IVpc] = None) -> None:
super().__init__(
scope, id,
schedule=schedule,
scheduled_fargate_task_definition_options=scheduled_fargate_task_definition_options,
scheduled_fargate_task_image_options=scheduled_fargate_task_image_options,
cluster=cluster,
desired_task_count=desired_task_count,
vpc=vpc
)
def _add_task_definition_to_event_target(self, task_definition: aws_ecs.TaskDefinition) -> aws_events_targets.EcsTask:
event_rule_target = aws_events_targets.EcsTask(
cluster=self.cluster,
task_definition=task_definition,
subnet_selection=aws_ec2.SubnetSelection(subnet_type=aws_ec2.SubnetType.PUBLIC),
task_count=self.desired_task_count
)
self.event_rule().add_target(event_rule_target)
return event_rule_target I'm still getting:
It's interesting, that the Any suggestion? Thanks in advance! |
@floehopper that would be great! We'd be more than happy to review your PR! 💯 |
Have you changed your stack definition to instantiate the I'm not super-familiar with Python. Does the overridden method definitely not invoke the superclass version of the method. Given that you've explicitly called Otherwise I can't see any obvious differences that look like they might be causing your problem. Here are the relevant bits of code from one of my projects: const vpc = new ec2.Vpc(this, 'vpc', {
natGateways: 0,
subnetConfiguration: [
{ name: 'public', cidrMask: 24, subnetType: ec2.SubnetType.PUBLIC }
],
}); const backupTask = new ScheduledFargateTaskOnPublicSubnet(this, 'backupTask', {
cluster: cluster,
scheduledFargateTaskDefinitionOptions: {
taskDefinition: taskDefinition, schedule: schedule
},
schedule: schedule
}); |
Here's a working solution in Python. I had to inherit from class ScheduledFargateTaskOnPublicSubnet(aws_ecs_patterns.ScheduledTaskBase, metaclass=jsii.JSIIMeta, jsii_type="@aws-cdk/aws-ecs-patterns.ScheduledFargateTask"):
def __init__(self, scope: core.Construct, id: str, *,
schedule: aws_applicationautoscaling.Schedule,
scheduled_fargate_task_definition_options: Optional[aws_ecs_patterns.ScheduledFargateTaskDefinitionOptions] = None,
scheduled_fargate_task_image_options: Optional[aws_ecs_patterns.ScheduledFargateTaskImageOptions] = None,
cluster: Optional[aws_ecs.ICluster] = None,
desired_task_count: Optional[jsii.Number] = None,
vpc: Optional[aws_ec2.IVpc] = None) -> None:
super().__init__(scope, id, schedule=schedule, cluster=cluster, desired_task_count=desired_task_count, vpc=vpc)
self.task_definition = aws_ecs.FargateTaskDefinition(
self, 'MyTaskDef',
memory_limit_mib=scheduled_fargate_task_image_options.memory_limit_mib or 512,
cpu=scheduled_fargate_task_image_options.cpu or 256
)
self.task_definition.add_container(
'MyContainer',
image=scheduled_fargate_task_image_options.image,
command=scheduled_fargate_task_image_options.command,
environment=scheduled_fargate_task_image_options.environment,
secrets=scheduled_fargate_task_image_options.secrets,
logging=scheduled_fargate_task_image_options.log_driver
)
self._add_task_definition_to_event_target(self.task_definition)
@jsii.member(jsii_name="taskDefinition")
def task_definition(self) -> aws_ecs.FargateTaskDefinition:
"""The Fargate task definition in this construct."""
return self.task_definition
@jsii.member(jsii_name="addTaskDefinitionToEventTarget")
def _add_task_definition_to_event_target(self, task_definition: aws_ecs.TaskDefinition) -> aws_events_targets.EcsTask:
event_rule_target = aws_events_targets.EcsTask(
cluster=self.cluster,
task_definition=task_definition,
subnet_selection=aws_ec2.SubnetSelection(subnet_type=aws_ec2.SubnetType.PUBLIC),
task_count=self.desired_task_count
)
self.event_rule.add_target(event_rule_target)
return event_rule_target And then you can create your VPC with a public subnet only and no NAT gateways: def vpc(self) -> aws_ec2.Vpc:
return aws_ec2.Vpc(
self, 'MyVPC',
cidr='172.16.0.0/28', # 172.16.0.1 -> 172.16.0.14
subnet_configuration=[
aws_ec2.SubnetConfiguration(
name='Public',
subnet_type=aws_ec2.SubnetType.PUBLIC
)
],
max_azs=1,
nat_gateways=0
) |
Allow instances of ScheduledFargateTask and ScheduledEc2Task to run in a *public* subnet via a configuration option. The default remains that such instances are restricted to run on private subnets, but it is now possible to allow them to run on public subnets if the user is willing to sacrifice the extra security that a private subnet provides in favour of a simpler/cheaper system that does not require a NAT gateway or a NAT instance. I've added a unit test which demonstrated the following error which is what was occurring previously if the VPC did not provide a private subnet: Error: There are no 'Private' subnet groups in this VPC. Available types: Public fixes aws#6312
PR submitted: #6624 |
Allow instances of ScheduledFargateTask and ScheduledEc2Task to run in a *public* subnet via a configuration option. The default remains that such instances are restricted to run on private subnets, but it is now possible to allow them to run on public subnets if the user is willing to sacrifice the extra security that a private subnet provides in favour of a simpler/cheaper system that does not require a NAT gateway or a NAT instance. The new unit test schedules a Fargate task to run on a container in a VPC with no private subnet. Before the changes to ScheduledTaskBase in this commit, this test caused the following error: Error: There are no 'Private' subnet groups in this VPC. Available types: Public fixes aws#6312
…et (#6624) Allow instances of ScheduledFargateTask and ScheduledEc2Task to run in a *public* subnet via a configuration option. The default remains that such instances are restricted to run on private subnets, but it is now possible to allow them to run on public subnets if the user is willing to sacrifice the extra security that a private subnet provides in favour of a simpler/cheaper system that does not require a NAT gateway or a NAT instance. The new unit test schedules a Fargate task to run on a container in a VPC with no private subnet. Before the changes to ScheduledTaskBase in this commit, this test caused the following error: Error: There are no 'Private' subnet groups in this VPC. Available types: Public fixes #6312 Co-authored-by: Wesley Pettit <[email protected]>
Allow
ScheduledFargateTask
andScheduledEc2Task
to run in a public subnet via a configuration option.Use Case
I'm currently using the
ScheduledFargateTask
class to run a number of simple tasks. The tasks need access to the internet, but there's no need for them to be accessible from the internet. I could run the tasks on a private subnet, but this would mean I would need either a NAT Gateway (expensive) or run a NAT Instance on EC2 (maintenance/complexity overhead).Since the tasks only run for a few minutes every week I'm willing to sacrifice the extra security that a private subnet provides in favour of a simpler/cheaper system where the tasks run on a public subnet.
However, currently
ScheduledFargateTask
will only run a task if its VPC has a private subnet - if there is no private subnet available, an error is reported. I would like to be able to run my tasks on a VPC defined along the following lines:Proposed Solution
Currently the
addTaskDefinitionToEventTarget
method onScheduledTaskBase
instantiates the underlyingEcsTask
, but there is no way to specify thesubnetSelection
property of thatEcsTask
and so it defaults to{ subnetType: ec2.SubnetType.PRIVATE }
.I propose that we add a
subnetSelection
property to theScheduledTaskBaseProps
interface and supply that property when instantiating the underlyingEcsTask
. This new property would default to{ subnetType: ec2.SubnetType.PRIVATE }
thus retaining the existing behaviour.Other
In this comment @skinny85 mentioned that this is a gap in the
ScheduledFargateTask
construct.In this comment @moofish32 suggested that using only a public subnet is a reasonable option in some circumstances.
Reading between the lines, it sounds as if others commenting on this issue might welcome this functionality.
👋 I may be able to implement this feature request
This is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: