기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
WorkSpaces 개인용 리전 간 리디렉션
Amazon 의 리전 간 리디렉션 기능을 사용하면 정규화된 도메인 이름(FQDN)을 의 등록 코드로 사용할 WorkSpaces수 있습니다 WorkSpaces. 리전 간 리디렉션 WorkSpaces 은 도메인 이름 시스템(DNS) 라우팅 정책과 함께 작동하여 기본 리디렉션을 사용할 수 없는 WorkSpaces 경우 WorkSpaces 사용자를 대체 리디렉션으로 리디렉션합니다. 예를 들어 DNS 장애 조치 라우팅 정책을 사용하여 사용자가 기본 AWS 리전 WorkSpaces 의 에 액세스할 수 없는 경우 지정된 장애 조치 리전의 WorkSpaces 에 사용자를 연결할 수 있습니다.
DNS 장애 조치 라우팅 정책과 함께 리전 간 리디렉션을 사용하여 리전 복원성과 고가용성을 달성할 수 있습니다. 또한 이 기능을 트래픽 배포 또는 유지 관리 기간 WorkSpaces 중 대안 제공과 같은 다른 용도로 사용할 수 있습니다. DNS 구성에 Amazon Route 53을 사용하는 경우 Amazon CloudWatch 경보를 모니터링하는 상태 확인을 활용할 수 있습니다.
이 기능을 사용하려면 두 개(또는 그 이상) AWS 리전에서 사용자를 WorkSpaces 위해 를 설정해야 합니다. 연결 별칭이라는 특수 FQDN기반 등록 코드도 생성해야 합니다. 이러한 연결 별칭은 WorkSpaces 사용자의 리전별 등록 코드를 대체합니다. (지역별 등록 코드는 여전히 유효하지만, 리전 간 리디렉션이 작동하려면 사용자가 FQDN 대신 를 등록 코드로 사용해야 합니다.)
연결 별칭을 생성하려면 www.example.com
또는 FQDN와 같은 인 연결 문자열을 지정합니다desktop.example.com
. 리전 간 리디렉션에 이 도메인을 사용하려면 도메인 등록 기관에 등록하고 도메인에 대한 DNS 서비스를 구성해야 합니다.
연결 별칭을 생성한 후 다른 리전의 WorkSpaces 디렉터리와 연결하여 연결 페어를 생성합니다. 각 연결 쌍에는 기본 리전과 하나 이상의 장애 조치 리전이 있습니다. 기본 리전에서 중단이 발생하는 경우 DNS 장애 조치 라우팅 정책은 WorkSpaces 사용자를 장애 조치 리전에서 사용자를 위해 설정한 WorkSpaces 로 리디렉션합니다.
기본 및 장애 조치 리전을 지정하려면 DNS 장애 조치 라우팅 정책을 구성할 때 리전 우선 순위(기본 또는 보조)를 정의합니다.
내용
사전 조건
-
FQDN 연결 별칭에서 로 사용할 도메인을 소유하고 등록해야 합니다. 다른 도메인 등록 대행자를 아직 사용하고 있지 않은 경우 Amazon Route 53를 사용하여 도메인을 등록할 수 있습니다. 자세한 내용은 Amazon Route 53 개발자 안내서의 Registering domain names using Amazon Route 53를 참조하세요.
중요
Amazon 와 함께 사용하는 모든 도메인 이름을 사용하려면 필요한 모든 권한이 있어야 합니다 WorkSpaces. 도메인 이름이 제3자의 법적 권리를 위반하거나 침해하거나 관련 법률을 위반하지 않는다는 데 동의하는 것으로 간주합니다.
도메인 이름의 총 길이는 255자를 초과할 수 없습니다. 도메인 이름에 대한 자세한 내용은 Amazon Route 53 개발자 안내서의 DNS 도메인 이름 형식을 참조하세요.
리전 간 리디렉션은 프라이빗 DNS 영역의 퍼블릭 도메인 이름과 도메인 이름 모두에서 작동합니다. 프라이빗 DNS 영역을 사용하는 경우 가 포함된 가상 프라이빗 클라우드(VPN)에 가상 프라이빗 네트워크(VPC) 연결을 제공해야 합니다 WorkSpaces. WorkSpaces 사용자가 퍼블릭 인터넷FQDN에서 프라이빗을 사용하려고 하면 WorkSpaces 클라이언트 애플리케이션은 다음 오류 메시지를 반환합니다.
"We're unable to register the WorkSpace because of a DNS server issue. Contact your administrator for help."
-
DNS 서비스를 설정하고 필요한 DNS 라우팅 정책을 구성해야 합니다. 리전 간 리디렉션은 DNS 라우팅 정책과 함께 작동하여 필요에 따라 WorkSpaces 사용자를 리디렉션합니다.
-
교차 리전 리디렉션을 설정하려는 각 기본 및 장애 조치 리전에서 사용자를 WorkSpaces 위해 를 생성합니다. 각 리전의 각 WorkSpaces 디렉터리에 동일한 사용자 이름을 사용해야 합니다. Active Directory 사용자 데이터를 동기화된 상태로 유지하려면 AD Connector를 사용하여 사용자를 WorkSpaces 위해 설정한 각 리전의 동일한 Active Directory를 가리키는 것이 좋습니다. 생성에 대한 자세한 내용은 시작을 WorkSpaces WorkSpaces참조하세요.
중요
다중 리전 복제를 위해 AWS Managed Microsoft AD 디렉터리를 구성하는 경우 Amazon 에 사용할 수 있도록 기본 리전의 디렉터리만 등록할 수 있습니다 WorkSpaces. Amazon에서 사용할 복제 리전에 디렉터리를 등록하려는 시도 WorkSpaces 는 실패합니다. AWS Managed Microsoft AD를 사용한 다중 리전 복제는 복제된 리전 내에서 Amazon WorkSpaces 과 함께 사용할 수 없습니다.
리전 간 리디렉션 설정을 마치면 WorkSpaces 사용자가 기본 리전에 대한 리전 FQDN기반 등록 코드(예:
WSpdx+ABC12D
) 대신 기반 등록 코드를 사용하고 있는지 확인해야 합니다. 이렇게 하려면 의 절차를 사용하여 FQDN 연결 문자열이 포함된 이메일을 전송해야 합니다5단계: WorkSpaces 사용자에게 연결 문자열 전송.참고
Active Directory에서 사용자를 생성하는 대신 WorkSpaces 콘솔에서 사용자를 생성하는 경우 는 새 를 시작할 때마다 리전 기반 등록 코드를 사용하여 사용자에게 초대 이메일을 WorkSpaces 자동으로 보냅니다 WorkSpace. 즉, 장애 조치 리전에서 사용자에 WorkSpaces 대해 를 설정하면 사용자도 이러한 장애 조치 에 대한 이메일을 자동으로 수신합니다 WorkSpaces. 리전 기반 등록 코드가 포함된 이메일은 무시하도록 사용자에게 지시해야 합니다.
제한 사항
-
리전 간 리디렉션은 기본 리전에 대한 연결이 실패했는지 여부를 자동으로 확인하지 않고 다른 리전에 대한 WorkSpaces 리디렉션을 실패합니다. 즉, 자동 장애 조치가 발생하지 않습니다.
자동 장애 조치 시나리오를 구현하려면 리전 간 리디렉션과 함께 다른 메커니즘을 사용해야 합니다. 예를 들어 기본 리전의 CloudWatch 경보를 모니터링하는 Route 53 상태 확인과 함께 Amazon Route 53 장애 조치 DNS 라우팅 정책을 사용할 수 있습니다. 기본 리전의 CloudWatch 경보가 트리거되면 DNS 장애 조치 라우팅 정책은 WorkSpaces 사용자를 장애 조치 리전에서 사용자를 위해 WorkSpaces 설정한 로 리디렉션합니다.
-
리전 간 리디렉션을 사용하는 경우 사용자 데이터는 서로 다른 리전 WorkSpaces 의 간에 유지되지 않습니다. 사용자가 서로 다른 리전에서 파일에 액세스할 수 있도록 하려면 기본 및 장애 조치 리전에서 Amazon WorkDocs 이 지원되는 경우 WorkSpaces 사용자에 WorkDocs 대해 Amazon을 설정하는 것이 좋습니다. Amazon 에 대한 자세한 내용은 Amazon 관리 안내서의 Amazon WorkDocs Drive를 WorkDocs참조하세요. WorkDocs 사용자 WorkDocs 에 대해 Amazon을 활성화하는 방법에 대한 자세한 내용은 기존 등록하기 AWS Directory Service 디렉터리를 WorkSpaces 퍼스널에 및 섹션을 참조하세요 WorkSpace AWS Managed Microsoft AD에 Amazon WorkDocs 활성화. WorkSpaces 사용자가 WorkDocs 에서 Amazon을 설정하는 방법에 대한 자세한 내용은 Amazon WorkSpaces 사용 설명서의 와 통합 WorkDocs을 WorkSpaces참조하세요.
-
리전 간 리디렉션은 Linux, macOS 및 Windows WorkSpaces 클라이언트 애플리케이션의 버전 3.0.9 이상에서만 지원됩니다. Web Access에서도 리전 간 리디렉션을 사용할 수 있습니다.
-
리전 간 리디렉션은 AWS GovCloud (US) Region와 중국(닝샤) 리전을 제외하고 AWS Amazon WorkSpaces 을 사용할 수 있는
모든 리전에서 사용할 수 있습니다.
1단계: 연결 별칭 생성
동일한 AWS 계정을 사용하여 교차 리전 리디렉션을 설정하려는 각 기본 및 장애 조치 리전에서 연결 별칭을 생성합니다.
연결 별칭을 생성하는 방법
에서 WorkSpaces 콘솔을 엽니다https://console.aws.amazon.com/workspaces/
. -
콘솔의 오른쪽 상단에서 의 기본 AWS 리전을 선택합니다 WorkSpaces.
-
탐색 창에서 Account Settings(계정 설정)를 선택합니다.
-
리전 간 리디렉션에서 연결 별칭 생성을 선택합니다.
-
연결 문자열 에
www.example.com
또는 와 FQDN같은 를 입력합니다desktop.example.com
. 연결 문자열은 최대 255자입니다. 여기에는 문자(A~Z 및 a~z), 숫자(0~9) 및 .- 기호만 사용할 수 있습니다.중요
연결 문자열을 생성하면 항상 AWS 계정과 연결됩니다. 원래 계정에서 연결 문자열의 모든 인스턴스를 삭제한 경우에도 다른 계정으로 같은 연결 문자열을 다시 만들 수 없습니다. 연결 문자열은 전역적으로 계정에 예약되어 있습니다.
-
(선택 사항) 태그에서 연결 별칭과 연결할 태그를 지정합니다.
-
연결 별칭 생성을 선택합니다.
-
이 단계를 반복하지만 단계 2에서 에 대한 장애 조치 리전을 선택해야 합니다 WorkSpaces. 장애 조치 리전이 여러 개 있을 경우 각 장애 조치 리전에 대해 이 절차를 반복합니다. 동일한 AWS 계정을 사용하여 각 장애 조치 리전에서 연결 별칭을 생성해야 합니다.
(선택 사항) 2단계: 다른 계정과 연결 별칭 공유
연결 별칭을 동일한 AWS 리전 AWS 의 다른 계정과 공유할 수 있습니다. 연결 별칭을 다른 계정과 공유하면 해당 계정에 해당 별칭을 동일한 리전에서 해당 계정이 소유한 디렉터리에만 연결하거나 연결을 해제할 수 있는 권한이 부여됩니다. 연결 별칭을 소유한 계정만 별칭을 삭제할 수 있습니다.
참고
연결 별칭은 AWS 리전당 하나의 디렉터리에만 연결할 수 있습니다. 연결 별칭을 다른 AWS 계정과 공유하는 경우 하나의 계정(계정 또는 공유 계정)만 해당 리전의 디렉터리와 별칭을 연결할 수 있습니다.
연결 별칭을 다른 AWS 계정과 공유하려면
에서 WorkSpaces 콘솔을 엽니다https://console.aws.amazon.com/workspaces/
. -
콘솔의 오른쪽 상단에서 연결 별칭을 다른 AWS 계정과 공유할 AWS 리전을 선택합니다.
-
탐색 창에서 Account Settings(계정 설정)를 선택합니다.
-
리전 간 리디렉션 연결에서 연결 문자열을 선택한 다음 작업, 연결 별칭 공유/공유 해제를 선택합니다.
연결 별칭의 세부 정보 페이지에서 별칭을 공유할 수도 있습니다. 이렇게 하려면 공유 계정에서 연결 별칭 공유를 선택합니다.
-
연결 별칭 공유/공유 해제 페이지의 계정 과 공유에서 이 AWS 리전에서 연결 별칭을 공유할 AWS 계정 ID를 입력합니다.
-
공유를 선택합니다.
3단계: 연결 별칭을 각 리전의 디렉터리에 연결
동일한 연결 별칭을 둘 이상의 리전에 있는 WorkSpaces 디렉터리와 연결하면 디렉터리 간에 연결 페어가 생성됩니다. 각 연결 쌍에는 기본 리전과 하나 이상의 장애 조치 리전이 있습니다.
예를 들어 기본 리전이 미국 서부(오레곤) 리전인 경우 미국 서부(오레곤) 리전의 WorkSpaces 디렉터리를 미국 동부(버지니아 북부) 리전의 WorkSpaces 디렉터리와 페어링할 수 있습니다. 기본 리전에서 중단이 발생하는 경우, 리전 간 리디렉션은 DNS 장애 조치 라우팅 정책 및 미국 서부(오레곤) 리전에서 수행한 모든 상태 확인과 함께 작동하여 사용자를 미국 동부(버지니아 북부) 리전에서 WorkSpaces 설정한 로 리디렉션합니다. 리전 간 리디렉션 경험에 대한 자세한 내용은 리전 간 리디렉션 중에 발생하는 상황 섹션을 참조하세요.
참고
WorkSpaces 사용자가 장애 조치 리전에서 상당한 거리(예: 수천 마일 거리)에 있는 경우, 사용자의 WorkSpaces 경험은 평소보다 덜 반응할 수 있습니다. 위치의 다양한 AWS 리전으로의 왕복 시간(RTT)을 확인하려면 Amazon WorkSpaces 연결 상태 확인
연결 별칭을 디렉터리와 연결하는 방법
AWS 리전당 하나의 디렉터리에만 연결 별칭을 연결할 수 있습니다. 연결 별칭을 다른 AWS 계정과 공유한 경우 하나의 계정(계정 또는 공유 계정)만 해당 리전의 디렉터리와 별칭을 연결할 수 있습니다.
에서 WorkSpaces 콘솔을 엽니다https://console.aws.amazon.com/workspaces/
. -
콘솔의 오른쪽 상단에서 의 기본 AWS 리전을 선택합니다 WorkSpaces.
-
탐색 창에서 Account Settings(계정 설정)를 선택합니다.
-
리전 간 리디렉션 연결에서 연결 문자열을 선택한 다음 작업, 연결/연결 해제를 선택합니다.
연결 별칭의 세부 정보 페이지에서 디렉터리에 연결 별칭을 연결할 수도 있습니다. 이렇게 하려면 연결된 디렉터리에서 디렉터리 연결을 선택합니다.
-
연결/연결 해제 페이지의 디렉터리 연결에서 이 AWS 리전에서 연결 별칭을 연결할 디렉터리를 선택합니다.
참고
다중 리전 복제를 위해 AWS Managed Microsoft AD 디렉터리를 구성하는 경우 기본 리전의 디렉터리만 Amazon 에서 사용할 수 있습니다 WorkSpaces. 복제된 리전에서 Amazon과 함께 디렉터리를 사용하려고 하면 실패 WorkSpaces 합니다. AWS Managed Microsoft AD를 사용한 다중 리전 복제는 복제된 리전 내에서 Amazon WorkSpaces 과 함께 사용할 수 없습니다.
-
연결을 선택합니다.
-
이 단계를 반복하지만 에서 에 대한 장애 조치 리전단계 2을 선택해야 합니다 WorkSpaces. 장애 조치 리전이 여러 개 있을 경우 각 장애 조치 리전에 대해 이 절차를 반복합니다. 각 장애 조치 리전의 디렉터리에 동일한 연결 별칭을 연결해야 합니다.
4단계: DNS 서비스 구성 및 DNS 라우팅 정책 설정
연결 별칭과 연결 별칭 연결 페어를 생성한 후 연결 문자열에 사용한 도메인에 대한 DNS 서비스를 구성할 수 있습니다. 이 용도로 모든 DNS 서비스 공급자를 사용할 수 있습니다. 선호하는 DNS 서비스 공급자가 아직 없는 경우 Amazon Route 53을 사용할 수 있습니다. 자세한 내용은 Amazon Route 53 개발자 안내서의 DNS 서비스로 Amazon Route 53 구성을 참조하세요.
도메인에 대한 DNS 서비스를 구성한 후에는 리전 간 리디렉션에 사용할 DNS 라우팅 정책을 설정해야 합니다. 예를 들어 Amazon Route 53 상태 확인을 사용하여 사용자가 특정 리전 WorkSpaces 에서 에 연결할 수 있는지 여부를 확인할 수 있습니다. 사용자가 연결할 수 없는 경우 DNS 장애 조치 정책을 사용하여 한 리전에서 다른 리전으로 DNS 트래픽을 라우팅할 수 있습니다.
DNS 라우팅 정책 선택에 대한 자세한 내용은 Amazon Route 53 개발자 안내서의 라우팅 정책 선택을 참조하세요. Amazon Route 53 상태 확인에 대한 자세한 내용은 Amazon Route 53 개발자 안내서에서 Amazon Route 53가 리소스의 상태를 확인하는 방법을 참조하세요.
DNS 라우팅 정책을 설정할 때는 기본 리전의 디렉터리와 연결 별칭 간의 연결을 위한 연결 식별자 WorkSpaces 가 필요합니다. WorkSpaces 장애 조치 리전 또는 리전의 디렉터리와 연결 별칭 간의 연결을 위한 연결 식별자도 필요합니다.
참고
연결 식별자는 연결 별칭 ID와 동일하지 않습니다. 연결 별칭 ID는 wsca-
로 시작합니다.
연결 별칭 연결을 위해 연결 식별자를 찾는 방법
에서 WorkSpaces 콘솔을 엽니다https://console.aws.amazon.com/workspaces/
. -
콘솔의 오른쪽 상단에서 의 기본 AWS 리전을 선택합니다 WorkSpaces.
-
탐색 창에서 Account Settings(계정 설정)를 선택합니다.
-
리전 간 리디렉션 연결에서 연결 문자열 텍스트(FQDN)를 선택하여 연결 별칭 세부 정보 페이지를 봅니다.
-
연결 별칭 세부 정보 페이지의 연결된 디렉터리에서 연결 식별자에 표시된 값을 기록해 둡니다.
-
이 단계를 반복하지만 단계 2에서 에 대한 장애 조치 리전을 선택해야 합니다 WorkSpaces. 장애 조치 리전이 여러 개 있을 경우 각 장애 조치 리전에 대해 이 절차를 반복하여 연결 식별자를 찾습니다.
예: Route 53을 사용하여 DNS 장애 조치 라우팅 정책을 설정하려면
다음 예에서는 도메인의 퍼블릭 호스팅 영역을 설정합니다. 하지만 퍼블릭 또는 프라이빗 호스팅 영역을 설정할 수 있습니다. 호스팅 영역 설정에 대한 자세한 내용은 Amazon Route 53 개발자 안내서의 호스팅 영역 작업을 참조하세요.
또한 이 예에서는 장애 조치 라우팅 정책을 사용합니다. 리전 간 리디렉션 전략에 다른 라우팅 정책 유형을 사용할 수 있습니다. DNS 라우팅 정책 선택에 대한 자세한 내용은 Amazon Route 53 개발자 안내서의 라우팅 정책 선택을 참조하세요.
Route 53에서 장애 조치 라우팅 정책을 설정하는 경우 기본 리전에 상태 확인 필수입니다. Route 53에서 상태 확인 생성에 대한 자세한 내용은 Amazon Route 53 개발자 안내서의 Amazon Route 53 상태 확인 생성 및 DNS 장애 조치 구성 및 상태 확인 생성, 업데이트 및 삭제를 참조하세요.
Route 53 상태 확인에 Amazon CloudWatch 경보를 사용하려면 기본 리전의 리소스를 모니터링하기 위한 경보도 설정해야 CloudWatch 합니다. 에 대한 자세한 내용은 Amazon 사용 설명서의 Amazon이란 무엇입니까 CloudWatch?를 CloudWatch참조하세요. CloudWatch Route 53이 상태 확인에서 CloudWatch 경보를 사용하는 방법에 대한 자세한 내용은 Amazon Route 53 개발자 안내서의 Route 53에서 CloudWatch 경보를 모니터링하는 상태 확인 및 경보 모니터링을 결정하는 방법을 참조하세요. CloudWatch
Route 53에서 DNS 장애 조치 라우팅 정책을 설정하려면 먼저 도메인에 호스팅 영역을 생성해야 합니다.
-
에서 Route 53 콘솔을 엽니다https://console.aws.amazon.com/route53/
. -
탐색 창에서 호스팅 영역을 선택한 후 호스팅 영역 생성을 선택합니다.
-
생성된 호스팅 영역 페이지에서 도메인 이름 아래에 도메인 이름(예:
example.com
)을 입력합니다. -
유형에서 퍼블릭 호스팅 영역을 선택합니다.
-
호스팅 영역 생성(Create hosted zone)을 선택합니다.
그런 다음 기본 리전에 대한 상태 확인을 생성합니다.
-
에서 Route 53 콘솔을 엽니다https://console.aws.amazon.com/route53/
. -
탐색 창에서 상태 확인을 선택한 다음 상태 확인 생성을 선택합니다.
-
상태 확인 구성 페이지에서 상태 확인의 이름을 입력합니다.
-
모니터링할 항목에서 엔드포인트 , 기타 상태 확인(계산된 상태 확인) 또는 CloudWatch 경보 상태 를 선택합니다.
-
이전 단계에서 선택한 항목에 따라 상태 확인을 구성하고 다음을 선택합니다.
-
상태 확인 실패 시 알림 메시지 받음 페이지의 경보 생성에서 예 또는 아니요를 선택합니다.
-
상태 확인 생성을 선택합니다.
상태 확인을 생성한 후 DNS 장애 조치 레코드를 생성할 수 있습니다.
-
에서 Route 53 콘솔을 엽니다https://console.aws.amazon.com/route53/
. -
탐색 창에서 호스팅 영역(Hosted zones)을 선택합니다.
-
호스팅 영역 페이지에서 도메인 이름을 선택합니다.
-
도메인 이름의 세부 정보 페이지에서 레코드 생성을 선택합니다.
-
라우팅 정책 선택 페이지에서 장애 조치를 선택하고 다음을 선택합니다.
-
레코드 구성 페이지의 기본 구성에서 레코드 이름에 하위 도메인 이름을 입력합니다. 예를 들어 FQDN가 인 경우 를
desktop.example.com
입력합니다desktop
.참고
루트 도메인을 사용하려면 레코드 이름을 비워 두세요. 그러나 도메인을 와 함께 사용하도록 설정하지
workspaces
않은 한desktop
또는 와 같은 하위 도메인을 사용하는 것이 좋습니다 WorkSpaces. -
레코드 유형 에서 TXT – 이메일 발신자를 확인하고 애플리케이션별 값 을 선택합니다.
-
TTL 초 설정을 기본값으로 둡니다.
-
추가할 장애 조치 레코드에서
your_domain_name
에서 장애 조치 레코드 정의를 선택합니다.
이제 기본 및 장애 조치 리전에 대한 장애 조치 레코드를 설정해야 합니다.
예: 기본 리전의 장애 조치 레코드를 설정하는 방법
-
장애 조치 레코드 정의 대화 상자의 값/트래픽 라우팅 대상에서 레코드 유형에 따라 IP 주소 또는 다른 값을 선택합니다.
-
샘플 텍스트를 입력할 수 있는 상자가 열립니다. 기본 리전의 연결 별칭 연결을 위한 연결 식별자를 입력합니다.
-
장애 조치 레코드 유형에서 기본을 선택합니다.
-
상태 확인에서 기본 리전에 대해 생성한 상태 확인을 선택합니다.
-
레코드 ID에 이 레코드를 식별할 수 있는 설명을 입력합니다.
-
장애 조치 레코드 정의를 선택합니다. 새 장애 조치 레코드가 추가할 장애 조치 레코드 아래에 나타납니다.
your_domain_name
.
예: 장애 조치 리전의 장애 조치 레코드를 설정하는 방법
-
추가할 장애 조치 레코드에서
your_domain_name
에서 장애 조치 레코드 정의를 선택합니다. -
장애 조치 레코드 정의 대화 상자의 값/트래픽 라우팅 대상에서 레코드 유형에 따라 IP 주소 또는 다른 값을 선택합니다.
-
샘플 텍스트를 입력할 수 있는 상자가 열립니다. 장애 조치 리전의 연결 별칭 연결을 위한 연결 식별자를 입력합니다.
-
장애 조치 레코드 유형에서 보조를 선택합니다.
-
(선택 사항) 상태 확인에 장애 조치 리전에 대해 생성한 상태 확인을 입력합니다.
-
레코드 ID에 이 레코드를 식별할 수 있는 설명을 입력합니다.
-
장애 조치 레코드 정의를 선택합니다. 새 장애 조치 레코드가 추가할 장애 조치 레코드 아래에 나타납니다.
your_domain_name
.
기본 리전에 대해 설정한 상태 확인이 실패하면 DNS 장애 조치 라우팅 정책이 WorkSpaces 사용자를 장애 조치 리전으로 리디렉션합니다. Route 53은 기본 리전에 대한 상태 확인을 계속 모니터링하며, 기본 리전에 대한 상태 확인이 더 이상 실패하지 않으면 Route 53은 자동으로 WorkSpaces 사용자를 기본 리전 WorkSpaces 의 해당 로 다시 리디렉션합니다.
DNS 레코드 생성에 대한 자세한 내용은 Amazon Route 53 개발자 안내서의 Amazon Route 53 콘솔을 사용하여 레코드 생성을 참조하세요. DNS TXT 레코드 구성에 대한 자세한 내용은 Amazon Route 53 개발자 안내서의 TXT 레코드 유형을 참조하세요.
5단계: WorkSpaces 사용자에게 연결 문자열 전송
정전 시 필요에 따라 사용자를 WorkSpaces 리디렉션하려면 연결 문자열(FQDN)을 사용자에게 전송해야 합니다. WorkSpaces 사용자에게 리전 기반 등록 코드(예: WSpdx+ABC12D
)를 이미 발급한 경우 해당 코드는 계속 유효합니다. 그러나 리전 간 리디렉션이 작동 WorkSpaces 하려면 사용자가 클라이언트 애플리케이션에 를 등록할 때 연결 문자열 WorkSpaces 을 WorkSpaces 등록 코드로 사용해야 합니다.
중요
Active Directory에서 사용자를 생성하는 대신 WorkSpaces 콘솔에서 사용자를 생성하는 경우 WorkSpaces 는 새 를 시작할 때마다 리전 기반 등록 코드(예: WSpdx+ABC12D
)를 사용하여 사용자에게 초대 이메일을 자동으로 보냅니다 WorkSpace. 리전 간 리디렉션을 이미 설정했더라도 새 에 대해 자동으로 전송되는 초대 이메일에는 연결 문자열 대신 이 리전 기반 등록 코드가 WorkSpaces 포함됩니다.
WorkSpaces 사용자가 리전 기반 등록 코드 대신 연결 문자열을 사용하고 있는지 확인하려면 아래 절차에 따라 연결 문자열과 함께 다른 이메일을 보내야 합니다.
WorkSpaces 사용자에게 연결 문자열을 보내려면
에서 WorkSpaces 콘솔을 엽니다https://console.aws.amazon.com/workspaces/
. -
콘솔의 오른쪽 상단에서 의 기본 AWS 리전을 선택합니다 WorkSpaces.
-
탐색 창에서 를 선택합니다WorkSpaces.
-
페이지에서 검색 상자를 WorkSpaces 사용하여 초대장을 보낼 사용자를 검색한 다음 검색 결과 WorkSpace 에서 해당하는 를 선택합니다. WorkSpace 한 번에 하나만 선택할 수 있습니다.
-
Actions(작업), Invite User(사용자 초대)를 선택합니다.
-
사용자 초대 WorkSpaces 페이지에서 사용자에게 보낼 이메일 템플릿을 볼 수 있습니다.
-
(선택 사항) WorkSpaces 디렉터리와 연결된 연결 별칭이 두 개 이상인 경우 연결 별칭 문자열 목록에서 사용자가 사용할 연결 문자열을 선택합니다. 이메일 템플릿이 업데이트되어 선택한 문자열이 표시됩니다.
-
이메일 템플릿 텍스트를 복사한 후 이메일 애플리케이션을 사용하여 사용자에게 보내는 이메일에 붙여 넣습니다. 이메일 애플리케이션에서 필요에 따라 텍스트를 수정할 수 있습니다. 초대 이메일이 준비되면 사용자에게 발송합니다.
리전 간 리디렉션 아키텍처 다이어그램
다음 다이어그램은 리전 간 리디렉션의 배포 프로세스를 설명합니다.
참고
리전 간 리디렉션은 리전 간 장애 조치 및 대체만 용이하게 합니다. 보조 리전 WorkSpaces 에서 생성 및 유지 관리를 용이하게 하지 않으며 리전 간 데이터 복제를 허용하지 않습니다. WorkSpaces 기본 리전과 보조 리전 모두에서 별도로 관리해야 합니다.
리전 간 리디렉션 시작
중단이 발생할 경우 DNS 레코드를 수동으로 업데이트하거나 장애 조치 리전을 결정하는 상태 확인을 기반으로 자동 라우팅 정책을 사용할 수 있습니다. Amazon Route 53을 사용하여 재해 복구 메커니즘 생성에 설명된 재해 복구 메커니즘을
리전 간 리디렉션 중에 발생하는 상황
리전 장애 조치 중에 WorkSpaces 사용자는 기본 리전 WorkSpaces 의 에서 연결이 해제됩니다. 재연결을 시도하면 다음 오류 메시지가 표시됩니다.
We can't connect to your WorkSpace. Check your network connection, and then try again.
그런 다음 사용자에게 다시 로그인하라는 메시지가 표시됩니다. 를 등록 코드FQDN로 사용하는 경우 다시 로그인하면 DNS 장애 조치 라우팅 정책이 장애 조치 리전에서 설정한 WorkSpaces 로 리디렉션합니다.
참고
경우에 따라 사용자가 다시 로그인할 때 다시 연결하지 못할 수도 있습니다. 이 동작이 발생하면 WorkSpaces 클라이언트 애플리케이션을 닫았다가 다시 시작한 다음 다시 로그인을 시도해야 합니다.
디렉터리에서 연결 별칭 연결 해제
디렉터리를 소유한 계정만 디렉터리에서 연결 별칭의 연결을 해제할 수 있습니다.
연결 별칭을 다른 계정과 공유하고 해당 계정이 자체적으로 소유한 디렉터리와 연결 별칭을 연결한 경우 해당 계정을 사용하여 디렉터리에서 연결 별칭의 연결을 해제해야 합니다.
디렉터리에서 연결 별칭 연결을 해제하는 방법
에서 WorkSpaces 콘솔을 엽니다https://console.aws.amazon.com/workspaces/
. -
콘솔의 오른쪽 상단에서 연결 해제하려는 연결 별칭이 포함된 AWS 리전을 선택합니다.
-
탐색 창에서 Account Settings(계정 설정)를 선택합니다.
-
리전 간 리디렉션 연결에서 연결 문자열을 선택한 다음 작업, 연결/연결 해제를 선택합니다.
연결 별칭 세부 정보 페이지에서도 연결 별칭의 연결을 해제할 수 있습니다. 이렇게 하려면 연결된 디렉터리에서 연결 해제를 선택합니다.
-
연결/연결 해제 페이지에서 연결 해제를 선택합니다.
-
연결 해제를 확인하라는 메시지가 표시된 대화 상자에서 연결 해제를 선택합니다.
연결 별칭 공유 해제
연결 별칭 소유자만 별칭 공유를 해제할 수 있습니다. 계정과 연결 별칭의 공유를 해제하면 해당 계정은 더 이상 연결 별칭을 디렉터리에 연결할 수 없습니다.
연결 별칭 공유를 해제하는 방법
에서 WorkSpaces 콘솔을 엽니다https://console.aws.amazon.com/workspaces/
. -
콘솔의 오른쪽 상단에서 공유 해제하려는 연결 별칭이 포함된 AWS 리전을 선택합니다.
-
탐색 창에서 Account Settings(계정 설정)를 선택합니다.
-
리전 간 리디렉션 연결에서 연결 문자열을 선택한 다음 작업, 연결 별칭 공유/공유 해제를 선택합니다.
연결 별칭 세부 정보 페이지에서도 연결 별칭의 공유를 해제할 수 있습니다. 이렇게 하려면 공유 계정에서 공유 해제를 선택합니다.
-
연결 별칭 공유/공유 해제제 페이지에서 공유 해제를 선택합니다.
-
연결 별칭 공유 해제를 확인하라는 메시지가 표시된 대화 상자에서 공유 해제를 선택합니다.
연결 별칭 삭제
사용자 계정에서 연결 별칭을 소유하고 연결 별칭이 디렉터리와 연결되어 있지 않은 경우에만 연결 별칭을 삭제할 수 있습니다.
연결 별칭을 다른 계정과 공유하고 해당 계정이 자체적으로 소유한 디렉터리와 연결 별칭을 연결한 경우 해당 계정이 먼저 디렉터리에서 연결 별칭의 연결을 해제해야 연결 별칭을 삭제할 수 있습니다.
중요
연결 문자열을 생성하면 항상 AWS 계정에 연결됩니다. 원래 계정에서 연결 문자열의 모든 인스턴스를 삭제한 경우에도 다른 계정으로 같은 연결 문자열을 다시 만들 수 없습니다. 연결 문자열은 전역적으로 계정에 예약되어 있습니다.
주의
더 이상 를 사용자의 등록 코드FQDN로 사용하지 않는 경우 잠재적 보안 문제를 방지하기 위해 WorkSpaces 특정 예방 조치를 취해야 합니다. 자세한 내용은 리전 간 리디렉션 사용을 중지하는 경우 보안 고려 사항 단원을 참조하십시오.
연결 별칭을 삭제하는 방법
에서 WorkSpaces 콘솔을 엽니다https://console.aws.amazon.com/workspaces/
. -
콘솔의 오른쪽 상단에서 삭제할 연결 별칭이 포함된 AWS 리전을 선택합니다.
-
탐색 창에서 Account Settings(계정 설정)를 선택합니다.
-
리전 간 리디렉션 연결에서 연결 문자열을 선택한 다음 삭제를 선택합니다.
연결 별칭 세부 정보 페이지에서도 연결 별칭을 삭제할 수 있습니다. 페이지 오른쪽 상단 모서리에서 삭제를 선택하면 됩니다.
참고
삭제 버튼이 비활성화된 경우 자신이 별칭의 소유자인지 확인하고 별칭이 디렉터리와 연결되어 있지 않은지 확인하세요.
-
삭제를 확인하라는 대화 상자에서 삭제를 선택합니다.
IAM 연결 별칭 연결 및 연결 해제 권한
IAM 사용자를 사용하여 연결 별칭을 연결하거나 연결 해제하는 경우 사용자에게 workspaces:AssociateConnectionAlias
및 에 대한 권한이 있어야 합니다workspaces:DisassociateConnectionAlias
.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "workspaces:AssociateConnectionAlias", "workspaces:DisassociateConnectionAlias" ], "Resource": [ "arn:aws:workspaces:
us-east-1
:123456789012
:connectionalias/wsca-a1bcd2efg
" ] } ] }
중요
연결 별칭을 소유하지 않은 계정의 연결 별칭을 연결하거나 연결 해제하기 위한 IAM 정책을 생성하는 경우 에서 계정 ID를 지정할 수 없습니다ARN. 대신 다음 예시 정책에 표시된 대로 계정 ID에 *
기호를 사용해야 합니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "workspaces:AssociateConnectionAlias", "workspaces:DisassociateConnectionAlias" ], "Resource": [ "arn:aws:workspaces:
us-east-1
:*:connectionalias/wsca-a1bcd2efg
" ] } ] }
해당 계정이 연결 또는 연결 해제할 연결 별칭을 소유한 ARN 경우에만 에서 계정 ID를 지정할 수 있습니다.
에 대한 자세한 내용은 섹션을 IAM참조하세요ID 및 액세스 관리 대상 WorkSpaces.
리전 간 리디렉션 사용을 중지하는 경우 보안 고려 사항
더 이상 를 WorkSpaces 사용자의 등록 코드FQDN로 사용하지 않는 경우 잠재적 보안 문제를 방지하기 위해 다음 예방 조치를 취해야 합니다.
-
WorkSpaces 사용자에게 WorkSpaces 디렉터리에 대한 리전별 등록 코드(예:
WSpdx+ABC12D
)를 발급하고 를 등록 코드FQDN로 사용하지 않도록 지시해야 합니다. -
여전히 이 도메인 을 소유한 경우 피싱 공격에서 악용되지 않도록 DNS TXT 레코드를 업데이트하여 이 도메인을 제거해야 합니다. DNS TXT 레코드에서 이 도메인을 제거하고 WorkSpaces 사용자가 를 등록 코드FQDN로 사용하려고 하면 연결 시도가 무해하게 실패합니다.
-
더 이상 이 도메인을 소유하지 않는 경우 WorkSpaces 사용자는 리전별 등록 코드를 사용해야 합니다. 를 등록 코드FQDN로 계속 사용하려고 하면 연결 시도가 악성 사이트로 리디렉션될 수 있습니다.