Category: Management Tools


EC2 Container Service 신규 측정 기능: Clusters 및 Services 용

Amazon EC2 Container Service는 Docker 기반 응용 프로그램을 실행하고 관리하는 것을 도와주는 서비스입니다. EC2 Container Service – 최신 기능, 사례 및 관련 자료 총정리에서 보여 드린 대로 손쉬운 클러스터 관리 및 높은 성능, 유연한 스케줄링, 확장성, 이동성과 아울러 안전하고 효율적인 환경에서 AWS와의 연계가 가능한 장점을 가지고 있습니다.

콘테이너 기반 응용 프로그램은 Task에서 만들어집니다. Task는 같은 EC2 인스턴스에서 함께 실행되는 한 개 이상의 Docker 콘테이너입니다.각 인스턴스는 클러스터로 그룹이 됩니다. 그래서 인스턴스는 Task를 수행하기 위해 이용되는 리소스 풀과 같은 형태를 취합니다.

이러한 모델은 모니터링 및 측정에 대한 여러가지 이슈가 발생합니다. 클러스터를 너무 크지도 작지도 않은 적절한 크기로 유지하기 위해 별도의 인스턴스 보다는 클러스터 전체의 메모리와 CPU 사용율을 봐야 하기 때문입니다. 특히, 다양한 CPU와 메모리의 크기를 가진 EC2 인스턴스가 포함 된 클러스터에서 쉽지 않은 일입니다.

신규 Cluster 측정 기능
이를 위해서 클러스터의 자원을 제대로 측정하고 이를 기반으로 확장할 수 있도록 각 인스턴스의 크기 및 콘테이너의 설정을 기준으로 만들어진 Amazon CloudWatch 측정 기준과 모니터링을 시작합니다. AWS ECS 관리 콘솔에서 측정치를 볼 수 있으며 이를 기반으로 Auto Scaling을 할 수 있습니다.

각 인스턴스에는 ECS Container Agent가 실행되고 있습니다. 이를 통해 인스턴스 및 Task의 CPU 및 메모리 측정값을 수집하고 정규화를 위해 데이터를 보냅니다. 정규화 작업은 클러스터 전체의 CPU 및 메모리 사용을 표현하기 위한 통계가 생성됩니다. 이러한 통계치에 따라 전체 클러스터의 활용 상황을 파악할 수 있습니다.

간단하게 살펴보겠습니다. default라는 이름의 클러스터 아래 하나의 t2.medium 인스턴스를 가지고 있습니다.

이 시점에서 Task가 실행되지 않고 클러스터는 유휴(idle) 상태입니다.

전체 CPU를 소비하게 끔 2개의 Task를 실행했습니다.:

Task가 CPU를 소비하기 까지조금 시간이 조금 걸립니다. 이제 CPU 사용율은 아래와 같이 되었습니다.

그래서 또 다른 t2.medium 인스턴스를 클러스터에 집어 넣고 활용도를 다시 확인 보았습니다. 추가된 용량에 따라 전체 이용률은 50 %로 감소했습니다.

새로운 측정치(CPUUtilizationMemoryUtilization)는 CloudWatch를 통해 이용 가능하며, 알림을 만드는 데 사용할 수 있습니다.

신규 Service 측정치
올해 초반에 EC2 Container Service를 부하 분산을 통한 애플리케이션 본격 사용에 대해 발표하였습니다. Service 스케줄러를 통해 우리가 원하는 수준에 맞게 확장 가능하고 높은 품질의 유지 관리가 가능합니다. CPU 및 메모리 사용률 통계가 서비스마다 수집 되어 콘솔에서 볼 수 있습니다.

오늘부터 새로운 Cluster와 Service의 통계 모니터링은 바로 활용해 보실 수 있습니다.

Jeff;

이 글은 New Metrics for EC2 Container Service: Clusters & Services의 한국어 번역본입니다.

Amazon S3 기능 추가 – 알람 기능 및 버킷 측정 기준 향상

2006년 봄에 Amazon Simple Storage Service (S3)간단한 블로그 공지로부터 시작했습니다. 그동안 간편하지만 강력한 서비스 모델을 유지해 오면서, 가격 인하를 포함하여 중복을 감소한 스토리지, VPC 엔드 포인트, 리전간 복제 기능이벤트 노티피게이션 기능 등을 추가해 왔습니다.

