쿠키 기본 설정 선택

당사는 사이트와 서비스를 제공하는 데 필요한 필수 쿠키 및 유사한 도구를 사용합니다. 고객이 사이트를 어떻게 사용하는지 파악하고 개선할 수 있도록 성능 쿠키를 사용해 익명의 통계를 수집합니다. 필수 쿠키는 비활성화할 수 없지만 '사용자 지정' 또는 ‘거부’를 클릭하여 성능 쿠키를 거부할 수 있습니다.

사용자가 동의하는 경우 AWS와 승인된 제3자도 쿠키를 사용하여 유용한 사이트 기능을 제공하고, 사용자의 기본 설정을 기억하고, 관련 광고를 비롯한 관련 콘텐츠를 표시합니다. 필수가 아닌 모든 쿠키를 수락하거나 거부하려면 ‘수락’ 또는 ‘거부’를 클릭하세요. 더 자세한 내용을 선택하려면 ‘사용자 정의’를 클릭하세요.

설정
문의하기
피드백
AWS Documentation
AWS 계정 생성

AWS AppSync에서 데이터 소스 연결

PDF
포커스 모드
AWS AppSync에서 데이터 소스 연결 - AWS AppSync GraphQL
데이터 원본 유형데이터 원본 추가

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

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

데이터 소스는 GraphQL APIs 수 있는 AWS 계정의 리소스입니다. AWS AppSync는 Amazon DynamoDB AWS Lambda, 관계형 데이터베이스(Amazon Aurora Serverless), Amazon OpenSearch Service 및 HTTP 엔드포인트와 같은 다양한 데이터 소스를 지원합니다. 여러 데이터 소스와 상호 작용하도록 AWS AppSync API를 구성할 수 있으므로 단일 위치에서 데이터를 집계할 수 있습니다. AWS AppSync는 계정의 기존 AWS 리소스를 사용하거나 스키마 정의에서 사용자를 대신하여 DynamoDB 테이블을 프로비저닝할 수 있습니다.

다음 섹션에서는 GraphQL API에 데이터 원본을 연결하는 방법을 알아봅니다.

데이터 원본 유형

이제 AWS AppSync 콘솔에서 스키마를 생성했으므로 데이터 소스를 연결할 수 있습니다. API를 처음으로 만들 때 사전 정의된 스키마를 생성하는 동안 Amazon DynamoDB 테이블을 프로비저닝하는 옵션이 있습니다. 그러나 이 섹션에서는 이 옵션에 대해 다루지 않습니다. 이에 대한 예는 스키마 시작 섹션에서 확인할 수 있습니다.

대신 AWS AppSync가 지원하는 모든 데이터 소스를 살펴보겠습니다. 애플리케이션에 적합한 솔루션을 선택할 때는 여러 가지 요소를 고려하게 됩니다. 아래 섹션에서는 각 데이터 원본에 대한 몇 가지 추가 컨텍스트를 제공합니다. 데이터 원본에 대한 일반 정보는 데이터 원본을 참조하세요.

Amazon DynamoDB

Amazon DynamoDB는 확장 가능한 애플리케이션을 위한 AWS주요 스토리지 솔루션 중 하나입니다. DynamoDB의 핵심 구성 요소는 단순한 데이터 모음인 테이블입니다. 일반적으로 Book 또는 Author 등의 엔터티를 기반으로 테이블을 만들게 됩니다. 테이블 엔트리 정보는 각 엔트리에 고유한 필드 그룹인 항목으로 저장됩니다. 전체 항목은 데이터베이스의 행 및 레코드를 나타냅니다. 예를 들어, Book 엔트리의 항목에는 해당 값과 함께 title 및 author이(가) 포함될 수 있습니다. title 및 author 등의 개별 필드를 특성이라고 하며, 이는 관계형 데이터베이스의 열 값과 유사합니다.

