[Udemy][day-43] Section19 : AWS 모니터링 및 감사: CloudWatch, X-Ray 및 CloudTrail - 2

#AWS Certified Developer Associate

 

(12.27 시작)

 

232. 엑스레이 개요

프로덕션 환경에서 디버깅을 할때 (the good old way) :

- 로컬에서 테스트

- 어디에서든 로그 문장을 추가해서

- 프로덕션 환경에서 다시 배포 - 로그를 통해 오류를 찾아내 다시 배포

다른 애플리케이션에서 로깅을 실행하면 CloudWatch 는 다른 모든 형식을 가져 인사이트를 중앙화 하기 어렵고 CloudWatch 로그 탐색도 어려워져서 분석하기도 어려워짐

'모놀리스(Monolith)' : 거대한 애플리케이션이 모두 처리해 쉽게 디버깅할 수 있고 분산된 서비스를 사용하면 aws 계정에서 수백개의 마이크로 서비스를 실행 - 강사가 악몽이라고 함

전체 아키텍처나 서비스맵을 한번에 볼 수 없음 - 이때 AWS X-Ray 를 사용

 

AWS X-Ray

visual analysis of our applicaations (애플리케이션에 관한 시각적 분석을 제공)

클라이언트가 애플리케이션에 요청을 보내면 요청이 얼마나 실패하고 실패하지 않는지 확인함, 그리고 애플리케이션에서 어떤 역할을 하는지 확인함

 

AWS X-Ray advantages

애플리케이션 성능 트러블 슈팅 - 병목 현상 식별

마이크로서비스 아키텍처의 종속성을 이해할 수 있음 - 모든 마이크로 서비스가 서로 어떻게 상호 작용하는지 시각적으로 확인할 수 있기 때문

pinpoint service issues (어떤 서비스가 문제인지 찾아낼 수 있음)

각 요청의 동작을 이해할 수 있음

요청을 기반으로 오류와 예외를 찾을 수 있음

지연시간이나 요청처리시간 측면에서 SLA 시간을 충족하는지 확인 가능

어떤 서비스가 속도를 늦추고 스로틀하는지 확인 가능

오류의 영향을 받는 사용자도 파악할 수 있음

 

X-Ray compatibility (호환성)

- AWS Lambda

- Elastic Beanstalk

- ECS

- ELB

- API Gateway

- EC2 Instance or any pllication server (even on premise)

 

AWS X-Ray Leverages Tracing

추적은 요청을 따르는 방식 (tracing is an end to end way to following a "request")

애플리케이션 서버에 요청을 보내면 요청을 처리하는 각 구성 요소는 자체 추적(trace)을 추가하게 됨

추적은 세그먼트로 구성되고 세그먼트는 서브세그먼트로 구성됨

발생한 일에 관한 추가 정보를 제공하기 위해 추적에 주석을 추가하는 것

이를 통해 모든 요청 및 샘플 요청을 추적할 수 있음 (ex - 전체 요청에 관한 백분율만 확인, 분당 5개의 요청만 확인 등)

X-Ray Security : 

- IAM 인증 사용

- 미사용 데이터 암호화에는 KMS 사용

 

AWS X-Ray how to enable it?

• 코드(java, python, go, node.js, .net) 에 aws x-ray sdk 포함

코드 수정은 거의 하지 않지만 약간의 수정이 필요

x-ray sdk will then capture:

- call to aws service

- http/https requests

- dayabase calls

 

• install x-ray deamon or enable x-ray aws intergration

데몬은 저용량 udp 패킷 인터셉터의 역할을 하는 작언 프로그램이다

aws lambda / other aws services already run the x-ray daemon for you

각 애플리케이션은 x-ray 에 데이터 작성을 위해 iam 권한을 가져야 함

 

 

X-Ray 는 추적을 전송한느 다른 모든 서비스의 데이터를 수집하고 

서비스 맵은 추적의 모든 세그먼트에서 산출됨

X-Ray 그래프로 기술이 없는 사람도 트러블 슈팅을 할 수 있도록 함

 

 

AWS X-Ray Troubleshooting

EC2 에서 X-Ray 가 실행되지 않는다면

- IAM 역할에 적합한 권한이 있는지 확인해야함

- EC2 인스턴스에서 X-Ray 데몬이 실행되는지 확인해야함

 

to enable on AWS Lambda

- Lamda 가 적합한 정책의 IAM 실행 역할이 있는지 확인해야함

