[하나 디지털파워온] AWS 공인교육 필기 (3)

클라우드 서비스 | 클라우드 컴퓨팅 솔루션| Amazon Web Services

Amazon Web Services는 안정성이고 확장 가능하며 저렴한 클라우드 컴퓨팅 서비스를 제공합니다. 무료로 가입할 수 있으며 요금은 사용한 만큼 지불하면 됩니다.

aws.amazon.com

사용자 요청 패스에 따라서 비용 지불

버킷으로 데이터가 들어오는 것은 공짜

데이터를 꺼낼 때는 돈 지불 필요

스토리지 : 저장 용량에 대한 비용

요청 및 데이터 검색 : 요청에 대한 비용

Amazon S3 Intelligent-Tiering, 아카이브 액세스 계층 추가 | Amazon Web Services

AWS는 2년 전에 S3 Intelligent-Tiering을 출시하면서 데이터 액세스 패턴을 깊이 이해하지 못해도 S3를 활용할 수 있는 기능을 추가했습니다. 오늘, 거의 액세스하지 않는 객체를 자동으로 아카이브하는 S3 Intelligent-Tiering의 두 가지 새로운 최적화 기능을 출시합니다. 이러한 새로운 최적화 기능을 통해 예측할 수 없는 액세스 패턴이 있고 간혹 몇 달 동안 액세스하지 않는 객체를 아카이브하는 데 필요한 수동 […]

#aws.amazon.com

<Amazon S3 Glacier 스토리지 클래스의 이점>

추가 비용 내고 1-5분 정도 빨리 볼 수 있도록 가능

데이터 패턴을 잘 분석해서 효율적으로!

<Amazon S3 Transfer Acceleration>

더 빠르게 업로드 하는 방법

사용자와 가장 가까운 위치에 400개 엣지 로케이션 존재

본인 근무지와 가장 가까운 엣지 로케이션까지만

인터넷 통한 업로드보다 더 빠르게 가능

전세계적인 네트워크 가지고 있는 거의 유일무이한 아마존🖤

목적지가 멀리 떨어진 리전에도 빠르게 가능하다!

<공유 파일 시스템>

마운트해서 작업을 원할 때!

multi attach 작업이 있지만 제한적이다!

직접 서버에 마운트하는 것이 아니다!

NAS

<Amazon EFS>

NFSv4는 리눅스만 쓸 수 있다

<Amazon FSx>

윈도우용도 있고 등등.. 다양하게 사용 가능

<Amazon EFS 이점>

비용이 발생된다

목적을 잘 확인하고 그에 맞는 것을 선택해야 한다

<AWS DataSync>

옮겨진 데이터를 클라우드만 쓰는 것은 아니다

클라우드 구성 형태에 따라서

public cloud : AWs, GCP, Azure 등 모든 사용자가 쓸 수 있도록

private cloud : 우리 회사 기존에 서버가 많다. 그런 서버들로 자체적 클라우드를 만드는 것, 오픈 스탯, 회사 내부에서만, 직접 운영 및 관리를 해야 한다

hybrid cloud : 모든 것을 다 클라우드로 가는 것이 아니라 일부 서비스만 클라우드로, 일부는 유지, 클라우드에 종속되는 것을 두려워한다. 일단 데이터 옮겨두고, 온프레미스랑 클라우드 환경에서 데이터 유연하게 주고받을 수 있도록

조금 문제가 되는 것이 있다

*데이터가 너무 많으면 네트워크로 옮길 때 한 달이 넘게 걸릴 수도 있다

또는 보안상 인터넷 연결을 안할 수도 있다

<Storage Gateway 아키텍처>

유연하게 혼합된 형태를 쓸 수 있다

https://docs.aws.amazon.com/ko_kr/filegateway/latest/files3/StorageGatewayConcepts.html

이미지 썸네일 삭제

Storage Gateway 작동 방식 (아키텍처) - AWSStorage Gateway

쿠키 기본 설정 선택 AWS는 사이트 및 서비스를 제공하는 데 필요한 필수 쿠키 및 그와 유사한 도구를 사용합니다. 성능 쿠키는 익명 통계를 수집하여 고객이 사이트를 어떻게 이용하는지 파악하고 개선할 수 있게 해줍니다. 필수 쿠키는 비활성화할 수 없지만 성능 쿠키는 ‘쿠키 사용자 지정’을 클릭하여 거부할 수 있습니다. 귀하가 동의하는 경우, AWS와 승인을 받은 서드 파티가 유용한 사이트 기능을 제공하고, 기본 설정을 저장하고, 관련 광고를 비롯한 관련 콘텐츠를 표시하는 데 쿠키를 사용하게 됩니다. 이러한 쿠키를 허용하지 않고 계속...

