[클라우드 활용 포트폴리오] AWS 아키텍처 기초 설계 실습

1. 학습 개요

이번 포트폴리오는 클라우드 활용 9주차 강의자료를 바탕으로, AWS 클라우드 아키텍처의 기본 개념과 좋은 아키텍처를 설계하기 위한 핵심 조건을 정리한 글이다.

지금까지의 블로그 글에서는 EC2, S3, VPC, IAM, WAF, GuardDuty 등 AWS의 주요 서비스를 개별적으로 학습하고 실습했다. EC2는 서버를 실행하는 컴퓨팅 서비스이고, S3는 데이터를 저장하는 객체 스토리지이며, VPC는 네트워크를 구성하는 기반 서비스이다. IAM은 권한을 관리하고, WAF와 GuardDuty는 보안을 강화하는 역할을 한다.

이번 9주차에서는 이러한 개별 서비스를 단순히 따로 사용하는 것이 아니라, 어떻게 조합하여 하나의 안정적인 시스템 구조를 설계할 것인가에 초점을 맞추었다. 즉, AWS 아키텍처는 단순히 서비스를 많이 사용하는 것이 아니라, 각 서비스의 역할을 명확히 나누고 서로 안전하고 효율적으로 연결하는 설계 과정이라고 이해할 수 있다.

이번 글에서는 다음 내용을 중심으로 정리한다.

• 아키텍처의 개념
• 클라우드 아키텍처가 중요한 이유
• AWS Well-Architected Framework의 6가지 핵심 요소
• AWS 아키텍처의 기초 구성 요소
• 간단한 웹 서비스 아키텍처 설계 예시
• 아키텍처 설계 실습 과정
• 실습 중 발생할 수 있는 문제점과 해결 방안
• 9주차 학습 후기

---

2. 아키텍처란 무엇인가?

아키텍처란 시스템을 구성하는 요소와 그 요소들 사이의 관계, 배치, 흐름을 정의하는 설계도이다.

건축에서 설계도가 중요한 것처럼, IT 시스템에서도 아키텍처 설계는 매우 중요하다. 건물을 지을 때 기둥, 벽, 배관, 전기 설비, 출입구의 위치를 제대로 설계하지 않으면 유지보수 비용이 증가하고 안전 문제가 발생할 수 있다. 마찬가지로 클라우드 시스템에서도 서버, 데이터베이스, 스토리지, 네트워크, 보안 요소를 제대로 설계하지 않으면 장애 위험이 커지고 운영 비용이 증가할 수 있다.

클라우드 아키텍처는 다음과 같은 질문에 답하는 과정이다.

• 사용자는 어떤 경로로 서비스에 접근하는가?
• 웹 서버는 어디에 배치할 것인가?
• 데이터베이스는 외부에 공개할 것인가, 내부망에 둘 것인가?
• 정적 파일은 어디에 저장할 것인가?
• 장애가 발생했을 때 어떻게 복구할 것인가?
• 트래픽이 증가하면 어떻게 확장할 것인가?
• 비용을 줄이기 위해 어떤 리소스를 선택할 것인가?
• 보안 사고를 탐지하기 위해 어떤 로그와 모니터링을 사용할 것인가?

즉, 아키텍처는 단순한 그림이 아니라 시스템이 안정적으로 동작하기 위한 전체 구조와 운영 방식을 정의하는 설계이다.

---

3. 클라우드 아키텍처가 중요한 이유

클라우드에서는 서버나 스토리지를 빠르게 생성할 수 있다. 하지만 리소스를 쉽게 만들 수 있다는 점이 곧 좋은 시스템을 의미하지는 않는다. 오히려 계획 없이 리소스를 생성하면 비용 증가, 보안 취약점, 장애 발생, 관리 복잡성 증가로 이어질 수 있다.

예를 들어 EC2 인스턴스를 하나 생성하고 웹 서비스를 배포하는 것은 비교적 간단하다. 하지만 실제 운영 환경에서는 다음과 같은 추가 고려가 필요하다.

