AWS Well-Architected Tool이란 무엇일까?

이번에 회사에서 사용중인 AWS 아키텍처의 보안 점검을 위해,
"AWS Well-Architected Tool"이라는 무료 도구를 사용한다는 이야기를 들었다.
생소하여 간단히 조사 및 학습을 해보려고 한다.

해당 글은 대부분 AWS Well-Architected Tool과 AWS Docs 본문의 글을 인용했음을 밝힙니다.

---

AWS Well-Architected Tool이란?

워크로드 상태를 검토하고 AWS 아키텍처 모범 사례와 비교하는 데 도움이 되며,
이 도구는 클라우드 아키텍트가 안전하고, 성능이 뛰어나며, 복원력을 갖춘,
효율적인 애플리케이션 아키텍처를 구축할 수 있도록 개발된 AWS Well-Architected Framework를 기반으로 한다.
AWS 솔루션 아키텍처 팀이 수십만 건의 워크로드 검토를 수행하는 데 사용해 온 이 프레임워크는 고객 및 파트너가 아키텍처를 평가할 수 있는 일관된 접근 방식을 제공하며, 시간이 지나면서 애플리케이션 요구 사항에 따라 확장되는 디자인을 구현하는 데 도움이 되는 지침을 제공한다.

워크로드 란?

고객 대면 애플리케이션이나 백엔드 프로세스 같이 비즈니스 가치를 창출하는 리소스 및 코드 모음 또는
주어진 기간에 시스템에 의해 실행되어야 할 작업의 할당량을 의미

출처: https://velog.io/@jch9537/%ED%95%9C-%EC%A4%84-%EC%9A%A9%EC%96%B4-Workload%EB%9E%80

 

---

 

이점

 

1. 무료 설계 지침

- 자유롭게 AWS 아키텍트가 사용하는 모범 사례 및 지식에 액세스 가능
- 워크로드에 대한 일련의 질문에 대답하면, 이 도구에서 클라우드에 맞게 더 나은 워크로드를 구축하는 방법에 대한 단계별 지침과 함께 실행 계획을 제공

 

2. 워크로드를 일관되게 검토

- 클라우드 아키텍처를 검토하고 측정 시, 도움이 되는 단일 도구와 일관된 프로세스를 조직에 제공
- 조직 전체에서 여러 워크로드를 담당하는 경우, 이 도구를 사용하여 워크로드의 전반적인 상태를 모니터링하고 잠재적 위험을 파악 가능
- 도구에서 제공하는 결과를 사용하여 개선을 위한 다음 단계를 파악하고, 아키텍처 관련 의사결정을 내리고, 아키텍처 관련 고려 사항을 기업 거버넌스 프로세스에 적용 가능

 

3. 개선 사항 파악 및 구현

- 워크로드 수명 주기 전체에서 지속적 개선을 지원 가능
- 손쉽게 특정 시점의 마일스톤을 저장하고 워크로드 변경 사항을 추적 가능
- 원할 때마다 새로운 검토 프로세스를 시작하여 시간이 지남에 따라 아키텍처가 계속해서 개선되도록 할 수 있음

 

---

 

작동 방식

출처: AWS Well-Architected Tool 작동 방식

1단계: 워크로드 정의

- 워크로드는 정적 웹 사이트와 같이 단순하거나 다수의 데이터 스토어 와 많은 구성 요소가 있는 마이크로서비스 아키텍처 와 같이 복잡한 것일 수 있음

 

2단계: 아키텍처 검토 시행

- 일련의 기본 질문에 답하여 현재 AWS 모범 사례를 기준으로 워크로드를 검토

 

3단계: 모범 사례 적용
- 워크로드에서 발견된 문제 목록과 개선을 위한 단계별 지침을 제공

 

데이터 스토어 란?

데이터 스토어(data store)는 데이터베이스같은 저장소뿐 아니라 단순 파일, 이메일 등의 더 단순한 스토어 타입들을 포함하는, 데이터 컬렉션들을 영속적으로 저장하고 관리하기 위한 저장소이다.

출처: https://ko.wikipedia.org/wiki/%EB%8D%B0%EC%9D%B4%ED%84%B0_%EC%8A%A4%ED%86%A0%EC%96%B4

마이크로서비스 아키텍처 란?