docs.aws.amazon.com

<AWS Snow 패밀리 서비스 모델>

https://www.youtube.com/watch?v=XEh62PeISPM

<관계형 데이터베이스 및 비관계형 데이터베이스>

우리한테 필요한 것은 무엇일까?

<알맞은 데이터베이스 선택>

관계형 : 엄격한 스키마 기준 필요, 케이블 만들고, 쿨러 정의, 데이터 타입 정의, 번호, 이름, 나이 등 중요, 그곳에 맞는 데이터를 행 단위로, 정형화된 데이터만 처리할 수 있다. 테이블에 어긋나는 것은 처리할 수 없다.

서버 용량 부족하면 해결할 수 있는 방법 2가지

서버 처리 능력 부족 -> 서버 늘리기!

이 한 개를 더 크게? 아니면 여러 개?

하나의 단일 서버를 더욱 크게!!

CPU, 메모리 등을 더욱 크게 = scale up(일반적인 경우)

똑같은 서버를 여러 개를 수평적으로 확장=사용자 구성을 분산처리=scale out

서버 안에 테이블이 모여 있어야 원활하게 가능

서버용량의 최대치는 정해져 있다 그 시점의 컴퓨팅 파워 존재

한 대가 처리하다 보니 과도한 요청은 처리되지 않음

데이터베이스의 용량이 부족하면 서버를 여러 개 만들어서 테이블을 통해서 각각 사용 계정을 골고루 분산 처리

• 훨씬 더 많은 요청들을 원활하게 처리 가능

파티션 : 조각조각 나눠서 분산처리!->빠른처리 가능

비관계형 : 스키마 고정X

센서 네트워크 빠르게 처리해야하는 경우에는 관계형이 감당 못할 수도 있다

"고려사항"

하나, 관계인지 비관계인지

둘, 우리가 직접 구축할 것인지, 아니면 더 쉽게 서비스로 제공받을건지

관리형 데이터 베이스 사용하면 회사 인건비가 줄어들 수 있다

인력과 관리 시간을 줄임 + 사용함으로서 조직 차원 비용 절감

*각각의 차이점 알아두기

*하나부터 끝까지 다 직접 관리하는 것이 비관리형 서비스

*aws에서 대신해주는 것이 관리형 데이터베이스

관리형데이터베이스를 사용할 경우 개발자들은 애플리케이션최적화만 관리하면 된다.

• 공식 aws.amazon. 에서 공식 설명문서(docu) 확인 가능! 설명서 탭에 들어가면 볼 수 있음

일단 코드를 쭉 구성한 후, 추가적인 수정 등을 진행하는 것이 AWS Cloud Formation에 있어 유리하다.

• 코드형 인프라(IaC) : Infra as Code [ 템플릿으로 생각하면 좋다 ] - 상당한 장점을 얻게 된다.
• 언제든 필요할 때마다 필요한 코드를 찍어낼 수 있다는 것(VPC-서브넷-EC2 인스턴스 보안그룹)
• VPC(.yaml 파일로 이미 만들어둔 코드) ; 데베 & 서버까지 코드(Atom 사용)로 작성할 수 있다.

<재사용성>

• 리전에 문제가 있을 때 코드를 가지고 있으면 빠르게 가능하다
• 인프라 많이 쓰는 경우 : (온프레미스같은 경우 실제 환경과 동일한 테스트 환경을 만들 수 없다(돈이 많이 들기 때문)) 코드를 테스트해서 찍어내고 지우면 된다(동일 환경 반복적으로 빠르고 안전하게 만들고 지우고를 반복 가능)
• 수동으로 하나씩 변경하는 것이 아니라 코드를 바꾼다

<CloudFormation 이해>

• 인프라를 코드로 관리하게 되면 애플리케이션 소스 코드와 동일하게 버전 관리가 가능하다→구성바꿨을 때 꼬인다면 이전 깃허브에 나와있기 때문에 금방 돌려놓을 수 있다. 꼬이게 되면 서비스가 중단되는 경우도 있으니까 이전 코드로 쉽게 가능
• cloud formation : 검색해서 들어가게 되면 템플릿으로 생성한다는 것을 볼 수 있다. 준비된 템플릿/샘플 템플릿 사용 중에서 선택 가능

