DEV Community: Amine AIT AAZIZI

Automated EKS Cost Optimization with AWS Config

Amine AIT AAZIZI — Tue, 06 Jan 2026 12:19:03 +0000

Through the past years, I helped a number of organizations to optimize cloud costs in AWS, more particularly additional EKS costs. I mainly used AWS config that assesses, audits, and evaluates the configurations of your resources in your AWS account.

How did I use this service for cost optimization? Well consider a scenario where we can be alerted if a specific EKS cluster is deployed in the account. If this EKS cluster goes to extended support, you will be paying 6x the cost of a regular EKS cluster with a supported version.

This blog post demonstrates how to implement a custom rule in AWS Config, to optimize cost by monitoring EKS cluster. The custom AWS Config rule monitors the account checking the version of EKS cluster running. Then when a deprecated EKS version is deployed, AWS Config will flag it as non-compliant.

Overview of solution

The AWS Config custom rule invokes the AWS Lambda function that detects if an EKS cluster is in a non-supported version. The invocation of this function occurs every time there is a new EKS cluster detected in the account.

The AWS Config custom rules invoke a Lambda function that contains the logic to evaluate whether the EKS cluster is either Compliant or Noncompliant. For this we will be relying on endoflife that provides an API to fetch deprecation data directly.
Nothing will happen if the resource is evaluated as compliant. However, If the resource is evaluated as non-complaint, then the lambda function will send an alert through an AWS Simple Notification Service (Amazon SNS) topic to the administration team which will allow the account administrators to take the corrective action.

An alternative solution would have been to use the AWS managed config rule to manage supported EKS clusters … But there are 2 issues with this solution:

1- This rule requires regular updates each 3/6 months to update the oldestVersionSupported parameter as EKS releases and deprecates versions regularly.
2- If you don’t specify the oldestVersionSupported parameter, AWS will evaluate and consider all the versions including the ones on extended support as compliant … and this is exactly what we are trying to avoid.

Deployment

Prerequisites: You must have setup AWS credentials in your environment

Clone repository

git clone https://github.com/aaitaazizi/custom-aws-config-rules-for-eks.git && cd custom-aws-config-rules-for-eks

Generate cloudformation template using rain

rain pkg aws-config-eks-version-rule/template.yaml --output aws-config-eks-version-rule/template.out.yaml

Deploy

aws cloudformation deploy \
--template-file custom-eks-version-rule.out.yaml \
--stack-name aws-config-eks-version-rule-stack \
--parameter-overrides NotificationEmail=YOUR_EMAIL  \
--region eu-west-1 \
--capabilities CAPABILITY_IAM \
--no-cli-pager

Multi-account deployment

In an organization and multi-account context, you may have to consider options such as using Cloudformation stacksets or AWS config conformance packs to adapt the current template to your needs. This will deploy your AWS config rule across all the accounts and enable EKS cost efficient governance inside your AWS organization.

An additional rule for non-critical workloads

One of the rules that you could additionally add for non-critical workload is to force EKS cluster to have the STANDARD upgrade policy instead of the EXTENDED upgrade policy which is the default value.

So technically, what you can do is to create a new config rule that considers any EKS cluster with EXTENDED support policy as non compliant. Then, you can add a remediation action in order to force the update of this cluster into a STANDARD policy. This will ensure that all the clusters will auto upgrade as soon as they reach the standard end of support period of the EKS cluster.

It’s important to note that it should be deployed to non-critical and/or non-production environments. Here’s an example of solution you can deploy in your account directly to assess the compliance of EKS cluster upgrade policy (without the remediation for now) accessible via this folder repository

Use cases and benefits

Reduce EKS control-plane spend by avoiding Extended Support premium charges through early detection and timely upgrades.

Improve security posture by keeping clusters on supported versions that continue receiving fixes and security updates.

Standardize platform governance by applying one consistent policy to every EKS cluster in the organization. This will strengthen ownership and accountability by making version drift visible to the right service owners via tags, reports and dashboard such as the EKS dashboard.

Enable proactive lifecycle planning by surfacing clusters nearing end-of-support early enough to schedule maintenance windows.

What’s next ?

Automating cost governance is the most effective way to prevent EKS budget overruns before they happen. I suggest you give this solution a try and/or adapt it with your own business requirements and let me know what you think. If you have any feedbacks or thoughts, please feel free to submit comments.

AWS simplified Cloudtrail events monitoring using Cloudwatch Logs

Amine AIT AAZIZI — Tue, 23 Dec 2025 18:28:06 +0000

