App-FargateStack
view release on metacpan or search on metacpan
- an IAM role for the the cluster
- an IAM policy that has permissions enabling your worker
- an ECS task definition that describes your task
- a CloudWatch log group
- an EventBridge target event
- an IAM role for EventBridge
- an IAM policy for EventBridge
- an EventBridge rule that schedules the worker
...so as you can see, rolling all of this by hand could be a daunting
task and one made even more difficult when you decide to use other AWS
resources inside your task like buckets, queues or an EFS file
systems!
## Web Applications
Creating a web application using a minimal configuration works too. To
build a web application you can start with this minimal configuration:
---
app:
- If the checksum has not changed, it will skip the update to avoid
unnecessary API calls.
This model gives you the best of both worlds: the "minimal
configuration, maximum results" of a secure default, and the full
"transparent box" control to customize your security posture as your
application's needs evolve.
### Conflict and Drift Management
The framework includes robust safety checks to prevent accidental data
loss. If it detects that the Web ACL has been modified in the AWS
Console _and_ you have also modified your local `web-acl.json` file,
it will detect the state conflict, refuse to make any changes, and
provide a clear error message with instructions on how to resolve it.
### Estimated Cost
The default WAF configuration is designed to provide a strong security
baseline while remaining cost-effective. When you enable WAF without
specifying any `managed_rules`, the framework applies the `default`
The amount of time, in seconds, to wait after a scale-in activity before
another scale-in activity can start. This prevents the service from scaling
in too aggressively.
Default: `300`
- **scale\_out\_cooldown** (Optional)
The amount of time, in seconds, to wait after a scale-out activity before
another scale-out activity can start. This allows new tasks time to warm up
and start accepting traffic before the service decides to scale out again.
Default: `60`
- **policy\_name** (Managed by CApp::FargateStack)
This is a unique name for the scaling policy generated by the framework. It
is written to your configuration file and used to detect drift between your
configuration and the live environment in AWS. You should not modify this
value.
## Drift Detection and Management
CApp::FargateStack treats your YAML configuration as the single source of
truth. On every `plan` or `apply` run, it will compare the `autoscaling`
configuration in your file with the live scaling policy in AWS.
If it detects any differences (e.g., someone manually changed the max capacity
in the AWS Console), it will report the drift and will not apply any changes.
To overwrite the live settings and enforce the configuration from your file,
you must re-run the `apply` command with the `--force` flag. This provides a
critical safety check against accidental configuration changes.
### The `autoscaling` keyword
For any service type (`https`, `http`, `daemon`, or `task`), you can enable
and configure autoscaling directly from the command line. This provides a
quick-start method to make your service elastic from the moment it's created.
The Cautoscaling: keyword accepts a metric and an optional target value:
- **Enable with a specific target value:**
0.0.0.0/0 route to an Internet Gateway (a public subnet).
While not fatal, placing tasks in public subnets is discouraged unless
you have a specific need.
### Why this matters
Running tasks in public subnets can introduce risk and operational
surprises:
- Accidental exposure
If the task is assigned a public IP and the security group allows
inbound access, it may be reachable from the internet.
- Unintended dependency
Public-subnet egress typically relies on a public IP and the Internet
Gateway. That can bypass intended egress controls, logging, or central
inspection.
lib/App/EC2.pm view on Meta::CPAN
]
);
}
########################################################################
sub authorize_security_group_ingress {
########################################################################
my ( $self, %args ) = @_;
my ( $group_id, $port, $protocol, $source_group, $cidr ) = @args{qw(group_id port protocol source_group cidr)};
$protocol //= 'tcp';
$port //= '80';
return $self->command(
'authorize-security-group-ingress' => [
'--group-id' => $group_id,
'--port' => $port,
'--protocol' => $protocol,
$cidr ? ( '--cidr' => $cidr ) : (),
$source_group ? ( '--source-group' => $source_group ) : (),
]
);
}
########################################################################
sub validate_subnets {
########################################################################
my ( $self, $subnets ) = @_;
lib/App/FargateStack/Builder/HTTPService.pm view on Meta::CPAN
}
$self->log_info( 'http-service: authorizing ingress for [%s] on port(s): [%s]...%s',
$sg, join( q{, }, @allow_ports ), $dryrun );
if ( !$dryrun ) {
foreach my $port (@allow_ports) {
$ec2->authorize_security_group_ingress(
group_id => $sg,
port => $port,
cidr => '0.0.0.0/0',
);
}
}
return $sg;
}
########################################################################
sub create_alias {
########################################################################
lib/App/FargateStack/Pod.pm view on Meta::CPAN
=item * an IAM role for EventBridge
=item * an IAM policy for EventBridge
=item * an EventBridge rule that schedules the worker
=back
...so as you can see, rolling all of this by hand could be a daunting
task and one made even more difficult when you decide to use other AWS
resources inside your task like buckets, queues or an EFS file
systems!
=head2 Web Applications
Creating a web application using a minimal configuration works too. To
build a web application you can start with this minimal configuration:
---
app:
lib/App/FargateStack/Pod.pm view on Meta::CPAN
=back
This model gives you the best of both worlds: the "minimal
configuration, maximum results" of a secure default, and the full
"transparent box" control to customize your security posture as your
application's needs evolve.
=head3 Conflict and Drift Management
The framework includes robust safety checks to prevent accidental data
loss. If it detects that the Web ACL has been modified in the AWS
Console I<and> you have also modified your local F<web-acl.json> file,
it will detect the state conflict, refuse to make any changes, and
provide a clear error message with instructions on how to resolve it.
=head3 Estimated Cost
The default WAF configuration is designed to provide a strong security
baseline while remaining cost-effective. When you enable WAF without
specifying any C<managed_rules>, the framework applies the C<default>
lib/App/FargateStack/Pod.pm view on Meta::CPAN
The amount of time, in seconds, to wait after a scale-in activity before
another scale-in activity can start. This prevents the service from scaling
in too aggressively.
Default: C<300>
=item * B<scale_out_cooldown> (Optional)
The amount of time, in seconds, to wait after a scale-out activity before
another scale-out activity can start. This allows new tasks time to warm up
and start accepting traffic before the service decides to scale out again.
Default: C<60>
=item * B<policy_name> (Managed by CApp::FargateStack)
This is a unique name for the scaling policy generated by the framework. It
is written to your configuration file and used to detect drift between your
configuration and the live environment in AWS. You should not modify this
value.
lib/App/FargateStack/Pod.pm view on Meta::CPAN
=head2 Drift Detection and Management
CApp::FargateStack treats your YAML configuration as the single source of
truth. On every C<plan> or C<apply> run, it will compare the C<autoscaling>
configuration in your file with the live scaling policy in AWS.
If it detects any differences (e.g., someone manually changed the max capacity
in the AWS Console), it will report the drift and will not apply any changes.
To overwrite the live settings and enforce the configuration from your file,
you must re-run the C<apply> command with the C<--force> flag. This provides a
critical safety check against accidental configuration changes.
=head3 The C<autoscaling> keyword
For any service type (C<https>, C<http>, C<daemon>, or C<task>), you can enable
and configure autoscaling directly from the command line. This provides a
quick-start method to make your service elastic from the moment it's created.
The Cautoscaling: keyword accepts a metric and an optional target value:
=over
lib/App/FargateStack/Pod.pm view on Meta::CPAN
While not fatal, placing tasks in public subnets is discouraged unless
you have a specific need.
=head3 Why this matters
Running tasks in public subnets can introduce risk and operational
surprises:
=over 4
=item * Accidental exposure
If the task is assigned a public IP and the security group allows
inbound access, it may be reachable from the internet.
=item * Unintended dependency
Public-subnet egress typically relies on a public IP and the Internet
Gateway. That can bypass intended egress controls, logging, or central
inspection.
share/README.md view on Meta::CPAN
- an IAM role for the the cluster
- an IAM policy that has permissions enabling your worker
- an ECS task definition that describes your task
- a CloudWatch log group
- an EventBridge target event
- an IAM role for EventBridge
- an IAM policy for EventBridge
- an EventBridge rule that schedules the worker
...so as you can see, rolling all of this by hand could be a daunting
task and one made even more difficult when you decide to use other AWS
resources inside your task like buckets, queues or an EFS file
systems!
## Web Applications
Creating a web application using a minimal configuration works too. To
build a web application you can start with this minimal configuration:
---
app:
share/README.md view on Meta::CPAN
- If the checksum has not changed, it will skip the update to avoid
unnecessary API calls.
This model gives you the best of both worlds: the "minimal
configuration, maximum results" of a secure default, and the full
"transparent box" control to customize your security posture as your
application's needs evolve.
### Conflict and Drift Management
The framework includes robust safety checks to prevent accidental data
loss. If it detects that the Web ACL has been modified in the AWS
Console _and_ you have also modified your local `web-acl.json` file,
it will detect the state conflict, refuse to make any changes, and
provide a clear error message with instructions on how to resolve it.
### Estimated Cost
The default WAF configuration is designed to provide a strong security
baseline while remaining cost-effective. When you enable WAF without
specifying any `managed_rules`, the framework applies the `default`
share/README.md view on Meta::CPAN
The amount of time, in seconds, to wait after a scale-in activity before
another scale-in activity can start. This prevents the service from scaling
in too aggressively.
Default: `300`
- **scale\_out\_cooldown** (Optional)
The amount of time, in seconds, to wait after a scale-out activity before
another scale-out activity can start. This allows new tasks time to warm up
and start accepting traffic before the service decides to scale out again.
Default: `60`
- **policy\_name** (Managed by CApp::FargateStack)
This is a unique name for the scaling policy generated by the framework. It
is written to your configuration file and used to detect drift between your
configuration and the live environment in AWS. You should not modify this
value.
share/README.md view on Meta::CPAN
## Drift Detection and Management
CApp::FargateStack treats your YAML configuration as the single source of
truth. On every `plan` or `apply` run, it will compare the `autoscaling`
configuration in your file with the live scaling policy in AWS.
If it detects any differences (e.g., someone manually changed the max capacity
in the AWS Console), it will report the drift and will not apply any changes.
To overwrite the live settings and enforce the configuration from your file,
you must re-run the `apply` command with the `--force` flag. This provides a
critical safety check against accidental configuration changes.
### The `autoscaling` keyword
For any service type (`https`, `http`, `daemon`, or `task`), you can enable
and configure autoscaling directly from the command line. This provides a
quick-start method to make your service elastic from the moment it's created.
The Cautoscaling: keyword accepts a metric and an optional target value:
- **Enable with a specific target value:**
share/README.md view on Meta::CPAN
0.0.0.0/0 route to an Internet Gateway (a public subnet).
While not fatal, placing tasks in public subnets is discouraged unless
you have a specific need.
### Why this matters
Running tasks in public subnets can introduce risk and operational
surprises:
- Accidental exposure
If the task is assigned a public IP and the security group allows
inbound access, it may be reachable from the internet.
- Unintended dependency
Public-subnet egress typically relies on a public IP and the Internet
Gateway. That can bypass intended egress controls, logging, or central
inspection.
( run in 0.431 second using v1.01-cache-2.11-cpan-de7293f3b23 )