What is a Host Header Rule?

A Host header rule ensures that only requests matching specific domain names (e.g., demo.cloud.com) are allowed and routed to your backend.

This helps:

• Route traffic to the correct service

• Restrict access to only valid domains

How to Configure (as shown in screenshot)

1. Go to EC2 → Load Balancers → Listeners

2. Select your HTTPS:443 listener

3. Click Add rule

4. Under Conditions → Add condition → Host header

5. Enter your domain:

   • Exact: demo.example.com

   • Wildcard: *.example.com

6. Set action → Forward to target group

7. Assign priority (lower number = higher priority)

Important Behavior

• Rules are evaluated top-down (by priority)

• If no rule matches → Default action is triggered (commonly 403)

Why It Matters

• Prevents unwanted traffic hitting your backend

• Reduces exposure via ALB DNS

• Helps mitigate Host Header Injection risks

Key Takeaway

Use Host Header rules to allow only trusted domains and enforce a default deny (403) for everything else.

Before Optimization

After Optimization

Step-by-Step: Disabling CloudWatch Log Collection in ECS

After identifying that CloudWatch logs were driving up the cost, I looked into where these logs were being generated i.e. ECS Task Definition.

ECS task streams container logs to CloudWatch using the awslogs driver.This is helpful for debugging but quickly becomes expensive in testing, production environments where logs are continuous.

Note: Disabling CloudWatch log collection is recommended only for testing or development environments.

Instead of sending all logs to CloudWatch, you can use a local log driver with rotation.
This approach keeps your logs available for debugging directly on the ECS host while dramatically reducing ingestion and storage costs in CloudWatch.

Step 1: View Current Log Configuration (When Enabled)

In the ECS console, open your cluster’s service and navigate to the Task Definition associated with that service. Under each container definition, you’ll see the log collection (awslogs) option enabled. This configuration pushes all container logs to CloudWatch, which can increase both log ingestion and storage costs.

Step 2: Disable the Log Configuration

To stop unnecessary log streaming, create a new Task Definition revision. In your container definition, open the Log Configuration section, disable the log collection option, then save and deploy the new revision in your ECS service.

After deployment, you’ll notice that the Logs tab in your ECS service now appears empty, this is expected, as log streaming to CloudWatch has been disabled.

Setting Up Local Log Rotation on ECS (EC2 Hosts)

Disabling CloudWatch log collection helps reduce costs, but we still need access to container logs for debugging and monitoring. To handle this efficiently, we can enable local log rotation on the ECS host (the EC2 instance running your containers).

This ensures that container logs are stored locally on the instance and automatically rotated when they reach a certain size, preventing the disk from filling up.

The image below shows the system logs before local log rotation

To verify the logging driver used by a specific container, run the following command:

docker inspect -f '{{.HostConfig.LogConfig.Type}}' <container_id>

Example: docker inspect -f '{{.HostConfig.LogConfig.Type}}' 1e9c943d26d4

Step 1: SSH or directly Session Connect into your ECS EC2 instance

• Switch to root: sudo su

• Go to Docker config directory:

    cd /etc/docker
    pwd   # confirm path
  

  

• Edit daemon.json: vi daemon.json

  

• Add log rotation code: adjust the max-size and max-file values based on your disk capacity and log volume requirements:

    {
      "log-driver": "local",
      "log-opts": {
        "max-size": "20m",  // Maximum size of a single log file (e.g., 20 megabytes)
        "max-file": "7"    // Maximum number of log files to keep
      }
    }
  

  

• Save the file and restart Docker: sudo systemctl restart docker

Step 2: Verify Log Rotation

• After implementing Step 1, verify that log rotation is active for each container: docker inspect -f '{{.HostConfig.LogConfig.Type}}' <container-id>

    docker inspect -f '{{.HostConfig.LogConfig.Type}}' <container-id>
    Example:
    docker inspect -f '{{.HostConfig.LogConfig.Type}}' 1f9c943d25d9
  

  

This confirms that log rotation has been successfully applied and logs are ready for monitoring or debugging.

verify the log path:

sudo ls -lh /var/lib/docker/containers/<container-id>/
# or
sudo ls -lh /var/lib/docker/containers/<container-id>/local-logs/

# OR go to log path

sudo cd /var/lib/docker/containers/<container-id>/local-logs/

sudo cd /var/lib/docker/containers/<container-id>/

If log rotation is configured correctly, you’ll see files like:

container-json.log
container-json.log.1
container-json.log.2

The screenshot below shows an example of checking container logs: docker logs <container-id>

The screenshot below shows how to optimize CloudWatch log costs by configuring log group retention periods.

Conclusion

By shifting non-essential ECS logs from CloudWatch to local Docker rotation, you gain immediate control over your log costs and significantly reduce your AWS bill without losing local troubleshooting capability.

