DEV Community: Ryan Bell

Cloud cost sprawl and how to rein it in

Ryan Bell — Mon, 15 Jun 2026 11:30:53 +0000

Cloud spending has a way of growing quietly until a finance review turns up a bill nobody can fully explain. The cloud's great strength, the ability to spin up resources in seconds, is also how the waste accumulates: every easy launch is an easy thing to forget. This sprawl is rarely the result of one bad decision. It is the sum of hundreds of small, reasonable ones that nobody ever revisited, and reining it in is less about a clever tool than about a few disciplined habits.

Tagging: you cannot manage what you cannot attribute

The root problem behind most runaway cloud bills is that no one can tell what each resource is for or who owns it. A consistent tagging policy fixes this at the source. By requiring every resource to carry tags for its owner, project, and environment, you turn an opaque bill into something you can actually read: this much for that project, that much for this team. Tagging is unglamorous and easy to defer, but without it, every cost conversation stalls on "what even is this line item?" With it, waste becomes visible and accountable, which is the first requirement for cutting it.

Idle and orphaned resources

The most common form of cloud waste is paying for things nobody uses. Test servers left running after the test ended, storage volumes that outlived the machines they were attached to, oversized instances provisioned for a peak that never recurs, and old snapshots accumulating month after month. Individually each is small; collectively they are often a large share of an avoidable bill. Two habits address this: right-sizing, where you periodically check whether running resources are actually as large as they need to be, and a regular sweep for orphaned resources that are costing money while serving no one. Much of this can be automated, but even a manual monthly pass finds real savings.

The review cadence that makes it stick

Cost control is not a one-time cleanup; it drifts back the moment attention lapses, which is why the most effective practice is a recurring review. A short monthly look at the bill, broken down by the tags above, with someone responsible for asking why anything jumped, keeps sprawl from rebuilding. The goal is not to make every engineer obsess over pennies but to create a steady, lightweight rhythm of visibility and accountability. For organizations without the in-house bandwidth to run this consistently, an Orlando IT solutions provider can set up the tagging, monitoring, and review process so the savings persist instead of evaporating after the first cleanup.

Enforce tagging by owner, project, and environment so costs are attributable.
Hunt down idle and orphaned resources; right-size what is oversized.
Hold a short, recurring cost review so sprawl cannot quietly rebuild.
Automate where you can, but a manual monthly pass still pays off.

Cloud sprawl is not one bad call. It is a thousand small, reasonable ones nobody circled back to, which is exactly why a recurring review beats a one-time purge.

The encouraging part is that controlling cloud costs rarely requires re-architecting anything; it requires knowing what you have, removing what you do not need, and looking at the bill on a schedule. Teams that adopt those habits routinely trim a meaningful fraction of their spend without touching anything users notice. The waste was never delivering value in the first place, which makes this one of the few optimizations that is pure upside once you build the discipline to keep at it.

Ransomware readiness for a 30-person company

Ryan Bell — Thu, 11 Jun 2026 11:22:13 +0000

Ransomware coverage tends to focus on large breaches, but the businesses hit hardest are usually small ones — the thirty-person company with no dedicated security staff, a flat network, and backups nobody has tested in a year. The good news is that ransomware readiness at this size is not about expensive tooling. It is about three unglamorous fundamentals done properly: backups you can actually restore from, a network that does not let one infection reach everything, and a team that has practiced what to do. Here is how a small shop builds each one.

Backups: the part that decides everything

When ransomware encrypts your files, your recovery is only as good as your backups. The standard worth aiming for is "3-2-1": three copies of your data, on two different types of media, with one copy kept offline or otherwise out of reach of the network. The offline part is the piece small businesses miss. Modern ransomware actively hunts for connected backups and encrypts those too, so a backup drive that is always plugged in offers a false sense of safety. An immutable or air-gapped copy — one that cannot be altered or deleted for a set retention window — is what lets you say no to a ransom demand.

And a backup you have never restored is a hypothesis, not a safety net. Schedule a test restore at least quarterly. The first time most teams try, they discover the backup was missing a critical database, or that a full restore takes far longer than the business can afford to be down. Better to learn that on a calm Tuesday than during an incident.

Segmentation: stop one machine from becoming all of them