- X-Ray 코드를 가져왔는지도 확인해야함

- AWS Lambda 에서 X-Ray 통합이 활성화 됐는지도 확인해야함

 

 

 

 

233. 엑스레이 실습

실습에 앞서서 리전을 강의와 동일하게 버지니아 북부로 놓고 진행했음

강의에서 말하기를 샘플애플리케이션은 버지니아 북부에서만 돌아간다고 함 (잘모름)

 

애플리케이션 선택

옵션에서 실습은 샘플 애플리케이션으로 한다고 하지만

사용자 애플리케이션일때의 진행을 한번 훑어본다고 함

 

언어 선택

적용할 언어를 선택하면

 

sdk

sdk 를 다운로드하고 미들웨어를 추가할 수 있는 소스코드를 확인할 수 있다

모든 언어가 다 비슷하게 sdk 를 설치하고 적용시킬 코드를 조금만 수정하면 된다고 한다

 

데몬 실행

이후 데몬을 실행해야 하는데

x-ray sdk 가 추적 데이터를 직접적으로 x-ray 에 보내지 않게 한다 - 스로틀을 피하고 싶기 때문이라고 함

 

다시 이전으로 돌아가서 샘플애플리케이션 옵션으로 진행

 

샘플 애플리케이션 시작

위 링크를 클릭해서 애플리케이션 github 에서 코드를 볼 수 있다

샘플 애플리케이션 시작을 누르면 cloudformation 으로 이동한다

 

1단계 스택 생성에서 s3 url 기본값을 그대로 놓고 다음

2단계 스택 세부 정보 지정에서 스택 이름은 기본값 그대로 두고 vpc 는 사용 가능한걸 설정해주고 다음

3단계 스택 옵션 구성 변경사항 없고 다음

 

이후 확인에서

iam 리소스 생성 승인

iam 역할을 cloudformation 에서 생성해주는 것을 승인하라고 나온다

승인 체크 해주고 생성

클라우드 포메이션으로 템플릿 생성이 완료되는데에는 5분 에서 10분이 걸린다고 한다

 

그런데 몇번 해봐도

rollback

흠... no platform named 라는데 뭐지

만질게 스택 이름밖에 없어서 바꿔봐도 안되가지고

그냥 최대한 강의만 들었음

 

앱이 실행되고 beanstalk url 로 들어가면

계속 로그인을 하는 샘플 웹사이트가 열리고

초당 5개의 로그인을 한다고 함

로그인이 36개 쌓이면 중복로그인이 발생하게 되고

x-ray 에서 완료를 누르고 그래프를 볼 수 있다고 한다

 

그래프 맵

ec2 인스턴스와 dynamodb 에서 오류가 발생하고 있는 상황이고

ec2 를 클릭해보면 옆에 서비스 디테일이 표시되는데

응답시간의 평균을 확인할 수 있다고 한다

 

error 를 클릭하고 추적탭으로 들어가면

error-true

error=true 로 추적된 결과를 보면

signup 과 favicon.ico 에서 요류가 발생했는데

signup 은 앱 화면에서 start 버튼을 눌러 발생시킨 중복 로그인 오류이고

favicon 은 애플리케이션 아이콘 사진이 없어서 발생하는 오류라고 한다

signup 으로 들어가보면

 

trace overview

추적 오버뷰 탭으로 이동하게 되고 추적 리스트가 보이게 된다

두가지 id 를 가진 409 에러가 확인되고

여기서 하나를 들어가보면

 

프론트엔드에서 dynamodb 로 요청을 했고 

해당 요청의 post 는 로그인을 위한 post 이다

아래 putitem  으로 항목을 테이블에 입력하는 작업을 수행한다

애플리케이션에서 무슨 일이 벌어지는지 많은 정보를 얻을 수 있다

 

subsegment

서브세그먼트에서 더 자세한 사항을 확인할 수 있다

즉 추적에 관한 자세한 정보를 모두 확인할 수 있다

 

ok 상태인 부분의 trace 탭에 들어가보면

traces

각 부분에서 얼마나 시간이 걸렸고 무슨 활동을 했는지 오른쪽에서 모두 확인할 수 있다

 

aws x-ray 에서는 그래프와 추적(서비스맵)을 볼 수 있고 코드에서 발생한 오류를 탐색할 수 있다

 

 

 

 

234. X-Ray : 계측 및 개념

Instrumentation (계측) : 제품의 성능을 측정하고, 오류를 진단하고 추적 정보를 쓰는 것을 의미함 (소프트웨어 엔지니어링 분야)