<스택>

• 템플릿=코드
• 템플릿으로 찍어낸 자원들의 물리적 그룹=스택
• Amazon VPC, Amazon DB/RDS 등등의 종류가 포함되어 있으며, 실행 중인 스택의 리소스 및 설정 업데이트 가능

<인프라 도구>

• 코드로 네트워크나 서버를 만들기 위해서는 인프라에 대한 이해 필요

<AWS Elastic Beanstalk>

• 파이썬, 자바 등으로 어플리케이션 코드만 구현 + 코드가 동작하는 런타임 지원(환경 선택) = 일라스틱이 자동으로 인프라 구현(인프라 신경쓸 필요가 없다)
• 편리하지만 재현할 수 있는 부분은 제한적이다
• 세부적 디테일 변경은 불가능

<AWS 솔루션 라이브러리>

• 공개 라이브러리 사용 가능

<AWS CDK>

• 코드 문법 따로 공부 해야 하나?
• 개발자와 친숙한 언어를 통해서 템플릿을 만들 수 있다(친숙한 언어로서 작성하는 것도 가능하다)
• 사용자친화적으로 인프라 구축 가능

<AWS Systems Manager>

• 자동화로 수많은 서버들을 만듦
• 인스턴스가 몇백개가 넘어가면 패치, 업데이트, 구성할 때 힘들다
• 중앙에서 명렁을 내거나 업데이트하거나 패치할 수 있다
• 공용 관리에 최적화된 서비스(대규모 서비스 운용 편리)
• 온프레미스 : 에이전트 설치하면 중앙 통제 가능

💓클라우드 인프라 간단하게 구축하는 방법 : 매번 반복하지 말고 코드로 만들어서!

<느슨한 결합>

• 안티 패턴 : 장애가 있을 때마다 큰 것들을 요구(유연하지 않다)
• 모범 사례 : 강력한 결합을 끊어버리고 ELB(Elastic load balancing) 사용
• ASG ; Auto Server Group

<마이크로서비스>

• 모놀리식 포럼 사이트에서 사용자, 주제, 메시지 기능 존재. 이 세 개의 코드가 다 묶여있다. 사용자 요구에 따라 기능을 추가해야 한다. 실제 유저들이 주제라는 서비스 기능을 조금 더 변경을 요구하고 있다. 근데 다 영향받아서 다 바꿔야 한다. 복잡한 서비스의 경우 한 가지만 바뀌어도 엄청난 일이다. 몇 개월 단위로 큰 단위의 배포만 가능. 배포가 됐을 때 사용자들의 만족도가 높아야 좋은데 그렇지 않으면 또 바꿔야 한다. 사용자 요구를 바로바로!
• 사용자 요구사항이 빠르게 바뀌다 보니 각각을 묶여있지 않은 독립된 작은 단위 서비스를 만들고 서로필요할 때마다 api로 요청
• 독립 언어, 독립된 실행 환경 가능. api만 잘 정의하면 된다
• 컨테이너도 기본적으로는 가상화인데, 특징이 있다면 OS Level Virtualization 이라는 것. 우리가 쓴 코드 + 런타임 엔진 + 구성 + 종속성(환경일관성)을 한데 모았다고 생각하면 된다.

<컨테이너>

• OS Level Virtualizaiton
• 이 코드를 넣고 동작할 모든 구성과 종속성을 너고 포장해버림
• 이 자체가 어떤 독립된 실행 환경
• 상대적으로 가볍고 편리함
• Container Image
• 똑같은 컨테이너를 반복해서 찍어낼 수 있다

<가상화 및 추상화 수준> 클라우드 아닌 온프레미스

• 하드웨어 레벨 가상화
• 가상머신(virtualization)- H/W 레벨베어메탈서버는 물리적인 서버. 하나의 가상머신 자체가 서버를 구성하며 하나의 VM 안에 게스ㅌ
• 컨테이너는 OS 레벨.
• 컨테이너 : 종속성 다 가지고 있음, 별도 gust os 없음(훨씬 가벼움, 빠른 다운로드), 원래 os 위에 도커 설치, 부팅도 몇초면 됨, 클라우드가 아니라 온프레미스 물리적 환경에서만 사용 가능

<AWS의 컨테이너>

