AWS Firewall Manager

AWS WAF 및 VPC 보안 그룹의 관리 및 유지 관리 태스크를 단순화합니다. WAF 방화벽 규칙, Shield 보호 및 VPC 보안 그룹을 한 번만 설정하면 됩니다. 새로운 리소스를 추가하는 경우에도 서비스가 계정과 리소스에 규칙과 보호를 자동으로 적용합니다. Firewall Manager에서는 다음과 같은 작업을 수행할 수 있습니다.

• 여러 애플리케이션과 계정에서 간편하게 규칙 관리
• 자동으로 새 계정 검색 및 규정 미준수 이벤트 수정
• AWS Marketplace에서 WAF 규칙 배포
• 모든 계정에서 신속하게 공격에 대응

Firewall Manager를 사용하는 경우, 새로운 애플리케이션이 생성될 때 새로운 애플리케이션 및 리소스가 처음부터 공통 보안 규칙 세트를 준수하도록 할 수 있습니다. 이를 통해 단일 서비스를 통해 방화벽 규칙을 수립하고, 보안 정책을 생성하며, 전체 AWS 인프라에 걸쳐 일관된 계층형 방식으로 이를 적용할 수 있게 됩니다.

이 서비스를 사용하려면 전체 기능을 갖춘 AWS Organizations를 활성화하고, AWS Config를 사용하고, Firewall Manger 관리자로 할당된 사용자가 있어야 하는 세가지 사전 조건이 있습니다.

사용 예시

사용 사례

AWS 클라우드에서 실행하는 애플리케이션 수가 증가함에 따라 대규모로 규정 준수를 관리하는 방식을 숙지해야 합니다. 애플리케이션 수가 늘어나면 발생하는 몇 가지 문제는 다음과 같습니다.

• 계정 및 리소스 수가 많아짐 - 모든 계정 및 리소스에서 중앙 집중식으로 보안 정책을 관리하기 어려워집니다.
• 지속적으로 새 앱이 생성됨 - 모든 앱이 첫날에 일관되게 보호되는지 확인하는 것은 어렵습니다.
• 조직 전체 위협에 대한 가시성 - 조직 전체의 위협을 모니터링하고 대응할 수 있는 단일 장소가 없습니다.

AWS Firewall Manger를 사용해 환경 내의 클라우드 보안 및 모니터링 범위를 확장할 수 있습니다.

DDoS 복원력

위 다이어그램에서 AWS Shiled 및 WAF는 아키텍처의 엣지에 배치되고 문지기 역할을 하여 트래픽을 허용 또는 거부합니다. Shield는 일반적인 3 계층 및 4 계층 인프라 공격으로부터 인프라를 보호합니다. WAF는 7 계층인 애플리케이션 계층을 보호합니다.

Route 53, CloudFront 등의 서비스를 AWS 엣지 로케이션에서 사용할 수 있는 서비스를 사용하면 엣지 로케이션의 글로벌 네트워크를 활용할 수 있습니다. 여러 엣지 로케잇녀을 사용하는 경우 애플리케이션에 더 큰 내결함성과 대량의 트래픽 관리를 위한 향상된 스케일링 기능을 제공할 수 있습니다.

기존 데이터 센터 환경에서는 인프라 계층 DDoS 공격을 완화할 수 있습니다. 용량 오버프로비저닝, DDoS 완화 시스템 배포, DDoS 완화 서비스를 통한 트래픽 스크러빙 등의 기술을 사용할 수 있습니다. AWS에서 DDoS 완화 기능은 자동으로 제공됩니다. 이러한 기능을 가잘 잘 활용하는 아키텍처를 선택하면 애플리케이션의 DDoS 복원력을 최적화할 수 있으며, 과도한 트래픽에 맞게 아키텍처 크기를 조정할 수 있습니다.

적용 모범 사례

AWS WAF

WAF는 일반적인 웹 악용과 봇으로부터 웹 애플리케이션이나 API를 보호하는 데 도움이 되는 웹 애플리케이션 방화벽입니다. AWS WAF에서는 트래픽이 애플리케이션에 수신되는 방식을 제 어할 수 있습니다. SQL 명령어 삽입(SQLi) 또는 크로스 사이트 스크립팅(XSS)과 같은 일반적인 공격 패턴을 차단하고 봇 트래픽을 제어하는 보안 규칙을 생성하면 됩니다. 호환 AWS 서비스로 전달되는 HTTP(S)요청도 모니터링할 수 있습니다.

