kakasoo

[SAA-C03] 7. EC2 기초 및 유형 별 기본 사항

카카수(kakasoo) — Sun, 7 Apr 2024 20:05:34 +0900

EC2란?

EC2는 AWS에서 제공되는 가장 인기있는 서비스로, 하나의 서비스가 아니라 고수준에서 여러 서비스들을 포괄하는 단어이기도 하다.

가상 머신을 임대하는 것 외에도 데이터를 가상 드라이브 또는 EBS에 저장하거나, ELB로 부하를 분산, 오토 스케일링 그룹으로 서비스를 확장하는 것 모두가 EC2 서비스에 포함된다.

EC2에서 가상머신을 임대할 때 선택사항

OS ( Linux, Windows, Mac OS )를 선택해야 하며, 나는 Amazon Linux 2를 사용한다.
컴퓨터 성능, 코어 수 ( = 프리티어로 t2.micro를 사용하기 때문에 코어는 1개 )
램 (RAM, Random Access Memory) 의 크기를 선택해야 하며, 마찬가지로 프리티어에서는 1GiB이다.
스토리지의 크기 ( ex. EBS, EFS )
네트워크 카드를 선택하여 어떤 종류의 공용 IP가 지정되길 원하는지, 네트워크 속도는 어느 정도로 빠를지를 선택할 수 있다.
보안 그룹을 설정하여 접근 가능한 IP와 포트를 명시할 수 있다.
인스턴스를 구성하기 위한 부트스트랩 스크립트 ( = User Data, Configure at first launch ) 를 작성할 수 있다.

EC2의 종류

인스턴스 유형	vCpu	메모리(GiB)	스토리지	네트워크 성능	EBS 대역폭 (Mbps)
t2.micro	1	1	EBS만	낮음	-
t2.xlarge	4	16	EBS만	중간	-
c5d.4xlarge	16	32	1 x 400 NVMe SSD	최대 10 Gbps	4,750
r5.16xlarge	64	512	EBS만	최대 20 Gbps	13,600
m5.8xlarge	32	128	EBS만	최대 10 Gbps	6,800

인스턴스의 수는 굉장히 많고, 대략적인 설명을 위해 5가지만 옮겨보았다.

이를 외울 필요는 전혀 없지만, 이름이 어떤 식으로 생성되는지 정도는 알면 좋다.

이름의 명명 규칙은 인스턴스 클래스와 세대, 그리고 인스턴스의 크기 순으로 작성되며, 세대는 높을수록 나중에 만들어진 최신 버전이다.

인스턴스의 크기는, 2의 배수로 컴퓨터 자원이 증가하는데, small, large, 2xlarge, 4xlarge 등이 존재한다.

인스턴스 클래스는 인스턴스의 유형이라고 하는데, 목적에 따라 인스턴스를 7가지 정도 분류한 것을 의미한다.

EC2 인스턴스 유형 기본사항

T: General Purpose
C: Compute Optimized
R: Memory Optimized
Accelerated Computing
S: Storage Optimized
Instance Features
Measuring Instance Performance

T : 범용 인스턴스로 컴퓨팅 성능, 메모리, 네트워크 성능 등 균형이 잘 맞아 범용 인스턴스라고 한다.

C : 컴퓨팅 최적화로 고성능이 요구되는 일부 데이터 일괄 처리, 미디어 처리, 게임 서버 등에 사용한다.

R : 메모리 최적화로, 여기서 말하는 RAM이 매우 커서 캐시 용도로 활용하기 위해 인스턴스를 생성한다. ( 간혹 X,Z도 존재 )

S : 스토리지 최적화로, 로컬 스토리지에서 대규모 데이터셋에 접근할 때나 사용한다. 메모리가 아닌, 데이터 웨어 하우징 용도로 쓴다.

EC2 생성 이후 주요 속성

name
instance ID
Public IPv4 ( 공용 IP ) 로 AWS 외부에서 접근할 때 사용하는 아이피 주소, 인스턴스를 재시작 시 바뀌기 때문에 주의해야 한다.
Private IPv4 ( 사설 IP ) 로, 공용 IP로 접근 시 AWS 내부에서 가리키는 주소
key-pair name, 만약 SSH 접속을 위한 키 페어를 생성했을 경우 해당 키 페어의 이름을 의미한다.

[SAA-C03] 6. AWS 예산 (Budge) 확인하기

카카수(kakasoo) — Sun, 7 Apr 2024 19:41:34 +0900

결제 및 비용 관리 탭

예산 확인은 AWS 콘솔에서 우측 위 자신의 프로필을 누르고, [결제 및 비용관리] 탭을 누르면 확인할 수 있다.

[과금 정보 및 비용 관리 홈]에서는 자기가 이번 달에 사용한 금액을 AWS 서비스 ( = 리소스 ) 별로 확인해볼 수 있다.

