Tag Archives: Featured

Making the Backblaze Network AI Ready

Post Syndicated from Brent Nowak original https://www.backblaze.com/blog/making-the-backblaze-network-ai-ready/

An illustration of a chip with AI written on it.

AI isn’t just reshaping how data is processed—it’s rewriting how data moves. Behind every training run or inference pipeline is a torrent of data, and how efficiently (or not) that data travels through networks (and whether it’s an AI-ready network) can make or break performance. 

Data workloads have massively evolved over the 18 years we’ve been in business from computer backups to exabyte-scale storage to AI data pipelines. And that has implications for not just our storage hardware, but our network. 

What started as a single ISP serving a few racks in the early days has grown into a global, multi-terabit backbone connecting customers, compute, and storage in real time via multiple Tier 1 carriers, Internet Exchanges, and PNI links. 

So why talk about it now? Because AI is testing the limits of every part of the infrastructure stack—and the network is where those limits are most visible. Running an AI-ready network means rethinking how you design, route, and scale traffic to handle not just more data, but faster, more synchronized, and more resilient data movement than ever before.

In this post, I’m talking about how our network has evolved to support AI workflows, including what’s changed under the hood, how we’re adapting our hardware and architecture, and what that means for the way data moves through Backblaze today.

Go with the flow

The Network Engineering (NetEng) group at Backblaze is responsible for the design, implementation, and support of our physical network—everything from the physical copper and fiber cables inside our datacenters to the routers and switches that connect our storage to the world.

When we talk about network traffic, we often refer to a “flow”—a stream of information sent between two or more parties. Downloading a file? That’s a flow between your computer and the server offering the file. Multiple small requests loading a website (text, formatting code, animation code, etc.)? Those are known as “mouse” flows. Massive dataset transfers that sustain hundreds of gigabits per second? Those are “elephant” flows. 

The elephant in the room

AI workloads are the largest “elephant” flows our network has ever sustained. These aren’t just big files, they’re ecosystems of data: multi-petabyte datasets, hundreds of thousands of objects ranging from a single megabyte to hundreds of megabytes per object, and thousands of simultaneous connections working in parallel.

Moving these data sets around is no small task. It means engineering for sustained, lossless throughput. It’s cutting edge, using many machines to perform parallel operations, all at large transfer rates. Let’s say we’re the source of a dataset that is being transferred to a neocloud for processing, the processing layers (often GPUs) want a continuous stream of high bandwidth with no loss. And a single dropped packet in a training pipeline can trigger expensive re-requests, idle GPUs, and cascading slowdowns. 

With that in mind, we’ve evolved our infrastructure from traditional cloud networking—designed for smaller flows—to handle the relentless firehose of AI data.

Traditional cloud vs AI cloud

AI changes everything about traffic behavior. It doesn’t just mean that our total capacity is bigger, but also that our considerations for how we design, support, and scale our infrastructure morphed along with our capacity upgrades.

Here’s a quick overview of the former challenges and the new ones we’re engineering to serve our AI workflows.

Traditional Cloud Network AI Cloud Network
Small to large flow sizes (megabits to, gigabits) Very large flows (multi-gigabit to terabit)
High entropy flows (many sources and destinations) Low entropy flows (consistent source/destination pairs)
Predictable usage patterns Burst traffic patterns
Tolerant to failures Sensitive to faults, buffering, congestion

In short: AI traffic is heavier, stickier, and far less forgiving. So the goal is to design networks that can transfer 100Gbps, 200Gbps, and up to 1,000 Gbps (1 Terabit) a second with a low latency, low jitter, and a zero loss profile. Simple right? 

Hardware network upgrades

To meet these new demands of AI workflows, we’ve upgraded nearly every layer of our physical infrastructure. We needed to increase the density of our networking hardware, deploy denser fiber optic solutions, and upgrade the capacity of our edge network.

What technologies are we deploying?

1. Transitioning from NRZ to PAM4 Optics

The fiber optic modules that are used to connect all our infrastructure hardware (servers, switches, routers) have been transitioned to modules that support a denser encoding method. Both NRZ and PAM4 are technologies used to modulate signals. Think of NRZ as a one-lane highway with one passenger per car. PAM4 adds three more passengers per car, doubling the rate without doubling lanes and with controllable cons such as increased noise sensitivity. By using four voltage levels instead of two, PAM4 transmits twice the information per signal change, effectively doubling bandwidth per fiber strand.

2. MTP-8 and MTP-16 Fiber

MTP is a fiber connector type and the number after denotes the number of fiber optic strands contained within the cable. The higher the number, the more fiber pairs in the cable. We’ve used MTP-8 for years (four pairs of fiber), but to handle AI-scale traffic, we’re now deploying MTP-16 for higher-density connections. That means where we once ran 100G links, we now run 400G—and can scale up to multiple 100G paths as workloads grow (4x100G, 8x100G, etc).

3. Expanding edge and core capacity

We’ve refreshed routers and switches to handle higher port speeds and density—moving from 100G to 400G interfaces across our interconnects. The result: higher aggregate throughput and better fault isolation for massive parallel transfers.

Visualizing an AI workflow

Our monitoring tools track network flows (TCP conversations) in real time, giving us visibility into how large AI workflows move across the infrastructure. We use this type of information to monitor and make sure that large workflows are distributed across our physical infrastructure to allow for traffic balancing.

So, what does a large “AI workflow” look like? It’s not one device talking to one device at a high rate, but rather a collection of actors all working together.

On our side, our API layer speaks to our storage layer, requesting the files. Once the files are retrieved from our storage layer, they flow through our API servers and are then sent to a destination. In order to achieve a high throughput, many API servers talk to many destination servers. 

A typical 200+ Gbps transfer (diagrammed below) might involve four API virtual IPs (VIPs), each hosted on multiple backend servers sending 5–7 Gbps to ten destination nodes for a total output of 52Gbps from each API server. On the receiving side, each destination server might be ingesting 20Gbps across multiple streams.

The key insight: AI data transfer isn’t one big pipe—it’s a distributed mesh of many coordinated streams. Our design scales linearly—add more API servers, add more destination nodes, and the flow grows predictably without congestion or packet loss.

Conclusion 

AI workflows have redefined what “fast” means on the network. At Backblaze, we’ve evolved from a single-ISP startup to an AI-scale infrastructure provider by continuously pushing the boundaries of connectivity, throughput, and reliability.

As our customers push the frontiers of AI, we’ll keep tuning the invisible layer that makes it possible: the AI-ready network.

The post Making the Backblaze Network AI Ready appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Why CoreWeave’s Object Storage Launch is Good for AI—and Everyone Building It

Post Syndicated from Maddie Presland original https://www.backblaze.com/blog/why-coreweaves-object-storage-launch-is-good-for-ai-and-everyone-building-it/

A decorative image showing cloud storage and AI icons.

CoreWeave just launched their own AI Object Storage. Our take? We love to see it. 

At first glance, it might look like a competitive offering, but as far as we’re concerned, the more storage options out there, the better for builders. It’s another sign that object storage has officially arrived as a key ingredient in the AI stack. 

Now, your AI stack can look like this: Fast, flexible storage close to your GPUs from CoreWeave (essential for training and inference). And when the run’s over? Move it to Backblaze B2 Overdrive to keep it ready for your next run at the right temperature and price-to-performance ratio.

More options mean more ways to build smart, cost-efficient pipelines that let teams train faster and iterate more without getting locked in. We’ll always cheer for that. 

Why object storage is essential for AI workloads

How do you balance scalability with performance while staying on budget? This ebook explores how object storage enhances every stage of the pipeline from collection to training to deployment, and provides real-world use cases.

Get the Ebook

Why object storage matters in the AI stack

Every AI model depends on moving massive datasets through training, inference, and retraining cycles. Each stage requires fast, reliable access to data. That’s where object storage comes in.

Object storage enables this by offering:

  • Elastic scalability for petabyte-scale data.
  • Reliability and durability across long model lifecycles.
  • Lifecycle management features to balance cost, performance, and accessibility.

As AI projects scale, smart data management becomes just as important as GPU performance. High-end GPUs can only deliver full value when they’re continuously fed the right data at the right time. When data sits in the wrong tier or takes too long to retrieve, compute resources go underused. And that means wasted time and money.

Balancing performance and cost in AI workloads

CoreWeave’s Local Object Transport Accelerator (LOTA) delivers up to 7GB/s throughput per GPU, helping data move quickly between storage and compute. With pricing around $110 per terabyte (about $60 with discounts) and regional capacity up to 10TiB, it’s built for performance-critical workloads where proximity to GPUs makes a measurable difference.

Its launch adds more choice to the ecosystem and highlights the growing demand for storage built specifically for AI. As more specialized options emerge, organizations are thinking carefully about how to right-size their infrastructure for each stage of the AI lifecycle.

When maximum performance is the goal, GPU-adjacent storage like CoreWeave’s can help teams squeeze out every last bit of speed during intensive training cycles. But for most AI workloads, B2 Overdrive provides the right balance of cost and performance. It offers the throughput and durability needed to support active training while keeping pricing predictable and scalable.

Many AI builders combine these strengths through a multi-cloud setup. Teams might use CoreWeave Object Storage when latency and proximity to GPUs deliver measurable gains, and then keep the rest of their AI pipeline on B2 Overdrive so datasets remain readily available for retraining, testing, or deployment.

Example configuration:

  • CoreWeave Object Storage for specialized, compute-intensive training where every millisecond counts. It’s ideal for short bursts of high-throughput processing, such as large-scale model fine-tuning or time-sensitive inferencing.
  • B2 Overdrive for the broader AI workflow, including day-to-day training, staging, versioning, and long-term dataset management. It provides the performance needed for ongoing model development while keeping data costs predictable and accessible across teams and environments. 

B2 Overdrive offers: 

  • Storage at roughly $15 per terabyte
  • High throughput and rapid access for post-training workflows
  • Simple APIs and event notifications to automate data movement across environments

This kind of architecture gives teams the freedom to use each platform where it shines. Backblaze handles the heavy lifting for most workloads, while CoreWeave adds targeted acceleration when raw GPU performance is the top priority. The result is a flexible, cost-aware workflow that supports both innovation and scale.

AI infrastructure that plays to every strength

The most effective AI setups use the right cloud for the right job. They run training where GPUs can perform at their peak, and store data where it stays organized and ready to move when needed.

B2 Overdrive provides a foundation for this strategy, offering a layer of object storage that keeps data secure, accessible, and easy to integrate across environments. Teams can combine each platform’s strengths to achieve speed when it’s needed, scalability that endures, and freedom from lock-in and runaway costs.

The AI ecosystem is expanding, and with the right partners, so are the possibilities.

See how Backblaze B2 Overdrive keeps AI data fast, flexible, and affordable.

The post Why CoreWeave’s Object Storage Launch is Good for AI—and Everyone Building It appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

The Hidden Cost of Cloud Storage: What 400+ IT Leaders Wish They Knew Sooner

Post Syndicated from Yev original https://www.backblaze.com/blog/the-hidden-cost-of-cloud-storage-what-400-it-leaders-wish-they-knew-sooner/

A decorative image showing pillars in multiple sizes.

Cloud storage was supposed to simplify infrastructure. Instead, it’s become one of the most unpredictable—and expensive—line items in IT budgets.

A new Dimensional Research report, commissioned by Backblaze, reveals that 95% of organizations experience unexpected cloud storage charges—costs that disrupt budgets, slow innovation, and limit flexibility.

Download the Report

The 2025 study surveyed more than 400 IT decision makers responsible for managing at least 250TB of data in the public cloud. The findings make one thing clear: as AI, analytics, and data-intensive workloads expand, hidden costs and limited interoperability are forcing companies to rethink their cloud strategies.

The problem: Hidden fees are everywhere

According to the research, nearly every organization surveyed has been hit by surprise charges like retrieval, egress, or PUT fees.

  • 95% of respondents reported unexpected costs for cloud storage usage.
  • Larger organizations—those with more than 5PB of data—were even more likely to experience frequent charges.

These hidden costs have become such a burden that 85% of companies are taking steps to manage them. The top tactics include:

  • Reducing the size of datasets stored in the cloud (56%)
  • Shortening storage duration policies (45%)
  • Cutting spending elsewhere in the tech stack (40%)

In short: IT teams are making trade-offs to avoid surprise costs—trade-offs that can limit innovation and reduce the value of their data

Egress costs are locking companies in

One of the most striking findings: 

55% of respondents said that the cost of egressing and moving data is the biggest barrier to switching cloud storage providers.

That means many organizations feel trapped in their current solutions—not because the technology is best-in-class, but because moving their data would be too expensive.

This dynamic creates what’s often called a “walled garden” effect—where providers profit from data lock-in rather than delivering value through performance or innovation.

The result? Slower cloud adoption, limited agility, and higher total cost of ownership for IT teams trying to scale modern workloads.

Flexibility and interoperability are the new imperatives

If cost surprises weren’t enough, nearly all respondents (99%) said that limited flexibility and lack of interoperability are impacting their ability to deliver and scale.

In other words: even when data is stored safely, it’s often stuck—difficult to move, integrate, or use across tools and platforms.

This friction hits hardest at large enterprises and data-heavy organizations that depend on cross-cloud workflows, hybrid architectures, or AI pipelines that require moving large volumes of data frequently.

A turning point for cloud storage strategy

With 62% of respondents preferring to select best of breed providers vs. one-stop-shops, these findings highlight a growing shift:

  • IT teams are no longer choosing cloud providers solely based on performance or ecosystem.
  • They’re prioritizing predictability, transparency, and interoperability—the ability to move and use data freely, without hidden penalties.

Backblaze has long championed this model with open cloud storage that puts customers—not pricing structures—in control. Our egress fee transparency, S3 compatible APIs, and simple pricing are designed to eliminate the pain points identified in this report.As one respondent put it: “We need a cloud partner that helps us use our data, not pay to move it.”

What’s next: Join the conversation

The full report—The Hidden Cost of Cloud Object Storage—is now available for download. Inside, you’ll find all the data, charts, and insights from 400+ IT leaders across industries and company sizes.

Download the Report

And, to dive deeper into the findings, join us for an upcoming live webinar with experts from Dimensional Research and Backblaze. We’ll unpack the key trends, share real-world stories from IT leaders, and discuss how to build a more transparent, flexible cloud strategy.

Register for the Webinar

About the research

The survey, conducted by Dimensional Research in May–June 2025, included responses from 403 qualified technology stakeholders responsible for cloud storage strategy and budgets. All participants represented companies with over 250TB of data stored in the public cloud.

The post The Hidden Cost of Cloud Storage: What 400+ IT Leaders Wish They Knew Sooner appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

The Reliability Edge SREs Have Been Waiting For

Post Syndicated from Maddie Presland original https://www.backblaze.com/blog/the-reliability-edge-sres-have-been-waiting-for/

A decorative image showing several types of devices with digital patterns in the background.

Site reliability engineers (SREs) are measured by one thing above all: keeping systems available when it matters most. They’re the ones getting calls at midnight, managing the war room during outages, and preventing small hiccups from snowballing into customer-facing failures.

