Intent-Based Infrastructure: Declare What You Need, Not How to Build It

The Infrastructure Tax

Every SaaS founder building on AWS faces an implicit tax: the gap between what you want to build and what AWS requires you to configure.

You want a database. AWS gives you RDS, Aurora, DynamoDB, or a dozen other options — each with its own VPC requirements, security groups, parameter groups, backup policies, and monitoring setup.

You want auth. AWS gives you Cognito, but then you need to configure user pools, identity pools, app clients, OAuth scopes, lambda triggers, hosted UI customization, and token validation middleware.

The result? You spend more time configuring infrastructure than building features.

What Is Intent-Based Infrastructure?

Intent-based infrastructure flips the model. Instead of specifying how to build something in AWS primitives, you declare what you need in business terms:

infrastructure: {
  databases: [{ id: 'main', type: 'postgres' }],
  auth: [{ id: 'users', signInWith: ['email', 'google'] }],
  storage: [{ id: 'uploads', cdn: true }],
  caches: [{ type: 'redis' }],
}

The framework translates these intents into fully configured AWS resources:

Why This Matters for SaaS

Faster Time to Market

A database declaration takes one line. The equivalent CDK construct takes 50–100 lines when you include VPC, subnets, security groups, parameter groups, backups, and monitoring. Multiply that across auth, storage, caching, and queues, and you've saved weeks of infrastructure work.

Preset-Driven Scaling

Intents respect your environment preset. The same database intent on nano gives you a db.t3.micro with basic backups. On medium, it's a db.r6g.large with multi-AZ, enhanced monitoring, and Point-in-Time Recovery.

You scale your entire infrastructure by changing one word:

envs: {
  dev: { preset: 'free' },    // Local Docker, $0
  staging: { preset: 'nano' }, // Minimal AWS, ~$5-15/mo
  prod: { preset: 'medium' },  // Production AWS, ~$100-300/mo
}

Override When Needed

Intents are defaults, not constraints. Need a specific RDS instance class in production? Override it directly on the environment config:

envs: {
  prod: {
    preset: 'medium',
    lambda: { memoryMb: 1024, timeoutSec: 20 },
    api: { throttleRateLimit: 200 },
  },
}

Overrides are flat — you specify the section you want to change (lambda, api, vpc, observability) directly alongside the preset. VentureKit deep-merges your overrides with the preset defaults so you only specify what's different.

How It Works Under the Hood

VentureKit's @venturekit/infra package contains a resolver that:

The generated CDK code follows AWS Well-Architected Framework best practices. Security groups follow least-privilege. Encryption is enabled by default. Monitoring and alarms are configured automatically.

Getting Started

Try it locally with the free preset — no AWS account required:

npx @venturekit/cli init my-saas
cd my-saas
vk dev

Your intents run against Docker Compose locally: Postgres, Redis, MinIO (S3-compatible), and a Lambda-mimicking HTTP server. When you're ready to deploy, vk deploy translates the same intents into real AWS resources.