AWSでのセルフホスティング

​

アーキテクチャ概観

​

Network — AZごとの4つのサブネット階層

​

Data tier

​

RDS Postgres、Multi-AZ、RDS管理のmaster password

• manage_master_user_password = true — master credentialはRDS自身が所有し、AWSが約7日ごとに自動ローテーションするSecrets Manager secretに入ります。Secrets Managerに DATABASE_URL secretはありません。理由は後述の entrypointが起動時にDATABASE_URLを組み立てる理由 を参照してください。
• multi_az = var.environment == "production" — Multi-AZは本番のみです。staging/devはフットプリントとコストを最小にするためsingle-AZで動きます。
• Storageとmaster-user secretはどちらも、このモジュール自身のKMS CMK（aws_kms_key.envelope — 後述の KMS CMK を参照）で暗号化されます。
• backup_retention_period = 14、deletion_protection、performance_insights_enabled は environment == "production" によって有効化されます（Performance Insightsはburstableな db.t4g.micro/t3 クラスではサポートされておらず、staging.tfvars が使うのはまさにそれです）。
• parameter groupレベルの rds.force_ssl = 1 により、転送中のTLSが必須になります。組み立てられる DATABASE_URL は sslmode=no-verify を持ちます（TLSは有効、ただしRDSのCA chainは検証しません。require/verify-full ではなく no-verify にする理由はentrypointのセクションを参照してください）。

​

ElastiCache Redis

• 分散rate limiter（createRedisRateLimiter）。これにより /v1/run のquotaはプロセス単位ではなくfleet全体で強制されます。
• live-view/authoringのpub-sub relay。あるレプリカで生成されたCDP frameを、別のレプリカに接続しているviewerへfan outできます。
• 後述のEventBridge tickと並ぶscheduler-firing coordination。

​

EFS — content-addressed registry

​

Compute — 4つのECS Fargateサービス

​

Edge — ALB (api.*) + CloudFront (app.*)

