Source and image handling.

The case study is based on the 2016ICT Cloud Architecture & Administration revised final reports dated 9 and 18 October 2026. Its nine published images are selected from embedded report figures. They retain the original technical evidence while cropping unrelated areas and covering account, instance, endpoint and other identifying fields with opaque redactions. No screenshot was reconstructed or generated. The full reports and raw images are not published.

Each figure on the case-study page identifies its report figure, explains what is visible, and opens a full-resolution copy of the publication-safe image.

What the captures establish.

The original architecture diagram describes the intended two-VPC design; route-table and Flow Log captures provide more specific configuration and traffic evidence. The snapshot capture shows an available pre-migration snapshot. The database capture shows Multi-AZ enabled and public access disabled, but not a tested failover. The reports record 214 rows before and after restoration; the published snapshot image is not itself a post-restore query.

Figure 32 in the 18 October report is a genuine browser capture of /query2.php returning country, population and urban-population rows at an ALB hostname. It supports a successful query in that moment, not continuous availability or the internal network path by itself.

Auto Scaling activity shows a policy-triggered increase from two to four instances under a temporarily lowered 2% CPU target. A separate activity history shows successful replacement after an instance was terminated. Neither screenshot is a final ALB target-health listing, and the adjusted load test is not a throughput benchmark for the normal 50% policy.

What remains uncertain.

The request-loop capture includes HTTP 502 and 504 responses among HTTP 200 responses. The available screenshots do not provide a synchronised termination and response timeline, so the cause of those errors is unknown. They do not establish uninterrupted service or a precise outage duration. The reports say two healthy targets were restored, but the published replacement-activity image does not independently prove final target health.

The 9 October report had unfinished placeholders for Figures 20 and 32. In the 18 October report, Figure 32 is a completed browser-query capture. Figure 20, however, reuses the Figure 19 ALB configuration image and does not show target-group health. A pre-failure target-health capture elsewhere in the report does not verify the final state. No substitute health evidence was invented, and no AWS environment was rerun for this portfolio article.

Academic scope.

This was an AWS Academy Learner Lab deployment, not a production security review. It used HTTP, a single NAT Gateway and an Academy-provided IAM role. Database Multi-AZ was configured but no direct RDS failover test is documented. A future validation pass would need a final target-health capture, a synchronised failure-test timeline, TLS and access-control review.