(241002 작성 내용에서 계속....)
3. 사용자 그룹에 정책을 추가
4) EC2 인스턴스 생성 (AWS 안에 가상머신 생성)
4-1) 리전을 서울 리전으로 변경
4-2) 인스턴스 시작을 눌러 인스턴스 생성
5) S3 버킷 생성 후 크기가 작은 파일 업로드
- 버킷 : 파일 저장소. 버킷의 이름에는 중복이 없어야 한다. 중복이 있을 경우 저장 과정에서 충돌이 발생할 수 있음.
6) user1 사용자로 로그인(다른 브라우저 사용) 후 S3와 EC2 서비스로 접근
6-1) root 계정으로 user1의 콘솔 로그인 링크를 확인
6-2) 다른 브라우저에서 user1 계정으로 로그인하고 S3에 접속
- 버킷 목록 조회(List*), 객체 목록 조회(Describe*), 객체 상세 목록 조회(Describe*)이 가능하다.
> user1 계정에 대하여 S3readonlyaccess 정책을 적용했기 때문에 가능하다.
6-3) 버킷에 파일(객체) 업로드
- user1에 대한 계정은 S3readonlyaccess 정책만 적용했기 때문에 파일(객체) 업로드(Put*)는 불가능하다.
6-4) AmazonS3ReadOnlyAccess
https://docs.aws.amazon.com/ko_kr/aws-managed-policy/latest/reference/AmazonS3ReadOnlyAccess.html
- user1 사용자는 S3-Support 그룹에 포함되어 있고, S3-Support 그룹은 AmazonS3ReadOnlyAccess 권한을 가지고 있으므로, 버킷 목록을 조회(List*)할 수 있고, 버킷에 저장된 파일(객체) 목록(list*)과 상세 정보를 조회(Describe*)할 수 있고, 버킷에 저장된 객체를 다운로드(Get*)할 수도 있으나, 객체를 추가(Put*)하는 것은 불가능하다.
7) user1 사용자로 EC2 서비스에 접근
- EC2에 대한 권한이 없으므로 정보가 출력되지 않는다.
8) user2 사용자로 로그인
8-1) S3 서비스로 접근
- user2 사용자는 S3 서비스에 대해 아무런 권한이 없기 때문에 버킷 목록을 볼 수 없고, 모든 버튼이 비활성화 상태이다.
8-2) EC2 서비스로 접근하여 EC2 인스턴스를 조회 및 인스턴스 중지
- 인스턴스 조회에는 문제가 없다.
- readonlyaccess 권한이기 때문에 인스턴스 중지에 실패한다.
8-3) AmazonEC2ReadOnlyAccess
https://docs.aws.amazon.com/ko_kr/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html
- user2 사용자는 EC2-Support 그룹에 속해 있고, EC2-Support 그룹은 AmazonEC2ReadOnlyAccess 권한을 가지고 있으므로, 인스턴스 목록과 상세 정보는 조회는 가능하나, 인스턴스 중지, 시작, 재부팅은 불가능하다.
9) user3로 로그인
9-1) S3 서비스와 EC2 서비스에 접근
- EC2PullAccess 권한을 가지고 있기 때문에 S3 서비스에는 접근이 불가능하고 EC2 서비스에는 접근이 가능하다.
- 위와 같이 인스턴스 조회(Describe*) 항목만 출력되는 이유는 그룹 정책 적용 시 인라인 정책에서 경계 권한으로 ec2describe 사항을 넣어줬기 때문이다.
- 동일한 이유로 인스턴스 중지(Stop*)와 시작(Start*) 권한이 적용되어 있기 때문에 가능하다.
10) user3 사용자를 S3-Support 그룹에 추가한 후 S3 서비스로 이동
10-1) root 계정으로 user3 사용자를 S3-Support 그룹에 추가
10-2) user3 사용자로 S3 서비스에 접근
- 버킷 목록/상세 조회, 개체 목록/상세 조회 및 다운로드가 가능하다.
11) user1 사용자에게 EC2 인스턴스 읽기 전용 권한 부여 (인라인 정책으로 부여)
11-1) user1 계정으로 로그인 후 EC2 서비스 접근
12) 모든 리소스 삭제
12-1) S3에서는 객체(파일)을 모두 삭제한 후 버킷을 삭제한다.
12-2) EC2 인스턴스 종료
12-3) 사용자, 사용자 그룹 삭제
Access Key를 이용한 AWS 서비스 이용
* AWS 서비스를 이용하는 방법
1) Management Console
- 사람 사용자가 로그인 후 사용
2) AWS CLI
- 사람 또는 프로그램이 Access Key를 이용해서 사용
3) 각 개발 언어별 SDK(Source Development Kit)
- 응용 프로그램을 이용하여 사용
1. AWS CLI 설치
https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html
- 설치가 완료되면 명령 프롬프트를 이용해서 설치 확인
C:\Users\crpark> aws --version
aws-cli/2.17.63 Python/3.12.6 Windows/11 exe/AMD64
C:\Users\crpark> aws iam list-users
Unable to locate credentials. You can configure credentials by running "aws configure".
2. 사용자 생성 후 Access Key를 발급
2-1) Access Key를 등록
2-2) 사용자 목록을 조회
3. S3 버킷 목록 조회
https://docs.aws.amazon.com/cli/latest/reference/s3/
https://docs.aws.amazon.com/cli/latest/reference/s3api/list-buckets.html
> aws s3api list-buckets
3-1) S3 버킷 생성 후 조회
- CLI를 이용한 버킷 생성
> aws s3api create-bucket --bucket mybucket-inno-6 --create-bucket-configuration LocationConstraint=ap-northeast-2
- 버킷 조회
> aws s3api list-buckets
LAB
AWS CLI를 이용해서 생성한 S3 버킷에 AWS CLI를 이용하여
(1) (작은 크기의) 파일을 업로드한 후
(2) 업로드한 파일을 확인하고
(3) 모든 작업이 끝나면 생성한 S3 버킷을 삭제한다.
(1) 버킷에 객체 등록 (put-object)
(2) 버킷에 객체가 등록되었는지 확인 => 객체 목록 조회 (list-objects)
(3) S3 버킷 삭제 => 객체 먼저 삭제 후 버킷 삭제
VPC (Virtual Private Cloud)
- AWS 사용자 계정 전용 가상 네트워크
- AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리
- 하나의 AWS 리전 안에서만 존재할 수 있고, A 리전에 만든 VPC는 B 리전에서는 보이지 않는다. => VPC peering
- 생성 시 RFC 1918에 지정된 프라이빗 주소 체계 사용을 권장한다.
VPC 구성 옵션
https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/create-vpc-options.html
1. 기본 VPC (default VPC)
:
- 기본 VPC 구성 요소
1)
2. 서브넷(subnet)
- VPC 내 논리적 구분
- 하나의 가용영역 내에서만 존재할 수 있다.
- 종류
1) 퍼블릿 서브넷
2) 프라이빗 서브넷
3. 탄력적 네트워크 인터페이스 (ENI, Elastic Network Interface, )
- 물리 서버의 네트워크 인터페이스와 같은 기능 수행
- VPC에서 가상 네트워크 카드를 제공하는 논리적 네트워크 구성 요소
4. 인터넷 게이트웨이 (igw, Internet GateWay)
- 퍼블릭 IP(나를 찾을 수 있는 주소) 주소를 갖는 인스턴스가 인터넷에 연결할 수 있도록 기능을 제공한다.
- 처음 VPC를 만들면 igw와 연결되지 않으므로, 직접 igw와 VPC를 연결해야 한다.
- 하나의 VPC는 하나의 igw만 연결할 수 있다. => 나가는 관문은 하나뿐
5. 라우팅 (routing)
- VPC의 네트워크 트래픽을 전달할 위치를 결정하는데 사용되는 규칙이다.
- 트래픽을 전달할 IP 주소 범위(대상 주소)와 트래픽을 전송할 게이트웨이, 네트워크 인터페이스 또는 연결(대상)을 지정
- VPC는 소프트웨어 함수로 IP 라우팅을 구현하고, 사용자는 라우팅 테이블만 관리하면 된다.
- 라우팅 테이블 == 라우팅의 집합으로, 서브넷과 연결할 수 있다.
- 기본 라우팅 테이블 = 기본 VPC와 함께 자동으로 제공되는 라우팅 테이블
> 기본 VPC인 경우, local 및 igw로의 라우팅을 포함한다.
> 기본 VPC가 아닌 경우, local 라우팅만을 포함한다.
- 예시 1.
----------- ---------------------
대상 주소(Destination) 대상(Target)
----------- ---------------------
172.31.0.0/16 local
0.0.0.0/0 igw-0b7313723843100f9
~~~~~~~ ~~~~~~~~~~~~~~~~~~~
인터넷 상의 모든 인터넷 게이트웨이
호스트 IP 기반
=> if, 172.31.10.10 으로 패킷을 보내려고 하면, local로 라우팅을 처리한다.
=> if, 198.51.100.50 으로 패킷을 보내려고 하면, 라우팅할 위치와 가장 근접하게 일치하는 항목을 기반으로 라우팅을 처리한다. >>> igw로 라우팅된다.
=> 결론적으로, 라우팅 테이블 항목 간의 순서는 중요하지 않다.
- 예시 2.
6. 보안 그룹 (SG, Security Group)
- 인스턴스의 ENI에서 송수신하는 트래픽을 제어한다.
- 모든 ENI는 최소 한개 이상의 보안 그룹과 연결되어야 하고, 보안 그룹은 또한 여러 ENI와 연결 될 수 있다. (= N:N 관계)
- 생성할 때 그룹 이름 / 설명 / 포함될 VPC를 지정하고, 생성 후에 인바운드/아웃바운드 규칙을 지정한다.
=> 트래픽을 허용한다는 말
- 상태 저장 방화벽 역할을 수행 => 보안 그룹이 트래픽을 한 방향으로 전달하도록 허용할 때 반대 방향의 응답 트래픽을 지능적으로 허용하는 것
7. 네트워크 접근 제한 목록 (NACL, Network Access Contorl List)
https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-network-acls.html#default-network-acl
- 보안 그룹과 유사하다.
>
> VPC에서는 삭제할 수 없는 기본 NACL이 있다.
- 서브넷에 연결되어 해당 서브넷과 송수신되는 트래픽을 제어한다.
=> NACL >>>> ENI
- 상태 비저장을 띈다
> NACL을 통과한 연결 상태를 추척하지 않는다.
> 모든 인바운드/아웃바운드 트래픽의 허용 규칙을 별도로 작성해야 한다.
- NACL의 경우 규칙을 적용할 때 규칙 번호의 오름차순으로 처리하고, 만족하는 규칙이 있을 경우 해당 규칙을 제외한 나머지는 무시한다.
=> 순서에 영향을 받음!
- 보안 그룹 VS NACL
| 항목 | 보안 그룹 | 네트워크 ACL |
| 운영 레벨 | 인스턴스 | 서브넷 |
| 적용범위 | 인스턴스와 연결된 경우에만 인스턴스에 적용 | 연결된 서브넷에 배포된 모든 인스턴스에 적용 (보안 그룹 규칙이 지나치게 허용적일 경우 추가 보안 계층을 제공) |
| 규칙 지원 | 허용 규칙만 지원 | 허용 및 거부 규칙 지원 |
| 트래픽 허용 규칙 순서 종속성 | 트래픽 허용 여부를 결정하기 전에 모든 규칙을 평가 | |
| 상태 저장 |
VPC 생성 -> EC2 인스턴스 생성(웹 서버 설치) -> 인스턴스로 22, 80 포트 접근
1. VPC 생성
2. 인터넷 게이트웨이 생성
- VPC를 인터넷에 연결하기 위해 생성
3. 서브넷 생성
4. 라우팅 테이블 생성하고 서브넷에 연결
5. 라우팅 테이블에 인터넷 게이트웨이로의 라우팅을 추가
=> 퍼블릭 라우팅 테이블로 변경
6. NACL 확인
7. SSH Client 프로그램(Bitvise)을 이용하여 EC2 인스턴스로 접속
8. 내 PC에서 EC2 인스턴스의 80포트로 요청
=> 연결되지 않음
=> NACL에서는 모든 포트 접근을 허용하고 있으나 보안그룹에서 80포트 접근을 허용하고 있지 않음.
=> 따라서 보안그룹에서 80포트로 들어오는 요청을 허용하는 규칙을 생성
9. NACL에 80 포트로 들어오는 트래픽을 거부하는 규칙을 10번으로 추가
=> 이 경우 NACL에서 80포트로 들어오는 요청이 거부되어 인스턴스에 접근이 불가하게 된다.
10. NACL에 80포트로 들어오는 트래픽을 허가하는 규칙을 20번으로 추가
=> 이 또한 접근이 불가하다.
=> 오름차순으로 규칙을 적용하므로 10번에서 접근을 거부하였기 떄문에 20번 규칙은 적용되지 않는다.
11. NACL에 80 포트로 들어오는 트래픽을 허가하는 규칙을 5번으로 추가
=> 인바운드/아웃바운드 규칙이 오름차순으로 적용되므로 5번이 가장 먼저 적용되기 때문에 다음 순번의 규칙은 무시된다.
12. 리소스 정리 (중요!)
1) EC2 종료
Amazon EC2 (Elastic Compute Cloud)
https://aws.amazon.com/ko/pm/ec2/
- 안전하고 크기 조정이 가능한 컴퓨팅 파워를 클라우드에서 제공하는 웹 서비스
- 안정적인 확장 가능한 인프라에 온디맨드로 엑세스한다.
- 99.99%의 가용성을 지원하는 서비스 수준 계약 (SLA, Service Level Agreement)이다.
AMI (Amazon Machine Image)
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/AMIs.html
-
인스턴스 유형
https://aws.amazon.com/ko/ec2/instance-types
- 명명 규칙
https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html
EBS (Elastic Block Store) = 하드디스크
https://aws.amazon.com/ko/ebs/
-
EBS 스냅샷
https://aws.amazon.com/ko/ebs/snapshots/
-
탄력적 주소 (EIP, Elastic IP)
'Study > seSAC 금천 4기' 카테고리의 다른 글
| 클라우드_5일차_241010 (0) | 2024.10.14 |
|---|---|
| 클라우드_3일차_241007 (1) | 2024.10.11 |
| 클라우드_1일차_241001 (0) | 2024.10.08 |
| 컨테이너 Orchestration_3일차_240926 (3) | 2024.09.30 |
| 컨테이너 Orchestration_2일차_240925 (0) | 2024.09.30 |