DEV Community: Jorel Fermin

One panic shouldn't kill the scan: isolating rules with catch_unwind

Jorel Fermin — Tue, 20 Oct 2026 20:48:07 +0000

Cloud Cost Analyzer runs 92 rules against your cloud account in a single scan. A rule is a real unit of work: it pulls a resource's config and metrics, evaluates them against a cost model, and maybe emits a finding. They're independent, and every one of them leans on libraries I don't control: cloud SDKs, response parsers, date and math crates.

Any of that can meet an input it didn't anticipate and panic: an unwrap() that couldn't fail until some resource shape I'd never seen, an index out of bounds deep in a dependency, an overflow on a field that's normally small. Usually nobody wrote bad code. A library just hit an edge case nobody dependency-audited for.

The question isn't whether a rule will panic. It's what happens to the other 91 when rule

57 does. A cost report that dies two-thirds of the way through because one rule met one weird EBS volume isn't much use to anyone.

"So handle it with `Result`"

The obvious objection: this is Rust, so model the failure as a Result and there's nothing to catch. The rules do exactly that for every failure they can see coming. Can't reach the metrics API? Result. Missing a field the check needs? Result. Expected failures travel the normal error path and always have.

A panic is the failure I didn't foresee. You can't write ? for a bug you don't know exists, and you certainly can't for one buried three crates deep in a dependency that panics on input its author never tested. Result handles the errors you anticipated. catch_unwind covers the ones you couldn't, and it only exists in my code because Result can't reach into code I didn't write.

std::panic::catch_unwind runs a closure and hands you back a Result instead of letting the panic tear through your stack. Here's the real dispatch, one rule at a time:

let mut eval = std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
    rule.evaluate(resource, metrics, costs)
}))
.unwrap_or_else(|_| {
    tracing::error!(
        rule_id = rule_id,
        resource_id = %resource.resource_id,
        "rule panicked during evaluate; skipping its finding"
    );
    None
})?;

A rule panics, we log which rule and which resource, return None for that one finding, and the loop moves on to the next rule. One panic costs one finding.

What `AssertUnwindSafe` actually promises

The compiler demands that wrapper, and it's worth understanding why before reaching for it.

catch_unwind only accepts a closure that's UnwindSafe. The idea: if a panic unwinds through the middle of your closure, any state it shared with the outside could be left half-updated, and UnwindSafe is the marker that says there's no such state to observe. My closure captures &rule, &resource, and friends by reference, so the compiler can't prove that on its own and refuses to compile.

AssertUnwindSafe is me telling the compiler I've checked, and that catching this panic won't let anyone observe a broken invariant. That holds here for a concrete reason: on panic I throw the result away. I return None and never read a partially-built finding. There's no torn state to see because I don't look. That's the bar for reaching for AssertUnwindSafe. You should be able to point at why the post-panic state is unobservable.

The setting that silently turns all of this off

catch_unwind only works if panics unwind, which is why it isn't a try/catch. Rust has two panic strategies, and you choose per build:

# Cargo.toml — a size-optimized profile
# Inherits all release settings, adds panic=abort to remove unwind tables
panic = "abort"

Under panic = "abort", a panic doesn't unwind the stack. It calls the abort handler and kills the process immediately, so catch_unwind never gets a chance to run. Every one of those careful per-rule guards becomes a no-op, and rule #57 takes the whole process down with it. That happens in the exact build you ship to production, because panic = "abort" is something you turn on to drop unwind tables and shrink the binary.

So panic isolation is a whole-binary decision rather than a library feature you add. If you want one bad rule to cost one finding, you have to keep the unwinding runtime, and eat the binary size, on purpose. No assert or catch_unwind call can buy that back for you. It's the trade you make once, in the profile, and it's invisible in the code that depends on it.

One more edge: poisoned locks

If a rule panics while holding a Mutex or RwLock, that lock is poisoned and the next rule to touch it inherits the panic. The isolation above holds partly because the shared data these rules read is immutable and lock-free, so there's no lock to poison. If yours mutates shared state under a lock, catching the panic isn't enough. You have to decide what a poisoned lock means.

Where it landed

Rules and the second-stage analyzers both run inside that catch_unwind, under an unwinding profile. When a rule, or a library it leans on, meets an input nobody anticipated, the cost is one missing finding and a log line naming the culprit. The isolation works because the binary is built to allow it, and I can say exactly why the post-panic state is safe to ignore: I never read it.

This is part of a series on building Cloud Cost Analyzer in Rust.

Social cards in pure Rust: no headless Chrome

Jorel Fermin — Thu, 10 Sep 2026 21:26:54 +0000

Cloud Cost Analyzer (CCA) lets you share a read-only scan as a link. Someone drops that link in Slack or on LinkedIn, and instead of a bare URL I wanted it to unfurl into a proper card: the brand mark, the monthly savings we found, the number of findings.