• EC2 인스턴스의 가상머신 안에 직접 도커 설치해서 컨테이너 운영도 가능
• VM 안에 도커 설치해서 컨테이너 운영도 가능 : 성능 저하? not that much
• 컨테이너가 별로 없으면 관리 가능하지만 대규모 환경의 경우 마이크로서비스가 정말 많다. 하나하나 컨테이너 직접 관리는 현실적으로 불가능. 어떤 인스턴스에 올릴지 다 고려해야 한다. 부족하면 늘려야 한다. 장애 있는지 체크하고 옮겨야 한다. 배포, 관리 자동화해주는 서비스 존재. 컨테이너가 너무 많으면 컨테이너 대체. 서버 부족하면 더 만들어주고. 장애 있으면 알아서 배치 = 오케스트레이션 도구(Kubernetes)

<AWS에서 컨테이너 실행>

• Container Image 저장소 역할

<Amazon ECR>

• 코드의 연결을 다 끊어버리고 이미지 만들어서 ECR에 저장하고 버전 관리 가능
• 사용자들이 해당 컨테이너가 몇 개 필요하다고 ECS에 → 적당한 인스턴스에 알아서 배포

<Amazon EKS 솔루션>

<Amazon ECS 오케스트레이션> - Amazon ECS, EKS 2종류

호스팅 - Amazon Fargate /EC2 2종류

모듈 10 : 네트워킹 2

규모가 큰 조직은 VPC가 많다, 각각 네트워크 별로 분리

• 조직에서 사용하는 VPC는 ? - 몇 개일까요
• Virtual Private Cloud(VPC)는 사용자의 AWS 계정 전용 가상 네트워크. VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있고, VPC의 IP 주소 범위를 지정하고 서브넷과 게이트웨이를 추가하고 보안 그룹을 연결한다

<게이트웨이 VPC 엔드포인트>

<인터페이스 VPC 엔드포인트>

<VPC 피어링>

• 먼저 피어링을 만들고 각각의 VPC의 라우팅 탭에 경로 설정.
• 반대편에도 목적지 설정 후 보내기
• 같은계정, 같은리전, 다른계정, 다른리전 다 연결 가능함
• 연결하고자 하는 vpc ip가 서로 같으면 안됨
•  

• 다른 vpc를 경유해서 갈 수 없다
• b,c 연결하려면 직접 연결해야지만 통신이 가능하다

<VPC 피어링의 이점>

• 인터넷 사용하지 않음
• 안전하게 aws 내부 네트워크로 이중화 고민 없이 쉽게 사용할 수 있음

<예: 공유 서비스에 대한 VPC 피어링>

• 따로따로 만들면 다 돈이 든다, 관리 비용도 많이 든다
• 그럴바에 공유 서비스를 한 곳에 모아놓고, vpc 피어링으로 내부적 안전하게 사용하도록 만들기→하나 자원으로 사용→비용, 관리부담 줄일 수 있다
• vpc 피어링 : 자체 연결!
• aws 내부 네트워크로! 안전하게 연결!

<예: 풀 메시 VPC 피어링>

•  

• vpc 많아지면 연결이 너무 어렵다 차라리 중앙에서 모아서 하는 게 낫지 않겠어?→transit gateway

<AWS Site-to-Site VPN>

• Hybrid Cloud : 고객이 가장 많이 사용하는 환경
• 모든 서비스 자원들을 클라우드를 옮기자니 종속되는 것이 위험하다. 두 개를 같이 쓴느 것! 온프레미스의 물리적 데이터 센터와 클라우드를 안전하게 연결해야 한다(주고받아야 하기 때문에) 인터넷으로 그대로 보내면 보안상 좋지 않다.
• encryption / hash(무결성 체크) / authentication(인증)
• 인증된 장비끼리 암호화, 변조됐는지 확인
• 고객들의 물리적 데이터 센터 안에는 vpn 장비가 있어야 한다→커스터머 게이트웨이
• 실제 방화벽 장비, vpn 장비→라우터 장비
• virtual private gateway : 인터넷 연결 후 양쪽에서 보안정책 정해서 보안화된 것 안전하게 주고받음
• 속도 1.25가 최대치

<AWS Direct Connect(DX)>

• 리전마다 DX 로케이션이 존재. 서울에는 2개.
• 회사 보안 거버넌스 때문에 인터넷 허용되지 않을 경우 vpn(속도 제한 있음) 사용해야 한다
• 자체적 사설 네트워크로 이루어져 있다

<AWS VPN 또는 Direct Connect 중 선택>

<AWS Transit Gateway>

• 완전관리형
• 안전하게 관리하고 있다
• 최개 5000개 통합할 수 있다(중앙화)
• 이전까지 상당히 제한→유연해짐

