Amazon Linux AMI FAQ

Q: Amazon Linux AMI란 무엇인가요?

Amazon Linux AMI는 Amazon Elastic Compute Cloud(Amazon EC2)에서 사용할 수 있도록 Amazon Web Services가 지원하고 관리하는 Linux 이미지입니다. Amazon EC2에서 실행되는 애플리케이션에 안정적이고 안전한 고성능 실행 환경을 제공할 수 있도록 설계되었습니다. 또한 시작 구성 도구와 일반적으로 사용되는 여러 AWS 라이브러리 및 도구 등 AWS와 손쉽게 통합할 수 있는 패키지를 포함합니다. Amazon Web Services는 Amazon Linux AMI를 실행하는 모든 인스턴스에 지속적인 보안 및 유지관리 업데이트를 제공합니다. Amazon Linux AMI는 Amazon EC2 사용자에게 무료로 제공됩니다.

Q: Amazon은 Amazon Linux AMI에 대한 지원을 제공합니까?

예. Amazon Linux AMI는 AWS Support에 가입한 경우에 지원됩니다. 자세한 내용은 AWS Support 페이지에서 확인할 수 있습니다.

Q: Amazon Linux AMI의 지원 기간은 어떻게 되나요?

Amazon Linux AMI(Amazon Linux 1이라고도 함)는 2023년 12월 31일에 수명 종료에 도달했습니다. 2024년 1월 1일부터 Amazon Linux AMI는 보안 업데이트나 버그 수정을 수신하지 않습니다.

Q: 유지 관리 지원은 표준 지원 기간과 어떻게 다른가요?

유지 관리 지원은 Amazon Linux AMI의 표준 지원이 종료된 이후의 기간을 기준으로 합니다. 유지 관리 지원은 2020년 12월 31일에서 2023년 12월 31일까지로 연장되었습니다. 이 기간 동안 AWS는 더 이상 새 EC2 인스턴스 유형, 새 AWS 서비스 및 기능, 새 패키지에 대한 지원을 추가하지 않습니다. 대신 AWS는 감소된 패키지 세트에 적용되는 중요 보안 수정에 대한 업데이트만 제공합니다. 추가적으로 AMI 및 해당 리포지토리의 일부 패키지는 업스트림 기간 종료 사례에 따라 유지 관리 지원 기간 동안 천천히 사용이 종료됩니다.

Q: 유지 관리 지원 기간 동안 중요 보안 패치가 제공되는 패키지 목록은 무엇입니까?

AWS는 더 이상 사용되지 않는 사용자 공간 패키지를 제외한 모든 업데이트뿐만 아니라 AMI의 Linux 커널에 대한 중요 보안 업데이트까지 제공합니다.

Q: ‘유지 관리 지원’ 기간 동안 더 이상 업데이트가 제공되지 않는 패키지는 무엇입니까?

유지 관리 기간에 하위 수준 사용자 공간 라이브러리 외부의 업스트림 소스에서 사용 기간이 종료된 모든 패키지에는 더 이상 업데이트가 제공되지 않습니다.

다음 패키지는 원래 2018.03 릴리스에서 더 이상 사용되지 않으며, 유지 관리 지원 기간에 추가 업데이트를 받지 않습니다.

MySQL 5.1
PHP 5.3
PHP 5.4
PHP 5.5
PHP 7.0
PostgreSQL 8
Python 2.6
Ruby 1.8
Ruby 1.9
Ruby 2.1
Ruby 2.2

또한, 다음 패키지도 유지 관리 기간에 추가 업데이트를 받지 않으며, 지원이 종료됩니다.

모든 호환 패키지
BZR - (bzr-python26 및 bzr-python27 패키지)
Ganglia
Mercurial
MySQL 5.5
Python 3.4(python34)
Python 3.5(python35)
PostgreSQL 9.3(postgresql93)
PHP 7.1
PHP 7.2
Tomcat 7
Tomcat 8
Ruby 2.3
Ruby 2.4
PostgreSQL 9.4
Puppet 2.7.x(puppet)
Puppet 3.7.x(puppet3)
하위 버전 1.9
전송
OpenJDK 1.7.0(java-1.7.0-openjdk)

또한, 이외의 일부 패키지는 유지 관리 기간에 때때로 업데이트 수신이 중지됩니다.

RPM 종속성의 특징과 이러한 최상위 수준 패키지 중 하나가 여러 RPM으로 구성되는 방식에 따라 Amazon Linux 1에 있는 모든 RPM 패키지의 전체 목록과 지원 종료 날짜는 여기에서 확인할 수 있습니다.

