Cost Saving Strategies on AWS

As more and more businesses migrate to the cloud, optimizing cloud costs has become an essential part of managing their cloud infrastructure. In this article, we will discuss some cost-saving strategies for AWS that can help businesses reduce their cloud costs.

Step 1: Use the cost explorer to discover the services that are taking most of your costs

The cost explorer is a tool in AWS that allows users to analyze and visualize their AWS costs and usage. It can help businesses identify which services are consuming the most resources and costing the most money. By analyzing this data, businesses can make informed decisions about which services to optimize or even shut down to reduce their costs.

Step 2: Shut down inactive EC2 instances

EC2 instances are a significant cost in AWS, and businesses can save money by shutting down instances that are not being used. This can be achieved by setting up an email alert that informs the user if an instance is idle for greater than x% of the time. The user can then decide to shut down the instance manually or automate the process using AWS Lambda.

Step 3: If you are using ECS, Adjust ECS task definitions based on CPU and Memory utilization

ECS is a container orchestration service in AWS that allows businesses to run and scale containerized applications. By analyzing the CPU and memory utilization of the tasks in the service, businesses can adjust the task definitions of the compute to have lesser CPUs or memory, reducing the cost of the service.

Step 4: Move from ELB to Application Load Balancer

Elastic Load Balancer (ELB) is a service in AWS that distributes incoming traffic to multiple targets, such as EC2 instances, containers, or IP addresses. However, the cost of ELB can be significant, and businesses can save money by moving to Application Load Balancer (ALB), which offers more advanced features at a lower cost.

Pros of using ALB include:

• More granular routing options
• Better support for containerized applications
• Native support for HTTP/2 and WebSocket protocols

Step 5: Consider using alternatives like NGINX for load balancing

Elastic Load Balancer (ELB) and NGINX are both popular load balancing solutions, but they differ in their approach and capabilities. Here is a comparison table that highlights the differences between ELB and NGINX:

Feature	ELB	NGINX
Cost	Can be expensive for larger deployments	Open-source, free, and paid options
Configuration	Limited configuration options	Flexible and customizable
Scalability	Can scale up and down automatically	Can scale up and down manually
Performance	Can handle high traffic volumes	Fast and efficient, high performance
SSL/TLS Offloading	Supports SSL/TLS offloading	Supports SSL/TLS offloading
Health Checks	Supports basic health checks	Supports advanced health checks
Protocols	Supports HTTP, HTTPS, and TCP	Supports HTTP, HTTPS, and TCP
Customization	Limited customization options	Highly customizable

As you can see, both ELB and NGINX have their own strengths and weaknesses. ELB is a managed service, which means that AWS handles the infrastructure and management of the load balancer. However, this comes at a cost, and ELB can be expensive for larger deployments.

How to setup NGINX for load balancing?

To set up NGINX for load balancing and auto scaling with ECS, businesses can follow these steps:

• Launch an ECS cluster and service
• Create a task definition with the NGINX container image
• Configure NGINX to load balance requests to the ECS service
• Set up auto scaling policies for the ECS service based on CPU or memory utilization

7. Explore AWS Route 53 DNS-based load balancing

AWS Route 53 is a DNS service that can be used to route traffic to multiple AWS resources, including EC2 instances, containers, and IP addresses. Businesses with a small number of instances can use Route 53’s DNS-based load balancing to route traffic to their instances, reducing the cost of ELB or ALB.

Step 5: Consider using Route 53 DNS based Load Balancing

If you have a small number of instances, you can use AWS Route 53 DNS-based load balancing to route traffic to your instances. This can be a cost-effective option for smaller applications. A tutorial with sample code can help you set up this service and optimize your usage of it.

To set up Route 53 DNS-based load balancing, businesses can follow these steps:

• Create a Route 53 hosted zone
• Add DNS records for the resources to be load balanced
• Create a health check for the resources
• Configure Route 53 to route traffic to the healthy resources

Here’s a step-by-step tutorial on how to configure NGINX for load balancing and auto scaling if you are using ECS:

1. Launch an Amazon ECS cluster:

First, launch an Amazon ECS cluster using the ECS optimized Amazon Machine Image (AMI). You can follow the instructions in the Amazon ECS documentation to create an ECS cluster.

2. Create an ECS service:

Next, create an ECS service that will run your application. You can follow the instructions in the Amazon ECS documentation to create an ECS service.

3. Install NGINX:

Once your ECS cluster and service are up and running, you can install NGINX on an EC2 instance that will act as the load balancer. You can follow the instructions in the NGINX documentation to install NGINX on an EC2 instance.

4. Configure NGINX:

Next, you need to configure NGINX to act as the load balancer for your ECS service. You can do this by creating an NGINX configuration file that specifies the IP addresses and ports of your ECS tasks.

Example of SAMPLE NGINIX configuration file

http {
    upstream ecs_cluster {
        server <ecs_task_ip_address_1>:<ecs_task_port>;
        server <ecs_task_ip_address_2>:<ecs_task_port>;
        server <ecs_task_ip_address_3>:<ecs_task_port>;
    }
 
    server {
        listen 80;
 
        location / {
            proxy_pass http://ecs_cluster;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

In this configuration file, replace <ecs_task_ip_address> with the IP address of your ECS tasks, and <ecs_task_port> with the port number that your tasks are running on.

5. Configure auto scaling:

Finally, you can configure auto scaling for your ECS service by creating an Amazon CloudWatch alarm that triggers when your ECS tasks exceed a certain CPU utilization threshold. When the alarm is triggered, it can automatically launch new ECS tasks to handle the increased load.

You can follow the instructions in the Amazon ECS documentation to create an Amazon CloudWatch alarm and configure auto scaling for your ECS service.

That’s it! With NGINX, you can configure load balancing and auto scaling for your ECS service to handle increased traffic and demand.

A target tracking scaling policy for an ECS service

Here’s an example of how you can create an Application Auto Scaling policy for scaling ECS tasks:

1. Define a scalable target:

resource "aws_appautoscaling_target" "ecs_target" {
  max_capacity       = 10
  min_capacity       = 1
  resource_id        = "service/${aws_ecs_service.my_service.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
}

This block of code defines an Application Auto Scaling target for an ECS service. The resource_id attribute specifies the ECS service to scale, while the max_capacity and min_capacity attributes define the maximum and minimum number of tasks to run.

2. Define a scaling policy:

resource "aws_appautoscaling_policy" "ecs_policy" {
  name               = "ecs-scaling-policy"
  policy_type        = "TargetTrackingScaling"
  resource_id        = "${aws_appautoscaling_target.ecs_target.id}"
  scalable_dimension = "ecs:service:DesiredCount"

  target_tracking_scaling_policy_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }
    target_value = 60.0
  }
}

This block of code defines an Application Auto Scaling policy for an ECS service. The policy_type attribute specifies that this is a target tracking scaling policy, which adjusts the number of tasks to maintain a target value for a specified metric. In this case, we are using the ECSServiceAverageCPUUtilization metric and setting a target value of 60%. This means that Application Auto Scaling will automatically adjust the number of tasks to maintain a CPU utilization of around 60%.

3. Attach the policy to the target:

resource "aws_appautoscaling_policy_attachment" "ecs_attachment" {
  policy_arn = "${aws_appautoscaling_policy.ecs_policy.arn}"
  target_arn = "${aws_appautoscaling_target.ecs_target.arn}"
}

This block of code attaches the Application Auto Scaling policy to the ECS service target.

With this setup, Application Auto Scaling will automatically adjust the number of ECS tasks running in response to changes in the specified metric (in this case, CPU utilization). This allows your application to automatically scale up and down to handle varying workloads without requiring manual intervention.

Note that you can customize the metrics and target values to suit your specific use case. You can also create multiple Application Auto Scaling policies for the same target, each with different metrics and target values.

Configure NGINX to act as a load balancer

To configure NGINX to act as a load balancer, you can follow these steps:

1. Install NGINX: You can install NGINX on your server by using your package manager. For example, if you are using Ubuntu, you can use the following command to install NGINX:

sudo apt-get update
sudo apt-get install nginx

Configure NGINX as a load balancer: You can configure NGINX to act as a load balancer by editing the /etc/nginx/nginx.conf file. Here is an example configuration for a simple load balancer that balances requests between two backend servers:

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend;
        }
    }
}