• 서버가 장애 나면 어떻게 복구할 것인가?
• 사용자가 많아지면 서버를 어떻게 확장할 것인가?
• 데이터베이스를 외부에서 직접 접근하지 못하게 하려면 어떻게 해야 하는가?
• 정적 파일은 EC2 내부에 둘 것인가, S3에 둘 것인가?
• 관리자는 어떤 IP에서만 서버에 접속할 수 있어야 하는가?
• 비용이 과도하게 발생하지 않도록 어떤 리소스를 선택해야 하는가?
• 로그와 지표를 어디서 확인할 것인가?

따라서 클라우드 아키텍처는 단순히 서비스를 연결하는 것이 아니라, 운영, 보안, 장애 대응, 성능, 비용, 지속 가능성까지 함께 고려하는 설계 작업이다.

---

4. 좋은 아키텍처의 6가지 요건

AWS에서는 좋은 클라우드 아키텍처를 설계하기 위해 AWS Well-Architected Framework를 제시한다. 9주차 강의자료에서도 좋은 아키텍처의 핵심 요소로 다음 6가지를 정리했다.

요소설명

운영 우수성	시스템을 안정적으로 운영하고 지속적으로 개선하는 능력
보안성	데이터와 시스템을 무단 접근, 변조, 파괴로부터 보호하는 능력
신뢰성	장애가 발생해도 복구하고 서비스를 지속하는 능력
성능 효율성	필요한 자원을 적절히 사용하여 빠르게 처리하는 능력
비용 최적화	필요한 만큼만 자원을 사용하여 비용을 효율화하는 능력
지속 가능성	클라우드 워크로드 운영 시 환경적 영향을 최소화하는 능력

이 6가지 요소는 서로 독립적인 것이 아니라 함께 고려되어야 한다. 예를 들어 보안성을 높이기 위해 모든 접근을 막아버리면 운영 편의성이 떨어질 수 있고, 비용을 줄이기 위해 너무 작은 인스턴스를 사용하면 성능과 신뢰성이 낮아질 수 있다. 따라서 좋은 아키텍처는 여러 조건 사이에서 균형을 잡는 과정이라고 볼 수 있다.

---

5. 운영 우수성

운영 우수성은 시스템을 안정적으로 운영하고, 장애나 변경 사항을 빠르게 파악하며, 지속적으로 개선할 수 있는 능력이다.

운영 우수성을 높이기 위해서는 다음과 같은 요소가 필요하다.

• 운영 절차 문서화
• 반복 작업 자동화
• 로그와 지표 기반 모니터링
• 장애 발생 시 원인 분석 가능
• 배포와 변경 이력 관리
• 운영 결과를 바탕으로 지속 개선

예를 들어 EC2 서버를 운영할 때 CPU 사용률, 네트워크 사용량, 디스크 사용량을 CloudWatch로 모니터링하면 시스템 상태를 빠르게 파악할 수 있다. 또한 반복적인 배포 작업을 스크립트나 자동화 도구로 처리하면 사람의 실수를 줄일 수 있다.

운영 우수성은 단순히 “문제가 생기면 복구하는 능력”이 아니라, 문제가 생기기 전에 관찰하고, 문제가 발생했을 때 원인을 빠르게 찾고, 이후 같은 문제가 반복되지 않도록 개선하는 과정이다.

CloudWatch

---

6. 보안성

보안성은 시스템, 데이터, 애플리케이션을 무단 접근이나 변조, 파괴로부터 보호하는 능력이다. 클라우드 환경에서는 보안을 하나의 장비나 설정으로 해결하는 것이 아니라, 여러 계층에서 방어하는 방어 심층(Defense in Depth) 개념이 중요하다.

보안성을 높이기 위한 주요 원칙은 다음과 같다.

• 최소 권한 원칙 적용
• IAM 사용자와 역할 분리
• 루트 계정 사용 최소화
• MFA 적용
• 보안 그룹에서 필요한 포트만 허용
• DB 서버는 프라이빗 서브넷에 배치
• S3 퍼블릭 액세스 신중히 관리
• CloudTrail, GuardDuty 등을 통한 보안 이벤트 추적
• WAF를 통한 웹 공격 차단