추측할 수 있듯이 테이블은 애플리케이션의 데이터를 저장하는 데 사용됩니다.를 AWS AppSync 사용하면 DynamoDB 테이블을 GraphQL API에 연결하여 데이터를 조작할 수 있습니다. 프런트엔드 웹 및 모바일 블로그에서 이 사용 사례를 확인하세요. 이 애플리케이션을 통해 사용자는 소셜 미디어 앱에 가입할 수 있습니다. 사용자는 그룹에 가입하고 그룹에 가입한 다른 사용자에게 브로드캐스트되는 게시물을 업로드할 수 있습니다. 해당 애플리케이션은 사용자, 게시물 및 사용자 그룹 정보를 DynamoDB에 저장합니다. GraphQL API(관리형 AWS AppSync)는 DynamoDB 테이블과 인터페이스합니다. 사용자가 시스템에서 변경하는 내용이 프런트엔드에 반영되면 GraphQL API는 이러한 변경 사항을 검색하여 다른 사용자에게 실시간으로 브로드캐스트합니다.

AWS Lambda

Lambda는 이벤트에 대한 응답으로 코드를 실행하는 데 필요한 리소스를 자동으로 빌드하는 이벤트 기반 서비스입니다. Lambda는 리소스를 실행하기 위한 코드, 종속성 및 구성을 포함하는 그룹 문인 함수를 사용합니다. 함수는 함수를 간접적으로 호출하는 활동 그룹인 트리거를 감지하면 자동으로 실행됩니다. 트리거는 API 호출을 수행하는 애플리케이션, 리소스를 실행하는 계정의 AWS 서비스 등과 같은 것일 수 있습니다. 함수가 트리거되면 수정할 데이터가 포함된 JSON 문서인 이벤트를 처리합니다.

Lambda는 코드를 실행하는 데 적합하며, 실행을 위해 리소스를 프로비저닝할 필요가 없습니다. 프런트엔드 웹 및 모바일 블로그에서 이 사용 사례를 확인하세요. 이 사용 사례는 DynamoDB 섹션에 소개된 사용 사례와 약간 비슷합니다. 이 애플리케이션에서 GraphQL API는 게시물 추가(변형) 및 해당 데이터 가져오기(쿼리)와 같은 작업을 정의하는 역할을 합니다. 작업의 기능(예: getPost ( id: String ! ) : Post, getPostsByAuthor ( author: String ! ) : [ Post ])을 구현하기 위해 Lambda 함수를 사용하여 인바운드 요청을 처리합니다. 옵션 2:Lambda 해석기 AWS AppSync 에서 AWS AppSync 서비스를 사용하여 스키마를 유지하고 Lambda 데이터 소스를 작업 중 하나에 연결합니다. 작업이 호출되면 Lambda는 Amazon RDS 프록시와 상호 작용하여 데이터베이스에서 비즈니스 로직을 수행합니다.

Amazon RDS

Amazon RDS를 사용하면 관계형 데이터베이스를 빠르게 빌드하고 구성할 수 있습니다. Amazon RDS에서는 클라우드의 격리된 데이터베이스 환경으로 사용할 일반 데이터베이스 인스턴스를 만들게 됩니다. 이 인스턴스에서는 실제 RDBMS 소프트웨어(PostgreSQL, MySQL 등)인 DB 엔진을 사용합니다. 이 서비스는 AWS인프라, 패치 및 암호화와 같은 보안 서비스, 배포에 대한 관리 비용 절감을 통해 확장성을 제공하여 대부분의 백엔드 작업을 오프로드합니다.

Lambda 섹션에서 동일한 사용 사례를 확인하세요. 옵션 3:Amazon RDS 해석기를 AWS AppSync 사용할 때 표시되는 다른 옵션은의 GraphQL API를 Amazon RDS AWS AppSync 에 직접 연결하는 것입니다. 이 서비스는 데이터 API를 사용하여 데이터베이스를 GraphQL API와 연결합니다. 해석기는 필드(일반적으로 쿼리, 변형 또는 구독)에 연결되며 데이터베이스에 액세스하는 데 필요한 SQL 문을 구현합니다. 클라이언트가 필드를 호출하는 요청을 보내면 해석기는 문을 실행하고 응답을 반환합니다.