트래픽은 웹 액세스 제어 목록(웹 ACL)을 기준으로 평가된 후 대상 위치로 전송됩니다. 한 번도 거부되지 않고 웹 ACL을 모두 통과하는 트래픽은 대상 위치 AWS 서비스로 전송됩니다.

상세

액세스 제어 구성 요소

WAF를 구성하기 전에 AWS 리소스에 대한 액세스를 제어하는 데 사용되는 구성 요소를 이해해야 합니다. 구성 요소는 다음과 같습니다.

• 웹 ACL
  웹 ACL을 사용하여 AWS 리소스 집합을 보호합니다. 규칙을 추가하여 웹 ACL을 생성하고 보호 전략을 정의합니다.
• 규칙
  규칙에서는 웹 요청을 검사하기 위한 기준을 정의하고 이 기준과 일치하는 요청을 처리하는 방법을 지정합니다.
• 규칙 그룹
  규칙은 개별적으로 사용하거나 재사용 가능한 규칙 그룹에서 사용할 수 있습니다. AWS WAF용 AWS 관리형 규칙 및 AWS Marketplace 판매자는 사용할 관리형 규칙 그룹을 제공합니다. 사용자 고유의 규칙 그룹을 정의할 수도 있습니다.
• 규칙 문
  AWS WAF에서 웹 요청을 검사하는 방법을 지시하는 규칙의 일부입니다. AWS WAF가 웹 요청이 스테이트먼트와 일치한다고 표현합니다.
• IP 집합
  규칙 문에서 함께 사용할 정규 표현식 모음입니다. 정규식 패턴 집합은 AWS 리소스입니다.
• 정규식 패턴 집합
  규칙 문에서 함께 사용할 정규 표현식 모음입니다. 정규식 패턴 집합은 AWS 리소스입니다.
• 모니터링 및 로깅
  CloudWatch를 사용하여 웹 요청, 웹 ACL 및 규칙을 모니터링할 수 있습니다. 로깅을 활성화하여 웹 ACL에서 분석한 트래픽에 대한 자세한 정보를 얻을 수도 있습니다. 로그를 전송할 위치를 CloudWatch Logs, S3, Kinesis Data Firehose 중에서 선택할 수 있습니다.

ACL 규칙 구문을 사용하는 트래픽 제어

규칙 문은 웹 요청을 검사하는 방법을 AWS WAF에 제시하는 규칙의 일부입니다. AWS WAF가 웹 요청에서 검사 기준을 찾으면 웹 요청이 스테이트먼트와 일치한다고 표현합니다.

모든 규칙 스테이트먼트는 다음을 수행합니다.

• 구문 유형에 따라 무엇을 어떻게 찾을지 지정합니다.
• 다른 구문을 포함할 수 있는 하나의 최상위 규칙 구문이 있습니다.

규칙 문은 매우 간단할 수 있습니다. 예를 들어 웹 요청을 확인할 출처 국가 집합을 제공하는 구문이 있을 수 있습니다. 규칙 문은 매우 복잡할 수도 있습니다. 예를 들어 다른 많은 구문을 논리적 AND, OR 및 NOT 구문과 결합한 고문이 있을 수 있습니다.

웹 ACL에는 규칙 그룹을 참조하는 규칙 구문이 포함될 수 있습니다. 콘솔에서 웹 ACL은 규칙 구문으로 표현되지 않습니다. 모든 웹 ACL에는 JSON 형식 표현이 있습니다. JSON에서 이러한 특수 유형의 규칙 구문을 볼 수 있습니다. 복잡한 규칙의 경우 JSON 편집기를 사용하여 웹 ACL을 관리합니다.

AWS WAF에서는 여러 규칙 문의 중첩을 지원합니다. 예를 들어 중첩을 사용하여 특정 지리적 영역에서 들어오는 요청의 속도를 제어합니다. 속도 기반 규칙을 사용하고 그 안에 지리적 일치를 중첩하여 범위를 좁힙니다.

상세

