AWS DevOps Case Studies: Terraform, App Runner, WAF · Remote Since Forever

How a CloudFront Custom Error Page Leaked JWTs to S3: A Case Study

2026-08-13T11:00:00+02:00

A client was preparing to put an API behind CloudFront in production. During the final penetration test, one curl request showed that every distribution with custom error pages was reflecting users' JWT tokens in S3 XML error responses.

Sixteen distributions shared the same copy-pasted Terraform block.

CloudFront is AWS's content delivery network (CDN). A JSON Web Token (JWT) is the signed session string the API gives a user after login. curl is the command-line tool we use to send HTTP requests by hand. Three terms are enough to follow the finding.

CloudFront was handling TLS at the edge, HTTP/2 and HTTP/3 connections, DDoS protection, and branded error pages from a separate S3 bucket. The staging setup had been running for weeks. The distributions were stable, the error pages rendered correctly, and the TLS grades looked good.

The One-Line Proof

curl https://your-api.example.com/custom_error_pages/502.html \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.YOUR_ACTUAL_TOKEN"

If your response looks like this, you're vulnerable:

<?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>InvalidArgument</Code>
  <Message>Unsupported Authorization Type</Message>
  <ArgumentName>Authorization</ArgumentName>
  <ArgumentValue>Bearer eyJhbGciOiJIUzI1NiJ9.YOUR_ACTUAL_TOKEN</ArgumentValue>
</Error>

Your full JWT (user ID, email, role, expiry, everything in the payload) reflected back in an S3 XML error response. The path exists on practically every CloudFront distribution with custom error pages. Any GET request with an Authorization header triggers it, no authentication and no origin failure required.

S3 reflects any Authorization scheme, not just Bearer. Basic auth credentials (Basic dXNlcjpwYXNzd29yZA==), API tokens (Token API_TOKEN_VALUE), anything non-AWS gets dumped into the XML. If your API uses any of these, the same leak applies.

Cookies, X-API-Key, and custom headers are forwarded to S3 too but not reflected in the XML. S3 only complains about the one header it tries to parse.

Why did CloudFront forward the `Authorization` header to S3?

A CloudFront distribution sits between users and one or more origins (the actual servers that hold your content). Each origin gets a behavior that tells CloudFront which requests to route there and what to forward along.

In this pattern, there are two origins behind one distribution:

The API behavior needs viewer headers. The S3 error-page behavior does not.

The API origin is your application: an Application Load Balancer (ALB) in front of Elastic Container Service (ECS) containers, a Lambda function, or an EC2 instance. It needs the viewer's Authorization header to authenticate requests, Content-Type to parse bodies, and cookies for sessions. Forwarding everything to this origin is correct.

The error page origin is an S3 bucket containing three static HTML files: 502.html, 503.html, and 404.html. It serves the same branded "We'll be right back" page to every user regardless of who they are.

It needs nothing from the viewer: not their identity, not their cookies, not their query strings. It just needs CloudFront to ask for a file by path, and it returns the HTML.

The problem is that both origins were given the same origin request policy: the one designed for the API. So when CloudFront routes a request to the S3 error page bucket, it sends along everything the viewer included, including Authorization: Bearer <JWT>.

S3 is not your API. It doesn't understand Bearer tokens. It tries to interpret the Authorization header as AWS Signature Version 4, fails, and returns an XML error that includes the header value it couldn't parse. Your JWT is now in the response body.

The setup looks like this in Terraform (CloudFormation and the console follow the same pattern):

# Origin 1: Your API (ALB, ECS, Lambda, etc.)
origin {
  domain_name = aws_lb.api.dns_name
  origin_id   = "api"
}

# Origin 2: S3 bucket with static error pages
origin {
  domain_name = aws_s3_bucket.error_pages.website_endpoint
  origin_id   = "error-pages"
}

# When the API returns 502, serve the S3 error page instead
custom_error_response {
  error_code         = 502
  response_page_path = "/custom_error_pages/502.html"
}

# Behavior for the API (default): forwards all viewer headers
default_cache_behavior {
  target_origin_id         = "api"
  origin_request_policy_id = aws_cloudfront_origin_request_policy.AllViewerExceptHostHeader.id
}

# Behavior for the error pages: ALSO forwards all viewer headers
ordered_cache_behavior {
  path_pattern             = "/custom_error_pages/*"
  target_origin_id         = "error-pages"
  origin_request_policy_id = aws_cloudfront_origin_request_policy.AllViewerExceptHostHeader.id
  # ↑ THIS IS THE PROBLEM
}

The AllViewerExceptHostHeader policy tells CloudFront: "forward every header the viewer sent (Authorization, Cookie, X-Custom-Whatever) to the origin, except Host." That's correct for the API behavior, where your backend needs those headers. It's catastrophically wrong for the error page behavior, where the origin is an S3 bucket serving static HTML.

Three ways the token leaks

The error page path isn't linked anywhere. No browser navigates to /custom_error_pages/502.html during normal use. Three practical routes still reach it.

The path is trivially discoverable by scanners. It's in CloudFront's own documentation examples, and tools like ffuf, feroxbuster, and nuclei include /error/, /custom_error_pages/, and /502.html in their default wordlists. A scanner that hits the path and sees <Code>InvalidArgument</Code> with <ArgumentName>Authorization</ArgumentName> in the XML response can identify the misconfiguration from the shape alone. Our pentest tooling found this one that way.

A production outage can leak the token without any scanner. When the origin returns 502/503, CloudFront intercepts the error and fetches the S3 error page with the original request's Authorization header attached. The user didn't navigate to the error page; CloudFront sent them there. Their token leaks through a normal deployment, container restart, or scaling event, visible in the response body to any browser extension, corporate proxy, or compromised CDN edge watching that window.

Path	Trigger	Result
Direct access	A GET request with an `Authorization` header reaches `/custom_error_pages/502.html`.	S3 reflects the header in XML. No origin failure is needed.
Origin failure	An API request carries a JWT, then the origin returns 502 or 503.	CloudFront fetches the S3 error page with the original headers, and the token comes back to the user.
Plain HTTP	The error-page behavior uses `viewer_protocol_policy = "allow-all"`.	A network attacker can read the token without breaking its cryptography.

Most of the distributions we audited had the plain-HTTP setting. The API behavior used redirect-to-https; the error-page behavior was a separate block with separate settings.

The Terraform Template Problem

We found this in a client's infrastructure codebase. We audited every CloudFront distribution across their staging and production accounts. The same ordered_cache_behavior block for /custom_error_pages/* showed up on distribution after distribution, all pointing to the same S3 error pages bucket, all using AllViewerExceptHostHeader.

