[ AWS ] aws 서비스 살펴보기 #1

AWS 서비스에 대해서 검색해보고 Cloud vs On-Prem 각 서비스에 대한 장단점 비교를 한번 해보는 자료만들기

1. Computing

0) basic network

VPC

• 논리적으로 격리된 가상 네트워크, ‘네트워크’ 와 유사한개념

subnet

• vpc 의 ip 주소 범위
• 하나의 서브넷은 하나의 az 에 있을 수 있음

AZ

• 물리적으로 분리된 데이터 센터

Local Zones

• aws region 의 확장
• 자체적으로 인터넷 연결됨

1) EC2

• AWS에서 가장 기본적이면서 널리 쓰이는 인프라로 인터넷에 연결된 가상서버를 제공함
• 클라우드에서 컴퓨팅 파워의 규모를 자유자재로 변경할 수 있는 웹 서비스
  • AutoScaling
• EC2의 간단한 웹 서비스 인터페이스를 통해 간편하게 필요한 용량을 얻고 구성할 수 있음
• 컴퓨팅 리소스에 대한 포괄적인 제어권을 제공하며, Amazon의 검증된 컴퓨팅 인프라에서 실행할 수 있음
• 안정성을 위해 여러 리전과 가용영역에 걸쳐 배포된다.

장단점 비교

요소 EC2 온프레미스 서버

확장성	높음 (필요에 따라 용량을 쉽게 확장하거나 축소할 수 있음)	낮음 (서버 확장에 물리적 한계가 있을 수 있으며, 확장을 위해서는 새로운 하드웨어를 구입해야 함)
비용 효율성	사용한 만큼만 비용을 지불하는 구조로, 유지보수 비용이 적음	초기 투자 비용이 더 높을 수 있지만, 장기적으로는 EC2보다 비용을 예측하기 쉽습니다
관리 서비스	AWS가 인프라를 관리하므로, 사용자는 애플리케이션 개발과 유지보수에만 집중할 수 있음	서버 유지보수와 관리는 사용자가 담당해야 함
보안	AWS가 보안 서비스를 제공하며, 데이터 보안을 강화할 수 있음	데이터가 자사의 서버에 저장되므로, 보안을 더 잘 통제할 수 있음
가용성	높은 가용성을 제공하며, 장애 복구성이 쉽음	서버 장애 시 복구하기가 어렵고, 백업 시스템을 구축해야 함
데이터 주권	데이터가 AWS의 서버에 저장되므로, 데이터 주권에 대한 우려가 있을 수 있음	데이터가 자사의 서버에 저장되므로, 데이터 주권과 보안을 더 잘 통제할 수 있음
사설 네트워크 통합	-	사내 네트워크와 통합하여 안정적인 네트워크 환경을 구축할 수 있음

💡
AutoScaling?
트래픽에 따라 ec2 인스턴스들을 자동으로 확장하거나 제거해주는 서비스
Amazon EC2 Auto Scaling을 사용하면 비정상 인스턴스를 탐지하여 교체하는 EC2 인스턴스 플릿 관리를 통해 그리고 사용자가 정의하는 조건에 따라 Amazon EC2 용량을 자동으로 확장 또는 축소함으로써 애플리케이션 가용성을 유지할 수 있음

 

 

2) Lambda

Lambda는 AWS에서 제공하는 서버리스 컴퓨팅 플랫폼이다.

서버리스란, 서버가 없다는 뜻이 아니고 개발자가 서버의 존재를 신경쓸 필요가 없다는 뜻이다. 서버가 잘 돌아가고 있는지, 개수와 사양한 적당한지 등등 신경쓸 필요없이 사용자는 오직 코드에만 집중할 수 있으니 무척 편하다.

이때 사용한 컴퓨팅 시간, 용량에 대해서만 AWS에게 비용을 지불하면 된다.

언제 쓰면 좋을까?

코드를 계속 실행시키기 보다는 특정한 시기에만 실행시키는 경우에 Lambda를 사용하면 유용하다.

예를 들면

• 서버 띄우지 않고 간단한 코드를 실행시키고 싶은 경우
• 특정 기간 또는 특정 주기로 코드를 실행시켜야 하는 경우
• 트리거가 실행될때만 코드를 실행시키고 싶은 경우

하지만 람다의 단점도 존재한다.

• 코드 용량이 최대 250MB 이다.
• 함수 실행 시간은 최대 15분이다.
• 처음 함수 호출시 Cold Start를 하게되고 초기 지연시간이 발생한다.
• 비싸다.

