[AWS] 클라우드 비용의 계엄이 선포됐다! - Data Transfer 비용 아끼기

해당 글은 AWS 범용 클라우드 아키텍처의 데이터 전송 비용 알아보기을 거의 다 참고했습니다!

 

클라우드 비용 절약은 IT 회사라면 늘 풀어야 할 숙제입니다. 어떻게 보면 풀 수 없는 숙제이기도 합니다.

 

그리고 AWS 클라우드와 EKS 를 운영하는 입장에서 비용은 적으면 적을수록 당연히 좋죠. 일부러 비용을 많이 나오게 하려는 엔지니어는 없을겁니다!

 

하지만... 결국 "누구에게나 그럴듯한 계획은 있다, 비용 청구서를 받기 전까지는" 같은 상황이 펼쳐집니다.

누구에게나 그럴듯한 계획은 있다, 비용 청구서를 받기 전까지는

 

클라우드 비용 측면으로 봤을 때 크게 2가지로 나눌 수 있을 것 같습니다.

데이터 전송량(Data Transfer)과 리소스 사용량(Resource Usage) 입니다.

 

이번 글에서는 AWS 에서 데이터 전송 비용을 아낄 수 있는 방법에 대해 설명하고자 합니다.

 

그럼 렛츠두더 코드~

 

 

AWS Data Transfer 란?

---

AWS 에서 말하는 Data Transfer(데이터 전송)란, AWS 서비스나 인터넷끼리 주고 받는 데이터를 말합니다.

 

데이터 전송은 다음과 같은 상황에 따라 비용이 달라지는데,

• Source/Destination 리전
• 데이터 전송의 종류
• AWS 서비스의 종류(S3, EC2, RDS ...)
• 데이터 전송의 양

입니다.

 

큰 그림으로 보자면 아래와 같이 부과됩니다.

출처 - https://www.nops.io/blog/how-to-reduce-aws-data-transfer-costs-best-practices/

 

그런데 기본적으로 모든 AWS 리전의 모든 서비스 인바운드에 대한 전송은 요금이 부과되지 않습니다.

하지만, AWS 에서 인터넷상으로의 아웃 바운드에 대한 데이터 전송을 요금이 부과됩니다.

 

예를 들어, S3 버킷에 오브젝트를 업로드 하는 인바운드에 대한 데이터 전송은 요금이 부과되지 않는 반면, 반대로 S3 버킷에서 오브젝트를 다운로드 하는 아웃바운드에 대한 데이터 전송은 요금이 부과됩니다.

 

그럼 좀 더 자세하게 살펴보죠!

 

같은 AWS 리전 내 데이터 전송

---

인터넷 게이트웨이로 같은 리전 내에 있는 S3, DyanmoDB 같은 AWS 서비스에 접근하는 경우(인바운드)는 비용이 부과되지 않습니다.

출처 - https://aws.amazon.com/ko/blogs/korea/overview-of-data-transfer-costs-for-common-architectures/

여기서 말하는 AWS 서비스는 AWS Managed 서비스를 말합니다.
EC2, RDS, EFS 같은 서비스들은 포함되지 않습니다.

 

이번에는 NAT 게이트웨이를 통해서 접근할 경우입니다.

 

Private Subnet 에 있는 인스턴스일 경우 인터넷에 접근하려면 NAT 게이트웨이를 통해서 나가게 되는데, 이때 NAT 게이트웨이에 대한 요금만 부과됩니다.

출처 - https://aws.amazon.com/ko/blogs/korea/overview-of-data-transfer-costs-for-common-architectures/

빨간색은 비용이 부과됨을 의미합니다.

 

하지만 NAT Gateway 를 지나서 Internet Gateway 로 뻗어나갈 땐 여전히 요금이 부과되지 않습니다.

 

다음은 다중 가용 영역에서 요금 부과는 어떨지 살펴보겠습니다.

 

기본적으로 같은 가용 영역에서는 요금이 부과되지 않고, 다른 가용 영역일 경우 요금이 부과됩니다.

 

아래 그림을 보면 더 쉽게 이해가 가능합니다.

출처 - https://aws.amazon.com/ko/blogs/korea/overview-of-data-transfer-costs-for-common-architectures/

 

1번의 경우, 가용 영역(AZ) 이 서로 다르기 때문에 인바운드/아웃바운드 상관 없이 요금이 부과됩니다.

 

2번의 경우, 마찬가지로 가용 영역(AZ) 이 서로 다르기 때문에 인바운드/아웃바운드 상관 없이 요금이 부과됩니다.

 

3번의 경우, 가용 영역(AZ) 이 같기 때문에 요금이 부과되지 않습니다.

 

4번의 경우, 사실 가용 영역이 달라서 요금이 부과되어야 하지만 RDS 특성상 기본 인스턴스와 대기 인스턴스 간의 복제 시 추가 데이터 전송 요금은 부과되지 않는다고 합니다.

출처 - https://aws.amazon.com/ko/blogs/korea/overview-of-data-transfer-costs-for-common-architectures/

 

 

워크로드의 고가용성을 위해서라면 최소한 서로 다른 가용 영역에 둬야겠지만... 비용을 아끼기 위해 단일 가용 영역에..

