모니터링 비용 - Amazon Cognito
비용 보기 및 예상 비용 관리

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

모니터링 비용

Amazon Cognito는 다음과 같은 사용량 차원에 대해 요금을 부과합니다.

  • 사용자 풀 월간 활성 사용자 수 () MAUs

  • OIDC또는 SAML 페더레이션으로 MAUs 로그인한 사용자 풀

  • MAUs고급 보안 기능을 갖춘 사용자 풀에서

  • 활성 사용자 풀 앱 클라이언트 및 클라이언트 자격 증명 부여를 통한 M2M (Machine to Machine) 인증을 위한 요청 볼륨

  • 일부 사용자 풀 카테고리의 기본 할당량을 초과하여 구매한 사용량을 초과했습니다. APIs

또한 이메일 메시지, SMS 메시지, Lambda 트리거와 같은 사용자 풀 기능으로 인해 종속 서비스에서 비용이 발생할 수 있습니다. 전체 개요는 Amazon Cognito 요금을 참조하십시오.

비용 보기 및 예상

AWS Billing and Cost Management 콘솔에서 AWS 비용을 보고 보고할 수 있습니다. 청구 및 결제 섹션에서 Amazon Cognito에 대한 가장 최근 요금을 확인할 수 있습니다. 청구서, 서비스별 요금에서 Cognito 필터링하여 사용량을 확인하세요. 자세한 내용은 AWS Billing 사용 설명서에서 결제 보기를 참조하세요.

API요청 비율을 모니터링하려면 Service Quotas 콘솔에서 사용률 지표를 검토하세요. 예를 들어 클라이언트 자격 증명 요청은 요청 비율로 표시됩니다. ClientAuthentication 청구서에서 이러한 요청은 요청을 생성한 앱 클라이언트와 연결됩니다. 이 정보를 사용하면 멀티테넌트 아키텍처에서 테넌트에게 비용을 공평하게 할당할 수 있습니다.

일정 기간 동안의 M2M 요청 수를 파악하기 위해 Logs로 이벤트를AWS CloudTrail 전송하여 분석할 수도 있습니다. CloudWatch 클라이언트 자격 증명 CloudTrail 부여로 Token_POST 이벤트에서 이벤트를 쿼리하세요. 다음 CloudWatch Insights 쿼리는 이 수를 반환합니다.

filter eventName = "Token_POST" and @message like '"grant_type":["client_credentials"]' | stats count(*)

비용 관리

Amazon Cognito는 사용자 수, 기능 사용량 및 요청량을 기준으로 요금을 청구합니다. 다음은 Amazon Cognito에서 비용을 관리하기 위한 몇 가지 팁입니다.

비활성 사용자를 활성화하지 마세요.

사용자를 활성화시키는 일반적인 작업은 로그인, 가입, 암호 재설정입니다. 자세한 목록은 을 참조하십시오. 월별 활성 사용자) Amazon Cognito는 비활성 사용자를 청구서에 포함하지 않습니다. 사용자를 활성 상태로 설정하는 작업은 피하십시오. 작업 대신 AdminGetUserAPI작업을 사용하여 사용자를 쿼리하세요. ListUsers 비활성 사용자를 대상으로 사용자 풀 작업에 대한 대량의 관리 테스트를 수행하지 마세요.

페더레이션 사용자 연결

SAML2.0 또는 OpenID Connect (OIDC) ID 공급자로 로그인하는 사용자는 로컬 사용자보다 비용이 많이 듭니다. 이러한 사용자를 로컬 사용자 프로필에 연결할 수 있습니다. 연결된 사용자는 페더레이션 사용자와 함께 제공되는 속성 및 액세스 권한을 사용하여 로컬 사용자로 로그인할 수 있습니다. 연결된 로컬 계정으로 SAML OIDC IdPs 로그인했거나 한 달 동안 연결된 로컬 계정으로만 로그인한 사용자는 로컬 사용자로 요금이 청구됩니다.

요청 비율 관리

사용자 풀이 할당량 상한에 가까워지면 볼륨을 처리할 추가 용량 구매를 고려할 수 있습니다. 애플리케이션에서 요청의 양을 줄일 수 있을 수도 있습니다. 자세한 내용은 할당량 한도에 대한 요청 비율을 최적화하세요. 단원을 참조하십시오.

필요한 경우에만 새 토큰을 요청하세요.

클라이언트 자격 증명을 통한 M2M (Machine to Machine) 인증은 많은 양의 토큰 요청에 도달할 수 있습니다. 각각의 새 토큰 요청은 요청률 할당량 및 청구 규모에 영향을 미칩니다. 비용을 최적화하려면 애플리케이션 설계에 토큰 만료 설정 및 토큰 처리를 포함하세요.

  • 애플리케이션에서 새 토큰을 요청할 때 이전에 발행한 토큰의 캐시된 버전을 받을 수 있도록 액세스 토큰을 캐시합니다. 이 방법을 구현하면 캐싱 프록시는 이전에 획득한 토큰의 만료를 알지 못한 채 액세스 토큰을 요청하는 애플리케이션을 차단하는 역할을 합니다. 캐싱 토큰은 Lambda 함수 및 Docker 컨테이너와 같은 수명이 짧은 마이크로서비스에 적합합니다.

  • 토큰 만료를 고려한 토큰 처리 메커니즘을 애플리케이션에 구현하십시오. 이전 토큰이 만료되기 전까지는 새 토큰을 요청하지 마세요. 가장 좋은 방법은 토큰 수명 주기의 약 75% 에 토큰을 새로 고치는 것입니다. 이렇게 하면 애플리케이션에서 사용자 연속성을 보장하는 동시에 토큰 지속 시간을 극대화할 수 있습니다.

    각 애플리케이션의 기밀성 및 가용성 요구 사항을 평가하고 적절한 유효 기간의 액세스 토큰을 발급하도록 사용자 풀 앱 클라이언트를 구성하십시오. 사용자 지정 토큰 기간은 수명이 APIs 길고 자격 증명 요청 빈도를 지속적으로 관리할 수 있는 서버에 가장 적합합니다.

사용하지 않는 클라이언트 자격 증명 (앱 클라이언트) 삭제

M2M 승인 청구는 토큰 요청 비율과 클라이언트 자격 증명을 부여하는 앱 클라이언트 수라는 두 가지 요소를 기반으로 합니다. M2M 인증용 앱 클라이언트를 사용하지 않는 경우 해당 클라이언트를 삭제하거나 클라이언트 자격 증명을 발급할 수 있는 권한을 제거하세요. 앱 클라이언트 구성 관리에 대한 자세한 내용은 을 참조하십시오. 사용자 풀 앱 클라이언트

고급 보안 관리

사용자 풀에서 고급 보안 기능을 구성하면 사용자 풀의 모든 MAUs 사용자에게 고급 보안 청구 요금이 적용됩니다. 고급 보안 기능이 필요하지 않은 사용자가 있는 경우 사용자를 다른 사용자 풀로 분리하세요.