예를 들어 웹 서버는 퍼블릭 서브넷에 배치하고, 데이터베이스는 프라이빗 서브넷에 배치하는 구조가 보안성이 높은 기본 설계이다. 사용자는 웹 서버에 접근할 수 있지만, 데이터베이스에는 직접 접근할 수 없기 때문이다.

또한 SSH나 RDP 같은 관리용 포트는 전체 인터넷에 공개하지 않고, 본인의 IP로 제한해야 한다. IAM 권한도 모든 권한을 주는 것이 아니라, 사용자가 실제로 필요한 작업만 수행할 수 있도록 제한해야 한다.

---

7. 신뢰성

신뢰성은 장애가 발생하더라도 시스템이 복구되고 서비스를 지속할 수 있는 능력이다. 클라우드에서는 장애가 발생하지 않는 환경을 만드는 것보다, 장애가 발생해도 빠르게 복구할 수 있는 구조를 만드는 것이 중요하다.

신뢰성을 높이는 방법은 다음과 같다.

• 여러 가용 영역에 리소스 분산
• Auto Scaling을 통한 인스턴스 자동 확장
• Load Balancer를 통한 트래픽 분산
• 데이터 백업 및 복구 계획 수립
• RDS Multi-AZ 구성
• S3 버전 관리 및 수명 주기 정책 활용
• 장애 발생 시 자동 복구 구조 설계

예를 들어 EC2 인스턴스를 하나만 사용하면 해당 인스턴스에 장애가 발생했을 때 서비스가 중단될 수 있다. 하지만 여러 가용 영역에 EC2 인스턴스를 배치하고 Load Balancer로 트래픽을 분산하면 특정 인스턴스에 문제가 생겨도 다른 인스턴스가 요청을 처리할 수 있다.

따라서 신뢰성 있는 아키텍처는 단일 장애 지점을 줄이고, 장애 발생 시 빠르게 복구할 수 있도록 설계되어야 한다.

---

8. 성능 효율성

성능 효율성은 자원을 낭비하지 않으면서 필요한 성능을 제공하는 능력이다. 클라우드에서는 필요한 성능에 맞게 인스턴스 타입, 스토리지, 데이터베이스, 네트워크 구성을 선택할 수 있다.

성능 효율성을 높이기 위한 방법은 다음과 같다.

• 워크로드에 맞는 EC2 인스턴스 타입 선택
• 정적 파일은 S3와 CloudFront를 활용
• 데이터베이스 읽기 부하가 크면 읽기 복제본 고려
• 캐싱을 활용해 응답 속도 개선
• Auto Scaling으로 트래픽 증가에 대응
• CloudWatch 지표를 기반으로 병목 구간 분석

예를 들어 이미지, CSS, JavaScript 같은 정적 파일을 EC2 서버에서 직접 제공하면 서버 부하가 커질 수 있다. 이러한 파일은 S3에 저장하고 CloudFront를 통해 배포하면 EC2 서버의 부담을 줄이고 사용자에게 더 빠르게 콘텐츠를 제공할 수 있다.

성능 효율성은 단순히 높은 사양의 서버를 사용하는 것이 아니라, 서비스 특성에 맞는 리소스를 적절하게 선택하는 것이다.

---

9. 비용 최적화

비용 최적화는 필요한 만큼만 리소스를 사용하고, 불필요한 비용을 줄이는 능력이다. 클라우드는 사용한 만큼 비용을 지불하는 구조이기 때문에, 리소스를 생성한 뒤 방치하면 비용이 계속 발생할 수 있다.

비용 최적화를 위해 고려할 점은 다음과 같다.

• 사용하지 않는 EC2 인스턴스 종료
• EBS 볼륨과 스냅샷 정리
• S3 스토리지 클래스 선택
• 장기 워크로드에는 Savings Plans 또는 예약 인스턴스 고려
• 테스트 환경에는 필요한 시간만 인스턴스 실행
• AWS Budgets로 비용 알림 설정
• Cost Explorer로 서비스별 비용 분석
• Auto Scaling으로 과도한 리소스 상시 운영 방지

예를 들어 실습용 EC2 인스턴스를 Stop 상태로만 두면 서버 실행 비용은 줄어들 수 있지만, EBS 볼륨 비용은 계속 발생할 수 있다. 따라서 실습이 끝난 뒤에는 인스턴스 종료뿐만 아니라 EBS 볼륨, 스냅샷, Elastic IP까지 함께 확인해야 한다.

