기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon EC2의 AL2 Amazon EC2
**참고**
AL2는 더 이상 Amazon Linux의 최신 버전이 아닙니다. AL2023은 AL2의 후속 버전입니다. 자세한 내용은 [AL2023 사용 설명서의 AL2와 AL2023 비교](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) [AL2023 ](https://docs.aws.amazon.com/linux/al2023/ug/) [및 AL2023의 패키지 변경 AL2023](https://docs.aws.amazon.com/linux/al2023/release-notes/compare-packages.html) 사항 목록을 참조하세요.
**Topics**
+ [AL2 AMI를 사용하여 Amazon EC2 인스턴스 시작 AL2](#launch-ec2-instance)
+ [Systems Manager를 사용하여 최신 AL2 AMI 찾기](#find-latest-al2-using-systems-manager)
+ [Amazon EC2 인스턴스에 연결](#connect-to-amazon-linux-limits-ec2)
+ [AL2 AMI 부팅 모드](#default-boot-mode-al2)
+ [패키지 리포지토리](#package-repository)
+ [AL2에서 cloud-init 사용](amazon-linux-cloud-init.md)
+ [AL2 인스턴스 구성](configure-ec2-instance.md)
+ [사용자 제공 커널](UserProvidedKernels.md)
+ [AL2 AMI 릴리스 알림](linux-ami-notifications.md)
+ [AL2 MATE 데스크톱 연결 구성](amazon-linux-ami-mate.md)
+ [AL2 자습서](al2-tutorials.md)
## AL2 AMI를 사용하여 Amazon EC2 인스턴스 시작 AL2
AL2 AMI를 사용하여 Amazon EC2 인스턴스를 시작할 수 있습니다. AL2 자세한 내용은 [1단계: 인스턴스 시작을](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance) 참조하세요.
## Systems Manager를 사용하여 최신 AL2 AMI 찾기
Amazon EC2는 인스턴스를 시작할 때 사용할 수 AWS 있는에서 유지 관리하는 AWS Systems Manager 퍼블릭 AMIs에 대한 퍼블릭 파라미터를 제공합니다. 예를 들어 EC2-provided 파라미터`/aws/service/ami-amazon-linux-latest/amzn2-ami-kernel-default-hvm-x86_64-gp2`는 모든 리전에서 사용할 수 있으며 항상 지정된 리전에서 AL2 AMI의 최신 버전을 가리킵니다.
를 사용하여 최신 AL2023 AMI를 찾으려면 AL2023 시작하기를 AWS Systems Manager참조하세요. [ AL2023](https://docs.aws.amazon.com/linux/al2023/ug/get-started.html)
Amazon EC2 AMI 퍼블릭 파라미터는 다음 경로에서 사용할 수 있습니다.
`/aws/service/ami-amazon-linux-latest`
다음 AWS CLI 명령을 실행하여 현재 AWS 리전의 모든 Amazon Linux AMIs 목록을 볼 수 있습니다.
```
aws ssm get-parameters-by-path --path /aws/service/ami-amazon-linux-latest --query "Parameters[].Name"
```
**퍼블릭 파라미터를 사용하여 인스턴스를 시작하려면**
다음 예제에서는 EC2-provided 퍼블릭 파라미터를 사용하여 최신 AL2 AMI를 사용하여 `m5.xlarge` 인스턴스를 시작합니다.
명령에서 파라미터를 지정하려면 `resolve:ssm:public-parameter` 구문을 사용합니다. 여기서 `resolve:ssm`은 표준 접두사이고 `public-parameter`는 퍼블릭 파라미터의 경로와 이름입니다.
이 예에는 `--count` 및 `--security-group` 파라미터가 포함되어 있지 않습니다. `--count`의 기본값은 1입니다. 기본 VPC와 기본 보안 그룹이 있는 경우 이들이 사용됩니다.
```
aws ec2 run-instances
--image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/amzn2-ami-kernel-default-hvm-x86_64-gp2
--instance-type m5.xlarge
--key-name MyKeyPair
```
자세한 내용은 *AWS Systems Manager 사용 설명서*의 [퍼블릭 파라미터 사용을](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-store-public-parameters.html) 참조하세요.
**Amazon Linux 2 AMI 이름 이해**
Amazon Linux 2 AMI 이름은 다음 이름 지정 체계를 사용합니다.
`amzn2-ami-[minimal-][kernel-{5.10,default,4.14}]-hvm-{x86_64,aarch64}-{ebs,gp2}`
+ **최소** AMIs 이미지 크기를 줄이기 위해 최소화된 사전 설치된 패키지 세트가 함께 제공됩니다.
+ **커널-VERSION**은 각 AMI에 사전 설치된 커널 버전을 결정합니다.
+ `kernel-5.10`는 Linux 커널 버전 5.10을 선택합니다. *AL2에 권장되는 커널 버전입니다.*
+ `kernel-default`는 AL2에 권장되는 기본 커널을 선택합니다. 커널 5.10의 별칭입니다.
+ `kernel-4.14`는 Linux 커널 버전 4.14를 선택합니다. *이는 이전 AMI 릴리스와의 호환성을 위해서만 제공됩니다. 새 인스턴스 시작에는이 버전을 사용하지 마십시오. 이 AMI가 지원되지 않을 것으로 예상합니다.*
+ 특정 커널을 참조하지 않고 특별한 AMI 이름 집합이 존재합니다. 이러한 AMIs는 커널 4.14의 별칭입니다. *이러한 AMIs는 이전 AMI 릴리스와의 호환성을 위해서만 제공됩니다. 새 인스턴스 시작에는이 AMI 이름을 사용하지 마십시오. 이러한 AMIs 것으로 예상합니다.*
+ **x86\$164/aarch64**는 AMI를 실행할 CPU 플랫폼을 결정합니다. Intel 및 AMD 기반 EC2 인스턴스의 경우 x86\$164를 선택합니다. EC2 Graviton 인스턴스에 대해 aarch64를 선택합니다.
+ **ebs/gp2**는 각 AMI를 제공하는 데 사용되는 EBS 볼륨 유형을 결정합니다. 참조는 [EBS 볼륨 유형을 참조하세요](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html). *항상 gp2를 선택합니다.*
## Amazon EC2 인스턴스에 연결
SSH 및 AWS Systems Manager Session Manager EC2 Instance Connect를 포함하여 Amazon Linux 인스턴스에 연결하는 방법에는 여러 가지가 있습니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [Linux 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)을 참조하세요.
**SSH 사용자 및 **sudo****
Amazon Linux는 기본적으로 원격 `root` 보안 쉘(SSH)을 허용하지 않습니다. 또한 암호 인증은 무차별 대입 공격을 방지하기 위해 비활성화됩니다. Amazon Linux 인스턴스에 대해 SSH 로그인을 사용하려면 시작 시 인스턴스에 키 페어를 제공해야 합니다. 또한 SSH 액세스를 허용하도록 인스턴스를 시작하는 데 사용되는 보안 그룹을 설정해야 합니다. 기본적으로 SSH를 사용하여 원격으로 로그인할 수 있는 유일한 계정은 입니다`ec2-user`. 이 계정에는 **sudo** 권한도 있습니다. 원격 `root` 로그인을 활성화하는 경우 키 페어와 보조 사용자를 사용하는 것보다 안전하지 않다는 점에 유의하세요.
## AL2 AMI 부팅 모드
AL2 AMIs에는 부팅 모드 파라미터가 설정되어 있지 않습니다. AL2 AMIs에서 시작된 인스턴스는 인스턴스 유형의 기본 부팅 모드 값을 따릅니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [부팅 모드를](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html) 참조하세요.
## 패키지 리포지토리
이 정보는 AL2에 적용됩니다. AL2023에 대한 자세한 내용은 Amazon Linux [2023 사용 설명서의 AL2023에서 패키지 및 운영 체제 업데이트 관리를](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) 참조하세요. **
AL2 및 AL1은 각 Amazon EC2 AWS 리전에서 호스팅되는 온라인 패키지 리포지토리와 함께 사용하도록 설계되었습니다. 리포지토리는 **yum** 업데이트 도구를 사용하여 액세스되며 모든 리전에서 사용할 수 있습니다. 각 리전에서 리포지토리를 호스팅하면 데이터 전송 요금 없이 데이터를 신속히 배포할 수 있습니다.
**중요**
AL1의 마지막 버전은 2023년 12월 31일에 EOL에 도달했으며 2024년 1월 1일부터 보안 업데이트 또는 버그 수정을 받지 않습니다. 자세한 내용은 [Amazon Linux AMI 지원 종료](https://aws.amazon.com//blogs/aws/update-on-amazon-linux-ami-end-of-life/)를 참조하세요.
인스턴스에 대한 데이터 또는 사용자 지정을 보존할 필요가 없는 경우 현재 AL2 AMI를 사용하여 새 인스턴스를 시작할 수 있습니다. 인스턴스에 대한 데이터 또는 사용자 지정을 보존해야 하는 경우 Amazon Linux 패키지 리포지토리를 통해 해당 인스턴스를 유지할 수 있습니다. 이러한 리포지토리에는 업데이트된 모든 패키지가 포함되어 있습니다. 실행 중인 인스턴스에 이러한 업데이트를 적용하도록 선택할 수 있습니다. 이전 버전의 AMI 및 업데이트 패키지는 새 버전이 릴리스되더라도 계속 사용할 수 있습니다.
**참고**
Amazon EC2 인스턴스에서 인터넷 액세스 없이 패키지를 업데이트하고 설치하려면 [AL1, AL2 또는 AL2023을 실행하는 Amazon EC2 인스턴스에서 인터넷 액세스 없이 yum을 업데이트하거나 패키지를 설치하려면 어떻게 해야 하나요?를 참조하세요](https://repost.aws/knowledge-center/ec2-al1-al2-update-yum-without-internet).
패키지를 설치하려면 다음 명령을 사용합니다.
```
[ec2-user ~]$ sudo yum install package
```
필요한 애플리케이션이 Amazon Linux에 없는 경우 Amazon Linux 인스턴스에 해당 애플리케이션을 설치하면 됩니다. Amazon Linux는 yum 패키지 관리에 RPMs 및를 사용하며, 이는 새 애플리케이션을 설치하는 가장 직접적인 방법일 수 있습니다. 중앙 Amazon Linux 리포지토리에는 사용할 수 있는 애플리케이션이 많으므로 이곳에서 애플리케이션을 사용할 수 있는지부터 확인해야 합니다. 여기에서 이러한 애플리케이션을 Amazon Linux 인스턴스에 추가할 수 있습니다.
애플리케이션을 실행 중인 Amazon Linux 인스턴스에 업로드하려면 **scp** 또는 **sftp**를 사용하고 인스턴스에 로그인하여 애플리케이션을 구성합니다. 또한 기본 제공된 cloud-init 패키지의 **PACKAGE\$1SETUP** 작업을 사용하여 인스턴스 시작 중에 애플리케이션을 업로드할 수도 있습니다. 자세한 내용은 [AL2에서 cloud-init 사용](amazon-linux-cloud-init.md) 섹션을 참조하세요.
### 보안 업데이트
보안 업데이트는 패키지 리포지토리를 사용하여 제공됩니다. 보안 업데이트와 업데이트된 AMI 보안 알림은 모두 [Amazon Linux 보안 센터에](https://alas.aws.amazon.com) 게시됩니다. AWS 보안 정책에 대한 자세한 내용을 찾아보거나 보안 문제를 보고하려면 [AWS 클라우드 보안](https://aws.amazon.com/security/)을 참조하세요.
AL1 및 AL2는 시작 시 중요하거나 중요한 보안 업데이트를 다운로드하고 설치하도록 구성됩니다. 커널 업데이트는 이 구성에 포함되지 않습니다.
AL2023에서는이 구성이 AL1 및 AL2에 비해 변경되었습니다. AL2023의 보안 업데이트에 대한 자세한 내용은 Amazon Linux 2023 사용 설명서의 [보안 업데이트 및 기능을](https://docs.aws.amazon.com/linux/al2023/ug/security-features.html) 참조하세요. **
시작 후에는 사용 사례를 위해 필수 업데이트를 설치하는 것이 좋습니다. 예를 들어 시작 시 모든 업데이트(보안 업데이트뿐만 아니라)를 적용하거나 각 업데이트를 평가하고 시스템에 적용되는 업데이트만 적용할 수 있습니다. 다음과 같은 cloud-init 설정 `repo_upgrade`를 사용하여 이를 제어합니다. 다음 cloud-init 구성 코드 조각은 인스턴스 초기화에 전달하는 사용자 데이터 텍스트의 설정을 변경하는 방법을 보여 줍니다.
```
#cloud-config
repo_upgrade: security
```
`repo_upgrade`에 가능한 값은 다음과 같습니다.
`critical`
대기 중인 심각한 보안 업데이트를 적용합니다.
`important`
대기 중인 심각하거나 중요한 보안 업데이트를 적용합니다.
`medium`
대기 중인 심각하거나 중요하거나 심각도가 보통인 보안 업데이트를 적용합니다.
`low`
심각도가 낮은 보안 업데이트를 포함하여 대기 중인 보안 업데이트를 모두 적용합니다.
`security`
Amazon에서 보안 업데이트로 표시하는 대기 중인 중요하거나 심각한 업데이트를 적용합니다.
`bugfix`
Amazon에서 버그 수정 사항으로 표시하는 업데이트를 적용합니다. 버그 수정 사항은 대규모 업데이트 세트이며 보안 업데이트와 사소한 기타 버그에 대한 수정 사항을 포함합니다.
`all`
분류와 관계 없이 해당되는 모든 업데이트를 적용합니다.
`none`
시작 시 인스턴스에 어떠한 업데이트도 적용하지 마세요.
**Note**
Amazon Linux는 업데이트를 로 표시하지 않습니다`bugfix`. Amazon Linux에서 비보안 관련 업데이트를 적용하려면를 사용합니다`repo_upgrade: all`.
`repo_upgrade`에 대한 기본 설정은 security입니다. 즉, 사용자 데이터에 다른 값을 지정하지 않은 경우 기본적으로 Amazon Linux는 해당 시점에 설치된 모든 패키지에 대해 시작 시 보안 업그레이드를 수행합니다. 또한 Amazon Linux는 로그인 시 `/etc/motd` 파일을 사용하여 사용 가능한 업데이트 수를 나열하는 방법으로 설치된 패키지에 대한 모든 업데이트를 사용자에게 알립니다. 이러한 업데이트를 설치하려면 인스턴스에서 **sudo yum upgrade**를 실행해야 합니다.
### 리포지토리 구성
AL1 및 AL2의 경우 AMIs는 보안 업데이트를 제외하고 AMI가 생성된 시점에 사용 가능한 패키지의 스냅샷입니다. 원래 AMI에 없지만 런타임에 설치된 모든 패키지는 사용 가능한 최신 버전이 됩니다. AL2에 사용할 수 있는 최신 패키지를 가져오려면를 실행합니다**yum update -y**.
**문제 해결 도움말**
예를 들어 nano 인스턴스 유형(예: `t3.nano`)에서 **yum update** 실행 중 `cannot allocate memory` 오류가 발생하는 경우 업데이트를 활성화하기 위해 스왑 공간을 할당해야 할 수 있습니다.
AL2023의 경우 리포지토리 구성이 AL1 및 AL2에 비해 변경되었습니다. AL2023 리포지토리에 대한 자세한 내용은 [운영 체제 및 패키지 업데이트 관리](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html)를 참조하세요.
AL2023까지의 버전에서는 Amazon Linux의 한 마이너 버전에서 다음 버전으로의 연속 업데이트 흐름, 즉 *롤링 릴리스*를 제공하도록 구성되었습니다. 가장 좋은 방법은 이전 AMI를 시작하고 업데이트를 적용하는 대신 AMI를 사용 가능한 최신 AMIs로 업데이트하는 것입니다.
AL1에서 AL2로 또는 AL2에서 AL2023으로 등 주요 Amazon Linux 버전 간에는 현재 위치 업그레이드AL2가 지원되지 않습니다. 자세한 내용은 [Amazon Linux 가용성](what-is-amazon-linux.md#amazon-linux-availability) 단원을 참조하십시오.
# AL2에서 cloud-init 사용
cloud-init 패키지는 Canonical에서 구축한 오픈 소스 애플리케이션이며 Amazon EC2와 같은 클라우드 컴퓨팅 환경에서 Linux 이미지 부트스트랩을 수행하는 데 사용됩니다. Amazon Linux에는 cloud-init의 사용자 지정 버전이 포함됩니다. 이렇게 하면 부팅 시 인스턴스에 발생해야 하는 작업을 지정할 수 있습니다. 인스턴스를 시작할 때 사용자 데이터 필드를 통해 원하는 작업을 cloud-init로 전달할 수 있습니다. 즉, 여러 사용 사례에 공통 AMI를 사용하고 이러한 AMI를 시작 시 동적으로 구성할 수 있습니다. 또한 Amazon Linux는 cloud-init를 사용하여 ec2-user 계정의 초기 구성을 수행합니다.
자세한 내용은 [cloud-init 설명서](http://cloudinit.readthedocs.org/en/latest/)를 참조하세요.
Amazon Linux는 `/etc/cloud/cloud.cfg.d` 및 `/etc/cloud/cloud.cfg`에 있는 cloud-init 작업을 사용합니다. `/etc/cloud/cloud.cfg.d`에서 자체 cloud-init 작업 파일을 만들 수 있습니다. 이 디렉터리의 모든 파일은 cloud-init으로 읽습니다. 어휘 순으로 읽히며, 나중의 파일이 이전 파일의 값을 덮어씁니다.
cloud-init 패키지는 부팅 시 인스턴스에 대해 다음과 같은 일반적인 구성 작업을 수행합니다.
+ 기본 로캘 설정.
+ 호스트 이름 설정.
+ 사용자 데이터 구문 분석 및 처리.
+ 호스트 프라이빗 SSH 키 생성.
+ 손쉬운 로그인 및 관리를 위해 사용자의 퍼블릭 SSH 키를 `.ssh/authorized_keys`에 추가.
+ 패키지 관리를 위한 리포지토리 준비.
+ 사용자 데이터에 정의된 패키지 작업 처리.
+ 사용자 데이터에 있는 사용자 스크립트를 실행합니다.
+ 해당하는 경우 인스턴스 스토어 볼륨을 탑재합니다.
+ 기본적으로 `ephemeral0` 인스턴스 스토어 볼륨은 `/media/ephemeral0`이 있고 유효한 파일 시스템이 포함된 경우 여기에 마운트됩니다. 그렇지 않은 경우 마운트되지 않습니다.
+ 기본적으로 인스턴스와 연결된 모든 스왑 볼륨이 탑재됩니다(`m1.small` 및 `c1.medium` 인스턴스 유형만 해당).
+ 다음 cloud-init 명령을 사용하여 기본 인스턴스 스토어 볼륨 탑재를 재정의할 수 있습니다.
```
#cloud-config
mounts:
- [ ephemeral0 ]
```
탑재를 더 세부적으로 제어하려면 cloud-init 설명서의 [탑재](http://cloudinit.readthedocs.io/en/latest/topics/modules.html#mounts)를 참조하세요.
+ TRIM을 지원하는 인스턴스 스토어 볼륨은 인스턴스를 시작할 때 포맷되지 않으므로, 볼륨을 파티셔닝하고 포맷한 후 탑재해야 합니다. 자세한 내용은 [인스턴스 스토어 볼륨 TRIM 지원을 참조하세요](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-instance-store.html#InstanceStoreTrimSupport). `disk_setup` 모듈을 사용하여 부팅 시 인스턴스 스토어 볼륨을 파티셔닝하고 포맷할 수 있습니다. 자세한 내용은 cloud-init 문서의 [Disk Setup](http://cloudinit.readthedocs.io/en/latest/topics/modules.html#disk-setup)을 참조하세요.
## 지원되는 사용자 데이터 형식
cloud-init 패키지는 다양한 형식의 사용자 데이터 처리를 지원합니다.
+ Gzip
+ 사용자 데이터가 gzip으로 압축된 경우 cloud-init는 데이터의 압축을 풀고 적절하게 처리합니다.
+ MIME 멀티파트
+ MIME 멀티파트 파일을 사용하여 두 가지 이상의 데이터 유형을 지정할 수 있습니다. 예를 들어 사용자 데이터 스크립트와 클라우드 구성 유형을 모두 지정할 수 있습니다. 멀티파트 파일의 각 부분은 지원되는 형식 중 하나일 경우 cloud-init에 의해 처리할 수 있습니다.
+ Base64 디코딩
+ 사용자 데이터가 base64로 인코딩된 경우 cloud-init는 디코딩된 데이터를 지원되는 유형 중 하나로 이해할 수 있는지 여부를 결정합니다. 디코딩된 데이터를 인식하는 경우 데이터를 디코딩하여 그에 맞게 처리합니다. 그렇지 않을 경우 base64 데이터를 원상태로 반환합니다.
+ 사용자 데이터 스크립트
+ `#!` 또는 `Content-Type: text/x-shellscript`로 시작합니다.
+ 스크립트는 첫 부팅 주기에 `/etc/init.d/cloud-init-user-scripts`에 의해 실행됩니다. 이 동작은 부팅 프로세스 후반(초기 구성 작업이 수행된 후)에 발생합니다.
+ Include 파일
+ `#include` 또는 `Content-Type: text/x-include-url`로 시작합니다.
+ 이것은 include 파일의 내용입니다. 이 파일에는 줄당 URL 하나씩, URL 목록이 포함되어 있습니다. 각각의 URL을 읽어오며 해당 내용이 이 동일한 규칙 세트를 통과합니다. URL에서 읽어온 콘텐츠는 gzip으로 압축된 형태이거나 MIME-multi-part 또는 일반 텍스트 형태일 수 있습니다.
+ 클라우드 구성 데이터
+ `#cloud-config` 또는 `Content-Type: text/cloud-config`로 시작합니다.
+ 이 콘텐츠는 클라우드 구성 데이터입니다.
+ Upstart 작업(AL2에서는 지원되지 않음)
+ `#upstart-job` 또는 `Content-Type: text/upstart-job`로 시작합니다.
+ 이 콘텐츠는의 파일에 저장되며`/etc/init`, 업스타트는 다른 업스타트 작업과 마찬가지로 콘텐츠를 사용합니다.
+ 클라우드 부트후크
+ `#cloud-boothook` 또는 `Content-Type: text/cloud-boothook`로 시작합니다.
+ 이것은 bookhook 데이터의 내용입니다. `/var/lib/cloud`에 있는 파일에 저장된 후 즉시 실행됩니다.
+ 이것은 맨 처음으로 사용 가능한 *hook*입니다. 한 번만 실행되도록 제공된 메커니즘이 없습니다. boothook는 이 부분을 자체적으로 처리해야 합니다. 환경 변수 `INSTANCE_ID`에 인스턴스 ID가 함께 제공됩니다. 이 변수를 사용하여 boothook 데이터의 인스턴스당 1회 세트를 제공하세요.
# AL2 인스턴스 구성
AL2 인스턴스를 성공적으로 시작하고 로그인한 후 인스턴스를 변경할 수 있습니다. 특정 애플리케이션의 요구 사항에 맞춰 다양한 방법으로 인스턴스를 구성할 수 있습니다. 다음은 관련 내용을 익히는 데 도움이 되는 몇 가지 일반적인 작업입니다.
**Topics**
+ [일반적인 구성 시나리오](#instance-configuration-scenarios)
+ [AL2 인스턴스에서 소프트웨어 관리](managing-software.md)
+ [Amazon EC2 AL2 인스턴스에 대한 프로세서 상태 제어](processor_state_control.md)
+ [AL2용 I/O 스케줄러](io-scheduler.md)
+ [AL2 인스턴스의 호스트 이름 변경](set-hostname.md)
+ [AL2 인스턴스에서 동적 DNS 설정](dynamic-dns.md)
+ [AL2용 ec2-net-utils를 사용하여 네트워크 인터페이스 구성](ec2-net-utils.md)
## 일반적인 구성 시나리오
Amazon Linux의 기본 배포에는 기본적인 서버 작업에 필요한 소프트웨어 패키지 및 유틸리티가 포함되어 있습니다. 이외에도 다양한 소프트웨어 리포지토리의 더 많은 소프트웨어 패키지를 사용할 수 있고, 훨씬 더 많은 패키지를 소스 코드로 개발할 수 있습니다. 이러한 위치의 소프트웨어를 설치 및 개발하는 방법에 대한 자세한 내용은 [AL2 인스턴스에서 소프트웨어 관리](managing-software.md) 섹션을 참조하세요.
Amazon Linux 인스턴스는 `ec2-user`로 미리 구성되어 제공되지만 수퍼유저 권한이 없는 다른 사용자를 추가할 수도 있습니다. 사용자 추가 및 제거에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Linux 인스턴스에서 사용자 관리를 참조하세요](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/managing-users.html).
도메인 이름이 등록된 자체 네트워크를 보유한 경우 인스턴스의 호스트 이름을 변경하여 해당 도메인에 속한 것으로 표시할 수 있습니다. 호스트 이름 설정은 그대로 두고 시스템 프롬프트를 더욱 의미 있는 이름으로 변경할 수도 있습니다. 자세한 내용은 [AL2 인스턴스의 호스트 이름 변경](set-hostname.md) 섹션을 참조하세요. 인스턴스에서 동적 DNS 서비스 공급자를 사용하도록 구성할 수 있습니다. 자세한 내용은 [AL2 인스턴스에서 동적 DNS 설정](dynamic-dns.md) 섹션을 참조하세요.
Amazon EC2에서 인스턴스를 시작할 때 사용자 데이터를 인스턴스에 전달하여 일반적인 구성 작업을 수행하는 데 사용하도록 할 수 있고, 인스턴스가 시작된 후에 스크립트를 실행할 수도 있습니다. Amazon EC2에 cloud-init 명령 및 shell 스크립트라는 두 가지 유형의 사용자 데이터를 전달할 수 있습니다. 자세한 내용은 *Amazon EC2 사용 설명서*[의 시작 시 Linux 인스턴스에서 명령 실행을 참조하세요](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html).
# AL2 인스턴스에서 소프트웨어 관리
Amazon Linux의 기본 배포에는 기본적인 서버 작업에 필요한 소프트웨어 패키지 및 유틸리티가 포함되어 있습니다.
이 정보는 AL2에 적용됩니다. AL2023에 대한 자세한 내용은 Amazon Linux [2023 사용 설명서의 AL2023에서 패키지 및 운영 체제 업데이트 관리를](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) 참조하세요. **
소프트웨어를 최신 상태로 유지하는 것이 중요합니다. Linux 배포의 다양한 패키지가 버그 수정, 기능 추가 및 보안 취약점 해결을 위해 자주 업데이트됩니다. 자세한 내용은 [AL2 인스턴스에서 인스턴스 소프트웨어 업데이트](install-updates.md) 단원을 참조하십시오.
기본적으로 AL2 인스턴스는 다음 리포지토리가 활성화된 상태로 시작됩니다.
+ `amzn2-core`
+ `amzn2extra-docker`
에서 업데이트한 이러한 리포지토리에서 사용할 수 있는 패키지가 많지만 다른 리포지토리에 포함된 패키지를 설치할 AWS수 있습니다. 자세한 내용은 [AL2 인스턴스에 리포지토리 추가](add-repositories.md) 단원을 참조하십시오. 활성화된 리포지토리에서 패키지를 찾고 설치하는 방법은 [AL2 인스턴스에서 소프트웨어 패키지 찾기 및 설치](find-install-software.md)의 내용을 참조하세요.
리포지토리에 저장된 소프트웨어 패키지만 사용할 수 있는 것은 아닙니다. 일부 소프트웨어의 경우 인스턴스에서 소스 코드를 컴파일해야 합니다. 자세한 내용은 [AL2 인스턴스에서 소프트웨어 컴파일 준비](compile-software.md) 단원을 참조하십시오.
AL2 인스턴스는 yum 패키지 관리자를 사용하여 소프트웨어를 관리합니다. yum 패키지 관리자는 소프트웨어를 설치, 제거 및 업데이트하고 각 패키지의 모든 종속성을 관리할 수 있습니다.
**Topics**
+ [AL2 인스턴스에서 인스턴스 소프트웨어 업데이트](install-updates.md)
+ [AL2 인스턴스에 리포지토리 추가](add-repositories.md)
+ [AL2 인스턴스에서 소프트웨어 패키지 찾기 및 설치](find-install-software.md)
+ [AL2 인스턴스에서 소프트웨어 컴파일 준비](compile-software.md)
# AL2 인스턴스에서 인스턴스 소프트웨어 업데이트
소프트웨어를 최신 상태로 유지하는 것이 중요합니다. Linux 배포의 패키지가 버그 수정, 기능 추가 및 보안 취약점 해결을 위해 자주 업데이트됩니다. 처음으로 Amazon Linux 인스턴스를 시작하여 연결하면 보안을 위해 소프트웨어 패키지를 업데이트하라는 메시지가 표시될 수 있습니다. 이 섹션에서는 전체 시스템 또는 단일 패키지를 업데이트하는 방법을 보여 줍니다.
이 정보는 AL2에 적용됩니다. AL2023에 대한 자세한 내용은 Amazon Linux [2023 사용 설명서의 AL2023에서 패키지 및 운영 체제 업데이트 관리를](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) 참조하세요. **
AL2의 변경 사항 및 업데이트에 대한 자세한 내용은 [AL2 릴리스 정보를](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html) 참조하세요.
AL2023 관련 변경 내용 및 업데이트에 대한 자세한 내용은 [AL2023 릴리스 정보](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes.html)를 참조하세요.
**중요**
Amazon Linux 2 AMI를 사용하는 EC2 인스턴스를 IPv6 전용 서브넷으로 시작한 경우 인스턴스에 연결하고 `sudo amazon-linux-https disable`을 실행해야 합니다. 이렇게 하면 http patch 서비스를 사용하여 AL2 인스턴스를 IPv6을 통해 S3의 yum 리포지토리에 연결할 수 있습니다.
**AL2 인스턴스의 모든 패키지를 업데이트하려면**
1. (선택 사항) shell 창에서 **screen** 세션을 시작합니다. 경우에 따라 네트워크 장애로 인해 인스턴스에 대한 SSH 연결이 끊어질 수 있습니다. 오래 걸리는 소프트웨어 업데이트 중에 연결이 끊어진 경우 인스턴스가 복구 가능한 혼동 상태로 유지될 수 있습니다. 연결이 끊어진 경우에도 **screen** 세션을 통해 업데이트가 계속 실행되며, 이후에 아무런 문제 없이 세션에 다시 연결할 수 있습니다.
1. **screen** 명령을 실행하여 세션을 시작합니다.
```
[ec2-user ~]$ screen
```
1. 세션의 연결이 끊어진 경우 인스턴스에 다시 로그인하고 사용 가능한 화면을 나열합니다.
```
[ec2-user ~]$ screen -ls
There is a screen on:
17793.pts-0.ip-12-34-56-78 (Detached)
1 Socket in /var/run/screen/S-ec2-user.
```
1. 이전 명령에서 확인한 프로세스 ID와 **screen -r** 명령을 사용하여 화면에 다시 연결합니다.
```
[ec2-user ~]$ screen -r 17793
```
1. **screen** 사용을 마쳤으면 **exit** 명령을 사용하여 세션을 닫습니다.
```
[ec2-user ~]$ exit
[screen is terminating]
```
1. **yum update** 명령을 실행합니다. `--security` 플래그를 추가하여 보안 업데이트만 적용할 수도 있습니다.
```
[ec2-user ~]$ sudo yum update
```
1. 나열된 패키지를 검토하고, **y**를 입력하고, Enter 키를 눌러 업데이트를 수락합니다. 시스템의 모든 패키지를 업데이트하는 데 몇 분이 걸릴 수 있습니다. **yum** 출력은 실행 중인 업데이트의 상태를 보여줍니다.
1. (선택 사항) [인스턴스를 재부팅](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html)하여 업데이트의 최신 패키지와 라이브러리를 사용하고 있는지 확인합니다. 커널 업데이트는 재부팅이 발생할 때까지 로드되지 않습니다. `glibc` 라이브러리를 업데이트한 이후에도 항상 재부팅해야 합니다. 서비스를 제어하는 패키지를 업데이트할 경우 서비스를 다시 시작하여 업데이트를 선택하면 되지만, 시스템을 재부팅하면 이전의 모든 패키지 및 라이브러리 업데이트가 완료됩니다.
**AL2 인스턴스에서 단일 패키지를 업데이트하려면**
이 절차를 사용하여 전체 시스템이 아닌 단일 패키지와 해당 종속 패키지를 업데이트할 수 있습니다.
1. 업데이트할 패키지의 이름이 포함된 **yum update** 명령을 실행합니다.
```
[ec2-user ~]$ sudo yum update openssl
```
1. 나열된 패키지 정보를 검토하고, **y**을 입력하고, Enter 키를 눌러 업데이트를 수락합니다. 해결되어야 하는 패키지 종속성이 있는 경우 둘 이상의 패키지가 나열될 수 있습니다. **yum** 출력은 실행 중인 업데이트의 상태를 보여줍니다.
1. (선택 사항) [인스턴스를 재부팅](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html)하여 업데이트의 최신 패키지 및 라이브러리를 사용하고 있는지 확인합니다. 커널 업데이트는 재부팅이 발생할 때까지 로드되지 않습니다. `glibc` 라이브러리를 업데이트한 이후에도 항상 재부팅해야 합니다. 서비스를 제어하는 패키지를 업데이트할 경우 서비스를 다시 시작하여 업데이트를 선택하면 되지만, 시스템을 재부팅하면 이전의 모든 패키지 및 라이브러리 업데이트가 완료됩니다.
# AL2 인스턴스에 리포지토리 추가
이 정보는 AL2에 적용됩니다. AL2023에 대한 자세한 내용은 Amazon Linux 2023 사용 설명서의 [AL2023에서 버전이 지정된 리포지토리를 통한 결정적 업그레이드를](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) 참조하세요. **
기본적으로 AL2 인스턴스는 다음 리포지토리가 활성화된 상태로 시작됩니다.
+ `amzn2-core`
+ `amzn2extra-docker`
Amazon Web Services에서 업데이트하는 이러한 리포지토리의 다양한 패키지 이외에도 다른 리포지토리에 포함된 패키지를 설치할 수 있습니다.
**yum**이 아닌 다른 리포지토리의 패키지를 설치하려면 `/etc/yum.conf` 디렉터리의 `repository.repo` 파일 또는 자체 `/etc/yum.repos.d` 파일에 리포지토리 정보를 추가해야 합니다. 이 작업을 직접 수행할 수도 있지만, 대부분의 yum 리포지토리는 리포지토리 URL을 통해 자체 `repository.repo` 파일을 제공합니다.
**yum 리포지토리가 이미 설치되어 있는지 확인하려면**
다음 명령을 사용하여 설치되어 있는 yum 리포지토리를 조회합니다.
```
[ec2-user ~]$ yum repolist all
```
명령 결과에 설치된 리포지토리가 출력되고 각 상태가 보고됩니다. 사용 가능한 리포지토리에는 해당 리포지토리에 포함된 패키지 수가 표시됩니다.
**/etc/yum.repos.d에 yum 리포지토리를 추가하려면 다음을 수행합니다.**
1. `.repo` 파일의 위치를 찾습니다. 위치는 추가할 리포지토리에 따라 다를 수 있습니다. 이 예시에서 `.repo` 파일은 `https://www.example.com/repository.repo`에 있습니다.
1. **yum-config-manager** 명령을 사용하여 리포지토리를 추가합니다.
```
[ec2-user ~]$ sudo yum-config-manager --add-repo https://www.example.com/repository.repo
Loaded plugins: priorities, update-motd, upgrade-helper
adding repo from: https://www.example.com/repository.repo
grabbing file https://www.example.com/repository.repo to /etc/yum.repos.d/repository.repo
repository.repo | 4.0 kB 00:00
repo saved to /etc/yum.repos.d/repository.repo
```
리포지토리를 설치한 후 다음 절차에 따라 리포지토리를 활성화해야 합니다.
**/etc/yum.repos.d에 yum 리포지토리를 활성화하려면 다음을 수행합니다.**
**yum-config-manager** 플래그와 함께 `--enable repository` 명령을 사용합니다. 다음 명령은 Fedora 프로젝트의 EPEL(Extra Packages for Enterprise Linux) 리포지토리를 활성화합니다. 이 리포지토리는 기본적으로 Amazon Linux AMI 인스턴스의 `/etc/yum.repos.d`에 있지만 활성화되지 않은 상태입니다.
```
[ec2-user ~]$ sudo yum-config-manager --enable epel
```
자세한 내용과이 패키지의 최신 버전을 다운로드하려면 [https://fedoraproject.org/wiki/EPEL](https://fedoraproject.org/wiki/EPEL) 참조하십시오.
# AL2 인스턴스에서 소프트웨어 패키지 찾기 및 설치
패키지 관리 도구를 사용하여 소프트웨어 패키지를 찾고 설치할 수 있습니다. Amazon Linux 2에서 기본 소프트웨어 패키지 관리 도구는 입니다YUM. AL2023에서 기본 소프트웨어 패키지 관리 도구는 DNF입니다. 자세한 내용은 Amazon Linux 2023 사용 설명서의 [패키지 관리 도구를](https://docs.aws.amazon.com/linux/al2023/ug/package-management.html) 참조하세요. **
## AL2 인스턴스에서 소프트웨어 패키지 찾기
**yum search** 명령을 사용하여 구성된 리포지토리에서 사용 가능한 패키지 설명을 검색할 수 있습니다. 이 기능은 설치할 패키지의 이름을 정확히 알지 못할 때 특히 유용합니다. 명령에 검색어를 덧붙이기만 하면 됩니다. 여러 단어를 검색하려는 경우 검색어를 따옴표로 묶습니다.
```
[ec2-user ~]$ yum search "find"
```
다음은 예제 출력입니다.
```
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
============================== N/S matched: find ===============================
findutils.x86_64 : The GNU versions of find utilities (find and xargs)
gedit-plugin-findinfiles.x86_64 : gedit findinfiles plugin
ocaml-findlib-devel.x86_64 : Development files for ocaml-findlib
perl-File-Find-Rule.noarch : Perl module implementing an alternative interface to File::Find
robotfindskitten.x86_64 : A game/zen simulation. You are robot. Your job is to find kitten.
mlocate.x86_64 : An utility for finding files by name
ocaml-findlib.x86_64 : Objective CAML package manager and build helper
perl-Devel-Cycle.noarch : Find memory cycles in objects
perl-Devel-EnforceEncapsulation.noarch : Find access violations to blessed objects
perl-File-Find-Rule-Perl.noarch : Common rules for searching for Perl things
perl-File-HomeDir.noarch : Find your home and other directories on any platform
perl-IPC-Cmd.noarch : Finding and running system commands made easy
perl-Perl-MinimumVersion.noarch : Find a minimum required version of perl for Perl code
texlive-xesearch.noarch : A string finder for XeTeX
valgrind.x86_64 : Tool for finding memory management bugs in programs
valgrind.i686 : Tool for finding memory management bugs in programs
```
여러 단어를 따옴표로 묶은 검색어를 사용하면 검색어와 정확히 일치하는 결과만 반환됩니다. 원하는 패키지가 검색되지 않은 경우 키워드를 하나만 사용하여 검색한 후 결과를 살펴봅니다. 뜻이 같은 키워드를 사용하여 검색 범위를 넓힐 수도 있습니다.
AL2용 패키지에 대한 자세한 내용은 다음을 참조하세요.
+ [AL2 Extras 라이브러리](al2-extras.md)
+ [패키지 리포지토리](ec2.md#package-repository)
## AL2 인스턴스에 소프트웨어 패키지 설치
AL2에서 yum 패키지 관리 도구는 활성화된 모든 리포지토리에서 서로 다른 소프트웨어 패키지를 검색하고 소프트웨어 설치 프로세스의 모든 종속성을 처리합니다. AL2023에 소프트웨어 패키지를 설치하는 방법에 대한 자세한 내용은 Amazon Linux 2023 사용 설명서의 [패키지 및 운영 체제 업데이트 관리를](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) 참조하세요. **
**리포지토리에서 패키지를 설치하려면**
**yum install *package*** 명령을 사용하고 *package*를 설치할 소프트웨어의 이름으로 바꿉니다. 예를 들어 **links** 텍스트 기반 웹 브라우저를 설치하려면 다음 명령을 입력합니다.
```
[ec2-user ~]$ sudo yum install links
```
**다운로드한 RPM 패키지 파일을 설치하려면**
**yum install**을 사용하여 인터넷에서 다운로드한 RPM 패키지 파일을 설치할 수도 있습니다. 이렇게 하려면 설치 명령에 리포지토리 패키지 이름 대신 RPM 파일의 경로 이름을 덧붙이면 됩니다.
```
[ec2-user ~]$ sudo yum install my-package.rpm
```
**설치된 패키지를 나열하려면**
인스턴스에 설치된 패키지 목록을 확인하려면 다음 명령을 사용합니다.
```
[ec2-user ~]$ yum list installed
```
# AL2 인스턴스에서 소프트웨어 컴파일 준비
인터넷에 있는 오픈 소스 소프트웨어 중에는 아직 컴파일되지 않은 상태로 패키지 리포지토리에서 다운로드 가능한 것도 있습니다. 또한 이후에 소스 코드로 직접 컴파일해야 하는 소프트웨어 패키지를 검색할 수도 있습니다. 시스템이 AL2 및 Amazon Linux에서 소프트웨어를 컴파일할 수 있으려면 , **make** **gcc**및와 같은 여러 개발 도구를 설치해야 합니다**autoconf**.
소프트웨어 컴파일은 모든 Amazon EC2 인스턴스에 필요한 작업은 아니기 때문에 이러한 도구는 기본적으로 설치되지 않고 "Development Tools"라는 패키지 그룹으로 제공됩니다. **yum groupinstall** 명령으로 인스턴스에 이 그룹을 손쉽게 추가할 수 있습니다.
```
[ec2-user ~]$ sudo yum groupinstall "Development Tools"
```
[https://github.com/](https://github.com/) 및 [http://sourceforge.net/](https://sourceforge.net/) 등의 웹 사이트에서 소프트웨어 소스 코드 패키지를 tarball이라는 압축된 아카이브 파일로 다운로드할 수 있는 경우가 많습니다. 이러한 tarball의 파일 확장명은 일반적으로 `.tar.gz`입니다. **tar** 명령으로 이러한 아카이브의 압축을 풀 수 있습니다.
```
[ec2-user ~]$ tar -xzf software.tar.gz
```
소스 코드 패키지의 압축을 풀고 아카이빙을 해제한 후에는 소스 코드 디렉터리의 `README` 또는 `INSTALL` 파일을 참조하여 자세한 소스 코드 컴파일 및 설치 방법을 확인해야 합니다.
**Amazon Linux 패키지의 소스 코드를 검색하려면**
Amazon Web Services에서는 유지 관리되는 패키지의 소스 코드를 제공합니다. **yumdownloader --source** 명령을 사용하여 설치된 패키지의 소스 코드를 다운로드할 수 있습니다.
**yumdownloader --source *package*** 명령을 실행하여 *package*에 대한 소스 코드를 다운로드합니다. 예를 들어 `htop` 패키지의 소스 코드를 다운로드하려면 다음 명령을 입력합니다.
```
[ec2-user ~]$ yumdownloader --source htop
Loaded plugins: priorities, update-motd, upgrade-helper
Enabling amzn-updates-source repository
Enabling amzn-main-source repository
amzn-main-source | 1.9 kB 00:00:00
amzn-updates-source | 1.9 kB 00:00:00
(1/2): amzn-updates-source/latest/primary_db | 52 kB 00:00:00
(2/2): amzn-main-source/latest/primary_db | 734 kB 00:00:00
htop-1.0.1-2.3.amzn1.src.rpm
```
소스 RPM의 위치는 명령을 실행했던 디렉터리에 있습니다.
# Amazon EC2 AL2 인스턴스에 대한 프로세서 상태 제어
C 상태는 유휴 상태일 때 코어가 진입하는 절전 수준을 제어합니다. C 상태는 C0(코어가 완전 활성 상태에서 명령을 실행하는 가장 얕은 단계) \$1 C6(코어의 전원이 꺼지는 가장 깊은 유휴 단계)의 숫자로 표시됩니다.
P 상태는 코어의 성능(CPU 주파수)을 제어합니다. P 상태는 P0(코어가 인텔 Turbo Boost Technology를 사용하여 최대 주파수로 증가하는 최고 성능 설정)에서 시작하여 P1(최대 기준 주파수의 P 상태) \$1 P15(최저 주파수)의 숫자로 표시됩니다.
프로세서의 성능 일관성을 향상하고 지연 시간을 줄이거나 특정 워크로드에 대해 인스턴스를 조정하기 위해 C 상태 또는 P 상태 설정을 변경할 수 있습니다. 기본 C 상태 및 P 상태는 대부분의 최고 성능을 제공하도록 설정되어 있고 대부분의 워크로드에 적합합니다. 그러나 애플리케이션에서 단일 또는 이중 코어의 높은 주파수에서 지연 시간을 줄이는 것이 비용상 이익이 되거나 Turbo Boost 버스트 주파수에 비해 낮은 주파수에서 일관된 성능을 제공하는 것이 이익이 되는 경우 이러한 인스턴스에서 사용 가능한 C 상태 또는 P 상태 설정을 시험해보는 것을 고려하세요.
운영 체제가 프로세서 C 상태 및 P 상태를 제어할 수 있는 기능을 제공하는 Amazon EC2 인스턴스 유형에 대한 자세한 내용은 [ Amazon EC2 사용 설명서의 Amazon EC2 인스턴스에 대한 프로세서 상태 제어를 참조하세요](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/processor_state_control.html). *Amazon EC2 *
다음 섹션은 다른 프로세서 상태 구성 및 구성에 따른 영향을 확인하는 방법에 대해 설명합니다. 이러한 절차는 Amazon Linux용으로 작성되어 적용되지만 Linux 커널 버전이 3.9 이상인 다른 Linux 배포판에서도 작동할 수 있습니다.
**참고**
이 페이지의 예에서는 다음을 사용합니다.
프로세서 주파수 및 C-상태 정보를 표시하는 **turbostat** 유틸리티입니다. **turbostat** 유틸리티는 기본적으로 Amazon Linux에서 사용할 수 있습니다.
워크로드를 시뮬레이션하는 **stress** 명령. **stress**를 설치하려면 먼저 **sudo amazon-linux-extras install epel**을 실행하여 EPEL 리포지토리를 활성화한 다음 **sudo yum install -y stress**를 실행합니다.
출력에 C 상태 정보가 표시되지 않을 경우 명령에 **--debug** 옵션을 포함시킵니다(**sudo turbostat --debug stress ****).
**Topics**
+ [최고 Turbo Boost 주파수에서 최상의 성능](#turbo-perf)
+ [C 상태 심화 제한을 통한 고성능 및 저 지연 시간](#c-states)
+ [변동성이 가장 낮은 기준 성능](#baseline-perf)
## 최고 Turbo Boost 주파수에서 최상의 성능
이는 Amazon Linux AMI의 기본 프로세서 상태 제어 구성이고 대부분의 워크로드에 권장됩니다. 이 구성은 변동성이 낮은 최고 성능을 제공합니다. 비활성 코어가 더 깊은 절전 상태로 진입하도록 함으로써 필요한 가용 온도를 제공하여 단일 또는 듀얼 코어 프로세서가 최대 Turbo Boost 성능을 실현할 수 있습니다.
다음 예제는 적극적으로 작업을 수행하는 코어 2개가 있는 `c4.8xlarge` 인스턴스가 최대 프로세서 Turbo Boost 주파수에 도달한 것을 보여줍니다.
```
[ec2-user ~]$ sudo turbostat stress -c 2 -t 10
stress: info: [30680] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
stress: info: [30680] successful run completed in 10s
pk cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 %pc2 %pc3 %pc6 %pc7 Pkg_W RAM_W PKG_% RAM_%
5.54 3.44 2.90 0 9.18 0.00 85.28 0.00 0.00 0.00 0.00 0.00 94.04 32.70 54.18 0.00
0 0 0 0.12 3.26 2.90 0 3.61 0.00 96.27 0.00 0.00 0.00 0.00 0.00 48.12 18.88 26.02 0.00
0 0 18 0.12 3.26 2.90 0 3.61
0 1 1 0.12 3.26 2.90 0 4.11 0.00 95.77 0.00
0 1 19 0.13 3.27 2.90 0 4.11
0 2 2 0.13 3.28 2.90 0 4.45 0.00 95.42 0.00
0 2 20 0.11 3.27 2.90 0 4.47
0 3 3 0.05 3.42 2.90 0 99.91 0.00 0.05 0.00
0 3 21 97.84 3.45 2.90 0 2.11
...
1 1 10 0.06 3.33 2.90 0 99.88 0.01 0.06 0.00
1 1 28 97.61 3.44 2.90 0 2.32
...
10.002556 sec
```
이 예제에서는 다른 코어가 `C6` 절전 상태에 진입하여 전력을 절감하고 작업 코어에 전력과 가용 온도를 제공하기 때문에 vCPU 21 및 28은 최대 Turbo Boost 주파수로 실행될 수 있습니다. vCPU 3 및 10(각각은 vCPU 21 및 28과 프로세서 코어를 공유)은 `C1` 상태에서 명령을 대기합니다.
다음 예에서 18개 코어 모두는 적극적으로 작업을 수행하여 최대 Turbo Boost의 가용 온도가 없지만 3.2GHz의 "전체 코어 Turbo Boost" 속도에서 모두 실행됩니다.
```
[ec2-user ~]$ sudo turbostat stress -c 36 -t 10
stress: info: [30685] dispatching hogs: 36 cpu, 0 io, 0 vm, 0 hdd
stress: info: [30685] successful run completed in 10s
pk cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 %pc2 %pc3 %pc6 %pc7 Pkg_W RAM_W PKG_% RAM_%
99.27 3.20 2.90 0 0.26 0.00 0.47 0.00 0.00 0.00 0.00 0.00 228.59 31.33 199.26 0.00
0 0 0 99.08 3.20 2.90 0 0.27 0.01 0.64 0.00 0.00 0.00 0.00 0.00 114.69 18.55 99.32 0.00
0 0 18 98.74 3.20 2.90 0 0.62
0 1 1 99.14 3.20 2.90 0 0.09 0.00 0.76 0.00
0 1 19 98.75 3.20 2.90 0 0.49
0 2 2 99.07 3.20 2.90 0 0.10 0.02 0.81 0.00
0 2 20 98.73 3.20 2.90 0 0.44
0 3 3 99.02 3.20 2.90 0 0.24 0.00 0.74 0.00
0 3 21 99.13 3.20 2.90 0 0.13
0 4 4 99.26 3.20 2.90 0 0.09 0.00 0.65 0.00
0 4 22 98.68 3.20 2.90 0 0.67
0 5 5 99.19 3.20 2.90 0 0.08 0.00 0.73 0.00
0 5 23 98.58 3.20 2.90 0 0.69
0 6 6 99.01 3.20 2.90 0 0.11 0.00 0.89 0.00
0 6 24 98.72 3.20 2.90 0 0.39
...
```
## C 상태 심화 제한을 통한 고성능 및 저 지연 시간
C 상태는 비활성 상태일 때 코어가 진입하는 절전 수준을 제어합니다. C 상태를 제어하여 시스템의 지연 시간과 성능 조합을 미세 조정할 수 있습니다. 코어가 절전 상태에 진입하기 위해서는 시간이 소요되고 비록 한 코어가 절전 중이면 다른 코어는 더 많은 가용 온도로 더 높은 주파수로 동작할 수 있지만 절전 중인 코어가 다시 정상 상태로 돌아와 작업을 수행하는 데는 시간이 소요됩니다. 예를 들어, 네트워크 패킷 인터럽트를 처리하는 코어가 절전 상태인 경우 인터럽트 상태를 해결하는 것이 지연될 수 있습니다. 그 경우 C 상태가 심화되지 않도록 시스템을 구성하여 프로세서 반응 지연 시간을 줄일 수 있지만 그 대가로 Turbo Boost를 위해 다른 코어에서 사용할 수 있는 가용성이 줄어듭니다.
절전 상태가 심화되지 않도록 설정하는 일반적인 방법에서는 Redis 데이터베이스 애플리케이션이 사용되고 이 경우 최대한 빠른 쿼리 응답 시간이 제공되도록 시스템 메모리에 데이터베이스가 저장됩니다.
**AL2에서 더 깊은 절전 상태를 제한하려면**
1. 원하는 편집기를 사용하여 `/etc/default/grub` 파일을 엽니다.
```
[ec2-user ~]$ sudo vim /etc/default/grub
```
1. `GRUB_CMDLINE_LINUX_DEFAULT` 라인을 수정하고 `intel_idle.max_cstate=1` 및 `processor.max_cstate=1` 옵션을 추가하여 `C1`을 유휴 코어의 최대 유휴 C 상태로 설정합니다.
```
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 intel_idle.max_cstate=1 processor.max_cstate=1"
GRUB_TIMEOUT=0
```
`intel_idle.max_cstate=1` 옵션은 인텔 기반 인스턴스에 대한 C 상태 제한을 구성하고 `processor.max_cstate=1` 옵션은 AMD 기반 인스턴스에 대한 C 상태 제한을 구성합니다. 구성에 두 옵션을 모두 추가하는 것이 안전합니다. 이를 통해 단일 구성으로 인텔과 AMD 플랫폼에서 원하는 동작을 설정할 수 있습니다.
1. 파일을 저장하고 편집기를 종료합니다.
1. 다음 명령을 실행하여 부팅 구성을 재구성합니다.
```
[ec2-user ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
```
1. 인스턴스를 재부팅하여 새 커널 옵션을 활성화합니다.
```
[ec2-user ~]$ sudo reboot
```
**Amazon Linux AMI에서 절전 상태 심화를 제한하려면**
1. 원하는 편집기를 사용하여 `/boot/grub/grub.conf` 파일을 엽니다.
```
[ec2-user ~]$ sudo vim /boot/grub/grub.conf
```
1. 처음 항목의 `kernel` 라인을 수정하고 `intel_idle.max_cstate=1` 및 `processor.max_cstate=1` 옵션을 추가하여 `C1`을 유휴 코어의 최대 유휴 C 상태로 설정합니다.
```
# created by imagebuilder
default=0
timeout=1
hiddenmenu
title Amazon Linux 2014.09 (3.14.26-24.46.amzn1.x86_64)
root (hd0,0)
kernel /boot/vmlinuz-3.14.26-24.46.amzn1.x86_64 root=LABEL=/ console=ttyS0 intel_idle.max_cstate=1 processor.max_cstate=1
initrd /boot/initramfs-3.14.26-24.46.amzn1.x86_64.img
```
`intel_idle.max_cstate=1` 옵션은 인텔 기반 인스턴스에 대한 C 상태 제한을 구성하고 `processor.max_cstate=1` 옵션은 AMD 기반 인스턴스에 대한 C 상태 제한을 구성합니다. 구성에 두 옵션을 모두 추가하는 것이 안전합니다. 이를 통해 단일 구성으로 인텔과 AMD 플랫폼에서 원하는 동작을 설정할 수 있습니다.
1. 파일을 저장하고 편집기를 종료합니다.
1. 인스턴스를 재부팅하여 새 커널 옵션을 활성화합니다.
```
[ec2-user ~]$ sudo reboot
```
다음 예제는 "전체 코어 Turbo Boost" 코어 주파수에서 적극적으로 작업을 수행하는 코어 2개가 있는 `c4.8xlarge` 인스턴스를 보여줍니다.
```
[ec2-user ~]$ sudo turbostat stress -c 2 -t 10
stress: info: [5322] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
stress: info: [5322] successful run completed in 10s
pk cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 %pc2 %pc3 %pc6 %pc7 Pkg_W RAM_W PKG_% RAM_%
5.56 3.20 2.90 0 94.44 0.00 0.00 0.00 0.00 0.00 0.00 0.00 131.90 31.11 199.47 0.00
0 0 0 0.03 2.08 2.90 0 99.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 67.23 17.11 99.76 0.00
0 0 18 0.01 1.93 2.90 0 99.99
0 1 1 0.02 1.96 2.90 0 99.98 0.00 0.00 0.00
0 1 19 99.70 3.20 2.90 0 0.30
...
1 1 10 0.02 1.97 2.90 0 99.98 0.00 0.00 0.00
1 1 28 99.67 3.20 2.90 0 0.33
1 2 11 0.04 2.63 2.90 0 99.96 0.00 0.00 0.00
1 2 29 0.02 2.11 2.90 0 99.98
...
```
이 예에서 vCPUs 19 및 28 코어는 3.2GHz에서 동작하고 다른 코어는 `C1` C 상태에서 명령을 대기합니다. 비록 작업 중인 코어는 최대 Turbo Boost 주파수에 도달할 수 없지만 비활성 코어는 가장 깊은 `C6` C 상태에 있을 때보다 훨씬 빠르게 새 요청에 응답할 수 있습니다.
## 변동성이 가장 낮은 기준 성능
P 상태를 조정하여 프로세서 주파수의 변동성을 줄일 수 있습니다. P 상태는 코어의 성능(CPU 주파수)을 제어합니다. 대부분의 워크로드는 P0에서 더 좋은 성능을 발휘하지만 그 경우 Turbo Boost가 필요합니다. 그러나 Turbo Boost 주파수가 사용되는 경우 발생할 수 있는 성능 버스트보다 일관적인 성능을 갖도록 시스템을 미세 조정하는 것이 필요할 때가 있습니다.
인텔 Advanced Vector Extensions(AVX 또는 AVX2) 워크로드는 낮은 주파수에서 좋은 성능을 보이고 AVX 명령은 더 많은 전력을 사용할 수 있습니다. Turbo Boost를 비활성화하여 낮은 주파수에서 프로세서를 실행하면 사용 전력을 줄이고 스피드를 좀 더 일관성 있게 유지할 수 있습니다. 인스턴스 구성 최적화 및 AVX 워크로드에 대한 자세한 내용은 [Intel 웹 사이트](https://www.intel.com/content/www/us/en/developer/articles/technical/the-intel-advanced-vector-extensions-512-feature-on-intel-xeon-scalable.html?wapkw=advanced%20vector%20extensions)를 참조하세요.
CPU 유휴 드라이버는 P 상태를 제어합니다. 최신 CPU 세대에는 다음과 같이 커널 수준에 해당하는 업데이트된 CPU 유휴 드라이버가 필요합니다.
+ Linux 커널 버전 6.1 이상 - Intel Granite Rapids 지원(예: R8i)
+ Linux 커널 버전 5.10 이상 - AMD 밀라노(예: M6a) 지원
+ Linux 커널 버전 5.6 이상 - Intel Icelake 지원(예: M6i)
실행 중인 시스템의 커널이 CPU를 인식하는지 확인하려면 다음 명령을 실행합니다.
```
if [ -d /sys/devices/system/cpu/cpu0/cpuidle ]; then echo "C-state control enabled"; else echo "Kernel cpuidle driver does not recognize this CPU generation"; fi
```
이 명령의 출력으로 지원이 부족하다는 것을 나타내면 커널을 업그레이드하는 것이 좋습니다.
이 섹션은 절전 상태가 심화되는 것을 제한하고 Turbo Boost(`P1` P 상태 요청)를 비활성화하여 이러한 워크로드 유형에 짧은 지연 시간과 낮은 프로세서 속도 변동성을 제공하는 방법에 대해 설명합니다.
**더 깊은 절전 상태를 제한하고 AL2에서 Turbo Boost를 비활성화하려면**
1. 원하는 편집기를 사용하여 `/etc/default/grub` 파일을 엽니다.
```
[ec2-user ~]$ sudo vim /etc/default/grub
```
1. `GRUB_CMDLINE_LINUX_DEFAULT` 라인을 수정하고 `intel_idle.max_cstate=1` 및 `processor.max_cstate=1` 옵션을 추가하여 `C1`을 유휴 코어의 최대 유휴 C 상태로 설정합니다.
```
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 intel_idle.max_cstate=1 processor.max_cstate=1"
GRUB_TIMEOUT=0
```
`intel_idle.max_cstate=1` 옵션은 인텔 기반 인스턴스에 대한 C 상태 제한을 구성하고 `processor.max_cstate=1` 옵션은 AMD 기반 인스턴스에 대한 C 상태 제한을 구성합니다. 구성에 두 옵션을 모두 추가하는 것이 안전합니다. 이를 통해 단일 구성으로 인텔과 AMD 플랫폼에서 원하는 동작을 설정할 수 있습니다.
1. 파일을 저장하고 편집기를 종료합니다.
1. 다음 명령을 실행하여 부팅 구성을 재구성합니다.
```
[ec2-user ~]$ grub2-mkconfig -o /boot/grub2/grub.cfg
```
1. 인스턴스를 재부팅하여 새 커널 옵션을 활성화합니다.
```
[ec2-user ~]$ sudo reboot
```
1. `P1` P 상태가 제공하는 낮은 프로세서 속도 변동성이 필요한 경우 다음 명령을 사용하여 Turbo Boost를 비활성화합니다.
```
[ec2-user ~]$ sudo sh -c "echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo"
```
1. 워크로드가 종료되면 다음 명령으로 Turbo Boost를 다시 활성화할 수 있습니다.
```
[ec2-user ~]$ sudo sh -c "echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo"
```
**Amazon Linux AMI에서 절전 상태 심화를 제한하고 Turbo Boost를 비활성화하려면**
1. 원하는 편집기를 사용하여 `/boot/grub/grub.conf` 파일을 엽니다.
```
[ec2-user ~]$ sudo vim /boot/grub/grub.conf
```
1. 처음 항목의 `kernel` 라인을 수정하고 `intel_idle.max_cstate=1` 및 `processor.max_cstate=1` 옵션을 추가하여 `C1`을 유휴 코어의 최대 유휴 C 상태로 설정합니다.
```
# created by imagebuilder
default=0
timeout=1
hiddenmenu
title Amazon Linux 2014.09 (3.14.26-24.46.amzn1.x86_64)
root (hd0,0)
kernel /boot/vmlinuz-3.14.26-24.46.amzn1.x86_64 root=LABEL=/ console=ttyS0 intel_idle.max_cstate=1 processor.max_cstate=1
initrd /boot/initramfs-3.14.26-24.46.amzn1.x86_64.img
```
`intel_idle.max_cstate=1` 옵션은 인텔 기반 인스턴스에 대한 C 상태 제한을 구성하고 `processor.max_cstate=1` 옵션은 AMD 기반 인스턴스에 대한 C 상태 제한을 구성합니다. 구성에 두 옵션을 모두 추가하는 것이 안전합니다. 이를 통해 단일 구성으로 인텔과 AMD 플랫폼에서 원하는 동작을 설정할 수 있습니다.
1. 파일을 저장하고 편집기를 종료합니다.
1. 인스턴스를 재부팅하여 새 커널 옵션을 활성화합니다.
```
[ec2-user ~]$ sudo reboot
```
1. `P1` P 상태가 제공하는 낮은 프로세서 속도 변동성이 필요한 경우 다음 명령을 사용하여 Turbo Boost를 비활성화합니다.
```
[ec2-user ~]$ sudo sh -c "echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo"
```
1. 워크로드가 종료되면 다음 명령으로 Turbo Boost를 다시 활성화할 수 있습니다.
```
[ec2-user ~]$ sudo sh -c "echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo"
```
다음 예제는 Turbo Boost 없이 기준 코어 주파수에서 적극적으로 작업을 수행하는 vCPU 2개가 있는 `c4.8xlarge` 인스턴스를 보여줍니다.
```
[ec2-user ~]$ sudo turbostat stress -c 2 -t 10
stress: info: [5389] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
stress: info: [5389] successful run completed in 10s
pk cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 %pc2 %pc3 %pc6 %pc7 Pkg_W RAM_W PKG_% RAM_%
5.59 2.90 2.90 0 94.41 0.00 0.00 0.00 0.00 0.00 0.00 0.00 128.48 33.54 200.00 0.00
0 0 0 0.04 2.90 2.90 0 99.96 0.00 0.00 0.00 0.00 0.00 0.00 0.00 65.33 19.02 100.00 0.00
0 0 18 0.04 2.90 2.90 0 99.96
0 1 1 0.05 2.90 2.90 0 99.95 0.00 0.00 0.00
0 1 19 0.04 2.90 2.90 0 99.96
0 2 2 0.04 2.90 2.90 0 99.96 0.00 0.00 0.00
0 2 20 0.04 2.90 2.90 0 99.96
0 3 3 0.05 2.90 2.90 0 99.95 0.00 0.00 0.00
0 3 21 99.95 2.90 2.90 0 0.05
...
1 1 28 99.92 2.90 2.90 0 0.08
1 2 11 0.06 2.90 2.90 0 99.94 0.00 0.00 0.00
1 2 29 0.05 2.90 2.90 0 99.95
```
vCPUs 21 및 28용 코어는 2.9GHz의 기준 프로세서 속도에서 적극적으로 작업을 수행하고 모든 비활성 코어도 또한 `C1` C 상태에서 기준 속도로 동작하여 명령을 수락할 수 있습니다.
# AL2용 I/O 스케줄러
I/O 스케줄러는 I/O 요청을 정렬 및 병합하고 처리 순서를 결정하는 Linux 운영 체제의 일부입니다.
I/O 스케줄러는 탐색 시간이 비싸고 같은 위치에 있는 요청을 병합하는 것이 최적인 마그네틱 하드 드라이브와 같은 디바이스에 특히 유용합니다. I/O 스케줄러는 솔리드 스테이트 디바이스와 가상 환경에서 효과가 적습니다. 솔리드 스테이트 디바이스의 경우 순차 액세스와 무작위 액세스가 다르지 않고 가상 환경의 경우 호스트가 자체 스케줄링 계층을 제공하기 때문입니다.
이 주제에서는 Amazon Linux I/O 스케줄러에 대해 설명합니다. 다른 Linux 배포판에서 사용하는 I/O 스케줄러에 대한 자세한 내용은 해당 설명서를 참조하세요.
**Topics**
+ [지원되는 스케줄러](#supported-schedulers)
+ [기본 스케줄러](#default-schedulers)
+ [스케줄러 변경](#change-scheduler)
## 지원되는 스케줄러
Amazon Linux는 다음과 같은 I/O 스케줄러를 지원합니다.
+ `deadline` - *기한* I/O 스케줄러는 I/O 요청을 정렬하고 가장 효율적인 순서로 처리합니다. 각 I/O 요청의 시작 시간을 보장합니다. 또한 너무 오랫동안 보류 중인 I/O 요청에 더 높은 우선순위를 부여합니다.
+ `cfq` - *완전히 공정한 대기열*(CFQ) I/O 스케줄러는 프로세스 간에 I/O 리소스를 공정하게 할당하려고 합니다. I/O 요청을 정렬하여 프로세스별 대기열에 삽입합니다.
+ `noop` - *작업 없음*(noop) I/O 스케줄러는 모든 I/O 요청을 FIFO 대기열에 삽입한 다음 단일 요청으로 병합합니다. 이 스케줄러는 요청 정렬을 수행하지 않습니다.
## 기본 스케줄러
작업 없음(noop)은 Amazon Linux의 기본 I/O 스케줄러입니다. 이 스케줄러는 다음과 같은 이유로 사용됩니다.
+ 대부분의 인스턴스 유형은 기본 호스트가 인스턴스에 대한 예약을 수행하는 가상 디바이스를 사용합니다.
+ 솔리드 스테이트 디바이스는 I/O 스케줄러의 이점이 효과가 적은 많은 인스턴스 유형에 사용됩니다.
+ 침범성이 가장 적은 I/O 스케줄러이며 필요한 경우 사용자 지정할 수 있습니다.
## 스케줄러 변경
I/O 스케줄러를 변경하면 스케줄러가 주어진 시간에 완료되는 I/O 요청의 수를 늘리는지 아니면 줄이는지에 따라 성능이 향상되거나 저하될 수 있습니다. 이는 주로 워크로드, 사용 중인 인스턴스 유형의 생성 및 액세스 중인 디바이스 유형에 따라 달라집니다. 사용 중인 I/O 스케줄러를 변경하는 경우 **iotop**과 같은 도구를 사용하여 I/O 성능을 측정하고 변경 사항이 사용 사례에 유용한지 여부를 확인하는 것이 좋습니다.
예를 들어 `nvme0n1`과 같은 명령을 사용하여 디바이스에 대한 I/O 스케줄러를 볼 수 있습니다. 다음 명령에서 `nvme0n1`을 인스턴스의 `/sys/block`에 나열된 디바이스로 대체합니다.
```
$ cat /sys/block/nvme0n1/queue/scheduler
```
디바이스에 대한 I/O 스케줄러를 설정하려면 다음 명령을 사용합니다.
```
$ echo cfq|deadline|noop > /sys/block/nvme0n1/queue/scheduler
```
예를 들어, *xvda* 디바이스에 대해 `noop`에서 `cfq`로 I/O 스케줄러를 설정하려면 다음 명령을 사용합니다.
```
$ echo cfq > /sys/block/xvda/queue/scheduler
```
# AL2 인스턴스의 호스트 이름 변경
프라이빗 VPC에서 인스턴스를 시작하는 경우 Amazon EC2에서 게스트 OS 호스트 이름을 할당합니다. Amazon EC2에서 할당하는 호스트 이름의 유형은 서브넷 설정에 따라 다릅니다. EC2 호스트 이름에 대한 자세한 내용은 [Amazon EC2 사용 설명서의 Amazon EC2 인스턴스 호스트 이름 유형을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html) 참조하세요. *Amazon EC2 *
IPv4 주소를 갖는 IP 기반 이름 지정을 사용하여 구성되는 일반적인 Amazon EC2 프라이빗 DNS 이름은 `ip-12-34-56-78.us-west-2.compute.internal`과 같이 보이며, 여기서 이름은 내부 도메인, 서비스(이 경우 `compute`), 리전 및 프라이빗 IPv4 주소 형태로 구성됩니다. 인스턴스에 로그인하면 shell 프롬프트에 이 호스트 이름의 일부(예: `ip-12-34-56-78`)가 표시됩니다. 탄력적 IP 주소를 사용하지 않는 경우 Amazon EC2 인스턴스를 중지하고 다시 시작할 때마다 퍼블릭 IPv4 주소, 퍼블릭 DNS 이름, 시스템 호스트 이름 및 shell 프롬프트가 바뀝니다.
**중요**
이 정보는 Amazon Linux에 적용됩니다. 기타 배포에 대한 자세한 내용은 해당 설명서를 참조하세요.
## 시스템 호스트 이름 변경
인스턴스의 IP 주소에 퍼블릭 DNS 이름을 등록한 경우(예: `webserver.mydomain.com`) 인스턴스가 자신이 해당 도메인에 속함을 인식하도록 시스템 호스트 이름을 설정할 수 있습니다. 이렇게 하면에서 제공하는 호스트 이름 대신이 이름의 첫 번째 부분이 표시되도록 셸 프롬프트도 변경됩니다 AWS (예: `ip-12-34-56-78`). 퍼블릭 DNS 이름을 등록하지 않은 경우에도 호스트 이름을 변경할 수 있지만 절차가 약간 다릅니다.
호스트 이름 업데이트를 유지하려면 `preserve_hostname` cloud-init 설정이 `true`로 설정되어 있는지 확인해야 합니다. 다음 명령을 실행하여 이 설정을 편집하거나 추가할 수 있습니다.
```
sudo vi /etc/cloud/cloud.cfg
```
`preserve_hostname` 설정이 나열되어 있지 않으면 파일 끝에 다음 텍스트 줄을 추가합니다.
```
preserve_hostname: true
```
**시스템 호스트 이름을 퍼블릭 DNS 이름으로 변경하려면 다음을 수행합니다.**
이미 퍼블릭 DNS 이름을 등록한 경우 이 절차를 따릅니다.
1.
+ AL2의 경우: **hostnamectl** 명령을 사용하여 정규화된 도메인 이름(예: )을 반영하도록 호스트 이름을 설정합니다**webserver.mydomain.com**.
```
[ec2-user ~]$ sudo hostnamectl set-hostname webserver.mydomain.com
```
+ Amazon Linux AMI: 인스턴스에서 선호하는 텍스트 편집기로 `/etc/sysconfig/network` 구성 파일을 열고 `HOSTNAME` 항목을 변경하여 정규화된 도메인 이름을 반영합니다(예: **webserver.mydomain.com**).
```
HOSTNAME=webserver.mydomain.com
```
1. 인스턴스를 재부팅하여 새 호스트 이름을 적용합니다.
```
[ec2-user ~]$ sudo reboot
```
또는 Amazon EC2 콘솔을 사용하여 재부팅할 수 있습니다(**인스턴스** 페이지에서 인스턴스를 선택하고 **인스턴스 상태**, **인스턴스 재부팅**을 차례로 선택).
1. 인스턴스에 로그인하고 호스트 이름이 업데이트되었는지 확인합니다. 프롬프트에 새 호스트 이름이 첫 번째 "."까지 표시되어야 하고, **hostname** 명령이 정규화된 도메인 이름을 표시해야 합니다.
```
[ec2-user@webserver ~]$ hostname
webserver.mydomain.com
```
**퍼블릭 DNS 이름 없이 시스템 호스트 이름을 변경하려면 다음을 수행합니다.**
1.
+ AL2의 경우: **hostnamectl** 명령을 사용하여 원하는 시스템 호스트 이름(예: )을 반영하도록 호스트 이름을 설정합니다**webserver**.
```
[ec2-user ~]$ sudo hostnamectl set-hostname webserver.localdomain
```
+ Amazon Linux AMI: 인스턴스에서 선호하는 텍스트 편집기로 `/etc/sysconfig/network` 구성 파일을 열고 `HOSTNAME` 항목을 변경하여 원하는 호스트 이름을 반영합니다(예: **webserver**).
```
HOSTNAME=webserver.localdomain
```
1. 선호하는 텍스트 편집기로 `/etc/hosts` 파일을 열고 **127.0.0.1**로 시작되는 항목을 아래 예제와 일치하도록 변경합니다. 원하는 호스트 이름을 대신 입력하면 됩니다.
```
127.0.0.1 webserver.localdomain webserver localhost4 localhost4.localdomain4
```
1. 인스턴스를 재부팅하여 새 호스트 이름을 적용합니다.
```
[ec2-user ~]$ sudo reboot
```
또는 Amazon EC2 콘솔을 사용하여 재부팅할 수 있습니다(**인스턴스** 페이지에서 인스턴스를 선택하고 **인스턴스 상태**, **인스턴스 재부팅**을 차례로 선택).
1. 인스턴스에 로그인하고 호스트 이름이 업데이트되었는지 확인합니다. 프롬프트에 새 호스트 이름이 첫 번째 "."까지 표시되어야 하고, **hostname** 명령이 정규화된 도메인 이름을 표시해야 합니다.
```
[ec2-user@webserver ~]$ hostname
webserver.localdomain
```
사용자 데이터를 지정하여 인스턴스를 구성하는 등 더 프로그래밍 방식의 솔루션을 구현할 수도 있습니다. 인스턴스가 Auto Scaling 그룹의 일부인 경우 수명 주기 후크를 사용하여 사용자 데이터를 정의할 수 있습니다. 자세한 내용은 [시작 시 Linux 인스턴스에서 명령 실행](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) 및 *AWS CloudFormation * 사용 설명서의 [인스턴스 시작을 위한 수명 주기 후크](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-autoscaling-lifecyclehook.html#aws-resource-autoscaling-lifecyclehook--examples--Lifecycle_hook_for_instance_launch)를 참조하세요.
## 호스트 이름에 영향을 주지 않고 shell 프롬프트 변경
인스턴스의 호스트 이름을 수정하지 않고에서 제공하는 프라이빗 이름(예: **webserver**)보다 더 유용한 시스템 이름 AWS (예: )을 표시하려면 쉘 프롬프트 구성 파일을 편집하여 호스트 이름 대신 시스템 별명을 표시할 `ip-12-34-56-78`수 있습니다.
**shell 프롬프트를 호스트 별칭으로 변경하려면 다음을 수행합니다.**
1. `/etc/profile.d`에 `NICKNAME`이라는 환경 변수를 shell 프롬프트로 사용할 값으로 설정하는 파일을 생성합니다. 예를 들어 시스템 별칭을 **webserver**라고 설정하려면 다음 명령을 실행합니다.
```
[ec2-user ~]$ sudo sh -c 'echo "export NICKNAME=webserver" > /etc/profile.d/prompt.sh'
```
1. 즐겨 찾는 텍스트 편집기(예: `/etc/bashrc` 또는 `/etc/bash.bashrc`)에서 **vim**(Red Hat) 또는 **nano**(Debian/Ubuntu) 파일을 엽니다. **sudo** 및 `/etc/bashrc`는 `/etc/bash.bashrc`가 소유하므로 `root`와 함께 편집기 명령을 사용해야 합니다.
1. 파일을 편집하여 호스트 이름 대신 별칭을 표시하도록 shell 프롬프트 변수(`PS1`)를 변경합니다. `/etc/bashrc` 또는 `/etc/bash.bashrc`에서 shell 프롬프트를 설정하는 다음 줄을 찾습니다. 아래에서는 참조를 위해 위아래 몇 줄을 함께 표시했으며, `[ "$PS1"`로 시작되는 줄을 찾으면 됩니다.
```
# Turn on checkwinsize
shopt -s checkwinsize
[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@\h \W]\\$ "
# You might want to have e.g. tty in prompt (e.g. more virtual machines)
# and console windows
```
그 줄에서 `\h`(`hostname`에 대한 기호)를 `NICKNAME` 변수로 변경하세요.
```
# Turn on checkwinsize
shopt -s checkwinsize
[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@$NICKNAME \W]\\$ "
# You might want to have e.g. tty in prompt (e.g. more virtual machines)
# and console windows
```
1. (선택 사항) shell 창의 제목을 새 별칭으로 설정하려면 다음 단계를 완료합니다.
1. `/etc/sysconfig/bash-prompt-xterm`이라는 이름의 파일을 만듭니다.
```
[ec2-user ~]$ sudo touch /etc/sysconfig/bash-prompt-xterm
```
1. 다음 명령으로 파일을 실행 가능하도록 만듭니다.
```
[ec2-user ~]$ sudo chmod +x /etc/sysconfig/bash-prompt-xterm
```
1. 선호하는 텍스트 편집기(예: `/etc/sysconfig/bash-prompt-xterm` 또는 **vim**)에서 **nano** 파일을 엽니다. **sudo**는 `/etc/sysconfig/bash-prompt-xterm`가 소유하므로 `root`와 함께 에디터 명령을 사용해야 합니다.
1. 파일에 다음 줄을 추가합니다.
```
echo -ne "\033]0;${USER}@${NICKNAME}:${PWD/#$HOME/~}\007"
```
1. 로그아웃하고 다시 로그인하여 새 별칭 값을 적용합니다.
## 다른 Linux 배포판에서 호스트 이름 변경
이 페이지의 절차는 Amazon Linux에서 사용하기 위한 것입니다. 다른 Linux 배포판에 대한 자세한 내용은 해당 설명서와 다음 항목을 참조하세요.
+ [RHEL 7 또는 Centos 7을 실행하는 프라이빗 Amazon EC2 인스턴스로 정적 호스트 이름을 할당하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/linux-static-hostname-rhel7-centos7/)
# AL2 인스턴스에서 동적 DNS 설정
EC2 인스턴스를 시작하면 인터넷에서 인스턴스에 접속하는 데 사용할 수 있는 퍼블릭 IP 주소와 퍼블릭 도메인 이름 시스템(DNS) 이름이 지정됩니다. Amazon Web Services 도메인에는 수없이 많은 호스트가 있으므로 퍼블릭 이름이 상당히 길어야 각 이름의 고유성을 유지할 수 있습니다. 일반적인 Amazon EC2 퍼블릭 DNS 이름은 다음과 같습니다. `ec2-12-34-56-78.us-west-2.compute.amazonaws.com`여기서 이름은 Amazon Web Services 도메인, 서비스(이 경우 `compute`), AWS 리전및 퍼블릭 IP 주소의 형태로 구성됩니다.
동적 DNS 서비스는 도메인 영역 내에서 기억하기 쉽고 호스트의 사용 사례에 더욱 적합한 맞춤형 DNS 호스트 이름을 제공합니다. 경우에 따라 이러한 서비스를 무료로 이용할 수도 있습니다. Amazon EC2에 동적 DNS 공급자를 사용하고 인스턴스가 시작될 때마다 퍼블릭 DNS 이름에 연결된 IP 주소를 업데이트하도록 인스턴스를 구성할 수 있습니다. 매우 다양한 공급자 중에서 선택할 수 있으며, 적합한 공급자를 선택하는 구체적인 방법 및 이름을 등록하는 방법은 본 안내서의 범위를 벗어납니다.
**Amazon EC2에 동적 DNS를 사용하려면 다음을 수행합니다.**
1. 동적 DNS 서비스 공급자의 서비스에 가입하고 퍼블릭 DNS 이름을 등록합니다. 이 절차에서는 [noip.com/free](https://www.noip.com/free)의 무료 서비스를 예제로 사용합니다.
1. 동적 DNS 업데이트 클라이언트를 구성합니다. 동적 DNS 서비스 공급자의 서비스에 가입하고 퍼블릭 DNS 이름을 등록했으면 DNS 이름에 인스턴스의 IP 주소를 가리킵니다. 공급자에 따라([noip.com](https://noip.com) 포함) 공급자 웹 사이트의 계정 페이지에서 수동으로 입력하거나 소프트웨어 업데이트 클라이언트를 지원합니다. 업데이트 클라이언트가 EC2 인스턴스에서 실행되고 있다면 종료 및 재시작 후와 같이 IP 주소가 바뀔 때마다 동적 DNS 레코드가 업데이트됩니다. 이 예제에서는 [noip.com](https://noip.com)에서 제공하는 서비스와 연동되는 noip2 클라이언트를 설치합니다.
1. EPEL(Extra Packages for Enterprise Linux) 리포지토리를 활성화하여 `noip2` 클라이언트에 액세스할 수 있습니다.
**참고**
AL2 인스턴스에는 기본적으로 EPEL 리포지토리에 대한 GPG 키 및 리포지토리 정보가 설치되어 있습니다. 자세한 내용과이 패키지의 최신 버전을 다운로드하려면 [https://fedoraproject.org/wiki/EPEL](https://fedoraproject.org/wiki/EPEL) 참조하십시오.
```
[ec2-user ~]$ sudo amazon-linux-extras install epel -y
```
1. `noip` 패키지를 설치합니다.
```
[ec2-user ~]$ sudo yum install -y noip
```
1. 구성 파일을 생성합니다. 요청에 따라 로그인 및 암호 정보를 입력하고 후속 질문에 답하여 클라이언트를 구성합니다.
```
[ec2-user ~]$ sudo noip2 -C
```
1. noip 서비스를 활성화합니다.
```
[ec2-user ~]$ sudo systemctl enable noip.service
```
1. noip 서비스를 시작합니다.
```
[ec2-user ~]$ sudo systemctl start noip.service
```
이 명령은 클라이언트를 시작합니다. 클라이언트는 앞서 생성한 구성 파일(`/etc/no-ip2.conf`)을 읽고 사용자가 선택한 퍼블릭 DNS 이름의 IP 주소를 업데이트합니다.
1. 업데이트 클라이언트가 동적 DNS 이름의 IP 주소를 올바르게 설정했는지 확인합니다. 몇 분 동안 DNS 레코드가 업데이트되기를 기다린 후, 이 절차에서 구성한 퍼블릭 DNS 이름을 사용하여 SSH를 통해 인스턴스에 연결해 봅니다.
# AL2용 ec2-net-utils를 사용하여 네트워크 인터페이스 구성
Amazon Linux 2 AMIs에는 ec2-net-utils라고 AWS하는에서 설치한 추가 스크립트가 포함될 수 있습니다. 이러한 스크립트는 네트워크 인터페이스의 구성을 선택적으로 구성합니다. 이러한 스크립트는 AL2에서만 사용할 수 있습니다.
**참고**
Amazon Linux 2023의 경우 `amazon-ec2-net-utils` 패키지는 `/run/systemd/network` 디렉터리에서 인터페이스별 구성을 생성합니다. 자세한 정보는 * Amazon Linux 2023 사용 설명서*의 [네트워킹 서비스](https://docs.aws.amazon.com/linux/al2023/ug/networking-service.html)를 참조하세요.
패키지가 아직 설치되지 않은 경우 다음 명령을 사용하여 AL2에 패키지를 설치하거나, 패키지가 설치되어 있고 추가 업데이트를 사용할 수 있는 경우 패키지를 업데이트합니다.
```
$ yum install ec2-net-utils
```
다음 구성 요소는 ec2-net-utils의 일부입니다.
udev 규칙(`/etc/udev/rules.d`)
실행 중인 인스턴스에 연결, 분리 또는 다시 연결될 때 네트워크 인터페이스를 식별하며 핫플러그 스크립트(`53-ec2-network-interfaces.rules`)가 실행되도록 합니다. MAC 주소를 드라이브 이름(`75-persistent-net-generator.rules`, 여기서 `70-persistent-net.rules`를 생성)에 매핑합니다.
핫플러그 스크립트
DHCP에서 사용하기에 적합한 인터페이스 구성 파일을 생성합니다(`/etc/sysconfig/network-scripts/ifcfg-eth`*N*). 또한 라우팅 구성 파일도 생성합니다(`/etc/sysconfig/network-scripts/route-eth`*N*).
DHCP 스크립트
네트워크 인터페이스에서 새 DHCP 임대를 수신할 때마다 이 스크립트는 인스턴스 메타데이터에 탄력적 IP 주소를 쿼리합니다. 각 탄력적 IP 주소마다 라우팅 정책 데이터베이스에 규칙을 추가하여 해당 주소의 아웃바운드 트래픽에 올바른 네트워크 인터페이스가 사용되도록 합니다. 또한 각 프라이빗 IP 주소를 네트워크 인터페이스에 부 주소로 추가합니다.
**ec2ifup** eth*N* (`/usr/sbin/`)
표준 **ifup**의 기능을 확장합니다. 이 스크립트는 구성 파일 `ifcfg-eth`*N* 및 `route-eth`*N*을 다시 쓴 후 **ifup**을 실행합니다.
**ec2ifdown** eth*N* (`/usr/sbin/`)
표준 **ifdown**의 기능을 확장합니다. 이 스크립트는 라우팅 정책 데이터베이스에서 네트워크 인터페이스 관련 규칙을 모두 제거한 후 **ifdown**을 실행합니다.
**ec2ifscan** (`/usr/sbin/`)
구성되지 않은 네트워크 인터페이스가 있는지 확인하고 이러한 인터페이스를 구성합니다.
이 스크립트는 ec2-net-utils의 초기 릴리스에서는 사용할 수 없습니다.
ec2-net-utils에서 생성된 구성 파일을 나열하려면 다음 명령을 사용합니다.
```
$ ls -l /etc/sysconfig/network-scripts/*-eth?
```
자동화를 비활성화하려는 경우 `EC2SYNC=no`를 해당 `ifcfg-eth`*N* 파일에 추가할 수 있습니다. 예를 들어, 다음 명령을 사용하여 eth1 인터페이스에 대한 자동화를 사용하지 않도록 설정합니다.
```
$ sed -i -e 's/^EC2SYNC=yes/EC2SYNC=no/' /etc/sysconfig/network-scripts/ifcfg-eth1
```
자동화를 완전히 사용하지 않으려면 다음 명령을 사용하여 패키지를 제거할 수 있습니다.
```
$ yum remove ec2-net-utils
```
# 사용자 제공 커널
Amazon EC2 인스턴스에 사용자 지정 커널이 필요할 경우 가장 적합한 AMI를 사용하여 시작한 후 해당 인스턴스에서 사용자 지정 커널을 컴파일하고, 부트로더를 업데이트하여 새 커널을 지정합니다. 이 프로세스는 AMI에서 사용하는 가상화 유형에 따라 다릅니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [Linux AMI 가상화 유형을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html) 참조하세요.
**Topics**
+ [HVM AMIs(GRUB)](#HVM_instances)
+ [AMIs 반가상화(PV-GRUB)](#Paravirtual_instances)
## HVM AMIs(GRUB)
HVM 인스턴스 볼륨은 실제 물리적 디스크인 것처럼 취급됩니다. 부팅 프로세스는 디스크 파티션이 설정되고 부트로더가 있는 베어 메탈(bare metal) 운영 체제의 부팅 프로세스와 비슷하며, 현재 지원되는 모든 Linux 배포판을 사용할 수 있습니다. 가장 일반적인 부트로더는 GRUB 또는 GRUB2입니다.
기본적으로 GRUB는 추가적인 부팅 지연을 발생시키지 않기 위해 인스턴스 콘솔에 출력을 전송하지 않습니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 콘솔 출력](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshoot-unreachable-instance.html#instance-console-console-output)을 참조하세요. 사용자 지정 커널을 설치하는 경우 GRUB 출력을 사용하도록 설정해야 합니다.
대체 커널을 지정할 필요는 없지만, 새 커널을 테스트할 때 대체 커널을 사용하는 것이 권장됩니다. GRUB은 새 커널에 장애가 발생한 경우 다른 커널로 이를 대체하여 사용할 수 있습니다. 대체 커널이 있으면 새 커널이 없는 경우에도 인스턴스가 부팅될 수 있습니다.
Amazon Linux용 레거시 GRUB에서는 `/boot/grub/menu.lst`를 사용하며, AL2용 GRUB2는를 사용합니다`/etc/default/grub`. AL2 부트로더에서 기본 커널을 업데이트하는 방법에 대한 자세한 내용은 해당 Linux 배포판의 설명서를 참조하세요.
## AMIs 반가상화(PV-GRUB)
반가상화(PV) 가상화를 사용하는 AMIs 부팅 프로세스 중에 *PV-GRUB*이라는 시스템을 사용합니다. PV-GRUB는 GNU GRUB 0.97의 패치 버전을 실행하는 반가상화 부트로더입니다. 인스턴스를 실행하면 PV-GRUB가 부팅 과정을 실행하고 이미지의 `menu.lst` 파일에 지정된 커널을 체인로드합니다.
PV-GRUB는 표준 `grub.conf` 또는 `menu.lst` 명령을 이해할 수 있으며 따라서 모든 최신 지원 Linux 배포판과 함께 사용할 수 있습니다. Ubuntu 10.04 LTS, Oracle Enterprise Linux, CentOS 5.x 등 이전 배포판은 특별한 "ec2" 또는 "xen" 커널 패키지를 필요로 하지만, 새 배포판은 필요한 드라이버를 기본 커널 패키지에 포함하고 있습니다.
대부분의 PV(반가상화) AMI는 PV-GRUB AKI를 기본적으로 사용하므로(Amazon EC2 Launch Wizard Start 메뉴에서 제공되는 모든 PV Linux AMI 포함), 사용할 다른 커널이 사용자의 배포판과 호환되는 경우라면 인스턴스에서 해당 커널을 사용하기 위해 별도의 조치를 취할 필요는 없습니다. 인스턴스에서 사용자 지정 커널을 실행하는 최상의 방법은 원하는 것과 가장 근접한 AMI로 시작하여, 인스턴스에서 사용자 지정 커널을 컴파일하고, `menu.lst` 파일을 수정하는 것입니다.
AMI의 커널 이미지가 PV-GRUB AKI인지 확인할 수 있습니다. 다음 [describe-images](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-images.html) 명령(해당 커널 이미지 ID로 대체)을 실행하여 `Name` 필드가 `pv-grub`로 시작하는지 확인합니다.
```
aws ec2 describe-images --filters Name=image-id,Values=aki-880531cd
```
**Topics**
+ [PV-GRUB의 제한 사항](#pv-grub-limitations)
+ [Configuring GRUB](#configuringGRUB)
+ [Amazon PV-GRUB 커널 이미지 ID](#AmazonKernelImageIDs)
+ [PV-GRUB 업데이트](#UpdatingPV-GRUB)
### PV-GRUB의 제한 사항
PV-GRUB에는 다음과 같은 제한 사항이 있습니다.
+ 64비트 버전의 PV-GRUB을 사용해서 32비트 커널을 실행할 수는 없으며, 32비트 버전의 PV-GRUB을 사용해서 64비트 커널을 실행할 수도 없습니다.
+ PV-GRUB AKI를 사용할 때 ARI(Amazon 램디스크 이미지)를 지정할 수 없습니다.
+ AWS 는 PV-GRUB이 EXT2, EXT3, EXT4, JFS, XFS 및 ReiserFS 파일 시스템 형식으로 작동하는지 테스트하고 확인했습니다. 그 밖의 파일 시스템 포맷은 PV-GRUB에서 작동하지 않을 수 있습니다.
+ PV-GRUB은 gzip, bzip2, lzo, xz 압축 포맷을 사용해서 압축된 커널을 부팅시킬 수 있습니다.
+ Cluster AMI는 완전한 HVM(하드웨어 가상 머신)을 사용하기 때문에 PV-GRUB을 지원하지 않으며 이를 필요로 하지도 않습니다. PV(반가상화) 인스턴스는 PV-GRUB을 사용해서 부팅하지만, HVM 인스턴스 볼륨은 실제 디스크처럼 취급되며 그 부팅 과정은 파티션 처리된 디스크와 부트로더가 있는 베어 메탈(bare metal) 운영 체제의 부팅 과정과 유사합니다.
+ PV-GRUB 버전 1.03 및 그 이하 버전은 GPT 파티셔닝을 지원하지 않으며 MBR 파티셔닝만 지원합니다.
+ Amazon Elastic Block Store(Amazon EBS) 볼륨으로 LVM(Logical Volume Manager)를 사용할 계획인 경우, LVM 외부의 개별적인 부트 파티션을 필요로 합니다. 상기 요건이 갖추어지면 LVM으로 논리적 볼륨을 생성할 수 있게 됩니다.
### 반가상화 AMIs대해 GRUB 구성
PV-GRUB을 부팅하려면 이미지 내에 GRUB `menu.lst` 파일이 존재해야 합니다. 이 파일의 가장 일반적인 위치는 `/boot/grub/menu.lst`입니다.
다음은 PV-GRUB AKI로 AMI를 부팅하는 것에 대한 `menu.lst` 구성 파일의 예입니다. 이 예에서는 Amazon Linux 2018.03(이 AMI에 대한 원래 커널) 커널과 Vanilla Linux 4.16.4([https://www.kernel.org/](https://www.kernel.org/)에서 제공되는 Vanilla Linux 커널의 최신 버전) 커널 중에서 선택할 수 있습니다. Vanilla 항목은 해당 AMI에 대한 원래 항목에서 복제된 것이며, `kernel` 및 `initrd` 경로는 새 위치로 업데이트됩니다. `default 0` 파라미터는 부트로더가 발견한 첫 번째 항목(이 경우는 Vanilla 항목)을 참조하게 하고, `fallback 1` 파라미터는 첫 항목 부팅에 문제가 있는 경우 부트로더가 두 번째 항목을 참조하게 합니다.
```
default 0
fallback 1
timeout 0
hiddenmenu
title Vanilla Linux 4.16.4
root (hd0)
kernel /boot/vmlinuz-4.16.4 root=LABEL=/ console=hvc0
initrd /boot/initrd.img-4.16.4
title Amazon Linux 2018.03 (4.14.26-46.32.amzn1.x86_64)
root (hd0)
kernel /boot/vmlinuz-4.14.26-46.32.amzn1.x86_64 root=LABEL=/ console=hvc0
initrd /boot/initramfs-4.14.26-46.32.amzn1.x86_64.img
```
`menu.lst` 파일에서 대체 커널을 지정할 필요는 없지만, 새 커널을 테스트할 때 대체 커널을 사용하는 것이 권장됩니다. PV-GRUB은 새 커널에 장애가 발생한 경우 다른 커널로 이를 대체하여 사용할 수 있습니다. 대체 커널이 있을 경우 인스턴스는 새 커널을 발견할 수 없는 경우에도 부팅할 수 있습니다.
PV-GRUB은 `menu.lst`를 찾기 위해 다음 위치를 검사합니다(발견한 경우 그 이하 경로는 검색 안 함).
+ `(hd0)/boot/grub`
+ `(hd0,0)/boot/grub`
+ `(hd0,0)/grub`
+ `(hd0,1)/boot/grub`
+ `(hd0,1)/grub`
+ `(hd0,2)/boot/grub`
+ `(hd0,2)/grub`
+ `(hd0,3)/boot/grub`
+ `(hd0,3)/grub`
PV-GRUB 1.03 이하 버전은 이 목록에서 첫 2개의 위치만 검색합니다.
### Amazon PV-GRUB 커널 이미지 ID
PV-GRUB AKI는 아시아 태평양(오사카) 리전을 제외한 모든 Amazon EC2 리전에서 제공됩니다. 32비트 및 64비트의 두 아키텍처 유형에 대한 AKI가 존재합니다. 가장 최신의 AMI는 기본적으로 PV-GRUB AKI를 사용합니다.
모든 PV-GRUB 버전이 모든 인스턴스 유형과 호환되는 것은 아니기 때문에, 언제나 PV-GRUB AKI의 최신 버전을 사용하는 것이 권장됩니다. 다음 [describe-images](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-images.html) 명령을 사용하여 현재 리전에 대한 PV-GRUB AKI 목록을 가져옵니다.
```
aws ec2 describe-images --owners amazon --filters Name=name,Values=pv-grub-*.gz
```
PV-GRUB는 `ap-southeast-2` 리전에서만 제공되는 AKI입니다. 사용자가 해당 리전에 복사할 AMI가 해당 리전에서 사용 가능한 PV-GRUB의 버전을 사용하는지를 확인해야 합니다.
다음은 각 리전에 대한 현재 AKI ID입니다. hd0 AKI를 사용해서 새 AMI를 등록할 수 있습니다.
**참고**
hd00 AKI가 이전에 제공되었던 리전의 경우 이전 버전과의 호환성을 위해 hd00 AKI가 계속해서 제공되고 있습니다.
**ap-northeast-1, Asia Pacific (Tokyo)**
| 이미지 ID | 이미지 이름 |
| --- | --- |
| aki-f975a998 | pv-grub-hd0\$11.05-i386.gz |
| aki-7077ab11 | pv-grub-hd0\$11.05-x86\$164.gz |
**ap-southeast-1, Asia Pacific (Singapore) Region**
| 이미지 ID | 이미지 이름 |
| --- | --- |
| aki-17a40074 | pv-grub-hd0\$11.05-i386.gz |
| aki-73a50110 | pv-grub-hd0\$11.05-x86\$164.gz |
**ap-southeast-2, Asia Pacific (Sydney)**
| 이미지 ID | 이미지 이름 |
| --- | --- |
| aki-ba5665d9 | pv-grub-hd0\$11.05-i386.gz |
| aki-66506305 | pv-grub-hd0\$11.05-x86\$164.gz |
**eu-central-1, Europe (Frankfurt)**
| 이미지 ID | 이미지 이름 |
| --- | --- |
| aki-1419e57b | pv-grub-hd0\$11.05-i386.gz |
| aki-931fe3fc | pv-grub-hd0\$11.05-x86\$164.gz |
**eu-west-1, Europe (Ireland)**
| 이미지 ID | 이미지 이름 |
| --- | --- |
| aki-1c9fd86f | pv-grub-hd0\$11.05-i386.gz |
| aki-dc9ed9af | pv-grub-hd0\$11.05-x86\$164.gz |
**sa-east-1, South America (São Paulo)**
| 이미지 ID | 이미지 이름 |
| --- | --- |
| aki-7cd34110 | pv-grub-hd0\$11.05-i386.gz |
| aki-912fbcfd | pv-grub-hd0\$11.05-x86\$164.gz |
**us-east-1, US East (N. Virginia)**
| 이미지 ID | 이미지 이름 |
| --- | --- |
| aki-04206613 | pv-grub-hd0\$11.05-i386.gz |
| aki-5c21674b | pv-grub-hd0\$11.05-x86\$164.gz |
**us-gov-west-1, AWS GovCloud(미국 서부)**
| 이미지 ID | 이미지 이름 |
| --- | --- |
| aki-5ee9573f | pv-grub-hd0\$11.05-i386.gz |
| aki-9ee55bff | pv-grub-hd0\$11.05-x86\$164.gz |
**us-west-1, US West (N. California)**
| 이미지 ID | 이미지 이름 |
| --- | --- |
| aki-43cf8123 | pv-grub-hd0\$11.05-i386.gz |
| aki-59cc8239 | pv-grub-hd0\$11.05-x86\$164.gz |
**us-west-2, US West (Oregon)**
| 이미지 ID | 이미지 이름 |
| --- | --- |
| aki-7a69931a | pv-grub-hd0\$11.05-i386.gz |
| aki-70cb0e10 | pv-grub-hd0\$11.05-x86\$164.gz |
### PV-GRUB 업데이트
모든 PV-GRUB 버전이 모든 인스턴스 유형과 호환되는 것은 아니기 때문에, 언제나 PV-GRUB AKI의 최신 버전을 사용하는 것이 권장됩니다. 또한 PV-GRUB의 이전 버전이 모든 리전에서 사용 가능한 것은 아니므로, 이전 버전을 사용하는 AMI를 해당 버전을 지원하지 않는 리전으로 복사한 경우는 커널 이미지를 업데이트할 때까지 AMI에서 실행된 인스턴스를 부팅시킬 수 없습니다. 다음 절차를 사용해 PV-GRUB의 인스턴스 버전을 확인하고 필요한 경우 업데이트를 하세요.
**PV-GRUB 버전 확인 방법**
1. 인스턴스에 대한 커널 ID를 찾습니다.
```
aws ec2 describe-instance-attribute --instance-id instance_id --attribute kernel --region region
{
"InstanceId": "instance_id",
"KernelId": "aki-70cb0e10"
}
```
이 인스턴스에 대한 커널 ID는 `aki-70cb0e10`입니다.
1. 해당 커널 ID의 버전 정보를 확인합니다.
```
aws ec2 describe-images --image-ids aki-70cb0e10 --region region
{
"Images": [
{
"VirtualizationType": "paravirtual",
"Name": "pv-grub-hd0_1.05-x86_64.gz",
...
"Description": "PV-GRUB release 1.05, 64-bit"
}
]
}
```
여기서 커널 이미지는 PV-GRUB 1.05입니다. 사용자의 PV-GRUB 버전이 최신 버전이 아닌 경우([Amazon PV-GRUB 커널 이미지 ID](#AmazonKernelImageIDs)에서 확인 가능), 다음 절차를 사용하여 이를 업데이트해야 합니다.
**PV-GRUB 버전 업데이트 방법**
인스턴스가 PV-GRUB의 이전 버전을 사용하는 경우, 이를 최신 버전으로 업데이트해야 합니다.
1. [Amazon PV-GRUB 커널 이미지 ID](#AmazonKernelImageIDs)에서 리전 및 프로세스 아키텍처에 대한 최신 PV-GRUB AKI를 확인합니다.
1. 인스턴스를 중단합니다. 사용하고 있는 커널 이미지를 수정하려면 인스턴스를 중단할 필요가 있습니다.
```
aws ec2 stop-instances --instance-ids instance_id --region region
```
1. 인스턴스에 대해 사용되는 커널 이미지를 수정합니다.
```
aws ec2 modify-instance-attribute --instance-id instance_id --kernel kernel_id --region region
```
1. 인스턴스를 재시작합니다.
```
aws ec2 start-instances --instance-ids instance_id --region region
```
# AL2 AMI 릴리스 알림
최신 Amazon Linux AMI가 배포될 때 알림을 받으려면 Amazon SNS를 사용하여 구독할 수 있습니다.
AL2023 알림 구독에 대한 자세한 내용은 Amazon Linux 2023 사용 설명서의 [새 업데이트에 대한 알림 수신](https://docs.aws.amazon.com/linux/al2023/ug/receive-update-notification.html)을 참조하세요. **
**참고**
AL1에 대한 표준 지원은 2020년 12월 31일에 종료되었습니다. AL1 유지 관리 지원 단계는 2023년 12월 31일에 종료되었습니다. AL1 EOL 및 유지 관리 지원에 대한 자세한 내용은 블로그 게시물 [Update on Amazon Linux AMI end-of-life](https://aws.amazon.com/blogs/aws/update-on-amazon-linux-ami-end-of-life/)를 참조하세요.
**Amazon Linux 알림을 구독하려면**
1. [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home)에서 Amazon SNS 콘솔을 엽니다.
1. 필요한 경우 탐색 모음에서 리전을 **미국 동부(버지니아 북부)**로 변경합니다. 구독하려는 SNS 알림이 생성된 리전을 선택해야 합니다.
1. 탐색 창에서 **구독**과 **구독 생성**을 선택합니다.
1. **구독 생성** 대화 상자에서 다음과 같이 수행합니다.
1. [AL2] **주제 ARN**에서 다음 Amazon 리소스 이름(ARN)을 복사하여 붙여 넣습니다**arn:aws:sns:us-east-1:137112412989:amazon-linux-2-ami-updates**.
1. [Amazon Linux] **주제 ARN**의 경우, 다음 Amazon 리소스 이름(ARN)을 복사합니다. **arn:aws:sns:us-east-1:137112412989:amazon-linux-ami-updates**.
1. **프로토콜**에서 **이메일**을 선택합니다.
1. **엔드포인트**에 알림 받을 이메일 주소를 입력합니다.
1. **Create subscription**을 선택합니다.
1. "AWS 알림 - 구독 확인"이라는 제목의 확인 이메일을 받게 됩니다. 이메일을 열고 **구독 확인**을 선택하여 구독을 완료합니다.
AMI가 릴리스될 때마다, 해당 주제의 구독자에게 알림이 발송됩니다. 이 알림을 수신하지 않으려면 다음 절차를 수행하여 구독 해제합니다.
**Amazon Linux 알림을 구독 해제하려면**
1. [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home)에서 Amazon SNS 콘솔을 엽니다.
1. 필요한 경우 탐색 모음에서 리전을 **미국 동부(버지니아 북부)**로 변경합니다. SNS 알림이 생성된 리전을 사용해야 합니다.
1. 탐색 창에서 **구독**을 선택하고 해당 구독을 선택한 후 **작업**, **구독 삭제**를 선택합니다.
1. 확인 메시지가 나타나면 **삭제**를 선택합니다.
**Amazon Linux AMI SNS 메시지 형식**
SNS 메시지의 스키마는 다음과 같습니다.
```
{
"description": "Validates output from AMI Release SNS message",
"type": "object",
"properties": {
"v1": {
"type": "object",
"properties": {
"ReleaseVersion": {
"description": "Major release (ex. 2018.03)",
"type": "string"
},
"ImageVersion": {
"description": "Full release (ex. 2018.03.0.20180412)",
"type": "string"
},
"ReleaseNotes": {
"description": "Human-readable string with extra information",
"type": "string"
},
"Regions": {
"type": "object",
"description": "Each key will be a region name (ex. us-east-1)",
"additionalProperties": {
"type": "array",
"items": {
"type": "object",
"properties": {
"Name": {
"description": "AMI Name (ex. amzn-ami-hvm-2018.03.0.20180412-x86_64-gp2)",
"type": "string"
},
"ImageId": {
"description": "AMI Name (ex.ami-467ca739)",
"type": "string"
}
},
"required": [
"Name",
"ImageId"
]
}
}
}
},
"required": [
"ReleaseVersion",
"ImageVersion",
"ReleaseNotes",
"Regions"
]
}
},
"required": [
"v1"
]
}
```
# AL2 MATE 데스크톱 연결 구성
[MATE 데스크톱 환경](https://mate-desktop.org/)은 다음 설명과 함께 AMI에 사전 설치 및 사전 구성됩니다.
"`.NET Core x.x, Mono x.xx, PowerShell x.x, and MATE DE pre-installed to run your .NET applications on Amazon Linux 2 with Long Term Support (LTS).`"
환경은 명령줄을 최소한으로 사용하여 AL2 인스턴스를 관리하기 위한 직관적인 그래픽 사용자 인터페이스를 제공합니다. 인터페이스에는 아이콘, 창, 도구 모음, 폴더, 배경 화면 및 바탕 화면 위젯과 같은 그래픽 표현이 사용됩니다. 기본 제공 GUI 기반 도구를 사용하여 일반적인 작업을 수행할 수 있습니다. 예를 들어 소프트웨어 추가 및 제거, 업데이트 적용, 파일 구성, 프로그램 시작 및 시스템 상태 모니터링을 위한 도구가 있습니다.
**중요**
`xrdp`는 AMI에 번들로 제공되는 원격 데스크톱 소프트웨어입니다. 기본적으로 `xrdp`는 자체 서명된 TLS 인증서를 사용하여 원격 데스크톱 세션을 암호화합니다. AWS 도 `xrdp` 유지 관리자도 프로덕션 환경에서 자체 서명된 인증서를 사용하지 않는 것이 좋습니다. 대신 적절한 CA(인증 기관)에서 인증서를 가져와 인스턴스에 설치합니다. TLS 구성에 대한 자세한 내용은 `xrdp` wiki의 [TLS 보안 계층](https://github.com/neutrinolabs/xrdp/wiki/TLS-security-layer)을 참조하세요.
**참고**
xrdp 대신 가상 네트워크 컴퓨팅(VNC) 서비스를 사용하려면 [AL2Knowledge Center를 실행하는 Amazon EC2 인스턴스에 GUI를 설치하려면 어떻게 해야 합니까](https://repost.aws/knowledge-center/ec2-linux-2-install-gui) AWS ? 문서를 참조하세요.
## 사전 조건
이 주제에 표시된 명령을 실행하려면 AWS Command Line Interface (AWS CLI) 또는를 설치하고 AWS 프로필을 AWS Tools for Windows PowerShell구성해야 합니다.
**옵션**
1. 설치 AWS CLI - 자세한 내용은 *AWS Command Line Interface 사용 설명서*[의 설치 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-set-up.html) 및 [구성 기본 사항을 참조하세요](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html).
1. Tools for Windows PowerShell 설치 - 자세한 내용은 *AWS Tools for PowerShell 사용 설명서*에서 [AWS Tools for Windows PowerShell설치](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html) 및 [공유 자격 증명](https://docs.aws.amazon.com/powershell/latest/userguide/shared-credentials-in-aws-powershell.html)을 참조하세요.
**작은 정보**
의 전체 설치를 수행하는 대신 AWS CLI에서 직접 시작하는 브라우저 기반 사전 인증된 [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) 쉘에를 사용할 수 있습니다 AWS Management Console. [지원되는 AWS 리전](https://docs.aws.amazon.com/cloudshell/latest/userguide/supported-aws-regions.html)를 확인하여 작업 중인 리전에서 사용할 수 있는지 확인합니다.
## RDP 연결 구성
다음 단계에 따라 로컬 시스템에서 MATE 데스크톱 환경을 실행하는 AL2 인스턴스로의 RDP(원격 데스크톱 프로토콜) 연결을 설정합니다.
1. AMI 이름에 MATE가 포함된 AL2용 AMI의 ID를 가져오려면 로컬 명령줄 도구에서 [describe-images](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-images.html) 명령을 사용할 수 있습니다. 명령줄 도구를 설치하지 않은 경우 AWS CloudShell 세션에서 직접 다음 쿼리를 수행할 수 있습니다. CloudShell에서 셸 세션을 시작하는 방법에 대한 정보는 [AWS CloudShell로 시작하기](https://docs.aws.amazon.com/cloudshell/latest/userguide/getting-started.html)를 참조하세요. Amazon EC2 콘솔에서 인스턴스를 시작하고 AMI 검색 창에 `MATE`를 입력하여 MATE 포함 AMI를 찾을 수 있습니다. MATE가 사전 설치된 AL2 퀵 스타트가 검색 결과에 표시됩니다.
```
aws ec2 describe-images --filters "Name=name,Values=amzn2*MATE*" --query "Images[*].[ImageId,Name,Description]"
[
[
"ami-0123example0abc12",
"amzn2-x86_64-MATEDE_DOTNET-2020.12.04",
".NET Core 5.0, Mono 6.12, PowerShell 7.1, and MATE DE pre-installed to run your .NET applications on Amazon Linux 2 with Long Term Support (LTS)."
],
[
"ami-0456example0def34",
"amzn2-x86_64-MATEDE_DOTNET-2020.04.14",
"Amazon Linux 2 with .Net Core, PowerShell, Mono, and MATE Desktop Environment"
]
]
```
사용하기에 적합한 AMI를 선택합니다.
1. 이전 단계에서 찾은 AMI로 EC2 인스턴스를 시작합니다. 포트 3389로의 인바운드 TCP 트래픽을 허용하도록 보안 그룹을 구성합니다. 보안 그룹 구성에 대한 자세한 내용은 [VPC의 보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)을 참조하세요. 이 구성을 사용하면 RDP 클라이언트를 사용하여 인스턴스에 연결할 수 있습니다.
1. [SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html)를 이용해 인스턴스에 연결합니다.
1. 인스턴스의 소프트웨어 및 커널을 업데이트하세요.
```
[ec2-user ~]$ sudo yum update
```
업데이트가 완료되면 인스턴스를 재부팅하여 업데이트에서 최신 패키지 및 라이브러리를 사용 중인지를 확인합니다. 커널 업데이트를 로드하려면 재부팅해야 합니다.
```
[ec2-user ~]$ sudo reboot
```
1. 인스턴스에 다시 연결하고 Linux 인스턴스에서 다음 명령을 실행하여 `ec2-user`의 암호를 설정하세요.
```
[ec2-user ~]$ sudo passwd ec2-user
```
1. 인증서와 키를 설치합니다.
인증서와 키가 이미 있는 경우 다음과 같이 `/etc/xrdp/` 디렉터리에 복사합니다.
+ 인증서 - `/etc/xrdp/cert.pem`
+ 키 - `/etc/xrdp/key.pem`
인증서와 키가 없는 경우 다음 명령을 사용하여 `/etc/xrdp` 디렉터리에 생성합니다.
```
$ sudo openssl req -x509 -sha384 -newkey rsa:3072 -nodes -keyout /etc/xrdp/key.pem -out /etc/xrdp/cert.pem -days 365
```
**참고**
이 명령은 365일간 유효한 인증서를 생성합니다.
1. 인스턴스에 연결할 컴퓨터에서 RDP 클라이언트를 엽니다(예: Microsoft Windows를 실행하는 컴퓨터에서 원격 데스크톱 연결). 사용자 이름으로 `ec2-user`를 입력하고 이전 단계에서 설정한 암호를 입력합니다.
**Amazon EC2 인스턴스에서 `xrdp`를 비활성화하려면**
Linux 인스턴스에서 다음의 명령 중 하나를 실행하여 언제든 `xrdp`를 비활성화할 수 있습니다. 다음의 명령은 X11 서버로 MATE를 사용하는 능력에 영향을 주지 않습니다.
```
[ec2-user ~]$ sudo systemctl disable xrdp
```
```
[ec2-user ~]$ sudo systemctl stop xrdp
```
**Amazon EC2 인스턴스에서 `xrdp`를 활성화하려면**
MATE 데스크톱 환경을 실행하는 AL2 인스턴스에 연결할 수 `xrdp` 있도록 다시 활성화하려면 Linux 인스턴스에서 다음 명령 중 하나를 실행합니다.
```
[ec2-user ~]$ sudo systemctl enable xrdp
```
```
[ec2-user ~]$ sudo systemctl start xrdp
```
# AL2 자습서
다음 자습서에서는 AL2를 실행하는 Amazon EC2 인스턴스를 사용하여 일반적인 작업을 수행하는 방법을 보여줍니다. 동영상 자습서는 [AWS 교육 동영상 및 실습](https://www.aws.training/) 섹션을 참조하세요.
AL2023 지침은 *Amazon Linux 2023 사용 설명서의 *[자습](https://docs.aws.amazon.com/linux/al2023/ug/tutorials-al2023.html)서를 참조하세요.
**Topics**
+ [자습서: AL2에 LAMP 서버 설치](ec2-lamp-amazon-linux-2.md)
+ [자습서: AL2에서 SSL/TLS 구성](SSL-on-amazon-linux-2.md)
+ [자습서: AL2에서 WordPress 블로그 호스팅](hosting-wordpress.md)
# 자습서: AL2에 LAMP 서버 설치
다음 절차는 AL2 인스턴스(LAMP 웹 서버 또는 LAMP 스택이라고도 함)에 PHP 및 [MariaDB](https://mariadb.org/about/)(MySQL의 커뮤니티 개발 포크) 지원이 포함된 Apache 웹 서버를 설치하는 데 도움이 됩니다. 이 서버를 사용해서 고정 웹사이트를 호스팅하거나 데이터베이스에서 정보를 읽고 쓰는 동적 PHP 애플리케이션을 배포할 수 있습니다.
**중요**
Ubuntu 또는 Red Hat Enterprise, Linux와 같은 다른 배포에서 LAMP 웹 서버를 설정하려는 경우 이 자습서를 이용할 수 없습니다. AL2023의 경우 [AL2023에 LAMP 서버 설치를 참조하세요](https://docs.aws.amazon.com//linux/al2023/ug/ec2-lamp-amazon-linux-2023.html). Ubuntu의 경우 Ubuntu 커뮤니티 설명서 [ApacheMySQLPHP](https://help.ubuntu.com/community/ApacheMySQLPHP)를 참조하세요. 다른 배포는 관련 설명서를 참조하세요.
**옵션: 자동화를 사용하여 이 자습서 완료**
다음 작업 대신 AWS Systems Manager 자동화를 사용하여이 자습서를 완료하려면 [AWS Docs-InstallALAMPServer-AL2](https://console.aws.amazon.com/systems-manager/automation/execute/AWSDocs-InstallALAMPServer-AL2) 자동화 문서를 실행합니다.
**Topics**
+ [1단계: LAMP 서버 준비](#prepare-lamp-server)
+ [2단계: LAMP 서버 테스트](#test-lamp-server)
+ [3단계: 데이터베이스 서버 보안 설정](#secure-mariadb-lamp-server)
+ [4단계: (선택 사항) phpMyAdmin 설치](#install-phpmyadmin-lamp-server)
+ [문제 해결](#lamp-troubleshooting)
+ [관련 주제](#lamp-more-info)
## 1단계: LAMP 서버 준비
**사전 조건**
+ 이 자습서에서는 인터넷에서 연결할 수 있는 퍼블릭 DNS 이름으로 AL2를 사용하여 새 인스턴스를 이미 시작했다고 가정합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 시작](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html)을 참조하세요. SSH(포트 22), HTTP(포트 80), HTTPS(포트 443) 연결을 허용할 수 있도록 보안 그룹을 구성해야 합니다. 이러한 사전 조건에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [보안 그룹 규칙을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html) 참조하세요.
+ 다음 절차에서는 현재 AL2에서 사용할 수 있는 최신 PHP 버전을 설치합니다`php8.2`. 이 자습서에서 명시한 애플리케이션이 아닌 PHP 애플리케이션을 사용하려는 경우 `php8.2`와의 호환성을 확인해야 합니다.
**LAMP 서버를 준비하려면**
1. [인스턴스에 연결합니다](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html).
1. 모든 소프트웨어 패키지가 최신 상태로 업데이트되어 있는지 확인하기 위해, 인스턴스에서 퀵 소프트웨어 업데이트를 실행합니다. 이 업데이트 과정은 몇 분 정도 시간이 소요될 수 있지만, 최신 보안 업데이트와 버그 수정을 위해 수행할 필요가 있습니다.
`-y` 옵션을 사용하면 확인 여부를 묻지 않고 업데이트를 설치합니다. 설치 전에 업데이트 정보를 확인하려면 이 옵션을 생략합니다.
```
[ec2-user ~]$ sudo yum update -y
```
1. `mariadb10.5` Amazon Linux Extras 리포지토리를 설치하여 최신 버전의 MariaDB 패키지를 가져옵니다.
```
[ec2-user ~]$ sudo amazon-linux-extras install mariadb10.5
```
`sudo: amazon-linux-extras: command not found` 오류가 발생하면 인스턴스가 Amazon Linux 2 AMI로 실행되지 않은 것입니다(Amazon Linux AMI를 사용하고 있는 것일 수 있음). 다음 명령을 사용하여 Amazon Linux 버전을 볼 수 있습니다.
```
cat /etc/system-release
```
1. `php8.2` Amazon Linux Extras 리포지토리를 설치하여 AL2용 PHP 패키지의 최신 버전을 가져옵니다.
```
[ec2-user ~]$ sudo amazon-linux-extras install php8.2
```
1. 이제 인스턴스가 최신 상태이므로 Apache 웹 서버, MariaDB 및 PHP 소프트웨어 패키지를 설치할 수 있습니다. yum install 명령을 사용하여 여러 소프트웨어 패키지와 모든 관련 종속 프로그램을 동시에 설치합니다.
```
[ec2-user ~]$ sudo yum install -y httpd
```
다음 명령을 사용하여 이러한 패키지의 현재 버전을 볼 수 있습니다.
```
yum info package_name
```
1. Apache 웹 서버를 시작합니다.
```
[ec2-user ~]$ sudo systemctl start httpd
```
1. **systemctl** 명령을 사용하여 Apache 웹 서버가 매번 시스템이 부팅할 때마다 시작되도록 합니다.
```
[ec2-user ~]$ sudo systemctl enable httpd
```
다음 명령을 실행하여 **httpd**가 실행되고 있는지 확인할 수 있습니다.
```
[ec2-user ~]$ sudo systemctl is-enabled httpd
```
1. 인스턴스에 대해 인바운드 HTTP(포트 80) 연결을 허용하는 보안 규칙이 없는 경우 추가합니다. 기본적으로 초기화 중에 인스턴스에 대해 **launch-wizard-*N*** 보안 그룹이 설정됩니다. 이 그룹에는 SSH 연결을 허용하는 규칙이 한 개 들어 있습니다.
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. **인스턴스**를 선택하고 해당 인스턴스를 선택합니다.
1. **보안** 탭에서 인바운드 규칙을 확인합니다. 다음과 같은 규칙이 표시되어야 합니다.
```
Port range Protocol Source
22 tcp 0.0.0.0/0
```
**주의**
`0.0.0.0/0`을 사용하면 모든 IP 주소에서 SSH를 사용하여 인스턴스에 액세스할 수 있습니다. 테스트 환경에서 잠시 사용하는 것은 괜찮지만 프로덕션 환경에서는 안전하지 않습니다. 프로덕션에서는 특정 IP 주소나 주소 범위만 인스턴스에 액세스하도록 허용하세요.
1. 보안 그룹에 대한 링크를 선택합니다. [보안 그룹에 규칙 추가](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule)의 절차에 따라 다음 값을 사용하여 새 인바운드 보안 규칙을 추가합니다.
+ **유형**: HTTP
+ **프로토콜**: TCP
+ **포트 범위**: 80
+ **소스**: 사용자 지정
1. 웹 서버를 테스트합니다. 웹 브라우저에서 인스턴스의 공용 DNS 주소(또는 공용 IP 주소)를 입력합니다. `/var/www/html`에 콘텐츠가 없으면 Apache 테스트 페이지가 표시됩니다. Amazon EC2 콘솔을 사용하여 인스턴스의 퍼블릭 DNS를 확인할 수 있습니다. **퍼블릭 DNS** 열을 확인합니다. 이 열이 숨겨진 경우 **열 표시/숨기기** 아이콘(기어 모양 아이콘)을 선택하고 **퍼블릭 DNS**를 선택합니다.
인스턴스의 보안 그룹에 포트 80에서 HTTP 트래픽을 허용하는 규칙이 포함되어 있는지 확인합니다. 자세한 내용은 [보안 그룹 규칙 추가](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) 섹션을 참조하세요.
**중요**
Amazon Linux을 사용하지 않는 경우, 이러한 연결을 허용하도록 인스턴스의 방화벽을 구성할 필요가 있습니다. 방화벽 구성 방법에 대한 자세한 내용은 사용자의 특정 배포에 대한 문서를 참조하세요.
![\[서버를 테스트하면 Apache 테스트 페이지가 표시됩니다.\]](http://docs.aws.amazon.com/ko_kr/linux/al2/ug/images/apache_test_page_al2_2.4.png)
Apache **httpd**는 Apache document root라는 디렉터리에 보관된 파일을 처리합니다. Amazon Linux Apache 문서 루트는 `/var/www/html`이며, 기본적으로 루트에서 소유합니다.
`ec2-user` 계정에서 이 디렉터리의 파일을 조작할 수 있게 하려면 디렉터리의 소유권과 권한을 변경해야 합니다. 이 작업을 수행하는 방법에는 여러 가지가 있습니다. 본 자습서에서는 `ec2-user`를 `apache` 그룹에 추가하여 `apache` 그룹에 `/var/www` 디렉터리의 소유권을 부여하고 쓰기 권한을 할당합니다.
**파일 권한 설정**
1. 사용자(이 경우는 `ec2-user`)를 `apache` 그룹에 추가합니다.
```
[ec2-user ~]$ sudo usermod -a -G apache ec2-user
```
1. 로그아웃하고 다시 로그인한 다음, 새 그룹을 선택하고 멤버십을 확인합니다.
1. 로그아웃합니다(**exit** 명령을 사용하거나 터미널 창 닫기).
```
[ec2-user ~]$ exit
```
1. `apache` 그룹의 멤버십을 확인하려면 인스턴스에 다시 연결한 후 다음 명령을 실행합니다.
```
[ec2-user ~]$ groups
ec2-user adm wheel apache systemd-journal
```
1. `/var/www` 및 그 콘텐츠의 그룹 소유권을 `apache` 그룹으로 변경합니다.
```
[ec2-user ~]$ sudo chown -R ec2-user:apache /var/www
```
1. 그룹 쓰기 권한을 추가하여 나중에 하위 디렉터리에 대한 그룹 ID를 설정하려면 `/var/www`와 그 하위 디렉터리의 디렉터리 권한을 변경합니다.
```
[ec2-user ~]$ sudo chmod 2775 /var/www && find /var/www -type d -exec sudo chmod 2775 {} \;
```
1. 그룹 쓰기 권한을 추가하려면 `/var/www` 및 그 하위 디렉터리의 파일 권한을 반복하여 변경합니다.
```
[ec2-user ~]$ find /var/www -type f -exec sudo chmod 0664 {} \;
```
이제 `ec2-user`와 `apache` 그룹의 향후 멤버는 Apache document root에서 파일 추가, 삭제, 편집을 할 수 있고, 이를 통해 사용자는 정적 웹 사이트 또는 PHP 애플리케이션과 같은 콘텐츠를 추가할 수 있습니다.
**웹 서버를 보호하려면(선택 사항)**
HTTP 프로토콜을 실행하는 웹 서버는 송신하거나 수신하는 데이터에 대해 아무런 전송 보안 기능도 제공하지 않습니다. 웹 브라우저를 사용하여 HTTP 서버에 연결할 때 방문하는 URL, 수신하는 웹 페이지의 내용, 제출하는 HTML 양식의 내용(암호 포함)이 모두 네트워크 경로를 따라 어디서든 엿보려는 사람들에게 보입니다. 웹 서버를 안전하게 보호하기 위한 최선의 방법은 SSL/TLS 암호화로 데이터를 보호하는 HTTPS(HTTP Secure) 지원 기능을 설치하는 것입니다.
서버에서 HTTPS를 활성화하는 방법에 대한 자세한 내용은 [자습서: AL2에서 SSL/TLS 구성](SSL-on-amazon-linux-2.md) 섹션을 참조하세요.
## 2단계: LAMP 서버 테스트
서버가 설치되어 실행 중이고 파일 권한이 올바르게 설정되었다면 사용자의 `ec2-user` 계정을 통해 인터넷에서 사용 가능한 `/var/www/html` 디렉터리에서 PHP 파일을 생성할 수 있어야 합니다.
**LAMP 서버를 테스트하려면**
1. Apache 문서 루트에서 PHP 파일을 생성합니다.
```
[ec2-user ~]$ echo "" > /var/www/html/phpinfo.php
```
이 명령을 실행하는 동안 "Permission denied" 오류가 발생하면, 로그아웃하고 다시 로그인한 다음, [파일 권한 설정](#setting-file-permissions-2)에서 구성한 적절한 그룹 권한을 선택합니다.
1. 웹 브라우저에서는 방금 생성한 파일의 URL을 입력합니다. 이 URL은 인스턴스의 퍼블릭 DNS 주소에 슬래시(/)와 파일 이름이 추가된 형태입니다. 다음 예를 참조하세요.
```
http://my.public.dns.amazonaws.com/phpinfo.php
```
PHP 정보 페이지가 표시되어야 합니다:
![\[LAMP 서버를 테스트하면 PHP 정보 페이지가 표시됩니다.\]](http://docs.aws.amazon.com/ko_kr/linux/al2/ug/images/phpinfo7.2.10.png)
이 페이지가 보이지 않을 경우 이전 단계에서 `/var/www/html/phpinfo.php` 파일이 제대로 생성되었는지 확인하세요. 또한 다음 명령을 사용하여 필수 패키지가 모두 설치되었는지도 확인할 수 있습니다.
```
[ec2-user ~]$ sudo yum list installed httpd mariadb-server php-mysqlnd
```
출력에서 필요한 패키지가 하나라도 나열되지 않으면, **sudo yum install *package*** 명령을 사용하여 패키지를 설치합니다. `php7.2` 및 `lamp-mariadb10.2-php7.2` extra가 **amazon-linux-extras** 명령의 출력에서 활성화되는지도 확인합니다.
1. `phpinfo.php` 파일을 삭제합니다. 이 파일은 유용한 정보를 포함하고 있지만 보안상 이유로 인터넷에 공개되어서는 안 됩니다.
```
[ec2-user ~]$ rm /var/www/html/phpinfo.php
```
이제 LAMP 웹 서버가 완전히 동작하는 상태가 됩니다. `/var/www/html`의 Apache document root에 콘텐츠를 추가하면 인스턴스에 대한 퍼블릭 DNS 주소에서 그 콘텐츠를 볼 수 있습니다.
## 3단계: 데이터베이스 서버 보안 설정
MariaDB 서버의 기본 설치는 테스트 및 개발 기능에 유용한 여러 기능을 포함하고 있지만, 이 기능들은 프로덕션 서버에서는 비활성화되거나 제거되어야 합니다. **mysql\$1secure\$1installation** 명령을 통해 루트 암호를 설정하고 설치 패키지에서 보안성이 낮은 기능을 제거하는 과정을 수행할 수 있습니다. MariaDB 서버를 사용할 계획이 없더라도 이 절차를 수행하는 것이 좋습니다.
**MariaDB 서버의 보안을 유지하려면**
1. MariaDB 서버를 시작합니다.
```
[ec2-user ~]$ sudo systemctl start mariadb
```
1. **mysql\$1secure\$1installation**를 실행합니다.
```
[ec2-user ~]$ sudo mysql_secure_installation
```
1. 암호를 입력하라는 메시지가 표시되면 루트 계정의 암호를 입력합니다.
1. 현재 루트 암호를 입력합니다. 기본적으로 root 계정에는 암호가 없습니다. Enter를 누릅니다.
1. 암호를 설정하려면 **Y**를 누른 후 안전한 암호를 두 번 입력합니다. 보안 암호 생성에 대한 자세한 내용은 [https://identitysafe.norton.com/password-generator/](https://identitysafe.norton.com/password-generator/) 섹션을 참조하세요. 이 암호를 안전한 장소에 보관하시기 바랍니다.
MariaDB에 대한 루트 암호를 설정하는 것은 데이터베이스를 보호하는 가장 기초적인 방법일 뿐입니다. 데이터베이스 기반 애플리케이션을 빌드하거나 설치할 때, 일반적으로 그 애플리케이션의 데이터베이스 서비스 사용자를 만들고 데이터베이스 관리 이외의 어떤 목적으로도 루트 계정을 사용하지 못하게 합니다.
1. **Y**를 눌러서 익명 사용자 계정을 제거합니다.
1. **Y**를 입력하여 원격 루트 로그인을 비활성화합니다.
1. **Y**를 눌러서 테스트 데이터베이스를 제거합니다.
1. **Y**를 눌러서 권한 테이블을 다시 로드하고 변경사항을 저장합니다.
1. (선택 사항) 지금 바로 사용할 계획이 아니라면 MariaDB 서버를 중지합니다. 필요할 때 다시 시작할 수 있습니다.
```
[ec2-user ~]$ sudo systemctl stop mariadb
```
1. (선택 사항) 부팅 시 MariaDB 서버가 시작되도록 하려면 다음 명령을 입력합니다.
```
[ec2-user ~]$ sudo systemctl enable mariadb
```
## 4단계: (선택 사항) phpMyAdmin 설치
[phpMyAdmin](https://www.phpmyadmin.net/)은 EC2 인스턴스의 MySQL 데이터베이스를 보고 편집하는 데 사용할 수 있는 웹 기반 데이터베이스 관리 도구입니다. Amazon Linux 인스턴스에서 `phpMyAdmin`을 설치 및 구성하려면 다음 단계를 따르세요.
**중요**
Apache에서 SSL/TLS를 활성화하지 않은 경우 `phpMyAdmin`을 사용하여 LAMP 서버에 액세스하지 않는 것이 좋습니다. 이 상태에서 액세스하면 데이터베이스 관리자 암호와 기타 데이터가 인터넷을 통해 안전하지 못한 상태로 전송됩니다. 개발자의 보안 권장 사항을 보려면 [phpMyAdmin 설치 보안](https://docs.phpmyadmin.net/en/latest/setup.html#securing-your-phpmyadmin-installation)을 참조하세요. EC2 인스턴스에서의 웹 서버 보안에 대한 일반적인 정보는 [자습서: AL2에서 SSL/TLS 구성](SSL-on-amazon-linux-2.md) 섹션을 참조하세요.
**phpMyAdmin을 설치하려면**
1. 필요한 종속 항목을 설치합니다.
```
[ec2-user ~]$ sudo yum install php-mbstring php-xml -y
```
1. Apache를 다시 시작합니다.
```
[ec2-user ~]$ sudo systemctl restart httpd
```
1. `php-fpm`을 다시 시작합니다.
```
[ec2-user ~]$ sudo systemctl restart php-fpm
```
1. Apache 문서 루트(`/var/www/html`)로 이동합니다.
```
[ec2-user ~]$ cd /var/www/html
```
1. [https://www.phpmyadmin.net/downloads](https://www.phpmyadmin.net/downloads)에서 phpMyAdmin 최신 릴리스의 소스 패키지를 선택합니다. 인스턴스로 파일을 직접 다운로드하려면 다음 예제와 같이 링크를 복사한 후 **wget** 명령에 붙여 넣습니다.
```
[ec2-user html]$ wget https://www.phpmyadmin.net/downloads/phpMyAdmin-latest-all-languages.tar.gz
```
1. `phpMyAdmin` 폴더를 생성하고 다음 명령을 사용하여 해당 폴더로 패키지의 압축을 풉니다.
```
[ec2-user html]$ mkdir phpMyAdmin && tar -xvzf phpMyAdmin-latest-all-languages.tar.gz -C phpMyAdmin --strip-components 1
```
1. *phpMyAdmin-latest-all-languages.tar.gz* tarball을 삭제합니다.
```
[ec2-user html]$ rm phpMyAdmin-latest-all-languages.tar.gz
```
1. (선택 사항) MySQL 서버가 실행 중이지 않으면 지금 시작합니다.
```
[ec2-user ~]$ sudo systemctl start mariadb
```
1. 웹 브라우저에서 phpMyAdmin 설치의 URL을 입력합니다. 아래의 예와 같이 이 URL은 인스턴스의 퍼블릭 DNS 주소(또는 퍼블릭 IP 주소)에 슬래시(/)와 설치 디렉터리의 이름이 추가된 형태입니다. 다음 예를 참조하세요.
```
http://my.public.dns.amazonaws.com/phpMyAdmin
```
사용자는 phpMyAdmin 로그인 페이지를 볼 수 있어야 합니다:
![\[phpMyAdmin 설치의 URL을 입력하면 phpMyAdmin 로그인 화면이 나타납니다.\]](http://docs.aws.amazon.com/ko_kr/linux/al2/ug/images/phpmyadmin_login.png)
1. 앞서 만든 `root` 사용자 이름 및 MySQL 루트 암호로 phpMyAdmin 설치에 로그인합니다.
작동하려면 먼저 설치를 구성해야 합니다. 먼저 다음과 같이 구성 파일을 수동으로 작성하는 것이 좋습니다.
1. 최소 구성 파일로 시작하려면 자주 사용하는 텍스트 편집기를 사용하여 새 파일을 생성한 후에 `config.sample.inc.php` 내용을 파일에 복사합니다.
1. 이 파일을 `config.inc.php`가 포함된 phpMyAdmin 디렉토리에 `index.php`로 저장하세요.
1. 추가 설정에 대해서는 phpMyAdmin 설치 지침에서 [설정 스크립트 사용](https://docs.phpmyadmin.net/en/latest/setup.html#using-the-setup-script) 섹션의 파일 생성 후 지침을 참조하세요.
phpMyAdmin에 대한 자세한 내용은 [phpMyAdmin 사용 설명서](http://docs.phpmyadmin.net/en/latest/user.html)를 참조하세요.
## 문제 해결
이 섹션에서는 새 LAMP 서버를 설정하는 동안 발생할 수 있는 일반적인 문제 해결을 위한 제안을 제공합니다.
### 웹 브라우저를 사용하여 서버에 연결할 수 없음
다음을 확인하여 Apache 웹 서버가 실행 중이고 엑세스 가능한지 확인합니다.
+ **웹 서버가 실행되고 있습니까?**
다음 명령을 실행하여 **httpd**가 실행되고 있는지 확인할 수 있습니다.
```
[ec2-user ~]$ sudo systemctl is-enabled httpd
```
**httpd** 프로세스가 실행되지 않는 경우 [LAMP 서버를 준비하려면](#install_apache-2)에 설명된 단계를 반복합니다.
+ **방화벽이 올바르게 구성되었습니까?**
인스턴스의 보안 그룹에 포트 80에서 HTTP 트래픽을 허용하는 규칙이 포함되어 있는지 확인합니다. 자세한 내용은 [보안 그룹 규칙 추가](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) 섹션을 참조하세요.
### HTTPS를 사용하여 서버에 연결할 수 없음
다음 확인을 수행하여 Apache 웹 서버가 HTTPS를 지원하도록 구성되어 있는지 확인합니다.
+ **웹 서버가 올바르게 구성되었습니까?**
Apache를 설치한 후 서버는 HTTP 트래픽에 대해 구성됩니다. HTTPS를 지원하려면 서버에서 TLS를 활성화하고 SSL 인증서를 설치합니다. 자세한 정보는 [자습서: AL2에서 SSL/TLS 구성](SSL-on-amazon-linux-2.md) 섹션을 참조하세요.
+ **방화벽이 올바르게 구성되었습니까?**
인스턴스의 보안 그룹에 포트 443에서 HTTP 트래픽을 허용하는 규칙이 포함되어 있는지 확인합니다. 자세한 내용은 [보안 그룹에 규칙 추가를 참조하세요](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule).
## 관련 주제
파일을 인스턴스에 전송하거나 웹 서버에 WordPress 블로그를 설치하는 것에 대한 자세한 다용은 다음 문서를 참고하세요.
+ [를 사용하여 Linux 인스턴스로 파일을 전송합니다WinSCP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#Transfer_WinSCP).
+ [SCP 클라이언트를 사용하여 Linux 인스턴스로 파일을 전송합니다](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html#linux-file-transfer-scp).
+ [자습서: AL2에서 WordPress 블로그 호스팅](hosting-wordpress.md)
이 자습서에서 사용되는 명령과 소프트웨어에 대한 자세한 내용은 다음 웹 페이지를 확인하세요.
+ Apache 웹 서버: [http://httpd.apache.org/](http://httpd.apache.org/)
+ MariaDB 데이터베이스 서버: [https://mariadb.org/](https://mariadb.org/)
+ PHP 프로그래밍 언어: [http://php.net/](http://php.net/)
+ `chmod` 명령: [https://en.wikipedia.org/wiki/Chmod](https://en.wikipedia.org/wiki/Chmod)
+ `chown` 명령: [https://en.wikipedia.org/wiki/Chown](https://en.wikipedia.org/wiki/Chown)
웹 서버에 대한 도메인 이름을 등록하거나 기존 도메인 이름을 현재 호스트로 이전하는 것에 대한 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [Amazon Route 53에서 도메인 및 하위 도메인 생성 및 마이그레이션](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/creating-migrating.html)을 참조하세요.
# 자습서: AL2에서 SSL/TLS 구성
Secure Sockets Layer/Transport Layer Security(SSL/TLS)는 웹 서버와 웹 클라이언트 간 암호화된 채널을 만들어 전송 중인 데이터가 도청되지 않도록 보호합니다. 이 자습서에서는 AL2 및 Apache 웹 서버가 있는 EC2 인스턴스에서 SSL/TLS에 대한 지원을 수동으로 추가하는 방법을 설명합니다. 이 자습서에서는 로드 밸런서를 사용하고 있지 않다고 가정합니다. Elastic Load Balancing를 사용하는 경우 [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/)의 인증서를 대신 사용하여 로드 밸런서에 SSL 오프로드를 구성하도록 선택할 수 있습니다.
일반적으로 웹 암호화를 단순히 SSL이라고 부릅니다. 웹 브라우저에서 여전히 SSL을 지원하지만, 후속 프로토콜인 TLS가 공격에 덜 취약합니다. AL2는 기본적으로 모든 버전의 SSL에 대한 서버 측 지원을 비활성화합니다. [보안 표준 본문](https://www.ssl.com/article/deprecating-early-tls/)에서는 TLS 1.0이 안전하지 않다고 간주합니다. TLS 1.0 및 TLS 1.1은 2021년 3월에 공식적으로 [사용 중단](https://datatracker.ietf.org/doc/rfc8996/)되었습니다. 이 자습서에서는 TLS 1.2 활성화만을 기반으로 하여 지침을 제공합니다. TLS 1.3은 2018년에 완료되었으며, 기본 TLS 라이브러리(이 자습서의 OpenSSL)가 지원 및 사용 설정되는 한 AL2에서 사용할 수 있습니다. [클라이언트는 2023년 6월 28일까지 TLS 1.2 이상을 지원해야 합니다](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/). 업데이트된 암호화 표준에 대한 자세한 내용은 [RFC 7568](https://tools.ietf.org/html/rfc7568) 및 [RFC 8446](https://tools.ietf.org/html/rfc8446)을 참조하세요.
이 자습서는 현대 웹 암호화를 단순히 TLS로 언급합니다.
**중요**
이 절차는 AL2와 함께 사용하기 위한 것입니다. 또한 사용자가 새 Amazon EC2 인스턴스로 시작한다고 가정합니다. 다른 배포를 실행하는 EC2 인스턴스 또는 이전 버전의 AL2를 실행하는 인스턴스를 설정하려는 경우이 자습서의 일부 절차가 작동하지 않을 수 있습니다. Ubuntu의 경우 커뮤니티 설명서 [Ubuntu에서 SSL 열기](https://help.ubuntu.com/community/OpenSSL)를 참조하십시오. Red Hat Enterprise Linux의 경우 [Apache HTTP 웹 서버 설정](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/setting-apache-http-server_deploying-different-types-of-servers)을 참조하세요. 다른 배포는 관련 설명서를 참조하세요.
**참고**
또는 AWS Nitro Enclaves를 사용하여 Amazon EC2 인스턴스에서 실행되는 웹 애플리케이션 및 서버에 퍼블릭 및 프라이빗 SSL/TLS 인증서를 사용할 수 있는 엔클레이브 애플리케이션인 AWS Nitro 엔클레이브에 AWS Certificate Manager (ACM)을 사용할 수 있습니다. Nitro Enclaves는 격리된 컴퓨팅 환경을 생성하여 SSL/TLS 인증서 및 프라이빗 키와 같은 매우 민감한 데이터를 보호하고 안전하게 처리할 수 있도록 지원하는 Amazon EC2 기능입니다.
Nitro Enclaves용 ACM은 Amazon EC2 Linux 인스턴스에서 실행되는 **nginx**와 함께 작동하여 프라이빗 키를 생성하고, 인증서와 프라이빗 키를 배포하며, 인증서 갱신을 관리합니다.
Nitro Enclaves용 ACM을 사용하려면 엔클레이브 지원 Linux 인스턴스를 사용해야 합니다.
자세한 내용은 [AWS Nitro Enclaves란 무엇입니까?를 참조하세요](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html). [AWS Certificate Manager Nitro Enclaves 사용 설명서](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave-refapp.html)*AWS 의 Nitro Enclaves*용 및 .
**Topics**
+ [사전 조건](#ssl_prereq)
+ [1단계: 서버에서 TLS 활성화](#ssl_enable)
+ [2단계: CA가 서명한 인증서 가져오기](#ssl_certificate)
+ [3단계: 보안 구성 테스트 및 하드닝](#ssl_test)
+ [문제 해결](#troubleshooting)
## 사전 조건
이 자습서를 시작하기 전에 다음 단계를 완료합니다.
+ Amazon EBS 지원 AL2 인스턴스를 시작합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 시작](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html)을 참조하세요.
+ 인스턴스가 다음 TCP 포트에서 연결을 허용하도록 보안 그룹을 구성합니다.
+ SSH(포트 22)
+ HTTP(포트 80)
+ HTTPS(포트 443)
자세한 내용은 *Amazon EC2 사용 설명서*의 [보안 그룹 규칙](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html)을 참조하세요.
+ Apache 웹 서버를 설치합니다. step-by-step[자습서: AL2에 LAMP 웹 서버 설치를 참조하세요](ec2-lamp-amazon-linux-2.md). httpd 패키지와 그 종속 프로그램만 필요합니다. PHP 및 MariaDB와 관련된 지침은 무시해도 됩니다.
+ 웹 사이트를 식별하고 인증하려면 TLS 퍼블릭 키 인프라(PKI)는 도메인 이름 시스템(DNS)을 사용합니다. EC2 인스턴스를 사용하여 퍼블릭 웹 사이트를 호스팅하려는 경우, 웹 서버의 도메인 이름을 등록하거나 Amazon EC2 호스트로 기존 도메인 이름을 전송해야 합니다. 수많은 타사 도메인 등록 및 DNS 호스팅 서비스를 이에 사용할 수 있습니다. 또는 [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)을 사용할 수도 있습니다.
## 1단계: 서버에서 TLS 활성화
**옵션: 자동화를 사용하여 이 자습서 완료**
다음 작업 대신 AWS Systems Manager 자동화를 사용하여이 자습서를 완료하려면 [자동화 문서를](https://console.aws.amazon.com/systems-manager/documents/AWSDocs-Configure-SSL-TLS-AL2/) 실행합니다.
이 절차에서는 자체 서명된 디지털 인증서를 사용하여 AL2에서 TLS를 설정하는 프로세스를 안내합니다.
**참고**
자체 서명된 인증서는 테스트에는 허용되지만 프로덕션에는 허용되지 않습니다. 자체 서명된 인증서를 인터넷에 노출하면 사이트 방문자에게 인사말로 보안 경고가 표시됩니다.
**서버에서 TLS를 활성화하려면**
1. [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)한 다음 Apache가 실행되는지 확인합니다.
```
[ec2-user ~]$ sudo systemctl is-enabled httpd
```
반환된 값이 "enabled"가 아닌 경우 Apache를 시작한 다음 시스템 부팅 시마다 시작하도록 설정합니다.
```
[ec2-user ~]$ sudo systemctl start httpd && sudo systemctl enable httpd
```
1. 모든 소프트웨어 패키지가 최신 상태로 업데이트되어 있는지 확인하기 위해, 인스턴스에서 퀵 소프트웨어 업데이트를 실행합니다. 이 업데이트 과정은 몇 분 정도 시간이 소요될 수 있지만, 최신 보안 업데이트와 버그 수정을 위해 수행할 필요가 있습니다.
**참고**
`-y` 옵션을 사용하면 확인 여부를 묻지 않고 업데이트를 설치합니다. 설치 전에 업데이트 정보를 확인하려면 이 옵션을 생략합니다.
```
[ec2-user ~]$ sudo yum update -y
```
1. 이제 인스턴스가 최신 상태이므로 다음과 같은 Apache module `mod_ssl`을 설치하여 TLS 지원을 추가합니다.
```
[ec2-user ~]$ sudo yum install -y mod_ssl
```
이제 인스턴스에는 보안 서버 구성과 테스트를 위한 인증서 생성에 사용할 다음 파일이 포함됩니다.
+ `/etc/httpd/conf.d/ssl.conf`
mod\$1ssl의 구성 파일입니다. 여기에는 Apache에 암호화 키 및 인증서의 위치, 허용하는 TLS 프로토콜 버전, 허용하는 암호화 암호를 알려주는 *명령*이 포함되어 있습니다.
+ `/etc/pki/tls/certs/make-dummy-cert`
서버 호스트에 대한 프라이빗 키와 자체 서명된 X.509 인증서 생성용 스크립트입니다. 이 인증서는 Apache가 TLS를 사용하도록 올바르게 설치되었는지 테스트하는 데 유용합니다. 제공하는 자격 증명이 없기 때문에 프로덕션에서 사용되어서는 안됩니다. 프로덕션 환경에서 사용되는 경우 웹 브라우저에서 경고를 트리거합니다.
1. 스크립트를 실행하여 자체 서명된 테스트용 더미 인증서와 키를 생성합니다.
```
[ec2-user ~]$ cd /etc/pki/tls/certs
sudo ./make-dummy-cert localhost.crt
```
그러면 새 파일인 `localhost.crt` 파일이 `/etc/pki/tls/certs/` 디렉터리에 생성됩니다. 지정된 파일의 이름은 `/etc/httpd/conf.d/ssl.conf`의 **SSLCertificateFile** 명령에 할당된 기본값과 일치합니다.
이 파일에는 자체 서명된 인증서와 인증서의 프라이빗 키가 모두 포함됩니다. Apache에서는 인증서와 키를 PEM 형식으로 요구합니다. 이 형식은 아래의 축약된 예제와 같이 "BEGIN" 및 "END" 라인으로 프레임 처리된 Base64 인코딩 ASCII 문자로 구성됩니다.
```
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQD2KKx/8Zk94m1q
3gQMZF9ZN66Ls19+3tHAgQ5Fpo9KJDhzLjOOCI8u1PTcGmAah5kEitCEc0wzmNeo
BCl0wYR6G0rGaKtK9Dn7CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vr
GvwnKoMh3DlK44D9dX7IDua2PlYx5+eroA+1Lqf32ZSaAO0bBIMIYTHigwbHMZoT
...
56tE7THvH7vOEf4/iUOsIrEzaMaJ0mqkmY1A70qQGQKBgBF3H1qNRNHuyMcPODFs
27hDzPDinrquSEvoZIggkDMlh2irTiipJ/GhkvTpoQlv0fK/VXw8vSgeaBuhwJvS
LXU9HvYq0U6O4FgD3nAyB9hI0BE13r1HjUvbjT7moH+RhnNz6eqqdscCS09VtRAo
4QQvAqOa8UheYeoXLdWcHaLP
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy
...
z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0
CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vrGvwnKoMh3DlK44D9dlU3
WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak
3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg==
-----END CERTIFICATE-----
```
파일 이름과 확장명은 편의상 사용되며 기능에 영향을 미치지 않습니다. 예를 들어 `ssl.conf` 파일에서 관련 명령에 동일한 이름을 사용하는 한, 인증서 이름을 `cert.crt`, `cert.pem` 또는 다른 파일 이름으로 지정할 수 있습니다.
**참고**
기본 TLS 파일을 고유의 사용자 지정 파일로 대체하는 경우 파일이 PEM 형식인지 확인하세요.
1. 자체 서명된 더미 인증서에도 키가 포함되어 있으므로 자주 사용하는 텍스트 편집기(예: **vim** 또는 **nano**)를 루트 사용자로 사용하여 `/etc/httpd/conf.d/ssl.conf` 파일을 열고 다음 줄에 주석을 답니다. 다음 단계를 완료하기 전에 이 행을 주석으로 처리하지 않는 경우 Apache 서비스가 시작되지 않습니다.
```
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
```
1. Apache를 다시 시작합니다.
```
[ec2-user ~]$ sudo systemctl restart httpd
```
**참고**
앞에서 설명한 대로 EC2 인스턴스에서 TCP 포트 443에 액세스할 수 있는지 확인하세요.
1. Apache 웹 서버가 현재 포트 443에 대해 HTTPS(보안 HTTP)를 지원해야 합니다. 접두사가 **https://**인 브라우저 URL 표시줄에 IP 주소 또는 EC2 인스턴스의 정규화된 도메인 이름을 입력하여 이를 테스트합니다.
신뢰할 수 없는 자체 서명된 호스트 인증서를 사용하여 사이트에 연결하기 때문에 브라우저에 보안 경고가 연속으로 표시될 수 있습니다. 경고를 무시하고 계속 진행합니다.
Apache 기본 테스트 페이지가 열리면 서버에 TLS가 구성되었다는 것입니다. 브라우저와 서버 사이를 통과하는 모든 데이터가 이제 암호화됩니다.
**참고**
사이트 방문자에게 경고 화면이 표시되는 것을 방지하려면 암호화뿐만 아니라 해당 사이트의 소유자라는 것을 공개적으로 인증하는 신뢰할 수 있는 CA 서명 인증서를 가져와야 합니다.
## 2단계: CA가 서명한 인증서 가져오기
CA가 서명한 인증서를 가져오려면 다음 절차를 사용할 수 있습니다.
+ 프라이빗 키에서 인증서 서명 요청(CSR)을 생성합니다.
+ 인증 기관(CA)에 CSR 제출
+ 단일 호스트 인증서 가져오기
+ Apache를 수성하여 인증서 사용
자체 서명된 TLS X.509 호스트 인증서는 CA가 서명한 인증서와 암호적으로 동일합니다. 그 차이는 수학적인 것이 아니라 사회적입니다. CA는 신청자에게 인증서를 발급하기 전에 도메인의 소유권을 최소한으로 검사합니다. 각 웹 브라우저에는 이를 하도록 브라우저 공급업체에서 신뢰한 CA 목록이 포함되어 있습니다. X.509 인증서는 프라이빗 서버 키에 해당하는 퍼블릭 키와 퍼블릭 키에 암호화 방식으로 연결된 CA의 서명으로 주로 구성되어 있습니다. 브라우저가 HTTPS를 통해 웹 서버에 연결되면 서버는 브라우저에서 신뢰할 수 있는 CA 목록을 확인하도록 인증서를 제공합니다. 서명자가 목록에 있거나 신뢰할 수 있는 다른 서명자로 구성되는 *신뢰 체인*을 통해 서명자에 액세스할 수 있는 경우, 브라우저는 서버와 암호화된 빠른 데이터 채널을 협상하고 페이지를 로드합니다.
요청 확인 절차로 인해 인증서에는 일반적으로 비용이 발생하므로 여러 인증 기관을 알아봐야 합니다. 일부 CA는 기본 수준 인증서를 무료로 제공합니다. 이러한 CA 중 가장 주목할 만한 것은 [Let's Encrypt](https://letsencrypt.org/) 프로젝트인데, 이것은 인증서 생성 및 갱신 프로세스의 자동화도 지원합니다. Let's Encrycrypt 인증서 사용에 대한 자세한 내용은 [Certbot 받기](https://eff-certbot.readthedocs.io/en/stable/install.html)를 참조하세요.
상업용 서비스를 제공할 계획이라면 [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)가 좋은 옵션입니다.
호스트 인증서의 기본을 이루는 것은 키입니다. 2019년 현재 [정부](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf) 및 [산업](https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf) 그룹에서는 2030년까지 문서를 보호하기 위해 마련된 RSA 키에 대해 최소 2048비트의 키(모듈러스) 크기를 사용할 것을 권장합니다. AL2에서 OpenSSL에 의해 생성된 기본 모듈러스 크기는 2048비트이며 CA 서명 인증서에 사용하기에 적합합니다. 다음 절차는 사용자 지정된 키(예: 더 큰 모듈러스 또는 다른 암호화 알고리즘 사용)를 원하는 사용자를 위해 제공되는 선택적 단계입니다.
**중요**
이 CA 서명 호스트 인증서 획득 지침은 등록과 호스팅이 완료된 DNS 도메인을 소유하지 않을 경우 제대로 적용하기 어렵습니다.
**CA가 서명한 인증서를 가져오려면**
1. [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)한 다음 /etc/pki/tls/private/으로 이동합니다. 여기는 TLS에 대한 서버의 프라이빗 키를 저장하는 디렉터리입니다. 기존 호스트 키를 사용하여 CSR을 생성하려면 3단계로 건너뜁니다.
1. (선택 사항) 새 프라이빗 키를 생성합니다. 다음은 몇 가지 키 구성 샘플입니다. 어떤 결과 키도 웹 서버에서 사용할 수 있지만 보안 구현의 정도와 유형은 각각 다릅니다.
+ **예 1:** 기본 RSA 호스트 키를 만듭니다. 결과 파일인 **custom.key**는 2048비트 RSA 프라이빗 키입니다.
```
[ec2-user ~]$ sudo openssl genrsa -out custom.key
```
+ **예 2:** 더 큰 모듈러스로 더 강력한 RSA 키를 만듭니다. 결과 파일인 **custom.key**는 4096비트 RSA 프라이빗 키입니다.
```
[ec2-user ~]$ sudo openssl genrsa -out custom.key 4096
```
+ **예 3:** 암호로 보호되는 4096비트 암호화 RSA 키를 생성합니다. 그러면 AES-128 암호화로 암호화된 4096비트 RSA 프라이빗 키인 **custom.key** 파일이 생성됩니다.
**중요**
키 암호화를 통해 보안을 강화할 수 있지만, 암호화된 키에는 암호가 필요하기 때문에 이를 사용하는 서비스는 자동으로 시작할 수 없습니다. 이 키를 사용할 때마다 SSH 연결을 통해 암호(위의 예에서는 "abcde12345")를 제공해야 합니다.
```
[ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096
```
+ **예 4:** 비 RSA 암호를 사용하여 키를 생성합니다. RSA 암호화는 두 개의 라지 소수의 결과를 기반으로 하는 공개 키의 크기 때문에 상대적으로 느릴 수 있습니다. 그러나 RSA 암호화 이외의 암호화를 사용하는 TLS의 키를 생성할 수 있습니다. 타원 곡선 수학을 기반으로 하는 키는 동등한 보안 수준을 제공할 때보다 작고 산술적으로 빠릅니다.
```
[ec2-user ~]$ sudo openssl ecparam -name prime256v1 -out custom.key -genkey
```
그 결과는 OpenSSL에서 지원하는 "명명된 곡선"인 prime256v1을 사용하는 256비트 타원 곡선 프라이빗 키입니다. [NIST](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf)에 따르면 이 키의 암호화 강도는 2048비트 RSA 키보다 약간 더 높습니다.
**참고**
모든 CA에서 타원 곡선 기반 키에 대해 RSA 키와 동등한 수준의 지원을 제공하지는 않습니다.
새 프라이빗 키의 소유권 및 권한은 매우 제한적(소유자=루트, 그룹=루트, 소유자 전용 읽기/쓰기)이어야 합니다. 명령은 다음 예에서와 같습니다.
```
[ec2-user ~]$ sudo chown root:root custom.key
[ec2-user ~]$ sudo chmod 600 custom.key
[ec2-user ~]$ ls -al custom.key
```
이 명령의 결과는 다음과 같아야 합니다.
```
-rw------- root root custom.key
```
만족스러운 키를 생성 및 구성한 후 CSR을 생성할 수 있습니다.
1. 원하는 키를 사용하여 CSR을 생성합니다. 다음 예에는 **custom.key**가 사용됩니다.
```
[ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem
```
OpenSSL은 대화 상자를 열고 아래 표의 정보를 입력하라는 메시지를 표시합니다. 도메인에서 확인된 기본 호스트 인증서의 경우 **Common Name**을 제외한 모든 필드는 선택 사항입니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/linux/al2/ug/SSL-on-amazon-linux-2.html)
마지막으로 OpenSSL은 챌린지 암호(선택 사항)를 입력하라는 메시지를 표시합니다. 이 암호는 해당 CSR 및 사용자와 해당 CA 간의 트랜잭션에만 적용되므로, 암호 및 기타 선택적 필드(선택적 회사 이름)에 대한 해당 CA의 권장 사항을 따릅니다. CSR 챌린지 암호는 서버 작업에 영향을 미치지 않습니다.
결과 파일인 **csr.pem**에는 퍼블릭 키, 퍼블릭 키의 디지털 서명 및 입력한 메타데이터가 포함되어 있습니다.
1. CA에 CSR을 제출합니다. 이는 보통 텍스트 편집기에서 CSR 파일을 열고 웹 양식에 내용을 복사하는 것으로 구성됩니다. 이때 인증서에 추가할 하나 이상의 주체 대체 이름(SAN)을 입력하라는 메시지가 나타날 수 있습니다. **www.example.com**이 일반 이름일 경우, **example.com**은 좋은 SAN이며, 그 반대의 경우도 마찬가지입니다. 사이트 방문자는 이 이름 중 하나를 입력하면 오류 없이 연결됩니다. CA 웹 양식에서 이를 허용하는 경우, SAN 목록에 일반 이름을 포함시킵니다. 일부 CA는 이를 자동으로 포함시킵니다.
요청이 승인되면 CA에서 서명한 새 호스트 인증서를 받게 됩니다. CA의 신뢰 체인을 완료하는 데 필요한 추가 인증서가 포함된 *중간 인증서* 파일을 다운로드하라는 안내를 받을 수도 있습니다.
**참고**
CA는 다양한 목적을 위해 마련된 여러 형식의 파일을 보낼 수 있습니다. 본 자습서에서는 PEM 형식의 인증서 파일만 사용해야 하는데, 이는 보통 `.pem` 또는 `.crt` 파일 확장명으로 표시되지만 항상 그런 것은 아닙니다. 어떤 파일을 사용할지 확실하지 않은 경우 텍스트 편집기로 파일을 열고 다음 라인으로 시작되는 블록 하나 이상이 포함되는 파일을 찾습니다.
```
- - - - -BEGIN CERTIFICATE - - - - -
```
또한 파일은 다음 라인으로 끝나야 합니다.
```
- - - -END CERTIFICATE - - - - -
```
또한 명령줄의 파일을 다음과 같이 테스트할 수 있습니다.
```
[ec2-user certs]$ openssl x509 -in certificate.crt -text
```
이 줄이 파일에 나타나는지 확인하세요. `.p7b`, `.p7c`, 또는 유사한 파일 확장명으로 끝나는 파일을 사용하지 않습니다.
1. `/etc/pki/tls/certs` 디렉터리에 CA가 서명한 새 인증서와 모든 중간 인증서를 배치합니다.
**참고**
여러 가지 방법으로 새 인증서를 EC2 인스턴스에 업로드할 수 있지만, 가장 간편하고 유익한 방법은 텍스트 편집기(예: vi, nano, 메모장)를 로컬 컴퓨터와 인스턴스에 모두 열고 두 편집기 간에 파일 콘텐츠를 복사하여 붙이는 것입니다. EC2 인스턴스에서 이러한 작업을 수행할 때 루트 [sudo] 권한이 필요합니다. 이렇게 하면 권한 또는 경로 문제가 있는 경우 즉시 확인할 수 있습니다. 하지만 콘텐츠를 복사하는 동안 라인을 추가하거나 어떤 식으로든 콘텐츠를 변경하지 않도록 주의하세요.
`/etc/pki/tls/certs` 디렉터리 내부에서 파일 소유권, 그룹 및 권한 설정이 매우 제한적인 AL2 기본값(owner=root, group=root, 소유자 전용 읽기/쓰기)과 일치하는지 확인합니다. 다음 예제는 사용하는 명령을 보여 줍니다.
```
[ec2-user certs]$ sudo chown root:root custom.crt
[ec2-user certs]$ sudo chmod 600 custom.crt
[ec2-user certs]$ ls -al custom.crt
```
이 명령의 결과는 다음과 같아야 합니다.
```
-rw------- root root custom.crt
```
중간 인증서 파일에 대한 권한은 덜 엄격합니다(소유자=루트, 그룹=루트, 소유자 쓰기 가능, 그룹 읽기 가능, 모든 사용자 읽기 가능). 다음 예제는 사용하는 명령을 보여 줍니다.
```
[ec2-user certs]$ sudo chown root:root intermediate.crt
[ec2-user certs]$ sudo chmod 644 intermediate.crt
[ec2-user certs]$ ls -al intermediate.crt
```
이 명령의 결과는 다음과 같아야 합니다.
```
-rw-r--r-- root root intermediate.crt
```
1. `/etc/pki/tls/private/` 디렉터리에서 CSR을 생성할 때 사용한 프라이빗 키를 배치합니다.
**참고**
여러 가지 방법으로 사용자 지정 키를 EC2 인스턴스에 업로드할 수 있지만, 가장 간편하고 유익한 방법은 텍스트 편집기(예: vi, nano, 메모장)를 로컬 컴퓨터와 인스턴스에 모두 열고 두 편집기 간에 파일 콘텐츠를 복사하여 붙이는 것입니다. EC2 인스턴스에서 이러한 작업을 수행할 때 루트 [sudo] 권한이 필요합니다. 이렇게 하면 권한 또는 경로 문제가 있는 경우 즉시 확인할 수 있습니다. 하지만 콘텐츠를 복사하는 동안 라인을 추가하거나 어떤 식으로든 콘텐츠를 변경하지 않도록 주의하세요.
`/etc/pki/tls/private` 디렉터리 내부에서 다음 명령을 사용하여 파일 소유권, 그룹 및 권한 설정이 매우 제한적인 AL2 기본값(소유자=루트, 그룹=루트, 소유자 전용 읽기/쓰기)과 일치하는지 확인합니다.
```
[ec2-user private]$ sudo chown root:root custom.key
[ec2-user private]$ sudo chmod 600 custom.key
[ec2-user private]$ ls -al custom.key
```
이 명령의 결과는 다음과 같아야 합니다.
```
-rw------- root root custom.key
```
1. 새 인증서 및 키 파일을 반영하기 위해 `/etc/httpd/conf.d/ssl.conf`를 편집합니다.
1. Apache의 `SSLCertificateFile` 명령에 CA가 서명한 호스트 인증서의 경로와 파일 이름을 입력합니다.
```
SSLCertificateFile /etc/pki/tls/certs/custom.crt
```
1. 중간 인증서 파일을 받은 경우(이 예에서는 `intermediate.crt`), Apache의 `SSLCACertificateFile` 명령을 사용하여 경로 및 파일 이름을 입력합니다.
```
SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt
```
**참고**
일부 CA는 호스트 인증서와 중간 인증서를 단일 파일로 결합하기 때문에 `SSLCACertificateFile` 명령이 불필요합니다. CA가 제공한 지침을 참조하세요.
1. Apache의 `SSLCertificateKeyFile` 명령에 프라이빗 키(이 예에서는 `custom.key`)의 경로와 파일 이름을 입력합니다.
```
SSLCertificateKeyFile /etc/pki/tls/private/custom.key
```
1. `/etc/httpd/conf.d/ssl.conf`를 저장하고 Apache를 다시 시작합니다.
```
[ec2-user ~]$ sudo systemctl restart httpd
```
1. `https://` 접두사가 포함된 브라우저 URL 막대에 도메인 이름을 입력하여 서버를 테스트합니다. 브라우저에서는 테스트 페이지가 오류 생성 없이 HTTPS를 통해 로드되어야 합니다.
## 3단계: 보안 구성 테스트 및 하드닝
TLS이 작동되고 일반에 공개된 후 이의 실제 보안 수준을 테스트해야 합니다. 보안 설정을 무료로 완벽하게 분석해 주는 [Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html)와 같은 온라인 서비스를 사용하면 이를 손쉽게 수행할 수 있습니다. 그 결과에 따라 수용할 프로토콜, 원하는 암호 및 제외할 암호를 관리하여 기본 보안 구성을 하드닝할 수 있습니다. 자세한 내용은 [how Qualys formulates its scores](https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide) 섹션을 참조하세요.
**중요**
실제 테스트는 서버 보안에 매우 중요합니다. 구성상의 작은 오류가 심각한 보안 침해 및 데이터 손실로 이어질 수 있습니다. 권장되는 보안 사례는 연구 및 새롭게 생겨나는 위협에 대처하기 위해 끊임없이 변화하므로 보안 감사를 주기적으로 실시하는 것이 서버 관리에 필수적입니다.
[Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html) 사이트에 **www.example.com** 형식으로 서버의 정규화된 도메인 이름을 입력합니다. 약 2분 후 사이트 등급(A - F) 및 확인된 상세 분석 결과를 받게 됩니다. 다음 표에는 AL2의 기본 Apache 구성과 동일한 설정과 기본 Certbot 인증서가 있는 도메인에 대한 보고서가 요약되어 있습니다.
| | |
| --- |--- |
| 종합 등급 | B |
| 인증서 | 100% |
| 프로토콜 지원 | 95% |
| 키 교환 | 70% |
| 암호화 수준 | 90% |
개요에서 구성이 대체로 문제가 없어 보여도 세부 정보 보고서에서는 몇몇 잠재적 문제를 여기에 심각도 순서로 나열하여 표시합니다.
✗ **RC4 암호는 이전 버전의 특정 브라우저에서 사용하도록 지원됩니다.** 암호는 암호화 알고리즘의 수학적 핵심입니다. TLS 데이터 스트림을 암호화하는 데 사용하는 빠른 암호인 RC4에는 몇 가지 [심각한 취약점](http://www.imperva.com/docs/hii_attacking_ssl_when_using_rc4.pdf)이 있는 것으로 알려져 있습니다. 타당한 레거시 브라우저 지원 사유가 없다면 비활성화해야 합니다.
✗ **이전 TLS 버전이 지원됩니다.** 구성에서는 TLS 1.0(이미 사용 중지 상태)과 TLS 1.1(사용 중지 절차 진행 중)을 지원합니다. 2018년부터는 TLS 1.2만 권장됩니다.
✗ **전방향 보안은 부분적으로 지원됩니다.** [전방향 보안](https://en.wikipedia.org/wiki/Forward_secrecy)은 프라이빗 키에서 파생된 임시(사용 후 삭제) 세션 키를 사용하여 암호화하는 알고리즘의 기능입니다. 이는 실제 공격자가 웹 서버의 장기 프라이빗 키를 보유하고 있더라도 HTTPS 데이터의 암호를 해독할 수 없다는 것을 뜻합니다.
**TLS 구성을 수정하고 향후에 대비하려면**
1. 텍스트 편집기에서 `/etc/httpd/conf.d/ssl.conf` 구성 파일을 열고 다음 줄의 시작 부분에 "\$1"을 입력하여 해당 줄을 주석으로 처리합니다.
```
#SSLProtocol all -SSLv3
```
1. 다음 명령을 추가합니다.
```
#SSLProtocol all -SSLv3
SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
```
이러한 명령은 SSL 버전 2 및 3과 TLS 버전 1.0 및 1.1을 명시적으로 비활성화합니다. 이제 이 서버는 TLS 1.2 이외의 프로토콜을 사용하는 클라이언트와의 암호화된 연결을 허용하지 않습니다. 명령의 상세 내용은 서버의 구성 내용을 사람에게 더욱 명확히 전달합니다.
**참고**
이러한 방식으로 TLS 버전 1.0 및 1.1을 비활성화하면 적은 비율의 오래된 웹 브라우저가 사이트에 액세스하지 못하도록 차단합니다.
**허용된 암호의 목록을 수정하려면**
1. 구성 파일인 `/etc/httpd/conf.d/ssl.conf`에서 **SSLCipherSuite** 명령이 포함된 섹션을 찾고 기존의 줄을 줄의 시작에 “\$1”을 입력하여 주석으로 처리합니다.
```
#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
```
1. 명시적 암호 그룹과 전방향 보안을 우선순위에 두고 부정확한 암호를 방지하는 암호 오더를 지정합니다. 여기에 사용된 `SSLCipherSuite` 명령은 서버에서 실행되는 특정 소프트웨어에 맞게 TLS 구성을 조정하는 [Mozilla SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/)의 출력에 기반합니다. 먼저 다음 명령의 출력을 사용하여 Apache와 OpenSSL의 버전을 확인합니다.
```
[ec2-user ~]$ yum list installed | grep httpd
[ec2-user ~]$ yum list installed | grep openssl
```
예를 들어, 반환된 정보가 Apache 2.4.34 및 OpenSSL 1.0.2인 경우 이를 생성기에 입력합니다. "현대" 호환성 모델을 선택하면 적극적으로 보안을 적용하지만 대부분의 브라우저에서 여전히 작동하는 `SSLCipherSuite` 명령을 생성합니다. 소프트웨어가 최신 구성을 지원하지 않으면 소프트웨어를 업데이트하거나 대신 "중간" 구성을 선택할 수 있습니다.
```
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:
ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
```
선택된 암호에는 이름에 *Elliptic Curve Diffie-Hellman Ephemeral*의 약자인 *ECDHE*가 포함되어 있습니다. *ephemeral*은 전방향 보안을 나타냅니다. 부차적 결과로서 해당 암호는 RC4를 지원하지 않습니다.
내용이 표시되지 않는 기본값 또는 terse 명령 대신 명시적 암호 목록을 사용하는 것이 좋습니다.
생성된 명령을 `/etc/httpd/conf.d/ssl.conf`에 복사합니다.
**참고**
여기에서는 가독성을 위해 여러 줄로 표시했지만, 이 명령은 `/etc/httpd/conf.d/ssl.conf`에 복사할 때 암호 이름 사이에 공백 없이 콜론만을 추가하여 한 줄에 입력해야 합니다.
1. 마지막으로 줄 시작 부분에 있는 "\$1"을 제거하여 다음 줄의 주석 처리를 해제합니다.
```
#SSLHonorCipherOrder on
```
이 명령은 (이 예에서는) 전방향 보안을 지원하는 암호를 포함하여 서버에서 순위가 높은 암호를 선호하도록 합니다. 이 명령이 설정되면 서버는 먼저 강력한 보안 연결 설정을 시도해 본 후 보안이 더 약한 허용된 암호로 대체합니다.
이 두 절차를 모두 완료한 다음에는 변경 사항을 `/etc/httpd/conf.d/ssl.conf`에 저장하고 Apache를 재시작합니다.
[Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html)에서 도메인을 다시 테스트하면 RC4 취약성과 다른 경고 문제가 해결되고 요약은 다음과 같을 것입니다.
| | |
| --- |--- |
| 종합 등급 | A |
| 인증서 | 100% |
| 프로토콜 지원 | 100% |
| 키 교환 | 90% |
| 암호화 수준 | 90% |
OpenSSL을 업데이트할 때마다 새 암호가 사용되고 이전 암호에 대한 지원은 제거됩니다. EC2 AL2 인스턴스를 up-to-date 유지하고, [OpenSSL](https://www.openssl.org/)의 보안 공지를 주시하고, 기술 보도에서 새로운 보안 악용에 대한 보고를 주의 깊게 확인하세요.
## 문제 해결
+ **암호를 입력하지 않으면 Apache 웹 서버가 시작되지 않음**
암호화되고 암호로 보호되는 프라이빗 서버 키를 설치한 경우 이는 예상된 동작입니다.
키에서 암호화 및 암호 요구 사항을 제거할 수 있습니다. 기본 디렉터리에 `custom.key`라는 암호화된 프라이빗 RSA 키가 있고 이 키의 암호가 **abcde12345**라고 가정하면, EC2 인스턴스에서 다음 명령을 실행하여 이 키의 암호화되지 않은 버전을 생성합니다.
```
[ec2-user ~]$ cd /etc/pki/tls/private/
[ec2-user private]$ sudo cp custom.key custom.key.bak
[ec2-user private]$ sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt
[ec2-user private]$ sudo mv custom.key.nocrypt custom.key
[ec2-user private]$ sudo chown root:root custom.key
[ec2-user private]$ sudo chmod 600 custom.key
[ec2-user private]$ sudo systemctl restart httpd
```
이제 Apache가 암호를 묻지 않고 시작할 것입니다.
+ **sudo yum install -y mod\$1ssl을 실행할 때 오류가 발생합니다.**
SSL에 필요한 패키지를 설치하려 할 때 다음과 같은 오류가 표시될 수 있습니다.
```
Error: httpd24-tools conflicts with httpd-tools-2.2.34-1.16.amzn1.x86_64
Error: httpd24 conflicts with httpd-2.2.34-1.16.amzn1.x86_64
```
이는 일반적으로 EC2 인스턴스가 AL2를 실행하고 있지 않음을 의미합니다. 이 자습서에서는 공식 AL2 AMI에서 새로 생성된 인스턴스만 지원합니다.
# 자습서: AL2에서 WordPress 블로그 호스팅
다음 절차는 AL2 인스턴스에 WordPress 블로그를 설치, 구성 및 보호하는 데 도움이 됩니다. 본 자습서는 기존 호스팅 서비스에서는 일반적이지 않은 WordPress 블로그를 호스팅하는 웹 서버를 사용자가 완전히 제어할 수 있다는 점에서 Amazon EC2 사용에 있어 좋은 입문 기회를 제공합니다.
사용자는 서버에 대한 소프트웨어 패키지를 업데이트하고 보안 패치를 유지관리할 책임이 있습니다. 웹 서버 구성과 직접 상호 작용할 필요가 없는 보다 자동화된 WordPress 설치를 위해 CloudFormation 서비스는 빠르게 시작할 수 있는 WordPress 템플릿을 제공합니다. 자세한 내용은 *AWS CloudFormation 사용 설명서*에서 [시작하기](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.Walkthrough.html)를 참조하세요. 데이터베이스가 분리된 고가용성 솔루션이 필요하다면 *AWS Elastic Beanstalk 개발자 안내서*에서 [고가용성 WordPress 웹 사이트 배포](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/php-hawordpress-tutorial.html)를 참조하세요.
**중요**
이 절차는 AL2와 함께 사용하기 위한 것입니다. 기타 배포에 대한 자세한 내용은 해당 설명서를 참조하세요. 본 자습서에 있는 단계의 상당수가 Ubuntu 인스턴스에서 작동하지 않습니다. Ubuntu 인스턴스에 WordPress를 설치하는 방법은 Ubuntu 설명서에서 [WordPress](https://help.ubuntu.com/community/WordPress) 섹션을 참조하세요. [CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorials-wordpress-launch-instance.html)를 사용하여 Amazon Linux, macOS 또는 Unix 시스템에서 태스크를 수행할 수도 있습니다.
**Topics**
+ [사전 조건](#hosting-wordpress-prereqs)
+ [WordPress 설치](#install-wordpress)
+ [다음 단계](#wordpress-next-steps)
+ [도움말\$1 내 퍼블릭 DNS 이름이 변경되어 블로그를 사용할 수 없습니다.](#wordpress-troubleshooting)
## 사전 조건
이 자습서에서는의 모든 단계에 따라 PHP 및 데이터베이스(MySQL 또는 MariaDB)가 지원되는 기능 웹 서버를 사용하여 AL2 인스턴스를 시작했다고 가정합니다[자습서: AL2에 LAMP 서버 설치](ec2-lamp-amazon-linux-2.md). 또한 본 자습서는 보안 그룹이 `HTTP` 및 `HTTPS` 트래픽을 허용하도록 구성하는 단계와 파일 권한이 웹 서버에 맞게 적절하게 설정되어 있는지 확인하는 여러 단계를 포함하고 있습니다. 보안 그룹 규칙 추가에 대한 자세한 내용은 [보안 그룹에 규칙 추가](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) 섹션을 참조하세요.
탄력적 IP 주소(EIP)는 WordPress 블로그를 호스팅하는 데 사용 중인 인스턴스와 연결하는 것이 가장 바람직합니다. 인스턴스의 퍼블릭 DNS 주소가 설치 위치를 바꾸거나 위반하는 것을 방지할 수 있기 때문입니다. 자신이 소유하고 있는 도메인 이름을 블로그에 사용하고 싶다면 도메인 이름의 DNS 레코드가 EIP 주소를 가리키도록 업데이트할 수 있습니다(이와 관련하여 도움이 필요하다면 도메인 이름 등록 기관에게 문의하세요). 실행 중인 인스턴스와 연결되어 있는 EIP 주소는 한 개까지 무료로 사용할 수 있습니다. 자세한 내용은 *Amazon EC2 사용 설명서*에서 [탄력적 IP 주소](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)를 참조하세요.
블로그에 사용할 도메인 이름이 아직 없는 경우 Route 53에 도메인 이름을 등록하고 인스턴스의 EIP 주소를 도메인 이름에 연결할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [Amazon Route 53을 사용하여 도메인 이름 등록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html)을 참조하세요.
## WordPress 설치
**옵션: 자동화를 사용하여 이 자습서 완료**
다음 작업 대신 AWS Systems Manager 자동화를 사용하여이 자습서를 완료하려면 [자동화 문서를](https://console.aws.amazon.com/systems-manager/documents/AWSDocs-HostingAWordPressBlog/) 실행합니다.
인스턴스에 연결한 후 WordPress 설치 패키지를 다운로드합니다.
**WordPress 설치 패키지의 다운로드 및 압축해제 방법**
1. **wget** 명령을 사용하여 최신 WordPress 설치 패키지를 다운로드 합니다. 다음 명령을 사용할 경우 언제나 최신 릴리스를 다운로드합니다.
```
[ec2-user ~]$ wget https://wordpress.org/latest.tar.gz
```
1. 설치 패키지의 압축 및 아카이빙을 해제합니다. 설치 폴더는 `wordpress`라는 폴더로 압축 해제됩니다.
```
[ec2-user ~]$ tar -xzf latest.tar.gz
```
**WordPress 설치에 대한 데이터베이스 사용자 및 데이터베이스를 생성하려면**
WordPress 설치 시 블로그 게시물, 사용자 의견 등의 정보를 데이터베이스에 저장해야 합니다. 다음 절차를 통해 블로그의 데이터베이스와 이 데이터베이스에 대해 정보 읽기 및 저장 권한이 있는 사용자를 생성할 수 있습니다.
1. 데이터베이스 서버를 시작합니다.
+
```
[ec2-user ~]$ sudo systemctl start mariadb
```
1. 데이터베이스 서버에 `root` 사용자로 로그인합니다. 메시지가 표시되면 데이터베이스 `root` 암호를 입력합니다. 이 암호는 사용자의 `root` 시스템 암호와 다를 수 있으며, 데이터베이스 서버를 보안 설정하지 않은 경우 암호가 비어 있을 수도 있습니다.
데이터베이스 서버를 보안 설정하지 않았다면 반드시 설정하시기 바랍니다. 자세한 내용은 [MariaDB 서버의 보안을 유지하려면](ec2-lamp-amazon-linux-2.md#securing-maria-db) (AL2)를 참조하세요.
```
[ec2-user ~]$ mysql -u root -p
```
1. MySQL 데이터베이스에 대한 사용자 및 암호를 생성합니다. WordPress 설치는 MySQL 데이터베이스를 통신하기 위해 상기 값을 사용합니다.
사용자에 대해 보안이 강력한 암호를 생성하시기 바랍니다. 작은따옴표(')는 각 명령을 구별하는 구분자로 기능하기 때문에, 암호에는 사용하지 마세요. 기존 암호를 재사용하지 마세요. 새로 설정한 암호는 안전한 장소에 보관하세요.
고유한 사용자 이름과 암호로 해당 부분을 대체하여 다음 명령을 입력합니다.
```
CREATE USER 'wordpress-user'@'localhost' IDENTIFIED BY 'your_strong_password';
```
1. 데이터베이스를 생성합니다. 데이터베이스에 이를 설명할 수 있는 유의미한 이름을 붙입니다(예: `wordpress-db`.).
**참고**
아래 명령에서 데이터베이스 이름을 앞 뒤로 묶는 기호(`)를 백틱(backtick)이라고 합니다. 백틱(```) 키는 일반적으로 표준 키보드에서 `Tab` 키 위에 있습니다. 백틱이 항상 필요하지는 않지만, 이를 통해 데이터베이스 이름에 하이픈(-) 등 허용되지 않는 문자를 사용할 수 있습니다.
```
CREATE DATABASE `wordpress-db`;
```
1. 데이터베이스에 대한 전체 권한을 이전에 생성한 WordPress 사용자에게 부여합니다.
```
GRANT ALL PRIVILEGES ON `wordpress-db`.* TO "wordpress-user"@"localhost";
```
1. 데이터베이스 권한을 새로고침(flush)해서 모든 변경사항이 적용되도록 합니다.
```
FLUSH PRIVILEGES;
```
1. `mysql` 클라이언트를 종료합니다.
```
exit
```
**wp-config.php 파일 생성 및 편집 방법**
WordPress 설치 폴더는 `wp-config-sample.php`라는 샘플 구성 파일을 포함하고 있습니다. 본 절차에서는 이 파일을 복사하고 특정 구성에 맞도록 편집합니다.
1. `wp-config-sample.php` 파일을 `wp-config.php`라는 파일에 복사합니다. 이를 통해 새 구성 파일을 생성하고 원본 샘플 파일을 이전 상태 그대로 백업으로 보존할 수 있습니다.
```
[ec2-user ~]$ cp wordpress/wp-config-sample.php wordpress/wp-config.php
```
1. `wp-config.php` 파일을 원하는 텍스트 편집기(**nano**, **vim** 등)로 편집하고 설치에 대한 값을 입력합니다. 원하는 텍스트 편집기가 없는 경우 초보자에게는 `nano`가 적합합니다.
```
[ec2-user ~]$ nano wordpress/wp-config.php
```
1. `DB_NAME`을(를) 정의하는 줄을 찾고 `database_name_here`을(를) [Step 4](#create_database)의 [WordPress 설치에 대한 데이터베이스 사용자 및 데이터베이스를 생성하려면](#create_user_and_database)에서 생성한 데이터베이스 이름으로 변경합니다.
```
define('DB_NAME', 'wordpress-db');
```
1. `DB_USER`을(를) 정의하는 줄을 찾고 `username_here`을(를) [Step 3](#create_database_user)의 [WordPress 설치에 대한 데이터베이스 사용자 및 데이터베이스를 생성하려면](#create_user_and_database)에서 생성한 데이터베이스 사용자로 변경합니다.
```
define('DB_USER', 'wordpress-user');
```
1. `DB_PASSWORD`을(를) 정의하는 줄을 찾고 `password_here`을(를) [Step 3](#create_database_user)의 [WordPress 설치에 대한 데이터베이스 사용자 및 데이터베이스를 생성하려면](#create_user_and_database)에서 생성한 보안성이 강력한 암호로 변경합니다.
```
define('DB_PASSWORD', 'your_strong_password');
```
1. `Authentication Unique Keys and Salts`라는 섹션을 검색합니다. 이 `KEY` 및 `SALT` 값은 WordPress 사용자가 로컬 컴퓨터에 저장하는 브라우저 쿠키에 암호 계층을 제공합니다. 기본적으로 긴 무작위 값을 추가해서 사이트의 보안성을 강화할 수 있습니다. [https://api.wordpress.org/secret-key/1.1/salt/](https://api.wordpress.org/secret-key/1.1/salt/)을 방문해서 키 값의 세트를 무작위로 생성하고 이를 `wp-config.php` 파일로 복사해서 붙여 넣을 수 있습니다. PuTTY 터미널로 텍스트를 붙여넣기 하기 위해, PuTTY 터미널 내부에서 텍스트를 붙여넣기하려는 위치에 커서를 놓고 마우스를 오른쪽 클릭합니다.
보안 키에 대한 자세한 내용을 보려면 [http://codex.wordpress.org/Editing\$1wp-config.php\$1Security\$1Keys](https://wordpress.org/support/article/editing-wp-config-php/#security-keys)로 이동하세요.
**참고**
아래 값은 예시 목적만을 위한 것입니다. 설치 시 이 값을 사용하지는 마세요.
```
define('AUTH_KEY', ' #U$$+[RXN8:b^-L 0(WU_+ c+WFkI~c]o]-bHw+)/Aj[wTwSiZ)Y |;(^[Iw]Pi+LG#A4R?7N`YB3');
define('NONCE_KEY', 'P(g62HeZxEes|LnI^i=H,[XwK9I&[2s|:?0N}VJM%?;v2v]v+;+^9eXUahg@::Cj');
define('AUTH_SALT', 'C$DpB4Hj[JK:?{ql`sRVa:{:7yShy(9A@5wg+`JJVb1fk%_-Bx*M4(qc[Qg%JT!h');
define('SECURE_AUTH_SALT', 'd!uRu#}+q#{f$Z?Z9uFPG.${+S{n~1M&%@~gL>U>NV.|Y%Ug4#I^*LVd9QeZ^&XmK|e(76miC+&W&+^0P/');
define('NONCE_SALT', '-97r*V/cgxLmp?Zy4zUU4r99QQ_rGs2LTd%P;|_e1tS)8_B/,.6[=UK`
```
#
# Possible values for the Options directive are "None", "All",
# or any combination of:
# Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important. Please see
# http://httpd.apache.org/docs/2.4/mod/core.html#options
# for more information.
#
Options Indexes FollowSymLinks
#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride None
#
# Controls who can get stuff from this server.
#
Require all granted
```
1. 위 영역에서 `AllowOverride None` 라인을 `AllowOverride All`로 변경합니다.
**참고**
이 파일에는 `AllowOverride` 라인이 많기 때문에 `` 영역의 라인을 변경할 때는 주의해야 합니다.
```
AllowOverride All
```
1. 파일을 저장하고 텍스트 편집기를 종료합니다.
**AL2에 PHP 그래픽 그리기 라이브러리를 설치하려면**
PHP용 GD 라이브러리를 사용하면 이미지를 수정할 수 있습니다. 블로그의 헤더 이미지를 잘라야 하는 경우 이 라이브러리를 설치합니다. 설치하는 phpMyAdmin 버전에는 이 라이브러리의 특정 최소 버전(예: 버전 7.2)이 필요할 수 있습니다.
다음 명령을 사용하여 AL2에 PHP 그래픽 그리기 라이브러리를 설치합니다. 예를 들어, LAMP 스택 설치의 일부로 amazon-linux-extras에서 php7.2를 설치한 경우 이 명령은 PHP 그래픽 그리기 라이브러리의 버전 7.2를 설치합니다.
```
[ec2-user ~]$ sudo yum install php-gd
```
설치된 버전을 확인하려면 다음 명령을 사용합니다.
```
[ec2-user ~]$ sudo yum list installed php-gd
```
다음은 예제 출력입니다.
```
php-gd.x86_64 7.2.30-1.amzn2 @amzn2extra-php7.2
```
**Apache 웹 서버에 대한 파일 권한 수정 방법**
WordPress의 제공 기능 중 일부(예: 관리 화면을 통한 미디어 업로드 등)는 Apache 문서 루트에 대한 쓰기 권한을 필요로 합니다. 아직 적용하지 않은 경우 다음 그룹 멤버십 및 권한을 적용합니다(에 자세히 설명됨[자습서: AL2에 LAMP 서버 설치](ec2-lamp-amazon-linux-2.md)).
1. `/var/www`의 파일 소유권 및 그 콘텐츠를 `apache` 사용자에게 허용합니다.
```
[ec2-user ~]$ sudo chown -R apache /var/www
```
1. `/var/www` 및 그 콘텐츠의 그룹 소유권을 `apache` 그룹에 허용합니다.
```
[ec2-user ~]$ sudo chgrp -R apache /var/www
```
1. `/var/www` 및 그 하위 디렉터리의 디렉터리 권한을 변경해서 그룹 쓰기 권한을 추가하고 미래 하위 디렉터리에서 그룹 ID를 설정합니다.
```
[ec2-user ~]$ sudo chmod 2775 /var/www
[ec2-user ~]$ find /var/www -type d -exec sudo chmod 2775 {} \;
```
1. `/var/www` 및 그 하위 디렉터리의 파일 권한을 재귀적으로 변경합니다.
```
[ec2-user ~]$ find /var/www -type f -exec sudo chmod 0644 {} \;
```
**참고**
WordPress를 FTP 서버로도 사용하려는 경우 여기서 더 많은 권한 그룹 설정이 필요합니다. 이 작업을 수행하려면 권장된 [WordPress 단계 및 보안 설정](https://wordpress.org/support/article/changing-file-permissions/)을 검토하세요.
1. Apache 웹 서버를 재시작해서 새 그룹 및 권한을 가져옵니다.
+
```
[ec2-user ~]$ sudo systemctl restart httpd
```
**AL2를 사용하여 WordPress 설치 스크립트 실행**
이제 WordPress를 설치할 준비가 되었습니다. 사용하는 명령은 운영 체제에 따라 다릅니다. 이 절차의 명령은 AL2와 함께 사용됩니다.
1. **systemctl** 명령을 사용하여 시스템이 부팅될 때마다 `httpd` 및 데이터베이스 서비스가 시작되도록 합니다.
```
[ec2-user ~]$ sudo systemctl enable httpd && sudo systemctl enable mariadb
```
1. 데이터베이스 서버가 실행되는지 확인합니다.
```
[ec2-user ~]$ sudo systemctl status mariadb
```
데이터베이스 서비스가 실행 중이지 않은 경우, 이를 시작합니다.
```
[ec2-user ~]$ sudo systemctl start mariadb
```
1. Apache 웹 서버(`httpd`)가 실행 중인지 확인합니다.
```
[ec2-user ~]$ sudo systemctl status httpd
```
`httpd` 서비스가 실행 중이지 않은 경우, 이를 시작합니다.
```
[ec2-user ~]$ sudo systemctl start httpd
```
1. 웹 브라우저에서 WordPress 블로그의 URL을 입력합니다(인스턴스에 대한 퍼블릭 DNS 주소 또는 `blog` 폴더 다음의 주소). 이제 WordPress 설치 스크립트가 나타납니다. WordPress 설치에 필요한 정보를 제공합니다. **WordPress 설치(Install WordPress)**를 선택해서 설치를 완료합니다. 자세한 내용은 WordPress 웹 사이트의 [5단계: 설치 스크립트 실행](https://wordpress.org/support/article/how-to-install-wordpress/#step-5-run-the-install-script)을 참조하세요.
## 다음 단계
WordPress 블로그를 테스트한 후 구성을 업데이트하세요.
**사용자 지정 도메인 이름 사용**
EC2 인스턴스의 EIP 주소와 연결되어 있는 도메인 이름이 있는 경우에는 EC2 퍼블릭 DNS 주소 대신에 해당 이름을 사용하여 블로그를 구성할 수 있습니다. 자세한 내용은 WordPress 웹 사이트의 [사이트 URL 변경](https://wordpress.org/support/article/changing-the-site-url/)을 참조하세요.
**블로그 구성**
다른 [테마](https://wordpress.org/themes/)와 [플러그인](https://wordpress.org/plugins/)을 사용하여 더욱 풍부한 맞춤형 경험을 독자에게 제공하도록 블로그를 구성할 수도 있습니다. 하지만 설치 프로세스가 역효과를 낳아 전체 블로그를 잃는 경우가 발생할 수도 있습니다. 따라서 테마나 플러그인을 설치하기 전에 인스턴스의 백업 Amazon Machine Image(AMI)를 생성하여 설치 중 오류가 발생하더라도 블로그를 복구할 수 있도록 대비하는 것이 좋습니다. 자세한 내용은 [자체 AMI 생성을 참조하세요](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami).
**용량 증가**
운영하는 WordPress 블로그가 유명해지고 그에 따라 보다 많은 컴퓨팅 파워 또는 스토리지가 필요하게 될 경우 다음 단계를 고려하세요.
+ 인스턴스에서 스토리지 공간을 확장합니다. 자세한 내용은 *Amazon EBS 사용 설명서*의 [Amazon EBS Elastic Volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modify-volume.html)를 참조하세요.
+ MySQL 데이터베이스를 [Amazon RDS](https://aws.amazon.com/rds)로 이동하여 이 서비스의 간편한 조정 기능을 이용합니다.
**인터넷 트래픽의 네트워크 성능 향상**
블로그가 전 세계에 위치한 사용자로부터 트래픽을 유도할 것으로 예상되는 경우 [AWS Global Accelerator](https://aws.amazon.com/global-accelerator) 사용을 고려해 보세요. Global Accelerator는 사용자의 클라이언트 디바이스와 AWS에서 실행되는 WordPress 애플리케이션 간의 인터넷 트래픽 성능을 개선하여 지연 시간을 줄일 수 있도록 돕습니다. Global Accelerator는 [AWS 글로벌 네트워크를](https://aws.amazon.com/about-aws/global-infrastructure/global_network/) 사용하여 클라이언트와 가장 가까운 AWS 리전의 정상 애플리케이션 엔드포인트로 트래픽을 전달합니다.
**WordPress에 대해 자세히 알아보기**
WordPress에 대한 자세한 내용은 [http://codex.wordpress.org/](http://codex.wordpress.org/)에서 WordPress Codex 도움 문서를 참조하세요.
설치 문제 해결에 대한 자세한 내용은 [일반적인 설치 문제를](https://wordpress.org/support/article/how-to-install-wordpress/#common-installation-problems) 참조하세요.
WordPress 블로그의 보안을 강화하는 방법에 대한 자세한 내용은 [ WordPress 강화를](https://wordpress.org/support/article/hardening-wordpress/) 참조하세요.
WordPress 블로그up-to-date 유지하는 방법에 대한 자세한 내용은 [ WordPress 업데이트를](https://wordpress.org/support/article/updating-wordpress/) 참조하세요.
## 도움말\$1 내 퍼블릭 DNS 이름이 변경되어 블로그를 사용할 수 없습니다.
WordPress 설치 위치는 EC2 인스턴스의 퍼블릭 DNS 주소를 사용해 자동으로 구성됩니다. 이때 인스턴스를 중단했다가 다시 시작하면 퍼블릭 DNS 주소가 바뀌어(탄력적 IP 주소와 연결되어 있지 않은 경우) 블로그를 더 이상 사용할 수 없게 됩니다. 리소스를 참조해야 할 주소가 더 이상 존재하지 않거나 다른 EC2 인스턴스에 할당되었기 때문입니다. 문제에 대한 자세한 설명과 몇 가지 가능한 해결 방법은 [사이트 URL 변경에](https://wordpress.org/support/article/changing-the-site-url/) 요약되어 있습니다.
WordPress 설치에이 문제가 발생한 경우 WordPress용 **wp-cli** 명령줄 인터페이스를 사용하는 아래 절차를 사용하여 블로그를 복구할 수 있습니다.
****wp-cli**를 사용하여 WordPress 사이트 URL을 바꾸는 방법**
1. SSH를 통해 EC2 인스턴스에 연결합니다.
1. 인스턴스의 이전 사이트 URL과 새로운 사이트 URL을 기록합니다. 이전 사이트 URL은 WordPress 설치 시 EC2 인스턴스의 퍼블릭 DNS 이름일 가능성이 높습니다. 그리고 새로운 사이트 URL은 EC2 인스턴스의 현재 퍼블릭 DNS 이름입니다. 이전 사이트 URL을 잘 모르더라도 아래와 같이 **curl** 명령을 사용하여 찾을 수 있습니다.
```
[ec2-user ~]$ curl localhost | grep wp-content
```
명령을 실행하여 출력되는 화면에서 이전 퍼블릭 DNS 이름의 참조를 확인해야 합니다. 출력 화면은 다음과 같습니다(빨간색의 이전 사이트 URL).
```
```
1. 다음 명령으로 **wp-cli**를 다운로드합니다.
```
[ec2-user ~]$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
```
1. 아래와 같은 명령으로 이전 사이트 URL을 찾아 WordPress 설치 위치로 바꿉니다. EC2 인스턴스의 이전 사이트 URL과 새로운 사이트 URL, 그리고 WordPress 설치 경로(일반적으로 `/var/www/html` 또는 `/var/www/html/blog`)를 치환합니다.
```
[ec2-user ~]$ php wp-cli.phar search-replace 'old_site_url' 'new_site_url' --path=/path/to/wordpress/installation --skip-columns=guid
```
1. 웹 브라우저에서 WordPress 블로그의 새로운 사이트 URL을 입력하여 사이트에 올바로 접속되는지 다시 확인합니다. 그렇지 않은 경우 [사이트 URL 변경](https://wordpress.org/support/article/changing-the-site-url/) 및 [일반적인 설치 문제](https://wordpress.org/support/article/how-to-install-wordpress/#common-installation-problems)에서 자세한 내용을 참조하세요.