Build through code
Provision cloud infrastructure through Terraform rather than relying on repeated manual console changes.
Cloud Engineering Case Study
AWS Cloud Platformwith Terraform
A modular cloud-engineering platform using infrastructure as code, encrypted remote state, state locking and reusable Terraform components.
Executive Summary
Creating a repeatable foundation for cloud engineering.
The AWS Cloud Platform was created to develop practical experience designing and managing cloud infrastructure through Terraform.
The project avoids treating AWS as a collection of manually created resources. Instead, infrastructure is defined through code, separated into reusable modules and supported by remote state, locking and documentation.
The repository is structured to support multiple environments and future integration with monitoring, configuration management and automated deployment workflows.
The Challenge
Build cloud capability that remains controlled and repeatable.
Cloud consoles make it easy to create resources quickly, but manual changes can become inconsistent, difficult to audit and hard to reproduce.
The challenge was to create a structured platform where cloud resources, dependencies, environments and architectural decisions could be managed through a professional engineering workflow.
Project Objectives
Cloud infrastructure designed for reuse and control.
Protect Terraform state
Store state centrally with versioning and locking to support safer infrastructure changes.
Create reusable modules
Separate networking, compute, IAM, monitoring and security concerns into maintainable components.
Support multiple environments
Create a structure capable of supporting development, test and production configurations.
Document decisions
Record architectural choices, blockers, progress and implementation guidance alongside the code.
Develop practical AWS skills
Use a real repository and deployment workflow to build operational cloud capability.
Delivery Approach
Infrastructure developed in dependency order.
Define repository architecture
Created separate directories for environments, modules, scripts, documentation and supporting automation.
Create the bootstrap layer
Built a dedicated Terraform configuration responsible for creating the remote-state infrastructure.
Configure remote state
Provisioned an S3 bucket with versioning and encryption for central Terraform state storage.
Implement state locking
Added DynamoDB locking to reduce the risk of conflicting Terraform operations.
Develop reusable modules
Introduced modular structures for networking, IAM, security groups, EC2 and monitoring.
Build environment configurations
Created separate development, test and production directories to support controlled expansion.
Platform Components
Cloud services with clear engineering responsibilities.
Infrastructure as Code
Terraform
Defines cloud resources through version-controlled and reviewable configuration.Remote State
Amazon S3
Stores central Terraform state with versioning and server-side encryption.State Coordination
Amazon DynamoDB
Provides state locking to prevent simultaneous infrastructure modification.Identity
AWS IAM
Controls Terraform permissions and supports the principle of least privilege.Networking
VPC and Subnets
Provide the network foundation for future compute, security and application services.Delivery
Git and GitHub
Provide version history, collaboration, traceability and a future path to CI/CD.Architecture
From repository to managed AWS resources.
↓
↓
↓
↓
Architecture Decisions
Choices made to improve safety and maintainability.
Separate bootstrap state
Decision
Keep the state-backend configuration separate from the environments that consume it.
Reason
The state bucket and lock table must exist before other Terraform configurations can use them.
Benefit
Creates a clearer and safer infrastructure bootstrap process.
Use environment directories
Decision
Maintain development, test and production configurations separately.
Reason
Different environments may require different resource sizes, controls and deployment timing.
Benefit
Supports controlled change while allowing common modules to be reused.
Adopt reusable modules
Decision
Separate infrastructure capabilities into focused Terraform modules.
Reason
Large monolithic configurations become difficult to test, understand and maintain.
Benefit
Improves consistency, reuse and future expansion.
Document as code
Decision
Store architecture, progress, blockers and decisions in the same repository.
Reason
Infrastructure code alone does not explain the context behind important choices.
Benefit
Improves maintainability and provides clear evidence of engineering reasoning.
Project Delivery
Structured management of dependencies and risk.
Scope definition
Established the platform boundaries, repository structure and first delivery milestones.
Dependency management
Identified account activation, IAM access and state bootstrap as prerequisites.
Risk reduction
Used state locking, encryption, version control and modular design to reduce change risk.
Incremental delivery
Delivered bootstrap capability before networking and wider cloud resources.
Documentation
Maintained architecture, progress, blockers and decision records alongside implementation.
Future readiness
Designed the repository to support CI/CD, Ansible, monitoring and additional environments.
Challenges
Resolving access, state and delivery dependencies.
AWS account readiness
Problem
Infrastructure work could not progress fully until the AWS account and required access were active.
Response
Documented the blocker and continued developing the repository structure and Terraform design.
Outcome
Work resumed quickly once access became available without losing project direction.
Terraform authentication
Problem
Terraform required secure AWS credentials and clearly scoped permissions.
Response
Created a dedicated Terraform identity and kept credentials outside source control.
Outcome
Infrastructure provisioning could be performed without embedding secrets in the repository.
State bootstrap dependency
Problem
Remote state cannot be used until the resources storing that state already exist.
Response
Created a separate bootstrap configuration for S3 and DynamoDB.
Outcome
The platform has a repeatable initialisation path for future environments.
Repository SSH access
Problem
GitHub SSH configuration initially caused repository access and identity conflicts.
Response
Used an SSH host alias and corrected the repository remote configuration.
Outcome
The project could be pushed securely and maintained through Git.
Outcomes
A controlled foundation for future cloud development.
Central state
Terraform state is stored centrally rather than remaining on one workstation.
Safer changes
DynamoDB locking reduces the risk of conflicting infrastructure updates.
Reusable architecture
Common infrastructure components can be reused across environments.
Engineering context
Decisions and procedures are maintained with the infrastructure code.
Skills Demonstrated
Cloud engineering supported by delivery discipline.
Lessons Learned
Cloud foundations should be established before expansion.
Remote state, locking and identity should be considered before deploying wider infrastructure.
Modular Terraform improves reuse, but module boundaries should be based on clear responsibilities rather than created unnecessarily.
Dependencies and blockers should be documented so progress can continue even when external access or approvals are delayed.
Infrastructure as code provides the greatest value when supported by version control, documentation and a controlled delivery process.
Source and Related Work