Because every Wedding RSVP website needs to be provisioned using Terraform (Cloud) within AWS.
🌎 Website | 📷 Gallery | 🏗️ Infrastructure
Foundational infrastructure for the Wedding service is provisioned using Terraform and Terraform Cloud, and can be found within this repository. Transient infrastructure such as Lambda functions/API-gateways (which change based on each deployment) are handled using the Serverless Framework; with the application itself being responsible for these concerns. Resources created at this level (within Terraform) can expose details to the transient application infrastructure by way of Secrets Manager secrets and SSM parameters.
Below is a table detailing how each concern has been broken up into logical separated units.
Context | Name | Purpose | Example resources |
---|---|---|---|
Shared | Network | Communication, spanning all stages | Route53 hosted zones for root domain |
Stage | Apps/Application |
Fulfil runtime requirements | CloudFront, SSM, SQS, SNS |
Stage | Data/Application |
Permanent storage | RDS, S3 (User uploads) |
Stage | Health | Monitoring and alerting | S3 (logs), CloudTrail, CloudWatch alarms |
Stage | Network | Communication, within given stage | VPC, VPC endpoints, DNS, NAT-instance |
Stage | Security | Security | KMS, WAF, GuardDuty |
For a clearer understanding of the meaning behind Context and Application please continue reading.
Terraform projects which compose the the Wedding service have been broken up into two seperate contexts - Shared and Stage.
Stage
Stage projects are for infrastructural concerns which relate to a given stage environment, for example staging
and prod
.
There is expected to be an instance of each given project per stage environment.
Resources within a project can be shared throughout the same environment, but not cross into different stage environments.
Within Terraform Cloud we suffix the given project with the stage name to identify its' environment.
Shared
Shared projects are for cross-cutting concerns which span all stages - and are shared throughout the service as a whole.
Resources within this service have been designed in such a way that they can placed within the same AWS account, or multiple seperate AWS accounts.
The service is composed of many applications which are logically seperated within a given stage based on runtime/storage requirements. There are two applications - one named Website, which manages the infrastructure for the RSVP website; and another named Gallery, which manages infrastructure for the photo gallery.
There is a Makefile to provide tooling to assist continued development of the service. So as to ensure coding standards are met and any security issues caught before provisionment, the following tools are relied upon:
- tflint - Fixes possible errors and enforces best-practises.
- tfsec - Static analysis tool to spot potential security issues.
- tfdoc - generates structured documentation for each Terraform project.
These tools are run (via make can-release
) within a GitHub workflow upon each push to the repository.
They can also be run locally by invoking the same Make target.