But storage from major cloud providers often makes their job harder. Tiering delays stretch out recovery times. Replication gaps create blind spots across regions. Complex policy chains flood monitoring systems with noise. Instead of protecting reliability, general-purpose storage often undermines it.

What SREs need is a storage layer that works with them, not against them—one that delivers durability without complexity, speed without cold-tier delays, and clarity without policy sprawl.

A specialized, always-hot storage foundation provides exactly that.

This is the final post in our three-part series on how specialized storage helps every member of a cloud-native team. (See articles one and two to get the full story.) This time, we’re zeroing in on the reliability engineers who keep customer-facing systems humming behind the scenes.

Build a disaster recovery plan that’s ready for anything

Uncover proven frameworks for every stage of recovery and common pitfalls to avoid in our Essential Guide to Disaster Recovery Planning.

Reliability starts with storage

For SREs, storage is the backbone of availability and recovery. When it falters, the blast radius spreads fast. Even a minor failure can ripple outward and amplify the impact of every incident.

In the sections below, we’ll look at how those ripple effects play out in real-world scenarios, and how specialized, always-hot storage helps SREs contain failures, recover faster, and quiet the noise that makes reliability so hard to sustain.

Contain the blast radius

SREs spend much of their time running “what-if” drills. What if a drive fails? What if a region goes down? What if replication lags behind?

With general-purpose cloud storage, those “what-ifs” become real risks:

  • Tiering delays: Infrequently accessed data is automatically pushed into colder, slower tiers. During an incident, archived data such as logs or snapshots must be restored before it’s usable. This slows recovery when seconds count.
  • Replication gaps: Replication isn’t always immediate or consistent across regions. When writes lag or copies fall out of sync, recovery data can be stale or incomplete, leaving teams guessing at the true state of their systems.
  • Policy complexity: Layers of identity and access management (IAM), lifecycle, and routing policies often overlap in unpredictable ways. A single misconfiguration—like archiving active data or blocking a needed API—can cascade through dependent services, turning a minor error into a wider outage.

Each layer meant to increase flexibility instead adds fragility.

Specialized storage changes that dynamic. Designed for worry-free durability and built to eliminate single points of failure, it distributes data across independent systems so localized issues don’t cascade. Even if hardware fails or a region experiences disruption, data remains accessible and recovery stays predictable. For SREs, that means fewer nightmare scenarios to model, fewer “what-ifs” in runbooks, and faster, more confident recovery.

Cut mean time to recovery (MTTR), protect SLAs

When an incident hits, the SLA clock starts ticking. Every minute spent waiting on logs, snapshots, or configs adds pressure from customers and leadership alike.

But in tiered storage systems, those critical assets are often parked in colder, low-cost tiers meant for archival access rather than fast recovery. Pulling them back can take hours or even days before triage can begin. That latency bloats MTTR and turns manageable events into prolonged outages with real customer impact.

Specialized storage eliminates these bottlenecks. Always-hot data and millisecond reads give SREs immediate visibility into logs, snapshots, and configs, so evidence is available the moment an incident begins. Instead of stalling while waiting on a restore job, teams can dive directly into diagnosis and resolution. The results are faster MTTR, steadier SLA performance, and fewer fire drills turning into headline outages.

Reduce alert fatigue

Ask any SRE what wears them down and the answer comes quickly: false alarms and 3 a.m. wake-ups. The incident itself may be rare, but the noise leading up to it is relentless.

In big-cloud environments, complexity breeds that noise: 

  • Lifecycle policies silently archive data until a request fails
  • IAM rules misalign with pipeline needs
  • Tier transitions or throttling events masquerade as outages in monitoring dashboards. 

Each quirk becomes another alert, another call, another night interrupted. Over time, the noise blends with the signal, and teams start second-guessing what’s real. Alert fatigue sets in. Engineers tune out notifications or delay responses, not from neglect but from exhaustion. The result is a slower reaction when a real outage hits, which is exactly the scenario the alerts were meant to prevent.

Specialized storage dials down the chaos. A single-tier design with clear access controls strips away layers of risk, keeping alerts meaningful and edge cases rare. Instead of burning cycles firefighting brittle rules, SREs can focus on resilience engineering and prevent outages in the first place.

Rethink storage, strengthen reliability

The SRE role is already demanding. Storage shouldn’t add to the burden. An always-hot storage layer gives teams the durability, speed, and simplicity they need to keep systems reliable without extra toil.

Backblaze B2 was built with SREs in mind:

  • Architected for 11 nine’s of durability
  • Millisecond reads that slash MTTR and protect SLAs.
  • Simplified architecture that cuts noise and pager fatigue.

You don’t need to rebuild your stack to get these benefits. Just swap the endpoint and redeploy. With Backblaze B2, storage stops undermining reliability and starts strengthening it.

Tired of midnight pages for preventable storage issues? There’s a better way. Explore how Backblaze B2 fits into your reliability workflows, and how much calmer on-call life feels when storage simply works.

The post The Reliability Edge SREs Have Been Waiting For appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Three Hidden Costs in AI Video Storage

Post Syndicated from Maddie Presland original https://www.backblaze.com/blog/three-hidden-costs-in-ai-video-storage/

A decorative image showing various types of media.

Generative AI video is exploding. Platforms can turn prompts into polished clips, and models churn through massive training sets of images and footage. Behind the magic, though, is the unavoidable reality of storing and moving petabytes of data. 

Training runs require archiving colossal datasets, then pulling them back in full when it’s time to retrain. Once models go live, the output itself becomes another major workload to manage, whether that’s endless libraries of user-generated videos or fast-cycling streams of ephemeral content. These challenges are part of life for every GenAI company, but the costs of handling them vary widely depending on the provider.Those cloud storage costs can spiral quickly out of control. The big cloud providers lure teams in with low headline rates, but the fine print tells a different story. Pricing depends on which storage tier you pick, how often you move data between regions, and how many API requests your pipeline makes. Founders end up building workflows around cloud quirks instead of what’s fastest and simplest for their teams.

Free ebook: The Cost of Cloud Storage for AI

Struggling to keep AI storage costs under control? Download our free ebook to discover how to optimize cloud storage for AI workloads—without compromising performance.

Download the Ebook

Hidden cost #1: Storage tiers and complexity

AI video data doesn’t behave neatly. Training sets might sit untouched for long stretches before being needed again all at once. User-facing content might accumulate forever, or spike and crash depending on the latest trend. For lean engineering teams, predicting these swings is nearly impossible.

On major cloud providers, the stakes are high. Choose a hot tier and you’ll overpay when data goes cold. Pick an archive tier and you’ll face delays and penalties when you suddenly need that dataset tomorrow. Constantly shifting petabytes between tiers adds both operational overhead and surprise costs.

The numbers tell the story: a 5PB archive costs about $120K a month on AWS S3 Standard for storage alone, before any egress charges. The same capacity runs closer to $30K on Backblaze B2 Cloud Storage—a $90K delta that could fund another GPU cluster or extend a startup’s runway.

Backblaze B2 comes in at around one-fifth the cost of S3, with no tiering games to manage. And when workloads demand maximum throughput, B2 Overdrive scales while delivering a stronger price-to-performance ratio than others offer. That means less time modeling cost scenarios and more time iterating on product and model design.

Hidden cost #2: Egress fees

AI development thrives on iteration. Training and retraining cycles shuffle enormous datasets across clusters, often more than once a month. Each transfer can rival the cost of storage itself. And the faster a team wants to move, the more those bills stack up.

The big cloud providers introduce friction at every step. They charge not only when data exits their cloud but also when it crosses between their own regions. At petabyte scale, those tolls can reach five or even six figures in a single month, forcing founders into an impossible tradeoff: experiment less or drain the budget.

Consider that moving just 1PB once per month on AWS in the US East (N. Virginia) region racks up around $53.8K. Double that transfer frequency and you’re staring at over $100K in egress fees. That’s budget better spent on hiring, acquiring customers, or building better products.

Backblaze removes this bottleneck. Backblaze B2 already includes free egress to leading GPU and CDN partners. For companies operating at AI scale, B2 Overdrive goes further with unlimited free egress to any destination. That means models can be trained, tuned, and distributed globally without a single surprise charge standing in the way of progress.

Mirage, an AI video platform, experienced this firsthand. By eliminating egress costs, they cut storage-related expenses by up to 95% compared to their previous provider—freeing resources to reinvest in growth and product innovation.

Hidden cost #3: API requests and transaction fees

Not every AI video workflow interacts with storage the same way. Some stream large video files in big chunks, keeping the number of calls manageable. Others slice data into millions or billions of tiny objects—frames, embeddings, or metadata—and rely heavily on listing and indexing operations. In those cases, what looks like spare change per request quickly compounds into thousands of dollars in charges every month.

Major cloud storage providers are relentless here. Every PUT, GET, LIST, or HEAD operation comes with a fee, no matter how small. At scale, those fractions of a cent add up fast, leaving engineers designing around billing quirks instead of choosing the cleanest solution for their pipelines.

Picture a pipeline that generates one billion writes and two billion reads in a single month. On AWS, the tab for those transactions alone would run close to $5.8K. On Backblaze B2, writes are free and reads cost just $0.004 per 10,000 requests, bringing the same workload down to about $800. And the first 2,500 Class B and Class C transactions each day are free, further shrinking the bill. On B2 Overdrive, all API calls are included at no additional cost.

Whether your architecture leans toward billions of tiny objects or more efficient streaming, Backblaze keeps request charges predictable and manageable. That makes API calls something your team doesn’t need to obsess over, which is exactly how it should be.

Bringing it together: Simple, predictable economics

Taken together, these hidden costs show why storing AI video on “the big three” often feels like playing a rigged game. The pricing looks straightforward until the bills arrive, padded with charges for tiers, transfers, and transactions. Each one eats away at budget and slows the pace of innovation.

Backblaze offers a different path. By stripping out the fine print and focusing on price-to-performance, it makes storage a stable foundation instead of a moving target. Mirage proves what that means in practice: eliminating egress fees drove huge savings and freed resources to reinvest in their product.

For founders, that kind of predictability turns storage from a frustrating line item into the fuel for faster iteration, bolder experimentation, and sustainable growth.

The post Three Hidden Costs in AI Video Storage appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Are Hard Drives Getting Better? Let’s Revisit the Bathtub Curve

Post Syndicated from Drive Stats Team original https://www.backblaze.com/blog/are-hard-drives-getting-better-lets-revisit-the-bathtub-curve/

A decorative image showing stylized hard drives.

If you’ve hung around Backblaze for a while (and especially if you’re a Drive Stats fan), you may have heard us talking about the bathtub curve. In Drive Failure Over Time: The Bathtub Curve Is Leaking, we challenged one of reliability engineering’s oldest ideas—the notion that drive failures trace a predictable U-shaped curve over time. 

But, the data didn’t agree. Our fleet showed dips, spikes, and plateaus that refused to behave. Now, after 13 years of continuous data, the picture is clearer—and stranger. 

The bathtub curve isn’t just leaking, and the shape of reliability might look more like an ankle-high wall at the entrance to a walk-in shower. The neat story of early failures, calm middle age, and gentle decline no longer fits the world our drives inhabit. Drives are getting better—or, more precisely, the Drive Stats dataset says that our drives are performing better in data center environments. 

So, let’s talk about what our current “bathtub curve” looks like, and how it compares to earlier generations of the analysis. 

The TL;DR: Hard drives are getting better, and lasting longer.

The intro: Let’s talk bathtub curve

If you’ve spent any time around hardware reliability, you’ve seen it: a smooth U-shaped line called the bathtub curve. It promises order in the chaos of failure—a story where devices begin life with a burst of defects, settle into steady performance, and finally wear out in predictable decline. And, this is what it looks like:

For decades, it’s been engineering shorthand for how things die. But as our dataset has grown—more than a decade of drive telemetry and millions of drive-days—the data is clear: Our real drive population is more complicated. 

What the bathtub curve looked like then

The first time we ran this analysis was in 2013, and when we updated the article in 2021, we shared this chart:

It shows the annualized failure rate (AFR) of the full drive pool over time (in years) at two different look-back points—2013 and 2021. At that time, you could already see that the bathtub curve was starting to, as the venerable Andy Klein put it, “leak.” The 2013 data looks the closest to a true bathtub curve, while the 2021 data shows fewer early failures and a lower failure rate for more years. We also see the average longevity of drives goes up by about two years before spiking into the failure zone.

Numbers can both define and obscure reality

Now, there are some very interesting factors that come into play when comparing hard drive reliability over time. For example, our usual caveats about how we use drives vs. how consumers use drives, how our workloads have changed over time, etc. More importantly, though, because we’re comparing averages, it’s easy to lose track of the context around our dataset—how many hard drives are we talking about in 2013 vs. 2021? 

When we did this analysis in 2013, Backblaze had been open for six years, but we’d only been publishing the Drive Stats dataset since 2013. So, arriving at presenting a look-back at the data (i.e., this is how many drives failed when they were between zero and one years old) was a bit of a math problem compared to our usual data reporting. We were talking about drives that entered the drive pool in 2007, and those were ones we hadn’t shared complete daily logs about, even if the drive was still in service in 2013 (which, as you can tell from the data, was unlikely). We achieved that by looking at failures vs. logged on hours, and when we re-created the analysis recently, we used this SQL query: 

CREATE VIEW introduction_dates AS
-- Calculate the introduction date of drives that were already in service on 2013-04-10
SELECT serial_number, date(date_add('hour', -1 * smart_9_raw, TIMESTAMP '2013-04-10 00:00:00')) AS introduced
FROM drivestats
WHERE date = DATE '2013-04-10'
UNION
-- Use the minimum date for drives that entered service after after 2013-04-10
SELECT serial_number, MIN(date) as introduced
FROM drivestats
WHERE serial_number NOT IN (
SELECT serial_number
FROM drivestats
WHERE date = DATE '2013-04-10'
)
GROUP BY serial_number;

SELECT
date_diff('day', d2.introduced, d1.date) / 91 AS age_in_quarters,
100 * 365 * (cast(SUM(d1.failure) AS DOUBLE) / COUNT(*)) AS afr
FROM drivestats AS d1
INNER JOIN introduction_dates AS d2
ON d1.serial_number = d2.serial_number
GROUP BY 1
ORDER BY 1;

Our drive pool looked a lot different in 2013 as well. Not only was it smaller (~35,000 drives and over 100PB of data were live as of September 2014), but it also was made up of “consumer” drives. While we didn’t see much of a difference between the two when we actually tested them in the environment, we did a lot of drive farming in those days, a process that included actually “shelling” the drives and removing them from their housings—which means that our drive pool had a lot more potential to get some bumps along the way. Hard drives are pretty resilient and we were careful, but it’s worth noting. 

By the time we were doing this analysis in 2021, we had a lot more data and a lot more storage drives—206,928 or so. Between 2013 and 2021, we had added capacity to our Sacramento data center; expanded our data center regions with locations in Phoenix and Amsterdam, with more on the way in 2022; we launched Backblaze B2 Cloud Storage; and, we went public

