Tagged: AWS

AWS S3 PreSigned URL 설정하기

AWS S3 PreSigned URL 설정에 대해서 알아 본다. AWS S3 는 저장된 객체에 대해 HTTP 를 통해서 다운로드를 제공 한다. 문제는 이렇게 객체를 다운로드 하도록 주소를 공개할 경우에 누구나 다운로드 할 수있게 되서 보안상 좋지 않다. 그래서 AWS S3 는 인증 과정을 통해서 특정 시간 동안만 URL 에 다운로드 권한을 부여하는 PreSigned URL 기능을 제공하는데 이에 대해서 알아 본다.

AWS 사용자

먼저 PreSigned URL 에 인증 과정에서 사용할 Signiture 생성을 위해서 accesskey, secretkey 가 필요하다. 이것은 결국 AWS 사용자가 필요하다는 것과 같다.

사용자를 추가할때는 “AWS 액세스 유형 선택” 에서 “액세스 키- 프로그래밍 방식 액세스” 유형으로 계정을 생성해야 한다. AWS 콘솔로 로그인이 불필요한 사용자 이기 때문인데, 이렇게 생성을 진행하면 마지막에 accesskey, secretkey 가 발급되어 진다. 이것을 잘 보관 하자.

IAM Role, Policy

AWS S3 Presigned URL 을 위해 생성한 AWS 계정에는 그 어떤 IAM Role, Policy 가 필요하지 않다. 이것은 사용자에 S3 권한 설정을 IAM 을 통해서 할지 아니면 AWS S3 의 Permission Policy 로 할지에 따라 다를 수 있다. AWS S3 에서도 Permission Policy 를 설정할 수 있고 이 설정에서 특정 사용자에게 정책을 부여할 수 있다.

AWS S3 Presigned URL 만을 위한 계정이기 때문에 IAM 에서 권한을 부여하지 말고 AWS S3 에서 권한을 부여 방법을 선택 했다.

AWS S3 생성

AWS S3 는 글로벌 한 서비스이지만 생성할 리전을 선택할 수 있다. 생성할때에 S3 버킷에 대해서 별다른 설정을 하지 않고 그냥 기본값으로 생성한다. 나중에 설정을 얼마든지 변경할 수 있는데, 단 Presigned URL 을 한다고 해서 “Block Public Access settings for this bucket” 을 손대서는 안된다.

PreSigned URL 을 한다고 버킷의 공개 접근 설정을 변경해서는 절대로 안된다. 혹자는 URL 자체를 제공해줘야 하기 때문에 공개설정을 해줘야 한다고 하지만 특정 사용자에게 URL 을 제공하는 방식이기 때문에 버킷의 공개 접근 설정은 불 필요 하다.

AWS S3 Bucket Policy

여기서 핵심인데, 앞에서 AWS 계정에 아무런 권한 설정을 하지 않았다. 이제 그 권한 설정을 AWS S3 버킷에서 해주면 된다. Permission 탭에서 Bucket Policy 를 볼 수 있는데, 여기서 다음과 같이 해주자.

Bucket Policy 정책
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicRead",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::1234567890:user/systemv"
            },
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion"
            ],
            "Resource": [
                "arn:aws:s3:::bucket_name",
                "arn:aws:s3:::bucket_name/*"
            ]
        }
    ]
}

Principal 에 앞에서 생성한 AWS 계정이다. Resource 에는 Bucket 의 arn 을 주면 된다.

테스트

이제 테스트를 해보자. 테스트는 간단하게 Python 코드를 작성해 해보면 된다.

Presigned URL 테스트 코드
Python
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
31
32
33
34
35
36
37
38
39
40
41
# -*- coding: utf-8 -*-
import logging
import boto3
from botocore.exceptions import ClientError
import requests  # To install: pip install requests
 
 
def create_presigned_url(bucket_name, object_name, expiration=60):
    """Generate a presigned URL to share an S3 object
 
    :param bucket_name: string
    :param object_name: string
    :param expiration: Time in seconds for the presigned URL to remain valid
    :return: Presigned URL as string. If error, returns None.
    """
 
    # Generate a presigned URL for the S3 object
    s3_client = boto3.client(
        "s3",
        aws_access_key_id="access key id",
        aws_secret_access_key="secret access key",
        region_name="ap-northeast-2",
    )
    try:
        response = s3_client.generate_presigned_url(
            "get_object", Params={"Bucket": bucket_name, "Key": object_name}, ExpiresIn=expiration
        )
    except ClientError as e:
        logging.error(e)
        return None
 
    # The response contains the presigned URL
    return response
 
 
if __name__ >= "__main__":
    url = create_presigned_url("Bucket Name", "utils/putty.exe")
    print(url)
    if url is not None:
        response = requests.get(url)
        print(response)

access key id 와 secret key id, Bucket Name 에 본인에 맞게 수정해 준다. 거기다 ‘utils/putty.exe’ 는 AWS S3 버킷에 있는 객체다.

위 코드를 실행하면 Presigned URL 이 출력이 된다. 유효기간은 expiration 변수에 값을 수정하거나 인자로 주면 된다. 기본값은 60초 이다.

강남의 클라우드 회사들.. 테크 기업 맞나?

한국뿐만 아니라 전 세계적으로 이제는 클라우드(Cloud) 가 대세다. 이런 대세속에서 특이하게도 한국은 아직 그 시장 크지 않다. 정확하게 말하면 클라우드로 전환해서 쓰는 비율이 잘해야 15% 정도. 아직도 랙 서버 기반의 IDC 서버를 많이 쓴다.

최근에 금융권에서도 공공 클라우드 사업자를 선정해 클라우드로 전환하는 사례가 있다. 대표적인게 국민카드. 리브메이트 앱이 아마도 클라우드로 구축된 사례일 것이다.

이렇게 큰 규모에 경우에 클라우드 사업을 위해서는 클라우드를 잘 아는 기업을 선정해서 기술지원을 받는다. 국내에 클라우드는 AWS, Azure, GCP 삼파전인데 이들 글로벌 클라우드 회사에 기술을 가져다 다른 기업에 기술지원과 전환작업을 해주는 회사들이 존재하는데 그런 회사를 MSP 회사라고 한다. 이런 MSP 회사들 중에 한국에서는 대표적인 회사 두 회사가 있는데 강남에 있다. 신기하게도 한 두블럭이면 갈 수 있을 정도로 인접해 있다.

국내 금융권에서도 클라우드를 사용하고 하는 움직임이 있기 때문에 클라우드 엔지니어에 대한 수요가 상당하다. 문제는 이런 수요가 많은 만큼 그러한 기술을 지원해줄 사람들은 많이 없다는데 문제가 있다.

그런데, 사람이 아무리 없기로서니 아무나 다 뽑아서 프로젝트 매니저로 보내는 일은 없어야 하지 않을까? 프로젝트 매니저로 온 사람이라면 적어도 프로젝트에 대해 기술적 방향성이나 제안등을 할 수 있을 정도는 되어야 하는데 AWS EC2 가 뭔지도 모르거나, 그러다보니 전체적인 서비스를 서로 엮어서 전체적인 시스템을 만들어내는 아키텍쳐에 대한 지식도 없는 사람이 프로젝트 매니저를 하는 건 문제가 있다.

그런 기술적인 숙련도가 없는 사람을 그것도 강남에 클라우드 회사에서 정규직으로 뽑아놓고 현장에 뿌리고 있는데, 이런 현장에서는 매니저라는 사람의 사고 방식은 대부분 다음과 같다.

나는 프로젝트 매니저다. 기술은 잘 몰라도 내가 하라고 하면 너는 해야한다. 그러라고 돈주고 뽑은거다.

적도 프로젝트 매니저라면 몇년씩 클라우드 경력을 쌓은 사람에 대한 예의라도 있어야 하는데, 거꾸로 내가 책임자니까 무소 불휘의 권력을 쥔것마냥, 고작 한다는 것이 엑셀 파일에 자원 현황이나 기록하고 있고 그것을 잘 정리하지 않는다고 닥달하는 모습을 보여주는게 최근에 벌어지는 일이다.

클라우드 본사가 만든 한심한 아키텍쳐

강남에 이름 있다하는 클라우드 회사가 만들었다는 아키텍쳐에 일부다. AWS 클라우드 다이어그램인데, Public Subnet 이 두개, Private Subnet 그 뒤에 1개 있다.

EndPoint 를 NLB 가 받고 이것을 뒤에 Public Subnet 에 있는 웹 방화벽이 받고 있다. 웃기지 않나? 여기서 이것이 왜 문제가 되는지를 이해하지 못한다면 심각하게 자신의 능력을 한번 되돌아 봐야 한다.

