(작성 중...)

보통 메일 서버를 직접 구축하는 짓은 하지 말라고들 한다.
스팸/바이러스 메일을 걸러내는 작업, 내 메일이 스팸처리가 되지 않게 하기 위한 작업, 메일을 중단 없이 수신할 수 있도록 지원 등등...
물론 직접 구축하는 작업이 아무나 할 수 있는게 아니기도 하고.

그래서 개인 도메인을 이용한 메일을 사용하기 위해선 유/무료의 기업용 서비스를 이용하거나 메일건 같은 서비스를 이용한다.
무료는 거의 없어지는 추세에 다음 스마트워크나 메일건 정도 남아있지만 제약들이 좀 불편했고, 유료도 서비스 자체나 과금 정책 등도 마음에 안드는 구석들이 하나씩 있어서 어떻게 하면 좋을까 고민하던 중, 어느정도 손이 가지만 타협할만한 방법이 있는 것 같아서 사용 및 설정을 해보았다.

일반 메일 서버 구축을 하듯이 Postfix + Dovecot 을 설정하지만, 실제 외부와 통신은 AWS SES를 거쳐서 진행하는 방식으로 구성을 하였다.
참고로 이미 이런 형태로 제공하는 가이드 등이 존재하지만, 다양한 계정으로의 수신을 지원하지 않아서 그 부분 등을 고려하여 세팅을 진행하였다.

AWS SES

AWS Simple Email Service 라고, 메일의 송수신을 지원하는 서비스이다.
다만 일반적인 메일 서비스처럼 지원을 하는건 아니고 송/수신이 조금씩 다르다.

일반적인 메일 서비스처럼 바로 사용할 수 있는건 아니지만(그런 목적으론 유료의 AWS WorkMail이 있다)
송신 기준으로 메일 전송에 필요한 각종 서버 설정을 하지 않고 AWS의 신뢰도에 기댈 수 있고, 수신 기준으로도 AWS가 일단 안정적으로 받아주고 시작하는게 좋아보여서 사용하기로 하였다. (바이러스 검사나 스팸 체크도 해주지만 내가 후처리를 따로 해줘야 한다.)

사용 방식 / 비용

먼저 송신은 초당, 일당 전송 제한이 있으며
AWS API를 이용하여 전송(월 62,000건 무료 후 과금)을 하거나, AWS IAM 사용자를 이용한 SMTP로 전송이 가능하며,
1000건당 $0.1 및 용량 기준으로 GB당 $0.12 가 과급된다.

후자의 SMTP 방식을 이용하면 일반 메일 클라이언트에 등록해서 사용할 수 있긴 한데, IAM을 사용하기 때문에 사용자 아이디/비밀번호를 내가 설정할 수도 없고 권한 부여도 까다롭다.

수신은 정한 규칙에 따라 AWS 람다를 실행하거나, S3에 저장하거나, SNS 토픽을 발행하는 등의 방식으로 이루어진다.
이 또한 1000건당 $0.1 (1000건 무로) / 256KB 1 chunk 기준으로 chunk 1000건당 $0.09 과금된다.
작성일 기준으로 한국 리전은 수신을 지원하지 않아 us-east-1 에서 사용하였음.

AWS SES 설정

AWS 에서 메일 송신을 위해선
1. 도메인 혹은 메일 주소 인증
2. 도메인의 경우 DKIM 등 설정
3. 외부로 메일 전송을 위한 Sandbox 해제 요청
작업을 해야하고,

수신을 위해선 MX레코드 설정이 필요하다.
이런 부분은 다른 사람들이 쓴 글이나 AWS 가이드에도 설명이 잘 되어있으니 생략.

이 후 Rule set 설정, Lambda, S3, SNS 등 설정은 분량 관계상 별도 포스팅으로. (작성 후 링크 예정)

Postfix

SMTP 프로토콜을 이용하여 메일을 수발신 할때 사용하는 프로그램. MTA (Mail Transfer Agent) 의 한 종류이다.
예전엔 sendmail 이 사용되었으나 요즘엔 Postfix를 가장 많이 사용한다.

Postfix 기능들

이 프로그램이 하는 역할이 겉으로 보기엔 단순 메일 수발신이지만 자세히 보면 좀 다양하다. 적절히 필요한 것만 취하면 됨.

1. 서버 내에서 내/외부로 메일 전송시 처리
    -> 안 써서 필요없음