Q: 유지 관리 지원 기간이 종료된 후 Amazon Linux AMI를 실행할 수 있나요?

예. 해당 정책이 변경되는 경우 미리 알려 드리겠습니다.

Q: Amazon Linux AMI는 EC2 외부에서 지원됩니까?

아니요. Amazon Linux AMI는 Amazon EC2 내에서만 사용할 수 있습니다.

Q: Amazon Linux AMI에서 소스 코드를 확인할 수 있습니까?

예. Amazon Linux AMI에서 제공되는 소스 명령줄 도구인 yumdownloader를 사용하면 Amazon EC2 내의 소스 코드를 볼 수 있습니다.

Q: Amazon Linux AMI 업데이트는 어디에서 가져올 수 있습니까?

업데이트는 각 Amazon EC2 리전에 호스팅된 미리 구성된 yum 리포지토리를 통해 제공됩니다. 보안 업데이트는 AMI를 처음 부팅할 때 자동으로 적용됩니다. 로그인하면 오늘의 메시지(/etc/motd)가 추가 업데이트 가용 여부를 표시합니다.

Q: 버그를 보고하거나 기능 및 패키지를 요청하려면 어떻게 해야 합니까?

Amazon EC2 토론 포럼을 통해 버그를 보고하고 기능 및 패키지를 요청할 수 있습니다. 이 포럼은 Amazon Linux AMI 엔지니어링 팀뿐 아니라 AWS Developer Support를 통해서도 모니터링됩니다.
 

Q: EPEL(Extra Packages for Enterprise Linux) 리포지토리를 활성화하려면 어떻게 해야 합니까?

/etc/yum.repos.d/epel.repo를 수정합니다. [epel] 표시가 된 섹션 아래에서 enabled=0을 enabled=1로 변경합니다.

EPEL 6 리포지토리를 일시적으로 활성화하려면 yum 명령줄 옵션인 --enablerepo=epel을 사용하십시오.

Amazon Linux AMI 리포지토리는 다른 타사 리포지토리보다 높은 우선순위로 구성된다는 점에 유의하십시오. 이는 Amazon Linux AMI의 일부인 패키지 여러 개가 타사 리포지토리에도 존재하므로, Amazon Linux AMI 버전이 기본 사례에 설치되도록 하기 위해서입니다.

Q: AMI를 특정 버전으로 고정하려면 어떻게 해야 합니까?

Amazon Linux AMI 리포지토리 구조는 사용자가 그 다음 버전의 Amazon Linux AMI로 단계적으로 진행할 수 있도록 지속적인 업데이트 흐름을 제공하도록 구성되었습니다.

패키지 업데이트는 항상 리포지토리로 푸시되며 yum이 "latest"를 가리키도록 구성된 모든 Amazon Linux AMI 버전에서 사용할 수 있습니다. 인스턴스가 가리키는 리포지토리를 확인하려면 /etc/yum.conf에서 "releasever" 변수를 살펴보면 됩니다. 기본적으로, Amazon Linux AMI는 releasever=latest로 설정되어 있습니다.

즉, AMI Linux AMI는 지정 시간 스냅샷처럼 처리됩니다. 리포지토리와 업데이트 구조를 갖추고 있어 Amazon에서 구축한 최신 패키지가 해당 리포지토리로 푸시되어 항상 최신 상태를 유지하게 됩니다.

AWS에서 새로운 Amazon Linux AMI 주 버전을 출시할 때 패키지 업데이트를 하길 원하지 않는 경우, "lock on launch" 기능을 사용하면 간편하게 AMI를 특정 주 버전으로 유지할 수 있습니다.

이 기능을 새 인스턴스에서 활성화하려면, EC2 콘솔 또는 --user-data 플래그가 있는 aws ec2 run-instances(ec2-run-instances -f를 사용해도 마찬가지임)를 통해 cloud-init에 다음과 같은 사용자 데이터가 전달된 2015.09 Amazon Linux AMI를 시작합니다.
#cloud-config
repo_releasever: 2015.09

기존 인스턴스를 현재 버전에 고정하려면(/etc/system-release에 표시되어 있음), /etc/yum.conf를 편집합니다. releasever=latest를 읽는 라인을 코멘트 아웃하고 yum clean all을 실행하여 캐시를 지웁니다.

참고: "최신" 버전이 아닌 리포지토리에 AMI를 고정하면, 추가 업데이트가 수신되지 않습니다. Amazon Linux AMI 업데이트를 지속적으로 수신할 수 있는 유일한 방법은 최신 AMI를 사용하거나 이전 AMI를 계속해서 업데이트하여 리포지토리가 "최신"을 가리키게 하는 것입니다.

