Java on Cloud Terms – Best Practices for AWS, Azure, and GCP

Java has long been a heavyweight in the enterprise world – stable, strongly typed, and backward-compatible. But during the first major wave of cloud adoption, Java was often left on the sidelines. It could run in the cloud – but it wasn’t always practical. Long startup times, high memory consumption, and poor containerization made many developers turn to faster alternatives like Node.js, Go, or Python.

But things have changed.

Male entrepreneur assisting female colleague working on computer at office

With virtual threads, GraalVM native builds, SnapStart, structured concurrency, and cloud-native frameworks like Quarkus and Micronaut, Java has become one of the most cloud-capable languages out there.

In this article, we share our best hands-on experiences running Java on AWS, Azure, and GCP – and how we at HiQ build solutions that both developers and operations teams love.

Java in the Cloud – What’s Changed?

The short answer: almost everything.

A few years ago:

You couldn’t use Spring Boot in a Lambda function without waiting several seconds for a cold start.
A microservice using the JVM might need 1–2 GB of RAM just to get going.
Java apps were difficult to scale horizontally without tweaking the GC, heap, and OS interfaces.

Today:

Virtual threads in Java 21 allow you to handle thousands of concurrent requests using simple, blocking code.
GraalVM lets you compile Java into native binaries with sub-100 ms startup times.
Frameworks like Quarkus and Micronaut are built from the ground up for containers, Kubernetes, and serverless.

Most importantly – the cloud platforms themselves have gone all in on Java. All three major providers now offer first-class support, dedicated SDKs, optimized build tools, and ready-to-use deployment services for JVM-based applications.

Amazon Web Services – When Every Millisecond Counts

AWS has supported Java for a long time, but SnapStart was the game changer for serverless scenarios.

What is SnapStart?

A feature in AWS Lambda that snapshots the JVM state after initialization – and reuses it during cold starts. This means even “heavy” Java functions using Spring Boot can now start in under half a second.

When we use it:

In API services where latency matters, but we still want the full power of the Spring ecosystem. We’ve seen Spring Boot REST APIs with 100+ configurations cold start in under 400 ms using SnapStart – with zero code changes.

Field tips:

Use Spring Cloud Function or AWS Serverless Java Container to avoid vendor lock-in.
Want even lower latency? Run Quarkus with a native build in a container on Fargate or via the Lambda Runtime Interface Emulator.

Beyond serverless:

For container workloads, we often use Corretto (Amazon’s own OpenJDK distribution) together with EKS or ECS. We combine this with autoscaling and bin-packing using Karpenter to maximize vCPU capacity.

Microsoft Azure – Spring Boot in Suit and Slippers

Microsoft’s relationship with Java has evolved quickly – from a .NET-centric shop to an active Spring sponsor, releasing its own OpenJDK (Microsoft Build of OpenJDK), and providing Azure Spring Apps – a fully managed platform for Spring Boot apps.

Why Azure Spring Apps is interesting:

You get autoscaling, logging, metrics, secret management, and service discovery out of the box.
Spring Boot apps deploy as-is – no need for Docker, Kubernetes, or cloud-specific wiring.
Particularly valuable in large organizations with a “platform team vs. app team” setup.

When we use it:

In projects where business teams drive application development, and we want them to focus on code – not infrastructure. Azure Spring Apps becomes the perfect balance between platform control and developer freedom.

What about serverless?

Azure Functions supports Java 11 and 17. But unlike AWS, there’s no SnapStart – so we recommend Quarkus or Micronaut with native builds to minimize cold start time.

Field tips:

Connect Azure Monitor and Application Insights early – you’ll get valuable tracing, logs, and metrics for your production phase.
Use Spring Cloud Azure for smooth integration with Cosmos DB, Key Vault, Blob Storage, etc.

Google Cloud Platform – Containers First, Spring Second

Google has a strong Java heritage, but their platform is Kubernetes-first. Running Spring Boot on App Engine works – but the real power lies in GKE and Cloud Run.

Cloud Run = Serverless Containers

This is where Quarkus in native mode truly shines – startup times between 30–80 ms, low memory usage, and scale-to-zero capabilities. Perfect for bursty workloads or low-traffic services.

When we use it:

In solutions where we want to build a cluster of small services, some of which are only triggered on demand. We’ve built systems triggered by Pub/Sub events that batch-process data and return to idle – all using Cloud Run with Java native images.

Field tips:

Jib (Google’s build tool) makes it super easy to create container images directly from Maven/Gradle – no Dockerfile needed.
Use Spring Cloud GCP for auto-configuration with Pub/Sub, Spanner, Secret Manager, etc.
Cloud Functions for Java exist – but we find Cloud Run often provides better control and performance.

Lessons Across All Platforms

Native builds make a difference:
It’s not just hype – GraalVM native builds reduce both startup time and memory footprint. But they require preparation: adapting reflection, using the right frameworks (Spring Native is improving, but still not friction-free), and configuring the GC and image size properly.
Observability is non-negotiable:
System.out.println() just won’t cut it anymore. We always use OpenTelemetry (spans, traces, metrics) and push to Prometheus, Azure Monitor, Cloud Logging, or Datadog – depending on the client’s stack.
JVM choice matters more than you think:
Corretto, Temurin, Zulu, and other OpenJDK distributions differ in GC performance, default flags, and even subtle behaviors. We always benchmark under load before going to production.

Java in the Cloud: More Relevant Than Ever

Java has gone from “cloud-compatible” to “cloud-native.” Every new release shows this – with features like virtual threads and structured concurrency, platform support like SnapStart, and an ecosystem embracing containers, serverless, and automation.

And we see it in our solutions:

We deploy Spring Boot apps in Azure Spring Apps for rapid enterprise development.
• We spin up Quarkus-native containers in Cloud Run to optimize burst workloads.
• We use SnapStart on AWS Lambda to balance scale and latency in API requests.

Java isn’t just sticking around – it’s more relevant than ever.

Curious how we at HiQ use Java in the cloud to build scalable, cost-efficient, and modern solutions? Or want to join the team crafting cutting-edge systems? Reach out – we’re happy to share insights, code, and experience.

Join the Team