3) LightSail

• 간단한 VPS(Virtual Private Server)솔루션이 필요한 사용자가 AWS를 시작할 수 있는 가장 쉬운 방법으로 Lightsail은 개발자에게 클라우드에서 웹사이트와 웹 애플리케이션을 배포하고 관리할 수 있는 컴퓨팅, 스토리지 및 네트워킹 용량 및 기능을 제공함
• Lightsail에는 프로젝트를 빠르게 시작하는 데 필요한 가상 머신, SSD기반 스토리지, 데이터 전송, DNS관리, 정적IP가 포함되어 있음

온프레미스 vs Lambda  vs Lightsail

장점	장점	장점
- 보안 및 데이터 주권 제어 가능	- 서버리스 아키텍처로 운영 비용 절감 가능	- 사용하기 쉬운 UI와 CLI 제공
- 안정적인 성능 제공	- 이벤트 기반으로 효율적인 리소스 사용	- 고성능 스토리지 및 네트워크 제공
- 기존의 관행에 기반한 관리	- 빠른 배포 및 확장성 제공	- 월 단위 요금제로 비용 예측 쉬움
단점	단점	단점
- 초기 투자 비용이 높음	- 복잡한 애플리케이션 배포 시 어려움	- 제한된 구성 옵션 제공
- 장기적인 운영 비용이 높을 수 있음	- 서버리스 아키텍처에 익숙하지 않은 개발자에게 어려움	- 제한된 사용자 지정 가능성
- 하드웨어 및 소프트웨어 유지보수 필요	- 보안 및 데이터 주권 제어가 어려울 수 있음	- 제한된 보안 및 컴플라이언스 인증 제공

2. Storage

1) S3

Amazon S3는 어디서나 원하는 양의 데이터를 저장하고 검색할 수 있도록 구축된 객체 스토리지입니다. S3는 업계 최고 수준의 내구성, 가용성, 성능, 보안 및 거의 무제한의 확장성을 아주 저렴한 요금으로 제공하는 단순한 스토리지 서비스입니다.

 

1. 스토리지 및 데이터 저장

S3는 파일, 이미지, 비디오, 문서 등의 데이터를 저장하기 위한 공간을 제공합니다. 이 데이터들은 "버킷"이라고 불리는 저장 공간에 저장됩니다**. 각 버킷은 전 세계 어느 곳에서나 고유한 이름**을 가지며, 이를 통해 데이터를 관리하고 접근할 수 있습니다.

 

2. 확장성

S3는 확장 가능한 서비스로, 수천 개에서 수백만 개의 파일을 저장하고 관리할 수 있습니다. 필요에 따라 스토리지 용량을 조정하거나 파일을 추가하거나 삭제할 수 있습니다.

 

3. 데이터 보안 및 접근 제어

S3는 데이터 보안을 위한 다양한 기능을 제공합니다. 데이터를 암호화하여 저장하고, 접근 권한을 세밀하게 제어하여 누가 데이터에 접근하고 수정할 수 있는지를 관리할 수 있습니다.

 

4. 데이터 백업 및 복원

S3는 데이터의 백업과 복원 기능을 사용하여 중요한 데이터를 안전하게 저장하고, 필요한 경우에는 데이터를 원래 상태로 복원할 수 있습니다.

 

5. 웹 호스팅 및 정적 웹 사이트 호스팅

S3를 사용하여 정적 웹 페이지나 웹 사이트를 호스팅 할 수 있습니다. 이를 통해 비용을 절감하고, 빠르고 안정적인 웹 호스팅 환경을 구축할 수 있습니다.

 

6. 데이터 전송 및 배포

S3를 사용하면 전 세계 어디에서나 데이터를 손쉽게 업로드하고 다운로드할 수 있습니다. 또한, 데이터를 글로벌하게 배포하기 위해 S3의 내용을 Content Delivery Network(CDN)와 통합하여 사용할 수 있습니다.

 

7. 비용 효율성

S3는 사용한 용량에 따라 과금되며, 필요한 만큼만 비용을 지불하면 됩니다. 이로써 비용을 효율적으로 관리하면서 필요한 데이터 스토리지를 유연하게 활용할 수 있습니다.

 

S3 vs 온프레미스