Q: 초기 시작 시 필수 및 중요 보안 업데이트의 자동 설치를 비활성화하려면 어떻게 해야 합니까?

첫 번째 부팅 시 Amazon Linux AMI는 패키지 리포지토리에 있는 필수 또는 중요 등급으로 지정된 보안 업데이트를 사용자 공간에 설치합니다. 이 설치는 SSH와 같은 서비스가 시작되기 전에 완료됩니다.

AMI가 yum 리포지토리에 액세스할 수 없는 경우 제한 시간 초과가 발생하며 부팅 절차를 완료하기 전에 여러 번 다시 액세스를 시도합니다. 이러한 일이 발생하는 잠재적인 이유는 제한적인 방화벽 설정 또는 VPC 설정으로 인해 Amazon Linux AMI 패키지 리포지토리로의 액세스가 방해를 받기 때문입니다.

이 문제가 발생하는 경우 Amazon Linux AMI가 해당 패키지 리포지토리에 연결할 수 있도록 환경을 변경하거나 부팅 시 보안 업데이트를 비활성화할 수 있습니다.

AWS EC2 콘솔에서 부팅 시 보안 업데이트 비활성화

Request Instances Wizard의 "Advanced Instance Options" 페이지를 보면 Amazon Linux AMI 사용자 데이터를 전송하는 텍스트 필드가 있습니다. 이 데이터는 텍스트로 입력하거나 파일로 업로드할 수 있습니다. 어느 경우든 데이터는 다음과 같아야 합니다.
#cloud-config
repo_upgrade: none

명령줄에서 부팅 시 보안 업데이트를 비활성화하려면,

위의 사용자 데이터로 텍스트 파일을 생성하고, 이를 aws ec2 run-instances with the --user-data file://<filename> 플래그로 전달합니다(ec2-run-instances -f도 사용할 수 있음).

Amazon Linux AMI를 다시 번들링할 때 부팅 시 보안 업데이트를 비활성화하려면 다음과 같이 하십시오.

/etc/cloud/cloud.cfg를 수정하고 repo_upgrade: security를 repo_upgrade: none으로 변경합니다.

Q: Virtual Private Cloud(VPC)에서 인터넷 게이트웨이 또는 NAT 인스턴스 없이 SSH를 실행하면 시간이 오래 걸리는 이유는 무엇입니까?

이전 질문의 답변을 참조해 주십시오.

Q: 왜 RAID 배열이 /dev/md127이 아닌 /dev/md0에서 시작합니까?

mdadm의 새 버전은 버전 1.2 슈퍼블록과 함께 RAID 어레이를 생성하며 번호가 지정된 디바이스와 자동으로 어셈블하지 않습니다. 파일 시스템에 대한 레이블을 설정하여 파티션을 참조합니다. 대부분의 파일 시스템 생성 도구는 -L 플래그를 사용하여 레이블을 설정합니다. 일단 설정되면, 해당 레이블은 마운트에 의해 참조되거나 /etc/fstab의 LABEL=[NAME]으로 참조됩니다.

예: 레이블이 있는 RAID0 어레이 생성
mdadm --create --verbose /dev/md0 --level=0 --name=0 --raid-devices=2 /dev/sdb /dev/sdc
mkfs.ext4 -L RAID0 /dev/md0
mkdir -p /mnt/RAID0
mount LABEL=RAID0 /mnt/RAID0
예: 기존 ext[2-4] 파일 시스템의 레이블 설정
e2label /dev/md127 RAID
mkdir -p /mnt/RAID
mount LABEL=RAID /mnt/RAID

Q: wheel 그룹이 /etc/sudoers에서 비활성화되는 이유는 무엇이며 이를 다시 활성화하려면 어떻게 해야 합니까?

Linux 운영 체제는 wheel이 sudo에 대해 활성화되었는지에 따라 기본값이 다르게 되어 있습니다. Amazon은 기본적으로 sudo에서 wheel이 비활성화되어 있는 편이 Amazon Linux AMI의 보안을 유지하는 데 더 적합하다고 생각합니다.

이 문제에 대한 해결책은 2가지가 있습니다. 이러한 해결책은 SSH를 기본 ec2-user로 인스턴스에 지정할 수 있는지와 사용자의 sudo 사용 가능 여부를 변경했는지에 따라 달라집니다.

옵션 1: 기본값을 변경하지 않은 사용자의 경우 SSH를 인스턴스 내에서 ec2-user로 지정할 수 있어야 합니다. 그런 다음 루트를 얻기 위해 sudo를 호출하면, wheel을 다시 활성화하기 위해 sudoer 파일을 변경할 수 있습니다.
옵션 2: 기본값을 변경한 사용자 또는 ec2-user에서 루트로 sudo를 호출할 수 없는 경우 다음 단계를 따르는 것이 좋습니다.