마이크로서비스 아키텍처(주로 마이크로서비스라고도 함)란 애플리케이션 개발을 위한 아키텍처 스타일을 의미합니다. 마이크로서비스를 사용하면 대규모 애플리케이션을 각각 담당 영역을 가진 소규모의 독립적인 구성요소로 구분할 수 있습니다. 마이크로서비스 기반 애플리케이션은 단일 사용자 요청을 처리하기 위해 여러 내부 마이크로서비스를 호출하여 응답을 작성할 수 있습니다.

출처: https://cloud.google.com/learn/what-is-microservices-architecture?hl=ko

---

 

그러면 모범 사례에는 어떤 것들이 있을까?

확인해보니 AWS Well-Architected Tool의 기반이 되는 AWS Well-Architected Tool Framework의 모범 사례는 5가지 부문으로 구성이 되어 있었다.

 

---

 

1. 운영 우수성

정의

 

클라우드의 운영 우수성에는 4가지 모범 사례 영역이 있다.

          조직, 준비, 운영, 개선

- 조직의 경영진이 비즈니스 목표를 결정
- 조직은 요구 사항과 우선순위를 파악 및 비즈니스 성과를 실현할 수 있도록 업무를 구성하고 수행
- 워크로드에서 이를 지원하는 데 필요한 정보를 생성해야 함
- 워크로드의 통합, 배포 및 제공하는 서비스를 구현 시, 반복 프로세스를 자동화하여 운영환경에 유익한 변경 사항을 지속해서 적용 가능
- 워크로드 운영에 내재한 위험이 있다면 파악 후 정보에 근거하여 운영 환경에 적용 여부를 결정해야 함
- 팀에서 워크로드를 지원할 수 있어야 함
- 원하는 비즈니스 성과에서 도출된 비즈니스 및 운영 지표를 통해 워크로드 상태, 운영 활동, 인시던트 에 대한 대응 능력을 파악 가능
- 우선순위는 비즈니스 요구 사항과 비즈니스 환경 변화에 따라 달라지며, 이를 피드백 루프로 활용하여 조직과 워크로드 운영을 지속적으로 개선

인시던트 란?

서비스의 정상적인 수행을 방해하거나 품질을 저하 시키는 이벤트를 말합니다.

출처: https://www.bespinglobal.com/guide-for-incident-management/

 

 

설계 원칙

 

클라우드의 운영 우수성에는 5가지 설계 원칙이 있다.

코드를 통한 운영
- 애플리케이션 코드를 위해 사용하였던 엔지니어링 원칙을 클라우드에서 인프라를 포함한 환경에 적용 가능
- 클라우드에서는 전체 워크로드(애플리케이션, 인프라)를 코드로 정의하고 코드와 함께 업데이트할 수 있고 운영 절차를 코드로 구현하고 이벤트에 대응하여 이를 트리거하면 실행을 자동화할 수 있음
- 코드로 운영을 수행하면 인적 오류가 제한되고 이벤트에 대한 일관된 대응이 가능

 

자주 발생하고 되돌릴 수 있는 사소한 변경 내용 적용
- 요소를 정기적으로 업데이트할 수 있도록 워크로드를 설계하고, 실패할 경우 되돌릴 수 있는 작은 증분으로 변경 내용을 적용
- 가능하면 고객에게 영향을 주지 않도록 함

 

수시로 운영 절차 수정
- 운영 절차를 사용할 때 개선할 여지가 있는지 확인
- 워크로드가 개선되면 절차도 적절하게 개선
- 정기적인 게임 데이 를 설정하여 모든 절차가 효과가 있으며 팀이 이러한 절차에 친숙한지 여부를 검토하고 검증

 

실패 예측
- "사전 분석(pre-mortem)" 연습을 수행하여 잠재적인 실패 소스를 식별하고 이를 해소하거나 완화할 수 있도록 함
- 실패 시나리오를 테스트하고 그에 따른 영향을 이해했는지 여부를 검증
- 응답 절차를 테스트하여 효과가 있는지, 팀이 이 실행 단계에 친숙한지 확인
- 정기적인 게임 데이 를 준비하여 시뮬레이션된 이벤트에 대한 팀의 대응 및 워크로드를 테스트

