Environments
Two-tier model — nonprod + prod — on AWS using an AWS Organizations multi-account structure. Referenced by the Architecture and Supply Chain & CI/CD Security sections.
Account structure (4 active at launch, +1 in Phase 2)
| Account | Role | When |
|---|---|---|
| management | Org root: consolidated billing, org-wide CloudTrail, IAM (users, groups, policies), Service Control Policies (SCPs). No workloads. | Day 1 |
| shared-services | ECR (container registry), Route 53 (DNS), Terraform state (S3 + DynamoDB lock), audit-log archive, GitHub OIDC trust, cross-account deploy roles | Day 1 |
| set-nonprod | The nonprod environment (dev + QA + demo) | Day 1 |
| set-prod-eu | Production — Ireland (eu-west-1) | Before launch |
| set-prod-il | Production — Israel (Tel Aviv, il-central-1), for Nimbus-aligned customers | Phase 2 |
AWS best practice: the management account holds only governance, never workloads — ECR and shared infra live in shared-services.
Human access: IAM (not SSO)
S.E.T uses plain IAM for human team access — not IAM Identity Center / SSO.
- IAM users for team members, organized into role-based groups
- MFA mandatory on every IAM user — no console access without it
- Least-privilege IAM policies per group; quarterly access review
- Avoid long-lived access keys — prefer
assume-role+ temporary credentials with MFA for CLI/programmatic access; rotate any keys that must exist - Root account locked down: hardware MFA, break-glass only, never daily ops
- IAM Access Analyzer enabled to flag overly-permissive policies
Note: AWS recommends IAM Identity Center (SSO) for human access, and auditors generally prefer it (central identity, temporary credentials, cleaner offboarding). IAM-only is an accepted alternative for a small team, hardened here with mandatory MFA, least privilege, minimal long-lived keys, and quarterly reviews. Revisit SSO if the team grows or an auditor requires it.
What differs between nonprod and prod
| nonprod | production | |
|---|---|---|
| AWS account | set-nonprod | set-prod-eu (+ set-prod-il Phase 2) |
| URL | setdev.binarynetworks.ai / api.setdev.binarynetworks.ai | set.binarynetworks.ai / api.set.binarynetworks.ai |
| Region | eu-west-1 (Ireland) | eu-west-1; il-central-1 Phase 2 |
| Availability | Single-AZ | Multi-AZ (3 AZs) |
| Fargate (api) | 0.5 vCPU / 1 GB, 1–2 tasks | 1 vCPU / 2 GB, auto-scale 2–10 |
| Fargate (workers) | 0.5 vCPU / 1 GB, 1 task | auto-scale per queue depth |
| RDS Postgres | db.t4g.small, single-AZ | db.m6g.large to start, scale class up as load grows, Multi-AZ + 1 read replica |
| Redis | cache.t4g.micro, single node | cache.r7g.large, Multi-AZ |
| Data | synthetic / sanitized — no real customer data, ever | real customer data |
| KMS keys | per-environment (never cross account) | per-environment CMKs |
| Backup retention | 3 days PITR | 35 days PITR + cross-region encrypted backups |
| WorkOS env | "Development" | "Production" |
| Logz.io project | set-nonprod (Slack alerts only) | set-prod (full retention; PagerDuty + on-call SMS) |
| Deploy trigger | auto on merge to develop | merge to main + required-reviewer approval gate |
Production database scaling path
Start small, grow with load — all supported by RDS with minimal disruption:
- Start at db.m6g.large (2 vCPU / 8 GB, Multi-AZ)
- Scale instance class up (→ db.r6g.large → db.r6g.xlarge → …) via an RDS modify operation: applies to the standby first, then a brief (~60s) Multi-AZ failover, then the old primary — near-zero downtime
- Storage grows automatically via RDS storage autoscaling — no manual disk resizing
- Read replicas offload analytics/dashboard queries; add more as read load grows
- Net: medium now, bigger later, without re-architecture
Deploy flow
Full pipeline in the Supply Chain & CI/CD Security section. Summary:
feature/* → PR (validation job, no creds) → S.E.T-team review → merge develop
→ auto-deploy nonprod → QA / demo → PR develop→main
→ required-reviewer approval → deploy prod (rolling + circuit breaker + auto-rollback)
Implementation order
- management + shared-services — foundation (IAM, OIDC trust, ECR, Terraform state)
- set-nonprod — where development + testing happen first
- set-prod-eu — stood up as launch approaches, after validation in nonprod
- set-prod-il — Phase 2, when the first Nimbus customer signs
Cost estimate (early stage, before production load)
| Account | Monthly |
|---|---|
| management | ~$10 |
| shared-services | ~$30–60 |
| set-nonprod (single-AZ) | ~$120–200 |
| set-prod-eu (db.m6g.large, pre-load) | ~$700–1,300 |
| Total before production traffic | ~$900–1,600/month |
Production scales with customer load (+$1,000–3,000 at hundreds of tenants).