On a flat network, every device can talk to every other device, which is exactly how ransomware spreads from a single clicked attachment to the whole company in minutes. Segmentation breaks the network into zones — separating, say, the point-of-sale systems, the back-office machines, the servers, and the guest Wi-Fi — so that an infection in one zone cannot freely reach the others. For a small business this does not require a redesign; even basic VLAN separation and tightened firewall rules between segments dramatically shrink the blast radius. Pair it with the principle of least privilege on file shares so a compromised user account cannot encrypt data it never needed to touch.

Drills: the plan you have not rehearsed will not hold

An incident-response plan that lives in a document nobody has read fails under pressure. Run a tabletop exercise once or twice a year: gather the handful of people who would be involved and walk through a realistic scenario out loud. Who disconnects the affected machines? Who has the backup admin credentials, and are they stored somewhere that is not also encrypted? Who calls the insurer, and who talks to staff and customers? These exercises routinely surface gaps — a single person who is the only one who knows the recovery process, a contact list that is itself on the file server — that are cheap to fix beforehand and ruinous to discover during an attack.

Putting it together

None of these three require enterprise budgets, but they do require someone to own them and keep them current. A small business without in-house IT often gets there fastest with a managed services partner — a provider like Dytech Group can set up immutable backups, segment the network, and run the periodic restore tests and tabletop drills so readiness does not quietly lapse. Backups, segmentation, drills: get those three right and a ransomware infection becomes a bad day instead of an extinction event.

Email authentication for small businesses: SPF, DKIM, and DMARC in plain terms

Ryan Bell — Mon, 08 Jun 2026 14:25:07 +0000

If your domain sends email and you have never touched SPF, DKIM, and DMARC, you are both easier to spoof and more likely to land in spam than you need to be. These three DNS records are the backbone of email authentication, and for a small business they are some of the highest-leverage security work you can do in an afternoon. Here is what each one actually does and the order to roll them out.

SPF: who is allowed to send

SPF — Sender Policy Framework — is a single DNS TXT record that lists the mail servers authorized to send email for your domain. When a receiving server gets a message claiming to be from you, it checks your SPF record and asks: did this actually come from an IP you approved? A record looks something like v=spf1 include:_spf.google.com include:servers.mcsv.net -all — your mail provider, any third-party senders (marketing tools, ticketing systems), and a policy at the end. The two common failure modes are forgetting a legitimate sender, which sends your own mail to spam, and the "too many DNS lookups" limit, which silently breaks SPF once you chain too many includes. The -all at the end is a hard fail; many start with ~all (soft fail) while testing.

DKIM: proof the message wasn't tampered with

SPF authorizes the server; DKIM authorizes the message. DomainKeys Identified Mail attaches a cryptographic signature to every outgoing email, using a private key your mail provider holds, and publishes the matching public key in your DNS. The receiver recomputes the signature and confirms two things: the mail came from your domain, and the headers and body were not altered in transit. Most providers generate the keys for you — you just paste a TXT (or CNAME) record at a selector like google._domainkey. The one habit worth keeping is rotating keys periodically, the same way you would any other secret.

DMARC: what to do when checks fail

SPF and DKIM each answer a question; DMARC decides what happens with the answer and tells you about it. A DMARC record sets a policy — none, quarantine, or reject — for mail that fails authentication, and crucially it can email you aggregate reports of who is sending under your domain. The correct rollout is gradual: start at p=none with reporting on, read the reports for a few weeks to find every legitimate sender you forgot, fix your SPF and DKIM until real mail passes cleanly, then tighten to quarantine and finally reject. Jumping straight to reject is how teams nuke their own invoices and password resets.

The order, and getting help

Roll them out in sequence: SPF first, then DKIM, then DMARC at p=none to observe, tightening over weeks. None of it costs anything but DNS edits and attention. If your business does not have someone who lives in DNS and would rather not learn the hard way which record breaks the CEO's email, this is exactly the kind of recurring, easy-to-get-wrong task a managed IT services provider handles as routine — set it up correctly once, monitor the DMARC reports, and keep the records current as you add and drop senders. Done right, the payoff is concrete: less of your mail in spam folders, and far less of your domain in the hands of whoever is impersonating it.