The block was written once for the API distribution, where it was correct. Then it was copied to every other distribution (SPAs, admin dashboards, static sites, upload CDNs) because it "worked" and nobody questioned whether a static error page bucket needed to receive the viewer's Authorization header.

Terraform's copy-paste turned one mistake into a pattern across the whole account.

A handful of the affected distributions served authenticated traffic (APIs and legacy apps). Those were fully exploitable: every authenticated request that hit a 502 leaked the caller's JWT. The rest served static frontends that don't normally receive Authorization headers, but the direct-access path still worked on all of them.

The Chain That Made It Critical

The JWT leak alone is a HIGH: you can capture a token and replay it for the remaining access-token lifetime. But during this engagement, we found it chained with something else that pushed it to CRITICAL.

The API signs session tokens with a JWT secret. On staging, that secret was hardcoded as a trivially guessable value in the ECS task definition's plaintext environment block. Not in Secrets Manager, not pulled from SSM Parameter Store, just a short, dictionary-word string sitting in Terraform.

We confirmed the secret remotely without any internal access. The API returns different error messages depending on whether a token's signature verifies:

# Token signed with the guessable secret (correct):
curl -X POST https://api.staging.example.com/api/session/token \
  -H "Cookie: session=<forged-token-signed-with-guessable-secret>"
# → "Session has been revoked" (signature PASSED, DB hash lookup failed)

# Token signed with wrong secret:
curl -X POST https://api.staging.example.com/api/session/token \
  -H "Cookie: session=<token-with-wrong-signature>"
# → "Invalid session" (signature FAILED)

That error difference acts as an oracle. "Session has been revoked" means the JWT signature verified successfully; the server moved past cryptographic verification to the database lookup phase. "Invalid session" means the signature check failed. The two code paths are distinguishable remotely.

We proved the full chain end-to-end

We registered a test account and signed in. We captured the session token, leaked it through the error page, and validated it offline. Then we replayed it and had the account. All with curl.

Step 1: Sign in. We registered a test account and signed in. The server set an httpOnly session cookie. It was a long-lived JWT signed with the guessable secret.

Step 2: Leak the token. We sent a GET request to the error page path. The session token was in the Authorization header. The S3 XML error returned it verbatim. Byte for byte, it matched the original.

Step 3: Validate offline. We computed the HMAC-SHA256 signature using the guessable secret. It matched the token's signature exactly. No server interaction needed. The attacker now knows the token is real, who it belongs to, and when it expires.

Step 4: Replay. We sent the leaked session token to the token endpoint. The server verified the JWT signature (passed) and looked up the token hash (found a real active session). It minted a fresh access token.

Step 5: Account takeover. We used the fresh access token to call the user-profile endpoint. The server returned the full profile: ID, email, name, role, all PII fields. Full account access with no password. All from a token that was never meant to leave the httpOnly cookie jar.

The leak becomes account takeover when the staging JWT secret is guessable.

We ran the entire chain with curl against a live staging environment. We didn't need source code access to exploit it. We only needed it to discover the hardcoded secret in Terraform. An external attacker reaches the same outcome by guessing the secret or by intercepting a token through the error page leak.

The public bucket

The bucket is also enumerable:

curl https://your-error-pages-bucket.s3.amazonaws.com/

Returns a full ListBucketResult XML with every file, size, ETag, and last-modified timestamp, no authentication required.

It's public because the error page origin uses an S3 website endpoint, which forces public read access. OAC (Origin Access Control) only works with the REST API endpoint. The pages themselves are benign HTML, but the bucket is one IAM policy drift away from attacker-writable: a phishing form in a 502 page would be served by your own domain, from your own CloudFront distribution, with your own TLS certificate.

The Fix

The error page behavior serves static HTML from S3. It doesn't need the viewer's auth token, cookies, query strings, or any other header.

When you omit origin_request_policy_id entirely, CloudFront sends only the minimum required headers to the origin. That is enough for an S3 website endpoint to fetch a file by path, and there is nothing left for S3 to reflect back.

The simplest fix is to delete the origin_request_policy_id line from every error page behavior. It shouldn't have been there in the first place.

But if you want to be explicit about the intent (and make it harder for someone to re-add a permissive policy later thinking it was accidentally removed), define a policy that forwards nothing:

resource "aws_cloudfront_origin_request_policy" "ErrorPagesNoAuth" {
  name    = "ErrorPages-NoAuth"
  comment = "Error pages are static HTML, no viewer headers needed"

  headers_config {
    header_behavior = "none"
  }
  cookies_config {
    cookie_behavior = "none"
  }
  query_strings_config {
    query_string_behavior = "none"
  }
}