All those things are cool from a historical perspective, but the more impactful thing to pay attention to is that any time you have less data (read: a smaller number of total drives), each individual data point has more impact on the whole. In the bathtub curve, you naturally reduce the number of drives as they get older—every drive has a day one, but not every drive has a day 1,461 (or, in lay people’s terms: four years, one day). With fewer drives, more spikes. So, if you start off with more drives, your numbers are likely to be more steady—unless there’s a real problem, or you’re entering your true drive pool failure zone. 

And, since we’ve transitioned to buying more drives, and decommissioning drives in a different way—well, that all affects what the end result is. More on our drive hygiene habits later; for now, let’s get into our current data.

What the bathtub curve looks like now

Without further ado, let’s look at the failure rates in our current Backblaze drive pool:

That’s a pretty solid deviation in both age of drive failure and the high point of AFR from the last two times we’ve run the analyses. When we ran our 2025 numbers (at the close of Q2 2025), we reported on 317,230 drives. Take that as an approximate raw number given the normal drive exclusions in each Drive Stats report, but it gets you in the ballpark. 

For consistency’s sake, here’s 2013:

And here’s 2021:

What’s missing, and a bit difficult to visualize, is the scale on both the x axis (time in years) and the y axis (annualized failure rate expressed in percentage). Let’s put all three on the same chart:

Note that both the 2013 data and the 2021 data have high failure percentage peaks at some point near the end of their drive lifetimes. In 2013, it was 13.73% at about 3 years, 3 months (and 13.30% at 3 years, 9 months). In 2021, it’s 14.24%, with that peak hitting at 7 years, 9 months. 

Now, compare that with the 2025 data: Our peak is 4.25% at 10 years, 3 months (woah). Not only is that a significant improvement in drive longevity, it’s also the first time we’ve seen the peak drive failure rate at the hairy end of the drive curve. And, it’s about a third of each of the other failure peaks. 

Meanwhile, we see that the drive failure rates on the front end of the curve are also incredibly low—when a drive is between zero and one years old, we barely crack 1.30% AFR. For reference, the most recent quarterly AFR is 1.36%. 

Still, if we take a look at the trendlines, we can see that the 2021 and the 2025 data isn’t too far off, shape-wise. That is, we see a pretty even failure rate through the significant majority of the drives’ lives, then a fairly steep spike once we get into drive failure territory. 

What does that mean? Well, drives are getting better, and lasting longer. And, given that our trendlines are about the same shape from 2021 to 2025, we should likely check back in when 2029 rolls around to see if our failure peak has pushed out even further.

Hey, what about that data contextualization you did above?

Good point—there are significant things that have changed about our dataset that may be affecting our numbers. We’ve already tackled the consumer vs. enterprise drive debate, and while we don’t have updated testing on that front, there are other things about buying drives at scale that may have an effect on the data. 

For instance, because we buy drives in bulk, that means that a big chunk of drives enter our data pool at the same time. Given that we, over the years, have really only seen model-by-model variation, this means that if you get a lemon of a drive and you’ve added a lot of them, you may have a chunk of drives failing all at once. 

Also, we have a different process for decommissioning drives these days. There are lots of things that go into that strategy, but you can simplify it all to risk management and our ability to grow our storage footprint over time. From a practical perspective, that means sometimes there are drives that are still performing well that we decide to take out of service anyway—and that means they get taken out of the fleet without ever having failed. Since our analyses above are based on annualized failure rate vs. age of drive, you can see a big drop in drive population without the expected failure rate spike. 

Finally, we have different standards for new drives. Some of them just have to do with the industry at large—drives are getting bigger, and storage patterns are changing. But, compared with 2013, when a natural disaster forced us to innovate in unexpected ways, we’ve got more flexibility to consider our purchases, and to do so in a way that’s specific to our environment. 

Was the bathtub curve just wrong?

The issue isn’t that the bathtub curve is wrong—it’s that it’s incomplete. It treats time as the only dimension of reliability, ignoring workload, manufacturing variation, firmware updates, and operational churn. And, it rests on a set of assumptions:

  • Devices are identical and operate under the same conditions.
  • Failures happen independently, driven mostly by time.
  • The environment stays constant across a product’s life.

The good news: When it comes to data centers, most of these are as true as they can be in a real-world environment. Data centers environments attempt to be as consistent as possible to be able to reduce power consumption, and to be able to properly anticipate and plan data workloads. Basically, consistency = a happy data center. 

That said, conditions can’t ever be perfect. Our numbers have always and will always reflect both good planning and the unforeseen aspects of reality. Understanding whether drives are “good” or “bad” is always a conversation between what you theorize (in this case, the bathtub curve) and what happens (the Drive Stats dataset). 

What’s next?

Why does all this talk of numbers matter? Well, as we’ve expanded our drive pool over time, in some ways, we’ve increased confidence in the results we’re seeing, both on day one and day 1,461. Even if we had the exact same drives models and drive pool make up (by percentage) from 2013 that we did in 2021, having more of them would give us better results. But, now we have a greater diversity of drives and more of them. 

That doesn’t mean we’re the be-all, end-all of drive reliability, but it does give us some more footing to slice and dice the data and bring it back to you. As always, you can find the full Drive Stats dataset on our website, which means you can repeat this experiment, or use the data in any way you can imagine. Stay tuned for our quarterly reports and more articles from the Drive Stats extended universe—and feel free to sign up for the Drive Stats newsletter if you want to stay up-to-date.

The post Are Hard Drives Getting Better? Let’s Revisit the Bathtub Curve appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

How Backblaze Computer Backup and Jamf Pro Extension Attributes Enhance the Customer Experience

Post Syndicated from Mark McLaughlin original https://www.backblaze.com/blog/how-backblaze-computer-backup-and-jamf-pro-extension-attributes-enhance-the-customer-experience/

A decorative image showing computer and user icons.

At Backblaze, we’ve always believed that data protection should be easy, reliable, and seamless. Our Computer Backup product has long provided individuals and organizations with unlimited, automatic, and affordable cloud backup. But for IT admins managing fleets of devices, visibility and control are just as critical as the backup itself.

That’s where our integration with Jamf Pro comes in. By developing extension attributes that surface key information about Backblaze Computer Backup directly into Jamf Pro, we’ve made it simpler than ever for admins to monitor and manage backup health across their organization.

Why extension attributes matter

Jamf Pro is the industry standard for managing Apple devices, giving IT teams centralized oversight and policy enforcement across Macs, iPhones, and iPads. Extension attributes allow admins to collect custom data points beyond Jamf’s built-in inventory. By plugging Backblaze-specific attributes into Jamf, organizations gain real-time insight into the backup status of every managed Mac—without jumping between multiple dashboards.

This alignment reduces blind spots, helps meet compliance requirements, and, most importantly, gives peace of mind that critical company data is safe.

The four key extension attributes

We’ve developed four extension attributes that bring actionable backup insights into Jamf Pro:

1. Backup selected

This attribute shows whether Backblaze Computer Backup is enabled on a device. IT admins can quickly confirm if backups are actively running, ensuring no endpoint is left unprotected.

2. Backup size

Data size matters—not just for storage costs, but for understanding the scope of protection. This attribute reports the total size of the data being backed up, helping teams gauge usage and anticipate trends.

3. Last backup date

Knowing when a device last backed up is critical to risk management. This attribute ensures admins can spot machines that haven’t backed up recently and take proactive steps before a potential data loss occurs.

4. Safety frozen status

Backblaze’s Safety Freeze feature protects users from data loss by preventing accidental or malicious changes to a backup. By surfacing this status in Jamf, admins gain visibility into whether a device’s backup is frozen and can act accordingly.

Benefits for IT teams and end users

By combining Backblaze’s reliable backup with Jamf’s centralized management, organizations gain:

  • Proactive risk management: Spotting gaps in backup coverage before they become crises.
  • Streamlined compliance: Meeting audit requirements with centralized backup data reporting.
  • Operational efficiency: Saving IT teams from switching between tools and reducing the need for manual checks.
  • Automatic, seamless backups: Employees know their data is being protected without interruptions or extra effort.

Looking ahead

The development of these Jamf Pro extension attributes is part of our broader mission to empower IT teams with tools that reduce friction and strengthen resilience. As remote and hybrid work environments continue to expand, seamless integrations like these will only become more valuable.

At Backblaze, we’re proud to provide more than just a backup service—we’re delivering visibility, control, and confidence.

Want to try it yourself? Get started today and see how these Jamf Pro extension attributes can make managing backups as simple as possible.

The post How Backblaze Computer Backup and Jamf Pro Extension Attributes Enhance the Customer Experience appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

The Storage Fix DevOps Has Been Waiting For

Post Syndicated from David Johnson original https://www.backblaze.com/blog/the-storage-fix-devops-has-been-waiting-for/

A decorative images showing a hybrid cloud environment.

Developer operations (DevOps) engineers sit at the intersection of development and operations. Their job is to keep pipelines humming, environments consistent, and deployments on schedule, all while juggling uptime, costs, and compliance.

This balancing act leaves little tolerance for surprises. Unfortunately, storage from major cloud providers often delivers exactly that. Built to cover every use case from backups to analytics to streaming, general-purpose storage prioritizes breadth over focus. The result is complexity:

  • Tiering rules that shift data unexpectedly
  • Pricing models that change with every access pattern
  • Dependencies that ripple across services

For DevOps, this type of one-size-fits-all system means hidden costs, shifting performance, and integration headaches right when predictability matters most.

The good news: you don’t need to overhaul your entire stack to regain control. Adding a specialized, always-hot storage layer can resolve DevOps engineers’ biggest storage headaches without forcing major workflow changes.

This post is the second in our three-part series on how specialized storage helps every member of a cloud-native team, including developers, DevOps engineers, and site reliability engineers (SREs). Today, we’ll focus on the payoffs for DevOps engineers.

Storage that works the way DevOps does

For DevOps engineers, storage issues often show up in the middle of critical workflows. A change meant to speed deployments triggers cascading adjustments. A spike in access patterns turns into sprawling invoices and finance tickets. A misaligned rule blocks data right when pipelines need it most.

In the sections below, we’ll dig into how these problems derail day-to-day operations, and how purpose-built cloud storage removes the friction so DevOps teams can stay focused on building and delivering.

Free ebook: Why object storage is essential for AI workloads

Unlock faster development and simpler workflows—without surprise costs. Get our free ebook “Cloud Storage for the Cloud-Native Era.”

Get the Ebook

Migration without migraines

Swapping a storage layer usually comes with the fear of broken pipelines, incompatible APIs, or weeks of retraining. And the big three cloud providers compound this by tying services together so tightly that even small changes can ripple through deployments

That means a tweak meant to improve storage can unexpectedly force adjustments in compute, networking, or identity and access management (IAM). Now, you’re slowing down releases instead of speeding them up.

Specialized storage avoids this trap. With drop-in S3 compatibility and no tier juggling, adding it to your stack requires little more than updating an endpoint and credentials. Pipelines keep running, Terraform and Kubernetes scripts stay intact, and deployments continue smoothly, so storage upgrades feel like routine maintenance, not full migrations.

Invoices without inquisitions

Engineers shouldn’t have to be accountants. But with major cloud providers, storage costs often spike without warning when charges are tied to shifting access patterns, such as frequent reads, writes, or transfers. 

The result is sprawling invoices packed with egress fees, API surcharges, and delete penalties. Finance teams see the bill and demand answers. DevOps teams could spend hours untangling storage math instead of improving automation or hardening pipelines. Every unexplained charge turns into a ticket, and every ticket drags engineers away from engineering.

Specialized storage removes this ordeal. Flat, transparent pricing and no hidden penalties make costs easy to predict and explain. That clarity keeps tickets low and escalations rare. DevOps teams can walk into finance reviews with confidence, backed by numbers that are simple to explain.

Engineering without entanglements

Major cloud provider environments come with a maze of tiers, lifecycle policies, IAM rules, and cross-service dependencies. Managing these isn’t a one-time task; it’s a cycle of effort that eats into engineering time:

  • Writing: Defining lifecycle policies and IAM rules to control when data moves between tiers or who can access it.
  • Testing: Validating every rule to make sure it doesn’t archive active data, block critical access, or violate compliance requirements.
  • Maintaining: Updating policies as workloads evolve, with new buckets, new services, or shifting security mandates.
  • Troubleshooting: Debugging typos, misaligned automations, or unexpected interactions that can lead to outages, delays, or surprise costs.

For DevOps, every new policy is another layer of overhead and another chance for something to break. 

Specialized storage ends this cycle. With no lifecycle rules to script or tiers to monitor, you don’t have to spend hours debugging brittle policies. That reclaimed time goes back into what matters: strengthening automation, refining observability, and improving the pipelines your developers depend on.

Growth without gridlock

DevOps isn’t just about keeping today’s pipelines running; it’s also about ensuring infrastructure won’t collapse under tomorrow’s demands.

As organizations layer on AI/ML pipelines, streaming services, or analytics workloads, data volumes surge and access patterns become less predictable. General-purpose storage often struggles under these conditions, throttling performance and forcing DevOps engineers into troubleshooting slowdowns and capacity crunches whenever workloads outpace storage. 

Specialized storage meets these challenges. Its high throughput and penalty-free design scale with demand, so performance holds steady even as workloads expand. Whether supporting AI training jobs or streaming analytics, your infrastructure grows without bottlenecks—and without turning DevOps into crisis management.

Rethink your storage, not your stack

The demands on DevOps engineers aren’t slowing down. They’re expected to deliver speed, reliability, and cost control, all at once. The wrong storage layer makes that harder; the right one makes it easier.

Backblaze B2 was built to make DevOps engineers’ lives easier: 

  • Minimal changes: S3-compatible APIs work with Terraform, Kubernetes, ArgoCD, and more.
  • Predictable costs: Transparent pricing and little-to-no egress fees.
  • Simplified operations: Always-hot access, no tier juggling, no lifecycle headaches.
  • Future-ready: High throughput and AI-ready integrations.

You don’t have to rebuild your stack to gain these benefits. Just swap the storage endpoint, redeploy, and get back to engineering.

Tired of troubleshooting tiers or decoding invoices? There’s a simpler path forward. Explore how Backblaze B2 fits into your DevOps workflows, and how much smoother things run when storage isn’t slowing you down.

The post The Storage Fix DevOps Has Been Waiting For appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Why Cloud-Native Developers Need a Specialized Storage Layer

Post Syndicated from David Johnson original https://www.backblaze.com/blog/why-cloud-native-developers-need-a-specialized-storage-layer/

A decorative image showing several cubes on a gradient background.

Cloud-native developers move fast. Continuous integration and continuous development/deployment (CI/CD) pipelines, containerized environments, and growing performance demands leave little room for delays. Even small bottlenecks can slow momentum, and a common source of slowdown is storage.

Most cloud-native teams default to storage from major cloud providers because it’s convenient and deeply integrated with other services, such as compute, networking, and machine learning (ML). But that convenience isn’t always optimized for development velocity. These platforms prioritize flexibility for a wide range of use cases, not the consistency and speed that fast-moving dev teams need. 

