Fjall Docs — deploy AWS infrastructure into your own account

Overview

The Resilient tier targets applications that need high availability and data durability without the compute baseline of Enterprise. It scaffolds 3 Availability Zones with one NAT Gateway each, an Aurora PostgreSQL cluster with two readers, KMS customer-managed keys for storage and Database Insights, RDS Proxy with TLS required, and the resilient backup tier, which sets 30-day database backups, deletion protection on DynamoDB tables and production load balancers, S3 versioning and AWS Backup enrolment.

Resilient is a gated tier. Selecting it runs an entitlement check that blocks with “Resilient tier requires a Pro plan.” when your organisation is on a lower plan.

Prerequisites

Requirement	How to satisfy it
Fjall CLI	`npm install -g fjall` (Node 22.3 or later)
Signed in	`fjall login`
AWS account	`fjall connect`
Pro plan	Upgrade your organisation in the Fjall web app

Create a Resilient Application

fjall create app --name api --type resilient

Run fjall create app with no flags to pick the tier from a menu instead. The first prompt reads ? Choose your starting point? and lists six options in this order: Standard, Lightweight, Resilient, Enterprise, Tinkerer, Custom. Standard is pre-highlighted unless you passed -t/--type.

Architecture

┌─────────────────────────────────────────────────────────────┐
│  VPC (3 AZs, 3 NAT Gateways)                                │
│                                                             │
│  ┌─────────────────────────────────────────────┐            │
│  │  ALB (Application Load Balancer)             │            │
│  └──────────────┬──────────────────────────────┘            │
│                 │                                           │
│  ┌──────────────▼──────────────────────────────┐            │
│  │  ECS Fargate (1024 CPU / 2048 MiB)           │            │
│  │  4 tasks (scales to 20)                      │            │
│  └──────────────┬──────────────────────────────┘            │
│                 │                                           │
│  ┌──────────────▼──────────────────────────────┐            │
│  │  RDS Proxy (TLS required)                    │            │
│  └──────────────┬──────────────────────────────┘            │
│                 │                                           │
│  ┌──────────────▼──────────────────────────────┐            │
│  │  Aurora (2 readers, KMS, 30-day backup)      │            │
│  │  Database Insights (KMS encrypted)           │            │
│  └─────────────────────────────────────────────┘            │
│                                                             │
│  VPC Endpoints: ECR, Secrets Manager                        │
│  Flow Logs: CloudWatch Logs (90-day retention)              │
└─────────────────────────────────────────────────────────────┘

What’s Included

Resource	Configuration
Compute	ECS Fargate, 1024 CPU, 2048 MiB memory
Scaling	4 desired tasks, scales to 20
Database	Aurora with 2 readers, KMS encryption, 30-day backup retention
Backup tier	Resilient: 30-day backups, deletion protection, S3 versioning
Proxy	RDS Proxy with TLS required
Insights	Database Insights, standard mode, KMS-encrypted storage
Network	3 AZs, 3 NAT Gateways
VPC endpoints	Interface endpoints for ECR and Secrets Manager
Flow logs	CloudWatch Logs, 90-day retention
Encryption	KMS customer-managed keys for storage and insights
Backup	AWS Backup at the resilient vault tier
Storage	S3 buckets version by default at this tier
Lambda	512 MB memory, 120s timeout (when you add one)

Database Variants

fjall create app --type resilient scaffolds Aurora. Every other variant is available through fjall add database, and each one carries its own Resilient configuration.

Variant	Resilient configuration
Aurora (scaffolded)	2 readers, CMK storage key, Database Insights (CMK), RDS Proxy with TLS, 30-day backups
GlobalAurora	Everything Aurora provides, plus `enableGlobalWriteForwarding`
Instance	r7g.large, CMK storage key, Database Insights (CMK), RDS Proxy with TLS, 30-day backups
ClickHouse	m7g.large, S3 cold tier, daily optimise at 04:00 and backup at 05:00 UTC, 14-day backup retention

Add a variant by naming both the database type and the tier:

fjall add database -a api --name Analytics --type ClickHouse --databaseName analytics --tier resilient

--tier on fjall add database requires --type, because a tier configures each database type differently.

Generated Infrastructure

Creating a Resilient application writes an infrastructure.ts close to this:

import {
  App,
  DatabaseFactory,
  ComputeFactory,
  getConfig,
} from "@fjall/components-infrastructure";

const appName = "api";
const app = App.getApp(appName, {
  network: {
    maxAzs: 3,
    natGateways: { count: 3 },
    flowLogs: { retentionDays: 90 },
    vpcEndpoints: {
      interface: { ecr: true, secretsManager: true },
    },
  },
  backup: { tier: "resilient" },
});

app.addTags({
  "fjall:costAllocation:owner": "engineering",
});

const apiDatabase = app.addDatabase(
  DatabaseFactory.build("api", {
    vpc: app.getVpc(),
    type: "Aurora",
    databaseName: "api",
    encryption: { storageKey: { useCMK: true } },
    databaseInsights: { encryptionKey: { useCMK: true } },
    proxy: { requireTLS: true },
    readers: { count: 2 },
  }),
);