비용 최적화는 단순히 가장 싼 리소스를 고르는 것이 아니라, 워크로드의 특성과 사용 패턴에 맞는 리소스를 선택하는 과정이다.

---

10. 지속 가능성

지속 가능성은 클라우드 워크로드 운영 시 환경적 영향을 최소화하는 능력이다. 클라우드 시스템도 결국 컴퓨팅 자원을 사용하므로, 불필요한 리소스를 줄이고 효율적으로 운영하는 것이 중요하다.

지속 가능성을 높이기 위한 방법은 다음과 같다.

• 사용하지 않는 리소스 삭제
• 필요한 만큼만 컴퓨팅 자원 사용
• Auto Scaling을 통한 과잉 프로비저닝 방지
• 서버리스 서비스 활용
• 데이터 수명 주기 정책 적용
• 중복 저장 데이터 정리
• 적절한 리전과 서비스 선택

예를 들어 항상 켜둘 필요가 없는 작업은 EC2 대신 Lambda 같은 서버리스 서비스를 사용할 수 있다. 또한 오래된 로그나 백업 데이터는 S3 수명 주기 정책을 통해 저비용 스토리지 클래스로 이동하거나 삭제할 수 있다.

지속 가능성은 비용 최적화와도 연결된다. 불필요한 리소스를 줄이면 비용도 줄고, 동시에 자원 낭비도 줄일 수 있다.

---

11. AWS 아키텍처의 기초 요소

AWS 아키텍처를 설계할 때는 여러 서비스가 각각 어떤 역할을 하는지 이해해야 한다. 9주차 강의자료에서는 AWS 아키텍처의 기초 요소를 컴퓨팅, 스토리지, 네트워크, 데이터베이스, 보안, 모니터링 및 로깅으로 정리했다.

요소설명AWS 서비스 예시

컴퓨팅	애플리케이션 실행	EC2, Lambda
스토리지	데이터 저장	S3, EBS, EFS
네트워크	자원 연결 및 트래픽 분산	VPC, Load Balancer, Route 53
데이터베이스	구조화된 데이터 저장	RDS, DynamoDB
보안	접근 제어 및 데이터 보호	IAM, WAF, GuardDuty
모니터링 및 로깅	시스템 상태 추적	CloudWatch, CloudTrail

좋은 아키텍처는 이 요소들이 각각의 역할에 맞게 배치되고 연결되어야 한다. 예를 들어 웹 애플리케이션을 설계한다면 EC2 또는 Lambda가 컴퓨팅을 담당하고, S3가 정적 파일 저장을 담당하며, RDS가 데이터베이스 역할을 맡을 수 있다. VPC는 네트워크를 구성하고, IAM과 보안 그룹은 접근을 제어하며, CloudWatch와 CloudTrail은 운영 상태와 API 활동을 추적한다.

---

12. 기본 웹 서비스 아키텍처 설계 예시

9주차 내용을 바탕으로 간단한 웹 서비스 아키텍처를 설계하면 다음과 같다.

사용자
→ Route 53
→ CloudFront
→ AWS WAF
→ Application Load Balancer
→ Public Subnet의 EC2 Web Server
→ Private Subnet의 RDS Database

정적 파일:
S3 Bucket → CloudFront로 배포

보안:
IAM, Security Group, WAF, GuardDuty

모니터링:
CloudWatch, CloudTrail

이 구조에서 각 서비스의 역할은 다음과 같다.

구성 요소역할

Route 53	도메인 이름을 서비스 주소로 연결
CloudFront	전 세계 사용자에게 빠르게 콘텐츠 제공
AWS WAF	웹 공격 요청 필터링
Application Load Balancer	여러 EC2 인스턴스로 트래픽 분산
EC2	웹 애플리케이션 실행
RDS	애플리케이션 데이터 저장
S3	이미지, CSS, JS 등 정적 파일 저장
VPC	네트워크 격리 및 서브넷 구성
Security Group	인스턴스 단위 접근 제어
IAM	사용자와 서비스 권한 제어
CloudWatch	지표와 로그 모니터링
CloudTrail	API 호출 기록 추적
GuardDuty	이상 행위 탐지