<transit gateway 구성 요소>

• 확장도 가능
•  

<서버리스란 무엇입니까?>

• EC2 인스턴스와 다르게 배포할 수 없다, 이중화X, 코드만 돌려놓으면 안전하게 관리해주고 알아서 용량도 관리
• 시간만 잘라서 그만큼의 비용만 지불

<AWS 서버리스 포트폴리오>

• 우리 서비스 현관문처럼 사용자 api 요청 받아서 특정 서비스 전달
• sQs : quick service

<API Gateway 기능>

• 프론트 엔드 역할
• 연동 서비스 : AWS WAF(Web Application FW) - 7계층 디도스 공격 판단, 차단시킬 수 있다, 보안 서비스와 연동
• HTML?CSS/JavaScript로 작성(특히 자바스크립트)

<Amazon Simple Queue Service (Amazon SQS)>

• 완전관리형 : 용량은 신경쓸 필요가 없다
• 메시지가 처리 안되고 누락될 수 있는데, 보관 가능(대량 메시지 유입되는 경우에도 안전하게 처리 가능)

<Amazon SQS 사용 사례>

• 대기열 종류 2가지
  • 스탠더드 : 최대한 순서대로 처리, 최대한 중복 처리하지 않고 1번만 하기 위해 노력, 중복 처리가 될 수도 있다, 빠르게, 병렬로 처리, 중복 처리될 가능성이 있다..
  • FIFO : 정확히 1번만! 순서 지킴! 대신 제한된 api. 느릴 수도 있다

<Amazon SQS 대기열 구성 최적화>

• 메시지 끝났다고 말해야 처리할 수 있다
• 가시성 제한 : 처리 실패되면 풀어서 다른 사람이 꺼낼 수 있다

<Amazon SNS>

• 똑같은 메시지를 1:n으로 푸쉬하는 서비스
• 구독자 이용은 이메일, 문자, 람다, kinesis data 등

<Kinesis Data Streams 개요>

• 샤드에 다 담겨 있다
• 처리 서버가 가지고 와서 전처리 하고 나서

<Kinesis Data Firehose 개요>

• 특정 서비스로 연결 가능
• 데이터 분석할 때 많이 사용

<Step Functions>

• 람다 묶어 쓰기, 람다 조직화, 람다 연속처리하거나 병렬 처리하거나 리트라이 하거나 분개하거나 워크플로우 짜기. 람다 순차적으로 ,분기적으로 할 수 있도록, 여러 처리 가능하도록

<Step Functions 상태 머신>

• 상태 정의, 상태에 맞는 람다 넣어두기
• 제이선으로 만들면 된다

<복잡한 분산 워크플로의 오케스트레이션>

• 단계별로 처리
• 여러 개 람다를 조직화해서

<엣지의 AWS 클라우드>

• 리전 안에 엣지 있음
• 사용자들이 리전까지 가지 않아도 엣지 로케이션, 로컬 존스를 통해서 캐싱된 데이터 저장
• 온프레미스 환경과 클라우드 환경 같이이용 : 하이브리드
• 아웃포스트 : (원래는 고객이 직접 구매한 것) 물리적 장비조차도 임대해주는 것. AWS 관리 콘솔로 운영/관리할 수 있도록! 통합된 관리!! but expensive
• 고객들 근처에로 다가가고 있다:) 빠르게 서비스 이용하고 접근할 수 있는 환경!

<엣지 서비스 아키텍처>

• 쉴드, 라우트(DNS), 와프, 클라우드프론트(CDN) : 리전에 있지 않고 엣지 로케이션에 있다. 사용자들과 가깝다. 빨리 접근할 수 있는 서비스 제공
• 물리적 환경에 아웃포스트 랙 이용해서 고객들이 원하는 자원이 다 들어있다
• 전 세계 400 이상 서비스들이 배치, 사용자들이 본인과 가장 가까운 곳에 인스턴트 있음

<라우트 53> - 확장 가능한 DNS 및 도메인 이름 등록

• dns 서버를 서비스로 제공
• 리눅스나 윈도우 서버에 메인서비스를 올림
• 이중화 용량을 안정적으로
• 도메인 이름을 IP 주소로 확인,등록 또는 이전
• 지연시간 및 상태 확인, 기타 기준 등에 따라 요청을 라우팅한다.

회사들마다 도메인 : 전세계적으로 고유해야 한다. → 비슷한 도메인 추천받음

<라우팅 정책>