That was two separate problems. Figuring them out took me somewhere I didn't expect, because neither one wanted a headless browser, but both needed a card. One of them even ate an afternoon because the fonts wouldn't cooperate. Here's the whole thing.

The dashboard is a single-page app, rendered entirely in the browser (ssr: false). That's fine for humans. It's not fine for the crawlers Slack, LinkedIn, and X send at your link, because those don't run JavaScript. They fetch the HTML, find an empty shell with no og: meta tags, and give up. You get the bare URL in the Slack thread.

So the crawler gets served something different. A CloudFront function reads the User-Agent on the viewer request: known bots get 302'd to a small server-rendered /embed page that carries the Open Graph tags and a meta refresh back to the real app. Humans get the SPA untouched. The crawler reads a fully-formed page with og:title, og:image, and friends; a human clicking the same link lands on the interactive dashboard.

This is user-agent-based dynamic rendering for social crawlers, not SEO cloaking. The /embed page carries the same title and numbers a human would see, and it meta refreshes straight to the real app, so nobody is handed content that contradicts what the link actually shows.

That's the easy half, structurally. Now comes the picture, which is where I had a choice to make.

The default path for "turn some text on a branded background into a PNG" is to render HTML in headless Chrome and screenshot it. It works. It also means shipping a browser alongside your service, keeping it patched, and paying its cold-start and memory cost on a code path that exists only to make links look nice. In a Rust backend that's a lot of weight to carry for a nice Slack unfurl.

I built the card as an SVG string and rasterized it in-process with resvg and tiny-skia, both pure Rust. The whole renderer is about ten lines:

static FONTDB: LazyLock<Arc<usvg::fontdb::Database>> = LazyLock::new(|| {
    let mut db = usvg::fontdb::Database::new();
    db.load_font_data(SG_700.to_vec());   // include_bytes! at compile time
    db.load_font_data(SG_500.to_vec());
    db.load_font_data(INTER_600.to_vec());
    Arc::new(db)
});

fn render_png(svg: &str) -> Result<Vec<u8>, ServiceError> {
    let opt = usvg::Options { fontdb: FONTDB.clone(), ..Default::default() };
    let tree = usvg::Tree::from_str(svg, &opt)?;
    let mut pixmap = tiny_skia::Pixmap::new(CARD_W, CARD_H).ok_or(ServiceError::Render)?;
    resvg::render(&tree, tiny_skia::Transform::identity(), &mut pixmap.as_mut());
    Ok(pixmap.encode_png()?)
}

A few things in there I'd do again:

The fonts are compiled into the binary with include_bytes!. No font files to ship, no system-font lookup that can differ between my laptop and the container. The binary just renders the same card everywhere, full stop.
LazyLock<Arc<Database>> parses the font data once per process. Each render clones the Arc (cheap) into its own usvg::Options, so building a card is string formatting plus a rasterize. That's the whole cost model.
The layout is single-column, left-aligned, on purpose. resvg doesn't expose a text-measurement API - you can't ask it how wide a string is before drawing it. Any centered element would need that. Committing to a left-aligned column means I never have to measure anything at all; the SVG is static positions with the numbers interpolated in.

The handler builds the SVG, calls render_png, and returns it with a one-hour Cache-Control. There's a CCA_OG_SAMPLE env var that dumps a real card to disk so I can eyeball it, and the test just asserts the output starts with the PNG magic bytes and has the right dimensions. That's deliberately not much - I'm not going to pixel-diff a card, but I do want to hear about the day the renderer stops producing a valid PNG.

Then I spent an afternoon wondering why everything was in the wrong font.

The cards looked structurally fine - right size, right colors, text in the right places - but the typeface was not what I wanted. Headings were supposed to be Space Grotesk. They were coming out in resvg's fallback face. Getting the font-family string "more correct" did not help, which took me a while to be okay with.

The SVG references the font the normal way:

<text font-family="Space Grotesk" font-weight="700" ...>
<text font-family="Space Grotesk" font-weight="500" ...>

The actual problem was upstream, in the font files themselves, which I only found when I finally opened one. I'd grabbed static TTFs from Fontsource, which ships each weight as a separate file - and, the part that got me, each file declares its own family name in the OpenType name table. The 700 file is not "Space Grotesk, weight 700." Depending on the face it calls itself "Space Grotesk" for one weight and "Space Grotesk Medium"/"Space Grotesk Light" for others. The filenames and the internal family names don't necessarily agree.

resvg (via usvg) matches fonts the CSS way: find a family named exactly "Space Grotesk," then pick the closest weight within that family. When the only family that literally exists in the database is "Space Grotesk Light," a request for font-family="Space Grotesk" matches nothing and silently falls back. No error, no warning - just the wrong font, which looked close enough that I kept debugging the SVG instead of the font.