2. 외부 클라이언트에서 서버를 통하여 메일 전송 (SMTP Submission)
    -> AWS의 SMTP를 사용해도 되는데, 메일 주소(사용자)별 인증을 쓰고 싶어서 이용.

3. 외부 클라이언트로 전송할때 사용자 인증 / 메일 검증 등
    -> 인증은 Postfix 자체적으로 할 수 있게 설정도 가능한데, 후술할 Dovecot과 연결하여 Dovecot의 인증을 사용하는 방법도 가능하다. 다 따로 구현하면 관리가 번거로워지니 이 방법을 사용할 예정.

4. 내 도메인으로 전송된 메일을 수신
    -> 나의 경우 수신을 AWS가 해주기 때문에 불필요한 기능이지만, 발송 과정에서 Postfix를 사용하고 있고 내 도메인으로 전송하는 경우가 발생할 수 있기 때문에 적절한 설정을 해줘야한다. (예시로 a@naver.com 에서 b@naver.com 으로 메일을 보내는 경우.)
        기본적으론 서버 내 해당하는 경로에 메일 원문을 저장하게 되어 있지만, 난 Dovecot 으로 전송하도록 설정할 예정

5. 메일 수신시 사용자 존재 여부 확인 / alias (다른 주소로 수신하는 기능)
    -> 메일 수신자에 따라 실질적으로 어떤 계정이 해당 메일을 받을지 결정하는 기능..
        support@도메인 으로 전송하면 CS팀에 속한 직원이 모두 해당 메일을 받는다거나.. 하는 목적으로 사용된다.
        난 내 도메인으로 오는 전체 메일을 내가 사용할 한두개 계정으로 받기 위해 사용할건데, 메일 수신을 Postfix만 하는게 아니라서 Postfix 와 Lambda 양쪽에 동일하게 작동하도록 구성해주어야 한다.

6. 다른 서버가 전송하는 메일을 다른 서버로 릴레이
    -> 보안 상의 이유 등으로 보통 비활성화

Postfix 설정

분량 관계상 포스팅을 분리하여 작성 (작성 후 링크 예정)

Dovecot

메일 박스를 관리하며 POP3, IMAP 등 프로토콜을 지원하여 다른 프로그램에서 메일을 받아갈 수 있도록 지원한다.
SMTP Submission 기능도 지원하는 것 같긴 하던데, 어차피 Postfix도 필요할 것 같아서 사용하지 않았음.

MTA(Postfix)가 메일을 수신해서 폴더에 저장하면 Dovecot이 알아서 그걸 읽는 방법도 있고,
MTA가 다시 Dovecot으로 LDA(Local Delivery Agent)나 LMTP(SMTP 개량 프로토콜)를 통해 보내줄 수도 있다.
예전엔 LDA를 썼었는데 최근엔 설정 편의성과 성능 때문에 LMTP를 더 많이 쓴다고 한다.

나의 경우 역시 Postfix - LMTP -> Dovecot 로 설정을 하였고,
AWS SES에서 수신한 메일도 AWS SES -> S3 -> SNS -> Lambda - LMTP -> Dovecot 으로 구성을 하였다.
보통 Lambda에서 Dovecot의 메일박스로 파일을 바로 전송시키는 방법을 사용하는데, 이러면 폴더 구조 같은걸 내가 신경 써줘야해서 난 수신자/alias 구분만 Lambda에서 하고 LMTP로 Dovecot에 떠넘겼음.

Dovecot 설정

역시 분량 관계상 포스팅 분리하여 작성 (작성 후 링크 예정)

사용 포트 / TLS

Dovecot 에서 사용할 POP3 와 IMAP 은 TLS 암호화가 추가된 버전인 POP3S(995/tcp), IMAPS(993/tcp) 만 사용할 예정이다.
내부 메일 전달을 위한 LMTP는 Postfix만 쓸거면 unix socket으로 해도 되지만, Lambda에서 사용해야 하니 적당히 임의로 2525/tcp 포트도 추가로 사용.

사용자가 메일 전송을 위해 Postfix에 접속할 때는 SMTPS(tcp/465) 대신 SMTP + STARTTLS 을 사용할거고, 25/tcp 가 OUTBOUND로 차단되는 경우가 많기 때문에, 587/tcp 포트를 사용한다.

즉 587, 993, 995 3개 포트는 모두 열려있어야 하며, 2525 포트는 내부에서 사용할 수 있게만 열려있으면 된다.

TLS 연결을 위해 인증서를 발급받아야 하는데, Let's encrypt(certbot) 을 이용한 웹서버용 인증서를 그대로 사용할 수 있다.
이 인증서의 발급 방법은 생략.
발급된 경로만 잘 확인하여 후에 설정할 때 적절한 경로를 넣어주면 된다.