• 똑같아서 어디로 가든 상관 없음
• 단순 : 사용자가 따따따 아이피가 뭐예요? 받아서 한 번은 1번 한 번은 2번(순차적으로, 단순정책, simple)
• 장애 조치 : 문제 발생하면 감지하고 사용자에게 정상적인 사이트로 우회하게 만든다, 여러 리전에 멀티 리전환경을 만들 수 있다
• 지리 위치 : 사용자에게 가까운 쪽으로 접근하게 만든다, 똑같은 주소를 물어봐도 다른 서버 알려줄 수 있다
• 지리 근접 라우팅 : 지역적 영향 경계를 우리가 바꿀 수 있다. 지역적 영향 인위적 조작 가능
•  

• 지연 시간 기반 라우팅 : 사용자들이 가장 빨리 접근할 수 있게. 사용자가 요청했을 때 사용자로부터 가장 빨리 접근할 수 있는 서버로 접근할 수 있도록. 응답이 얼마나 걸리는지 체크한 후 응답 시간이 짧은 쪽으로
• 다중값 응답 라우팅 : 다 응답, 사용자가 한 개를 선택하도록. 문제가 있는 것은 표기되기 때문에 정상적인 서버로 요청하게 만든다.
• 가중치 기반 라우팅 : 가중치 90:10(비율 선택 가능) 가중치 쓰는 경우는 새롭게 서비스 배포하고 나서 시뉵 배포도니 서비스의 안정성을 검증하기 전까지 한 번에 넘길 수 없다. 기존 서비스로 트레픽을 처리하고 새 환경은 일부 사용자만 가서 문제 없을 때 비중 넘기기. 이전 버전과 신규 버전이 있을 때 문제가 있는 애들 보내보고.. 안정성 체크 가중치 기반으로 몇 대 몇으로 응답하게 만들겠다!
• 다양한 정책을 통해서 처리할 수 있다

<콘텐츠 전송 네트워크>

• 사용자가 더 빨리 캐싱된 데이터에 접근하게 만든다
• 본인과 가장 가까운 엣지까지만 인터넷 접근. 캐싱이 되지 않아도 고성능 네트워크로 요청하고 빨리 가지고와서 캐싱한다

<엣지 캐싱>

• 처음부터 캐싱이 되어있지 않음. 일단 사용자가 먼저 엣지 요청. 캐싱된 것 있으면 꺼내옴. 없으면 네트워크 이용해서 데이터 꺼내옴. 나중에는 캐싱된 것을 바로 꺼낼 수 있도록

<DDos 공격>

• 일반 사용자 피씨에 에이전트 숨겨놓음. 사용자 컴퓨터에 악성코드 심어둠.

<OSI 계층 공격>

• 에플리케이션 계층 공격
• 티시피라고 하는 4계층 프로토콜. 일부러 서버가 응답해도 반응이 없게 만들어서 답을 못하게 만든다. 서비스 프로세스를 대상으로 서버 자체에서 처리안되게.
• 공격 방어 서비스가 바로 = AWS Shield
• standard 무료, 이미 제공받고 있음
• 3계층, 4계층, 디도스 공격에 대해 이미 방어하고 있음.
• 어드벤스드 서비스 : 7계층 공격도 방어할 수 있다, 추가

<AWS WAF>

• web application firewall
• web hacking attack, l7 ddos 공격 방어 가능
• 연결할 수 있는 서비스가 제한되어 있음
• api 가능, 클라우드프론트 가능, ald, appsync 가능, ACL 불가능!

<엑세스 제어 구성 요소>

• 와프가 공격 막다 보면 로그 엄청 막힘
• 다른 분석도구로 처리하게 할 수 있다

<ACL Firewall Manager>

• 와프 외에도 보안서비스들을 중앙에서 관리하는 것!
• 우리 회사 계정이 여러 개일 수 있다 회사가 크면 팀별로 계정이 다르다. 전사적 보안정책은 같다. 여러 계정에 한 번에 똑같은 정책을 넣었을 때. 따로 설정하는 것이 아니라 계정 묶어서. 전사적 보안정책!

<DDoS 복원력이 뛰어난 참조 아키텍처>

• 실제 서버 자원들 공유X 필터링해서 정상적으로 들어오는 것들만 보안그룹을 통과할 수 있도록

<AWS Outposts 패밀리>

• 물리적 환경 없이 똑같이 관리 가능

<outposts의 aws 리소스>

• 범위 안에서만 사용 가능

리전을 넘어서 최대한 고객 근처로 가는 것이 목표 :)