The fix was normalizing the name table so both faces report the same family and distinguish themselves by weight class instead. A few lines of fonttools does it:

from fontTools.ttLib import TTFont
f = TTFont("space-grotesk-700.ttf")
for rec in f["name"].names:
    if rec.nameID in (1, 16):        # family name
        rec.string = "Space Grotesk"
f["OS/2"].usWeightClass = 700        # keep the weight distinct
f.save("space-grotesk-700.ttf")

Now both faces belong to one "Space Grotesk" family with usWeightClass 500 and 700, and font-family="Space Grotesk" font-weight="700" resolves to exactly the face I meant.

One licensing note, since editing a font's name table can be a violation in some situations: the SIL Open Font License lets you modify and rename fonts freely unless the font declares a Reserved Font Name, in which case you're not allowed to keep that name on a modified copy. I checked - the faces I was using don't reserve one - so collapsing them to a single "Space Grotesk" family is fine. If yours does reserve a name, rename to something new instead. It's thirty seconds to confirm before you ship a modified .ttf, and I'd rather not find out the hard way.

Where it landed: a service that turns a shared scan into a branded PNG in-process, fonts baked into the binary, no browser anywhere in the pipeline. Share a scan link and it unfurls with a card showing the monthly savings and the finding count, generated the same way in every environment because there's nothing external left to disagree with itself.

If you're reaching for headless Chrome only to rasterize some text on a background, resvg plus tiny-skia is worth an hour of your time before you commit to it. And check your font's name table before you spend an afternoon wondering why "Space Grotesk" isn't Space Grotesk.

This is part of a series on building Cloud Cost Analyzer in Rust.

Idle load balancers: the ~$16/month each you forgot to delete"

Jorel Fermin — Wed, 19 Aug 2026 18:35:59 +0000

Short version: An Application or Network Load Balancer costs ~$0.0225/hour, about $16/month, just to exist, plus capacity units. Classic Load Balancers run ~$18/month. Load balancers outlive the services behind them: the app gets torn down, the ALB keeps billing. Here's how to find load balancers with no real traffic or no healthy targets, and remove them safely.

Why idle load balancers linger

The hourly base charge is fixed - an ALB with zero requests bills the same ~$16/month as a busy one. Load balancers are usually created early (with an app or an IaC module) and deleted last, if ever. A handful of abandoned ALBs from old environments is real, recurring money.

Step 1 - List load balancers and their traffic

aws elbv2 describe-load-balancers \
  --query 'LoadBalancers[].{Name:LoadBalancerName,Type:Type,ARN:LoadBalancerArn}' \
  --output table

For an ALB, check request volume over the last 7 days (the metric dimension is the tail of the ARN, e.g. app/my-alb/50dc6c495c0c9188):

aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name RequestCount \
  --dimensions Name=LoadBalancer,Value=app/my-alb/50dc6c495c0c9188 \
  --start-time "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Sum \
  --query 'Datapoints[].Sum'

Near-zero request counts over a week is a strong idle signal. (For NLBs, use the AWS/NetworkELB namespace and ActiveFlowCount.)

Step 2 - Check for empty or unhealthy target groups

A load balancer with no healthy targets is doing nothing useful:

for tg in $(aws elbv2 describe-target-groups \
  --load-balancer-arn <lb-arn> \
  --query 'TargetGroups[].TargetGroupArn' --output text); do
  echo "== $tg =="
  aws elbv2 describe-target-health --target-group-arn "$tg" \
    --query 'TargetHealthDescriptions[].TargetHealth.State' --output text
done

Empty output (no targets) or all unhealthy alongside near-zero requests is a confident "delete me."

Step 3 - Delete safely

aws elbv2 delete-load-balancer --load-balancer-arn <lb-arn>

Caveat: a load balancer with no requests isn't always dead - it might be a disaster-recovery endpoint, a rarely-hit admin panel, or the target of a DNS record something depends on. Before deleting, check Route 53 (and any external DNS) for records pointing at the load balancer's DNS name, and confirm nothing references it:

aws elbv2 describe-load-balancers --load-balancer-arn <lb-arn> \
  --query 'LoadBalancers[].DNSName' --output text

Then grep your DNS zones for that name. No references + no traffic + no healthy targets = safe to remove.

Doing it across every account, automatically

Pulling CloudWatch for every load balancer by hand doesn't scale. It's one of the checks in a read-only CLI I built, Cloud Cost Analyzer - its idle-load-balancer rule flags load balancers serving fewer than 100 requests/day over a 7-day window, alongside 89 other AWS cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

It runs in your environment with read-only access, so your AWS credentials never leave it. Free tier if you want to try it on one account, and dashboards if you want to review or share reports.