공격 방식

DDoS

DDoS는 다수의 오염된 시스템이 네트워크 또는 웹 애플리케이션과 같은 대상에 많은 양의 트래픽으로 대상에 서비스 장애를 일으키려고 시도하는 공격입니다. DDoS 공격은 정상적인 사용자의 서비스 액세스를 방해할 수 있으며 과도한 트래픽 볼륨으로 인해 시스템에 장애를 발생시킬 수 있습니다.

DDoS 공격의 일반적인 개념은 추가 호스트를 활용하여 대상에 대한 요청을 증대시켜 최대 용량에 도달하게 해 사용할 수 없게 만드는 것입니다.

OSI 계층 공격

DDoS 공격은 대개 공격 대상 Open Systems Interconnection(OSI) 모델 계층을 기준으로 격리할 수 있습니다. DDoS 공격은 네트워크(3계층), 전송(4 계층), 표현(6 계층) 및 애플리케이션(7 계층) 계층에서 가장 많이 나타납니다.

1. 인프라 계층 공격
   3 계층과 4 계층에 대한 공격은 일반적으로 계층 공격으로 분류됩니다. 가장 흔히 발생하는 DDoS 공격 유형인 인프라 계층 공격에는 동기화(SYN) 서비스 장애 등의 백터, 그리고 UDP(User Datagram Protocol) 패킷 서비스 장애와 같은 기타 반사 공격이 포함됩니다. 이러한 공격은 대개 볼륨이 상당히 크고, 네트워크 또는 애플리케이션 서버 용량에 과부하가 걸리게 하는 것을 목표로 합니다. 다행히 이러한 공격 유형은 징후가 분명하고 탐지하기가 좀 더 쉽습니다.
   
   
2. 애플리케이션 계층 공격
   공격자가 7 계층 공격을 사용해 애플리케이션 자체를 표적으로 삼기도 합니다. 이러한 공격에서는 SYN 플러드 인프라 공격과 유사하게 공격자가 애플리케이션의 특정 기능을 오버로드하여 애플리케이션이 적법한 사용자에게 응답하지 않거나 사용할 수 없게 만드려 시도합니다.

AWS Shield

AWS Shield는 AWS에서 실행되는 애플리케이션을 보호하는 관리형 DDoS 보호 서비스입니다. 이 서비스는 애플리케이션 가동 중지 및 지연 시간을 최소화하는 동적 탐지 및 자동 인라인 완화 기능을 제공합니다. AWS Shield에는 Shield  Standard와 Shield Advanced라는 두 가지 계층이 있습니다.

AWS Shield Standard에서는 흔히 발생하는 가장 일반적인 인프라(3, 4 계층) 공격 중 일부에 대한 보호 기능을 제공합니다. 이러한 공격에는 SYN/UDP flood 및 리플렉션 공격이 포함됩니다. Shield Standard는 악성 트래픽을 탐지하며 실시간 문제 완화 기능을 제공합니다. Shield Standard의 보호 기능 사용 시에는 추가 요금이 부과되지 않습니다.

애플리케이션을 DDoS 공격으로부터 더욱 철저히 보호해야 하는 경우에는 Shield Advanced를 사용할 수 있습니다. 이는 복잡한 대규모 DDoS 공격 탐지 및 완화 기능이 추가로 제공됩니다. 그리고 이러한 공격을 실시간에 가깝게 확인할 수 있으며, 웹 애플리케이션 방화벽인 AWS WAF와 통합도 가능합니다.

작동방식

콘텐츠 전송 네트워크

웹 트래픽이 지리적으로 분산된 경우 전체 인프라를 전 세계에 복제하는 것은 때떄로 불가능할 수도 있습니다. 또한 비용 효율적이지 않습니다. 콘텐츠 전송 네트워크(CDN)에서는 웹 콘텐츠의 캐시된 사본을 고객에게 제공하기 위해 엣지 로케이션의 글로벌 네트워크를 사용할 수 있습니다.

응답 시간을 줄이기 위해 CDN은 고객 또는 발신 요청 위치에 가장 가까운 엣지 로케이션을 사용합니다. 가장 가까운 엣지 로케이션 사용 시에는 웹 자산이 캐시에서 제공되므로 처리량이 크게 증가합니다. 동적 데이터의 경우, 다수의 CDN이 오리진 서버에서 데이터를 검색하도록 구성할 수 있습니다.

