- 전용 호스트
- 한 사용자를 위한 물리적 전용 EC2 서버
- EC2 인스턴스 배치를 완전히 제어함
- 3년동안 사용자의 계정에 할당된다.
- 비싼 편이다.
- 또는 강력한 규제 또는 규정 준수 요구가 있는 회사의 경우
AWS
VPC
vpc 만들면
DHCP옵션세트, 기본라우팅테이블, 기본네트워크ACL, 기본 보안그룹
4개가 자동으로 만들어짐
public subnet 4개 만들기
my-pub-2a / ap-northeast-2a / 10.38.0.0/20
my-pub-2b / ap-northeast-2b / 10.38.16.0/20
my-pub-2c / ap-northeast-2c / 10.38.32.0/20
my-pub-2d / ap-northeast-2d / 10.38.48.0/20
private subnet 4개 만들기
my-pvt-2a / ap-northeast-2a / 10.38.64.0/20
my-pvt-2b / ap-northeast-2b / 10.38.80.0/20
my-pvt-2c / ap-northeast-2c / 10.38.96.0/20
my-pvt-2d / ap-northeast-2d / 10.38.112.0/20
- public subnet 4개만 자동 할당 ip 생성 체크
인터넷게이트웨이
라우팅테이블
이거 한줄만잇으면 private subnet
pub 4개 명시적 서브넷연결에 추가
라우팅 테이블 생성 -> private 용
- 서브넷 연결편집 ㄱㄱ
EC2
인스턴스 생성
VPC Peering
- VPC 피어링 연결은 프리이빗 IPv4 주소 또는 IPv6 주소를 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있도록 하기위한 두 VPC 사이의 네트워킹 연결이다.
- 동일한 네트워크에 속하는 경우와 같이 VPC의 인스턴스가 서로 통신할 수 있다.
- 사용자의 자체 VPC 또는 다른 AWS 계정의 VPC와 VPC 피어링 연결을 만들 수 있다.
- VPC는 다른 리전에 있을 수 있다. (리전간 VPC 피어링 연결이라고도함)
- AWS는 VPC의 기존 인프라를 사용하여 VPC 피어링 연결을 생성한다. 이는 게이트웨이도, VPN 연결도 아니며 물리적 하드웨어 각각에 의존하지 않는다.
tokyo
인스턴스 생성
key-pair도 리전마다 잇는거여서 다시 만들어줌
피어링
- 지금내 라우팅테이블 설정
- 2줄잇는거보니 public 라우팅 테이블 -> 서울 추가
서울 public 라우팅 테이블
도쿄 연결
- 이제 도쿄인스턴스에서 서울에 잇는 인스턴스로 private ip로도 핑 잘나간다.
알리바바
cloud DNS
볼륨
- 볼륨 연결
lsblk
sudo mkfs -t ext4 /dev/xvdf- 볼륨수정 (증가는 되는데 줄이는건 안됨)
sudo growpart /dev/xvda 1- food.tar 업로드
sudo tar xvf food.tar -C /var/www/html- 스냅샷 생성
-
만들어지면 -> 스냅샷에서 이미지 생성
-
스냅샷 그자체를 ec2로 만들수 없으므로 스냅샷 -> 이미지 -> 인스턴스의 과정을 거쳐야 한다.
- 만들어진 AMI 복사 (비용이 발생한다, 10gb짜리 데이터포메이션이여서)
-
토쿄 리전에 와보니까 AMI 복사되어있는거 확인!
-
이미지 복사하면 스냅샷도 같이 복사됨
업로드할때는 돈안드는데 내려받을때 돈들음
- 서울에서 만든 AMI로 인스턴스 시작 ㄱㄱ
알리바바
- seoul -> modify
tokyo 에서 AMI 복사해서 만든 인스턴스로
삭제 작업--------
도쿄
- 인스턴스 삭제
- AMI 먼저 삭제(AMI 등록취소)후 그다음 스냅샷 삭제
-> 보안그룹 삭제
-> keypair 삭제
- 마지막으로 봤을 떄 보안그룹 1 그리고 종료되고 있는 인스턴스 2개 뺴고는 다 0이여야함
서울
-
피어링연결
-> 삭제 (이건 어느방향에서든 삭제하면 됨) -> 삭제 요청시 관련라우팅 테이블 항목삭제까지 해준다.
도쿄
-
라우팅 테이블
가보면 라우팅 테이블에 vpc 피어링 블랙홀로 되어있는거 확인가능 -
제거 ㄱㄱ
서울
-
인스턴스 중지 ㄱㄱ
-
AMI 등록취소
-
스냅샷 삭제
