Fjall Docs — deploy AWS infrastructure into your own account

Overview

The Enterprise tier is the highest-capability preset Fjall scaffolds. It combines large compute allocations, KMS customer-managed keys across every data store, RDS Proxy with TLS, four interface VPC endpoints, S3-backed flow logs with 365-day retention, and the enterprise backup tier, which turns on everything the lower tiers leave off: 35-day database backups, advanced Database Insights, deletion protection, one customer-managed key per stack for DynamoDB, SNS, Lambda, log groups and ECS Exec, Container Insights, load balancer and CloudFront access logs, and Lambda X-Ray tracing. An operator identity that runs aws ecs execute-command at this tier needs kms:GenerateDataKey on the stack key as well as ecs:ExecuteCommand. IAM Role → ECS services shows the grant. From fjall 38 the tier’s CloudFront access logs are delivered by CloudWatch-vended standard logging (v2), which this tier turns on by default. CloudWatch Logs creates the delivery resources in us-east-1 only: an application deployed to us-east-1 keeps them in its CDN stack, and an application in any other region gets a <App>UsEast1CdnLogging stack that holds them, deploys after the CDN stack and is destroyed before it. See CDN Factory → logging to point delivery at another bucket. logging: false on a CDN turns its delivery off, and an application with no logging CDN gets no <App>UsEast1CdnLogging stack.

