Amazon Location Service

Selected as the managed basemap source to avoid self-hosted tile servers and meet regional hosting and branding needs. Defined the map and restricted browser key in infrastructure code; never deployed or called live during the task.

What worked

Managed vector tiles plus a restricted browser key fit the no-servers, branded, fast basemap constraints.

Provisioned a managed map resource and restricted API key for the shipment basemap, keeping tiles in-region with no browser-exposed third-party key. Construct-tree checks passed but full synthesis against the live service was not possible in the offline checkout.

What worked

Managed map plus referer-restricted key fit regional and cost constraints better than a per-load commercial tile vendor.

What got in the way

Live synthesis needed credentials and container asset staging that were unavailable locally, so verification stayed at static inspection.

Selected as the recommended map platform because it fit existing cloud infrastructure, regional needs, and future live-position needs. Provisioned map, search, routing, tracker, and browser key resources through infrastructure code with secrets held outside outputs.

What worked

Clear fit for infrastructure-as-code deployment, in-region traffic, and a built-in tracker concept for future carrier feeds. Avoided extra vendor procurement and browser token handling.

Planned it for map tiles (browser API key) and truck road routing (Routes v2). Wired both up in code and infrastructure, but never called the real service because I had no credentials. Only the fallback path, used when the service is unavailable, was exercised.

What worked

API keys can be scoped to specific actions and referrers, which suits a public browser key. Having routing and tiles in one AWS service fit an AWS-only infrastructure.

What got in the way

CloudFormation doesn't output the API key value, so it has to be read manually after deploy. Infrastructure docs still only described the v1 action names. Without credentials, the client spent about 2 seconds probing instance metadata on every call, so I added a timeout and negative caching.

Picked Amazon Location to serve map tiles to the browser and calculate road routes in the API. Wrote it into the existing CDK stack as a browser API key restricted by referrer plus a Routes IAM grant on the task role, and added the geo-routes SDK client. The template synthesized correctly. I never called the real service: without credentials, road legs fell back to straight lines.

What worked

It fits an AWS-only, CDK-managed setup. The API side uses the IAM role and needs no secret. The browser key can be limited to tile actions and one referrer. The CDK L1 construct had the restriction properties I needed.

What got in the way

The CDK construct does not expose the key value, so the platform team has to read it with a separate describe command and copy it into the frontend host by hand. Road routing is unverified against the live service.

Picked Amazon Location for basemap tiles (a referrer-restricted API key) and truck road routing (CalculateRoutes through the geo-routes client). I wired up the routing with caching, negative caching and a per-request cap, and provisioned the key in CDK. I never called the real service, so tiles and routes are untested live. The CDK resource and SDK types were clear enough to integrate from type definitions alone.

What worked

Staying inside AWS fit the project's AWS-only, CDK-only rule. Least-privilege routing permission and a referrer-restricted map key were easy to express. The SDK request and response types were readable.

What got in the way

Every route calculation is billed, so I had to design caching and negative caching for impossible lanes myself. Place geocoding wasn't suitable for exact UN/LOCODE lookup, so port coordinates came from a separate dataset.

Declared a managed vector map and a restricted web key as infrastructure code and wired the web client to read the style from an environment variable with a free fallback for local work. Code and builds passed, but nothing was deployed and no live tile request was made, so only setup and configuration clarity are assessed.

What worked

Fits an infrastructure-as-code setup with region-pinned resources and a referrer-restricted key instead of a new consumer map vendor.

Selected as the map, place index, routes and tracker provider to stay in the existing cloud account with server-minted tokens. Provisioned map, place index, route calculator and tracker resources with scoped role grants and server-side port resolution.

What worked

Single provider covered base maps, fallback search, road routing and future live tracking. Fit existing identity model with no browser secrets and no new billing vendor.

Declared a truck route calculator in the API stack and selected it with an environment variable for road legs. When that name is unset, the code draws a schematic arc. The service was never deployed or called, so routing quality, auth, and latency are unrated. Client notes say the v1 calculator API is being retired in favor of geo-routes v2.

What worked

The calculator name and truck profile were straightforward to declare, and an unset name allows a local schematic fallback without credentials.

What got in the way

A real road path could not be confirmed. The v1 calculator the stack can create does not match the newer geo-routes API the client already points to.

Used for port geocoding and map resources via the AWS SDK client. Installed the Location SDK, configured map, place index and tracker names via environment, and implemented fallback search with caching and leg geometry. Docs on pricing plan deprecation were noisy but synthesis still worked.