이 아키텍처의 핵심은 역할 분리이다. 웹 서버와 데이터베이스를 같은 위치에 두지 않고, 외부 접근이 필요한 리소스와 내부에서만 접근해야 하는 리소스를 분리한다. 또한 정적 파일은 S3에 저장하여 EC2의 부담을 줄이고, WAF와 보안 그룹으로 보안 계층을 추가한다.

---

13. 아키텍처 설계 실습 과정

13.1 실습 목적

이번 실습의 목적은 AWS 서비스를 개별적으로 이해하는 것을 넘어, 하나의 웹 서비스가 어떤 구조로 배치되어야 하는지 아키텍처 관점에서 설계해보는 것이다.

특히 다음 조건을 고려하여 설계했다.

• 사용자가 인터넷에서 웹 서비스에 접속할 수 있어야 한다.
• 웹 서버는 외부 요청을 받을 수 있어야 한다.
• 데이터베이스는 외부에 직접 노출되지 않아야 한다.
• 정적 파일은 별도 스토리지에 저장해야 한다.
• 보안 그룹과 IAM을 통해 접근 권한을 제한해야 한다.
• 로그와 지표를 통해 운영 상태를 확인할 수 있어야 한다.
• 비용이 과도하게 증가하지 않도록 실습용 리소스를 선택해야 한다.

---

13.2 실습 구성

실습에서는 다음과 같은 기본 구조를 설계했다.

영역구성

네트워크	VPC, Public Subnet, Private Subnet
컴퓨팅	EC2 Web Server
스토리지	S3 Bucket
데이터베이스	RDS 또는 데이터베이스 배치 구조 설계
보안	IAM Role, Security Group
모니터링	CloudWatch
로그 추적	CloudTrail
추가 보안	WAF, GuardDuty

 

---

13.3 실습 단계 1: VPC 구조 설계

먼저 VPC를 중심으로 네트워크 구조를 설계했다. VPC는 AWS 리소스를 배치하는 가상 네트워크이므로, 아키텍처의 기본이 된다.

설계 예시는 다음과 같다.

항목설정 예시

VPC CIDR	10.0.0.0/16
Public Subnet	10.0.1.0/24
Private Subnet	10.0.2.0/24
Internet Gateway	Public Subnet 인터넷 연결
NAT Gateway	Private Subnet의 아웃바운드 인터넷 접근
Route Table	Public/Private 용도별 분리

Public Subnet에는 외부 접근이 필요한 웹 서버나 로드 밸런서를 배치하고, Private Subnet에는 데이터베이스처럼 외부 노출을 피해야 하는 리소스를 배치하는 구조로 설계했다.

VPC 생

---

13.4 실습 단계 2: EC2 웹 서버 배치

다음으로 EC2 인스턴스를 웹 서버 역할로 배치했다. EC2는 사용자의 요청을 처리하는 컴퓨팅 계층이다.

EC2를 Public Subnet에 배치하면 인터넷에서 직접 접근할 수 있지만, 실제 운영 환경에서는 Application Load Balancer를 앞단에 두고 EC2는 필요한 포트만 열어두는 방식이 더 안전하다.

보안 그룹은 다음과 같이 설계했다.

유형포트소스

HTTP	80	0.0.0.0/0
HTTPS	443	0.0.0.0/0
SSH	22	내 IP

관리용 SSH 포트를 전체 인터넷에 열지 않고 내 IP로 제한함으로써 보안성을 높였다.

EC2 생성

보안그룹 인바운드 규칙

---

13.5 실습 단계 3: S3 정적 파일 저장소 설계

웹 서비스에서 이미지, CSS, JavaScript 같은 정적 파일을 EC2 내부에 저장하면 서버 부하가 증가할 수 있다. 따라서 정적 파일은 S3 버킷에 저장하는 구조로 설계했다.

S3를 정적 파일 저장소로 사용하면 다음과 같은 장점이 있다.