Amazon EventBridge

EventBridge에서는 연결한 서비스 또는 애플리케이션(이벤트 소스)으로부터 이벤트를 수신하고 정해진 규칙에 따라 이벤트를 처리하는 파이프라인인 이벤트 버스를 만들게 됩니다. 이벤트는 실행 환경의 상태가 일부 변하는 것을 의미하고, 규칙은 이벤트에 대한 필터 집합입니다. 규칙은 이벤트 패턴 또는 이벤트 상태 변화의 메타데이터(ID, 리전, 계정 번호, ARN 등)를 따릅니다. 이벤트가 이벤트 패턴과 매칭되면 EventBridge는 파이프라인을 통해 대상 서비스(대상)로 이벤트를 보내고 규칙에 지정된 작업을 트리거합니다.

EventBridge는 상태가 변경되는 작업을 일부 다른 서비스로 라우팅하는 데 적합합니다. 프런트엔드 웹 및 모바일 블로그에서 이 사용 사례를 확인하세요. 이 예시는 여러 팀이 서로 다른 서비스를 유지 관리하는 전자 상거래 솔루션을 보여줍니다. 이러한 서비스 중 하나는 프런트엔드에서 배송의 단계(주문 생성, 진행 중, 발송됨, 배송됨 등)마다 고객에게 주문 업데이트를 제공합니다. 그러나 별도의 백엔드 팀에서 주문 시스템 데이터를 유지 관리하기 때문에 이 서비스를 관리하는 프런트엔드 팀은 주문 시스템 데이터에 직접 액세스할 수 없습니다. 백엔드 팀의 주문 시스템은 블랙박스라고도 불릴 정도로 데이터를 구조화하는 방식에 대한 정보를 얻기가 어렵습니다. 하지만 백엔드 팀은 EventBridge에서 관리하는 이벤트 버스를 통해 주문 데이터를 게시하는 시스템을 구축했습니다. 이벤트 버스에서 오는 데이터에 액세스하여 프런트엔드로 라우팅하기 위해 프런트엔드 팀은 GraphQL API를 가리키는 새 대상을 생성했습니다 AWS AppSync. 또한 주문 업데이트와 관련된 데이터만 전송하는 규칙도 만들었습니다. 업데이트가 이루어지면 이벤트 버스의 데이터가 GraphQL API로 전송됩니다. API의 스키마는 데이터를 처리한 후 이를 프런트엔드로 전달합니다.

데이터 원본 없음

데이터 원본을 사용할 계획이 없다면 none으로 설정할 수 있습니다. 명시적으로는 여전히 데이터 소스로 분류되지만 none 데이터 원본은 저장 매체가 아닙니다. 일반적으로 해석기는 요청을 처리하기 위해 특정 시점에 하나 이상의 데이터 원본을 간접적으로 호출합니다. 그러나 데이터 원본을 조작할 필요가 없는 경우도 있습니다. 데이터 원본을 none(으)로 설정하면 요청이 실행되고 데이터 간접 호출 단계를 건너뛴 다음 응답이 실행됩니다.

EventBridge 섹션에서 동일한 사용 사례를 확인하세요. 스키마에서 변형은 상태 업데이트를 처리한 다음 구독자에게 전송합니다. 해석기의 작동 방식을 생각해보면, 보통 한 번 이상의 데이터 원본 간접 호출이 있습니다. 그러나 이 시나리오의 데이터는 이미 이벤트 버스에 의해 자동으로 전송되었습니다. 즉, 변형이 데이터 원본 간접 호출을 수행할 필요가 없으며, 주문 상태를 로컬에서 간단히 처리할 수 있습니다. 변형은 none(으)로 설정되며, 이 경우 데이터 원본 간접 호출 없이 패스스루 값으로 작동합니다. 그러면 데이터가 스키마에 채워지고 구독자에게 전송됩니다.