확장성	고성능, 필요에 따라 용량을 쉽게 확장할 수 있음	초기 투자 비용이 높음, 확장성이 제한적일 수 있음
보안	AWS의 보안 서비스 제공, 접근 제어 강화	데이터 주권을 더 잘 통제할 수 있음
비용	사용한 만큼만 비용을 지불하는 구조로 경제적	고정 비용이 필요하며, 장기적으로는 비용이 예측하기 어려움
관리	AWS가 인프라를 관리하므로 사용자는 데이터와 애플리케이션에만 집중할 수 있음	서버 유지보수, 관리 부담이 사용자에게 있음
가용성	높은 가용성을 제공하며, 장애 복구성이 쉽음	서버 장애 시 복구하기가 어렵고, 백업 시스템을 구축해야 함
기능	다양한 AWS 서비스를 활용할 수 있음	제한된 기능으로 자체 구축해야 할 수 있음

온프레미스 객체 스토리지의 종류로는 Dell EMC 가 있다.

2) EBS

Amazon EBS는 Amazon EC2 인스턴스에서 사용하는 고성능 블록 스토리지 서비스로 영구 블록 스토리지 볼륨을 제공한다. EC2 인스턴스에서 HDD 및 SSD 유형처럼 인식되며, 사용자가 원하는 성능 제공이 가능합니다.

 

EBS의 특징

• EC2 인스턴스가 종료되어도 별개로 작동하여 데이터가 날아가지 않음
• 가용 영역 내에서 각 볼륨이 자동으로 복제됨
• 워크로드에 따라 비용 최적화가 가능한 다양한 볼륨 유형 제공
• 백업된 스냅샷에서 EBS 볼륨 생성 및 복원이 가능함
• DB, 파일 시스템 또는 원시 블록 수준 스토리지에 대한 액세스가 필요한 경우 적합

EBS는 언제 사용하나요?

단일 인스턴스에 대한 고성능 스토리지 서비스가 필요한 경우 사용

• 일반 온프렘 SSD, HDD:
  • 장점: 초기 비용이 낮고 온프렘 환경에서 신뢰성이 높습니다. 저장 공간 확장이 가능합니다.
  • 단점: 용량 확장성이 제한적이며, 높은 성능 유지와 데이터 보관이 어려울 수 있습니다.
• EBS (Amazon Elastic Block Store):
  • 장점: 높은 확장성과 유연성을 제공하며, AWS의 신뢰성 및 가용성을 활용할 수 있습니다. 보안 강화와 관리 서비스가 제공되며, 성능을 조정할 수 있습니다.
  • 단점: 초기 비용이 높고 클라우드 환경에서만 사용 가능합니다. 복잡한 비용 관리가 필요할 수 있습니다.

-> 시험 포인트:

1) EC2 instance와 함께 사용 가능

2) 요금 책정 (용량/스냅샷/데이터 이동/IOPS)

3) Persistent

4) Snapshot 기능

3) EFS

Amazon EFS는 AWS 클라우드 서비스 및 온프레미스 리소스와 함께 사용할 수 있는 간단하고 확장 가능한 서버리스 파일 시스템을 제공합니다. EFS는 리눅스 인스턴스를 위한 파일 스토리지로써 쉽게 말해 회사의 온프레미스 환경의 NFS, NAS 폴더와 유사한 서비스라고 생각하시면 됩니다.

 

EFS의 특징

• 완전 관리형 서비스로 파일 시스템을 쉽고 빠르게 생성 및 구성 가능
• 수천 개의 EC2에서 동시에 액세스 가능함
• 파일이 추가 또는 제거됨에 따라 자동으로 스토리지 용량을 즉시 확장하거나 축소
• 여러 가용 영역에 파일이 중복으로 저장되어 하나의 가용 영역이 파괴되더라도 다른 가용 영역에서 서비스가 제공 가능함
• 간단하고 용량 조절이 자유로운 ELASTIC 파일 저장소

EFS는 언제 사용하나요?

EFS는 여러 EC2 인스턴스에 대한 공유 파일 시스템이 필요한 워크로드에 적합합니다. 따라서 콘텐츠 관리 시스템을 위한 파일 스토리지에 사용하면 좋습니다.

 

장점