Then in every ordered_cache_behavior for /custom_error_pages/*:

ordered_cache_behavior {
  path_pattern             = "/custom_error_pages/*"
  target_origin_id         = "error-pages"
  origin_request_policy_id = aws_cloudfront_origin_request_policy.ErrorPagesNoAuth.id
  viewer_protocol_policy   = "redirect-to-https"
  # ... rest unchanged
}

Verification:

# Before fix:
curl https://your-api.com/custom_error_pages/502.html \
  -H "Authorization: Bearer TEST"
# → <ArgumentValue>Bearer TEST</ArgumentValue>  ← LEAKED

# After fix:
curl https://your-api.com/custom_error_pages/502.html \
  -H "Authorization: Bearer TEST"
# → <!DOCTYPE html><html>...(your 502 page HTML)...  ← SAFE

For defense in depth:

Switch the S3 origin from a public website endpoint to a private bucket with OAC. This closes the public listing vulnerability and eliminates the unencrypted HTTP origin protocol.
Set error_caching_min_ttl = 0 so error responses aren't cached at all.
Set viewer_protocol_policy = "redirect-to-https" on the error page behavior so the path can't be accessed over plain HTTP.

Forwarding headers to error pages is valid when the origin needs the viewer's identity: a Lambda@Edge function rendering personalized error pages, a Cognito-gated bucket, or a debugging service logging which user hit the error. In those cases the origin is an application that can safely consume auth headers. If your error page origin is S3, the answer is always header_behavior = "none".

What we shipped

Sixteen distributions closed. The JWT reflection path is gone across the client's account, and HTTP-to-HTTPS is enforced on every error-page behavior. The one residual risk (the public S3 website endpoint) is on the follow-up list.

How to Check If You're Vulnerable

Step 1: Find your error page path. Look for custom_error_response blocks in your CloudFront distribution. The response_page_path tells you where the error pages live.

Step 2: Send a request with an auth header.

curl -s https://your-domain.com/custom_error_pages/502.html \
  -H "Authorization: Bearer CHECK_THIS_TOKEN"

Step 3: Check the response. If you see <ArgumentValue>Bearer CHECK_THIS_TOKEN</ArgumentValue> in the XML, you're vulnerable. If you see your HTML error page, you're fine. A 403 means the path doesn't exist or the behavior doesn't allow GET, which is also fine.

Step 4: Check all your distributions. If you use the same Terraform module or copy-paste pattern across distributions, check every one. In one engagement we found the majority of distributions sharing the same misconfiguration. The one you check might be fine while a dozen others are leaking.

Check every distribution

Nobody asked whether a static HTML bucket needed the same headers as an authenticated API. If you're running CloudFront with custom S3 error pages, spend sixty seconds running the curl command above against each distribution.

A note on responsible testing: every test account created during this engagement was registered with a non-existent @example.com address, used only for curl-based proof-of-concept, and cleaned up after the findings were documented. No real user sessions were intercepted or replayed. The full chain was proven end-to-end using our own credentials against a staging environment with explicit authorization from the infrastructure owner.

An Event-Driven Architecture Case Study: Lessons from a Real-World Application

2025-04-07T19:32:53+02:00

Over the past decade, Clearview Team has built and maintained a pair of interconnected platforms for a confidential awards group. This is the event-driven AWS architecture that keeps both systems observable.

Prefer a downloadable version Read the case study as a PDF Download

The Client

A Confidential Non-profit and Awards Group *Membership Operations, Automated and Simplified *

At one time managed primarily through Excel spreadsheets and mail-in forms, the client’s membership system was functional but time-intensive for its administrators. With the benefit of an automated, online membership management system, client’s Board of Directors wisely contracted Clearview to combine member-related functions into one web-based platform.

More than a decade later, we’re still working in close partnership with the client to maintain and streamline member processes and relations through a secure, custom-built online portal. We’re continually finding new ways to empower administrators and members alike with rich tools and features, supporting this 501(c)(3) non-profit’s continued growth.

Purpose-built member dashboard with quick access to useful member functions including online signup, membership upgrade, and renewal; info & address changes; member-only services and perks; automated password reset & forgotten login recovery; notification preferences.
Powerful administrator dashboard, complete with tiered admin privileges, quick member lookup & sorting, bulk member management, numerous import/export options, and detailed reports.
Secure, multi-method payment processing with in-dashboard payment logs, receipts, and refund processing.
Newsletter and notification management including automated synchronization with MailChimp newsletter and SendGrid transactional email platforms.
Scheduled self-maintenance and member relations tasks including proactive address validation and expiration notifications.

The Digital Workflow Platform

Annual Intake and Review Workflow

The client also runs an annual intake-and-review cycle that once involved sorting through over a thousand hand-mailed physical packages. This veritable mountain of material was then shuffled through very extensive multi-stage review and selection processes by hand.

Since joining the client’s team in 2010, Clearview has systematically brought each of these processes together in a single online platform.

Fully web-based intake process, including secure online payment; upload of video clips, documents, and signoff forms; followup intake for supplementary materials.
Automated media verification, storage, and transcoding, utilizing Vimeo API integration for high-quality, secure, and familiar playback for reviewers. All media is secured against unauthorized download.
Advanced partner dashboard, enabling organizations with many moving parts to delegate intake tasks to multiple designated contributors and divide labor.
Review management, including secure reviewer application and selection process; a dedicated review portal with high-quality material review, shortlisting, issue flagging, and discussion features; selection and notification workflows.
Selection management, including application and eligibility processes and a secure selection interface.
Tight integration with the organization’s membership database for permissions verification.
Extensive administration dashboard, including tiered admin roles; organization and intake management; category and field management; payment, receipt, and transaction management; flexible sponsor-credits system; deadline management, late fee rules, and exceptions; numerous import/export tools.
Secure, triple-redundant data archival following each year’s cycle.
On-call support, including email support for contributors, reviewers, and participants.

The Project

Clearview Team's engineers and clients are spread across time zones, so monitoring and incident response carry real coordination overhead. This engagement is where we chose Event-driven architecture.

Challenges

The challenges we aim to solve with this approach:

Decoupling of services: To improve the agility of the application we designed our system not to be tightly coupled.
Real-time responsiveness: The application services operate on event-driven communication, which means the services can produce an event in real time. This enables our on-call engineers to react to important events that are produced by either user actions or system events.
Improved observability: The event-driven approach improves system observability. By analyzing event flows, we constantly monitor and improve the system behavior, identify bottlenecks, and locate the root cause of issues more effectively.

Deployment

The application is deployed on the AWS Cloud platform as AWS already provides all the communication buses that we need to produce, broker, and consume events.

Event Types We have covered the most important event types in the app, such as:

Finance events
Membership events
Scheduled job events
Health check events.

Goals

This project aims to solve the client’s requirements to create and continuously improve the membership and awards system while implementing a modern system architecture. More details about what kind of problems the application is designed to solve can be seen in the diagram below.

System Architecture

This application is built around separate services, each running inside its own container. Services communicate through events — state changes that trigger actions elsewhere in the system.

Event-driven Architecture

An event is a state change — a user placing an order, a payment failing, a scheduled job firing. Services produce events and other services consume them, without needing to know about each other directly.

Event-driven architecture is often called EDA for short.

The rest of this post covers how we wired the event bus for job scheduling and monitoring — the piece that lets our team get notified in real-time and react before downtime reaches users.

Event-driven Architecture Showcase

Below is a diagram showing what a typical EDA system looks like and how it functions.

AWS based Event-driven architecture

The Application

The application is built on NodeJS with an API service serving multiple front-end domains. This approach has served us well. We have been running the app as a container on AWS.

The diagram shows API and the DB secured and isolated in the VPC. Frontend is served to the client via CloudFront which pulls the website assets from the S3 bucket.

Please keep in mind that the client communicates with the API after it has been loaded on the client-side rendered website.

Event Producers

Events are generated from various services and can be produced either by a client action or by a scheduled job.

API Event Producer

The best example of a client-produced event is any type of event related to credit card payments. The app uses the “@aws-sdk/client-eventbridge” library to communicate with the AWS Event Bridge service.

API Events List

The core services of the app produce events. Below is a list of services with a description of what each does.

The diagram shows API Services and Controllers that send events.

API Produced Sample Events

Finance Related Events Below you can find payment processing failed sample events

Health Check Events

Mailing List Events

Scheduler Event Producer

As it was not necessary to re-implement the wheel and create our scheduling service, we relied on the well-tested and proven AWS EventBridge Scheduler for the scheduling system. For this purpose a custom and dedicated Event Bus was created and named Client Production Scheduler Bus.

In this case, the Event Producer is the Scheduler itself.

The diagram shows events that are sent from the first event producer which is the Event Bridge Scheduler received and processed by The Production Event Bus, parsed by AWS Lambda, and at the end sent to a Slack webhook.

As per the diagram every cron job has the following flow:

a scheduler of recurring type that produces an event and sends it to the custom scheduler bus,
an endpoint that is defined as part of the api_destination event rule.

Evaluated Jobs

The complete list can be found below.

The diagram shows the list of Scheduled jobs, their endpoints, and json payload event they generate which gets sent to the Event Bus.

Company Statistic Scheduled Job

The diagram shows events that are produced the Event Bridge Scheduler, received and processed by The Production Event Bus, and forwarded to the target which is unique endpoint via API Destination.

Event Scheduler Job Notes:

Recurring schedule type
Cron expression style
Runs every 8 hours
Target: Scheduler Bus
API PutEvents

Event Rule

The bus receives the event and triggers the api cron company statistic rule.

API Destination

The Infrastructure

In this section, we will cover how the AWS infrastructure was set up, the services that send events to the default Event Bus, and how we process and consume those events.

The AWS Account

We used AWS Organizations to separate Production and Development environments. This is important as infrastructure-related events are sent to the default event bus. We wanted production and development events not to trigger the same rules as this could lead to unexpected behaviors.

The diagram shows how we separated production and development accounts while managing both with a single management account.

It makes it easier to have two environments not mixing up as we know for a fact that development events will not end up on the production Event Bus causing potential problems.

AWS RDS

The database service’s health and availability are very important for the app’s reliability. Therefore, we have a setup of monitoring database events with Slack notifications.

Every time there is an event such as the database service backing up an event is created and sent to the Event Bus. Such an event will end up as a Slack notification and be read by our team.

The diagram shows events that are sent from the MariaDB service, received and processed by AWS EventBridge, parsed by AWS Lambda, and at the end sent to a Slack webhook.

We decided that the following event categories will be forwarded to Slack: Notification, availability, backup, failure, low storage, maintenance and recovery.

The EventBridge Rule

AWS Health

The diagram shows events that are sent from the AWS Health service, received and processed by AWS EventBridge, parsed by AWS Lambda, and at the end sent to a Slack webhook.

Events type can be one of the following categories:

accountNotification
issue
scheduledChange

AWS Health events are sent to the default Event Bus. We want to react when we receive an event from the AWS Health service, therefore we create rules. For example, you can use AWS Health to receive email notifications if you have AWS resources in your AWS account scheduled for updates, such as EC2 instances. Below you can find examples of such rules.

EC2 service

Sample rules

Trigger on Every Event

Trigger on Specific Service-related Event

Rule for a specific service and event type category.

In this example, we will create a rule so that EventBridge reacts to the following.

Multiple Services and Event Type Categories

The examples in the previous procedure show you how to create a rule for a single service and event type category. You can also create a rule for multiple services and event-type categories. This means that you don’t have to create a separate rule for each service and category that you want to monitor. To do so, you must edit the event pattern as per following example

Example Rule

The most Flexible AWS Savings Plan

2024-03-11T01:12:09+01:00

AWS provides several ways to reduce your cost but no other program is as flexible as the Compute Saving Plan. This article covers what you need to know to successfully and efficiently use the AWS savings program.

What are Savings Plans

Put plainly, all AWS cost-saving plans offer cost reductions compared to On-Demand prices, in exchange for a long-term commitment. That commitment is 1 or 3 years long and is an hourly spend commitment type.

AWS provides three types of Savings Plans:

Compute Savings Plans,
EC2 Instance Savings Plans, and
Amazon SageMaker Savings Plans.

The focus of this article is on the most flexible type of savings plan which is the Compute Savings Plan.

Research, Research, Research

The first step we need to take is to see if there are any Recommendations. This page might tell you what AWS recommends to purchase. Not everyone gets this kind of suggestion as they are based on your usage.

Follow the next example to understand how to purchase a Compute Savings Plan.

A Simple Example: Get a Discount on a Single t4g.micro EC2 Instance

This is a straightforward example. In this example, the commitment is for 1 year in Europe (Ireland), the eu-west-1 region.

A very important note is to know that discounts vary from Region to Region so do your research beforehand.

Step 1: Check Your Bill

Find your bill in the AWS console. You can see something like this.

AWS Bill screenshot made by the author.

We identified that we are paying On-Demand prices for a t4g.micro EC2 instance.

Step 2: Identify the Savings Rate in Your Region

Find out in which region your EC2 instance is hosted. After that access the table at Savings Plan Compute Pricing page. That page will show you a table like the one below.

AWS Savings Plan Compute Pricing Page screenshot made by the author.

The goal is to get a discount on the usage of a t4g.micro EC2 instance.

On-Demand rate — $0.0092 * 720 hours (hours in a 30-day month) = $6.624
Savings Plans rate — $0.0075 * 720 hours (hours in a 30-day month) = $5.62500
Savings over On-Demand — 18%

If you commit to a 3-year term the savings will be 42% instead of 18% for the Ireland Region.

Step 3: Purchase a Plan

So the purchase plan will look like this.

AWS Savings Plan Purchase screenshot made by the author.

AWS Savings Plan Cart screenshot made by the author.

Important notes:

Do not purchase large plans and over-commit.
Purchase small plans and then monitor the coverage.
If you need more coverage at a later period in time you can purchase additional savings plans.

The hourly commitment rate is the one after the discount — the Savings Plans Rate.

Reports Analysis

Utilization Report

Below you can see a sample utilization report for a single day after the savings plan has been purchased.

AWS Utilization report screenshot made by the author.

Coverage Reports

Under the “Billing and Cost Management / Savings Plan” menu, you can find the Coverage report. Here you can get information about how much of your spending has been covered by a savings plan during a certain period. You get information such as Average coverage, Potential monthly savings vs On-Demand, and On-Demand spend not covered.

Before Creating a Savings Plan

This is an example of a Coverage report showing no active Savings plan. It has yet to be activated.

AWS Coverage report screenshot made by the author.

After Creating a Savings Plan

This is an example of a Coverage report that shows an active Savings plan with a coverage of 43%

AWS Coverage report screenshot made by the author.

It is very difficult to get 100% coverage so start with 50% and iterate.

Do Your Research First

As described above Compute Savings Plan represents a flexible savings plan that supports multiple regions, and services and you commit to a dollar amount instead of an instance type or size. But there are dangers as if you calculate wrong then you are stuck paying that committed dollar amount.

If you purchase Savings Plans you commit to a certain dollar amount on a period and you can not cancel. Therefore be careful and do your research first before committing to any kind of Savings Plan.

Migrating EC2 to AWS Graviton (ARM): A Cost-Reduction Case Study

2024-02-11T05:59:43+01:00

The world of cloud computing is changing fast, that is a fact. Some changes have a more significant impact, as was the case with the rise of AWS Graviton processors.

The whole tech industry is experiencing the growing adoption of ARM architecture, so why should it not be the case with the Cloud as well?

This article focuses on the impact of AWS Graviton on the Cloud offering, the shift towards the ARM architecture, and how Clearview is helping clients jump on the Graviton train and save on costs up to 20%.

Key points on AWS Graviton

AWS Graviton processors are becoming popular because of their superior performance and energy efficiency in cloud environments which reduces your carbon footprint,
Adapting the ARM architecture requires data migration or possible code improvements before benefiting from the superior improvements in both cost and performance.

The Rise of AWS Graviton

Understanding AWS Graviton Processors

AWS Graviton processors are powered by ARM architecture, enabling performance and cost optimizations, which represent a significant advancement in cloud computing, compared to traditional x86 processors.

Graviton processors are optimized for Cloud workloads with the following benefits:

Large L1 and L2 caches for every virtual central processing unit (vCPU), meaning that most of your workload never burdens RAM,
Every virtual CPU is a physical core, meaning more isolation between virtual CPUs,
Cores are connected in a fast mesh with ~2TB/s of bisection bandwidth, which allows applications to move very quickly from core to core,
Graviton’s RAM architecture means you don’t need to worry about application memory allocation, or which cores are running the application.

Generations of AWS Graviton

Graviton processors come in various generations with each generation offering various advances in processing power and efficiency.

Graviton

The first generation ARM architecture-based, known as A1 type, Graviton-powered EC2 instances were launched in 2018. Not every region is still providing this first-generation instance type. Use the following awscli command to check if a region supports the A1 instance type.

aws ec2 describe-instance-type-offerings \
    --location-type "availability-zone" \
    --filters Name=location,Values=us-east-2a \
    --region us-east-2 \
    --query "InstanceTypeOfferings[*].[InstanceType]" \
    --output text \
    --profile default | sort | grep a1

This processor features:

64-bit ARM Neoverse cores,
The instances are up to 40% less expensive than the same number of vCPUs and DRAM available in other instance types.

Graviton 2

Launched in 2019 it represents the second generation of AWS Graviton processes. Graviton2-based instance types offer up to 40% better price performance than fifth-generation instances.

Graviton 2 Instance types

We now have 12 instance families (M6g, M6gd, C6g, C6gd, C6gn, R6g, R6gd, T4g, X2gd, Im4gn, Is4gen, and G5g) that are powered by AWS Graviton2 processors that provide significant price performance benefits for a wide range of workloads.

Graviton 3

Launched in 2022, it is the third and latest generation that is generally available. When compared to AWS Graviton2 processors it provides:

up to 25% better computing performance,
up to 2x better floating-point performance,
up to 2x faster crypto performance, and
up to 3x better ML performance,
support for bfloat16,
and features the latest DDR5 memory, which provides 50% more memory bandwidth compared to DDR4.
up to 60% less energy usage for the same performance than comparable EC2 instances.

Graviton 3 instance types

All 7th generation instance types containing “g” means it is based on AWS Graviton 3, the silicon designed by AWS. Examples:

C7g, C7gd, C7gn: the “C” instance family is designed for compute-intensive workloads,
M7g, M7gd: “G” instance family is designed for general-purpose workloads with balanced computing, memory, and networking,
R7g, R7gd: The “R” instance family is designed for memory-intensive workloads.

Graviton 4

Launched in late November 2023 Graviton 4 represents the fourth generation and it is still in preview only, with general availability planned in Q1 of 2024. When compared to Graviton3 processors it provides:

up to 30% better computing performance,
50% more cores,
75% more memory bandwidth.

Graviton4 will be available in memory-optimized Amazon EC2 R8g instances, which are currently in preview only. R8g instances offer larger instance sizes with up to 3x more vCPUs and 3x more memory than current generation R7g instances. To learn more about Graviton4-based R8g instances, visit this link.

Switch your AWS Services to Graviton

Here we will describe which services we have switched over to AWS Graviton.

Some services can be switched with a few clicks, while others require a full data migration following best practices.

AWS EC2

Following is a tutorial on how we switched EC2 instances. Please note that t4g is run on Graviton 2. Migrating our NodeJScode to be compatible with ARM architecture meant upgrading a few packages only.

Note: do not forget to set your awscli profile as in all of these examples the default one is used.

Find ARM LTS Ubuntu Images

For the latest LTS which is 22.04 LTS (Jammy Jellyfish), currently.

aws ec2 describe-images \
    --filters "Name=name,Values=ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-arm64-server-*" "Name=architecture,Values=arm64" \
    --query "sort_by(Images, &CreationDate)[].[Name, ImageId, Architecture]"  \
    --output text \
    --region us-east-1 \
    --profile=default

This command will show you the IDs of the images that support the ARM architecture. Choose one and set it at the next step.

Set AMI ID

As the AMI ID has been found in the previous command, we need to save it to a variable.

AMI_ID=ami-02ddaf75821f25213

List EC2 Key Pairs

The following commands will show keys that were added previously. If you get an empty result you need to add your public SSH key.

aws ec2 describe-key-pairs \
  --region us-east-1 \
  --profile=default

Find the Availability Zone

The zone is directly connected to the subnet.

aws ec2 describe-instance-type-offerings \
--location-type availability-zone \
    --filters Name=instance-type,Values=t4g.small \
    --region us-east-1 \
    --profile=default

Note: This step is very important as you need to find the what availability zone supports your instance size.

Find the Subnet and Security Group

We need to find the correct Subnet and SG.

List Security Groups

aws ec2 describe-security-groups \
    --query "SecurityGroups[*].{Name:GroupName,ID:GroupId}" \
    --region us-east-1 \
    --profile=default

List subnets

aws ec2 describe-subnets \
    --region us-east-1 \
    --profile=default

Note: Find the correct subnet that is used by your old EC2 instance.

Create the EC2 Instance

Please note that the following command is an example only and that you need to change the values for:

the key name,
the subnet ID,
the security group ID,
set your tags,
use your profile name.

aws ec2 run-instances --image-id $AMI_ID --instance-type t4g.small  \
    --key-name nedim \
    --subnet-id subnet-000000000000000 \
    --security-group-ids sg-00000000000000000 \
    --associate-public-ip-address \
    --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=ubuntu-test-graviton}]' \
    --region us-east-1 \
    --profile=default

Prepare the image

Connect to the VM, and run the system upgrade.

New Server Configuration with Ansible

Since we used Ansible to set up the old server the process of setting up an identically configured server was a piece of cake. All we had to do was change the hostname in the host inventory file add the new server and rerun the playbooks.

Volume size

Make sure the new disk volume is identical to the size of the old server’s disk volume as we will copy over data from the old server to the new one.

Data Migration

Using RSYNC, copy over the data from the old server to the new Graviton-based one, using the SSH protocol.

rsync -avz -e ssh /var/www/ root@enew-server.compute-1.amazonaws.com:/var/www/

Note: This data migration does not guarantee that the code will work 100%, you will need to deploy and build the code again to be sure it works as expected. In our case, we needed to upgrade several NodeJS packages.

AWS RDS

With RDS instances no migration is necessary and you can take the easy way of just modifying the instance class of your instances if your database engine version supports it.

Determine if the current database version meets the minimum required version for moving to Graviton2.

Version supporting Graviton:

MySQL: 8.0.17 and higher,
PostgreSQL: 12.3, 13 and higher,
MariaDB: 10.4.13, 10.5 and higher.

If your RDS instance isn’t at a version supported by Graviton2, you need to upgrade to a supported version.

AWS ElastiCache for Redis

Migrating Amazon Elasticache for Redis and Memcached to Graviton2-based instances offers a smooth transition, only a change of instance type is required, with a performance improvement of up to 45%, all at a 20% lower cost compared to similar x86-based instances.

The Beginning of a New Age in Cloud Computing

In conclusion, the rise of AWS Graviton and ARM architecture represents a change in cloud computing that impacts the whole IT industry. These technologies bring together improved performance, cost-effectiveness, and energy efficiency. As more organizations adopt these technologies, we can expect a future where the flexibility of ARM architecture and the efficiency of Graviton processors set the standard for cloud infrastructure.

Therefore, do not miss the chance to make the switch and be part of the new standard.

Deploying Node Containers on AWS App Runner with Terraform

2024-01-11T07:01:42+01:00

The Smart Way to Deploy Containers on The Cloud

Say hello to AWS AppRunner

Containers on AWS AppRunner

Why AppRunner?

It is easy to deploy and manage

If you tried to deploy containers on the cloud you have experienced anything but an easy process. It has been easy to deploy containers on your local machine but deploying them on the Cloud has not been an easy process.

That was true until AWS AppRunner was introduced back in 2021.

It is a great solution for startups

Here at Clearview, we have found that AppRunner can be of very benefit to startup projects as it is cost-effective because of its on-demand pricing model and it is a fully managed service.

This will result in less time spent on setting up the infrastructure which saves us time and money.

It has an attractive pricing model

What is great about AppRunner is that when the container is in an idle state you only pay for the memory provisioned in each container instance. When a container is in the idle state it is considered to be a Provisioned container instance. Once the container starts to use CPU resources, it will be considered an Active container instance and you will be charged for the CPU resources used.

As you can pause and resume the service you can as well additionally save on costs.

In summary

Provisioned container instances — charged for memory ($0.007 / GB-hour),
Active container instances — charged for both memory and CPU resources used ($0.064 / vCPU-hour, $0.007 / GB-hour),
Paused instances— CPU and memory are not charged.

What can AppRunner do?

Since AWS App Runner is a fully managed service it will

automatically deploy web applications by detecting a new container image that has been pushed to the container registry,
automatically scale and load balance to meet the traffic needs.

Automatic deployment, scaling, and load balancing make it a desirable technology.

Easily Managed by Terraform

By adding Terraform to the mix we can provision this technology even faster. Later in this article, we will provide examples of code on how to set up AppRunner with Terraform.

History

Back when it was introduced it was still an early tech and still not developed and mature but in the last two years, it has grown significantly. Here are some improvements that we have witnessed while using the tech:

Added support for more regions across the world,
Reduced duration for deploying applications using container images, which is about a 30–40% reduction in deployment time depending on the container image size,
Increased instance startup time from one to a maximum of five minutes which enables slower instances that need more time of startup to be used,
Added dual stack support for incoming traffic through public endpoints, both IPv4 and IPv6 endpoints, simultaneously,
Reduced the time taken for image-based service deployment, Added support for immediate deployment failure if App Runner couldn’t pull an image.

Provisioning AppRunner with Terraform

In this demonstration, we will provision AWS services with Terraform as follows:

ECR for hosting container images,
NodeJS API service on AppRunner,
NuxtJS FrontEnd service on AppRunner.

Local variables are defined at the top of the .tf file to be straightforward about what values should be changed depending on the project.

Diagram

In the diagram, it is clear that the publicly exposed service is the FrontEnd service, which then connects to the API service. To point and connect one service to the other environment variables are used.

Provision ECR

This is an example of how to provision the ECR for API.

aws_apprunner_service_with_terraform/ecr.tf at e4c96bc5e856753515c2c640e853f0deeef5e71f · clearview/aws_apprunner_service_with_terraform

# my_api
resource "aws_ecr_repository" "my_ecr_api" {
  name                 = "my_ecr/my_api"
  image_tag_mutability = "MUTABLE"
  image_scanning_configuration {
    scan_on_push = true
  }
}

resource "aws_ecr_lifecycle_policy" "my_ecr_api" {
  repository = aws_ecr_repository.my_ecr_api.name

  policy = jsonencode({
    rules = [{
      rulePriority = 1
      description  = "keep last 10 images"
      action = {
        type = "expire"
      }
      selection = {
        tagStatus   = "any"
        countType   = "imageCountMoreThan"
        countNumber = 10
      }
    }]
  })
}

output "my_ecr_api_registry_id" {
  value       = aws_ecr_repository.my_ecr_api.registry_id
  description = ""
}
output "my_ecr_api_repository_url" {
  value       = aws_ecr_repository.my_ecr_api.repository_url
  description = ""
}

Provision of the API Service

In this example, the health check is performed against a custom endpoint available on the/api/healtcheck URN, but that might be different in your case.

To be safe and if you do not have a health check endpoint yet just use / .

This instance is provisioned with the following configuration:

1024 CPU units,
2048 MB of memory,
The health check endpoint is located at /api/healthcheck ,
Container port running on 3000 .

aws_apprunner_service_with_terraform/api_service.tf at e4c96bc5e856753515c2c640e853f0deeef5e71f · clearview/aws_apprunner_service_with_terraform

locals {
  api_port                   = 3000
  api_domain                 = "api.mydomain.team"
  api_git_repo               = "my/my_api"
  api_development_git_branch = "dev"
  api_ecr_image_development  = "${aws_ecr_repository.my_api_ecr.repository_url}:dev"
}
resource "aws_apprunner_service" "my_api" {

  depends_on = [
    aws_ecr_repository.my_api_ecr,
    aws_iam_role.my_app_runner_roles,
    aws_apprunner_vpc_connector.my_vpc_connector
  ]

  service_name = "my_api"

  source_configuration {
    authentication_configuration {
      access_role_arn = aws_iam_role.my_app_runner_roles.arn
    }

    image_repository {
      image_identifier      = local.api_ecr_image_development
      image_repository_type = "ECR"
      image_configuration {
        port = 3000
        runtime_environment_variables = {
          # Server Port
          PORT = "3000"
          #
          NODE_ENV       = "development"
          LOG_LEVEL      = "debug"
          PORT           = local.api_port
          CONTAINER_PORT = local.api_port
          HOST_PORT      = local.api_port
        }
        runtime_environment_secrets = {
        }
      }
    }
    auto_deployments_enabled = true
  }

  health_check_configuration {
    path                = "/api/healthcheck"
    healthy_threshold   = 1
    interval            = 5
    protocol            = "HTTP"
    timeout             = 20
    unhealthy_threshold = 20
  }

  instance_configuration {
    cpu    = "2048"
    memory = "4096"
  }

  network_configuration {
    egress_configuration {
      egress_type       = "VPC"
      vpc_connector_arn = aws_apprunner_vpc_connector.my_vpc_connector.arn
    }
  }

  tags = {
    Name = "my-my_api-apprunner-service"
  }
}

output "my_api_apprunner_my_api_service_url" {
  value       = aws_apprunner_service.my_api.service_url
  description = ""
}

Provision of the FrontEnd service

This instance is provisioned with the following configuration:

1024 CPU units,
2048 MB of memory,
The health check endpoint is located at /ping .

aws_apprunner_service_with_terraform/fe_service.tf at e4c96bc5e856753515c2c640e853f0deeef5e71f · clearview/aws_apprunner_service_with_terraform

locals {
  my_fe_port                   = 3001
  my_fe_domain                 = "frontend.my-domain.org"
  my_fe_apprunner_domain       = "members.development.my-domain.org"
  my_fe_ecr_image_development  = "${aws_ecr_repository.my_fe_ecr.repository_url}:dev"
  my_fe_git_repo               = "clearview/my-members-fe"
  my_fe_development_git_branch = "dev"
}

resource "aws_apprunner_service" "my_fe" {
  depends_on = [
    aws_ecr_repository.my_fe_ecr
  ]

  service_name = "my_fe"

  source_configuration {
    authentication_configuration {
      access_role_arn = aws_iam_role.my_app_runner_roles.arn
    }

    image_repository {
      image_identifier      = local.my_fe_ecr_image_development
      image_repository_type = "ECR"
      image_configuration {
        port          = local.my_fe_port
        start_command = "yarn dev"
        runtime_environment_variables = {
          HOST           = "0.0.0.0"
          HOSTNAME       = "0.0.0.0"
          NITRO_HOST     = "0.0.0.0"
          ENV            = "development"
          NODE_ENV       = "development"
          PORT           = local.my_fe_port
          NITRO_PORT     = local.my_fe_port
          CONTAINER_PORT = local.my_fe_port
          HOST_PORT      = local.my_fe_port
          # API
          PROXY_TARGET      = "https://${local.api_domain}"
          NUXT_API_BASE_URL = "https://${local.api_domain}"
          # Nuxt
          NUXT_PUBLIC_DEV      = true
          NUXT_PUBLIC_DEBUG    = true
          NUXT_PUBLIC_SITE_URL = "http://localhost:${local.my_fe_port}"
          NUXT_PORT            = local.my_fe_port
          NUXT_HOST            = "0.0.0.0"
          # Debug
          LOG_LEVEL = "debug"
        }
      }
    }
    auto_deployments_enabled = true
  }

  health_check_configuration {
    path                = "/ping"
    healthy_threshold   = 1
    interval            = 20
    protocol            = "HTTP"
    timeout             = 19
    unhealthy_threshold = 20
  }

  instance_configuration {
    cpu    = "1024"
    memory = "2048"
  }

  network_configuration {
    egress_configuration {
      egress_type       = "VPC"
      vpc_connector_arn = aws_apprunner_vpc_connector.my_vpc_connector.arn
    }

    ingress_configuration {
      is_publicly_accessible = true
    }

  }

  tags = {
    Name = "my-my_fe-apprunner-service"
  }
}

output "my_fe_apprunner_my_fe_service_url" {
  value       = aws_apprunner_service.my_fe.service_url
  description = ""
}

Conclusion

In this article, we covered AppRunner from its humble beginnings to the powerful technology it has proven to be today. We provided useful diagrams and Terraform code for easy provisioning of service.

If you have any questions please do not hesitate to contact our team.

AWS Budgets and Alerts with Terraform: A Cost-Monitoring Case Study

2024-01-03T13:47:03+01:00

Monitor and Control Amazon Cloud Costs with Terraform

For every Cloud project, you need to set budgets and alerts with Terraform

AWS Budgets with Terraform

Why set up a budget for your cloud account?

If you wonder why most startups fail it is simple, they run out of money and there have been many horror stories about crazy big cloud bills.

At Clearview, when we put a new client on the Cloud, we know they will get a bill eventually. It’s our responsibility to make sure that the bill will not be a big and sudden surprise.

Setting up the budgets

Setting the AWS Cloud budget

The first step is to set budgets and alerts. We usually set:

The Account wide budget,
The Most used service budget,
The Most important tag budget.

Every budget sends out an email notification when the budget cost threshold is reached, in these two cases:

The ACTUAL cost which will be triggered once that amount has already been spent,
The FORECASTED cost notification will be triggered earlier as the cost is based on prediction based on your past usage.

As we are a tech company the budgets are set using Terraform and in the next section, you can find diagrams and code samples that explain how budgets and notifications work.

Monthly Account Budget

Set your Monthly AWS Budget.

This budget tracks account-wide costs.

resource "aws_budgets_budget" "monthly_account_budget" {
  name         = "Monthly Budget for my Account"
  budget_type  = "COST"
  limit_amount = "500"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 90
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["email@my.team"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 100
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["email@my.team"]
  }
}

aws_budgets_notifications_with_terraform/monthly_account_budget.tf at 0b8af27933b32c27c7b09c4b633724ed17fe82b9 · clearview/aws_budgets_notifications_with_terraform

The notification block arguments

Each notification block inside aws_budgets_budget controls one alert. The five arguments the AWS provider expects are:

comparison_operator — one of GREATER_THAN, LESS_THAN, or EQUAL_TO. For a spend budget you almost always use GREATER_THAN.
threshold — a number. Compared against the budgeted amount.
threshold_type — PERCENTAGE or ABSOLUTE_VALUE. Percentage is easier to reason about because you don't have to rewrite the block when the budget limit changes.
notification_type — ACTUAL (the current spend) or FORECASTED (AWS's prediction based on past usage). Set one of each per budget so you get both an early warning and a real breach alert.
subscriber_email_addresses — a list of email strings. This is where the alert lands. Every address in the list receives a copy. Note: it is a Terraform list, not a comma-separated string, so use ["a@x", "b@x"] shape not "a@x, b@x".

There are two adjacent arguments that this example does not use but you might reach for:

subscriber_sns_topic_arns — send the notification to an SNS topic instead of (or in addition to) email. Useful when you want the alert to fan out into Slack via an SNS→Lambda hop.
subscriber_type on the older notification shape has been replaced by the three subscriber_* list arguments; you should not need it on modern provider versions (hashicorp/aws >= 4.0).

Full provider docs: aws_budgets_budget#notification.

Budgets by Service

AWS Budgets illustration.

EC2 Monthly Budget

This budget will track costs for EC2 services only.

resource "aws_budgets_budget" "ec2_monthly_budget" {
  name         = "My EC2 Monthly Budget"
  budget_type  = "COST"
  limit_amount = "400"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name = "Service"
    values = [
      "Amazon Elastic Compute Cloud - Compute",
    ]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 90
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["email@my.team"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 100
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["email@my.team"]
  }
}

aws_budgets_notifications_with_terraform/ec2_monthly_account_budget.tf at 0b8af27933b32c27c7b09c4b633724ed17fe82b9 · clearview/aws_budgets_notifications_with_terraform

S3 Monthly Budget

AWS S3 Monthly Budget.

This budget will track costs for S3 buckets only.

resource "aws_budgets_budget" "s3_monthly_budget" {
  name         = "My S3 Monthly Budget"
  budget_type  = "COST"
  limit_amount = "100"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name = "Service"
    values = [
      "Amazon Simple Storage Service",
    ]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 90
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["email@my.team"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 110
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["email@my.team"]
  }
}

aws_budgets_notifications_with_terraform/s3_monthly_account_budget.tf at 0b8af27933b32c27c7b09c4b633724ed17fe82b9 · clearview/aws_budgets_notifications_with_terraform

AppRunner Monthly Budget

This budget will track costs for AppRunner services only.

resource "aws_budgets_budget" "apprunner_monthly_budget" {
  name         = "My AppRunner Monthly Budget"
  budget_type  = "COST"
  limit_amount = "100"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name = "Service"
    values = [
      "AWS App Runner",
    ]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 90
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["email@my.team"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 110
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["email@my.team"]
  }
}

aws_budgets_notifications_with_terraform/apprunner_monthly_account_budget.tf at 0b8af27933b32c27c7b09c4b633724ed17fe82b9 · clearview/aws_budgets_notifications_with_terraform

Budgets based on tag filtering

Production Tag Monthly Budget

This budget will group multiple types of service based on the tag, in this case, the production tag is used.

production_tag_monthly_budget.tf on GitHub

Closing

This article explained the importance of setting a cloud budget and then demonstrated how to do it programmatically. Not only that, we went a step further and created nice diagrams for each budget so that it is easier for every reader to imagine the setup.

We hope this article finds its way and helps you avoid unnecessary cloud costs.

AWS DevOps Case Studies: Terraform, App Runner, WAF · Remote Since Forever

How a CloudFront Custom Error Page Leaked JWTs to S3: A Case Study

The One-Line Proof

Why did CloudFront forward the Authorization header to S3?

Three ways the token leaks

The Terraform Template Problem

The Chain That Made It Critical

We proved the full chain end-to-end

The public bucket

The Fix

What we shipped

How to Check If You're Vulnerable

Check every distribution

An Event-Driven Architecture Case Study: Lessons from a Real-World Application

The Client

The Digital Workflow Platform

The Project

Challenges

Deployment

Goals

System Architecture

Event-driven Architecture

Event-driven Architecture Showcase

The Application

Event Producers

API Event Producer

API Events List

API Produced Sample Events

Scheduler Event Producer

Evaluated Jobs

Company Statistic Scheduled Job

Event Rule

The Infrastructure

AWS RDS

The EventBridge Rule

AWS Health

EC2 service

Sample rules

Multiple Services and Event Type Categories

Example Rule

The most Flexible AWS Savings Plan

What are Savings Plans

Research, Research, Research

Follow the next example to understand how to purchase a Compute Savings Plan.

A Simple Example: Get a Discount on a Single t4g.micro EC2 Instance

Step 1: Check Your Bill

Step 2: Identify the Savings Rate in Your Region

Step 3: Purchase a Plan

Reports Analysis

Utilization Report

Coverage Reports

Before Creating a Savings Plan

After Creating a Savings Plan

Do Your Research First

Migrating EC2 to AWS Graviton (ARM): A Cost-Reduction Case Study

Key points on AWS Graviton

The Rise of AWS Graviton

Understanding AWS Graviton Processors

Generations of AWS Graviton

Graviton

Graviton 2

Graviton 2 Instance types

Graviton 3

Graviton 3 instance types

Graviton 4

Switch your AWS Services to Graviton

AWS EC2

Find ARM LTS Ubuntu Images

Set AMI ID

List EC2 Key Pairs

Find the Availability Zone

Find the Subnet and Security Group

List Security Groups

List subnets

Create the EC2 Instance

Prepare the image

New Server Configuration with Ansible

Volume size

Data Migration

AWS RDS

Why did CloudFront forward the `Authorization` header to S3?