AWS에서 데이터 전송 비용 대폭 절감하기

 (bitsand.cloud)
5P by GN⁺ | ★ favorite | 댓글 1개
  • AWS의 같은 리전 내 가용 영역 간 전송은 송신·수신 양쪽에 GB당 $0.01씩 붙어 1TB 직접 전송에 약 $20가 들지만, S3를 임시 경유지로 쓰면 비용을 센트 단위까지 낮출 수 있음
  • 표준 S3 버킷은 리전 단위로 동작하고 AWS가 리전 내 최소 3개 가용 영역에 복제하므로, 같은 리전의 여러 AZ에서 동일하게 접근 가능함
  • EC2가 같은 리전의 S3에 업로드하고 다른 AZ에서 다운로드하면 데이터 전송 요금은 무료이며, 실제 비용은 짧은 보관 시간의 S3 스토리지 비용과 API 요청 비용으로 좁혀짐
  • us-east-1에서 1TB를 1시간 미만 보관하면 S3 Standard $23/TB-month의 1/720인 약 $0.03만 들고, 1PB도 직접 전송 $20,000 대신 약 $32 수준으로 줄어듦
  • 이 방식은 네트워크 전송 코드의 드롭인 대체재가 아니고 지연 시간이 커질 수 있지만, 비용이 최우선인 대량 cross-AZ 전송에는 99% 이상 절감 효과를 낼 수 있음

AWS 데이터 전송 비용이 커지는 지점

  • AWS에서 데이터를 부주의하게 옮기면 전송 비용이 빠르게 누적됨
  • 작성 시점 기준 주요 데이터 전송 요금은 다음과 같음
    • AWS에서 공용 인터넷으로 나가는 전송은 us-east-1에서 GB당 $0.09, af-south-1에서 GB당 $0.154까지이며, 1TB 전송 비용은 $90~$154임
    • 한 AWS 리전에서 다른 리전으로 나가는 전송은 us-east-1에서 GB당 $0.02, af-south-1에서 GB당 $0.147까지이며, AWS 네트워크를 벗어나지 않아도 1TB에 $20~$147이 들 수 있음
    • 같은 리전의 서로 다른 가용 영역 간 전송은 방향마다 GB당 $0.01이며, 1TB를 us-east-1a에서 us-east-1b로 보내면 송신 $10과 수신 $10으로 총 $20가 됨
  • 인터넷 전송과 리전 간 전송은 나가는 데이터에 대한 egress 요금만 내지만, 같은 리전 내 AZ 간 전송은 양방향으로 비용이 붙음
  • 여러 가용 영역에 리소스를 배치하는 구성은 안정성과 가용성을 높이지만, 서로 다른 AZ의 리소스가 데이터를 주고받으면 cross-AZ 비용이 발생함

PrivateLink와 VPC 엔드포인트 주의점

  • EC2 인스턴스에서 다른 리전의 공용 S3 버킷으로 1TB를 전송하면, 기대한 리전 간 전송 비용 $20 대신 인터넷 egress 비용 $90이 나올 수 있음
  • AWS PrivateLink와 VPC 엔드포인트는 리전 간 데이터가 AWS 네트워크를 벗어나지 않도록 보장해 가격과 보안 측면에서 유용함
  • 다만 이 기능들은 무료가 아니며, 자체 제한과 요금 세부사항이 있음
  • 관련 자료

S3로 cross-AZ 전송 비용 우회하기

  • 대부분의 S3 스토리지 클래스는 버킷을 가용 영역이 아니라 리전 단위로 저장함
    • 사용자는 us-east-1a나 us-east-1b 버킷이 아니라 us-east-1 버킷에 업로드함
    • AWS는 내부적으로 데이터를 리전 내 최소 3개 가용 영역에 복제함
  • 표준 S3 버킷의 데이터는 같은 리전의 모든 AWS 가용 영역에서 동일하게 접근 가능하며, us-east-1a에서 다운로드하든 us-east-1b에서 다운로드하든 S3 입장에서는 차이가 없음
  • S3 Standard에서 같은 리전 내 다운로드는 무료이고, 다른 리전이나 공용 인터넷으로 다운로드할 때 일반 데이터 전송 요금이 붙음
  • S3 업로드는 모든 스토리지 클래스에서 데이터 전송 비용이 무료임
    • 다만 S3 API 요청 비용은 발생함
    • 요청 비용은 상대적으로 작음