Here’s the good news: Adding a specialized, always-hot storage layer can reduce friction and unlock faster, smoother development—without changing the tools you already use.

This post kicks off a three-part series on how specialized cloud storage benefits every member of a cloud-native team: developers, DevOps engineers, and SREs. 

First up: the developer.

Free ebook: Why object storage is essential for AI workloads

How do you balance scalability with performance while staying on budget? This ebook explores how object storage enhances every stage of the pipeline from collection to training to deployment, and provides real-world use cases.

Get the Ebook

When storage slows you down and how to fix it

When storage underperforms, it disrupts your development loop. Cold-tier delays, unpredictable time to first byte (TTFB), and inconsistent throughput take time away from building and shipping applications, or from supporting AI/ML workloads that depend on fast, consistent data access.

In the sections below, we look at how these issues show up in practice and how specialized cloud storage can help remove the roadblocks to faster development.

Build-test loops without the bottleneck

Fast feedback loops are the heartbeat of cloud-native development. Every delay in retrieving files, artifacts, or dependencies drags out build-test cycles and can also slow AI/ML workloads that rely on quick, repeated access to large datasets.

Delays often come from the way cloud providers structure tiered storage. Data is divided into hot, cool, and cold tiers. While cooler tiers cost less, they’re built for retention, not speed. When builds depend on files stored in these tiers, retrieving them adds latency.

Lifecycle policies compound this by automatically moving files into cooler tiers if they haven’t been accessed for a set period. When developers need those files again, they first have to retrieve them from a slower tier, adding latency and sometimes fees.

A specialized, always-hot storage layer eliminates these delays by removing tiers and retrieval hurdles altogether. All data stays instantly accessible, so artifacts and dependencies are always ready the moment they’re needed. Builds run without waiting for restores, tests execute without interruption, and feedback loops stay tight.

Consistent throughput, no tuning required

With general-purpose storage from major cloud providers, consistent performance doesn’t come out of the box. Developers are left to manage it themselves, often through manual tweaks such as file-size tuning or other trial-and-error adjustments.

But tuning only goes so far. Even if developers adjust file sizes or request patterns, those tweaks can’t overcome the built-in delays of tiered storage systems. To compensate, many teams add caching layers or complex configurations. Those workarounds may patch performance gaps in the short term, but they create their own set of burdens:

  • Extra rules and scripts: Moving data between tiers or maintaining caches often requires custom automation.
  • Added complexity: Each workaround becomes another system to monitor and maintain, increasing the risk of errors.
  • Slower workflows: Rather than focusing on development, teams burn time managing storage mechanics.

Specialized storage eliminates the need for tuning or caching altogether. With high-throughput performance available from the start, developers don’t have to waste time building or maintaining workarounds. No scripts, no caches, and no trial-and-error.

Predictable performance under real workloads

General-purpose cloud storage can stumble when workloads scale. Because storage is tightly coupled with compute, networking, and access controls in big cloud providers’ environments, conflicts between these layers can slow requests or, in some cases, cause downtime. 

These mismatches happen for several reasons:

  • Competing goals: Major cloud providers build storage to handle many use cases at once, but that broad design isn’t optimized for any one workload. Compute jobs, in particular, demand consistent speed. The result is a mismatch: infrastructure built for broad efficiency can struggle to deliver reliable performance when applications scale in production, or when AI pipelines push storage and compute simultaneously.
  • Complex rules: In big cloud provider environments, storage doesn’t operate in isolation. Access controls, security policies, and service dependencies pile up across layers, and they don’t always work in sync. A permission, routing choice, or automation can create unexpected bottlenecks when combined with other rules.
  • Network constraints: High egress and cross-region transfer fees discourage data from moving freely between services or locations. Teams may delay or limit transfers to avoid unexpected costs, but that hesitation creates bottlenecks when workloads need to pull data across clouds or regions.

Together, these issues create hidden instability. Performance that seems fine in testing can falter in production as heavier workloads expose bottlenecks and small delays ripple through applications. 

Specialized storage removes this uncertainty by eliminating the hidden conflicts that come from tightly coupled, general-purpose systems. With reliable, low-latency access that stays steady even under production load, teams don’t have to scramble to fix surprises mid-release. 

It’s time to rethink the storage layer

You don’t need to rip and replace your entire cloud strategy to get better performance. You just need to be strategic about which layers serve which purposes.

For cloud-native developers, that means choosing storage that keeps pace with your workflows, so you can move fast, stay in flow, and focus on code instead of configuration.

Backblaze B2 was built with developers in mind:

  • Always-hot access to every object.
  • S3-compatible APIs that work with your existing tools.
  • Enterprise-grade reliability with the best price to performance in the industry.

Because it plugs directly into the tools you already use, you can add Backblaze B2 to your stack without rewriting workflows or retraining teams. Instead of working around storage, you finally get storage that works with you.

Tired of babysitting your storage or coding around its quirks? There’s a better way. Explore how Backblaze B2 fits into your cloud-native stack, and how much faster things can move when builds run without bottlenecks, performance stays consistent, and new features ship without delay.

The post Why Cloud-Native Developers Need a Specialized Storage Layer appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Lessons from Vibe Coding Three Apps in Three Weeks

Post Syndicated from Jeronimo De Leon original https://www.backblaze.com/blog/lessons-from-vibe-coding-three-apps-in-three-weeks/

A decorative images showing a gear, chips, and the word AI.

While taking some time for paternity leave in a small village in the middle of Bulgaria, I used my baby’s nap times to dive deeper into vibe coding to see just how fast and close these AI tools can get you to building real, production-ready apps. It led to a serious of articles, LinkedIn posts, and product experiments, all focused on understanding and sharing my insights on the state of programming and product design that leverage AI.

In my previous article, “ColabWithMe: A GPT Specialized in Google Colab for Data Analysis & ML,” I talked about how generative AI is redefining the programming landscape. As the Harvard Business Review noted in “We’re All Programmers Now,” this shift represents more than just enabling non-technical employees to code. The real opportunity lies in developing multi-skilled professionals who can operate across domains, compressing innovation cycles from weeks to days. (I explore this further in “The Shape of AI Training: How Skill Profiles Guide AI Learning Paths.“)

Which brings me to what I actually built during those nap times—three different applications using a variety of AI tools. Rather than focusing on polished user interfaces, I focused on backend functionality and core business logic. I discovered that debugging the frontend and getting it to look how I wanted consumed far more time than implementing core backend features. So, many of these vibe-coded apps work nicely on the backend, but need more polish on the frontend. Let’s dig in.

Tools reviewed

Vibe coding means building software by describing what you want in natural language and letting AI generate the code. I tested tools across three categories to see how they enable this new way of building.

  • Integrated development environment (IDE) integrated agents: GitHub Copilot Agent, Gemini Code Assistant, Claude, Cursor.
  • Conversational interfaces: ChatGPT, ChatGPT Codex, Grok, Claude.
  • Prompt app builders: Replit, Lovable, Bolt, GitHub Spark.

Project 1: TickGoals.com, AI-powered goal setting (Approximately 7 hours)

The first application tackled a common productivity challenge: transforming vague aspirations into actionable SMART goals. The system implements a conversational AI interface that guides users through goal refinement, then automatically generates structured milestones and tasks.

Key features:

  • Chat with AI to transform vague goals into structured SMART goals
  • Auto-generate actionable milestones and tasks based on your refined goals
  • To-do list interface for tracking progress and completion
  • Persistent goal storage with progress visualization

Tech stack:

  • React frontend for conversational UI generated by GitHub Spark
  • Firebase Functions for serverless backend processing
  • OpenAI API for goal and task creation
  • Firebase Firestore for persistent goal and task storage

Initially I prototyped across Lovable, Replit, Bolt and GitHub Spark to see what each would generate. I eventually used the code GitHub Spark generated for a cleaner React component structure. Check it out here: https://tickgoals.com

Project 2: NewsVibe.AI, newsletter aggregation and summarization platform (Approximately 12 hours)

While catching up on email, I noticed my inbox was filled with newsletters that I’d often just skim or summarize, so I built a tool to handle this automatically. The app provides users with personalized email addresses for newsletter subscriptions, then presents content in a newsfeed interface to easily scroll through with AI summarization.

Key features:

  • Personal @newsvibe.me email addresses for newsletter subscriptions.
  • Instagram-style scrollable feed displaying all your newsletters.
  • AI-powered summarization to get quick overviews of content.
  • Automatic extraction of links and key information from newsletters.
  • Subscription management dashboard with usage analytics.

Tech stack:

  • Cloudflare pages for frontend hosting.
  • Maileroo for email processing and parsing.
  • Supabase for user management and content storage.
  • Python backend deployed on Render for newsletter and summarization processing.
  • OpenAI API for content summarization.
  • Stripe integration for subscription management.

I split this project into separate frontend and backend repos, and found it blazing fast to build out all the backend functionality first before tackling the frontend.

Project 3: Welcome.AI, newsletter editor agent (Approximately 10 hours)

Welcome AI has been my side project since 2017, initially focused on competitive analysis of AI tools. I’ve rebuilt it multiple times, with the latest iteration using retrieval augmented generation (RAG) for content. But, content curation still required manual review, either by me or community contributors, so I built an agent to automate the entire process, identifying, categorizing, and synthesizing AI news into a publication-ready newsletter. View a generated newsletter here. Subscribe at https://newsletter.welcome.ai/

Key Features:

  • Automatically identifies and filters AI-related news from RSS feeds and newsletters
  • Categorizes stories by topic and summarizes key points
  • Writes complete newsletter copy with insights and summaries
  • Curates the top stories and case studies for featured content sections
  • Generates HTML formatting and generates a feature image for the top story

Tech Stack:

  • Python news feed processing
  • OpenAI Agent SDK and APIs
  • GitHub Actions for automated workflow execution
  • Supabase for content management and curation state
  • Backblaze B2 for generated feature image storage

This was purely a backend project to test and experiment with the OpenAI Agent SDK, though I diverged from it toward more direct large language model (LLM) tasks by the end.

Lessons learned

At a high level, you can definitely see how these tools are going to dramatically speed up development, especially for getting to minimum viable product (MVP) or prototype. You should only need a day or two to get something up and test market traction, especially with prompt app builders.

I found Claude Opus/Claude Code worked best for backend code within the IDE, while Gemini Pro was particularly good at frontend landing page development. Coding agents that make multiple changes across multiple files simultaneously, like those in Cursor, Copilot Agent, or ChatGPT Codex, still felt a bit daunting. I experienced chunks of code being deleted a few times, so I spent considerable time reviewing changes or reverting them.

Prompt app builders like Lovable, Replit, GitHub Spark, and Bolt can get you pretty far, but you can eventually hit a wall where the AI starts breaking more than it fixes, or you need to integrate third-party services that require direct code access. With one project, I started in a prompt builder then moved to an IDE for refinement.

High-level, here are some tips that should help in your vibe coding journey.

Before starting: Set instructions and rules