모든 운영상 실패로부터 학습
- 모든 운영상 이벤트 및 실패로부터 파악한 내용을 통해 개선
- 팀 전반 및 조직 전체에서 파악한 내용을 공유

 

게임 데이 란?

전 아마존 직원 제시 로빈스(Jesse Robbins)가 처음 시작한 이 모범 사례는 컴퓨팅 용량 계획 및 준비를 검증하고 필요한 모든 운영 방식이 예상대로 작동하는지 확인하기 위한 테스트 이벤트입니다.
시뮬레이션 중 이슈가 있는 경우, 팀이 문제를 빨리 식별하고 신속하게 해결하고 과정에서 문제 해결을 훈련시키는 데 도움이됩니다. 또한, 장애 조치 및 복구 기능을 테스트하고 숨어있는 잠재된 결함을 노출 할 수 있습니다. 게임 데이는 각 서비스팀이 확장 과정(페이지 뷰, 주문 등)를 이해하도록 돕고 테스트 할 수있는 기회를 제공합니다.

출처: https://aws.amazon.com/ko/blogs/korea/prime-day-2017-powered-by-aws/

 

---

 

2. 보안

정의

 

클라우드의 보안에는 6가지 모범 사례 영역이 있다.

          보안, Identity and Access Management, 탐지, 인프라 보호,

          데이터 보호, 인시던트 대응

 

- 워크로드를 설계하기 전에 보안에 영향을 미치는 업무의 수행 방식을 마련해야 함
- 작업을 수행할 수 있는 대상 및 작업 내용을 제어할 수 있어야 함
- 보안 사고를 식별하고 시스템과 서비스를 보호하며 데이터 보호를 통해 데이터의 기밀성과 무결성을 유지할 수 있어야 함
- 보안 사고에 대응하기 위한 잘 정의된 프로세스를 마련하고 숙련해야 함
- 금전적 손해 방지 또는 규제 의무 준수 등 목표 달성을 뒷받침하는 중요한 도구이자 기법
- AWS 책임공유모델 은 클라우드를 채택한 고객의 보안 및 규정 준수 목표를 이루는데 도움을 줌
- 클라우드 서비스를 뒷받침하는 인프라를 AWS가 물리적으로 보호해 주기 때문에 AWS 고객들은 서비스를 이용하여 목표를 달성하는 데 집중 가능
- AWS 클라우드에서는 보안 데이터에 더 폭넓게 액세스할 수 있으며 보안 이벤트에 대한 응답도 자동화되어 있음

AWS 책임공유모델 이란?

AWS의 책임공유모델은 시설과 관련된 물리적 보안, 컴퓨팅, 스토리지, 네트워크, 가상화 레이어 등에 대한 것은 AWS가 책임소재를 가져가며, 그 윗단의 네트워크 구성과 보안 그룹, OS 방화벽, OS, 애플리케이션, 서비스 인증 및 계정관리 등의 부분을 고객이 책임지는 형태다.

컨테이너 환경에서의 책임공유모델은 기반 서비스(NW, 컴퓨팅, 스토리지)와 API 엔드포인트, OS, 플랫폼, 애플리케이션을 AWS가 담당하며, 그 윗단의 고객 데이터와 데이터 보안, 방화벽, IAM(사용자, 그룹, 역할, 정책)을 고객이 책임지게 된다.

출처 : http://www.itdaily.kr/news/articleView.html?idxno=102643

 

 

설계 원칙

 

클라우드에는 7가지 보안 설계 원칙이 있다.

강력한 자격 증명 기반 구현
- 권한을 최소화한 보안 주체를 구현하고 AWS 리소스와의 각 상호 작용에 대한 적절한 권한을 부여하여 업무를 분리
- 자격 증명 관리를 중앙 집중화하고 장기적인 정적 자격 증명에 대한 의존도를 해소하는 것이 목표

추척 기능 활성화
- 실시간으로 환경에 대한 작업 및 변경 사항을 모니터링하고 알림을 전송하며 감사
- 로그 및 지표 수집을 시스템과 통합하여 자동으로 조사하고 조치

모든 계층에 보안 적용
- 여러 보안 제어 기능을 통해 심층 방어 방식을 적용
- 모든 계층(예: 네트워크 엣지, VPC, 로드 밸런싱, 모든 인스턴스 및 컴퓨팅 서비스, 운영 체제, 애플리케이션, 코드)에 적용