작년에 이벤트 알림 기능을 추가한 이후 다양한 객체 이벤트에 대한 알림을 지원해 왔습니다. 예를 들어, PUT, POST, Copy, Multipart Upload 등의 이벤트가 있을 때 알람을 지원합니다. 이러한 알람 통지 기능은 모든 버킷의 객체가 대상입니다. 오늘 부터 객체들이 삭제 되었을 때, 접두사 및 접미사(prefixes 및 suffixes) 필터링을 지원합니다. 또한, 버킷 수준에서 Amazon CloudWatch 메트릭 지원합니다.

알림 통지 기능 향상
또한, S3 버킷에서 객체가 삭제 된 경우에 알람을 통지하도록 설정할 수 있습니다. 다른 형식의 통지와 마찬가지로, 삭제 통지는 SQS 큐(Queue)나 SNS 토픽(Topic), AWS Lambda function에 연결해서 보낼 수 있습니다. 이러한 객체 삭제 알림은 DELETE 수행이 될 때 S3 객체를 관리하기 위한 인덱스 업데이트 및 데이터 추적 등에 사용할 수 있습니다.

또한, 객체 이름의 접두사와 접미사를 사용한 필터를 사용할 수 있습니다. 다음 예제에서는 특정 버킷에서 “images /” 접두사 “.png” 접미사의 객체가 삭제 된 경우에 알람을 통지 할 수 있습니다.

관리 콘솔에서 여러 개의 알람 통지를 생성 및 편집 할 수 있습니다.

CloudWatch 스토리지 측정 기준
Amazon CloudWatch는 AWS 서비스 및 여러분이 추가한 응용 프로그램의 측정 값 추적 및 알람 기능을 가지고 있습니다. 알람 설정은 경과 시간 동안 임계값을 초과 할 때 발생합니다. S3의 모니터 및 알람 기능을 S3에 대해서도 할 수 있습니다. 지원되는 측정 지표는 버킷 당 총 바이트 수 (표준 및 RRS)과 총 객체 수입니다. 측정 기준에 따른 결과는 AWS 관리 콘솔에서 볼 수 있습니다.

측정 기준은 빌링과 함께 마찬가지로 매일 업데이트 합니다. 또한, 스토리지 라이프 사이클 규칙 등에 의해 Glacier로 이동하도록 설정 된 객체는 제외됩니다.

지금 사용 가능
이 기능들은 오늘 부터 바로 사용이 가능합니다.

Jeff;

이 글은 Amazon S3 Update – Notification Enhancements & Bucket Metrics의 한국어 번역입니다.

Amazon CloudWatch 신규 기능 – 인스턴스 재시작용 알람 만들기

Amazon CloudWatchAmazon Elastic Compute Cloud (EC2) 인스턴스를 포함하여 다양한 클라우드 리소스를 모니터링 할 수 있습니다. 클라우드 시스템 및 응용 프로그램 수치(Metric)를 모니터링하여 그래프 형식으로 확인하고, 지정된 임계치를 초과하면 (CloudWatch 알람를 통해) 통보하도록 설정할 수 있습니다. 예를 들어, 알람이 발생했을 경우 EC2 인스턴스를 중지 혹은 종료 할 수 있습니다 (자세한 사항은 Amazon CloudWatch – Alarm Actions을 참고하십시오).

새로운 기능 – 인스턴스 재시작
오늘 네번째로 신규 기능을 추가했습니다. 즉, CloudWatch 알람이 발생했을 때 EC2 인스턴스를 다시 시작하도록 설정할 수 있게 되었습니다. 클라우드 시스템 및 응용 프로그램 모니터링과 알람을 함께 사용하면 높은 유연성을 제공해 드릴 것입니다.

인스턴스 상태 확인이 반복적으로 실패하는 경우 인스턴스를 다시 시작할 수 있습니다. 즉, 메모리 누수를 일으키는 응용 프로그램이나 서비스가 원인이 되어 메모리가 부족한 상태가 되었을 수도 있고, 이 때는 인스턴스 재시작이 상황을 개선하기 위해 가장 빠르고 쉬운 방법입니다. EBS-Backed 인스턴스 유형이거나 인스턴스가 깨진 경우에만 적용되는 극히 일부의 복구 작업과는 달리 이 작업은 모든 인스턴스 유형에서 사용할 수 있는 (인스턴스의 상태에 관계없이) 가장 효과적입니다.

