[쿠버네티스 1/26] AWS - VPC

신현식·2023년 1월 26일

aws vpc 구름

구름_AWS

목록 보기

2/3

리전을 바꿔주지 않으면 기존에 만들었던 키와 보안그룹을 사용하는 것이 불가능하다.

Linux에 CLI 설치

CLI 설치 파일 다운로드 후 압축 해제하여 설치

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

unzip awscliv2.zip

./aws/install

설치 확인 및 액세스 키 입력

aws --version

aws configure
AWS Access Key ID [None] : 액세스 키 입력
AWS Secret Access Key [None] : 비밀 액세스 키 입력
## S3의 region 입력을 해도 무관하며, 설정 이후 변경이 가능
Default region name [None] : Default 값 입력 
Default output format [None] : json

설정한 내용은 OS 계정 Home 디렉터리 하위에 숨긴 폴더로 저장됩니다. ex) /root/.aws/

AWS CLI를 통해 s3 버킷 생성

aws s3 ls -> 현재 버킷에는 아무것도 없다.

## 신규 버킷 생성
[root@ip-172-31-4-179 ~]# aws s3 mb s3://hs-test-bk1
make_bucket: hs-test-bk1

아마존 웹사이트에 들어가서 확인하면 버킷이 새로 만들어진 것을 볼 수 있다.

객체 복사

mkdir test
cd test
## 빈 파일 생성
echo s3 test1 > file
## 파일 s3 스토리지에 복사
aws s3 cp file s3://hs-test-bk1/
mkdir test1

echo s3 test2 > test1/file2
[root@ip-172-31-4-179 test]# aws s3 cp ./test1 s3://hs-test-bk1/
upload failed: test1/ to s3://hs-test-bk1/ Parameter validation failed:
Invalid length for parameter Key, value: 0, valid range: 1-inf

💡 faild 됨 -> why? s3가 파일단위 접근만 지원하기 때문에 디렉터리에 접근이 불가능하다.

따라서 파일에 접근하거나 옵션을 붙여줘야 한다.

--recursive
해당 옵션을 사용하면 지정된 디렉터리 또는 접두사 아래의 모든 객체에 대해 명령이 수행된다. (명령어 mv, cp, rm 적용)

## 파일에 접근
[root@ip-172-31-4-179 test]# aws s3 cp ./test1/file2 s3://hs-test-bk1/
upload: test1/file2 to s3://hs-test-bk1/file2

## 버킷 및 객체 확인
[root@ip-172-31-4-179 test]# aws s3 ls s3://hs-test-bk1
2023-01-26 01:41:53          9 file
2023-01-26 01:46:03          9 file2

## 디렉터리에 접근
[root@ip-172-31-4-179 test]# aws s3 cp ./ s3://hs-test-bk1/ --recursive
upload: ./file to s3://hs-test-bk1/file
upload: test1/file2 to s3://hs-test-bk1/test1/file2
[root@ip-172-31-4-179 test]# aws s3 ls s3://hs-test-bk1
                           PRE test1/
2023-01-26 01:47:38          9 file
2023-01-26 01:46:03          9 file2

객체 이동

## aws s3 mv <source> <target>
aws s3 mv /root/file.txt s3://hs-test-bk1

객체 삭제 및 버킷 삭제

기존 웹페이지와 마찬가지로 버킷안에 파일이 있으면 버컷삭제가 불가능하니 먼저 객체를 없애주고 버킷을 삭제해야 한다.

## aws s3 rm <s3://버킷명/객체명>
aws s3 rm s3://hs-test-bk1/ --recursive
aws s3 ls s3://hs-test-bk1

## aws s3 rb <s3://버킷명>
aws s3 rb s3://hs-test-bk1

객체 동기화

aws s3 sync <source> <target>
s3 sync ./ s3://hs-test-bk1

## 루트에 존재하는 것들이 s3에 잘 동기화 되었는지 확인
aws s3 ls s3://hs-test-bk1

자동으로 동기화 하도록 설정

리눅스에서는 crontab를 사용하여 동기화 설정을 해준다.

vi /etc/crontab
## (분 시 일 월 요일) 명령
17 11 26 1 * aws s3 sync /root/test s3://hs-test-bk1
## aws_job이라는 이름으로 저장
w /etc/cron.d/aws_job
q!