• 영향을 받는 인스턴스를 중단합니다. 종료하지는 마십시오.
• EC2 콘솔 또는 EC2 API 도구를 사용하여 루트 EBS 볼륨을 분리합니다.
• 해당 볼륨을 원격 루트 액세스 권한이 있는 다른 EC2 인스턴스에 연결합니다.
• 해당 인스턴스에 로그인합니다.
• 새로 연결된 볼륨을 탑재합니다.
  sudo mount /dev/xvdf /mnt
• 연결된 볼륨에 있는 sudoer 파일을 변경하고 wheel 그룹의 주석 처리를 제거하십시오.
  sudo sed -i.bak 's,# \(%wheel\s\+ALL=(ALL)\s\+ALL\),\1,' /mnt/etc/sudoers
• 볼륨 탑재를 해제합니다.
  sudo umount -d /dev/xvdf
• 볼륨을 분리합니다.
• 중단된 인스턴스에 볼륨을 다시 연결합니다(해당 디바이스가 분리 전과 동일한지 확인, 일반적으로 /dev/sda1).
• 영향을 받은 인스턴스를 시작합니다.

Q: 터미널을 통해 Amazon Linux AMI와 통신할 때 왜 � 또는 â 같은 이상한 기호가 보입니까?

Amazon Linux AMI는 UTF-8 문자 인코딩을 기본으로 사용합니다. UTF-8 인코딩을 사용하지 않는 클라이언트 터미널은 UTF-8 문자를 항상 올바르게 번역하지 않습니다. 이를 바로 잡으려면 다음과 같이 클라이언트 터미널 인코딩을 UTF-8로 설정합니다.

• Gnome Terminal: 터미널 메뉴에서 Set Character Encoding을 선택하고 UTF-8을 선택합니다.
• PuTTY: 제목 표시줄의 오른쪽을 클릭하여 메뉴를 가져옵니다. 그런 다음 Change Settings를 선택합니다. Window → Translation → Remote Character Set에서 UTF-8을 선택합니다.

Q: /etc/yum.repos.d/amzn*.repo에 report_instanceid라는 옵션이 있습니다. 이것은 무엇을 합니까?

Amazon Linux AMI 리포지토리는 각 리전의 S3 버킷입니다. 인스턴스의 yum 프로세스가 이러한 버킷에서 패키지를 다운로드할 때 해당 S3 연결에 대한 정보가 로깅됩니다.
Amazon Linux AMI의 경우, report_instanceid=yes 설정은 Amazon Linux AMI 리포지토리가 패키지를 다운로드하는 인스턴스의 인스턴스 ID(i-xxxxxxxx)와 리전(예: us-west-2)을 로깅하도록 허용합니다. 이로써 Amazon Linux AMI 팀은 개별 인스턴스에 대해 더욱 집중된 고객 중심 지원을 할 수 있습니다.
report_instanceid=yes는 Amazon Linux AMI 리포지토리에만 기본적으로 활성화됩니다.

Q: 시스템 릴리스 패키지가 업그레이드될 때 /etc/yum.repos.d/amzn*.repo yum 리포지토리 구성 파일이 덮어쓰여지는 이유는 무엇입니까?

시스템 릴리스 패키지가 업그레이드되면 인스턴스가 항상 Amazon Linux AMI yum 리포지토리 구성에 대한 변경 사항을 확인할 수 있도록 리포지토리 구성 파일이 덮어 쓰입니다.
Amazon Linux AMI 2014.09 미만 버전의 경우:
이러한 파일은 cloud-init에서 /etc/cloud/templates/amzn-*.repo.tmpl에 있는 템플릿을 사용해 생성합니다. 이 템플릿 파일에 대한 변경 사항은 유지됩니다.

Amazon Linux AMI 2014.09 이상 버전의 경우:

인스턴스가 지리적으로 가장 가까운 리포지토리에 도달할 수 있도록 /etc/yum.repos.d/amzn*.repo 파일에서 yum 변수를 사용하며 cloud-init 템플릿을 더 이상 사용하지 않습니다. 이러한 파일의 수정 내용은 시스템 릴리스가 업그레이드될 때 /etc/yum.repos.d/amzn*.repo.rpmsave로 보존됩니다.

2014.09로 업그레이드하는 사용자는 /etc/yum.repos.d/amzn*.repo.rpmsave로 저장된 /etc/yum.repos.d/amzn*.repo 파일의 편집 내용을 모두 확인할 수 있습니다.