보안 모범 사례의 자동 적용
- 자동화된 소프트웨어 기반의 보안 메커니즘은 더욱 빠르게 안전한 확장 능력을 향상 시켜주며 비용 효율적
- 버전 제어가 가능한 템플릿에서 코드로 정의 및 관리되는 제어 기능의 구현을 비롯한 보안 아키텍처를 생성

전송 및 보관 중인 데이터 보호
- 데이터를 민감도 수준으로 분류하고 적절한 경우 암호화, 토큰화 및 액세스 제어와 같은 메커니즘을 사용

사람들이 데이터에 쉽게 액세스할 수 없도록 유지
- 데이터의 직접 액세스 또는 수동 처리의 필요성을 줄이거나 없애기 위한 메커니즘 및 도구를 사용
- 도구를 사용하여 민감한 데이터를 처리할 때 잘못된 취급이나 수정 및 수작업으로 인한 오류의 위험을 줄임

보안 이벤트에 대비
- 조직의 요구 사항에 부합하는 인시던트 관리 및 조사 정책과 프로세스를 마련하여 인시던트에 대비
- 인시던트 대응 시뮬레이션을 실행하고 자동화된 도구를 사용하여 감지, 조사 및 복구 속도를 높임

 

---

 

3. 안정성

정의

 

클라우드의 안정성에는 4가지 모범 사례 영역이 있다.

          기반, 워크로드 아키텍처, 변경 관리, 장애 관리

- 안정성을 달성하려면 기반에서 시작해야 함
- 기반은 서비스 할당량과 네트워크 토폴로지 로 워크로드를 수용하는 환경을 의미
- 분산 시스템의 워크로드 아키텍처는 장애를 예방하고 완화하도록 설계
- 워크로드는 수요 또는 요구 사항의 변경을 처리해야 하며, 장애를 감지하고 자동으로 복구되도록 설계

 

토폴로지 란?

토폴로지(영어: topology, 문화어: 망구성방식)는 컴퓨터 네트워크의 요소들(링크, 노드 등)을 물리적으로 연결해 놓은 것, 또는 그 연결 방식을 말한다.

출처: https://ko.wikipedia.org/wiki/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC_%ED%86%A0%ED%8F%B4%EB%A1%9C%EC%A7%80

 

 

설계 원칙

 

클라우드에는 5가지 안정성 설계 원칙이 있다.

장애 자동 복구
- 워크로드의 KPI(핵심 성능 지표)를 모니터링하면 임계값이 위반될 때 자동화를 트리거할 수 있음
- KPI는 서비스의 기술적 측면이 아닌 비즈니스 가치에 기반한 측정한 값이어야 함
- KPI를 모니터링하면 장애 추적 및 자동 알림을 지원하고, 자동화된 복구 프로세스에 따라 장애 지점을 우회하거나 복구 가능
- 정교한 자동화를 구현할 경우 장애가 발생하기 전에 예측하여 해결 가능

복구 절차 테스트
- 온프레미스 환경에서 테스트는 워크로드가 특정 시나리오에서 작동하는 것을 증명하기 위해 시행
- 일반적으로 복구 전략을 검증하기 위해 테스트하지 않음
- 클라우드에서는 워크로드의 장애 과정을 테스트하고 복구 절차를 검증 가능
- 자동화를 사용하여 다양한 장애를 시뮬레이션하거나 이전에 장애로 이어졌던 시나리오를 재현 가능
- 이 접근 방식은 장애 경로를 노출한 후 실제 장애 시나리오가 발생하기 전에 테스트 후 수정하여 위험을 줄일 수 있음

수평적 확장으로 워크로드 전체 가용성 증대
- 단일의 큰 리소스를 다수의 작은 리소스로 대체하여 단일 장애가 전체 워크로드에 미치는 영향을 축소
- 요청을 더 작은 리소스 여러 개로 분산시키면 단일 장애 지점을 회피 가능

용량 추정 불필요
- 워크로드에 대한 수요가 해당 워크로드의 용량을 넘어서는 리소스 포화 상태는 온프레미스 워크로드에서 흔히 발생하는 장애의 원인(서비스 거부 공격의 대상)
- 클라우드에서는 수요 및 워크로드 사용량을 모니터링하고 리소스 추가 또는 제거를 자동화하여 프로비저닝 과다 또는 부족 현상없이 최적의 수준으로 수요를 충족 가능
- 클라우드에도 제한은 있지만 할당량을 어느 정도 제어하고 관리 가능

