Infrastructure as Decorators
Infrastructure as Decorators (IaD) is the design model used by this project. It is a project term, not a claim about an established industry standard.
The central idea is:
Infrastructure remains owned by your IaC. IaD declares how application code participates in that infrastructure.
Your infrastructure-as-code application still owns the stack, APIs, networks, roles, tables, buckets, and other resources. A decorated handler adds the application-level intent that connects that handler to those resources.
Three related models
The terms below describe different centers of gravity. This table is a short, neutral comparison, not a definitive taxonomy.
| Model | Typical source of truth | What application code contributes |
|---|---|---|
| Infrastructure as Code | A dedicated program or declarative infrastructure files | Resources and their relationships are described directly |
| Infrastructure from Code | Application source and its conventions | Infrastructure is inferred or generated from application structure |
| Infrastructure as Decorators | IaC plus explicit declarations attached to application code | Handlers declare routing, configuration, permissions, and relationships |
In Lambda API Decorators, decorators are metadata-bearing declarations. HTTP decorators express routes; configuration decorators can select runtime, timeout, layers, environment, or networking; permission and authorization decorators express access intent and route behavior. The CDK package resolves that metadata while building infrastructure.
The current implementation has AWS CDK as its only infrastructure backend. Pulumi and other providers are not supported by this implementation. Also, changing the IaC backend would not make AWS-specific declarations portable: their meaning can depend on AWS Lambda, API Gateway, IAM, or CDK resource objects.
See Architecture for the package boundary and Configuration model for resolution details.