## 현재 시간 확인
date

1월 26일 11시 17분이 되면 이 명령(test에 있는 것들을 s3 버킷과 동기화)이 실행된다.

AWS VPC

VPN은 Virtual private network의 약자로 큰 규모의 조직이 여러곳에 분산되어 있는 컴퓨터들을 연결하는 보안성이 높은 사설 네트워크를 만들거나 인터넷을 활용하여 원격지 간에 네트워크를 서로 연결하고 암호화 기술을 적용하여 보다 안정적이며, 보안성이 높은 통신 서비스를 제공하는 서비스를 말한다.

아마존 웹서비스는 VPC와 VPC 게이트웨이를 통해 온프레미스의 VPN 장비와 아마존 웹서비스간의 VPN을 연결할 수 있으며, 이를 통해 보안성이 높은 하이브리드 클라우드 환경을 구현하여 원활한 클라우드 컴퓨팅 서비스를 지원할 수 있다.
서브넷이 틀려도 같은 VPC 내부에 있으면 서로 통신이 가능하다.

VPC 구성요소

IP Address

VPC와 서브넷

public subnet / private subnet

라우팅 테이블

아웃바운드 트래픽에 대한 경로 지정. 서브넷 및 VPC 간 통신을 위하여 구성

VPC 주요 서비스

보안 그룹 / 네트워크 ACL

VPC 피어링 연결(VPC Peering Connection)

비공개적으로 서로 다른 VPC 간에 트래픽을 라우팅할 수 있게 하기 위한 네트워크 연결 제공한다. 동일한 네트워크에 속한 것과 같이 서로 다른 VPC의 인스턴스 간에 통신이 가능하다.

NAT 게이트웨이

VPC Endpoint

VPN

VPC 생성순서

vpc 생성(네트워크에서 사용할 IP 구간 설정)
서브넷 생성(설정된 IP 구간을 세부적으로 설정)
인터넷 게이트웨이 생성 및 VPC 연결
라우팅 테이블 생성 및 작성(퍼블릭/프라이빗 서브넷 설정)
-> 프라이빗 서브넷에 속한 인스턴스가 인터넷을 필요로 하는 경우
nat 게이트웨이 생성
라우팅 테이블 작성

VPC를 만드는 순간 기본 라우팅 테이블이 작성됨 - 해당 VPC에 속한 인스턴스들은 서로 통신이 가능하도록!

VPC 생성

vpc 서브넷의 크기는 최대 16이다.

'VPC 등' 선택

AZ 사용자 지정
서울 리전은 가용영역을 a와 c를 사용하는 것이 좋다.
서브넷 CIDR 설정
퍼블릭
2a - 10.0.0.0/24
2c - 10.0.10.0/24
프라이빗
2a - 10.0.100.0/24
2c - 10.0.110.0/24
nat게이트웨이와 vpc 엔드포인트는 없음으로 하고 나머지는 건들지 않고 vpc를 생성한다.

'VPC만' 선택

VPC이름:my-vpc, IPv4 CIDR 100.0.0.0/16 하고 VPC를 생성한다.
서브넷 설정
서브넷에 가서 서브넷 생성, VPC ID: 생성했던 VPC 선택
서브넷 이름: my-pub-sb, 가용영역: 2a, CIDR : 100.0.0.0/24
서브넷 이름: my-pri-sb, 가용영역: 2a, CIDR : 100.0.100.0/24
서브넷 이름: my-pri2-sb, 가용영역: 2c, CIDR : 100.0.110.0/24
인터넷 게이트웨이 생성
인터넷 게이트웨이에 가서 생성, 작업에 VPC에 연결 선택, 만들었던 VPC와 연결
라우팅 테이블 생성 및 작성
라우팅 테이블에 가서 생성, my-pub-rtb, my-pri1-rtb, my-pri2-rtb 생성
- my-pub-rtb에 들어가 라우팅 선택 -> 라우팅 편집 선택 -> 라우팅 추가(전체 네트워크 대상(0.0.0.0/0)으로 인터넷 게이트 웨이 설정)
- 서브넷 연결에 있는 명시적 서브넷 연결에서 서브넷 연결 편집 -> my-pub-rtb 선택한 후 연결저장

