DEV Community: Muskan Bandta

AWS Storage Explained: S3 vs EBS vs EFS, and When to Use Which

Muskan Bandta — Thu, 24 Sep 2026 05:27:31 +0000

S3, EBS, EFS. Three AWS storage services, similar-looking names, completely different jobs, and using the wrong one for a task is a classic beginner mistake that leads to weird architectures and surprise bills. The good news: once you understand the one thing that separates them, choosing is easy. Let me explain what each is, in plain terms, and give you a rule that picks the right one every time.

The key distinction: how the storage is accessed

The three services differ mainly in how your application talks to the storage. That single distinction drives everything else.

EBS is a disk attached to one server.
EFS is a shared file system many servers can mount at once.
S3 is object storage you access over an API, not a file system at all.

Get that, and the rest follows.

EBS: a hard drive for one instance

EBS (Elastic Block Store) is a block storage volume, essentially a virtual hard drive you attach to a single EC2 instance. Your operating system sees it as a disk, formats it, and reads and writes to it like any local drive.

Key properties:

Attached to one instance at a time (in the normal case). It is that instance's disk.
Lives in one Availability Zone.
This is where your OS, your databases, and anything that needs fast, low-latency block access lives.

Use EBS for: the boot volume of an EC2 instance, and storage for a database or application that runs on that instance and needs a real disk. If you are thinking "my server needs a drive," that is EBS.

EFS: a shared drive many instances can mount

EFS (Elastic File System) is a managed network file system. Unlike EBS, many instances can mount the same EFS file system at once and see the same files. It grows and shrinks automatically, and it spans Availability Zones.

Use EFS for: workloads where multiple servers need to share the same files, a fleet of web servers serving the same content, a shared home directory, a content management system across instances. If your answer to "which server owns this data" is "several of them, together," that is EFS.

The tradeoff: it is more expensive per GB than EBS and has network-file-system latency, so it is not the right home for a high-performance database. Use it for sharing, not for raw speed.

S3: object storage over an API

S3 (Simple Storage Service) is different in kind. It is not a disk and not a file system. You store objects (files plus metadata) in buckets, and you access them over an HTTP API (GetObject, PutObject), not by mounting a drive. Your app talks to S3 with SDK calls, not filesystem reads.

Key properties:

Effectively unlimited scale, extremely durable, cheap per GB.
Accessed over the network by API from anywhere, not tied to an instance.
Not a filesystem, you cannot "cd into" a bucket, you request objects by key.

Use S3 for: backups, static assets (images, videos, downloads), data lakes, logs, anything you access as whole files rather than editing in place, and static website hosting. If you are storing files an application reads and writes as objects, that is S3, and it is usually the cheapest and most scalable choice.

The rule that picks the right one

Ask "who needs to access this, and how?"

One instance needs a fast local disk (OS, database)? EBS.
Multiple instances need to share the same files live? EFS.
You are storing files you access as objects over an API (assets, backups, logs, data)? S3.