OpenSearch

Amazon OpenSearch Service는 전체 텍스트 검색, 데이터 시각화 및 로깅을 구현하는 도구 모음입니다. 이 서비스를 사용하여 업로드한 구조화된 데이터를 쿼리할 수 있습니다.

이 서비스에서는 OpenSearch의 인스턴스를 만들게 됩니다. 이를 노드라고 합니다. 노드에서는 인덱스를 하나 이상 추가하게 됩니다. 인덱스는 개념적으로 관계형 데이터베이스의 테이블과 조금 비슷합니다. (하지만 OpenSearch는 ACID를 준수하지 않으므로 그와 같은 방식으로 사용해서는 안 됩니다.) OpenSearch 서비스에 업로드하는 데이터로 인덱스를 채우게 됩니다. 데이터가 업로드되면 인덱스 내에 있는 하나 이상의 샤드에 데이터를 인덱싱합니다. 샤드는 일부 데이터를 포함하는 인덱스의 파티션과 같으며 다른 샤드와 별도로 쿼리할 수 있습니다. 업로드가 완료되면 데이터는 문서라는 JSON 파일로 구조화됩니다. 그러면 노드에 문서의 데이터를 쿼리할 수 있습니다.

HTTP 엔드포인트

HTTP 엔드포인트를 데이터 소스로 사용할 수 있습니다. AWS AppSync는 파라미터 및 페이로드와 같은 관련 정보를 사용하여 엔드포인트에 요청을 보낼 수 있습니다. HTTP 응답은 해석기에 노출되며, 해석기는 작업이 완료된 후 최종 응답을 반환합니다.

데이터 원본 추가

데이터 소스를 생성한 경우 이를 AWS AppSync 서비스, 특히 API에 연결할 수 있습니다.

Console

  1. 에 로그인 AWS Management Console 하고 AppSync 콘솔을 엽니다.

    1. 대시보드에서 API를 선택합니다.

    2. 사이드바에서 데이터 원본을 선택합니다.

  2. 데이터 원본 생성을 선택합니다.

    1. 데이터 원본의 이름을 지정합니다. 원하는 경우 설명을 입력할 수도 있습니다.

    2. 데이터 원본 유형을 선택합니다.

    3. DynamoDB의 경우 리전을 선택한 다음 리전의 테이블을 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 테이블과의 상호 작용 규칙을 지정할 수 있습니다. 버전 관리를 사용하도록 설정하여 여러 클라이언트가 동시에 데이터를 업데이트하려고 할 때 각 요청에 대한 데이터 버전을 자동으로 생성할 수 있습니다. 버전 관리는 충돌 감지 및 해결 목적으로 다양한 데이터 변형을 유지 및 관리하는 데 사용됩니다. 또한 데이터 원본을 가져오고 스키마에서 여기에 액세스하는 데 필요한 CRUD, List, Query 작업의 일부를 생성하는 자동 스키마 생성을 활성화할 수도 있습니다.

      OpenSearch의 경우 리전을 선택한 다음 리전의 도메인(클러스터) 을 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 도메인과의 상호 작용 규칙을 지정할 수 있습니다.

      Lambda의 경우 리전을 선택한 다음 리전에서 Lambda 함수의 ARN을 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 Lambda 함수와의 상호 작용 규칙을 지정할 수 있습니다.

      HTTP의 경우 HTTP 엔드포인트를 입력해야 합니다.

      EventBridge의 경우 리전을 선택한 다음 리전에서 이벤트 버스를 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 이벤트 버스와의 상호 작용 규칙을 지정할 수 있습니다.

      RDS의 경우 리전을 선택한 다음 암호 저장소(사용자 이름 및 암호), 데이터베이스 이름, 스키마를 선택해야 합니다.

      없음의 경우 실제 데이터 원본이 없는 데이터 원본을 추가하게 됩니다. 이는 실제 데이터 원본을 통하지 않고 로컬에서 해석기를 처리하기 위함입니다.

      참고

      기존 역할을 가져오는 경우 신뢰 정책이 필요합니다. 자세한 내용은 IAM 신뢰 정책을 참조하세요.

  3. 생성(Create)을 선택합니다.

    참고

    또는 DynamoDB 데이터 원본을 생성하는 경우 콘솔의 스키마 페이지로 이동하여 페이지 상단에서 리소스 생성을 선택한 다음 사전 정의된 모델을 채워 테이블로 변환할 수 있습니다. 이 옵션에서는 기본 유형을 채우거나 가져오고, 파티션 키를 포함한 기본 테이블 데이터를 구성하고, 스키마 변경 사항을 검토합니다.