예시로 보여준 이미지는 IAM 사용자로 로그인하였기 때문에 권한이 없어 아무것도 나오지 않는데, 이럴 경우 Root에서 권한을 줘야 한다.

IAM User가 예산을 확인할 수 있게 권한 주기

이번에는 Root 계정으로 로그인하여, 계정 프로필 탭에서 [계정]을 누른다. ( 예시 이미지에서는 여전히 IAM이지만 루트로 해야 한다 )

계정 탭에 들어가서 스크롤을 하면 아래에 [결제 정보에 대한 IAM 사용자 및 역할 액세스] 라는 섹션이 존재한다.

이 색션에서 편집을 누르고,

IAM 액세스 활성화를 누른 다음에 [업데이트] 를 누르면 IAM 사용자도 예산을 확인할 수 있게 된다.

꼭 IAM 사용자가 예산을 볼 수 있어야 하는 것은 아니고, 규정이 만약 Root 계정만 비용을 관리할 수 있게 하고자 한다면 줄 필요는 없다.

비용 확인하기

액세스가 허용되어 있다면 [과금 정보 및 비용 관리 홈]에서는 비용과 청구서 보기 버튼이 활성화되어 나타나 있을 것이다.

[청구서 보기] 버튼을 누르고 서비스 별 요금에서, 어떤 서비스에 어느 정도 요금을 썼는지 확인해볼 수 있다.

여담, 더 알아두면 좋은 내용

프리티어의 요금만 따로 관리할 수 있는 탭이 있다.

사용량을 초과하지 않도록 모니터링할 때 사용하기 좋다.

예산 탭에서는 예산이 초과되었을 때 이메일로 알림을 주게 설정할 수 있다.

일반적으로는 프리티어를 사용할 때 제로 지출 예산으로, 지출이 발생했을 때 알림을 주게 하는 예산 설정,

그리고 자신이 모니터링하기 원하는 금액 대를 설정할 수 있게 월별 비용 예산 탭이 있다.

월별 비용 예산을 설정할 경우, 해당 예산의 85%에 도달하거나 100% 도달하는 시점에 각각 메일을 보내 알림을 준다.

[SAA-C03] 5. 자격증명 보고서와 액세스 관리자

카카수(kakasoo) — Sat, 6 Apr 2024 19:17:23 +0900

자격 증명 보고서 ( = IAM Credentials Report )

제목의 둘은 IAM 보안 도구로 묶이는 도구들인데, 도구라고 해서 거창한 것은 아니고 권한을 체크하는 버튼 두 개일 뿐이다.

IAM 자격 증명 보고서 ( = IAM Credentials Report )는 계정 레벨에서 사용이 가능하며, 모든 사용자의 정보를 볼 수 있다.

보고서는 계정에 있는 사용자와 다양한 자격 증명의 상태를 포함하고 있는데, 여기에는 MFA 인증 여부 따위의 정보가 나온다.

이는 보안 관리자에게 어떤 사용자에게 주목해야 하는지 정보를 제공해준다.

IAM 대시보드 좌측 사이드에서 자격 증명 보고서를 누르고, 보안 인증 보고서 다운로드 버튼을 누르면 CSV 형태로 볼 수 있다.

액세스 관리자 ( = IAM Access Advisor )

두번째 보안도구는 IAM 액세스 관리자 ( = IAM Access Advisor ) 로 유저 레벨에서 사용이 가능하다.

액세스 관리자는 사용자에게 부여된 서비스의 권한과 해당 서비스에 마지막으로 액세스한 시간이 나온다.

이는 최소 권한의 원칙에 맞게 사용자를 관리하도록 매우 도움이 되는 도구로, 해당 도구를 사용하여 불필요한 권한을 파악할 수 있다.

IAM 모범 사례

마지막으로 지금까지 배운 내용에 대한 정리로, 보안을 위한 IAM 모범 사례를 나열한다.

사용자를 추가하거나 수정하는 것 외에는 루트 계정을 사용하지말라.
하나의 AWS 사용자는 하나의 사용자를 갖는 것이 옳으니 자격 증명을 공유하지 말라.
사용자를 그룹에 할당하여 그룹으로 권한을 주어라.
강한 비밀번호 정책을 사용하라.
MFA를 사용하라.
AWS 서비스에 권한을 줄 때마다 역할을 생성하여 사용하라. ( ex. EC2 Instance )
AWS 프로그래밍을 할 경우, 즉, CLI, SDK를 사용할 경우 Access Key는 절대 공유하지말라.
계정의 권한을 감사할 때에는 IAM 자격 증명 보고서와 IAM Access Advisor를 사용하라.

[SAA-C03] 4. IAM Role

카카수(kakasoo) — Sat, 6 Apr 2024 19:10:23 +0900

IAM Role ( = 역할 )

Role은 사용자와 같지만 실제 사람이 사용하도록 만들어진 것이 아니고 AWS 서비스에 의해 사용되며, IAM 대시보드에서 사용할 수 있다.