In cloud environments, managing costs is crucial to maintaining efficiency and profitability. With AWS, services like EC2, RDS, and Redis can run 24/7, incurring charges even when idle. By leveraging AWS Lambda for automation, you can optimize these resources to start and stop during off-hours, reducing unnecessary costs.

2. Why Automate Resource Shutdowns?

EC2, RDS, and Redis instances continue to consume resources even when not in use, leading to higher costs. Automating their shutdown during off-hours helps minimize idle resource consumption, potentially saving up to 50% on monthly cloud expenses. For example, stopping EC2 instances during non-peak times or pausing RDS databases overnight can significantly reduce your AWS bill.

3. Step-by-Step Implementation

Below is a detailed step-by-step guide, along with screenshots, to help you implement the automation process for EC2, RDS, and Redis start/stop during off-hours using AWS Lambda. Follow each stage carefully to ensure a seamless setup.

Step1: In the AWS Management Console, navigate to Lambda Service and create lambda function and edit configuration section to increase Timeout value and create new policy, attach to created existing lambda function role as shown in below attached screenshots.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:DescribeInstances",
        "rds:DescribeDBInstances",
        "rds:StartDBInstance",
        "rds:StopDBInstance",
        "elasticache:CreateCacheCluster",
        "elasticache:DeleteCacheCluster",
        "elasticache:DescribeCacheClusters"
      ],
      "Resource": "*"
    }
  ]
}

Note: If you’re using tagged resources, you can narrow the "Resource": "*" field to specific ARNs for better security. For example, replace "*" with the ARNs of your EC2, RDS, or ElastiCache resources.

In the search bar, look for the policy you just created. For example, in my case, it is named lambda-starter-stopper-policy.

Step2: After completing Step 1, click on the newly created Lambda function and enter the script for the EC2, RDS, and Redis instances that you want to automate for starting and stopping. Use the exact/correct name, instance-id and other required details.

After above configuration is done, add script to lambda function starter you created earlier like shown below.

import boto3
region = 'ap-south-1' # replace with your actual region
instances = ['i-001g234456ef'] # replace with your actual instance-id
db_instances = ['frm-test'] # replace with your actual db identifier name

ec2 = boto3.client('ec2', region_name=region)
rds = boto3.client('rds', region_name=region)
elasticache = boto3.client('elasticache', region_name=region)

def lambda_handler(event, context):
    ec2.start_instances(InstanceIds=instances)
    for db_instance in db_instances:
        rds.start_db_instance(
        DBInstanceIdentifier = db_instance
     )
    print('start your instances: ' + str(instances))
    response = elasticache.create_replication_group(
        ReplicationGroupId='frm-test', # replace with your actual redis cache name 
        ReplicationGroupDescription='frm-test', # you can keep the name same as cache name
        NumCacheClusters=1,
        CacheNodeType='cache.t3.micro', # replace with your cache node type
        Engine='redis',
        EngineVersion='7.1', # replace with your engine-version
        CacheSubnetGroupName='subnet-group-redis-project', # replace with your actual subnet group name
        SecurityGroupIds=[
            'sg-00946312345', # replace with your security-group id used by redis
        ],
        PreferredMaintenanceWindow='sun:01:00-sun:02:00', # replace with your actual details
        Port=6379, # replace with your actual redis port
        AutoMinorVersionUpgrade=True
    )

Step 3: After completing Step 2, follow the same approach to create a Lambda function for stopping resources. Refer to the screenshots and script for guidance.

import json
import json
import boto3

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    rds = boto3.client('rds')
    elasticache = boto3.client('elasticache')

    # Stop EC2 instances
    ec2_instances = ['i-001g234456ef'] # replace with your lambda starter mentioned ec2 instance-id
    for instance_id in ec2_instances:
        ec2.stop_instances(InstanceIds=[instance_id])

    # Stop RDS instances
    rds_instances = ['frm-test'] # replace with your lambda starter mentioned db identifier name 
    for instance_id in rds_instances:
        rds.stop_db_instance(DBInstanceIdentifier=instance_id)

    # Stop ElastiCache/Redis clusters
    elasticache_clusters = ['frm-test'] # replace with your lambda starter mentioned redis cache name
    for cluster_id in elasticache_clusters:
        elasticache.delete_replication_group(ReplicationGroupId=cluster_id)

    return {
        'statusCode': 200,
        'body': json.dumps('Resources stopped successfully')
    }

Step4: Create AWS EventBridge scheduler rule for lambda starter/stopper automation.

STOPPER REFERENCE:

STARTER REFERENCE:

NOTE: After creating the scheduler, attach it to the respective starter/stopper Lambda functions for automation. Ensure the scheduler is properly linked to the functions.

