Architects working on AWS spend a lot of time aligning their workloads to the Well-Architected Framework. They review instance types, autoscaling behavior, resilience patterns, observability, IAM boundaries, deployment pipelines, and cost controls. They debate the trade-offs between managed services and self-managed components, horizontal or vertical scaling, and whether a design will still behave correctly under failure or growth. That is exactly what the framework is designed to encourage. But there is a gap in many of those reviews \u2014 one that is surprisingly common in Java environments. The Java Virtual Machine (JVM) is often not part of the conversation at all. <\/p>\n\n\n\n
That omission matters more than many teams realize. AWS is clear that neglecting any of the six pillars makes it harder to build a system that delivers on expectations and requirements. Yet most Java teams will spend weeks tuning infrastructure and platform choices while treating the Java runtime as a fixed background dependency. In practice, the Java runtime shapes throughput, tail latency, warmup behavior, memory efficiency, CPU usage, operational consistency, and the quality of runtime diagnostics available during troubleshooting. If those factors influence system behavior, then ignoring the JVM creates a blind spot in the Well-Architected review itself. <\/p>\n\n\n\n
That is the main point I want to make here. I am not claiming that the JVM replaces architecture. It does not. I am also not claiming that switching runtimes magically makes a workload \u201cWell-Architected\u201d \u2014 it will not. What I am arguing is simpler and, in my view, harder to dismiss: for Java workloads on AWS, the runtime is part <\/em>of the architecture. For architects who take the six AWS Well-Architected Framework pillars seriously, they should not overlook a layer that can materially affect all six, and in some cases affect them significantly.<\/mark> [1] <\/p>\n\n\n\n One of the most striking things about AWS architecture reviews is how much effort goes into optimizing everything around the application. Teams will analyze EC2 families, Graviton migration, EKS scaling policies, service mesh choices, storage tiers, network boundaries, and observability dashboards. But in many Java estates, they still run the default JVM choice without stopping to ask a more fundamental question: is the runtime itself helping or hurting the outcomes they are trying to achieve? <\/p>\n\n\n\n This is where I think many Well-Architected reviews are incomplete. If you are reviewing a Java workload for performance efficiency, but you are not asking how efficiently the JVM converts CPU cycles into business throughput, the review is incomplete. If you are reviewing cost optimization, but you are not asking how much runtime overhead is spent on compilation, warmup, and GC behavior across a fleet, the review is incomplete. If you are reviewing operational excellence, but you are not asking whether the runtime provides enough observability to identify root cause quickly in production, the review is incomplete. The same logic carries into reliability, security, and sustainability. <\/p>\n\n\n\n This is precisely why I think the JVM belongs in the AWS Well-Architected discussion. In cloud-native Java systems, runtime behavior is not just an implementation detail. It affects how quickly services stabilize after startup, how efficiently they scale, how predictable they are under load, and how easy they are to diagnose when things go wrong. Those are architectural outcomes, not low-level trivia. <\/p>\n\n\n\n The easiest way to underestimate the JVM is to think of it as plumbing. In reality, it is one of the most consequential moving parts in a Java system.<\/mark> <\/mark><\/strong>The JIT compiler influences steady-state performance. The garbage collector influences latency consistency. Warmup behavior influences startup and scale-out efficiency. Runtime observability influences how quickly engineers can detect unexpected behavior in production. <\/p>\n\n\n\n Observability is especially important here. AWS frames operational excellence around building software correctly while consistently delivering a great customer experience, and that includes designing and operating workloads effectively at scale. In real Java systems, many of the hardest production issues do not show up cleanly at the application framework level. They show up as CPU spikes, lock contention, allocation pressure, compilation effects, or latency outliers that cannot be explained from infrastructure metrics alone. <\/p>\n\n\n\n This is one reason I think Java Flight Recorder (JFR) and profiling belong in this discussion. Azul Prime supports Java Flight Recorder, and JFR gives teams a structured way to see what the runtime is doing. [2] Azul Mission Control can analyze those recordings, and async-profiler support makes it easier to capture useful low-overhead production data in JFR-compatible form. That does not just help performance engineers. It helps operators, SREs, platform teams, and architects move from symptoms to root causes faster. A workload is easier to operate well when the runtime is observable enough to explain itself. <\/p>\n\n\n\n So when I say the JVM belongs in a Well-Architected review, I do not just mean that it can make things faster. I mean that it can make a workload easier to understand, easier to optimize, and easier to operate. That is a much broader and more interesting argument. <\/p>\n\n\n\n AWS describes the Well-Architected Framework as a way to understand the pros and cons of decisions made while building systems, and warns that neglecting the six pillars can make it challenging to build a system that delivers on expectations and requirements. Those six pillars are operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Together, they help teams build stable and efficient systems. <\/p>\n\n\n\n With that framework in mind, the interesting question is not whether the JVM touches the six pillars. It clearly does. The more useful question is how strongly it affects each one, and where Azul Prime can make the biggest difference. <\/p>\n\n\n\n This pillar makes the strongest case for Azul Prime. <\/p>\n\n\n\n AWS defines performance efficiency as the ability to use cloud resources efficiently to meet performance requirements and maintain that efficiency as demand changes and technologies evolve. [3] That is almost a perfect description of why JVM choice matters in Java workloads. A runtime that delivers more throughput, more predictable latency, and faster convergence to steady-state performance is using cloud resources more efficiently. <\/p>\n\n\n\n Azul Prime is built for exactly this kind of problem. Azul Prime\u2019s Zing JVM combines the Falcon JIT compiler and C4 garbage collector to improve both code execution and latency consistency. [4] Falcon is designed to generate high-performance machine code. C4 is designed to avoid the classic \u201cstop-the-world” pause behavior that becomes increasingly painful in large, latency-sensitive Java deployments. [5] Prime also brings ReadyNow and Optimizer Hub into the picture, which means this is not just about the speed of a single JVM after it has been running for a long time. It is about how quickly and consistently a workload can reach optimized behavior across a fleet. <\/p>\n\n\n\n That distinction matters on AWS. In a static environment, teams can sometimes tolerate mediocre warmup because it is amortized over long uptime. In elastic AWS environments, fresh JVMs appear all the time. Pods get rescheduled, nodes get recycled, deployments happen frequently, and autoscaling introduces new capacity under pressure. In those environments, performance efficiency is not only about the eventual peak speed of the code. It is also about the path the workload takes to get there. Prime improves that path. <\/p>\n\n\n\n This argument is no longer theoretical. In our Kafka benchmark<\/a>, the results were clear – simply switching the underlying JVM can materially change throughput with minimal engineering effort. That matters because Kafka is a good example of the kind of large-scale Java system where the runtime is not a footnote. It is part of the performance architecture. <\/p>\n\n\n\n AWS defines cost optimization as delivering business value at the lowest price point. [6] That sounds obvious, but in practice many cloud cost discussions stay too close to the infrastructure layer. Teams talk about reserved capacity, Spot usage, Graviton migration, rightsizing, and storage tiers. All of that matters. But for Java workloads, cost is also shaped by how efficiently the runtime turns infrastructure spend into useful work. <\/p>\n\n\n\n Where this becomes really interesting is in horizontally scaled environments. Modern AWS workloads are rarely static. They scale out, restart, redeploy, and replace capacity constantly. In those environments, one of the hidden taxes is repeated optimization work. Each JVM spends CPU rediscovering profiles, compiling methods, and working toward a state that other JVMs in the cluster may already have reached earlier. It is runtime overhead showing up as cloud spend. <\/p>\n\n\n\n This is why I see Optimizer Hub as one of the most important parts of the story. Optimizer Hub can offload JIT compilation and share optimization knowledge across the fleet. [7] Cloud Native Compiler moves JIT work to dedicated resources instead of making every client JVM pay the full local cost. [8] ReadyNow Orchestrator records and serves profiles in a way that makes ReadyNow operationally practical in large fleets of containerized environments. [9] That combination changes the economics of horizontal scale because compiled knowledge and warmup history stop being local, disposable artifacts and start becoming reusable fleet-level assets. <\/p>\n\n\n\n That is a very AWS-relevant idea. If workloads are elastic, repeated local warmup and repeated local JIT work can become an invisible cost multiplier. Optimizer Hub helps break that pattern. And that is why it belongs naturally in a cost optimization conversation, not just in a performance tuning conversation. <\/p>\n\n\n\n This is why performance and cost should not be treated as separate discussions. Better steady-state code from Falcon can increase carrying capacity. Better latency consistency from C4 can reduce the need for defensive overprovisioning. Faster warmup can reduce the period during which fresh instances are consuming compute without yet delivering their full business value. All of those effects change the cost profile of a Java workload on AWS. <\/mark><\/p>\n\n\n\n It also aligns well with how we talk about cloud cost optimization more broadly. The cost question should not only be \u201cWhich AWS service is cheaper?\u201d It should also be \u201cHow much useful business work are we getting from the compute we already pay for?\u201d For Java on AWS, Azul Prime gives a much better answer to that question than most teams assume. [10]<\/p>\n\n\n\n AWS defines operational excellence as a commitment to building software correctly while consistently delivering a great customer experience. It includes designing the workload, operating it at scale, and evolving it over time. [11] That is exactly where many Java organizations feel the pain of runtime behavior. <\/p>\n\n\n\n Java teams do not only debug application bugs. They debug startup effects, compilation transitions, GC behavior, lock contention, allocation spikes, and production incidents where the application seems \u201cslow\u201d but nobody can explain why from infrastructure metrics alone. In many organizations, the platform team sees CPU, the SRE team sees latency, the developer team sees no obvious bug, and the runtime remains a blind spot in the middle. That is not operational excellence. That is fragmented troubleshooting. <\/p>\n\n\n\n Azul Prime improves this in two ways. First, it reduces a category of operational surprises by making runtime behavior more predictable \u2014 especially around warmup and latency consistency. Second, it improves the ability to diagnose what is actually happening inside the JVM. JFR, Azul Mission Control, and async-profiler support give teams better visibility into what the runtime is doing so they can identify root cause faster and with more confidence. [12]<\/p>\n\n\n\n This is more important than it may sound. A workload is easier to operate when teams can answer practical questions quickly. Why do new pods perform differently just after scale-out? Why is CPU higher after deployment? Why does one subset of instances stabilize faster than another? Why does the service only miss its latency objective during ramp-up? Those are AWS operations questions, but in Java workloads the answers often live inside the runtime. <\/p>\n\n\n\n That is why runtime observability belongs much more centrally in architecture reviews. Architects often care deeply about dashboards, traces, and logs, but if the JVM layer is opaque, they still miss part of the operational picture. Prime makes that layer both more stable and more visible, which is exactly what operational excellence needs. <\/p>\n\n\n\n AWS defines reliability as the ability of a workload to perform its intended function correctly and consistently when expected to do so, throughout its entire lifecycle. [13] That is a broad and important definition. It also points to something many teams learn the hard way: in Java systems, performance instability often turns into reliability incidents. <\/p>\n\n\n\n A long pause, a heavy warmup period, or erratic runtime behavior may begin as a performance problem, but users do not experience it that way. They experience failed requests, timeouts, retry storms, queue growth, noisy autoscaling, or inconsistent service behavior. Reliability issues are often the operational form of runtime inefficiency. <\/p>\n\n\n\n Azul Prime does not replace good AWS reliability design. You still need proper service boundaries, resilience patterns, health checks, tested recovery, and sound deployment practices. But Prime can remove a meaningful category of runtime-induced instability. The C4 garbage collector is designed to maintain high throughput and low latency even with large heap sizes, and that consistency matters because predictable systems are easier to scale, alert on, and recover around than systems with sharp latency pathologies. <\/p>\n\n\n\n This is one of the most understated benefits of a better JVM. The value is not only higher benchmark numbers, but in fewer situations where runtime behavior leaks upward and destabilizes the service. The result is better reliability, even when nothing in the application architecture has changed. <\/p>\n\n\n\n Security is probably the weakest connection to this article\u2019s central argument, but it still matters. AWS defines security as protecting data, systems, and assets while using cloud technologies to improve security. [14] For Java systems, the runtime should not be oversold here. Prime is not primarily a security product. But it is still part of the workload\u2019s software supply chain and runtime governance model. <\/p>\n\n\n\n That matters because many organizations are disciplined about cloud security controls while being much less disciplined about runtime lifecycle management. They know who owns IAM. They know who owns KMS. They know who owns VPC boundaries. But they have less transparency about who owns JVM patching strategy, supportability, and consistency across environments. That gap is easy to underestimate until it becomes an audit or operational risk. <\/p>\n\n\n\n A Well-Architected Java workload is stronger when the runtime is supported and intentionally managed. Even if security is not the headline reason to adopt Prime, it is still part of the case for treating the JVM as a first-class architectural component rather than a forgotten dependency. <\/p>\n\n\n\n AWS frames sustainability around environmental impacts, especially energy consumption and efficiency, and calls them important levers for reducing resource usage. [15] That should resonate with any architect who has ever seen a fleet burning compute on work that creates little to no customer value. <\/p>\n\n\n\n For Java systems, sustainability is closely connected to performance efficiency and cost optimization. If the same workload can process more business transactions per core, require fewer instances to handle a target load, or reduce the amount of repeated optimization work done across a cluster, then resource usage drops. Lower resource usage means lower cost, but it also means lower waste. <\/p>\n\n\n\n This pillar is worth highlighting because it reminds architects that \u201cwaste\u201d has more than one dimension. Excess CPU spent on repeated JIT work is not only a billing issue. Overprovisioning to compensate for warmup behavior is not just a budget issue. Inefficient runtime behavior is also an energy efficiency issue. When Prime reduces that waste, it contributes to sustainability in a very practical and measurable way. <\/p>\n\n\n\n Not every Java workload needs this level of attention. Some are lightly loaded, operationally simple, or not sensitive enough for runtime choice to meaningfully change the business outcome. That is fine. Well-Architected thinking is about trade-offs, not ideology. <\/p>\n\n\n\n But there are environments where JVM choice matters far more than teams tend to assume. High-CPU services, customer-facing APIs with strict latency objectives, memory-intensive applications, large Java fleets, and workloads that scale horizontally are all strong candidates. These are the kinds of systems where warmup, JIT overhead, GC behavior, and runtime observability stop being secondary details and start becoming drivers of cost, performance, and operational stability. <\/p>\n\n\n\n Kafka is a good example because it is both throughput-heavy and operationally central in many architectures. Not every workload looks like Kafka. But the benchmark proves a broader point: if changing the JVM can materially change the outcome for a foundational platform like Kafka, with minimal engineering effort, then the runtime is not a side topic. It is part of the architecture. [16]<\/p>\n\n\n\n I am not claiming that Azul Prime replaces good AWS architecture. It does not. It does not remove the need for proper observability, resilience engineering, IAM discipline, cost governance, or sound deployment practice. And it does not affect all six pillars equally. <\/p>\n\n\n\n If there\u2019s one takeaway: Many AWS Java reviews are missing an important layer when they do not consider the JVM at all. For the right workloads, that omission is not minor. It can affect performance efficiency, cost optimization, operational excellence, reliability, and even the strength of the organization\u2019s security and sustainability posture. [17]<\/p>\n\n\n\n The final question to ponder: <\/p>\n\n\n\n If the JVM can materially influence so many AWS Well-Architected outcomes for Java workloads, why is it still absent from so many architecture reviews? <\/mark><\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Learn how Azul Prime aligns to AWS\u2019s Well-Architected Framework.<\/p>\n","protected":false},"author":92,"featured_media":93295,"template":"","resource_categories":[494,524,669,771],"industry":[],"product":[280],"role":[57,61,64,69],"resource_topic":[273,772,773],"class_list":["post-93285","article","type-article","status-publish","has-post-thumbnail","hentry","resource_categories-java-performance","resource_categories-high-performance-jvm","resource_categories-performance","resource_categories-aws","product-prime","role-architect","role-cto","role-head-of-engineering","role-vp-engineering","resource_topic-performance","resource_topic-aws","resource_topic-well-architected-framework"],"acf":{"article_smart_summary":" In this post you will learn:<\/span>\u00a0<\/span><\/p>\n<\/a>The missing layer in many AWS Java reviews<\/h2>\n\n\n\n
<\/a>Why the JVM belongs in the Well-Architected discussion<\/h2>\n\n\n\n
<\/a>A quick refresher on the six AWS pillars<\/h2>\n\n\n\n
\n
\n
\n
\n
\n
\n
<\/a>Performance Efficiency: Where JVM choice has the clearest impact<\/h2>\n\n\n\n
<\/a>Cost Optimization: Where better JVM behavior changes the economics<\/h2>\n\n\n\n
<\/a>Operational Excellence: Fewer surprises, better diagnostics, faster root cause analysis<\/h2>\n\n\n\n
<\/a>Reliability: Because runtime stability often becomes a reliability issue<\/h2>\n\n\n\n
<\/a>Security: Not the main story, but still part of a Well-Architected runtime strategy<\/h2>\n\n\n\n
<\/a>Sustainability: Better runtime efficiency reduces waste, not just cost<\/h2>\n\n\n\n
<\/a>The AWS Java workloads where runtime has the most impact<\/h2>\n\n\n\n
<\/a>The JVM belongs in the conversation<\/h2>\n\n\n\n
<\/a>References<\/h2>\n\n\n\n
\n
\n