You are a machine learning specialist at a rideshare startup company.
Your team supports developers who are using SageMaker notebook instances in a private subnet of your corporate VPC.
Your developers have important customer data stored on the SageMaker notebook instance's EBS volume, and so they wish to take a snapshot of that EBS volume.
When your developers attempt to locate the SageMaker notebook EC2 instance and its EBS volume within your corporate VPC, they don't find them.
What is the reason they don't see the instance or its EBS volume in the corporate VPC?
Click on the arrows to vote for the correct answer
A. B. C. D.Correct Answer: B.
Option A is incorrect.
SageMaker notebook instances run in an AWS service account (not in customer accounts), but they run on EC2 instances, not in EKS containers.
Option B is correct.
SageMaker runs its notebook instances on EC2 in an AWS service account, not in customer accounts.
Therefore, you can't access the EC2 instance EBS volumes.
Option C is incorrect.
SageMaker notebook instances run in an AWS service account (not in customer accounts), and they run on EC2 instances, not in ECS containers.
Option D is incorrect.
SageMaker runs its notebook instances on EC2 in an AWS service account, not in customer accounts.
References:
Please see the Amazon SageMaker developer guide titled Connect SageMaker Studio Notebooks to Resources in a VPC (https://docs.aws.amazon.com/sagemaker/latest/dg/studio-notebooks-and-internet-access.html),
The Amazon EC2 Auto Scaling FAQs page (https://aws.amazon.com/ec2/autoscaling/faqs/),
The AWS Machine Learning blog titled Understanding Amazon SageMaker notebook instance networking configurations and advanced routing options (https://aws.amazon.com/blogs/machine-learning/understanding-amazon-sagemaker-notebook-instance-networking-configurations-and-advanced-routing-options/)
The reason why the developers cannot locate the SageMaker notebook EC2 instance and its EBS volume within the corporate VPC is because SageMaker notebook instances run on a separate AWS service account, which is different from the corporate account.
Option B is the correct answer as SageMaker notebook instances run on EC2 instances running within an AWS service account. This means that SageMaker notebook instances are launched in a separate AWS account created specifically for SageMaker. This allows SageMaker to manage the underlying infrastructure and resources required to run the notebook instances, including the creation and management of the EC2 instances and EBS volumes used by the notebooks.
By default, SageMaker notebook instances are launched in a private subnet within the VPC of the AWS service account, which is separate from the VPC of the corporate account. This ensures that the notebook instances and their associated resources are isolated and secure.
To access the data stored on the EBS volume of the SageMaker notebook instance, the developers can take a snapshot of the volume and copy it to their corporate account. Alternatively, they can create a cross-account VPC peering connection between the SageMaker service account and the corporate account, which allows them to access the resources in the SageMaker account from the corporate VPC.
Option A is incorrect because SageMaker notebook instances do not run on EKS containers. EKS is a service that enables running Kubernetes clusters on AWS, while SageMaker is a managed service for building, training, and deploying machine learning models.
Option C is incorrect because SageMaker notebook instances do not run on containers within the ECS service. ECS is a container management service that allows running Docker containers on AWS.
Option D is incorrect because SageMaker notebook instances do not run on EC2 instances within the corporate account. They run on EC2 instances within a separate AWS service account created specifically for SageMaker.