엣지 로케이션에 유지할 정도로 자주 액세스되지 않는 콘텐츠가 있을 때는 리전 엣지 캐시를 사용합니다. 이러한 콘텐츠는 리전 엣지 캐시를 사용합니다. 이러한 콘텐츠는 리전 내 엣지 캐시에 수집되므로 오리진 서버에 해당 콘텐츠를 검색할 필요가 없습니다.

CloudFront

CloudFront는 웹 사이트, API, 동영상 콘텐츠 또는 기타 웹 자산의 전송을 가속화하는 글로벌 CDN 서비스입니다. 다른 AWS 제품과 통합하여 사용하면 개발자와 기업이 사용자에게 쉽고 빠르게 콘텐츠를 전송할 수 있습니다. 최소 사용 약정이 없습니다.

CloudFront는 지연 시간 및 처리량을 위한 네트워크 계층 최적화와 함께 캐시 동작 최적화를 위한 강력한 유연성을 제공합니다. CDN은 기본적으로 멀티 티어 캐시를 제공합니다. 멀티 티어 캐시에 포함되어 있는 리전 엣지 캐시는 객체가 엣지에 아직 캐싱되어 있지 않은 경우 지연 시간을 단축하고 오리진 서버의 부하를 줄입니다.

CloudFront는 WebSocket 프로토콜을 통한 실시간 양방향 통신을 지원합니다. 이 영구 연결을 통해 클라이언트와 서버가 반복적인 연결로 인해 오버헤드 없이 서로 실시간 데이터를 전송할 수 있습니다. 이는 특히 채팅, 공동 작업, 게임, 금융 거래 같은 통신 애플리케이션에 유용합니다.

이처럼 CloudFront에서 WebSocket이 지원되므로 고객은 다른 동적 및 정적 콘텐츠와 동일한 경로를 통해 WebSocket 트래픽을 관리할 수 있습니다. CloudFront를 사용하면 CloudFront가 기본 제공하는 AWS Shield 및 AWS WAF와의 통합을 통해 DDoS 보호를 활용할 수 있습니다.

엣지 캐싱

CloudFront가 아닌 일반적인 웹 서버에서 이미지를 제공한다고 가정합니다. URL A/photo.png를 사용하여 photo.png라는 이미지를 제공할 수 있습니다. 사용자는 이 URL로 쉽게 이동해 해당 이미지를 볼 수 있습니다.

이미지가 발견될 때까지 인터넷으로 이루어진 상호 연결된 네트워크의 복잡한 모음을 통해 네트워크에서 다른 네트워크로 요청이 라우팅되었다는 사실은 아마 모를 것입니다.

CloudFront는 AWS 백본 네트워크를 통해 콘텐츠를 가장 효과적으로 서비스할 수 있는 엣지 로케이션으로 각 사용자 요청을 라우팅하여 콘텐츠 배포 속도를 높입니다. 일반적으로 CloudFront 엣지의 서버가 유저에게 가장 빠른 속도로 제공합니다. AWS 네트워크를 사용하면 사용자의 요청이 반드시 통과해야 하는 네트워크의 수가 줄어들어 성능이 향상됩니다. 파일의 첫 바이트를 로드하는 데 걸리는 지연 시간이 줄어들고 데이터 전송 속도가 빨라집니다. 또한 파일(객체)의 사본이 전 세계 여러 엣지 로케이션에 유지(또는 캐시)되므로 안정성과 가용성이 향상됩니다.

CloudFront 캐싱 단계

1. 요청이 최적의 엣지 로케이션으로 라우팅 됩니다.
2. 캐시되지 않은 콘텐츠가 오리진으로부터 검색됩니다.
3. 오리진 콘텐츠가 캐싱을 위해 CloudFront 엣지 로케이션으로 전송됩니다.
4. 데이터가 사용자에게 전달 됩니다.

콘텐츠가 이미 캐시되어 있으며 콘텐츠 유지 시간(TTL)이 만료되지 않았다면 2~3단계를 건너뛰며 데이터가 엣지 로케이션에서 콘텐츠 요청자에게 전송됩니다.

