Cloud Security Looks Different Depending on Who You Are: Startups, Enterprises and Quantum Teams

 

Security sits between your workloads and the people trying to reach your data

A ten-person startup and a bank with fifty thousand employees have very little in common, but attackers treat them the same way: as a list of open doors. A forgotten storage bucket, a reused password or an unpatched server is enough, and size doesn't change that.

What does change is what each team needs from a security provider. And there's a third group that's only now starting to ask the question, the people working with quantum computing. Here's how we see each of them.

We'll cover what the main services do, what each group should prioritise, and which questions to ask a provider before you sign.

The services behind the buzzwords

Most security offerings boil down to six things. It helps to know what they actually are before you start comparing vendors.

Managed SOC / MDR	A team watching your systems around the clock and acting when something looks wrong.
Vulnerability & pen testing	Friendly attackers who find the holes first and tell you how to close them.
Identity & zero trust	MFA, least-privilege access, and checking every login instead of trusting the network.
Encryption & key management	Data scrambled at rest and in transit, with keys that stay under your control.
WAF & DDoS protection	Filters that keep malicious traffic away from your apps and keep you online.
Compliance, backup & DR	Audit readiness (ISO 27001, SOC 2, India's DPDP Act) and recovery plans that have actually been tested.

None of these works well alone. A SOC with no identity controls is watching a door that's already unlocked, and encryption without tested backups protects data you may not be able to recover. A good provider makes the pieces work together instead of selling each one as a separate product.

How a managed SOC actually works

The phrase "24×7 monitoring" hides a fairly simple loop. Logs from your cloud accounts, laptops and login systems flow into one place. Analysts, helped by automation, sort the genuine threats from the daily noise. When something is real, they contain it, and then they help you fix whatever let it in.

One distinction is worth knowing. A basic monitoring service sends you an alert and leaves the rest to you. A managed detection and response (MDR) service acts on your behalf, for example by isolating a laptop, disabling a compromised account or blocking a malicious address. Ask which one you're buying, because at 3 a.m. the difference matters.

There's a regulatory angle in India as well. CERT-In directions expect certain cyber incidents to be reported within six hours of being noticed. That's hard to meet if nobody was watching in the first place.

Startups: get the basics right early

Nobody joins a startup to think about security policies. Fair enough. But the cost of skipping it shows up at awkward moments, usually when a large customer sends over a 200-question security form, or when someone's laptop gets phished.

You don't need a big budget to avoid most of the pain. Turn on MFA and single sign-on everywhere. Run automated checks on your cloud setup so a public bucket gets flagged the same day. Keep production access limited to the few people who really need it. Then rent your security monitoring instead of hiring for it. A managed service costs a fraction of a full-time team, and you can scale it up as you grow.

Compliance is worth starting sooner than feels natural. A SOC 2 or ISO 27001 report can be the difference between closing an enterprise deal this quarter and waiting six months.

The goal isn't to look like a big company. It's to avoid being the easy target.

A sensible order of operations

The trick is sequencing. Start with the controls that remove the most risk for the least effort.

 A startup security roadmap: small steps, in order

• Week 1: identity first. Enforce MFA and single sign-on on email, code repositories, cloud consoles and the admin panel of every SaaS tool. A large share of account takeovers end here.
• Month 1: see your cloud. Turn on automated posture checks so public storage, open ports and over-generous permissions are flagged the day they appear.
• Month 3: add monitoring. Send logs from your cloud, laptops and identity provider to a managed service, so someone is watching while your team sleeps.
• Month 6: collect proof. Write down the policies you actually follow, gather evidence and begin a SOC 2 or ISO 27001 audit.

Mistakes we see most often

• Secrets such as API keys and database passwords committed to code repositories.
• Shared admin accounts, which make it impossible to say who did what.
• Access that is never removed when someone leaves or changes role.
• Backups that exist but have never been restored as a test.

Enterprises: the hard part is seeing everything

Big organisations rarely lack security tools. They usually have too many. Workloads sit across two or three clouds and an old data centre, thousands of people hold access they've forgotten about, and every vendor in the supply chain is one more way in.

Layered defence: if one layer fails, the next one is still there

So the work is mostly about consistency. A 24×7 SOC fed by a proper SIEM, tight control over privileged accounts, data loss prevention where the sensitive data lives, and regular red-team exercises to test whether any of it holds up. Add data-residency rules and sector regulations, and a provider with local infrastructure and local compliance experience starts to matter a lot.

Zero trust, without the slogan

"Zero trust" has been stretched to cover almost anything, but the core idea is simple: being inside the network no longer earns trust. Every request, from a person or a service, is checked for who is asking, whether their device is healthy and whether the request looks normal, and then gets only the access that task needs.

Zero trust: every request is checked, every time

Suppliers are part of your attack surface

Many serious breaches begin with a supplier, not with the company that was ultimately hit. A payroll vendor, a software library or a managed service provider can all become the way in. Enterprises need a consistent way to assess suppliers before onboarding, limit what each one can reach, and keep watching after the contract is signed.

Measure what matters

Security leaders often struggle to explain their work to a board because the usual output is a list of tools. A few plain numbers tell a clearer story:

• Time to detect and time to respond to real incidents, in hours or minutes.
• Time to patch critical vulnerabilities on your most important systems.
• Share of privileged accounts protected by strong MFA and reviewed regularly.
• Time to revoke access when someone leaves, ideally the same day.

Regulation shapes the architecture Data-residency rules and sector regulation aren't paperwork added at the end. They decide where workloads can run and who may touch the data. In India, the DPDP Act sits alongside sector requirements from regulators such as the RBI and SEBI, and a cross-border design that ignores them can be expensive to unwind. This is where a provider with local infrastructure and local compliance experience earns its fee.

Quantum computing users: two problems, one of them urgent If you run quantum workloads, or work in a field that will soon depend on them, security splits into two separate questions.

Post-quantum cryptography is designed to hold up against quantum attacks

The data someone may be stealing right now

Today's encryption would be breakable by a large enough quantum computer. Such machines don't exist yet, but that hasn't stopped attackers from copying encrypted data now and keeping it for later. Security people call this "harvest now, decrypt later." If your data needs to stay private for ten or twenty years, such as research IP, patient records or financial history, it's already in scope. NIST has published its first post-quantum standards (ML-KEM, ML-DSA and SLH-DSA), which means there's something concrete to plan around.

Harvest now, decrypt later: the data is taken today, the damage comes later

The NIST standards are published as FIPS 203, 204 and 205. ML-KEM handles key exchange, which is how two systems agree on a shared secret. ML-DSA and SLH-DSA handle digital signatures, which prove who sent something and that it wasn't altered. Those two jobs, key exchange and signatures, are what most of today's public-key cryptography does, and both need replacing over time. Symmetric encryption such as AES-256 is far less affected.

The quantum work itself

Circuits, algorithms and results are valuable and often unique. When they run on shared cloud hardware, they need the same care as any crown-jewel asset: strong identity controls, isolated environments, encrypted storage and a clear audit trail.

• Strong identity for every account that can submit jobs or read results, with MFA and short-lived credentials.
• Isolated environments so one project or team can't see another's circuits and data.
• Encrypted storage for circuits, parameters and results, with keys you control.
• Audit trails showing who ran what, when and from where.
• Clear contracts on how long your hardware provider keeps job data and who can access it.

A sensible first step is unglamorous. Make a list of where your organisation uses cryptography, flag the data that has to stay secret for years, and make sure your systems can swap algorithms without a rebuild. Many teams begin with hybrid setups that combine classical and post-quantum encryption.

Four steps toward post-quantum readiness

Hybrid setups hedge both ways. If a new algorithm turns out to be flawed, the classical layer still protects you, and if quantum machines arrive early, the new layer does. Major browsers and cloud providers already deploy hybrid key exchange, so the tooling is maturing.

At a glance: what each group should focus on

The three groups face the same attackers but need different things first. This table sums up where we'd start.

	First priority	Biggest risk	Best-fit services
Startups	MFA and SSO, cloud posture checks, an early start on compliance	Easy mistakes: a public bucket, a phished login	Managed SOC / MDR, compliance support, vulnerability scanning
Enterprises	Visibility and consistency across clouds, data centres and suppliers	Sprawl, forgotten access and weak links in the supply chain	24×7 SOC with SIEM, privileged access control, red-team testing
Quantum teams	A cryptography inventory and protection for the quantum workloads	Harvest now, decrypt later, and exposure of unique research	Encryption and key management, isolated environments, post-quantum planning

What to look for in a partner Ask how quickly they respond to an incident, and get the answer in minutes or hours, not "promptly." Check which compliance frameworks they've actually been audited against, and where your data physically sits. Make sure they can serve a small team today without forcing you to switch when you grow. And ask what their post-quantum plan is. If the answer is a blank look, that tells you something.

Five questions to ask any security partner

Red flags worth noticing

• Vague answers such as "promptly", "industry standard" or "best effort" where you asked for a number.
• Compliance claims with no audit report you can actually read.
• No clear answer on where your data is stored or who can access it.
• A post-quantum plan that amounts to "we're watching the space".

To wrap up Security isn't something you finish. It changes as you grow, as attackers adapt and as technologies like quantum computing mature. Startups need a solid foundation, enterprises need clarity across a sprawling estate, and quantum teams need to protect both today's data and tomorrow's cryptography. The common thread is to start earlier than feels necessary.
The blog is written by Anirudhha Puranik (Lead Cloud Ops @ Cloud.in)

Managed Cloud Services at Every Stage: Startups, Enterprises and Quantum Teams

Introduction

Getting onto the cloud isn't the difficult part anymore. The harder part is running it day after day: keeping it secure, keeping the bill under control, and not wearing out your best engineers in the process.

Picture a two-person startup shipping its first product, a global enterprise with thousands of workloads, and a research group trying out quantum algorithms. On paper they have almost nothing in common. But all three run into the same wall: keeping infrastructure healthy eats the time that should go into the work that sets the business apart.

That's the gap managed services fill. Rather than building and staffing every operational function yourself, you hand the daily cloud operations to a specialist partner and put your own people on products, customers or research.

What Managed Services Actually Cover

A decent managed services engagement is a lot more than someone keeping an eye on the console. It's a full operating model, and it usually includes the following:

• 24x7 monitoring and incident response: alerts that fire before customers notice, and people who triage and fix problems instead of scrambling after the fact
• Security and compliance operations: IAM clean-up, patching, threat detection and staying ready for audits
• Cost optimization (FinOps): rightsizing, savings plans, budgets and anomaly alerts
• Backup and disaster recovery: backups that have actually been restored in a test, not just ones that are switched on
• Automation and Infrastructure as Code: environments you can rebuild the same way every time, with changes tracked in version control
• Architecture reviews and continuous improvement: regular check-ins against the AWS Well-Architected Framework

How much each of these matters depends on who you are, so here are three very different cases.

1. Startups: Move Fast Without Building an Ops Team

When you're a startup, speed is what keeps you alive. Every hour an engineer spends patching servers, tuning alarms or working out why the bill suddenly doubled is an hour the product doesn't get.

What startups usually run into:

• Nobody owns DevOps or security, and there's no budget to hire a team for it
• Cloud bills that grow faster than anyone planned for
• Investors and customers asking security questions long before any security program exists
• Quick architecture decisions that turn out to be expensive to reverse

Where managed services help:

• Monitoring, alerting and on-call cover from day one, with no hiring needed
• A landing zone and account structure done properly early on, so there's no painful rebuild later
• Budgets, tagging and anomaly alerts, so the finance team isn't caught off guard as usage grows
• A security baseline that takes the sting out of the first customer questionnaire or audit
• Engagements that flex with the company instead of tying it to big fixed commitments

The aim is easy to state. Keep the team small, keep shipping, and make sure the foundation can handle ten times the load when growth arrives.

2. Enterprise: Reliability, Governance and Scale

Enterprises have the reverse problem. Money and people are rarely the issue; complexity is. There are many accounts, plenty of teams, legacy systems nobody wants to touch, strict compliance rules and almost no patience for downtime.

What enterprises usually run into:

• Sprawl across accounts and regions, with every team following slightly different standards
• Compliance obligations such as ISO 27001, SOC, PCI DSS or industry-specific regulation
• Skills gaps, and the sheer difficulty of staffing a real 24x7 operations team internally
• Pressure to modernize while the existing systems have to stay up
• Shadow spend, and little accountability for cost across business unit

Where managed services help:

• Central governance through landing zones, guardrails and policy-as-code across accounts
• Round-the-clock operations with defined SLAs, escalation paths and reporting people can actually read
• Security operations that either plug into the enterprise's own SOC or extend it, covering detection, response and posture management
• Structured change and patch management, which cuts down on unplanned outages
• FinOps practices that give every business unit visibility into what it spends
• Resilience planning: backup strategy, disaster recovery design and regular testing

Enterprises rarely want to replace their internal teams, and they shouldn't. Staff keep ownership of strategy and architecture while the partner carries the day-to-day operational load.

3. Quantum Computing Users: Managing a Very Different Kind of Workload

Quantum computing is still young, yet the people working in it already have real operational needs. That includes research labs and universities as well as startups and enterprise innovation teams. Most quantum workloads aren't purely quantum either. They're hybrid: classical compute prepares the data, a quantum processor or simulator handles one part of the problem, and classical compute picks up the results to analyze them.

On AWS, Amazon Braket is the service that usually comes into play here. It gives you access to simulators and to quantum hardware from several providers through a single service. Getting good results from it still leans heavily on ordinary classical cloud discipline.

What quantum users usually run into:

• Cost control: quantum processor tasks and big simulator runs are billed per task, per shot or per minute, so experiments can add up fast
• Hybrid workflow orchestration: coordinating classical pre- and post-processing around the quantum jobs, often in iterative loops
• Access and data governance: research data and proprietary algorithms still need identity controls, encryption and audit trails
• Reproducibility: you have to be able to trace an experiment back to the code, device, parameters and results behind it
• Skills: researchers want to work on algorithms, not cloud plumbing

Where managed services help:

• Setup and automation of secure accounts, notebooks, storage and networking for quantum experiments
• Budgets, alerts and usage reporting, so a long-running experiment doesn't turn into a surprise invoice
• Least-privilege access and audit logging, so researchers and outside collaborators can share resources safely
• Support for the classical half of hybrid workloads, including scalable compute, storage and data pipelines for pre- and post-processing
• Monitoring and operational support, so researchers can spend their time on the science
• Quantum-readiness planning for enterprises, including post-quantum cryptography as part of the long-term security roadmap

Quantum users don't need a separate cloud. They need the same operational discipline as everyone else, applied to a workload that is more experimental, more collaborative and a lot more sensitive to cost.

One Operating Model, Three Different Priorities

Segment	Top Priority	What Managed Services Deliver
Startups	Speed and lean operations	Ready-made ops, security baseline, cost guardrails
Enterprise	Reliability, governance, compliance	24x7 operations, SLAs, centralized controls, FinOps
Quantum users	Cost control and research focus	Secure hybrid environments, budgets, access governance

How to Choose the Right Managed Services Partner

Whichever group you belong to, a handful of questions will tell you whether you're getting a real partner or just a ticket queue:

• Do they own outcomes such as uptime, cost and security posture, or do they only respond to tickets?
• Is support backed by SLAs, with clear escalation and reporting that's open about problems?
• Do they optimize proactively, with regular reviews that bring cost and risk down over time?
• Can they show real security and compliance experience in your industry?
• Do they understand where you are, whether that's startup agility, enterprise governance or experimenting with emerging tech?
• Will they be able to grow with you as your needs change?

Best Practices to Get the Most from Managed Services

• Agree on what success means (uptime, cost, security) before the engagement starts
• Keep architecture ownership in-house and let the partner own operational execution
• Go through cost and security reports on a regular schedule, not just after something breaks
• Make automation and Infrastructure as Code the default from the start instead of a later upgrade
• Revisit the engagement whenever the business grows or the workloads change

Conclusion

Startups need to keep moving without building an operations department. Enterprises need complex environments that run reliably, stay secure and meet compliance requirements. Quantum teams need a controlled, cost-aware base so researchers can get on with discovery.

The goals differ but the answer is the same. A strong managed services partner turns cloud operations from a distraction into something you can depend on. Teams that get this right spend less time looking after infrastructure and more time on what matters to them, whether that's a first product, a global platform or the next quantum breakthrough.

The blog is written by Aditya Mandhare, Sr. Cloud Engineer@ Cloud.in

Responsible AI in Healthcare: Building Trust and Compliance with AWS

Introduction

AI is transforming healthcare through faster diagnosis, personalized treatment, predictive analytics, medical imaging, drug discovery, and operational automation. However, healthcare AI must address privacy, security, fairness, explainability, governance, and regulatory compliance while protecting sensitive patient information.

AWS provides a broad set of AI, healthcare, security, governance, and compliance services to support Responsible AI across the complete lifecycle—from secure data ingestion and model development to monitoring, governance, and audit.

Responsible AI Architecture for Healthcare

 

1. Edge and Application Security

Protect internet-facing healthcare applications using:

• Route 53 – resilient DNS and health checks
• CloudFront – secure content delivery
• WAF – protection against web exploits and malicious requests
• Shield Advanced – DDoS protection

2. Secure and HIPAA-Ready Foundation

Healthcare workloads require strong isolation, encryption, and access controls:

• Artifact – supports HIPAA eligibility through the AWS BAA
• VPC / PrivateLink – private and isolated connectivity
• KMS – encryption and key management
• Secrets Manager – secure credential storage and rotation

3. Patient Data Protection

Bedrock Guardrails helps protect sensitive healthcare information by:

• Detecting and filtering sensitive information and PHI
• Blocking unsafe content and prompt injection attempts
• Supporting contextual grounding
• Logging guardrail actions through CloudTrail

4. Healthcare Data Foundation

HealthLake stores healthcare data using the FHIR R4 standard and supports standardized clinical information such as diagnoses, medications, laboratory results, and patient history. CloudTrail provides visibility into data access.

5. Grounded Generative AI with RAG

Bedrock Knowledge Bases enables Retrieval-Augmented Generation (RAG) by indexing trusted healthcare content and retrieving relevant information during inference. Contextual grounding helps ensure responses are supported by trusted sources and reduces hallucinations.

6. Secure AI Agents

For agent-based healthcare workflows, Bedrock AgentCore provides:

• Encrypted session isolation
• Role-based access
• Fine-grained tool authorization
• Observability and execution logging

7. Governance, Monitoring and Compliance

AWS supports continuous monitoring and auditability through:

• CloudTrail – API and activity logging
• S3 Object Lock – protected audit-log storage
• Athena – audit-log analysis
• CloudWatch – operational monitoring
• GuardDuty – threat detection
• Security Hub – centralized security and compliance findings

Healthcare Data Governance

Responsible AI depends on trustworthy and well-governed data. AWS services support:

• Secure data ingestion and storage
• Data classification and PHI discovery
• Data lineage and cataloging
• Fine-grained access control
• Centralized governance

Key services include S3, Glue, Glue Data Catalog, Lake Formation, Macie, IAM, Organizations, DataSync, AppFlow, and Transfer Family.

Privacy and Security

Patient information can be protected using multiple security layers:

• Encryption: KMS, S3 Encryption, EBS Encryption
• Identity: IAM, IAM Identity Center
• Network Security: VPC, PrivateLink, Security Groups, Network ACLs
• Threat Detection: GuardDuty, Security Hub, WAF, Shield

AI Model Development and Explainability

SageMaker supports the ML lifecycle, including data preparation, training, experimentation, model registration, and deployment.

SageMaker Clarify helps evaluate bias and explain model predictions through:

• SHAP values
• Feature importance
• Bias detection
• Fairness metrics
• Continuous monitoring

SageMaker Model Cards support model documentation and governance.

Generative AI and Healthcare-Specific Services

Bedrock enables healthcare use cases such as:

• Clinical note and discharge summarization
• Medical Q&A
• Healthcare assistants
• Patient communication
• Research support

Healthcare-specific AWS services include:

• Comprehend Medical – extracts conditions, medications, procedures, and PHI from clinical text
• Textract – extracts information from medical and insurance documents
• Transcribe Medical – converts clinician speech into medical transcripts
• HealthLake – creates standardized, AI-ready healthcare data

Continuous Monitoring and Compliance

Responsible AI requires continuous monitoring for model drift, bias, accuracy, data quality, latency, security, and configuration changes.

AWS services include:

• SageMaker Model Monitor
• CloudWatch
• EventBridge
• CloudTrail
• Config
• Audit Manager
• Artifact

These capabilities support compliance with standards and regulations such as HIPAA, HITRUST, GDPR, ISO 27001, SOC, and PCI DSS.

Resilience and Disaster Recovery

Healthcare workloads require reliable backup and recovery using:

• Backup
• S3 Versioning
• S3 Glacier
• EBS Snapshots
• RDS Backups

These support automated backups, immutable storage, long-term retention, and cross-region recovery.

Responsible AI Best Practices

• Encrypt sensitive healthcare data at rest and in transit.
• Apply least-privilege access controls.
• Use standardized healthcare formats such as FHIR.
• Document models and AI behavior.
• Assess and continuously monitor bias.
• Provide explainable AI outputs for clinical users.
• Monitor model performance and drift.
• Maintain comprehensive audit trails.
• Protect internet-facing AI applications.
• Automate compliance, backup, and recovery processes.

Key Benefits

AWS enables healthcare organizations to build Responsible AI solutions with:

• Secure and scalable healthcare data management
• Healthcare-specific AI capabilities
• Explainable and fair AI
• Strong privacy and security controls
• Centralized governance and auditability
• Continuous monitoring
• Automated compliance
• Resilient and scalable infrastructure
• Managed services that reduce operational complexity

Conclusion

Responsible AI in healthcare requires more than accurate models. It requires secure data management, privacy, explainability, fairness, continuous monitoring, governance, and regulatory compliance.

AWS provides an integrated ecosystem—including HealthLake, SageMaker, Bedrock, Bedrock Guardrails, Security Hub, GuardDuty, CloudTrail, and Audit Manager—to help healthcare organizations build AI solutions that are secure, scalable, trustworthy, and aligned with regulatory expectations.

The blog is written by Vimal Pal, Cloud Solutions Architect, Cloud.in

The CDN is Becoming Part of the Application and AI is Accelerating That Shift

For twenty years we asked how fast the CDN could deliver a response. The better question now is how much of the response the application should ever have to compute.

The CDN is becoming part of the application — and AI is accelerating that shift

For most of its history, a CDN sat in a well-understood place on the architecture diagram:

User → CDN → Origin → Database

It cached static objects, terminated TLS closer to the user, absorbed bursts, and kept the origin from falling over. It made things faster. It did not make architectural decisions.

That framing has quietly stopped being accurate. Applications are API-driven, personalized and increasingly AI-powered, and the dominant cost is no longer bandwidth  it is compute. Application CPU, database connections, GPU time and tokens. Once that is true, the interesting question changes from how fast can we deliver this to how far into the stack does this request actually need to travel.

1. Caching is a compute-avoidance strategy, not a latency optimization

Start with something ordinary. A product image is obviously a CDN workload. But the same reasoning extends to application responses: GET /products/123 Accept: application/json

If that response is identical for a large population of users, it can be cached at the edge under a well-chosen cache key. The arithmetic is not subtle: without caching: 10,000 requests → 10,000 origin requests with caching: 10,000 requests → 1 origin request + 9,999 hits

The application did not get faster. The application did less work. That distinction matters, because what you avoid is the expensive part: request parsing, serialization, ORM overhead, connection-pool pressure, query planning, and the container capacity you provisioned to survive peak.

The engineering, though, lives entirely in the cache key and this is where most “we put a CDN in front of it” projects quietly fail:

• Normalize before you key. Sort query parameters, strip tracking parameters (utm_*, fbclid, gclid), lowercase the path where your routing is case-insensitive. An unnormalized key turns one cacheable object into thousands of near-duplicates and tanks your hit ratio.
• Vary is a multiplier, not a switch. Vary: Accept-Encoding is fine. Vary: User-Agent fragments your cache across effectively unbounded cardinality. If you need device-class variation, normalize to a small enumerated set at the edge and vary on that.
• Invalidate by tag, not by URL. Surrogate keys (Fastly), cache tags (Cloudflare, Akamai) let a single product update purge every collection page, search facet and API response that embedded it. Without them, teams default to short TTLs which is just paying for the miss in advance.
• stale-while-revalidate decouples freshness from latency. A 60-second TTL with a 600-second SWR window means the origin sees one revalidation per minute per object rather than a thundering herd at every expiry, and users never wait on it. Pair it with stale-if-error and the edge becomes a availability control as well.
• Microcaching is underrated. A 1–5 second TTL on a hot, “uncacheable” dynamic endpoint sounds pointless until you do the math: at 2,000 RPS, a 2-second TTL removes 99.95% of origin traffic. Nobody notices two seconds of staleness on a trending feed.
• Collapse the misses. Tiered caching and request coalescing mean that a cold object requested simultaneously by 500 edge locations results in one origin fetch, not 500.

None of this is new. What is new is the reason to care: at current compute prices, these are cost-control mechanisms that happen to also reduce latency.

2. Decide workload placement up front, not after the fact

The common pattern is build the application, then put a CDN in front of it. The better one is to decide, per workload, which layer is allowed to answer.

Where each workload should be answered: CDN, edge, application, database or AI layer

The point is not to cache everything. “Show me my current bank balance” is user-specific and time-sensitive; it has to traverse authentication, the account service and the database, and any cache hit there is a correctness bug. “Book seat 14A and take payment” must reach the transactional path it is not idempotent and it is not cacheable at any TTL.

But between those two extremes sits an enormous middle ground that most teams send to origin out of habit: the application shell, the product catalog, category and search-facet pages, pricing for anonymous users, configuration and feature-flag payloads, public API responses. A useful structural pattern here is edge composition serve a cached, cacheable shell to everyone and inject the personalized fragment separately, either through a second authenticated call or through an edge function that stitches identity into the response at the PoP. You get one cache entry serving millions of users instead of one per user.

The objective is not maximum caching. It is correct placement.

3. AI does not extend the cost model. It breaks it.

A conventional request has a predictable cost envelope. An AI request does not.

Traditional request path versus AI request path, and where cost concentrates

Three things change at once:

Cost stops being per-request and becomes per-token. A cached JSON response costs effectively nothing to serve again. A regenerated LLM response costs the full prefill of its context plus every decoded output token, every single time. Worse, the context is usually the expensive part . A RAG prompt carrying eight retrieved chunks can be 10–50x the length of the user’s actual question.

Latency becomes multi-modal. Total latency is now the sum of embedding, ANN search, prompt assembly, prefill and decode. Time-to-first-token is dominated by prefill, which scales with context length; total time scales with output length. Your p99 is no longer a database outlier, it is a long answer.

The pipeline has more failure modes than the thing it replaced. Vector store, embedding model, retrieval ranking, model provider, rate limits, context-window overflow.

Now consider a support assistant. "What is your refund policy?" is a stable, tenant-wide answer. Invoking a model for it thousands of times a day, identically  is pure waste. "Why was my refund rejected for order #1234?" is genuinely personalized and genuinely needs retrieval and reasoning.

The principle that falls out of this is simple to state and surprisingly hard to enforce:

Do not invoke inference when the answer can be served from cache, retrieved from a system of record, or precomputed.

A practical corollary: separate prompt caching from semantic caching. Prompt caching (provider-side KV-cache reuse of a shared prefix) cuts prefill cost when many requests share a long system prompt or document. Semantic caching skips the model entirely. They compose well, and teams routinely conflate them.

4. From cache keys to semantic cache keys

Traditional caching asks a syntactic question: is this URL, with this request context, cacheable? AI introduces a semantic one.

These three prompts are different strings with one intent:

“What’s your refund policy?” “Can I get my money back if I cancel?” “What are the rules for getting a refund?”

A URL-keyed cache sees three distinct requests and pays for three generations. A semantic cache embeds the normalized prompt, runs an approximate-nearest-neighbour lookup against previously answered prompts, and reuses the stored response when similarity clears a threshold.

Semantic cache decision flow and the guardrails the cache key must carry

The economics are compelling — an embedding call is orders of magnitude cheaper than a generation — but the failure mode is qualitatively different from a traditional cache miss. A stale object is late. A false semantic hit is confidently wrong, and it looks exactly like a correct answer.

That means the guardrails are not optional:

• Scope is part of the key. Tenant, user entitlement, locale, and plan tier. “What’s my refund policy” means different things to a B2B account and a consumer one. A semantic cache that ignores scope is a cross-tenant data leak with extra steps.
• Version the corpus. If the underlying policy document changes, every cached answer derived from it is invalid. Tag cache entries with source-document versions and purge by tag — the same discipline as surrogate keys, applied to generated content.
• Version the prompt and model. Change the system prompt or swap the model and your cached responses no longer represent what the pipeline would produce. Include a hash of both in the key.
• Tune the threshold against labelled data, and fail open. τ is a precision/recall dial. Too low and you serve wrong answers; too high and you never hit. Log near-misses to find where the boundary actually sits, and when in doubt, fall through to the model.
• Never cache what you cannot re-derive. Anything user-specific, time-sensitive or transactional stays out.

Done carefully, the cache stops storing content and starts avoiding computation. That is a different kind of infrastructure.

5. The edge becomes a decision point

Put those layers together and the request path stops being a straight line. It becomes a sequence of escalating questions, each one more expensive to answer than the last.

The edge as a decision point: cache, edge function, application, data layer, inference

The objective is one sentence: resolve the request at the earliest layer that can correctly answer it. Not the fastest layer, not the closest — the earliest one that is still correct. Correctness is the binding constraint; cost and latency are what you optimize inside it.

6. AI traffic is also breaking assumptions the CDN itself was built on

This is the part that gets least attention and is arguably the most interesting, because it is not about what you build on top of a CDN  it is about the cache algorithms underneath it.

Cloudflare, working with researchers at ETH Zürich, published data in April 2026 showing that roughly a third of traffic across their network is automated, and that AI crawlers account for about 80% of self-identified AI bot traffic. The behavioural profile is nothing like a human’s:

• High unique-URL ratio. Human traffic is Zipfian a small set of popular pages carries most requests, which is exactly the distribution LRU was designed for. AI crawlers perform sequential full-site scans, and in modelling of iterative RAG loops the unique-access ratio sits between 70% and 100%.
• No session reuse. Crawlers do not use browser caching, and multiple independent instances each appear as a fresh visitor requesting the same content.
• Crawling inefficiency. A meaningful fraction of fetches from popular crawlers end in 404s or redirects.

The consequence is cache pollution. Long-tail objects that would previously have been evicted get pulled in repeatedly, displacing the popular content human users depend on. Measured hit rate at a single CDN node drops when AI crawler traffic is included, and the standard mitigations — prefetching, cache speculation — get less effective, not more, because there is no locality to predict.

The proposed responses are genuinely architectural. First, replacing LRU for mixed traffic: early experiments suggest eviction policies like SIEVE or S3-FIFO let human traffic hold its hit rate whether or not crawlers are present. Second, and more radically, splitting the cache by traffic class — human traffic served from latency-optimized edge caches, interactive AI traffic (RAG, live summarization) from higher-capacity tiers that tolerate slightly more latency, and bulk training crawls pushed to deep origin-side tiers or queue-admitted and deferred when the infrastructure is under load.

That is a real-world example of a production system where the eviction policy is now a function of who is asking.

7. What the platforms have actually shipped

This is not speculative roadmap material. All three major platforms moved in 2026.

What Akamai, AWS CloudFront and Cloudflare shipped in 2026

Akamai — inference placement as a routing problem. In March 2026 Akamai launched AI Grid intelligent orchestration as part of its Inference Cloud, described as the first global-scale implementation of NVIDIA’s AI Grid reference design. It routes inference across more than 4,400 edge locations plus regional and core GPU capacity, with a workload-aware control plane brokering requests in real time against cost-per-token, time-to-first-token and throughput. Semantic caching and WebAssembly-based serverless compute (EdgeWorkers, Akamai Functions) sit at the edge tier; multi-thousand-GPU Blackwell clusters handle heavy multi-modal and post-training work at the core. The architectural claim is that where inference executes is now a runtime decision, not a deployment-time one.

AWS — the edge as an AI traffic control plane. AWS WAF shipped an AI activity dashboard in February 2026, with Bot Control detection now covering more than 650 distinct bots and agents across categories like AI search crawlers, data collectors and LLM training crawlers. In June it went further with AI traffic monetization: a Monetize rule action that returns HTTP 402 with pricing and accepted payment networks, verifies the agent’s signed payment authorization at the CloudFront edge, then fetches and serves the content — settlement handled by a third-party facilitator. Whatever you think of micropayments, the significant part is architectural: identify, classify, rate-limit, charge and serve, all before the origin is involved.

Cloudflare — convergence of CDN, edge compute and AI gateway. AI Gateway provides caching, rate limiting, model routing, fallback and observability in front of providers including Workers AI, OpenAI, Anthropic and Google, with per-request cache control via headers like cf-aig-cache-ttl. Workers AI runs models on the network itself, Vectorize provides the vector store, and AI Crawl Control and Pay Per Crawl handle the policy side. The stack has effectively merged: CDN + edge compute + AI gateway + inference, behind one control plane. 8. The progression

CDN 1.0 through CDN 5.0

Not every application needs CDN 5.0. Most need CDN 2.0 done properly, which is a more useful observation than it sounds — plenty of teams running on modern platforms have never tuned a cache key. The point of the progression is not a maturity model to climb. It is that the boundary between CDN, application and AI infrastructure has become fluid, and an architecture that treats those as three separately-owned tiers will leave both latency and money on the table.

9. The questions worth asking at design time

The architect’s checklist

Run these in order, and stop at the first layer that can answer correctly:

1. Can the edge answer this? If yes, it never reaches the origin.
2. Can it be cached or precomputed? If yes, do not recompute it per request.
3. Does it need application logic? If not, keep it at the edge.
4. Does it actually need inference? If not, do not invoke a model.
5. If inference is required, where should it run? Edge, regional or core — driven by latency budget, model size and GPU memory footprint.
6. Who is consuming this? Human, crawler, or agent — and should they get the same response, the same cache tier, and the same price?
7. What can move closer to the user without becoming incorrect? Correctness first, then cost, then latency.

The goal was never to push everything to the edge. It is to minimize unnecessary movement and computation across the whole architecture.

The CDN of the AI era is not a faster path to the application. It is becoming part of the application — deciding what gets delivered, what gets cached, what reaches the origin, what traffic gets controlled or charged, and increasingly, where computation and inference should happen at all.

The blog is written by Swapnil Vaidya (Lead Cloud Solutions Architect @ Cloud.in)