Securing the Connected Clinic: Cloud Crypto Performance Under the Microscope

Author: Denis Avetisyan


New research dives deep into the performance of cryptographic operations on serverless platforms to optimize privacy and responsiveness in healthcare IoT applications.

Function-as-a-Service architectures from Azure and AWS were subjected to microbenchmark analysis, revealing the underlying performance characteristics of each platform when disassembled into its component parts.
Function-as-a-Service architectures from Azure and AWS were subjected to microbenchmark analysis, revealing the underlying performance characteristics of each platform when disassembled into its component parts.

A comprehensive microbenchmarking study of cryptographic workload execution across AWS and Azure Function as a Service, focusing on key management and remote patient monitoring.

Despite the increasing reliance on cloud services for healthcare IoT applications, a comprehensive understanding of cryptographic performance trade-offs across diverse cloud infrastructures remains elusive. This research, ‘Microbenchmarking Cloud Cryptographic Workloads for Privacy-Preserving Healthcare IoT’, presents an extensive microbenchmark study evaluating core cryptographic workloads-including AES, SHA, HMAC, and ECC-across Function as a Service (FaaS) platforms integrated with Key Management Services from AWS and Azure. Our analysis, spanning two CPU architectures, six programming languages, and various instance types, identifies optimal configurations for balancing performance, cost, and security in these environments. Will these findings enable more efficient and secure data protection for sensitive healthcare data in the rapidly evolving landscape of remote patient monitoring and connected medical devices?


Deconstructing the Serverless Perimeter

The proliferation of Function-as-a-Service (FaaS) computing, exemplified by platforms like AWS Lambda and Azure Functions, presents a distinctly broadened attack surface for malicious actors. These architectures, designed for scalability and efficiency, operate on an ephemeral basis – functions are executed only when triggered, existing briefly before disappearing. This transient nature complicates traditional security measures, which often rely on persistent monitoring and static configurations. Each function represents a potential entry point, and the sheer number of these short-lived execution environments creates a complex and rapidly changing landscape for security teams to manage. Furthermore, the distributed nature of serverless applications, often integrating numerous third-party services and APIs, introduces additional vulnerabilities related to data exposure and compromised dependencies. Consequently, securing FaaS applications demands innovative approaches that prioritize runtime protection, automated vulnerability detection, and granular access control.

Conventional security strategies, designed for long-lived servers and predictable network perimeters, struggle to adapt to the transient and highly distributed nature of serverless architectures. These systems, characterized by ephemeral functions and event-driven execution, present a moving target for traditional intrusion detection and prevention systems. The lack of persistent infrastructure necessitates a move beyond signature-based detection towards behavioral analysis and runtime protection, focusing on identifying anomalous activity within individual function invocations. Furthermore, the increased reliance on third-party APIs and integrations expands the attack surface, demanding robust identity and access management, alongside continuous vulnerability scanning tailored to the unique challenges of serverless environments. A fundamental shift is therefore required – one that prioritizes automation, granular permissions, and a security model deeply integrated into the entire serverless application lifecycle.

This diagram illustrates how function-as-a-service microbenchmarks collect execution and data flow information.
This diagram illustrates how function-as-a-service microbenchmarks collect execution and data flow information.

Forging Security Through Cryptographic Implementation

Serverless function deployments support a diverse range of programming languages for cryptographic operations. Algorithms such as Advanced Encryption Standard (AES) can be implemented utilizing languages including Rust, Go, Python, Java, C#, and TypeScript. This flexibility allows developers to leverage existing skillsets and codebases when building serverless applications requiring data encryption and security features. The choice of language impacts performance characteristics, resource utilization, and the complexity of implementation, but does not fundamentally limit the cryptographic capabilities of the serverless environment.

Execution performance of cryptographic algorithms within serverless functions is notably dependent on both the programming language used and the cloud provider’s infrastructure. Benchmarking indicates that Python implementations frequently achieve the fastest execution speeds when deployed on Amazon Web Services (AWS). Conversely, C# demonstrates superior performance in comparable deployments on Microsoft Azure. These variances are attributable to differences in runtime environments, underlying infrastructure optimizations, and the efficiency of language-specific cryptographic libraries within each platform. Developers should prioritize language selection based on target cloud provider to optimize for speed and cost.

Benchmarking across multiple serverless platforms consistently indicated that Rust exhibits a smaller memory footprint than implementations utilizing languages such as Python, C#, Java, and Go. This reduced memory consumption translates directly to lower resource allocation during function execution, potentially decreasing costs and improving cold start times. Specifically, Rust’s memory efficiency stems from its lack of a garbage collector and its focus on zero-cost abstractions, allowing for fine-grained control over memory management and minimizing runtime overhead compared to languages relying on automatic memory management.

