AWS
We only leave things on AWS when they have to be there. New APIs and routine application hosting belong on Fly.io with Cloudflare in front—not on a fresh AWS stack per project.
AWS stays for platform services and workloads that need AWS-native scale or enterprise features—not as our default place to run a container API.
What stays on AWS
Section titled “What stays on AWS”| Stay on AWS when… | Examples (conceptual) |
|---|---|
| Large storage or data gravity | Big data lakes, archival volumes, or systems already built around S3-scale storage |
| Enterprise-grade requirements | Vendor contracts, compliance zones, or managed services that only exist (or only make sense) on AWS |
| Shared platform already there | Databases, queues, identity, or integrations the whole company already operates in AWS |
| Not a fit for Fly + tunnel | Long-lived batch jobs, legacy VMs, or specialized hardware/networking Fly does not provide |
If the answer is “we need a standard Docker API with staging and production,” the answer is Fly, not a new ECS cluster.
What we are not doing on AWS by default
- Standing up **per-app** load balancers, autoscaling groups, and log pipelines for every API
- Treating AWS as the **first choice** for new Brytebridge APIs
- Sharing **production credentials** broadly for day-to-day developer work
How AWS fits the rest of the stack
Section titled “How AWS fits the rest of the stack”New APIs → GitHub Actions → Fly.io → Cloudflare (public edge)AWS → shared data, enterprise services, and “must stay” storageFly-hosted APIs may call AWS services (databases, queues, object storage) where those systems already live. That is integration—not “host the API on AWS because we always have.”
Observability (logs, metrics, dashboards) is moving to Grafana Cloud, not new AWS instances per team.
Access and governance (developing)
Section titled “Access and governance (developing)”When you do touch AWS, the same mindset applies as Fly and GitHub:
- Least privilege — roles scoped to job and environment
- Tier separation — staging / UAT / production access is not interchangeable
- No long-lived keys in repos — prefer OIDC, short-lived credentials, and managed secrets
- Auditability — changes traceable for SOC 2–style reviews
Detailed IAM patterns and account layout will be documented here as we formalize them.
Related
Section titled “Related”- Fly.io — default home for APIs
- Fly vs AWS — comparison for hosting decisions
- GitHub — how deploys are tracked
- Zero Trust — minimum permissions across environments