A web page might appear as a single unified service, yet every response relies on multiple interdependent tiers: networking, compute web servers, databases, configuration stores, and object storage. This project diagram isolates those layers to make request pathways and failure domains transparent.
This article discusses the architectural design presented in the diagram rather than a post-incident operational report. No automated failover tests, uptime SLAs, or raw benchmark metrics can be claimed from an architectural diagram alone.
Reading the primary request path
The request flow travels from the user to Amazon CloudFront, continues to the Application Load Balancer (ALB), routes to EC2 web servers, and interacts with Amazon RDS. The diagram spans a VPC across two Availability Zones (AZs). Each AZ contains a public subnet for EC2 instances, while the Multi-AZ RDS instance resides securely within private subnets.
- CloudFront acts as the edge distribution layer. Cacheable static assets are served directly from edge locations; dynamic or authenticated responses require precise cache policies and header forwarding.
- ALB receives forwarded traffic from CloudFront, monitors target health, and distributes requests to healthy EC2 instances. In this pattern, the ALB must be provisioned across subnets in at least two AZs.
- EC2 runs the application or web server software. The Auto Scaling Group in the diagram indicates a minimum of 1 and a maximum of 2 instances.
- RDS Multi-AZ provides transactional relational storage with an active standby replica in an alternate AZ for automated failover. The standby in a Multi-AZ DB instance is not an active read replica for distributing queries.
AWS explains how ALBs evaluate target health across multiple AZs and the structural differences between primary and standby instances in Multi-AZ RDS.
The lifecycle of a single request
Consider a user loading a page that displays structured records and an attached media file. This walkthrough illustrates potential system interactions; the diagram does not prescribe specific endpoint paths or application frameworks.
- The client browser dispatches an HTTPS request to CloudFront. For static assets that rarely change, cache policies minimize origin hits. Pages tied to user identity must employ strict cache bypass rules to ensure private responses are never served to other clients.
- CloudFront routes cache-miss or dynamic requests to the ALB origin. For public-facing ALBs, access should be restricted via custom secret headers or AWS WAF so origin traffic cannot bypass CloudFront.
- The ALB evaluates target health checks and forwards the request to a healthy EC2 instance. Health checks must reflect genuine application readiness rather than just an active OS process.
- The EC2 application queries or mutates data via the RDS database endpoint. When requests require media assets, EC2 accesses S3. When application secrets or parameters are needed, EC2 retrieves them from Parameter Store under an attached IAM role.
- The response travels back through the ALB and CloudFront to the browser. Only safe, non-sensitive responses should be cached at the edge.
AWS architectural guides on restricting ALB access to CloudFront demonstrate patterns for internet-facing origins. ALB and RDS address fundamentally different failure scenarios: ALB balances around unhealthy application targets, whereas RDS executes automated database failover when primary health degrades.
Two AZs are insufficient when minimum capacity is set to one
The diagram depicts EC2 compute spanning two AZs, yet the Auto Scaling Group specification indicates minimum 1, maximum 2. With only one active instance, the workload runs in a single AZ at any given moment. Should that AZ experience disruption, Auto Scaling must provision, boot, and register a replacement in the alternate AZ before traffic can be served. Hence, spanning two AZs on paper does not guarantee zero-downtime resilience.
For genuine multi-AZ availability, a production baseline requires at least one healthy instance actively running in each AZ, with sufficient headroom to absorb load if one AZ fails. Minimum, desired, and maximum counts, instance sizing, and dynamic scaling policies must reflect real traffic profiles. AWS details how Auto Scaling balances instances across AZs and how upper thresholds limit scale-out capacity.
Multi-AZ RDS mitigates catastrophic database loss during primary hardware failure, but failover is not instantaneous. Applications must gracefully handle broken connection pools, execute safe transaction retries, and reconnect to the database endpoint. RDS failover documentation highlights that failover duration varies based on replication lag and crash recovery.
Networking architecture and supporting service access
In the diagram, EC2 web servers reside in public subnets while RDS is in private subnets. A public subnet route table directs 0.0.0.0/0 to an Internet Gateway; this does not automatically expose instances unless public IPs and permissive security groups are assigned. For hardened implementations, EC2 should be placed in private subnets with the ALB remaining as the public ingress. Outbound connectivity from private subnets is then mediated via NAT Gateways or AWS VPC endpoints. See VPC route table configurations.
Security groups must enforce strict chaining: ALB to EC2 ingress, and EC2 to RDS database ports. Web servers should never accept direct internet traffic when routed through an ALB. For S3 and Parameter Store, IAM instance profiles with least-privilege roles must be utilized instead of static IAM credentials. Read and write permissions should strictly scope to explicit ARNs.
Sensitive parameters should use the SecureString type encrypted via AWS KMS. Permissions to read and decrypt parameters must align precisely with the application role. Details are documented in Parameter Store access controls and SecureString KMS encryption.
Operational readiness beyond the diagram
The architectural diagram captures data paths and storage layouts. Deployment pipelines, metric alarms, audit trails, and cost budgets are omitted; yet all must be designed before running in production. A diagram alone does not prove operational instrumentation.
For practical deployment, CI/CD pipelines should run automated linting, preview Infrastructure as Code changes, apply updates using short-lived credentials, and run post-deployment smoke tests. Operationally, healthy host counts, ALB 5xx errors, EC2 CPU thresholds, and RDS connection spikes must trigger alarms. CloudWatch can publish alarm notifications via SNS.
CloudTrail audits management plane API calls and infrastructure mutations, while AWS Budgets alerts when usage crosses forecast thresholds. Neither replaces principle-of-least-privilege or chaos engineering. AWS documentation differentiates CloudTrail auditing from budget alert configurations.
Verification checklist before claiming high availability
- Run at least two healthy instances across two AZs, terminate one instance, and verify that user requests succeed without interruption while the replacement provisions.
- Simulate a complete single-AZ failure and measure remaining compute headroom, error rates, latency spikes, and time to recovery. Ensure Auto Scaling maximum limits do not throttle required scale-out.
- Trigger an RDS failover and observe how application connection pools handle reconnects and transaction retries. Measure recovery time against product RTO and RPO objectives.
- Audit health check thresholds, CloudFront cache headers, direct ALB access rules, security group chains, IAM instance policies, CloudWatch alarms, and cost expenditures once infrastructure is running.
This architecture outlines a web topology with redundant tiers, but true high availability is an engineered and rigorously tested system property, not a default guarantee derived from cloud service brand names. The diagram provides the foundation for sizing per-AZ capacity, testing automated database failover, enforcing network isolation, and validating operational resilience.dikonfigurasi dan diuji, bukan hasil yang otomatis muncul dari nama layanan. Diagram menjadi titik awal untuk menilai kapasitas per AZ, pemulihan database, keamanan jaringan, dan respons operasional secara terukur.