AWS - Cloud Formation, VPC Peering, VPC Endpoint

Cloud Formation: AWS안에서만 동작시킬 수 있는 tool   

terraform의 경우 구애받지 X // 근데 사용하다 이유생기면 처리해 줄 주체가 없음

IaC (Infrastructure as a Code): 코드 -> 리소스 생성

 

※노트북이 바뀌어서 VScode 접속하는데 

vscode 인스턴스의 퍼블릭주소:8080 입력했는데 timed_out 오류 떴다?

-> 99% 방화벽 문제!!!

-> 보안 그룹 들어가서 편집에서 바뀐 내 ip주소로 변환 (What is my IP로도 확인 가능)

 

실습

 

 

 

 

 

 

쉘 스크립트 파일 실행하면서 마지막에 생긴 object url을 aws 스택생성 시 Amazon S3 URL에 집어넣기

 

 

 

새로운 VPC 생성된 것을 확인할 수 있다.

 

subnet_resource 쉘 파일 실행

 

쉘 파일 내용 중 VPC와 밑 VpcID에 할당(!Ref)된 VPC는 맵핑되어야 한다. (만약 MyVPC라면 밑에도 MyVPC)

 

 

업데이트 버튼 클릭

 

subnet_resource 실행하면서 나온 object url로 교체

 

 

가용영역 a,c 를 넣고 단계 진행 및 전송

 

 

(이전)

 

 

스택 형성 확인 및 create_complete

 

 

 

-Output 섹션 활용 (스택 세부정보에서 출력 내용 확인 가능, 현재는 아무것도 없음)

 

 

resource_output 쉘 파일 실행

 

 

resource_output에서 output 항목란에 value값이 출력될 거임

아까처럼 나온 object url 복사 그리고 업데이트 -> 템플릿 교체에서 url 바꾸기 (사실 동일한 거긴하나 실습차원에서)

 

아웃풋 파일안에 명시된 라우팅테이블, 프라이빗 서브넷, 인터넷 게이트웨이등이 생성되고 있음

 

 

 

vpc에서도 프라이빗 서브넷, 라우팅 테이블, 인터넷 게이트웨이가 형성된 것을 확인할 수 있음

 

 

이전에는 없었던 출력 결과가 지금은 나온 것을 확인할 수 있음

 

 

-Metadata Section의 ParameterGroups 활용

 

metadata parameter groups 파일에서 파라미터에 선언된 순서대로 출력될 것

 

 

metadata parameter groups 쉘 파일 실행하고 나온 object url로 교체한 결과, 순서대로 나오는 것을 확인할 수 있다.

 

이 항목에 체크하고 전송

 

 

transitGWSubnet, NAT Gateway 등 여러 이벤트가 생성되고 있음 확인할 수 있음 

 

 

us-east-1에서 해보기

 

us-east-1 디렉토리 이동 후 attach_iam_policy 쉘 파일 수행 (권한 정책)

 

us-east-1과 ap-northeast-2를 비교했을 때 비슷하나

parameter 값이 다르고 us-east-1에 openswan이 추가된 것을 확인할 수 있음

 

 

cloud_formation_stack 쉘 파일 실행

 

 

미국 버지니아 북부에 스택 하나가 형성된 것을 확인

 

똑같이 프랑크프루트에서도 해보자

 

 

 

프랑크프루트에서도 쉘 파일 실행한 결과 프랑크프루트 지역에서도 스택 하나가 형성된 것을 확인할 수 있음

 

CloudWatch: 모니터링 역할 (운영 및 관리에 유용)

 

-CloudAlarm 실습

 

 

 

AWS SNS 콘솔로 들어가서 주제 생성 및 구독 생성 (엔드포인트는 알람받을 주소로 자신의 이메일로!!)

 

 

이메일로 확인 메일오고 confirm 누르기 (근데 모르고 이전에 스택 생성했던 프랑크프루트에서 구독 생성해버린 것.. 삭제하고 서울 리젼에서 다시해보쟈....)

 

 