응용 프로그램 수치를 모니터링하는 CloudWatch API 또는 AWS 명령어 인터페이스 (CLI)를 사용하면 응용 프로그램이 반복적으로 응답하지 않으면 인스턴스를 다시 시작할 수 있습니다. 프로세스가 막히거나 응용 프로그램 서버가 제대로 작동하지 않을 수도 있습니다. 이런 경우, (가상) 리셋 스위치를 누르는 것이 다시 정상 작동을 위한 쉽고 간단한 방법입니다.

알람 만들기
CPU 사용률이 장기간 90%를 초과 한 상태일 경우, 인스턴스 중 하나를 재시작하도록 알람을 생성하는 방법을 살펴 보겠습니다. AWS 괸리 콘솔에서 인스턴스를 찾아 Alarm Status란 아이콘을 클릭합니다.

Take Action을 클릭하고 Reboot Instance를 선택하여 매개 변수를 설정합니다 (CPU 사용률이 90% 이상 15분 이상 지속되는 경우).

필요하다면, 콘솔에서 단계 중에 IAM 역할 만들기를 진행합니다 (이것 역시 새로운 기능입니다.)

이 역할은 CloudWatch의 “Describe”기능과 EC2 API 호출을 허용하기 위한 것입니다. 또한, 인스턴스 재시작 및 종료에 대한 권한 역시 허용합니다.
Create Alarm을 클릭하면, 설정이 완료됩니다!

이 기능은 현재 모든 AWS 리전(Region)에서 오늘부터 사용할 수 있습니다.

Jeff;

이 글은 New Amazon CloudWatch Action – Reboot EC2 Instance의 한국어 번역입니다.

AWS Service Catalog 서비스 소개

큰 조직의 IT 부서를 운영한다는 것이 쉽지는 않습니다. 한편으로는 여러분 조직의 내부 사용자들에게 최고의 신규 기술을 제공해서 최대한 효율과 생산성을 제공함과 동시에 다른 한편으로는 IT 전문가로서 사내 표준 정립과 유지, 모범 사례 수집 및 전파, 예산 낭비와 기술 남용을 피하기 위한 감독 기능 역시 수행해야 합니다.

수년 전에는 AWS 적용을 위해 초기 실험을 하는 실무팀 부터 현업에 조용히 도입했습니다. 클라우드에 힘입은 그 분들의 민첩한 성공 스토리는 빠르게 퍼졌고 조직 상위에 있는 분들도 곧이어 주목했습니다. 이런 “셰도우(shadow) IT” 모델이 기술 도입 시 효과적이기는 하나, 역시 기술 도입에 관한 사내 표준을 만들어야 합니다.

저희가 이런 대규모 조직에게 듣는 피드백은 놀라울 정도로 같았습니다! 이 분들은 AWS를 이용하여 현업 애플리케이션을 지원하고 내부 고객들에게 모든 종류의 서비스를 제공하고 있으나, AWS 잇점을 살리면서도 일관성 유지 및 접근 통제, 모범 사례 전파, 예산 관리등을 위해 템플릿, 관리 도구 및 규정 같은 것이 있기를 바랬습니다.

AWS Service Catalog 소개
오늘은 곧 출시 예정인 AWS Service Catalog에 대해 말씀드리겠습니다. 위에서 설명한 어려움을 해결하고자 하는 것이 바로 이 서비스입니다. 어떤 IT 부서라도 AWS 기반 서비스를 부서의 통제 아래 일관성 있게 내부 사용자에게 제공할 수 있도록 도와드리는 도구입니다! AWS Service Catalog를 이용하면 IT 부서의 현업 이슈, 비용 경감, 재사용 촉진 등을 하면서도 이 블로그에 기술되어 있는 클라우드 컴퓨팅의 이점들을 체감할 수 있도록 여러분의 조직을 도와드릴 수 있을 것입니다.