• 확장성: EFS는 클라우드 환경에서 제공되는 서비스로서, 필요에 따라 용량을 쉽게 확장할 수 있습니다. 반면, 온프레미스 NFS는 물리적 스토리지의 한계를 가질 수 있습니다.
• 유연성: EFS는 AWS의 다른 서비스와 쉽게 통합될 수 있으며, 멀티존 및 복제 옵션을 통해 데이터 가용성과 지속성을 높일 수 있습니다. NFS는 특정 온프레미스 환경에 바인딩되어 있습니다.
• 보안: EFS는 파일 수준의 보안을 제공하며, IAM 역할을 사용하여 액세스를 제어할 수 있습니다. NFS도 보안 설정을 지원하지만, 복잡한 보안 규칙을 구성하기는 더 어려울 수 있습니다.

단점

• 비용: EFS는 사용한 만큼 비용을 지불하는 구조로, 대규모 데이터 저장 및 처리 작업에서는 비용이 부담스러울 수 있습니다. NFS는 초기 투자 비용이 더 낮을 수 있지만, 장기적으로는 유지보수 및 업그레이드 비용이 발생할 수 있습니다.
• 네트워크 종속성: EFS는 네트워크 성능에 따라 파일 액세스 속도가 영향을 받을 수 있습니다. NFS도 마찬가지이지만, 온프레미스 환경에서는 네트워크 구성을 더 세밀하게 제어할 수 있습니다.
• -> 시험 포인트: 자동으로 크기를 조정하는 서비스 (Auto Scaling) Lambda, S3, EFS / 병렬접근 Multiple Node 구성

4) FSx

• 완전 관리형(Fully managed) 파일 시스템(스토리지) 서비스.
• 세계적으로 유명한 3rd Party 파일 시스템을 AWS에서 사용 할 수 있도록 하는 서비스이다.
• 아래의 4가지 3rd Party 파일 시스템을 지원한다
  • Windows File Server
  • Lustre
  • OpenZFS
  • NetApp ONTAP 9

기존의 온프레미스 환경에서 AWS 클라우드로 파일 서버를 이동하고자 할 때

Amazon FSx를 활용한다.

 

FSx는 EFS와 마찬가지로 주로 여러 EC2 인스턴스나 온프레미스에서 접근되는 파일 공유 스토리지로 사용된다.

그렇기 때문에 여러 EC2 인스턴스에서 접근 가능하며, 다른 AZ 에서도 접근이 가능하다

Fsx for Windows File Server

• Windows 전용 서비스 - 윈도우 시스템이 호환된다. (Fully Managed 파일 서버이다)
• 윈도우 서버가 제공하는 기능:
  • SMB(CIFS) 프로토콜로 통신: 윈도우의 컴퓨터 끼리 파일 공유나 프린터 공유에 사용되는 프로토콜
  • NTFS: (NT File System) Windows의 표준 파일시스템를 사용
  • AD: (Acitive Directory) Windows에서 도메인 단위로 유저나 컴퓨터를 관리
  • Windows ACL: ACL은 AD에 의해서 실행되는 접근제어 기능이다. 파일 또는 폴더의 리소스에 대해서 유저마다 접근 허가/거부가 가능
  • DFS, DFS Namespace, DFSR

DFS

FSx는 Microsoft 분산 파일 시스템(DFS, Distributed File System)를 지원한다

DFS란 윈도우 컴퓨터끼리 공유되고 있는 폴더을 한꺼번에 관리하는 기능이다.

• DFS를 통해 다중 AZ에 파일 시스템을 배포하여 가용성과 내구성을 확보한다.
• DFS Replication을 사용하면 두 파일 시스템 간에 데이터를 자동으로 복제할 수 있다.

CIFS와 SMB 프로토콜 = Windows OS

NFS = Linux OS

 

 AWS FSx  vs 온프레미스

확장성	높음 (필요에 따라 쉽게 확장 가능)	낮음 (물리적 스토리지의 한계를 가지며 확장성이 제한적)
유연성	높음 (온디맨드 방식으로 파일 스토리지를 프로비저닝 가능, 언제 어디서나 액세스 가능)	낮음 (물리적 스토리지의 용량을 초과하면 확장하기 어렵고, 데이터베이스나 애플리케이션의 성장과 요구에 적응하기 어렵음)
보안	높음 (AWS의 IAM과 VPC를 사용하여 파일 스토리지의 보안을 제어할 수 있으며, 데이터 보호 및 규정 준수 요구 사항을 충족할 수 있음)	중간 (물리적 보안과 내부 관리 관리를 통해 보안을 유지해야 하며, 보안 사고와 데이터 손실의 위험이 존재할 수 있음)
성능	높음 (SSD 기반 스토리지를 사용하여 높은 I/O 성능과 낮은 지연 시간을 제공)	중간 (네트워크 성능에 따라 파일 스토리지의 성능이 영향을 받을 수 있으며, 물리적 스토리지의 성능 한계를 가질 수 있음)
비용	높음 (클라우드 기반 파일 스토리지는 비용이 부담스러울 수 있으며, 사용량과 성능 요구 사항에 따라 비용이 달라질 수 있음)	중간 (초기 투자 비용이 적을 수 있지만, 장기적으로는 유지보수 및 업그레이드 비용이 발생할 수 있음)
관리	낮음 (AWS에서 관리 및 보안을 제공)	높음 (내부 IT 팀이 직접 관리해야 함)
네트워크 종속성	높음 (네트워크 대역폭과 지연 시간이 파일 스토리지의 성능에 영향을 미칠 수 있음)	낮음 (로컬 네트워크를 통해 높은 성능을 제공할 수 있음)