아직 EC2에 대한 걸 배웠지만, 만약 EC2 인스턴스를 만든다면, EC2 인스턴스가 AWS에서 어떤 작업을 수행하길 원할 수도 있다.

이럴 때 EC2 내부 코드 상에 자격증명을 하는 대신 EC2에 필요로 하는 권한을 담아 IAM Role을 만들고 이를 하나의 개체로 묶을 수 있다.

이러면 EC2 인스턴스가 AWS 개체에 접근하고자 할 때 Role에 따라 접근할 수 있는 자원을 확인할 것이다.

일반적으로는 EC2 Instance Roles과 Lambda Function Roles이 존재하지만, 그 외에도 많은 서비스에 Role을 적용할 수 있다.

Role 생성하기

아래 이미지를 참고하여, Role을 생성해볼 수 있다.

Role도 사용자 정책 ( = Policy ) 과 마찬가지로 동일한 JSON 파일을 사용하여 정의되기 때문에, IAM-001에게 준 것을 그대로 넣었다.

[SAA-C03] 3. AWS CLI, Cloud Shell

카카수(kakasoo) — Sat, 6 Apr 2024 18:58:19 +0900

AWS 리소스에 접근하는 방법

AWS에는 3가지 접근 방법으로, 콘솔, CLI, AWS SDK가 있다.

콘솔은 대시보드 형태로 웹 상에서 직접 AWS 리소스를 다룰 때 사용하지만, CLI나 AWS SDK는 외부 환경에서 리소스를 다룰 수 있다.

따라서 CLI, AWS SDK는 권한 인증이 필수적인데, 이 때 액세스 키를 필요로 한다. ( 액세스 키는 절대 다른 사람에게 공유해선 안 된다. )

액세스 키 아이디 ( Access Key ID ) 는 username과 같고 시크릿 액세스 키 ( = Secret Access Key ) 는 password와 같다.

CLI는 AWS에서 제공하는 커맨드 라인 인터페이스로 쉘과 같은 환경에서 명령어로 AWS를 사용할 수 있게 해준다.

SDK는 Software Developer Kit의 준말로, 특정 언어로 된 라이브러리의 집합인데,

프로그래밍 언어에 따른 개별 SDK가 존재하여 이 역시 SDK 서비스나 API 프로그래밍을 위한 액세스를 가능하게 해준다.

이 SDK는 터미널이 아닌, 코딩을 통해 애플리케이션에 심어야 한다.

CLI 환경에서 AWS 접근하기

Install or update to the latest version of the AWS CLI - AWS Command Line Interface

When updating from a previous version, the unzip command prompts to overwrite existing files. To skip these prompts, such as with script automation, use the -u update flag for unzip. This flag automatically updates existing files and creates new ones as ne

docs.aws.amazon.com

일단 AWS 문서대로 AWS CLI 도구를 설치해야 한다.

이 블로그 포스팅에서는 Mac 기준으로만 설명한다.

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

Password:
installer: Package name is AWS Command Line Interface
installer: Installing at base path /
installer: The install was successful.

aws --version
aws-cli/2.15.36 Python/3.11.8 Darwin/22.1.0 exe/x86_64 prompt/off

위 두 명령어를 치고, Password가 나오면 기기에 저장된 사용자 비밀번호를 입력하여 설치를 진행한다.

설치가 완료되면 aws --version 명령어를 쳐서 설치가 제대로 이루어졌는지 확인한다.

aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]: ap-northeast-2
Default output format [None]: # 입력 없이 엔터를 누르고 진행

다음으로는 aws configure 명령어로 AWS 계정에 대한 인증 정보를 주어야 한다.

여기서는 미리 만든 액세스 키로 ID와 Secret Access Key를 입력하여 인증을 했고, region은 Seoul Region을 명시했다.

액세스 키를 생성하고 싶다면, IAM 대시보드에서 특정 사용자로 간 다음 [액세스 키 만들기] 를 클릭하면 된다.

여담으로, 액세스 키를 다시 삭제하고 싶다면 Root 계정에서 하는 게 아니라 해당 사용자로 로그인하여 삭제해야 한다.

aws iam list-users

{
    "Users": [
        {
            "Path": "/",
            "UserName": "IAM-001",
            "UserId": "생략",
            "Arn": "arn:aws:iam::699508358870:user/IAM-001", // Amazon Resource Names
            "CreateDate": "2024-04-06T05:39:04+00:00", // 생성 시간
            "PasswordLastUsed": "2024-04-06T08:14:11+00:00" // 마지막 비밀번호 사용 시간
        }
    ]
}

인증이 완료되면 `aws iam list-users`와 같이 AWS CLI 명령어를 사용할 수 있다.

위 명령어는 iam의 사용자 리스트를 조회하는 것으로, 조회된 정보는 사용자 대시보드와 매우 유사한 형태인 걸 확인할 수 있다.