AWS Service Catalog는 AWS의 통합 서비스로서, 관리자 모드와 일반 사용자 모드 두 가지 인터페이스가 제공되고, 제품 관리와 통합을 쉽게 할 수 있도록 설계된 API 모음도 제공합니다. 먼저 핵심 개념과 개체를 살펴보겠습니다:

  • 서비스 카탈로그(Service Catalog) – 서비스 카탈로그는 하나의 AWS account에 종속됩니다. 관리자가 관리하며 하나 이상의 포트폴리오(Portfolios)를 가집니다.
  • 관리자(Administrator) – 관리자는 서비스 카탈로그 안에 있는 프로덕트 포트폴리오(Portfolios of Products)를 업로드하고 관리하는 책임을 집니다.
  • 사용자(User) – 사용자는 서비스 카탈로그의 포털페이지를 접속하여 여러 포트폴리오를 찾아보고, 관심있는 프로덕트를 골라서 띄웁니다. 사용자는 동일한 AWS account 안에서 관리자모드 또는 기타모드로 동작할 수 있습니다.
  • 포탈(Portal) – 포탈은 서비스 카탈로그의 창문(View)인데요, 특정 사용자가 접속할 수 있는 포트폴리오와 제품만 보여주도록 맞춤제작 가능합니다.
  • 포트폴리오(Portfolio) – 포트폴리오란 서비스 카탈로그 아래 버전관리 중인 프로덕트들의 모음입니다. 각 포트폴리오는 포탈 속의 특정 사용자들(IAM role, group, user name 등으로 판단)만 접근할 수 있습니다.
  • 프로덕트(Product) – 프로덕트는 AWS리소스들의 모음인데요(EC2 인스턴스, 애플리케이션 서버, 데이타베이스 등등), 이 단위 별로 프로덕트를 런치하고 관리하게 됩니다. (런칭되어 실행중인 프로덕트는 AWS용어로 Stack이라 부릅니다). 프로덕트는 CloudFormation 템플릿으로 기술되며, 포트폴리오 아래 하나의 프로덕트가 서로 다른 버전으로도 동시 존재할 수 있습니다.

복잡한 것처럼 들리지만, 실은 그렇지 않습니다. 정리해 보면, 관리자는 프로덕트를 업로드하고 일부속성과 접근권한을 조정함으로써 서비스 카탈로그 안에 일련의 포트폴리오를 생성합니다. 또한, 사용자는 맞춤제작된 포탈을 둘러보고 필요한 프로덕트를 찾아 실행합니다.

Service Catalog 관리자모드와 사용자모드 각각 어떻게 생겼는지 간단히 살펴보겠습니다. 아래 스크린샷과 기능들은 출시일이 어느정도 변경이 있을 수도 있다는 점 참고해 주세요.

AWS Service Catalog – 관리자 모드
제가 관리자라고 해보겠습니다. AWS 관리 콘솔을 열어 AWS Service Catalog를 선택하면 아래처럼 보입니다:

이름, 설명, 소유자 등을 입력하여 포트폴리오를 생성하는 것부터 시작합니다. 원하면 태그도 추가할 수 있습니다.

이제 포트폴리오에 프로덕트를 추가할 수 있습니다. 이 과정은 여러 개의 스크린으로 나뉘어 있는데요, 보기보다 간단합니다. 먼저 프로덕트 상세내용을 입력하는 것부터 시작합니다.

다음에는 부가정보와 태그등을 집어넣습니다.

마지막 단계는 프로덕트를 어떻게 구현하는 지 CloudFormation 템플릿을 설정합니다:

프로덕트가 이제 포트폴리오에 추가되었습니다.

프로덕트를 사용하는 데 제약을 줄 수도 있고, user와 group 별로 접근을 제어할 수도, 해당 포트폴리오를 다른 AWS account에게 공유할 수도 있습니다.

AWS Service Catalog – 사용자 모드
이번에 서비스 카탈로그를 사용자 관점에서 보겠습니다. 다시 한번, 아래 스크린샷들은 아직 초기버전임을 감안해 주세요. 아래는 개인화된 포탈의 전체 화면입니다.

Products 항목은 내가 이용할 수 있는 프로덕트들을 표시해 줍니다:

프로덕트 실행은 몇 번의 클릭이면 끝납니다

Stacks영역은 내 account 내에 스택(Stacks: 실행 중인 프로덕트)를 보여줍니다.:

기대하세요!
관심 있으신 분들은 AWS Service Catalog 페이지를 방문하여 알림과 업데이트를 받아볼 수 있도록 등록할 수 있습니다.

AWS Service Catalog 출시가 가까워질 수록 더 많은 얘기를 들려드릴 수 있을 것입니다. 계속해서 이 블로그를 봐주시면 여러분이 제일 먼저 소식을 들을 수 있습니다!

Jeff;

AWS Service Catalog는 2015년 7월 10일 정식 출시하였습니다. 이 글은 Coming Soon – AWS Service Catalog의 한국어 번역으로 AWS 본사 프로페셔널 컨설턴트로 근무하는 이종남님이 수고해주셨습니다.

AWS Service Catalog 정식 출시

