- AWS Glue ist der Orchestrator: Visual ETL für raumliche Datentransformationen, Spark-basiertes ETL für schwere Lasten mit Sedona-Unterstützung und Python Shell für leichtgewichtige Skripte. Hier beginnen
- S3 + COG: beliebige Regionen eines 50-GB-Rasters in 50-200ms per HTTP-Range-Requests lesen. Speicherkosten: $0,023/GB/Monat
- Athena Spatial SQL: GeoParquet auf S3 ohne Datenbank abfragen. $5 pro TB gescannter Daten, keine Infrastruktur
- Lambda + Step Functions für ereignisgesteuerte Pipelines. Cold Start mit GDAL: 8-12 Sekunden. Warm: 200-400ms. Ideal für Batch- und Event-Verarbeitung
AWS hat über 200 Services, aber kein “AWS für Geodaten”-Produkt. Das ist gleichzeitig die Herausforderung und die Chance. Sie stellen Ihren eigenen Stack aus Lambda, S3, Athena und Step Functions zusammen.
Richtig gemacht ist das gunstiger und flexibler als jede Fertiglosung. Falsch gemacht wird es zum Labyrinth aus Cold Starts, Timeout-Fehlern und unerwarteten Rechnungen. Dieser Beitrag beschreibt die Muster, die in der Produktion funktionieren, und die Fallstricke, auf die wir beim Aufbau von Geodaten-Pipelines auf AWS für Kunden gestossen sind, die Terabytes an Raster- und Vektordaten verarbeiten.
Serie: Geodaten in der Cloud
Dies ist Teil 2 unserer Serie “Geodaten in der Cloud”. Jeder Beitrag ist in sich abgeschlossen. Teil 1 behandelt Databricks. Teil 3 behandelt GCP. Lesen Sie den Beitrag, der zu Ihrem Stack passt.
AWS-Geodaten-Landschaft
Acht AWS-Services sind für Geodaten relevant. Die meisten Produktions-Workloads nutzen davon nur vier. Hier ist die vollstandige Übersicht, damit Sie wissen, was es gibt - und was Sie ignorieren können.
| SERVICE | GEODATEN-EINSATZ | WANN VERWENDEN |
|---|---|---|
| Glue | ETL-Orchestrierung (Visual ETL, Spark ETL, Python Shell) | Primarer Orchestrator für raumliche Datenpipelines |
| S3 | Speicherung (COG, GeoParquet, STAC-Kataloge) | Immer - primarer Speicher-Layer |
| Lambda | Serverlose Verarbeitung (Raster-Kacheln, Vektor-Transformationen) | Ereignisgesteuert, kleine bis mittlere Payloads |
| Athena | Raumliches SQL auf S3-Daten (GeoParquet) | Ad-hoc-Abfragen, keine Infrastruktur benötigt |
| Step Functions | Pipeline-Orchestrierung | Mehrstufige Workflows, Koordination von Glue + Lambda |
| ECS/Fargate | Container-basierte Verarbeitung | Rechenintensive, lang laufende Jobs |
| EMR (Spark) | Grossmassstabliche verteilte Verarbeitung | 100+ Mio. Datensätze, wenn Glue Spark nicht ausreicht |
| SageMaker | ML auf Geodaten | Klassifikation von Satellitenbildern |
KERNAUSSAGE: EINFACH BLEIBEN
Die meisten Geodaten-Workloads auf AWS nutzen nur 5 Services: Glue + S3 + Lambda + Athena + Step Functions. Glue ist das Rückgrat - es übernimmt ETL, raumliche Transformationen und Sedona-basierte Verarbeitung. Die unteren drei in dieser Tabelle sind Spezialwerkzeuge - greifen Sie nur darauf zurück, wenn die Kern-funf Ihren Workload wirklich nicht bewaltigen können. Mit EMR oder SageMaker zu beginnen, bevor Glue Spark ETL ausprobiert würde, ist Over-Engineering.
Glue: Der Orchestrator
AWS Glue ist der Startpunkt für die meisten Geodaten-Pipelines. Es gibt drei Varianten, jede für einen anderen Massstab raumlicher Workloads geeignet. Python Shell für kleine Datenmengen (unter 1 GB) - etwa Geocoding einer CSV-Datei oder Pufferung einiger tausend Flurstucke. Spark ETL für schwere Lasten - raumliche Joins auf Millionen von Features mit Apache Sedona. Und Visual ETL für Drag-and-Drop-Datentransformationen, wenn Ihr Team Analysten umfasst, die keinen Code schreiben.
Die entscheidende Unterscheidung: Glue Python Shell ist Single-Node (max 1 DPU, 16 GB Arbeitsspeicher). Für alles, was raumliche Joins im grossen Massstab, verteilte Rasterverarbeitung oder Datensätze über einige Gigabytes hinaus umfasst, benötigen Sie Glue Spark ETL. Hier kommt Sedona ins Spiel - Glue 4.0 unterstutzt Sedona nativ und bietet verteiltes raumliches SQL über einen verwalteten Spark-Cluster, ohne einen einzigen Server bereitzustellen.
| GLUE-VARIANTE | WORKER-TYP | SPEICHER | GEODATEN-EINSATZ |
|---|---|---|---|
| Python Shell | G.1X (max 1 DPU) | 16 GB | Kleine Vektor-Operationen mit GeoPandas. Geocoding, Pufferung, Formatkonvertierung |
| Spark ETL | G.2X | 32 GB | Verteilte raumliche Joins, Sedona SQL, Millionen von Features |
| Spark ETL | G.4X | 64 GB | Fensterbasierte Rasterverarbeitung, große COG-Operationen |
| Spark ETL | G.8X | 128 GB | GPU-beschleunigte ML- + Raster-kombinierte Workloads |
Sedona auf Glue erfordert Spark ETL, nicht Python Shell. Das ist der haufigste Fehler, den wir in der Produktion sehen. Teams richten einen Python-Shell-Job ein, versuchen Sedona zu importieren und erhalten kryptische Import-Fehler. Python Shell fuhrt kein Spark aus. Für Sedona Spatial SQL benötigen Sie einen Spark-ETL-Job mit dem Sedona JAR als Abhängigkeit.
Glue-Jobs installieren Python-Abhangigkeiten über das --additional-python-modules Flag - kommagetrennte Paketnamen wie geopandas, shapely, fiona, rasterio. Für Sedona auf Glue 4.0 sind die Spark JARs vorinstalliert - Sie benötigen nur --additional-python-modules: apache-sedona für die Python API. Bei alteren Glue-Versionen verwenden Sie --extra-jars mit S3-URIs, die auf hochgeladene JARs verweisen. Eine wichtige Lektion aus der Produktion: Maven-Koordinaten statt S3-URIs an --extra-jars zu ubergeben, verursacht eine URISyntaxException, die nichts Nutzliches über das eigentliche Problem aussagt.
WARNUNG: S3 IST KEIN DATEISYSTEM
S3 ist Object Storage. Es unterstutzt nicht die Seek-Operationen, die GDAL für das Schreiben von GeoTIFFs oder SQLite für GeoPackage benötigt. Die Lösung ist dasselbe zweistufige Schreibmuster wie auf Databricks Volumes: zuerst in das lokale /tmp auf dem Glue-Worker schreiben, dann die fertige Datei nach S3 hochladen. Direktes Schreiben auf S3-Pfade scheitert still oder erzeugt korrupte Ausgaben. Jede GIS-Bibliothek mit Random I/O (rasterio, fiona, SQLite/GeoPackage) ist davon betroffen.
Code-Struktur, die Glue erwartet: eine main.py als Einstiegspunkt (die ScriptLocation), die flache Schrittmodule importiert, die in --extra-py-files als S3-URIs aufgefuhrt sind. Keine Pakethierarchie - Glue kann verschachtelte Imports nicht auflosen. Die main.py initialisiert GlueContext und Sedona, parst Laufzeitargumente über getResolvedOptions und ruft dann jeden Schritt sequenziell auf. Das unterscheidet sich grundlegend von der Struktur lokaler Python-Projekte, und diese Lucke verursacht die meisten Deployment-Fehler bei der Migration von Desktop-ArcPy zu Cloud-Glue.
ZWEI FALLEN, DIE STUNDEN KOSTEN
Path() funktioniert nicht mit S3. Pythons Path("s3://bucket/file").exists() gibt bei S3-Pfaden stillschweigend False zurück - selbst wenn die Datei existiert. Verwenden Sie boto3's head_object für Existenzprufungen. Ausserdem: Glue ignoriert requirements.txt vollständig. Alle Abhangigkeiten müssen über --additional-python-modules angegeben werden.
IAM-Rollenweitergabe dauert 10-15 Sekunden. Eine neue IAM-Rolle erstellen und sofort einen Glue-Job damit starten, verursacht einen Cross-Account-Pass-Role-Fehler. Fugen Sie eine Propagierungswartezeit nach der Rollenerstellung ein, sonst scheitert Ihre CI/CD-Pipeline beim ersten Deployment intermittierend.
Glue ersetzt drei Legacy-Tools gleichzeitig: FME für ETL-Transformationen (Glue + Sedona deckt dieselben raumlichen Operationen ab), geplante ArcPy-Skripte (Glue-Jobs mit EventBridge-Cron-Triggern) und File-Geodatabase-Verwaltung (GeoParquet auf S3 mit Glue Data Catalog für Schema-Erkennung). Der Glue Data Catalog fungiert als Metadaten-Layer, der Ihre S3-Daten von Athena abfragbar macht, ohne zusatzliche Infrastruktur.
Lambda für Geodaten
Das Cold-Start-Problem ist das Hauptthema, über das niemand offen spricht. GDAL + rasterio + numpy bilden zusammen einen Lambda Layer von ca. 150 MB. Der erste Aufruf nach einer Inaktivitatsphase benötigt 8-12 Sekunden zur Initialisierung. Das ist inakzeptabel für Echtzeit-APIs, aber völlig in Ordnung für Batch-Verarbeitung und ereignisgesteuerte Pipelines.
LAMBDA COLD START - EHRLICHE ZAHLEN
Lambda mit 1769 MB Arbeitsspeicher, us-east-1
Warme Aufrufe laufen in 200-400ms bei typischer Raster-Kachelgenerierung. Die entscheidende Frage ist, ob Sie Provisioned Concurrency ($0,015/GB-Stunde) benötigen oder Cold Starts für Batch- und ereignisgesteuerte Verarbeitung akzeptieren können.
Das Produktionsmuster ist unkompliziert: Lambda empfangt ein S3-Event mit dem Bucket und Key eines neu hochgeladenen Rasters. Es offnet das COG über GDALs virtuelles Dateisystem (das HTTP-Range-Requests an S3 stellt), liest nur das benotige raumliche Fenster anhand der Bounding Box aus dem Event-Payload und schreibt das Ergebnis zurück nach S3. Die gesamte Operation beruhrt nur die Pixel, die sie benötigt - nicht die vollstandige Datei.
Deployment-Tipp: Docker-Images statt Zip-Layer verwenden. Das 250-MB-Limit (unkomprimiert) für Lambda Layers ist zu klein für GDAL + rasterio + numpy. Docker-basierte Lambda-Images unterstutzen bis zu 10 GB, und Community-Basis-Images wie lambgeo/lambda-gdal enthalten GDAL, rasterio und numpy vorkompiliert für Lambdas Amazon-Linux-Runtime. Das eliminiert den haufigsten Deployment-Fehler.
S3 + COG Speicherung
Warum COG auf S3 wichtig ist: HTTP-Range-Requests bedeuten, dass Lambda nur die benotigten Pixel liest. Ein 50-GB-Satellitenbild kann eine 1 km x 1 km Kachel in 50-200ms liefern, ohne die gesamte Datei herunterzuladen. Dieses Muster macht serverloses Geodaten-Processing wirtschaftlich rentabel.
Speicherkosten: $0,023/GB/Monat auf S3 Standard. Ein 1-TB-Rasterkatalog kostet $23/Monat. Für Archivdaten, auf die weniger als einmal im Monat zugegriffen wird, sinkt dies mit S3 Glacier Instant Retrieval auf $0,004/GB/Monat - eine Reduktion um 83%.
In der Praxis offnen Sie ein COG auf S3 direkt über GDALs virtuellen Dateisystem-Treiber. Wenn Sie einen fensterbasierten Lesevorgang anfordern - etwa den 1 km x 1 km Bereich um eine bestimmte Bounding Box - übersetzt GDAL dies in HTTP-Range-Requests gegen S3. Es liest nur die internen Kacheln, die Ihr Fenster uberlappen, typischerweise in 50-200ms bei einem 50-GB-Raster. Der Rest der Datei wird nie beruhrt. Deshalb ist das COG-Format entscheidend: ohne interne Kachelung und Ubersichten musste GDAL die gesamte Datei herunterladen, um eine kleine Region zu extrahieren.
Die S3-Verzeichnisstruktur ist kostenrelevant. Partitionieren Sie Ihre Daten nach Datum und Region mit Hive-Stil-Prafixen (raw/sentinel-2/year=2024/month=06/), damit Athena und Glue Crawler irrelevante Dateien überspringen. Speichern Sie verarbeitete Ausgaben getrennt von Rohdaten. Und verwenden Sie immer GeoParquet für Vektordaten - es bietet spaltenbasierte Speicherung mit raumlichen Metadaten, die sowohl Athena als auch Glue für Predicate Pushdown nutzen können.
Das STAC-Katalog-Muster verbindet alles: Indizieren Sie Ihre COGs auf S3 mit einer STAC API. Abfragen nach Datum, Bounding Box, Wolkenbedeckung - und dann direkter Zugriff auf einzelne COGs per Range Requests. Keine Datenbank, kein Dateiserver, nur S3 + Metadaten.
Für einen tiefgehenden Einblick in COG, GeoParquet und STAC-Formate lesen Sie unseren Leitfaden zu Cloud-nativen Geodatenformaten.
Athena Spatial SQL
Athena ermoglicht die Abfrage von GeoParquet-Daten direkt auf S3 mit Standard-SQL. Keine Datenbank zu verwalten, keine Infrastruktur bereitzustellen. Richten Sie Athena auf einen S3-Bucket, definieren Sie eine externe Tabelle über den Glue Data Catalog und stellen Sie Abfragen.
WARNUNG: ATHENA HAT KEINE NATIVEN ST_-FUNKTIONEN
Anders als BigQuery oder Snowflake hat Athena keine nativen raumlichen Funktionen wie ST_Contains oder ST_Distance. Sie können keine geometriebasierten raumlichen Pradikate in Athena SQL schreiben. Das Muster, das funktioniert: H3-Indizes in Ihren GeoParquet-Dateien vorberechnen (über Glue Spark ETL mit Sedona) und H3-Zellen-Lookups als raumlichen Filter in Athena verwenden. Das ist tatsachlich schneller und gunstiger als geometriebasierte Abfragen - bedeutet aber, dass Ihre raumliche Indizierungsstrategie in der Datenaufbereitungsphase entworfen werden muss, nicht zur Abfragezeit.
Der Workflow: Glue berechnet H3-Indizes und schreibt sie als Spalte in Ihre GeoParquet-Dateien. Athena-Abfragen filtern nach H3-Zellwerten mit einfachen Gleichheits- oder Bereichspradikaten. Kein Geometrievergleich zur Abfragezeit, kein raumlicher Index zu pflegen. Eine Abfrage nach “allen Flurstucken in Berlin” wird zu einem Filter auf H3-Zellen, die Berlins Grenze schneiden - einmal bei der Datenaufbereitung berechnet, tausendmal in Athena abgefragt.
Stolperfalle bei der Koordinatenreihenfolge: H3-Funktionen erwarten (latitude, longitude) - das Gegenteil der meisten GIS-Tools. Wenn Ihre H3-Zellen bei Daten, von denen Sie wissen, dass sie sich uberlappen, null Treffer liefern, prüfen Sie zuerst die Achsenreihenfolge. Das ist dieselbe Falle wie bei Databricks Mosaic. Auf GCP (BigQuery) ist es umgekehrt: ST_GEOGPOINT erwartet Longitude zuerst, Latitude an zweiter Stelle. Jede Plattform hat ihre eigene Konvention.
Kosten: $5 pro TB gescannter Daten. Mit GeoParquets Spaltenformat scannen Sie typischerweise nur 10-20% der Gesamtdaten (nur die referenzierten Spalten), sodass die tatsachlichen Kosten $0,50-$1,00 pro TB gespeicherter Daten betragen. Bei 100 Abfragen pro Monat auf einem 1-TB-Datensatz sind das ca. $5-10/Monat gesamt.
DATEN PARTITIONIEREN
Athena berechnet pro TB gescannter Daten. Durch Partitionierung Ihrer GeoParquet-Dateien nach Region oder Datum uberspringt Athena irrelevante Dateien vollständig. Eine Abfrage über Berliner Parzellen sollte keine Muncher Daten scannen. Verwenden Sie Hive-Partitionierung (s3://bucket/parcels/country=DE/state=BE/) und Ihre Kosten sinken um 80-90%.
Die Einschränkung: Athena ist keine Echtzeit-Datenbank. Die Abfrageausfuhrung dauert je nach Datenmenge und Komplexität 3-15 Sekunden. Für Sub-Sekunden-Raumabfragen, die eine Webanwendung bedienen, verwenden Sie PostGIS auf RDS. Athena ist für Ad-hoc- Analysen und Batch-Reporting gedacht.
Step Functions Pipelines
Geodaten-Workflows sind selten einzelne Operationen. Satellitenbilder treffen ein, müssen validiert, in COG konvertiert, auf Qualität gepruft und in Kataloge aufgenommen werden. Step Functions orchestriert dies, ohne dass Sie Server verwalten müssen - und koordiniert sowohl Glue-Jobs als auch Lambda-Funktionen in derselben Pipeline.
Das zentrale Muster aus der Produktion: Verwenden Sie das .sync-Suffix auf Glue-Ressourcen-ARNs, damit Step Functions auf die Job-Fertigstellung wartet, bevor es fortfahrt. Ubergeben Sie S3-URIs zwischen Zustandsubergangen (nie Inline-Daten - es gibt ein 256-KB-Payload-Limit). Setzen Sie explizite TimeoutSeconds für langlaufende Raster-Operationen. Und nutzen Sie Parallel-Branches, wenn Schritte unabhängig sind - Vektoren und Raster gleichzeitig statt nacheinander zu verarbeiten halbiert die Pipeline-Laufzeit.
Eine echte Produktionspipeline - Satellitenbild-Ingestion:
S3-Ereignis: Neues Bild hochgeladen
S3 lost die Pipeline aus, wenn ein neues GeoTIFF im Raw-Bucket landet. Kein Polling, keine Cron-Jobs. Ereignisgesteuert von Anfang an.
Lambda 1: Validierung und Metadaten-Extraktion
CRS, Auflösung, Bandanzahl und raumliche Ausdehnung prüfen. Fehlerhafte Dateien ablehnen, bevor Rechenzeit für die Verarbeitung aufgewendet wird. Metadaten für den STAC-Katalog extrahieren.
Lambda 2: COG-Kacheln generieren
Rohes GeoTIFF in Cloud Optimised GeoTIFF mit internem Tiling und Ubersichten konvertieren. Dies ermoglicht das Range-Request-Muster, das die Kachelbereitstellung aus S3 beschleunigt.
Lambda 3: Qualitatsprufungen
COG-Ausgabe verifizieren: korrekte Kachelgrossen, Ubersichtsebenen, raumliche Ausdehnung stimmt mit der Eingabe uberein. Verarbeitungsfehler abfangen, bevor sie sich downstream fortpflanzen.
Lambda 4: STAC-Katalog aktualisieren
Das verarbeitete Bild mit Metadaten, Vorschaubild und Zugriffslinks im STAC-Katalog registrieren. Das Bild ist nun auffindbar und abfragbar.
PIPELINE-KOSTEN PRO BILD
Gesamt: ca. $0,03 pro Bild (5 Lambda-Aufrufe + S3-Lese-/Schreibvorgange + Step-Functions-Zustandsubergange). Bei 1.000 Bildern pro Tag sind das $30/Monat für eine vollautomatisierte Ingestion-Pipeline mit Validierung, Konvertierung, Qualitatssicherung und Katalogisierung.
Echte Benchmarks
Diese Zahlen stammen aus Produktions-Workloads in us-east-1. Lambda konfiguriert mit 1769 MB Arbeitsspeicher (1 volle vCPU). S3 Standard Speicherklasse. Die Cold-Start-Zahlen sind enthalten, weil so zu tun, als existierten sie nicht, niemandem hilft.
AWS GEODATEN - PRODUKTIONS-BENCHMARKS
Kostenanalyse
Der Kostenvorteil von AWS für Geodaten ist real - aber nur, wenn Sie das technische Know-how haben, den Stack aufzubauen und zu betreiben. Hier ist der direkte Vergleich für ein mittelgrosses Team, das 10.000 Kacheln pro Tag mit 1 TB Rasterspeicher verarbeitet.
ESRI STACK
MONATLICHER GESAMTBETRAG
~$1.000/Mo.
+ Enterprise-Lizenzgebuhren
AWS STACK
MONATLICHER GESAMTBETRAG
~$83/Mo.
Keine Lizenzgebuhren
EHRLICHER VORBEHALT: ENGINEERING-KOSTEN SIND REAL
Diese Zahlen setzen voraus, dass Sie das technische Know-how haben, den AWS-Stack aufzubauen und zu betreiben. ESRIs Kosten umfassen den Komfort einer verwalteten Plattform mit Dokumentation, Support und einer GUI. Wenn Ihr Team keine AWS-Erfahrung hat, können die Engineering-Kosten für Aufbau und Betrieb dieses Stacks die Einsparungen für 1-2 Jahre ubersteigen. Der 12-fache Kostenunterschied realisiert sich nur, wenn Ihr Team den Stack eigenstandig betreiben kann.
Wann AWS für Geodaten nicht geeignet ist
Wir bauen Geodaten-Pipelines auf AWS für Kunden. Trotzdem raten wir manchen davon ab. Das sind die Szenarien, in denen AWS die falsche Wahl ist:
1. Ihr Team hat keine AWS-Erfahrung
Die Lernkurve ist steil. Lambda Layers, IAM Roles, VPC Networking, S3 Event Triggers - jedes davon hat Tucken, die Wochen brauchen um sie zu verstehen. Planen Sie 2-3 Monate Einarbeitungszeit für ein Team ohne AWS-Erfahrung, bevor Sie etwas Produktionsreifes aufbauen können.
2. Sie benötigen eine verwaltete Geodaten-Plattform
AWS hat keine. Sie setzen aus Bausteinen zusammen. Wenn Sie eine click-to-deploy Geodaten-Plattform mit GUI, Vendor-Support und Dokumentation wunschen, ziehen Sie ESRI on AWS oder Databricks in Betracht. Der DIY-Ansatz erfordert echte technische Investitionen.
3. Echtzeit-Raumabfragen (unter 50ms)
Athena ist keine Echtzeit-Datenbank. Die Mindestabfragezeit betragt unabhängig von der Datenmenge 3 Sekunden. Für Sub-50ms-Raumabfragen, die eine Live-Webanwendung bedienen, verwenden Sie PostGIS auf RDS oder Aurora mit einem raumlichen Index. Lambda + Athena ist für Batch-Processing, nicht für interaktive Nutzung.
4. Grossmassstabliche Raster-Analysen
Lambda hat ein 15-Minuten-Ausfuhrungslimit und eine 10-GB-Arbeitsspeichergrenze. Für rechenintensives Raster-Processing - Mosaicking größer Gebiete, Zeitreihenanalyse über Jahre von Satellitendaten, Multibandklassifikation - verwenden Sie ECS/Fargate oder SageMaker Processing. Oder ziehen Sie Google Earth Engine in Betracht, das genau für diesen Workload entwickelt würde.
5. Sie sind bereits auf Azure oder GCP
Multi-Cloud erhoh die Komplexität bei minimalem Nutzen. Wenn die primere Cloud Ihres Unternehmens Azure oder GCP ist, nutzen Sie deren native Geodaten-Services. Die Architekturmuster in diesem Beitrag lassen sich auf jede Cloud ubertragen - die spezifischen Services haben nur andere Namen. Teilen Sie Ihre Infrastruktur nicht allein für Geodaten.
Referenzarchitektur
Dies ist die Produktionsarchitektur, die wir für Kunden einsetzen, die mehr als 1 TB Geodaten verarbeiten. Funf Ebenen, vier AWS-Services pro Ebene, kein Over-Engineering.
1. DATEN-INGESTION
2. ETL + RAUMLICHE VERARBEITUNG
3. ANALYSE
4. PIPELINE-ORCHESTRIERUNG
5. BEREITSTELLUNG
Der STAC-Katalog ergänzt dies: eine Lambda-gesicherte API mit DynamoDB- Speicher, die alle verarbeiteten Daten indiziert. Benutzer fragen den Katalog nach Bounding Box, Datumsbereich oder Sensortyp ab und greifen dann per Range Requests direkt aus S3 auf einzelne COGs zu. Gesamtinfrastrukturkosten für den Katalog: unter $10/Monat.
Haufig gestellte Fragen
Kann AWS Geodaten-Workloads verarbeiten?
Ja, aber es gibt keinen einzelnen “AWS Geospatial”-Service. Sie kombinieren S3 (Speicherung), Lambda (Verarbeitung), Athena (raumliches SQL) und Step Functions (Orchestrierung). Das bietet maximale Flexibilitat, erfordert aber technischen Aufwand für die Zusammenstellung. Die meisten Produktions-Geodaten-Workloads auf AWS nutzen nur diese vier Services.
Wie lang ist die Cold-Start-Zeit für Lambda mit GDAL?
Cold Start mit einem vollstandigen GDAL/rasterio Lambda Layer dauert 8-12 Sekunden. Warme Aufrufe laufen in 200-400ms. Für latenzempfindliche Workloads verwenden Sie Provisioned Concurrency ($0,015/GB-Stunde), um Funktionen warm zu halten und den Cold Start auf unter 0,5 Sekunden zu reduzieren.
Wie viel kostet Geodaten-Verarbeitung auf AWS?
Speicherung: $0,023/GB/Monat auf S3. Verarbeitung: ca. $0,0001 pro Lambda-Aufruf für typische Kachelgenerierung. Raumliche Abfragen: $5 pro TB gescannter Daten über Athena. Ein typischer monatlicher Workload (1 TB Speicher, 10.000 tagliche Kachelanfragen, wochentliche Ad-hoc-Abfragen) kostet ca. $50-80/Monat.
AWS gibt Ihnen maximale Kontrolle zu minimalen Kosten - wenn Sie das technische Know-how haben, den Stack zusammenzustellen und zu betreiben.
$0,03 pro Bild durch eine vollstandige Pipeline. $23/Monat für ein Terabyte Raster. Raumliches SQL für $5 pro TB gescannter Daten. Die Okonomie ist uberzeugend für Teams, die die Infrastruktur betreiben können. Für alle anderen spart eine verwaltete Plattform mehr als sie kostet.
Das Muster ist unabhängig von der Cloud dasselbe: Daten in Cloud-nativen Formaten speichern, mit serverlosem Computing verarbeiten, mit raumlichem SQL abfragen, mit verwalteten Workflows orchestrieren. AWS gibt Ihnen dabei die granularste Kontrolle über jedes einzelne Element.
Workflow-Automatisierung Einblicke erhalten
Monatliche Tipps zur Automatisierung von GIS-Workflows, Open-Source-Tools und Erkenntnisse aus Enterprise-Deployments. Kein Spam.