CLI

  • create-data-source 명령을 실행하여 데이터 원본을 생성합니다.

    이 특정 명령에 대해 몇 가지 파라미터를 입력해야 합니다.

    1. API의 api-id.

    2. 테이블의 name.

    3. 데이터 원본의 type. 선택한 데이터 원본 유형에 따라 service-role-arn 및 -config 태그를 입력해야 할 수 있습니다.

    예를 들어 명령은 다음과 같을 수 있습니다.

     aws appsync create-data-source --api-id abcdefghijklmnopqrstuvwxyz --name data_source_name --type data_source_type --service-role-arn arn:aws:iam::107289374856:role/role_name --[data_source_type]-config {params}
CDK
작은 정보

CDK를 사용하기 전에 CDK의 공식 설명서를 CDK 참조와 함께 검토 AWS AppSync하는 것이 좋습니다.

아래 나열된 단계는 특정 리소스를 추가하는 데 사용되는 스니펫의 일반적인 예시만 보여줍니다. 프로덕션 코드에서는 이 예시가 올바르게 작동하는 솔루션이 아닙니다. 또한 이미 작동하는 앱을 가지고 있는 것으로 가정합니다.

특정 데이터 원본을 추가하려면 스택 파일에 구성을 추가해야 합니다. 데이터 원본 유형 목록은 다음에서 찾을 수 있습니다.

  1. 대개는 사용 중인 서비스에 가져오기 지침을 추가해야 할 수 있습니다. 예를 들면 다음 형식을 따를 수 있습니다.

    import * as x from 'x'; # import wildcard as the 'x' keyword from 'x-service'
