InkBridge Networks - A new name for Network RADIUS

The problem with RADIUS in the cloud

The costs are higher than you think

The promise of cloud-hosted infrastructure sounds tempting. Someone else manages your database, you pay only for what you need, you may have better data security, and the database can scale up with your business as it grows. However, implementing RADIUS in the cloud comes with challenges. The pricing for databases in cloud environments is optimized for non-RADIUS use cases, which can result in surprisingly high operational costs when used as part of a RADIUS ecosystem.


Many cloud storage providers such as Amazon Web Services and Microsoft Azure offer database hosting services which seem reasonably priced at a first glance. These cloud platforms also typically offer additional benefits over a “self-hosted” system such as enhanced security technologies, tiered support, and scalability. This combination makes cloud databases a sensible choice for many organizations.

That said, some of our clients have been blind-sided with high cloud costs when they've hosted RADIUS in the cloud. Why does this happen?

Why RADIUS in the cloud is expensive

Most uses of cloud databases are for reads

A typical use-case for cloud databases is to store large amounts of data, and to do many queries. The data is updated occasionally, but not often. In many cases, reads outnumber writes one hundred to one.

Write operations are more expensive

The main issue with hosted databases is that the pricing models are based on the use cases where database read operations strongly outnumber the database writes. In some cases, write operations can cost five times as much as read operations!

This model is fine if most of what you need to do is query a customer database or inventory system, and only occasionally do writes. However, the database usage pattern in a RADIUS ecosystem can be the exact opposite of this scenario, with the number of writes at least equal to the number of reads, and sometimes more.

For example, if you need to keep track of session data for accounting purposes, or if you keep your historical data separate from your live data, each RADIUS accounting packet results in one database read and one database write. For an ISP with a million users, this can be a million read/write cycles, every ten minutes, 24 hours a day, seven days a week. The database write costs alone can quickly reach tens of thousands of dollars a month. This expense would be over and above the cost of storing hundreds of gigabytes of accounting data and tracking IP addresses in real time.

These numbers are enormous when you consider a comparison with a more conventional cloud storage scenario where reads outnumber writes by 100 times. A RADIUS server has closer to 1-1 read/write distribution, which means that using RADIUS in the cloud can be hundreds of times more expensive than a non-RADIUS use case!

Performance issues

The performance is artificially throttled

Some cloud hosting companies will also artificially throttle throughput at lower price tiers. This means that a smaller database will get slower performance, forcing the customer to pay for more storage than they need in order to get the performance they want.

In RADIUS systems, it is common to expect performance of thousands of reads/second to authenticate users, even with relatively small databases. In the artificially throttled cloud model, you cannot get this level of throughput unless you pay for more storage capacity which then also permits higher throughput.

Coupling the pricing for performance with storage capacity means that customers have to choose the most expensive option to get the functionality they need from the cloud. The alleged “benefits of the cloud” turn out to have their costs, just like any other solution. In fact, we have seen several clients need to unnecessarily inflate the size of their databases simply to get better performance.

Shared resources are throttled resources

In many cases, it is possible to use a cloud virtual machine (VM), but not the cloud database. You can install your own database, and get a much better cost/performance ratio. There is still the downside that the cloud VM is using shared resources, and performance might just drop to near-zero for periods of time! If another VM on the same physical system is using large amounts of CPU time, disk IO, or network connectivity, then other VMs on the system can get “starved” of resources.

While such a cloud system may be “up” for purposes of monitoring, its performance will be minimal. So it might as well be “down”, as it cannot handle the load it normally needs to process.

Cost-effective alternatives

If your organisation is exploring cloud infrastructure because you don’t want the overhead of managing your own database, and “cloud is cheaper",  there are other options.

We often recommend that our clients set up their own database and put it on their own hardware. They can then simply store their data server in a third-party data centre, which will provide physical security and temperature control. The data centre will typically only charge for traffic, not storage, because you are using your own hardware. This pricing model is often much truer to the promise of paying for “only what you need” than most cloud storage providers.


For small businesses concerned about both cost savings and data security, evaluating alternatives to public clouds becomes even more critical. While Amazon Web Services and Microsoft Azure offer robust security features, their pricing models for database operations can quickly erode expected cost benefits for RADIUS workloads. Consider how your specific authentication needs—tracking IP addresses, storing sensitive customer data, and maintaining reliable internet connection—align with different infrastructure options. 


Cloud platforms excel at flexibility, but organisations with predictable RADIUS workloads often find dedicated infrastructure provides better value.


Bottom line

The right solution depends on your specific authentication patterns and performance requirements. For RADIUS workloads with high write operations, traditional infrastructure often delivers better economics than cloud platforms, despite the allure of managed services.


Need more help?


InkBridge Networks has been at the forefront of network security for over two decades, tackling complex challenges across various protocols and infrastructures. Our team of seasoned experts has encountered and solved nearly every conceivable network security issue. If you're looking for insights from the architects behind some of the internet's most foundational authentication systems, you can request a quote for network security solutions here


Related Articles

Why you should separate historical data from live data

ISPs and telecoms are often legally required to keep user session data for long periods of time. However, keeping these records can result in enormous databases tables which significantly affect the performance of your RADIUS system. This article explores how to optimize database performance so that you can maintain operational efficiency while storing years of user activity data.

Database design principles for RADIUS systems

Database design is often overlooked as a critical element of a RADIUS ecosystem. In practice, when we work with our clients, we usually spend the bulk of our time optimizing the database architecture. Our time spent on FreeRADIUS is small in comparison. Why? Because the difference between a fast, reliable RADIUS system and a slow, unstable one is almost always the database.