Maintaining data confidentiality and integrity within serverless environments necessitates efficient cryptographic implementations due to the unique characteristics of these architectures. Serverless functions, by design, are ephemeral and stateless, meaning data must be encrypted in transit and at rest, and decryption keys must be securely managed without relying on persistent storage within the function itself. Inefficient cryptographic operations can introduce significant latency, impacting application responsiveness and potentially increasing costs due to longer execution times and greater resource consumption. Furthermore, poorly implemented cryptography can create vulnerabilities, exposing sensitive data to unauthorized access or modification, and compromising the overall security posture of the application. Therefore, careful consideration must be given to algorithm selection, key management practices, and code optimization to ensure robust security without sacrificing performance or scalability.

Performance metrics for AES256 encryption and decryption reveal that execution time and memory consumption vary with memory size, and warm execution speeds differ between x86_64 and Arm64 architectures.
Performance metrics for AES256 encryption and decryption reveal that execution time and memory consumption vary with memory size, and warm execution speeds differ between x86_64 and Arm64 architectures.

Dissecting Performance: Metrics and Observability

Microbenchmarking serverless functions involves isolating and measuring the execution time of specific code segments to pinpoint performance bottlenecks. This technique differs from end-to-end testing by focusing on granular code performance rather than overall system behavior. By systematically testing individual functions or code blocks with controlled inputs, developers can identify inefficient algorithms, suboptimal data structures, or expensive I/O operations. Results are typically presented as execution time, memory allocation, and CPU usage, allowing for direct comparison between different implementations or configurations. The process facilitates targeted optimization efforts, improving overall function performance and reducing resource consumption without requiring broad system-level changes.

Performance evaluations consistently demonstrated that ARM64-based serverless function deployments exhibited lower cold-start latencies compared to their x86_64 counterparts. This difference in cold-start performance is attributed to architectural distinctions, specifically the ARM64 instruction set’s generally more efficient memory access and streamlined execution pipeline. Observed latency reductions ranged from 15-30% depending on the function’s complexity and dependencies, indicating a significant advantage for ARM64 in latency-sensitive applications. These results suggest that the underlying processor architecture directly impacts the initial function invocation time, a critical metric for serverless performance.

CloudWatch, offered by Amazon Web Services, and Application Insights, provided by Microsoft Azure, are critical components for serverless application management. These tools collect, analyze, and visualize telemetry data encompassing function invocations, execution duration, memory utilization, disk I/O, and network traffic. Specifically, CloudWatch logs and metrics can be used to track errors, performance bottlenecks, and custom application-level data, while Application Insights provides similar functionality with a focus on application health and dependency mapping. Both platforms offer alerting capabilities based on predefined or custom thresholds, enabling proactive identification of performance regressions or potential security incidents such as unauthorized access attempts or unusual API call patterns. Collected data can also be integrated with other security information and event management (SIEM) systems for comprehensive threat detection and incident response.

Analysis of serverless function execution costs revealed that configurations utilizing 128MB of memory consistently resulted in the lowest overall cost profile. However, this economic benefit is directly correlated with increased execution time; functions allocated less memory require more time to process the same workload. This trade-off stems from the billing model of most serverless platforms, which charges based on both execution duration and memory allocated. While higher memory allocations reduce execution time, the increased cost per unit of memory often outweighs the savings from reduced duration, making 128MB the most cost-effective option in tested scenarios.

Continuous analysis of serverless function metrics – including execution duration, memory utilization, error rates, and invocation counts – enables performance optimization and proactive issue resolution. By establishing baseline performance indicators and setting up alerts for anomalous behavior, development teams can identify and address bottlenecks, resource constraints, or code errors before they manifest as user-facing problems. This data-driven approach facilitates iterative improvements to function code, configuration, and underlying infrastructure, leading to reduced latency, increased throughput, and improved application reliability. Furthermore, metric analysis aids in capacity planning, allowing for the anticipation and mitigation of potential scaling challenges during periods of high demand.

Automating the Serverless Fabric: Infrastructure as Code