Nine times out of ten the answer is obvious once you frame it that way. The classic mistake is using an EBS volume or EFS for something that should be S3 (like storing uploaded images on a server's disk instead of in a bucket), which makes your app stateful, harder to scale, and more expensive.

A cost note

Rough order, cheapest to most expensive per GB: S3 (cheap, and cheaper still with lifecycle rules moving old data to colder tiers), then EBS, then EFS (the shared-filesystem convenience costs more). This is another reason to default to S3 for anything you can: it is usually both the most scalable and the cheapest. And on EBS specifically, use gp3 volumes, they are cheaper and better than the older gp2.

The take

S3, EBS, and EFS are not competitors, they are three answers to three different questions. EBS is a disk for one instance, EFS is a shared file system for many, and S3 is API-accessed object storage for files at scale. Ask who needs the data and how they access it, and the choice makes itself. Default to S3 whenever your data is really just files, it is usually the cheapest, most scalable, and least painful option.

Which storage service did you misuse first? A lot of people start by saving uploads to an instance's EBS disk, then learn the hard way why that data belonged in S3 the first time they needed a second server.

A Model That Finds Zero-Days Now Exists. Here's the Cloud Exposure Audit to Run This Week.

Muskan Bandta — Thu, 24 Sep 2026 05:27:20 +0000

GPT-6 Astra shipped with the first Critical cybersecurity rating OpenAI has ever given a model, because it can autonomously find zero-days and build working exploits. The capability is gated for now, but the honest planning assumption is that some form of automated vulnerability discovery reaches adversaries sooner than anyone would like. I am not going to write a doom piece about that. I am going to give you the audit I actually ran on our own cloud this week, because the useful response to this news is not fear, it is a checklist you can finish in a few hours.

The thesis is simple: automated vulnerability discovery probes what is reachable, not what is important to you. So the single highest-value thing you can do is know and shrink what you expose. Here is how.

1. Inventory what is actually reachable from the internet

You cannot defend what you do not know is exposed, and every account exposes more than its owners think. Build the list:

Public IPs and the instances behind them.
Load balancers and what they route to.
S3 buckets with any public access, and buckets fronting a CDN.
Security groups allowing 0.0.0.0/0 on any port, and especially on anything that is not 443.
API endpoints, admin panels, and dashboards reachable without a VPN.

Most teams find something here they forgot existed. That forgotten thing is exactly what automated discovery finds first.

2. Kill the exposure you do not need

For everything on that list, ask "does this need to be reachable from the entire internet." Usually a surprising amount does not:

Dev and staging environments with public IPs that could sit behind a VPN.
Admin interfaces open to the world that should be IP-restricted.
Security groups with 0.0.0.0/0 that were "temporary" a year ago.
Old load balancers and endpoints from services that no longer exist.

Every item you remove is one fewer thing any scanner, human or automated, can probe. This overlaps almost perfectly with the orphaned-resource cleanup I usually frame as cost work: the forgotten public bucket and the idle exposed load balancer are both a bill and an attack surface.

3. Measure and shrink your patch latency

If exploit development speeds up, the window between a vulnerability going public and being weaponized shrinks toward zero. Your patch latency, how long from "CVE published" to "patched in prod", becomes your dominant risk. Two moves:

Actually measure it. Pick your last few notable patches and time them. Most teams are slower than they believe.
Shorten it for internet-facing systems specifically. You do not need to patch everything in an hour; you need to patch the reachable things fast, because those are what gets probed.

4. Tighten the identities attached to exposed things

For anything reachable, check the blast radius if it were compromised: what IAM role or permissions does it carry? An exposed instance with an over-broad role turns a foothold into a full incident. Simulate the permissions of your internet-facing workloads and cut anything they do not need. Least privilege is not new advice; it is the advice that limits how far a successful exploit gets.

5. Make sure something independent would notice

You will not prevent every novel exploit if they get cheap to produce. So the last layer is detection, and it has to be independent of the thing being attacked:

Anomaly alarms on API call velocity per identity (CloudTrail to metric filter to alarm is enough to start).
Alerts on unexpected state changes and on spend spikes (a compromised account often shows up as a cost anomaly first).
A watcher comparing real resource state to expected baselines, on separate credentials from your workloads, so a breach that changes something surfaces as drift within minutes. (That independent-verification pattern is one we built into ZopNight precisely because the system being attacked cannot be trusted to report its own compromise.)

The take

A model that autonomously finds and weaponizes zero-days now exists, and even gated, that resets the clock on defensive fundamentals. The response is not to panic, it is to spend an afternoon this week doing five boring things: inventory what you expose, remove what you do not need exposed, measure and shrink patch latency, tighten the identities on reachable systems, and confirm something independent would notice a breach. None of it is new. All of it just got more urgent, because the assumption underneath the old comfort, that finding novel exploits is slow and expensive, is the assumption that is expiring.

Run the exposure inventory in step one and I would bet you find at least one thing you forgot was public. What did you find? Mine was an old dev load balancer still routing to something, exactly the kind of forgotten reachable surface this whole exercise is about.

IAM Explained Simply: Users, Roles, Policies and Why It Confuses Everyone

Muskan Bandta — Fri, 18 Sep 2026 06:43:59 +0000

IAM is the thing every AWS beginner bounces off. It is also the thing you cannot avoid, because nothing in AWS works until IAM lets it. The confusion is not your fault: IAM has a few pieces that sound similar (users, roles, policies, groups) and the relationships between them are not obvious. Let me explain it the way I wish someone had explained it to me, with no jargon until it earns its place.

The one sentence version

IAM answers a single question for every request in your account: is this identity allowed to perform this action on this resource? Everything else is detail about how you express "this identity," "this action," and "this resource." Hold that sentence and the pieces fall into place.

The pieces, in plain terms

Identities (who is asking):

User: a person or a long-lived thing with its own credentials. You, logging in. A user is meant for a human or a fixed program.
Group: just a bucket of users so you can attach permissions to many people at once. "The Developers group." A group is a convenience, not an identity that acts.
Role: the one that confuses everyone, and the most important to understand. A role is a set of permissions that anything can temporarily assume. It has no permanent credentials. An EC2 instance, a Lambda function, or a user from another account can "put on" a role and get its permissions for a short time, then take it off. Think of a role as a costume anyone approved can wear, not a person.

Permissions (what they can do):

Policy: a JSON document that says Allow or Deny for specific actions on specific resources. Policies are where the actual permissions live. You attach policies to users, groups, or roles.

So the shape is: policies define permissions, and you attach them to identities (users, groups, roles).

Why roles are the part that clicks last

Beginners get users immediately and roles slowly, because "permissions nobody owns permanently, that things temporarily assume" is unusual. But roles are how AWS wants you to work, for a good reason: no long-lived credentials to leak.

Instead of giving your EC2 instance a stored access key (which can be stolen), you attach a role to the instance. The instance assumes the role and gets temporary credentials that rotate automatically. Same for Lambda, for cross-account access, for CI pipelines. If you find yourself creating a user and storing its keys somewhere for a machine to use, that is almost always a sign you should have used a role instead.

A tiny policy, decoded

Policies look scary and are actually simple once you see the structure:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

Read it as a sentence: Allow the action get an S3 object on the resource any object in my-bucket. That is it. Effect (Allow/Deny), Action (what), Resource (on what). Most policies are just longer lists of these.

The two rules that resolve most confusion

1. Explicit Deny always wins. If any policy that applies to you says Deny, you are denied, no matter how many Allows exist. This is why "I have admin but still get access denied" happens, some Deny higher up (an SCP, a boundary) overrode your Allow.

2. Deny by default. If nothing explicitly Allows an action, it is denied. You do not start with everything and remove; you start with nothing and grant. This is why a brand-new user can do almost nothing until you attach a policy.

How to not shoot yourself in the foot

Least privilege. Grant the specific actions needed, not *. It is annoying now and a relief forever. Broad permissions are how accounts become un-auditable.
Roles for machines, users for humans (and prefer SSO even for humans). Do not store access keys for services. Attach a role.
Use the policy simulator. Before you swear a permission is right, simulate it. AWS has a tool that tells you whether a given identity can do a given action, no guessing.
Groups for people, not roles. Put humans in groups and attach policies to the group, so onboarding is "add to group," not "copy someone's permissions."

The take

IAM is confusing because the words overlap, not because the idea is hard. It answers one question, is this identity allowed to do this action on this resource, using policies (the permissions) attached to identities (users for humans, roles for machines and temporary access, groups for convenience). Remember that explicit Deny wins and everything is denied by default, prefer roles over stored keys, and grant least privilege, and IAM stops being the wall you bounce off.

What part of IAM took longest to click for you? For most people it is roles, the "permissions nobody owns that things temporarily wear" idea that is unlike anything else until it suddenly makes sense.

Astra Solved 10 Decades-Old Problems on a Rounding Error of Compute. The Real Story Is the Cost Curve.

Muskan Bandta — Fri, 18 Sep 2026 06:43:47 +0000

Before GPT-6 Astra made headlines for finding zero-days, it did something quieter and, to me, more economically startling: it produced proofs for ten mathematics and theoretical computer science problems that had sat unsolved for decades, and it did it for a reported few thousand dollars of compute. Everyone focused on the math. I keep thinking about the invoice. Because the story that matters for anyone who budgets infrastructure is not "AI is smart now," it is what happens to planning when a unit of genuinely novel intellectual work drops to the price of a rounding error.

The number is the news

Decades-unsolved problems are, by definition, things that resisted a lot of expert human effort. The traditional cost of solving one is measured in careers, not dollars. Astra reportedly cleared ten for an amount of compute that would not survive a single line-item review on most cloud bills.

Set aside whether every proof holds up (that verification matters and is its own story). The direction is the point: the marginal cost of attempting hard, novel, high-value intellectual work is collapsing toward the cost of the compute to run the attempt. That is a different economic regime, and it breaks assumptions that FinOps and capacity planning are built on.

Why this is a cost-planning problem, not just an AI story

For years, expensive cognitive work was a fixed, scarce, human input you planned around. You could not "scale up" a research breakthrough by renting more of it. Now, increasingly, you can attempt to, by spending compute. That changes three things about how you budget:

Some work moves from headcount to a cloud line item. Tasks that used to be "hire an expert, wait a quarter" become "spend some compute, get an attempt back today." The cost does not disappear, it moves from payroll to your inference and GPU bill, where it behaves completely differently: usage-metered, spiky, and attributable only if you instrument it.
The temptation to over-attempt is real. When one attempt is cheap, teams run many. Cheap-per-attempt times a-lot-of-attempts is how a "rounding error" becomes a real number on the bill. This is Jevons paradox again: make something efficient and consumption rises to meet it.
The value per run is wildly variable. A $2,000 run that cracks a decades-old problem is the deal of the century. A $2,000 run that produces a plausible-looking wrong answer nobody verifies is $2,000 of waste dressed as progress. The cost is easy to see; the value is hard, and connecting them is the actual discipline.

The FinOps muscles this demands

None of this is exotic if you already do cloud cost work. It is the same muscles, pointed at a new kind of spend:

Attribute it. Which team, which project, which question generated this compute? Novel-work spend hides across invoices and shared keys exactly like early cloud spend did. If you cannot attribute it, you cannot manage it.
Cap the attempts. Budgets and rate limits per project, so "cheap per run" does not quietly become "expensive in aggregate" while everyone feels frugal.
Verify before you value. The run cost is the easy half. The hard half is checking whether the output is right and worth what it cost. A pile of unverified AI outputs is not an asset, it is a liability with a receipt.
Watch for runaway loops. An automated pipeline firing expensive runs on a loop is the new "forgot to turn off the GPU box," and it shows up as a spend anomaly before anyone notices. (Anomaly detection on this spend is the same instinct as anomaly detection on cloud cost, which is part of what ZopNight does, pointed at a new resource.)

The take

Astra solving ten decades-old problems cheaply is being read as a capability milestone, and it is one. But the more durable lesson for anyone who plans infrastructure spend is economic: the cost of attempting hard, novel work is collapsing toward compute, which means categories of work are migrating from headcount onto your cloud bill, where they behave like every other usage-metered cost, cheap per unit, dangerous in aggregate, and worthless unless you connect the spend to verified value. The teams that treat this like real FinOps, attribute, cap, verify, alert, will get the leverage. The teams that treat it as "it's only a few thousand dollars" will find out how fast a few thousand dollars, many times over, adds up.

Is your organization starting to spend real compute on open-ended, novel work yet? And if so, is that spend tracked as a real cost line with attribution, or is it still "it's just some API calls"? That gap is where I expect the next round of budget surprises.

How OpenAI Decided Astra Was Too Dangerous to Ship Open: Capability Thresholds, Explained

Muskan Bandta — Fri, 18 Sep 2026 06:43:37 +0000

When GPT-6 Astra shipped on September 3, the headline was that OpenAI rated it Critical for cybersecurity, the first time it has ever given a model that rating, and chose to gate the dangerous capability rather than release it openly. A lot of coverage treated "Critical" as a vibe. It is not. It is the output of a structured process for deciding when a model is too dangerous to ship as-is, and understanding that process is genuinely useful, because this kind of capability-gating is going to become normal and you will keep seeing these ratings. Here is how it actually works, in plain terms.

The core idea: capability thresholds, not just "is it safe"

The framework OpenAI and other labs use does not ask the vague question "is this model safe." It asks a sharper one: "does this model cross a defined capability threshold in a domain we consider dangerous." Cybersecurity is one such domain (others include things like bio and autonomy). Each domain has tiers, roughly escalating from low to high to critical, defined by what the model can do, not how it feels.

So "Critical for cybersecurity" is not a mood. It is a claim that the model crossed a specific, pre-defined capability line, in this case, the ability to autonomously find zero-day vulnerabilities in hardened systems and turn them into working exploits without human guidance. That is a bright-line capability, and the model reportedly cleared it.

Why the threshold triggers action, not just a label

The point of defining thresholds in advance is that crossing one is supposed to force a response, before the model ships, not after something goes wrong. That is exactly what played out with Astra:

An internal evaluation showed the model performing well enough at autonomous cyberattacks that OpenAI could not rule out having crossed its Critical threshold.
Crossing that line triggered a pause on parts of the work while the company strengthened isolation, internet controls, action monitoring, and alignment.
Development resumed after those mitigations, and the model shipped with the dangerous capability gated rather than open.

The sequence is the whole value of the framework: define the dangerous line ahead of time, evaluate against it honestly, and let crossing it mandate specific safeguards. Without pre-defined thresholds, "is it too dangerous" becomes a judgment call made under launch pressure, which is exactly when you do not want to be inventing the standard.

What "gated" means as a mitigation

Rating a capability Critical does not automatically mean "do not ship." It means "do not ship this capability openly." Astra's general intelligence is available; the zero-day capability ships behind split, controlled access. This is the framework working as intended: it separates the dangerous slice from the useful whole and applies controls proportional to the risk, rather than the blunt choice of ban-it-all or ship-it-all.

Why this matters even if you never touch model safety

You are not running these evaluations. So why care? Two reasons that are directly practical:

These ratings are becoming a signal you should read. When a model ships with a Critical cyber rating, that is public information about what capabilities now exist in the world, gated or not. It is an input to your own threat model. "A model that can autonomously find zero-days exists as of September 2026" is a planning fact, and the rating is how you learned it.
The pattern is coming to your own AI governance. The idea of defining capability thresholds in advance, evaluating against them, and gating what crosses the line is not just for frontier labs. Any organization deploying capable AI against real systems will eventually need its own version: what is this agent allowed to do, at what capability does it require human gating, what is the pre-defined line that changes the rules. The framework labs are using is a preview of the governance every AI-using company will need.

The take

"Critical for cybersecurity" is not a marketing adjective, it is the result of a defined process: name the dangerous capabilities in advance, set thresholds, evaluate honestly, and let crossing a line force specific safeguards, up to and including gating the capability away from open release. Astra is the first model to trip the cyber threshold, and watching how OpenAI handled it, pause, mitigate, resume, ship gated, is a preview of how capable-but-dangerous AI gets released from here. It is also a template for the governance your own organization will need the day it puts a capable model near anything that matters.

Does your organization have any pre-defined line for what an AI system is allowed to do before a human has to step in, or is it still decided case by case under pressure? That "we'll know it when we see it" gap is exactly what capability thresholds are meant to close.

AWS Compute Explained: EC2 vs ECS vs Fargate vs Lambda, and When to Use Which

Muskan Bandta — Thu, 17 Sep 2026 11:17:29 +0000

AWS has a confusing number of ways to run your code, and the names do not tell you how they relate. EC2, ECS, Fargate, Lambda, and more, all "compute," all overlapping. Beginners pick one semi-randomly and stick with it. Let me lay out what each actually is, how much of the work AWS does for you versus you, and a simple way to decide, so you choose on purpose instead of by habit.

The one axis that organizes all of them

Every compute option sits on a single spectrum: how much of the operational work do you do versus how much AWS does. More control means more responsibility; less responsibility means less control. That is the whole tradeoff.

From most-you-manage to least:

EC2: you get a virtual server

EC2 (Elastic Compute Cloud) gives you a virtual machine. You pick the size, the operating system, and you are responsible for the OS, patching, scaling, and what runs on it. It is the most flexible and the most work.

Use it when: you need full control of the environment, you are running something that expects a real server (legacy apps, specific OS tuning), or you want to manage the machine yourself.

The catch: you own the undifferentiated heavy lifting, patching, scaling, keeping it healthy. Powerful, but you are the sysadmin.

Containers: ECS and the Fargate question

Containers package your app with its dependencies so it runs the same everywhere. To run containers on AWS you need two decisions: an orchestrator (what schedules and manages your containers) and a launch type (what the containers actually run on).

ECS (Elastic Container Service) is the orchestrator. It decides where your containers run, restarts them if they die, and scales them. But ECS still needs something to run the containers on, and that is where the two launch types come in:

ECS on EC2: your containers run on EC2 instances that you manage. You still own the servers under the containers.
ECS on Fargate: you do not manage any servers at all. You hand AWS a container and say "run this," and Fargate provisions the compute invisibly. No instances to patch or scale.

So Fargate is not a separate orchestrator, it is a serverless way to run containers. ECS (or EKS, the Kubernetes version) is the brain; Fargate is the "no servers to manage" launch option under it.

Use containers when: you want portability and consistent deploys, and you are running services (APIs, workers) that stay up. Choose Fargate over EC2 launch type unless you have a specific reason to manage the underlying instances (cost tuning at scale, special hardware).

Lambda: you give AWS a function

Lambda is the far end of the spectrum: you upload a function, and AWS runs it in response to an event (an HTTP request, a file upload, a queue message). No servers, no containers to manage, no capacity to plan. You pay per invocation and per millisecond of run time, and when nothing calls it, you pay nothing.

Use it when: your workload is event-driven, bursty, or intermittent, individual tasks are short, and you do not want to run anything 24/7. Great for glue code, webhooks, scheduled jobs, and light APIs.

The catch: cold starts (the first call after idle waits for the function to spin up), execution time limits, and it is a poor fit for long-running or steady heavy workloads (where always-on compute is cheaper).

A decision shortcut

Ask these in order:

Is it event-driven, short, and intermittent? Lambda. Do not run a server for something that fires a few times an hour.
Is it a long-running service you want portable and easy to deploy? Containers on ECS/EKS, and use Fargate so you do not manage servers, unless you have a reason to.
Do you need full control of the machine, a specific OS, or are you running something that expects a real server? EC2.
Not sure and want the least operational burden? Start serverless (Lambda for functions, Fargate for containers) and move toward EC2 only if you hit a wall or a cost crossover.

The cost angle in one line

Roughly: Lambda is cheapest for spiky, low-volume work (you pay only when it runs); containers on Fargate are a sweet spot for steady services without server management; EC2 becomes cheapest per unit at large, steady scale if you manage it well (rightsizing, commitments). "Serverless is always cheaper" and "EC2 is always cheaper" are both wrong, it depends on the shape of the workload.

The take

AWS compute is one spectrum from "you manage the server" (EC2) to "you hand AWS a function" (Lambda), with containers (ECS/EKS, run on EC2 or serverless Fargate) in between. Pick based on the shape of your workload and how much operational work you want to own: event-driven and short means Lambda, steady portable services mean containers on Fargate, full control means EC2. Choose on purpose, and you get the right tradeoff instead of whatever you used last time.

Which compute option did you default to when you started, and did you later realize a different one fit better? A lot of people run everything on EC2 first, then discover half of it should have been Lambda or Fargate.

AI Assistants Can Now Drive Your Kubernetes Cluster. Here's the Ops Risk Nobody's Costing In

Muskan Bandta — Tue, 15 Sep 2026 12:10:09 +0000

Red Hat is building an open-source MCP server for Kubernetes and OpenShift, which lets AI assistants like VS Code, Copilot, and Cursor read and act on your clusters directly. This is genuinely useful, describing what you want in plain language and having the assistant translate it into cluster operations is a real productivity win. It also hands an AI assistant a path to your cluster's control plane, and most of the excitement I have seen skips straight past what that means operationally. As someone who worries about blast radius, let me lay out the risk and how to adopt this safely, because the tool is coming whether or not you plan for it.

What "AI can drive your cluster" actually means

An MCP server for Kubernetes exposes cluster operations as tools an AI assistant can call: list resources, read logs, describe deployments, and depending on how it is configured, create, scale, patch, and delete. The assistant reasons in natural language and calls those tools to get things done.

The productivity case is obvious: "why is this pod crashing" becomes a conversation instead of ten kubectl commands. The risk is the same door: an assistant that can kubectl apply and kubectl delete has the same power as an admin running those commands, and it is driven by a model interpreting fuzzy instructions and whatever text it reads along the way.

The three risks to actually plan for

1. Read versus write is everything. An assistant that can only read your cluster is low-risk and high-value: it triages, explains, and suggests, and a human executes. An assistant that can write to the cluster is a different risk class entirely, because now a misinterpreted instruction or a confidently wrong plan becomes a real change to production. The single most important decision is where you draw the read/write line, and the safe default is read-only until you have strong reasons and strong guardrails otherwise.

2. The cluster's own data is an injection surface. This is the part people miss. An assistant driving your cluster reads logs, resource names, annotations, and events to do its job, and all of that is text that people and workloads can write. A crafted log line or a malicious annotation is now input to a system that can call cluster operations. It is the same prompt-injection problem that turns any credentialed agent into a liability: the assistant does not distinguish "instruction from my operator" from "text I read in a pod log." If it can write to the cluster, that injection surface has teeth.

3. RBAC is your real control, and it is probably too broad. Whatever the assistant can do is bounded by the Kubernetes RBAC of the identity it uses. If you point it at a service account with cluster-admin "to make it work," you have handed a language model cluster-admin. The whole safety story rests on scoping that RBAC tightly: least privilege, namespaced where possible, and no destructive verbs unless you have deliberately decided to allow them.

How to adopt it without getting burned

You do not have to choose between the productivity and the safety. In order:

Start read-only. Give the assistant a role that can get, list, and watch, and nothing that mutates. This captures most of the value (triage, explanation, debugging help) with almost none of the risk.
Scope RBAC tightly, per namespace. Do not use cluster-admin. Grant the specific verbs on the specific resources in the specific namespaces the assistant genuinely needs. This is the actual control, treat it as seriously as you would any admin credential.
Require human approval for writes. If you enable mutations, gate them: the assistant proposes the change, a human reviews and applies it. Plan then approve then execute, the same pattern that keeps any credentialed agent safe.
Audit everything. Log every operation the assistant performs, on separate infrastructure. When something goes wrong you need to reconstruct what it did, and "the assistant's own logs" are not a trustworthy record if the assistant is what misbehaved.
Stage rollouts of write access. If you must give it write access, do it in dev and staging first, watch how it behaves against real cluster data, and only then consider production, narrowly.

The take

AI assistants driving Kubernetes is a real productivity leap and a real expansion of who (or what) can change your cluster. The tool is arriving; the responsible move is to plan the guardrails before you enable it, not after an incident. Start read-only, scope RBAC tightly, gate writes behind a human, and audit independently. Do that and you get the debugging-as-a-conversation upside without handing a language model the keys to production. Skip it, and "the assistant deleted the wrong deployment" becomes a postmortem you could have avoided.

If you have wired an AI assistant to your cluster, did you give it write access, and if so, what guardrails did you put around it first? I would keep mine read-only for a long while before I trusted it with delete.

Astra Was Paused, Isolated, Then Resumed. What 'Air-Gapped Model Evaluation' Looks Like as Infrastructure

Muskan Bandta — Tue, 15 Sep 2026 12:09:57 +0000

One detail in the GPT-6 Astra story got less attention than the zero-days and the math, and it is the one I found most interesting as an infrastructure person. When OpenAI's evaluation suggested the model might have crossed its Critical cybersecurity threshold, the company did not just pause the work, it strengthened isolation, internet controls, and action monitoring before resuming. In other words, it changed the infrastructure the model runs and is tested in. That is a real engineering problem: how do you safely evaluate a system you suspect is dangerous, and what does that setup actually look like? Turns out the principles are ones any ops engineer already knows.

The problem: you have to test the thing you are afraid of

You cannot know whether a model can autonomously exploit systems without letting it try, in some form. But letting a genuinely capable offensive system loose in a normal environment is exactly what you are trying to avoid. The whole discipline of dangerous-capability evaluation lives in that tension: give the model enough of a real environment to reveal what it can do, while ensuring that whatever it does cannot reach anything it should not. That is a containment problem, and containment is an infrastructure discipline.

The building blocks (and why they are familiar)

The controls reportedly strengthened around Astra map cleanly onto concepts you already use:

1. Isolation / air-gapping. The evaluation environment is cut off from anything that matters, no path to production, to the internet at large, or to other systems. In cloud terms this is an aggressively isolated network: a VPC with no internet gateway, no peering, no route to anything real, egress denied by default. If the model finds an exploit, there is nowhere for that exploit to go. This is the same instinct as running untrusted code in a sandbox, scaled up and taken seriously.

2. Controlled internet access. "No internet" is often too restrictive to test realistically, so instead of open egress you get a tightly controlled, logged, allowlisted path, if any. Every outbound connection is mediated and recorded. This is exactly the egress-control hygiene I harp on for normal workloads: default deny, allow the specific known destinations, log everything. The difference is only the stakes.

3. Action monitoring. Everything the model does is watched and recorded, on infrastructure the model does not control. If it tries something, you see it, and crucially you see it on a system separate from the one being tested. This is the independent-verification principle: the thing being evaluated cannot be the thing that reports on the evaluation, because a capable adversarial system would simply lie in its own logs.

4. Kill switches and reversibility. You need to be able to stop it, and to ensure that anything it changed can be undone. Nothing it touches should be irreversible. Designed undo, again, a principle any careful operator applies to risky changes, here applied to a risky system.

Why this is the same shape as running any credentialed agent safely

Here is the connection that made this click for me. The controls around evaluating a dangerous frontier model, isolate it, control its egress, monitor its actions independently, keep a kill switch, keep everything reversible, are the exact same controls you should put around any AI agent you give real access to. The frontier lab is doing it at maximum intensity because the stakes are maximal. But the pattern scales down directly to the ops agent you might wire into your own cloud:

Give it an isolated blast radius, not the run of the account.
Default-deny its ability to reach and change things, allow specifically.
Monitor what it does on infrastructure it does not control, so its own logs are not your only record.
Keep a way to stop it and undo what it did.

We built our own agent guardrails on these same principles (isolation, independent state verification, designed undo are the backbone of how ZopNight lets automation take real actions safely), not because we are evaluating a Critical-rated model, but because the containment shape is universal. Astra's evaluation setup is just the most extreme, most legible example of it.

The take

The most quietly instructive part of the Astra story is not what the model can do, it is how OpenAI contained it to find out: isolation, controlled egress, independent action monitoring, reversibility. Those are not exotic AI-safety concepts, they are containment fundamentals every infrastructure engineer already practices, dialed up to match the stakes. And they are the same fundamentals that make any credentialed AI agent safe to run, at any scale. If you want a template for safely operating capable AI in your own environment, the frontier lab's dangerous-model evaluation is a surprisingly good one, because it is just good containment, taken seriously.

If you run an AI agent with real access, how many of these four does your setup actually have, isolation, controlled egress, independent monitoring, a kill switch? Most setups I have seen have one or two and call it done. The Astra story is a reminder that the full set exists for a reason.

VPC for Beginners: Subnets, Route Tables, and How Traffic Actually Flows

Muskan Bandta — Fri, 11 Sep 2026 10:32:48 +0000

A VPC is where your cloud networking lives, and it is the topic beginners avoid until something will not connect and they are forced to learn it under pressure. That is the worst time to learn it. Let me walk through the VPC the calm way: what each piece is, and how a packet actually travels from the internet to your server and back, because once you can trace that path, VPC troubleshooting stops being guesswork.

What a VPC is

A VPC (Virtual Private Cloud) is your own private, isolated network inside AWS. You get an IP address range (a CIDR block like 10.0.0.0/16), and everything you run lives at some address inside it. Nothing outside can reach in, and nothing inside can reach out, unless you explicitly set up a path. That "explicitly set up a path" is the whole job.

The pieces, and what each one does

Subnets: slices of your VPC. You divide your VPC's IP range into subnets, each in one Availability Zone. The key distinction:

Public subnet: can reach the internet (has a route to an internet gateway). Put things here that need to be reachable from outside, like a load balancer.
Private subnet: no direct internet route. Put things here that should not be exposed, like databases and app servers.

There is nothing magic about "public" and "private," a subnet is public only because its route table sends internet-bound traffic to an internet gateway. Change the routing and its nature changes.

Route tables: the signposts. A route table is a list of rules that says "traffic for this destination goes this way." Each subnet is associated with a route table. This is where public/private is actually decided:

A route 0.0.0.0/0 -> internet gateway makes a subnet public (all internet traffic goes to the internet gateway).
No such route (or 0.0.0.0/0 -> NAT gateway) keeps it private.

Internet gateway: the door to the internet. One per VPC. It is the thing that lets public subnets talk to the internet, both directions. No internet gateway, no internet.

NAT gateway: one-way door for private subnets. A private subnet has no internet route, but sometimes a private server needs to reach out (to download updates, call an API) without being reachable in. A NAT gateway, placed in a public subnet, lets private instances initiate outbound connections while staying unreachable from outside. (It also costs money per hour and per GB, worth knowing.)

Security groups and NACLs: the guards.

Security group: a firewall attached to a resource (like an instance). Stateful, if you allow traffic in, the response is automatically allowed out. This is your main, everyday control.
NACL (Network ACL): a firewall at the subnet level. Stateless, you must allow both directions explicitly. Most people leave NACLs open and rely on security groups.

How traffic actually flows (trace one packet)

Here is a request from a user on the internet to your app, which is the mental model that makes everything click.

A user hits your load balancer, which lives in a public subnet.
The packet arrives at the VPC through the internet gateway (because the public subnet's route table sends internet traffic there).
The load balancer's security group checks: is inbound traffic on port 443 allowed? If yes, in it goes.
The load balancer forwards to your app server in a private subnet. This is internal VPC traffic, no internet gateway needed.
The app server's security group checks: is traffic from the load balancer allowed? If yes, the app handles it.
The response travels back the same path. Because security groups are stateful, the return traffic is automatically allowed.

Now the reverse case that trips people up: the app server needs to call an external API.

Its packet is bound for the internet, but it is in a private subnet with no internet gateway route.
The route table sends 0.0.0.0/0 to a NAT gateway in the public subnet.
The NAT gateway forwards it out through the internet gateway, and the response comes back to the app, but nobody outside could have initiated a connection to the app.

Why "it will not connect" is usually easy to diagnose

Almost every VPC connectivity problem is one of these, checked in order:

Route table: does the subnet have a route to where the traffic needs to go (internet gateway for public, NAT for private outbound)?
Security group: does it allow the port and source?
NACL: is the subnet-level ACL blocking it (rare, but check)?
Public IP: does the resource even have a public IP if it needs to be reached directly?

Trace the packet's intended path and check each hop. The problem is almost always a missing route or a closed security group.

The take

A VPC is your private network, and everything in it comes down to slicing it into public and private subnets, using route tables to decide where traffic goes, and using security groups to decide what is allowed. Public means "has a route to the internet gateway," private means "does not." Learn to trace one packet from the internet to your server and back, and VPC stops being the scary part of AWS and becomes the part you reason about calmly.

What VPC concept finally made networking click for you? For me it was realizing "public subnet" is not a setting, it is just a route table with a path to the internet gateway.

Offensive AI Just Became Real With Astra. Defensive AI Is the Only Thing That Scales to Meet It.

Muskan Bandta — Fri, 11 Sep 2026 10:32:36 +0000

GPT-6 Astra is the moment offensive AI stopped being hypothetical. A model that can autonomously find zero-days and build working exploits, rated Critical by its own maker, is a different category from "AI helps attackers write code faster." The capability is gated today, but the demonstration is done: this is possible, and possibility diffuses. The question I keep coming back to is not "should I be scared," it is structural: if attacks can be generated at machine speed and scale, what defends against that? And the uncomfortable answer is that human-speed defense alone does not, which means the interesting shift is defensive AI, and it is one defenders should welcome rather than fear.

Why human-speed defense stops being enough

Security has always been asymmetric: attackers need one way in, defenders have to cover everything. What kept that survivable was that finding novel ways in was slow and expensive, it required rare human expertise and time. That scarcity was a quiet tax on attackers that protected everyone.

Machine-speed vulnerability discovery removes that tax. If probing your entire attack surface for novel weaknesses becomes something you rent by the hour, the volume and velocity of attacks can exceed what human analysts can triage. You cannot hire your way out of a speed mismatch. A team that reviews alerts at human pace against attacks generated at machine pace loses on throughput alone, not on skill.

This is the real reason offensive AI matters to defenders. It is not that any single attack is unstoppable. It is that the rate changes, and rate is something humans do not scale on.

What "defensive AI" actually means (and does not)

Defensive AI is not a magic shield or a product you buy to make the problem disappear. It is the recognition that some parts of defense have to move at the same speed as the offense, which means automation and machine reasoning in the loop. Concretely, the parts that have to speed up:

Detection. Noticing that something is wrong, across a huge surface, faster than a human scanning dashboards. Anomaly detection on behavior, on API velocity, on state changes, on spend, at machine speed.
Triage. Deciding which of ten thousand signals matters, so humans spend their limited attention on the real thing instead of drowning.
Response to the routine. Automatically containing or reverting the clear-cut cases (a known-bad pattern, an obviously compromised credential) so humans handle judgment, not volume.

What it does not mean: taking the human out of the consequential decisions. The point is to match the offense's speed on detection and triage so that human judgment is spent where it is actually needed, not exhausted on throughput.

The part defenders can actually feel good about

Here is the genuinely optimistic read. Defense has a structural advantage attackers do not: defenders know their own environment. An attacker's AI has to discover what you have. Your defensive AI already knows your inventory, your baselines, your normal. That asymmetry is real, and it is exactly the asymmetry the Astra evaluation itself relied on, they contained the model by controlling an environment they fully understood.

So the defensive playbook for the machine-speed era is not exotic, it is the fundamentals with automation added for speed:

Know your environment cold. Full inventory, clear baselines. You cannot detect abnormal if you never defined normal. This is the same discovery discipline that underpins cost management.
Automate detection and let it run at machine speed. Independent monitoring that compares reality to expected state continuously, not a human glancing at a dashboard twice a day. (This is the shape of what we built into ZopNight for state and cost anomalies, and the same shape applies to security signals.)
Keep humans on judgment, automation on volume. Machine speed for triage and the obvious cases, human review for the consequential ones.
Shrink the surface so the machine has less to defend. Every forgotten exposure you remove is one fewer thing either side's AI has to reason about, and it tilts the known-my-environment asymmetry further in your favor.

The take

Astra makes offensive AI real, and the honest structural consequence is that human-speed defense alone cannot keep pace with machine-speed attacks, not because of skill, but because of rate. The response is not fear, it is defensive AI: automation on detection and triage so that human judgment goes where it is needed instead of being spent on volume, built on the one advantage defenders keep, that you know your own environment and the attacker has to discover it. Know your environment cold, automate detection at machine speed, keep humans on the decisions that matter, and shrink the surface. The offense got faster. The defense has to, and it can, because it starts from home ground.

If attacks start arriving at machine speed, which part of your defense breaks first, detection, triage, or response? For most teams it is triage, the human bottleneck of deciding what matters, which is exactly the part that has to get faster first.

Savings Plans vs Reserved Instances in 2026: The Rules We Actually Use

Muskan Bandta — Fri, 11 Sep 2026 10:32:29 +0000

Committing to AWS in exchange for a discount is one of the biggest cost levers you have, and it is also where people freeze, because there are two mechanisms (Savings Plans and Reserved Instances), several flavors of each, and a real risk of locking in the wrong thing for a year. Here is the practical version: what each one is, and the simple rules we use to decide, without the analysis paralysis.

The core idea behind both

On-demand pricing is the flexible, expensive default. Both Savings Plans and Reserved Instances give you a discount (often 30 to 70%) in exchange for committing to a level of usage for 1 or 3 years. The difference is what you commit to.

Reserved Instances: commit to specific capacity

An RI is a commitment to a specific instance configuration: instance family, region, and (for standard RIs) more or less locked-in attributes, for a 1 or 3 year term.

Standard RIs: biggest discount, least flexible. You are largely committing to a specific family in a region.
Convertible RIs: smaller discount, but you can exchange them for different families later.

RIs also can provide a capacity reservation, guaranteeing you can launch that instance in that AZ, which matters if you need guaranteed capacity.

Savings Plans: commit to spend, not capacity

A Savings Plan is a commitment to spend a certain dollar amount per hour (say $10/hour) for 1 or 3 years, and AWS applies the discount to your usage up to that amount.

Compute Savings Plans: the most flexible. The discount applies across instance families, regions, operating systems, and even Fargate and Lambda. Smaller discount than the most locked-in RI, but it follows your usage as it changes.
EC2 Instance Savings Plans: commit to a specific instance family in a region for a bigger discount, less flexible than Compute SP but more flexible than a standard RI within that family.

The rules we actually use

Here is the decision framework, in order:

1. Rightsize before you commit. Always. Never buy a commitment for an oversized instance, you will lock in the waste for a year. Rightsize first, then commit to the correct baseline. This is the mistake that turns a cost-saving into a cost-trap.

2. Cover your steady baseline, not your peak. Commit only to the usage you are confident will run the whole term, the always-on floor. Leave burst and uncertain workloads on on-demand (or spot). Over-committing is worse than under-committing, because unused commitment is pure waste.

3. Default to Compute Savings Plans for flexibility. For most teams, a Compute Savings Plan is the right default. It gives a strong discount and follows you across families, regions, Fargate, and Lambda as your architecture changes, which it will. You trade a few points of discount for not being locked to a family you might migrate off.

4. Use EC2 Instance Savings Plans or Standard RIs for stable, known workloads. If you have a large, stable workload you are certain will stay on a specific family (a fixed production fleet), the bigger discount of an EC2 Instance SP or Standard RI is worth the reduced flexibility.

5. Start with 1-year, no-upfront until you trust the number. A 3-year all-upfront commitment is the biggest discount and the biggest risk. Until you are confident in your baseline, a 1-year no-upfront plan captures most of the savings with far less lock-in. Ladder into longer terms as your confidence grows.

6. Remember RIs are the only option for some services. Savings Plans cover EC2, Fargate, and Lambda. But RDS, ElastiCache, Redshift, and OpenSearch still use Reserved Instances (or reserved nodes), not Savings Plans. So a full commitment strategy usually means Compute Savings Plans for compute plus RIs for your managed databases and data services.

Putting it together

A typical sensible setup:

Compute Savings Plan covering the steady EC2/Fargate/Lambda baseline.
Reserved Instances for the production RDS and ElastiCache baseline (no SP option there).
On-demand for burst and anything uncertain.
Spot for interruptible workloads.
All of it sized after rightsizing, and reviewed as usage changes, because commitments should track reality, not a snapshot from a year ago.

Cost Explorer will generate Savings Plans and RI recommendations from your usage history, which is a fine starting point, but run them through the rules above rather than buying what it suggests blindly. (Continuous tooling can track commitment utilization and coverage for you over time, which is part of what platforms like ZopNight do, but the decision logic is what matters.)

The take

Savings Plans commit to spend and flex across your usage; Reserved Instances commit to specific capacity for a bigger discount. Rightsize first, cover only the baseline, default to Compute Savings Plans for flexibility, use RIs where they are the only option (managed databases) or for very stable fleets, and start short until you trust your numbers. Do that and commitments become the biggest safe discount you have, instead of a year-long bet you regret.

How do you split your commitments, mostly Savings Plans, mostly RIs, or a layer of both? And has an over-commitment ever burned you? Mine was a family I committed to right before we migrated off it, a lesson in rule number one.

Containers vs VMs vs Serverless: The Mental Model That Finally Made It Click

Muskan Bandta — Thu, 10 Sep 2026 06:22:38 +0000

Virtual machines, containers, serverless. Three ways to run your code, endless articles comparing them, and yet a lot of people still cannot say clearly why you would pick one over another. The confusion comes from comparing them on the wrong axis. Here is the mental model that made it click for me: each one is a different answer to "how much of the machine do you carry with your app," and once you see them that way, when to use which becomes obvious.

The single axis: how much you carry

Think of running your code as packing for a trip. The question is how much of the environment you bring along.

Virtual machine: you bring the whole house. Your app, plus a full operating system, plus everything.
Container: you bring a suitcase. Your app plus just its dependencies, sharing the host's operating system.
Serverless: you bring yourself. Just your code, and the platform supplies everything else on demand.

Everything else, cost, speed, control, follows from how much you carry.

Virtual machines: the whole house

A VM virtualizes hardware. Each VM runs its own full operating system on top of a hypervisor that slices up a physical machine. Your app runs inside that complete OS.

You get: strong isolation (each VM is a separate OS), full control of the environment, the ability to run anything.
You pay in: weight. Each VM carries a whole OS, so they are large, slow to start (minutes), and you are responsible for patching and maintaining every one of those operating systems.

Use a VM when you need full control of the OS, strong isolation, or you are running something that expects a complete machine.

Containers: the suitcase

A container packages your app with its dependencies but shares the host operating system's kernel instead of carrying its own. That is the whole difference from a VM, and it changes everything:

You get: lightweight, fast-starting (seconds), portable units that run the same on your laptop and in production. You can pack many containers onto one host because they are not each dragging a full OS.
You pay in: slightly weaker isolation than VMs (they share a kernel), and you need something to orchestrate them at scale (Kubernetes, ECS).

Use containers when you want consistent, portable deploys and efficient use of your machines, which is most modern services. Containers are the default unit for a reason: they are the sweet spot between control and efficiency.

Serverless: just bring yourself

Serverless (like AWS Lambda) means you provide only your code, and the platform runs it on demand, provisioning and tearing down the compute invisibly. There is a server, you just never see or manage it.

You get: zero infrastructure to manage, automatic scaling (including to zero), and you pay only while your code actually runs. Nothing to patch, nothing to size.
You pay in: less control, cold starts (the first request after idle waits for a spin-up), execution limits, and a poor fit for long-running or steady heavy workloads.

Use serverless when your work is event-driven, bursty, or intermittent, and you want to manage nothing. Perfect for glue code, webhooks, and jobs that fire occasionally.

They are not mutually exclusive

The real world mixes all three. Serverless functions often run in containers under the hood. Containers run on VMs. A single system might use VMs for a legacy database, containers for its main services, and serverless for occasional event handlers. The question is never "which one for my whole company," it is "which one for this workload."

The decision, in three questions

Is the work event-driven, short, and intermittent, and do you want to manage nothing? Serverless.
Is it a service you want portable, efficient, and consistent across environments? Containers.
Do you need full OS control, strong isolation, or to run something that expects a whole machine? VM.

And the cost shape, roughly: serverless wins for spiky low-volume work (pay per run), containers win for steady services (efficient packing, no per-OS overhead), VMs make sense when you need the control or isolation and can keep them well-utilized.

The take

Stop comparing containers, VMs, and serverless on a feature checklist and compare them on one axis: how much of the machine you carry with your app. A VM brings the whole OS (heavy, isolated, full control). A container brings just dependencies and shares the kernel (light, portable, the modern default). Serverless brings only your code (zero management, scales to zero, less control). Match the amount you carry to the shape of the workload, mix them freely, and the choice stops being confusing.

Which one did this finally click with for you? For me it was understanding that a container shares the host kernel while a VM carries its own OS, that one sentence explained every difference in speed, size, and isolation at once.