기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon S3 File Gateway 관리
이 섹션의 주제에서는 Amazon S3 File Gateway 리소스를 관리하는 방법에 대한 정보를 제공합니다. 게이트웨이 관리에는 게이트웨이에 파일 공유 및 Amazon S3 버킷에 액세스할 수 있는 권한 부여, 게이트웨이 및 파일 공유에 대한 정보 및 설정 편집, 파일 공유 삭제, 캐시된 객체 새로 고침, 게이트웨이 및 파일 공유에 대한 운영 상태 표시기 이해가 포함됩니다.
**주제**
+ [기본 게이트웨이 정보 편집](edit-gateway-information.md) - Storage Gateway 콘솔을 사용하여 게이트웨이 이름, 시간대, CloudWatch 로그 그룹 등 기존 게이트웨이의 기본 정보를 편집하는 방법에 대해 알아봅니다.
+ [액세스 및 권한 부여](add-file-share.md) - IAM 역할을 사용하여 게이트웨이에 Amazon S3 버킷 및 Amazon VPC 엔드포인트에 대한 액세스 권한을 제공하고, 특정 보안 문제를 방지하고, AWS 계정 간 버킷에 파일 공유를 연결하는 방법을 알아봅니다.
+ [파일 공유 삭제](remove-file-share.md) - Storage Gateway 콘솔을 사용하여 파일 공유를 삭제하는 방법에 대해 알아봅니다.
+ [게이트웨이 SMB 설정 편집](edit-smb-access-settings.md) - 게이트웨이의 SMB 파일 공유에 대한 보안 전략, Active Directory 인증, 게스트 액세스, 로컬 그룹 권한 및 파일 공유 가시성을 제어하는 게이트웨이 수준 SMB 설정을 편집하는 방법을 알아봅니다.
+ [SMB 파일 공유 설정 편집](edit-smbfileshare-settings.md) - 설정을 편집하여 SMB 파일 공유의 이름, 로깅, 캐시 새로 고침, 스토리지 클래스, 파일 내보내기 등을 구성하는 방법을 알아봅니다.
+ [SMB 파일 공유 액세스 제한](edit-file-share-access-smb.md) - 허용되거나 거부된 사용자 또는 그룹을 추가하여 SMB 파일 공유에 대한 액세스를 제한하는 방법을 알아봅니다.
+ [NFS 파일 공유 설정 편집](edit-storage-class.md) - 설정을 편집하여 NFS 파일 공유의 이름, 로깅, 캐시 새로 고침, 스토리지 클래스, 파일 내보내기 등을 구성하는 방법을 알아봅니다.
+ [NFS 파일 공유 메타데이터 기본값 편집](edit-metadata-defaults.md) - NFS 파일 공유의 파일 및 폴더에 대한 Unix 권한을 포함하는 기본 메타데이터 값을 편집하는 방법을 알아봅니다.
+ [NFS 파일 공유 액세스 제한](edit-nfs-client.md) - NFS 파일 공유의 특정 IP 주소 또는 IP 범위에서 클라이언트에 대한 액세스를 제한하는 방법을 알아봅니다.
+ [Amazon S3 버킷 객체 새로 고침](refresh-cache.md) - 파일 공유의 S3 버킷 객체 캐시를 새로 고치고 캐시를 자동으로 새로 고치도록 일정을 구성하는 방법을 알아봅니다.
+ [S3 Object Lock 사용](s3-object-lock.md) - Amazon S3 File Gateway가 S3 Object Lock 기능과 작동하는 방식에 대해 알아봅니다.
+ [파일 공유 상태](understand-file-share.md) - 파일 공유 상태를 보고 해석하는 방법을 알아봅니다.
+ [게이트웨이 상태](understand-gateway-status.md) - 게이트웨이 상태를 보고 해석하는 방법을 알아봅니다.
+ [Amazon S3 File Gateway의 대역폭 관리](MaintenanceUpdateBandwidth-common.md) - 게이트웨이에서 사용하는 네트워크 대역폭의 양을 제어하기 AWS 위해 게이트웨이의 업로드 처리량을 로 제한하는 방법을 알아봅니다.
# S3 File Gateway의 기본 정보 편집
Storage Gateway 콘솔을 사용하여 게이트웨이 이름, 시간대, CloudWatch 로그 그룹 등 기존 게이트웨이의 기본 정보를 편집할 수 있습니다.
**기존 게이트웨이의 기본 정보를 편집하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **게이트웨이**를 선택한 다음 기본 정보를 편집할 게이트웨이를 선택합니다.
1. **작업** 드롭다운 메뉴에서 **게이트웨이 정보 편집**을 선택합니다.
1. **게이트웨이 이름**에 게이트웨이 이름을 입력합니다. 이 이름으로 검색하면 Storage Gateway 콘솔의 목록 페이지에서 게이트웨이를 찾을 수 있습니다.
**참고**
게이트웨이 이름은 2\$1255자여야 하며 슬래시(`\` 또는 `/`)를 포함할 수 없습니다.
게이트웨이 이름을 변경하면 게이트웨이 모니터링을 위해 설정된 모든 CloudWatch 경보의 연결이 끊어집니다. 경보를 다시 연결하려면 CloudWatch 콘솔에서 각 경보의 **GatewayName**을 업데이트합니다.
1. **게이트웨이 표준 시간대**에서 게이트웨이를 배포하려는 전 세계 지역의 현지 시간대를 선택합니다.
1. **로그 그룹 설정 방법 선택**에서 게이트웨이의 상태를 모니터링하기 위해 Amazon CloudWatch Logs를 설정하는 방법을 선택합니다. 다음 옵션 중에서 선택할 수 있습니다.
+ **새 로그 그룹 생성** - 게이트웨이를 모니터링할 새 로그 그룹을 설정합니다.
+ **기존 로그 그룹 사용** - 해당 드롭다운 목록에서 기존 로그 그룹을 선택합니다.
+ **로깅 비활성화** - 게이트웨이를 모니터링하는 데 Amazon CloudWatch Logs를 사용하지 않습니다.
1. 변경하려는 설정 수정을 마쳤으면 **변경 사항 저장**을 선택합니다.
# 파일 공유 및 버킷에 대한 액세스 및 권한 부여
S3 File Gateway가 활성화되고 실행된 후 추가 파일 공유를 추가하고 게이트웨이 및 파일 공유 AWS 계정 와 다른의 버킷을 포함하여 Amazon S3 버킷에 대한 액세스 권한을 부여할 수 있습니다. 다음 섹션에서는 IAM 역할을 사용하여 게이트웨이에 Amazon S3 버킷 및 VPC 엔드포인트에 대한 액세스 권한을 제공하고, 특정 보안 문제를 방지하고, AWS 계정의 버킷에 파일 공유를 연결하는 방법을 설명합니다.
파일 공유를 새로 생성하는 방법에 대한 자세한 내용은 [파일 공유 생성](GettingStartedCreateFileShare.md) 섹션을 참조하세요.
이 섹션에는 파일 공유 및 Amazon S3 버킷에 대한 액세스 및 권한을 부여하는 방법에 대한 추가 정보를 제공하는 다음 주제가 포함되어 있습니다.
**주제**
+ [Amazon S3 버킷에 액세스할 수 있는 권한 부여](grant-access-s3.md) - File Gateway에 Amazon S3 버킷에 파일을 업로드하고 버킷에 연결하는 데 사용하는 모든 액세스 포인트 또는 Amazon Virtual Private Cloud(Amazon VPC) 엔드포인트에서 작업을 수행할 수 있는 액세스 권한을 부여하는 방법을 알아봅니다.
+ [교차 서비스 혼동된 대리인 방지](cross-service-confused-deputy-prevention.md) - 작업을 수행할 권한이 없는 엔터티가 권한이 더 많은 엔터티에게 작업을 수행하도록 강요하는 일반적인 보안 문제를 방지하는 방법을 알아보세요.
+ [교차 계정 액세스에서 파일 공유 사용](cross-account-access.md) - Amazon Web Services 계정 및 해당 계정의 사용자에게 다른 Amazon Web Services 계정에 속한 리소스에 액세스할 수 있는 액세스 권한을 부여하는 방법을 알아봅니다.
# Amazon S3 버킷에 액세스할 수 있는 권한 부여
파일 공유를 생성할 때 File Gateway는 Amazon S3 버킷에 파일을 업로드하고 버킷에 연결하는 데 사용하는 액세스 포인트 또는 가상 프라이빗 클라우드(VPC) 엔드포인트에서 작업을 수행할 수 있는 액세스 권한이 필요합니다. 이 액세스 권한을 부여하기 위해 File Gateway는이 액세스 권한을 부여하는 IAM 정책과 연결된 AWS Identity and Access Management (IAM) 역할을 수임합니다.
이 역할에는 IAM 정책과 이 정책에 대한 보안 토큰 서비스 신뢰(STS) 관계가 필요합니다. 이 정책에 따라 역할이 실행할 수 있는 작업이 결정됩니다. 또한 S3 버킷 및 연결된 액세스 포인트 또는 VPC 엔드포인트에는 IAM 역할이 액세스할 수 있도록 허용하는 액세스 정책이 있어야 합니다.
역할 및 액세스 정책을 직접 생성하거나 File Gateway에서 대신 생성할 수 있습니다. File Gateway에서 이러한 정책을 대신 생성한 경우 해당 정책에는 S3 작업 목록이 포함됩니다. 역할 및 권한에 대한 자세한 내용은 *IAM 사용 설명서*의 [역할을 만들어 AWS 서비스에 권한 위임](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)을 참조하세요.
다음 예는 File Gateway가 IAM 역할을 수임하도록 허용하는 신뢰 정책입니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "storagegateway.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
**중요**
Storage Gateway는 `iam:PassRole` 정책 작업을 사용하여 전달된 기존 서비스 역할을 수임할 수 있지만 `iam:PassedToService` 컨텍스트 키를 사용하여 작업을 특정 서비스로 제한하는 IAM 정책은 지원하지 않습니다.
자세한 내용은AWS Identity and Access Management 사용 설명서**에서 다음 주제를 참조하세요.
[IAM: 특정 AWS 서비스에 IAM 역할 전달](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html)
[사용자에게 AWS 서비스에 역할을 전달할 수 있는 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)
[IAM에 사용 가능한 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_PassedToService)
File Gateway에서 사용자 대신 정책을 생성하도록 하지 않으려는 경우 정책을 직접 생성하여 파일 공유에 연결합니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 [파일 공유 생성](GettingStartedCreateFileShare.md) 섹션을 참조하세요.
다음 예제 정책은 File Gateway에서 정책에 나열된 모든 Amazon S3 작업을 수행하도록 허용합니다. 설명문의 첫 번째 부분은 S3 버킷 `amzn-s3-demo-bucket`에 대해 나열된 모든 작업을 수행하도록 허용합니다. 두 번째 부분은 `amzn-s3-demo-bucket`의 모든 객체에 대해 나열된 작업을 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"s3:GetAccelerateConfiguration",
"s3:GetBucketLocation",
"s3:GetBucketVersioning",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:ListBucketMultipartUploads"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Effect": "Allow"
},
{
"Action": [
"s3:AbortMultipartUpload",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:GetObjectVersion",
"s3:ListMultipartUploadParts",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Effect": "Allow"
}
]
}
```
------
다음 예제 정책은 이전 정책과 유사하지만 File Gateway가 액세스 포인트를 통해 버킷에 액세스하는 데 필요한 작업을 수행하도록 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"s3:AbortMultipartUpload",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:GetObjectVersion",
"s3:ListMultipartUploadParts",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:us-east-1:111122223333:accesspoint/TestAccessPointName/*",
"Effect": "Allow"
}
]
}
```
------
**참고**
VPC 엔드포인트를 통해 파일 공유를 S3 버킷에 연결해야 하는 경우 *AWS PrivateLink 사용 설명서*의 [Amazon S3에 대한 엔드포인트 정책](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#vpc-endpoints-policies-s3)을 참조하세요.
**참고**
암호화된 버킷의 경우 파일 공유는 대상 S3 버킷 계정의 키를 사용해야 합니다.
**참고**
File Gateway가 암호화에 SSE-KMS 또는 DSSE-KMS를 사용하는 경우 파일 공유와 연결된 IAM 역할에 *kms:Encrypt*, *kms:Decrypt*, *kms:ReEncrypt\$1*, *kms:GenerateDataKey* 및 *kms:DescribeKey* 권한이 포함되어 있는지 확인합니다. 자세한 내용은 [Storage Gateway에 대한 자격 증명 기반 정책(IAM 정책) 사용](https://docs.aws.amazon.com/filegateway/latest/files3/using-identity-based-policies.html)을 참조하세요.
# 교차 서비스 혼동된 대리인 방지
혼동된 대리자 문제는 작업을 수행할 권한이 없는 엔터티가 권한이 더 많은 엔터티에게 작업을 수행하도록 강요할 수 있는 보안 문제입니다. 에서 AWS교차 서비스 가장은 혼동된 대리자 문제를 초래할 수 있습니다. 교차 서비스 가장은 한 서비스(*직접 호출하는 서비스*)가 다른 서비스(*직접 호출되는 서비스*)를 직접 호출할 때 발생할 수 있습니다. 직접 호출하는 서비스는 다른 고객의 리소스에 대해 액세스 권한이 없는 방식으로 작동하게 권한을 사용하도록 조작될 수 있습니다. 이를 방지하기 위해 AWS 에서는 계정의 리소스에 대한 액세스 권한이 부여된 서비스 위탁자를 사용하여 모든 서비스에 대한 데이터를 보호하는 데 도움이 되는 도구를 제공합니다.
리소스 정책에서 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) 및 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) 전역 조건 컨텍스트 키를 사용하여 리소스에 다른 서비스를 AWS Storage Gateway 제공하는 권한을 제한하는 것이 좋습니다. 두 전역 조건 컨텍스트 키를 모두 사용하는 경우 `aws:SourceAccount` 값과 `aws:SourceArn` 값의 계정은 동일한 정책 문에서 사용할 경우 동일한 계정 ID를 사용해야 합니다.
`aws:SourceArn`의 값은 파일 공유가 연결된 Storage Gateway의 ARN이어야 합니다.
혼동된 대리인 문제로부터 보호하는 가장 효과적인 방법은 리소스의 전체 ARN이 포함된 `aws:SourceArn`글로벌 조건 컨텍스트 키를 사용하는 것입니다. 리소스의 전체 ARN을 모를 경우 또는 여러 리소스를 지정하는 경우, ARN의 알 수 없는 부분에 대해 와일드카드(`*`)를 포함한 `aws:SourceArn`전역 조건 컨텍스트 키를 사용합니다. 예제: `arn:aws:servicename::123456789012:*`.
다음 예는 Storage Gateway에서 `aws:SourceArn` 및 `aws:SourceAccount` 전역 조건 컨텍스트 키를 사용하여 혼동된 대리자 문제를 방지하는 방법을 보여줍니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ConfusedDeputyPreventionExamplePolicy",
"Effect": "Allow",
"Principal": {
"Service": "storagegateway.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "444455556666"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:storagegateway:us-east-1:444455556666:gateway/sgw-123456DA"
}
}
}
]
}
```
------
# 교차 계정 액세스에서 파일 공유 사용
*교차 계정* 액세스란 Amazon Web Services 계정과 해당 계정의 사용자에게 다른 Amazon Web Services 계정에 속한 리소스에 대한 액세스 권한이 부여되는 경우를 말합니다. File Gateway에서 한 Amazon Web Services 계정의 파일 공유를 사용하여 다른 Amazon Web Services 계정에 속한 Amazon S3 버킷의 객체에 액세스할 수 있습니다.
**한 Amazon Web Services 계정이 소유한 파일 공유를 사용하여 다른 Amazon Web Services 계정의 S3 버킷에 액세스하려면**
1. S3 버킷 소유자가 액세스해야 하는 S3 버킷 및 해당 버킷의 객체에 대한 액세스 권한을 Amazon Web Services 계정에 부여해야 합니다. 이 액세스 권한을 부여하는 방법에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*에서 [예제 2: 버킷 소유자가 교차 계정 버킷 권한 부여](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html)를 참조하세요. 필요한 권한 목록은 [Amazon S3 버킷에 액세스할 수 있는 권한 부여](grant-access-s3.md) 섹션을 참조하세요.
1. 파일 공유에서 S3 버킷에 액세스하기 위해 사용하는 IAM 역할에 `s3:GetObjectAcl` 및 `s3:PutObjectAcl` 등과 같은 작업에 대한 권한이 포함되어 있어야 합니다. 또한 IAM 역할에 계정이 해당 IAM 역할을 할 수 있도록 허용하는 신뢰 정책이 포함되어 있어야 합니다. 이러한 신뢰 정책의 예제는 [Amazon S3 버킷에 액세스할 수 있는 권한 부여](grant-access-s3.md) 섹션을 참조하세요.
파일 공유가 S3 버킷에 액세스하기 위해 기존 역할을 사용하는 경우에는 반드시 `s3:GetObjectAc` 및 `s3:PutObjectAcl` 작업에 대한 권한이 포함되어 있어야 합니다. 또한 계정이 이 역할을 수임할 수 있도록 허용하는 신뢰 정책이 필요합니다. 이러한 신뢰 정책의 예제는 [Amazon S3 버킷에 액세스할 수 있는 권한 부여](grant-access-s3.md) 섹션을 참조하세요.
1. [https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/)에서 파일 공유를 생성하거나 파일 공유 설정을 편집할 때 **S3 버킷 소유자가 액세스할 수 있는 게이트웨이 파일**을 선택합니다.
교차 계정 액세스를 위해 파일 공유를 생성 또는 업데이트하고 온프레미스에서 파일 공유를 탑재한 경우 설정을 테스트하는 것이 가장 좋습니다. 이를 위해 디렉터리 콘텐츠를 나열하거나 테스트 파일을 작성하고 파일이 S3 버킷에 객체로 표시되는지 확인할 수 있습니다.
**중요**
파일 공유에서 사용하는 계정에 교차 계정 액세스 권한을 부여할 수 있도록 정책이 올바르게 설정되어 있는지 확인합니다. 올바르게 선택되어 있지 않는 경우 온프레미스 애플리케이션을 통한 파일 업데이트 내용이 작업 중인 Amazon S3 버킷에 전파되지 않습니다.
## 리소스
액세스 정책 및 액세스 제어 목록에 대한 자세한 내용은 다음 항목을 참조하세요.
*Amazon Simple Storage Service 사용 설명서*의 [사용 가능한 액세스 정책 옵션 사용 지침](https://docs.aws.amazon.com/AmazonS3/latest/dev/access-policy-alternatives-guidelines.html)
**Amazon Simple Storage Service 사용 설명서의 [액세스 제어 목록(ACL) 개요](https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html)
# 파일 공유 삭제
파일 공유가 필요 없으면 Storage Gateway 콘솔에서 삭제할 수 있습니다. 파일 공유를 삭제하면 파일 공유가 매핑되는 Amazon S3 버킷에서 게이트웨이가 연결 해제됩니다. 그러나 S3 버킷과 그 콘텐츠는 삭제되지 않습니다.
게이트웨이가 S3 버킷으로 데이터를 업로드하는 도중 파일 공유를 삭제할 경우 삭제 프로세스는 모든 데이터가 업로드된 이후에 완료됩니다. 파일 공유는 데이터가 완전히 업로드될 때까지 DELETING 상태를 유지합니다.
데이터가 완전히 업로드될 때까지 기다리지 않으려는 경우 이 주제의 뒷부분에 나오는 **파일 공유를 강제로 삭제하려면** 절차를 참조하세요.
**파일 공유를 삭제하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **파일 공유**를 선택한 다음 삭제할 파일 공유를 하나 이상 선택합니다.
1. **작업**에서 **파일 공유 삭제**를 선택합니다. 확인 대화 상자가 표시됩니다.
1. 지정된 파일 공유를 삭제할 것인지 확인한 다음 확인 상자에 *delete*라는 단어를 입력하고 **삭제**를 선택합니다.
경우에 따라 파일 공유를 삭제하기 전에 네트워크 파일 시스템(NFS) 파일 공유에 있는 파일에 쓴 모든 데이터를 업로드할 때까지 기다리지 않을 수도 있습니다. 예를 들어, 아직 업로드되지 않은 데이터를 의도적으로 삭제하거나, 파일 공유를 지원하는 Amazon S3 버킷이 이미 삭제되어 지정된 데이터를 더 이상 업로드할 수 없는 경우가 있습니다.
이러한 경우 AWS Management Console 또는 `DeleteFileShare` API 작업을 사용하여 파일 공유를 강제로 삭제할 수 있습니다. 이 작업을 실행하면 데이터 업로드 프로세스가 중지됩니다. 파일 공유는 FORCE\$1DELETING 상태로 바뀝니다. Storage Gateway 콘솔에서 파일 공유를 강제로 삭제하려면 다음 절차를 참조하세요.
**파일 공유를 강제로 삭제하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **파일 공유** 목록 페이지에서 위 절차에서 삭제 플래그를 지정한 파일 공유를 선택하여 세부 정보를 확인합니다. 몇 초 후 **세부 정보** 탭에 삭제 알림 메시지가 나타납니다.
1. **세부 정보** 탭에 표시되는 메시지에서 강제로 삭제할 파일 공유의 ID를 확인하고 확인란을 선택한 후 **지금 강제 삭제**를 선택합니다.
**참고**
강제 삭제 작업은 실행 취소할 수 없습니다.
파일 공유를 강제로 삭제하면 다중 파트 업로드에서 부분적으로 전송된 파일이 Amazon S3에 남아 스토리지 요금이 발생할 수 있습니다. 이러한 파일 부분을 자동으로 삭제하도록 Amazon S3 버킷 수명 주기 규칙을 구성하는 것이 좋습니다. 자세한 내용은 [모범 사례: 멀티파트 업로드 관리](https://docs.aws.amazon.com/filegateway/latest/files3/best-practices-managing-multi-part-uploads.html)를 참조하세요.
[DeleteFileShare](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_DeleteFileShare.html) API 작업을 사용하여 파일 공유를 강제로 삭제할 수도 있습니다. API를 사용하여 파일 공유를 삭제하려면 `storagegateway:DeleteFileShare` IAM 정책 권한이 필요합니다.
# 게이트웨이에 대한 SMB 설정 편집
게이트웨이 수준 SMB 설정을 사용하면 게이트웨이의 SMB 파일 공유에 대한 보안 전략, Active Directory 인증, 게스트 액세스, 로컬 그룹 권한 및 파일 공유 가시성을 구성할 수 있습니다.
**게이트웨이 수준 SMB 설정을 편집하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **게이트웨이**를 선택한 다음 SMB 설정을 편집할 게이트웨이를 선택합니다.
1. **작업** 드롭다운 메뉴에서 **SMB 설정 편집**을 선택한 다음 편집할 설정을 선택합니다.
이 섹션에는 게이트웨이의 각 개별 SMB 설정 구성과 관련된 추가 정보와 절차를 제공하는 다음 주제가 포함되어 있습니다.
**주제**
+ [게이트웨이 보안 수준 설정](security-strategy.md) - SMB(Server Message Block) 서명 및 암호화와 같은 연결 요구 사항을 지정하도록 보안 수준을 설정하는 방법과 SMB 버전 1 클라이언트로부터의 연결을 허용할지 여부를 알아봅니다.
+ [Active Directory 인증 구성](enable-ad-settings.md) - SMB 파일 공유에 대한 사용자 인증 액세스를 위해 회사 Active Directory 또는 AWS 관리형 Microsoft AD를 구성하는 방법을 알아봅니다.
+ [게스트 액세스 권한 제공](guest-access.md) - 올바른 게스트 계정 사용자 이름과 암호를 제공하는 모든 사용자의 게스트 액세스를 허용하도록 게이트웨이를 구성하는 방법을 알아봅니다.
+ [로컬 그룹 구성](local-group-settings.md) - Active Directory 사용자에게 특수 파일 공유 권한을 부여하도록 로컬 그룹을 구성하는 방법을 알아봅니다.
+ [파일 공유 표시 여부 설정](file-share-visibility.md) - 사용자에게 공유를 나열할 때 게이트웨이의 공유가 표시되는지 여부를 지정하는 방법을 알아봅니다.
# 게이트웨이의 보안 수준 설정
S3 File Gateway를 사용하여 게이트웨이의 보안 수준을 지정할 수 있습니다. 이러한 보안 수준을 지정하면 게이트웨이에서 SMB(Server Message Block) 서명 또는 SMB 암호화가 필요한지 여부와 SMB 버전 1을 활성화하고 싶은지 여부를 설정할 수 있습니다.
**보안 수준을 구성하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **게이트웨이**를 선택한 다음 SMB 설정을 편집할 게이트웨이를 선택합니다.
1. **작업** 드롭다운 메뉴에서 **SMB 설정 편집**을 선택한 다음 **SMB 보안 설정**을 선택합니다.
1. **Security level(보안 수준)**에서 다음 중 하나를 선택합니다.
**참고**
AWS API를 사용하여이 설정을 구성하는 방법에 대한 자세한 내용은 API 참조의 [UpdateSMBSecurityStrategy](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_UpdateSMBSecurityStrategy.html)를 *AWS Storage Gateway 참조*하세요.
보안 수준이 높아지면 게이트웨이 성능에 영향을 미칠 수 있습니다.
+ **AES256 암호화 적용** - 이 옵션을 선택하면 S3 File Gateway는 256비트 AES 암호화 알고리즘을 사용하는 SMBv3 클라이언트로부터의 연결만 허용합니다. 128비트 알고리즘은 허용되지 않습니다. 이 옵션은 민감한 데이터를 처리하는 환경에서 사용하는 것이 좋습니다. Microsoft Windows의 모든 현재 SMB 클라이언트에서 작동합니다.
+ **암호화 적용** - 이 옵션을 선택하면 S3 File Gateway에서 암호화가 켜진 SMBv3 클라이언트의 연결만 허용합니다. 256비트 알고리즘과 128비트 알고리즘이 모두 허용됩니다. 이 옵션은 민감한 데이터를 처리하는 환경에서 사용하는 것이 좋습니다. Microsoft Windows의 모든 현재 SMB 클라이언트에서 작동합니다.
+ **서명 적용** – 이 옵션을 선택하면 S3 File Gateway가 서명이 활성화된 SMBv2 또는 SMBv3 클라이언트에서의 연결만 허용합니다. 이 옵션은 Microsoft Windows의 모든 현재 SMB 클라이언트에서 작동합니다.
+ **클라이언트 협상** – 이 옵션을 선택하면 클라이언트가 협상한 내용에 따라 요청이 설정됩니다. 환경의 서로 다른 클라이언트에서 호환성을 극대화하고 싶을 때 이 옵션을 사용할 것을 권장합니다.
**참고**
2019년 6월 20일 전에 활성화된 게이트웨이의 경우, 기본 보안 수준이 **Client negotiated(클라이언트 협상)**입니다.
2019년 6월 20일자로 활성화된 게이트웨이의 경우, 기본 보안 수준이 **Enforce encryption(암호화 적용)**입니다.
1. **저장**을 선택합니다.
# Active Directory를 사용하여 사용자 인증
회사 Active Directory를 사용하거나 SMB 파일 공유 AWS Managed Microsoft AD 에 대한 사용자 인증 액세스를 위해 Microsoft AD 도메인 자격 증명으로 게이트웨이의 SMB 설정을 편집합니다. 이렇게 하면 게이트웨이가 Active Directory 도메인에 조인하고 도메인의 멤버들이 SMB 파일 공유에 액세스할 수 있습니다.
**참고**
를 사용하여에서 호스팅 Active Directory 도메인 서비스를 생성할 Directory Service수 있습니다 AWS 클라우드.
Amazon EC2 게이트웨이와 AWS Managed Microsoft AD 함께를 사용하려면와 동일한 VPC에서 Amazon EC2 인스턴스를 생성하고 AWS Managed Microsoft AD, Amazon EC2 인스턴스에 \$1workspaceMembers 보안 그룹을 추가하고,의 관리자 자격 증명을 사용하여 AD 도메인에 가입해야 합니다 AWS Managed Microsoft AD.
에 대한 자세한 내용은 [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)를 AWS Managed Microsoft AD참조하세요.
Amazon EC2에 대한 자세한 내용은 [https://docs.aws.amazon.com/ec2/](https://docs.aws.amazon.com/ec2/)를 참조하세요.
SMB 파일 공유에서 액세스 제어 목록(ACL)을 활성화할 수도 있습니다. ACL을 활성화하는 방법에 대한 자세한 내용은 [Windows ACL을 사용하여 SMB 파일 공유 액세스 제한](smb-acl.md) 섹션을 참조하세요.
**Active Directory 인증을 활성화하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **게이트웨이**를 선택한 다음 SMB 설정을 편집할 게이트웨이를 선택합니다.
1. **작업** 드롭다운 메뉴에서 **SMB 설정 편집**을 선택한 다음 **Active Directory 설정**을 선택합니다.
1. **도메인 이름**에 게이트웨이가 조인할 Active Directory 도메인의 이름을 입력합니다.
**참고**
게이트웨이가 도메인에 조인한 적이 없는 경우**Active Directory 상태는** **분리 완료**로 표시됩니다.
Active Directory 서비스 계정에는 필요한 권한이 있어야 합니다. 자세한 내용은 [Active Directory 서비스 계정 권한 요구 사항](https://docs.aws.amazon.com/filegateway/latest/files3/ad-serviceaccount-permissions.html)을 참조하세요.
도메인에 조인하면 게이트웨이의 **게이트웨이 ID**를 계정 이름(예: SGW-1234ADE)으로 사용하여 기본 컴퓨터 컨테이너(OU 아님)에 Active Directory 컴퓨터 계정이 생성됩니다. 이 계정의 이름은 사용자 지정할 수 없습니다.
Active Directory 환경에서 도메인 조인 프로세스를 용이하게 하기 위해 계정을 사전 준비해야 하는 경우 이 계정을 미리 생성해야 합니다.
Active Directory 환경에 새 컴퓨터 객체에 대해 지정된 OU가 있는 경우 도메인을 조인할 때 해당 OU를 지정해야 합니다.
게이트웨이에서 Active Directory 디렉터리를 조인할 수 없는 경우에는 [JoinDomain](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_JoinDomain.html) API 작업을 사용하여 디렉터리의 IP 주소로 조인해보십시오.
1. **도메인 사용자** 및 **도메인 암호**에 게이트웨이가 도메인에 조인하는 데 사용할 Active Directory 서비스 계정의 자격 증명을 입력합니다.
1. (선택 사항) **조직 단위(OU)**에 Active Directory가 새 컴퓨터 객체에 사용하는 지정된 OU를 입력합니다.
1. (선택 사항) **도메인 컨트롤러(DC)**에 게이트웨이가 Active Directory에 연결할 하나 이상의 DC 이름을 입력합니다. 여러 DC를 쉼표로 구분된 목록으로 입력할 수 있습니다. DNS가 DC를 자동으로 선택할 수 있도록 이 필드를 비워 둘 수 있습니다.
1. **변경 사항 저장**을 선택합니다.
**특정 AD 사용자 및 그룹으로 파일 공유 액세스를 제한하려면**
1. Storage Gateway 콘솔에서 액세스를 제한하려는 파일 공유를 선택합니다.
1. **작업** 드롭다운 메뉴에서 **파일 공유 액세스 설정 편집**을 선택합니다.
1. **사용자 및 그룹 파일 공유 액세스** 섹션에서 설정을 선택합니다.
**허용된 사용자 및 그룹**에서 **허용된 사용자 추가** 또는 **허용된 그룹 추가**를 선택하고 파일 공유 액세스를 허용할 AD 사용자 또는 그룹을 입력합니다. 이 프로세스를 반복하여 필요한 만큼 사용자 및 그룹을 허용합니다.
**거부된 사용자 및 그룹**에서 **거부된 사용자 추가** 또는 **거부된 그룹 추가**를 선택하고 파일 공유 액세스를 거부할 AD 사용자 또는 그룹을 입력합니다. 이 프로세스를 반복하여 필요한 만큼 사용자 및 그룹을 거부합니다.
**참고**
**사용자 및 그룹 파일 공유 액세스** 섹션은 **Active Directory**가 선택된 경우에만 나타납니다.
그룹에는 `@` 문자 접두사가 붙어야 합니다. 허용 가능한 형식은 다음과 같습니다. `DOMAIN\User1`, `user1`, `@group1` 및 `@DOMAIN\group1`.
**허용 및 거부된 사용자 및 그룹** 목록을 구성하면 Windows ACL은 해당 목록을 재정의하는 액세스 권한을 부여하지 않습니다.
**허용 및 거부된 사용자 및 그룹** 목록은 ACL보다 먼저 평가되며 파일 공유를 탑재하거나 액세스할 수 있는 사용자를 제어합니다. **허용** 목록에 사용자 또는 그룹이 있는 경우 해당 목록은 활성으로 간주되며 해당 사용자만 파일 공유를 탑재할 수 있습니다.
사용자가 파일 공유를 탑재한 후 ACL은 사용자가 액세스할 수 있는 특정 파일 또는 폴더를 제어하는 보다 세분화된 보호를 제공합니다. 자세한 내용은 [새 SMB 파일 공유에서 Windows ACL 활성화](https://docs.aws.amazon.com/filegateway/latest/files3/smb-acl.html#enable-acl-new-fileshare)를 참조하세요.
1. 항목 추가를 마치면 **저장**을 선택하십시오.
# 파일 공유에 대한 게스트 액세스 권한 제공
올바른 게스트 계정 사용자 이름과 암호를 제공할 수 있는 모든 사용자에게 게스트 액세스를 허용하도록 S3 File Gateway를 구성할 수 있습니다. 이 방법이 사용자가 File Gateway에 액세스할 수 있는 유일한 방법이 되도록 하려면 게이트웨이를 Microsoft Active Directory 도메인에 조인할 필요가 없습니다. 이 게스트 액세스 방법을 사용하여 Active Directory 도메인의 멤버인 S3 File Gateway에서 파일 공유를 생성할 수도 있습니다.
**게스트 액세스 권한 ** 인증 방법을 사용하도록 파일 공유를 구성하면 게스트 액세스 사용자 이름은 `smbguest`입니다. 게스트 액세스 권한을 사용하여 파일 공유를 생성하려면 먼저 `smbguest` 사용자에 대한 기본 암호를 변경해야 합니다.
다음 절차에 따라 게스트 사용자 `smbguest`의 암호를 변경할 수 있습니다.
**게스트 액세스 암호를 변경하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. 콘솔 페이지 왼쪽의 탐색 창에서 **게이트웨이**를 선택한 다음 게스트 액세스 권한을 제공할 게이트웨이의 **이름**을 선택합니다.
1. **작업** 드롭다운 메뉴에서 **SMB 설정 편집**을 선택한 다음 **게스트 액세스 설정**을 선택합니다.
1. **게스트 암호**에 설정하려는 게스트 액세스 암호를 입력한 다음 **변경 사항 저장**을 선택합니다.
# 게이트웨이의 로컬 그룹을 구성하려면
로컬 그룹 설정을 사용하면 게이트웨이의 SMB 파일 공유에 대한 특별한 권한을 Active Directory 사용자 또는 그룹에 부여할 수 있습니다.
로컬 그룹 설정을 사용하여 게이트웨이 관리자 권한을 할당할 수 있습니다. 게이트웨이 관리자는 공유 폴더 Microsoft Management Console 스냅인을 사용하여 열려 있고 잠긴 파일을 강제로 닫을 수 있습니다.
**참고**
게이트웨이를 Active Directory 도메인에 조인하려면 먼저 하나 이상의 게이트웨이 관리자 사용자 또는 그룹을 추가해야 합니다.
**게이트웨이 관리자를 할당하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **게이트웨이**를 선택한 다음 SMB 설정을 편집할 게이트웨이를 선택합니다.
1. **작업** 드롭다운 메뉴에서 **SMB 설정 편집**을 선택한 다음 **로컬 그룹 설정**을 선택합니다.
1. **로컬 그룹 설정** 섹션에서 설정을 선택합니다. 이 섹션은 Active Directory를 사용하는 파일 공유에만 표시됩니다.
**게이트웨이 관리자**의 경우 로컬 게이트웨이 관리자 권한을 부여하려는 Active Directory 사용자 및 그룹을 추가합니다. 도메인 이름을 포함하여 줄 당 하나의 사용자 또는 그룹을 추가합니다. 예를 들어 **corp\$1Domain Admins**입니다. 줄을 더 생성하려면 **새 게이트웨이 관리자 추가**를 선택합니다.
**참고**
게이트웨이 관리자를 편집하면 모든 SMB 파일 공유의 연결이 해제되었다가 다시 연결됩니다.
1. **변경 사항 저장**을 선택한 다음 **계속**을 선택하여 표시되는 경고 메시지를 확인합니다.
# 파일 공유 표시 여부 설정
파일 공유 표시 여부는 사용자에게 공유를 나열할 때 게이트웨이의 공유를 표시할지 여부를 제어합니다(예: 네트워크 보기 또는 찾아보기 목록). 게이트웨이의 파일 공유가 표시되면 클라이언트가 게이트웨이 IP 주소 또는 DNS 이름을 알고 있는 경우 파일 브라우저를 사용하여 공유를 쉽게 검색할 수 있습니다. 파일 공유가 표시되지 않으면 클라이언트는 게이트웨이 IP 또는 DNS 이름 외에도 파일 공유 이름을 알아야 공유를 검색할 수 있습니다.
**참고**
이 설정은 배포의 파일 공유에 대한 액세스를 보호하는 효과적인 방법이 아닙니다. 보안을 위해 특정 사용자 및 그룹에 대한 액세스를 제한하도록 권한을 구성하는 것이 좋습니다. 지침은 [SMB 파일 공유에 대한 사용자 및 그룹 액세스 제한](https://docs.aws.amazon.com/filegateway/latest/files3/edit-file-share-access-smb.html)을 참조하세요.
**파일 공유 표시 여부를 설정하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **게이트웨이**를 선택한 다음 SMB 설정을 편집할 게이트웨이를 선택합니다.
1. **작업** 드롭다운 메뉴에서 **SMB 설정 편집**을 선택한 다음 **파일 공유 표시 여부 설정**을 선택합니다.
1. 게이트웨이가 사용자에게 공유를 나열할 때 이 게이트웨이의 공유를 표시하려면 **표시 여부 상태** 확인란을 선택합니다. 게이트웨이가 사용자에게 공유를 나열할 때 이 게이트웨이의 공유가 표시되지 않도록 하려면 이 확인란을 선택 취소한 상태로 둡니다.
# SMB 파일 공유에 대한 설정 편집
기존 SMB 파일 공유에 대해 다음 설정을 편집할 수 있습니다.
+ **파일 공유 이름** - 파일 공유의 이름을 선택합니다.
+ **감사 로그** - 감사 로그를 켜거나 끕니다.
+ **기존 로그 그룹 목록** - 감사 로그에 대한 기존 로그 그룹을 선택합니다.
+ **비게이트웨이 파일 캐시 새로 고침 시간** - 파일 공유의 캐시를 새로 고칠 간격을 지정합니다.
**참고**
이 값을 30분 미만으로 설정하면 대량의 Amazon S3 객체가 자주 생성되거나 삭제되는 경우 게이트웨이 성능에 부정적인 영향을 미칠 수 있습니다.
+ **이벤트 업로드 설정 시간** - 클라이언트가 `ObjectUploaded` 알림을 생성하기 전에 파일에 쓴 마지막 시점 이후 대기할 시간(초)을 지정합니다.
+ **새 객체의 스토리지 클래스** - Amazon S3 버킷에 생성한 새 객체에 사용할 스토리지 클래스를 선택합니다.
+ **MIME 유형 추측** - Storage Gateway가 파일 확장자를 기반으로 하여 업로드되는 객체의 MIME 유형을 추측하도록 할지 선택합니다.
+ **S3 버킷 소유자가 액세스할 수 있는 게이트웨이 파일 **- 게이트웨이의 파일을 파일 공유에 연결된 Amazon S3 버킷을 소유한 AWS 계정에 액세스할 수 있도록 할지 여부를 선택합니다.
+ **요청자 지불 활성화** - 버킷 소유자가 아닌 파일 공유에서 데이터를 읽거나 요청하는 계정에 액세스 요금을 지불하도록 요구할지 여부를 선택합니다.
+ **다음으로 내보내기** - 파일을 읽기-쓰기 또는 읽기 전용 상태로 내보낼지 여부를 선택합니다.
+ **제어하는 파일 및 디렉터리 액세스** - Windows ACL 또는 POSIX 권한을 사용하여 파일 및 디렉터리 액세스를 제어할지 여부를 선택합니다.
+ **기회 잠금(oplock)** - 파일 공유가 기회 잠금을 사용하여 파일 버퍼링 전략을 최적화하도록 허용할지 여부를 선택합니다.
+ **대/소문자 구분 강제 적용** - 클라이언트 또는 게이트웨이가 파일 및 디렉터리 이름에 대한 대/소문자 구분을 제어할지 여부를 선택합니다.
**참고**
파일 공유에 현재 강제 대/소문자 구분이 활성화된 경우 비활성화하면 이름이 동일하지만 대/소문자가 다른 파일(예: file.txt, File.txt)에 액세스할 수 없게 될 수 있습니다. 대/소문자를 구분하지 않는 클라이언트는 버전 하나만 액세스할 수 있습니다.
+ **파일 및 디렉터리에 대한 액세스 기반 열거** - 디렉터리 열거 중에 공유의 파일 및 폴더를 모든 사용자에게 표시할지 아니면 읽기 액세스 권한이 있는 사용자에게만 표시할지 선택합니다.
**참고**
새 버킷 또는 액세스 포인트를 가리키도록 기존 파일 공유를 편집하거나 VPC 엔드포인트 설정을 수정할 수 없습니다. 새 파일 공유를 생성할 때만 이러한 설정을 구성할 수 있습니다.
**파일 공유 설정을 편집하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **파일 공유**를 선택한 후 업데이트할 파일 공유를 선택하십시오.
1. **작업**에서 **파일 공유 설정 편집**을 선택합니다.
1. 변경하려는 설정을 모두 변경합니다.
1. **저장**을 선택합니다.
# SMB 파일 공유에 대한 사용자 및 그룹 액세스 제한
파일 공유에 대한 액세스를 제한하려면 허용되거나 거부된 사용자 또는 그룹을 추가하는 것이 좋습니다. 그렇지 않으면 인증된 모든 사용자가 파일 공유를 사용할 수 있습니다.
**SMB 액세스 설정을 편집하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **파일 공유**를 선택한 후 편집할 SMB 파일 공유를 선택합니다.
1. **작업**에서 **액세스 공유 설정 편집**을 선택합니다.
1. **사용자 및 그룹 파일 공유 액세스** 섹션에서 설정을 선택합니다.
**허용된 사용자 및 그룹**에서 **허용된 사용자 추가** 또는 **허용된 그룹 추가**를 선택하고 파일 공유 액세스를 허용할 AD 사용자 또는 그룹을 입력합니다. 이 프로세스를 반복하여 필요한 만큼 사용자 및 그룹을 허용합니다. **허용된 사용자 및 그룹** 목록에 없는 모든 사용자는 액세스가 거부됩니다.
**거부된 사용자 및 그룹**에서 **거부된 사용자 추가** 또는 **거부된 그룹 추가**를 선택하고 파일 공유 액세스를 거부할 AD 사용자 또는 그룹을 입력합니다. 이 프로세스를 반복하여 필요한 만큼 사용자 및 그룹을 거부합니다. **허용된 사용자 및 그룹** 목록이 비어 있는 경우 **거부된 사용자 및 그룹** 목록에 있는 사용자를 제외한 모든 사용자에게 액세스 권한이 부여됩니다.
**참고**
AD 사용자 또는 그룹 이름만 입력합니다. 도메인 이름에는 게이트웨이가 조인되는 특정 AD의 게이트웨이 멤버십이 내재되어 있습니다.
허용된/거부된 사용자 또는 그룹을 지정하지 않으면 모든 인증된 AD 사용자가 파일 공유를 내보낼 수 있습니다.
# 기존 파일 공유의 서버 측 암호화 방법 변경
다음 절차에서는 Storage Gateway 콘솔을 사용하여 기존 NFS 또는 SMB 파일 공유의 서버 측 암호화 방법을 변경하는 방법을 설명합니다. Storage Gateway API를 사용하여 이 작업을 수행하려면 *AWS Storage Gateway API* 참조의 [UpdateNFSFileShare](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_UpdateNFSFileShare.html) 또는 [UpdateSMBFileShare](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_UpdateSMBFileShare.html)를 참조하세요.
**참고**
암호화 방법을 업데이트하면 업데이트 후 Amazon S3 버킷에 저장된 기존 객체에 새 방법이 적용됩니다.
암호화에 SSE-KMS를 사용하도록 File Gateway를 구성하는 경우 파일 공유와 연결된 IAM 역할에 `kms:Encrypt`, `kms:Decrypt`, `kms:ReEncrypt*`, `kms:GenerateDataKey` 및 `kms:DescribeKey` 권한을 수동으로 추가해야 합니다. 자세한 내용은 [Storage Gateway에 대한 자격 증명 기반 정책(IAM 정책) 사용](https://docs.aws.amazon.com/filegateway/latest/files3/using-identity-based-policies.html)을 참조하세요.
**NFS 또는 SMB 파일 공유의 서버 측 암호화 방법을 변경하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **파일 공유**를 선택한 다음 암호화 방법을 변경할 파일 공유를 선택합니다.
1. **작업**에서 **파일 공유 암호화 편집**을 선택합니다.
1. **암호화**에서 Amazon S3의 저장 파일에 사용할 암호화 유형을 선택합니다.
+ Amazon S3(SSE-S3)로 관리되는 서버 측 암호화를 사용하려면 **S3 관리형 키(SSE-S3)**를 선택합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [Amazon S3 관리형 키로 서버 측 암호화 사용](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html)을 참조하세요.
+ AWS Key Management Service(SSE-KMS)로 관리되는 서버 측 암호화를 사용하려면 **KMS 관리형 키(SSE-KMS)를** 선택합니다. **기본 KMS 키**에서 기존 AWS KMS 키를 선택하거나 **새 KMS 키 생성을** 선택하여 AWS Key Management Service(AWS KMS) 콘솔에서 새 KMS 키를 생성합니다.
에 대한 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [AWS Key Management Service란 무엇입니까?](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)를 AWS KMS참조하세요.
+ AWS Key Management Service(DSSE-KMS)로 관리되는 이중 계층 서버 측 암호화를 사용하려면 ** AWS Key Management Service 키를 사용한 이중 계층 서버 측 암호화(DSSE-KMS)**를 선택합니다. **기본 KMS 키**에서 기존 AWS KMS 키를 선택하거나 **새 KMS 키 생성을** 선택하여 AWS Key Management Service(AWS KMS) 콘솔에서 새 KMS 키를 생성합니다.
DSSE-KMS에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [AWS KMS 키를 사용한 이중 계층 서버 측 암호화 사용을](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingDSSEncryption.html) 참조하세요.
**참고**
DSSE-KMS 및 AWS KMS 키 사용에는 추가 요금이 부과됩니다. 자세한 내용은 [AWS KMS 요금](https://aws.amazon.com/kms/pricing/)을 참조하십시오.
목록에 없는 별칭이 있는 AWS KMS 키를 지정하거나 다른 AWS 계정의 AWS KMS 키를 사용하려면를 사용해야 합니다 AWS Command Line Interface. 비대칭 KMS 키는 지원되지 않습니다. 자세한 내용을 알아보려면 *AWS Storage Gateway API 참조*의 [CreateSMBFileShare](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_CreateSMBFileShare.html)를 참조하세요.
1. 완료되었으면 **변경 사항 저장**을 선택합니다.
# NFS 파일 공유에 대한 설정 편집
기존 NFS 파일 공유를 생성한 후 다음 절차에 따라 설정을 편집합니다.
**참고**
새 버킷 또는 액세스 포인트를 가리키도록 기존 파일 공유를 편집하거나 VPC 엔드포인트 설정을 수정할 수 없습니다. 새 파일 공유를 생성할 때만 이러한 설정을 구성할 수 있습니다.
**파일 공유 설정을 편집하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **파일 공유**를 선택한 후 업데이트할 파일 공유를 선택하십시오.
1. **작업**에서 **파일 공유 설정 편집**을 선택합니다.
1. **파일 공유 이름**에 파일 공유의 이름을 입력합니다.
1. **감사 로그**에서 다음 중 하나를 선택합니다.
+ 이 파일 공유에 대한 새 로그 그룹을 생성하려면 **새 로그 그룹 생성**을 선택합니다.
+ 이 파일 공유에 대한 상태 및 리소스 알림을 기존 로그 그룹에 보내려면 **기존 로그 그룹 사용**을 선택한 다음 목록에서 원하는 그룹을 선택합니다.
+ 이 파일 공유에 대한 로깅을 끄려면 **로깅 비활성화**를 선택합니다.
감사 로그에 대한 자세한 내용은 [S3 File Gateway 감사 로그 이해](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#audit-logs)를 참조하세요.
1. **비게이트웨이 파일 캐시 새로 고침 시간**에서 **새로 고침 간격 설정**을 선택한 다음 TTL(Time To Live)을 사용하여 파일 공유의 캐시를 새로 고치는 시간을 **분** 또는 **일** 단위로 설정합니다. TTL은 마지막 새로 고침 이후 경과한 시간입니다. TTL 간격이 경과한 후 디렉터리에 액세스하면 File Gateway가 Amazon S3 버킷에서 해당 디렉터리의 콘텐츠를 새로 고칩니다.
**참고**
이 값을 30분 미만으로 설정하면 대량의 Amazon S3 객체가 자주 생성되거나 삭제되는 경우 게이트웨이 성능에 부정적인 영향을 미칠 수 있습니다.
1. **이벤트 업로드 설정 시간**에서 **설정 시간 설정**을 선택한 다음 설정 시간을 초 단위로 입력합니다. **설정 시간**은 최근 클라이언트 쓰기 작업과 `ObjectUploaded` 로그 알림 생성 사이의 최소 지연을 제어합니다. 클라이언트는 짧은 시간 동안 파일에 소규모 쓰기 작업을 많이 수행할 수 있으므로 동일한 파일에 대해 여러 개의 알림이 빠르게 연속해서 생성되지 않도록 이 파라미터를 최대한 길게 설정하는 것이 좋습니다. 자세한 내용은 [파일 업로드 알림 받기](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#get-file-upload-notification)를 참조하세요.
1. **새 객체의 스토리지 클래스**의 경우 드롭다운 목록에서 스토리지 클래스를 선택합니다. 스토리지 클래스에 대한 자세한 내용은 [File Gateway와 함께 스토리지 클래스 사용](https://docs.aws.amazon.com/filegateway/latest/files3/storage-classes.html#ia-file-gateway)을 참조하세요.
1. **객체 메타데이터**에서 다음을 수행합니다.
1. Storage Gateway가 파일 확장명을 기반으로 업로드된 객체의 미디어 유형을 추측하도록 허용하려면 **MIME 유형 추측**을 선택합니다.
1. **S3 버킷을 소유한 계정이 읽기, 쓰기, 편집 및 삭제 권한을 포함하여 게이트웨이에서 생성한 파일의 전체 소유권을 갖도록 하려면 S3 버킷 소유자가 액세스할** 수 있는 게이트웨이 파일을 선택합니다. AWS S3
1. 버킷 소유자가 아닌 파일 요청자가 데이터 요청 비용을 지불하고 S3 버킷에서 다운로드하도록 하려면 **요청자 지불 활성화**를 선택합니다.
1.
1. **액세스 수준**에서 다음 중 하나를 선택합니다.
+ **Root squash (default)(Root Squash(기본값))** 원격 superuser(root)에 대한 액세스가 UID(65534) 및 GID(65534)로 매핑됩니다.
+ **All squash(모든 Squash)**: 모든 사용자 액세스가 사용자 ID(UID)(65534) 및 그룹 ID(65534)로 매핑됩니다.
+ **No root squash(Root Squash 없음)** 원격 superuser(root)는 root로서 액세스를 받습니다.
1. **다른 이름으로 내보내기**에서 다음 중 하나를 선택합니다.
+ 클라이언트가 파일 공유에서 파일을 읽고 쓸 수 있도록 허용하려면 **읽기/쓰기**를 선택합니다.
+ 클라이언트가 파일을 읽지만 파일 공유에 쓰지 않도록 허용하려면 **읽기 전용**을 선택합니다.
**참고**
Microsoft Windows 클라이언트에 탑재된 파일 공유의 경우, **읽기 전용**을 선택하면 예상하지 못한 오류가 발생하여 폴더를 생성할 수 없다는 메시지가 표시될 수도 있습니다. 이 메시지는 무시해도 됩니다.
1. 설정 편집을 완료한 후 **변경사항 저장**을 선택합니다.
# NFS 파일 공유에서 메타데이터 기본값 편집
버킷의 파일 또는 디렉터리에 대한 메타데이터 값을 설정하지 않으면 S3 File Gateway가 기본 메타데이터 값을 설정합니다. 이러한 값에는 파일 및 폴더에 대한 Unix 권한이 포함됩니다. Storage Gateway 콘솔에서 메타데이터 기본값을 편집할 수 있습니다.
S3 File Gateway가 Amazon S3에 파일 및 폴더를 저장하면 Unix 파일 권한은 객체 메타데이터에 저장됩니다. S3 File Gateway가 S3 File Gateway에서 저장하지 않은 객체를 발견하면 이러한 객체에는 기본 Unix 파일 권한이 할당됩니다. 다음 표에서 기본 Unix 권한을 확인할 수 있습니다.
| Metadata | 설명 |
| --- | --- |
| 디렉터리 권한 | "nnnn" 형식의 Unix 디렉터리 모드. 예를 들어 "0666"은 파일 공유 내 모든 디렉터리의 액세스 모드를 나타냅니다. 기본값은 0777입니다. |
| 파일 권한 | "nnnn" 형식의 Unix 파일 모드. 예를 들어 "0666"은 파일 공유 내 파일 모드를 나타냅니다. 기본값은 0666입니다. |
| 사용자 ID | 파일 공유 내 파일에 대한 기본 소유자 ID. 기본값은 65534입니다. |
| 그룹 ID입니다. | 파일 공유의 기본 그룹 ID. 기본값은 65534입니다. |
**메타데이터 기본값을 편집하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **파일 공유**를 선택한 후 업데이트할 파일 공유를 선택하십시오.
1. **작업**에서 **파일 메타데이터 기본값 편집**을 선택하십시오.
1. **파일 메타데이터 기본값 편집** 대화 상자에서 메타데이터 정보를 입력하고 **저장**을 선택하십시오.
# NFS 파일 공유에 대한 클라이언트 액세스 제한
NFS 파일 공유에 연결할 수 있는 NFS 클라이언트의 특정 클라이언트 IP 주소 또는 CIDR 블록 범위 목록을 정의하려면 NFS 클라이언트 액세스 설정을 편집하는 것이 좋습니다. 액세스를 제한하지 않으면 네트워크의 모든 클라이언트가 파일 공유에 마운트할 수 있습니다.
**NFS 파일 공유에 대한 클라이언트 액세스를 제한하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. 콘솔 페이지 왼쪽의 탐색 창에서 **파일 공유**를 선택한 다음 편집하려는 NFS 파일 공유의 **파일 공유 ID**를 선택합니다.
1. **작업** 드롭다운 메뉴에서 **파일 공유 액세스 설정 편집**을 선택합니다.
**객체 액세스** 섹션에는 현재 NFS 파일 공유에 연결할 수 있는 IP 주소 및 CIDR 블록 목록이 표시됩니다. 현재 액세스가 제한되지 않은 경우 0.0.0.0/0 CIDR 블록의 **허용된 클라이언트** 아래에 가능한 모든 IPv4 주소의 연결이 허용됨을 나타내는 항목이 표시됩니다.
1. **허용된 클라이언트**의 0.0.0.0/0 CIDR 블록 오른쪽에 있는 **제거**를 선택합니다.
1. **클라이언트 추가**를 선택한 다음 허용하려는 클라이언트의 CIDR 표기법으로 IP 주소 또는 주소 범위를 제공합니다.
1. 필요에 따라 IP 주소 또는 범위를 더 추가하려면 이전 단계를 반복합니다. 실수하거나 액세스를 취소해야 하는 경우 목록에서 삭제하려는 IP 주소 또는 범위의 오른쪽에 있는 **제거**를 선택할 수 있습니다.
1. 완료되었으면 **변경 사항 저장**을 선택합니다.
# Amazon S3 버킷 객체 새로 고침
NFS/SMB 클라이언트가 파일 시스템 작업을 수행할 때 게이트웨이가 파일 공유와 연결된 Amazon S3 객체 캐시 내 객체의 인벤토리를 유지합니다. 게이트웨이가 이 캐시된 인벤토리를 사용하여 Amazon S3 요청의 지연 시간 및 빈도를 줄입니다. 이 작업은 S3 File Gateway 캐시 스토리지로 파일을 가져오지 않습니다. Amazon S3 객체 캐시의 객체 인벤토리 변경 사항을 반영하도록 캐시된 인벤토리만 업데이트합니다.
파일 공유의 S3 버킷 객체 캐시를 새로 고치려면 다음 목록에서 사용 사례에 가장 적합한 방법을 선택한 다음 아래 해당 절차를 완료합니다.
**참고**
사용하는 방법에 관계없이 디렉터리를 처음 나열하면 초기화되어 게이트웨이가 Amazon S3에서 디렉터리의 메타 데이터 콘텐츠를 나열합니다. 디렉터리를 초기화하는 데 필요한 시간은 해당 디렉터리의 항목 수에 비례합니다.
**Topics**
+ [Storage Gateway 콘솔을 사용하여 자동 캐시 새로 고침 일정 구성](#auto-refresh-console-procedure)
+ [Amazon CloudWatch 규칙과 AWS Lambda 함께를 사용하여 자동 캐시 새로 고침 일정 구성](#auto-refresh-lambda-procedure)
+ [Storage Gateway 콘솔을 사용하여 수동 캐시 새로 고침 수행](#manual-refresh-console-procedure)
+ [Storage Gateway API를 사용하여 수동 캐시 새로 고침 수행](#manual-refresh-api-procedure)
## Storage Gateway 콘솔을 사용하여 자동 캐시 새로 고침 일정 구성
다음 절차에서는 지정한 TTL(Time To Live) 값을 기반으로 자동 캐시 새로 고침 일정을 구성합니다. TTL 기반 캐시 새로 고침 일정을 구성하기 전에 다음 사항을 고려하세요.
+ TTL은 지정된 디렉터리의 마지막 캐시 새로 고침 이후 시간으로 측정됩니다.
+ TTL 기반 캐시 새로 고침은 지정된 TTL 기간이 만료된 후 지정된 디렉터리에 액세스하는 경우에만 발생합니다.
+ 새로 고침은 비반복적입니다. 액세스 중인 특정 디렉터리에서만 발생합니다.
+ 새로 고침은 TTL 만료 이후 동기화되지 않은 디렉터리에 대해서만 Amazon S3 API 비용이 발생합니다.
+ 디렉터리는 NFS 또는 SMB 활동으로 액세스하는 경우에만 동기화됩니다.
+ 동기화는 지정한 TTL 기간보다 더 자주 발생하지 않습니다.
+ TTL 기반 캐시 새로 고침 구성은 게이트웨이와 Amazon S3 버킷 간의 워크플로 외부에서 Amazon S3 버킷의 콘텐츠를 직접 자주 업데이트하는 경우에만 권장됩니다.
+ 게이트웨이가 디렉터리의 내용을 새로 고치는 동안 만료된 TTL이 있는 디렉터리에 액세스하는 NFS 및 SMB 작업이 차단됩니다.
**참고**
캐시 새로 고침은 디렉터리 액세스 작업을 차단할 수 있으므로 배포에 유용한 가장 긴 TTL 기간을 구성하는 것이 좋습니다.
**Storage Gateway 콘솔을 사용하여 자동 캐시 새로 고침 일정을 구성하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **파일 공유**를 선택합니다.
1. 새로 고침 일정을 구성할 파일 공유를 선택합니다.
1. **작업**에서 **파일 공유 설정 편집**을 선택합니다.
1. **이후 S3에서 자동 캐시 새로 고침**의 경우 확인란을 선택하고 TTL(Time To Live)을 사용하여 파일 공유의 캐시를 새로 고치는 시간을 일, 시간 및 분으로 설정합니다. TTL은 마지막 새로 고침 이후 디렉터리에 액세스할 때 File Gateway가 Amazon S3 버킷에서 해당 디렉터리의 콘텐츠를 처음으로 새로 고칠 때까지의 시간입니다.
1. **변경 사항 저장**을 선택합니다.
## Amazon CloudWatch 규칙과 AWS Lambda 함께를 사용하여 자동 캐시 새로 고침 일정 구성
**Amazon CloudWatch 규칙과 AWS Lambda 함께를 사용하여 자동 캐시 새로 고침 일정을 구성하려면**
1. S3 File Gateway에서 사용하는 S3 버킷을 식별합니다.
1. *이벤트* 섹션이 비어 있는지 확인합니다. 나중에 자동으로 채워집니다.
1. IAM 역할을 생성하고 Lambda `lambda.amazonaws.com`에 대한 신뢰 관계를 허용합니다.
1. 다음 정책을 추가합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "StorageGatewayPermissions",
"Effect": "Allow",
"Action": "storagegateway:RefreshCache",
"Resource": "*"
},
{
"Sid": "CloudWatchLogsPermissions",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:CreateLogGroup",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
------
1. Lambda 콘솔을 사용하여 Lambda 함수를 생성합니다.
1. Lambda 작업에 다음 함수를 사용합니다.
```
import json
import boto3
client = boto3.client('storagegateway')
def lambda_handler(event, context):
print(event)
response = client.refresh_cache(
FileShareARN='arn:aws:storagegateway:ap-southeast-2:672406474878:share/share-E51FBS9C'
)
print(response)
return 'Your FileShare cache has been refreshed'
```
1. **실행 역할**에 대해 생성한 IAM 역할을 선택합니다.
1. 선택 사항: Amazon S3에 대한 트리거를 추가하고 **ObjectCreated** 또는 **ObjectRemoved** 이벤트를 선택합니다.
**참고**
`RefreshCache`는 다른 프로세스를 시작하기 전에 한 프로세스를 완료해야 합니다. 버킷에 많은 객체를 생성하거나 삭제하면 성능이 저하될 수 있습니다. 따라서 S3 트리거를 사용하지 않는 것이 좋습니다. 대신 다음에 설명된 Amazon CloudWatch 규칙을 사용합니다.
1. CloudWatch 콘솔에서 CloudWatch 규칙을 생성하고 일정을 추가합니다. 일반적으로 *고정 속도*는 30분으로 하는 것이 좋습니다. 그러나 대형 S3 버킷에는 1\$12시간을 사용할 수 있습니다.
1. CloudWatch 이벤트에 대한 새 트리거를 추가하고 방금 생성한 규칙을 선택합니다.
1. Lambda 구성을 저장합니다. **테스트**를 선택합니다.
1. **S3 PUT**을 선택하고 요구 사항에 맞게 테스트를 사용자 지정합니다.
1. 테스트가 성공해야 합니다. 그렇지 않은 경우 요구 사항에 맞게 JSON을 수정하고 다시 테스트합니다.
1. Amazon S3 콘솔을 열고 생성한 이벤트와 Lambda 함수 ARN이 있는지 확인합니다.
1. Amazon S3 콘솔 또는 AWS CLI를 사용하여 객체를 S3 버킷에 업로드합니다.
CloudWatch 콘솔은 다음과 유사한 CloudWatch 출력을 생성합니다.
```
{
u'Records': [
{u'eventVersion': u'2.0', u'eventTime': u'2018-09-10T01:03:59.217Z', u'requestParameters': {u'sourceIPAddress': u'MY-IP-ADDRESS'},
u's3': {u'configurationId': u'95a51e1c-999f-485a-b994-9f830f84769f', u'object': {u'sequencer': u'00549CC2BF34D47AED', u'key': u'new/filename.jpeg'},
u'bucket': {u'arn': u'arn:aws:s3:::amzn-s3-demo-bucket', u'name': u'MY-GATEWAY-NAME', u'ownerIdentity': {u'principalId': u'A3OKNBZ72HVPP9'}}, u's3SchemaVersion': u'1.0'},
u'responseElements': {u'x-amz-id-2': u'76tiugjhvjfyriugiug87t890nefevbck0iA3rPU9I/s4NY9uXwtRL75tCyxasgsdgfsq+IhvAg5M=', u'x-amz-request-id': u'651C2D4101D31593'},
u'awsRegion': u'MY-REGION', u'eventName': u'ObjectCreated:PUT', u'userIdentity': {u'principalId': u'AWS:AROAI5LQR5JHFHDFHDFHJ:MY-USERNAME'}, u'eventSource': u'aws:s3'}
]
}
```
Lambda 호출은 다음과 유사한 출력을 제공합니다.
```
{
u'FileShareARN': u'arn:aws:storagegateway:REGION:ACCOUNT-ID:share/MY-SHARE-ID',
'ResponseMetadata': {'RetryAttempts': 0, 'HTTPStatusCode': 200, 'RequestId': '6663236a-b495-11e8-946a-bf44f413b71f',
'HTTPHeaders': {'x-amzn-requestid': '6663236a-b495-11e8-946a-bf44f413b71f', 'date': 'Mon, 10 Sep 2018 01:03:59 GMT',
'content-length': '90', 'content-type': 'application/x-amz-json-1.1'
}
}
}
```
클라이언트에 탑재된 NFS 공유에는 이 업데이트가 반영됩니다.
**참고**
수백만 개의 객체가 있는 대용량 버킷에서 대용량 객체 생성 또는 삭제를 업데이트하는 캐시의 경우 업데이트에 몇 시간이 걸릴 수 있습니다.
1. Amazon S3 콘솔 또는 AWS CLI를 사용하여 해당 객체를 수동으로 삭제합니다.
1. 클라이언트에 탑재된 NFS 공유를 확인합니다. 객체가 사라졌는지 확인합니다(캐시가 새로 고쳐졌기 때문).
1. CloudWatch 로그를 확인하여 `ObjectRemoved:Delete` 이벤트를 사용한 삭제 로그를 확인합니다.
```
{
u'account': u'MY-ACCOUNT-ID', u'region': u'MY-REGION', u'detail': {}, u'detail-type': u'Scheduled Event', u'source': u'aws.events',
u'version': u'0', u'time': u'2018-09-10T03:42:06Z', u'id': u'6468ef77-4db8-0200-82f0-04e16a8c2bdb',
u'resources': [u'arn:aws:events:REGION:MY-ACCOUNT-ID:rule/FGw-RefreshCache-CW']
}
```
**참고**
cron 작업 또는 예약된 작업의 경우 CloudWatch 로그 이벤트는 `u'detail-type': u'Scheduled Event'`입니다.
## Storage Gateway 콘솔을 사용하여 수동 캐시 새로 고침 수행
**Storage Gateway 콘솔을 사용하여 수동 캐시 새로 고침을 수행하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. **파일 공유**를 선택한 다음 새로 고침을 수행할 파일 공유를 선택합니다.
1. **작업**에서 **캐시 새로 고침**을 선택하십시오.
새로 고침 프로세스에 걸리는 시간은 게이트웨이에 캐시된 객체의 수와 S3 버킷에 추가되거나 S3 버킷에서 제거된 객체의 수에 따라 달라집니다.
## Storage Gateway API를 사용하여 수동 캐시 새로 고침 수행
다음 절차에서는 Storage Gateway API를 사용하여 수동 캐시 새로 고침을 수행합니다. API 기반 캐시 새로 고침을 수행하기 전에 다음 사항을 고려하세요.
+ 재귀 또는 비재귀 새로 고침을 지정할 수 있습니다.
+ 재귀 새로 고침은 리소스 집약적이고 비용이 많이 듭니다.
+ 새로 고침은 요청에서 인수로 전달하는 디렉터리에만 Amazon S3 API 비용이 발생하고, 재귀 새로 고침을 지정하는 경우 해당 디렉터리의 하위 항목에만 비용이 발생합니다.
+ 새로 고침은 게이트웨이를 사용하는 동안 다른 작업과 동시에 실행됩니다.
+ NFS 및 SMB 작업은 일반적으로 작업에서 액세스하는 디렉터리에 대해 새로 고침이 활성화되지 않는 한 새로 고침 중에 차단되지 않습니다.
+ 게이트웨이는 현재 캐시 콘텐츠가 오래된 것인지 확인할 수 없으며 최신성과 관계없이 NFS 및 SMB 작업에 현재 콘텐츠를 사용합니다.
+ 캐시 새로 고침은 게이트웨이 가상 하드웨어 리소스를 활용하므로 새로 고침이 진행되는 동안 게이트웨이 성능에 부정적인 영향을 미칠 수 있습니다.
+ API 기반 캐시 새로 고침은 게이트웨이와 Amazon S3 버킷 간의 워크플로 외부에서 Amazon S3 버킷의 콘텐츠를 직접 업데이트하는 경우에만 권장됩니다.
**참고**
게이트웨이 워크플로 외부에서 Amazon S3 콘텐츠를 업데이트하는 특정 디렉터리를 알고 있는 경우 API 기반 새로 고침 요청에 이러한 디렉터리를 지정하여 Amazon S3 API 비용과 게이트웨이 성능 영향을 줄이는 것이 좋습니다.
**Storage Gateway API를 사용하여 수동 캐시 새로 고침을 수행하려면**
+ HTTP POST 요청을 보내 Storage Gateway API를 통해 원하는 파라미터로 `RefreshCache` 작업을 호출합니다. 자세한 내용은 *AWS Storage Gateway API 참조*에서 [RefreshCache](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_RefreshCache.html)를 참조하세요.
**참고**
`RefreshCache` 요청을 전송하면 캐시 새로 고침 작업만 시작됩니다. 캐시 새로 고침이 완료되었다고 해서 반드시 파일 새로 고침이 완료되었음을 의미하지는 않습니다. 게이트웨이 파일 공유에서 새 파일을 확인하기 전에 파일 새로 고침 작업이 완료되었는지 확인하려면 `refresh-complete` 알림을 사용하십시오. 이렇게 하려면 Amazon CloudWatch 이벤트를 통해 알림을 받도록 구독하면 됩니다. 자세한 내용은 [파일 작업에 대한 알림 받기](monitoring-file-gateway.md#get-notification) 단원을 참조하십시오.
# Amazon S3 File Gateway에 S3 Object Lock 사용
Amazon S3 File Gateway는 Amazon S3 Object Lock이 켜진 S3 버킷에 대한 액세스를 지원합니다. Amazon S3 Object Lock을 사용하면 "Write Once Read Many(WORM)" 모델을 사용하여 객체를 저장할 수 있습니다. Amazon S3 Object Lock을 사용하면, S3 버킷의 객체를 삭제하거나 덮어쓰지 못하게 할 수 있습니다. Amazon S3 Object Lock은 객체 버전 관리 기능과 연동하여 데이터를 보호합니다.
Amazon S3 Object Lock을 활성화할 경우에도 객체를 수정할 수는 있습니다. 예를 들어 S3 File Gateway의 파일 공유를 통해 객체에 쓰거나 객체를 삭제하거나 객체 이름을 변경할 수 있습니다. 이러한 방식으로 객체를 수정할 경우 S3 File Gateway는 이전 버전(잠긴 개체)에 영향을 주지 않고 새 버전의 객체를 저장합니다.
예를 들어 S3 File Gateway NFS 또는 SMB 인터페이스를 사용하여 파일을 삭제할 때 해당 S3 객체가 잠긴 경우, 게이트웨이는 S3 삭제 마커를 객체의 다음 버전으로 배치하고 원래 객체 버전을 그대로 유지합니다. 마찬가지로, S3 File Gateway가 잠긴 객체의 내용이나 메타데이터를 수정하는 경우, 객체의 새 버전은 변경 사항과 함께 업로드되지만 객체의 원래 잠금 버전은 변경되지 않은 상태로 유지됩니다.
Amazon S3 3 Object Lock 기능에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [S3 Object Lock을 사용하여 객체 잠금](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lock.html)을 참조하세요.
# 파일 공유 상태 이해
파일 공유의 상태를 확인하여 파일 공유의 상태를 한눈에 볼 수 있습니다. 상태가 파일 공유가 정상적으로 작동하고 있음을 나타내는 경우 사용자는 아무런 조치를 취할 필요가 없습니다. 상태가 문제가 있음을 나타내는 경우 조사하여 조치가 필요한지 여부를 확인할 수 있습니다.
Storage Gateway 콘솔의 상태 열에서 파일 공유의 **상태**를 볼 수 있습니다. 제대로 작동하는 파일 공유에는 AVAILABLE 상태가 표시됩니다. 대부분의 경우 이 상태가 되어야 합니다.
다음 표에서는 파일 공유 상태, 파일 공유의 의미 및 조치가 필요한지 여부를 설명합니다.
| Status | 의미 |
| --- | --- |
| AVAILABLE | 파일 공유가 적절히 구성되어 사용할 수 있습니다. 제대로 작동하는 파일 공유의 표준 상태입니다. |
| CREATING | 파일 공유가 아직 완전히 생성되지 않았으므로 사용할 준비가 되지 않았습니다. CREATING 상태는 일시적입니다. 아무 조치도 필요하지 않습니다. 파일 공유가이 상태에서 멈춘 경우 게이트웨이 VM이 연결을 끊었기 때문일 수 있습니다 AWS. |
| 업데이트 중 | 파일 공유 구성이 현재 업데이트 중입니다. 업데이트 중 상태는 과도기적인 상태입니다. 아무 조치도 필요하지 않습니다. 파일 공유가이 상태에서 멈춘 경우 게이트웨이 VM이 연결을 끊었기 때문일 수 있습니다 AWS. |
| DELETING | 파일 공유를 삭제하고 있습니다. 모든 데이터가 업로드될 때까지 파일 공유는 삭제되지 않습니다 AWS. DELETING 상태는 일시적이므로 아무 조치도 취할 필요가 없습니다. |
| FORCE\$1DELETING | 파일 공유를 강제로 삭제하고 있습니다. 파일 공유는 즉시 삭제되고 데이터는에 업로드되지 않습니다 AWS. FORCE\$1DELETING 상태는 일시적이므로 아무 조치도 취할 필요가 없습니다. |
| UNAVAILABLE | 파일 공유가 비정상 상태입니다. 조치가 필요합니다. 몇 가지 가능한 원인으로는 역할 정책 오류 또는 존재하지 않는 Amazon S3 버킷에 대한 매핑이 있습니다. 비정상 상태를 유발한 문제가 해결되면 파일 공유는 다시 AVAILABLE 상태가 됩니다. |
# 게이트웨이 상태 이해
AWS Storage Gateway 배포의 각 게이트웨이에는 게이트웨이의 상태를 한눈에 알려주는 연결된 상태가 있습니다. 대부분의 경우 그 상태는 게이트웨이가 정상적으로 작동하고 있으므로 아무 조치도 취할 필요가 없음을 알려줍니다. 어떤 경우에는 상태를 통해 조치가 필요한 또는 필요 없는 문제가 있음을 나타냅니다.
Storage Gateway 콘솔의 **게이트웨이** 페이지에서 배포의 각 게이트웨이 상태를 확인할 수 있습니다. 게이트웨이 상태가 게이트웨이 이름 옆의 **상태** 열에 나타납니다. 정상적으로 작동하는 게이트웨이의 상태는 `RUNNING`입니다.
다음 표에는 각 게이트웨이 상태에 대한 설명과 해당 상태를 기반으로 조치를 취해야 하는지 여부가 나와 있습니다. 사용 중인 모든 경우 또는 거의 대부분의 경우에 게이트웨이는 `RUNNING` 상태여야 합니다.
| Status | 의미 |
| --- | --- |
| RUNNING | 게이트웨이가 적절히 구성되어 사용할 수 있습니다. |
| OFFLINE | 다음 중 하나 이상의 이유로 게이트웨이가 `OFFLINE` 상태일 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/filegateway/latest/files3/understand-gateway-status.html) |
# Amazon S3 File Gateway의 대역폭 관리
게이트웨이의 업로드 처리량을 로 제한 AWS 하여 게이트웨이가 사용하는 네트워크 대역폭의 양을 제어할 수 있습니다. 기본적으로 활성화된 게이트웨이는 속도 제한이 없습니다.
AWS Management Console, AWS 소프트웨어 개발 키트(SDK) 또는 AWS Storage Gateway API를 사용하여 bandwidth-rate-limit 일정을 구성할 수 있습니다(*AWS Storage Gateway API 참조*의 [UpdateBandwidthRateLimitSchedule](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_UpdateBandwidthRateLimitSchedule.html) 참조). 대역폭 속도 제한 일정을 사용하는 경우 하루 또는 일주일 내내 제한이 자동으로 변경되도록 구성할 수 있습니다. 자세한 내용은 [Storage Gateway 콘솔을 사용하여 게이트웨이의 대역폭 속도 제한 일정을 보고 편집할 수 있습니다.](#SchedulingBandwidthThrottling) 단원을 참조하십시오.
Storage Gateway 콘솔의 **모니터링** 탭 또는 Amazon CloudWatch에서 `CloudBytesUploaded` 지표를 사용하여 Storage Gateway의 업로드 처리량을 모니터링할 수 있습니다.
**참고**
대역폭 속도 제한은 Storage Gateway 파일 업로드에만 적용됩니다. 다른 게이트웨이 작업은 영향을 받지 않습니다.
대역폭 속도 제한은 업로드되는 모든 파일의 초당 평균 처리량을 밸런싱하는 방식으로 작동합니다. 업로드가 특정 마이크로초 또는 밀리초 동안 대역폭 속도 제한을 잠시 초과할 수는 있지만, 장기간에 걸쳐 큰 폭의 스파이크가 발생하지는 않습니다.
현재는 대역폭 속도 제한 및 일정 구성이 Amazon FSx File Gateway 유형에서 지원되지 않습니다.
**Topics**
+ [Storage Gateway 콘솔을 사용하여 게이트웨이의 대역폭 속도 제한 일정을 보고 편집할 수 있습니다.](#SchedulingBandwidthThrottling)
+ [를 사용하여 게이트웨이 대역폭 속도 제한 업데이트 AWS SDK for Java](#MaintenanceUpdateBandwidthJava-common)
+ [를 사용하여 게이트웨이 대역폭 속도 제한 업데이트 AWS SDK for .NET](#MaintenanceUpdateBandwidthDotNet-common)
+ [를 사용하여 게이트웨이 대역폭 속도 제한 업데이트 AWS Tools for Windows PowerShell](#MaintenanceUpdateBandwidthPowerShell-common)
## Storage Gateway 콘솔을 사용하여 게이트웨이의 대역폭 속도 제한 일정을 보고 편집할 수 있습니다.
이 섹션에서는 게이트웨이의 대역폭 속도 제한 일정을 보고 편집하는 방법을 설명합니다.
**대역폭 속도 제한 일정을 보고 편집하려면**
1. Storage Gateway 콘솔([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/))을 엽니다.
1. 왼쪽 탐색 창에서 **게이트웨이**를 선택한 다음 관리할 게이트웨이를 선택합니다.
1. **작업**에서 **대역폭 속도 제한 일정 편집**을 선택합니다.
게이트웨이의 현재 대역폭 속도 제한 일정이 **대역폭 속도 제한 일정 편집** 페이지에 표시됩니다. 기본적으로 새 게이트웨이에는 정의된 대역폭 속도 제한이 없습니다.
1. (선택 사항) **새 대역폭 속도 제한 추가**를 선택하여 구성 가능한 새 간격을 일정에 추가합니다. 추가한 간격에 대해 다음 정보를 입력합니다.
+ **업로드 속도** - 업로드 속도 제한을 초당 메가비트(Mbps) 단위로 입력합니다. 최소값은 100Mbps입니다.
+ **요일** - 간격을 적용할 요일을 선택합니다. 평일(월요일\$1금요일), 주말(토요일 및 일요일), 매주 요일 또는 매주 특정 요일에 간격을 적용할 수 있습니다. 대역폭 속도 제한을 모든 날짜 및 항상 균일하게 지속적으로 적용하려면 **일정 없음**을 선택합니다.
+ **시작 시간** - 게이트웨이의 UTC 기준 시간대와 HH:MM 형식을 사용하여 대역폭 간격의 시작 시간을 입력합니다.
**참고**
여기에 지정한 시간이 시작되면 대역폭 속도 제한 간격이 시작됩니다.
+ **종료 시간** - 게이트웨이의 GMT 기준 시간대와 HH:MM 형식을 사용하여 대역폭 간격의 종료 시간을 입력합니다.
**중요**
여기에 지정된 시간이 끝나면 대역폭 속도 제한 간격이 종료됩니다. 한 시간이 지나면 종료되는 간격을 예약하려면 **59**를 입력합니다.
간격 사이에 중단 없이 시간 시작 시점에 전환되는 연속적인 간격을 예약하려면 첫 번째 간격의 종료 분에 **59**를 입력합니다. 다음 간격의 시작 분에는 **00**을 입력합니다.
1. (선택 사항) 대역폭 속도 제한 일정이 완료될 때까지 원하는 대로 이전 단계를 반복합니다. 일정에서 일정 간격을 삭제해야 하는 경우 **제거**를 선택합니다.
**중요**
대역폭 속도 제한 간격은 겹칠 수 없습니다. 간격의 시작 시간은 이전 간격의 종료 시간 이후, 다음 간격의 시작 시간 이전이어야 합니다.
1. 작업을 마쳤으면 **변경 사항 저장**을 선택합니다.
## 를 사용하여 게이트웨이 대역폭 속도 제한 업데이트 AWS SDK for Java
대역폭 속도 제한을 프로그래밍 방식으로 업데이트하면 일정 기간 동안 예약된 작업을 사용하는 등의 방법으로 자동으로 제한을 조정할 수 있습니다. 다음 예시는 AWS SDK for Java를 사용하여 게이트웨이의 대역폭 속도 제한을 업데이트하는 방법을 보여줍니다. 예시 코드를 사용하려면 Java 콘솔 애플리케이션을 실행하는 방법을 잘 알아야 합니다. 자세한 내용은AWS SDK for Java 개발자 안내서에서 [시작하기](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-setup.html)를 참조하세요.**
**Example :를 사용하여 게이트웨이 대역폭 속도 제한 업데이트 AWS SDK for Java**
다음 Java 코드 예시에서는 게이트웨이의 대역폭 속도 제한을 업데이트합니다. 이 예제 코드를 사용하려면 서비스 엔드포인트, 게이트웨이 Amazon 리소스 이름(ARN), 업로드 한도를 제공해야 합니다. Storage Gateway에서 사용할 수 있는 AWS 서비스 엔드포인트 목록은AWS 일반 참조에서 [AWS Storage Gateway 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/sg.html)을 참조하세요.**
```
import java.io.IOException;
import com.amazonaws.AmazonClientException;
import com.amazonaws.auth.PropertiesCredentials;
import com.amazonaws.services.storagegateway.AWSStorageGatewayClient;
import com.amazonaws.services.storagegateway.model. UpdateBandwidthRateLimitScheduleRequest;
import com.amazonaws.services.storagegateway.model. UpdateBandwidthRateLimitScheduleReturn;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;
public class UpdateBandwidthExample {
public static AWSStorageGatewayClient sgClient;
// The gatewayARN
public static String gatewayARN = "*** provide gateway ARN ***";
// The endpoint
static String serviceURL = "https://storagegateway.us-east-1.amazonaws.com";
// Rates
static long uploadRate = 100 * 1024 * 1024; // Bits per second, minimum 100 Megabits/second
public static void main(String[] args) throws IOException {
// Create a Storage Gateway client
sgClient = new AWSStorageGatewayClient(new PropertiesCredentials(
UpdateBandwidthExample.class.getResourceAsStream("AwsCredentials.properties")));
sgClient.setEndpoint(serviceURL);
UpdateBandwidth(gatewayARN, uploadRate, null); // download rate not supported by S3 File Gateways
}
private static void UpdateBandwidth(String gatewayArn, long uploadRate, long downloadRate) {
try
{
BandwidthRateLimit bandwidthRateLimit = new BandwidthRateLimit(downloadRate, uploadRate);
BandwidthRateLimitInterval noScheduleInterval = new BandwidthRateLimitInterval()
.withBandwidthRateLimit(bandwidthRateLimit)
.withDaysOfWeek(Arrays.asList(1, 2, 3, 4, 5, 6, 0))
.withStartHourOfDay(0)
.withStartMinuteOfHour(0)
.withEndHourOfDay(23)
.withEndMinuteOfHour(59);
UpdateBandwidthRateLimitScheduleRequest updateBandwidthRateLimitScheduleRequest =
new UpdateBandwidthRateLimitScheduleRequest()
.withGatewayARN(gatewayArn)
.with BandwidthRateLimitIntervals(Collections.singletonList(noScheduleInterval));
UpdateBandwidthRateLimitScheduleReturn updateBandwidthRateLimitScheuduleResponse = sgClient.UpdateBandwidthRateLimitSchedule(updateBandwidthRateLimitScheduleRequest);
String returnGatewayARN = updateBandwidthRateLimitScheuduleResponse.getGatewayARN();
System.out.println("Updated the bandwidth rate limits of " + returnGatewayARN);
System.out.println("Upload bandwidth limit = " + uploadRate + " bits per second");
}
catch (AmazonClientException ex)
{
System.err.println("Error updating gateway bandwith.\n" + ex.toString());
}
}
}
```
## 를 사용하여 게이트웨이 대역폭 속도 제한 업데이트 AWS SDK for .NET
대역폭 속도 제한을 프로그래밍 방식으로 업데이트하면 일정 기간 동안 예약된 작업을 사용하는 등의 방법으로 자동으로 제한을 조정할 수 있습니다. 다음 예제에서는 .NET용 AWS 소프트웨어 개발 키트(SDK)를 사용하여 게이트웨이의 대역폭 속도 제한을 업데이트하는 방법을 보여줍니다. 예시 코드를 사용하려면 .NET 콘솔 애플리케이션을 실행하는 방법을 잘 알아야 합니다. 자세한 내용은AWS SDK for .NET 개발자 안내서에서 [시작하기](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-setup.html)를 참조하세요.**
**Example :를 사용하여 게이트웨이 대역폭 속도 제한 업데이트 AWS SDK for .NET**
다음 C\$1 코드 예시에서는 게이트웨이의 대역폭 속도 제한을 업데이트합니다. 이 예제 코드를 사용하려면 서비스 엔드포인트, 게이트웨이 Amazon 리소스 이름(ARN), 업로드 한도를 제공해야 합니다. Storage Gateway에서 사용할 수 있는 AWS 서비스 엔드포인트 목록은AWS 일반 참조에서 [AWS Storage Gateway 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/sg.html)을 참조하세요.**
```
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Amazon.StorageGateway;
using Amazon.StorageGateway.Model;
namespace AWSStorageGateway
{
class UpdateBandwidthExample
{
static AmazonStorageGatewayClient sgClient;
static AmazonStorageGatewayConfig sgConfig;
// The gatewayARN
public static String gatewayARN = "*** provide gateway ARN ***";
// The endpoint
static String serviceURL = "https://storagegateway.us-east-1.amazonaws.com";
// Rates
static long uploadRate = 100 * 1024 * 1024; // Bits per second, minimum 100 Megabits/second
public static void Main(string[] args)
{
// Create a Storage Gateway client
sgConfig = new AmazonStorageGatewayConfig();
sgConfig.ServiceURL = serviceURL;
sgClient = new AmazonStorageGatewayClient(sgConfig);
UpdateBandwidth(gatewayARN, uploadRate, null);
Console.WriteLine("\nTo continue, press Enter.");
Console.Read();
}
public static void UpdateBandwidth(string gatewayARN, long uploadRate, long downloadRate)
{
try
{
BandwidthRateLimit bandwidthRateLimit = new BandwidthRateLimit(downloadRate, uploadRate);
BandwidthRateLimitInterval noScheduleInterval = new BandwidthRateLimitInterval()
.withBandwidthRateLimit(bandwidthRateLimit)
.withDaysOfWeek(Arrays.asList(1, 2, 3, 4, 5, 6, 0))
.withStartHourOfDay(0)
.withStartMinuteOfHour(0)
.withEndHourOfDay(23)
.withEndMinuteOfHour(59);
List bandwidthRateLimitIntervals = new List();
bandwidthRateLimitIntervals.Add(noScheduleInterval);
UpdateBandwidthRateLimitScheduleRequest updateBandwidthRateLimitScheduleRequest =
new UpdateBandwidthRateLimitScheduleRequest()
.withGatewayARN(gatewayARN)
.with BandwidthRateLimitIntervals(bandwidthRateLimitIntervals);
UpdateBandwidthRateLimitScheduleReturn updateBandwidthRateLimitScheuduleResponse = sgClient.UpdateBandwidthRateLimitSchedule(updateBandwidthRateLimitScheduleRequest);
String returnGatewayARN = updateBandwidthRateLimitScheuduleResponse.GatewayARN;
Console.WriteLine("Updated the bandwidth rate limits of " + returnGatewayARN);
Console.WriteLine("Upload bandwidth limit = " + uploadRate + " bits per second");
}
catch (AmazonStorageGatewayException ex)
{
Console.WriteLine("Error updating gateway bandwith.\n" + ex.ToString());
}
}
}
}
```
## 를 사용하여 게이트웨이 대역폭 속도 제한 업데이트 AWS Tools for Windows PowerShell
대역폭 속도 제한을 프로그래밍 방식으로 업데이트하면 일정 기간 동안 예약된 작업을 사용하는 등의 방법으로 자동으로 제한을 조정할 수 있습니다. 다음 예시는 AWS Tools for Windows PowerShell를 사용하여 게이트웨이의 대역폭 속도 제한을 업데이트하는 방법을 보여줍니다. 예시 코드를 사용하려면 PowerShell 스크립트를 실행하는 방법을 잘 알아야 합니다. 자세한 내용은 *AWS Tools for PowerShell 사용 설명서*에서 [시작하기](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-started.html)를 참조하세요.
**Example :를 사용하여 게이트웨이 대역폭 속도 제한 업데이트 AWS Tools for Windows PowerShell**
다음 PowerShell 스크립트 예시에서는 게이트웨이의 대역폭 속도 제한을 업데이트합니다. 이 예제 스크립트를 사용하려면 게이트웨이 Amazon 리소스 이름(ARN) 및 업로드 한도를 제공해야 합니다.
```
<#
.DESCRIPTION
Update Gateway bandwidth limits schedule
.NOTES
PREREQUISITES:
1) AWS Tools for PowerShell from https://aws.amazon.com/powershell/
2) Credentials and region stored in session using Initialize-AWSDefault.
For more info, see https://docs.aws.amazon.com/powershell/latest/userguide/specifying-your-aws-credentials.html
.EXAMPLE
powershell.exe .\SG_UpdateBandwidth.ps1
#>
$UploadBandwidthRate = 100 * 1024 * 1024
$gatewayARN = "*** provide gateway ARN ***"
$bandwidthRateLimitInterval = New-Object Amazon.StorageGateway.Model.BandwidthRateLimitInterval
$bandwidthRateLimitInterval.StartHourOfDay = 0
$bandwidthRateLimitInterval.StartMinuteOfHour = 0
$bandwidthRateLimitInterval.EndHourOfDay = 23
$bandwidthRateLimitInterval.EndMinuteOfHour = 59
$bandwidthRateLimitInterval.DaysOfWeek = 0,1,2,3,4,5,6
$bandwidthRateLimitInterval.AverageUploadRateLimitInBitsPerSec = $UploadBandwidthRate
#Update Bandwidth Rate Limits
Update-SGBandwidthRateLimitSchedule -GatewayARN $gatewayARN `
-BandwidthRateLimitInterval @($bandwidthRateLimitInterval)
$schedule = Get-SGBandwidthRateLimitSchedule -GatewayARN $gatewayARN
Write-Output("`nGateway: " + $gatewayARN);
Write-Output("`nNew bandwidth throttle schedule: " + $schedule.BandwidthRateLimitIntervals.AverageUploadRateLimitInBitsPerSec)
```