CloudFront 구성

CloudFront를 구성하려면 CloudFront가 사용자의 파일을 가져오는 오리진 서버(예: S3 버킷 또는 사용자의 HTTP 서버)를 지정합니다. 이들 서버는 전 세계의 CloudFront 엣지 로케이션에서 배포됩니다.

• 오리진 서버는 객체의 최종 원본 버전을 저장합니다.
• HTTP를 통해 콘텐츠를 제공하는 경우, 오리진 서버는 S3 버킷이거나 웹 서버 같은 HTTP 서버입니다.
• HTTP 서버는 EC2 인스턴스 또는 사용자가 관리하는 온프레미스 서버에서 실행될 수 있습니다. 이러한 서버를 사용자 지정 오리진이라고도 합니다.

다음으로 CloudFront 배포를 생성합니다. 그러면 최종 사용자가 웹 사이트 또는 애플리케이션을 통해 요청하는 파일을 가져올 오리진 서버에 대해 CloudFront에 알려줍니다. 동시에 CloudFront에서 모든 요청을 기록할지 여부 및 배포를 만들자마자 활성화할지 여부와 같은 세부 사항을 지정합니다.

CloudFront는 새 배포에 도메인 이름을 할당합니다. 이 서비스는 콘텐츠를 제외한 배포의 구성을 모든 엣지 로케이션에 전송합니다.

성능 개선

CloudFront는 관리형 서비스입니다. 성능을 개선할 수 있도록 AWS에서 제공하는 서비스를 파악해야 합니다. 그리고 애플리케이션 성능을 최적화하도록 CloudFront를 구성해야 합니다.

AWS는 콘텐츠 전송 성능을 개선하는 기능을 제공합니다.

• TCP 최적화
  CloudFront는 TCP 최적화 기능을 사용해 네트워크에서 현재 트래픽을 전송 중인 속도와 현재 왕복 지연 시간을 관찰합니다. 그런 다음 해당 데이터를 입력으로 사용하여 성능을 자동으로 개선합니다.
• TLS 1.3 지원
   CloudFront는 TLS 1.3을 지원합니다. TLS 1.3은 필요한 왕복 수가 적어 더 간편한 핸드셰이크 프로세스를 통해 더욱 우수한 성능을 제공합니다. 그리고 개선된 보안 기능도 추가로 제공합니다.
• 동적 콘텐츠 배치
  CloudFront를 사용하면 ELSB 로드 밸런서나 EC2 인스턴스에서 웹 애플리케이션 또는 API와 같은 동적 콘텐츠를 제공할 수 있습니다. 그러면 콘텐츠의 성능, 가용성 및 보안을 개선할 수 있습니다.

성능 개선을 위해 CloudFront 배포의 구성을 조정할 수도 있습니다.

• 캐싱 전략 정의
  적절한 TTL을 선택해야 합니다. 또한 쿼리 문자열 파라미터, 쿠키 또는 요청 헤더 등을 기준으로 캐싱을 고려해야 합니다.
• 캐시 적중률 개선
  CloudFront 콘솔에서 적중, 미스, 오류 상태의 뷰어 요청 비율을 확일할 수 있습니다. 그리고 CloudFront 캐시 통계 보고서에 수집된 통계를 기준으로 하여 배포를 변경할 수 있습니다.
• CloudFront Origin Shield 사용
  리전 엣지 캐시와 오리진 간에 캐싱 게층을 더 추가할 수 있습니다. Origin Shield가 사용 사례에 항상 적합한 것은 아니지만 뷰어가 여러 지역의 리전에 분산되어 있거나 온프레미스 오리진에 용량 또는 대역폭 제약 조건이 적용되는 경우에는 유용할 수 있습니다.

엣지 서비스

AWS 엣지 컴퓨팅 서비스는 필요에 따라 엔드포인트에 가깝게 데이터 처리 및 분석 기능을 이동하는 인프라와 소프트웨어를 제공합니다. 여기에는 AWS 데이터 센터 외부 위치, 심지어 고객 소유 디바이스에 AWS 관리형 하드웨어 및 소프트웨어를 배포하는 것이 포함됩니다.