5) Storage Gateway

스토리지 게이트웨이는 온-프레미스 환경에서 직접 가상 머신 (VMware ESXi, Microsoft Hyper-V, Linux KVM)으로 배치되거나 사전 구성된 독립형 Hardware appliance로 배치될 수 있습니다. 또한, Storage Gateway에는 별도의 네트워킹이나 추가 하드웨어가 필요하지 않으며 다음을 제공합니다.

• NFS, SMB, iSCSI 및 iSCSI VTL과 같은 표준 스토리지 프로토콜을 지원하므로 기존 애플리케이션은 변경 없이 AWS 클라우드 스토리지 사용 가능
• 애플리케이션의 지연 시간이 짧은 액세스를 위한 로컬 캐시
• 온 프레미스와 AWS 클라우드 간의 최적화된 보안 데이터 전송
• 아마존 S3, 아마존 S3 Glacier, 그리고 아마존 EBS와 같은 다른 AWS 클라우드 스토리지 서비스와의 상호 운용성
• AWS 키 관리 서비스 (KMS), AWS ID 및 액세스 관리 (IAM), AWS CloudTrail, 아마존 CloudWatch 와 같은 다른 AWS 서비스와의 통합

Storage Gateway는 온-프레미스 인프라의 이점과 클라우드의 모든 이점을 결합합니다.

그림 2: Storage Gateway의 고급 아키텍처

Storage Gateway의 세 가지 일반적인 사용 사례에는 백업을 클라우드로 옮기고 온 프레미스 NAS 스토리지를 클라우드 지원 파일 공유로 옮기고 온 프레미스 애플리케이션에 대한 지연 시간이 짧은 액세스를 클라우드 데이터에 제공하는 것이 포함됩니다.

그림 3: 다양한 클라우드 도입 과정에서 배포할 수 있는 3 가지 일반적인 스토리지 게이트웨이 사용 사례

이러한 사용 사례를 지원하기 위해 AWS는 세 가지 다른 유형의 게이트웨이( 파일 게이트웨이 , 볼륨 게이트웨이 및 테이프 게이트웨이)를 제공합니다.

그림 4: 스토리지 게이트웨이는 파일 게이트웨이, 볼륨 게이트웨이, 테이프 게이트웨이의 세 가지 게이트웨이 유형으로 구성됩니다.

6) SnowBall

---

개념도

 On-premise에서 AWS로 대규모 데이터를 이관할 때 사용되는 Snowball에 대해서  알아보도록 하겠습니다.우리가 대규모 데이터를 전용선이나 VPN으로 옯길 경우, 비용과 시간이 어마 무시하게 발생하게 됩니다.때문에 Snowball이라는 이동 장비를 통해서 데이터를 이관하게 됩니다.

출처:

https://sh-t.tistory.com/91

[Start! AWS Business:티스토리]

3. Database

1) RDS

데이터 베이스 인프라 및 업데이트들을 AWS 측에서 관리해주고 데이터베이스의 설치, 운영 그리고 관리 등의 서비스들을 지원하는 AWS의 관계형 데이터베이스이다. 현재 AWS RDS는 MySQL, Oracle, SQL Server, PostgreSQL, MariaDB, Microsoft SQL Server 그리고 MySQL, PostgreSQL과 호환이 되는 Aurora DB를 제공한다. Aurora DB는 다른 관계형 데이터베이스보다 성능과 속도 면에서 빠르다는 이점을 가지고 있다.