위와 같이 정보를 볼 수 있는 것은, IAM-001에 미리 IAM 접근 권한을 설정했기 때문이다.

접근 권한을 설정하는 것을 보지 않고 이 글부터 본 사람은 아래 링크를 확인하면 된다.

[SAA-C03] 1. IAM 사용자와 그룹 생성

사용자, 사용자 그룹 ( Users, User Groups ) 에 대한 설명 Alice, Bob, Charles, David, Edward, Fred 6명의 사람들이 있다고 해보자. Alice, Bob, Charles는 Developer이고, David, Edward는 Operation팀에 속한다. 마지막으로 Fred

kscodebase.tistory.com

AWS Cloud Shell

Supported AWS Regions for AWS CloudShell - AWS CloudShell

Supported AWS Regions for AWS CloudShell This section covers the list of supported AWS Regions and Opt-in Regions for AWS CloudShell. For a list of AWS service endpoints and quotas for CloudShell, see the AWS CloudShell page in the Amazon Web Services Gene

docs.aws.amazon.com

AWS에는 클라우드 쉘이라는 기능이 존재하는데, 이는 사용자마다 클라우드 환경에서 쉘을 사용할 수 있게 AWS가 제공하는 기능이다.

위치는 사용자 계정 정보가 있는 공간에, 쉘 모양으로 되어 있는 아이콘을 누르면 확인할 수 있다.

CLI 환경을 사용한 것처럼 동일하게 사용이 가능하되, 이미 aws configuration으로 자격증명을 한 것처럼 바로 CLI를 호출할 수 있다.

--region 옵션을 주면 CLI를 사용할 때 리전을 명시할 수 있지만, 사용하지 않는다면 브라우저 상에서 선택한 region이 기본값이 된다.

클라우드 쉘에는 전체 저장소가 있는데, 이를 사용해서 간단한 파일을 업로드하거나 다운로드하는 것도 가능하다.

[cloudshell-user@ip-10-132-40-113 ~]$ echo "text" > demo.txt
[cloudshell-user@ip-10-132-40-113 ~]$ ls
demo.txt
[cloudshell-user@ip-10-132-40-113 ~]$ 
[cloudshell-user@ip-10-132-40-113 ~]$ pwd
/home/cloudshell-user

위 스크립트는 파일을 저장한 후 ls 명령어로 파일이 저장된 것을 확인하고, 해당 경로를 pwd 명령어로 찍어본 것이다.

이제 이 파일을 다운로드 기능을 사용해서 내려받을 수 있다.

AWS CLI는 외부에서 자격증명을 해야 하기 때문에 보안 문제가 있을 수 있어, 간단한 명령어는 클라우드 쉘을 쓰는 것이 낫다.

이 때, 사용할 간단한 명령어들은, 미리 스크립트를 작성하여 파일로 공유해두면 동일한 명령어의 사용을 보장할 수도 있다.

[SAA-C03] 2. IAM 사용자 보호 방법 ( ex. MFA )

카카수(kakasoo) — Sat, 6 Apr 2024 16:47:36 +0900

IAM 사용자 보호 방법 2가지

사용자들은 계정에 접근 권한이 있고 구성을 변경하거나 리소스 삭제가 가능한 경우도 많다.

따라서 적어도 루트 계정만은 반드시 보호해야 하며, 전체 IAM 사용자도 보호하는 것이 좋다.

그룹과 사용자의 정보가 침해당하지 않게 보호하는 매커니즘은 2개가 있다.

비밀번호 정책
MFA의 사용 ( 다요소 인증 )

비밀번호가 더 어려워지게 특정 유형 글자 사용을 강제하거나 비밀번호 최소 길이를 지정할 수 있다.

또 비밀번호를 수정할 수 없게 하거나, 90일마다 비밀번호를 만료시켜 변경하게 할 수도 있고,

이전에 사용한 것과 동일한 비밀번호를 사용하는 것을 막아 보안을 더 안전하게 유지할 수 있다.

이런 식으로 비밀번호 정책을 이용하면 계정에 대한 치명적인 공격을 막는 데에 도움이 된다.

두번째 방어 메커니즘은 MFA, 다 요소 인증이라는 것인데 AWS에서는 이 메커니즘을 필수로 권장한다.

MFA는 해킹으로 비밀번호가 유출된 상태되더라도 휴대전화처럼 물리적 장치를 뺏기지 않는 한 안전하다.

MFA 장치의 옵션

시험에 나오는 내용이지만 매우 간단하다.

아래의 4가지 장치가 있다고 생각하면 된다.

Virtual MFA device ( = 가상 MFA 장치 )로 Google Authentication와 같은 어플리케이션이 해당
Universal 2nd Factor (U2F) Security Key ( = 범용 두 번째 인자 )

MFA device는 인증받은 휴대폰이나 물리적 기기를 통해 코드를 내려주는 방식을 말한다.