• app.<domain> → web target group（priority 10）— Next.js SSR app。
• api.<domain> → api target group（priority 20）— ただし意図されたpublic surfaceだけです: /v1/*、/api/*、/health、/ready、/internal/tick。priority 30の2つ目のruleが、hosted MCP endpoint用に /mcp、/mcp/* を追加します。これは 別の ruleです。ALBの path_pattern conditionは最大5つの値までで、最初のruleがすでにその上限に達しているためです。
• api.<domain> 上のその他すべて → 固定の 403 {"error":"forbidden"} response。 これはlistenerの default_action です。composed engineのコントロールプレーン（/runs、/flows、/deploys、/secrets、/schedules、/registry）は、その層では設計上unauthenticatedだからです。wrapper自身のapp-level gateはdefense in depthであって、唯一の防衛線ではありません。ALBでdeny-by-defaultにすることで、app-layer gateが将来regressしてもギャップを閉じられます。

• alb_idle_timeout >= 300 — variables.tf のhard validationです。serviceはSSE/WS connectionを255秒（server.ts Bun idleTimeout）開いたままにするため、ALB timeoutがそれより短いとlive-view streamがsession途中で切れます。
• Stickiness on（lb_cookie、3600秒）を api target groupで有効にします。これにより、特定のauthoring/live-view sessionは、そのbrowser pageを実際に所有しているレプリカへ着地し続けます。

​

KMS CMK — secret envelope + at-rest key

1. Secret envelope master key。 var.use_kms_envelope = true（デフォルト）のとき、serviceは JINBA_KMS_KEY_ARN を設定して動きます。これは JINBA_MASTER_KEY bridgeより優先されます。master keyはKMSから出ず、すべてのsecret unwrapは独立したCloudTrail監査対象の kms:Decrypt callになります。
2. At-rest encryption。RDS、Redis、EFS、SQS queues、S3 web bucket、CloudWatch log groupを暗号化します。監査されるkeyは1つなので、rotationはserviceごとのre-encrypt sweepではなく、単一のCMK operationになります。

​

SQS run-dispatch — FIFOではなくstandard queue

​

EventBridge → signed /internal/tick

​

entrypointが起動時にDATABASE_URLを組み立てる理由

• Terraformは、rotationをまたいでも変わらないpieceだけをplainな非secret environmentとしてinjectします。JT_DB_HOST（aws_db_instance.main.address、hostのみで .endpoint ではない）、JT_DB_PORT、JT_DB_USER、JT_DB_NAME、JT_DB_SSLMODE=no-verify です。
• 現在の rotating passwordは、RDS-managed secretから直接 secrets referenceとしてinjectします。:password:: JSON-key selector（"${local.rds_master_secret_arn}:password::"）を使います。ECSはtask startごとにこれを解決するため、新しくrollされたtaskは常に、その瞬間にliveなpasswordを受け取ります。
• containerの最初のprocessとして実行されるentrypointが、これらのpieceからconnection stringを組み立て、実際の CMD（または後述のmigration taskのようなECS command override）を exec する前に DATABASE_URL を export します。

if [ -z "${DATABASE_URL:-}" ] && [ -n "${JT_DB_PASSWORD:-}" ] && [ -n "${JT_DB_HOST:-}" ]; then
  _enc_pw="$(bun -e 'process.stdout.write(encodeURIComponent(process.env.JT_DB_PASSWORD||""))')"
  export DATABASE_URL="postgres://${JT_DB_USER}:${_enc_pw}@${JT_DB_HOST}:${JT_DB_PORT}/${JT_DB_NAME}?sslmode=${JT_DB_SSLMODE}"
fi
exec "$@"

​

モジュールの適用

cd deploy/terraform/bootstrap
terraform init
terraform apply -var 'state_bucket=jinbatrail-tfstate-<account_id>' -var 'lock_table=jinbatrail-tflock'

cd deploy/terraform
terraform init \
  -backend-config="bucket=jinbatrail-tfstate-<account_id>" \
  -backend-config="key=staging/terraform.tfstate" \
  -backend-config="region=us-east-1" \
  -backend-config="dynamodb_table=jinbatrail-tflock"

terraform plan  -var domain_name=jinbatrail.example -var 'anthropic_api_key=…'
terraform apply -var domain_name=jinbatrail.example

​

api_desired_count を1より大きくしないこと

1. gateが確認するreplica countは自己申告であり、ここでは何もそれを報告していません。 replicaCount は JT_REPLICA_COUNT から来ます。これはデフォルトで 1 であり、environment variables reference の自身のdocumentationにある通り、“informational … not used to configure anything.” です。compute.tf の common_environment は、どこでも var.api_desired_count から JT_REPLICA_COUNT を設定していません。具体的には、このモジュールで今 api_desired_count を 2 に上げても、/ready gateは2レプリカで動いていることを認識しません。1 を読み続け、greenのままです。意図されたhard-fail protectionは、それが観測すべきTerraform knobに配線されていません。
2. Live-view session ownershipは、gap closureでは消えない物理的制約です。 active authoring sessionのCDP pageは、あるtaskのprocessによって開かれ、移動できません。Redis pub-sub relayはすでにcaptureされた frames を他のレプリカへfan outしますが、2つ目のレプリカは、自分が開いていないpageを引き継いで control することはできません。sticky ALB sessionsがこれを成立させており、gap closureだけで成立しているのではありません。そしてstickiness pinningはbest-effort cookieであって、すべてのfailure modeでのhard guaranteeではありません（task recycleがsession途中で起きれば、そのsessionのbrowserはやはりdropします）。

​

Observability

• 1つのSNS topic。下記のすべてのalarmがそこへpublishします（alarm_sns_topic_arn）。任意のemail subscriptionは var.alarm_email でgateされます。subscriberがいなくてもalarmは常に存在しdashboardを動かすため、このモジュールのapplyが黙って誰かにpageし始めることはありません。
• ALB: ELB-generatedおよびtarget-generatedの5xx counts、api target groupのunhealthy-host count（これはboot/readiness gateがinfra signalとして現れたものです。/health に失敗するtaskはhealthy targetになりません）、そしてlive-view WS/SSE relayのconnection dropのproxyとしての高い TargetConnectionErrorCount。
• RDS: CPU、free storage、connection-count thresholds。それぞれ単純な var.*_alarm_threshold で、instance sizeごとにtuneできます。
• SQS: queue-backlog high/low（worker autoscaling policiesを駆動）とDLQ-not-empty（Run、またはscheduler tickがすべてのredeliveryを使い切った状態）。
• CloudWatch dashboard（${name}-ops）。4つのwidgetを持ちます: ALB requests/5xx、target health/latency、RDS CPU/connections/storage、queue/DLQ depth。
• Tracing は変数でgateされます（enable_tracing、デフォルト false — opt inするまでコストゼロ）。X-Ray write IAM policyを付与し、OTEL_* envをadvertiseするだけです。実際にspanをexportするには、task上のADOT/OTel collector sidecarがまだ必要ですが、このモジュールはそれを追加しません。

​

関連