자동화 변경 사항 관리
- 인프라 변경은 자동화를 통해 수행
- 자동화 변경을 통하여 인프라를 관리해야 하며 이후에 이러한 변경을 추적하고 검토 가능

온프레미스 란?

온프레미스(on-premise)는 소프트웨어 등 솔루션을 클라우드 같이 원격 환경이 아닌 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식을 말한다.

출처: http://wiki.hash.kr/index.php/%EC%98%A8%ED%94%84%EB%A0%88%EB%AF%B8%EC%8A%A4

 

---

 

4. 성능 효율성

정의

 

클라우드의 성능 효율성에는 4가지 모범 사례 영역이 있다.

          선택의 폭, 검토, 모니터링, 절충

- 고성능 아키텍처 구축 시, 데이터 기반 접근 방식을 취함
- 개괄적 설계부터 리소스 유형 선택 및 구성에 이르는 아키텍처의 모든 측면에 대한 데이터를 수집
- 정기적으로 선택 사항을 검토함으로써 계속 진화하는 AWS 클라우드를 최대한 활용 가능
- 모니터링을 수행하면 예상 성능과의 차이를 확인 가능
- 압축 또는 캐싱을 사용하거나 일관성 요구 사항을 완화하는 등의 절충을 통해 아키텍처를 설계하면 성능을 개선 가능

 

 

설계 원칙

 

클라우드에는 5가지 성능 효율성 설계 원칙이 있다.

고급 기술의 대중화
- 팀에서 고급 기술을 손쉽게 구현할 수 있도록 복잡한 태스크를 클라우드 공급업체에 위임
- IT 팀에 새로운 기술의 호스팅 및 실행에 대해 알아볼 것을 요청하는 대신 기술을 서비스 형태로 사용하는 것을 고려해 보는 것도 하나의 방법(ex, NoSQL DB, 미디어 트랜스코딩 및 기계 학습 등)
- 클라우드에서는 이러한 기술이 팀에서 사용할 수 있는 서비스 형식으로 제공되므로 팀은 리소스 프로비저닝 및 관리가 아닌 제품 개발에 집중 가능

몇 분 만에 전 세계에 배포
- 전 세계의 여러 AWS 리전에 워크로드를 배포하면 최소한의 비용으로 지연 시간을 줄이고 고객 경험을 개선 가능

서버리스 아키텍쳐 사용
- 서버리스 아키텍처에서는 물리적 서버를 실행하고 유지 관리하지 않고도 기존의 컴퓨팅 활동을 수행 가능
- 예를 들어 서버리스 스토리지 서비스를 정적 웹 사이트로 사용하고(웹 서버 불필요) 이벤트 서비스를 통해 코드를 호스팅 가능
- 이렇게 하면 물리적 서버 관리로 인한 운영 부담이 없어짐
- 이러한 관리형 서비스는 클라우드 규모에서 운영되므로 트랜잭션 비용을 절감 가능

실현 횟수 증가
- 자동화할 수 있는 가상 리소스를 활용하면 여러 가지 인스턴스, 스토리지 또는 구성에 대한 비교 테스트를 신속하게 수행 가능.

기계적 동조 고려
- 클라우드 서비스가 어떻게 사용되는지 파악하고 항상 워크로드 목표에 가장 부합하는 기술 접근 방식을 사용
- 예를 들어 데이터베이스 또는 스토리지 접근 방식을 선택할 때는 데이터 접근 패턴을 고려

 

---

 

5. 비용 최적화

정의

 

클라우드의 비용 최적화에는 5가지 모범 사례 영역이 있다.

          클라우드 재무 관리 시행, 지출 및 사용량 인식, 비용 효율적인 리소스,
          수요 관리 및 리소스 공급, 시간 경과에 따른 최적화

