view release on metacpan or  search on metacpan

share/README.md  view on Meta::CPAN

After the initial creation, you take full control of the rules. To
add, remove, or modify rules, you simply edit the `web-acl.json` file
directly.

On subsequent runs of `apply`, `App::FargateStack` will:

- Calculate a checksum of your `web-acl.json` file.
- If the checksum has changed, it will safely update the remote Web ACL
with your new rule set.
- 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`
bundle, which includes the `base` and `sql` rule sets.

The approximate monthly cost for this default configuration is
**~$9.00 per month**, plus per-request charges.

The cost is broken down as follows:

- **$5.00 / month** for the Web ACL itself.
- **$4.00 / month** for the four AWS Managed Rule Groups included
in the `default` bundle (3 in 'base', 1 in 'sql').
- **$0.60 / per 1 million requests** processed by the Web ACL.

**Warning:** Enabling the `premium` rule set will incur significant
additional monthly and per-request fees for services like Bot Control
and Account Takeover Prevention. Always review the [AWS WAF
pricing](https://aws.amazon.com/waf/pricing/) page before enabling
premium features.

## Roadmap for HTTP Services

- path based routing on ALB listeners

[Back to Table of Contents](#table-of-contents)

# AUTOSCALING

## Overview

For services that experience variable load, such as HTTP applications or
background job processors, `App::FargateStack` can automate the process of
scaling the number of running tasks up or down to meet demand. This ensures
high availability during traffic spikes and saves costs during quiet periods.

The framework integrates with AWS Application Auto Scaling to provide target
tracking scaling policies. This allows you to define a target metric - such as
average CPU utilization or the number of requests per minute - and the framework
will automatically manage the number of Fargate tasks to keep that metric at
your desired level.

## Enabling Autoscaling

To enable autoscaling for a service, add an `autoscaling` block to its task
configuration in your .yml configuration file.

tasks:
  my-service:
    # ... other task settings ...
    autoscaling:
      min\_capacity: 1
      max\_capacity: 10
      cpu: 60

## Configuration Parameters

The `autoscaling` block accepts the following keys:

- **min\_capacity** (Required)

    The minimum number of tasks to keep running at all times. The service will
    never scale in below this number.

- **max\_capacity** (Required)

    The maximum number of tasks that the service can scale out to. This acts as
    a safeguard to control costs.

- **cpu** OR **requests** (Required, mutually exclusive)

    You must specify exactly one scaling metric.

    - `cpu`: The target average CPU utilization percentage across all tasks in
    the service. Valid values are between 1 and 100.
    - `requests`: The target number of requests per minute for each task. This
    is only valid for tasks of type `http` or `https` that are behind an
    Application Load Balancer.

- **scale\_in\_cooldown** (Optional)

    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.