웹 방화벽은 그야말로 웹에서 들어오는 패킷에 대한 보안검사기능을 한다. L7 패킷 검사가 가능한 장비. 그런데, 저렇게 Public Subnet 에 그것도 EIP 를 박아서 놔두면 십중팔구 DDOS 공격 대상이다. AWS 의 Shield 서비스를 해준다고 하지만 차라리 Private Subnet 구축하는게 훨씬 낫다. (AWS Shield Standard 는 EC2 인스턴스에 대한 DDOS 방어를 해주지 않는다. Advanced 는 가능하지만 한달에 3,000 달러다) 이렇게 웹 방화벽을 Public Subnet 에 올려놓고 구축하는 사례는 본적이 없다.

문제는 또 있다. 웹 방화벽은 EC2 인스턴스로 구축된다. 이 웹 방화벽은 뒤에 ALB 에 연결되는 구조다. 웹 방화벽이 ALB 의 도메인으로 연결이 된다고 하더라도 어짜피 커넥션은 IP 기반이 될 것이다. ALB 는 고정IP 가 아닌 유동 IP 이며 늘었다 줄었다 하게 된다. 웹 방화벽이 이렇게 유동적으로 변경되는 IP를 탐지해서 연결 설정을 해주면 고맙겠지만 안타갑게도 이중화를 위한 IP 2개만 들어간다.

십중팔구 트래픽일 몰리게 되면 방화벽이 뒤에 ALB 로 보내는 트래픽 양이 늘어날텐데 ALB 에서는 IP 를 늘리겠지만 그렇게 해봤자 아무런 소용이 없게 된다.

또 다른 문제는 EndPoint 로 NLB 를 사용했다는 데 있다. NLB 는 L4 계열이다. 네트워크 라우트 경로 설정에 유용하지 HTTP 기반의 연결에는 부적합하다. 가장 문제가 되는 것이 AWS WAF 문제다. AWS WAF 서비스는 Web 방화벽이다. Web 은 L7 기반인데, 당연히 NLB 에 연동될 수가 없다.

AWS WAF 의 경우에 ALB, CloudFront 등에 연동 된다. 요 몇일 AWS WAF 설정해야 한다고 난리던데, 그러면 WAF 를 EC2 웹 방화벽 뒤에 있는 Private Subnet 의 ALB 에 붙일 수 밖에 없든데, 얼간이 같은 설정이다. 앞에 이미 EC2 기반의 웹 방화벽이 일을 하고 있는데, 뒷단에 WAF 를 붙여서 뭣하게?

수준이 너무나 낮다

적어도 클라우드 MSP 사업을 영위하고 있다면, 적어도 프로젝트 매니징 능력이라도 있는 사람을 현장에 투입하고 아키텍쳐 또한 유기적인 조합이 가능하도록 해야 할 것이 아닌가?

더 크게 생각해볼 문제도 있다. 최근에 공정한 경쟁에 대한 관심은 우리 사회에 큰 논란을 낳기도 했다. 인국공 문제가 그런 것이다. 인천국제공항에 비정규직의 정규직화는 정규직 직원들에 대한 불공정 시비를 불렀다. 불공정한 경쟁으로 특정한 자리, 위치에 올라서 다른 사람을 부리는 것을 우리사회는 용납하지 않는다.

이번 프로젝트를 하면서 느낀 것이 바로 저러한 것이였다. 프로젝트 매니저라고 하는 사람은 아무것도 몰랐다. 그져 AWS 라는 것이 무엇이다 정도. PC 를 사용자중에서도 파워유저급과 비교될 정도 수준 일 뿐이다. 그런 사람이 프로젝트 매니저를 한다는 것이 그져 기술을 아는 사람을 대려다가 엑셀 파일이나 작성하며서 다 됐냐 안됐냐 만 따지는 것이 과연 공정한 것인가?

이런식이면 대학교를 막 졸업한 컴퓨터 관련 전공자를 앉혀놔도 될 정도다.

강남에 클라우드 회사는 테크 회사다. 본인들이 외주 업체 직원을 뽑을때에 기술이 낫을 거 같은 사람들이 많으니 기술면접을 엄격하게 진행하는 마당이면 적어도 본인들 회사 직원들 또한 그런 기준으로 뽑아야 하지 않겠나…..

Best Practice

클라우드를 하다보면 이런 말을 자주 듣게 된다. 한국어로 번역하자면 “모범 사례” 인데, 클라우드 아키텍쳐에 대한 모범사례를 다양하게 익히는 것이 좋다. 아키텍쳐라는 것이 정답이 없다보니 그나마 좋다라고 하는 것을 익히는 것이다.

여러 엔지니어, 특히나 강남에 클라우드에 다닌다는 사람들과 이야기를 하다보면 너도나도 모범 사례들을 이야기 한다. AWS 의 경우에 Re:Invent 행사에서 많이 다뤄지기도 해서 많이 알려진 것들도 많다. 하지만 이런 사람들이 도맡아 하는 기업의 아키텍쳐는 모범 사례는 고사하고 기초적인 3-Tier 모놀리틱 아키텍쳐를 클라우드로 구현하지 못한다.

대표적인 사례가 AutoScaling Group 사용을 하는 비율이 많지 않다. 금융권은 전멸이고 그나마 좀 사용한다는 곳이 쇼핑몰 들이다. CloudFront 를 EndPoint 로 하고 Static 파일은 S3, Dynamic 은 ALB 뒤에 EC2 서버로 서빙하는 구조를 가지는 아키텍쳐를 찾기도 힘들다.

HTTP 헤더 조작을 많이 한다면 이야기가 달라지만, 아직도 Apache + Tomcat 혹은 Nginx + Tomcat 으로 서버를 구성하는 곳도 지천이다. ALB – Apache – Tomcat 구조. Apache 에서는 mod_jk 로 톰캣 연동…. static 파일 서빙을 위해서 Apache 를 넣었다는 건데, 바보 같은 짓이다.

널리고 널렸다. 왜 이렇게 됐을까? 고객이라고 우쭈쭈쭈 고객님 말씀이 옳습니다 하는 바람에 이런 멍청한 구조가 나온 것이다.

기술의 발전은 인간을 이롭게 하는데 있다. 이것은 엔지니어에게도 그대로 적용된다. 왜 클라우드를 사용하는가? 기업의 대답은 “돈” 이겠지만 나의 대답은 “인간을 이롭게 하기 위해” 그냥 직접적으로 말한다면 “야근을 하지 않기 위해” 서다. 클라우드를 사용한다면 언제든지 Continuous 한 서비스 운영이 가능해지는데, 죽어도 이것을 하면 안된다고 하는 고객들을 설득할 마음조차도 없는게 국내 MSP 업체들이다.

그런 와중에 능력도 없는 프로젝트 매니저라니…. 대가리 박고 반성해라.. M사..

AWS CloudFormation 보안 모범 사례

이 문서는 다음의 내용을 번역한 것입니다.

AWS CloudFormation을 사용하면 개발자와 시스템 관리자가 AWS와 연관된 리소스 모음을 질서있고 예측 가능한 방식으로 프로비저닝하고 업데이트하여 쉽게 생성하고 관리 할 수 ​​있다. 우리의 많은 고객들은 그들의 AWS 환경에서 변경사항을 간단하게 캡쳐하고 버전 제어를 실행하고 인프라에서 다른 작업 중에서도 비용을 관리하는 등에 모든 리소스를 제어하기 위해 CloudFormation 을 사용한다.

고객들은 자주 어떻게 CloudFormation 스택에 허가권을 제어하는 우리에게 묻는다. 이 글에서, 우리는 CloudFormation 에 대한 AWS Identity 와 IAM 정책을 사용, CloudFormation 에 특화된 IAM 조건 그리고 CloudFormation 스택 정책들을 포함하는 몇가지 모범사례를 공유한다. 대부분의 CloudFormation 배포는 AWS CLI 나 SDK 를 통해서 이루어지기 때문에 우리는 모범 사례를 어떻게 구현하는지 보여주기 위해서 AWS CLI 와 SDK 사용에 포커스를 둘 것이다.

IAM 을 통한 CloudFormation 스택 접근 제한

IAM 을 통해서, 여러분은 정책이나 사용자 혹은 롤(role) 을 사용함으로써 AWS 서비스나 리소스 접근을 보안적으로 통제할 수 있다. CloudFormation 은 fine-grained(세분화된) 액세스 제어를 제공하기 위해서 IAM 을 지렛대로 사용한다.

모범사례를 통해서, 우리는 최소 권한 원칙을 적용된 IAM 정책들을 통해 AWS 서비스 및 자원 접근을 제한하기 권한다. 이것을 하는 가장 단순한 방법은 CloudFormation 에 특정 API 콜을 제한하는 것이다. 예를들어, 여러분은 특정 IAM 유저나 롤이 CloudFormation 스택을 삭제하거나 업데이트하길 원하지 않을 것이다. 다음의 단수한 정책들은 모든 CloudFormation API 접근을 허용하지만 여러분의 프로덕트 스택의 UpdateStack 과 DeleteStack API 접근은 거부한다.