Q: 맨 페이지 색상을 변경하거나 끄는 방법은 무엇입니까?

맨 페이지 색상은 /etc/profile.d/less.sh(bash 및 zsh)와 /etc/profile.d/less.csh(csh)에서 구성됩니다. 색상을 끄려면 export export LESS_(bash, zsh) 및/또는 setenv LESS_(csh)로 시작하는 모든 줄을 제거하십시오.

Q: 2015.09 이전 인스턴스에서 시스템 호출 감사를 비활성화하려면 어떻게 해야 합니까?

시스템 호출 감사는 새로 출시되는 2015.09 Amazon Linux AMI에서 기본적으로 비활성화되어 있습니다. 시스템 호출 감사는 모든 시스템 호출에 대해 오버헤드를 추가하며 디스크 또는 네트워크 중심의 애플리케이션 등에서 성능을 눈에 띄게 저하시킬 수 있습니다.

시스템 호출 감사가 필요한 경우 /etc/audit/audit.rules에서 다음 줄을 찾아 제거하거나 주석을 단 후 감사 데몬을 다시 시작합니다.
-a never,task
예(루트 권한):
# auditctl -l
LIST_RULES: task,never
# sed -i.bak -e '/^-a never,task$/ s/^/#/' /etc/audit/audit.rules
# service auditd restart
# auditctl -l
No rules
2015.09 이전 AMI에서 시작된 인스턴스 관련 성능 개선 사항을 활용하려면 동일한 줄(-a never,task)을 /etc/audit/audit.rules에 추가하고 데몬을 다시 시작합니다. 업그레이드 중이고 감사 규칙 파일을 변경하지 않은 경우 새 규칙 파일을 /etc/audit/audit.rules로 이동하거나 복사하기만 하면 됩니다.
예(루트 권한)
# auditctl -l
No rules
# cp -p /etc/audit/rules.d/audit.rules.default /etc/audit/audit.rules
cp: overwrite ‘/etc/audit/audit.rules’? y
# service auditd restart
# auditctl -l
LIST_RULES: task,never

Q: mime 멀티파트 사용자 데이터를 cloud-init와 함께 사용하는 예를 알려 주실 수 있습니까?

cloud-init용 mime 멀티파트 관련 설명서는 여기서 확인할 수 있습니다.
MIME 멀티파트는 까다로운 형식일 수 있으므로 write-mime-multipart 도구를 사용하여 멀티파트 파일을 생성하는 것이 좋습니다. 이 도구는 cloud-utils 패키지에 들어 있으며 sudo yum install /usr/bin/write-mime-multipart와 함께 설치할 수 있습니다. 이 도구에서는 파일의 첫 줄을 사용하여 Content-Type을 결정하고 cloud-init는 Content-Type을 사용하여 파일을 해석하는 방식을 결정합니다. 일부 파일의 예는 다음과 같습니다.
#cloud-config
repo_releasever: 2015.09
및
#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt
다음은 출력을 포함한 write-mime-multipart의 예입니다.
[ec2-user@ip-172-31-4-37 ~]$ write-mime-multipart repo_releasever-2015.09.cfg ci-was-here.sh
Content-Type: multipart/mixed; boundary="===============6347220379374809187=="
MIME-Version: 1.0
--===============6347220379374809187==
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="repo_releasever-2015.09.cfg"
#cloud-config
repo_releasever: 2015.09
--===============6347220379374809187==
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="ci-was-here.sh"
#!/bin/bash
echo "cloud-init was here..." >> /tmp/cloud-init-was-here.txt
--===============6347220379374809187==--
이 도구를 사용하는 방법에 대한 자세한 내용은 man write-mime-multipart를 통해 확인할 수 있습니다.

Q: Amazon Linux AMI 리포지토리로 연결되도록 VPC 종단점을 구성하려면 어떻게 해야 합니까?

인터넷에 액세스하지 않고 VPC 내에서 yum 리포지토리에 액세스할 수 있습니다. VPC 종단점 정책이 VPC에서 Amazon Linux AMI 리포리토리를 호스팅하는 S3 버킷으로의 트래픽을 허용해야 합니다.
이를 구현할 수 있는 VPC 종단점 정책의 예는 다음과 같습니다.
{
"Statement": [
{
"Sid": "Amazon Linux AMI Repository Access",
"Principal": "*",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::packages.*.amazonaws.com/*",
"arn:aws:s3:::repo.*.amazonaws.com/*"
]
}
]
}
자세한 내용은 VPC 종단점 설명서를 참조하십시오.