- X-Ray 로 애플리케이션을 계측하려면 코드를 수정하여 X-Ray SDK 를 이용해야 함

- SDK 를 사용하는 것은 단지 configuration 만 조금 변경해 주면 된다고 함

- 사용자 정의 추적을 쓰거나, 데이터에 주석을 달거나, X-Ray 가 express 서비스에 보내는 방식을 변경하고 싶을 때 애플리케이션 코드도 수정할 수 있음

 

X-Ray Concepts

Segments - URL에서 볼 수 있는 것들 - 각 애플리케이션과 서비스가 전송함

Subsegment - 세그먼트에서 더 세분화된 사항을 확인

Trace - 모든 세그먼트를 함께 모았을 때 API 호출의 종단 간(end to end) 뷰를 형성함

Sampling - X-Ray 로 보내지는 요청의 양을 줄여 비용을 감소시킬 때 사용함 - 모든 요청이 필요하지 않을 수 있기 때문

Annotations - 주석은 추적을 인덱싱하고 필터와 함께 사용하기 위해 key-value 쌍 데이터를 추가하는 것

Metadata - 메타데이터도 주석과 마찬가지로 key-value pair 이지만 인덱스는 아님

- 주석은 인덱싱되어 필터와 함께 검색할 수 있지만 메타데이터는 인덱싱 되지 않기 때문에 검색에 사용할 수 없다

X-Ray daemon / agent - 여러 계정에 추적을 보내는 config 를 가지고있음

- 이를 위해 iam 권한이 올바른지 확인해야함

- 모든 로깅 및 애플리케이션 추적을 위한 중앙 계정을 만들 수 있음

 

X-Ray Sampling Rules

샘플링 규칙으로 X-Ray 서비스와 레코드에 보내는 데이터의 양을 제어할 수 있음

- X-Ray 에 더 많은 데이터를 보낼수록 더 큰 비용을 지불해야함

코드를 변경하지 않고 샘플링 규칙을 수정할 수 있음

 

기본적으로 샘플링 규칙은 X-Ray SDK 가 매 초 마다 모든 첫 번째 요청을 기록하고 다음 추가 요청의 5%를 기록함

- 매 초(each second) 의 첫번째 요청을 리저버(reservoir) 라고 함 - 이는 서비스가 요청을 처리하는 동안 초당 적어도 하나의 추적이 기록되는 것을 보장함

- 5% 는 비율(rate) 라고 함 - 리저버의 크기를 초과하는 추가 요청을 샘플링함

 

X-Ray Custom Sampling Rules

커스텀하게 샘플링 규칙을 만들 수 있는데 무엇이 리저버고 무엇이 비율인지 정의할 수 있음

ex)

Example Higher minimum rate for POSTs : reservoir - 10 / rate - 0.10

-> 리저버 10 은 초당 10개의 요청이 X-Ray 에 보내진다는 뜻 / rate 0.10 은 10% 로 리저버 제외 다른 요청의 10%가 보내진다는 뜻

 

Example Debugging rule to trace all requests for a problematic route : reservoir - 1, rate 1

-> 모든 요청을 원하기 때문에 리저버랑 비율 둘다 1

- 실제 상황이라면 매우 비쌀 것

 

X-Ray 콘솔에서 샘플링 규칙을 변경한 경우 애플리케이션을 재시작 할 필요는 없다

- 데몬이 자동으로 샘플링 규칙을 얻어 X-Ray 서비스에 올바른 양의 데이터를 보내준다고 함

 

 

 

 

235. X-Ray : 샘플링 규칙

X-Ray 콘솔에서 샘플링으로 들어가서 샘플링 규칙 생성으로 들어가준다

 

create sampling rules

우선순위 는 기본 규칙이 10000으로 되어있고 새로 demosampling 을 만들고 우선순의를 5000으로 해줬다

리저버 크키는 10이고 rate 는 1로 해줬다

애플리케이션 조건에 따라 크기는 자유롭게 설정하면 된다고 한다

 

x-ray 는 서비스 또는 서비스유형으로 자세히 분석이 가능하다고 함

분산 서비스를 실행한다면 꼭 사용해야 하는 서비스라고 함

 

실제로 만들지는 않음

 

 

 

236. X-Ray : API

X-Ray Write APIs (쓰기 API) (used by the X-Ray daemon)

X-Ray 데몬 에서 데이터를 X-Ray 서비스에 쓸 때 사용함

