Split View: AWS Well-Architected Framework 완전 가이드 2025: 6개 기둥, 실전 적용, 비용/보안/성능

AWS Well-Architected Framework Complete Guide 2025: Six Pillars, Practical Adoption, Cost/Security/Performance

TL;DR

• Six Pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability.
• Trade-offs: No system can satisfy every pillar 100%. Decide based on business priorities.
• Well-Architected Tool: Free self-assessment inside the AWS Console.
• Sustainability (added 2021): Considers environmental impact — efficient code equals less carbon.
• Applicable to any cloud: It is an AWS framework, but the principles hold on GCP/Azure too.

1. What Is the Well-Architected Framework?

1.1 Background

After reviewing tens of thousands of customer architectures, AWS distilled its findings into a best-practice guide. It started with five pillars; Sustainability was added in 2021, making six.

1.2 The Six Pillars (2025)

1.3 General Principles

Five principles that apply to every pillar:

1. Measure, don't guess — data-driven decisions.
2. Test at production scale — staging is not production.
3. Increase experimentation with automation — manual work equals human error.
4. Allow evolutionary architectures — nothing built once lasts forever.
5. Improve operations through game days — chaos engineering.

2. Pillar 1: Operational Excellence

2.1 Core

"The ability to run and monitor systems to deliver business value and to continually improve supporting processes and procedures."

2.2 Design Principles

1. Operations as code — codify infra, policy, and procedure.
2. Small, frequent changes — big deployments are risky.
3. Continuously refine procedures — retros, runbook updates.
4. Anticipate failure — map failure modes.
5. Learn from every operational failure — postmortems.

2.3 Practical Checklist

Plan:

• Business objectives are explicit?
• Success measured by metrics?
• Operational priorities defined?

Prepare:

• All infra managed as IaC (CloudFormation/Terraform)?
• CI/CD pipeline in place?
• Monitoring and alerting configured?

Operate:

• Runbooks current?
• Clear on-call procedures?
• Incident response times measured?

Evolve:

• Regular retrospectives?
• Chaos engineering drills?
• Metrics-driven improvement?

2.4 AWS Tools

• CloudFormation / CDK — IaC.
• Systems Manager — automation (runbooks, patching).
• CloudWatch — monitoring, alerting.
• X-Ray — distributed tracing.
• Config — resource change tracking.

3. Pillar 2: Security

3.1 Core

"Protect data, systems, and assets while delivering business value through risk assessments and mitigation strategies."

3.2 Design Principles

1. Implement a strong identity foundation — IAM, MFA, least privilege.
2. Apply security at all layers — defense in depth.
3. Encrypt data at rest and in transit — encryption everywhere.
4. Keep people away from data — prefer automation.
5. Prepare for security events — incident response plan.
6. Understand the shared responsibility model — AWS secures the cloud, you secure what is in it.

3.3 IAM Best Practices

BAD: use the root account
BAD: access keys inside code
BAD: wildcard (*) permissions
BAD: shared users

GOOD: MFA for every user
GOOD: role-based access (IAM Roles)
GOOD: least-privilege principle
GOOD: Access Analyzer
GOOD: temporary credentials via STS

3.4 Data Protection

At rest:

• S3: default SSE-S3, or SSE-KMS.
• EBS: enable default encryption.
• RDS: KMS-managed keys.
• DynamoDB: always encrypted (default).

In transit:

• TLS 1.2+ mandatory.
• Encrypt intra-VPC traffic (service mesh, mTLS).
• VPN / Direct Connect.

3.5 Network Security

[Public Subnet]    <- Internet Gateway
    |
[Private Subnet]   <- NAT Gateway (egress only)
    |
[Isolated Subnet]  <- DB only, no internet

Security Group vs. NACL:

• Security Group: instance-level, stateful.
• NACL: subnet-level, stateless.

3.6 AWS Security Tools

4. Pillar 3: Reliability

4.1 Core

"The ability of a workload to perform its intended function correctly and consistently."

4.2 Design Principles

1. Automatically recover from failure — auto-healing.
2. Test recovery procedures — chaos engineering.
3. Scale horizontally — no single giant instance.
4. Stop guessing capacity — Auto Scaling.
5. Manage change through automation — IaC.