Originally published on the Dragon Fractal Cloud Cost Analyzer blog.

Migrate EBS gp2 volumes to gp3 and cut storage cost by about 20%

Jorel Fermin — Wed, 19 Aug 2026 17:27:10 +0000

Short version: AWS gp3 EBS volumes cost about ~20% less per GB than gp2 ($0.08 vs $0.10 per GB-month in us-east-1) and includes 3,000 IOPS and 125 MB/s of baseline performance for free. You can convert a volume from gp2 to gp3 online, with no downtime and no snapshot with a single modify-volume call. For most volumes, it's a real savings. Here's how to find those volumes, migrate them, and the one caveat to keep in mind.

Why gp3 is cheaper (and usually faster)

gp2 pricing couples performance to its size: you get 3 IOPS per GB, so the only way to get more IOPS on gp2 is to over-provision storage you don't need. gp3 removes that coupling:

	gp2	gp3
Storage	$0.10 / GB-month	$0.08 / GB-month (-20%)
Baseline IOPS	3 IOPS/GB (burst to 3,000)	3,000 included at any size
Baseline throughput	scales with size	125 MB/s included
Extra IOPS / throughput	not possible	provision independently

(Prices are us-east-1 list; the ratio holds across regions.)

For a 500 GB volume, that's $50/month to $40/month, i.e., $120/year saved, per volume, with equal or better performance. Now multiply this by every gp2 volume in every account.

Step 1 - Find your gp2 volumes

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[].{ID:VolumeId,GiB:Size,AZ:AvailabilityZone,State:State}' \
  --output table

Run it per region. EBS is regional, so a volume only shows up in its own region:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "== $region =="
  aws ec2 describe-volumes --region "$region" \
    --filters Name=volume-type,Values=gp2 \
    --query 'Volumes[].{ID:VolumeId,GiB:Size}' --output text
done

Step 2 - Migrate (online, no downtime)

Converting the type is a live modify-volume. The volume stays attached and readable/writable the whole time; it briefly enters an optimizing state:

aws ec2 modify-volume --volume-id vol-0abc123def456 --volume-type gp3

To convert everything in a region at once:

for vol in $(aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[].VolumeId' --output text); do
  echo "migrating $vol"
  aws ec2 modify-volume --volume-id "$vol" --volume-type gp3
done

No snapshot, no detach, no reboot. (AWS allows one modification per volume per 6 hours, so migrate and then wait before modifying the same volume.)

The one caveat: high-IOPS / high-throughput volumes

Because gp2 IOPS scale with size, a large gp2 volume may already deliver more than gp3's 3,000 baseline IOPS. A 2 TB gp2 volume provides 6,000 IOPS; if your workload actually uses them, migrate and provision matching performance on gp3:

aws ec2 modify-volume --volume-id vol-0abc123def456 \
  --volume-type gp3 --iops 6000 --throughput 250

The first 3,000 IOPS and 125 MB/s are free; beyond that, extra IOPS are $0.005/provisioned-IOPS-month and extra throughput $0.040/MB/s-month. Even fully matched, gp3 is usually still cheaper than the equivalent gp2, but check CloudWatch VolumeReadOps/VolumeWriteOps before assuming you need the headroom. Volumes under ~1 TB with normal workloads are a straight 20% win.

Doing it across every account, automatically

Finding gp2 volumes and estimating the savings across every account and region by hand doesn't scale. It's one of the checks in a read-only CLI I built, Cloud Cost Analyzer. It flags every gp2 volume with the estimated monthly savings, alongside 89 other AWS cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

It runs in your environment with read-only access, so your AWS credentials never leave it. Free tier if you want to try it on one account, and dashboards if you want to review or share reports.

Originally published on the Dragon Fractal Cloud Cost Analyzer blog.

DEV Community: Jorel Fermin

One panic shouldn't kill the scan: isolating rules with catch_unwind

57 does. A cost report that dies two-thirds of the way through because one rule met one weird EBS volume isn't much use to anyone.

"So handle it with Result"

What AssertUnwindSafe actually promises

The setting that silently turns all of this off

One more edge: poisoned locks

Where it landed

Social cards in pure Rust: no headless Chrome

Idle load balancers: the ~$16/month each you forgot to delete"

Why idle load balancers linger

Step 1 - List load balancers and their traffic

Step 2 - Check for empty or unhealthy target groups

Step 3 - Delete safely

Doing it across every account, automatically

Migrate EBS gp2 volumes to gp3 and cut storage cost by about 20%

Why gp3 is cheaper (and usually faster)

Step 1 - Find your gp2 volumes

Step 2 - Migrate (online, no downtime)

The one caveat: high-IOPS / high-throughput volumes

Doing it across every account, automatically

"So handle it with `Result`"

What `AssertUnwindSafe` actually promises