import {a, b, ...} from 'c'; # import {specific constructs} from 'c-service'

    예를 들어, AWS AppSync 및 DynamoDB 서비스를 가져오는 방법은 다음과 같습니다.

    import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';

  2. RDS와 같은 일부 서비스는 데이터 원본을 생성하기 전에 스택 파일에 몇 가지 추가 설정이 필요합니다(예: VPC 생성, 역할, 액세스 보안 인증 정보). 자세한 내용은 관련 CDK 페이지의 예시를 참조하세요.

  3. 대부분의 데이터 소스, 특히 AWS 서비스의 경우 스택 파일에 데이터 소스의 새 인스턴스를 생성합니다. 일반적으로 다음과 같습니다.

    const add_data_source_func = new service_scope.resource_name(scope: Construct, id: string, props: data_source_props);

    예를 들어 Amazon DynamoDB 테이블의 예는 다음과 같습니다.

    const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
  partitionKey: {
    name: 'id',
    type: dynamodb.AttributeType.STRING,
  },
  sortKey: {
    name: 'id',
    type: dynamodb.AttributeType.STRING,
  },
  tableClass: dynamodb.TableClass.STANDARD,
});
    참고

    대부분의 데이터 원본은 필수 속성을 하나 이상 갖습니다(? 기호 없이 표시됨). 어떤 속성이 필요한지 알아보려면 CDK 설명서를 참조하세요.

  4. 다음으로 데이터 원본을 GraphQL API에 연결해야 합니다. 권장되는 방법은 파이프라인 해석기용 함수를 만들 때 추가하는 것입니다. 예를 들어 아래 스니펫은 DynamoDB 테이블의 모든 요소를 스캔하는 함수입니다.

    const add_func = new appsync.AppsyncFunction(this, 'func_ID', {
  name: 'func_name_in_console',
  add_api,
  dataSource: add_api.addDynamoDbDataSource('data_source_name_in_console', add_ddb_table),
  code: appsync.Code.fromInline(`
      export function request(ctx) {
        return { operation: 'Scan' };
      }

      export function response(ctx) {
        return ctx.result.items;
      }
  `),
  runtime: appsync.FunctionRuntime.JS_1_0_0,
});

    dataSource 속성에서 GraphQL API(add_api)를 호출하고 기본 제공되는 메서드(addDynamoDbDataSource) 중 하나를 사용하여 테이블과 GraphQL API 사이의 연결을 설정할 수 있습니다. 인수는 AWS AppSync 콘솔에 존재할이 링크의 이름(data_source_name_in_console이 예제에서는 )과 테이블 메서드()입니다add_ddb_table. 이 주제에 대한 자세한 내용은 다음 섹션에서 해석기 제작을 시작하면서 설명하겠습니다.

    다른 방법으로도 데이터 원본을 연결할 수 있습니다. 기술적으로는 테이블 함수의 속성 목록에 api를 추가할 수 있습니다. 예를 들어 다음은 3단계의 스니펫이지만, 여기에는 GraphQL API가 포함된 api 속성이 있습니다.

    const add_api = new appsync.GraphqlApi(this, 'API_ID', {
  ...
});

const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {

 ...

  api: add_api
});

    또는 GraphqlApi 구성을 별도로 호출할 수도 있습니다.

    const add_api = new appsync.GraphqlApi(this, 'API_ID', {
  ...
});

const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
  ...
});

const link_data_source = add_api.addDynamoDbDataSource('data_source_name_in_console', add_ddb_table);

    함수의 속성에만 연결을 만드는 것이 좋습니다. 그렇지 않으면 AWS AppSync 콘솔에서 해석기 함수를 데이터 소스에 수동으로 연결하거나(콘솔 값을 계속 사용하려는 경우data_source_name_in_console) 함수에서와 같은 다른 이름으로 별도의 연결을 생성해야 합니다data_source_name_in_console_2. 이는 속성이 정보를 처리하는 방식에 제한이 있기 때문입니다.

    참고

    변경 사항을 확인하려면 앱을 다시 배포해야 합니다.

