Build the network. Watch how the system behaves.
Cloud infrastructure needs a deliberate network structure and a way to explain its behaviour under load. Provisioning compute alone leaves questions about which resources are exposed, how the environment is organised, and what information becomes available when demand changes.
This project focused on AWS infrastructure using a VPC, public and private subnets, EC2, and CloudWatch. It combined systems design with monitoring and load testing, bringing the shape of the environment together with the signals needed to examine how it runs.
I designed the network with public and private separation, provisioned and configured EC2 compute, and set up CloudWatch monitoring, logging, and alerting. Load testing under production-style traffic conditions provided a practical setting for evaluating performance and reliability. The emphasis was on making behaviour observable as well as making infrastructure available.
Select a layer to see its purpose in the system. Reliability depends on the relationships between these layers, as much as the individual components.
The network separates public and private parts of the system, so exposure is an explicit design choice.
Begin with the VPC and the division between public and private subnets. This gives the environment an explicit structure and separates networking decisions from the assumption that every resource should occupy the same exposed space.
Configure EC2 instances and bring monitoring, logs, and alerts into the environment through CloudWatch. Compute and observability are considered together, so examining the system’s behaviour is part of the setup rather than a separate task after deployment.
Run load tests under conditions intended to resemble production traffic and inspect the available signals. The purpose is to evaluate how the configured system behaves under pressure, giving the infrastructure design a practical basis for review.
Subnet separation was a central part of the VPC design. It establishes a network boundary that can be reasoned about explicitly, rather than treating the cloud environment as an undifferentiated collection of instances.
CloudWatch monitoring, logging, and alerting were included in the implementation. This makes observability a design concern and keeps attention on the signals that explain the system, alongside the resources required to run it.
Load testing creates a way to examine performance and reliability under changing demand. In this project it complemented provisioning and configuration, connecting infrastructure choices to observed behaviour instead of ending the work when deployment succeeded.
The documented work includes AWS configuration, observability setup, and load testing. No numerical throughput, response-time, availability, or cost benchmark is published in this account. Production-style test conditions describe the evaluation setting; they do not establish a managed production service or a reliability guarantee.
Which alerts would lead to a clear action, and which would create noise? What happens when an instance becomes unavailable during a test? Further exploration could examine failure scenarios, recovery expectations, and the relationship between performance signals and the decisions an operator needs to make.
A calmer way to keep the whole team moving.