이 후 발급된 인증서를 Dovecot / Postfix 각각 설정에 적절히 넣어주면 된다.

전체 구성도

아직 시작도 안했지만 벌써부터 복잡한, 전체 구성도는 아래와 같다.

DB와 메일 서버는 동일 서버여도 되지만 난 분리되어 있기 때문에 이미지상 분리해뒀다.

이미지에서 볼 수 있다시피 Lambda가 DB와 EC2 서버에 각각 접근해야 하는데, DB는 당연하고 LMTP도 Public 오픈을 권장하지 않기 때문에 Lambda를 private subnet에 넣고 동일 VPC 네트워크 내에 사설망을 이용하도록 구성하였음.

나중에 사용자 인증을 LDAP 으로 사용한다거나.. 등도 고민 중인데..... 갈길이 멀다.....ㅠ

iDRAC 에 접속하면 Virtual Console 이라고,, 간단하게 말해서 원격으로 서버 콘솔에 접근할 수 있다.
일종의 원격제어...
서버가 죽어도 서버실에 갈 필요 없이 왠만한 복구는 다 할 수 있게 해주는 한줄기 빛같은 존재

Java Web Start 라고, 웹브라우저에서 바로 자바를 실행할 수 있게 만들어진 프레임워크를 사용하는데, 요즘에 보안때문에 그런게 될일은 당근 없고, 그냥 viewer.jnlp 파일이 다운받아지는걸 자바로 실행해주면 된다.

평소엔 쓸 일이 없으니 봉인해두다가, 오늘 쓸일이 있어서 열어봤는데

안된다...ㅠㅠㅠ

검색해보니 Java Web Start 가 Java 9에서 deprecated 되었고, Java 11에서 삭제되었다고 함.
웹에서 실행해줄 뿐이지 어쨋든 자바니까, 직접 실행할 수 있는 방법을 찾아봤다.

우선 jnlp 파일을 열어보면 연결에 필요한 인자값들과 OS와 아키텍쳐에 따른 java 파일 링크가 걸려있다.
avctKVM.jar 파일과 연결하려는 시스템에 맞는 lib 파일들을 받는다.

그리고 구버전 JRE를 구한다. 설치할 필요는 없으니 오라클 홈페이지에서 tar.gz 버전으로 다운로드 받으면 됨.
1.7.0_80 (7u80) 버전이 된다길래 난 이걸로 했음.
bin, lib 등이 있는 폴더를(Mac버전 기준 Home) jre 라는 이름으로 바꿔서 가져온다.

정리하면,
┣ avctKVM.jar
┣ lib/
┃    ┣avctKVMIOMac64.jar
┣    ┗avctVMAPI_DLLMac64.jar
┣ jre/
┃    ┣ bin/...
┗    ┗ lib/...
이런느낌의 디렉토리 구성이 되도록..

이 후 viewer.jnlp 파일의 인자를 참고하여 다음과 같이 명령어를 실행하면 된다.
- viewer.jnlp 에는 일회용 ID/PW가 있는데, 그걸 써도 되지만 원래 계정을 입력해도 접속이 잘 됨.
- 없어도 되는 인자도 있겠지만 난 그냥 다 넣어줌.
- vmprivilege는 참고한 글에서 넣어줬길래 그냥 넣어줌.

./jre/bin/java -cp avctKVM.jar \
	-Djava.library.path=./lib com.avocent.idrac.kvm.Main \
	ip=SERVER_HOST \
	vm=1 \
	user=USER_ID \
	passwd=USER_PW \
	kmport=9595 \
	vport=9595 \
	apcp=1 \
	reconnect=1 \
	chat=1 \
	F1=1 \
	custom=0 \
	scaling=15 \
	minwinheight=100 \
	minwinwidth=100 \
	videoborder=0 \
	version=2 \
	vmprivilege=true

아, java 를 인터넷에서 받았다고 실행을 안해줄텐데, 파인더에서 option+열기로 먼저 실행해주거나,,, 여러가지 방법으로 허용해주면 됨.
난 걍 개인 정보 보호 - 개발자 도구 옵션에서 터미널을 추가했음

이러면 원래 쓰던거처럼 연결이 잘 됨.
다만 맥 기준,
한번이라도 한글인 상태로 타이핑을 하면 키 입력이 이상하게 들어가서 재접속을 해야하고
macOS 보안 옵션 문제인지 전체 키스트로크를 받을 수 없다고 오류가 난다. 이건 설정에서 직접 허용해주면 될 것 같기도 함.