Like custom instructions in ChatGPT, each tool benefits from coding guidelines: Claude Code uses CLAUDE.md, Copilot uses configured instructions, and Cursor has rules (templates at https://cursor.directory/rules).

A screenshot of provided context for generative code tools.

Both Claude Code and Cursor support MCP (Model Context Protocol) for enhanced integrations (Cursor MCP directory: https://cursor.directory/mcp). Some tools can also index documentation folders for deeper context. Set these up first for better code generation.

Start with a complete product requirements document (PRD)

Before writing any code, spend time iterating with an LLM to generate a thorough PRD. This back-and-forth refinement process goes a long way in providing the context your AI coding tools need. Capture everything: user workflows, UI specifications, technical requirements, and success metrics. Save this in your README.md as your north star.

Prompt app builders like GitHub Spark generate PRDs first from your initial prompt, so the more complete and refined it is, the better.

Define your project structure upfront

Work with the LLM to create a structure that follows best practices but stays simple for what you’re building. An MVP doesn’t need enterprise architecture. Map out where components, services, and APIs belong, and include this in your initial prompt.

A screenshot of the project file structure for one of the vibe coding apps created by Jeronimo De Leon.

Monitor new file generation closely as AI tools can suggest new files when not needed. When this happens, correct it immediately. Keep the structure as simple as possible. Break up files that are doing too many things, as this makes them harder to read and update later.

Add context markers throughout your code

Include file paths and descriptions at the top of each file. This helps the AI maintain context when making changes. Add detailed logging at critical points to track what’s happening when things break. Watch for function renames, LLMs often change function names unnecessarily when updating code, breaking references elsewhere.

Always check current API documentation

LLMs can generate outdated code. OpenAI and Pinecone have changed their import syntax, but AI tools still produce the old versions. Have the LLM search for the latest docs, or check them yourself. Knowing how your services currently work helps you catch these mistakes immediately.

One feature, one conversation

Multitasking with AI means juggling code review while it generates more changes. Keep each conversation focused on a single feature unless features are directly related. When the LLM offers to optimize unrelated areas, decline. If the AI gets stuck repeating failed solutions, start fresh rather than fighting it.

Wisdom of the crowds

When stuck, get code reviews from other LLMs since they can catch different issues. But always review their output carefully. LLMs can duplicate functions across files or, worse, delete essential code. In Agent mode especially, I’ve seen them remove core functionality unrelated to the current task. Give specific instructions about where functions belong and double-check nothing critical disappeared.

Vibe Coding = Product Management + Engineering

The most significant shift with AI-assisted development isn’t the speed; it’s the role change. You’re no longer just implementing; you’re defining what to build, how it should work, and why it matters.

This is the multi-skilled professional evolution I mentioned earlier. When “We’re All Programmers Now,” it means domain experts can build their own solutions, but it also means programmers must become domain experts in product thinking. Success with vibe coding requires clear product vision to articulate requirements, technical knowledge to guide the AI correctly, and relentless focus on user problems.

You become the conductor orchestrating AI capabilities while maintaining the judgment to build what people actually need. The future belongs to these blended roles: product managers who understand engineering deeply enough to guide AI tools, and engineers who think like product managers. These T-shaped and M-shaped professionals operate fluidly across domains. This is how we compress innovation cycles from weeks to days: by eliminating the translation layer between idea and implementation.

The post Lessons from Vibe Coding Three Apps in Three Weeks appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Qwen models are now available in Amazon Bedrock

Post Syndicated from Danilo Poccia original https://aws.amazon.com/blogs/aws/qwen-models-are-now-available-in-amazon-bedrock/

Today we are adding Qwen models from Alibaba in Amazon Bedrock. With this launch, Amazon Bedrock continues to expand model choice by adding access to Qwen3 open weight foundation models (FMs) in a full managed, serverless way. This release includes four models: Qwen3-Coder-480B-A35B-Instruct, Qwen3-Coder-30B-A3B-Instruct, Qwen3-235B-A22B-Instruct-2507, and Qwen3-32B (Dense). Together, these models feature both mixture-of-experts (MoE) and dense architectures, providing flexible options for different application requirements.

Amazon Bedrock provides access to industry-leading FMs through a unified API without requiring infrastructure management. You can access models from multiple model providers, integrate models into your applications, and scale usage based on workload requirements. With Amazon Bedrock, customer data is never used to train the underlying models. With the addition of Qwen3 models, Amazon Bedrock offers even more options for use cases like:

  • Code generation and repository analysis with extended context understanding
  • Building agentic workflows that orchestrate multiple tools and APIs for business automation
  • Balancing AI costs and performance using hybrid thinking modes for adaptive reasoning

Qwen3 models in Amazon Bedrock
These four Qwen3 models are now available in Amazon Bedrock, each optimized for different performance and cost requirements:

  • Qwen3-Coder-480B-A35B-Instruct – This is a mixture-of-experts (MoE) model with 480B total parameters and 35B active parameters. It’s optimized for coding and agentic tasks and achieves strong results in benchmarks such as agentic coding, browser use, and tool use. These capabilities make it suitable for repository-scale code analysis and multistep workflow automation.
  • Qwen3-Coder-30B-A3B-Instruct – This is a MoE model with 30B total parameters and 3B active parameters. Specifically optimized for coding tasks and instruction-following scenarios, this model demonstrates strong performance in code generation, analysis, and debugging across multiple programming languages.
  • Qwen3-235B-A22B-Instruct-2507 – This is an instruction-tuned MoE model with 235B total parameters and 22B active parameters. It delivers competitive performance across coding, math, and general reasoning tasks, balancing capability with efficiency.
  • Qwen3-32B (Dense) – This is a dense model with 32B parameters. It is suitable for real-time or resource-constrained environments such as mobile devices and edge computing deployments where consistent performance is critical.

Architectural and functional features in Qwen3
The Qwen3 models introduce several architectural and functional features:

MoE compared with dense architectures – MoE models such as Qwen3-Coder-480B-A35B, Qwen3-Coder-30B-A3B-Instruct, and Qwen3-235B-A22B-Instruct-2507, activate only part of the parameters for each request, providing high performance with efficient inference. The dense Qwen3-32B activates all parameters, offering more consistent and predictable performance.

Agentic capabilities – Qwen3 models can handle multi-step reasoning and structured planning in one model invocation. They can generate outputs that call external tools or APIs when integrated into an agent framework. The models also maintain extended context across long sessions. In addition, they support tool calling to allow standardized communication with external environments.

Hybrid thinking modes – Qwen3 introduces a hybrid approach to problem-solving, which supports two modes: thinking and non-thinking. The thinking mode applies step-by-step reasoning before delivering the final answer. This is ideal for complex problems that require deeper thought. Whereas the non-thinking mode provides fast and near-instant responses for less complex tasks where speed is more important than depth. This helps developers manage performance and cost trade-offs more effectively.

Long-context handling – The Qwen3-Coder models support extended context windows, with up to 256K tokens natively and up to 1 million tokens with extrapolation methods. This allows the model to process entire repositories, large technical documents, or long conversational histories within a single task.

When to use each model
The four Qwen3 models serve distinct use cases. Qwen3-Coder-480B-A35B-Instruct is designed for complex software engineering scenarios. It’s suited for advanced code generation, long-context processing such as repository-level analysis, and integration with external tools. Qwen3-Coder-30B-A3B-Instruct is particularly effective for tasks such as code completion, refactoring, and answering programming-related queries. If you need versatile performance across multiple domains, Qwen3-235B-A22B-Instruct-2507 offers a balance, delivering strong general-purpose reasoning and instruction-following capabilities while leveraging the efficiency advantages of its MoE architecture. Qwen3-32B (Dense) is appropriate for scenarios where consistent performance, low latency, and cost optimization are important.

Getting started with Qwen models in Amazon Bedrock
To begin using Qwen models, in the Amazon Bedrock console, I choose Model Access from the Configure and learn section of the navigation pane. I then navigate to the Qwen models to request access. In the Chat/Text Playground section of the navigation pane, I can quickly test the new Qwen models with my prompts.

To integrate Qwen3 models into my applications, I can use any AWS SDKs. The AWS SDKs include access to the Amazon Bedrock InvokeModel and Converse API. I can also use these model with any agentic framework that supports Amazon Bedrock and deploy the agents using Amazon Bedrock AgentCore. For example, here’s the Python code of a simple agent with tool access built using Strands Agents:

from strands import Agent
from strands_tools import calculator

agent = Agent(
    model="qwen.qwen3-coder-480b-instruct-v1:0",
    tools=[calculator]
)

agent("Tell me the square root of 42 ^ 9")

with open("function.py", 'r') as f:
    my_function_code = f.read()

agent(f"Help me optimize this Python function for better performance:\n\n{my_function_code}")

Now available
Qwen models are available today in the following AWS Regions:

  • Qwen3-Coder-480B-A35B-Instruct is available in the US West (Oregon), Asia Pacific (Mumbai, Tokyo), and Europe (London, Stockholm) Regions.
  • Qwen3-Coder-30B-A3B-Instruct, Qwen3-235B-A22B-Instruct-2507, and Qwen3-32B are available in the US East (N. Virginia), US West (Oregon), Asia Pacific (Mumbai, Tokyo), Europe (Ireland, London, Milan, Stockholm), and South America (São Paulo) Regions.

Check the full Region list for future updates. You can start testing and building immediately without infrastructure setup or capacity planning. To learn more, visit the Qwen in Amazon Bedrock product page and the Amazon Bedrock pricing page.

Try Qwen models on the Amazon Bedrock console now, and offer feedback through AWS re:Post for Amazon Bedrock or your typical AWS Support channels.

Danilo

DeepSeek-V3.1 model now available in Amazon Bedrock

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/deepseek-v3-1-now-available-in-amazon-bedrock/

In March, Amazon Web Services (AWS) became the first cloud service provider to deliver DeepSeek-R1 in a serverless way by launching it as a fully managed, generally available model in Amazon Bedrock. Since then, customers have used DeepSeek-R1’s capabilities through Amazon Bedrock to build generative AI applications, benefiting from the Bedrock’s robust guardrails and comprehensive tooling for safe AI deployment.

Today, I am excited to announce DeepSeek-V3.1 is now available as a fully managed foundation model in Amazon Bedrock. DeepSeek-V3.1 is a hybrid open weight model that switches between thinking mode (chain-of-thought reasoning) for detailed step-by-step analysis and non-thinking mode (direct answers) for faster responses.

According to DeepSeek, the thinking mode of DeepSeek-V3.1 achieves comparable answer quality with better results, stronger multi-step reasoning for complex search tasks, and big gains in thinking efficiency compared with DeepSeek-R1-0528.

Benchmarks DeepSeek-V3.1 DeepSeek-R1-0528
Browsecomp 30.0 8.9
Browsecomp_zh 49.2 35.7
HLE 29.8 24.8
xbench-DeepSearch 71.2 55.0
Frames 83.7 82.0
SimpleQA 93.4 92.3
Seal0 42.6 29.7
SWE-bench Verified 66.0 44.6
SWE-bench Multilingual 54.5 30.5
Terminal-Bench 31.3 5.7
(c)
https://api-docs.deepseek.com/news/news250821

DeepSeek-V3.1 model performance in tool usage and agent tasks has significantly improved through post-training optimization compared to previous DeepSeek models. DeepSeek-V3.1 also supports over 100 languages with near-native proficiency, including significantly improved capability in low-resource languages lacking large monolingual or parallel corpora. You can build global applications to deliver enhanced accuracy and reduced hallucinations compared to previous DeepSeek models, while maintaining visibility into its decision-making process.

Here are your key use cases using this model:

  • Code generation – DeepSeek-V3.1 excels in coding tasks with improvements in software engineering benchmarks and code agent capabilities, making it ideal for automated code generation, debugging, and software engineering workflows. It performs well on coding benchmarks while delivering high-quality results efficiently.
  • Agentic AI tools – The model features enhanced tool calling through post-training optimization, making it strong in tool usage and agentic workflows. It supports structured tool calling, code agents, and search agents, positioning it as a solid choice for building autonomous AI systems.
  • Enterprise applications – DeepSeek models are integrated into various chat platforms and productivity tools, enhancing user interactions and supporting customer service workflows. The model’s multilingual capabilities and cultural sensitivity make it suitable for global enterprise applications.

As I mentioned in my previous post, when implementing publicly available models, give careful consideration to data privacy requirements when implementing in your production environments, check for bias in output, and monitor your results in terms of data security, responsible AI, and model evaluation.

You can access the enterprise-grade security features of Amazon Bedrock and implement safeguards customized to your application requirements and responsible AI policies with Amazon Bedrock Guardrails. You can also evaluate and compare models to identify the optimal model for your use cases by using Amazon Bedrock model evaluation tools.

Get started with the DeepSeek-V3.1 model in Amazon Bedrock
If you’re new to using the DeepSeek-V3.1 model, go to the Amazon Bedrock console, choose Model access under Bedrock configurations in the left navigation pane. To access the fully managed DeepSeek-V3.1 model, request access for DeepSeek-V3.1 in the DeepSeek section. You’ll then be granted access to the model in Amazon Bedrock.

Next, to test the DeepSeek-V3.1 model in Amazon Bedrock, choose Chat/Text under Playgrounds in the left menu pane. Then choose Select model in the upper left, and select DeepSeek as the category and DeepSeek-V3.1 as the model. Then choose Apply.

Using the selected DeepSeek-V3.1 model, I run the following prompt example about technical architecture decision.

Outline the high-level architecture for a scalable URL shortener service like bit.ly. Discuss key components like API design, database choice (SQL vs. NoSQL), how the redirect mechanism works, and how you would generate unique short codes.

You can turn the thinking on and off by toggling Model reasoning mode to generate a response’s chain of thought prior to the final conclusion.

You can also access the model using the AWS Command Line Interface (AWS CLI) and AWS SDK. This model supports both the InvokeModel and Converse API. You can check out a broad range of code examples for multiple use cases and a variety of programming languages.

To learn more, visit DeepSeek model inference parameters and responses in the AWS documentation.

Now available
DeepSeek-V3.1 is now available in the US West (Oregon), Asia Pacific (Tokyo), Asia Pacific (Mumbai), Europe (London), and Europe (Stockholm) AWS Regions. Check the full Region list for future updates. To learn more, check out the DeepSeek in Amazon Bedrock product page and the Amazon Bedrock pricing page.

Give the DeepSeek-V3.1 model a try in the Amazon Bedrock console today and send feedback to AWS re:Post for Amazon Bedrock or through your usual AWS Support contacts.

Channy

The Truth About Cloud Security Costs: Why High Costs Don’t Always Mean Better Protection

Post Syndicated from Kari Rivas original https://www.backblaze.com/blog/the-truth-about-cloud-security-costs-why-high-costs-dont-always-mean-better-protection/

A decorative image showing a shield and gears.

When evaluating cloud providers, cost is often the most visible factor—but in enterprise IT, information security (InfoSec), and compliance, security is always the first (and likely most important) concern. As a technology leader, you know that determining “acceptable” risk is a moving target, but you’re likely also regularly squeezed by budget pressures and a mandate to contribute to the company’s bottom line. 

Taking a chance on providers with lower price tags might feel like too big of a risk—lower-cost providers must be sacrificing something, and all too often, that something is security. Right?

It’s a fair question, but the answer might surprise you. Today, we’re talking about how specialized cloud providers provide surprising value—and even provide security benefits—when compared with traditional, hyperscaler architectures. Let’s talk about what you need to know to evaluate a cloud provider’s security posture.

Want to hear from the experts?

Join our upcoming session to hear from Backblaze experts Troy Liljedahl, Sr. Director, Solutions Engineering, and Pat Patterson, Chief Technical Evangelist, about the knowledge and features you need to stay ahead of modern threats.

Join us to learn:

  • Foundational controls: Master the best practices for using encryption, Object Lock, access keys, role-based access controls, and more to build a solid defense.
  • Advanced threat detection: Get an exclusive look at Backblaze’s new feature, Anomaly Alerts, which helps detect irregular and potentially suspicious data access patterns.
  • A unified approach: Understand how to integrate these powerful features to create a strong, easy-to-manage security strategy.

Ask the Experts

How specialized cloud providers provide security benefits

In theory, cloud architecture encourages redundancy. But in practice, many companies—even those using multi-cloud strategies—tend to consolidate key services like authentication and orchestration with a single vendor. When that vendor’s services go down, it doesn’t matter that your data is replicated across three availability zones in the same data center. If you can’t log in to access it, your redundancy becomes purely theoretical. This year alone, there have been major outages that had widespread consequences from the likes of Google, IBM cloud, and others.

Specialized cloud providers and multi-cloud strategies provide inherent benefits here.

  • Vendor transparency: Open cloud providers publish clear, detailed practices around architecture, encryption, and compliance rather than burying them behind opaque marketing claims. This transparency allows your teams to independently validate security assurances.
  • Avoiding lock-in: Multi-cloud strategies ensure you’re not beholden to a single vendor’s security practices. If one provider falls short, data replication and redundancy across platforms can maintain both compliance and resilience.
  • Risk distribution: By spreading workloads across providers, organizations mitigate the risk of a single point of failure, outage, or vendor breach.
  • Compliance flexibility: Different providers may align more strongly with specific frameworks (SOC 2, HIPAA, GDPR, etc.), giving enterprises options to meet evolving regulatory demands.

This means that organizations don’t have to choose between cost efficiency and security—they can and should get both.

How to evaluate a cloud provider’s security posture

Choosing the right cloud provider isn’t just about price, features, or performance—it’s about knowing they can safeguard your data and prove it. Here are key areas to assess:

  1. Architecture & physical security
    • Does the provider operate its own infrastructure or rely on generic colocation facilities?
    • What physical safeguards (biometrics, restricted access, surveillance) protect the data centers?
  2. Encryption & data protection
    • Is data encrypted both in transit (TLS/SSL) and at rest (AES-256 or equivalent)?
    • Are key management options available, including customer-managed keys?
    • Is immutability (Object Lock or write once, read many (WORM) storage) supported for ransomware defense?
  3. Access & identity controls
    • Are granular permissioning and role-based access (RBAC) controls available?
    • Does the provider support single sign on (SSO), multi-factor authentication (MFA), and integration with enterprise identity systems?
    • Can admins maintain clear audit logs of all access and changes?
  4. Compliance & certifications
    • Which third-party attestations does the provider maintain (SOC 2, HIPAA, PCI-DSS, GDPR, ISO)?
    • Can they provide signed agreements (such as Business Associate Agreements (BAAs)) as needed for regulated industries?
  5. Resilience & multi-cloud strategy
    • Do they offer replication across regions or the ability to integrate into a multi-cloud strategy?
    • How quickly can you move workloads or data out if you need to change vendors or access data in case of emergency?

By using this evaluation framework, IT leaders can look past marketing promises and price tags, focusing on verifiable controls and independent certifications.

The hyperscaler tax for cloud security

Many enterprises assume that higher cloud storage costs from hyperscalers like AWS, Azure, or Google Cloud translate directly into better security. In reality, much of that premium is a “hyperscaler tax” driven by complex business models, bundled services, and legacy infrastructure—not inherently superior protection. Specialized cloud providers can often deliver the same enterprise-grade security controls—encryption, compliance certifications, access management—without the inflated price tag, proving that security and affordability are not mutually exclusive.

Building a better mousetrap: The innovation behind Backblaze B2

From the beginning, Backblaze has architected its storage solution to be both performant and cost-effective. And, by specializing in storage (as opposed to the myriad of solutions offered by, say, Amazon Web Services and other hyperscalers), Backblaze is able to optimize for the economics of storage and storage alone.

To help you get past the price tag and into the technical details, let’s break down the pillars of Backblaze B2 security and compliance.

Compliance? We’ve got a visual for that.

Want a quick glance on how Backblaze compares to other cloud storage providers on key security and compliance elements? Check out our comparison matrices.

Architecture and physical security: The foundation of trust

Our security starts with our physical infrastructure. Our data centers are designed for 11 nines of data durability and are staffed 24/7/365. They feature:

  • Best-in-class security features: Biometric security, ID checks, and multi-layered access controls.
  • A purpose-built infrastructure: From Backblaze Storage Pods to projects like Shard Stash and ongoing feature releases, the Backblaze platform is designed for maximum data durability and security.

This physical and architectural security is the bedrock of our service, and it’s backed by industry-standard certifications like SOC 2 Type 2 certification.

Data storage security: Protecting data at rest and in transit

Data security is a core tenet of our platform. From the moment your data leaves your system until it is stored on our pods, it is protected by multiple layers of encryption.

  • Encryption in transit: All files are transmitted to Backblaze B2 using an encrypted TLS connection.
  • Encryption at rest: Your data is encrypted before it is stored on disk. We offer two options for server-side encryption with 256-bit Advanced Encryption Standard (AES-256):
    • Server-side encryption (SSE) with Backblaze managed keys (SSE-B2): We handle the key management for you, providing seamless, built-in protection.
    • SSE with customer managed keys (SSE-C): For organizations with strict compliance requirements, you can manage your own keys, giving you complete control over your data’s access.
  • Object Lock for immutability: Our Object Lock feature provides a powerful layer of ransomware protection. Using a write-once, read-many (WORM) model, it prevents files from being modified, manipulated, or deleted for a customer-determined retention period. This is an essential tool for compliance and disaster recovery.
  • Cloud Replication: For businesses with high-availability or geographical redundancy requirements, Backblaze B2 supports automatic replication of data across different regions, ensuring your data is always available and safe from regional outages or other incidents.

Access management security: Granting control and ensuring accountability

Controlling who can access your data is paramount. We provide granular, enterprise-grade access management controls that give you full command over your storage:

  • Fine-grained API key control: Create and manage accounts, groups, and specific data access permissions with robust API key control.
  • Multi-factor authentication (MFA) & single sign-on (SSO): We offer multiple account authentication options, including MFA and SSO via providers like Google Workspace and Office 365, to prevent unauthorized access.
  • Comprehensive logging: Backblaze provides detailed logs and reports on all activities within your account, so you can maintain a clear audit trail.

Compliance: Demonstrating our commitment to best practices

Security is not just a feature; it’s a commitment that’s verified by independent third parties. Backblaze has achieved a number of security and compliance attestations, including:

  • SOC 2, Type 2: We have been independently audited and certified for SOC 2, Type 2 compliance, demonstrating our commitment to protecting customer data.
  • HIPAA: For business customers who are Covered Entities under the Health Insurance Portability and Accountability Act (HIPAA), we can provide a Business Associate Agreement (BAA) upon request.
  • PCI-DSS: Backblaze’s adherence to the Payment Card Industry Data Security Standard (PCI-DSS) is supported by our use of Stripe to handle card information and our internal security controls.
  • GDPR: We adhere to General Data Protection Regulation (GDPR) privacy policies and provide Data Processing Agreement Addendums (DPAs) for EEA/EU and UK residents.

While some competitors may also offer these certifications, Backblaze’s pricing model is built to ensure you don’t have to pay a premium for them. Our efficiencies mean that we can pass the savings directly to you without compromising on the security and compliance that your business demands.

Specialized cloud storage: Enabling enterprises to evaluate their best options

In the end, our goal is to free you from the false choice between security and affordability. The reality is that the high cost of some cloud providers is a result of their complex, multi-tiered business models—not a reflection of superior security. Backblaze’s commitment to building a focused, innovative, and transparent cloud storage solution allows us to deliver on our promise: enterprise-grade security and compliance, at a fraction of the cost.

The post The Truth About Cloud Security Costs: Why High Costs Don’t Always Mean Better Protection appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Archiving: The Steady Driver of Media & Entertainment Storage

Post Syndicated from Laquie TN Campbell original https://www.backblaze.com/blog/archiving-the-steady-driver-of-media-entertainment-storage/

A decorative image showing media icons on a gradient background.

Industry research consistently shows that archiving and preservation remain the largest drivers of storage demand in media and entertainment workflows. As of 2024, archiving—including both new and historical assets—accounts for the majority of digital storage capacity. 

This reflects an ongoing reality: Every production adds new terabytes of content, and studios/vendors are responsible for keeping it safe and usable long-term. And, for many M&E teams, traditional LTO tape libraries represent a cumbersome way to manage vast (and growing) archives. 

Increasingly, the decision is less whether to adopt cloud, and more how to use it responsibly. For some, that means hybrid systems that balance performance and scalability. For others, particularly smaller studios, cloud may become the backbone of both active and deep archives.

Free ebook: Why Media Workflows Are Embracing Cloud Storage—On Their Own Terms

Cloud media workflows are quick to promise a solution, but it’s more important for you to learn how to navigate. Read our ebook on how to use the cloud to best serve you and your team.

Your Media, Your Way

Why archiving dominates conversations—and what makes it so complex

Long-term preservation isn’t a “set-and-forget” task—technology evolves, file formats age, and migration becomes as essential as storage itself. Meanwhile, the shift to 4K, 8K, HDR, and immersive content means productions routinely generate petabytes of material. 

The challenge isn’t just volume, but ensuring ongoing integrity, accessibility, and migration compatibility over decades. That makes both current trends in file creation and future-proofing archives an active task. 

While the challenge can look different to different types of M&E teams, there are benefits for all of them:  

  • For editors and post-production teams, active archives keep high-resolution footage readily available, eliminating the frustration of digging through cold storage when a quick edit or repurposing request comes in.
  • For media asset managers, they transform archives into searchable, metadata-rich repositories that reduce retrieval time and prevent costly duplication of content.
  • For executives and producers, active archives protect past investments by making legacy assets easily accessible for remonetization in new markets, remasters, and marketing campaigns.
  • For IT and workflow engineers, they provide automated tiering and integration across on-prem and cloud systems, ensuring scalable performance without ballooning infrastructure costs.

Still, a recent NAB survey showed that archive capacity remains a challenge for 85% of respondents. Searchability is another weak spot, with some teams still relying on spreadsheets.

Why cloud adoption has been cautious

Although cloud storage offers flexibility, adoption in the M&E industry has been measured. Common concerns include:

  • High egress costs: Many providers charge significant fees for retrieving archived data. For media workflows that often involve moving large files in and out of storage, these costs can add up quickly.
  • Performance concerns: Latency and bandwidth limitations can disrupt workflows, especially in post-production environments that rely on fast access to high-resolution files.
  • Unpredictable workflows: Unlike enterprise archives where files may be rarely accessed, media archives are often “active.” Teams may suddenly need terabytes of content for a remastering project or marketing campaign. Cloud pricing models built around cold storage don’t always align well with this reality.
  • Trust and security: Especially in the early years of cloud, concerns around data sovereignty, intellectual property protection, and compliance slowed adoption. While cloud providers have strengthened their credentials in these areas, trust remains a consideration.
  • Established investments in on-prem: Many organizations already have significant capital invested in tape libraries, network attached storage (NAS), storage area network (SAN) systems, or colocation setups, making the shift to cloud a long-term transition rather than an overnight change.

How the cloud can help

The shift from “traditional” production to newer technologies in content filming and creation—including both hardware and software tools—leaves many M&E teams with several, competing demands for their tech stacks. Cloud workflows can offer significant benefits for scalability, searchability, and budget management.

Elastic capacity

Cloud removes the need for large upfront capital investments and scales as archives grow. For organizations with fluctuating storage needs, this flexibility is particularly valuable.

Cost-tiering options

Cloud services now offer multiple archival tiers—from “hot” to “deep archive”—allowing teams to balance cost with access needs. Combined with lifecycle management policies, this helps align budgets with actual usage.

Hybrid approaches

The most common strategy today is hybrid: keeping frequently accessed assets on-premises or in private cloud, while offloading less active content to public cloud. Surveys show hybrid adoption has grown significantly in the last five years, with expectations that it will continue to rise.

Collaboration and accessibility

For global teams, cloud improves accessibility. Editors, producers, and marketing teams in different regions can access the same archival assets without relying on physical transfers, VPNs, or duplicated storage.

AI-enabled metadata

Cloud platforms also support AI and ML services that enrich metadata. This transforms archives from passive repositories into searchable, discoverable libraries—unlocking new value from existing content.

The future of media archiving is in the cloud

The move to cloud is gradual, shaped by cost, performance, and workflow realities. Yet the volume and importance of archives—and cloud-based workflows—continue to grow. When paired with thoughtful strategies, cloud storage offers a flexible way to manage that growth while unlocking new creative value.

By designing storage approaches that balance innovation with practicality, M&E teams can ensure archives remain accessible, secure, and ready to support the next generation of storytelling.

The post Archiving: The Steady Driver of Media & Entertainment Storage appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Introducing an Interactive Code Review Experience with Amazon Q Developer in GitHub

Post Syndicated from Sundaresh Iyer original https://aws.amazon.com/blogs/devops/introducing-an-interactive-code-review-experience-with-amazon-q-developer-in-github/

Code reviews are one of the most valuable rituals in software development. They help ensure quality, maintain consistency, and foster growth as engineers. But they’re also one of the most time consuming steps in the software development lifecycle. A common pattern I’ve seen is a developer opening a pull request (PR), receiving automated or peer comments, and then needing to search through documentation, Slack threads, or past code just to understand why a change was suggested. That search for missing context creates a friction that slows teams down, adds back-and-forth cycles, and often distracts from the bigger picture of building great products.

In the initial preview experience, teams used Amazon Q Developer in GitHub across issues and PRs for feature work, automated code reviews, and common modernization tasks. This kept work inside GitHub and reduced handoffs. Automatic reviews on new or reopened PRs surfaced findings early, but teams still wanted more context and a tighter loop inside the PR.

Today we’re introducing an interactive code review experience for PRs You can ask Amazon Q Developer questions about any finding using /q, see a concise summary with threaded findings, and apply suggested changes without leaving GitHub. Code reviews by Amazon Q Developer now complete quicker than before, which reduces wait time and shortens the review cycle so teams can merge sooner and spend more time building.

What’s new and why it matters

  • Interactive Conversations in the pull request: Comment with /q to get inline answers, or ask Q Developer to propose a code change you can apply in the PR. For example:/q explain this finding or /q propose a change that replaces class toggles with a data attribute for state.
  • Code review summaries with threaded findings: Each code review begins with a concise summary and findings are threaded underneath. This makes updates easier to follow and reduces noise.
  • Faster execution with clearer notifications: Amazon Q Developer completes its analysis quicker and notifications are organized and easier to scan. This reduces wait time and shortens the review cycle.
    When you create or open a new PR, Amazon Q Developer automatically starts a code review if the code review feature is enabled for your GitHub installation in the Amazon Q Developer console. Subsequent commits do not trigger another automatic review. To run a fresh analysis, post /q review as a new comment on the PR.

Getting Started with Amazon Q Developer in GitHub

To get started, install the Amazon Q Developer GitHub App in your GitHub organization or repository. The app is available through the GitHub Marketplace and can be used without an AWS account during the preview. During installation, you choose whether to provide access to all repositories or only selected repositories in your GitHub organization. You can increase free usage by registering the app installation in the Amazon Q Developer console.
For more details on installation, permissions, and configuration options, see the Amazon Q Developer for GitHub documentation. Once the app is installed, you can begin using Q Developer to review PRs automatically.

Using Amazon Q Developer in Pull Requests

To dive deeper, here’s an end-to-end walk-through of the new interactive code review experience using a simple card game I built with Amazon Q Developer.

  1. Create a new pull request : In this example, I started by creating a feature branch and named it demo, added atailwind.css file to the JavaScript and HTML card game app, pushed the branch, and opened a PR for review.
    • GitHub interface showing the creation of a new pull request for a demo branch, with changes to a tailwind.css file in a card game application
  2. Amazon Q Developer automatically starts a code review, analyzing code quality, potential issues, and adherence to best practices. A concise summary appeared at the top, with individual findings threaded underneath. This gave me the big picture and the specifics in one place.
    •  GitHub pull request interface showing a notification that Amazon Q Developer has automatically initiated a code review and is analyzing the changes, with a progress indicator
    • GitHub interface displaying Amazon Q Developer's completed review with a concise summary at the top and detailed findings organized in threaded comments below, highlighting code quality issues and suggested improvements
  3. Code review the summary and findings: I reviewed the summary and threaded findings to decide which change to take on first. Seeing both the rationale and the exact lines called out meant I knew where to begin, without hunting through files.
    •         GitHub interface showing Amazon Q Developer's threaded findings, where each finding is organized as a separate comment thread with detailed explanations of identified issues in the code
    •        
  4. Ask for Clarification with /q : One of the findings suggested using state property to track the card status in my card game application. so I asked Q Developer for clarification. It responded quickly with concrete context and pointers, which reduced back and forth and improved the quality of the review.
    •         Screenshot showing a conversation thread where a developer uses the /q command to ask Amazon Q Developer for clarification about state property implementation in the card game
    •         GitHub interface displaying Amazon Q Developer's detailed response to the clarification request, providing context and specific explanations about the state property implementation recommendation
  5. Continue the conversation (if needed) : I reviewed Q Developer’s suggestion and responded back stating that I preferred an alternate approach and Q Developer quickly returned a complete implementation I could apply in the PR
    •      GitHub interface showing a follow-up exchange between the developer and Amazon Q Developer, where the developer proposes an alternate approach and receives implementation suggestions
  6. Apply Fixes : After reviewing the implementation suggestion, I clicked on Commit suggestion to create a new commit on the PR branch with my username as the author.
  7. Re-run the review : I didn’t need this for my example, but if you push additional changes, you can run a fresh analysis by posting /q review as a new top-level comment. Q Developer will run the review and post updated findings.

With the code review complete and checks passing, I merged. The new interactive code review experience reduced wait time and review cycles and made the “why” behind each finding and suggested change clear.

Conclusion

Amazon Q Developer for GitHub is available today in preview. Whether you are an individual developer or part of a large engineering team, this update helps you ship cleaner code with fewer cycles and makes code reviews something to look forward to rather than avoid.
Try it out on your next PR. Type /q, ask a question, and see how smarter conversational reviews transform your workflow.

Stack to Win: A Powerful Solution for Sports Media Production

Post Syndicated from Dave Simon original https://www.backblaze.com/blog/stack-to-win-a-powerful-solution-for-sports-media-production/

A decorative image showing the text Stack to Win with Boomer Esiason. In the background, the logos for Backblaze, Suite Studios, and Iconik are displayed on media screens.

I recently joined an incredible group of thought leaders for a panel discussion on the future of sports media. Hosted by sports commentator and former NFL MVP Boomer Esiason, our Stack to Win panel featured Jeremy Strootman from Iconik, Jay Maxwell from Suite Studios, the NFL’s VP of Broadcasting Mike North, and me—Dave Simon from Backblaze. Together, we explored the complexities of modern sports content creation and how our integrated cloud-native solutions from Backblaze B2, Iconik, and Suite offer a powerful blueprint for radically streamlining workflows and unlocking new opportunities for efficiency, speed, and monetization.

The traditional, linear model of sports media production is a thing of the past. It’s been completely changed by new technology and a shift in what fans expect. Today, media teams are in a real-time battle for attention against every other form of entertainment. This new world demands a different kind of setup, one that’s built for the cloud and designed to handle the entire media lifecycle. The solution we’ve built, a powerful combination of Backblaze, Iconik, and Suite Studios, is exactly that. It’s the playbook for staying ahead.

Watch the full interview

There’s so much more that we could summarize in just one blog post. Check out the full video below:

The (data) problem

Game day content is immense—we’re talking 6–7TB of data nightly. In the past, this was a logistical nightmare. As Jeremy Strootman from Iconik pointed out, “It used to be we’d get a hard drive and I’d get a hard drive, and we made sure that we just took different flights on the way home. It was literally that archaic.” When speed is everything, old methods like shipping hard drives are a huge liability.

This pressure comes from fans who have an insatiable appetite for content across every platform imaginable. They expect teams to produce their own content in real-time for streaming and social media. For many, the “second screen” is now the main screen, with 73% of fans using mobile apps for real-time updates during live events. If your workflow is slow, you’ve already lost the competition.

The definition of sports content has also expanded. It’s no longer just about the game itself, but also the stories around it—the players’ lives and the team’s entire ecosystem. Jay Maxwell of Suite Studios captured this perfectly:

The product is not just what’s on the field anymore. It’s also what’s going on in these, you know, athletes lives, what’s going on in the peripheries of the team and the organizations.
—Jay Maxwell, Co-Founder and Chief Product Officer, Suite Studios

This includes pop culture crossovers, fantasy sports, and in-game betting, all of which demand instant video highlights.

A great example of this is when Eagles wide receiver AJ Brown was spotted reading a book called “Inner Excellence” on the sidelines. The moment went viral, and the book, which was previously ranked 585,000 on the bestseller list, vaulted to number one instantly. As the NFL’s Mike North noted, this is how fans can instantly “go deeper” and connect with their favorite players. The ability to capture and distribute these moments instantly is a fundamental requirement for success.

A modern technology stack

An integrated, cloud-native tech stack provides a seamless workflow that removes risk and speeds up the content pipeline. It’s a powerful combination of three key layers:

1. Foundation: The active cloud archive

Modern media workflows are built on a cloud storage foundation that replaces old systems like tape libraries and shelves full of hard drives. The key is an active cloud archive that gives you instant access to your footage. This eliminates the costly delays of older solutions and offers predictable costs, so you never get hit with surprise fees when you need to access your own content.

2. Intelligence: Media Asset Management (MAM)

This is the smart layer that makes your vast archive searchable and valuable. Instead of producers manually sifting through hours of footage, a multimodal AI search engine can find the exact clip they need in seconds. As Dave Simon explained, you can use a natural language search to describe exactly what you’re looking for, such as “Jerry Rice catching a ball over his left shoulder wearing a white jersey”. AI tools in a media stack can automatically transcribe interviews, search for specific quotes, and even identify abstract concepts like emotion or reframe a video for different social media platforms.

3. Accelerator: Real-time cloud editing

This component handles the final stage of production, allowing editors to access high-resolution media without a download delay. This technology streams data directly from the cloud, so editors can start working immediately. This is how a remote team can instantly cut and create content from footage uploaded on the field. 

The real magic is all of these elements combined: A clip is only useful if an editor can work with it right away, and a huge archive is only valuable if you can find what’s in it. This is a single, cohesive system that manages the entire media lifecycle from start to finish.

Reshaping the business of sports

Adopting a modern tech stack empowers rights holders—leagues, teams, and athletes—to manage and distribute content on a massive scale. They can bypass traditional media gatekeepers and build direct relationships with their fans. This opens up several possibilities, such as: 

  • Archive monetization. Vast archives, once a simple cost center, have now become a major source of revenue. With an accessible, intelligent archive, organizations can unlock new revenue streams.
  • Licensing storefronts: You can create B2B portals for broadcasters and filmmakers to license and download footage, which essentially creates a self-service revenue engine.
  • Direct-to-consumer (DTC) fan platforms: Launch your own subscription services with exclusive access to historical games and behind-the-scenes content.
  • Free Ad-supported Streaming TV (FAST) channels: Program and launch FAST channels using repurposed archival content.
  • Creator economy partnerships: License parts of your archive to creators to reach new audiences and share in the revenue.
  • Enable the athlete as a media entity. This same technology is behind the rise of athletes as media producers. Today’s players are actively shaping their own stories and building media businesses. The low barrier to entry for these cloud workflows is the foundation of this movement, giving athletes the same scalable tools once reserved for major networks. A great example of this is Peyton Manning’s Omaha Productions, which started as a player-led media company and became a leader in the space.

The future fan experience

This revolution is transforming the fan experience from a one-way broadcast to something personal, interactive, and instant. The future of sports consumption is personalized feeds tailored to individual interests. As Mike North noted, “You don’t really need to watch the game anymore to still be a fan.” For a fan who wants to know everything about a player, a custom feed can be created. For a fantasy football enthusiast, clips and highlights related to their team can be pushed to them in real time.

The experience will also be interactive. Streaming platforms are already using augmented reality (AR) overlays and multi-angle camera views. The next step, powered by AI and accessible archives, is allowing fans to directly ask for content, like, “‘Show me all the Hail Mary plays from this season?’” and instantly get a custom playlist. This shifts passive viewing into active exploration.

For any sports organization, the biggest risk is standing still and maintaining the status quo. As Jay Maxwell put it, “The barrier to entry to try is, you know, cheap if not free.” An integrated, cloud-native workflow isn’t just a competitive advantage—it’s the fundamental requirement for survival and success.

Check out the full solution below:

The post Stack to Win: A Powerful Solution for Sports Media Production appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Cloud Storage Myths Debunked, Part Four: Managing Multiple Clouds Is Too Complicated

Post Syndicated from David Johnson original https://www.backblaze.com/blog/cloud-storage-myths-debunked-part-four-managing-multiple-clouds-is-too-complicated/

A decorative image showing multiple types of storage media.

Today’s myth feels familiar, because it’s exactly what major cloud providers want you to believe:

Multi-cloud? Sounds like a recipe for chaos. Best stick with one and avoid the hassle.

On the surface, it sounds reasonable. The “big three” clouds promote their all-in-one ecosystems as seamless and unified. One provider, one bill, one console. That should make life easier, right?

Not so fast. The promise of simplicity often hides a different reality: deep complexity, rigid architecture, and vendor lock-in. For many cloud-native teams, what’s pitched as convenience ends up costing time, money, and agility.

This is the final post in our blog series debunking persistent myths about cloud storage. (You can read the first, second, and third articles in the series to get up-to-date.) And, if you’ve ever been told that multi-cloud is messy or risky, this one’s for you.

New Cloud Native Times Call for New Cloud Storage Approaches

Learn more about how the open cloud supports faster development, improved workflows, and reduced cost complexity in our free ebook, “New Cloud Native Times Call for New Cloud Storage Approaches.”

Get the Ebook

Integrated ≠ simple

The idea that one provider equals less overhead is seductive. But in practice, integration can mean entanglement. Instead of reducing operational drag, it creates a tightly woven web of interdependent services and proprietary systems, which makes changes slow and expensive.

The all-in-one trap

Big cloud providers’ platforms are sprawling by design. They’re built to meet every need under one roof. However, the supposed benefit of simplicity falls apart once you actually start using that provider’s full range of services. 

When it comes to storage alone, teams must navigate:

  • Multi-tier systems (hot, cool, cold) with different costs, speeds, and access methods, each requiring its own performance and cost configuration.
  • Complex lifecycle policies and scripts to automate data movement between tiers.
  • Intricate IAM setups to manage roles, policies, and permissions across services.
  • Proprietary APIs and tooling that create migration headaches and limit portability.
  • Console UIs and behaviors that change depending on region or storage class, adding to the learning curve.
  • Deep interdependencies across services, where a small change in storage can ripple through compute, networking, and security layers.

What starts as a unified experience quickly becomes a maze of shifting rules and unstable configurations. And the more deeply your architecture relies on these moving parts, the more frustrating your operations become.

Frustration, not flexibility

Not only is it tedious to manage all of this, but it can be risky. Miss a lifecycle rule, and you might incur unexpected fees. Misconfigure access policies, and you could lose visibility into or even access to your own data.

These aren’t edge cases. They’re everyday realities in cloud-native environments where time is tight, systems are complex, and DevOps teams are stretched thin. Here’s what that might look like in practice:

  • A developer spins up a test environment without realizing data is landing in a high-cost tier.
  • An SRE responds to a latency issue, only to discover the data lives in cold storage and restoring it generates retrieval costs and delays.
  • A backup job fails silently because of a permissions misconfiguration buried deep in nested IAM roles.

And when something breaks, support isn’t always fast or personal. Unless you’re a top-tier customer, you’re likely working through ticketing systems, documentation loops, or community forums.

These moments don’t just cause frustration—they drain time, inflate costs, and hinder your team’s ability to move fast with confidence.

Complexity isn’t a multi-cloud problem. It’s a design problem.

Let’s revisit the myth: Multi-cloud is too complicated.

It’s an understandable concern, but one that’s often based on frustration inside a major cloud provider’s ecosystem. When teams talk about complexity, they’re usually describing the friction that comes from navigating sprawling services, managing brittle configurations, and troubleshooting opaque policies within one provider.

The real issue isn’t how many clouds you use. It’s how much complexity one provider can introduce when you try to adapt, integrate, or scale. Vendor-specific tooling, tightly coupled services, and unpredictable costs create the illusion of simplicity—until you need to do something the platform didn’t anticipate.

That’s not a multi-cloud problem. That’s a design problem.

Making multi-cloud work for you

For many teams, multi-cloud isn’t a grand strategy, but something that happens organically. AI workloads move to GPU providers. Content gets delivered through specialized CDNs. Backups shift to more cost-effective and geographically separated storage. Whether by design or necessity, most modern architectures already span multiple clouds.

So the smarter question isn’t “Should we avoid it?” It’s “How do we make it sustainable without adding unnecessary complexity?”

That’s where Backblaze B2 comes in.

Backblaze B2 is purpose-built to make multi-cloud not only possible, but practical—for DevOps, SREs, and developers alike. It’s focused, interoperable, and refreshingly straightforward:

  • Always-hot storage: No tier juggling. No lifecycle scripts. Just fast, consistent access.
  • S3-compatible APIs: Seamlessly integrates with the tools and platforms you already use, such as Terraform, Kubernetes, ArgoCD, boto3, and more.
  • Streamlined IAM and UI: Control access and monitor usage without wading through layers of enterprise-grade configuration.
  • Free egress: Move data where you need it and when you need to, without the surprise charges that make multi-cloud cost-prohibitive.

Many teams start small with offloading archives, mirroring backup buckets, or feeding GPU pipelines for AI training. As modular architectures grow, Backblaze B2 scales with them, but without the rigidity or lock-in.

In fact, a 2025 Enterprise Strategy Group study found that many operational tasks, such as storage deployments, storage management, and integration with the hardware and software that they already used took up to 92% less time.

The simple interface contrasted sharply with other Cloud Service Providers’ interfaces that have confusing navigation and multiple options to sort through.

—Enterprise Strategy Group, “Analyzing the Economic Benefits of the Backblaze B2 Cloud Storage Platform,” May 2025.

Multi-cloud doesn’t have to be messy. With the right storage layer, it becomes your cleanest, most strategic advantage.

Want to dig even deeper?

Download the full ebook New Cloud-Native Times Call for New Cloud Storage Approaches to explore how modular, interoperable strategies are changing the cloud-native game.

The post Cloud Storage Myths Debunked, Part Four: Managing Multiple Clouds Is Too Complicated appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

The Gold Standard of Cloud Security: Why Our SOC2 Type 2 Compliance Sets Backblaze Apart

Post Syndicated from Kari Rivas original https://www.backblaze.com/blog/the-gold-standard-of-cloud-security-why-our-soc2-type-2-compliance-sets-backblaze-apart/

A decorative image showing a server, a drive, a NAS device, and a cloud.

As more organizations rely on the cloud to store critical data, the stakes around compliance and security keep rising. Regulations like GDPR and HIPAA are putting pressure on businesses to demonstrate that their data handling practices are sound, and customers increasingly want evidence—not just assurances—that their data is protected.

Every cloud provider claims to be “secure.” But as a risk owner and decision-maker, you need more than a marketing tagline. You need proof. That’s where SOC 2 Type 2 compliance comes in. At Backblaze, we don’t just meet this benchmark—we go beyond it. Unlike many cloud storage providers (CSPs) that may have only SOC 2 compliant data centers, Backblaze has also undergone the rigorous SOC 2 assessment at the company level.

What is SOC 2, and why does it matter?

SOC 2 (aka System and Organization Controls) is an assessment created by the American Institute of Certified Public Accountants (AICPA). It evaluates how service providers operate based on Trust Services Criteria:

  • Security
  • Availability
  • Confidentiality
  • Privacy
  • Processing integrity

Every SOC 2 assessment includes Security as the foundation, and organizations may also be evaluated against additional criteria that align with their services. Our assessment covers both Security and Availability, demonstrating that our systems are protected against unauthorized access and are resilient, reliable, and consistently accessible when you need them.

At Backblaze, we’ve put the right controls in place to meet these standards, such as:

  • Strong access management policies.
  • Redundant infrastructure to protect uptime.
  • Regular penetration testing and incident response reviews.

The business impact? You can rely on us to keep your data safe and accessible—without adding unnecessary risk to your operations.

Type 1 vs. Type 2: A key distinction

There are two types of SOC 2 examinations:

  • Type 1 shows that a company has the right controls in place at a specific point in time.
  • Type 2 goes further by validating that those controls are consistently followed and effective over a defined period.

Backblaze has achieved and consistently maintained SOC 2 Type 2 compliance. That distinction matters—it means you’re not just trusting that we say the right things, but that we do the right things, day in and day out.

What SOC 2 compliance delivers

SOC 2 compliance isn’t just a checkbox exercise. It provides meaningful assurances that directly affect your business:

  • Risk mitigation: Independent validation that controls work as intended.
  • Trust and credibility: Confidence that your cloud provider takes security seriously.
  • Vendor due diligence: Simplifies compliance reviews for your team.
  • Data integrity & availability: Assurance that your data remains reliable and accessible.

In short, SOC 2 compliance reduces uncertainty—making it easier for you to move forward with cloud adoption and scale with confidence.

SOC 2 data centers vs. SOC 2 as a company

It’s important to distinguish between compliance at the data center level and compliance at the company level.

  • SOC 2 compliant data centers: These examinations focus on the physical facility—things like access controls, environmental monitoring, and fire suppression. Many CSPs rely on SOC 2 certified facilities.
  • SOC 2 compliance as a company: This examination covers the provider’s internal operations, including policies, processes, and personnel practices. It examines how the service is built, run, and maintained.

Backblaze offers both. Our data centers are SOC 2 compliant, and our company is also SOC 2 Type 2 compliant.

Think of it like a bank: Secure vaults are critical (data centers), but so are strong internal policies and trained staff (company compliance). And, of course, you want both. That’s what we call defense in depth—end-to-end assurance that reduces risk and builds trust.

Surprisingly, you’ll find that many CSPs have SOC 2 data centers, but do not hold SOC 2 compliance at the company level.

Inside the SOC 2 audit process

SOC 2 evaluations are performed by independent third-party CPA firms, which ensures the results are objective and credible. The process includes:

  1. Scoping: Identifying which systems and processes are reviewed.
  2. Control documentation: Recording policies and procedures.
  3. Evidence collection: Proving that controls are in place.
  4. Testing & evaluation: Verifying effectiveness over time.
  5. Reporting: Delivering findings in a formal report.

At Backblaze, this isn’t a one-and-done exercise. We undergo annual audits, maintain robust monitoring, and test our systems regularly. For example:

  • Incident response plans, playbooks, and processes are reviewed and updated as needed. 
  • Penetration testing, the public bug bounty program, and our vulnerability management processes are designed to proactively identify, evaluate, prioritize, and remediate potential vulnerabilities.   
  • Change management ensures updates don’t introduce unnecessary risk.

Each step reinforces our commitment to security and transparency—so you don’t have to take our word for it.

Policies that protect your data

Policies and processes are the backbone of an effective SOC 2 program. At Backblaze, these policies aren’t just written down; they’re embedded in how we operate every day.

Change management (Security, Availability)

Changes that impact our systems, infrastructure, or software are controlled, tested, and approved before release. This prevents unauthorized or accidental changes that could disrupt operations or compromise security. For customers, this means you can rely on a stable, reliable storage platform that won’t jeopardize your workflows.

Logging & monitoring (Security, Availability)

We log system activities, monitor access attempts, and alert on high priority security events around the clock. We have implemented features such as Anomaly Alerts to support notifying customers about  unusual file upload and download patterns. Bucket Access Logs give you visibility into who accessed your data and when—adding both accountability and an audit trail for incident response.

Media handling & drive destruction (Security)

Physical media like drives are tightly controlled throughout their lifecycle. When a drive reaches end-of-life, it undergoes a secure erasure process. If it is not able to be securely erased, the device is destroyed, ensuring data is completely unrecoverable.

Environmental security (Availability)

Protecting data also means protecting the environment where it lives. Our data centers are equipped with redundant power and cooling systems, fire suppression, and environmental monitoring. Facilities are staffed 24/7/365 to respond to incidents in real time. These measures ensure uptime and business continuity—even in the face of physical disruptions like outages or natural disasters.

Each of these policies maps directly back to Trust Services Criteria, but more importantly, they translate into reduced risk, stronger reliability, and greater peace of mind for your business.

Why Backblaze stands apart

If you’re evaluating cloud storage providers, you can request a copy of our SOC 2 Type 2 report through Whistic. Backblaze currently offers 3 profiles on Whistic: Education Industry profile link, EU Customers profile link, or All Other Customers profile link. Once you have signed up, or signed in, you will be able to view or download the applicable documents and questionnaires.

Backblaze’s combination of SOC 2 compliant data centers and company-wide SOC 2 Type 2 compliance provides a higher level of assurance than many providers offer. That additional assurance is a powerful differentiator, especially for businesses in regulated industries.

And we’re not stopping here. Security isn’t static. We commit to annual assessments, continuous monitoring, and adapting to new threats as they emerge—so you can trust that your data is in good hands today, tomorrow, and beyond.

The post The Gold Standard of Cloud Security: Why Our SOC2 Type 2 Compliance Sets Backblaze Apart appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Cloud Storage Myths Debunked, Part Three: Onboarding Specialized Providers Is Too Hard

Post Syndicated from David Johnson original https://www.backblaze.com/blog/cloud-storage-myths-debunked-part-three-onboarding-specialized-providers-is-too-hard/

An illustration of computer screens.

Here’s a myth we hear again and again:

Integrating a new storage provider is too complicated. Migrating data, retraining teams, and reconfiguring tools will take too long and create too much risk.

It’s understandable. Data migrations have a reputation for being messy and disruptive. And let’s be honest, nobody wants to babysit infrastructure when there are products to build. For many teams, just the thought of switching cloud providers feels like a detour they don’t have time for.

But in reality, that fear is often bigger than the actual lift. If your workflows already use standard tooling like S3-compatible APIs, switching to a specialized provider is more like a well-marked exit than a hard left turn.

This is the third post in our series debunking persistent myths about cloud storage—check out the first and second posts—and why a best-of-breed, interoperable approach is actually less disruptive than sticking with legacy hyperscaler models.

New Cloud Native Times Call for New Cloud Storage Approaches

Learn more about how the open cloud supports faster development, improved workflows, and reduced cost complexity in our free ebook, “New Cloud Native Times Call for New Cloud Storage Approaches.”

Get the Ebook

Migration anxiety vs. reality

“Storage migration” can sound like it requires weeks of planning and an army of engineers. But if your apps are already using S3-compatible workflows, most of the heavy lifting is already done.

If you know S3, you’re already ready

Many specialized storage providers now support S3-compatible APIs, allowing teams to keep the tools, scripts, and services they already know, such as Terraform, Kubernetes, ArgoCD, boto3, and MinIO.

And because your teams are already familiar with the S3 API and related tools, retraining isn’t a hurdle. The same skills, scripts, and automation frameworks carry forward, keeping onboarding time minimal. In fact, most teams are surprised by how little they need to change to get started.

That means:

  • No need to learn a new SDK or storage interface
  • No retraining your DevOps team
  • No rewriting automation pipelines or batch jobs

In most cases, all it takes is updating your endpoint URL and refreshing credentials. The mental model stays the same, the tools stay the same, and your workflows continue as-is.

You don’t need to rip and replace

Downtime concerns are one of the biggest sources of hesitation when switching providers. But in practice, migrations to S3-compatible cloud storage providers rarely require full cutovers or risky, all-or-nothing switchovers. With a bit of planning, most teams handle migrations incrementally:

  • Start by migrating lower-risk datasets, such as backups or archives.
  • Validate configurations and permissions as data lands in the new system.
  • Slowly expand to production datasets as confidence grows.

Better yet, you don’t have to move everything at once. Many teams adopt phased transitions, running some buckets side-by-side or writing to both systems during the handoff to minimize risk. With a bit of planning and the right migration tools and guidance, you can keep operations stable while gradually shifting workloads at a comfortable pace.

Metadata isn’t a blocker

Migrating files without metadata continuity can break downstream systems, especially if your applications rely on timestamps or version tracking.

Fear not. S3-compatible cloud storage providers can preserve metadata during migration, including timestamps. That means your historical data stays intact and compliant with internal policies or regulatory needs, and you won’t need to reset or alter your data management policies.

Moving isn’t the risk. Staying locked in is.

Let’s flip the narrative. The real risk isn’t switching; it’s staying stuck.

Major cloud provider ecosystems are designed for lock-in. The deeper you go, the harder it becomes to leave. Features that look like conveniences, such as integrated IAM policies, tiered storage, and custom APIs, often become entanglements over time.

Each of these layers is built to reinforce reliance:

  • IAM rules tie access tightly to the provider’s own tooling.
  • Tiered storage creates dependencies on lifecycle rules and retrieval thresholds. 
  • Custom APIs mean even basic storage functions can require provider-specific logic.

And as you expand your usage—adding compute, networking, and security services—everything becomes interdependent. What starts as convenience evolves into constraint. Even small changes to your stack can trigger cascading reviews, system audits, or full reconfigurations.

The result? Innovation slows. Costs creep up. Flexibility disappears.

With a specialized provider, you break that cycle.

Specialized Doesn’t Mean Complicated

Specialized storage doesn’t complicate onboarding. It streamlines it. Solutions like Backblaze B2 are purpose-built to make this shift smooth and sustainable, without the trade-offs or surprises you might expect from switching providers.

  • S3 compatibility allows for seamless integration with the tools and workflows your team already uses.
  • Granular control means you can choose the tools and providers that work best for your architecture, not the ones bundled into a vendor’s ecosystem.
  • Metadata continuity is supported through features like custom upload timestamps, preserving file context during migration.
  • Transparent pricing ensures there are no hidden egress fees, transaction charges, or retention penalties to catch you off guard.
  • Hands-on support helps you plan, validate, and scale your migration with confidence and minimal disruption.

Breaking out of a single-vendor ecosystem may feel intimidating, but it’s often the fastest way to simplify operations, improve performance, and regain control over your cloud strategy.

The best part? Once you’ve made the move, you’re free to experiment. Multi-cloud strategies become more accessible. Your architecture becomes more modular. And your team can focus on building, not babysitting infrastructure.

Next Up: In the final post in this series, we’ll tackle Myth #4: Managing multiple clouds is complicated. (Spoiler: It doesn’t have to be.)

Want to dig even deeper? Download the full whitepaper New Cloud-Native Times Call for New Cloud Storage Approaches.

The post Cloud Storage Myths Debunked, Part Three: Onboarding Specialized Providers Is Too Hard appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Cloud Storage Myths Debunked, Part Two: Storage Isn’t a Big Enough Problem to Remediate

Post Syndicated from David Johnson original https://www.backblaze.com/blog/cloud-storage-myths-debunked-part-two-storage-isnt-a-big-enough-problem-to-remediate/

A decorative image showing devices on a cloud background.

Today’s myth might sound familiar:

Storage is a minor cost, so it’s not worth switching from major cloud providers.

It’s easy to see how this thinking takes hold. In many cloud-native projects, storage can be the last concern. Compute, networking, and database services often drive most of the costs. Storage? That’s just where your data sits.

But hidden fees, unpredictable retrieval charges, and surprising performance constraints make storage far more impactful than many teams realize—especially for cloud-native workflows.

This post is the second in our blog series unpacking four of the most common myths and misconceptions about specialized cloud storage—see the first post here—and why an interoperable, best-of-breed approach can enhance and streamline cloud-native app development.

New Cloud Native Times Call for New Cloud Storage Approaches

Learn more about how the open cloud supports faster development, improved workflows, and reduced cost complexity in our free ebook, “New Cloud Native Times Call for New Cloud Storage Approaches.”

Get the Ebook

Underestimate the importance of storage at your peril

Major cloud providers offer plenty of storage options, but the real costs aren’t always clear up front. 

The charges you don’t see coming

Between egress charges, API call fees, transaction costs, and minimum retention charges, even small changes in how your application moves or retrieves data can quickly inflate your bill.

What looked affordable at launch can snowball into sticker shock once traffic increases or new workloads start driving more data in and out of storage. A single spike in user activity or analytics queries can trigger thousands (or millions) of storage transactions, each billed individually.

These expenses add up fast, and they’re tough to predict.

The egress trap

Egress charges might be one of the best-kept open secrets among the “big three” cloud providers. Every time data leaves their environment—whether to a CDN, another cloud, or end users—egress fees kick in. And they aren’t trivial.

Frequent data transfers, a hallmark of cloud-native architectures, can quietly devour budgets. The big dogs know this. Once your data is deep in their ecosystem, pulling it out becomes financially painful.

This creates a subtle but powerful form of vendor lock-in, making it harder to shift workloads or storage to more specialized providers.

Vendor lock-in, by design

Major cloud providers bundle storage, compute, networking, and a long list of services into tightly coupled ecosystems. On paper, that integration offers convenience. In practice, it creates real friction if you ever want to move.

Even when using open standards like the S3 API, migrating workloads can require new tooling, careful planning, and extensive testing. Under tight deadlines, the mere prospect of switching providers can feel too risky to attempt.

It’s not just inertia; it’s engineered friction designed to keep you tethered.

Complex storage slows down everything

Bundling storage inside a big cloud provider’s stack might seem efficient, but it often creates fragile setups that slow teams down. Configurations get complicated fast:

  • Hot and cold storage tiers
  • Lifecycle rules
  • IAM policies
  • Interdependent compute pipelines

Every added layer increases the odds that something breaks, pulling engineers into troubleshooting instead of building.

Latency-sensitive workloads such as real-time analytics or streaming services are especially vulnerable. Even small missteps can ripple through the user experience.

And when those issues hit, teams scramble to patch things up, burning time and resources that could be better spent moving products forward.

AI workloads bring storage costs into sharp focus

AI-powered applications, from model training to updating retrieval-augmented generation (RAG) pipelines, put heavy demands on storage. These workloads hammer systems with high-throughput reads and writes.

Each refresh or update adds to your bill:

  • Delete penalties
  • Retention minimums
  • API call surcharges

When teams start rationing runs, batching updates, or delaying refreshes just to control costs, innovation slows.

Specialized storage keeps costs predictable and workloads agile

Unlike the “big three” cloud providers, who often hide complexity behind convenience, specialized cloud storage providers like Backblaze B2 take a more transparent approach:

  • Clear, predictable pricing means no surprise egress fees, retrieval costs, API charges, or deletion penalties.
  • Always-hot storage eliminates the need for lifecycle policies and tier management.
  • Open architecture means you stay in control—no proprietary hooks, no walled gardens, and no painful unwinding if your needs change down the road.

For cloud-native teams, this isn’t just a storage swap; it’s an operational upgrade. Streamlined management, lower risk, and transparent costs mean teams can focus on shipping new products and features, not decoding their storage bills.

In fact, Enterprise Strategy Group released a comprehensive analysis of the economic benefits of Backblaze B2 in May 2025. The analysis concluded that Backblaze B2’s storage costs (monthly storage cost + cost of downloads + cost of transactions) were 3.1x to 3.2x lower than alternative cloud storage providers.

Simple, transparent, affordable pricing enabled Backblaze B2 users to spend far less on storage and use the savings to innovate and grow.
—Enterprise Strategy Group

What’s next for you and storage?

If you liked this article, check out the first in the series, “Cloud Storage Myths Debunked: Hyperscaler Storage Is Good Enough for Cloud-Native Apps.” And, stay tuned for the next post in this series, where we’ll tackle myth #3, addressing whether onboarding specialized providers is too hard. (It’s easier than you think.)

Want to dig even deeper? Download the full ebook “New Cloud-Native Times Call for New Cloud Storage Approaches.”

The post Cloud Storage Myths Debunked, Part Two: Storage Isn’t a Big Enough Problem to Remediate appeared first on Backblaze Blog | Cloud Storage & Cloud Backup