AWS에는 클라우드 기반으로 이메일 서비스를 이용할 수 있게 하는 Simple Email Service(이하 SES)가 존재한다. 하지만 SES 설정 초기에는 샌드박스 계정에 있다면서 경고를 띄워준다. 샌드박스 계정이란, 일일 이메일 건수 200건 및 AWS SES에 자격 증명이 된 이메일로만 메일을 보낼 수 있는 계정을 의미한다. 다시 말해, 샌드박스 계정으로는 이메일 인증을 거치지 않은 타 이메일로 메일 전송이 불가능하다는 것이다.
그렇다고 앱에 회원가입한 사람들한테 매번 aws 이메일 인증을 부탁하는 것도 웃긴 일이다.
그렇기 때문에 aws SES 샌드박스 계정 탈출을 신청했으나... 1번은 거절당했고, 다른 1번은 무려 2주의 시간을 들여 겨우겨우 Sandbox 계정에서 벗어날 수 있었다.
이번 포스팅에는 해당 내용 일기(?)를 작성할 것이다.
코드적인 내용은 매우 적고, 어떤 과정과 삽질을 거쳤는지 가볍게 봐주면 좋을 듯하다.
첫 번째 요청 - 너무 쉽게 생각했던 요청
첫 번째 요청은 4월 19일에 보냈었다.
지금 생각하면 SES Sandbox 계정에서 벗어나는 작업을 너무 쉽게 생각했었던 요청을 보냈었는데, 그 내용은 아래와 같다.
Use case description: I'm making an app with my friends that recommends a good cafe to code as a side project for coding practice. We need to authenticate user's email to sign up for the app. Therefore, I would like to send an email through AWS SES.
Mail Type: TRANSACTIONAL
요약하자면, `친구들과 자기개발 목적으로 사이드 프로젝트로 코딩하기 좋은 카페 지도 앱을 만들고 있다. 이메일 인증 기능이 필요하다. Transactional 목적이다.` 가 끝이다. 참고로 요청은 오직 영어, 일본어로만 가능하다.
AWS 측에서 정보가 너무 부족하다고, 아래 예시 정보들을 추가로 보내달라는 답변이 왔다.
- 이메일 발송 빈도
- 수신자 목록을 유지 관리하는 방법
- 반송, 불만 및 구독 취소 요청을 관리하는 방법
- 이메일 예시
그럼에도 불구하고, 나는 이 작업을 너무 안일하게 생각했었는지
`친구들과 사이드 프로젝트 용으로 개발하는 것이라 크게 생각한 것은 없다. 다만, 승인되지 않은 메일 주소로 전송하는 기능이 필요하다. 기업용도가 아닌 대학생 사이드 프로젝트다`
라고 답변을 보냈다.
AWS 측에서 우리 애플리케이션을 기업 규모로 생각하지 않고, 가볍고 악의가 없는 사이드 프로젝트 정도로 인지하게 하고 싶었던 것.
당연히 요청은 거절됐다.
Hello,
Thank you for providing us with additional information regarding your sending limits. We are unable to grant your request at this time.
귀하의 발송 제한에 대한 추가 정보를 제공해 주셔서 감사합니다. 귀하의 요청을 승인할 수 없습니다.
We reviewed your request and determined that your use of Amazon SES could have a negative impact on our service. We are denying this request to prevent other Amazon SES customers from experiencing interruptions in service.
우리는 당신의 요청을 검토했고 당신이 아마존 SES를 사용하는 것이 우리 서비스에 부정적인 영향을 미칠 수 있다고 판단했습니다. 우리는 다른 아마존 SES 고객들이 서비스 중단을 경험하는 것을 막기 위해 이 요청을 거부합니다.
두 번째 요청,,, 을 보내려 했으나!
AWS SES랑은 크게 상관 없을듯하지만, HTTPS, AWS Load Balancer, private subnet 등 보안적으로 보완을 하는 작업을 거쳤다.
그리고 배포 직전까지는 잠시 AWS SES에 대해 잊고 다른 일에 몰두하는 방안을 택했다.
그러다가 5월 12일, 백엔드 API가 거의 마무리가 된 시점에 AWS SES 승인을 한 번 보내보려 했다.
그런데 SES 창에 샌드박스 해제 요청 버튼이 뜨지 않았다! 한 번 요청에 거절되면 다시는 승인을 못받는건가... 싶었다.
그렇기 때문에 AWS Support 에 가서 일반 요청으로 문의를 넣었다.
마침 4/25에 AWS 한국어 문의 지원이 가능하다는 기사도 떴었다.
https://aws.amazon.com/ko/blogs/korea/choose-korean-in-aws-support-as-your-preferred-language/
AWS Support – 한국어 고객 및 기술 지원 서비스 시작 | Amazon Web Services
오늘 부터 AWS Support에서 기존의 영어, 일본어 및 중국어 지원이외에 여러분의 선호하는 언어로 한국어로 된 고객 및 기술지원을 받을 수 있습니다. 한국어를 구사하는 고객의 수가 증가함에 따
aws.amazon.com
영어 울렁증이 있던 나에게 한국어 문의를 할 수 있다는 것은 너무나도 소중한 기회였다.
때문에 5월 12일 오후 4시에 부담없이 바로 문의를 넣었다.
이 날이 금요일이였기 때문에, 사실상 15일 월요일쯤에 답변이 오지 않을까 예상했다.
그러나 15일 저녁이 지나서도 답변이 오지 않았다.
5월 16일 아침 9~10시까지 기다려보고 연락이 오지 않으면 다시 문의를 해보자는 생각으로 기다렸지만, 여전히 연락이 오지 않았다.
때문에 회신 방법을 전화번호(SMS)로 변경한다고 문의를 넣었다.
그러자 바로 전화가 나한테 왔다.
국제전화로 오길래 영어로 답변해야되는줄 알고 엄청 걱정했다.
심지어 처음 기계음도 영어로 뭐라뭐라 한다. 그렇기 때문에 심호흡을 가다듬고 번역기를 킨 상태로 대기하고 있었다.
다행히 상담원이 처음 하시는 말씀은 `여보세요`였다!
휴~ 한국어로 통화할 수 있어서 정말 다행이었다.
AWS SES는 빠르게 처리될 수 있는 부분이 아니어서 조금 살펴봐야 한다고 하셨다. 또, SES 관련 부서는 해외에만 존재하기 때문에 조금 늦어질 수 있다는 말도 들었다.
통화를 마치고, 상태가 `작업 할당됨`이었나... 로 바뀌기 시작했다.
그리고 돌아온 답변은 AWS CLI로 요청을 넣어보라는 것이었다.
그렇기 때문에 AWS CLI를 mac에 설치하고 아래 명령어로 입력을 해보았다.
AWS CLI 샌드박스 나가기 요청
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
aws sesv2 put-account-details \
--production-access-enabled \
--mail-type TRANSACTIONAL \
--website-url {사이드 프로젝트 URL} \
--use-case-description "Email transmission is used for user authentication in the application's 'Find and Reissue Password' process.
The ability to send e-mail is essential because password reissuance must be processed after sufficient authentication has been completed.
For this reason, I would like to request the release of the sandbox.
Email will be sent when user requests to find password and reissue, so it will not be sent to email that is not saved in the member DB.
And the history will be able to be saved as logs.
This will include a statement asking you to turn off your refusal to receive mail, as this is the case when you send a mail request only when you need it.
Incoming mail addresses are collected with your consent.
When user returns mail, it is changed or deleted after the system administrator checks the reason for the return.
Users can deny and block emails at any time on the site where they are receiving them.
In the early stages of application deployment, many users can access it, and therefore more than 200 requests can be made per day.
I would like to request the lifting of the limit through the demand survey." \
--additional-contact-email-addresses kth990303@naver.com \
--contact-language EN
|
cs |
양식은 https://docs.aws.amazon.com/ko_kr/ses/latest/dg/request-production-access.html 를 참고했다.
Amazon SES 샌드박스 환경에서 나가기 - Amazon Simple Email Service
이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.
docs.aws.amazon.com
하지만 나를 반겨주는 것은 200 OK가 아닌 An error occurred (ConflictException) when calling the PutAccountDetails operation: None 에러였다.
그렇기 때문에 다시 문의를 넣었다.
... 과정 설명
하지만 An error occurred (ConflictException) when calling the PutAccountDetails operation: None 에러가 발생하며 요청에 실패했습니다. 구글링으로 원인을 파악해보다가 https://github.com/aws/aws-cli/issues/6652 동일 이슈를 발견하였는데요, 해당 이슈에서는 다른 region으로 샌드박스 제한 해제 요청을 하는 것을 확인했습니다.
다른 region으로 요청을 보내도 크게 문제가 없는지, CLI 요청 실패 이유는 무엇인지 궁금합니다.
만약 다른 region으로 샌드박스 제한 해제 요청을 해도 문제가 없다면 다른 region을 통해 요청하려 합니다.
추가로, CLI 요청 형식이 올바른지도 궁금합니다.
항상 감사합니다.
위와 같이 문의를 하고 나니, 아래와 같은 답변이 왔다.
AWS CLI로도 요청이 불가했기 때문에, 고객센터 측에서도 한 번 알아보겠다고 답변이 왔다.
다만, 위에서도 언급했다시피 SES는 관련 부서가 해외에 존재해서 처리가 좀 늦어질 수 있다는 문구가 포함됐었다.
그리고 하루가 지난 5월 19일, 드디어 답변이 왔다!
ConflictException에 놓인 상태였다고 한다.
4월에 요청을 보냈었던 사례랑 무언가 충돌이 발생했었던 모양이다.
혹시나 샌드박스 요청 해제 버튼이 보이지 않으면, AWS CLI로도 안될 확률이 높으니 맘편히 고객센터에 빠르게 문의하길 바란다.
아무튼 아래 정보를 포함해서 회신해달라는 답변이 왔다.
1) 이메일 종류 - Marketing 또는 Transactional
2) 웹사이트 URL
3) 사례 설명을 사용하여 Amazon SES를 사용하여 이메일을 보내는 방법을 설명합니다. 요청을 처리하는 데 도움이 되려면 다음 질문에 답해야 합니다
◦ 메일 송수신 리스트를 어떻게 관리합니까?
◦ 반송 및 불만사항을 어떻게 처리할 계획입니까?
◦ 수신자가 사용자로부터 전자 메일 수신을 거부하려면 어떻게 해야 합니까?
그렇기 때문에 나는 아래 내용을 번역해서 보냈다.
이메일 발급은 해당 애플리케이션의 `비밀번호 찾기 및 재발급` 프로세스 로직에서 사용됩니다. 충분한 인증이 완료된 후에 비밀번호 재발급을 처리해야 하므로 이메일 발송 기능은 필수적입니다. 이러한 이유로 sandbox 해제 요청을 희망합니다.
비밀번호 찾기 및 재발급 시에 이메일을 발송할 예정이므로 회원 DB에 저장된 이메일로는 발송되지 않으며, 발송 내역은 로그로 확인할 수 있게 할 예정입니다.
사용자가 필요한 경우에 한정하여 메일 요청을 보내는 경우에 해당되므로, 메일 수신 거부를 해제해달라고 요청하는 문구가 포함될 예정입니다. 수신 메일 주소는 사용자의 동의를 얻어 수집합니다.
반송 메일은 시스템 관리자가 반송 이유를 확인 후 변경 또는 삭제합니다. 사용자는 이메일을 받는 사이트에서 언제든지 수신 거부 및 차단을 할 수 있습니다.
애플리케이션 배포 초기에 사용자가 많이 접속할 수 있으며, 따라서 일일 200건을 넘는 요청이 올 수 있습니다. 수요 조사를 통하여 한도 해제 요청을 희망합니다.
요청 후, 주말이 지나고 5월 22일 월요일 오전에 아래와 같은 답변이 왔다.
AWS SES 담당 부서로 케이스가 이관된다고 한다.
이제 영어로만 대화해야 한다!
진짜로 두 번째 요청을 보내보자
그리고 약 30분 후...
이제 SES 관련 부서로 이관이 됐나보다.
아예 영어로 연락이 왔다.
영어로 aws SES를 써야하는 이유, 그리고 관리를 어떻게 할 것인지 추가로 정보를 보내달라는 요청이 왔다.
그리고 Sandbox 계정 탈출을 희망하는 region이 애매하다는 판단을 내렸는지, 원하는 region을 보내라고 연락이 왔다.
따라서 나는 아래 글을 번역해서 답변을 보냈다.
참고로 아래 요청을 보내고 난 이후 region 관련 설정 빼고는 최종적으로 승인이 난 요청이다. 그렇기 때문에 참고하기 좋도록 큰 글씨로 적도록 하겠다.
안녕하세요
Amazon SES는 애플리케이션에 회원가입한 유저가 비밀번호 분실 시에, 회원 인증을 위한 이메일 인증 시에 사용됩니다. 수신자의 메일 주소는 애플리케이션 회원가입 시에 유저의 동의를 반드시 얻은 이후에 진행되는 로직입니다. 이메일 인증 로직은 아래와 같습니다.
1. SES로 우리가 발급한 인증코드를 포함하여 메일을 전송합니다.
2. 유저가 인증 코드를 창에 입력하면 이메일 인증이 완료됩니다.
올바르지 않은 요청으로 Amazon SES를 사용하는 이메일 인증 API 호출을 방지하기 위해 우리 애플리케이션만의 nonce를 포함한 요청인지 검증하는 로직 또한 포함돼있습니다.
전자 메일을 보내는 빈도는 현재 일 5~10건 정도로 예상됩니다. 이는 일 평균 예상 접속자 중, 비밀번호를 분실하여 이메일 인증할 것으로 예상되는 유저 수를 고려하여 계산했습니다.
수신자 목록은 AWS RDS의 회원 DB, 그리고 Spring logback으로 남겨지는 애플리케이션 로그를 통해서 관리할 것입니다. 만약 부족할 경우 email 관련 Table을 따로 만들어서 관리할 예정입니다.
유저가 불만이 있을 경우, 유저 이용 사이트에서 언제든지 메일 수신 차단이 가능합니다. 또한, 유저는 애플리케이션에 언제든지 불편사항에 대한 코멘트를 남길 수 있습니다. 해당 코멘트를 바탕으로 이메일 수신 차단, 불만 요청에 대한 처리를 적극적으로 할 예정입니다.
SES sand box region을 옮겨야 한다면 ap-northeast-1 (Tokyo)로 옮기고 싶습니다.
감사합니다.
ap-northeast-1 (Tokyo)로 작성한 이유는 ap-northeast-2 (Seoul)이 지난 4월에 rejected가 돼서 사용이 불가능한 줄 알았기 때문이다.
안녕하세요.
답변을 제출해 주셔서 감사합니다.
당신의 답변에 따르면, 우리는 당신이 ap-northwest-2 (서울)와 ap-northwest-1 (도쿄) 중 어느 지역에서 생산 접근이 필요한지 확신할 수 없습니다.
요청 지역이 ap-northeast-1(도쿄)인 경우:
귀하가 아시아 태평양(도쿄) 지역에서 확인된 신원이 없기 때문에 현재로서는 귀하의 요청을 수락할 수 없습니다.
다행인지 불행인지, 한번에 승인이 안되고 region 정보를 제대로 보내달라는 답변이 왔다.
그렇기 때문에 나는 아래와 같이 보냈다.
요약하자면, 아래와 같다.
서울 region으로 하고 싶어요!!!
서울 region이 불가능한줄 알고 tokyo로 요청한 거였어요.
서울 Region으로 하고 싶어요!!!
거의 수미상관 구조(...)로 ap-northeast-2 (Seoul)을 희망한다고 강력하게 주장했다.
그렇게 주장한 결과, 다음날 5월 23일 낮 2시쯤!
안녕하세요.
발송 제한을 늘리기 위해 요청을 제출해 주셔서 감사합니다. 새 발송 할당량은 하루에 50,000개의 메시지입니다. 현재 최대 전송 속도는 초당 14개의 메시지입니다. 우리는 또한 당신의 계정을 아마존 SES 샌드박스 밖으로 옮겼습니다.
이는 아시아 태평양(서울) 지역에서 즉시 적용됩니다. Amazon SES 콘솔의 Send Statistics 페이지에서 또는 GetSendQuota API를 사용하여 계정의 현재 전송 속도와 전송 할당량을 볼 수 있습니다.
드디어! 약 한달만에 AWS SES 샌드박스 계정에서 탈출했다~~
드디어 일일 200건 제한도 풀리고, 자격 증명 확인되지 않은 모르는 이메일 주소로도 메일을 보낼 수 있게 되었다~~
생각보다 훨씬 힘든 여정(?)이었다.
aws SES sandbox 계정 탈출에 맘졸이는 사람들을 위해 포스팅을 작성해보았다.
아마 대부분의 사람들은 나보다는 적은 기간 내로 승인되지 않을까?ㅋㅋㅋ
아무쪼록 모두 잘 승인되길 바란다.
'Infra > Aws' 카테고리의 다른 글
| [Infra] nGrinder API 성능테스트 세팅 삽질 기록 (1) | 2024.03.13 |
|---|---|
| [RDS] (적은 트래픽에서) t3.micro ~ t3.xlarge 성능 직접 업그레이드하며 비교해보기 (0) | 2023.09.22 |
| [Infra] AWS SNS+Chatbot로 슬랙 알림받기(Feat. AWS Budgets) (0) | 2023.05.22 |
| [Infra] 와이어샤크로 tcpdump 파일 분석하여 AWS ALB idle timeout 설정하기 (4) | 2023.05.15 |
| [230504] AWS Summit Seoul 2023 후기 (17) | 2023.05.04 |