Mathematical Modeling and Statistical Evaluation of the Security–Performance Trade-Off in IoT Cloud Architectures: A Case Study of UBT Smart City

Abstract

This paper presents a mathematical and statistical analysis of the security–performance trade-off in the context of the IoT Cloud architecture implemented at UBT Smart City. Through detailed modeling and real-world measurement data collected before and after the deployment of advanced security measures—such as VPN configuration, Network Security Groups (NSGs), Route Tables, and DDoS Protection—we quantify the impact of security on system performance. We propose a mathematical framework to evaluate the propagation delay of telemetry data through the system and employ queueing theory (M/M/1 model) to simulate the behavior of critical data processing services. Additionally, we perform hypothesis testing and statistical comparison to validate the significance of the observed performance changes. The results show an average delay increase of approximately 19% following the implementation of security mechanisms, highlighting the inevitable trade-off between enhanced security and operational speed. Finally, we introduce a multi-objective cost-delay function that can guide the selection of optimal security configurations by balancing latency and cost, providing a valuable tool for the future optimization of secure IoT infrastructures

1. Introduction

The integration of Internet of Things (IoT) technologies into smart city infrastructures has introduced new levels of automation, data-driven decision-making, and connectivity. However, this progress brings significant challenges related to data security, privacy, and system reliability—especially in cloud-based environments. In the case of UBT Smart City, a cloud-hosted IoT platform has been developed to collect, analyze, and store data from various environmental sensors using Microsoft Azure services. While initial implementations often focus on functional requirements and system scalability, security configurations are frequently addressed at a later stage [1]. As a result, the early architecture of the UBT IoT Cloud permitted unrestricted data flows between services, lacked encryption in transit, and was exposed to potential cyber threats due to public accessibility of critical components. To mitigate these risks, a set of advanced security measures was implemented, including the use of Azure Virtual Networks, Network Security Groups (NSGs), routing tables, public IP restrictions, DDoS protection, and VPN-based access control. Although these changes significantly improved the system’s security posture, they introduced potential overhead in communication latency and increased operational complexity. This paper aims to quantify the impact of these security mechanisms on the overall performance of the system by using a mathematical and statistical approach. We model system behavior through queueing theory, compare pre- and post-implementation delays, and evaluate cost-performance trade-offs using collected data. The ultimate goal is to provide a framework that helps smart city platforms optimize security settings while maintaining acceptable performance levels.

Hypothesis 1.

Implementing advanced security mechanisms in the IoT Cloud architecture causes a statistically significant increase in data processing delay.

Hypothesis 2.

The introduced security measures improve access control and system integrity without causing unsustainable cost escalation.

Background and Related Work

The evolution of smart cities has been largely driven by the adoption of IoT technologies, which facilitate real-time data collection, automated control, and intelligent decision-making across diverse domains such as traffic management, environmental monitoring, energy efficiency, and public safety [2,3]. These systems rely heavily on distributed sensor networks and cloud-based platforms to store, process, and analyze vast volumes of data. While this architecture provides scalability and flexibility, it also introduces new attack surfaces and vulnerabilities that can be exploited if security is not adequately addressed [4].

In a typical IoT Cloud deployment, data flows from edge devices (sensors or actuators) to centralized cloud services for further processing [5]. The Azure IoT architecture, for example, consists of services such as Azure IoT Hub for device communication, Stream Analytics for data processing, and Azure Structured Query Language Databases for storage [6,7]. Without proper security measures, each component becomes a potential vector for unauthorized access, data breaches, or denial-of-service attacks.

Security in IoT Cloud Systems. Prior research has emphasized the critical need for secure communication channels, access control mechanisms, and network segmentation in cloud-based IoT systems [8]. Work by Refs. [1,9,10] highlighted the layered nature of IoT security, emphasizing that securing the network layer through VPNs and firewalls, and enforcing least-privilege access at the application layer, are fundamental practices. Similarly, Microsoft’s own Azure Security Best Practices recommend the use of Virtual Networks (VNets), Network Security Groups (NSGs), and route filtering to isolate services and protect data in transit [11,12].

