Spec-Driven Infrastructure

Serverless computing abstracts infrastructure away, but that abstraction hides critical architectural decisions. Let's explore how to use Kiro Specs to make those decisions explicit, AWS MCP servers to understand what AWS services offer and what your architecture requires, and AWS CDK to generate infrastructure from specifications.

Transcript

1. ATHENS ATHENS April 28th 2026 Technopolis, Athens
2. ATHENS Spec-Driven Infrastructure: Building AWS solutions with Kiro Specs JAKUB GAJ Cloud Solution Architect @ Danske Bank (DK) jakub@serverless.ninja
3. ATHENS The serverless promise Zero servers to manage Automatic scaling Pay per use Faster time to market Serverless fundamentally changed how we build. Faster to ship, cheaper to run, and easier to start. No patching, no capacity planning. From zero to 1000s of requests. No traffic? No cost, no idle servers. Focus on product, not platform.
4. ATHENS Hidden decisions • Why this orchestration pattern over alternatives? • Sync or async processing? • What data to capture and how to model it? • How to handle failures and retries? • How to scope permissions? • What are the cost and scaling tradeoffs? They live in Slack threads, PR comments, someone's memory. Undocumented decisions: These aren't just implementation details, these are architecture.
5. ATHENS ADR documents We chose DynamoDB over PostgreSQL on RDS because... We chose Lambda durable functions over Step Functions because... We chose VPC endpoints over NAT gateways because... We chose EventBridge events over S3 notifications because... Context, options considered, rationale. Great practice. ADRs are documentation, but infrastructure is code. Architectural Decision Records capture the WHY behind the choices:
6. ATHENS Spec-Driven Development A software engineering methodology, prioritizing comprehensive planning and documentation before code implementation. Create detailed documentation covering requirements, expected behaviors, interfaces, and test criteria. Rooted in 1960s NASA workflows: verify the logic before you write the code.
7. ATHENS Kiro Ecosystem Feature Specs Structured requirements, design, and tasks Steering Project rules, standards, and conventions MCP Servers Access to external tools, knowledge sources Skills On-demand relevant expertise Powers MCP + Skills + Steering Activate dynamically Constructs Kiro configurations with CDK-style constructs
8. ATHENS Kiro Feature Specs Technical architecture, decisions, sequence diagrams, implementation considerations. Structured, testable, easy to understand: requirements, user stories, acceptance criteria. Executable implementation tasks with descriptions and expected outcomes, tasks dependencies.
9. ATHENS Kiro Steering Product's purpose, target users, key features, and business objectives. Chosen frameworks, libraries, development tools, and technical constraints. File organization, naming conventions, import patterns, and architectural decisions.
10. ATHENS Requirements phase Requirements are captured using the Easy Approach to Requirements Syntax (EARS) notation, providing clear, testable criteria for development. EARS notation for event-driven pattern: WHEN [event] AND [condition] THEN the system shall [outcome]
11. ATHENS CDK Resources Stack Template AWS Kiro Steering Files Specs Powers: IaC Application TS Project Stack L2 Constructs CloudFormation ASL Workflow EventBridge S3 Step Functions DynamoDB IAM MCP: IaC
12. ATHENS Travel Expense Processor NOMOS: turning chaos into structure 5 AWS services, 0 Lambda functions, all spec-driven. • Upload receipt photos or PDF invoices • Extract expense data (vendor, date, amount, currency) • Store structured results in DynamoDB table A functionless application built entirely from specs:
13. ATHENS
14. ATHENS Demo time! 1. Kiro Specs and Steering Files 2. Generating the CDK code 3. State machine in action
15. ATHENS When does it shine? Greenfield serverless projects Team onboarding Knowledge transfer Evolving systems & rapid iteration Multi-team collaboration Compliance & audit trails API contracts & testing Spec-Driven Workflow When to be cautious? Brownfield / legacy systems Highly custom logic Proof-of-concepts (PoC) Mixed tech stacks Rapidly changing requirements Manual infrastructure changes Undocumented business logic
16. ATHENS Use Specs to document your architectural choices now, even if you don't adopt it today. Involve your product owners to contribute to the Specs. Combine Specs + MCP + CDK to power-up your feature velocity. Key takeaways
17. ATHENS Ask Me Anything! Thanks! z ę ! Ευχαριστώ! Business Card Session Feedback