※ 따로 라우팅 테이블을 명시해주지 않으면 디폴트 라이팅 테이블의 영향을 받는다.

public/private 인스턴스 생성

퍼블릭 인스턴스 생성
네트워크 설정에서 VPC를 만들었던 것으로 변경, 서브넷을 퍼블릭 IP로 설정, 퍼블릭 IP 자동할당 활성화, 보안그룹생성(test-sg, ssh+icmp), 인바운드 규칙 추가(모든 ICMP, 소스유형: 위치무관)
프라이빗 인스턴스 생성
네트워크 설정에서 VPC를 만들었던 것으로 변경, 서브넷을 프라이빗IP로 각각 설정, 퍼블릭 IP 자동할당 비활성화, 만들었던 보안그룹 선택

터미널로 퍼블릭 인스턴스에 접속

ssh ec2-user@13.124.78.110(퍼블릭 IP) -i .\Downloads\linux1_key.pem(key 위치)

public 인스턴스에서 private 인스턴스에 접속

## 생성했었던 사용하는 pem키의 내용 복붙 후 저장
vi key

## 권한 부여
chmod 400 key
## 프라이빗 인스턴스 접속(유저 이름은 같으면 생략해주어도 된다.)
# ssh ec2-user@프라이빗 인스턴스의 프라이빗IPv4 주소  -i key
# ssh 프라이빗 인스턴스의 프라이빗IPv4 주소  -i key
ssh 100.0.100.205 -i key

private 인스턴스 외부 통신 설정

현재는 외부로 통신이 불가능한데 통신을 가능하게 하기 위해 nat 게이트웨이 설정을 해주면 된다.

NAT 게이트웨이에 가서 생성 -> 이름: my-nat, 서브넷: 만들었던 퍼블릭 서브넷, 탄력적 IP 할당 클릭 -> 생성
라우팅 테이블에서 pri 선택 -> 라우팅 편집 -> 라우팅 추가(전체 네티워크 대상(0.0.0.0/0)으로 nat 게이트웨이 설정) -> 변경사항 저장
서브넷 연결에 명시적 서브넷 연결 -> 서브넷 연결 편집 -> pri 추가한 이후 연결저장 하면 pri 인스턴스에도도 외부와 통신이 가능하다.

설정 전에는 ping을 보내지 못하였지만 지금은 ping이 가는것을 확인 할 수 있다. 설정하지 않은 private 인스턴스는 nat 게이트웨이가 설정되어있지 않아 ping을 보내지 못한다. 보내고 싶다면 nat 게이트웨이가 설정되어 있는 vpc의 서브넷 연결 편집에서 해당 인스턴스도 추가로 선택하여 저장해주면 된다.

VPC 삭제방법

인스턴스 삭제 -> nat 게이트웨이 삭제 -> 탄력적 IP에서 탄력적 IP 주소 릴리스(nat 게이트웨이에서 탄력적 IP를 적용했기 때문에 삭제하지 않으면 비용이 부가될 수 있다.) -> VPC 삭제

위와 같은 순서로 진행해주면 된다.

VPC Peering 동작과정

1.VPC 피어링 인터페이스 생성 및 연결신청
서울용 vpc, 인스턴스 창
미국 버지나아용 vpc, 인스턴스 창

2. 반대쪽 VPC에서 연결 수락
서울 VPC에서 피어링 연결로 간다. VPC를 연결할 미국 버지니아로 리전을 바꾸고 vpc ID를 복사해서 붙여넣고 연결을 만든다.
미국 VPC에서 피어링 연결로 가 작업에 요청수락을 한다.

3. 양쪽 VPC에서 라우팅 테이블 수정

미국 vpc 라우팅 테이블에서 서울과 연결된 라우팅 테이블 편집, 라우팅 추가(서울 vpc IP주소 / 피어링 연결)
서울 vpc 라우팅 테이블에도 마찬가지로 라우팅 추가(미국 vpc IP주소 / 피어링 연결)

신현식

전공 소개

이전 포스트

[쿠버네티스 1/25] AWS - EC2 & S3

다음 포스트