단점/불편한 점이 많아서 사용하지 않는 중.

기본 스토로지를 사용하되 s3에 백업하는 방식으로 구성이 더 나을 것 같다.

NextCloud 는 기본적으로 시스템의 디렉토리를 사용하지만,

추가로 External Storage Support 기능을 사용해서 FTP, S3 등등 외부 저장소를 마운트하여 사용할 수 있다.

처음엔 이렇게 연결하려고 했는데, 뭔가 안되어서 찾다보니, S3자체를 NextCloud의 주 저장소로 사용하는 방법이 있어서 그냥 그걸 사용해보기로 했음.

참고로 지금 하려는 주 저장소가 아니라 외부저장소로써 S3를 사용할 경우

(1) 사용자마다 S3 연결을 직접하지 못하고 관리자가 해줘야함

(2) 저장공간 사용 제약을 할 수 없음

(3) NextCloud의 공유 기능을 사용할 수 없음

요런 3가지 단점이 있다고 한다.

참고로 Amazon S3 뿐만 아니라 S3와 비슷한 object storage 류들도 사용이 가능하다고 함.

또한 S3와 연결된다고 해서 S3에서 직접 파일 브라우징을 할 순 없다고 한다. 파일 자체는 있지만 메타데이터가 없어서...

기존 설치된 NextCloud를 옮길 수도 없다. 새로 설치해야 됨.

nextcloud/config/config.php 파일 설정에

  'objectstore' => array(
    'class' => '\\OC\\Files\\ObjectStore\\S3',
    'arguments' => array(
      'bucket' => '버킷이름',
      'autocreate' => true,
      'key'    => 'IAM Access Key',
      'secret' => 'IAM Secret',
      'use_ssl' => true,
      'region' => 'AWS 리전, 서울이면 ap-northeast-2'
    ),
  ),

요 부분을 추가해두고 설치를 진행하면 된다.

이미 진행된 인스턴스가 있을 경우 nextcloud/data 폴더와 DB 테이블들을 날려버리고, config.php에 installed: true 라인 지우고, 마지막으로 config 폴더에 CAN_INSTALL 파일을 생성하고 접속하면 다시 설정부터 진행할 수 있다.

S3를 주 저장소로 할 경우 php의 파일 업로드 제한에 영향을 받지 않는 것 같다. 아마 S3 API 로 바로 업로드 시키는 듯?

참고: Configuring Object Storage as Primary Storage - https://docs.nextcloud.com/server/15/admin_manual/configuration_files/primary_storage.html

+ File lock 비활성화

NextCloud 는 공유된 파일을 2명 이상의 사용자가 동시에 편집해서 꼬이는 문제를 방지하기 위해 File locking 기능을 사용한다.

