AWS 학습 (+ VPC Peering 실습)

AWS 비용 절감하기

• Rightsizing
• Elasticity
• Pricing
• Storage

 

Tagging

인스턴스를 관리할 때 태깅은 매우 중요하며, 이 태깅을 통해 Instance Scheduler를 동작시킬 수 있다.(EC2, RDS 등 사용 가능)

 

S3 Class

S3는 Standard, IA, Glacier 이외에도 Intelligent-Tiering이 출시됨

 

‣S3 Intelligent-Tiering

자주 액세스하는지, 안 하는지를 잘 모를 땐 Intelligent-Tiering 클래스를 사용하면 됨.

소액의 Monitoring, 자동화 요금으로 액세스 패턴을 모니터링하고 수명주기에 따라 액세스되지 않으면 IA, 나중에 다시 액세스가 이루어지면 스탠다드로 클래스를 자동으로 변경해줌.

 

++ Archive Access 계층 추가

IA에서 거의 액세스하지 않는 객체들은 Archive Access 혹은 Deep Archive Access 계층에 저장하여 스토리지 비용을 더욱 줄일 수 있다.

180일 이상 객체에 액세스하지 않으면 매월 TB당 1 USD 미만의 비용으로 데이터 저장이 가능하다.

 

 

AWS Nitro System

EC2는 Server 위의 Hypervisor에서 실행되는 Guest OS 중 하나이다.

Hypervisor는 하나의 컴퓨터에서 여러 OS를 실행시켜주는 솔루션을 말한다.(ex) Xen, VirtualBox, VMware)

 

그런데 가상화는 자원을 많이 잡아먹는다.

AWS 기존 EC2는 Xen 기반의 하이퍼바이저를 사용하는데 기본 호스트에서 리소스를 소비하기 때문에 최적화 된 리소스를 제공할 수 없다.

그래서 KVM 기반 Hypervisor를 커스터마이징 하여 Nitro System을 구축했다.

 

Nitro System은 Bare Metal 형식/Bare Metal 급의 경량 Hypervisor로도 제공된다.

• Nitro 카드 - IO를 가속화하여 시스템 성능 향샹
• Nitro 보안 칩 - 가상화 및 보안 기능
• Nitro 하이퍼바이저 - 메모리, CPU 할당을 관리
• Nitro Enclave - 격리된 컴퓨팅 환경을 통해 인스턴스 내 민감 데이터를 보호

Bare Metal이란 HW 위에 Hypervisor 설치 없이 고객이 원하는 OS를 직접 HW 위에 설치하는 방식이다.

즉, HW 리소스를 공유하는 가상화 방식과는 다르게 HW의 모든 성능을 사용할 수 있는 방식이 베어 메탈 방식이다.

 

AWS Firecracker

Firecracker는 Serverless 컴퓨팅을 위한 microVM을 위해 AWS에서 만든 KVM 기반의 Hypervisor이다.

Lambda, Fargate 등 서버리스 서비스를 사용할 때 VM이 뜨면서 해당 코드를 실행하게 되는데, VM은 컨테이너보다 보안은 우수하지만 처음 부팅 시 느리고 비교적 리소스를 효율적으로 사용하기 어렵다.

 

속도와 리소스 효율 면에서 이를 개선하기 위해 AWS는 기존의 컨테이너 방식이나 VM 방식이 아닌 새로운 가상화 기술을 오픈소스로 공개했다.

Firecracker는 서버리스 컴퓨팅에 최적화된 microVM으로 VM 보안성은 유지하고, 컨테이너의 빠른 확장과 리소스 효율성을 더했다.

 

AWS RAM(Resource Access Manager)

- 다른 계정 또는 AWS 조직과 AWS 리소스를 공유하는 경우

 

AWS PrivateLink

VPC와 온프레미스 네트워크간 프라이빗한 서비스 공유

 

---

AWS Networking Service

• VPC
  • 가상의 데이터 센터
• VPN
  • Client VPN
  • Site-to-Site VPN
• Direct Connect
  • On-prem과 VPC를 연결
• ELB
  • Load Balancer
• Route53
  • DNS 서비스

 

VPC

NACL - Stateless ( In/Outbound를 다 정의해줘야 함)

Security Group - Stateful (In-Out만 정의해주면 됨)

 

On-prem과 VPC 연결하기

 

1. VPN Gateway 사용On-prem에 Customer Gateway를 두고 VPC에 VPN Gateway를 두어 연결할 수 있다.IPSec 기반 site-to-site vpn을 통해 암호화터널(이중화, TLS 통신)을 구성.

 

2. Direct Connect 사용전용회선을 통해 고객사와 직접 연결하며 AWS가 아닌 DX Location을 통해 연결한다.VPC(Virtual Private Gateway) --  Private Virtual Interface  -- Direct Connect Endpoint --  전용회선  -- On-premDX Location은 Seoul Region의 KINX(가산), LG U+(평촌) 두 곳이 있다.

 

VPC-VPC 간 연결하기

VPC Peering을 통해 두 VPC 사이의 네트워크를 연결한다.로컬, 다른 AWS 계정, 다른 리전간 연결도 가능하며 Routing Table을 통해 통제한다.

 

연결 방법

1. 연결하고자 하는 VPC에 VPC Peering을 요청한다.

2. 요청을 받은 VPC가 이를 승낙한다.

3. 후에 각각의 VPC의 Routing Table에서 테이블 정보를 수정한다.

 

실습

 

웹 서버 구성

 

현재 EC2 인스턴스 두 대가 실행 중이며, 각각 10.0.0.0/24(web1)와 192.168.0.0/24(web2) 서브넷에 위치해있다.

 

각각 다른 VPC에 위치해있으므로 서로 간에 통신은 이루어지지 않는 상태이다.

 

VPC Peering 구성

 

연결하고자 하는 VPC(peer 2)에 요청을 전송하기 위해 피어링 연결을 설정해준다. 

 

연결을 설정하면 아래와 같이 '수락 대기 중' 이라는 문구가 표시되며 승낙을 기다리는 상태가 된다.

 

현재 아래와 같은 상태에 해당한다.

 

이제 이 Peering에 대한 요청을 수락할 단계이다.

[요청 수락]을 클릭하여 이 피어링을 승낙해보자.

 

여기서 끝이 아니다.

앞서 설명했던 것처럼 VPC Peering은 Routing Table로 제어하기 때문에 각각의 Routing Table에서 VPC Peering에 대한 정보를 추가해주어야 한다.

 

각각의 Subnet을 대상으로 라우팅 해주자.

 

Routing Table 수정 후엔 정상적으로 통신이 이루어지는 것을 확인할 수 있다.

 

(참고)

ping 통신이 안된다면 보안그룹에서 인바운드 규칙에 ICMP가 추가돼있는지 확인한다.!