CloudFormation 을 위한 정책(Polices)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
    "Version":"2012-10-17",
    "Statement":[{
        "Effect":"Allow",
        "Action":[        
            "cloudformation:*"
        ],
        "Resource":"*"
    },
    {
        "Effect":"Deny",
        "Action":[        
            "cloudformation:UpdateStack",
            "cloudformation:DeleteStack"
        ],
        "Resource":"arn:aws:cloudformation:us-east-1:123456789012:stack/MyProductionStack/*"
    }]
}

IAM 정책은 종종 특정 리소스를 생성할 수 있도록 허용해야 하지만 이러한 리소스를 CloudFormation의 일부로 생성하지 않을 수 있다. 이것이 CloudFormation 의 IAM 조건 지원이 제공된다.

CloudFormation 을 위한 IAM 조건

다음은 여러분의 IAM 정책에 추가할 수 있는 세가지 CloudFormation 특화된 IAM 조건들이다.

  • cloudformation:TemplateURL
  • cloudformation:ResourceTypes
  • cloudformation:StackPolicyURL

이러한 세가지 조건을 통해서, 여러분은 특정리소스 생성, 업데이트, 특정 템프릿 사용등과 같은 스택 작업을 API 로 가능해지거나 스택 업데이트 중에 의도하지 않게 업데이트나 삭제가 될수 있는 스택 리소스를 방지하는 스택 정책을 사용해 특정 리소스를 제한할 수 있다.

Condition: TemplateURL

첫째 조건, Condition: TemplateURL, 생성, 업데이트, reside 등과 같은 스택 작업에 대해 CloudFormation 템플릿을 지정하도록 하고 그것만 사용하도록 강제한다. IAM 정책에서, 다음과 같다.

Condition: TemplateURL 을 위한 정책(Polices)
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
31
{
    "Version":"2012-10-17",
    "Statement":[{
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            “cloudformation:UpdateStack”
        ],
        "Resource": "*",
        "Condition": {
            "StringNotEquals": {
                "cloudformation:TemplateURL": [
                    "https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template"
                ]
            }
        }
    },
    {
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            "cloudformation:UpdateStack"
        ],
        "Resource": "*",
        "Condition": {
            "Null": {
                "cloudformation:TemplateURL": "true"
            }
        }
    }]
}

첫번째 구분은 지정된 템플릿에 한해서 모든 CreateStack 과 UpdateStack API 콜을 활성화 한다. 두번째 구분에서 모든 CreateStack 이나 UpdateStack API 콜들은 TemplateURL 파라메터를 반드시 포함하도록 한다. CLI 에서 여러분의 호출들은 –template-url 파라메터를 포함해야 한다.

CLI를 이용한 template-url
ZSH
1
aws cloudformation create-stack –stack-name cloudformation-demo –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template

Condition: ResourceTypes

CloudFormation 은 IAM 정책을 통해서 템플릿 생성, 업데이트에 리소스 타입을 제어할 수 있도록 해준다. CloudFormation API는 ResourceTypes 파라메터를 받는다. API 호출에서, 생성이나 업데이트할 수 있는 리소스 유형을 지정할 수 있다. 하지만, 새로운 ResourceTypes 파라메터를 사용하기 위해서는 다음과 같이 컨디션 조건을 추가함으로서 특정한 파라메터 사용이 가능하도록 IAM 정책을 수정할 필요가 있다.

새로운 ResourceType 설정
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
31
{
    "Version":"2012-10-17",
    "Statement":[{
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            "cloudformation:UpdateStack"
        ],
        "Resource": "*",
        "Condition": {
            "ForAllValues:StringLike": {
                "cloudformation:ResourceTypes": [
                    "AWS::IAM::*"
                ]
            }
        }
    },
    {
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            "cloudformation:UpdateStack"
        ],
        "Resource": "*",
        "Condition": {
            "Null": {
                "cloudformation:ResourceTypes": "true"
            }
        }
    }]
}

CLI 에서, 여러분의 호출은 –resource-types 파라메터 포함할 필요가 있다. 여러분의 스택을 업데이트하기 위한 호출은 다음과 같다.

CLI를 이용한 --resource-types
ZSH
1
aws cloudformation create-stack –stack-name cloudformation-demo –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template –resource-types="[AWS::IAM::Group, AWS::IAM::User]"

쉘(Shell)에 따라서 명령어는 쌍따옴표를 사용해야할 수도 있다. 그렇지 않으면 “No JSON object could be decoded” 에러를 보게 될 것이다.

CLI 사용시 쌍따옴표 사용
ZSH
1
aws cloudformation create-stack –stack-name cloudformation-demo –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template –resource-types='["AWS::IAM::Group", "AWS::IAM::User"]'

ResourceTypes 조건은 CLI 나 API 호출을 통해서 CloudFormation 이 올바른 리소스 타입과 템플릿을 생성, 업데이트 하도록 합니다. 첫번째 예제에서, 우리의 IAM 정책은 AWS::IAM 리소스를 포함한 예제였기 때문에 API 호출을 차단했을 것이다. 만약 우리의 템플릿이 오직 AWS::EC2::Instance 자원만 포함한다면, CLI 명령어는 다음과 같을 것이며 성공할 것입니다.

CLI command 예제
ZSH
1
aws cloudformation create-stack –stack-name cloudformation-demo –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template –resource-types='["AWS::EC2::Instance"]'

세번째 조건은 StackPolicyURL 조건이다. 어떻게 동작하는지 설명하기 전에, 우리는 스택 정책에 대해 몇가지 추가적인 컨텍스트를 제공할 필요가 있다.

Stack Policies

가끔, 최악의 운영 중단은 의도되지 않은 리소스에 변경으로 발생 된다. 이 리스크를 완화하는데 도움이 되기 위해, CloudFormation 은 스택 정책들을 제공는데 이것은 스택 업데이트 중에 의도치않은 업데이트나 삭제로부터 스택 리소스들을 보호해준다. IAM 과 함께 사용할 경우, 스택 정책들은 스택 리소스에 대해 악의적이고 의도치않은 변경 모두에 대해 두번째 방어 계층을 제공 한다.

CloudFormation 스택 정책은 스택 업데이트 작업의 일부로 업데이트할 수 있는 항목을 정의하는 JSON 문서다. 정책을 지정하거나 업데이트하기 위해서, 여러분의 IAM 사용자 혹은 롤(Role)은 반드시 우선적으로 Cloudformation::SetStackPolicy 액션을 호출 할 수 있어야 한다.

여러분 스택에 직접 스택 정책을 적용한다. 주의해야할 것은 이것은 IAM 정책이 아니다. 기본적으로, 스택 정책 설정은 명시적으로 Allow 지정하지 않는 한 업데이트를 거부하기 위해 Deny 를 사용해 모든 스택 리소스들을 보호한다. 이것은 만약 오직 몇가지 리소스들만 제한 하길 원한다면, 리소스 “*” 를 사용해 Allow 를 포함으로써 모든 업데이트를 반드시 명시적으로 허용해야 하며 특정 리소스를 Deny 해야 한다.

예를들면, 스택 정책은 라이브로 진행되는 데이터를 포함하고 있기 때문에 프로덕션 데이터베이스를 보호하는 데 종종 사용된다. 변경중인 필드에 따라 업데이트중에 전체 데이터베이스를 교체할 수 있는 경우가 있다. 다음의 예제는, 스택 정책은 명시적으로 프로덕션 데이터베이스 업데이트 시도를 거부한다.

프로덕션 데이터베이스 업데이트 거부
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
  "Statement" : [
    {
      "Effect" : "Deny",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "LogicalResourceId/ProductionDB_logical_ID"
    },
    {
      "Effect" : "Allow",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "*"
    }
  ]
}

여러분은 모든 RDS DB 인스턴스나 주어진 ResourceType 을 포함하도록 여러분의 스택 정책을 일반화 할 수 있다. 이것을 얻기 위해서는 컨디션 사용한다. 그러나, 우리의 예제는 와일드카드를 사용했기 때문에, condition 은 반드시 “StringEquals” 이 아닌 “StringLike” condition 을 사용해야 한다.

StringLike 사용예
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "Statement" : [
    {
      "Effect" : "Deny",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "*",
      "Condition" : {
        "StringLike" : {
          "ResourceType" : ["AWS::RDS::DBInstance", "AWS::AutoScaling::*"]
        }
      }
    },
    {
      "Effect" : "Allow",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "*"
    }
  ]
}

스택 정책에 대한 보다 많은 정보는  Prevent Updates to Stack Resources 참고하라.

