# EC2 IAM과 함께 S3 백업이 작동하지 않음

**URL:** https://meta.discourse.org/t/s3-backup-not-working-with-ec2-iam/234191
**Category:** Self-hosting
**Tags:** backups, s3
**Created:** [7월 27, 2022, 9:44오후 UTC](https://meta.discourse.org/t/s3-backup-not-working-with-ec2-iam/234191 "2022-07-27T21:44:32Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![paresy](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/paresy/32/96471_2.png) [@paresy](https://meta.discourse.org/u/paresy)
#### Post date: [7월 27, 2022, 9:44오후 UTC](https://meta.discourse.org/t/s3-backup-not-working-with-ec2-iam/234191/1 "2022-07-27T21:44:33Z")

</div>

이 문제에 관한 모든 주제와 튜토리얼을 검색하고 살펴본 것 같습니다.

백업 페이지를 열려고 할 때마다 항상 다음과 같은 오류가 발생합니다:

> Error while trying to load [/admin/backups.json](https://forum/admin/backups.json)

`/admin/backups.json`을 열면 단순히 `Access Denied` 오류만 표시됩니다.

이해가 안 되는 점은, EC2 인스턴스에서 다음 명령을 사용하면 정상적으로 작동한다는 것입니다:

> aws s3 ls s3://my-bucket-name

그리고 `./launcher enter app`으로 discourse 컨테이너에 들어가서 s3cmd를 설치한 후에도 이 명령을 성공적으로 실행할 수 있습니다:

> s3cmd ls s3://my-bucket-name

이 명령을 사용하여 버킷에 파일을 업로드할 수도 있으므로 IAM 정책에는 문제가 없을 것 같고, 왜 Discourse가 버킷에 접근하지 못하는지 이해할 수 없습니다. 권한 설정이 너무 엄격해서 발생하는 문제를 배제하기 위해 IAM 역할에 "AdministratorAccess"를 추가해 보기도 했습니다.

Discourse 설정:

```plaintext
backup location: S3
s3 backup bucket: my-bucket-name
s3 use iam profile: true
s3 region: 올바른 리전입니다. 세 번 확인했습니다.

```

나머지 s3 옵션은 그대로 두었습니다 → 따라서 대부분 비어 있거나 비활성화되어 있습니다.

무엇이 잘못되었을 수 있는지 아이디어가 있을까요?

감사합니다!

---

<div class="post-metadata">

### Author: ![maiki](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/maiki/32/233950_2.png) [@maiki](https://meta.discourse.org/u/maiki)
#### Post date: [7월 27, 2022, 10:14오후 UTC](https://meta.discourse.org/t/s3-backup-not-working-with-ec2-iam/234191/2 "2022-07-27T22:14:29Z")

</div>

> [@paresy](#):
>
> `/admin/backups.json`을 열면 일반적인 `Access Denied` 오류만 표시됩니다.

이것이 S3 설정과 관련이 있을 것 같지는 않고, 내부 Discourse 권한 메시지처럼 들립니다. `.json`을 끝에 붙이지 않고 `/admin/backups`를 페이지로 로드할 수 있나요?

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [7월 27, 2022, 10:22오후 UTC](https://meta.discourse.org/t/s3-backup-not-working-with-ec2-iam/234191/3 "2022-07-27T22:22:43Z")

</div>

이런 문제를 디버깅하는 가장 쉬운 방법은 Cloudtrail 로그를 확인하는 것입니다.

---

<div class="post-metadata">

### Author: ![paresy](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/paresy/32/96471_2.png) [@paresy](https://meta.discourse.org/u/paresy)
#### Post date: [7월 28, 2022, 11:24오전 UTC](https://meta.discourse.org/t/s3-backup-not-working-with-ec2-iam/234191/4 "2022-07-28T11:24:23Z")

</div>

정말 유용한 힌트였습니다. 권한 오류를 추적해 보니 Discourse가 다른 사용자를 사용하고 있는 것을 확인할 수 있었습니다. 이제 큰 의문인 "왜 이전에는 아무도 이 오류를 겪지 않았는가"에 대해 살펴볼 차례입니다.

우리는 AWS SNS를 통해 푸시 알림을 보내는 자체 플러그인을 사용하고 있었는데, 이 플러그인이 `Aws.config.update`를 통해 자격 증명을 전역으로 설정하고 있었습니다. 이로 인해 S3 Backup도 필요한 권한이 없는 잘못된 자격 증명을 사용하게 된 것입니다.

앞으로 해당 플러그인을 수정하여 자격 증명/리전을 로컬로 제공하고, 현재 더 선호하는 EC2 IAM 역할을 지원하도록 하겠습니다. 🙂

정확한 방향으로의 도움을 주셔서 감사합니다!

paresy

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [8월 27, 2022, 11:24오전 UTC](https://meta.discourse.org/t/s3-backup-not-working-with-ec2-iam/234191/5 "2022-08-27T11:24:31Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
