3계층 아키텍처가 AWS에서 고가용성을 달성하는 방법
Source: Dev.to
What High Availability Really Means
High availability refers to the ability of a system to remain operational even when individual components fail. Rather than relying on a single server or a single network path, workloads are distributed across multiple failure domains so that failures do not immediately result in downtime.
In AWS, the primary building block for high availability is the Availability Zone (AZ). Each AZ is physically separate and designed with independent power, cooling, and networking. Deploying across multiple AZs significantly reduces the impact of hardware or data‑center failures.
High availability is not about preventing failures entirely; it is about designing systems that continue to serve traffic when failures inevitably occur.
The 3‑Tier Architecture Concept
A 3‑tier architecture separates an application into three logical layers:
- Presentation tier – handles incoming user traffic.
- Application tier – processes business logic.
- Database tier – stores persistent data.
On AWS, these tiers are typically mapped to different subnets and services inside a VPC. This separation allows traffic and access to be tightly controlled, making the architecture easier to scale, secure, and operate over time.
Presentation Tier (Web Layer)
The presentation tier handles incoming HTTP/HTTPS requests.
- Components: Application Load Balancer (ALB) in public subnets, multiple web servers on EC2 instances or containers.
- Deployment: Across multiple AZs to avoid a single failure domain.
- Health checks: The ALB continuously checks target health and routes traffic only to healthy instances. If an instance or an entire AZ becomes unavailable, traffic is automatically rerouted.
- Exposure: Placed in public subnets, typically exposing ports 80 and 443.
Application Tier (Logic Layer)
The application tier processes business logic and coordinates communication between the web and database layers.
- Placement: Private subnets with no direct internet access.
- Access: Receives requests only from the web tier, often through an internal load balancer.
- High availability: Multiple application instances run across different AZs; Auto Scaling replaces unhealthy instances automatically.
- Benefit: Reduces the overall attack surface and ensures responsiveness during failures or traffic spikes.
Database Tier (Data Layer)
The database tier stores persistent application data and requires the highest level of stability and protection.
- Implementation: Amazon RDS with Multi‑AZ enabled.
- Placement: Private, isolated subnets; inbound access allowed only from the application tier.
- Failover: AWS maintains a standby replica in another AZ; if the primary fails, the standby is promoted automatically, minimizing downtime.
- Security: No outbound internet access; tightly restricted via Security Groups and routing rules.
How Availability Zones Work Together
In a high‑availability 3‑tier architecture, each tier spans multiple AZs, but traffic flows in a strict, predictable order:
- Users access the system through a public load balancer in the web tier.
- Requests are forwarded to the application tier, which processes business logic.
- The application tier communicates with the database tier as needed.
If an entire AZ fails, the load balancer stops routing traffic to that zone. Application instances in healthy zones continue serving requests, and the database layer fails over to its standby replica if required. This layered design provides resilience.
Networking and Traffic Flow
- Public subnets host internet‑facing components (load balancers, web servers).
- Private subnets host internal workloads (application servers, databases).
- Route tables control internet access for each layer.
- Security Groups define allowed communication between tiers.
Traffic flows downward through the tiers in a controlled manner, simplifying troubleshooting and reducing the risk of accidental exposure.
Scaling and Fault Tolerance
High availability is amplified when combined with automated scaling:
- Load balancers distribute traffic evenly.
- Health checks detect failures early.
- Auto Scaling adjusts capacity based on demand and instance health.
Instead of manually fixing failed servers, the system automatically replaces unhealthy resources, reducing downtime and operational overhead.
Common Use Cases
A high‑availability 3‑tier architecture is commonly used for:
- Public‑facing web applications
- Backend APIs with complex business logic
- E‑commerce platforms with strict uptime requirements
These workloads benefit from tier isolation and multi‑AZ deployments to maintain availability during failures.
Design Tips
- Keep each tier in separate subnets.
- Deploy across at least two Availability Zones.
- Use load balancers instead of direct instance access.
- Restrict traffic using Security Groups rather than broad IP ranges.
Conclusion
A high‑availability 3‑tier architecture on AWS combines logical separation, multi‑AZ deployment, and controlled traffic flow. Each tier plays a specific role, and AWS services work together to isolate failures and maintain uptime. With this structure in place, applications can continue serving traffic even when individual components or Availability Zones fail.