Conclusion
By following these steps and creating the AWS EventBridge scheduler rule, you’ve successfully automated the starting and stopping of your resources during off-hours. This approach not only streamlines operations but also significantly optimizes your AWS costs.

Ensure your scheduler rule is correctly set up by referring to the attached screenshots. If you encounter any issues, revisit the steps or consult the official AWS documentation for further assistance.

If this guide was helpful or you have suggestions for improvement, feel free to share your feedback.

By setting up a maintenance window with a cron expression, you can automate the regular cleanup of instances without manual intervention. This setup can be customized to run daily, during off-hours, or at specific intervals such as every few days or weeks. While there are other scheduling options available, configuring a cron expression is typically the easiest. This automation helps maintain optimal storage utilization and performance. Below is a step-by-step guide with screenshots to assist you through each stage of the process.

Step1: In the AWS Management Console, navigate to EC2, locate the IAM role for your instance, and attach the AmazonSSMManagedInstanceCore policy. This grants Systems Manager the permissions needed to manage and clean up your EC2 instances.

Step2: After completing Step 1, connect to the EC2 instance using Session Manager. Verify the Docker and system agent paths by running the following commands: which docker and which systemctl.

Step3: Go to AWS Systems Manager, click on "Documents" in the left sidebar, and create a cleanup document as shown in the screenshots.

• For AWS Linux-Based EC2 Instances(Confirm the Docker and system agent paths after Step 2):

    schemaVersion: '2.2'
    description: "Run Docker cleanup commands on EC2 instances"
    mainSteps:
      - action: aws:runShellScript
        name: runDockerCleanup
        inputs:
          runCommand:
            - /bin/docker stop $(/bin/docker ps -q)
            - sleep 2
            - /bin/docker system prune -a -f
            - sleep 3
            - /bin/docker volume ls -qf dangling=true | xargs -r /bin/docker volume rm
            - sleep 3
            - /bin/systemctl restart ecs
            - sleep 3
            - /bin/docker system prune -a -f
            - sudo sync; sudo echo 3 > /proc/sys/vm/drop_caches
            - /bin/systemctl status ecs
            - /bin/docker ps -a
  

• For Ubuntu-Based EC2 Instances(Confirm the Docker and system agent paths after Step 2):

schemaVersion: '2.2'
description: "Run Docker cleanup commands on EC2 instances"
mainSteps:
  - action: aws:runShellScript
    name: runDockerCleanup
    inputs:
      runCommand:
        - /usr/bin/docker stop $(/bin/docker ps -q)
        - sleep 2
        - /usr/bin/docker system prune -a -f
        - sleep 3
        - /usr/bin/docker volume ls -qf dangling=true | xargs -r /bin/docker volume rm
        - sleep 3
        - /usr/bin/systemctl restart ecs
        - sleep 3
        - /usr/bin/docker system prune -a -f
        - sudo sync; sudo echo 3 > /proc/sys/vm/drop_caches
        - /usr/bin/systemctl status ecs
        - /usr/bin/docker ps -a

NOTE: If your services include cron jobs*, avoid stopping running containers and restarting the ECS service as part of cleanup scripts. This can disrupt scheduled tasks. To modify the provided script for such scenarios, comment out the script lines* docker stop and systemctl restart ecs Use only the prune and dangling volume cleanup commands for such services.

• After the document is created, you can view and verify it as shown in the screenshots below.

Step4: Verify that your EC2 instance appears in Fleet Manager(found in the Systems Manager left sidebar), as shown in the screenshot below.

Step5: Set up a maintenance window to automate the cleanup using the created document, as shown in the screenshots below.

Step6: Navigate to the Systems Manager console, select "Maintenance Windows" from the left sidebar, choose your maintenance window, and click "Register Targets" to schedule the cleanup command on the selected EC2 instances, as shown in the screenshots below.

Step7: Register a "Tasks" to link the cleanup document with the maintenance window and the registered target instances, as shown in the screenshots below.

• Search for the created command document name in the command document search bar and select it.

• Select the target you registered earlier in the maintenance window. Set the concurrency value to 1 (tasks run on one instance at a time) and the error threshold value to 1 (task stops if one instance fails). This ensures sequential execution and halts on errors for accurate control.

• After registering the task, you can view and check the details, including description, tasks, and targets, as shown in the screenshots below.

• Check the history to verify the success or failure status of the cleanup commands executed on EC2 instances during the configured time period, as shown in the screenshot below.

💡

Note: Check Docker overlays and system storage using df -h and monitor memory usage with free -h on your EC2 instances both before and after executing the cleanup commands. Automating cleanup commands helps prevent hitting storage and memory limits, which could cause loss of EC2 server access and poor performance due to full storage, memory, and CPU usage.