마지막으로, 여러분의 모든 스택에 알맞은 미리 정의된 스택 정책을 가지고 있는지를 확인해라. 이것을 해결할려면 IAM 정책을 봐야 한다.

Condition:StackPolicyURL

여러분의 IAM 정책 내에서, 여러분은 모든 CloudFormation 스택이 StackPolicyURL 조건을 가지고 생성된 것과 연결된 스택 정책을 가지는지를 확인할 수 있다.

StackPolicyURL 조건 예제
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
{
    "Version":"2012-10-17",
    "Statement":[
    {
            "Effect": "Deny",
            "Action": [
                "cloudformation:SetStackPolicy"
            ],
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringNotEquals": {
                    "cloudformation:StackPolicyUrl": [
                        "https://s3.amazonaws.com/samplebucket/sampleallowpolicy.json"
                    ]
                }
            }
        },    
       {
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            "cloudformation:UpdateStack"
        ],
        "Resource": "*",
        "Condition": {
            "ForAnyValue:StringNotEquals": {
                "cloudformation:StackPolicyUrl": [
                    “https://s3.amazonaws.com/samplebucket/sampledenypolicy.json”
                ]
            }
        }
    },
    {
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            "cloudformation:UpdateStack",
            “cloudformation:SetStackPolicy”
        ],
        "Resource": "*",
        "Condition": {
            "Null": {
                "cloudformation:StackPolicyUrl": "true"
            }
        }
    }]
}

이 정책은 SetStackPolicy 가 호출될때마다 반드시 스택 정책 URL 이 지정되어 있는지 확인한다. 이 경우에, URL 은 https://s3.amazonaws.com/samplebucket/sampleallowpolicy.json 다. 유사하게, 모든 생성과 업데이트 스택 연산에서, 이 정책은 StackPolicyURL 은 S3 에 sampledenypolicy.json 문서로 지정되었고, StackPolicyURL 은 항상 지정된다. CLI 에서 create-stack 명령어는 다음과 같다.

StackPolicyURL CLI 명령어 예제
ZSH
1
aws cloudformation create-stack –stack-name cloudformation-demo –parameters ParameterKey=Password,ParameterValue=CloudFormationDemo –capabilities CAPABILITY_IAM –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template –stack-policy-url https://s3-us-east-1.amazonaws.com/samplebucket/sampledenypolicy.json

주의해야 할 것은 만약 스택 업데이트에 새로운 스택 정책을 지정한다면, CloudFormation 은 이미 있는 스택 정책을 사용한다. 새로운 정책은 오직 이후 업데이트에만 새 정책을 사용한다. 예를들어, 현재 정책이 모든 업데이트를 거부하도록 지정되어 있다면, 딱 한개 업데이트를 허용하기 위해서 스택정책을 변경할려면 반드시 SetStackPolicy 명령어를 실행해야 한다. 그리고 여러분은 스택에 대해서 업데이트 명령어를 실행할 수 있다. 이미 생성된 스택 업데이트를 위해서 다음과 같이 실행 할 수 있다.

SetStackPolicy CLI 명령어 예제
ZSH
1
aws cloudformation set-stack-policy –stack-name cloudformation-demo –stack-policy-url https://s3-us-east-1.amazonaws.com/samplebucket/sampleallowpolicy.json

그리고 업데이트를 실행할 수 있다.

SetStackPolicy 이후에 stack 업데이트 실행
ZSH
1
aws cloudformation update-stack –stack-name cloudformation-demo –parameters ParameterKey=Password,ParameterValue=NewPassword –capabilities CAPABILITY_IAM –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template –stack-policy-url https://s3-us-west-2.amazonaws.com/awshubfiles/sampledenypolicy.json

우리가 사용하는 IAM 정책은 스택이 생성 혹은 업데이트 될때마다 스택에 적용되어질 특정한 스택 정책을 보장한다.

Conclusion

CloudFormation 은 연관된 AWS 리소스를 생성, 관리하는 반복적인 방법을 제공한다. IAM 정책, 사용자, 롤, CloudFormation-specific IAM condition, 스택 정책을 조합해 사용함으로써, 여러분은 CloudFormation 스택을 의도한데로 사용하고 잘못된 업데이트, 삭제를 최소할 수 있다.

You can learn more about this topic and other CloudFormation best practices in the recording of our re:Invent 2015 session, (DVO304) AWS CloudFormation Best Practices, and in our documentation.

AWS EKS 클러스터 셋업

How to setup

AWS 의 EKS Cluster 를 셋업할 수 있는 방법에는 다음과 같다.

  • AWS Management Console
  • eksctl utility provided by AWS
  • IaC (Terrform, Ansible)

여기서는 AWS Management Console 를 이용한 방법을 사용할 것이다.

Prerequirement

AWS 를 사용하기 위해서는 권한이 있어야 한다. 다음과 같은 권한이 일단 필요하다.

  • AWS Account with Admin Privileges
  • AWS Cli Access to use Kubectl utility
  • Instance (To manage cluster by using Kubectl)

AWS 계정은 될수 있는한 관리자 권한이 필요하다.

Create IAM role for EKS Cluster

EKS Cluster 를 위한 IAM를 생성해야 한다. 이것은 IAM 서비스에서 역할(Role) 을 이용해서 생성한다.

각각의 허가권(Permission) 을 설정할 필요 없이 사용사례선택에서 EKS – Cluster 를 선택하고 Role 이름을 설정하면 끝나게 된다.

다음으로 일반 사용자가 이 Role 을 위임받을 수 있도록 신뢰관계를 맺어준다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::1111111111111111:user/systemv"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

systemv 사용자에 대해서 신뢰관계를 만들어 줬다.

Create Dedicated VPC for the EKS Cluster

VPC 를 생성해야 하는데, 하나하나 생성할 수도 있다. 하지만, EKS 를 위해서 AWS 는 CloudFormation 템플릿을 제공하고 있다. 이 정보는 다음의 링크를 통해서 확인할 수 있다.

위 내용을 보면 S3 에 CloudFormation 용 템플릿을 제공한다. 이를 이용하면 손쉽게 VPC 를 생성할 수 있는데 생성되는 리소스는 대략 다음과 같다.

  • 퍼블릭 서브넷 2개, 모든 서브넷에는 로드밸런서 할당을 위해 태그가 지정된다.
  • 엘라스틱 IP 할당.
  • 프라이빗 서브넷 2개, 모든 서브넷에는 내부 로드밸러서 할당을 위해 태그가 지정된다.
  • NAT 게이트웨이 1개
  • 모든 인바운드 트래픽을 차단하고 아웃바운드 트래픽을 허용하는 보안그룹.

AWS EKS 는 Master Node, Worker Node 로 구성되는데, Master Node 는 Managed 서비스이며 이것은 퍼블릭 서브넷이 필요하게 된다. Worker Node 는 EC2 인스턴스에 Docker 가 설치되며 EKS 에 의해서 제어된다. 이것은 프라이빗 서브넷이 필요하게 된다.

모든 인바운드 트래픽은 차단되고 아웃바운드 트래픽을 허용하기 위해서 NAT 게이트웨이가 설치가 된다.

CloudFormation 을 이용해 이런 제반사항들을 손쉽게 만들 수 있다.

AWS EKS 생성을 위한 CloudFormation 스택 이름 변수 정하기
AWS EKS 생성을 위한 CloudFormation 스택 이름 변수 정하기

스택이름만 쓰고 나머지는 그냥 기본적으로 제공하는 값을 사용해도 된다. 다음화면에서 태그나 기타 필요 옵션등을 선택할 수 있는데, 아무것도 안하고 넘어가도 된다.

CloudFormation 을 이용한 AWS EKS VPC 생성완료
CloudFormation 을 이용한 AWS EKS VPC 생성완료

생성된 자원들을 보면 어떤 것을 생성했고 어떻게 연결을 했는지도 눈에 보인다. SecurityGroup 은 ControllPlane 에 접근을 위해서 만들어졌다.

Login AWS Account for creating Cluster

앞에 CloudFormation 작업은 AWS Root 계정으로 진행 된다. 어짜피 네트워크 작업이며 이를 제어하기 위한 퍼미션만 사용자가 가지고 있어도 되기 때문이다. 하지만 서비스는 다르다. 서비스는 Role 기반으로 작동되는 경우가 많아 반드시 일반 계정으로 생성을 해야 한다.

만일 AWS Root 계정으로 EKS Cluster 를 생성할 경웨 피고한 경우가 생길 수 있다. 따라서 반드시 일반 계정으로 로그인을 해준다. 그 계정에 다음과 같은 정책을 생성해 준다.