DB, 혹은 설정된 mem cache 에 lock 정보를 가지고 있고, 30분마다 cron이 지워주는 방식으로 작동한다는데, S3를 사용할 경우 끄는걸 권장한다는 듯? ( https://autoize.com/s3-compatible-storage-for-nextcloud/ )

일단 당장 내가 lock 으로 인한 문제를 발견해서(생성되고 파일을 빠르게 지울경우 뭔가 이상하게 lock 이 걸려서 파일 삭제가 안됨..) 그냥 꺼버렸음.

config.php에

  'filelocking.enabled' => false,

를 추가해주면 된다.

Docker로 설치해봤는데, docker 이미지는 web installer 방식이라 초기 설치시간이 오래걸리길래 그냥 네이티브로 깔았다.

참고로 아래 설치법은 일부 선택 옵션들을 포함하니 참고.

Installation on Linux — Nextcloud 여기 잘 설명되어 있으니 그냥 여길 봐도 된다. 좀 귀찮게 해서 그렇지...

1. apache2 + php7.4 설치

Ubuntu 18.04의 기본 php 는 7.0이다. 7.3 이상을 권장하니 7.4를 깔아주자

nginx도 못쓰는건 아닌데,, 왠지 apache2 가 기본값인 것 같아서 그냥 apache2 로 진행하였다.

sudo apt -y install software-properties-common
sudo add-apt-repository ppa:ondrej/php

sudo apt install apache2 libapache2-mod-php7.4 php7.4 php7.4-bcmath php7.4-bz2 \
    php7.4-curl php7.4-gd php7.4-gmp php7.4-intl php7.4-json php7.4-mbstring \
    php7.4-mysql php7.4-xml php7.4-zip libxml2

NextCloud 에서 imagic 모듈도 설치를 추천한다.

sudo apt install php-imagick

2. NextCloud 설치

php 기반의 프로그램이다. 웹사이트에서 받아서 적절한 위치에 압축을 풀어만 주면 됨.

https://nextcloud.com/install/#instructions-server

3. apache2 설정

/etc/apache2/site-available/cloud.conf (당연히 이름과 각종 경로는 알아서 수정..)

<VirtualHost *:80>
        ServerName 사이트주소

        DocumentRoot /var/www/nextcloud/
        <Directory /var/www/nextcloud/>
                Require all granted
                AllowOverride All
                Options FollowSymLinks MultiViews
        </Directory>

        LogLevel emerg
</VirtualHost>

apache2 에 필요/선택 모듈을 활성화해준다.

a2enmod rewrite headers env dir mime

4. php 설정

php 기본 설정은 업로드 용량이 2MB이므로, 조금 늘려준다.

메모리 제한값도 기본은 128MB이지만 추천은 512MB

sudo vi /etc/php/7.4/apache2/php.ini

memory_limit = 512M

post_max_size = 10G

upload_max_filesize = 10G

5. HTTPS 설정

이건 알아서 해주자.

0. 용어 정리

PKI (Public Key Infrastructure); 공개키 기반 구조

X.509: 공개키 인증서와 인증 알고리즘을 사용하기 위한 PKI 표준

PKCS (Public Key Cryptography Standards): Private Key를 저장하는 문법에 관한 표준
            PKCS#1, PKCS#8, PKCS#12 등을 사용

CRL (Certificate Revocation List), OCSP (Online Certificate Status Protocol): 인증서 유효성 점검을 위한 표준/방법

CA (Certificate Authority): 인증 기관

ASN.1 (Abstract Syntax Notation One): 추상 구문 기법, 네트웍상의 데이터 교환을 정의한 프로토콜

RSA (Rivest–Shamir–Adleman): 공개키 암호시스템의 하나

ECDSA (Elliptic Curve Digital Signature Algorithm): 타원곡선을 이용한 전자서명 알고리즘

0-2. 인코딩/파일 종류 정리

참고로 당연히 아래에 적는 확장자는 참고용으로 강제사항은 아님.
PEM 포맷의 개인키를 my.key.pem, my.key, key.pem 등등 저장하기 나름.

인코딩에 따른 구분

내용에 따른 구분

1. OpenSSL 명령어

* 기본 config 경로: /etc/pki/tls/openssl.cnf

1) Private Key 생성

openssl genrsa -out key.pem 2048

[옵션]

-des, -seed, -aes256, ...: 해당하는 방식으로 키 암호화. 미사용시 암호화 X

-passout pass:PASSWORD: 키를 암호화할 경우 암호 지정. 미사용시 입력 프롬프트가 뜸

-f4 (0x10001), -3: E value 지정. 기본값: -f4

1024, 2048, 3072, 4096, ...: Private Key Bit 크기. 아래 부록 참고

2) CSR 생성

openssl req -new -key key.pem -out my.csr

[옵션]

-md5, -sha1, -sha256, ...: 서명에 사용할 Digest. 기본값은 버전마다 다르고 적당히 sha256 사용.
            전체 목록은 openssl dgst -h

-subj: 인증서 주제 설정. 미사용시 입력 프롬프트 표시
    예시) -subj "/C=KR/O=sho/CN=SHO Certificate"

3) CSR로부터 인증서 생성

X.509 V3 확장 설정

Web TLS 인증서 (CA용) - ca.ext

basicConstraints = critical, CA:TRUE
#basicConstraints = critical, CA:TRUE, pathlen:0

subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
keyUsage = cRLSign, keyCertSign

Web TLS 인증서 (End-entity, 사이트용) - end.ext

basicConstraints = critical, CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:blog.iolate.kr, IP:1.1.1.1

CA 인증서 생성

openssl x509 -req -days 3650 -extfile ca.ext -signkey key.pem -in my.csr -out root.crt

[옵션]

-set_serial 1: 시리얼 값 지정. 미지정시 임의값 생성

-md5, -sha1, -sha256, ...: 서명에 사용할 Digest.
            전체 목록은 openssl dgst -h
            직접 신뢰 설정을 하는 Root CA 가 아니라면, sha256 사용. sha1 등 취약한 digest 사용시 브라우저에서 경고함