In this configuration, the upstream directive defines a group of backend servers, and the proxy_pass directive in the location block directs requests to the backend servers.

Restart NGINX: After editing the configuration file, you need to restart NGINX to apply the changes. You can use the following command to restart NGINX:

sudo systemctl restart nginx

Test the load balancer: To test the load balancer, you can use a tool like curl to send requests to the server. For example, you can use the following command to send a request to the load balancer:

curl http://example.com

You should see a response from one of the backend servers.

Configure ECS with task definitions and auto scaling

To configure ECS with task definitions and auto scaling, you can follow these general steps:

1. Create a task definition: A task definition is a blueprint for how to run a specific Docker container within a task. It specifies the Docker image to use, how much CPU and memory to allocate to the task, and other configuration details. You can create a task definition using the AWS Management Console or the AWS CLI.
2. Create a service: A service is a long-running task that is automatically started and stopped by ECS. A service is associated with a task definition, and it can be configured to run a specific number of tasks (called the desired count). You can create a service using the AWS Management Console or the AWS CLI.
3. Configure auto scaling: You can use the AWS Application Auto Scaling service to set up auto scaling for your ECS services. Auto scaling allows you to automatically increase or decrease the number of tasks in your service based on metrics like CPU usage or memory usage. To configure auto scaling, you’ll need to create an auto scaling target and a scaling policy. You can do this using the AWS Management Console or the AWS CLI.

Here’s an example of how to create an ECS service with task definitions and auto scaling using the AWS Management Console:

1. Create a task definition:
   • Go to the Amazon ECS console and choose “Task Definitions” from the left navigation pane.
   • Choose “Create new Task Definition” and select “EC2” or “Fargate” depending on your requirements.
   • Configure the task definition details like the container image, CPU, memory, port mappings, etc.
   • Choose “Create” to save the task definition.
2. Create a service:
   • From the ECS console, select “Clusters” from the left navigation pane and choose the cluster you want to use.
   • Choose “Create Service” and configure the service details like the task definition, desired count, and load balancer settings.
   • Choose “Create Service” to save the service.
3. Configure auto scaling:
   • From the Amazon ECS console, choose “Clusters” from the left navigation pane and select the cluster you want to use.
   • Choose the “Services” tab and select the service you want to set up auto scaling for.
   • Choose the “Auto Scaling” tab and select “Configure Auto Scaling.”
   • Choose the metrics to use for scaling, such as CPU utilization or memory usage.
   • Configure the scaling policy, such as the minimum and maximum number of tasks to run.
   • Choose “Create” to save the auto scaling configuration.

With these steps completed, ECS will automatically start and stop tasks as needed based on the scaling policies you’ve configured.

Here is an example Terraform code for configuring an ECS service to use the target group:

resource "aws_ecs_service" "example" {
  name            = "example-service"
  cluster         = aws_ecs_cluster.example.id
  task_definition = aws_ecs_task_definition.example.arn
  desired_count   = 2
  
  load_balancer {
    target_group_arn = aws_lb_target_group.example.arn
    container_name   = "example-container"
    container_port   = 80
  }
}

here is an example of how to create an aws_lb_target_group resource in Terraform:

resource "aws_lb_target_group" "example" {
  name        = "example-target-group"
  port        = 80
  protocol    = "HTTP"
  vpc_id      = aws_vpc.example.id

  health_check {
    path     = "/"
    protocol = "HTTP"
  }
}

This creates an aws_lb_target_group resource named “example-target-group” listening on port 80 using the HTTP protocol, and performing a health check by sending an HTTP request to the root path of the target. The target group is associated with the VPC identified by the aws_vpc.example.id variable.