AWS RDS와 온프레미스 MsSQL은 각각의 장단점을 가지고 있습니다. 클라우드의 편리함과 성능을 필요로 하는 애플리케이션에는 AWS RDS가 유리할 수 있고, 비용과 유연성을 고려하는 경우에는 온프레미스 MsSQL이 적합할 수 있습니다. 필요에 따른 적절한 선택이 중요합니다.

2) DynamoDB

DynamoDB는 AWS에서 제공하는 서버리스 기반 Key-Value NoSQL 데이터베이스입니다.

DynamoDB를 사용하면 높은 성능과 비용적인 측면에서 이점을 가져올 수 있습니다.

1. NoSQL 데이터베이스이다.
   • NoSQL 데이터베이스에서는 JOIN이라는 개념이 없습니다. 애플리케이션 레벨에서 구현할 수는 있지만 매우 비효율적이며 NoSQL 데이터베이스를 쓰는 이유랑 맞지도 않습니다.
   • JOIN이라는 개념이 없기 때문에 정규화도 거의 불가능합니다. 그래서 NoSQL에서는 보통 반정규화를 합니다.
   • **RDBMS(관계형 데이터베이스)**는 종류나 특성에 따라 테이블을 나눴지만, DynamoDB에서는 모두 하나의 테이블에 표현할 수 있습니다.
2. HTTP로 통신한다.
   • DynamoDB는 HTTP로 통신합니다.
   • 다른 DB 리소스들은 TCP Connection 기반인데 비해, DynamoDB는 Connectionless합니다.
3. 서버리스(Serverless)이다.
   • 서버리스이기에 DynamoDB를 위한 별도의 서버가 존재하지 않습니다. 따라서 요청한 만큼만 비용을 지불하면 됩니다.
   • AWS Lambda 같은 다른 서버리스 기반 서비스와 좋은 시너지를 낼 수 있습니다.
4. Key-Value 데이터베이스이다.
   • Key를 제외한 테이블의 속성을 미리 정의해둘 필요가 없습니다.
   • 따라서 데이터에 대해 미리 스키마가 만들어져 있어야 하는 RDBMS와 달리 DynamoDB는 유연하게 데이터를 처리할 수 있습니다

3) Elastic Cache

ElastiCache는 Fully managed 분산 인메모리(In-memory) 캐싱 서비스이다.

ElastiCache는 주로 성능을 중시하는 애플리케이션에서 사용된다.

데이터베이스나 다른 백엔드 스토리지에서 가져오는 데이터를 **캐싱(Cache)**하여 액세스 속도를 향상시키는 데 사용된다.

즉, ElastiCache는 쉽게 말해서 데이터를 더 빨리 가져오기 위한 메모리 기반의 저장소 서비스이다.

4. Networking

1) VPC

 

 

 

 

 AWS VPC vs 기존 온프렘

NAT GW 와 F5 proxy 비교

1. 주요 기능:
   • NAT GW는 주로 IP 주소 변환과 네트워크 보안을 제공하는 반면, F5 Proxy 장비는 부하 분산, 보안, SSL 종료 등의 기능을 제공합니다.
2. 사용 사례:
   • NAT GW는 가정용 라우터나 기업 네트워크에서 널리 사용됩니다. F5 Proxy 장비는 대규모 웹 애플리케이션 환경에서 사용됩니다.
3. 성능:
   • F5 Proxy 장비는 고성능 트래픽 처리와 부하 분산에 최적화되어 있어, 대규모 웹 트래픽을 처리하는 데 더 적합합니다.
4. 보안:
   • 둘 다 보안 기능을 제공하지만, F5 Proxy 장비는 더 다양한 보안 위협으로부터 보호할 수 있으며, 웹 애플리케이션 계층에서의 보안을 강화할 수 있습니다.
5. 복잡도:
   • NAT GW는 설정과 운영이 비교적 간단하며, 네트워크의 기본 기능을 제공하는 데 중점을 둡니다. F5 Proxy 장비는 더 복잡한 구성과 운영이 필요하지만, 더 많은 고급 기능을 제공합니다.

2) Route53

Route 53은 AWS에서 제공하는 DNS 웹서비스입니다. 도메인과 관련된 다양한 서비스를 제공합니다. 그렇다면 DNS는 무엇일까요? 각각의 컴퓨터는 IP라는 고유의 주소를 가지고 있습니다. 하지만 IP는 숫자로 되있기 때문에 사람이 기억하기 힘듬니다. 네이버라는 웹사이트를 들어갈때 우리는 naver.com이라는 주소를 치고 들어갑니다. 이때 naver.com이 사람이 기억하기 쉬운 Domain입니다.