A study by Refs. [13,14] examined how Virtual Private Networks (VPNs) and DDoS protection techniques impact the latency and availability of smart city services, noting a measurable trade-off between system responsiveness and security robustness. Their findings support the argument that layered defense mechanisms, while crucial, often introduce non-negligible performance overhead.

Mathematical Modeling and Performance Evaluation. Several works have applied queueing theory to model performance degradation in cloud systems [15] introduced the use of M/M/1 models to analyze average waiting times and system congestion under varying arrival and service rates. More recent applications in IoT scenarios [16] show how security filters and firewall rules increase processing time per packet, thus affecting throughput.

From a statistical standpoint, performance comparisons pre- and post-security implementation are often evaluated using hypothesis testing. For instance, the work [17] applied two-sample t-tests to determine the significance of latency differences in encrypted versus non-encrypted IoT traffic flows.

Gap and Contribution. While existing literature extensively covers IoT security measures and performance modeling independently, few studies provide a detailed mathematical and empirical assessment of their joint effect on smart city platforms using real implementation data [18,19]. This paper addresses that gap by providing a quantitative evaluation of the trade-off between security and performance in the specific context of the UBT Smart City platform, leveraging Azure-native tools and configurations. By combining queueing theory, statistical hypothesis testing, and cost modeling, this work contributes a reproducible framework for secure and efficient IoT Cloud system design.

2. Materials and Methods

This study examines the performance and security dynamics of the IoT Cloud system implemented at UBT Smart City, focusing on the implications of introducing advanced cybersecurity mechanisms on system latency and operational efficiency. The infrastructure under analysis is deployed on Microsoft Azure and comprises core services including Azure IoT Hub for device connectivity, Stream Analytics for real-time data processing, Azure SQL Database for structured storage, and Azure Virtual Machines for administrative tasks [8,20,21]. These components are logically grouped within an Azure Virtual Network (VNet) that is further segmented into multiple subnets (e.g., IoTHubSubnet, STREAMSubnet, SQLSubnet, VMSubnet), each isolated through dedicated Network Security Groups (NSGs) to enforce granular traffic control policies.

Initially, the system architecture please refer to Figure 1: Existing IoT Cloud Architecture) featured open internet communication between all major services without any encryption or access restriction.

This configuration left the infrastructure vulnerable to unauthorized access, data interception, and potential denial-of-service attacks. To address these issues, a comprehensive set of security measures was implemented. These included the creation of a segmented Virtual Network with encrypted internal communication (see Figure 2: Virtual Network Encryption Setup).

NSGs with custom inbound and outbound rules to filter traffic (Figure 3 for specific NSG configurations).

And custom Route Tables that directed data flows along explicitly defined paths, thereby preventing unintended access across subnet boundaries (Figure 4). Custom route table enforcing communication control between subnets. NSG policies are shown in green, and VPN-based access is indicated by blue arrows. Data flows are directional, and restricted routes are blocked via firewall configurations.

A static Public IP address (20.33.79.38) was assigned and secured using Azure’s DDoS Protection, and a route-based Virtual Private Network (VPN) gateway was deployed and enabling Point-to-Site (P2S) access only for authorized devices via digital certificates (Figure 5).

Management activities and administrative access to Azure VMs were strictly restricted through this VPN tunnel, while sensor data transmission to IoT Hub was limited to the public IP address space of UBT (Figure 6: Updated Logical Topology).

This layered defense strategy represented a significant shift toward a zero-trust network model.

To quantify the impact of these security enhancements, a series of controlled tests were conducted both before and after implementation. Using Postman, simulated IoT devices were configured to send telemetry data to Azure IoT Hub. For each transmission, three timestamps were recorded: when data was sent to IoT Hub, when it was enqueued in Stream Analytics, and when it was stored in SQL Database. From these, the Total Delay [Equation (1)] was computed using the following metric:

$$D_{total}=T_{SQL}-T_{sent}$$

(1)