작년 가을 AWS re:Invent에서  AWS Service Catalog를 소개하였습니다. (AWS Service Catalog 출시 소개) 이 서비스를 통해 큰 조직에서 비지니스 애플리케이션을 잘 정리하고 내부에 일관성 있게 전달할 수 있도록 접근 제어, 일관된 관리, 베스트 프랙티스 공유, 예산 관리 등을 위한 각종 템플릿이나 도구들이 필요합니다. 사용자들은 Service Catalog를 통해서 제품 목록을 검색하고 접근 가능한지 어디에 있는지 어떻게 실행하는지 등을 스택이라는 것으로 이용할 수 있습니다. 관리자는 제품의 포트폴리오, 공급 라인 및 추가 규정을 조합하고 AWS Identity and Access Management (IAM)를 활용하여 특정 IAM 사용자, 그룹 및 역할을 따라 포트폴리오에 접근 제어를 할 수 있습니다.

지난번 발표를 통해 AWS 대표적인 고객이 서비스를 실제로 사용하면서 매우 가치 있는 다양한 피드백을 저희에게 보내주셨습니다.

이러한 피드백을 바탕으로 기업 고객에게 좀 더 도움이 되는 서비스가 되기 위해 컴플라이언스 관리, IAM 역할 지원, 비용 추적을 위한 태그 사용, (제품 목록인) 포트폴리오를 다른 AWS  계정에도 공유할 수 있는 기능이 추가되었습니다.

Service Catalog에 대한 고객의 피드백을 들어 보시겠습니다:


Chris Nolan (Technology Director at 2nd Watch):

우리는 AWS CloudFormation를 활용해 사용 중인 AWS 서비스를 표준화하고 관리합니다. AWS Service Catalog를 통해 템플릿 버전과 내부 사용량 보고 및 새 제품 및 조직을 어떻게 간단히 제공하는데 쉽게 할 수 있었습니다.”


Garland Garcia (Fellow at Lockheed Martin):

“AWS Service Catalog는 DevOps팀에게 꼭 필요한 도구가 될 것입니다. 개발자들이 AWS 서비스를 스스로 프로비저닝 할 수 있고, IT 부서는 이들 리소스 설정을 더 간단하게 제어할 수 있게 되었습니다. 기업 조직이 시기에 적절히 맞는 시장 솔루션을 만드는 시간을 줄이고 비지니스 목표에 맞출 수 있게 도와줄것입니다.”

정식 출시
오늘 부터 AWS Service Catalog는 모든 고객이 이용하실 수 있습니다!

첫 소개 블로그 글에 간단한 사용 방법을 소개하였으니 참고하시고, 대신 기능에 대한 고객의 피드백을 좀 더 설명하도록 하겠습니다.

실행 조건(Launch Constraints) – 실행 조건은 제품, 포트폴리오, IAM 사용자 및 그룹에 적용됩니다. 이는 제품이 어떻게 실행되는지를 제어하는 요소입니다. 예를 들어, 특정 AWS 리전 혹은 EC2 인스턴스 타입에 제품 사용을 제약할 수 있습니다. 각 제품의 포트폴리오는 AWS CloudFormation 템플릿을 활용하기 때문에 템플릿 파라미터로 설정할 수 있습니다.

IAM 역할(Role) 지원 – 각 제품은  IAM role을 지정해야 합니다. 각 역할을 가지고 실행하면, 제품의 CloudFormation에 지정된 역할을 사용합니다. 만약 역할이 제공되지 않으면 사용자의 IAM 크리덴셜을 사용합니다. 역할을 제공하는 것은 사용자에게 AWS 자원을 허용 범위 이상으로 사용하는 것을 막아주게 됩니다.

태그 – 태그는 AWS 자원을 확인하는 데 사용 가능합니다. 각 제품과 포트폴리오는 세 개까지 태그를 사용할 수 있습니다. 제품이 실행될때, 태그와 스택이 자동으로 적용됩니다. 사용자가 추가 태그를 스택에 포함 시킬 수 있습니다. 태그는  AWS Management Console에서 볼 수 있습니다.

포트폴리오 공유 – 몇몇 기업은 하나 이상의 AWS 관리 계정으로 사용해 왔습니다. 관리 상, 빌링이나 혹은 다른 과거의 이유 때문인데 Service Catalog는 이들 계정 사이에 서로 공유도 가능합니다.

추가 정보
오늘 Service Catalog는 US East (Northern Virginia)US West (Oregon) 리전에 정식 출시하며, 앞으로도 사용자의 요구와 피드백에 따라 더 많은 리전으로 확대할 예정입니다. 자세한 정보는 AWS Service Catalog 페이지를 참고해 주십시오.

Jeff;