x-ray 쓰기 전용 액세스 관리 정책

- PutTraceSegments : 세그먼트 문서를 AWS X-Ray 에 업로드함

- PutTelemetryRecords : X-Ray 데몬이 수신/거절 세그먼트가 몇개인지, 백앤드 연결 오류와 관련된 정보를 업로드함

- GetSamplingRules : Retrieve all sampling rules (to know what/when to send)

- GetSamplingTargets & GetSamplingStatisticSummaries : advanced (related with sampling rule)

 

 

쓰기 정책에 get 으로 명명된 이유 - X-Ray 콘솔에서 샘플링 규칙을 변경할 때마다 모든 X-Ray 데몬은 자동으로 업데이트 하여 언제 데이터를 X-Ray에 보내야 하는지 알게 됨, 따라서 X-Ray 데몬은 샘플링 규칙이 바뀌는지 알 수 있고 GetSamplingRule 의 권한과 허가가 필요함

 

X-Ray 데몬이 X-Ray 에 쓸때(write) 쓰기 권한이 필요함 (PutTraceSegments, PutTelemetryRecords )

그리고 샘플링 규칙을 가져와야 함 (GetSamplingRules)

이 api 들이 작동하기 위해서는 X-Ray 데몬이 올바른 IAM 정책이 

the x-ray daemon needs to have an IAM plicy authorizing the correct api calls to function correctly - x-ray 데몬이 올바르게 작동하려면 올바른 API 호출을 승인하는 IAM 정책이 있어야 한다고 함

 

X-Ray Read APIs (읽기 API) - continued

읽기를 위한 관련 정책

- GetServiceGraph : 콘솔에서 봤던 메인 그래프를 가져옴

- BatchGetTraces : ID로 지정된 추적 목록을 검색함 - 각 추적(each trace)은 단일 요청(single request)에서 발생하는 세그먼트 문서의 집합

- GetTraceSummary : 추적을 위해 특정 시간에 사용할 수 있는 ID와 주석을 받는다. 전체 추적을 원한다면 이 ID를 배치로 전달하여 추적 api 를 가져옴

- GetTraceGraph : 하나 이상의 특정 추적 ID 와 관련된 서비스 그래프를 검색함

 

 

237. Beanstalk 를 사용한 X-Ray

Beanstalk 플랫폼에는 X-Ray 데몬이 있어서 따로 포함할 필요는 없음

Beanstalk 콘솔에서 한 옵션을 설정함으로 데몬을 실행할 수 있음

또는 ebextensions 파일인 xray-daemon.config 를 만들어서 사용할 수도 있음

이후 EC2 인스턴스에 올바른 IAM 허가가 인스턴스 프로필에 있는지 확인해야함

물론 추적을 전송하기 위해 애플리케이션 코드가 X-Ray SDK 와 함께 계측되어있는지도 확인해야함

다중 도커 컨테이너를 실행할 경우 X-Ray 데몬을 사용자가 관리해야 할 수도 있음

 

 

 

 

238. X-Ray 및 ECS

ECS 에서 X-Ray daemon 을 실행시키는 3가지 방법 

 

• 데몬 자체를 컨테이너로 사용

예를들어 ECS 클러스터에 2개의 EC2 인스턴스가 있음

이 EC2 인스턴스를 관리하고, 데몬작업 - 즉 X-Ray 컨테이너를 실행하려고 함

즉 EC2 인스턴스마다 X-Ray 데몬 컨테이너가 실행됨

X-Ray agnet 가 모든 EC2 인스턴스에서 실행되고 UDP 포트로 X-Ray 데몬을 네트워크 관점에서 히트하기 위해 올바르게 연결한 후에 모든 애플리케이션을 실행할 수 있음

 

• 사이드 카(side car)

각 애플리케이션 컨테이너와 함께 하나의 X-Ray 컨테이너를 실행함 - 네트워크 관점에서 이들이 연결된 것처럼 인식

사이드카 라고 하는 이유는 X-Ray 데몬이 애플리케이션 컨테이너로 나란히(side to side) 실행되기 때문

애플리케이션 컨테이너마다 1개의 사이드카가 있게됨

• Fargate Cluster

ECS 클러스터일뿐 EC2 인스턴스를 제어할 수 없음

X-Ray 데몬 컨테이너를 사용할 수 없고 사이드카 패턴으로 X-Ray 컨테이너를 사용해야 함

 

 

 

 

 

 

239. AWS CloudTrail

