Cloud Architecture for Geospatial Artificial Intelligence
Part 2: AWS Building Blocks for Geospatial and AI Scalable Architectures
Introduction
Part 1 established the conceptual foundations: cloud-native formats (COG, GeoZarr) that enable efficient data access, geospatial foundation models that learn semantic representations, and embeddings as compact vectors encoding spatial structure and temporal patterns. These concepts address what satellite imagery analysis can achieve through modern AI approaches. Part 2 shifts focus to how: the infrastructure building blocks required to deploy these capabilities at scale.
Constructing scalable architectures for geospatial AI presents distinct challenges. Processing petabytes of satellite imagery demands storage systems optimized for partial access patterns, downloading entire Sentinel-2 scenes wastes bandwidth when analysis targets specific geographic extents or spectral bands. Generating embeddings through GPU-intensive foundation model inference requires compute infrastructure that scales elastically with variable workloads while controlling costs during idle periods. Orchestrating multi-stage pipelines, from image acquisition through preprocessing, embedding generation, storage, and analytics, necessitates workflow management that handles geographic parallelization, error recovery, and execution monitoring. Serving results through visualization APIs and change detection analytics demands low-latency compute that scales automatically with traffic patterns.
In our testing and deployment work, we explored various AWS services addressing these architectural needs. This article presents the building blocks we evaluated: S3 for storage, Batch for GPU compute, Step Functions for orchestration, and Lambda for serving.
The following sections examine four core infrastructure needs: petabyte-scale imagery storage, GPU inference at scale, complex workflow orchestration, and analytics serving. Each section identifies the architectural requirement, presents the corresponding AWS service, explains the mapping rationale, and describes how the components integrate into complete processing pipelines. The conclusion addresses container management with Docker and ECR, which ensures consistency across all deployment environments.
2.1 Storage Need: Petabyte-Scale Imagery
The Need
Satellite imagery archives grow continuously. Sentinel-2 captures 1.6 TB of new imagery daily. Landsat spans five decades of observations. Commercial providers like Planet add terabytes more each day. Foundation model workflows compound this: beyond storing source imagery, you need space for embeddings, change detection outputs, and analytics results.
Three storage challenges emerge at scale.
First, partial access matters more than full downloads. Analyses rarely need complete global coverage. You’re monitoring a forest region, tracking urban expansion in specific cities, or studying coastal zones. Downloading entire 500MB satellite scenes wastes bandwidth when you need only the 50MB subset covering your study area. The same applies to spectral bands: most applications use 3–4 bands from 13-band stacks, not all thirteen.
Second, data ages differently. Recent imagery (last 30 days) gets accessed frequently for active monitoring. Historical archives from years past support trend analysis but tolerate slower retrieval. Treating all data equally means overpaying for storage you rarely touch, or accepting slow access for data you need immediately.
Third, volumes grow faster than expected. A single regional study area might contain 100 satellite tiles. Processing these tiles generates millions of embedding vectors, each requiring storage. Expand monitoring to multiple regions or extend the timeline across several years, and storage needs jump from gigabytes to terabytes to petabytes. The storage system must handle this growth without requiring upfront capacity planning or forcing data migration when limits are reached.
AWS Services
Amazon S3 (Simple Storage Service) addresses these three storage challenges directly.
For partial access, S3 supports HTTP range requests, enabling applications to retrieve specific byte ranges from files without downloading entire objects. Combined with cloud-native formats like COG and GeoZarr that organize data into internal chunks, this capability enables precise spatial queries where a 500MB satellite scene organized as COG allows downloading just the 50MB geographic subset needed for analysis. GeoZarr extends this pattern to multidimensional arrays by chunking across latitude, longitude, time, and spectral bands, allowing applications to request only the spatial extent, time window, and bands required for their specific use case.
For aging data, S3 provides storage class tiers with automated lifecycle policies that handle transitions without manual intervention. Recent imagery stays in S3 Standard for millisecond-latency access, while data older than 90 days migrates automatically to S3 Intelligent-Tiering, which moves objects between access tiers based on actual usage patterns. Historical archives beyond one year transition to S3 Glacier, offering archival storage at significantly reduced cost with retrieval times ranging from minutes to hours depending on the urgency level selected. These transitions happen automatically based on rules defined once during initial setup, eliminating the need for ongoing manual data movement or storage optimization efforts.
For growing volumes, S3 scales without capacity planning, supporting objects ranging from bytes to 5TB with no practical limits on bucket size, allowing petabyte-scale archives to grow incrementally as data arrives. This eliminates provisioning decisions, migration requirements when crossing capacity thresholds, and the need for continuous capacity monitoring, as the storage infrastructure expands automatically to accommodate incoming data.
S3 serves as the foundation for cloud-native geospatial formats like COG, GeoZarr and GeoParquet, both designed to leverage S3’s byte-range retrieval through internal chunking strategies. Beyond simple file storage, these formats enable building spatial lakehouses where embeddings, satellite imagery, and analytics results coexist in a unified architecture, allowing SQL queries directly against geospatial data, joining embedding vectors with administrative boundaries, and executing spatiotemporal analytics without moving data into traditional databases.
2.2 Compute Need: GPU Inference at Scale
The Need
Foundation models require GPU acceleration. Processing a single satellite patch through Clay 1.5’s 632 million parameters takes milliseconds on GPU but minutes on CPU. For a regional study area containing 100 tiles, each generating millions of embeddings, CPU-based inference becomes impractical. GPUs are non-negotiable for any deployment beyond small-scale testing.
Three compute challenges emerge at scale.
First, parallelization determines throughput. A single GPU processes tiles sequentially. Covering large geographic areas means distributing work across multiple GPUs running simultaneously. The infrastructure must coordinate this parallel execution, track which tiles have processed, and aggregate results when all complete.
Second, workloads are intermittent and bursty. Embedding generation runs as batch jobs, not continuous services. You process new imagery when it arrives, then infrastructure sits idle until the next batch. Running GPU instances continuously during idle periods wastes resources. The system needs to scale from zero to dozens of GPUs when work arrives, then scale back to zero when processing completes.
Third, GPU costs dominate infrastructure spending. GPU instances represent the single largest operational expense in foundation model deployments. Processing large areas at standard pricing quickly becomes expensive. Cost reduction isn’t optional, it determines whether deployment is financially viable. The infrastructure must provide mechanisms to reduce GPU costs without sacrificing processing capability or requiring complex manual optimization.
AWS Services
AWS Batch solves these three compute challenges through a simple concept: compute environments. A compute environment tells Batch which GPU types to use, how many instances to launch, and whether to prioritize cost savings over guaranteed availability. Once configured, Batch handles everything automatically.
For parallelization, Batch distributes satellite tile processing across multiple GPUs without manual coordination. You submit 100 Sentinel-2 tiles for embedding generation to a queue. Batch provisions the GPU instances needed, pulls your foundation model container, assigns each tile to an available GPU, and tracks which tiles have completed processing. Geographic areas process in parallel automatically, no cluster management required.
For intermittent workloads, Batch scales GPU instances based on satellite imagery processing demands. When new imagery arrives and embedding jobs queue up, instances launch within minutes. When all tiles finish processing, instances terminate automatically. You pay only for the hours spent generating embeddings, not for idle GPUs waiting between satellite acquisition cycles.
Get Hajji Hicham’s stories in your inbox
Join Medium for free to get updates from this writer.
For cost optimization, Batch uses Spot instances to reduce embedding generation costs by 70–90%. Spot instances are spare AWS capacity offered at steep discounts, with the tradeoff that AWS can reclaim them with short notice. Batch handles this automatically: when a Spot instance gets interrupted mid-tile, it reschedules that satellite tile to another GPU and continues processing. Since each tile generates embeddings independently, interruptions simply delay individual tiles without cascading failures across the workflow. Configure Spot in your compute environment once, and Batch manages everything else.
Behind this compute infrastructure sits Docker and ECR (Elastic Container Registry), which ensure foundation models run identically across all GPU instances. Clay 1.5 requires specific versions of PyTorch, GDAL, and Python libraries. Docker packages everything (model weights, dependencies, code) into a container image stored in ECR with tags like clay:1.5.0. When Batch launches a GPU instance, it pulls this exact container, guaranteeing identical embeddings regardless of which instance processes the tile. This consistency proves critical for Spot instances: when a tile restarts on a different GPU after interruption, the container ensures identical results, eliminating artifacts in change detection workflows.
2.3 Orchestration Need: Complex Workflows
The Need
Embedding generation isn’t a single operation. It’s a multi-stage workflow: identify new satellite imagery in storage, filter scenes by cloud cover and date, divide coverage into processable tiles, launch parallel GPU jobs for each tile, validate output quality, and store results in appropriate formats. Each stage depends on outputs from the previous stage, and processing a large region requires coordinating hundreds of these workflows running simultaneously.
Three orchestration challenges emerge at scale.
First, coordination across stages becomes complex. You can’t start embedding generation until imagery preprocessing completes. You can’t store results until quality validation passes. Managing these dependencies manually, writing custom code that waits for stage A to finish before starting stage B, multiplied across hundreds of parallel workflows, creates brittle systems that break when conditions change.
Second, failures happen constantly at scale. A satellite file arrives corrupted from the provider. Network connections timeout during S3 transfers. A Spot GPU instance gets reclaimed mid-processing. At small scale, you handle these manually. At large scale, with thousands of tiles processing daily, manual intervention becomes impossible. The system needs to distinguish between transient failures worth retrying (network timeout) and permanent failures to skip (corrupted file), then act accordingly without human input.
Third, visibility into workflow status matters. When processing 500 tiles across a study area, you need to know: which tiles completed successfully, which are currently processing, which failed and why, and whether the overall workflow is progressing normally or stalled. Without this visibility, debugging problems means digging through logs for hundreds of independent jobs, trying to reconstruct what happened and where things went wrong.
AWS Services
Step Functions addresses these three orchestration challenges through visual workflow management. Instead of writing custom coordination code, you define workflows as state machines, diagrams showing each processing step and how they connect. Step Functions executes the workflow, tracks progress, and handles failures automatically.
For coordination across stages, Step Functions manages dependencies between workflow steps. Define the sequence: list new satellite imagery → filter by cloud cover → divide into tiles → launch Batch jobs → validate outputs → store results. Step Functions ensures each stage completes before the next begins, passes outputs from one stage as inputs to the next, and handles the logic of coordinating hundreds of parallel tile processing workflows. When preprocessing finishes for a tile, Step Functions automatically triggers embedding generation for that tile without manual intervention.
For handling failures, Step Functions implements automatic retry logic with configurable rules. A network timeout during S3 transfer triggers automatic retry with exponential backoff. A corrupted satellite file triggers a different path: log the error, skip that tile, and continue processing other tiles. Step Functions distinguishes between transient failures (retry automatically) and permanent failures (skip and continue) based on error types you define. When a Spot instance gets reclaimed mid-processing, Step Functions detects the failure and reschedules that tile to another GPU without human input.
For visibility, Step Functions provides a visual dashboard showing workflow execution in real time. Each workflow execution appears as a diagram where completed steps show green, in-progress steps show blue, and failed steps show red. Click any step to see its inputs, outputs, and execution logs. Processing 500 tiles across a study area means 500 workflow executions, each tracked individually. This visualization makes debugging straightforward: identify which tiles failed, examine the error for each, and understand whether failures cluster around specific issues (such as a corrupted imagery batch) or appear randomly (network timeouts).
CloudWatch collects logs and metrics from all components, generating log files for each processing step. When a tile fails during processing, these log files capture the error details: GPU memory issues, network timeouts, or invalid imagery files. I was pleasantly surprised by AWS Q Developer’s potential for analyzing these logs: instead of manually searching through thousands of log lines, Q Developer reads CloudWatch logs, identifies failure patterns, and explains what went wrong in plain language. For example, if multiple tiles fail with GPU memory errors, Q Developer pinpoints that Clay 1.5 needs larger instances for high-resolution imagery and suggests the fix, significantly accelerating troubleshooting.
2.4 Serving Need: Analytics and Visualization
The Need
Once embeddings are generated and stored, applications need to access and visualize them. Users want to explore change detection results on interactive maps, query embeddings to find similar areas, or generate time series showing how a region evolved. These operations read stored embeddings rather than running foundation models, they execute in seconds instead of the minutes or hours required for embedding generation.
Three serving challenges emerge at scale.
First, traffic patterns are unpredictable. A web mapping application might sit idle for hours, then suddenly handle dozens of users when a report gets published. Analytical queries arrive sporadically throughout the day. Running servers continuously to handle occasional bursts wastes resources during idle periods, while undersized infrastructure degrades performance when traffic spikes.
Second, latency requirements vary widely. Interactive map tiles need subsecond responses, users expect instant loading as they pan. Similarity searches comparing embeddings can tolerate a few seconds for analytical exploration. The serving infrastructure must handle this range without forcing you to build separate systems for each use case.
Third, operational overhead must stay minimal. After investing effort in embedding generation workflows, you don’t want to spend equal time managing web servers and auto-scaling configurations for serving results. The infrastructure should handle traffic automatically, scale from zero to thousands of requests without manual tuning, and charge only for actual usage rather than continuous operation.
AWS Services
Lambda addresses these three serving challenges through serverless computing. Unlike traditional servers that run continuously, Lambda executes code only when requests arrive. No servers to manage, no capacity to provision, no infrastructure to maintain.
For unpredictable traffic, Lambda scales automatically from zero to thousands of concurrent executions. When your web map sits idle, you pay nothing. When dozens of users start exploring change detection results simultaneously, Lambda provisions enough instances to handle all requests within seconds. When traffic drops, Lambda scales back to zero automatically. This elastic scaling happens without configuration, you define the function code and Lambda handles everything else.
For varying latency requirements, Lambda handles both interactive and analytical workloads through the same infrastructure. A function generating map tiles executes in milliseconds, retrieving the necessary embedding data from S3, computing change metrics, and returning rendered tiles. A function running similarity searches across thousands of embeddings takes a few seconds, acceptable for analytical queries.
For minimal operational overhead, Lambda eliminates server management entirely. Deploy your code as a function, specify memory requirements, and Lambda handles provisioning, scaling, patching, and monitoring. The same pattern extends across use cases: Lambda functions read embeddings from storage, compute analytics, and return results through APIs without managing any infrastructure.
TiTiler demonstrates how serverless approaches differ from traditional cartographic servers like GeoServer or MapServer, which run continuously and require manual capacity planning. By adopting Lambda’s on-demand execution model, TiTiler addresses these serving constraints naturally through its architecture rather than operational configuration. Recently, an even newer approach has emerged: deck.gl-raster enables client-side rendering directly from cloud-optimized formats without any tile server at all, pushing the serverless paradigm further by eliminating backend infrastructure entirely for certain use cases.
Conclusion
This article presented AWS building blocks for deploying geospatial foundation models at scale. The right combination of Batch for GPU compute, Lambda for serverless execution, Step Functions for workflow orchestration, and strategic use of Spot versus on-demand instances proves highly valuable for geospatial AI architects at every architecture level. Understanding how these components interact, when to apply each, and how to balance cost against reliability determines whether deployments succeed operationally and financially. Teams assemble these building blocks differently based on their specific scale, processing frequency, and budget constraints.
Part 3 shifts to operational realities: technical constraints, cost optimization strategies, and lessons learned from deploying geospatial foundation models in production.
Part 3: Technical Constraints, Architectural Choices, and Lessons Learned [Link when published]