이 글은 Now Available – AWS Service Catalog의 한국어 번역입니다.

VPC Flow Logs – 네트워크 트래픽 수집 및 활용 기능

많은 기업에서 네트워크 연결 중 문제 해결 및 보안 문제 및 네트웍 상 접근 규칙이 예상대로 작동하는지 확인하기 위해 네트워크 플로우 로그의 수집, 저장 및 분석을 하고 있습니다.

지금까지 AWS 고객은 주로 Amazon Elastic Compute Cloud (EC2)에 직접 에이전트를 설치하여 데이터를 수집하고 있었고, 각 인스턴스에 오버 헤드의 부하를 줄 뿐만 아니라 매번 인스턴스마다 제한적으로만 보기(View)가 가능했습니다.

VPC Flow Logs 소개

네트워크 모니터링에서 로그 수집 기능을 향상을 위해 Amazon Virtual Private Cloud의 Flow Logs를 공개합니다. 특정 VPC에서 Flow Logs를 사용하여 VPC 서브넷과 엘라스틱 네트워크 인터페이스(ENI)의 네트워크 트래픽이 CloudWatch Logs를 통해 저장된 후, 자신의 응용 프로그램이나 타사 프로그램에서 분석 할 수 있습니다.

특정 유형의 트래픽을 감지하여 알람을 만들거나 트래픽의 변화와 패턴을 파악하기위한 통계를 만들 수도 있습니다.

로그 정보는 보안 그룹 및 네트워크 접근(ACL) 규칙에 의해 허용 및 차단 트래픽 정보가 포함되어 있습니다. 또한, 소스 / 목적지 IP 주소, 포트, 프로토콜 번호 패킷 바이트 모니터링 간격 시간, 그리고 이에 따른 액션(ACCEPT 또는 REJECT) 정보도 포함됩니다.

VPC Flow Logs 시작하기

AWS 관리 콘솔, AWS 명령 줄 인터페이스 (CLI)EC2 API 호출을 통해 VPCFlow Logs를 활성화 할 수 있습니다. 아래는 VPC에서 Fow Logs를 사용하는 화면 스크린 샷입니다.

Flow Logs 구성 화면입니다.

VPC 대시 보드에 Flow Logs 탭이 표시됩니다.

Flow Logs는 CloudWatch Logs 로그 그룹에 저장됩니다. Flow Logs를 작성한 후 약 15분 후에 새로운 로그 그룹이 생성됩니다. CloudWatch Logs의 대시 보드에서 접근 가능합니다.

각 그룹은 엘라스틱 네트워크 인터페이스 (ENI)당 스트림으로 구성됩니다.

각 스트림은 다음과 같은 항목이 포함됩니다.

Flow Logs 유의 사항

VPC Flow Logs 사용 시 알아 주시면 좋을 몇 가지를 알려드립니다.

각 Flowsms 약 10 분 간격으로 캡처되어 윈도우에서 수집, 처리, 저장합니다. 로그 그룹을 만들고 첫 번째 레코드가 콘솔에서 확인 될 때​​까지 Flow Logs가 생성 된 후 약 10분 후에 가능합니다.

하나의 리소스에 대해 2개의 Flow Logs를 만들 수 있습니다.

Flow Logs에는 다음과 같은 트래픽 정보는 포함되어 있지 않습니다.

  1. Amazon DNS 서버 트래픽(개인 호스트 영역 쿼리 포함)
  2. Amazon에서 제공하는 Windows 라이센스 활성화 트래픽
  3. 인스턴스 메타 데이터 요청
  4. DHCP 요청과 응답

지금 사용하기

이 기능은 도쿄 지역 (아시아 태평양)를 비롯해 북부 캘리포니아 (미국 서부), 오레곤 (미국 서부), 북 버지니아 (미국 동부), 시드니 (아시아 태평양), 싱가포르 (아시아 태평양), 아일랜드 (유럽) 프랑크푸르트 (유럽)에서 이용이 가능합니다. 이용시 추가 비용이 필요하지 않습니다. CloudWatch Logs 스토리지 요금 만 청구됩니다. (자세한 내용은 CloudWatch 가격표을 참고하세요.)

Jeff;

PS – 일부 AWS 파트너는 VPC Flow Logs 처리, 분석, 시각화 등의 도구 제공을 위해 노력하고 있습니다. 그 부분에 대해서도 알려드리겠습니다.

본 글은 VPC Flow Logs – Log and View Network Traffic Flows의 한국어 번역입니다.