AWS Lambda Serverless 프로젝트 5 - 비디오 메타데이터 생성 - AWS 관리, 그룹, 역할, 자원, CloudWatch, CloudTrail, 결제 알람 AWS Lambda Serverless 프로젝트 1 - AWS CLI, Lambda, S3, IAM AWS Lambda Serverless 프로젝트 2 - IAM, Lambda, Elastic Transcoder, NPM, S3, CloudWatch AWS Lambda Serverless 프로젝트 3 - SNS, Lambda, S3 AWS Lambda Serverless 프로젝트 4- 비디오 메타데이터 생성 - Lambda, SNS, S3 이어서 AWS의 보안, 로깅, 알람 및 비용에 대해 자세히 살펴보겠습니다. AWS의 보안 모델 및 ID 관리 로깅, 경고 및 사용자 지정 메트릭(metrics) AWS 비용 모니터링과 추정 대부분의 아키텍처는 AWS 위에 구축되었습니다. 즉, 보안, 로깅, 경고 및 비용 측면에서 AWS를 명확하게 이해해야 합니다. Lambda 만 사용하든 서비스를 많이 사용하든 관계 없습니다. 보안을 올바르게 구성하고 로그를 찾을 위치를 알고 비용을 제어하는 것이 중요합니다. 이 장은 이러한 문제를 이해하고 AWS에서 중요한 정보를 찾는 위치를 파악할 수 있도록 고안되었습니다. AWS 보안은 복잡한 주제이지만이 장에서는 사용자와 역할의 차이점에 대한 개요와 정책 작성 방법을 보여줍니다. 이 정보는 서비스가 효과적이고 안전하게 통신 할 수있는 시스템을 구성하는 데 필요합니다. Lambda, S3, SNS 및 Elastic Transcoder를 사용하고 시스템에서 AWS로 배치를 수행하기 위해 Identity and Access Management (IAM) 사용자 및 여러 역할을 작성했습니다. 또한 SNS에서 리소스 기반 정책을 수정하고 S3 버킷에있는 객체의 액세스 제어 목록 (ACL)을 변경했습니다. 이러한 모든 조치는 AWS의 보안 요구 사항을 충족시키는 데 필요합니다. 이 섹션에서는 사용자, 그룹, 역할 및 정책에 대해 자세히 설명합니다. 기억할 것입니다. IAM 사용자는 인간 사용자, 애플리케이션 또는 서비스를 식별하는 AWS의 엔티티입니다. 일반적으로 사용자는 AWS에서 자원 및 서비스에 액세스하는 데 사용할 수있는 자격 증명 및 권한 집합을 가지고 있습니다. 예를 들어, 람다 함수를 업로드 할 수 있도록 람다라는 사용자를 만들었습니다. 그림은 lambda이라는 가상의 사용자에 대한 요약 페이지와 ARN을 보여줍니다. AWS 콘솔에서 IAM을 클릭하고 탐색 창에서 사용자를 클릭 한 다음 보려는 사용자의 이름을 클릭하여 AWS 콘솔에서이 요약을 볼 수 있습니다. 사용자, 응용 프로그램 또는 서비스를 나타내는 IAM 사용자를 만들 수 있습니다. 응용 프로그램 또는 서비스를 대신하여 작업하도록 만든 IAM 사용자를 때때로 서비스 계정이라고합니다. 이러한 유형의 IAM 사용자는 액세스 키를 사용하여 AWS 서비스 API에 액세스 할 수 있습니다. IAM 사용자의 액세스 키는 사용자가 처음 생성 될 때 생성되거나 나중에 IAM 콘솔에서 사용자를 클릭하고 필요한 사용자 이름을 클릭하고 보안 자격 증명을 선택하고 액세스 키 만들기 버튼을 클릭하여 만들 수 있습니다. 액세스 키의 두 구성 요소는 액세스 키 ID 및 보안 액세스 키입니다. 액세스 키 ID는 공개적으로 공유 할 수 있지만 비밀 키는 숨겨져 있어야합니다. 비밀 액세스 키가 공개되면 전체 키를 즉시 무효화하고 다시 만들어야합니다. IAM 사용자는 최대 두 개의 활성 액세스 키를 가질 수 있습니다. 실제 사용자에 대해 IAM 사용자를 만든 경우 해당 사용자에게 암호를 할당해야합니다. 이 암호를 사용하면 사용자가 AWS 콘솔에 로그인하여 서비스 및 API를 직접 사용할 수 있습니다. IAM 사용자의 암호를 만들려면 다음과 같이하십시오. 1. IAM 콘솔의 탐색 창에서 사용자를 클릭합니다. 2. 실제 사람을 위해 생성합니다. '사용자 추가'를 클릭하십시오. 3. 새 IAM 사용자에게 "worker"와 같은 이름을 지정하고 Programmatic access 확인란 및 AWS Management console Access를 선택합니다. 콘솔 액세스를 사용할지 여부를 선택하거나 새 사용자 지정 암호를 입력하거나 시스템에서 자동으로 암호를 생성하도록 선택할 수 있습니다. 다음 로그인시 사용자가 강제로 새 비밀번호를 만들 수도 있습니다. 4. 작업자의 권한 설정에서 아무 것도 선택하지 않습니다. "다음 : 검토"를 클릭하여 계속 진행합니다. "사용자 만들기"를 클릭합니다. 새로 생성된 user를 살펴볼 수 있습니다. 계정 ID를 얻으려면 오른쪽 상단 네비게이션 바에서 “지원”을 클릭 한 다음 지원 센터를 클릭합니다. 계정 ID (또는 계정 번호)는 콘솔의 오른쪽 위에 표시됩니다. 사용자에게 비밀번호가 지정되면 https://<Account-ID>.signin.aws.amazon.com/console로 이동하여 AWS 콘솔에 로그인 할 수 있습니다. AWS에서 worker로 로그인해봅시다. 비밀번호를 변경해야 계속 사용할 수 있습니다. 새로운 worker 유저로 사용이 가능해졌습니다. 그룹은 IAM 사용자 모음을 나타냅니다. 여러 사용자에 대한 권한을 한 번에 쉽게 지정할 수있는 방법을 제공합니다. 예를 들어 조직의 개발자 또는 테스터를위한 그룹을 만들거나 Lambda라는 그룹을 만들어 해당 그룹의 모든 구성원이 Lambda 기능을 실행할 수 있도록 할 수 있습니다. 아마존은 개별적으로 권한을 정의하는 대신 그룹을 사용하여 IAM 사용자에게 권한을 할당 할 것을 권장합니다. AWS는 기본 그룹을 제공하지 않지만 필요에 따라 그룹을 쉽게 만들 수 있습니다. 예를 들어, 여러 IAM 사용자가 람다 함수를 업로드 할 수 있도록 그룹을 생성합니다. 이 그룹은 응용 프로그램을 배포하기 위해 지속적인 배포 파이프 라인을 설정하려는 경우 유용 할 수 있습니다. 모범 사례는 다른 환경 (준비, 프로덕션 등)에 대해 IAM 사용자를 만들어야 함을 제안합니다. 이 그룹에 추가하면 배포를 수행 할 수있는 올바른 권한이 부여됩니다. 1. Groups을 클릭한 다음 “Create New Group”를 클릭하여 IAM 콘솔에 그룹을 만듭니다. 2. 그룹에 Lambda-DevOps와 같은 이름을 지정하고 다음 단계를 클릭합니다. 4. Lambda-DevOps를 클릭하고 권한(Permissions)탭이 선택되어 있는지 확인한 다음 인라인 정책 섹션을 확장합니다. 인라인 정책 섹션에서 여기를 클릭합니다. 링크를 클릭하고 사용자 정의 정책을 선택합니다. 5. Lambda-Upload-Policy와 같은 정책의 이름을 설정하고 GitHub의 코드를 정책 문서 본문에 복사합니다. "Statement": [ (1) 명령문 ID (Sid)는 설정할 수있는 선택적인 정책 ID입니다. 그것은 정책 내에서 고유해야하지만 당신은 그것을 만들 수 있습니다. 6. 정책 적용 버튼을 클릭하고 저장합니다. 새로 생성된 정책을 볼 수 있습니다. 7. 사용자 메뉴를 클릭하고 lambda 유저를 클릭하여 이전의 포스트에서 생성한 인라인 정책을 제거합니다. 8. 그룹 탭을 클릭 한 다음 그룹에 사용자 추가를 클릭합니다. 목록에서 lambda 사용자를 선택하고 그룹에 추가를 클릭합니다. 9. 권한 탭을 클릭합니다.. 볼 수있는 Lambda-Upload-Policy라는 새로운 인라인 정책이 나타납니다. 나중에 정책을 삭제하기로 결정한 경우 그룹에서 사용자를 삭제해야합니다. 그림은 그룹 탭에서이를 수행하는 방법을 보여줍니다. 함수 중 하나의 배포(deployment)를 테스트 할 수 있습니다. 역할은 일정 기간 동안 사용자, 응용 프로그램 또는 서비스가 취할 수있는 권한 집합입니다. 역할은 특정 사용자에게 고유하게 결합되어 있지 않으며 비밀번호 나 액세스 키와 같은 자격 증명도 없습니다. 일반적으로 필요한 리소스에 액세스 할 수없는 사용자 또는 서비스에 권한을 부여하도록 설계되었습니다. 이전에는 람다 함수가 S3에 액세스 할 수 있도록 역할을 만들었습니다. AWS의 일반적인 사용 사례입니다. 위임은 역할과 관련된 중요한 개념입니다. 간단히 말하면, 위임은 특정 리소스에 대한 액세스를 허용하는 제 3 자에 대한 사용 권한 부여와 관련됩니다. 여기에는 리소스를 소유하는 트러스 팅 계정과 리소스에 액세스해야하는 사용자 또는 응용 프로그램이 포함 된 트러스트 된 계정간에 트러스트 관계를 설정하는 작업이 포함됩니다. 그림은 IAM 콘솔의 역할을 보여줍니다. "lambda-s3-execution-role"을 클릭합니다. 그림은 lambda-s3-execution-role이라는 서비스에 대해 설정된 신뢰 관계가 있는 역할을 보여줍니다. 처음에 IAM 사용자를 만들면 계정에 액세스하거나 아무 것도 할 수 없습니다. 사용자가 수행 할 수있는 작업을 설명하는 정책을 작성하여 사용자 권한을 부여해야합니다. 새로운 그룹이나 역할에 대해서도 마찬가지입니다. 새 그룹이나 역할에 효과가있는 정책을 할당해야합니다. 정책에는 인라인과 관리되는 두 가지 유형이 있습니다. 관리되는 정책은 사용자, 그룹 및 역할에는 적용되지만 리소스에는 적용되지 않습니다. 관리되는 정책은 독립형입니다. 일부 관리 정책은 AWS에서 만들고 관리합니다. 고객 관리 정책을 작성하고 유지 관리 할 수도 있습니다. 관리 정책은 재사용 및 변경 관리에 유용합니다. 고객 관리 정책을 사용하여 수정하려는 경우 모든 변경 사항이 정책이 첨부 된 모든 IAM 사용자, 역할 및 그룹에 자동으로 적용됩니다. 관리 정책을 사용하면 쉽게 버전 및 롤백이 가능합니다. 정책은 JSON 문법을 따릅니다. 다음의 코드를 살펴봅시다. { (1) Version은 정책 언어 버전을 지정합니다. 현재 버전은 2012-10-17입니다. 맞춤 정책을 만드는 경우 버전을 포함하고 2012-10-17로 설정해야합니다. AWS의 권한은 신원 기반 또는 자원 기반입니다. 신원 기반 사용 권한은 IAM 사용자 또는 역할이 수행 할 수있는 작업을 지정합니다. 자원 기반 권한은 S3 버킷 또는 SNS 주제와 같은 AWS 자원이 수행 할 수있는 권한 또는 누가 액세스 권한을 가질 수 있는지 지정합니다. 3 장에서는 SNS 주제가 S3와 통신 할 수 있도록 정책을 수정했습니다. 이는 요구 사항을 충족시키기 위해 변경해야하는 리소스 기반 정책의 예입니다. "Statement": (3) Effect 요소는 필수 요소이며 명령문이 자원에 대한 액세스를 허용하는지 아니면 거부 하는지를 지정합니다. 사용 가능한 두 가지 옵션은 허용 및 거부입니다. 많은 IAM 정책에는 Principal, Sid 및 Condition과 같은 추가 요소가 포함되어 있습니다. Principal 요소는 리소스에 대한 액세스가 허용되거나 거부되는 IAM 사용자, 계정 또는 서비스를 지정합니다. Principal 요소는 IAM 사용자 또는 그룹에 첨부 된 정책에서는 사용되지 않습니다. 대신 역할에서 누가 역할을 맡을 수 있는지 지정하기 위해 역할에 사용됩니다. 또한 자원 기반 정책에 공통적입니다. Statement ID (Sid)는 SNS와 같은 특정 AWS 서비스의 정책에 필요합니다. 조건을 사용하면 정책 적용시기를 지정하는 규칙을 지정할 수 있습니다. 조건의 예가 다음 코드에 나와 있습니다. "Condition": { (1) 여러 조건부 요소를 사용할 수 있습니다. 여기에는 DateEquals, DateLessThan, DateMoreThan, StringEquals, StringLike, StringNotEquals 및 ArnEquals가 포함됩니다. (2) 조건 키는 사용자가 발행 한 요청의 값을 나타냅니다. 가능한 키에는 SourceIp, CurrentTime, Referer, SourceArn, userid 및 username이 있습니다. 값은 "127.0.0.1"과 같은 특정 리터럴 값이거나 정책 변수 일 수 있습니다. 여러 조건 "Statement": [ (1) 이 정책은 조건이 충족되면 s3에 대한 액세스를 명시 적으로 거부합니다. CloudWatch는 AWS에서 실행되는 리소스 및 서비스를 모니터링하고 광범위한 메트릭을 기반으로 알람을 설정하며 리소스 성능에 대한 통계를 볼 수있는 AWS 구성 요소입니다. 서버리스 시스템을 구축하기 시작하면 CloudWatch의 다른 기능보다 로깅을 더 많이 사용하게됩니다. 람다 함수에서 문제를 추적하고 디버깅하는 데 도움이 될 것이며, 잠시 동안 의지 할 것입니다. 그러나 다른 기능은 시스템이 성숙되고 생산 단계로 접어 들면서 중요해질 것입니다. CloudWatch를 사용하여 메트릭을 추적하고 예기치 않은 이벤트에 대한 알람을 설정합니다. CloudWatch의 로그 섹션은 AWS 콘솔에서 CloudWatch를 클릭 한 다음 탐색 창에서 로그를 클릭하여 액세스 할 수 있습니다. 3 장에서 개발 한 세 가지 기능에 해당하는 이미 생성 된 로그 그룹 집합을 볼 수 있습니다. 로그 그룹 중 하나를 클릭하면 로그 스트림 목록이 표시됩니다. 로그 스트림에는 발생한 이벤트의 원시 레코드 인 로그 이벤트가 들어 있습니다. 모든 로그 이벤트에는 시간 소인 W 이벤트 메시지가 있습니다. 오른쪽에있는 톱니 바퀴를 사용하면 기본 두 열보기에 열을 더 추가 할 수 있습니다. 생성 시간, 마지막 이벤트 시간, 첫 번째 이벤트 시간 및 ARN으로 열을 표시하도록 선택할 수 있습니다. 주요 로그보기를 보여줍니다. 전통적인 아키텍처에서 개발자 또는 솔루션 설계자는 보통 EC2 (Elastic Compute Cloud) 인스턴스에 로그 에이전트를 설치하고이를 사용하여 CloudWatch에 로그합니다. CloudWatch 로그 데이터는 무기한 저장됩니다. 만료되지 않습니다. 설정 한 기간 후에 CloudWatch에서 로그를 자동으로 삭제하도록하려면 CloudWatch 콘솔에서 로그를 삭제할 수 있습니다. 2. 보존 편집 대화 상자에서 원하는 기간을 선택하십시오. Never Expire에 이르기까지 1 일에서 10 년까지 다양합니다. 메트릭 필터는 들어오는 로그 이벤트에 대해 실행되는 패턴을 지정합니다. 일치하는 항목이 있으면 CloudWatch 측정 항목이 업데이트되어 그래프를 생성하거나 경보를 생성하는 데 사용할 수 있습니다. 패턴(pattern)- 로그에서 찾을 용어 나 구를 지정하는 데 사용됩니다. 값(value) - 메트릭에 게시 할 값입니다. 로그에서 추출한 수 또는 특정 용어 일 수 있습니다. 측정 항목 이름(metric name) - 값에 지정된 결과가 포함될 CloudWatch 측정 항목의 이름입니다. 네임 스페이스(namespace) - 관련 메트릭에 대한 그룹입니다. 필터 이름(filter name) - 필터의 이름입니다. 오류 때문에 람다 함수가 비정상적으로 종료 한 횟수를 추적하는 데 도움이되는 메트릭 필터, 메트릭 및 알람을 생성합니다. 2. 메트릭 필터 작성 단추를 클릭하여 계속하십시오. 필터 패턴 텍스트 상자에 "요청을 완료하기 전에 종료 된 프로세스"를 입력합니다. 4. 메트릭 지정을 클릭 한 다음 필터에 이름을 지정하고 메트릭 세부 사항을 설정합니다. 메트릭 네임 스페이스를 사용하면 관련 메트릭을 그룹화 할 수 있으므로 LambdaErrors와 같은 것을 사용하고 새 메트릭에 Lambda-ProcessExitErrorCount와 같은 이름을 지정합니다. 5. 필터 작성을 클릭하여 메트릭 필터를 작성합니다. 측정 항목을 만들었 으면 경보를 만들 수 있습니다. 또한 Metric Filter 패턴 구문을 사용하여 CloudWatch에서 로그 데이터를 검색 할 수 있습니다. 기존 로그 데이터를 검색하려면 로그 페이지로 이동하여 원하는 로그 그룹을 클릭하십시오. 로그 그룹 검색 단추를 클릭하고 필터 텍스트 상자에 패턴을 입력하십시오. 선택적으로 날짜 및 시간을 설정하여 검색 범위를 제한 할 수 있습니다. 특정 로그 스트림에서 검색을 수행하려면 먼저 이를 클릭 한 다음 패턴을 입력합니다. S3는 CloudWatch와 별도로 액세스 요청 및 로그 정보를 추적 할 수 있습니다. 이 로그는 누가 감사를 표시하고 어떤 서비스가 버킷에 액세스하는지에 대한 추가 정보를 얻는 데 유용합니다. S3 로그는 버킷 이름, 요청 시간 및 동작, 응답 상태와 같은 정보를 저장합니다. 1. S3 콘솔에서 로그 파일을 저장할 새 버킷을 만듭니다. 이 버킷의 이름을 serverless-video-logs로 지정하십시오. 2. "서버 액세스 로깅"버튼을 클릭하고 버킷의 로깅 기능을 활성화합니다. 5. 시스템을 테스트하려면 첫 번째 버킷에 개체를 업로드하거나 이름을 바꿉니다. 로그를 표시하는 데 몇 시간이 걸릴 수 있습니다. CloudWatch 알람은 지속 시간, 오류, 호출 또는 스로틀과 같은 메트릭을 모니터링하고 일정 시간 내에 이벤트 수가 설정된 임계 값을 초과하면 SNS에 메시지를 보내는 등의 작업을 수행합니다. 알람에는 세 가지 상태가 있습니다. OK- 모니터 된 메트릭이 정의 된 임계 값 내에 있습니다. 데이터 불충분(Insufficient Data) - 상태를 판별하는 데 사용할 수있는 데이터가 충분하지 않습니다. 경보(alarm) - 메트릭이 정의 된 임계 값의 범위를 벗어나므로 조치가 취해집니다. Lmabda 오류에 대한 알림을 트리거하는 경보를 작성해 보겠습니다. 이 경보는 1 분 간격으로 3 개 이상의 Lambda 오류가 발생하면 전자 메일을 보냅니다. lambda-error-notifications 이라는 SNS 항목을 작성하고 전자 메일 주소로 등록합니다 2. 주제에 관한 정보를 묻는 대화 상자가 화면에 나타납니다. 주제 이름을 lambda-error-notifications로 설정하고 표시 이름을 error-noti로 설정합니다. 저장할 주제 작성을 클릭합니다. 4. 주제 구독 버튼을 클릭하면 다른 대화 상자가 나타납니다. 5. 대화 상자에서 프로토콜을 전자 메일로 설정하고 전자 메일 주소를 엔드포인트 텍스트 상자에 입력하십시오. 7. 이메일을 확인하고 구독을 확인하십시오. 9. Alarm 대화 상자에서 Lambda Metric을 클릭 한 다음 Lambda> All Across Functions의 제목 아래에서 Errors 확인란을 선택합니다. 다음을 클릭하여 두 번째 페이지로 이동하십시오. 10. 경보의 이름 (예 : lambda-errors)을 입력 한 다음 한 번에 3 개 이상의 오류로 임계 값을 설정하십시오. 이제 알람이 제대로 설정되었는지 테스트해야합니다. 4. 선택할 수있는 테스트 이벤트 목록이 표시됩니다. 첫 번째 Hello World 테스트로 오류가 발생하기에 충분하므로 선택된 상태로두고 저장 및 테스트를 클릭합니다. 5. 테스트 결과에 즉각적인 오류가 발생해야합니다. 실행 결과에 "Failed"가 표시되고 오류 메시지에 "요청을 완료하기 전에 프로세스가 종료되었습니다"라고 표시되어야합니다. CloudWatch에서 알림을 받아야하므로 이메일을 확인합니다. CloudTrail은 API 호출을 기록하는 AWS 서비스입니다. API 호출자의 신원, 소스 IP 주소 및 이벤트와 같은 정보를 기록합니다. 이 데이터는 S3 버킷의 로그 파일에 저장됩니다. CloudTrail은 로그를 생성하고 AWS 서비스가 수행하는 작업과 누가 AWS 서비스를 호출하는지에 대한 정보를 수집하는 효과적인 방법입니다. 예를 들어, Elastic Transcoder가 새로운 작업을 시작하거나 유용한 S3 버킷을 삭제 한 사람을 찾을 때 사용한 이벤트를 볼 수 있습니다. CloudTrail은 CloudSearch, DynamoDB, Kinesis, API Gateway 및 Lambda를 비롯한 여러 AWS 서비스를 지원하며 로그를 CloudWatch 로그 그룹으로 직접 푸시하도록 구성 할 수 있습니다. CloudTrail은 사용자를 대신하여 사용자 또는 서비스가 계정 전반에 걸친 API 호출을 기록합니다. API 호출을 감사하고 문제를 진단하고 문제를 해결할 수있는 편리한 방법을 제공합니다. CloudTrail은 흔적 개념을 소개합니다.이 개념은 API 로깅을 활성화하는 구성입니다. 트레일에는 두 가지 유형이 있습니다. 하나는 모든 지역에 적용되고 다른 하나는 특정 지역에 적용됩니다. 일이 잘못되었을 때 시스템 내에서 일어나는 일을 이해하는 데 도움이되기 때문에 CloudTrail을 활성화해야합니다. 당신의 지역을위한 흔적을 만드는 단계를 밟아 봅시다! 1. AWS 콘솔에서 CloudTrail을 클릭 한 다음 지금 시작하기를 클릭합니다. 2. “추적 생성" 버튼을 클릭합니다. 3. “추적 이름"은 24-Hour-Video 입력을 하고 추적은 모든 리전에 적용을 아니요로 선택합니다. 4. 새 S3 버켓 작성을 아니오로 설정하고 S3 버킷 드롭 다운 목록에서 이전에 작성한 로그 (serverless-video-logs)에 대한 버킷을 선택합니다. 5. 추가 옵션을 보려면 고급을 클릭하십시오. 아무 것도 설정할 필요는 없지만 원하는 경우 SNS 알림 및 로그 파일 유효성 검사를 활성화 할 수 있습니다. 6. 추적을 저장하고 구성을 완료하려면 생성을 클릭합니다. 7. 트레일이 만들어지면 모든 지역에서 계정에 대한 모든 경로를 나열하는 표가 나타납니다. 하나의 트레일 만 작성 했으므로 클릭하여 옵션을 검사하고 구성합니다 구성해야 할 한 가지는 CloudWatch와의 통합입니다. 9. 계속 버튼을 클릭합니다. 10. 허용을 클릭합니다. CloudTrail이 CloudWatch API 호출을 실행할 수 있는 역할이 생성됩니다. CloudTrail의 API 활동 내역 페이지는 지난 7 일 동안 실행 된 API 호출을 작성, 수정 및 삭제합니다. 각 이벤트를 확장 한 다음 이벤트보기 단추를 클릭하여 자세한 정보를 볼 수 있습니다. 이벤트는 표시되는 데 최대 15 분이 걸릴 수 있습니다. 또는 S3 버킷을 검사하여 API 작업의 전체 로그를 보거나 CloudWatch에서 생성 된 해당 로그 그룹을 볼 수 있습니다. 결제 알림을 생성하려면 다음 단계를 진행합니다. 결제 및 비용 관리 콘솔에서 결제 알림 사용한다. 4. CloudWatch 콘솔을 열고 탐색 분할 창에서 청구를 선택합니다. 5. 경보 생성 버튼을 클릭 한 다음 청구 메트릭 하위 머리글을 클릭합니다. 6. 청구> 총 예상 충전량에서 첫 번째 확인란을 선택합니다 (예상 요금 측정 항목). 이 옵션을 선택하면 모든 AWS 서비스에서 예상 비용이 포착됩니다. 그러나 세분화되고 특정 서비스를 선택할 수 있습니다. 7.이 대화 상자는 사용한 대화 상자와 유사합니다. 지출 임계 값을 설정하고 통지 전달을위한 SNS 주제를 선택하십시오. 원하는 경우 새 목록을 클릭하고 이메일 주소를 직접 입력 할 수 있습니다. CloudCheckr (http://cloudcheckr.com)과 같은 서비스는 사용중인 서비스 및 리소스를 분석하여 비용을 추적하고 경고를 보내며 비용 절감을 도울 수 있습니다. CloudCheckr은 S3, CloudSearch, SES, SNS 및 DynamoDB를 비롯한 여러 AWS 서비스로 구성됩니다. 기능이 풍부하고 표준 AWS 기능보다 사용하기 쉽습니다. 권장 사항 및 일일 알림을 고려해 볼 가치가 있습니다. 또한 AWS에는 성능, 내결함성, 보안 및 비용 최적화의 개선을 제안하는 Trusted Advisor라는 서비스가 있습니다. 안타깝게도 Trusted Advisor의 무료 버전은 제한되어 있으므로 제공해야하는 모든 기능과 권장 사항을 살펴 보려면 유료 월간 요금제로 업그레이드하거나 AWS 엔터프라이즈 계정을 통해 액세스해야합니다. 비용 탐색기는 AWS에 내장 된 유용한 고급 보고서 작성 및 분석 도구입니다. 먼저 AWS 콘솔의 오른쪽 상단에서 이름 (또는 IAM 사용자 이름)을 클릭하고 My Billing Dashboard를 선택한 다음 탐색 창에서 비용 탐색기를 클릭하고 활성화하여 활성화해야합니다. 비용 탐색기는 이번 달 및 지난 4 개월 동안의 비용을 분석합니다. 그런 다음 향후 3 개월 동안 예측을 생성합니다. AWS가 당월 데이터를 처리하는 데 24 시간이 걸리기 때문에 처음에는 정보가 표시되지 않을 수 있습니다. 이전 달 동안의 데이터 처리로 시간이 오래 걸립니다 Simple Monthly Calculator (http://calculator.s3.amazonaws.com/index.html)는 Amazon에서 개발 한 웹 응용 프로그램으로 많은 서비스 비용 모델링에 도움을줍니다. 이 도구를 사용하여 콘솔의 왼쪽에있는 서비스를 선택한 다음 특정 자원의 소비와 관련된 정보를 입력하여 표시 비용을 얻을 수 있습니다. 이 추정치는 주로 S3, CloudFront 및 AWS 지원 계획에 대한 비용입니다. 이 도구는 복잡한 도구이며 유용성 문제가있는 것은 아니지만 견적을 도울 수 있습니다. 콘솔 오른쪽에있는 Common Customer Samples (공통 고객 샘플)를 클릭하거나 사용자 고유의 값을 입력하여 예상치를 볼 수 있습니다. 24 시간 비디오의 모델이 될 수있는 Media Application 고객 샘플을 가져 가면 다음과 같이 나뉩니다. 서버리스 아키텍처를 실행하는 비용은 종종 기존 인프라를 실행하는 것보다 훨씬 적습니다. 당연히 사용하는 각 서비스의 비용은 다를 수 있지만 Lambda 및 API 게이트웨이를 사용하여 서버가없는 시스템을 실행하는 데 필요한 사항을 살펴볼 수 있습니다. Amazon의 Lambda (https://aws.amazon.com/lambda/pricing/) 가격 책정은 요청 수, 실행 기간 및 함수에 할당 된 메모리 양에 따라 결정됩니다. 1 백만 건의 요청은 무료이며 그 이후의 각 요청은 $ 0.20입니다. 지속 시간은 함수가 실행되는 데 걸리는 시간을 기준으로 다음 100ms로 올림됩니다. Amazon은 기능을 위해 예약 된 메모리 양을 고려하면서 100ms 단위로 요금을 부과합니다. 1GB 메모리로 작성된 함수의 실행 시간은 100ms 당 $ 0.000001667 인 반면 128MB 메모리로 작성된 함수는 100ms 당 0.000000208입니다. 아마존의 가격은 지역에 따라 다를 수 있으며 언제든지 변경 될 수 있습니다. 예를 들어 한 달에 5 백만 번 256MB 기능을 실행해야하는 시나리오를 생각해보십시오. 이 함수는 매번 2 초 동안 실행됩니다. 비용 계산은 다음과 같습니다. 월간 계산 요금 : GB 초당 함수의 계산 가격은 $ 0.00001667입니다. 무료 티어는 400,000 GB-second를 무료로 제공합니다. 이 시나리오에서이 기능은 10ms (5M * 2 초) 동안 실행됩니다. 256MB의 메모리에서 10M 초는 2,500,000GB - 초 (10,000,000 * 256MB / 1024 = 2,500,000)와 같습니다. 해당 월의 총 청구 가능 금액 (GB - 초)은 2,100,000입니다 (2,500,000GB - 초 - 400,000 회 무료 GB - 초 = 2,100,000). 따라서 계산 요금은 $ 35.007 (2,100,000 GB - 초 * $ 0.00001667 = $ 35.007)입니다. 이 예제에서 람다를 실행하는 데 드는 총 비용은 $ 35.807입니다. API 게이트웨이 가격은받은 API 호출 수와 AWS에서 전송 된 데이터의 양에 따라 결정됩니다. 미국 동부 지역에서 아마존은 접수 된 백만 건의 API 호출 당 3.50 달러를 지불하고 처음 10TB는 0.09 달러 / GB를 양도합니다. 앞의 예에서 월별 아웃 바운드 데이터 전송이 매월 100GB라고 가정하면 API 게이트웨이 가격은 다음과 같습니다. 월간 데이터 요금 :AWS 보안, 로깅, 알람, 비용
로깅 및 경고는 서버가 없거나 전통적인 모든 시스템의 핵심 구성 요소입니다. 그들은 서비스 실패 또는 급격한 비용 상승과 같은 심각한 사건을 피할 수 있습니다. 일이 나 빠지면 강력한 로깅 및 경고 프레임 워크가 마련되어있어 감사하게 생각할 것입니다.
비용은 AWS와 같은 플랫폼을 사용하고 서버리스 아키텍처를 구현할 때 중요한 고려 사항입니다. 사용하려는 서비스의 비용 계산을 이해하는 것이 중요합니다. 이것은 청구서 충격을 피할뿐만 아니라 다음 달 비용을 예측하는 데 유용합니다. 우리는 서비스 비용을 예측하고 비용 추적 및 통제하에 대한 전략을 논의합니다.IAM 관리
IAM 사용자는 일반적으로 AWS에서 고유하게 식별되는 사용자 및 Amazon Resource Name (ARN)을 식별하는 데 도움이되는 친숙한 이름을 사용합니다. AWS의 IAM 콘솔로 이동해 보겠습니다. lambda 사용자를 클릭합니다.그룹(group) 만들기
그룹에 참여하는 모든 사용자는 그룹에 할당 된 권한을 상속받습니다. 마찬가지로 사용자가 그룹을 탈퇴하면 해당 그룹의 권한이 사용자에게서 제거됩니다. 또한 그룹은 사용자 만 포함 할 수 있으며 다른 그룹이나 역할과 같은 엔티티는 포함 할 수 없습니다.
3. 그룹에 정책을 붙이지않습니다. 다음 단계를 클릭 한 다음 그룹 생성을 클릭하여 저장하고 종료합니다.
{
"Sid": "Stmt1451465505000", (1)
"Effect": "Allow",
"Action": [
"lambda:GetFunction", (2)
"lambda:UpdateFunctionCode",
"lambda:UpdateFunctionConfiguration"
],
"Resource": [
"arn:aws:lambda:*"
(2) 필요한 Lambda 함수를 얻을 수 있고, 함수 코드를 업데이트하고, 설정을 업데이트 할 수있는 세 가지 동작을 허용합니다.역할(role) 생성
권한과 정책
정책의 범위는 다양 할 수 있습니다. 사용자 또는 역할 관리자에게 전체 계정에 대한 액세스 권한을 부여하거나 개별 작업을 지정할 수 있습니다. 세분화되고 작업 완료 (최소한의 권한 액세스)에 필요한 권한 만 지정하는 것이 좋습니다. 최소한의 권한 집합으로 시작하고 필요한 경우에만 사용 권한을 추가합니다.
인라인 정책은 특정 사용자, 그룹 또는 역할에 직접 생성되고 첨부됩니다. 엔티티가 삭제되면 엔티티에 포함 된 인라인 정책도 삭제됩니다. 자원 기반 정책은 항상 인라인입니다. 인라인 또는 관리되는 정책을 추가하려면 필요한 사용자, 그룹 또는 역할을 클릭 한 다음 사용 권한 탭을 클릭합니다. 관리되는 정책을 첨부, 확인 또는 분리 할 수 있으며 이와 유사하게 인라인 정책을 만들거나 보거나 제거 할 수 있습니다.
"Version":"2012-10-17", (1)
"Statement": [ (2)
{
"Effect": "Allow",
"Action": "logs:*",
"Resource":"arn:aws:logs:*:*:*"
},
....
(2) 명령문 배열은 정책을 구성하는 실제 사용 권한을 지정하는 하나 이상의 명령문을 포함합니다.자원(Resources)
자원 기반 정책은 주어진 자원에 누가 액세스 할 수 있는지를 지정합니다. 이를 통해 신뢰할 수있는 사용자는 역할을 맡을 필요없이 리소스에 액세스 할 수 있습니다. AWS 사용자 안내서에는 "자원 기반 정책을 사용한 교차 계정 액세스는 역할보다 이점이 있습니다. 리소스 기반 정책을 통해 액세스되는 리소스의 경우 사용자는 여전히 신뢰할 수있는 계정에서 작업하므로 역할 사용 권한 대신 사용자 권한을 포기할 필요가 없습니다. 즉, 사용자는 트러스 팅 계정의 리소스에 액세스 할 수있는 동시에 신뢰할 수있는 계정의 리소스에 계속 액세스 할 수 있습니다. "그러나 모든 AWS 서비스가 리소스 기반 정책을 지원하지는 않습니다. 현재 S3 버킷, SNS 주제, SQS 대기열, 빙하 금고, OpsWorks 스택 및 람다 기능 만 수행합니다.
...
{
"Effect": "Allow", (3)
"Action": [ (4)
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::*" (5)
(4) Action 요소 또는 배열은 리소스에서 허용되거나 거부되어야하는 특정 작업을 지정합니다. 와일드 카드 (*) 문자를 사용할 수 있습니다.
(5) Resource 요소는 명령문이 적용되는 객체를 식별합니다.
"DateLessThan": { (1)
"aws:CurrentTime": "2016-10-12T12:00:00Z"
},
"IpAddress": {
"aws:SourceIp": "127.0.0.1" (2)
}
}
조건 연산자가 여러 개 있거나 단일 조건 연산자에 연결된 여러 키가있는 경우 논리 AND를 사용하여 조건을 평가합니다. 단일 조건 연산자가 하나의 키에 대해 여러 값을 포함하면 해당 조건 연산자는 논리 OR를 사용하여 계산됩니다.
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html
Amazon은 보안을 위해 실용적인 범위 내에서 조건을 사용할 것을 권장합니다. 예를 들어 다음 코드는 HTTPS / SSL을 통해서만 콘텐츠를 제공하도록하는 S3 버킷 정책을 보여줍니다. 이 정책은 암호화되지 않은 HTTP를 통한 연결을 거부합니다.
https://raw.githubusercontent.com/KimJeongChul/architect-cloud/master/serverless/lambda-upload-policy/https-ssl-policy.json
{
"Effect": "Deny",
"Principal": "*", (1)
"Action": "s3:*", (1)
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"Bool": {
"aws:SecureTransport": false (2)
(2) SSL을 사용하여 요청을 보내지 않은 경우 조건이 충족됩니다. 이렇게하면 일반 암호화되지 않은 HTTP를 통해 정책에 액세스하려는 경우 정책에서 강제로 버킷에 대한 액세스를 차단합니다.CloudWatch
대부분의 서비스와 마찬가지로 AWS는 지역에 따라 CloudWatch의 가격 모델이 다릅니다. 미국 동부 (버지니아 북부)에서 CloudWatch를 사용한다고 가정 할 때 가격은 수집 된 로그의 GB 당 $ 0.50이며 월간 보관 로그의 GB 당 $ 0.03입니다. 알람은 매월 알람 당 $ 0.10이며, 맞춤 측정 항목은 측정 항목 당 $ 0.50입니다. CloudWatch의 무료 티어는 10 개의 맞춤 측정 항목, 10 개의 알람, 고객 당 1,000 개의 SNS 이메일 알림, 5GB의 데이터 처리 및 5GB의 보관 된 스토리지로 구성됩니다.
serverless 아키텍처를 사용하면 EC2 인스턴스를 프로비저닝하고 에이전트를 설치하는 것에 대해 걱정할 필요가 없습니다. Lambda는 CloudWatch에 자동으로 로그를 남깁니다. 실제로 잘 작동 할 수 있습니다. 특히 좋은 로깅 프레임 워크가 있는 경우 더욱 그렇습니다. 우리는 나중에 이야기 할 것입니다.
1. CloudWatch 콘솔에서 로그 페이지를 클릭하고 이후 이벤트 만료에서 만료 기간 없음을 클릭하여 보존 기간을 변경합니다.
메트릭 필터에는 다음과 같은 중요한 구성 요소가 포함됩니다.
1. CloudWatch 콘솔에서 탐색 창에서 로그를 클릭 한 다음 / aws / lambda / transcode-video 로그 그룹 옆의 확인란을 선택합니다.
3. 이전에이 오류 메시지가 표시된 로그 이벤트가 있으면 패턴을 테스트 할 수 있습니다. 패턴을 입력 한 위치의 바로 아래에있는 드롭 다운을 사용하고 패턴 테스트 버튼을 클릭하여 기존 로그 스트림을 살펴볼 수 있습니다.S3와 로깅(logging)
24 시간 비디오는 비디오 파일의 저장을 위해 S3에 의존하며 서버가없는 아키텍처를 사용하는 많은 시스템에서도 S3을 사용합니다. 따라서 S3 로깅을 활성화하고 사용하는 방법을 배우려면 처음 만든 버킷에 대해 S3 로깅을 활성화해야합니다.
3. 대상 버킷 드롭 다운에서 "serverless-video-logs"에서 만든 버킷을 선택합니다.
4. 대상 접두어에 upload / and save를 입력합니다.SNS 주제 구독 설정
1. AWS 콘솔에서 SNS를 클릭합니다. 탐색 창에서 주제를 선택하고 새 주제 작성 버튼을 클릭합니다.
3. 토픽을 만든 후에 토픽리스트 뷰에 머물러있을 것이고, 새로운 토픽이 리스트에 나타날 것입니다. 옆에있는 확인란을 선택하고 동작을 클릭합니다.
6. 서브 스크립 션 작성을 클릭하여 대화 상자를 저장하고 닫으십시오.
8. CloudWatch 콘솔에서 Alarms를 클릭 한 다음 Create Alarm을 클릭하십시오.
11. 기간을 1 분으로 변경 한 다음 통계를 합계로 변경합니다.
12. Actions (작업)에서 두 번째 드롭 다운에서 이전에 생성 한 SNS 주제를 선택합니다.
13. 경보 작성을 클릭하여 경보 작성을 완료합니다.AWS Lambda 오류 생성하기
2. AWS 콘솔에서 Lambda를 열고 기능 옆에있는 라디오 버튼을 클릭합니다
3. Actions (작업) 드롭 다운에서 Test Function (테스트 기능)을 선택합니다.
6. 테스트 버튼을 세 번 또는 네 번 더 클릭하여 알람에 충분한 데이터가 있는지 확인합니다.CloudTrail
CloudTrail의 무료 티어를 사용하면 지역별 무료 트레일을 만들 수 있습니다. 그러나 추가 트레일의 경우, 기록 된 10 만 건당 $ 2.00입니다.
8. 트레일 구성 페이지에서 CloudWatch 로그 섹션 아래의 구성을 클릭합니다.결제 알림 설정
1. 기본 AWS 콘솔에서 이름 (또는 자신을 나타내는 IAM 사용자의 이름)을 클릭 한 다음 내 대시 보드를 클릭합니다.
2. 탐색 창에서 기본 설정을 클릭 한 다음 수신 알림 수신 옆에있는 확인란을 선택합니다.
3. 환경 설정 저장을 클릭합니다.
8. 오른쪽 아래 모서리에있는 알람 만들기 버튼을 클릭하여 알람 만들기 대화 상자를 엽니다.비용 관리 및 최적화
S3 예상 비용은 $ 9.01입니다. 300GB 스토리지, 200PUT / COPY / POST / LIST 요청, 100GET 및 기타 요청, 2GB / month 데이터 전송 및 10GB / month 데이터 전송이 포함됩니다.
CloudFront의 예상 비용은 $ 549.96입니다. 평균 오브젝트 크기가 300KB 인 5000GB / 월 데이터 전송이 포함됩니다. 에지 위치 트래픽 분포는 미국과 유럽에서는 30 %, 일본에서는 15 %, 홍콩, 필리핀, 한국, 싱가포르 및 대만에서는 25 %입니다.
AWS 비즈니스 지원 계획은 $ 100.00입니다.
Amazon은 1 백만 건의 무료 요청과 한 달에 40 만 기가 초의 계산 시간을 가진 영구 무료 티어를 제공합니다. 이는 사용자가 백만 건의 요청을 수행하고 지불해야하기 전에 1GB의 메모리로 작성된 기능을 실행하는 데 400,000 초를 소비 할 수 있음을 의미합니다.
월간 청구 금액 :
무료 티어는 1 백만 건의 요청을 제공합니다. 즉, 4 백만 건의 청구 가능 요청 (5M 요청 - 1M 무료 요청 = 4M 요청) 만 제공됩니다.
각 백만 달러는 0.20 달러로 책정되어 청구액이 0.80 달러가됩니다 (4M 요청 * $ 0.2 / M = 0.80 달러).
월별 API 청구 :
무료 티어에는 한 달에 백만 건의 API 호출이 포함되지만 단 12 개월 만 유효합니다. 영구적 인 무료 계층이 아니므로이 계산에 포함되지 않습니다.
총 API 비용은 $ 17.50 (5M 요청 * $ 3.50 / M = $ 17.50)입니다.
데이터 요금은 $ 9.00입니다 (100GB * $ 0.09 / GB = $ 9).
이 예에서 API 게이트웨이 비용은 $ 26.50입니다. 람다 및 API 게이트웨이의 총 비용은 한 달에 62.307 달러입니다. 지속적으로 처리해야 할 요청 및 작업의 수를 모델링하는 것이 좋습니다. 128MB의 메모리 만 사용하고 1 초 동안 실행되는 람다 함수의 2M 호출을 예상하면 대략 $ 0.20 개월을 지불하게됩니다. 512MB의 RAM이 5 초 동안 실행되는 함수의 2M 호출을 예상하면 $ 75.00 조금 더 지불하게됩니다. Lambda를 사용하면 비용을 평가하고 사전 계획을 세우며 실제로 사용하는 것에 대해서만 비용을 지불 할 수 있습니다. 마지막으로 S3 나 SNS와 같은 다른 서비스를 고려해보십시오. 아무리 중요하지 않더라도 상관 없습니다.
Jeongchul Kim