서울 리젼에서 EC2 -> ec2-web의 작업 -> 모니터링 및 문제 해결 -> CloudWatch 경보 관리 들어간다.

 

 

 

 

bastion 서버 접속 및 stress tool 버튼 클릭

 

 

CPU Utilization 60이상일 때 아까 등록한 메일로 알람이 오는 것을 확인할 수 있다.

CloudWatch Agent

Agent는 서버의 메모리 내용을 전송하기에 먼저 web-server 접속을 해준다.

 

 

root 권한으로 설치

 

 

질문이 엄청 쏟아져 나오는데 시간설정은 60s, 그리고 SSM, XRAY, 로그파일저장 등은 2번 (NO)으로 해두자

 

cloudwatch-agent  설치되고 실행된 것을 확인할 수 있다.

 

 

AWS cloudwatch 에서 모니터링 가능

 

lab-edu-ec2-web의 경우 메모리 사용이 37.1%인 것을 확인할 수 있음

 

Custom Metric

Metric에 걸기위해서 접근 권한이 필요하고 이건 vscode에만 있으므로

web-server에 접근 권한을 부여해야 함!!

 

 

다시 web-server 접속하여 create_custom_metric 쉘 파일 실행

 

이전에는 없었던 네임스페이스인 Custom/DiskMetrics 하나가 생김

 

 

디스크 사용량이 똑같이 17[%]로 나오는 것을 확인할 수 있다. 

 

cron을 설치하고 -e 통해 편집기 들어가서 주기적으로 업데이트 해줄 수 있다.

sh 파일의 실행 결과를 /var/log/disk-metric.log에 결과로 추가 (>>) 

 

 

permission denied가 떠서 다시 crontab -e 통해 편집기 들어가서 앞에 sudo sh 실행한 결과

정상적으로 사용량이 뜨는 것을 볼 수 있다.

 

Custom Log

 

프로세스 종료: kill -9 [PID 번호]

 

 

streamlit 실행 및 로그 추가 

 

-CloudWatch Agent Log 수집 설정

vim /opt/aws/amazon-cloudwatch-agent/bin/config.json 편집기 들어가서

변수에 값을 넣는 것 자체가 로그 추가 됨

 

 

 

로그 추가

 

 

 

streamlit 을 실행하면서 생긴 로그들이 AWS > CloudWatch > 로그 그룹 > Application Log 들어가서 확인할 수 있다.

 

Custom LogDashboard

 

 

 

마크다운 내용 변경 (이렇게 할 수도 있다!)

왼쪽 코드 부분들이 오른쪽에 시각화처럼 생성

 

 

 

+ 버튼누르고 경보 누르기

 

 

 

추가됨

 

 

 

 

i-06c0cd8d7b99901b0 복사

 

 

 

 

 

-네트워크

 

-로그 테이블

 

 

Application-Log > 쿼리 실행 > 위젯 생성

 

 

전체적인 대쉬보드 생성 결과 확인

 

VPC Peering: 2개 이상의 같은 VPC끼리 통신하게 하는 기능

-같은/다른 지역/계정끼리 통신 가능

-다만, 같은 계정에 같은 리젼에서 CIDR Block이 같은 경우 통신 불가

-그리고, 전이적 transition에 의해,

A-B peering 맺었고, B-C peering 맺었다 해서 A-C 통신 불가 !! => A-C 얘네도 peering 맺어줘야 함!!!

 

실습

 

 

 

 

 

수락 대기중이기에 받아줘야 연결됨

 

 

 

10.0.0.0/16으로 안 가면 0.0.0.0/0 으로 빠진다.

라우팅 편집을 통해 피어링 부분을 넣어준다.

 

 

하지만, 수신측에서 10.0.0.0/16으로 가는 경로가 없기 때문에 라우팅 편집을 통해 경로를 생성해준다.

 

 

