구글 앱스 스크립트를 쓰면 간단한 작업인데, 굳이 왜 AWS를 사용함에 따라 이슈를 발생시키는지 알 수 없다.

 

https://towardsdatascience.com/extract-email-attachment-using-aws-624614a2429b

 

상기 구조에 따르면 1번을 하기 위해 workmail 이라는 것을 사용해야 하는데, 이를 위해서는 Router 53으로 도메인을 연결하여 MX, TXT, CNAME 도 등록해 줘야 한다.

 

여기서 나는 workmail 대신 daum smartwork를 사용했기 때문에 그림과 같이 MX가 등록되었다.

 

workmail은 aws에서 등록한 도메인만 되는 것으로 알고 있는데, 도메인 이전 등으로 하려면 복잡할 것으로 생각된다.

 

일단 1단계 하는 것만 해도 엄청 힘들다.

 

Router 53 : 호스팅 영역 -> 호스팅영역 생성 -> 도메인 등록 -> 각 레코드 등록 (프리티어에서는 유료인 것  같다. 월 2000원 정도 예상)

 

 

다음으로 Simple Email Service를 등록해야 하는데, 아시아 서울에서는 잘 안되는 것 같고, 버지니아에 설정이 되었다.

도메인을 등록하고, 사용자를 등록하는 것도 꽤나 시간이 오래 걸린다.

 

도메인 영역에 TXT 레코드가 존재하므로 해당 값을 Router 53에 등록해 줘야 한다.

 

sandbox로 되어 있는 부분을 활성화하지 않아도 등록된 메일이 얼마 없다면 테스트하는데에는 문제가 없다.

 

이메일 주소 확인이 완료되면, 이메일 수신, 룰셋 부분이 활성화 되는데, S3에 적당한 버킷을 만들어 연결 시키면 이는 생각보다 간단하다.

 

SNS Topic 을 설정하라는 설명도 있는데, 안 하는 것이 잘 되는 것 같기도 하다.

 

3, 4에 있는 Lambda를 이용해 저장하기를 시도해 봤지만 이유는 알 수 없이 안되는 것 같다.

 

 

저장은 eml 인데 이를 확인하려면 다운로드 하여 eml 로 확장자를 바꾸고 메일 프로그램에서 열여봐야 한다.

 

해당 설정을 성공하면 성취감이 들긴 하지만 정신 건강상 구글의 앱스스크립트를 써서 구글 드라이브에 저장 하는 것이 훨씬 편하다.

 

[첨부 추출하기]

 

https://gist.github.com/sandeepmanchi/365bff15f2f395eeee45dd2d70e85e09

 

람다 함수를 사용하기 위해 github 소스를 이용했는데, s3 엑세스 권한을 만드는 부분이 더 어렵다.

 

IAM 에서 역할을 만들어서 하거나 권한을 추가 시켜야 하는데, 나는 기본 역할에 S3의 모든 권한과 리소스 엑세스 권한을 주는 것으로 해결했다.

 

버킷 리전이 달라서 안되는 것일지도 몰라서 리전도 동일하게 맞춘 것으로 코딩을 하니 동작하였다.

 

파이프라인 상의 3, 4번을 처리하는 것이 좀 더 고된 작업이었는데, 해결했다.

 

 

3번의 경우는 S3에서 이메일이 저장되는 버킷을 선택하고, 속성에서 이벤트 알림을 추가해 주면 된다.(이벤트 유형 : 전송, 게시)

 

이때 작성한 lambda는 역시 동일 리전에 있어야 사용 가능하다.

 

 

설명 자료에는 이런 세부적인 것들이 누락되어 있어 절차대로 하더라도 구현하기 힘들다.

 

람다 함수에서 구성 탭, 권한으로 가면 실행 역할에 자동 생성된 역할이 있는데 이를 선택하면 IAM으로 이동한다.

 

정리하다가 봤는데, 함수 개요에 트리거가 자동으로 생성된 것을 볼 수 있다. 이는 S3에서 이벤트 알림을 전송과 게시로 추가했기 때문인 것 같다.

 

 

 

여기서 인라인 정책을 추가하여 S3의 모든 리소스와 모든 엑세스를 허용 시켰다.

 

 

AWS 의 서비스 중 SES, IAM 에 대해 경험을 하였고, S3와 lambda를 연동하는 작업을 해볼 수 있었다.

 

S3, lambda 연동은 아주 많은 분야에 사용될 것으로 예상한다.