How to Query Your Cloud Infrastructure in Plain English

In 2026, you can query databases in natural language. You can search codebases in natural language. You can ask AI assistants to generate entire applications in natural language. But most engineers still manage cloud infrastructure through provider-specific CLIs, web consoles, and dashboards that require memorizing commands, navigating five different UIs, or piping JSON through jq just to answer a simple question.

Infrastructure is the last major engineering surface that doesn't have a natural language interface. That gap is closing — and fast.

This article explains what querying infrastructure in natural language means, how it works technically, and what you can actually ask.

---

What "Querying Infrastructure in Natural Language" Means

Natural language infrastructure queries let you ask questions about your cloud environment the same way you'd ask a colleague — and get back a real, grounded answer based on live data.

Here are concrete before-and-after examples:

Kubernetes pods:

• Old way: kubectl get pods -n staging --field-selector=status.phase!=Running
• Natural language: "Which pods in the staging namespace aren't running?"

EC2 inventory:

• Old way: aws ec2 describe-instances --filters "Name=tag:Environment,Values=production" --query "Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,State:State.Name}"
• Natural language: "Show me all production EC2 instances and their types."

Cost investigation:

• Old way: Open AWS Cost Explorer → filter by service → set date range → compare to prior period → export CSV
• Natural language: "Why did our AWS bill go up this week?"

Security posture:

• Old way: Navigate to the IAM console → filter by last used date → cross-reference with policy attachments
• Natural language: "Show me IAM users with access keys that haven't been used in 90 days."

Network topology:

• Old way: Navigate to the VPC dashboard, load balancer console, and Route 53 separately
• Natural language: "Show me all load balancers and what they point to."

Recent changes:

• Old way: Parse CloudTrail logs or check your deployment tool's history
• Natural language: "What changed in production in the last hour?"

Cluster health:

• Old way: kubectl describe pod <name> for each pod, then check logs
• Natural language: "Which pods restarted recently and why?"

Idle resource audit:

• Old way: Export Cost Explorer data, filter by utilization, cross-reference with CloudWatch metrics
• Natural language: "Are we running any idle EC2 instances?"

The output in each case is a direct, grounded answer — not a documentation link, not a generic explanation. The tool fetches live data and tells you what's actually happening in your environment right now.

---

Why This Matters Now

Three things converged to make natural language cloud operations viable in 2026:

LLMs are good enough to understand infrastructure intent. Earlier models could generate CLI commands from natural language, but they hallucinated frequently and lacked the context to understand multi-cloud environments. Current models, grounded with live API data, can reliably translate "Why is the payments service slow?" into the right combination of API calls across Kubernetes metrics, load balancer health, and database connection pools.

Multi-cloud makes the old approach untenable. The average engineering team in 2026 is running AWS, Kubernetes, and at least one of GCP, Azure, Cloudflare, or a bare-metal provider. That's three or four completely different CLIs, four different console UIs, and four different mental models to hold simultaneously. A developer who can fluently use aws, kubectl, and gcloud in the same workflow is rare. A developer who can type a sentence is not.

AI coding tools have raised the expectation floor. Engineers who use Cursor, Claude Code, or Codex every day expect to be able to describe what they want and get it. They've stopped tolerating "look it up in the docs" for code. The same shift is happening for infrastructure. The mismatch — natural language for code, manual dashboards for infra — is increasingly obvious.

Infrastructure complexity has outpaced dashboard-based management. A modern production environment might have hundreds of services, thousands of pods, dozens of security groups, and multiple VPCs across regions. No dashboard was designed for this scale. You need something that can reason across the entire surface and return what's relevant to your specific question.

---

How It Works Technically

Understanding the architecture helps you trust the answers.

1. Your credentials stay local. A natural language infrastructure tool connects to your cloud providers using the credentials already on your machine — the same ones your CLI uses. There is no hosted SaaS layer that your secrets pass through. This is a critical distinction from chatbots that simulate knowledge of infrastructure: those tools generate plausible-sounding answers from training data. A grounded infrastructure tool fetches real data from real APIs.

2. Your question is translated into API calls. When you ask "Which pods in staging are unhappy?", the tool parses the intent, identifies the relevant providers and resources, and constructs the right API calls — in this case, a Kubernetes API request to the correct namespace with the appropriate filters.

3. Responses are aggregated into a unified answer. If your question spans multiple providers — "What's using the most compute across all environments?" — the tool queries AWS, GCP, Kubernetes, and any other connected providers in parallel, then aggregates the results into a single coherent response.

4. Answers are grounded in live data. Every answer reflects the current state of your infrastructure at query time. Not cached data from last week. Not training data from the model's pretraining corpus. Live API responses.

5. Read by default, act by choice. A well-designed natural language infrastructure tool separates read operations from write operations by default. Queries don't modify anything. When you want to make changes, you switch to an explicit "maker mode" — review the proposed changes, approve them, then execute.

---

What You Can Actually Ask

Here is a practical breakdown of the query types that work well with natural language infrastructure tools, organized by use case.

Topology and Discovery

Use these when you need to understand what's running, where it's running, and how it connects.

• "What services are running in us-east-1?"
• "Show me all load balancers and what they point to."
• "Map the dependencies for the payments service."
• "List all databases in the production environment."
• "What VPCs exist in my AWS account and what's in each one?"

Incidents and Debugging

Use these when something is broken and you need answers fast.

• "What changed in the last hour?"
• "Which pods restarted recently and why?"
• "Are there any failing health checks right now?"
• "Show me all 5xx errors in the last 30 minutes."
• "Which services have degraded replicas?"

Cost and Resource Efficiency

Use these for cost reviews, budget planning, and identifying waste.