10.10.40.114로 동일하다.

 

 

근데 vscode는 pri subnet02에 했고 우리는 지금 pri01에 라우팅을 통해 경로 설정했기 때문에 ping이 안통한다.

pri subnet01에 있는 web-server이기 때문에 web-server에서 시도해본다.

 

 

웹 서버에서 해 본 결과 핑이 되는 것을 확인할 수 있다.

 

vscode에서 하기위해선 pub subnet에서 10.10.0.0/16 경로를 추가해줘야 한다.

 

 

그 결과 ping이 되는 것을 확인할 수 있다.

 

Multi Region VPC Peering

 

 

 

 

프랑크프루트 피어링에 대해 수락대기중이므로 요청 수락을 통해 연결한다.

하지만, 아직 리소스에 대한 라우팅 테이블이 없기 때문에 라우팅 테이블 통해 경로를 생성한다.

 

 

프랑크프루트 프라이빗 라우팅 테이블에서 10.0.0.0/16 경로 설정해준다.

 

 

당연히 서울(ap-01)쪽에서도 해줘여 하므로프랑크프루트 ip (10.30.0.0/16)와 eu01 들어간 peering 부분에 대한 경로를 생성해준다.

 

 

 

프랑크프루트 네트워크프라이빗ip 주소를 webserver에서 핑 보낸 결과 되는 것을 확인할 수 있다.

 

*현재상황*

1. 서울 ap01 - 서울ap02 peering 완료

2. 서울 ap01 - 프랑크프루트 eu01 완료

하지만, 전이적 transition에 의해 서울ap02와 프랑크프루트 eu01은 통신이 되지 않는다!!

 

 

프랑크프루트 vpc 인스턴스 중 network > 세션매니저 통해 들어가서 ap02 ip주소 핑 찍은 결과 통신이 안되는 것을 확인할 수 있다!!

 

 

VPC Endpoint

 

웹 서버에 접속하여 root 권한으로 변수 할당 및 조회

 

 

엔드포인트 생성

 

 

게이트웨이 항목에 체크하여 엔드포인트 생성 (vpc: ap-01)

 

 

s3 버켓에서 이미지에 대한 버킷 정책을 삭제하고 확인해본다.

 

vscode에는 bucket(S3)에 대한 접근권한이 있는 것을 확인

 

 

vscode에서 bucket_policy_endpoint 쉘 파일 실행

 

쉘 파일 통해 나온 출력물(json)을 복붙하여 아까 버킷정책에 붙여넣어준다.

 

버킷에 대한 엔드포인트가 생성된 것을 볼 수 있고 라우팅 테이블 관리 들어가서 pri01 02를 추가해준다.

 

그럼 접근 권한에서 없던 web-server에서 객체 조회가 가능한 것을 확인할 수 있다.

 

이 부분은 삭제해야 함!! (조건이 없기 떄문에 어떻게 왔든 다 allow 해준다. 뭐든 다 통신됨)

 

따라서 이 부분을 삭제해서 다시 버킷 권한에 넣어주고 pri 01 라우팅 테이블에서 인터넷으로 빠져나가는 부분인 0.0.0.0/0 nat 게이트웨이를 제거한다.

 

그래도 잘 조회(통신)됨을 확인할 수 있다.

 

SSM (Session Manager)

앞서 pri 01은 NAT 게이트웨이를 삭제했기 때문에 세션매니저 서비스가 불가능하다.

 

 

 

 

서브넷은 pri 01 02

 

 

근데 오류가 뜸

 

왜냐하면 ap-01 DNS 호스트이름 비활성화 되어있으므로 그걸 활성화로 한다.

 

-ssm messages 생성

 

나머지는 동일하게

 

-ec2 messages

 

그러고나서, 

lab-edu-ec2-web 재부팅하고 세션 매니저에 연결한 결과

뜨는 것을 확인할 수 있다.