1TB와 1PB 비용 계산

  • us-east-1a의 EC2 인스턴스에서 us-east-1b의 EC2 인스턴스로 1TB를 직접 보내면 $20가 듦
  • 같은 데이터를 S3에 업로드한 뒤 다른 AZ의 인스턴스가 다운로드하면 업로드와 다운로드의 데이터 전송 비용은 무료임
  • 남는 비용은 S3 스토리지 비용임
    • us-east-1의 S3 Standard 스토리지는 GB당 월 $0.023, 즉 TB당 월 $23임
    • 과금은 시간 단위로 계산됨
    • 데이터가 S3에 1시간 미만만 남도록 설계하면 720시간 기준 $23의 1/720인 약 $0.03가 됨
    • 전송 후 S3 객체를 삭제해야 함
  • 이 계산에서 전송 비용은 GB당 $0.02에서 $0.000032/GB로 내려가며, 원래 요금의 0.15% 수준임
  • 극단적인 예로 1PB 전송은 표준 방식의 $20,000 대신 이 방식으로 약 $32가 듦

확장성과 제약

  • S3는 확장성이 높아 한 AZ에서 업로드한 객체를 다른 AZ의 많은 인스턴스가 동시에 다운로드하는 형태에도 적합함
    • 두 번째 AZ의 수천 개 인스턴스가 같은 S3 객체를 다운로드할 수 있음
    • S3 스토리지 비용은 동일하게 유지됨
    • 다운로드 비용도 무료로 유지됨
  • S3 객체 크기에는 제한이 있음
    • 단일 객체는 5TB를 넘을 수 없음
    • 5TB보다 큰 파일은 분할해야 함
    • 단일 업로드는 5GB를 넘을 수 없으므로 더 큰 파일은 멀티파트 업로드가 필요함
    • aws s3 cp는 멀티파트 업로드를 내부적으로 처리함
  • S3 One Zone-Infrequent Access와 S3 Express One Zone은 데이터를 단일 가용 영역에만 저장함
    • 저장 비용은 낮지만 가용성 측면의 대가가 있음
    • us-east-1에서 S3 One Zone-Infrequent Access는 GB당 $0.01이고, S3 Infrequent Access는 GB당 $0.0125임
    • S3 One Zone-Infrequent Access는 99.5% 가용성, S3 Infrequent Access는 99.99% 가용성을 목표로 설계됨

실험 구성과 확인된 비용

  • 실험은 비용 노이즈를 줄이기 위해 각 파트마다 새 AWS 계정 2개를 사용함
  • 각 계정에는 us-east-1a와 us-east-1b에 EC2 인스턴스 2개를 두고, us-east-1a 인스턴스에서 임의의 1TB 파일을 생성함
  • 두 가지 방식을 비교함
    • 첫 번째는 두 AZ의 프라이빗 서브넷이 있는 VPC에서 us-east-1b 인스턴스에 netcat 서버를 띄우고, us-east-1a 인스턴스가 1TB 파일을 직접 전송함
    • 두 번째는 S3 Gateway endpoint가 있는 VPC에서 S3 버킷을 만들고, us-east-1a 인스턴스가 1TB 파일을 업로드한 뒤 us-east-1b 인스턴스가 다운로드하고 삭제함
  • AWS 프리 티어가 실험 결과에 약간 영향을 줄 수 있음
    • S3 프리 티어는 12개월 동안 5GB-months임
    • 5GB-months는 1TB-hours보다 작지만 큰 차이는 아님
  • Cost Explorer 업데이트 후 직접 전송 실험은 예상 $20에 가까운 $21.49가 나옴
    • 전송을 한 번 중단하고 재시작한 점이 추가 비용 일부를 설명함
    • 생성된 파일은 기술적으로 1024GB라 기본 비용은 $20.48임
  • S3 기반 전송 실험은 처음에 $0.08로 확인됐고, 데이터 전송 비용은 나타나지 않음
  • 이후 S3 스토리지 비용은 버킷별 일 단위로 보고되며 Cost Explorer 반영이 다른 비용보다 늦다는 점이 확인됨
    • 예상대로 보고된 스토리지 비용은 몇 센트 수준임
    • S3 스토리지 프리 티어는 완전히 소진됨
    • 이 가능성은 FinOps 커뮤니티의 Dieter Matzion이 알려줌