• "What's the most expensive service this month?"
• "Are we running any idle instances?"
• "How much are we spending on the staging environment?"
• "Compare this month's AWS spend to last month by service."
• "Which RDS instances are overprovisioned?"

Security and Compliance

Use these for security reviews, audits, and catching misconfigurations before they become incidents.

• "Are there any security groups that allow inbound traffic from 0.0.0.0/0?"
• "Show me IAM users with unused access keys."
• "Which S3 buckets have public access enabled?"
• "List all open ports exposed to the internet."
• "Are any of my containers running as root?"

Planning and Change Management

Use these before making changes to understand impact.

• "What would happen if I scale the checkout service to 5 replicas?"
• "Generate a plan to add a new subnet in us-west-2."
• "Show me the downstream impact of taking the cache cluster offline."
• "What are the current resource limits on the API pods?"

Each of these queries would previously require navigating a console, composing a CLI command, or writing a script. Natural language infrastructure tools answer them in seconds.

---

Clanker Cloud: The Tool That Does This

Clanker Cloud is a desktop app that gives you a natural language interface to your entire cloud infrastructure.

What it connects to: AWS, GCP, Azure, Kubernetes, Cloudflare, Hetzner, DigitalOcean, and GitHub — from one surface. You don't switch between CLIs or browser tabs. You ask a question, and Clanker Cloud queries the right providers automatically.

Local-first by design. Your credentials never leave your machine. There is no hosted SaaS layer between you and your cloud providers. Clanker Cloud uses the credentials you've already configured — AWS profiles, kubeconfig files, GCP service accounts — exactly as your CLI tools would.

Read-first, act-second. Every query is read-only by default. Clanker Cloud gathers live context, surfaces it in a structured answer, and doesn't touch anything unless you explicitly switch to maker mode and approve a change. This makes it safe to use during an incident without fear of accidentally modifying production.

Bring your own AI keys (BYOK). Clanker Cloud does not mark up AI API costs. You bring your own OpenAI, Anthropic, or other model keys, and you pay the provider directly at cost.

One-minute setup. Install the desktop app, point it at your existing credentials, and start querying. There's no infrastructure to deploy, no agent to install in your cluster, no API keys to rotate.

Agent-managed workflows. For teams using AI coding agents like Claude Code or Codex, Clanker Cloud exposes an MCP (Model Context Protocol) interface — letting your coding agents query and operate infrastructure directly as part of automated workflows.

The open-source CLI is available at github.com/bgdnvk/clanker for those who prefer a terminal interface.

Explore the product demo, read the documentation, or check the FAQ for setup details. If you're working on a team, see how Clanker Cloud fits into collaborative workflows in the AI DevOps for teams guide. If you're a vibe coder or AI-native builder, see From Vibe Coding to Production.

---

The Gap Is Collapsing

Infrastructure management is about to feel very different.

The gap between "I know what I want to check" and "I have the answer" used to be measured in minutes — find the right CLI command, log into the right console, compose the right filter, parse the right output. That gap is collapsing to seconds.

Natural language DevOps doesn't mean infrastructure becomes less complex. It means that complexity is no longer a tax on the engineer's working memory. You ask what you want to know. You get an answer. You move on.

The engineers who figure this out early will operate faster, debug faster, and ship faster than the ones still navigating five dashboards for the same answer.

---

Frequently Asked Questions

Can you manage cloud infrastructure with natural language?

Yes. Tools like Clanker Cloud let you query AWS, GCP, Azure, Kubernetes, and other providers by typing questions in plain English. The tool translates your question into the appropriate API calls, fetches live data, and returns a grounded answer. For write operations (creating, modifying, or deleting resources), the same interface generates a change plan that you review and explicitly approve before anything is executed.

What is natural language DevOps?

Natural language DevOps is the practice of managing, querying, and operating cloud infrastructure using plain English instead of provider-specific CLI commands, web consoles, or custom scripts. Instead of memorizing kubectl flags or AWS CLI syntax, engineers ask questions and issue instructions in natural language. The underlying tool handles the translation to API calls and aggregates the results. Natural language DevOps tools are grounded in live infrastructure data — they don't generate generic answers from training data.

How do you query Kubernetes in plain English?

With a natural language infrastructure tool like Clanker Cloud, you connect your kubeconfig file and then ask questions directly: "Which pods in staging aren't running?", "Show me pods that restarted in the last hour," or "What's the resource usage on the API deployment?" The tool queries the Kubernetes API using your existing credentials and returns the relevant data. No kubectl command construction required.

What tools let you ask questions about your infrastructure?

Clanker Cloud is a desktop application that supports natural language queries across AWS, GCP, Azure, Kubernetes, Cloudflare, Hetzner, DigitalOcean, and GitHub from a single interface. It is local-first (credentials stay on your machine), read-only by default, and supports bring-your-own API keys for AI models. Setup takes under a minute using credentials you've already configured. The open-source CLI version is available at github.com/bgdnvk/clanker.

Is it safe to manage infrastructure with AI?

Safety depends on the tool's architecture. Clanker Cloud is safe for three specific reasons. First, it is local-first: your credentials never leave your machine and are never sent to a hosted SaaS layer. Second, it is read-first by default: queries fetch data but do not modify anything. Write operations require you to explicitly enter maker mode, review a generated change plan, and approve execution — nothing happens automatically. Third, it is bring-your-own-keys: you use your own AI provider credentials, so there is no opaque intermediary with access to your queries. The result is a tool that gives you fast answers about your infrastructure without introducing new attack surfaces or accidental change risks. See the FAQ for more on the security model.

---

Ready to query your infrastructure in plain English? Download Clanker Cloud — free, local-first, one-minute setup.