U2F는 AWS가 아닌 다른 인증 단체, 기업으로부터 USB 같은 장치를 통해 전자 열쇠를 발급받는 방식이다.

Yubico라는 회사의 YubiKey가 대표적인데, 하나의 USB 키로 여러 AWS 사용자에 로그인할 수 있게 한다.

Hardware Key Fob MFA Device ( Gemalto의 제품으로 Virtual MFA device의 하드웨어 버전 )
Harware Fob MFA Device for AWS GovCloud ( US 정부의 클라우드에 접근할 때 사용하는 특수한 키 팝 )

사용자 대시보드 ( = IAM User )에서 콘솔 액세스를 보면 MFA가 없다는 표시가 나온다.

클릭하여 자신이 원하는 device를 고르면 되는데, 보통 하드웨어를 가지고 있지는 않을 테니 첫번째 Authentication App을 고르면 된다.

고른 다음 어플리케이션을 설치하고 ( ex. Google Authentication ) 코드를 2번 연속으로 입력하면 해당 App이 등록이 된다.

등록 후에는 등록된 기기를 대시보드에서 확인할 수 있으며, 이후 로그인할 때마다 MFA 코드를 입력할 것을 요구한다.

[SAA-C03] 1. IAM 사용자와 그룹 생성

카카수(kakasoo) — Sat, 6 Apr 2024 15:35:12 +0900

사용자, 사용자 그룹 ( Users, User Groups ) 에 대한 설명

Alice, Bob, Charles, David, Edward, Fred 6명의 사람들이 있다고 해보자.

Alice, Bob, Charles는 Developer이고, David, Edward는 Operation팀에 속한다.

마지막으로 Fred는 어느 팀에도 속하지 않았다고 해보자.

이 때, 이 6명의 사람들을 각각 User ( = 사용자 ) 라고 하고, 정의된 3개의 그룹을 User Group ( = 사용자 그룹 ) 라고 정의한다.

사용자들은 자신의 그룹으로부터 권한을 상속받아 사용할 수 있기 때문에 그룹을 이용해서 권한을 관리하는 편이 더욱 효율적이다.

반면, Group Aduit Team 처럼, Charles, David가 이중으로 그룹에 속한 경우도 있을 것이다.

이 경우에 Charles, David는 자신이 속한 그룹의 권한 외에, Group Aduit Team의 권한까지, 총 2개의 권한을 상속받게 된다.

권한은 교집합이 아니라 합집합의 형태로, 자신이 속한 사용자 그룹의 권한들을 모두 합하여 가지게 된다.

IAM ( Identity and Access Management )

IAM은 위와 같이 사용자와 사용자 그룹을 관리할 수 있는 대시보드이자 그런 기능들을 의미한다.

우리는 이미 AWS에 가입할 때 IAM을 사용한 것이나 마찬가지인데, 이는 우리의 계정 역시 IAM에 해당하기 때문이다.

이런 첫번째 계정을 Root 계정이라고 부르고, 우리는 대부분의 경우에는 IAM에서 생성한 사용자를 사용해야 한다.

아무리 작은 기능이라도 IAM으로 사용자를 생성해서, 딱 필요한 기능만 사용하게끔 할 것인데,

이는 AWS가 '최소 권한 원칙'을 적용하여, 필요한 것 외에는 접근 못하게 생성하는 것을 권장하기 때문이다.

권한 ( = Policy )은 각 사용자 별로 딱 필요한 수준만 부여해주고, 그 이상의 권한을 사용할 수 없게 막아두는 것이 좋다.

이는 비용 관리 측면과 보안 측면에서, AWS가 권장하는 방식이지만, 말 그대로 권장이기 때문에 지키지 않더라도 불이익은 없다.

여담으로, Fred와 같이 어떤 그룹에도 속하지 않은 유저에게는 그 유저만 해당하는 권한을 부여할 수 있는데 이를 인라인 정책이라고 한다.

정리하면, IAM은 루트 계정 아래에 각 권한 별로 여러 사용자와 사용자 그룹을 생성하고 딱 필요한 만큼의 권한만 부여하는 것을 의미한다.

Policy 작성하기

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow", // Permission에 대한 허가
      "Action": "ec2:Describe*", // EC2의 Describe에 대한 액션을 의미
      "Resource": "*" // 접근 가능한 자원은 전체
    },
    ...
  ]
}

정책은 위와 같이 JSON 형식으로 작성한다.

Version은 보통 "2012-10-17"으로 고정이다.

Statement는 배열의 형태로, 허용되는 권한에 대한 내용을 담아야 하는데 각 객체에는 Sid, Effact, Action, Resource가 있다.

Sid는 해당 문장에 대해 아이디를 부여할 때, string으로 원하는 아이디 값을 넣어주면 된다.

Effect는 Allow, Deny의 enum 타입으로 다음으로 서술할 정책에 대해 허용할 권한인지 제한할 권한인지를 명시하면 된다.