system-eks-policy
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
31
32
33
34
35
36
37
38
39
40
41
42
43
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:CreateInstanceProfile",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:DescribeRegions",
                "autoscaling:DescribeLaunchConfigurations",
                "iam:CreateRole",
                "iam:AttachRolePolicy",
                "iam:AddRoleToInstanceProfile",
                "iam:PassRole",
                "autoscaling:DescribeScalingActivities",
                "ec2:CreateSecurityGroup",
                "ec2:RevokeSecurityGroupEgress",
                "autoscaling:DescribeAutoScalingGroups",
                "iam:ListAttachedRolePolicies",
                "autoscaling:UpdateAutoScalingGroup",
                "ec2:DescribeKeyPairs",
                "ec2:AuthorizeSecurityGroupEgress",
                "iam:GetRole",
                "ec2:CreateTags",
                "iam:ListRoles",
                "ssm:GetParameters",
                "ec2:DescribeSecurityGroups",
                "cloudformation:DescribeStacks",
                "ec2:RevokeSecurityGroupIngress",
                "ec2:DescribeImages",
                "autoscaling:CreateLaunchConfiguration",
                "iam:CreateServiceLinkedRole",
                "cloudformation:CreateStack",
                "ec2:DescribeVpcs",
                "ec2:DescribeSubnets",
                "eks:*",
                "autoscaling:CreateAutoScalingGroup"
            ],
            "Resource": "*"
        }
    ]
}

EKS Cluster 를 위한 권한이 대부분 다 들어 있다.

Create EKS Cluster

이제 네트워크 환경이 모두 구성됐으니 EKS Cluster 를 만들어야 한다. AWS 콘솔에서 EKS 를 검색해 서비스로 이동하면 된다.

AWS EKS Cluster 기본정보 입력
AWS EKS Cluster 기본정보 입력

Kubernetes 버전은 최신버전으로 했지만, 실제 서비스 운영은 기본값을 사용하길 권장한다. 클러스터 서비스 역할에는 맨처음에 만들었던 역할을 지정해 주면 된다.

AWS EKS Cluster 네트워킹 지정
AWS EKS Cluster 네트워킹 지정

네트워킹은 CloudFormation 으로 생성한 네트워크를 지정해 줘야 한다.

AWS EKS Cluster 클러스터 엔드포인트 액세스
AWS EKS Cluster 클러스터 엔드포인트 액세스

클러스터 엔드포이트 액세스는 퍼블릭 및 프라이빗으로 선택한다. 그리고 Amazon VPC CNI 는 최신버전으로 선택.

AWS EKS Cluster 클러스터 로깅
AWS EKS Cluster 클러스터 로깅

CloudWatch Logs 는 비활성화해서 넘어간다. 단, 실제 서비스를 운영할때는 활성화를 해준다. 적어도 Authenticator 정도는 해준다.

Install & Setup IAM Authenticator and Kubectl Utility

설치 aws-iam-authenticator 문서를 보고 authenticator 를 설치해 준다.

iam authenticator
ZSH
1
2
3
4
5
6
7
8
]$
$ curl -o aws-iam-authenticator https://amazon-eks.s3.us-west-2.amazonaws.com/1.18.9/2020-11-02/bin/linux/amd64/aws-iam-authenticator
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 33.6M  100 33.6M    0     0  2763k      0  0:00:12  0:00:12 --:--:-- 3229k
$ chmod +x ./aws-iam-authenticator
$ mv -vv aws-iam-authenticator ~/.local/bin/
renamed 'aws-iam-authenticator' -> '/home/sbhyun/.local/bin/aws-iam-authenticator'

AWS EKS 를 위한 kubectl 명령어를 다운로드 받는다.

AWS 를 위한 kubectl 다운로드
ZSH
1
2
3
4
5
6
7
8
9
10
]$
$ curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.19.6/2021-01-05/bin/linux/amd64/kubectl
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.4M  100 57.4M    0     0  3116k      0  0:00:18  0:00:18 --:--:-- 6107k
$ chmod +x kubectl
$ mv -vv kubectl ~/.local/bin/
renamed 'kubectl' -> '/home/sbhyun/.local/bin/kubectl'
$ kubectl version --short --client
Client Version: v1.19.6-eks-49a6c0

설치된 Client 버전과 AWS EKS 에서 버전이 같은지 확인한다.

이제 kubectl 명령어가 사용되는지를 확인해 본다.

AWS kubectl 사용확인
ZSH
1
2
3
]$
]$ kubectl get svc
The connection to the server localhost:8080 was refused - did you specify the right host or port?

접속을 위한 아무런 정보가 없기 에 localhost 에 접속을 시도했다.

AWS kubectl 접속정보
ZSH
1
2
3
]$
]$ aws eks --region ap-northeast-2 update-kubeconfig --name eks-cluster
Added new context arn:aws:eks:ap-northeast-2:1111111111111:cluster/eks-cluster to /home/systemv/.kube/config

접속을 위한 정보를 받아서 $HOME 에 .kube/config 에 저장이 된다. 이제 잘되는지 다음과 같이 확인해 보자.

kubectl 로 AWS Cluster 확인
ZSH
1
2
3
]$  kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.100.0.1   <none>        443/TCP   6m49s

위와같이 나오면 정상이다. 만일 위와같이 나오지 않는다면 Role 를 지정해줄 수도 있다.

kube 설정파일을 Role 지정 업데이트
ZSH
1
aws eks --region ap-northeast-2 update-kubeconfig --name eks-cluster --role-arn arn:aws:iam::11111111111111:role/systemv-ekscluster-role

이렇게 했는데도 안된다면 다음의 링크가 도움이 될지 모른다.

정상적으로 작동한다면 다음과 같이 Node 는 아무것도 안나올 것이고 Namespace 는 나올 것이다.

kubectl get nodes,ns
ZSH
1
2
3
4
5
6
7
8
$ kubectl get nodes
No resources found
$ kubectl get ns
NAME              STATUS   AGE
default           Active   20m
kube-node-lease   Active   20m
kube-public       Active   20m
kube-system       Active   20m

Create IAM Role for EKS Worker Nodes

EKS Cluster 는 Kubernetes 에서는 Master 작업이 끝난것이라고 보면 된다. 아직은 Work Node 가 없다. Work Node 는 NodeGroup 으로 묶여서 생성되고 Work Node 를 위한 Role 이 필요하다.

AWS Role for EKS WorkNodes
AWS Role for EKS WorkNodes

이와 더블어서 ssm.amazonaws.com, eks.amazonaws.com 을 신뢰관계에 추가 해준다.

많은게 필요가 없다. 이제 worknode 를 위한 group 를 생성해 보자.

AWS EKS WorkGroup 생성하기 - 기본정보 입력
AWS EKS WorkGroup 생성하기 – 기본정보 입력

이름과 역할을 지정해준다. 역할은 앞에서 생성한 역할이 자동으로 나올 것이다.

AWS EKS Workgroups 생성하기 - 컴퓨터 자원 생성
AWS EKS Workgroups 생성하기 – 컴퓨터 자원 생성

서비스 운영을 위한 시스템 자원을 선택해 준다. 이 시스템 작원은 물리적인 하드웨어를 선택하는 것이다. 이 자원 위에서 Docker 를 기반으로 Micro Service 가 돌아가게 된다.

AWS EKS Workgroups 설치하기 - 네트워크 설정
AWS EKS Workgroups 설치하기 – 네트워크 설정

서브넷은 AWS EKS 를 위한 서브넷을 선택되어 있어야 한다. 노드에 대한 액세스가 필요할 경우에 해주면 되고 보안 그룹은 기본보안 그룹(22 port 만 열려 있다)을 선택해 줬다. 서비스를 운영할때에는 적절하게 바꿔준다.

생성이 완료되면 다음과 같이 Node 가 나오게 된다.

kubectl get nodes
ZSH
1
2
3
4
$ kubectl get nodes
NAME                                                 STATUS   ROLES    AGE     VERSION
ip-192-168-187-113.ap-northeast-2.compute.internal   Ready    <none>   7m51s   v1.19.6-eks-49a6c0
ip-192-168-246-188.ap-northeast-2.compute.internal   Ready    <none>   8m      v1.19.6-eks-49a6c0

이것이 Kubernetes 에서 Master, Work node 작업이 완료된것과 같은 AWS EKS Cluster 가 세팅이 완료가 된 것이다.

이 글은 초기버전이다. 큰 틀에서 대충 이렇게 한다는 것을 보여주는 것 외에는 깊이가 없다.

Nginx 액세스 로그를 CloudWatch Logs Agent 로 보내기

이 글은 다음의 글을 번역한 것입니다. 저작권은 원작자에게 있습니다.

