AWS Service Reference — Options & Trade-offs
| Owner | Classification | Version | Effective | Next review | Status |
|---|---|---|---|---|---|
| Sekhar Prakash | Internal | 1.0 | 2026-09-05 | 2026-11-27 | Active |
Purpose. A reference of AWS-native service options researched against Finaisse's AWS footprint, beyond what the AWS Gate — Options Assessment already covers in full for the four open gate items. Nothing here is gated or SLA'd — these are hardening, cost, or compliance-posture options for later decisions, recorded so the research is not lost. Options are presented with trade-offs, not a single prescriptive answer, per Finaisse's standing practice for multi-valid-approach decisions.
Scope
Grounded against the applied Terraform in fin-infra/aws/ as of 2026-09-05. Standards cited: AWS Well-Architected (Security Pillar), the AWS Security Reference Architecture (SRA), CIS AWS Foundations Benchmark, and AWS Foundational Security Best Practices (FSBP) — Security Hub control IDs given where one exists. Cost figures are reference-region rates (typically US East); re-check ap-south-1 pricing via the AWS Pricing Calculator before budgeting.
Edge & WAF
Beyond the rate-based rule already recommended in the options assessment for F-41 (no brute-force protection on /auth/login):
| Option | What it does | Trade-off | Cost |
|---|---|---|---|
| Account Takeover Prevention (ATP) | Checks login attempts against AWS's stolen-credential database; aggregates by IP and client session | Response-inspection half (tracking login success/failure rates) is CloudFront-only, not available on a plain ALB | $10/mo + tiered per-request ($1,000/M for 0–2M, falling to $50/M beyond 30M) |
| Account Creation Fraud Prevention (ACFP) | Same stolen-credential check plus email-domain reputation and behavioral analysis, scoped to sign-up/registration endpoints | Not relevant unless Finaisse exposes a self-serve tenant sign-up flow | $10/mo + same tiered pricing as ATP |
| Bot Control (Common tier) | Signature detection of self-identifying bots (scrapers, search engines, automated browsers) | Overlaps functionally with rate-based rules for basic rate limiting | $10/mo + $1/M requests (first 10M free) |
| Bot Control (Targeted tier) | Adds browser fingerprinting, behavioral heuristics, ML-based coordinated-attack detection (~24h to baseline) | 10x Common's per-request cost | $10/mo + $10/M requests (first 1M free) |
| Rate-based rule, JA3/JA4 aggregation key | Rate-limits on TLS fingerprint rather than source IP — catches botnets that rotate IPs but reuse the same client stack | Usable directly on ALB today; the practical first line before ATP | 2 + 30 WCU per custom key |
Assessment: ATP is the most directly relevant control for credential stuffing on /auth/login, but its highest-value half doesn't work on ALB alone — a material consideration if blitz-api stays ALB-only rather than moving behind CloudFront. The JA3/JA4 rate-based rule is the practical near-term option; ATP is worth revisiting only alongside a CloudFront decision.
IAM & governance
Beyond the direct fix for F-12 already in the options assessment:
| Topic | Detail | Trade-off | Compliance framing |
|---|---|---|---|
| IAM Access Analyzer — ACCOUNT vs ORGANIZATION scope | ACCOUNT scope flags any access from outside the single account — including legitimate cross-account flows between Finaisse's own Log Archive/Audit/workload accounts — as an external-access finding. ORGANIZATION scope collapses that noise to genuinely external principals | Requires enabling AWS Organizations trusted access for Access Analyzer (one-time) and typically a delegated-administrator account (Audit, per AWS SRA) | Not a named CIS/FSBP control — operational quality, reduces false-positive fatigue as the org grows past 2 accounts |
| Permission boundaries vs SCPs | SCPs are org/OU/account-wide ceilings; permission boundaries cap what a specific principal's own policies can grant — relevant only once role-creation is delegated to non-platform-team principals | Not currently a gap — no evidence of delegated role-creation in the repo today; forward-looking, not urgent | — |
| SCP baseline vs AWS's own example set | Current 6 SCPs (region-deny, IMDSv2, deny-leave-org, deny-disable-GuardDuty, require-S3-encryption, deny-CloudTrail-deletion) are a reasonable minimal set, but AWS's own service-control-policy-examples baseline is broader: no SCP protects Config or Security Hub from tampering the way GuardDuty/CloudTrail are protected; no SCP-level root-API restriction exists; the CloudTrail SCP covers DeleteTrail/StopLogging/UpdateTrail but not PutEventSelectors (can silently narrow logging without "deleting" anything) | Each additional SCP is a design/governance decision, not a mechanical add | Root MFA/restriction is a near-universal SOC 2/CIS Level 1 expectation; Config/Security Hub tamper-protection is general hardening |
| Root & break-glass access | AWS recommends hardware/FIDO MFA on root without exception, root used only for the narrow list of tasks that require root, and a two-person rule for root credential access | The interim sekhar-console + Switch Role bridge is an AWS-recognized transitional pattern, but its assume-role trust is wildcarded across all account IDs (arn:aws:iam::*:role/OrganizationAccountAccessRole) rather than pinned to Finaisse's two known accounts, and MFA enforcement is not visible in IaC | Root MFA (hardware, ideally) is a hard SOC 2/CIS expectation, not optional |
| Credential/access reviews | Security Hub controls IAM.3 (90-day key rotation), IAM.8/IAM.22 (unused-credential removal, 45-day CIS-strict threshold), IAM.4 (no root access key), IAM.5/IAM.6/IAM.9 (MFA) all consume the IAM Credential Report automatically | AWS solves detection fully; nothing auto-rotates or auto-disables on a finding — remediation stays a manual/scripted process step | These map directly to CIS AWS Foundations Benchmark controls that are near-universal SOC 2 audit evidence requests |
| GitHub Actions OIDC trust scoping | See the new-finding note in the options assessment — trust is currently org-wide (repo:finaisse-org/*:*) | AWS STS now supports validating additional OIDC claims (e.g. environment, ref) as first-class condition keys, not just a single sub string match — worth using compound conditions rather than one wildcarded pattern | General hardening (Well-Architected SEC03), not a named CIS/FSBP control |
S3 & KMS
Beyond the TLS-only policy and SSE-KMS switch already recommended for F-18 in the options assessment:
| Topic | Detail | Trade-off | Compliance framing |
|---|---|---|---|
| S3 Object Lock (WORM) | Compliance mode blocks deletion/modification of a locked object version even for the account root, until retention lapses; built on top of S3 Versioning (already enabled) | Can only be enabled at bucket creation — not retrofittable onto app_data without a bucket recreation/migration; a one-way architectural decision | Regulatory-driven (e.g. SEC 17a-4-style immutability), not a general SOC 2 requirement — needs a compliance/legal read before adoption |
| Amazon Macie | Scans S3 for PII/credentials/PCI-pattern data; ~$0.10/bucket/mo monitoring floor + tiered per-GB inspection ($1.00/GB first 50TB) | Stronger fit for unstructured PII/free-text than structured financial documents (invoices, reconciliation exports) — a full-corpus one-time scan of ~500GB would run ~$500 at the first tier | Not a named SOC 2 control by itself, but supports the "detect accidentally-uploaded credentials/PCI data" objective auditors commonly probe for a fintech |
| KMS key policy hardening | Current CMK policies (RDS/S3/Secrets) are root-full-access + a bare service-principal grant — no key-administrator/key-user role separation, no kms:ViaService scoping. AWS Prescriptive Guidance recommends separating administrators (PutKeyPolicy, CreateGrant) from users (Encrypt/Decrypt only), and favors scoped, revocable grants over standing key-policy statements | Largely moot for the S3 CMK specifically until SSE-KMS is adopted (see F-18) — becomes live once that switch happens | Prescriptive guidance, not a numbered control; rotation is already compliant (enabled on all three CMKs) |
| Shared vs per-tenant CMK | A shared CMK (current design) is simpler/cheaper ($1/mo) but means a key-level compromise has blast-radius-equal-to-all-tenants; per-tenant CMKs give crypto-shredding (disable one tenant's key to instantly deny their data) at $1/mo × tenant count plus materially more IaC complexity | Non-issue at current 2-tenant staging scale; a scaling decision, not a security-only one | — |
| S3 access logging | Server Access Logging is free-ish but best-effort delivery (hours, sometimes dropped) with no identity context; CloudTrail data events are paid per event but deliver full IAM identity/assumed-role context in ~5 minutes | AWS's own S3 audit-logging guidance recommends CloudTrail data events, not server access logs, for compliance/audit use cases specifically — scope to app_data only to bound cost | Squarely a SOC 2 monitoring/access-audit control for tenant financial documents — "who accessed which tenant's invoice, when" |
| Presigned URL tenant scoping | Short expiry and method-binding are free built-in mechanics. Network-condition restrictions (aws:SourceIp/aws:SourceVpc) constrain where the signing call can originate, not who redeems the URL. S3 Access Points and Access Grants scale per-tenant isolation to tens of thousands of tenants | The cross-tenant leakage scenario (a wrong prefix computed in app code) is fundamentally an application/IAM-design correctness issue — AWS provides ABAC/session-tag enforcement primitives, but cannot retroactively narrow a URL validly signed by an over-broadly-permissioned role | Not AWS-solvable beyond providing the enforcement primitive; scoping the signing role to per-tenant session tags converts an app-code assumption into a cryptographic guarantee |
Network
Beyond the ECS security-group fix already flagged as a new finding in the options assessment:
| Topic | Detail | Trade-off | Compliance framing |
|---|---|---|---|
| AWS Network Firewall vs WAF-only | Network Firewall is stateful L3/L4/L7 inspection (any protocol); AWS's own guidance positions it primarily for egress filtering, not HTTP ingress — WAF is the correct, sufficient tool for the ALB's HTTPS-only ingress path | ~$576/mo in endpoint-hours alone (2 AZs) before processing a single GB — heavy relative to current spend. The current ecs SG's egress rule is wide open (-1/0.0.0.0/0); tightening that is a $0 Terraform change addressing the same underlying concern (uncontrolled egress from a compromised task) at far lower cost | Not a compliance gate — SOC 2 requires some documented, effective segmentation control, which WAF + SGs + isolated DB subnets already satisfy |
| VPC endpoints | S3 Gateway endpoint is free, no hourly or per-GB charge — strictly beneficial, no trade-off. Secrets Manager / CloudWatch Logs Interface endpoints (~$0.01/hr/AZ + $0.01/GB) remove NAT-routed AWS-API traffic from the internet-facing path entirely, a real defense-in-depth win independent of cost | Break-even for low-volume Secrets Manager traffic is unlikely to be reached; CloudWatch Logs (continuous log streaming from 16 services) is the one most likely to justify its cost — needs an actual traffic measurement first. ECR endpoints are not applicable — Finaisse pulls from GHCR, not ECR | Not a compliance prerequisite — cost/hardening optimization |
| Security group / NACL tooling | Security Hub's EC2.18/EC2.19 (unrestricted high-risk ports), EC2.2 (default SG denies all), EC2.21 (NACL SSH/RDP) give continuous automated detection of this class of finding once Security Hub + CIS/FSBP standards are enabled (see the options assessment). VPC Reachability Analyzer (point-to-point) and VPC Network Access Analyzer (scope-based, sweep-style) are available for ad hoc verification | — | Commonly expected by SOC 2 auditors as evidence of continuous configuration monitoring |
| DB/cache network isolation | Private subnets + security-group scoping (already correct) is necessary but not sufficient per Well-Architected SEC05-BP02, which names perimeter-only network security as an anti-pattern | RDS IAM database authentication and ElastiCache transit encryption (both discussed below) are the concrete "beyond the perimeter" controls currently off | RDS.10 and ElastiCache.5 are named FSBP controls |
| DDoS tiering | Shield Standard (automatic, free) already covers common L3/L4 volumetric attacks on the ALB and NAT Gateway EIP. Shield Advanced ($3,000/mo, 1-year commitment) adds L7 detection, cost protection, and SRT access | Not warranted at Finaisse's current traffic volume or threat profile — the trigger to revisit is a contractual DDoS-response SLA or evidence of targeted attack activity, not a calendar date | Not a SOC 2 prerequisite — Shield Standard + existing WAF rate limiting is defensible evidence |
| Multi-tenant network isolation | Tenant isolation is app-layer only (full-hostname match) — this is AWS's own documented "pool" tenancy model (SaaS Tenant Isolation Strategies whitepaper), a deliberate cost/isolation trade-off, not a deficiency by default. VPC Lattice solves a different problem (cross-account/cross-VPC exposure to tenant-owned AWS accounts) and doesn't match Finaisse's shape, where tenants are rows in a shared RDS instance | Not solvable by a network-layer AWS primitive at this architecture's current shape | Not typically a SOC 2 blocker — auditors routinely accept app-layer isolation with compensating controls (access logging, row-level scoping, tested tenant-boundary suites), which is an application/process verification question, not an infra one |
RDS & ElastiCache
Beyond the master-password-rotation and RDS-IAM-auth options already covered for F-18 in the options assessment:
| Topic | Detail | Trade-off | Compliance framing |
|---|---|---|---|
| RDS audit logging — pgAudit | Fully supported on RDS PostgreSQL, free, enabled via shared_preload_libraries = pgaudit in the parameter group (static parameter — requires one reboot). Captures structured, session/object-level DDL/DML detail with automatic cleartext-password redaction | log_statement/log_connections alone is weaker — no object-level detail, and a superuser can alter/disable logging since it's just a config parameter | General SOC 2 CC7.2 / audit-trail expectation, not a named CIS/FSBP control for RDS Postgres specifically |
| Database Activity Streams (DAS) | Does not apply to Finaisse's engine. DAS for PostgreSQL is Aurora-only — Finaisse runs standard aws_db_instance PostgreSQL, not Aurora. Where DAS does apply (Aurora, Oracle, SQL Server), it streams to Kinesis and is tamper-resistant even against a compromised superuser, unlike pgAudit-to-file | Adopting DAS would require an Aurora migration — a materially different, more expensive engine decision, not a toggle | Relevant only if tamper-resistance against a rogue superuser becomes a hard requirement |
| RDS backup/snapshot encryption | Automated backups and manual snapshots of a CMK-encrypted instance are automatically encrypted with the same key — no separate Terraform configuration needed. Cross-account snapshot sharing with a customer-managed CMK is possible but requires the source CMK's key policy to explicitly grant the destination account, and best practice is to re-encrypt with a destination-account CMK on copy rather than depend on the source key | — | Security Hub RDS.1 (snapshot should be private) — already closed here since the instance is CMK-encrypted, not AWS-managed-key |
| AWS Backup + Control Tower | Native RDS automated backups are per-instance/per-account with no org-wide compliance dashboard. AWS Backup + a Control Tower-provisioned Backup Administrator account adds Backup Vault Lock (WORM immutability even root/admin can't override) and org-wide retention policy | Adds its own storage cost and a second policy system to maintain. Not worth it for a cost-parked preprod; materially more compelling for production, where Vault Lock is a real ransomware/insider-threat control and audit-evidence accelerator | Hardening/operational-maturity decision, not a strict compliance prerequisite — 7/30-day native retention with CMK encryption already satisfies baseline backup-encryption controls |
| Data classification tagging | AWS Well-Architected SEC07-BP02 and the SRA both name resource tagging (e.g. DataClassification=financial-pii) combined with tag-based IAM/SCP conditions as a recognized pattern. RDS supports aws:RequestTag conditions at creation; S3 does not — s3:CreateBucket needs AWS Organizations Tag Policies instead, a distinct feature from SCPs, which is a documented and easy-to-miss gotcha | Should be added as an explicit, resource-specific tag on the RDS instance and app_data bucket only — not via default_tags, which would either tag everything or require complex per-resource overrides | Recognized pattern (SEC07-BP02/SRA), general hardening — deciding what counts as "financial-pii" is a Finaisse data-governance call AWS cannot make |
| ElastiCache transit encryption | Currently off (transit_encryption_enabled = false), with the Terraform comment explaining why: blitz uses redis:// not rediss://. Since December 2022, AWS supports a graduated, zero-downtime migration — set transit encryption to preferred (accepts both schemes) while the client migrates, then flip to required | No longer an infrastructure blocker — the fix is a staged application-side Redis-client config change in blitz, not an infra rebuild. No AWS Config/Security Hub control corresponds to this for ElastiCache the way force_ssl does for RDS | General hardening/defense-in-depth; some SOC 2 auditors and PCI DSS interpretations require encryption-in-transit regardless of network boundary — worth confirming scope with the security owner rather than assuming "VPC-internal" is sufficient on its own |
Identity — Cognito (not currently in use)
Finaisse's tenant-facing app authentication is built on BetterAuth (fin-infra#14); AWS Identity Center/SSO is used only for internal AWS-account operator access (F-22), not customer-facing tenant auth. Amazon Cognito was researched as an unexplored alternative — recorded here for completeness, not as a pending decision.
| Capability | Detail |
|---|---|
| MFA | SMS, email OTP, TOTP natively supported; passkeys/WebAuthn (WEB_AUTHN) can satisfy MFA but only as a first factor, not a second factor to password login |
| Threat Protection | Compromised-credential detection against breach databases, adaptive/risk-based step-up authentication, IP allow/deny lists — mutually exclusive with MFA-required (adaptive auth needs MFA set to optional) |
| SAML/OIDC federation | Natively supported for enterprise SSO — directly relevant to open owner decision #4 (SSO/SAML provider for enterprise tenants) if Cognito were considered against Okta/Entra/WorkOS |
| Multi-tenancy pattern | Shared-pool-with-groups is simpler but a hosted-login session cookie is valid across all app clients in the same pool (1hr, non-configurable) — real cross-tenant session-bleed risk unless pools are separated or hosted UI is bypassed for API-based sign-in. Pool-per-tenant gives strongest isolation but hits a hard 1,000-user-pools-per-account ceiling |
| Pricing | Essentials tier: 10,000 free MAU/mo, then flat $0.015/MAU. SAML/OIDC: $0.015/MAU above 50 free |
| Fit assessment | Positioned in third-party commentary as "a general-purpose identity primitive, not an auth platform built for B2B SaaS" — WorkOS is cited as a B2B-SaaS-first alternative. Given BetterAuth is already the chosen path, this is recorded as background, not a recommendation to switch |
Maturity and gaps
- Coverage: every AWS topic researched during the 2026-09-05 assessment is now recorded either here (hardening/later-decision depth) or in the options assessment (gate-item depth). Nothing from that research is undocumented.
- Not yet decided: data classification tagging scheme, Object Lock adoption, per-tenant vs shared CMK, and the Cognito-vs-BetterAuth question (already effectively decided in BetterAuth's favor, recorded here only for completeness) all require a product/compliance owner decision this page does not make.
- Known omission: AWS Config, Amazon Detective, and AWS Audit Manager are not named anywhere in the go-live gate or findings register — Config is an implicit Security Hub prerequisite (see the options assessment); Detective and Audit Manager are genuinely out of scope for now (Audit Manager is closed to new customers as of 2026-04-30 regardless).
- Re-verification: cost figures here are reference-region rates; re-check ap-south-1 pricing before any procurement decision. Control-ID citations should be re-verified against the live Security Hub console once Security Hub is actually enabled (F-11), since control sets and severities do shift between CIS Benchmark versions.
Related
Revision history
| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | 2026-09-05 | Sekhar Prakash | Initial reference — full option/trade-off detail for AWS topics researched but not carried at full depth in the gate options assessment, plus Cognito as a newly-recorded (not adopted) alternative. |
Finaisse Internal — Confidential. Not for external distribution.