Action은 이제 권한을 의미하며, Resource는 그 권한이 가리키는 리소스 대상을 의미한다.

사용자와 사용자 그룹 생성하기 실습

AWS에 회원가입했다는 가정 하에, 우선 로그인을 한 시점으로 설명을 시작한다.

최초 로그인을 한 후 IAM 대시보드로 이동한다.

대시보드에 이동하면 우측 상단에 리전 ( Region )이 글로벌로 설정된 것을 확인할 수 있는데, 이는 IAM이 글로벌 서비스란 의미다.

글로벌 서비스란 어떤 리전, 즉 어떤 지역에서나 사용할 수 있는 서비스라는 의미로, 계정임을 생각해보면 너무 당연한 일이다.

[사용자 생성] 버튼을 눌러서 이동하면,

위와 같이 사용자 생성 칸이 나온다.

나의 경우에는 'IAM-001' 이라고 입력했는데, 이는 이 사용자의 이름이 될 것이다. ( 추후 로그인할 때 사용자의 이름을 사용한다. )

선택한 것으로는 AWS Management Console에 대한 사용자 액세스 권한을 허용했는데, 이는 이 대시보드에 접근하는 걸 말한다.

API나 cli 환경에서만 사용할 게 아니라면 당연히 이 권한을 부여할 것이고, 권장사항은 identity center에서 지정하라고 나온다.

하지만 우리는 IAM 사용자를 생성할 것이라고 체크를 할 것이고, 일반적으로 콘솔 암호는 자동 생성된 암호를 선택해주면 된다.

자동 생성된 암호를 선택한 경우에는, 로그인 시 비밀번호 변경을 강제하는 옵션이 있는데 그것도 선택해주면 된다.

생성 후 본인이 바로 사용할 사용자라면, 수동으로 비밀번호를 설정하는 것을 추천한다.

다음 버튼을 누른다.

다음 버튼을 누르면, 이번에는 이 사용자에 대한 권한 설정을 하는 창이 나온다.

권한 설정은 이전에 만든 그룹에 사용자를 추가하는 것이 있고, 권한을 복사하여 새 권한을 만드는 것도 있다.

직접 정책 연결은 앞서 설명한 인라인 정책 ( Inline Policy ) 으로, 해당 사용자에게 그룹 없이 권한을 부여하는 방식이다.

여기서는 admin으로 이름을 설정하고 모든 권한을 주기 위해 'AdministratorAccess'를 선택한다.

미리 말한 것처럼, 권한은 최소 권한으로 주는 것이 좋지만, 여기서는 학습을 위해 전체 권한을 부여하는 것으로 했다.

권한을 부여한 다음에는 사용자 그룹이 생성되었을 것인데, 바로 선택하여 유저에게 권한을 준다.

마지막으로 최종 검토 페이지가 나오면 선택사항인 태그를 넣어줄 수 있다.

여기서는 임시로 Department라는 키에 Engineering 이라는 값을 넣었는데 아무런 의미도 없지만 추후 식별하기 편해서 넣는다.

마지막으로 사용자 생성 버튼을 누르면 생성이 완료된다.

사용자 탭으로 가서 방금 만든 IAM-001을 누르면 위와 같이 방금 만든 사용자의 상세를 볼 수 있다.

권한 정책에 AdministratorAccess가 있고, 연결 방식 ( Attached via ) 으로는 admin user group이 선택되어 있다.

이 권한이 어디서부터 왔는가를 의미하는 값으로, 추후 사용자의 권한을 관리할 때 참고할 수 있다.

AWS 사용자로 로그인하기

Root 계정의 프로필 탭을 누르거나 IAM 대시보드에 가면 AWS 계정에서 계정의 아이디를 확인할 수 있다.

이 계정의 ID를 입력한 다음, 아래 탭에서는 유저의 이름 ( ex. IAM-001 ) 을 입력, 설정한 비밀번호를 입력하면 로그인이 가능하다.

하지만 계정의 ID는 기억하기 어렵기 때문에 계정 ID에 대한 별칭을 설정할 수 있다.

별칭을 'kakasoo' 라고 설정한 경우 ID 12자리 대신 'kakasoo' 라는 별칭을 사용하고, 사용자 이름으로 계정 사용자로 로그인이 가능하다.

각각 로그인 후 상단의 프로필 탭을 누르면 루트 계정과 IAM 사용자가 나뉘는 것을 볼 수 있다.

[Meta] Invalid parameter

카카수(kakasoo) — Thu, 4 Apr 2024 22:55:38 +0900

에러 상황

{
  "channel": "meta",
  "message": "(#100) The parameter (생략) is required",
  "type": "OAuthException",
  "code": 100,
  "fbtrace_id": (생략)
}

