쿠키 기본 설정 선택

당사는 사이트와 서비스를 제공하는 데 필요한 필수 쿠키 및 유사한 도구를 사용합니다. 고객이 사이트를 어떻게 사용하는지 파악하고 개선할 수 있도록 성능 쿠키를 사용해 익명의 통계를 수집합니다. 필수 쿠키는 비활성화할 수 없지만 '사용자 지정' 또는 ‘거부’를 클릭하여 성능 쿠키를 거부할 수 있습니다.

사용자가 동의하는 경우 AWS와 승인된 제3자도 쿠키를 사용하여 유용한 사이트 기능을 제공하고, 사용자의 기본 설정을 기억하고, 관련 광고를 비롯한 관련 콘텐츠를 표시합니다. 필수가 아닌 모든 쿠키를 수락하거나 거부하려면 ‘수락’ 또는 ‘거부’를 클릭하세요. 더 자세한 내용을 선택하려면 ‘사용자 정의’를 클릭하세요.

설정
문의하기
피드백
AWS Documentation
AWS 계정 생성

Migrating workloads: CloudEndure landing zone (SALZ)

PDF
포커스 모드
Migrating workloads: CloudEndure landing zone (SALZ) - AMS Advanced Application Developer's Guide
이 페이지는 귀하의 언어로 번역되지 않았습니다. 번역 요청

This section provides information on setting up an intermediate migration single-account landing zone (SALZ) for CloudEndure (CE) cutover instances to be available for a workload ingest (WIGS) RFC.

To learn more about CloudEndure, see CloudEndure Migration.

Note

This is a predefined, security hardened, migration LZ and pattern.

Prerequisites:

  • A customer AMS account

  • Network and access integration between AMS account and the customer on-premise

  • A CloudEndure account

  • A pre-approval workflow for an AMS Security review and signoff, run with your CA and/or CSDM, (for example, misuse of the IAM user permanent credentials provides the ability to create/delete instances and security groups)

Note

Specific preparation and migration processes are described in this section.

AWS architecture diagram showing data flow between on-premises server and AWS cloud services.

Preparation: You and AMS operator:

  1. Prepare a Request for Change (RFC) with the Management | Other | Other | Update change type to AMS for the following resources and updates. You can submit separate Other | Other Update RFCs, or one. For details on that RFC/CT, see Other | Other Update with these requests:

    1. Assign a secondary CIDR block in your AMS VPC; a temporary CIDR block that will be removed after the migration is completed. Ensure that the block will not conflict with any existing routes back to your on-premise network. For example, if your AMS VPC CIDR is 10.0.0.0/16, and there is a route back to your on-premise netword of 10.1.0.0/16, then the temporary secondary CIDR could be 10.255.255.0/24. For information on AWS CIDR blocks, see VPC and Subnet Sizing.

    2. Create a new, private, subnet inside the initial-garden AMS VPC. Example name: migration-temp-subnet.

    3. Create a new route table for the subnet with only local VPC and NAT (Internet) routes, to avoid conflicts with the source server during instance cutover and possible outages. Ensure outbound traffic to the Internet is allowed for patch downloads, and so that AMS WIGS pre-requisites can be downloaded and installed.

    4. Update your Managed AD security group to allow inbound and outbound traffic to/from migration-temp-subnet. Also request that your EPS load balancer (ELB) security group (ex: mc-eps-McEpsElbPrivateSecurityGroup-M79OXBZEEX74) be updated to allow the new, private, subnet (i.e. migration-temp-subnet). If the traffic from the dedicated CloudEndure (CE) subnet is not allowed on all three TCP ports, WIGS ingestion will fail.

    5. Finally, request a new CloudEndure IAM policy and IAM user. The policy needs your correct account number, and the subnet IDs in the RunInstances statement should be: your <Customer Application Subnet(s) + Temp Migration Subnet>.

      To see an AMS pre-approved IAM CloudEndure policy: Unpack the WIGS Cloud Endure Landing Zone Example file and open the customer_cloud_endure_policy.json.

      Note

      If you want a more permissive policy, discuss what you need with your CloudArchitect/CSDM and obtain, if needed, an AMS Security Review and Signoff before submitting an RFC implementing the policy.

  2. Your preparation steps to use CloudEndure for AMS workload ingestion are done and, if your migration partner has completed their preparation steps, migration is ready to be performed. The WIGS RFC is submitted by your migration partner.

Note

IAM user keys won't be directly shared, but must be typed into the CloudEndure management console by the AMS operator in a screen-sharing session.

Preparation: Migration Partner and AMS Operator:

  1. Create CloudEndure migration project.

    1. During project creation, have AMS type-in IAM user credentials in screen-sharing sessions.

    2. In Replication Settings -> Choose the subnet where the Replication Servers will be launched, select customer-application-x subnet.

    3. In Replication Settings -> Choose the Security Groups to apply to the Replication Servers, select both Sentinel security groups (Private Only and EgressAll).

  2. Define cutover options for the machines (instances).

    1. Subnet: migration-temp-subnet.

    2. Security Group: Both "Sentinel" security groups (Private Only and EgressAll).

      Cutover instances must be able to communicate to the AMS Managed AD and to AWS public endpoints.

    3. Elastic IP: None

    4. Public IP: no

    5. IAM role: customer-mc-ec2-instance-profile

      The IAM role must allow for SSM communication. Better to use AMS default.

    6. Set tags as per convention.

Migration: Migration Partner:

  1. Create a dummy stack on AMS. You use the stack ID to gain access to the bastions.

  2. Install the CloudEndure (CE) agent on the source server. For details, see Installing the Agents.

  3. Create local admin credentials on the source server.

  4. Schedule a short cutover window and click Cutover, when ready. This finalizes the migration and redirects users to the target AWS Region.

  5. Request stack Admin access to the dummy stack, see Admin Access Request.

  6. Log into the bastion, then to the cutover instance using the local admin credentials you created.

  7. Create a failsafe AMI. For details on creating AMIs, see AMI Create.

  8. Prepare the instance for ingestion, see Migrating Workloads: Prerequisites for Linux and Windows.

  9. Run WIGS RFC against the instance, see Workload Ingest Stack: Creating.

프라이버시사이트 이용 약관쿠키 기본 설정
© 2025, Amazon Web Services, Inc. 또는 계열사. All rights reserved.