다음과 같이 위치와 관련된 AWS 엣지 서비스를 사용하여 일관된 하이브리드 경험을 위해 클라우드를 확장할 수 있습니다.

• AWS 엣지 로케이션
  엣지 로케이션은 AWS 네트워크 백본을 통해 AWS 리전에 연결됩니다. CloudFront, WAF 및 Shield가 여기에서 사용되는 서비스입니다.
• AWS 로컬 영역
  AWS 클라우드의 확장인 로컬 영역은 인구가 많은 산업 중심지와 가까운 곳에 배치됩니다. 
• AWS Outposts
  이를 사용항 온프레미스나 자체 데이터센터에서 일부 AWS 서비스를 싱행할 수 있습니다.
• Snow 패밀리
  Snow 제품 패밀리는 엣지에서 오프라인 스토리지를 제공합니다. 이러한 스토리지를 사용하여 AWS 리전에 데이터를 다시 전송합니다.

동일한 인프라, 서비스, API 및 도구를 사용하여 일관된 환경을 구축할 수 있습니다.

엣지 서비스 아키텍처

사용자가 온프레미스에서 부분적을 호스트되는 애플리케이션으로 요청을 전송합니다. 사용자 요청이 Route 53, WAF, CloudFront, Outposts와 상호작용합니다. 클라우드에서 호스트되는 AWS 서비스는 AWS Shield를 통해 보호됩니다.

Route 53

Route 53은 DNS, 도메인 이름 등록 및 상태 확인 기능을 제공합니다. Route 53은 개발자와 기업이 안정적이고 비용 효율적인 방식으로 최종 사용자를 인터넷 애플리케이션에 라우팅할 수 있도록 설계되었습니다. 이 서비스는 example.com과 같은 이름을 컴퓨터의 상호 연결에 사용되는 숫자 IP 주소로 변환합니다.

Route 53을 사용해 example.com 같은 도메인 이름을 구매 및 관리하고 도메인에 대한 DNS 설정을 자동으로 구성할 수 있습니다.

Route 53은 EC2 인스턴스, ELB(Elastic Load Balancing) 로드 벨런서 또는 S3 버킷 등 AWS에서 실행되는 인프라에 사용자 요청을 효율적으로 연결합니다. 사용자를 AWS 외부의 인프라로 라우팅하기 위해 Route 53을 사용할 수도 있습니다.

CloudWatch 경보를 구성하여 엔드포인트 상태를 확인할 수 있습니다. DNS를 상태 확인 지표와 결합하여 정상 엔드포인트를 모니터링하고 해당 엔드포인트로 트래픽을 라우팅합니다.

상세 

Route 53  퍼빌릭  및 프라이빗 DNS

호스팅 영역은 레코드의 컨테이너입니다. 레코드에는 특정 도메인(example.com)과 그 하위 도메인(www.example.com 등)의 트래픽을 라우팅하는 방식에 대한 정보가 포함됩니다. 호스팅 영역과 해당 도메인의 이름은 동일합니다.

호스팅 영역의 유형은 두 가지입니다.

• 퍼블릭 호스팅 영역은 인터넷에서 트래픽을 라우팅하고자 하는 방법을 지정하는 레코드를 포함합니다.
  • 인터넷 이름 해석
  • 위임 세트: 등록 기관 또는 상위 도메인에 제공할 권한 네임 서버
• 프라이빗 호스팅 영역은 VPC에서 트래픽을 라우팅하고자 하는 방법을 지정하는 레코드를 포함합니다.
  • VPC 내부에서의 이름 해석
  • 계정 간에 여러 VPC와 연결할 수 있음

라우팅 정책

레코드를 생성할 때 라우팅 정책을 선택하게 되는데, 이는 Route 53이 쿼리에 응답하는 방식을 결정합니다.

1. 단순 라우팅 정책
   도메인과 관련하여 특정 기능을 수행하는 리소스 하나에 사용합니다. 이러한 리소스의 예시는 example.com 웹 사이트용 콘텐츠를 제공하는 웹 서버 등이 있습니다.
   
   단순 라우팅을 사용할 경우 표준 DNS 레코드를 구성할 수 있으므로 가중치 기반 라우팅, 지연 시간 라우팅 등의 특수 Route 53 라우팅을 사용할 필요가 없습니다. 단순 라우팅을 사용할 때는 대개 리소스 하나에 트래픽을 라우팅합니다.
   
   