code 100번에 message가 항상 고정으로 들어가는 것은 아니지만, code 100이 시사하는 바는 항상 똑같다.
요청자의 요청이 잘못된 경우로, 일반적으로 우리가 4XX 클라이언트 에러라고 생각하는 것을 모두 code 100으로 표현한다.
여기서는 생략한 지점에 들어간 파라미터가 잘못되었다는 의미로, 어떤 파라미터가 잘못되었는지에 따라 요청이 바뀐다.

해결 방법

명백한 개발 실수이기 떄문에 수정을 하면 된다.

특정 파라미터의 경우에는 어떤 점이 잘못되었는지를 error_subcode와 error_user_title, error_user_msg로 상세히 표현해준다.

그러면 그 내용에 따라서 대응해주면 되는데, 발생 가능한 구체적인 사례들에 대해서는 각각의 글로 작성할 예정이다.

[Meta] 메타 유저와 대응되는 파트너사의 구조 - 최종

카카수(kakasoo) — Thu, 4 Apr 2024 22:39:15 +0900

[Meta] 메타 유저와 대응되는 파트너사의 구조 ( PBM, CBM )

이전 글에서 [Meta] 용어 정리 (메타 자산 구조, 유저부터 유저의 자산까지) 메타 용어 정리 설명하기에 앞서 메타 용어들을 정리하고 가야 할 필요성을 느낀다. 메타의 ERD 구조가 실제로는 어떠한

kscodebase.tistory.com

서론

저번에는 PBM과 CBM에 대해서 설명했다.

마지막 그림만 가지고 다시 설명하면, Meta User는 PBM을 자신의 agency로 등록해야 한다.

모종의 이유로, PBM에서 바로 광고를 집행하는 것은 계정 정지 등의 이유에 대해서 대응하기 취약하기 때문에 PBM은 CBM을 만든다.

PBM은 자신의 고객 당 하나의 CBM을 만들고, 고객으로부터 받은 자산 ( = DataSource )를 다시 CBM에게 넘긴다.

그러면 이제 CBM은 Meta User의 광고를 대신 집행할 수 있게 되는 것이다.

메타 유저와 파트너 사의 관계에 대한 최종적인 그림

[Meta] 용어 정리 (메타 자산 구조, 유저부터 유저의 자산까지)

메타 용어 정리 설명하기에 앞서 메타 용어들을 정리하고 가야 할 필요성을 느낀다. 메타의 ERD 구조가 실제로는 어떠한지 모르지만, Meta Marketing API를 호출하면서 광고 자산들의 구조에 대해 대

kscodebase.tistory.com

결국 이러한 형태가 된다.

좌우가 상당히 유사한 구조인데, 메타의 구조 상 완벽히 위와 대응되지는 않지만, 머릿 속에 두면 대부분의 의문을 해결할 수 있는 그림이다.

이로써 메타 유저부터 광고 계정까지, 그리고 자산 ( = 페이지, 카탈로그, 픽셀 ), 마지막으로 이와 대응되는 파트너 구조까지 설명했다.

이 개념들을 머릿속에 그리고 있다면 메타 개발자 문서를 읽는 데에 막힘이 없을 것이다.

스틱 - 쓸모없는 것, 의외성, 공백 이론

카카수(kakasoo) — Mon, 1 Apr 2024 22:33:29 +0900

전문가

복잡함에 더 매력을 느끼는 사람 - 스틱 81p

기능 추가는 사실 매우 순수한 의도에서 식자된다. 기술자가 리모컨을 바라보며 생각에 잠긴다. ‘흠, 여기 앞쪽 공간이 비는군. 그러고보니 마이크로칩 용량도 좀 여유가 있었지. 남는 용량을 그냥 놀리느니 율리어스력과 그레고리력을 변환하는 기능을 넣는 게 어떨까?’ 기술자는 그저 사람들을 돕고 싶었을 뿐이다. 사람들을 깜짝 놀라게 할 만한 새로운 기능을 추가해 리모컨을 더욱 개선하고 싶었을 뿐이다. 한 편 팀의 다른 기술자들은 달력변환 기능에 별반 관심이 없다. 쓸데없는 기능이라고 생각하면서도 굳이 “달력변환 기능을 추가하느니 차라리 내 모가지를 잘라!” 라고 반대하지는 않는 것이다. 이런 식으로 천천히 그리고 조용히 리모컨과 다른 첨단 기술 기기들은 점점 파멸을 향해 기어간다.

- 스틱 85p

이 책에서 전문가에 대한 재정의를 보고 처음 봤을 때, 이외수 작가의 '식인종'이나 '명예교수'처럼 탁월한 설명이라고 생각했다.

어려운 개념을 이해하기 위해서는, 우리가 이해하기 쉬운 개념으로 비유해서 설명해야 한다.

탁월한 비유, 예를 들어 원자와 전자의 관계가 태양계라고 설명하는 것과 같은 비유는 원래의 모델을 이해하는 데에 큰 도움을 준다.