Most AWS environments have AWS CloudTrail enabled, but very few teams actually detect critical events in real time. The recent announcement from AWS Re-invent simplified CloudWatch integration for CloudTrail.

So instead of just recording history, you can now react to every sensitive API call within seconds by streaming CloudTrail events directly into CloudWatch Logs for alerts, dashboards, and automation.

In this article, I will try to share some interesting insights regarding this topic by answering these following questions

Why is Cloudtrail alone not enough for monitoring ?

CloudTrail is excellent at answering “who did what, where, and when” for AWS API calls. But its main purpose is auditing, not operational monitoring.

It’s true that the CloudTrail console is optimized for compliance investigations but not continuous detection. Why ? because it doesn't provide native real-time alerting, metrics, or rich dashboards. This is exactly why you still need another service for that and that’s what CloudWatch Logs is designed for.

How was cloudwatch monitoring done before the announcement ?

Before this update, achieving observability of CloudTrail events in CloudWatch required a multi-step configuration.
Firstly, you had to create a Trail and explicitly configure it to push events to an S3 bucket primary and CloudWatch Logs log group optionally using an IAM role

Secondly, you had to explicitly create an IAM Role with a trust policy allowing the cloudtrail principal to assume it, and the required permission policies.

In addition, enabling this across an Organization often mean complex StackSets or Control Tower customizations to ensure every new account had this Trail-to-CloudWatch configuration.

How can you achieve it now after the update ?

Now with the new update, you can now configure everything directly from the Cloudwatch console.

You no longer need to create or manage a CloudTrail "Trail" object just to get logs into CloudWatch. The integration uses Service-Linked Channels (SLCs), which acts as background pipes that AWS services use to communicate securely.

One of the advantages of using Service-Linked Channels and Service-Linked Roles, the IAM permissions are managed automatically by AWS. You do not need to manually create and maintain an IAM role for this ingestion pipeline.

After these Re-invent updates, The workflow is now consistent with other AWS native logs such as VPC, EKS … providing a simplified way for configuring all telemetry ingestion in one place.

What are the key benefits of cloudtrail monitoring ?

Monitoring CloudTrail events in CloudWatch Logs can have several benefits:

Real-time alerts and automation

You can turn log patterns into metrics and then create CloudWatch alarms that notify via SNS, PagerDuty, etc., or trigger remediation via Lambda.

Single pane for all logs

CloudWatch Logs can centralize app logs, OS logs, VPC Flow Logs, and CloudTrail in one place, with a consistent query language and dashboards. This makes correlation like “API call happened here, app error happened there” much easier. More details are available in this announcement

Powerful querying and visualization

CloudWatch Logs Insights lets you run ad‑hoc queries, aggregate, group, and visualize CloudTrail events alongside other logs. This can be done in the cloudwatch console or using tools such as AWS managed Grafana with cloudwatch plugin.

A real-world Use case

Let suppose that you want to get alerted when some critical IAM changes happen such as CreateAccessKey. CloudTrail records this as a management event with eventSource = "iam.amazonaws.com" and eventName = "CreateAccessKey".

After configuring CloudTrail events to be delivered to a CloudWatch Logs log group using the new cloudwatch console -> Log management -> Data source -> Select Cloudtrail, You need to create a metric filter using this filter pattern:

{ ($.eventSource = "iam.amazonaws.com") && ($.eventName = "CreateAccessKey") }

This matches any CloudTrail event where IAM’s CreateAccessKey API was called.

Now every time CreateAccessKey appears in the logs, CloudWatch increments your metric by 1. Now the only thing left to do is to configure you alarm so that If at least one access key was created in the last 5 minutes as an example, go into ALARM state … and sends a notification (and/or executes remediation if needed)

Do I still need to use trails or Cloudtrail Lake ?

The answer is Yes. Using CloudTrail Lake or Trails with S3 will always be useful for long-term audit, compliance and data storage.

Trails are a foundational system of records with continuous capturing management events and writing them to hardened S3 buckets with long retention. Organization trails centralize activity from all accounts and regions so you can prove to auditors that logging is consistent across the entire organization.

On the other side, CloudTrail Lake builds on that stream as an audit analytics warehouse, storing events in dedicated event data stores with multi‑year, policy‑driven retention and letting you run SQL queries that are more efficient than searching raw S3 logs.

What’s next ?

By streaming events into CloudWatch Logs using the new simplified integration, you unlock real-time detection of threats like failed logins, IAM escalations, and access key creations, turning passive audit logs into active defenses.

You can start and implement this today in your AWS account. From a FinOps perspective, there is no difference as you will still be charged for both CloudTrail event delivery charges and CloudWatch Logs ingestion fees based on custom logs pricing.