최근에 나는 Ubuntu 18.04 에서 CloudWatch Logs 를 어떻게 설정하는지에 대한 글을 썼다. 그 글에서 나는 Agent 가 */var/log/syslog* 를 CloudWatch Logs로 syslog log 파일을 푸쉬하도록 설정했다. 이전 글을 보고 여기로 오길 바라고 혹시나 여러분이 Ubuntu 를 사용하지 않는다면 여러분이 사용하는 OS 에 CloudWatch Logs Agent 를 설치하기 위해서 AWS 문서를 체크해야 한다.

여기서 나는 Nginx 의 액세스 로그(access log) 와 에러 로그(Error log) 를 AWS CloudWatch Logs Agent 를 통해서 CloudWatch Logs 로 어떻게 전송하는지를 보여줄 것이다.

우리는 에이전트가 소비하기 원하는 두개의 Nginx 로그 파일을 가진다고 가정하자: */var/log/nginx/access.log* 와 */var/log/nginx/error.log* 로 원하는 만큼 많은 Nginx 로그를 추가할 수 있다.

AWS CloudWatch Logs Agent 는 *amazon-cloudwatch-agent.json* 파일로부터 설정들을 가지고 오고 이것은 Ubuntu 에서 */opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json* 위치해 있다.

이미 파일이 그곳에 있을거라 생각하고 collect_list 배열 아래쪽에 다음을 추가하면 된다.

AWS CloudWatch Logs Agent 설정
1
2
3
4
5
6
7
8
9
10
11
12
{
  "file_path": "/var/log/nginx/access.log",
  "log_group_name": "web-server-log-group",
  "log_stream_name": "{hostname}/access.log",
  "timestamp_format" :"[%d/%b/%Y:%H:%M:%S %z]"
},
{
  "file_path": "/var/log/nginx/error.log",
  "log_group_name": "web-server-log-group",
  "log_stream_name": "{hostname}/error.log",
  "timestamp_format" :"[%d/%b/%Y:%H:%M:%S %z]"
}

여기서 핵심은 Nginx 로그 파일에서 timestamp_format 과 일치하는 포맷을 찾는다는 것이고, 만약 Ubuntu 에서 Nginx 에 기본 로깅 설정을 사용중이라면 위 설정은 잘 맞는다.

또 log_group_name 이 CloudWatch Logs Agent 의 자격증명에 로그 스트림 생성을 위한 logs:CreateLogSteam, 로그 스트림 기술을 위한 logs:DescribeLogStream 그리고 로그 이벤트를 푸쉬하기 위한 logs:PutLogEvents 의 IAM 허가권을 가지는 로그 그룹과 일치하는지 확인해봐야 한다.

amazon-cloudwatch-agent.json 파일을 업로드 한 후에 agent 서비스를 재시작해줄 필요가 있다:

AWS CloudWatch Logs Agent 재시작
Shell
1
service amazon-cloudwatch-agent restart

곧바로 CloudWatch Logs 에서 Nginx 로그들이 표시된다.

Ubuntu 18.04 LTS 에 CloudWatch Logs Agent 설정하기

이 글은 다음의 글을 번역한 것입니다. 저작권은 원작자에게 있습니다.

AWS CloudWatch Logs Agent 는 서버로부터 AWS CloudWatch Logs 서버로 로그를 전송하기 위해 설정될 수 있다. 이 문서에서, 나는 어떻게 Ubuntu 18.04 LTS 에 어떻게 설정하는지 보여줄 것이지만 여러분은 Ubuntu16.04 혹은 다른 운영체제 에서도 유사한 절차를 따를 수 있다. CloudWatch Logs Agent 는 Windows Servers 에서 EventViewer 로그를 수집하기 위해 설정할 수도 있다.

아주 좋은것은 여러분이 AWS EC2 를 실행하지 않는다고 하더라도, Azure, Google Cloud, Linode, Digistal Ocean 등과 같이 어떤 서버든지 이 기술을 사용할 수 있다는 점이다. 이 문서는 여러분이 따라하기에 쉬운 간단한 샘플이다.

여러분은 이러한 절차를 설정관리 스크립트로 손쉽게 만들거나 자신만의 Docker 이미지 사용을 위해 Dockerfile에 추가할 수 있어야 한다.

Download / Install the Debian Package

AWS 는 그들의 문서에 CloudWatch Logs Agent 데미안 패키지 위치를 기술하고 있고 우리는 curl 을 이용해 다운로드하고 실행하면 된다.

amazon-cloudwatch-agent 다운로드 및 설치
ZSH
1
2
3
4
#download it
curl -o /root/amazon-cloudwatch-agent.deb https://s3.amazonaws.com/amazoncloudwatch-agent/debian/amd64/latest/amazon-cloudwatch-agent.deb
#install it
dpkg -i -E /root/amazon-cloudwatch-agent.deb

이 문서의 모든 명령어는 sudo 를 사용허거나 root 사용자로 실행하는 것으로 한다.

Add cwagent User to adm group

다음으로 우리는 설치 프로그램이 생성한 cwagent 리눅스 사용자 계정을 Ubuntu 시스템 로그들에 읽기 허가권을 주기 위해서 adm 그룹에 추가하는 수정작업을 할 것이다.

amazon-cloudwatch-agent를 위한 계정 생성
ZSH
1
usermod -aG adm cwagent

Setup an IAM User Account and Permissions

이제 우리는 여러분의 AWS 계정에 CloudWatch Logs 에 로그 데이터를 전송하기 위해 Ubuntu 서버에 허가권을 부여할 필요가 있다.

만약 AWS EC2 운영하고 있다면, 이 과정을 건너뛰고 Assumed Role 를 사용해라. 하지만 IAM 허가권을 가진 Assumed Role 이 있는지 확인할 필요가 있다.

AWS Console 에서 IAM 사용자를 생성하고 AWS accessID 와 AWS secretKey 를 기록하고 여러분의 Ubuntu 서버에서 다음과 같이 /home/cwagent/.aws/credentials 파일을 생성하십시오.

Amazon 서비스 접속키 설정
INI
1
2
3
[AmazonCloudWatchAgent]
aws_access_key_id = aaaaaaaa
aws_secret_access_key = bbbbbbbb

또, 다음과 같이 /home/cwagent/.aws/config 파일을 생성하십시오

Amazon 서비스 접속 설정
INI
1
2
3
[AmazonCloudWatchAgent]
output = text
region = us-east-1

AWS console 에서 만든 새로운 IAM user 의 aws_access_key_id 와 aws_secret_access_key 를 사용해야 해야하며 region 또한 정확하게 지정해야 한다. 다음과 같이 /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml 에 추가함으로써 인증을 위해 CloudWatch Logs Agent 가 여기를 바라보도록 한다.

amazon-cloudwatch-agent 설정
ZSH
1
2
echo "[credentials]" >> /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml
echo '    shared_credential_file = "/home/cwagent/.aws/credentials"' >> /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml

Create a Log Group

어떻게 로그들을 구성하길 원하는지에 대해서 잠깐 동안 생각해봐야 한다. CloudWatch Logs 는 Log Groups 과 Logs Streams 개념을 제공한다. 로그 그룹을 로그별로 다이나믹하게 생성하거나 하나의 로그 그룹에 모든 서버 로그들을 사용할지와 같은 것이다. 이 문서에서 우리는 hostname.example.com/syslog 와 같은 로그 스트림을 생성하는 여러 서버에 대한 로그를 가질 수있는 하나의 로그 그룹을(web-server-log-group) 생성할 것이다.

나는 단일 로그 그룹에 스트림을 생성하고 로그를 출판하기 위한 접근만 제공하기 위해 IAM 허가권을 제한할 수 있기 때문에 이러한 접근방법을 선호한다.

Grant the IAM User / Role Permission to Publish Logs

web-server-log-group 으로 명명된 로그 그룹을 가지고 있다고 가정하고 이전 절차에서 생성한 IAM user에 IAM 정책(Policy) 를 붙일 것이다. 만약 EC2 를 운영중이라면 Assumed Role 에 이 정책을 붙일 수 있다.

IAM Role 설정
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudWatchLogAgentPutForWebServerLogGroup",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:DescribeLogStreams",
        "logs:PutLogEvents"
      ],
      "Resource": [
        "arn:aws:logs:us-east-1:1234567890:log-group:web-server-log-group",
        "arn:aws:logs:us-east-1:1234567890:log-group:web-server-log-group:*:*"
      ]
    }
  ]
}

주의해야 할 것은 숫자 1234567890 는 여러분의 AWS account id 로 바꿔야 한다. 만약 CPU, Memory, Network, Disk 와 같은 서버 메트릭 데이터를 CloudWatch Logs Agents 가 출판하길 원한다면 다음과 같이 cloudwatch:PutMetricData 허용을 위해 추가적인 정책을 붙일 필요가 있다.