anchoranchoranchor

  1. 에 로그인 AWS Management Console 하고 AppSync 콘솔을 엽니다.

    1. 대시보드에서 API를 선택합니다.

    2. 사이드바에서 데이터 원본을 선택합니다.

  2. 데이터 원본 생성을 선택합니다.

    1. 데이터 원본의 이름을 지정합니다. 원하는 경우 설명을 입력할 수도 있습니다.

    2. 데이터 원본 유형을 선택합니다.

    3. DynamoDB의 경우 리전을 선택한 다음 리전의 테이블을 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 테이블과의 상호 작용 규칙을 지정할 수 있습니다. 버전 관리를 사용하도록 설정하여 여러 클라이언트가 동시에 데이터를 업데이트하려고 할 때 각 요청에 대한 데이터 버전을 자동으로 생성할 수 있습니다. 버전 관리는 충돌 감지 및 해결 목적으로 다양한 데이터 변형을 유지 및 관리하는 데 사용됩니다. 또한 데이터 원본을 가져오고 스키마에서 여기에 액세스하는 데 필요한 CRUD, List, Query 작업의 일부를 생성하는 자동 스키마 생성을 활성화할 수도 있습니다.

      OpenSearch의 경우 리전을 선택한 다음 리전의 도메인(클러스터) 을 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 도메인과의 상호 작용 규칙을 지정할 수 있습니다.

      Lambda의 경우 리전을 선택한 다음 리전에서 Lambda 함수의 ARN을 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 Lambda 함수와의 상호 작용 규칙을 지정할 수 있습니다.

      HTTP의 경우 HTTP 엔드포인트를 입력해야 합니다.

      EventBridge의 경우 리전을 선택한 다음 리전에서 이벤트 버스를 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 이벤트 버스와의 상호 작용 규칙을 지정할 수 있습니다.

      RDS의 경우 리전을 선택한 다음 암호 저장소(사용자 이름 및 암호), 데이터베이스 이름, 스키마를 선택해야 합니다.

      없음의 경우 실제 데이터 원본이 없는 데이터 원본을 추가하게 됩니다. 이는 실제 데이터 원본을 통하지 않고 로컬에서 해석기를 처리하기 위함입니다.

      참고

      기존 역할을 가져오는 경우 신뢰 정책이 필요합니다. 자세한 내용은 IAM 신뢰 정책을 참조하세요.

  3. 생성(Create)을 선택합니다.

    참고

    또는 DynamoDB 데이터 원본을 생성하는 경우 콘솔의 스키마 페이지로 이동하여 페이지 상단에서 리소스 생성을 선택한 다음 사전 정의된 모델을 채워 테이블로 변환할 수 있습니다. 이 옵션에서는 기본 유형을 채우거나 가져오고, 파티션 키를 포함한 기본 테이블 데이터를 구성하고, 스키마 변경 사항을 검토합니다.

IAM 신뢰 정책

데이터 소스에 기존 IAM 역할을 사용하는 경우 Amazon DynamoDB 테이블과 같은 AWS 리소스에서 작업을 수행할 수 PutItem 있는 적절한 권한을 해당 역할에 부여해야 합니다. 또한 다음 예제 정책과 같이 해당 역할의 신뢰 정책을 수정하여 AWS AppSync가 리소스 액세스에 사용할 수 있도록 해야 합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Principal": {
            "Service": "appsync.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
        }
    ]
}

신뢰 정책에 조건을 추가하여 데이터 원본에 대한 액세스를 원하는 대로 제한할 수도 있습니다. 현재 SourceArn 및 SourceAccount 키를 이러한 조건에 사용할 수 있습니다. 예를 들어 다음 정책에서는 데이터 원본에 대한 액세스를 123456789012 계정으로 제한합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appsync.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        }
      }
    }
  ]
}

또는 다음 정책을 사용하여 데이터 원본에 대한 액세스를 특정 API(예: abcdefghijklmnopq)로 제한할 수 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appsync.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:appsync:us-west-2:123456789012:apis/abcdefghijklmnopq"
        }
      }
    }
  ]
}

다음 정책을 us-east-1사용하여와 같은 특정 리전의 모든 AWS AppSync APIs에 대한 액세스를 제한할 수 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appsync.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:appsync:us-east-1:123456789012:apis/*"
        }
      }
    }
  ]
}

다음 섹션(해석기 구성)에서는 해석기 비즈니스 로직을 추가하고 이를 스키마의 필드에 연결하여 데이터 원본의 데이터를 처리합니다.

역할 정책 구성에 대한 자세한 내용은 IAM 사용 설명서의 역할 변경을 참조하세요.

AWS AppSync용 AWS Lambda 해석기의 크로스 계정 액세스에 대한 자세한 내용은 AWS AppSync용 크로스 계정 AWS Lambda 해석기 구축을 참조하세요.

이 페이지에서

프라이버시사이트 이용 약관쿠키 기본 설정
© 2025, Amazon Web Services, Inc. 또는 계열사. All rights reserved.