End-entity 인증서 생성

openssl x509 -req -days 365 -extfile end.ext -CA root.crt -CAcreateserial -CAkey my.key -in my.csr -out end.crt
openssl x509 -req -days 365 -extfile end.ext -CA root.crt -CAserial root.srl -CAkey my.key -in my.csr -out end.crt

[옵션]

-CAcreateserial: 시리얼 자동 지정 및 시리얼 파일 생성 (.srl)

-CAserial root.srl: CAcreateserial 로 한번 발급한 이후에는 이 옵션으로 시리얼 생성 파일 입력

-md5, -sha1, -sha256, ...: 서명에 사용할 Digest. sha256 사용. sha1 등 취약한 digest 사용시 브라우저에서 경고함

4) 생성된 파일 정보 확인

CSR / 인증서 / 개인키

openssl [req/x509/rsa] -noout -text -in [my.csr/end.crt/my.key]
openssl [req/x509/rsa] -noout -modulus -in [my.csr/end.crt/my.key] | openssl md5

2. 부록

Private Key 비트 크기

출처: https://en.wikipedia.org/wiki/Key_size

(대략적 요약)

* 128bit AES가 충분한 보안 수준으로 고려되었지만, 양자 컴퓨터의 등장 후 비밀 문서에 256bit 사용 권고

* 1024bit RSA와 80bit 대칭키 /
   2048bit RSA와 112bit 대칭키 / 
   3072bit RSA와 128bit 대칭키 /
   15360bit RSA와 256bit 대칭키  가 서로 보안 수준이 비슷하다고 판단됨.

* 1024bit RSA는 2006~2010년에 취약해짐.
   2048bit RSA는 2030년까지 유효할 것으로 판단.
   2030년 이후에는 3072bit 사용 권고

3. 참고

Wikipedia, OpenSSL 문서, 등등...

(그때그때 정리해둔 문서를 다시 정리한거라 참고 URL이 없음..ㅠ)

cloud9 을 사용하거나,, 뭐 여튼 필요할떄만 쓰는 aws 인스턴스의 경우엔 ip 주소를 매번 확인해줘야하는 번거로움이 추가된다.
따라서 부팅시에 Route 53 A레코드를 변경해주는 스크립트를 작성해보았음.

IAM 권한도 적절히 필요하겠지만, 난 cloud9 instance를 사용해서인지, aws가 알아서 credential 을 관리해줘서 생략.
필요하다면 아래 참고 글 링크를 확인해보자.

아래 파이썬 스크립트를 적절한 곳에 만들어 주고, 상단 변수 역시 설정해준다. 난 ~/route53/update.py 라고 만들었음.
특정 인스턴스의 public ip 를 구해온 다음, 지정한 url의 A레코드 값을 변경(없으면 생성)해주는 코드이다.
호스팅 영역 ID는 Route 53 에서 해당 도메인 이름(ex.com)을 선택하면 볼 수 있고, URL 은 호스팅 영역 내에서 생성하는 서브도메인을 포함한 이름(abc.ex.com)의 형태를 입력해주자.

INSTANCE_REGION="ap-southeast-1"
INSTANCE_ID="i-~~~~~~~~~~"
DOMAIN_ZONE="호스팅 영역 ID (ZGWP~~~~~~)"
URL="사용할 도메인 (abc.ex.com)"

import boto3

client_ec2 = boto3.client('ec2', region_name=INSTANCE_REGION)
r = client_ec2.describe_instances(InstanceIds=[INSTANCE_ID])

ip = r['Reservations'][0]['Instances'][0]['PublicIpAddress']

client_route53 = boto3.client('route53')
client_route53.change_resource_record_sets(
    HostedZoneId=DOMAIN_ZONE,
    ChangeBatch={'Changes': [{
        'Action': 'UPSERT',
        'ResourceRecordSet': {
            'Name': URL,
            'Type': 'A',
            'TTL': 300,
            'ResourceRecords': [{'Value': ip}]
        }
    }]}
)

그 다음 이 스크립트를 부팅시 실행되도록 설정한다. 여러가지 방법이 있지만 난 crontab을 이용하였음.

crontab -e

@reboot sleep 30 && /usr/bin/python3 /home/ec2-user/route53/update.py

경로 등은 알아서 수정해주자.
난 혹시 몰라서 30초 딜레이를 줬는데 안줘도 될 수도.

1번 테스트 해봤는데 일단 잘 된다. ㅎㅎ

참고
Auto-Register EC2 Instance in AWS Route 53