Overview
A GenAI feature is only a small part of what an enterprise needs to run it safely. Networking, identity, secrets handling, delivery pipelines, observability, governance and cost controls usually decide whether a prototype can become a service. This project starts from that side: build the platform foundations first, then place AI workloads on top.
The repository is under active development. This article separates what exists today from the target architecture so the two are not confused.
What exists today
1. A layered application
The FastAPI application uses a src layout with pyproject.toml, and separates responsibilities:
- api: versioned routes (
v1) and shared dependencies. - core: centralized configuration.
- services: an abstraction over Amazon Bedrock.
- use_cases: business-level features, currently an application-summary use case.
Hiding Bedrock behind a service layer keeps use cases independent of the SDK and easy to test with fakes.
2. Terraform foundations
Infrastructure is defined as code with reusable modules and per-environment configuration. The first module covers networking: a VPC with DNS support, an internet gateway, and public and private subnets across multiple availability zones. Public subnets do not auto-assign public IPs. A lab environment consumes the module.
3. Continuous integration
A GitHub Actions workflow runs on pushes and pull requests to main:
- Pre-commit checks and dependency consistency verification
- Application unit tests with pytest
- Gitleaks scanning of the complete git history for leaked secrets
The workflow uses read-only repository permissions, which follows least privilege even for CI.
Target architecture (roadmap)
The following are goals, not delivered features:
- Amazon Bedrock and Knowledge Bases with S3 Vectors for retrieval
- Containers on Amazon EKS, with images in ECR built through GitHub Actions
- IAM roles and EKS Pod Identity for workload access, Cognito for user authentication
- Private networking and endpoints
- CloudWatch observability
- AI governance and cost controls
The networking module will also need NAT or VPC endpoints, route tables and flow logs before it can host real workloads.
Why this order
- Security is cheaper early: secret scanning and least-privilege CI are easy to add on day one and painful to retrofit.
- Structure enables growth: separating use cases from provider code makes it simpler to add RAG or other use cases later.
- Infrastructure as code from the start keeps environments reproducible and reviewable.
How it relates to the RAG project
The application-layer work, such as grounded answers, citations and evaluation, lives in a separate repository. In time, that kind of workload can become a use case running on this platform.
Explore the project
For the current code, structure and roadmap, visit the aws-enterprise-genai-platform repository on GitHub.