CloudTrail 은 AWS 계정에 대한 거버넌스(Governance), 규정 준수 및 감사를 수행함

CloudTrail 은 기본적으로 활성화 되어있음

이는 콘솔, SDK, CLI, 다른 AWS 서비스에서 만들어진 AWS 계정 내 모든 이벤트의 기록과 API 호출을 얻게 해줌

모든 로그는 CloudTrail 에 나타남

또한 로그를 CloudTrail 로 부터 CloudWatch Logs 나 Amazon S3 로 보냄

모드느 리전이나 단일 리전에 적용되는 추적을 만들 수 있음

만약 누군가 aws 계정의 리소스를 삭제했다면, CloudTrail 을 살펴보면 확인할 수 있다

 

CloudTrail Diagram

 

CloudTrail Events

CloudTrail 에는 3종류의 이벤트가 있다고 함

• Management Events (관리 이벤트)

AWS 계정에 있는 리소스에서 수행되는 작업을 의미함

- 예를들어 누군가 보안을 구성할 때마다 IAM AttachRolePolicy 라는 API 코드를 사용하고 이것은 CloudTrail 에서 확인할 수 있음

기본값으로 추적은 어떤 경우에도 관리 이벤트를 기록하도록 구성됨

2종류로 관리 이벤트를 분리 할 수 있음

- 리소스를 수정하지 않는 읽기 이벤트 (ex - IAM 에서 모든 사용자 나열, EC2 에서 기관의 인스턴스를 나열하는 것과 같은 이벤트)

- 리소스를 수정하는 쓰기 이벤트 (ex - 누군가 dynamoDB 테이블을 지우려고 하는 이벤트)

 

• Data Events

기본적으로 분리되어 있음

데이터 이벤트는 로그에 남지 않음 - 대용량 작업이기 때문

GetObject, DeleteObject, PutObject 와 같은 Amazon S3 객체 수준의 활동에서 보이듯이 S3 버킷에서 많이 발생하는 것들

읽기와 쓰기 이벤트를 분리할 수 있음

AWS Lambda 함수 실행 기능 - 즉 누군가가 API 를 호출(Invoke)할 때마다 몇 번의 람다 함수가 호출되었는지 파악할 수 있음

 

• CloudTrail Insights Events

추가설명

 

 

CloudTrail Insights

모든 유형의 서비스에 걸쳐 많은 관리 이벤트가 발생하는 경우 많은 API 가 계정에서 아주 빠르게 발생함

- 이때 어떤 것이 이상하고, 특이한지, 특이하지 않은지 이해하기 힘들 것

CloudTrail Insights 를 활성화(유료) 하면 CloudTrail이 이벤트를 분석하고 계정 내 비정상적인 활동을 찾아냄

    예시 - 부정확한 리소스 프로비저닝, 서비스 제한 초과, aws iam 작업 폭주, 주기적인 유지 보수 활동의 격차 등

동작원리

- CloudTrail 이 정상 관리 활동을 분석하여 기준선을 만듬

- 기준선을 토대로 이벤트가 올바른 유형인지 계속해서 분석함

- 관리 이벤트는 CloudTrail 인사이트를 통해 계속해서 분석됨 - 무언가가 감지될 때 인사이트 이벤트를 생성함

 

이런 이상치, 인사이트 이벤트는 CloudTrail 콘솔에 나타나게 됨

원한다면 S3로 보낼 수 있음

또한 CloudTrail 인사이트 위에서 자동화할 필요가 있는 경우 EventBridge 이벤트, 즉 CloudWatch 이벤트도 만들어짐

 

CloudTrail Events Retention (이벤트 보관)

이벤트는 기본적으로 90일 동안 보관됨

이 기간을 넘어 이벤트를 보관하려면 S3에 로그를 보내야 함 - athena 를 이용하면 분석할 수 있음

 

 

 

 

240. CloudTrail 실습

cloudtrail dashboard

클라우드 트레일 대시보드

trails 를 생성할수도 있고 insights 를 생성할 수도 있다

이벤트 기록에서 최근 이 계정에서 발생한 기록을 확인할 수 있다

 

event history

좌측 메뉴에서 이벤트 기록으로 들어가서 이벤트 이름 - terminateinstances 로 검색해보면 인스턴스가 언제 삭제되었는지 확인해볼 수 있다

위와 같은 키벨류로 여러 이벤트 기록을 확인할수 있나보다

 

이제 새로운 트레일을 생성한다고 함

create new trail

