Geospatial in Cloud: AWS

AWS Geospatial Landscape

Eight AWS services matter for geospatial. Most production workloads use only four. Here is the full map so you know what exists - and what to ignore.

Lambda for Geospatial

The cold start problem is the number one issue nobody talks about honestly. GDAL + rasterio + numpy together form a ~150MB Lambda layer. The first invocation after a period of inactivity takes 8-12 seconds to initialise. That is unacceptable for real-time APIs but perfectly fine for batch processing and event-driven pipelines.

Warm invocations run in 200-400ms for typical raster tile generation. The trick is deciding whether you need provisioned concurrency ($0.015/GB-hour) or can accept cold starts for batch and event-driven processing.

Here is a production Lambda function that extracts a tile from a Cloud Optimised GeoTIFF stored on S3:

import rasterio
from rasterio.windows import Window

def handler(event, context):
    s3_path = f"s3://{event['bucket']}/{event['key']}"
    bbox = event['bbox']  # [minx, miny, maxx, maxy]

    with rasterio.open(s3_path) as src:
        window = src.window(*bbox)
        data = src.read(window=window)

    return {
        "statusCode": 200,
        "shape": data.shape,
        "dtype": str(data.dtype),
    }

S3 + COG Storage

Why COG matters on S3: HTTP range requests mean Lambda reads only the pixels it needs. A 50GB satellite image can serve a 1km x 1km tile in 50-200ms without downloading the entire file. This is the pattern that makes serverless geospatial economically viable.

Storage cost: $0.023/GB/month on S3 Standard. A 1TB raster catalogue costs $23/month. For archival data accessed less than once a month, S3 Glacier Instant Retrieval drops this to $0.004/GB/month - an 83% reduction.

import rasterio

# Direct S3 access via GDAL virtual filesystem
with rasterio.open("s3://my-bucket/imagery/scene.tif") as src:
    # Read only a specific window (HTTP range request)
    window = rasterio.windows.from_bounds(
        left=13.3, bottom=52.5, right=13.4, top=52.6,
        transform=src.transform
    )
    data = src.read(window=window)
    print(f"Read {data.shape} pixels from {src.width}x{src.height} raster")

The STAC catalogue pattern ties this together: index your COGs on S3 with a STAC API. Query by date, bounding box, cloud cover - then access individual COGs directly via range requests. No database, no file server, just S3 + metadata.

For a deep dive on COG, GeoParquet, and STAC formats, see our cloud-native geospatial formats guide.

Athena Spatial SQL

Athena now supports spatial functions on GeoParquet data stored in S3. No database to manage, no infrastructure to provision. Point Athena at an S3 bucket of GeoParquet files and query.

SELECT
  p.parcel_id,
  p.area_sqm,
  ST_Distance(p.geometry, ST_Point(13.4, 52.5)) as distance_m
FROM "s3://my-bucket/parcels/" p
WHERE ST_Contains(
  ST_GeomFromText('POLYGON((13.3 52.5, 13.4 52.5, 13.4 52.6, 13.3 52.6, 13.3 52.5))'),
  p.geometry
)
ORDER BY distance_m
LIMIT 100

Cost: $5 per TB of data scanned. With GeoParquet's columnar format, you typically scan 10-20% of the total data (only the columns you reference), so effective cost is $0.50-$1.00 per TB of actual data stored. For 100 queries a month on a 1TB dataset, that is roughly $5-10/month total.

The limitation: Athena is not a real-time database. Query execution takes 3-15 seconds depending on data volume and complexity. For sub-second spatial queries serving a web application, use PostGIS on RDS. Athena is for ad-hoc analysis and batch reporting.

Step Functions Pipelines

Geospatial workflows are rarely a single operation. Satellite imagery arrives, needs validation, conversion to COG, quality checks, and catalogue updates. Step Functions orchestrates this without you managing any servers.

A real production pipeline - satellite imagery ingestion:

Real Benchmarks

These numbers come from production workloads running in us-east-1. Lambda configured with 1769MB memory (1 full vCPU). S3 Standard storage class. We include the cold start numbers because pretending they do not exist helps nobody.

Cost Analysis

The cost advantage of AWS for geospatial is real - but only if you have the engineering capability to build and maintain the stack. Here is the side-by-side comparison for a mid-sized team processing 10K tiles per day with 1TB of raster storage.

When NOT to Use AWS for Geospatial

We build geospatial pipelines on AWS for clients. We still tell some of them not to. These are the scenarios where AWS is the wrong choice:

Reference Architecture

This is the production architecture we deploy for clients processing 1TB+ of geospatial data. Four layers, four AWS services per layer, no over-engineering.

The STAC catalogue sits alongside this: a Lambda-backed API with DynamoDB storage that indexes all processed data. Users query the catalogue by bounding box, date range, or sensor type, then access individual COGs directly from S3 via range requests. Total infrastructure cost for the catalogue: under $10/month.