app.addCompute(
  ComputeFactory.build("api", {
    type: "ecs",
    ecrRepository: app.getDefaultContainerRegistry(),
    services: [
      {
        name: "api",
        capacityProvider: "FARGATE",
        containers: [
          {
            port: 3000,
            environment: {
              ENVIRONMENT: getConfig().environment,
              DATABASE_HOST: apiDatabase.getHostEndpoint(),
              DATABASE_PORT: apiDatabase.getHostPort(),
              DATABASE_NAME: apiDatabase.getDatabaseName(),
              DATABASE_SSL: "true",
            },
            secretsImport: {
              DATABASE_USERNAME: apiDatabase
                .getCredentials()
                .getImport("username"),
              DATABASE_PASSWORD: apiDatabase
                .getCredentials()
                .getImport("password"),
            },
          },
        ],
        cpu: 1024,
        memoryLimitMiB: 2048,
        desiredCount: 4,
        scaling: { minCapacity: 4, maxCapacity: 20 },
        connections: [apiDatabase],
      },
    ],
  }),
);

The database and compute constructs both take the application name as their id. Edit this file directly, or use fjall add, fjall modify and fjall remove to change it.

Specifications

Compute (ECS Fargate)

Setting	Value
CPU	1024 units (1 vCPU) per task
Memory	2048 MiB per task
Tasks	4 desired, 4 minimum, 20 maximum
Auto-scaling	Target-tracking on average CPU at 50%, 60s cooldowns
Deployment	Rolling update with the ECS deployment circuit breaker
Rollback	Automatic on a tripped breaker

The circuit breaker sets ResetOnHealthyTask: false, which is stricter than the AWS default. A crash loop that occasionally boots one healthy task still trips the breaker rather than holding the deployment IN_PROGRESS.

Database (Aurora)

Setting	Value
Engine	Aurora PostgreSQL 18.4
Capacity	Serverless v2 writer and readers, scaling with load
Readers	2 reader instances
Backup retention	30 days, from the resilient backup tier
Point-in-time recovery	Within the 30-day retention window
Multi-AZ	Automatic failover to a reader
RDS Proxy	Connection pooling and failover handling, TLS required
Database Insights	Standard mode, encrypted with a customer-managed key

Network and security controls

Control	Value
Availability Zones	3, with one NAT Gateway per zone
Interface endpoints	ECR, Secrets Manager
VPC flow logs	CloudWatch Logs, 90-day retention
Storage encryption	KMS customer-managed key on the Aurora cluster
Insights encryption	KMS customer-managed key on Database Insights storage
Transport encryption	TLS required at the RDS Proxy, ACM certificates on the ALB
S3 versioning	On by default for buckets at this tier
Deletion protection	DynamoDB tables, and the load balancer in production
Backup enrolment	AWS Backup, resilient plan

Map these controls onto your own compliance framework. Fjall does not carry an attestation for a tier.

High Availability

Multi-AZ topology

ECS tasks spread across 3 Availability Zones
One NAT Gateway per zone, so a zone failure does not strand egress
Aurora promotes a reader on writer failure
ALB routes across all three zones

Auto-scaling

Auto-scaling is on by default. Omitting scaling gives a CPU target-tracking policy where minCapacity tracks desiredCount and maxCapacity defaults to Math.max(desiredCount + 1, 3). The Resilient preset sets both explicitly.

{
  name: "api",
  desiredCount: 4,
  scaling: { minCapacity: 4, maxCapacity: 20 },
}

Switch the metric with scalingType, or turn scaling off with scaling: false:

import { ScalingType } from "@fjall/components-infrastructure";

{
  name: "api",
  desiredCount: 4,
  scaling: {
    minCapacity: 4,
    maxCapacity: 20,
    scalingType: ScalingType.MEMORY,
  },
}

The policy targets 50% utilisation with 60-second scale-in and scale-out cooldowns. ScalingType.QUEUE swaps the target-tracking policy for step scaling on SQS backlog, which can wake a service from desiredCount: 0.

Alarms

Compute and database alarms ship on by default and publish to the application’s SNS topic. Override the thresholds on the resource, or pass alarms: false to opt out.

// On a service
alarms: {
  cpuThreshold: 80,
  memoryThreshold: 85,
  http5xxThreshold: 5,
  p99ResponseTimeThresholdMs: 2000,
}

// On the database
alarms: {
  cpuThreshold: 80,
  freeStorageThresholdGiB: 10,
  connectionsThreshold: 200,
}

Backup and Recovery

Standard enrols too — a daily snapshot kept 90 days. Resilient is the lowest tier that adds continuous backup and a copy outside the region, and the lowest at which S3 buckets are enrolled (AWS Backup requires versioning, which this tier turns on). Continuous backup is what buys second-level restore, and AWS supports it for RDS instances, Aurora clusters and S3 buckets. DynamoDB tables and ClickHouse data volumes are enrolled by the same rule and receive the daily snapshot instead, so their finest granularity is a day.

