---
title: Infrastructure as code
description: Define and reproduce AWS environments with version-controlled configuration.
---

[Designing first architecture on AWS: CryptX 2.0 Hackathon Workshop](https://www.youtube.com/watch?v=OVOONoYWAjQ)

<WorkshopRecordingLink href="https://youtu.be/OVOONoYWAjQ" />

Creating resources manually in the AWS console is useful for exploration, but repeated setup becomes difficult to review and reproduce. Infrastructure as code records resource definitions alongside application code.

## Why define the environment in code?

- Review infrastructure changes before applying them.
- Recreate development, testing, and production environments consistently.
- Track resource configuration and permissions in version control.
- Reduce drift caused by undocumented console changes.
- Share a repeatable setup across the team.

## Tools discussed in the workshop

| Tool | Scope | Role |
| --- | --- | --- |
| AWS Amplify | Web and mobile application workflows | Build and connect frontend and backend features |
| AWS CDK | AWS infrastructure definitions | Describe resources with languages such as TypeScript, Python, or Java |
| Terraform | Provider-based infrastructure management | Define resources across AWS and other platforms |

The session demonstrated CDK definitions for user pools, Lambda functions, and database tables, including encryption, indexes, and access policies. The useful idea is that permissions and data configuration belong in the same repeatable setup as the resources themselves.

## Apply it to the feedback system

Define the Cognito user pool, API routes, S3 bucket, processing functions, queue, notification topic, and database together. Give each function only the permissions required for its stage. Make environment-specific settings explicit so deploying a test environment does not accidentally reuse production resources.

[Continue to the end-to-end workflow](/docs/ta/workshops/aws-architecture/end-to-end-workflow)