34일차) 2025-02-17(AWS-EC2, VPC, RDS)
클라우드
온디맨드(On-demand, 수요가 발생하는 즉시) 리소스를 대여하거나 받은 후 사용한 만큼 금액을 지불하는 서비스
공용 클라우드
AWS, GCP, Azure
사설 클라우드
Openstack(KVM, OpenVswitch)같은 툴로 직접 구성
클라우드 컴퓨팅
어디서부터 구성할 것인지에 따라 달라짐
IaaS(Infrastucture as a Service)
서비스로써의 인프라, asS = 제공(서비스모델)
운영체제가 설치되어 있지 않은 서버(Bare-metal) = 직접 OS 단계부터 설치
PaaS(Platform as a Service)
운영체제 이상이 설치된 경우
ex. 내가 제공받은 서버에 Ubuntu 운영체제가 이미 설치되어 있음
ex. 개발환경이 구성되어 있음(Linux+Python)
ex. lambda를 통한 어플리케이션 배포
SaaS(Service as a Service)
서비스 그자체
ex. 구글 문서, 이메일 서비스
AWS
비용 알림 신청
- 서울 리전 확인
- 과금 요소 확인
EC2
인스턴스 생성
- 키 페어 생성
- 나: private 키, aws: public 키
# aws가 퍼블릭키를 서버에 심어줌
= 나는 해당 퍼블릭키에 해당하는 프라이빗키(pem)로 ssh 접근이 가능
- 인스턴스 세부정보
- 보안 탭
# 보안 - 보안그룹 확인하러 주로 많이 봐야 함
인바운드와 아웃바운드 중 아웃바운드는 손대지 말자!
EC2 서버 접속
- 접속하고자 하는 서버의 사용자이름을 모르는 경우
- root 로그인
- nginx 설치
root@ip-172-31-43-181:~# apt install -y nginx
- icmp를 열고, 위치무관 = Anywhere-IPv4
인스턴스 종료
VPC(Virtual Private Cloud)
오버레이 네트워크가 구성되어야 가용영역간의 migration과 고가용성(높은 확률로 사용할 수 있도록)이 가능
# VPC : 리전 밖 혹은 리전내에서 서로 독립적인 사설 네트워크, 일반적으로 다른 VPC끼리는 서로 통신이 안된다.
(VPN이나 VPC peering, Transit GW 같은 특수한 방법 제외)
# 우리는 앞으로 AZ A와 C를 쓸것이다. 인스턴스유형중에 B, D에서 못만드는 인스턴스 유형이 있음.
# Availability Zone : 가용영역, 서로 물리적으로 떨어져있는 데이터센터, 리전은 최소 3개 이상의 AZ로 구성되어있다.
- VPC 생성
- VPC에서 필터링 확인
- 인터넷 게이트웨이(IGW/대문) 생성
- 인터넷 게이트웨이 연결
- 서브넷 설정
VPC 서브넷
- 퍼블릭 서브넷: 외부와 통신이 되는 서브넷(인바운드-아웃바운드 둘다)
- 프라이빗 서브넷: 내부에서만 통신 가능한 서브넷(때에 따라서는 아웃바운드 가능)
- 라우팅 테이블 확인
라우팅 테이블
- 비명시적 서브넷 연결
- 라우팅 테이블 생성
- 라우팅 테이블 편집
- 명시적 서브넷 연결
- 서브넷 추가
- vpc를 만들면 자동으로 생성됐던 라우팅 테이블을 이용
# 서브넷을 만들면 이 라우팅테이블이 자동으로 선택되니까(비명시적 = 따로 라우팅테이블을 지정안하면)
이 기본라우팅테이블을 프라이빗서브넷을 위한 라우팅테이블로 이름을 붙여주자!
♨ igw와 연결되어있다 = 퍼블릭 서브넷
♨ igw와 연결되어있지않다 = 프라이빗 서브넷
pub-sub2 와 pri-sub2를 만들어보세요.
pub-sub2 - 10.10.11.0 /24 az - c
pri-sub2 - 10.10.12.0 /24 az - c
# 인스턴스를 만들어서 해당 퍼블릭을 선택해보면 퍼블릭 IP자동할당이 비활성화로 되어있다.
= 퍼블릭 IP를 못받음
# 처음에 퍼블릭서브넷을 만들때, 위 두개의 설정을 활성화하여 퍼블릭 IP와 퍼블릭 영문주소를 할당받도록 해야 한다.
♨ VPC를 처음 생성할때도 위의 옵션을 꼭 활성화해준다. ♨
실습)
프라이빗 서브넷(pri-sub1)에 인스턴스를 생성하고(서브넷설정편집은 하지말고)
생성시 퍼블릭IP를 부여받도록 해보세요(억지로)
보안그룹은 새로 만드세요! 기존 web-allow(ssh,icmp,http 허용)랑 동일하게
노트북에서 해당 인스턴스로 통신(ping)이 되는지 확인해보세요.
어디까지되고, 어디까지 안되는지(inbound,outbound) 검증
퍼블릭IP? = 글로벌하게 유효한 IP
비록 프라이빗 서브넷에 존재하는 인스턴스지만 공인아이피를 할당받았기 때문에 찾아오는건 가능할 것이다. 하지만 라우팅테이블의 정책상 pri인스턴스 입장에서 아웃바운드가 허용되어있지 않기때문에 icmp reply는 안될것이라는게 우리의 가정이다. 따라서 이 가설을 검증을 해보라는 뜻
1. 노트북 → pri인스턴스 (o)
2. pri인스턴스 → 노트북 (x) : 라우팅테이블 정책상, 외부로 통신하기 위한 정책 없음
→ 인바운드는 되는데, 아웃바운드가 안된다.
→ 검증하려면 어떻게 하면 좋을까?
pri-sub1에 공인IP를 갖고있는 인스턴스를 만들어보자!
# 프라이빗 서브넷에 있는 인스턴스는 공인IP를 부여받았어도 ssh 접속이 불가능(노트북이든, aws웹콘솔이든 불가능)
이 프라이빗서브넷에 존재하는 서버에 접속하기 위해 bastion 서버를 하나 만들어보자!
이름 : bastion
AMI : ubuntu 24.04 프리티어 사용가능.
유형 : t2.micro
키페어 : aws8
1. bastion을 만들었다면 bastion으로 ssh 접속
bastion에 접속할때의 ssh client = 노트북, ssh server = bastion
2. bastion에서 pri-srv로 ssh접속
ssh client = bastion , ssh server = pri-srv
bastion이 ssh 프라이빗 키(aws8.pem)를 갖고 있으면 됨
scp(ssh 파일전송하는 프로토콜) - 이건 필요없고, pem을 메모장으로 열어서 bastion 서버에서 vi로 파일을 만들자!
- aws8.pem 파일을 생성하면서 vi편집기로 진입
root@ip-10-10-1-118:~# vi aws8.pem
# pem파일의 권한을 변경후에 접속하면 접속이 잘 된다.
# tcpdump를 통해 인바운드(노트북->pri-srv)는 가능하지만 아웃바운드(pri-srv->노트북)는 불가능했다. 프라이빗 서브넷은 외부로 나가기 위한 정책이 없기 때문
- DB(RDS)를 위한 서브넷 생성
RDS(관계형 데이터베이스 서비스)
- RDS(관계형 데이터베이스 서비스) 생성
# RDS는 반드시 서브넷그룹에 DB를 만들어야함
# 서브넷그룹 : 두개이상의 서브넷 묶음 = “DB를 만들땐 꼭 두개이상의 가용영역에 걸쳐서 만들어” 강제된 느낌
실습)
생성한 데이터베이스에 접속해보세요!
이름 : bastion
AMI : ubuntu 24.04 프리티어 사용가능.
유형 : t2.micro
키페어 : aws8
서브넷 : rapa-vpc-pub-sub1
서버 생성 후 ssh로 접속
- mysql 명령어 설치
ubuntu@ip-10-10-1-185:~$ sudo -i
root@ip-10-10-1-185:~# apt install -y mysql-client
# sudo apt-get update
# sudo apt-get install -y mysql-client
- DB주소
- DB사용자
admin
- DB사용자암호
test1234
- DB이름
testdb
- 접속 시도
- RDS db 삭제