서버 매트릭 출판을 위한 IAM Role 설정
1
2
3
4
5
6
7
8
9
10
11
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudWatchPutMetricData",
      "Effect": "Allow",
      "Action": "cloudwatch:PutMetricData",
      "Resource": "*"
    }
  ]
}

나도 리소스(Resource)에 대해 와이들카드(*) 를 사용하는 대신에 좀더 제한적일 수 있는지 좀 더 찾아봐야 한다.

또, AWS 는 여러분이 사용할 수 있도록 CloudWatchAgentServerPolicy 으로 명명된 이미 만들어진 정책을 제공한다. 하지만 개인적으로 이건 조금 과도한 허가권이라 생각한다. 이것은 Agent 가 새로은 로그 그룹과 모든 로그 그룹에 로그를 출판하도록 서버에 허가한다.

Telling CloudWatch Logs Agent Which Log Files to Collect

AWS CloudWatch Logs Agent 는 위자드(Wizard) 를 통해서 json 설정 파일 생성을 위해 실행할 수 있는 툴을 가지고 있다:

Wizard를 이용한 설정
ZSH
1
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

아니면 이 위치에: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json 수동으로 JSON 파일을 생성할 수 있는데 다음과 같다.

amazon-cloudwatch-agent 설정
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "agent": {
    "metrics_collection_interval": 60,
    "run_as_user": "cwagent",
    "credentials_path":"/home/cwagent/.aws/credentials"
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/syslog",
            "log_group_name": "foundeo-web",
            "log_stream_name": "{hostname}/syslog",
            "timestamp_format" :"%b %d %H:%M:%S"
          }
        ]
      }
    }
  }
}

이것은 Ubuntu 서버의 /var/log/syslog 의 내용을 AWS CloudWatch Logs 서비스로 출판 한다. 여기에 nginx 로그를 CloudWatch Logs로 전송하는 예제가 있다.

Enable and Start the CloudWatch Logs Agent service

마지만 단계로 AWS CloudWatch Logs Ubuntu 서비스를 활성화 해주고 서비스를 시작해준다. 이것은 다음의 두개 명령어로 실행할 수 있다.

amazon-cloudwatch-agent 서비스 시작
ZSH
1
2
systemctl enable amazon-cloudwatch-agent.service
service amazon-cloudwatch-agent start

AWS CDK 개발 환경 구축하기

이 문서는 AWS CDK 개발 환경 구축에 대한 글이다. AWS CDK 는 코드로 AWS 자원을 관리하게 해주는 것으로 Infrastructure As Code 에 부합한다. 이를 사용하기 위해서는 환경 구축이 필수이기에 이를 기록한다.

구축 환경

AWS CDK 는 몇가지 언어를 지원 한다. 나는 Python 을 사용할 것임으로 Python 관련된 설정도 필수다. 그런데, Python 을 사용해보면 알겠지만 Windows 플랫폼 보다는 Unix 스타일의 플랫폼이 적합하다는 것을 알게 된다. 따라서 구축 환경은 다음과 같이 정했다.

  • OS: Mint Linux 19.3 Tricia XFCE
  • Python3

한가지 더 있다. Python3 을 사용할 경우에 AWS SDK 등을 모두 설치해야 한다. 하지만 Python 은 캡슐화를 지원한다. Virtualenv 가 바로 그것인데, 모든 것을 Virtualenv 환경으로 구축을 할 예정이다.

PreRequirement

이제 본격적으로 구축을 해보자. 이를 위해서 필수 프로그램이 필요한데, 이는 다음과 같다.

  • npm (Node)

이는 다음의 URL 을 명시되어 있다.

Node, npm 설치

npm 을 기반으로 한다고 문서에 나와 있다. 따라서 npm 을 설치해 줘야 한다. npm 은 Node.js 기반이며 Node.js 를 설치하는 방법은 다양하지만 이전에 이에 대해서 기술한 문서가 이미 있기에 다음을 참고 했다.

주의할 것은 AWS 의 문서에 나와 있다시피 LTS 버전을 설치해줘야 한다. AWS 문서에 나와 있듯이 CDK 를 설치해 준다.

AWS-CDK 설치 
ZSH
1
2
3
4
5
]$ npm install -g aws-cdk
/home/systemv/.nvm/versions/node/v12.15.0/bin/cdk -> /home/systemv/.nvm/versions/node/v12.15.0/lib/node_modules/aws-cdk/bin/cdk
+ aws-cdk@1.23.0
added 234 packages from 227 contributors in 11.018s
]$ cdk --version

Python3 환경 구축

Python3 에도 필요한 것이 있는데, distutils 패키지 이다. 이것은 우분투 패키지로 설치를 해줘야 한다. 다음과 같이 설치를 해준다.

Python3 의존성 라이브러리 설치
ZSH
1
]# apt install python3-distutils

이것을 설치해야지만 python3 을 로컬 계정에서 환경을 구축할 수 있다. 다음과 같이 pip 를 설치해 준다.

Python3 캡슐환경 설치
ZSH
1
2
3
]$ wget https://bootstrap.pypa.io/get-pip.py
]$ python3 get-pip.py --user
]$ .local/bin/pip3 install virtualenv

virtualenv 를 설치하고 난 후에 이제 캡슐환경을 만들어준다. 그냥 .python3 으로 만들어준다.

Python3 캡슐환경 활성화
ZSH
1
2
3
4
5
6
7
8
9
]$ virtualenv .python3
]$ .local/bin/virtualenv .python3
Using base prefix '/usr'
New python executable in /home/systemv/.python3/bin/python3
Also creating executable in /home/systemv/.python3/bin/python
Installing setuptools, pip, wheel...
done.
]$ source .python3/bin/activate
(.python3) $

여기서 이제 AWS CLI 와 기타 몇가지를 함께 설치해준다. 이는 Python3 에 패키지로 존재함으로 pip 명령어를 이용해서 설치하면 된다.

Python3 캡슐환경에 aws-sam-cli 설치
ZSH
1
(.python3) $ pip install awscli aws-toolkit aws-sam-cli

이로써 필수 프로그램 설치는 다 됐다.

VS Code 설정

이제 Editor 설정을 해야 한다. VS Code 라면 AWS CDK 를 사용하는데 부족함이 없다. 데스크탑 리눅스를 사용함으로 VS Code 에서 우분투 패키지를 다운로드해 설치하면 된다.

Color Themes

좋은 Color Themes 가독성을 높여줘 프로그래밍을 하는데 많은 도움이 된다. 내가 주로 사용하는 Color Themes 는 다음과 같다.

  • Ayu
  • Primal

물론, 이건 지극히 개인적인 것임으로 검색을 통해서 자신에게 맞는 Color Themes 를 찾으면 된다.

Python Extension 설정

VS Code 가 Python 을 지원하도록 해야 한다. 이를 위해서 Python Extension 을 설치하고 다음과 같이 설정을 해준다. 그리고 다음과 같이 pip 를 이용해서 프로그램을 설치해준다.

Python3 캡슐환경에 의존성 라이브러리 설치
ZSH
1
(.python3) $ pip install pycodestyle pydocstyle pylint pytest autopep8 black cfn-lint

AWS Toolkit for Visual Studio Code

AWS Tookit Extension 을 설치해 준다. 별도의 설정은 해주지 않아도 된다.

Indenticator, indent-rainbow

Python, Yaml 문법의 특성상 Indent 를 기반으로 문법 체크를 하는데 이 Extension이 도움이 된다.

Sort lines

라인을 알파벳 순, 숫자순으로 정렬을 해준다.

vscode-cfn-lint

cfn 는 CloudFormation 을 말한다. CloudFormation 문법을 체크해 준다.

YAML Support by Red Hat

CloudFormation 은 YAML 문법을 따른다. 이 문법을 체크해 준다.

Cloudformation YAML snippets for VS Code

코딩을 할때에 필요한 코드 조작을 넣어준다.

Better Comments

주석에 색깔을 입혀서 가독성을 높여준다.

이렇게 설치한 Extension 에 대한 설정값은 다음과 같다.

