AWS H01_Lesson01

목차

1. EC2

    1.1 Linux AMI 가상화 유형

    1.2 배치 그룹

    1.3 Domain Join Directory

    1.4 Tenancy

    1.5 AWS Nitro Enclave

 

2. S3

    2.1 Public Access

    2.2 ACL

    2.3 버킷 정책

EC2

---

Linux AMI 가상화 유형

인스턴스를 생성할 때 사용했던 AMI 이미지는 루트 볼륨 디바이스에 저장

AMI는 PV / HVM 두 가지 유형의 가상화를 사용한다.

주요 차이점은 부팅 방법, 더 나은 성능을 위해 HW 확장이 가능한지 차이.

	HVM(하드웨어 가상 머신)	PV(반가상화)
설명	이미지 루트 블록 디바이스의 MBR을 실행하여 가상화된 HW, Boot Set 제공	PV-GRUB이라는 특수 부트 로더를 통해 부팅 현재는 대부분 HVM 사용
HW 확장	O	X
지원 인스턴스 유형	모든 최신 유형 지원	전 세대 인스턴스 유형만 지원
지원 리전	모든 리전	9개만

 

배치 그룹

EC2 인스턴스를 배치하는 방법

-> 성능 향상, 장애 발생 대비 등의 효과

 

1. 클러스터 배치그룹

인접한 EC2 인스턴스를 고속 네트워크로 묶어서 사용.

(네트워크 지연 시간 짧음, HPC 등에 적합)

 

2. 파티션 배치그룹

HW를 파티션으로 분리

파티션끼리는 HW를 공유하지 않고 서로 다른 하드웨어를 사용하기 때문에

파티션 내 한 HW에서 장애 발생 시에도 다른 HW에 영향이 없음. 

(Hadoop 등 bigData 분석에 활용)

 

 

3. 분산형 배치그룹

같은 서버랙의 서버를 그룹화

분산그룹 내 서버는 다른 랙에 있으므로 기존 랙에 장애 발생 시에도 안전

고가용성을 확보해야 하는 중요한 애플리케이션에 사용

 

Domain Join Directory

AWS 클라우드 상에 동작하는 Windows/Linux 인스턴스를 중앙에서 관리하는 역할

(온프레미스 내 Active Directory와 동일한 개념)

AWS Managed AD는 실제 Microsoft AD에 구축되므로 기존 AD의 데이터를 동기화하거나 복제할 필요가 없다.

그러나 해당 기능을 사용하려면 Directory와 관련된 IAM 역할을 부여해야 한다.

< 출처 : docs.aws.amazon.com >

 

테넌시

Tenancy는 누가 자원의 소유자인지 결정하는 역할.

 

공유됨(Default Tenancy) 

여러 AWS 계정이 동일한 물리적 하드웨어를 공유할 수 있음

 

전용 인스턴스(Dedicated Instance) 

다른 AWS 계정의 인스턴스로부터 물리적으로 격리되며, 동일한 AWS 계정의 다른 인스턴스 중 전용 인스턴스가 아닌 인스턴스와 하드웨어 공유 가능

 

전용 호스트(Dedicated Host)

EC2 인스턴스에 대해 실제 물리적 서버를 지정할 수 있는 것

 

전용 인스턴스 vs 전용 호스트

전용 인스턴스	전용 호스트
Amazon이 결정한 전용 하드웨어에 인스턴스가 배치 (다른 AWS 고객의 인스턴스와 물리적 서버를 공유하지 않을 것을 보장)	고객이 원하는 물리적 서버를 지정하여 인스턴스를 배치하는 것

 

AWS Nitro Enclave

많은 제약을 통해 보안을 강화한 개별 가상 머신

 

출시 이유

EC2는 다양한 데이터 처리에 사용되는데 이 과정에서 민감한 데이터가 복호화될 수 있다.

그래서 개별 VPC를 설정하고, 연결을 제한하고, 액세스를 제한하는 등의 작업을 수행하는데 이를 관리하려면

운영 리소스가 필요하고 작업도 복잡해질 수 있다.

 

특징

영구 스토리지 X, 대화형 액세스 X, 외부 네트워킹 X

 

S3

---

 

Public Access

AWS에서는 모든 퍼블릭 액세스의 차단을 권장하며 '모든 퍼블릭 액세스 차단' 하위로 4가지 옵션이 제공된다.

각각의 설정은 독립적이므로 허용하고자 하는 설정은 체크를 해제해준다.

 

'모든 퍼블릭 액세스 차단' 설정을 하면 s3에 업로드된 객체에 접근 시 Access Denied가 표시된다.

 

ACL

Public Access가 버킷에 대한 액세스 권한을 모두에게 줄 건지, 임의의 사용자에게 줄 건지 결정짓는 역할이었다면,

ACL은 해당 사용자가 버킷/객체에 대한 권한을 얼마만큼 허용할 것인지를 결정짓는다.(Read or Write)

버킷에 대한 ACL, 객체에 대한 ACL을 각각 설정할 수 있는데, Public Access 설정값에 따라 위 옵션은 무시될 수 있다.

 

예를 들어,

현재 아래와 같이 '모든 퍼블릭 액세스 차단' 비활성화가 돼있다면

 

ACL 설정의 영향을 받지 않는다.

 

But, '객체' 별 ACL은 영향을 받음(객체의 읽기 권한이 없다면 Access Denied 표시)

 

버킷 정책

버킷/객체를 접근하는 사용자 별로 각각 권한을 부여하기 위해 사용하는 정책이다.

단순히 Read/Write가 아니라 버킷/객체에 대한 CRUD 권한을 정의할 수 있다.

{
  "Id": "Policy1636532476766",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1636532474746",
      "Action": [
        "s3:CreateBucket"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::ljj-bucket",
      "Principal": "*"
    }
  ]
}

 

+++

아래는 ljj-bucket 하위 리소스에 대한 접근 권한을 모두 allow 해주는 버킷 정책이다.

ACL - 비활성화 하면 ACL을 통해 버킷을 Control 하겠다.

버킷정책 - 비활성화 하면 버킷정책을 통해 버킷을 Control 하겠다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AddPerm",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::ljj-bucket/*"
        }
    ]
}