eoapi-cdk is a package of AWS CDK constructs designed to encapsulate eoAPI services and best practices as simple reusable components.
For more background on the included services see The Earth Observation API
Detailed API docs for the constructs can be found here.
An RDS instance with pgSTAC installed and the Postgres parameters optimized for the selected instance type.
A STAC API implementation using stac-fastapi with a pgSTAC backend. Packaged as a complete runtime for deployment with API Gateway and Lambda.
A complete dynamic tiling API using titiler-pgstac to create dynamic mosaics of assets based on STAC Search queries. Packaged as a complete runtime for deployment with API Gateway and Lambda and fully integrated with the pgSTAC Database construct.
A CDK construct to host a static Radiant Earth STAC browser on S3.
A complete OGC Features/Tiles API using tipg. Packaged as a complete runtime for deployment with API Gateway and Lambda. By default the API will be connected to the Database's public schema.
An API for large scale STAC data ingestion and validation into a pgSTAC instance.
Authentication for the STAC Ingestor API can be configured with JWTs authenticated by JWKS. To learn more about securing FastAPI applications with this approach see Securing FastAPI with JWKS (AWS Cognito, Auth0).
A sample Cognito-based authentication system is available at aws-asdi-auth.
A bastion host is a secure gateway that provides access to resources in a private subnet. In this case it provides the ability to make administrative connections to eoAPI's pgSTAC instance.
For more background on bastion hosts in AWS see this article.
And for configuration instructions for this construct see the docs.
Versioning is automatically handled via Conventional Commits and Semantic Release.
Warning: If you rebase main, you must ensure that the commits referenced by tags point to commits that are within the main branch. If a commit references a commit that is no longer on the main branch, Semantic Release will fail to detect the correct version of the project. More information.
Each pull request to main is added to a merge queue so that a "deployment test" workflow can run before the merge actually happens. If the deployment fails, the merge is cancelled. Here is the definition of this workflow and the tests definition.