AWS & Cloud Engineering · Proof-of-Concept Lab

AWS Cloud
Architecture &
Automation

A documented cloud portfolio covering Linux and Windows compute, containers, private networking, infrastructure as code and managed data.

View the full project report
Diagram of Medi-Advice AWS proof-of-concept modules for EC2 and Docker, VPC peering, CloudFormation automation and RDS replication
Solution map · Separate proof-of-concept modules, each built and validated independently
6hands-on build modules
2privately peered VPCs
5final stack resources
47evidence screenshots

Project overview

Context
CCT College Dublin
Environment
AWS proof-of-concept lab
Role
Architecture, implementation, validation & documentation
Approach
Build, validate, automate & document

A cloud portfolio built around working evidence.

The Medi-Advice project brought together six hands-on infrastructure modules. I deployed web workloads, containerised a site, connected two VPCs over private routes, automated resources with CloudFormation and tested managed MySQL replication.

The challenge

The goal was to move beyond isolated AWS console exercises. Each module needed a clear purpose, a working configuration and a final validation step that proved the service behaved as expected.

Scope note

These were separate lab modules rather than one production environment. The CloudFront work was a documented delivery design, not a completed deployment, and is described that way here.

Core builds

  1. 01 Compute & containers

    Hosted the Medi-Advice site on Ubuntu EC2, transferred files over SFTP, then rebuilt delivery with Docker and Nginx.

  2. 02 Private networking

    Peered Manufacturing and Engineering VPCs, updated both route tables and validated private HTTP traffic in both directions.

  3. 03 Infrastructure as code

    Used CloudFormation Change Sets to add HTTP access, a 10 GB EBS volume, its attachment and an S3 bucket.

  4. 04 Managed data

    Created an RDS MySQL primary and read replica, queried replicated inventory data and confirmed that replica writes were blocked.

Validation evidence

Provisioning was only the start.

Each module ended with a practical check. The evidence below keeps sensitive account details out of the public portfolio while preserving the technical result.

ComputeValidated

Container reached on port 80

The Nginx container served the Medi-Advice landing page while Apache remained inactive on the host.

docker ps 0.0.0.0:80 → nginx:alpine Website loaded successfully
NetworkingActive

Private traffic crossed both VPCs

Routes and security-group rules allowed the Windows IIS and Ubuntu Apache servers to reach each other by private IP.

Manufacturing ↔ Engineering 10.10.0.0/16 ↔ 10.20.0.0/16 HTTP response verified both ways
Infrastructure as codeComplete

Change Sets updated the stack safely

The final template managed the security group, EC2 instance, EBS volume, volume attachment and S3 bucket.

CloudFormation UPDATE_COMPLETE 5 managed resources
Managed dataRead only

Replication worked as designed

The replica returned the same ten inventory rows as the primary and rejected an attempted insert.

Primary → Read replica SELECT: 10 rows returned INSERT: blocked by read-only setting

Production thinking

Validated in the lab. Framed honestly for production.

What I would strengthen next

The controlled lab used public access and broad rules in places to make validation possible. A production design would move databases into private subnets, restrict administration, use IAM roles and Secrets Manager, enable encryption and add monitoring, backups and Multi-AZ resilience where required.

Technology used

Next case study

Online Retail Sales Analysis →