Modern serverless architecture increasingly relies on Infrastructure-as-Code (IaC) to move beyond manual configuration and scripting. IaC allows teams to define and manage serverless resources – such as functions, databases, and APIs – using declarative configuration files. Tools like the AWS Cloud Development Kit (CDK) and Bicep empower developers to express infrastructure in familiar programming languages, promoting code reusability and version control. This automation significantly reduces the potential for human error, accelerates deployment cycles, and facilitates consistent environments across development, testing, and production. By treating infrastructure as code, organizations gain the ability to apply software engineering best practices – including testing, review, and continuous integration – to the very foundation of their serverless applications, resulting in more reliable and scalable systems.

The adoption of Infrastructure-as-Code (IaC) significantly streamlines serverless application development by replacing manual configuration with declarative definitions. This approach automates the provisioning and management of resources, substantially reducing the potential for human error and freeing developers to focus on application logic. Beyond efficiency, IaC fosters consistency across environments – development, testing, and production – ensuring predictable behavior and minimizing discrepancies. Critically, IaC treats infrastructure configurations as code, enabling version control through systems like Git. This allows for tracking changes, rolling back to previous states, and collaborative development of infrastructure, mirroring best practices in software engineering and enhancing overall system reliability.

Detailed performance analysis, visualized through heatmaps, demonstrated significant variations in warm execution speeds between x86_64 and Arm64 serverless functions. These visualizations weren’t simply about identifying a universally ‘faster’ architecture; instead, they revealed that the optimal choice depended heavily on the specific workload. Certain functions exhibited substantial speedups – exceeding 20% in some instances – when executed on Arm64, while others performed better, though sometimes only marginally, on x86_64. This workload-specific behavior underscores the importance of empirical testing and careful consideration of application characteristics when selecting a serverless compute platform, moving beyond generalized assumptions about processor performance.

The convergence of Infrastructure-as-Code (IaC) practices with diligent monitoring and performance evaluation represents a pivotal strategy for organizations embracing serverless architectures. Implementing IaC not only streamlines the provisioning and management of resources but also establishes a foundational layer for automated security checks and policy enforcement. Continuous performance evaluation, tracking metrics like latency, error rates, and cost, allows for data-driven optimization of serverless functions and configurations. This combined approach facilitates the creation of applications that are inherently scalable, adapting seamlessly to fluctuating demands, and demonstrably reliable through proactive identification and mitigation of potential issues – ultimately fostering a robust and secure serverless ecosystem.

The pursuit of optimized cloud cryptography, as detailed in the research, mirrors a fundamental principle of system understanding: deliberate disruption. This study doesn’t simply accept reported performance metrics; it actively probes the boundaries of AWS and Azure FaaS platforms through rigorous microbenchmarking. As Edsger W. Dijkstra aptly stated, “It’s not enough to just do the right thing; you have to also do things right.” The research exemplifies this, dissecting cryptographic workload performance to uncover optimal configurations – a process akin to reverse-engineering the cloud environment. By meticulously analyzing latency and cost trade-offs, the work illuminates the inherent complexities of balancing security with efficiency in sensitive applications like remote patient monitoring, effectively validating-and sometimes invalidating-assumptions about serverless cryptography.

What Breaks Down Next?

The pursuit of cryptographic agility in serverless healthcare IoT inevitably reveals the brittleness of assumed constants. This work meticulously maps performance across cloud functions, but the very act of measurement introduces a transient reality. Latency figures become archaeological artifacts the moment a provider tweaks an algorithm or a hypervisor decides to daydream. The question isn’t merely ‘how fast?’ but ‘how predictably?’ and ‘at what cost to observability?’. One suspects the real bottleneck isn’t the AES implementation itself, but the elaborate dance required to prove it’s functioning correctly within a shared, ephemeral infrastructure.

Future efforts will likely focus not on squeezing marginal gains from existing primitives, but on radically different approaches to key management. The current reliance on centralized Key Management Services feels… quaint. A single point of failure, elegantly wrapped in an API. One anticipates research into decentralized key derivation, perhaps leveraging secure enclaves or even homomorphic encryption – not for performance, initially, but to introduce a satisfying level of systemic redundancy. The goal, after all, isn’t unbreakable encryption, but unbreakable trust in a system designed to be perpetually disassembled and reassembled.

Ultimately, the true benchmark isn’t cryptographic speed, but the speed at which the system can detect – and recover from – a compromise. A fast, fragile system is merely a more efficient vector for attack. The challenge lies in building a cryptographic infrastructure that doesn’t just resist breaking, but expects it, and has already calculated the cost of failure.


Original article: https://arxiv.org/pdf/2605.24063.pdf

Contact the author: https://www.linkedin.com/in/avetisyan/

See also:

2026-05-27 06:38