설령 전자가 사실 양자 구름이라는 확률적 개념에 의존하고 있다고 하더라도, 부분적이나마 이해하는 데에 큰 도움을 준다.

만약 어려운 개념이기 때문에 설명조차 어려워야 한다면 대부분은 그 내용을 끝까지 이해하기도 전에 피할 것이다.

할리우드 영화의 성공을 결정하는 카피 한 줄

이 부분 역시 통째로 중요한 단락이다.

어떤 사고 흐름을 가져야 하는지를 말해주는 단락이었다.

하나의 문장이 이 영화를 액션 영화인지 장르를 구분하게 하고 배우를 선정하게 만든다.

책에 나온 비유는 가물가물하지만, 만약 어떤 영화의 장르가 액션이고 스릴러라고 한다면 벌써 어떤 식으로 촬영이 될지 상상이 될 것이다.

사람은 하나의 문장으로부터 생각을 파생해나가기 때문에 처음에 어떻게 비유하느냐에 따라서 전체를 결정하게 만든다.

할리우드에서는 영화 투자를 받기 위해서 이미 시장에 내보였던 적 있는 영화 제목으로 새 영화를 설명한다고 한다.

의외성

“10대들 사이에 새로운 마약이 성행하고 있습니다. 여러분의 약장에도 숨어 있을 지 모릅니다.” - 스틱 139p

자동차 광고, 거친 돌밭을 달리는 차, 클로즈 아웃된 화면에서 멈춤없이 질주하며 마력을 뽐내는 차가 있다.

다시 클로즈업이 되며, 차에 탄 사람들이 웃고 있다.

나레이션이 차의 이름이 한 번 언급하고, 가족들을 위한 최고의 선택이라고 말한다.

“그 후 차가 갑자기 다른 차와 부딪히며 전복되고” 안전벨트를 차라고 말하는 공익 광고.

이 광고에는 기존의 공식을 깨트리는, 확실한 의외성이 있고 또 사람들을 놀라게 만든다.

첫번째 원칙이 단순함이었다면 두번째 원칙은 의외성이고, 이는 청자들을 놀라게 해야 한다는 의미이다.

사람들을 놀래키는 방법에 대해서 알 수 있다면 청자들에게 효과적으로 의미를 전달할 수 있을 것이다.

공백 이론

어린 아이들이 수백 마리의 포켓몬 이름과 특성을 전부 외울 수 있지만 주기율표를 외우지 못하는 이유가 뭘까?

의외성, 놀라움은 청자로 하여금 지식을 추리 소설을 읽듯이 탐독할 수 있게 궁금증을 자아내는 요소이다.

어린 아이들이 수백 마리의 포켓몬 이름과 특성을 전부 외우듯이 미지에 대한 호기심을 불러일으켜야 한다.

하지만 이런 사실에도 불구하고 사람들은 스스로 많은 것을 알고 있다고 착각하고 있어 놀래키기가 어렵다.

이는 지식의 수준이 적을수록 더 심해지는데, 미국의 주를 17개 외운 사람은 자기 지식에 자부심을 가진다.

반면 47개를 외운 사람은 나머지 3개의 주가 뭔지 심히 궁금해하며 배우고 싶어한다.

내가 이 책을 볼 때, 사람들에게 의이함, 호기심, 놀라움을 불러일으키기 위해서는 세 가지의 조건이 있다.

‘당신이 알고 있는 게 다가 아니다.’ 라는 사실을 깨닫게 해야 한다.
하지만 모르는 부분을 한꺼번에 다 공개해서는 안 되고, 조금씩 천천히 알아갈 수 있게 해줘야 한다.
지식의 공백을 채워줄 수 있는 그 조금의 부분을 알고 싶게끔 자극해야 한다.

“지저분한 아이스크림 기계”에 선정된 레스토랑을 알아보세요. - 스틱 139p

우리는 외국의 큰 사건들보다 우리 동네에 현상수배범 몽타주를 보는 데에 더 관심이 있을 것이다.

우리에게 재미나 영향을 줄 수 있는 어떤 지식을 우리가 모르고 있다는 것을 우리는 참기 힘들 것이다.

공백을 채우고 싶은 욕망

초등학교 학생들을 완전 합의와 반론 제기, 두 가지 방식으로 나누어서 수업을 진행해보는 실험이 있었다.

모든 학생이 합의에 이르게 하는 방식의 수업을 들은 아이들보다 후자가 더 도서관을 자주 가게 되었고,

또 수업이 끝난 다음 시청각 자료를 주었을 때 반론 제기 방식의 아이들이 쉬는 시간에도 볼 확률이 높았다.

전자의 경우 10%의 학생만이 영상을 본 반면, 후자는 45%의 학생이 영상을 보았다고 한다.

그 이유는 아마도 후자의 학생들이, “그래서 누구 말이 맞았는데?” 라는, 공백을 채우려는 욕망이 있기 때문이다.