언제 쓸 만한가

  • AWS는 S3 데이터를 내부적으로 가용 영역 간 복제하며, 그 비용은 사용자가 지불하는 S3 스토리지 비용에 포함되어 있음
  • S3를 경유하는 방식은 업로드 시점에 cross-AZ 비용을 간접적으로 지불한 상태를 활용함
  • 데이터를 S3에 오래 보관하면 cross-AZ 직접 전송보다 훨씬 비싸질 수 있음
  • 전송 직후 객체를 삭제하면 목표한 99% 비용 절감이 가능함
  • 단점도 분명함
    • 기존 데이터 전송 코드의 드롭인 대체재가 아님
    • 직접 네트워크 연결보다 지연 시간이 훨씬 높을 수 있음
  • 비용이 최우선인 경우에는 AWS에서 cross-AZ 데이터 전송 비용을 99% 이상 줄이는 실용적인 방법이 될 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 제 트릭을 공유하자면, Lightsail 인스턴스를 다른 AWS 리소스, 예를 들어 EC2 인스턴스나 S3 버킷의 데이터를 “프록시”하는 데 쓸 수 있음
    각 Lightsail 인스턴스에는 가격에 포함된 데이터 전송량이 있고, $3.5 인스턴스는 1TB, $5는 2TB, $10은 3TB, $20은 4TB, $40은 5TB를 제공함
    전송량당 가격으로는 $10 인스턴스의 3TB가 가장 좋음
    글의 데이터를 기준으로 EC2에서 3TB 트래픽은 us-east-1에서 $276.48, S3 버킷에서는 $69가 듦
    단점은 Lightsail에서는 인바운드와 아웃바운드 트래픽이 모두 “트래픽”으로 계산된다는 것임

    • https://aws.amazon.com/service-terms/
      AWS 약관 51.3에 따르면, 다른 서비스의 데이터 요금을 피하려는 방식으로 Amazon Lightsail을 쓰면 안 된다고 되어 있음
      예를 들어 다른 서비스에서 공용 인터넷이나 다른 목적지로 네트워크 트래픽을 프록시하거나, 로드 밸런싱/CDN 서비스를 통해 과도하게 데이터를 처리하는 경우가 해당되고, 위반 시 데이터 서비스를 제한하거나 계정을 정지할 수 있음
    • 또 다른 방법으로, CloudFront 무료 티어를 쓰면 AWS에서 매달 1TB를 무료로 다운로드할 수 있음
      S3나 원하는 HTTP 서버를 원본으로 지정하면 됨
      예전에는 첫 12개월 동안 월 50GB였지만, Cloudflare가 https://blog.cloudflare.com/aws-egregious-egress를 올린 직후 영구 무료 1TB로 바뀌었음
    • 세부적으로는 $5에 2TB가 $10에 3TB보다 더 좋음
    • 좋은 트릭이긴 하지만, AWS 약관 때문에 불장난에 가까움

  • GCP도 2023년에 비슷한 허점을 막았고, 아마 일부 고객이 악용했기 때문일 가능성이 큼
    이 방식이 충분히 널리 퍼지면 AWS도 똑같이 할 것으로 봄
    https://cloud.google.com/storage/pricing-announce#network

    • 가능성은 낮아 보임
      GCP가 막은 “허점”은 GCS로 같은 대륙 내 리전 간 데이터 전송을 무료로 할 수 있던 것이었고, AWS에서는 이미 유료임
      원글에서 말한 건 같은 리전 안의 가용 영역 간 전송도 GB당 $0.02가 들며, 이를 우회할 수 있다는 내용임
    • GCP에서 데이터를 무료로 빼내는 방법을 알고 있긴 한데 실제로 시도해 보진 않았음
      이 정보를 살 구매자를 찾을 수 있을지 궁금함
    • 이건 허점이라기보다, AWS가 S3를 최적화해 두고 EC2 인스턴스가 S3를 저장소로 쓰길 의도한 것처럼 느껴짐
      다만 전송 창구로 쓰는 건 아닐 수 있고, 데이터를 거기에 넣고 계속 두기를 기대하는 쪽에 가까움

  • 비용을 줄이고 리소스를 공짜로 얻는 이런 트릭은 아주 많음
    영리하긴 하지만 신뢰할 수는 없음
    OSS 저장소를 통해 GitHub Actions에서 암호화폐 채굴을 하게 되는 식의 해킹과 같은 종류임
    흥미로운 해킹 연습 정도로 다루되, 이런 해법을 프로덕션에 배포하지는 않는 게 좋음
    적어도 계정 담당자의 승인은 받아야 하며, 아니면 어느 날 AWS 계정이 종료된 상태로 깨어날 위험이 있음

    • 이 방법과 다른 기법들을 수년간 써 왔지만 한 번도 차단당한 적 없음
      S3를 거치는 방식은 여러 목적지로 데이터를 배포할 때 동기화 프로세스를 돌리는 것보다 일반적으로 더 효율적이기도 함

  • S3 저장 비용은 GB-월 단위로 청구되므로, 1TB × GB당 $0.023 ÷ 월 730시간이면 버킷에 한 시간 둔 경우 약 3센트가 되어야 함
    다만 거의 바로 삭제된 것으로 보이니, 데이터가 1분 정도 있었다면 0.03 ÷ 60 수준일 수 있음
    보통은 AWS가 이를 $0.01로 올림 처리할 것으로 예상함
    비용 및 사용량 보고서의 TimedByteStorage 값이 최종 판단 기준이 됨
    https://handbook.vantage.sh/aws/services/s3-pricing/

  • S3도 좋은 트릭이고, 추가로 더 있음
    큰 AWS 고객, 예를 들어 연 $100만 이상 쓰는 고객이라면 할인을 요청할 수 있음
    한때는 가용 영역 간 전송 할인이 매우 컸음
    가능한 한 한 가용 영역에 모으는 것도 방법임
    DB는 “b” 영역에 있고 유일한 서버는 “a” 영역에 있는 구성은 그냥 한 영역으로 표준화하는 것보다도 나쁨
    여러 가용 영역을 쓸 때는 부하를 인식하는 가용 영역 밸런싱을 해야 함

    • “DB는 b 영역, 유일한 서버는 a 영역” 같은 구성이 쓰일 사례가 있긴 하겠지만 상상이 잘 안 됨
      비용 때문인가? 그런데 비용 절감도 아닌 듯함
    • 4번으로 S3 Intelligent-Tiering 스토리지 클래스를 켜는 것도 가능함

  • 이건 기술판 조세 회피처럼 느껴짐
    너무 많은 사람이 이렇게 하면 AWS가 “그냥 허점을 닫아버릴” 것임
    AWS는 하나가 아니라, 각자 KPI를 가진 수십 또는 수백 개의 AWS에 가까움
    어떤 팀은 지출을 줄이길 원하지만, 실제로 지출을 줄이는 법까지 알려주지는 않음
    AWS처럼 충분히 복잡한 것을 만들면 모든 것이 서로 얽혀 있어서 고객이 어떤 한 요소만 최적화하는 건 불가능해짐

    • 이건 허점이 아니라 의도된 설계임
      AWS는 특정 서비스를 특정 방식으로 쓰길 원하고, 그래서 그렇게 쓰면 매우 싸게 만들어 둠
      S3 엔드포인트를 쓰는 것도 AWS가 S3 서비스를 쓰길 원하는 방식 중 하나임
      CloudFront도 또 다른 예임
      AWS는 CloudFront를 쓰길 원하므로, CloudFront를 다른 데이터 아웃바운드보다 더 싸게 만듦

  • 복잡한 클라우드 비용 최소화 시스템의 대안은 그냥 클라우드를 쓰지 않는 것임
    직접 호스팅하거나, GB당 아웃바운드 요금이 0센트인 Cloudflare를 쓰면 됨
    아니면 훨씬 저렴한 여러 VPS 호스팅 업체에서 클라우드 서버를 빌리고, GB당 9센트, 12센트, 17센트씩 돈을 빨아들이며 락인을 유도하는 비싸고 복잡한 클라우드 서비스를 쓰지 않으면 됨
    진지하게, 클라우드 비용을 정교하게 분석해야 하는 지점에 와 있다면 클라우드를 버리는 걸 고려해야 함

    • 정교한 클라우드 비용 분석을 하고 있다면 오히려 클라우드를 제대로 쓰고 있는 것임
      다른 곳에서는 그런 분석 자체가 완전히 불가능하기 때문임
      온프레미스로 가라는 사람들은 데이터센터를 홈랩처럼 다루지 않을 사람의 인건비가 얼마나 드는지 모르는 것 같음
      Apple iCloud조차 AWS와 GCP를 쓰는 건 경제적이기 때문임
      클라우드를 못 쓰니까 온프레미스로 돌아가야 한다고 생각하거나, 신뢰성에 별 관심이 없는 것임
      10G를 넘는 DDoS 방어 비용부터 계산해 보고도 클라우드가 더 비싸다고 말해 보라는 생각임
      우리는 AWS 대역폭에 10만 달러 이상을 쓰지만, 3개 가용 영역을 관리할 네트워크 엔지니어 비용을 내지 않아도 되기 때문에 전용 인터넷 회선보다 여전히 저렴함
    • “클라우드 비용을 정교하게 분석할 지점이면 클라우드를 버려라”는 건, 애초에 클라우드를 쓰는 이유 일부를 잃는다는 뜻이 됨
      많은 조직이 클라우드 기반 호스팅으로 옮기는 이유는 여러 장점 중에서도 FinOps와 비용 통제를 훨씬 더 깊게 할 수 있기 때문임
      인프라에 따라, 저장소나 컴퓨팅 수요가 변동한다면 클라우드 기반 해법이 잘 맞을 수 있음
      결국 도구일 뿐임
      프로덕션 베어메탈 서버에 SSH로 들어가 소프트웨어를 업데이트하고 방화벽을 관리하고 스토리지를 확인하던 곳에서도 일했고, 대부분의 호스팅을 클라우드 제공자로 처리하던 곳에서도 일했으며, 한쪽에서 다른 쪽으로 전환도 해 봄
      “클라우드”는 베어메탈 서버나 VPS보다 더 좋거나 나쁜 게 아니라 사용 사례에 달려 있음
      왜 한쪽이 더 맞는지 실사하고, 환경이 바뀔 때마다 다시 평가하면 됨
      이런 “클라우드 나쁨” 식 태도는 유치함
    • 글의 해법은 비교적 적용하기 쉬움
      이미 AWS에 락인되어 있다면 빠져나오는 데 비용이 꽤 들고, 어떤 경우에는 이 방식이 좋은 중간 지점이 될 수 있음
    • 직접 호스팅하려면, 실제로 클라우드의 기능, 즉 관리형 서비스를 쓰고 있는 경우 많은 회사에 없는 역량을 가진 IT 부서를 꾸려야 함
      그 비용은 많은 경우 절감액을 쉽게 상쇄하거나 넘어설 수 있음
      그래서 회사들이 클라우드를 선택하는 것이 너무 당연한 결정이 된 큰 이유이기도 함
    • 이 경우에는 “직접 호스팅”이 도움이 됐을 것 같지 않음
      AWS가 이 사례에서는 손해를 보고 운영하는 것으로 보임
      작성자는 AWS 가격 체계의 허점을 찾았고, 그래서 이렇게 싼 것임
      직접 했다면 더 비쌌을 가능성이 큼
      AWS 가격이 왜 이렇게 되어 있는지는 추측만 가능하지만, 한 서비스를 다른 서비스보다 더 쓰게 하려는 목적일 가능성이 높음

  • 대역폭을 많이 쓰는 사용자라면 Leaseweb, PhoenixNAP, Hetzner, OVH 같은 곳을 살펴볼 가치가 있음
    대역폭 가격이 터무니없을 정도로 더 저렴함
    예전에 표준 가격으로는 회사가 성립하지 않을 상황인데도 AWS 영업 담당자들이 대역폭 가격을 전혀 낮춰주지 않던 이상한 상황이 있었음

    • 그건 꽤 이례적인 것 같음
      전송 비용은 대부분 협상 가능한 항목으로 보임

  • 또 다른 트릭은 ECR을 쓰는 것임
    매달 인터넷으로 5TB를 무료 전송할 수 있음
    컨테이너 이미지는 공개여야 하지만 내용은 암호화할 수 있음
    Glacier에 미디어 아카이브를 저장할 때 유용함

  • AWS가 이런 터무니없는 데이터 전송 요금으로 계속 사람들을 뜯어낼 수 있는지 이해가 안 됨
    바로 옆에 Cloudflare R2가 100배는 나은 조건을 제공하고 있음

    • 데이터에는 “중력”이 있음
      데이터가 있는 곳에 묶어 두고, 중력에서 벗어나려면 돈이 들듯 데이터를 옮기려면 돈을 써야 함
    • 모든 VM과 컨테이너가 AWS에 있고, S3는 어떤 언어·프레임워크·구성을 쓰든 매우 견고하게 지원되면 팀에 다른 객체 저장소 업체를 쓰자고 요구하기가 정말 어려움
      R2에서 데이터 손실이나 느린 전송 같은 문제가 생기면 내가 비난받거나 적어도 도움 요청을 받게 됨
      반면 S3가 데이터를 잃거나 특정 경우 느리면 사람들은 우리가 뭔가 잘못 쓰고 있다고 생각하고, 개선 방법을 찾아냄
      아무도 비난받지 않음
      솔직히 사업이 어떤 가치라도 만들고 있다면 데이터 전송 요금은 무시해도 될 정도이며, 굳이 최적화할 필요가 없음
    • 대역폭을 꽤 많이 쓰는 SaaS의 새 기능을 R2로 만들었는데 아주 잘 동작함
      절감액도 정말 큼
      AWS-SDK(Node.js)를 그대로 쓰고 R2 엔드포인트만 사용함
    • Cloudflare는 AWS보다 훨씬 덜 신뢰함
      데이터가 AWS에 들어가면 같은 리전에 있는 모든 애플리케이션이 전송 비용 없이 데이터를 쓸 수 있음
      또한 글에서 인용한 가격은 표시 가격이고, 고객이 계약으로 대역폭을 선구매하면 훨씬 더 저렴해짐
    • R2는 아직 꽤 새로움
      실제 운영에서 성능과 가용성이 얼마나 좋은지 잘 모르겠음
      특히 내구성은 판단하기 어렵거나 거의 불가능함
      S3는 훨씬 긴 역사와 실적이 있어서 이점이 있음
      이미 모든 것이 AWS 안에 있다면 데이터를 가까이 두는 장점도 있음
      데이터 사용 방식에 따라 아웃바운드 비용이 항상 그렇게 큰 비용이 아닐 수도 있음
      다만 실제로 상당한 아웃바운드 트래픽을 만들기 시작하면 말도 안 되게 비싸짐
      R2 같은 경쟁자가 합리적으로 경쟁력 있는 신뢰성과 성능을 제공할 수 있다면 점유율을 늘릴 것으로 예상함
답변달기