여기서 DNS(Domain Name Server)라는 것을 알아야합니다. DNS는 도메인과 도메인에 해당하는 IP 정보를 가지고 있다가 도메인 주소에 대한 요청이 들어왔을 때 이에 해당하는 ip를 알려주는 서버입니다. 마치 친구의 이름에 해당하는 번호를 가지고있는 전화번호 주소록 같은 역할을 합니다.

온프레미스 DNS 서버와 Amazon Route 53에는 몇 가지 주요 차이점이 있습니다. 이러한 차이점은 안정성, 확장성, 기능, 비용 등 여러 측면에서 나타납니다. 다음은 두 서비스의 주요 차이점들입니다:

1. 구성 및 관리 방식:
   • 온프레미스 DNS 서버: 자체적으로 DNS 서버 하드웨어와 소프트웨어를 구매, 구성 및 유지 관리해야 합니다. 이는 추가적인 초기 비용과 기술 인력을 요구합니다.
   • Amazon Route 53: fully managed 서비스로, AWS가 서버 유지 관리, 업데이트, 보안 패치 등을 담당합니다. 사용자는 API 호출이나 AWS 콘솔을 통해 간편하게 사용할 수 있습니다.
2. 확장성 및 성능:
   • 온프레미스 DNS 서버: 물리적 서버의 성능과 용량에 한계가 있습니다. 트래픽이 증가하면 추가 서버를 구매하고 설정해야 합니다.
   • Amazon Route 53: 거의 제한 없는 확장성을 제공합니다. AWS의 글로벌 인프라를 활용하여 대량의 트래픽을 처리할 수 있으며, 자동으로 부하를 분산시킵니다.
3. 가용성과 내구성:
   • 온프레미스 DNS 서버: 단일 장애 지점이 존재합니다. 서버가 다운되면 DNS 서비스가 중단됩니다. 추가적인 고가용성 설정이 필요합니다.
   • Amazon Route 53: 고가용성을 위해 설계되었습니다. 여러 가용 영역에 걸쳐 복제된 서비스를 제공하여 장애에 탄력적으로 대응할 수 있습니다.
4. 기능 및 통합:
   • 온프레미스 DNS 서버: 기본적인 DNS 기능을 제공하지만, 고급 기능은 부족할 수 있습니다.
   • Amazon Route 53: DNS 뿐만 아니라 로드 밸런싱, 지리적 라우팅, Traffic Flow 등의 고급 기능을 제공합니다. 다른 AWS 서비들과 원활하게 통합됩니다.
5. 보안:
   • 온프레미스 DNS 서버: 보안 취약성에 따라 공격자가 DNS 서버를 공격할 위험이 있습니다.
   • Amazon Route 53: 보안 패치 자동 업데이트 및 AWS의 전반적인 보안 인프라를 통해 보안 취약성을 줄입니다.
6. 비용:
   • 온프레미스 DNS 서버: 초기 하드웨어 및 소프트웨어 비용, 유지보수 비용, 전기 및 냉각 비용 등이 발생합니다.
   • Amazon Route 53: 사용량 기반의 요금 모델을 제공하여 비용을 최적화할 수 있습니다. 관리, 유지보수, 전기, 냉각 등의 비용이 필요하지 않습니다.
7. 기술 및 지원:
   • 온프레미스 DNS 서버: DNS 서버 자체를 관리해야 하며, 기술 인력에 따라 성능이 달라질 수 있습니다.
   • Amazon Route 53: AWS의 전문적인 지원과 최적의 기술 지원을 받을 수 있습니다.

온프레미스 DNS 서버와 Amazon Route 53의 선택은 조직의 요구사항, 예산, 기술 역량 등에 따라 달라질 수 있습니다. 그러나 확장성, 성능, 가용성, 보안 등을 고려할 때, Amazon Route 53는 더 강력한 옵션으로 평가받고 있습니다.

3) LB (ALB,NLB)

ALB는 주로 HTTP/HTTPS 트래픽을 처리하는 데 사용되며, 애플리케이션 계층에서의 로드 밸런싱을 제공한다. 반면, NLB는 TCP/UDP 트래픽을 처리하며, 네트워크 계층에서의 로드 밸런싱을 제공한다. 왜냐하면 ALB와 NLB는 각각 다른 계층에서 동작하기 때문이다.