• EC2 서버의 저장 공간 부담 감소
• 정적 파일 관리 용이
• CloudFront와 연동하여 빠른 콘텐츠 배포 가능
• 수명 주기 정책을 통한 비용 최적화 가능

단, S3 버킷을 공개할 때는 퍼블릭 액세스 설정과 버킷 정책을 신중하게 관리해야 한다. 공개가 필요한 객체만 읽기 권한을 부여하고, 민감한 데이터는 절대 퍼블릭으로 열지 않아야 한다.

S3 버킷 생성

 

---

13.6 실습 단계 4: 데이터베이스 계층 설계

데이터베이스는 외부 인터넷에 직접 노출되면 안 되므로 Private Subnet에 배치하는 구조로 설계했다. 예를 들어 RDS를 사용하는 경우, Publicly accessible 옵션을 비활성화하고 Private Subnet에 배치하는 것이 안전하다.

DB 보안 그룹은 웹 서버 보안 그룹에서 오는 트래픽만 허용하도록 설계할 수 있다.

유형포트소스

MySQL/Aurora	3306	Web Server Security Group
PostgreSQL	5432	Web Server Security Group

이렇게 하면 외부 사용자는 데이터베이스에 직접 접근할 수 없고, 웹 서버만 데이터베이스와 통신할 수 있다.

---

13.7 실습 단계 5: 모니터링 및 로그 설계

아키텍처를 설계할 때 모니터링과 로깅은 반드시 포함되어야 한다. 시스템이 정상적으로 동작하는지, 장애가 발생했을 때 어디서 문제가 생겼는지 파악하기 위해 필요하다.

실습에서는 다음 서비스를 모니터링 및 로그 계층으로 정리했다.

서비스역할

CloudWatch	CPU 사용률, 네트워크 사용량, 로그 확인
CloudTrail	AWS API 호출 기록 추적
GuardDuty	이상 행위 탐지
AWS Budgets	비용 초과 알림

예를 들어 EC2 인스턴스의 CPU 사용률이 일정 기준을 넘으면 CloudWatch Alarm을 통해 알림을 받을 수 있다. CloudTrail을 사용하면 누가 어떤 API를 호출했는지 확인할 수 있어 보안 사고 분석에도 도움이 된다.

cloudwatch

cloudtrail

 

---

14. 실습 중 문제점 및 해결 방안

14.1 문제점 1: 퍼블릭 서브넷과 프라이빗 서브넷의 차이를 처음에 혼동함

처음에는 Public Subnet과 Private Subnet의 차이를 단순히 이름의 차이로 생각했다. 하지만 실제로는 라우팅 테이블에 인터넷 게이트웨이로 향하는 경로가 있는지 여부가 핵심이었다.

Public Subnet은 라우팅 테이블에 다음 경로가 있어야 한다.

Destination: 0.0.0.0/0
Target: Internet Gateway

반면 Private Subnet은 인터넷 게이트웨이로 직접 향하는 경로가 없어야 하며, 필요할 경우 NAT Gateway를 통해 아웃바운드 통신만 가능하게 구성한다.

해결 방안으로는 각 서브넷에 연결된 라우팅 테이블을 직접 확인하고, Public Subnet과 Private Subnet을 역할에 따라 분리했다.

---

14.2 문제점 2: 보안 그룹을 너무 넓게 열 위험이 있었음

처음에는 접속 테스트를 편하게 하기 위해 SSH 포트를 0.0.0.0/0으로 열 수 있다고 생각했다. 하지만 이는 전 세계 모든 IP에서 접속 시도가 가능하다는 뜻이므로 보안상 위험하다.

해결 방안으로 SSH나 RDP 같은 관리용 포트는 반드시 내 IP로 제한했다. 웹 서비스에 필요한 HTTP, HTTPS 포트만 외부에 공개하고, 관리 포트는 최소한으로 열어두는 방식으로 수정했다.

---

14.3 문제점 3: 비용과 신뢰성 사이의 균형을 고려해야 했음

좋은 아키텍처를 만들기 위해 여러 가용 영역, Load Balancer, NAT Gateway, RDS Multi-AZ 등을 모두 사용하면 신뢰성은 높아진다. 하지만 실습 계정에서는 비용이 증가할 수 있다.