2. 장애 조치 라우팅 정책
   액티브-패시브 장애 조치를 구성하려는 경우 사용합니다. 이 경우 Route 53 상태 확인을 통해 웹 애플리케이션, 웹 서버 및 기타 리소스의 상태와 성능을 모니터링합니다.
   
   상태 확인을 각각 생성하여 다음 중 하나를 모니터링할 수 있습니다.
   • 지정한 리소스의 상태
   • 다른 상태 확인 상태
     > 상태 확인을 생성하면 상태 확인의 상태를 받고, 상태가 변경될 때 알림을 받으며, DNS 장애 조치를 구성할 수 있습니다.
   • CloudWatch 경보 상태
     
     
3. 지리적 위치 라우팅 정책
   사용자의 위치를 기준으로 트래픽을 라우팅하려는 경우에 사용합니다. 이를 사용하면 사용자의 지리적 위치(DNS 쿼리가 시작된 위치)에 따라 트래픽을 지원할 리소스를 선택할 수 있습니다. 예를 들어 유럽에서 시작된 모든 쿼리를 프랑크푸르트 리전의 ELB 로드 밸런서로 라우팅할 수 있습니다.
   
   
4. 지리 근접 라우팅 정책
   리소스 위치를 기반으로 트래픽을 라우팅하고 선택적으로 한 위치의 리소스에서 다른 리소스로 트래픽을 이동하려는 경우에 사용합니다. 이를 사용해 Route 53이 사용자 및 리소스의 지리적 위치에 따라 트래픽을 리소스로 라우팅할 수 있습니다. 선택적으로 바이어스라고 하는 값을 지정하여 지정된 리소스로 트래픽을 더 많이 또는 더 적게 라우팅하도록 선택할 수 있습니다. 바이어스는 트래픽이 리소스로 라우팅되는 지리적 리전의 크기를 확장하거나 축소합니다.
   
   
5. 지연 시간 라우팅 정책
   여러 AWS 리전에 리소스가 있고 더 짧은 왕복 시간으로 가장 짧은 지연 시간을 제공하는 리전으로 트래픽을 라우팅하려는 경우 사용합니다.
   
   애플리케이션이 여러 AWS 리전에서 호스트된다면, 사용자들의 요청을 지연 시간이 가장 낮은 AWS 리전에서 처리함으로써 최종 사용자를 위해 성능을 향상시킬 수 있습니다.
   
   사용자와 리소스 간의 지연 시간에 대한 데이터는 전적으로 사용자와 AWS 데이터 센터 간의 트래픽에 기반합니다. AWS 리전에서 리소스를 사용하지 않는 경우 사용자와 리소스 간의 실제 지연 시간은 AWS 지연 시간 데이터와 크게 다를 수 있습니다. 리소스가 AWS 리전과 동일한 도시에 위치하는 경우에도 마찬가지입니다.
   
   
6. 다중 응답 라우팅 정책
   Route 53이 무작위로 선택도니 최대 8개의 정상 레코드로 DNS 쿼리에 응답하도록 하려는 경우에 사용합니다. 이를 사용하여, DNS 쿼리에 응답하여 웹 서버의 IP 주소와 같은 여러 값을 반환하도록 Route 53을 구성할 수 있습니다. 다중 값은 거의 모든 레코드에 대해 지정할 수 있지만, 다중 응답 라우팅을 사용하면 각 리소스의 상태도 확인할 수 있습니다. Route 53은 정상 리소스의 값만 반환합니다.
   
   다수의 상태 확인 가능한 IP 주소를 반환하는 기능은 DNS를 사용하여 가용성 및 로드 밸런싱을 개선하는 한 방법입니다. 하지만 이 기능이 로드 밸런서를 대처하는 것은 아닙니다.
   
   