이름은 demotrail 로 하고 trail log 를 저장할 새 버킷을 만들어 줬다

암호화는 demo 여서 disabled 해주고

다음

 

cloudwatch logs

클라우드 워치로 로그를 보낼 수 있는 기능이라고 함

로그그룹도 신규로 만들어주고

로그 그룹 이름은 자동으로 할당된다

IAM 역할도 새로 만들어주고 기본적으로 달리는 이름이 있지만 위와 같이 새로 만들어 주고

태그는 스킵

다음

 

log events

이벤트 유형을 선택할 수 있다

관리 이벤트는 읽기, 쓰기 이벤트가 기본으로 선택되어있고 추가 요금이 적용되지 않는다고 한다

강의에선 없었는데 rds data api 이벤트 제외도 있는걸로 봐서 편의사항으로 패치된듯

아래로

 

data events

데이터 이벤트 유형으로 이벤트 소스를 여러개 선택할 수 있다

강의에서는 s3 랑 lambda 만 있었는데

실제로 확인했을 때는

S3 / Lambda / DynamoDB / S3 Outposts / Managed Blockchain / S3 Object Lambda / Lake Formation 등등 많았다

로그 선택기 템플릿 에서도 readonly, writeonly 를 선택할 수 있고 사용자 지정으로 커스텀하게 만들 수도 있나보다

아래로

 

insights events

강의에선 그냥 위에서 체크하면 활성화 되었다고 나오지만 실제로 실습했을땐 2개의 옵션이 있었다

선택해서 받아볼 수 있나보다

 

데이터 이벤트와 인사이트 이벤트는 추가요금이 발생하므로 다시 체크 해제하고

다음

트레일 생성

 

cloudtrail

s3 버킷과 cloudwatch 로그그룹으로 로그들이 전송될꺼다

 

작동을 확인하기 위해 ec2 콘솔에서 키페어를 생성해본다고 한다

 

새로 만드는건 귀찮아서 안쓰던 키페어를 삭제하는걸로 대신했다

cloudtrail 에 연결한 s3 가 활성화 되는 시간이 필요한가보다

담배하나 피고왔다

 

cloudtrail - event history

클라우드 트레일의 이벤트 기록에서 아까 키페어를 지운 이벤트가 남아있다

 

cloudwatch log event

클라우드워치의 로그 이벤트에서도

이벤트 필터로 검색하면 키페어를 삭제한 기록을 확인할 수 있다

 

s3 bucket

클라우드 트레일에서 새로 생성한 버킷으로 가보면

리전별로 디렉토리가 나눠져있고

삭제한 키페어 리전으로 들어가서

날자에 맞는 디렉토리로 이동하게 되면

다운로드 받을 수 있는 json 파일이 압축해서 저장되어있다

Athena 로 이 기록들을 쿼리할 수 있다고 한다

 

athena

클라우드 트레일 콘솔의 이벤트 기록 탭에서 athena 테이블 생성 버튼을 클릭해서 스토리지 위치를 지정해서 테이블을 생성할 수 있다

테이블 생성

 

이렇게 하고 아테나에서 쿼리를 실행하려는데 버킷을 찾을 수 없다라고 나옴

강의에선 버킷을 새로 지정해줬는데

실습할땐 지정하는 팝업이 나오지 않아서 그냥 넘어갔음

 

 

 

241. CloudTrail vs CloudWatch vs X-Ray

각각 차이점

 

CloudTrail

사용자, 서비스, 또는 AWS 콘솔에서 이루어진 API 호출을 감사하는 것

승인되지 않은 호출을 감지하거나 API 호출로 인한 변경의 근본적인 원인을 찾을 때 사용함

 

CloudWatch

모니터링을 위해 CloudWatch Metrics 를 사용

CloudWatch Logs 로 애플리케이션 로그를 저장함

CloudWatch Alams 으로 예상치 못한 지표(metrics)가 나왔을때 알림(notifications)을 보냄

 

X-Ray

자동화된 추적(trace) 분석과 중앙 서비스 맵 시각화를 해줌

분산 서비스에서 통합하여 관리할 때 사용

디버깅과 X-Ray 콘솔 내 지연, 오류 및 오류분석 같은 항목을 보는데 유용함

분산 시스템 전체에서 추적 요청(request tracking)을 얻을 수도 있음

 

 

 

 

242. AWS 빠른 정리

이전에 만들었던 beanstalk 환경 삭제

codepipeline 삭제

 

끝!