- Well-Architected 프레임워크의 다른 원칙과 마찬가지로 비교 분석을 통해 하나를 선택
- 예를 들어 출시 시간에 최적화할지 아니면 비용에 최적화할지 선택
- 선결제 비용 최적화에 투자하는 것보다 출시 시간을 단축하거나 새로운 기능을 배포하거나 단순히 납기를 준수하는 등 속도를 가장 높일 수 있도록 최적화하는 것이 가장 좋은 경우도 있음
- 데이터를 고려하지 않고 급하게 설계 결정이 내려지는 경우도 있으며, 가장 비용 최적화된 구축 벤치마킹에 시간을 쓰기보다 “만약을 대비해” 과잉 지출을 하려는 유혹은 항상 존재
- 과잉 지출 시, 배포가 과다하게 프로비저닝되고 제대로 최적화되지 않을 수 있음
- 하지만 온프레미스 환경에서 클라우드로 리소스를 그대로 이전한 후에 최적화를 수행해야 하는 경우에는 이러한 방식을 선택해야 함
- 사전에 비용 최적화 전략에 적당한 노력을 들여 모범 사례를 일관적으로 준수하고 불필요한 오버프로비저닝을 방지하면 클라우드의 경제적 이점을 더 빨리 실현 가능

 

 

설계 원칙

 

클라우드에는 5가지 비용 최적화 설계 원칙이 있다.

클라우드 재무 관리 구현
- 클라우드에서 재정적 성공을 거두고 비즈니스 가치 실현을 가속화하려면 클라우드 재무 관리/비용 최적화에 투자가 필요
- 조직이 이 새로운 기술 및 사용 관리 영역에서 역량을 쌓기 위해서는 시간과 리소스를 할애해야 함
- 보안 또는 운영 우수성 역량과 마찬가지로 지식 강화, 프로그램, 리소스 및 프로세스를 통해 역량을 쌓아 비용 효율적인 조직이 되어야 함

소비 모델 도입
- 정교한 예측 기능을 사용하지 않아도 필요한 컴퓨팅 리소스에만 비용을 지불하고 비즈니스 요구 사항에 따라 사용량을 늘리거나 줄임
- 예시, Dynamo DB 스케줄링으로 EC2가 사용되는 시간에만 기동

전반적인 효율성 측정
- 워크로드의 비즈니스 결과 및 워크로드 제공과 관련된 비용을 측정
- 측정을 통해 늘어난 성과와 절감한 비용으로 얻을 수 있는 이익을 확인 가능

획일적인 업무 부담에 대한 비용 지출 중단
- 서버를 랙에 설치하고 쌓아 올리고 서버에 전원을 공급하는 등의 힘든 데이터 센터 운영 작업을 AWS가 처리
- 관리형 서비스를 통해 운영 체제 및 애플리케이션을 관리하는 운영 부담을 줄임

비용 분석 및 기여도 파악
- 클라우드를 사용하면 손쉽게 시스템의 사용량과 비용을 정확하게 식별할 수 있어 개별 워크로드 소유자가 IT 비용에 대한 투명한 기여도를 확인 가능
- ROI(투자 대비 수익률)를 측정할 수 있으며 워크로드 소유자는 리소스를 최적화하고 비용을 절감하는 기회를 경험 가능

 

---

 

글을 보기 좋게 정리했지만, 내용이 방대하여 일부만 기재하였다.

정리하면서 느낀 거지만 클라우드를 사용하는 입장에서 아직도 아무 생각 없이 기능 구현에만 매달렸다는 느낌을 여실히 받게 되었다.

 

실제로 사용을 해본다면 더욱 유익한 소개글이 됐을텐데 아쉽다.

 

은사님 말씀이 떠오른다.

 

          제대로 알아본 다음에 일해라

 

 

---

더 많은 내용을 보시려면 아래를 참고하세요.

---

Reference

https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/the-five-pillars-of-the-framework.html

https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/userguide/intro.html

https://aws.amazon.com/ko/well-architected-tool/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc

 

 

블로그의 다른 글

• https://developer-syubrofo.tistory.com/125

AWS도 로그인 시 OTP를 쓸 수 있다? AWS MFA에 대해서 알아보자

• https://developer-syubrofo.tistory.com/126

미 사용 AWS key-pairs 를 정리하는 방법

• https://developer-syubrofo.tistory.com/130

boto3 라이브러리로 미 사용중인 AWS EBS를 알아보자.

• https://developer-syubrofo.tistory.com/131

미 사용 AWS EC2 보안 그룹은 어떻게 확인할까?