VSCode Extension 설정
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
{
    "workbench.colorTheme": "Ayu Mirage",
    "workbench.iconTheme": "material-icon-theme",
    "python.venvPath": "~/.python3",
    "python.testing.pytestEnabled": true,
    "python.venvFolders": [
        ".python3"
    ],
    "python.pythonPath": "~/.python3/bin/python3",
    "python.autoComplete.extraPaths": [
        "~/.python3/lib/python3.6",
        "~/.python3/lib/python3.6/site-packages"
    ],
    "python.formatting.provider": "black",
    "python.formatting.blackArgs": [
        "--line-length",
        "100"
    ],
    "editor.formatOnSave": true,
    "python.linting.pylintEnabled": true,
    "python.linting.lintOnSave": true,
    "python.linting.enabled": true,
    "indenticator.inner.showHighlight": true,
    "indentRainbow.includedLanguages": [],
    "indentRainbow.excludedLanguages": [
        "plaintext"
    ],
    "indentRainbow.updateDelay": 100,
    "cfnLint.path": "~/.python3/bin/cfn-lint",
    "yaml.validate": false,
    "yaml.customTags": [
        "!And",
        "!And sequence",
        "!If",
        "!If sequence",
        "!Not",
        "!Not sequence",
        "!Equals",
        "!Equals sequence",
        "!Or",
        "!Or sequence",
        "!FindInMap",
        "!FindInMap sequence",
        "!Base64",
        "!Join",
        "!Join sequence",
        "!Cidr",
        "!Ref",
        "!Sub",
        "!Sub sequence",
        "!GetAtt",
        "!GetAZs",
        "!ImportValue",
        "!ImportValue sequence",
        "!Select",
        "!Select sequence",
        "!Split",
        "!Split sequence"
    ]
}

AWS Credential 세팅

Python3 에 가상환경에서 aws configure 명령어를 이용해서 접속을 위한 credential 을 만들어준다.

AWS 접속 설정
ZSH
1
2
3
4
5
(.python3) ]$ aws configure --profile
AWS Access Key ID [None]: *********************
AWS Secret Access Key [None]: ******************************
Default region name [None]: ap-northeast-2
Default output format [None]:

이로써 AWS CDK 를 위한 VS Code 설정을 기술했다. 정답은 없다. 개인적으로 사용하는 설정을 기반으로 보다 좋은 방법, 환경을 위한 설정이 있을 것이다.

Ansible, ec2.py 를 이용한 Dynamic Inventory 활용

Ansible 에는 접속 정보와 관련된 정보들을 Inventory 라고 부른다. 접속 호스트, 접속 계정 정보뿐만 아니라 이들을 그룹으로 묶거나 변수 설정도 가능하다.

그런데, 클라우드 시스템과 같이 서버 관련 정보를 API 형식으로 제공할 경우에 일일이 호스트 정보를 파일로 저장할 필요가 없다. 클라우드 시스템에 서버 관련 정보를 호출하며 자동으로 Inventory 정보가 생성되는 기능을 제공하는데 이를 Dynamic Inventory 라고 한다. 이 기능은 클라우드 뿐만 아니라 LDAP 과 같은 인증 시스템에도 활용가능하다.

Ansible 세팅

AWS 클라우드의 Dynamic Inventory를 활용하기 위한 Ansible 을 세팅해 보자. 가장 중요한 ansible.cfg 는 다음과 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
[defaults]
inventory      = ~/.ansible/inventories/production/ec2.py
library        = ~/.ansible/library
module_utils   = ~/.ansible/module_utils
roles_path     = ~/.ansible/roles
#remote_tmp     = ~/.ansible/tmp
local_tmp      = ~/.ansible/tmp
#plugin_filters_cfg = /etc/ansible/plugin_filters.yml
#forks          = 5
#poll_interval  = 15
remote_user    = ec2-user
sudo_user      = root
#ask_sudo_pass = True
#ask_pass      = True
transport      = smart
remote_port    = 22
 
host_key_checking = False
 
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False

특별히 inventory 에는 AWS 클라우드에 제공하는 Dynamic Inventory 스크립트 위치를 지정해준다. ansible 을 이용한 접속 정보, 실행할 계정에 대한 정보등을 기재한다.

디렉토리는 구조는 대략 다음과 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ tree
├── ansible.cfg
├── filter_plugins
├── inventories
│   └── production
│       ├── ec2.ini
│       ├── ec2.py
│       ├── group_vars
│       │   └── tag_Service_jmeter_server.yml
│       ├── hosts
│       └── keypairs
│           └── test-server.pem
├── library
├── module_utils
├── roles
└── tmp

AWS 클라우드 Dynamic Inventory 파일

AWS 클라우드의 경우에도 Ansible 의 Dinamic Inventory 기능을 제공한다. 작동원리는 AWS 자원 정보를 불러오고 이것을 Ansible 이 인식하는 Inventory 정보를 구성하는 것이다. AWS 자원 정보를 불러오기 위해서 AWS 는 다음과 같은 스크립트와 환경설정 정보를 제공한다.

ec2.py 는 AWS 클라우드 시스템에 호스트 관련 정보를 불러오도록 한다. ec2.ini 는 어디, 어떤 정보를 불러올 건지 어떤 내용을 출력할 것인지를 지정할 수가 있다. 예를들면 다음과 같다.

1
2
3
4
5
regions = ap-northeast-2
vpc_destination_variable = private_ip_address
route53 = False
rds = False
elasticache = False

regions 이 기본값은 all 이다. 이러면 모든 리전에 대해서 호스트 정보를 수집할려고 하기 때문에 시간이 오래걸리는 문제가 발생한다. 특정한 리전에 대해서만 수행하도록 지정하는 것이 좋다.

IAM 설정

가장 중요한것이 IAM 설정이다. Ansible 을 실행하는 서버에는 호스트 정보를 불러올수 있는 IAM 권한이 필요하다. 보통 IAM Role 지정이라고 하는데 대략 다음과 같은 Policy 를 만들어 Role 적용을 하면 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*",
                "elasticache:Describe*",
                "rds:Describe*",
                "route53:ListHostedZones",
                "route53:ListResourceRecordSets"
            ],
            "Resource": "*"
        }
    ]
}

Access Key, Secret key 를 이용하는 방법도 있지만 권장하지 않는다.

ec2.py 테스트 및 특징

이제 요건이 갖춰졌으니 테스트를 해보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
$ ec2.py --list
  "tag_Name_com_jenkins_master": [
    "10.18.198.155"
  ],
  "tag_Name_com_linux": [
    "10.18.198.172"
  ],
  "tag_Name_com_nat1": [
    "10.18.198.205"
  ],
  "tag_Name_com_nat2": [
    "10.18.198.209"
  ],

내용을 보면 위와같은 key 값들을 보게 된다. 집작했겠지만 ec2.py 는 ec2 인스턴스의 tag 를 key 로 지정해준다. tag 뿐만 아니라 ec2 인스턴스의 정보를 key 만들어준다.

이 key들은 Ansible Inventory 의 group 변수로 활용이 가능하다.

ec2 key pair 를 이용한 접속 정보 만들기

ec2.py 에서 key 들은 곧바로 Ansible 의 group 으로 활용 가능하다. 이를 위해서 inventory/production/group_vars 디렉토리에 key 이름으로 yaml 파일을 생성한다. 그리고 다음과 같이 내용을 입력한다.

1
ansible_ssh_private_key_file: ~/.ansible/inventories/production/keypairs/test-server.pem

Ansible이 그룹 접속을 할때에 위 변수를 활용하게 된다. AWS 클라우드 ec2 접속하기 위한 keypair 를 이용하는데 따른 설정이다.

접속 테스트

이제 다 됐다. 다음과 같이 접속 테스트를 한번 해본다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ ansible tag_Service_jmeter_server -m ping
[DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on
deprecation. This feature will be removed in version 2.10. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
[WARNING]: Invalid characters were found in group names but not replaced, use -vvvv to see details
 
[WARNING]: Platform linux on host 10.18.193.62 is using the discovered Python interpreter at /usr/bin/python, but future installation of another Python interpreter could change
this. See https://docs.ansible.com/ansible/2.8/reference_appendices/interpreter_discovery.html for more information.
 
10.18.193.62 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}

위와같이 나오면 성공한 것이다.

AMAZON S3 버킷 램덤화 객체 접두사 불 필요.

과거에 AMAZON S3 버킷 성능 끌어올리기 라는 글을 통해서 S3를 사용하는데 있어서 성능향상 방법에 대해서 설명한 적이 있다. 핵심은 객체 접두사를 램덤화해서 S3에 올라가는 파일들이 균일하게 넓게 퍼질 수 있도록 해야한다는 것이였다.

하지만 2018년 7월 17일에 AWS 에서는 S3에 성능향상을 언급하면서 이제 객체 접두사의 랜덤화는 불필요하다고 말했다.

Amazon S3, 요청 처리 성능 개선 발표

이 같은 S3 요청 처리 성능 향상으로 인해 객체 접두사를 랜덤화하여 더 빠른 성능을 실현하라는 이전의 지침은 더 이상 적용되지 않습니다. 즉, 이제 성능 저하 없이 S3 객체에 논리적 또는 순차적 명명 패턴을 사용할 수 있습니다. 이 성능 향상은 이제 모든 AWS 리전에서 제공됩니다. 자세한 내용은 Amazon S3 개발자 가이드를 참조하십시오.

이제 S3 버킷에서 객체를 저장할때 접두사를 램덤화하려는 고민을 하지 않아도 된다.