7. 가중치 기반 라우팅 정책
   트래픽을 지정한 비율로 여러 리소스로 라우팅하는 데 사용합니다. 이를 사용해 리소스 레코드 세트에 가중치를 할당하여 각 응답이 처리되는 빈도를 지정할 수 있습니다.
   
   
   아래 블루/그린 배포 예시에서는 소량의 트래픽을 새 프로덕션 환경으로 라우팅하는데 가중치 기반 라우팅 정책이 사용되고 있습니다. 새 환경이 의도한 대로 작동하면 가중치 기반 트래픽의 양을 늘려 환경이 증가된 로드를 처리할 수 있는지 확인할 수 있습니다. 테스트가 성공적이면 모든 트래픽을 새 환경으로 보낼 수 있습니다.

라우팅 정책 선택법

Step Functions

현대적 클라우드 애플리케이션이 다수의 서비스 및 구성 요소로 구성되는 것은 일반적입니다. 애플리케이션 규모가 커지면서 모든 구성 요소의 상호 작용을 조율하기 위해 점점 더 많은 코드를 작성해야 합니다. Step Functions를 사용하면 상호 작용을 위한 소프트웨어 작성보다는 구성 요소 상호 작용의 정의에 집중할 수 있습니다.

Step Functions는 다음 AWS 서비스와 통합됩니다. Step Functions에서 직접 API 작업을 호출하고 파라미터를 다음 서비스의 API로 전달할 수 있습니다.

• 컴퓨터 서비스: Lambda, ECS, EKS, Fargate
• 데이터베이스 서비스: DynamoDB
• 메시징 서비스: SNS 및 SQS
• 데이터 처리 및 분석 서비스: Athena, Batch, Glue, EMR, Glue DataBrew
• 기계 학습 서비스 SageMaker
• API Gateway에 의해 생성된 API

Step Functions 서비스 태스크를 사용하여 다른 AWS 서비스를 호출하도록 Step Functions 워크플로를 구성할 수 있습니다.

상태 머신

상태 머신은 출력을 결정하기 위해 이전 조건에 의존하는 일련의 작동 조건을 가진 객체입니다.

상태 머신의 일반적인 예는 탄산음료 자판기입니다. 자판기는 작동 상태(거래 대기)에서 시작하여 고객이 동전 또는 ㅈ폐를 투입하면 탄산음료 선택 상태로 전환됩니다. 그러면 판매 상태가 시작되어 탄산음료가 고객에게 제공됩니다. 완료 후 운영 상태로 돌아갑니다.

Step Functions를 사용하면 AWS 환경에서 사용자 고유의 상태 머신을 생성하여 자동화할 수 있습니다. States Language에는 다양한 상태, 태스크, 선택, 오류 처리 등으로 구성된 구조가 포함돼 있습니다.

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

상태는 상태 머신의 요소입니다. 상태는 상태 머신에서 다양한 기능을 수행할 수 있습니다. 상태가 수행할 수 있는 기능은 다음과 같습니다.

• 상태 머신에서 몇 가지 태스크 수행(Task 상태)
• 실행할 브랜치 선택(Choice 상태)
• 오류 또는 성공으로 실행 중지(Fail 또는 Succeed 상태)
• 입력을 출력으로 전달하거나 일부 수정된 데이터 전달(Pass 상태)
• 특정 시간 동안 또는 지정된 시간/ 날짜까지 실행 지연(Wait 상태)
• 병렬 브랜치 시작(Parallel 상태)
• 동적으로 단계 반복(Map 상태)

Step Functions에서는 Standard와 Express의 두 가지 워크플로 유형을 생성할 수 있습니다.

• 내구성이 우수하며 감사가 가능한 장기 실행 워크플로에는 Standard Workflow 유형을 사용합니다. 이러한 워크플로는 최대 1년까지 실행할 수 있으며, 워크플로가 완료된 후 최대 90일 동안 워크플로 활동의 전체 기록에 액세스할 수 있습니다. Standard Workflow에 사용되는 정확히 1회 모델에서는 재시도 동작을 지정하는 경우가 아니면 태스크와 상태가 2회 이상 실행되지 않습니다.
• IoT 데이터 수집, 스트리밍 데이터 처리 및 변환, 모바일 애플리케이션 백엔드 등의 대용량 이벤트 처리 워크로드에는 Express Workflow 유형을 사용합니다. 이러한 워크플로는 최대 5분까지 실행할 수 있습니다. Express Workflow에 사용되는 최소 1회 모델에서는 태스크와 상태가 여러 번 실행될 수도 있습니다.