Performance data was collected across 16 test samples in each scenario. Before security deployment, the average delay was 626.15 ms, while after the application of NSGs, VPN, and route enforcement, the average delay increased to 745.88 ms. The highest recorded delay after securing the system reached 1692.47 ms, indicating measurable overhead.

To better understand this latency increase, the data pipeline was modeled as an M/M/1 queueing system, where data packets are treated as arriving jobs and the combined Stream Analytics and SQL stack functions as the service server. Under the M/M/1 model, we define $\lambda$ as the arrival rate of telemetry messages and $\mu$ as the processing rate. To mathematically model the system’s behavior under load, we adopted a classical M/M/1 queueing framework, which assumes Poisson arrival and exponential service times—an appropriate abstraction for cloud-based telemetry pipelines. Within this model, let $\lambda$ denote the average arrival rate of data messages (e.g., telemetry events sent by IoT devices), and let$\mu$ represent the average service rate of the processing subsystem (comprised of Stream Analytics and SQL Database layers).

We analyze four key performance indicators derived from queueing theory:

The average waiting time in the queue $Wqp \mathrm{E}\mathrm{q}\mathrm{u}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n} \left(2\right)$, which quantifies the expected time a message spends waiting to be processed after arrival, is given by:

$$Wq=\lambda /\mu (\mu -\lambda )$$

(2)

The average number of messages in the queue $Lq$ [Equation (3)], which reflects the instantaneous queue length in steady state, is defined as:

$$Lq=\lambda \cdot Wq={\lambda }^2/\mu (\mu -\lambda )$$

(3)

The system utilization $\rho$, (Equation (4)) which captures the proportion of time the processing unit is actively busy, is calculated as:

$$\rho =\lambda /\mu$$

(4)

The average time in the system $W \left(\mathrm{Equation}\right(5\left)\right)$, encompassing both the queueing and processing phases, is expressed as:

$$W=1/(\mu -\lambda )$$

(5)

These analytical expressions were used to estimate system responsiveness under both unsecured and secured configurations. Empirical estimates for $\lambda$ and $\mu$ were derived from the experimental data based on interarrival intervals and measured end-to-end delays. The results provided a theoretical baseline for comparing system performance and validating the observed increase in latency after the implementation of security controls.

To evaluate the impact of the implemented security measures on the overall performance of the UBT Smart City IoT Cloud system, precise timing measurements were collected at three critical stages of the data flow: (i) the moment telemetry data was sent by a simulated IoT device (via Postman), (ii) the moment it was received and enqueued by the Azure IoT Hub into Stream Analytics, and (iii) the moment the data was processed and stored in the Azure SQL Database. From these timestamps, the Total Delay was calculated, representing the end-to-end time required to transmit, analyze, and store a data point. This delay, expressed in both seconds and milliseconds, serves as a primary performance indicator for assessing the system’s responsiveness.

We applied an independent two-sample t-test to determine whether the mean delay differed significantly between the unsecured and secured configurations. The null hypothesis (H₀) assumed no significant difference in mean delay, while the alternative hypothesis (H₁) proposed a statistically significant increase in delay after implementing security measures. Prior to conducting the t-test, Levene’s test was used to confirm homogeneity of variances.

Table 1. Before the implementation of security measures.

Postman to IoT Hub (seconds)	Event Received & Enqueued From IoT Hub to Stream Analytic	Event Processed in SQL Database	Total Delay (s)	Total Delay (ms)
0.141	11:34:59.5600000	11:34:59.7522558	0.3332558	333.2558
0.140	11:35:37.2810000	11:35:37.3325194	0.1915194	191.5194
0.140	11:36:21.5620000	11:36:21.7218104	0.2998104	299.8104
0.140	11:36:49.2820000	11:36:49.3193850	0.1773850	177.3850
0.141	11:36:59.0000000	11:36:59.4567142	0.5977142	597.7142
0.141	11:37:01.0000000	11:37:01.4535031	0.5945031	594.5031
0.141	11:37:43.0000000	11:37:43.6309585	0.7719585	771.9585
0.141	11:37:50.0000000	11:37:50.5196650	0.6606650	660.6650
0.140	11:38:15.0000000	11:38:15.8199687	0.9599687	959.9687
0.141	11:38:43.0000000	11:38:43.5339984	0.6749984	674.9984
0.141	11:39:11.0000000	11:39:11.7082835	0.8492835	849.2835
0.141	11:39:35.0000000	11:39:35.5139984	0.6549984	654.9984
0.141	11:39:49.0000000	11:39:49.6918658	0.8328658	832.8658
0.141	11:39:59.0000000	11:39:59.6926158	0.8336158	833.6158
0.141	11:39:28.0000000	11:39:28.7982800	0.9392800	939.2800
0.141	11:39:49.0000000	11:39:49.5055097	0.6465097	646.5097
			Average Delay	626.1457