Enterprise is a gated tier. Selecting it runs an entitlement check that blocks with “Enterprise tier requires an Enterprise 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`
Enterprise plan	Upgrade your organisation in the Fjall web app

Create an Enterprise Application

fjall create app --name api --type enterprise

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 (2048 CPU / 4096 MiB)           │            │
│  │  6 tasks (scales to 100)                     │            │
│  └──────────────┬──────────────────────────────┘            │
│                 │                                           │
│  ┌──────────────▼──────────────────────────────┐            │
│  │  RDS Proxy (TLS required)                    │            │
│  └──────────────┬──────────────────────────────┘            │
│                 │                                           │
│  ┌──────────────▼──────────────────────────────┐            │
│  │  Aurora (2 readers, KMS, 35-day backup)      │            │
│  │  Advanced Database Insights (KMS encrypted)  │            │
│  └─────────────────────────────────────────────┘            │
│                                                             │
│  VPC Endpoints: ECR, Secrets Manager, KMS, CloudWatch Logs  │
│  Flow Logs: S3 (365-day retention)                          │
└─────────────────────────────────────────────────────────────┘

What’s Included

Resource	Configuration
Compute	ECS Fargate, 2048 CPU, 4096 MiB memory
Scaling	6 desired tasks, scales to 100
Database	Aurora with 2 readers, KMS encryption, 35-day backup retention
Proxy	RDS Proxy with TLS required
Insights	Advanced Database Insights with KMS-encrypted storage
Read replica	Instance variant only. Aurora variants use 2 cluster readers instead
Network	3 AZs, 3 NAT Gateways
VPC endpoints	Interface endpoints for ECR, Secrets Manager, KMS, CloudWatch Logs
Flow logs	S3 destination, 365-day object expiry
Encryption	KMS customer-managed keys for storage and insights
Backup	AWS Backup at the enterprise vault tier
Storage	S3 buckets version by default at this tier
Lambda	1024 MB memory, 300s timeout (when you add one)

Database Variants

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

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

Global write forwarding lets an application connected to a secondary-region reader issue writes. Aurora forwards them to the primary writer rather than rejecting them, so a multi-region application keeps one connection string per region. Add a variant by naming both the database type and the tier:

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

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

Generated Infrastructure

Creating an Enterprise 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: { destination: "s3", retentionDays: 365 },
    vpcEndpoints: {
      interface: {
        ecr: true,
        secretsManager: true,
        kms: true,
        cloudwatchLogs: true,
      },
    },
  },
  backup: { tier: "enterprise" },
});

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: 2048,
        memoryLimitMiB: 4096,
        desiredCount: 6,
        scaling: { minCapacity: 6, maxCapacity: 100 },
        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.

Enterprise vs Resilient

Both tiers run 3 AZs, 3 NAT Gateways, CMK storage encryption, and RDS Proxy with TLS. These rows are where they differ. The backup-tier rows apply to every resource the application adds later, not only the scaffolded ones.

Feature	Resilient	Enterprise
CPU / memory	1024 / 2048 MiB	2048 / 4096 MiB
Backup retention	30 days	35 days
Database Insights	Standard	Advanced
Customer-managed keys	Database storage	Every store: one shared key per stack
Observability	Alarms	Container Insights, access logs, X-Ray
Desired tasks	4	6
Max tasks	20	100
Database (scaffolded)	Aurora	Aurora
Aurora backup retention	30 days	35 days
Instance size (Instance variant)	r7g.large	r7g.xlarge
Read replica (Instance variant)	No	Yes
ClickHouse size (ClickHouse variant)	m7g.large	m7g.xlarge
VPC interface endpoints	ECR, Secrets Manager	ECR, Secrets Manager, KMS, CloudWatch Logs
Flow logs	CloudWatch (90 days)	S3 (365 days)
Lambda memory	512 MB	1024 MB
Lambda timeout	120s	300s
AWS Backup vault tier	Resilient	Enterprise
AWS Backup rules	Continuous, 35 days	Continuous 35 days + monthly for 7 years
Recovery-point copies	DR region	DR region and the compliance account

Backup and Recovery

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.

Enterprise is the only tier whose recovery points leave the account. It runs two rules, each with one destination, because they answer different questions.

Rule	Schedule	Kept	Copied to
Continuous	Daily at 02:00 UTC, with continuous backup on	35 days	The DR-region vault in your own account
Monthly compliance	1st of the month, 02:00 UTC	7 years, warm unless the type supports cold storage	The compliance account’s vault

The continuous rule is the outage answer: inside its 35-day window you can restore to any second, and the copy in the DR region survives losing the primary one. AWS supports that second-level window for three of the five types this tier enrols — S3 buckets, RDS instances and Aurora clusters. A ClickHouse data volume and a DynamoDB table are enrolled by the same rule and receive a daily snapshot kept 35 days instead, so their finest granularity is a day rather than a second. The monthly rule is the record: a snapshot a month for seven years, in an account your application’s credentials cannot reach.

Layer	What the tier configures
What is enrolled	The RDS primary, the Aurora cluster, DynamoDB tables, ClickHouse data volumes and versioned buckets
What is not	Read replicas and Aurora member instances — the primary’s recovery points already hold that storage
Aurora	35-day backup retention with point-in-time recovery inside that window
S3	Versioning on by default, which is what makes a bucket eligible at all

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

Beyond day 35 the only recovery points are the monthly ones. The plan asks for them to move to cold storage at day 90, and AWS honours that request only for the resource types it supports cold storage on — of the five this tier enrols, DynamoDB tables qualify and the rest do not (an EBS-backed data volume would need an archive opt-in Fjall does not yet emit). Budget the seven-year record as warm storage, and size your recovery objectives against the rule that actually covers the age you need to restore from.

When to Use

Enterprise suits:

Regulated industries (finance, healthcare) that require audit trails and customer-managed encryption keys
High-throughput applications that need 100 concurrent tasks or more
Workloads that must keep AWS API traffic off the public internet via interface endpoints
Organisations with long-term log retention obligations

Pick Resilient instead when you need high availability without the larger compute baseline, the extra endpoints, or S3 flow-log retention.

Cost Considerations

Enterprise runs at a higher baseline than every other tier because of:

6 Fargate tasks running continuously (2 vCPU and 4 GB each)
3 NAT Gateways, one per AZ
Aurora with 2 readers plus RDS Proxy
4 VPC interface endpoints, billed per hour per endpoint per AZ
S3 flow-log storage held for 365 days
CloudFront access logs on an application with a CDN, delivered through CloudWatch Logs from fjall 38 (budget for the vended-log delivery charge per GB, plus S3 storage and requests for the objects)
Three copies of every monthly recovery point — the source vault, the DR region and the compliance account — held warm for the full seven years for every type but DynamoDB

Expect

300 to

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

Next Steps

Deploy Application

Deploy your Enterprise application to AWS

Add Resources

Extend with storage, messaging, or CDN

Compute Factory

Customise compute configuration

Database Factory

Customise database configuration

Factory Patterns

Application Patterns

Architecture Patterns

Enterprise Pattern

Overview

Prerequisites

Create an Enterprise Application

Architecture

What’s Included

Database Variants

Generated Infrastructure

Enterprise vs Resilient

Backup and Recovery

When to Use

Cost Considerations

Next Steps

Deploy Application

Add Resources

Compute Factory

Database Factory

​Overview

​Prerequisites

​Create an Enterprise Application

​Architecture

​What’s Included

​Database Variants

​Generated Infrastructure

​Enterprise vs Resilient

​Backup and Recovery

​When to Use

​Cost Considerations

​Next Steps

Deploy Application

Add Resources

Compute Factory

Database Factory

Overview

Prerequisites

Create an Enterprise Application

Architecture

What’s Included

Database Variants

Generated Infrastructure

Enterprise vs Resilient

Backup and Recovery

When to Use

Cost Considerations

Next Steps