Layer	What the tier configures
Aurora	30-day backup retention with point-in-time recovery inside that window
AWS Backup plan	Daily backup at 02:00 UTC, continuous backup enabled, 35-day retention
Cross-region copies	A copy action into the DR-region vault, when your organisation has a DR region set
What is enrolled	The RDS primary, the Aurora cluster, DynamoDB tables, ClickHouse data volumes and versioned buckets. Read replicas and Aurora member instances are not — the primary’s recovery points already hold that data
S3	Versioning on by default for buckets at this tier

Resources join the plan through the fjall:disasterRecovery:tier tag, applied from backup: { tier: "resilient" }. The vault and the plans live in the account infrastructure, not the application stack.

AWS Backup’s Region service opt-in has to admit the type, and it is yours to set. Fjall’s plans select resources by tag alone, and AWS applies a Region’s service opt-in to a tag-only selection. So in an account and Region where the opt-in for S3, RDS, Aurora, DynamoDB or EBS is off, a tagged resource of that type is in no backup plan at all — not a missing copy, no backup — and the plan still reports healthy. Fjall never turns one on for you: doing so moves that account’s backup charges and backup ARNs Region-wide. Check it at AWS Backup console → Settings → Service opt-in, in each account and Region you deploy into.

Recovery time depends on which layer you restore from. An Aurora writer failure fails over to a reader in minutes without a restore. A point-in-time restore of the cluster takes as long as Aurora needs to rebuild the volume. Test both paths against your own recovery objectives rather than assuming a figure.

Cost Considerations

Resilient runs at a higher baseline than Standard because of:

4 Fargate tasks running continuously (1 vCPU and 2 GB each)
3 NAT Gateways, one per AZ
Aurora with 2 readers plus RDS Proxy
2 VPC interface endpoints, billed per hour per endpoint per AZ
KMS customer-managed keys for storage and Database Insights
AWS Backup storage at 35-day retention

Expect

200 to

600 or more per month, depending on traffic and data volume. Run fjall costs against a deployed application for figures from your own account.

Resilient vs Standard

Feature	Standard	Resilient
Scaffolded database	RDS Instance	Aurora
CPU / memory	512 / 1024 MiB	1024 / 2048 MiB
Desired tasks	2	4
Max tasks	5	20
NAT Gateways	1	3
VPC interface endpoints	ECR	ECR, Secrets Manager
Flow log retention	14 days (default)	90 days
KMS customer-managed	No	Storage key and insights key
RDS Proxy	No	Yes, TLS required
Database Insights	Standard	Standard
Backup retention	14 days	30 days
Deletion protection	Databases	Databases, DynamoDB, prod ALB
AWS Backup	Standard plan	Resilient plan
Lambda defaults	256 MB, 60s	512 MB, 120s

Moving an existing Standard application up means replacing the RDS Instance with an Aurora cluster, which is a data migration rather than a config change. Plan it as one.

When to Use

Resilient suits:

Customer-facing applications that cannot absorb a single-AZ outage
Workloads that need customer-managed encryption keys without the Enterprise compute baseline
Applications with a backup and retention obligation beyond the database default
Teams that want connection pooling and TLS enforcement at the database edge

Pick a different tier when:

Situation	Tier
Steady, low-traffic production workload	Standard
Cost is the primary constraint	Lightweight
Experiments and free-tier work	Tinkerer
100 concurrent tasks, 4 interface endpoints, 365-day flow logs	Enterprise

Next Steps

Deploy Application

Deploy your Resilient application to AWS

Add Resources

Extend with storage, messaging, or CDN

Database Factory

Customise the Aurora configuration

Enterprise Pattern

Compare against the highest-capability tier

Factory Patterns

Application Patterns

Architecture Patterns

Resilient Pattern

Overview

Prerequisites

Create a Resilient Application

Architecture

What’s Included

Database Variants

Generated Infrastructure

Specifications

Compute (ECS Fargate)

Database (Aurora)

Network and security controls

High Availability

Multi-AZ topology

Auto-scaling

Alarms

Backup and Recovery

Cost Considerations

Resilient vs Standard

When to Use

Next Steps

Deploy Application

Add Resources

Database Factory

Enterprise Pattern

​Overview

​Prerequisites

​Create a Resilient Application

​Architecture

​What’s Included

​Database Variants

​Generated Infrastructure

​Specifications

​Compute (ECS Fargate)

​Database (Aurora)

​Network and security controls

​High Availability

​Multi-AZ topology

​Auto-scaling

​Alarms

​Backup and Recovery

​Cost Considerations

​Resilient vs Standard

​When to Use

​Next Steps

Deploy Application

Add Resources

Database Factory

Enterprise Pattern

Overview

Prerequisites

Create a Resilient Application

Architecture

What’s Included

Database Variants

Generated Infrastructure

Specifications

Compute (ECS Fargate)

Database (Aurora)

Network and security controls

High Availability

Multi-AZ topology

Auto-scaling

Alarms

Backup and Recovery

Cost Considerations

Resilient vs Standard

When to Use

Next Steps