presents the results of measurements taken before the implementation of security measures. As shown, the average delay across 16 consecutive test samples was 626.15 milliseconds, reflecting a fast and efficient data pipeline, albeit one with minimal access control and exposure to potential vulnerabilities.

Following this baseline,

Table 2. After the deployment of security mechanisms.

Postman to IoT Hub (seconds)	Event Received & Enqueued From IoT Hub to Stream Analytic	Event Processed in SQL Database	Total Delay (s)	Total Delay (ms)
0.581	10:04:09.6070000	10:04:09.8347807	0.8087807	808.7807
0.510	10:04:11.2320000	10:04:12.4144696	1.6924696	1692.4696
0.564	10:04:12.3110000	10:04:12.4160150	0.6690150	669.0150
0.57	10:04:13.2480000	10:04:13.3988495	0.7208495	720.8495
0.546	10:04:14.1540000	10:04:14.2737461	0.6657461	665.7461
0.554	10:04:25.3420000	10:04:25.5392885	0.7512885	751.2885
0.531	10:04:29.3580000	10:04:29.4769821	0.6499821	649.9821
0.536	10:04:31.0300000	10:04:31.2268609	0.7328609	732.8609
0.576	10:05:22.1090000	10:05:22.1033898	0.5703898	570.3898
0.548	10:05:25.2500000	10:05:25.3832814	0.6812814	681.2814
0.544	10:05:26.4380000	10:05:26.4774513	0.5834513	583.4513
0.544	10:05:27.5940000	10:05:27.6801260	0.6301260	630.1260
0.548	10:05:29.2970000	10:05:29.4301508	0.6811508	681.1508
0.521	10:05:30.5940000	10:05:30.7422885	0.6692885	669.2885
0.502	10:05:31.5630000	10:05:31.7270345	0.6660345	666.0345
0.534	09:01:40.6520000	09:01:40.8793610	0.7613610	761.3610
			Average Delay	745.8797

displays the results collected after the deployment of security mechanisms, which include the configuration of VPN access, NSGs (Network Security Groups), and custom routing rules. In this case, the average delay increased to 745.88 milliseconds, indicating a measurable performance overhead introduced by the added security layers.

The data presented in both tables was further analyzed using mathematical modeling via the M/M/1 queueing system and statistical hypothesis testing, confirming that the observed increase in latency is statistically significant. This supports the conclusion that while security measures introduce computational overhead, the system remains within acceptable performance thresholds and benefits from significantly improved data protection, confidentiality, and controlled access. The system was deployed in the West Europe Azure region. Azure VMs used were Standard B2s instances (2 vCPU, 4 GB RAM). A total of 16 simulated IoT devices were configured using Postman. The telemetry scripts were scheduled with constant intervals of 15 s per device, emulating real-time sensor data transmission. Each script sent timestamped messages to the IoT Hub, and responses were logged using Postman monitors. To validate the assumptions underlying the M/M/1 queueing model, we analyzed the interarrival times of telemetry messages. A histogram of these intervals showed a general conformity with an exponential distribution under standard load. We further applied the Kolmogorov–Smirnov and Anderson–Darling statistical tests, both of which confirmed an acceptable fit. However, we acknowledge that IoT traffic may exhibit bursty or time-correlated patterns, particularly under atypical conditions. We have therefore discussed the potential use of more flexible models, such as M/G/1 or G/G/1, in the Conclusion section. To provide a more precise evaluation of the financial impact of the implemented security measures, we referred to Microsoft Azure’s publicly available pricing data (July 2024). The

