일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 네이버 클라우드 플랫폼
- AD
- Python
- CloudFront
- CLI
- FSX
- security group
- Subnet
- Athena
- Jenkins
- VPC
- terraform
- NaCl
- S3
- Storage
- lambda
- ncp
- 테라폼
- ALB
- AWS
- storage gateway
- route table
- 윈도우
- EC2
- Linux
- Windows
- 도메인
- RDS
- Dedup
- dns
- Today
- Total
끄적이는 보송
[AWS] S3 엔드포인트가 VPC에 구성된 경우 EC2에서 yum 수행이 안되는 문제 해결 본문
문제 발생
Private Subnet에 위치한 Amazon Linux 2 EC2 Instnace가 패키지를 아래 에러 메시지를 뱉으며 다운로드하지 못하는 문제가 발생했었다. 외부로 핑은 나가는데 패키지 다운로드할 때 미러사이트를 찾지 못해 설치가 안된다는 것이다. Private EC2 Instance는 당연하게도 NAT GW를 통해 인터넷 통신을 하고 있는 환경이다.
Could not retrieve mirrorlist http://repo.ap-northeast-2.amazonaws.com/.../mirror.list error was
이를 해결해 보려, VPC Outbound 설정에 막힌 것은 아닌지, Security Group, NACL, DHCP 옵션 셋, VPC 필요 옵션 활성화, Route Table 정책 등등을 확인해 보았지만 문제는 없었다.
나의 경우, 조금 특이한 점이라면 S3 통신을 위한 S3 Gateway Endpoint를 생성해줬다는 것이며, 여기에 원인이 있었다.
문제 해결 및 원인
일단 레포지토리에 정상적으로 접속하는지 curl 명령어를 실행해 보았다. 403 에러가 발생했으며 이는 클라이언트의 요청이 도달하였나 거부되었음을 의미한다. 내 눈에 띈 것은 하단의 S3 부분이었다.
알고 보니 Amazon Linux 레포지토리는 S3에 HTTP 호스팅 되며 S3 엔드포인트 정책에서 이에 대한 액세스를 허용해야 하는 것이다. 그리고 S3 Gateway Endpoint의 Policy에 문제가 있었다. 특정 S3 Bucket으로만 통신을 허용하도록 되어 있으니 Amazon Linux EC2는 패키지 다운을 위해 S3에 호스팅 되지 않아 문제가 발생했던 것이다.
이것이 문제의 정책이다. 바로 Resource 부분에 특정 S3 Bucket만을 바라보도록 구성되어 있었다.
{
"Id": "Policy1111111111111",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1111111111111",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::bucketname",
"Principal": "*"
}
]
}
이것을 *로 변경하여 전부를 지정하거나 아니면 아래의 arn 주소를 resource에 추가해줘야 한다. 당연히 자신이 사용하고 있는 Region에 맞게 조금은 수정해줘야 한다.
바로 이렇게 말이다. (*Amazon Linux2 기준)
{
"Id": "Policy1111111111111",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1111111111111",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::bucketname",
"arn:aws:s3:::amazonlinux.ap-northeast-2.amazonaws.com/*",
"arn:aws:s3:::amazonlinux-2-repos-ap-northeast-2/*"
]
"Principal": "*"
}
]
}
재밌는 점
이는 Amazon Linux에만 국한된 이야기이며 다른 OS(ex. ubuntun, suse etc...)는 별문제 없이 잘만 패키지를 받아온다. 왜냐하면 패키지 설치를 위해 이들의 레포지토리는 S3로 호스팅 하지 않기 때문이다.
재밌는 점은 Private Amazon Linux Instnace는 NAT GW 없이 외부 인터넷 통신이 불가한 상황에서도 S3 Gateway Endpoitnt를 통해 패키지를 다운로드할 수 있다는 것이다. 단, s3를 통해 레포지토리를 참고하여 패키지를 다운로드하는 것이므로 모든 패키지를 설치할 수 있을 거 같지는 않다.
추가사항
추가로 하나 더 적어본다. S3 Gateway Endpoint(VPC endpoint)를 생성하고 Route Table을 지정하면 하단의 그림처럼 Route Table 정책에 추가되는 것을 볼 수 있다. 이 엔드포인트는 다른 AWS 서비스 간에 프라이빗한 연결을 생성할 수 있게 도와준다. 자세히 보면 서비스의 접두사 목록 ID를 지정하는 대신 'pl'로 시작하는 수정도 안 되는 Destination이 지정되어 있는데 이는 일종의 S3 버킷의 IP주소들의 집합이라고 보면 된다.
S3도 IP주소가 있으며 자주 변경되는 것이기 때문에 이런 ID로 입력되는 것인데, 이 'pl-78 a54011'라는 녀석이 어떤 CIDR를 품고 있는지 ec2 describe 명령어로 알아볼 수 있다.
AWS에서는 Private 한 통신이라고 광고하지만 정작확인해보면 Public IP 대역을 보여주고 있다. 사실은 Internet 통신이라는 것이다. 인터넷 통신이라고는 하지만 그들만의 사적인(?) 통신이기 때문에 'Private'라고 하는 건지는 잘 모르겠다.
'STUDY > AWS' 카테고리의 다른 글
[AWS] CloudWatch를 이용한 Billing 알람 설정하기 (0) | 2023.02.08 |
---|---|
[AWS] AWS Compute Optimizer (0) | 2023.01.30 |
Cloud9 연결 오류 원인 및 해결 (1) | 2022.12.20 |
[AWS] Amazon FSx for Windows Server 백업 실패 분석 및 해결(Maintenance Windows 설정 원인) (0) | 2022.12.02 |
Amazon RI(Reserved Instance) 구입해보기 (0) | 2022.11.24 |