ALB와 NLB는 각각의 특성과 용도에 따라 선택적으로 사용된다. 왜냐하면 ALB는 애플리케이션 계층에서의 로드 밸런싱을 제공하고, NLB는 네트워크 계층에서의 로드 밸런싱을 제공하기 때문이다.

이제 AWS ALB와 NLB의 기본 개념과 차이점에 대해 자세히 알아보자. 왜냐하면 이를 통해 애플리케이션의 요구사항에 맞는 로드 밸런서를 선택할 수 있기 때문이다.

 

 

ALB

LB는 주로 웹 애플리케이션에서 사용된다. 왜냐하면 ALB는 HTTP/HTTPS 트래픽을 처리하며, URL 경로 기반 라우팅과 호스트 기반 라우팅을 지원하기 때문이다. 이를 통해 다양한 웹 애플리케이션을 효과적으로 관리할 수 있다.

 

 

NLB

NLB는 주로 높은 성능을 요구하는 애플리케이션에서 사용된다. 왜냐하면 NLB는 매우 낮은 지연 시간을 제공하며, 정적 IP 주소와 TLS 종료를 지원하기 때문이다. 이를 통해 높은 성능을 요구하는 애플리케이션을 효과적으로 관리할 수 있다.

https://f-lab.kr/insight/understanding-aws-alb-and-nlb-20240516

AWS ALB와 NLB의 차이점 이해하기

 

요소 온프레미스 L4 라우터 AWS ALB AWS NLB

작동 계층	L4 (전송 계층)	L7 (애플리케이션 계층)	L4 및 L7
부하 분산 기준	IP 주소, 포트 번호	URL, HTTP 헤더, 쿼리 문자열	TCP/UDP 프로토콜
고급 기능 지원	아니요	예 (트래픽 관리, SSL 종료, 웹Socket 등)	아니요
확장성	제한적	뛰어난 확장성	높은 처리 용량
내결함성	제한적	예 (자동 확장, 장애 백업 등)	예 (자동 확장, 장애 백업 등)
보안	기본적인 보안	고급 보안 기능	고급 보안 기능
통합 및 관리 서비스	제한적	AWS 서비스 통합, 모니터링	AWS 서비스 통합, 모니터링
적합한 사용 사례	소규모 환경, 특정 사용 사례	웹 애플리케이션, 마이크로서비스	고성능 애플리케이션, 게임

기능은 같은데, 확장성의 차이 같다.

4) Transit Gateway

Transit Gateway는 VPC Peering과 마찬가지로 서로 다른 VPC간에 통신이 가능하게 하는 서비스입니다.

VPC Peering은 1 대 1 VPC 연결만 지원하여 직접적으로 연결되어있지 않은 VPC에 바로 접근할 수 없었다면 Transit Gateway는 중앙 허브를 통해 여러 VPC간 연결 정책을 중앙에서 관리할 수 있고, VPN을 통해 VPC와 온프레미스 네트워크를 연결할 수 있습니다.

• 중앙 허브와 VPN을 통해 VPC와 온프레미스 네트워크를 연결할 수 있습니다.
• 복잡한 피어링 관계를 제거하여 네트워크를 간소화 시킬 수 있습니다.
• 클라우드 라우터 역할을 하므로 새로운 연결을 한 번만 추가하면 됩니다.
• 다른 리전간의 Transit Gateway와 피어링 연결이 가능합니다.

Transit Gateway를 사용하면 중앙허브를 통해 위 인프라를 더욱더 관리하기 쉽고 확장성있는 구조로 변경할 수 있습니다.

VPC를 Transit Gateway에 연결해주기만하면 Transit Gateway에 연결된 모든 다른 VPC와 통신이 가능하게 됩니다.

또한 CGW(Customer Gateway)와 Transit Gateway를 연결하게 되면 Transit Gateway에 연결된 VPC는 VPN을 통해 온프레미스 네트워크와도 통신이 가능합니다.

따라서 연결해야하는 VPC 개수가 많으며, 온프레미스와의 VPN연결 까지 관리해야한다면 Transit Gateway를 사용하는 것이 관리적인 측면에서 훨씬 유리 합니다.

비용

같은 조건을 기준으로 Transit Gateway를 사용하는 것이 VPC Peering을 사용하는 것보다 약 1.5배 정도 비쌉니다.

Transit Gateway 요금과 관련된 정보는 아래 사이트를 통해 확인하실 수 있습니다.