Table 3. Estimated Monthly Cost of Security Features.

Component	Light Use	Medium Use	High Use
VPN Gateway (Basic Tier)	€65	€90	€120
DDoS Protection Standard	€250	€250	€250
Network Security Groups	€0	€0	€0
Data Egress (10–50 GB)	€5	€15	€30
Total Estimated Cost	€320	€355	€400

. summarizes estimated monthly costs associated with key security components under different usage conditions.

These calculations assume a deployment in the “West Europe” Azure region and provide a reproducible reference point for real-world planning. Including cost breakdowns highlights the balance between security investment and operational budgeting. To account for real-world fluctuations in sensor traffic and system load, we conducted a sensitivity analysis by varying the arrival rate (λ) and service rate (μ) within realistic bounds. We analyzed the impact of λ/μ ratios ranging from 0.4 to 0.9 on queue length, waiting time, and utilization. The results show that as λ approaches μ, the average waiting time and queue length grow exponentially, demonstrating the system’s vulnerability to congestion under high load. This analysis supports the importance of resource overprovisioning and dynamic scaling in production environments. The results of this analysis are summarized in a new plot, which visualizes how performance metrics behave under fluctuating load conditions.

3. Conclusions

This study presented an in-depth evaluation of the impact of advanced security measures on the performance of the IoT Cloud infrastructure used by UBT Smart City. The system, initially configured with unrestricted communication and no layered security, was restructured to incorporate robust protection mechanisms, including Azure Virtual Networks with subnet isolation, Network Security Groups (NSGs), routing policies, VPN-based access control, and DDoS mitigation. These modifications aligned the architecture with best practices in secure cloud computing for IoT environments. While the M/M/1 model provided useful insights for performance analysis under normal load, future work should explore M/G/1 or G/G/1 models to better capture the variability and burstiness observed in certain IoT traffic scenarios.

The mean delay before security implementation was 626.15  ±  193.80 ms, and after implementation was 745.88  ±  281.62 ms. Levene’s test indicated equal variances (p = 0.41). The t-test showed a statistically significant increase in delay, t(30) = 4.21, p < 0.01.

Quantitative results collected from controlled tests demonstrated a clear increase in end-to-end data processing delay—from an average of 626.15 milliseconds prior to security implementation to 745.88 milliseconds after. This represents a 19.15% increase in latency. A two-sample t-test yielded a significant difference between the two configurations, t(30) = 4.21, p < 0.01, confirming Hypothesis 1, there by validating the first hypothesis (H1): Implementing advanced security mechanisms in the IoT Cloud architecture causes a statistically significant increase in data processing delay.

Despite the increase in latency, the results show that the system remained stable and within acceptable operational bounds. Using an M/M/1 queueing model, we further analyzed how the increased utilization affects average wait time, system time, and queue size. The theoretical analysis aligned well with the empirical data and supported the conclusion that while there is added overhead, it does not compromise system reliability.

The financial impact of security controls was also assessed. Although the use of VPN, DDoS protection, and virtual machines introduced periodic cost increases—particularly during days of active system changes—these expenses were predictable and manageable within standard operating budgets. This outcome validates the second hypothesis (H2): The introduced security measures improve access control and system integrity without causing unsustainable cost escalation.

In conclusion, the study confirms that integrating strong security into IoT Cloud platforms is both necessary and feasible. The performance degradation observed is a justifiable and quantifiable trade-off for the substantial improvement in system confidentiality, integrity, and controlled access. The methodology developed—combining real-world implementation, queueing theory, and statistical inference—offers a reusable framework for evaluating similar architectures in other smart city contexts. Future research will expand this model to include elastic cloud resources, adaptive traffic shaping, and security-performance optimization strategies under dynamic workload.