따라서 실습에서는 실제 운영 환경의 권장 구조와 비용 절감형 실습 구조를 구분해서 생각했다.

구분운영 환경실습 환경

고가용성	Multi-AZ 구성	단일 AZ로 구조 이해
트래픽 분산	Load Balancer 사용	EC2 단일 인스턴스로 테스트
DB	RDS Multi-AZ	구조만 설계하거나 최소 사양 사용
NAT Gateway	사용 가능	비용 고려하여 필요 시만 사용
모니터링	CloudWatch, CloudTrail, GuardDuty	기본 지표와 로그 중심 확인

이 과정을 통해 아키텍처 설계는 무조건 많은 서비스를 사용하는 것이 아니라, 목적과 비용에 맞게 적절한 수준을 선택해야 한다는 점을 배웠다.

---

15. 9주차 학습 정리

9주차 학습을 통해 AWS 아키텍처는 단순한 서비스 목록이 아니라, 여러 서비스가 역할에 맞게 연결된 전체 시스템 구조라는 점을 이해했다.

아키텍처는 서버, 데이터베이스, 스토리지, 네트워크, 보안, 모니터링 요소가 어떻게 배치되고 연결되는지를 정의한다. 좋은 아키텍처는 운영 우수성, 보안성, 신뢰성, 성능 효율성, 비용 최적화, 지속 가능성을 함께 고려해야 한다.

이번 주차에서 가장 중요하게 느낀 점은 다음과 같다.

핵심 개념정리

아키텍처	시스템 구성 요소와 관계, 흐름을 정의하는 설계
운영 우수성	모니터링, 자동화, 문서화, 지속 개선
보안성	최소 권한, 네트워크 분리, 다중 방어 계층
신뢰성	장애 발생 시 복구 가능한 구조
성능 효율성	워크로드에 맞는 자원 선택
비용 최적화	필요한 만큼만 사용하고 불필요한 리소스 제거
지속 가능성	자원 낭비를 줄이고 효율적으로 운영
AWS 기초 요소	컴퓨팅, 스토리지, 네트워크, DB, 보안, 모니터링

---

16. 학습 후기

 이번 9주차 학습을 통해 AWS 서비스를 개별적으로 사용하는 것과, 여러 서비스를 조합하여 하나의 아키텍처로 설계하는 것은 다르다는 점을 알게 되었다.

 이전 실습에서는 EC2 인스턴스를 만들고, S3 버킷을 생성하고, IAM 권한을 설정하고, VPC와 보안 그룹을 구성하는 식으로 각각의 서비스를 따로 학습했다. 하지만 실제 클라우드 시스템은 이 서비스들이 서로 연결되어 동작한다. EC2는 VPC 안의 서브넷에 배치되고, 보안 그룹을 통해 접근이 제어되며, S3는 정적 파일 저장소로 사용될 수 있고, RDS는 Private Subnet에 배치되어 웹 서버에서만 접근하도록 구성할 수 있다.

 또한 좋은 아키텍처는 단순히 “잘 동작하는 구조”가 아니라는 점도 배웠다. 운영하기 쉬워야 하고, 보안적으로 안전해야 하며, 장애가 발생해도 복구 가능해야 한다. 성능도 충분해야 하지만 비용이 과도하게 증가해서는 안 되고, 불필요한 자원 낭비도 줄여야 한다.

특히 Public Subnet과 Private Subnet을 나누는 이유, 보안 그룹에서 관리용 포트를 내 IP로 제한해야 하는 이유, CloudWatch와   CloudTrail 같은 모니터링·로깅 서비스가 필요한 이유를 아키텍처 관점에서 다시 이해할 수 있었다.

이번 학습을 바탕으로 앞으로 AWS 기반 서비스를 설계할 때는 단순히 EC2나 S3를 생성하는 데서 끝내지 않고, 전체 시스템 구조를 먼저 생각한 뒤 각 서비스의 역할을 명확히 나누어 설계하고자 한다. 또한 Well-Architected Framework의 6가지 관점을 기준으로 내가 설계한 구조가 운영, 보안, 신뢰성, 성능, 비용, 지속 가능성 측면에서 적절한지 점검하는 습관을 가지려고 한다.