[AWS SDK for JavaScript V3 API 참조 안내서](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/)는 AWS SDK for JavaScript 버전 3(V3)의 모든 API 작업을 자세히 설명합니다.

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

# SDK for JavaScript 구성
<a name="configuring-the-jssdk"></a>

API를 사용하여 웹 서비스를 간접적으로 호출하기 위해 SDK for JavaScript를 사용하기 전에 SDK를 구성해야 합니다. 최소한 다음을 구성해야 합니다.
+ 서비스를 요청할 AWS 리전
+ 를 사용하여 코드를 인증하는 방법 AWS

이러한 설정 외에도 AWS 리소스에 대한 권한도 구성해야 할 수 있습니다. 예를 들어 Amazon S3 버킷에 대한 액세스를 제한하거나 읽기 전용 액세스만 가능하도록 Amazon DynamoDB 테이블을 제한할 수 있습니다.

[AWS SDKs 및 도구 참조 가이드](https://docs.aws.amazon.com/sdkref/latest/guide/)에는 많은 AWS SDKs.

이 단원의 주제에서는 웹 브라우저에서 실행되는 JavaScript 및 Node.js에 대해 SDK for JavaScript를 구성하는 방법을 설명합니다.

**Topics**
+ [서비스별 구성](global-config-object.md)
+ [AWS 리전 설정](setting-region.md)
+ [자격 증명 설정](setting-credentials.md)
+ [Node.js 고려 사항](node-js-considerations.md)
+ [브라우저 스크립트 고려 사항](browser-js-considerations.md)

# 서비스별 구성
<a name="global-config-object"></a>

서비스 객체에 구성 정보를 전달하여 SDK를 구성할 수 있습니다.

서비스 수준 구성은 개별 서비스에 대한 중요한 제어를 제공하므로 요구 사항이 기본 구성과 다를 때 개별 서비스 객체의 구성을 업데이트할 수 있습니다.

**참고**  
버전 2.x에서는 AWS SDK for JavaScript 서비스 구성을 개별 클라이언트 생성자에게 전달할 수 있습니다. 그러나 이러한 구성은 먼저 글로벌 SDK 구성 `AWS.config`의 복사본에 자동으로 병합됩니다.  
또한 `AWS.config.update({/* params *})`를 직접적으로 호출하면 기존 클라이언트가 아니라 업데이트 호출이 이루어진 후 인스턴스화된 서비스 클라이언트에 대한 구성만 업데이트됩니다.  
이 동작은 빈번하게 혼란을 야기했으며, 이로 인해 순방향 호환 방식으로 서비스 클라이언트의 하위 집합에만 영향을 주는 구성을 글로벌 객체에 추가하기가 어려워졌습니다. 버전 3에서는 더 이상 SDK로 관리되는 글로벌 구성이 없습니다. 인스턴스화된 각 서비스 클라이언트에 구성을 전달해야 합니다. 여전히 ​​동일한 구성을 여러 클라이언트에서 공유할 수는 있지만, 해당 구성이 글로벌 상태와 자동으로 병합되지는 않습니다.

## 서비스별 구성 설정
<a name="service-specific-configuration"></a>

SDK for JavaScript에 사용하는 각 서비스에는 해당 서비스에 대한 API의 일부인 서비스 객체를 통해 액세스합니다. 예를 들어 Amazon S3 서비스에 액세스하려면 Amazon S3 서비스 객체를 생성합니다. 해당 서비스 객체에 대한 생성자의 일부인 서비스별 구성 설정을 지정할 수 있습니다.

예를 들어 여러 AWS 리전의 Amazon EC2 객체에 액세스해야 하는 경우 각 리전에 대해 Amazon EC2 서비스 객체를 생성한 다음 그에 따라 각 서비스 객체의 리전 구성을 설정합니다.

```
var ec2_regionA = new EC2({region: 'ap-southeast-2', maxAttempts: 15});
var ec2_regionB = new EC2({region: 'us-west-2', maxAttempts: 15});
```

# AWS 리전 설정
<a name="setting-region"></a>

 AWS 리전은 동일한 지리적 영역에 있는 명명된 AWS 리소스 집합입니다. 리전의 한 가지 예로 미국 동부(버지니아 북부) 리전인 `us-east-1`을 들 수 있습니다. SDK가 해당 리전의 서비스에 액세스할 수 있도록 SDK for JavaScript에서 서비스 클라이언트를 생성할 때 리전을 지정합니다. 일부 서비스는 특정 리전에서만 사용할 수 있습니다.

SDK for JavaScript는 기본적으로 리전을 선택하지 않습니다. 그러나 환경 변수 또는 공유 구성 `config` 파일을 사용하여 AWS 리전을 설정할 수 있습니다.

## 클라이언트 클래스 생성자에서
<a name="setting-region-constructor"></a>

서비스 객체를 인스턴스화할 때 다음과 같이 해당 리소스의 AWS 리전을 클라이언트 클래스 생성자의 일부로 지정할 수 있습니다.

```
const s3Client = new S3.S3Client({region: 'us-west-2'});
```

## 환경 변수 사용
<a name="setting-region-environment-variable"></a>

`AWS_REGION` 환경 변수를 사용하여 리전을 설정할 수 있습니다. 이 변수를 정의하면 SDK for JavaScript가 해당 변수를 읽고 사용합니다.

## 공유 구성 파일 사용
<a name="setting-region-config-file"></a>

공유 자격 증명 파일을 사용하면 SDK에서 사용할 자격 증명을 저장할 수 있는 것과 마찬가지로 AWS 리전 및 기타 구성 설정을 `config` SDK에서 사용할 공유 파일에 보관할 수 있습니다. `AWS_SDK_LOAD_CONFIG` 환경 변수가 진리 값(truthy value)으로 설정된 경우 SDK for JavaScript는 로드 시 `config` 파일을 자동으로 검색합니다. `config` 파일을 저장하는 위치는 운영 체제에 따라 다릅니다.
+ Linux, macOS 또는 Unix 사용자 – `~/.aws/config`
+ Windows 사용자 - `C:\Users\USER_NAME\.aws\config`

아직 공유 `config` 파일이 없는 경우, 지정된 디렉터리에 하나를 생성할 수 있습니다. 다음 예제의 경우 `config` 파일에서 리전과 출력 형식을 둘 다 설정합니다.

```
[default]
   region=us-west-2
   output=json
```

공유 `config` 및 `credentials` 파일 사용에 관한 자세한 내용은 *AWS SDK 및 도구 참조 가이드*의 [Shared config and credentials files](https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html) 단원을 참조하세요.

## 리전 설정을 위한 우선순위
<a name="setting-region-order-of-precedence"></a>

리전 설정의 우선순위는 다음과 같습니다.

1. 어떤 리전이 클라이언트 클래스 생성자로 전달된 경우 이 리전이 사용됩니다.

1. 환경 변수에 리전을 설정한 경우 이 리전이 사용됩니다.

1. 그렇지 않으면 공유 구성 파일에 정의된 리전이 사용됩니다.

# 자격 증명 설정
<a name="setting-credentials"></a>

AWS 는 자격 증명을 사용하여 서비스를 호출하는 사람과 요청된 리소스에 대한 액세스가 허용되는지 여부를 식별합니다.

웹 브라우저에서 실행되든 Node.js 서버에서 실행되든, JavaScript 코드가 API를 통해 서비스에 액세스하려면 먼저 유효한 인증 자격 증명을 얻어야 합니다. 보안 인증을 서비스 객체에 직접 전달함으로써 서비스별로 보안 인증을 설정할 수 있습니다.

웹 브라우저에서 Node.js와 JavaScript 간에 서로 다른 인증 자격 증명을 설정하는 방법에는 여러 가지가 있습니다. 이 섹션의 주제에서는 Node.js 또는 웹 브라우저에서 인증 자격 증명을 설정하는 방법을 설명합니다. 각각의 경우에 옵션은 권장 순서로 제공됩니다.

## 보안 인증에 대한 모범 사례
<a name="credentials-best-practices"></a>

인증 자격 증명을 올바르게 설정하면 애플리케이션 또는 브라우저 스크립트가 필요한 서비스 및 리소스에 액세스할 수 있는 동시에 미션 크리티컬 애플리케이션에 미치거나 중요한 데이터를 손상시킬 수 있는 보안 문제에 대한 노출을 최소화할 수 있습니다.

인증 자격 증명을 설정할 때 적용되는 중요한 원칙은 항상 작업에 필요한 최소 권한을 부여하는 것입니다. 최소 권한을 초과하는 권한을 제공하고 그 결과로 추후 발견할 수 있는 보안 문제를 해결하기 보다는, 리소스에 대한 최소 권한을 제공하고 필요에 따라 권한을 추가하는 것이 더 안전합니다. 예를 들어 Amazon S3 버킷 또는 DynamoDB 테이블의 객체 같은 개별 리소스를 읽고 쓸 필요가 있지 않은 한, 그러한 권한을 읽기 전용으로 설정합니다.

최소 권한 부여에 관한 자세한 내용은 *IAM 사용 설명서*의 모범 사례 주제에서 [최소 권한 적용](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 단원을 참조하세요.

**Topics**
+ [보안 인증에 대한 모범 사례](#credentials-best-practices)
+ [Node.js에서 자격 증명 설정](setting-credentials-node.md)
+ [웹 브라우저에서 보안 인증 설정](setting-credentials-browser.md)

# Node.js에서 자격 증명 설정
<a name="setting-credentials-node"></a>

로컬에서 개발 중이고 고용주로부터 설정 인증 방법을 받지 않은 신규 사용자에게 설정하는 것이 좋습니다 AWS IAM Identity Center. 자세한 내용은 [를 사용한 SDK 인증 AWS](getting-your-credentials.md) 단원을 참조하십시오.

Node.js에서 SDK에 인증 자격 증명을 제공하는 방법에는 여러 가지가 있습니다. 그 가운데는 더 안전한 방법도 있고 애플리케이션 개발 시에 더 편리한 방법도 있습니다. Node.js에서 보안 인증을 얻을 때 로드하는 JSON 파일, 환경 변수 등 둘 이상의 소스를 사용하는 경우 주의해야 합니다. 변경 발생에 대한 인식 없이 코드가 실행되는 권한을 변경할 수 있습니다.

AWS SDK for JavaScript V3는 Node.js에 기본 자격 증명 공급자 체인을 제공하므로 자격 증명 공급자를 명시적으로 제공할 필요가 없습니다. 기본 [보안 인증 공급자 체인](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain)은 보안 인증이 소스 중 하나에서 반환될 때까지 지정된 우선순위에 따라 여러 가지 다양한 소스의 보안 인증을 확인하려고 시도합니다. SDK for JavaScript V3의 보안 인증 공급자 체인은 [여기에서](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-aws-sdk-credential-providers/#fromnodeproviderchain) 찾을 수 있습니다.

## 보안 인증 공급자 체인
<a name="credchain"></a>

모든 SDK에는 AWS 서비스에 요청하는 데 사용할 유효한 보안 인증을 얻기 위해 확인하는 일련의 장소(또는 소스)가 있습니다. 유효한 보안 인증 정보를 찾은 후에는 검색이 중지됩니다. 이러한 체계적인 검색을 기본 보안 인증 공급자 체인이라고 합니다.

체인의 각 단계마다 값을 설정하는 다양한 방법이 있습니다. 코드에서 직접 값을 설정하는 것이 항상 우선하며, 환경 변수로를 설정한 다음 공유 AWS `config` 파일에서를 설정합니다. 자세한 내용은AWS SDK 및 도구 참조 안내서**의 [Precedence of settings](https://docs.aws.amazon.com/sdkref/latest/guide/settings-reference.html#precedenceOfSettings)를 참조하세요.

*AWS SDKs 및 도구 참조 가이드*에는 모든 AWS SDKs 및에서 사용하는 SDK 구성 설정에 대한 정보가 있습니다 AWS CLI. 공유 AWS `config` 파일을 통해 SDK를 구성하는 방법에 대한 자세한 내용은 [공유 구성 및 자격 증명 파일을](https://docs.aws.amazon.com/sdkref/latest/guide/file-format.html) 참조하세요. 환경 변수 설정을 통해 SDK를 구성하는 방법에 관해 자세히 알아보려면 [Environment variables support](https://docs.aws.amazon.com/sdkref/latest/guide/environment-variables.html) 단원을 참조하세요.

를 인증하기 위해 AWS는 다음 표에 나열된 순서대로 자격 증명 공급자를 AWS SDK for JavaScript 확인합니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v3/developer-guide/setting-credentials-node.html)

신규 사용자에게 권장되는 시작하기 접근 방식을 따랐다면 시작하기 항목의 [를 사용한 SDK 인증 AWS](getting-your-credentials.md) 중에 AWS IAM Identity Center 인증을 설정합니다. 상황에 따라 다른 인증 방법이 유용할 수 있습니다. 보안 위험을 방지하려면 항상 단기 보안 인증을 사용하는 것이 좋습니다. 다른 인증 방법 절차에 대해서는 *AWS SDK 및 도구 참조 가이드*의 [Authentication and access](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) 단원을 참조하세요.

이 섹션의 주제에서는 인증 자격 증명을 Node.js로 로드하는 방법을 설명합니다.

**Topics**
+ [보안 인증 공급자 체인](#credchain)
+ [Amazon EC2의 IAM 역할에서 Node.js의 자격 증명 로드](loading-node-credentials-iam.md)
+ [Node.js Lambda 함수의 자격 증명 로드](loading-node-credentials-lambda.md)

# Amazon EC2의 IAM 역할에서 Node.js의 자격 증명 로드
<a name="loading-node-credentials-iam"></a>

Amazon EC2 인스턴스에서 Node.js 애플리케이션을 실행하는 경우 Amazon EC2의 IAM 역할을 활용하여 해당 인스턴스에 보안 인증을 자동으로 제공할 수 있습니다. IAM 역할을 사용하도록 인스턴스를 구성하면 SDK가 애플리케이션의 IAM 보안 인증을 자동으로 선택하므로 보안 인증을 수동으로 제공할 필요가 없습니다.

Amazon EC2 인스턴스에 IAM 역할을 추가하는 방법에 관한 자세한 내용은 [Amazon EC2의 IAM 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) 단원을 참조하세요.

# Node.js Lambda 함수의 자격 증명 로드
<a name="loading-node-credentials-lambda"></a>

 AWS Lambda 함수를 생성할 때 함수를 실행할 권한이 있는 특수 IAM 역할을 생성해야 합니다. 이 역할을 *실행 역할*이라고 합니다. Lambda 함수를 설정할 때 해당 실행 역할로 생성한 IAM 역할을 지정해야 합니다.

실행 역할은 Lambda 함수에 다른 웹 서비스를 실행 및 간접 호출하는 데 필요한 보안 인증을 제공합니다. 따라서 Lambda 함수 내에 쓰는 Node.js 코드에 보안 인증을 제공할 필요가 없습니다.

Lambda 실행 역할 생성에 관한 자세한 내용은 *AWS Lambda 개발자 안내서*의 [Lambda 리소스 액세스 권한](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html#lambda-intro-execution-role) 단원을 참조하세요.

# 웹 브라우저에서 보안 인증 설정
<a name="setting-credentials-browser"></a>

브라우저 스크립트에서 SDK에 인증 자격 증명을 제공하는 방법에는 여러 가지가 있습니다. 그 가운데는 더 안전한 방법도 있고 스크립트 개발 시에 더 편리한 방법도 있습니다.

 다음은 권장 순서로 보안 인증을 제공할 수 있는 방법입니다.

1. Amazon Cognito 자격 증명을 사용하여 사용자를 인증하고 보안 인증 제공

1. 웹 연동 자격 증명 사용

**주의**  
스크립트에서 AWS 보안 인증을 하드 코딩하지 않는 것이 좋습니다. 인증 자격 증명을 하드 코딩하면 액세스 키 ID 및 보안 액세스 키가 노출될 위험이 있습니다.

**Topics**
+ [Amazon Cognito 자격 증명을 사용하여 사용자 인증](loading-browser-credentials-cognito.md)

# Amazon Cognito 자격 증명을 사용하여 사용자 인증
<a name="loading-browser-credentials-cognito"></a>

브라우저 스크립트에 대한 AWS 보안 인증을 얻는 권장 방법은 Amazon Cognito 자격 증명 보안 인증 클라이언트 `CognitoIdentityClient`를 사용하는 것입니다. Amazon Cognito를 사용하면 타사 자격 증명 공급자를 통해 사용자를 인증할 수 있습니다.

Amazon Cognito 자격 증명을 사용하려면 먼저, Amazon Cognito 콘솔에서 자격 증명 풀을 생성해야 합니다. 자격 증명 풀은 애플리케이션이 사용자에게 제공하는 자격 증명 그룹을 나타냅니다. 사용자에게 제공되는 자격 증명은 각 사용자 계정을 고유하게 식별합니다. Amazon Cognito 자격 증명(identity)은 자격 증명(credential)이 아닙니다. AWS Security Token Service(AWS STS)에서 웹 자격 증명 연동 지원을 사용하여 인증 자격 증명으로 교환됩니다.

Amazon Cognito에서는 여러 자격 증명 공급자의 자격 증명 추상화를 관리할 수 있습니다. 그러면 로드되는 자격 증명이 AWS STS의 인증 자격 증명과 교환됩니다.

## Amazon Cognito 자격 증명 보안 인증 객체 구성
<a name="browser-cognito-configuration"></a>

아직 자격 증명 풀을 생성하지 않은 경우 Amazon Cognito 클라이언트를 구성하기 전에 [Amazon Cognito 콘솔](https://console.aws.amazon.com/cognito)에서 브라우저 스크립트와 함께 사용할 자격 증명 풀을 생성합니다. 자격 증명 풀에 대한 인증 IAM 역할과 미인증 IAM 역할을 모두 생성하고 연결합니다. 자세한 내용은 *Amazon Cognito 개발자 안내서*의 [자습서: 자격 증명 풀 생성](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorial-create-identity-pool.html) 단원을 참조하세요.

미인증 사용자는 자격 증명이 인증되지 않았으므로 이 역할은 앱의 게스트 사용자에게 적합하거나 사용자의 자격 증명 인증 여부가 중요하지 않은 경우에 적합합니다. 인증받은 사용자는 자격 증명을 확인하는 타사 자격 증명 공급자를 통해 애플리케이션에 로그인합니다. 미인증 사용자의 액세스 권한을 허용하지 않도록 리소스 권한 범위를 충분히 정했는지 확인하세요.

자격 증명 풀을 구성한 후 `@aws-sdk/credential-providers`에서 `fromCognitoIdentityPool` 메서드를 사용하여 자격 증명 풀에서 보안 인증을 검색합니다. Amazon S3 클라이언트를 생성하는 다음 예에서는 *AWS\$1REGION*을 리전으로 바꾸고 *IDENTITY\$1POOL\$1ID*를 자격 증명 풀 ID로 바꿉니다.

```
// Import required AWS SDK clients and command for Node.js
import {S3Client} from "@aws-sdk/client-s3";
import {fromCognitoIdentityPool} from "@aws-sdk/credential-providers";

const REGION = AWS_REGION;

const s3Client = new S3Client({
  region: REGION,
  credentials: fromCognitoIdentityPool({
    clientConfig: { region: REGION }, // Configure the underlying CognitoIdentityClient.
    identityPoolId: 'IDENTITY_POOL_ID',
    logins: {
            // Optional tokens, used for authenticated login.
        },
  })
});
```

선택 사항인 `logins` 속성은 공급자의 자격 증명 토큰에 대한 자격 증명 공급자 이름의 맵입니다. 자격 증명 공급자에게서 토큰을 받는 방법은 어떤 공급자를 사용하느냐에 따라 다릅니다. 예를 들어 Amazon Cognito 사용자 풀을 인증 공급자로 사용하는 경우 아래와 비슷한 메서드를 사용할 수 있습니다.

```
// Get the Amazon Cognito ID token for the user. 'getToken()' below.
let idToken = getToken();
let COGNITO_ID = "COGNITO_ID"; // 'COGNITO_ID' has the format 'cognito-idp.REGION.amazonaws.com/COGNITO_USER_POOL_ID'
let loginData = {
  [COGNITO_ID]: idToken,
};
const s3Client = new S3Client({
    region: REGION,
    credentials: fromCognitoIdentityPool({
    clientConfig: { region: REGION }, // Configure the underlying CognitoIdentityClient.
    identityPoolId: 'IDENTITY_POOL_ID',
    logins: loginData
  })
});

// Strips the token ID from the URL after authentication.
window.getToken = function () {
  var idtoken = window.location.href;
  var idtoken1 = idtoken.split("=")[1];
  var idtoken2 = idtoken1.split("&")[0];
  var idtoken3 = idtoken2.split("&")[0];
  return idtoken3;
};
```

## 인증되지 않은 사용자를 인증된 사용자로 전환
<a name="browser-switching-unauthenticated-users"></a>

Amazon Cognito는 인증된 사용자와 인증되지 않은 사용자를 모두 지원합니다. 인증되지 않은 사용자는 자격 증명 공급자로 로그인하지 않았더라도 리소스에 대한 액세스 권한을 받습니다. 이 액세스 권한 등급은 로그인하기 전에 사용자에게 콘텐츠를 표시하는 데 유용합니다. 각 미인증 사용자는 개별적으로 로그인되지 않고 인증되지 않았더라도 Amazon Cognito에 고유한 자격 증명이 있습니다.

### 처음에 인증되지 않은 사용자
<a name="browser-initially-unauthenticated-user"></a>

사용자는 일반적으로 `logins` 속성 없이 구성 객체의 인증 자격 증명 속성을 설정한 인증되지 않은 역할로 시작합니다. 이 경우 기본 보안 인증은 다음과 같을 수 있습니다.

```
// Import the required AWS SDK for JavaScript v3 modules.                   
import {fromCognitoIdentityPool} from "@aws-sdk/credential-providers";
// Set the default credentials.
const creds = fromCognitoIdentityPool({
  identityPoolId: 'IDENTITY_POOL_ID',
  clientConfig: { region: REGION } // Configure the underlying CognitoIdentityClient.
});
```

### 인증된 사용자로 전환
<a name="switch-to-authenticated"></a>

인증되지 않은 사용자가 자격 증명 공급자에 로그인한 상태에서 현재 사용자가 토큰을 갖고 있다면, 보안 인증 객체를 업데이트하고 `logins` 토큰을 추가하는 사용자 지정 함수를 호출하여 인증되지 않은 사용자를 인증된 사용자로 전환할 수 있습니다.

```
// Called when an identity provider has a token for a logged in user
function userLoggedIn(providerName, token) {
  creds.params.Logins = creds.params.logins || {};
  creds.params.Logins[providerName] = token;
                    
  // Expire credentials to refresh them on the next request
  creds.expired = true;
}
```

# Node.js 고려 사항
<a name="node-js-considerations"></a>

Node.js 코드는 JavaScript이지만 Node.js AWS SDK for JavaScript 에서를 사용하는 것은 브라우저 스크립트에서 SDK를 사용하는 것과 다를 수 있습니다. 일부 API 메서드는 Node.js에서 작동하지만 브라우저 스크립트에서는 작동하지 않습니다. 마찬가지로 브라우저 스크립트에서는 작동하지만 Node.js에서 작동하지 않는 API 메서드도 있습니다. 또한 일부 API를 성공적으로 사용할 수 있는지는 `File System (fs)` 모듈 등의 여러 Node.js 모듈을 가져와 사용하는 것과 같은 일반적인 Node.js 코딩 패턴에 익숙한지 여부에 달려 있습니다.

**참고**  
AWS 에서는 개발을 위해 Node.js의 활성 LTS 버전을 사용할 것을 권장합니다.

## 기본 제공 Node.js 모듈 사용
<a name="node-common-modules"></a>

Node.js는 설치하지 않고도 사용할 수 있는 기본 제공 모듈 모음을 제공합니다. 이러한 모듈을 사용하려면 `require` 메서드로 객체를 생성하여 모듈 이름을 지정합니다. 예를 들어 기본 제공 HTTP 모듈을 포함시키려면 다음을 사용합니다.

```
import http from 'http';
```

모듈의 메서드가 해당 객체의 메서드인 것처럼 모듈의 메서드를 호출합니다. 예를 들어 다음은 HTML 파일을 읽는 코드입니다.

```
// include File System module
import fs from "fs"; 
// Invoke readFile method 
fs.readFile('index.html', function(err, data) {
  if (err) {
    throw err;
  } else {
    // Successful file read
  }
});
```

Node.js가 제공하는 모든 기본 제공 모듈의 전체 목록은 Node.js 웹 사이트의 [Node.js documentation](https://nodejs.org/api/modules.html)을 참조하세요.

## npm 패키지 사용
<a name="node-npm-packages"></a>

기본 제공 모듈 외에도 Node.js 패키지 관리자인 `npm`의 타사 코드를 포함 및 통합할 수 있습니다. 이는 오픈 소스 Node.js 패키지와 이러한 패키지를 설치하기 위한 명령줄 인터페이스의 리포지토리입니다. `npm`과 현재 사용 가능한 패키지 목록에 대한 자세한 내용은 [https://www.npmjs.com](https://www.npmjs.com)을 참조하세요. [GitHub](https://github.com/sindresorhus/awesome-nodejs)에서 사용할 수 있는 추가 Node.js 패키지에 대해 알아볼 수도 있습니다.

# Node.js에서 maxSockets 구성
<a name="node-configuring-maxsockets"></a>

Node.js에서 오리진당 최대 연결 수를 설정할 수 있습니다. ` maxSockets`이 설정된 경우, 하위 HTTP 클라이언트가 요청을 대기열에 넣고 소켓이 사용 가능해지면 소켓에 요청을 할당합니다.

그러면 지정된 오리진에 한 번에 동시 요청할 수 있는 수의 상한을 설정할 수 있습니다. 이 값을 낮추면 수신하는 조절 또는 시간 초과 오류 수를 줄일 수 있습니다. 그러나 소켓이 사용 가능해질 때까지 요청이 대기되므로 메모리 사용량도 증가할 수 있습니다.

다음 예는 DynamoDB 클라이언트에 대해 `maxSockets`를 설정하는 방법을 보여줍니다.

```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { NodeHttpHandler } from "@smithy/node-http-handler";
import https from "https";    
let agent = new https.Agent({
  maxSockets: 25
});

let dynamodbClient = new DynamoDBClient({
  requestHandler: new NodeHttpHandler({
    requestTimeout: 3_000,
    httpsAgent: agent
  });
});
```

값 또는 `Agent` 객체를 제공하지 않는 경우 SDK for JavaScript는 50의 `maxSockets` 값을 사용합니다. `Agent` 객체를 제공하면 해당 `maxSockets` 값이 사용됩니다. Node.js에서 `maxSockets` 설정에 대한 자세한 내용은 [Node.js 설명서](https://nodejs.org/dist/latest/docs/api/http.html#http_agent_maxsockets)를 참조하세요.

의 v3.521.0부터 다음 [간편 구문을 사용하여 ](https://github.com/aws/aws-sdk-js-v3/blob/main/supplemental-docs/CLIENTS.md#new-in-v35210)를 구성할 AWS SDK for JavaScript수 있습니다`requestHandler`.

```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";

const client = new DynamoDBClient({
  requestHandler: {
    requestTimeout: 3_000,
    httpsAgent: { maxSockets: 25 },
  },
});
```

# Node.js에서 연결 유지를 이용해 연결 재사용
<a name="node-reusing-connections"></a>

기본 Node.js HTTP/HTTPS 에이전트는 모든 새 요청에 대해 새로운 TCP 연결을 생성합니다. 새 연결 설정 비용을 방지하기 위해는 *기본적으로* TCP 연결을 AWS SDK for JavaScript 재사용합니다.

Amazon DynamoDB 쿼리와 같은 수명이 짧은 작업의 경우 TCP 연결 설정에 따른 지연 시간 오버헤드가 작업 자체보다 클 수 있습니다. 또한 저장 시 DynamoDB 암호화가와 통합되므로 데이터베이스에서 각 작업에 대해 새 AWS KMS 캐시 항목을 다시 설정해야 하는 지연 시간이 [AWS KMS](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.howitworks.html)발생할 수 있습니다. [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.howitworks.html](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.howitworks.html) 

TCP 연결을 재사용하지 않으려면, 다음 DynamoDB 클라이언트 예시에서와 같이 서비스별 클라이언트 기준으로 `keepAlive`를 사용하여 활성 상태의 연결 재사용을 비활성화할 수 있습니다.

```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { NodeHttpHandler } from "@smithy/node-http-handler";
import { Agent } from "https";

const dynamodbClient = new DynamoDBClient({
    requestHandler: new NodeHttpHandler({
        httpsAgent: new Agent({ keepAlive: false })
    })
});
```

`keepAlive`가 활성화된 경우 기본값이 1000ms인 `keepAliveMsecs`를 사용하여 TCP 연결 유지 패킷에 대한 초기 지연을 설정할 수도 있습니다. 자세한 내용은 [Node.js 설명서](https://nodejs.org/api/http.html#new-agentoptions)를 참조하세요.

# Node.js용 프록시 구성
<a name="node-configuring-proxies"></a>

인터넷에 직접 연결할 수 없는 경우 SDK for JavaScript는 타사 HTTP 에이전트를 통해 HTTP 또는 HTTPS 프록시 사용을 지원합니다.

타사 HTTP 에이전트를 찾으려면 [npm](https://www.npmjs.com/)에서 "HTTP proxy"를 검색하세요.

타사 HTTP 에이전트 프록시를 설치하려면 명령 프롬프트에 다음을 입력합니다. 여기서 *PROXY*는 `npm` 패키지의 이름입니다.

```
npm install PROXY --save
```

애플리케이션에서 프록시를 사용하려면 DynamoDB 클라이언트에 대한 다음 예와 같이 `httpAgent` 및 ` httpsAgent` 속성을 사용합니다.

```
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { NodeHttpHandler } from "@smithy/node-http-handler";
import { HttpsProxyAgent } from "hpagent";
const agent = new HttpsProxyAgent({ proxy: "http://internal.proxy.com" });
const dynamodbClient = new DynamoDBClient({
    requestHandler: new NodeHttpHandler({
        httpAgent: agent,
        httpsAgent: agent
    }),
});
```

**참고**  
`httpAgent`는 `httpsAgent`와 동일하지 않으며 클라이언트에서 대부분의 직접 호출이 `https`로 이루어지므로 둘 다 설정해야 합니다.

# Node.js에서 인증서 번들 등록
<a name="node-registering-certs"></a>

Node.js용 기본 트러스트 스토어에는 AWS 서비스에 액세스하는 데 필요한 인증서가 포함되어 있습니다. 일부 경우에는 특정 인증서 집합만 포함하는 것이 좋을 수도 있습니다.

이 예제에서는 지정된 인증서가 제공되지 않은 경우 디스크의 특정 인증서를 사용하여 연결을 거부하는 ` https.Agent`를 생성합니다. 새로 생성한 `https.Agent`는 DynamoDB 클라이언트에서 사용됩니다.

```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { NodeHttpHandler } from "@smithy/node-http-handler";
import { Agent } from "https";
import { readFileSync } from "fs";
const certs = [readFileSync("/path/to/cert.pem")];
const agent = new Agent({
  rejectUnauthorized: true,
  ca: certs
});
const dynamodbClient = new DynamoDBClient({
  requestHandler: new NodeHttpHandler({
    httpAgent: agent,
    httpsAgent: agent
  })
});
```

# 브라우저 스크립트 고려 사항
<a name="browser-js-considerations"></a>

다음 주제에서는 브라우저 스크립트 AWS SDK for JavaScript 에서를 사용하기 위한 특별한 고려 사항을 설명합니다.

**Topics**
+ [브라우저용 SDK 빌드](building-sdk-for-browsers.md)
+ [교차 오리진 리소스 공유(CORS)](cors.md)
+ [Webpack으로 애플리케이션 번들링](webpack.md)

# 브라우저용 SDK 빌드
<a name="building-sdk-for-browsers"></a>

SDK for JavaScript 버전 2(V2)와 달리 V3는 기본 서비스 집합에 대한 지원이 포함된 JavaScript 파일로 제공됩니다. 대신 V3를 사용하면 필요한 SDK for JavaScript 파일만 번들로 제공하고 브라우저에 포함할 수 있으므로 오버헤드가 줄어듭니다. Webpack을 사용하여 필수 SDK for JavaScript 파일과 필요한 추가 타사 패키지를 단일 `Javascript` 파일로 번들링하고 `<script>` 태그를 사용하여 브라우저 스크립트에 이 파일을 로드하는 것이 좋습니다. Webpack에 관한 자세한 내용은 [Webpack으로 애플리케이션 번들링](webpack.md) 단원을 참조하세요.

브라우저에서 CORS를 적용하는 환경 외부에서 SDK를 사용하며 SDK for JavaScript에서 제공하는 모든 서비스에 액세스하려는 경우 리포지토리를 복제하고 기본 호스팅 버전의 SDK를 빌드하는 동일한 빌드 도구를 실행하여 SDK의 사용자 지정 사본을 로컬에서 빌드할 수 있습니다. 다음 섹션에서는 추가 서비스 및 API 버전으로 SDK를 빌드하는 단계를 설명합니다.

## SDK 빌더를 사용하여 SDK for JavaScript 빌드
<a name="using-the-sdk-builder"></a>

**참고**  
Amazon Web Services 버전 3(V3)는 더 이상 브라우저 빌더를 지원하지 않습니다. 브라우저 애플리케이션의 대역폭 사용량을 최소화하려면 명명된 모듈을 가져와서 번들링하여 크기를 줄이는 것이 좋습니다. 번들링에 관한 자세한 내용은 [Webpack으로 애플리케이션 번들링](webpack.md) 단원을 참조하세요.

# 교차 오리진 리소스 공유(CORS)
<a name="cors"></a>

CORS(Cross-origin 리소스 공유)는 최신 웹 브라우저의 보안 기능입니다. 이 기능을 사용하면 웹 브라우저가 어떤 도메인이 외부 웹 사이트 또는 서비스를 요청할 수 있을지 협상할 수 있습니다.

대부분의 리소스 요청이 외부 도메인(예: 웹 서비스용 엔드포인트)으로 전송되기 때문에 AWS SDK for JavaScript를 사용해 브라우저 애플리케이션을 개발하는 경우 CORS는 중요한 고려 대상입니다. JavaScript 환경에서 CORS 보안을 적용하는 경우 이 서비스와 함께 CORS를 구성해야 합니다.

CORS는 다음을 기반으로 교차 오리진 요청 시 리소스 공유 허용 여부를 결정합니다.
+ 요청을 수행한 특정 도메인 
+ 수행 중인 HTTP 요청 유형(GET, PUT, POST, DELETE 등)

## CORS 작동 방식
<a name="how-cors-works"></a>

가장 간단한 경우 브라우저 스크립트는 다른 도메인 내 서버의 리소스에 대해 GET 요청을 수행합니다. 요청이 GET 요청을 제출하도록 승인된 도메인에서 전송된 경우 해당 서버의 CORS 구성에 따라 cross-origin 서버는 요청된 리소스를 반환하여 응답합니다.

요청하는 도메인 또는 HTTP 요청 유형이 승인되지 않은 경우에는 요청이 거부됩니다. 그러나 CORS는 요청을 실제로 제출하기 전에 요청을 사전에 보낼 수 있습니다. 이 경우 preflight 요청은 `OPTIONS` 액세스 요청 작업을 전송하는 방식으로 이루어집니다. cross-origin 서버의 CORS 구성이 요청하는 도메인에 대한 액세스 권한을 부여하는 경우 서버에서는 요청하는 도메인이 요청한 리소스에 대해 수행 가능한 HTTP 요청 유형을 모두 나열하는 preflight 응답으로 회신합니다.

![\[CORS 요청의 프로세스 흐름\]](http://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v3/developer-guide/images/cors-overview.png)


## CORS 구성이 필요합니까?
<a name="the-need-for-cors-configuration"></a>

Amazon S3 버킷에서 작업을 수행하려면 먼저 해당 버킷에 CORS 구성이 필요합니다. 일부 JavaScript 환경에서는 CORS가 적용되지 않을 수 있으므로 CORS를 구성할 필요가 없습니다. 예를 들어 Amazon S3 버킷에서 애플리케이션을 호스팅하고 `*.s3.amazonaws.com` 또는 일부 다른 특정 엔드포인트에서 리소스에 액세스하는 경우에는 요청이 외부 도메인에 액세스하지 않습니다. 따라서 이 구성에는 CORS가 필요하지 않습니다. 이 경우에도 CORS는 Amazon S3 이외의 서비스에는 여전히 사용됩니다.

## Amazon S3 버킷에 대한 CORS 구성
<a name="configuring-cors-s3-bucket"></a>

Amazon S3 콘솔에서 CORS를 사용하도록 Amazon S3 버킷을 구성할 수 있습니다.

AWS Web Services Management Console에서 CORS를 구성하는 경우 JSON을 사용하여 CORS 구성을 생성해야 합니다. 새로운 AWS Web Services Management Console은 JSON CORS 구성만 지원합니다.

**중요**  
새 AWS Web Services Management Console에서 CORS 구성은 JSON이어야 합니다.

1. AWS Web Services Management Console에서 Amazon S3 콘솔을 열고, 구성하려는 버킷을 찾아 해당 확인란을 선택합니다.

1. 열리는 창에서 **권한**을 선택합니다.

1. **권한** 탭에서 **CORS 구성**을 선택합니다.

1. **CORS 구성 편집기**에 CORS 구성을 입력한 다음, **저장**을 선택합니다.

CORS 구성은 `<CORSRule>` 내에 일련의 규칙이 포함된 XML 파일입니다. 구성에는 규칙이 최대 100개까지 있을 수 있습니다. 규칙은 다음 태그 중 하나로 정의합니다.
+ `<AllowedOrigin>` - 교차 도메인 요청을 수행하도록 허용하는 도메인 오리진을 지정합니다.
+ `<AllowedMethod>` - 교차 도메인 요청에서 허용하는 요청 유형(GET, PUT, POST, DELETE, HEAD)을 지정합니다.
+ `<AllowedHeader>` - preflight 요청에서 허용되는 헤더를 지정합니다.

구성의 예는 *Amazon Simple Storage Service 사용 설명서*의 [교차 오리진 리소스 공유(CORS) 사용](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html#how-do-i-enable-cors) 단원을 참조하세요.

## CORS 구성의 예
<a name="cors-configuration-example"></a>

다음 CORS 구성 예를 통해 사용자는 `example.org` 도메인에서 버킷 내부의 객체를 보거나 추가하거나 제거하거나 업데이트할 수 있습니다. 그러나 웹 사이트의 도메인으로 `<AllowedOrigin>` 범위를 지정하는 것이 좋습니다. 모든 도메인을 허용하려면 `"*"`를 지정할 수 있습니다.

**중요**  
새 S3 콘솔에서 CORS 구성은 JSON이어야 합니다.

------
#### [ XML ]

```
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <CORSRule>
    <AllowedOrigin>https://example.org</AllowedOrigin>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedMethod>DELETE</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
    <ExposeHeader>ETag</ExposeHeader>
    <ExposeHeader>x-amz-meta-custom-header</ExposeHeader>
  </CORSRule>
</CORSConfiguration>
```

------
#### [ JSON ]

```
[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "HEAD",
            "GET",
            "PUT",
            "POST",
            "DELETE"
        ],
        "AllowedOrigins": [
            "https://www.example.org"
        ],
        "ExposeHeaders": [
             "ETag",
             "x-amz-meta-custom-header"]
    }
]
```

------

이 구성은 사용자가 버킷에 대해 작업을 수행하도록 허용하지 않고, 브라우저의 보안 모델이 Amazon S3에 대한 요청을 허용하도록 합니다. 권한은 버킷 권한 또는 IAM 역할 권한을 통해 구성해야 합니다.

`ExposeHeader`를 사용하면 SDK가 Amazon S3에서 반환된 응답 헤더를 읽도록 할 수 있습니다. 예를 들어 `PUT` 또는 멀티파트 업로드에서 `ETag` 헤더를 읽으려면 이전 예와 같이 구성에 `ExposeHeader` 태그를 포함해야 합니다. SDK는 CORS 구성을 통해 노출된 헤더에만 액세스할 수 있습니다. 객체에 대해 메타데이터를 설정한 경우 값은 접두사 `x-amz-meta-`가 붙은 헤더(예: `x-amz-meta-my-custom-header`)로 반환되며 동일한 방식으로 노출되어야 합니다.

# Webpack으로 애플리케이션 번들링
<a name="webpack"></a>

브라우저 스크립트 또는 Node.js에서 웹 애플리케이션이 코드 모듈을 사용하면 종속성이 생성됩니다. 이러한 코드 모듈에는 자체 종속성이 있을 수 있어 애플리케이션 작동에 필요한 상호 연결된 모듈 모음이 생깁니다. 종속성을 관리하려면 `webpack`과 같은 모듈 번들러를 사용하면 됩니다.

`webpack` 모듈 번들러는 애플리케이션 코드를 구문 분석하여 `import` 또는 `require` 문을 검색해 애플리케이션에 필요한 모든 자산이 포함된 번들을 생성합니다. 이렇게 하면 웹 페이지를 통해 자산을 쉽게 제공할 수 있습니다. SDK for JavaScript는 출력 번들에 포함할 종속성 중 하나로 `webpack`에 포함될 수 있습니다.

`webpack`에 관한 자세한 내용은 GitHub의 [webpack module bundler](https://webpack.github.io/)를​ 참조하세요.

## Webpack 설치
<a name="webpack-installing"></a>

`webpack` 모듈 번들러를 설치하려면 먼저, Node.js 패키지 관리자인 npm이 설치되어 있어야 합니다. 다음 명령을 입력하여 `webpack` CLI 및 JavaScript 모듈을 설치합니다.

```
npm install --save-dev webpack
```

webpack과 함께 자동으로 설치되는 파일 및 디렉터리 경로 작업을 위해 `path` 모듈을 사용하려면 Node.js `path-browserify` 패키지를 설치해야 할 수도 있습니다.

```
npm install --save-dev path-browserify
```

## Webpack 구성
<a name="webpack-configuring"></a>

기본적으로 webpack은 프로젝트의 루트 디렉터리에서 `webpack.config.js`라는 JavaScript 파일을 검색합니다. 이 파일은 구성 옵션을 지정합니다. 다음은 WebPack 버전 5.0.0 이상에 대한 `webpack.config.js` 구성 파일의 예입니다.

**참고**  
Webpack 구성 요구 사항은 설치하는 Webpack 버전에 따라 다릅니다. 자세한 내용은 [Webpack documentation](https://webpack.js.org/configuration/)을 참조하세요.

```
// Import path for resolving file paths
var path = require("path");
module.exports = {
  // Specify the entry point for our app.
  entry: [path.join(__dirname, "browser.js")],
  // Specify the output file containing our bundled code.
  output: {
    path: __dirname,
    filename: 'bundle.js'
  },
   // Enable WebPack to use the 'path' package.
   resolve:{
  fallback: { path: require.resolve("path-browserify")}
  }
  /**
  * In Webpack version v2.0.0 and earlier, you must tell 
  * webpack how to use "json-loader" to load 'json' files.
  * To do this Enter 'npm --save-dev install json-loader' at the 
  * command line to install the "json-loader' package, and include the 
  * following entry in your webpack.config.js.
  * module: {
    rules: [{test: /\.json$/, use: use: "json-loader"}]
  }
  **/
};
```

이 예에서는 `browser.js`가 *진입점*으로 지정됩니다. 이 *진입점*은 `webpack`이 가져온 모듈 검색을 시작하는 데 사용하는 파일입니다. 출력의 파일 이름은 `bundle.js`로 지정합니다. 출력 파일에는 애플리케이션에서 실행해야 하는 JavaScript가 모두 포함되어 있습니다. 진입점에 지정된 코드가 SDK for JavaScript와 같은 다른 모듈을 가져오거나 필요로 하는 경우 해당 코드는 구성에서 이를 지정할 필요 없이 번들링됩니다.

## Webpack 실행
<a name="webpack-running"></a>

`webpack`을 사용하는 애플리케이션을 빌드하려면 `package.json` 파일의 `scripts` 객체에 다음을 추가합니다.

```
"build": "webpack"
```

다음은 `webpack` 추가를 보여주는 `package.json` 파일의 예입니다.

```
{
  "name": "aws-webpack",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "webpack"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@aws-sdk/client-iam": "^3.32.0",
    "@aws-sdk/client-s3": "^3.32.0"
  },
  "devDependencies": {
    "webpack": "^5.0.0"
  }
}
```

애플리케이션을 빌드하려면 다음 명령을 입력합니다.

```
npm run build
```

그러면 `webpack` 모듈 번들러가 프로젝트의 루트 디렉터리에 지정한 JavaScript 파일을 생성합니다.

## Webpack 번들 사용
<a name="webpack-using-bundle"></a>

브라우저 스크립트에서 번들을 사용하려면 다음 예와 같이 `<script>` 태그를 사용해 번들을 포함하면 됩니다.

```
<!DOCTYPE html>
<html>
    <head>
        <title>Amazon SDK with webpack</title>
    </head> 
    <body>
        <div id="list"></div>
        <script src="bundle.js"></script>
    </body>
</html>
```

## Node.js에 대한 번들링
<a name="webpack-nodejs-bundles"></a>

`webpack`을 사용하면 구성에서 `node`를 대상으로 지정하여 Node.js에서 실행되는 번들을 생성할 수 있습니다.

```
target: "node"
```

이는 디스크 공간이 제한된 환경에서 Node.js 애플리케이션을 실행하는 경우 유용합니다. 다음은 출력 대상으로 Node.js가 지정된 `webpack.config.js` 구성의 예입니다.

```
// Import path for resolving file paths
var path = require("path");
module.exports = {
  // Specify the entry point for our app.
  entry: [path.join(__dirname, "browser.js")],
  // Specify the output file containing our bundled code.
  output: {
    path: __dirname,
    filename: 'bundle.js'
  },
  // Let webpack know to generate a Node.js bundle.
  target: "node",
   // Enable WebPack to use the 'path' package.
   resolve:{
  fallback: { path: require.resolve("path-browserify")}
   /**
   * In Webpack version v2.0.0 and earlier, you must tell 
   * webpack how to use "json-loader" to load 'json' files.
   * To do this Enter 'npm --save-dev install json-loader' at the 
   * command line to install the "json-loader' package, and include the 
   * following entry in your webpack.config.js.
   module: {
    rules: [{test: /\.json$/, use: use: "json-loader"}]
  }
  **/
};
```