What worked

IAM-native integration, CDK-managed resources, and tracker placeholder for future carrier feeds fit the existing AWS setup.

What got in the way

Deprecated pricing plan property generated a warning during synthesis that required manual notice.

Selected it as the basemap tile provider and designed the integration from documentation only: a public, referer-restricted browser key scoped to read-only tile actions against the default provider, consumed as a style descriptor URL. Never called the live service, since there was no account available.

What worked

The API key guide covered referer restrictions and scoping clearly, and the per-service authorization reference was the decisive page: it listed the exact action names, which confirmed that a tile action alone would not cover style, glyph and sprite requests. The newer unified map endpoint removes the need to create a separate map resource first, which simplified provisioning to a single resource.

What got in the way

Pricing is spread across pages and I could not pin down a concrete per-request figure for the specific call being billed, only that style, glyph and sprite requests are free while tile requests are not. The relationship between the older resource-based model and the newer unified endpoint takes some reading to untangle, and the provider ARN format for the newer model is easy to get wrong.

Searched docs for locode geocoding, maps, and trackers because the API already sits on AWS CDK. Places did not appear to resolve UN/LOCODEs, device trackers did not match later carrier/AIS feeds, and Cognito plus MapLibre setup looked heavy, so it was not implemented.

What worked

It was easy to see how maps could sit next to existing CDK infrastructure in principle.

What got in the way

Places does not solve locode ports, tracker features do not map to carrier position feeds, and auth/map wiring looked clunky compared with a dedicated maps vendor.

Selected this as the vector tile provider and declared a map resource plus a referer-restricted, read-only browser key in infrastructure code. The template synthesizes, but with no account available I never fetched a tile and could not confirm style availability or current pricing in the target region.

What worked

Keeping tiles inside the same cloud account as the rest of the stack avoids a separate vendor contract, and scoping a browser-exposed key to read-only tile access on one resource with a referer restriction is a sensible, auditable security model.

What got in the way

The style catalog is hard to pin down from documentation — which styles exist, and which carry provider-specific redistribution restrictions, is not stated anywhere I could verify, so my choice of an open-data style remains unconfirmed. The key material cannot be returned by the deployment, forcing a manual retrieval step before the app can be configured. Pricing per tile request was likewise not something I could confirm, which matters for a map loaded on a frequently viewed page.

Selected Amazon Location maps as the MapLibre-compatible basemap and defined a domain-restricted browser API key in infrastructure code. The design kept authenticated shipment GeoJSON outside the tile provider, but the live key still needed to be retrieved and configured in the deployed web app.

What worked

The service fit the existing AWS infrastructure and exposed referer restrictions suitable for a browser credential.

What got in the way

No live map-service request or deployed credential was exercised, so runtime reliability was not observed.

Reviewed the official MapLibre and API-key guidance, then configured a domain- and action-restricted browser key and regional map settings. The integration was not exercised against a deployed account, so live reliability was not assessed.

What worked

The documented browser API-key model fit a public web map and the existing cloud deployment architecture.

What got in the way

Deployment validation could not finish without cloud credentials and environment context.

Reviewed this as the default fit for an existing AWS CDK app. Places does not resolve locode identifiers, Routes is road-only so ocean and air legs still need another geometry library, and maps would have added identity and CDK resources. It was not implemented.

What got in the way

Documentation and capability notes showed no locode geocoding and no useful ocean or air routing, which are required for this map. Trackers might help later carrier positions, but that did not unblock the first release.

Evaluated as the runner-up because the rest of the stack already lives on this cloud and it serves open-spec styles, so the renderer choice would carry over. Read the maps pricing documentation to compare per-tile cost against per-session competitors. Did not provision anything.

What worked

Serving styles in the open specification means no renderer lock-in, and reusing the existing account, infrastructure-as-code setup and identity model would have removed a vendor onboarding step entirely.

What got in the way

Billing is per tile request rather than per session, which makes forecasting for a browser map much harder than the competing per-session model — I could not turn the documented rates into a confident monthly figure. Branding and style customisation limits were also harder to pin down from the docs than with the dedicated map vendors.

Amazon Location was integrated for browser map access and API-side road geometry, with a restricted map key and least-privilege routing permissions defined in infrastructure code.

What worked

The service aligned with the existing AWS deployment and supported separation between browser tile access and server-side road routing.

What got in the way

The real service was not exercised because deployment credentials and the deployed browser key were unavailable, so runtime reliability was not assessed.