4.3 AWS Availability Model

• Region: geographic area (us-east-1, ap-northeast-2).
• Availability Zone (AZ): isolated datacenter inside a region (3–6 typical).
• Edge Location: CloudFront PoP.

Multi-AZ: spread across AZs to survive single-AZ failure. Multi-Region: spread across regions to survive natural disasters or regional outages.

4.4 Availability Targets

Reality:

• 99.9% is hard on a single instance.
• 99.99% requires Multi-AZ + Auto Scaling.
• 99.999% requires Multi-Region with sophisticated failover.

4.5 Practical Pattern

ELB + Auto Scaling Group + Multi-AZ:

        [Route 53]
            |
       [ALB (multi-AZ)]
       /        |        \
   [EC2 az-a] [EC2 az-b] [EC2 az-c]
       |        |        |
       [RDS Multi-AZ Standby]

• EC2 dies: ASG launches a replacement.
• AZ dies: ALB routes traffic to the remaining AZs.
• Primary RDS dies: automatic failover to standby.

4.6 RTO and RPO

• RTO (Recovery Time Objective): acceptable time until recovery.
• RPO (Recovery Point Objective): acceptable data loss.

Pick the strategy that matches the RTO/RPO the business can absorb.

5. Pillar 4: Performance Efficiency

5.1 Core

"The ability to use computing resources efficiently to meet requirements, and to maintain that efficiency as demand and technology evolve."

5.2 Design Principles

1. Democratize advanced technologies — AI/ML and big data for everyone.
2. Go global — get close to users.
3. Prefer serverless — less operational burden.
4. Experiment more often — comparison tests.
5. Have mechanical sympathy — pick the right tool.

5.3 Compute Choices

5.4 Storage Choices

5.5 Database Choices

5.6 Caching

Layered caching:

1. CloudFront (CDN) — global edge.
2. API Gateway cache — API responses.
3. ElastiCache (Redis) — application cache.
4. DynamoDB DAX — DynamoDB cache.
5. RDS Read Replica — offload read traffic.

Result: response time cut by 90%+, DB load drops dramatically.

6. Pillar 5: Cost Optimization

6.1 Core

"The ability to run systems that deliver business value at the lowest price point."

6.2 Design Principles

1. Implement cloud financial management — FinOps.
2. Adopt a consumption model — pay for what you use.
3. Measure overall efficiency — cost per business metric.
4. Stop spending on undifferentiated heavy lifting — use managed services.
5. Analyze and attribute expenditure — tagging and allocation.

6.3 Pricing Models

Compute (EC2):

• On-Demand: most expensive, most flexible.
• Reserved Instance (1–3 years): up to 75% savings.
• Savings Plans: more flexible commitments.
• Spot: up to 90% savings, interruptible.

Storage (S3):

• Standard: frequent access.
• Standard-IA: infrequent access, ~30% cheaper.
• Glacier: long-term retention, ~95% cheaper.
• Glacier Deep Archive: cheapest, 95%+ cheaper.

6.4 Savings Strategies

1. Right-sizing:

aws compute-optimizer get-ec2-instance-recommendations

Drop an EC2 averaging 50% utilization to a smaller instance.

2. Auto Scaling: contract when traffic is low, expand when it spikes. Cost scales with usage.

3. Spot Instances: ideal for batch and CI/CD workloads, up to 90% off; design for interruption.

4. Reserved Instances / Savings Plans: for steady workloads — roughly 30% savings for a 1-year commit and 60% for 3 years.

5. S3 Lifecycle Policies:

{
  "Rules": [{
    "Id": "MoveToIA",
    "Status": "Enabled",
    "Transitions": [
      { "Days": 30, "StorageClass": "STANDARD_IA" },
      { "Days": 90, "StorageClass": "GLACIER" },
      { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
    ]
  }]
}

6. Cut data transfer cost: same-region transfers are free or cheap; prefer CloudFront over direct S3 egress; use VPC Endpoints to skip NAT Gateway charges.

6.5 Cost Monitoring

6.6 Tagging Strategy

Environment: production
Project: ecommerce
Owner: team-checkout
CostCenter: 1234

Then break down cost by tag in Cost Explorer.

7. Pillar 6: Sustainability (added 2021)

7.1 Core

"Addresses the environmental impact, particularly energy consumption and efficiency."

7.2 Design Principles

1. Understand your impact — where does the carbon come from?
2. Set sustainability goals — measurable targets.
3. Maximize utilization — no idle resources.
4. Adopt more efficient new technology — Graviton, ARM.
5. Use managed services — ride AWS's efficiency.
6. Reduce downstream impact — lighter clients too.

7.3 Sustainability Metrics

• Carbon footprint.
• Energy per user.
• Idle-resource ratio.
• Data-transfer optimization.

7.4 Practical Actions

• Efficient instance types: Graviton (ARM) is roughly 60% more efficient than comparable Intel/AMD.
• Auto Scaling: shut down what you are not using; auto-stop dev environments overnight.
• Object lifecycle: move cold data to cold storage and delete the rest.
• CDN: serve closer to users — fewer network hops, less energy.
• Region selection: favor regions with high renewable-energy ratios; AWS Customer Carbon Footprint Tool helps here.

7.5 AWS Commitments

• 100% renewable energy by 2025.
• Net-zero carbon by 2040.
• Efficient datacenter design.

8. Handling Trade-offs

8.1 Pillars in Tension

• Security vs. Performance: strong crypto has CPU cost; decide by data sensitivity.
• Cost vs. Reliability: Multi-Region doubles cost; decide by SLA.
• Performance vs. Cost: bigger instance, faster and pricier; decide by latency targets.
• Ops Excellence vs. Cost: automation front-loads cost; decide by long-term ROI.

8.2 Decision Framework

For each decision, ask:

1. Business goal — what matters most?
2. Per-pillar impact — which pillars are affected?
3. Trade-off — what are you giving up?
4. Risk — what if it goes wrong?
5. Reversibility — how expensive is changing later?

8.3 Example

Scenario: an e-commerce site serving 1M daily users.

9. Using the Well-Architected Tool

9.1 Free Self-Assessment

In the AWS Console:

1. Define the workload (name, environment, region).
2. Answer ~50 questions across the six pillars.
3. Identify improvement areas.
4. Prioritize.
5. Re-assess after changes.

9.2 Lenses

A Lens is additional guidance specialized for a particular workload or technology.

9.3 Well-Architected Review

Run with an AWS Solutions Architect (free or via a partner):

1. Architecture walk-through.
2. Six-pillar assessment.
3. Prioritized recommendations.
4. Improvement roadmap.

10. Anti-Pattern Catalog

10.1 Operations

• BAD: manual deploys → human error. GOOD: CI/CD pipeline.
• BAD: only local testing. GOOD: production-like environments.
• BAD: no postmortems. GOOD: blameless postmortems.

10.2 Security

• BAD: using the root account. GOOD: IAM users and roles.
• BAD: wildcard permissions. GOOD: least privilege.
• BAD: hard-coded credentials. GOOD: Secrets Manager / Parameter Store.
• BAD: HTTP only. GOOD: enforced HTTPS, HSTS.

10.3 Reliability

• BAD: single-AZ deployment. GOOD: Multi-AZ minimum.
• BAD: no backups or untested restores. GOOD: regular backups with restore drills.
• BAD: single points of failure. GOOD: redundancy across every layer.

10.4 Performance

• BAD: oversized instances for everything. GOOD: workload-appropriate sizing.
• BAD: no caching. GOOD: CloudFront + ElastiCache.
• BAD: everything synchronous. GOOD: async where it fits.

10.5 Cost

• BAD: everything On-Demand. GOOD: mix Reserved / Savings / Spot.
• BAD: no tagging. GOOD: consistent tagging strategy.
• BAD: abandoned resources. GOOD: regular cleanup, Trusted Advisor.

Quiz

References

• AWS Well-Architected Framework
• Well-Architected Tool
• AWS Architecture Center
• AWS Solutions Library
• AWS Customer Carbon Footprint Tool
• Cloud Adoption Framework
• The Twelve-Factor App
• Site Reliability Engineering Book
• AWS This is My Architecture
• AWS Trusted Advisor