설마 데이터센터에 불이 나겠어??!! 날수도???? 나면 어떡하지...

 

 

다음은 가용 영역 내 VPC 통신에 대해 살펴보겠습니다.

 

보통 VPC 간 통신을 하기 위해서는 VPC Peering 과 Transit Gateway 를 많이 사용합니다.

 

VPC Peering 의 경우, 다행히? 같은 가용 영역이라면 요금이 부과되지 않습니다.

출처 - https://aws.amazon.com/ko/blogs/korea/overview-of-data-transfer-costs-for-common-architectures/

 

하지만, 다른 가용 영역이라면 요금이 발생합니다.

 

이번엔 Transit Gateway 의 경우입니다.

 

Transit Gateway 는 여러 VPC 간 통신을 도와주는 아주 고마운 서비스이면서, 그만큼 수고비도 받는 서비스입니다.

 

NAT Gateway 처럼 게이트웨이를 지나가는 데이터에 대해 요금을 부과합니다.

 

VPC 가 엄청나게 복잡하지 않는다면 VPC Peering 을 사용하는 것이 비용 절감에 도움을 줄 수 있고, 가용 영역까지 단일로 간다면 VPC 레벨에서의 데이터 전송 요금은 부과되지 않겠네요!

 

 

다른 AWS 리전 사이 데이터 전송

---

AWS 리전이 다르다...

뭘하든 요금은 부과된다라고 먼저 생각하시면 쉽습니다.

 

서로 다른 리전일 경우, AWS 서비스에 접근하는 것조차 요금이 부과됩니다.

같은 리전일 경우(인바운드에 대해)에는 요금이 부과되지 않았던 부분이죠!

출처 - https://aws.amazon.com/ko/blogs/korea/overview-of-data-transfer-costs-for-common-architectures/

 

서로 다른 리전이기 때문에 VPC Peering 에 대해서도 요금이 부과되고,

출처 - https://aws.amazon.com/ko/blogs/korea/overview-of-data-transfer-costs-for-common-architectures/

 

서로 다른 리전이기 때문에 Transit Gateway 는 더더욱 비싼 요금이 부과됩니다.

출처 - https://aws.amazon.com/ko/blogs/korea/overview-of-data-transfer-costs-for-common-architectures/

 

당연한 소리지만, 최대한 리전은 나누지 않는 것이 비용 절감에 도움이 됩니다.

그런데, 누가 이유없이 리전을 나누지..??

"와 비즈니스적인 이유로도 리전을 나눌 필요가 없는데, 나는 그냥 리전을 나누고 싶어!"
하는 사람은 없겠죠..??

 

 

AWS 와 온프레미스 간 데이터 전송

---

역시나 온프레미스 역시 데이터 전송에 대한 요금이 부과됩니다!

 

Site-to-Site 도 요금이 부과되고,

출처 - https://aws.amazon.com/ko/blogs/korea/overview-of-data-transfer-costs-for-common-architectures/

 

Direct Connect 도 요금이 부과됩니다.

출처 - https://aws.amazon.com/ko/blogs/korea/overview-of-data-transfer-costs-for-common-architectures/

 

 

Saving Plan

---

지금까지 살펴본 내용으로는 이렇게 요약해 볼 수 있을 것 같습니다.

 

결국 다른 리전, 다른 가용 영역이라면 데이터 전송에 대한 요금이 부과되니 가능만 하다면 하나의 리전에 하나의 가용 영역에 인프라를 구성할 것!

 

따라서,

• AZ 단위의 워크로드 고가용성이 필요없다면 하나의 가용 영역을 사용할 것!
• NAT Gateway 는 정말 필요한 서브넷에만 붙일 것!
• Transit Gateway 보다는 VPC Peering 을 활용할 것!

이건 추가적인 팁입니다.

• S3 버킷이나 EFS 내에서 라이프 사이클을 이용해서 오래된 오브젝트나 데이터는 Freeze 시킬 것!
• Route53 에서 내부에서만 사용하는 도메인이라면 Private Hosted Zone 을 사용할 것!
• S3, DynamoDB 는 AWS PrivateLink Gateway 를 이용해서 인터넷이 아닌 내부 네트워크 망 사용하게 할 것!

 

이상입니다.

 

다음에는 AWS 클라우드에서 더 나아가 kubecost 를 활용해 쿠버네티스 클러스터의 비용 절감을 다뤄보도록 하겠습니다.

 

그럼 오늘은 여기까지!

 

Referenecs

---

https://aws.amazon.com/ko/blogs/korea/overview-of-data-transfer-costs-for-common-architectures/

https://www.cloudzero.com/blog/reduce-data-transfer-costs/

https://www.nops.io/blog/how-to-reduce-aws-data-transfer-costs-best-practices/

https://aws.amazon.com/ko/route53/pricing/

https://www.megazone.com/techblog_191113_aws-privatelink/

https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/gateway-endpoints.html

https://aws.amazon.com/ko/blogs/aws/optimize-storage-cost-with-reduced-pricing-for-amazon-efs-infrequent-access/