DEV Community: Jorel Fermin

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.