Skip to content

Latest commit

 

History

History

service_control_policies

README.md

Service control policy (SCP) examples

Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. SPDX-License-Identifier: CC-BY-SA-4.0

Table of Contents

Introduction

SCPs are a type of AWS Organizations organization policy that you can use to establish the maximum access that can be delegated by account administrators to principals within your organization. SCPs allow you to enforce security invariants such as ensuring that your identities can access only company-approved data stores and that your corporate credentials can be used only from company-managed networks.

Description

This folder contains examples of SCPs that enforce resource and network perimeter controls. These examples do not represent a complete list of valid data access patterns, and they are intended for you to tailor and extend them to suit the needs of your environment.

For your network perimeter, this folder has examples of policies for enforcing controls on specific service roles and IAM principals tagged with the data-perimeter-include tag set to true. Some AWS services use service roles to perform tasks on your behalf. Some service roles are designed to be used by a service to directly call other services on your behalf as well as to make API calls from your code (for example, an AWS Lambda function role is used to publish logs to Amazon CloudWatch and to make calls to AWS APIs from the Lambda function code). Because these services allow code execution, it is possible for a user to obtain the credentials associated with a service role. Therefore, you may want to enforce the use of such credentials from expected networks only. This folder provides examples for how to achieve this with Amazon Elastic Compute Cloud (Amazon EC2). Policy examples in this folder do not enforce network perimeter controls on any other IAM principals.

Use the following example SCPs individually or in combination:

Note that the SCP examples in this repository use a deny list strategy, which means that you also need a FullAWSAccess policy or other policy attached to your AWS Organizations organization entities to allow actions. You still also need to grant appropriate permissions to your principals by using identity-based or resource-based policies.

Included data access patterns

The following policy statements are included in the SCP examples, each statement representing specific data access patterns.

"Sid":"EnforceResourcePerimeterAWSResources"

This policy statement is included in the resource_perimeter_policy and limits access to trusted resources that include AWS owned resources:

  • Resources that belong to your Organizations organization specified by the organization ID (<my-org-id>) in the policy statement.
  • Resources owned by AWS services. To permit access to AWS owned resources through the resource perimeter, two methods are used:
    • Relevant service actions are listed in the NotAction element of the policy. Actions on resources that allow cross-account access are further restricted in other statements of the policy ("Sid":"EnforceResourcePerimeterAWSResourcesS3", "Sid":"EnforceResourcePerimeterAWSResourcesSSM", "Sid":"EnforceResourcePerimeterAWSResourcesEC2ImageBuilder", "EnforceResourcePerimeterAWSResourcesECR",, "EnforceResourcePerimeterAWSResourcesLambdaLayer").
      • iam:GetPolicy, iam:GetPolicyVersion, iam:ListEntitiesForPolicy, iam:ListPolicyVersions, iam:GenerateServiceLastAccessedDetails - Required for AWS managed policies. AWS managed policies are owned by an AWS service account.
      • s3:GetObject, s3:PutObject, s3:PutObjectAcl - Required for importing and storing assets in Amazon S3 buckets, like Service Catalog CloudFormation templates, AWS Data Exchange.
      • ssm:Describe*, ssm:List*, ssm:Get*, ssm:SendCommand, ssm:CreateAssociation, ssm:StartSession, ssm:StartChangeRequestExecution, ssm:StartAutomationExecution - Required for AWS Systems Manager global parameters, documents and automation runbooks. Some AWS services publish information about common artifacts as Systems Manager public parameters. For example, Amazon EC2 publishes information about Amazon Machine Images (AMIs) as public parameters. AWS automation or custom applications may need to access Systems Manager public documents also to support their operations. The AWS Systems Manager automation runbooks, such as AWS-ConfigureMaintenanceWindows, may be needed to configure maintenance windows in AWS Systems Manager.
      • imagebuilder:GetComponent - Required for EC2 Image Builder Amazon managed AWSTOE components.
      • ecr:GetDownloadUrlForLayer, ecr:BatchGetImage - Required for Amazon Elastic Kubernetes Service (Amazon EKS) add-ons, GuardDuty EKS Runtime Monitoring, and Amazon SageMaker pre-built Docker images.
      • lambda:GetLayerVersion - Required for CloudWatch Lambda Insights extension and AWS AppConfig Agent Lambda extension.
    • ec2:Owner condition key:
      • Key value set to amazon - Required for your users and applications to be able to perform operations against public images that are owned by Amazon or a verified partner (for example, copying or launching instances using these images).
  • Trusted resources that belong to an account outside of your Organizations organization. To permit access to a resource owned by an external account through the resource perimeter, relevant service actions have to be listed in the NotAction element of this statement (<action>). These actions are further restricted in the "Sid":"EnforceResourcePerimeterThirdPartyResources".

"Sid":"EnforceResourcePerimeterAWSResourcesS3"

This policy statement is included in the resource_perimeter_policy and limits access to trusted Amazon Simple Storage Service (Amazon S3) resources:

  • Amazon S3 resources that belong to your Organizations organization as specified by the organization ID (<my-org-id>) in the policy statement.
  • Amazon S3 resources owned by AWS services that use your credentials to access those resources on your behalf. This access pattern applies when you access data via an AWS service and that service takes subsequent actions on your behalf by using your AWS Identity and Access Management (IAM) credentials. To account for this access pattern, the s3:GetObject, s3:PutObject, and s3:PutObjectAcl actions are first listed in the NotAction element of the "Sid":"EnforceResourcePerimeterAWSResources" statement. "Sid":"EnforceResourcePerimeterAWSResourcesS3" then uses the aws:CalledVia condition key to restrict these actions to AWS services only.

Example data access patterns:

"Sid": "EnforceResourcePerimeterAWSResourcesSSM"

This policy statement is included in the resource_perimeter_policy and limits access to trusted AWS Systems Manager resources:

  • AWS Systems Manager resources that belong to your Organizations organization specified by the organization ID (<my-org-id>) in the policy statement.
  • AWS Systems Manager public parameters, pre-configured documents and automation definitions owned and published by AWS services that might be accessed by your identities and applications using your IAM credentials. To account for this access pattern, ssm:Get*, ssm:SendCommand, ssm:CreateAssociation, ssm:StartSession, ssm:StartChangeRequestExecution, ssm:StartAutomationExecution are first listed in the NotAction element of the "Sid":"EnforceResourcePerimeterAWSResources" statement."Sid":"EnforceResourcePerimeterAWSResourcesSSM" then uses the aws:PrincipalTag condition key with thessm-resource-perimeter-exception tag set to true to restrict access to these actions to IAM principals tagged for access to AWS Systems Manager parameters, documents and automation defination runbooks that do not belong to your organization.

"Sid": "EnforceResourcePerimeterAWSResourcesEC2ImageBuilder"

This policy statement is included in the resource_perimeter_policy and limits access to trusted EC2 Image Builder resources:

  • EC2 Image Builder resources that belong to your Organizations organization specified by the organization ID (<my-org-id>) in the policy statement.
  • Amazon managed AWSTOE components that might be accessed by your identities and applications using your IAM credentials. To account for this access pattern, the imagebuilder:GetComponent is first listed in the NotAction element of the "Sid":"EnforceResourcePerimeterAWSResources" statement. "Sid":"EnforceResourcePerimeterAWSResourcesImageBuilder" then uses the aws:PrincipalTag condition key with imagebuilder-resource-perimeter-exception tag set to true to restrict access to these actions to IAM principals tagged for access to EC2 Image Builder resources that do not belong to your organization.

"Sid":"EnforceResourcePerimeterAWSResourcesECR"

This policy statement is included in the resource_perimeter_policy and limits access to trusted Amazon Elastic Container Registry (Amazon ECR) resources:

  • Amazon ECR repositories that belong to your Organizations organization as specified by the organization ID (<my-org-id>) in the policy statement.
  • Amazon ECR repositories owned by Amazon Elastic Kubernetes Service (Amazon EKS) that host the Docker container images for Amazon EKS add-ons. These repositories are accessed by using the IAM roles of your Amazon EKS nodes and managed node groups. To account for this access pattern, the ecr:GetDownloadUrlForLayerandecr:BatchGetImage are first listed in the NotAction element of the "Sid":"EnforceResourcePerimeterAWSResources" statement. "Sid":"EnforceResourcePerimeterAWSResourcesECR" then uses the aws:ResourceAccount condition key to restrict these actions to Amazon ECR repositories owned by the AWS service accounts. <ecr-account-id> can vary by AWS Region, and you might need to allow multiple account IDs if you are operating in multiple Regions. For a complete list of Amazon EKS managed AWS accounts that host Amazon ECR repositories, see the Amazon EKS documentation about add-on images. The account ID is the first 12 digits of the registry URL.
  • Amazon ECR repositories owned by Amazon GuardDuty that host the Docker container images for GuardDuty EKS Runtime Monitoring. These repositories are accessed by using the IAM roles of your Amazon EKS nodes and managed node groups. To account for this access pattern, the ecr:GetDownloadUrlForLayerandecr:BatchGetImage are first listed in the NotAction element of the "Sid":"EnforceResourcePerimeterAWSResources" statement. "Sid":"EnforceResourcePerimeterAWSResourcesECR" then uses the aws:ResourceAccount condition key to restrict these actions to Amazon ECR repositories owned by the AWS service accounts. <ecr-account-id> can vary by AWS Region, and you might need to allow multiple account IDs if you are operating in multiple Regions. For a complete list of Amazon GuardDuty managed AWS accounts that host Amazon ECR repositories, see the GuardDuty EKS Runtime Monitoring documentation page. The account ID is the first 12 digits of the registry URL.
  • Amazon SageMaker ECR repositories hosting Amazon SageMaker pre-built Docker images. These repositories may be accessed by the IAM roles of your SageMaker notebooks or SageMaker studio notebooks. To account for this access pattern, the ecr:GetDownloadUrlForLayerandecr:BatchGetImage are first listed in the NotAction element of the "Sid":"EnforceResourcePerimeterAWSResources" statement. "Sid":"EnforceResourcePerimeterAWSResourcesECR" then uses the aws:ResourceAccount condition key to restrict these actions to Amazon ECR repositories owned by the AWS service accounts. <ecr-account-id> can vary by AWS Region, and you might need to allow multiple account IDs if you are operating in multiple Regions. The AWS documentation has a complete list of ECR repositories host SageMaker pre-built Docker images

"Sid":"EnforceResourcePerimeterAWSResourcesLambdaLayer"

This policy statement is included in resource_perimeter_policy and limits access to trusted Lambda layers:

  • Lambda layers that belong to your AWS Organizations organization as specified by the organization ID (<my-org-id>) in the policy statement.
  • Lambda layers owned by CloudWatch for CloudWatch Lambda Insights. These layers are accessed by the IAM principal used to configure your Lambda function. To account for this access pattern, the lambda:GetLayerVersion is first listed in the NotAction element of the "Sid":"EnforceResourcePerimeterAWSResources" statement. "Sid":"EnforceResourcePerimeterAWSResourcesLambdaLayer" then uses the aws:ResourceAccount condition key to restrict these actions to Lambda layers owned by the AWS service accounts. <lambdalayer-account-id> can vary by AWS Region, and you might need to allow multiple account IDs if you are operating in multiple Regions. For a complete list of CloudWatch managed AWS accounts that host Lambda layers, see the CloudWatch Lambda Insights documentation.
  • Lambda layers owned by AWS AppConfig for AWS AppConfig Agent Lambda extension. These layers are accessed by the IAM principal used to configure your Lambda function. To account for this access pattern, the lambda:GetLayerVersion is first listed in the NotAction element of the "Sid":"EnforceResourcePerimeterAWSResources" statement. "Sid":"EnforceResourcePerimeterAWSResourcesLambdaLayer" then uses the aws:ResourceAccount condition key to restrict these actions to Lambda layers owned by the AWS service accounts. <lambdalayer-account-id> can vary by AWS Region, and you might need to allow multiple account IDs if you are operating in multiple Regions. For a complete list of AWS AppConfig managed AWS accounts that host Lambda layers, see the AWS AppConfig Agent Lambda extension.

"Sid":"EnforceResourcePerimeterThirdPartyResources"

This policy statement is included in the resource_perimeter_policy and limits access to trusted resources that include third party resources:

  • Resources that belong to your Organizations organization and are specified by the organization ID (<my-org-id>) in the policy statement.
  • Trusted resources that belong to an account outside of your Organizations organization are specified by account IDs of third parties (<third-party-account-a> and <third-party-account-b>) in the policy statement. Further restrict access by specifying allowed actions in the Action element of the policy statement. These actions also have to be listed in the NotAction element of "Sid":"EnforceResourcePerimeterAWSResources".

"Sid": "EnforceNetworkPerimeter"

This policy statement is included in the network_perimeter_policy and limits access to expected networks for IAM principals tagged with the data-perimeter-include tag set to `true. Expected networks are defined as follows:

  • Your organization’s on-premises data centers and static egress points in AWS such as NAT gateways that are specified by IP ranges (<my-corporate-cidr>) in the policy statement.
  • Your organization’s VPCs specified by VPC IDs (<my-vpc>) in the policy statement.
  • Networks of AWS services that use your credentials to access resources on your behalf as denoted by aws:ViaAWSService in the policy statement. This access pattern applies when you access data via an AWS service and that service takes subsequent actions on your behalf by using your IAM identity credentials.
  • Networks of AWS services that use service roles to access resources on your behalf. To permit access from AWS networks through the network perimeter, two methods are used:
    • Relevant service actions are listed in the NotAction element of the policy statement:
      • dax:GetItem, dax:BatchGetItem, dax:Query, dax:Scan, dax:PutItem, dax:UpdateItem, dax:DeleteItem, dax:BatchWriteItem, and dax:ConditionCheckItem – Required for Amazon DynamoDB Accelerator (DAX) operations. At runtime, the DAX client directs all of your application's DynamoDB API requests to the DAX cluster, which is designed to run in your VPC; even though these API requests originate from your VPC, they do not traverse a VPC endpoint.
      • The aws:PrincipalArn condition key:
        • The key’s value is set to arn:aws:iam::*:role/aws:ec2-infrastructure – Required for Amazon EBS volume decryption. When you mount an encrypted Amazon EBS volume to an Amazon EC2 instance, Amazon EC2 calls AWS KMS to decrypt the data key that was used to encrypt the volume. The call to AWS KMS is signed by an IAM role, arn:aws:iam::*:role/aws:ec2-infrastructure, which is created in your account by Amazon EC2.

Example data access patterns:

  • Athena query. When an application running in your VPC creates an Athena query, Athena uses the application’s credentials to make subsequent requests to Amazon S3 to read data from your bucket and return results.
  • Elastic Beanstalk operations. When a user creates an application by using Elastic Beanstalk, Elastic Beanstalk launches an environment and uses your IAM credentials to create and configure other AWS resources such as Amazon EC2 instances.
  • Amazon S3 server-side encryption with AWS KMS (SSE-KMS). When you upload an object to an Amazon S3 bucket with the default SSE-KMS encryption enabled, Amazon S3 makes a subsequent request to AWS KMS in order to generate a data key from your CMK to encrypt the object. The call to AWS KMS is signed by using your credentials. A similar pattern is observed when a user tries to download an encrypted object when Amazon S3 calls AWS KMS to decrypt the key that was used to encrypt the object. Other services such as Secrets Manager use a similar integration with AWS KMS.
  • AWS Data Exchange publishing and subscribing (described in "Sid":"EnforceResourcePerimeterAWSResourcesS3" earlier in this document).
  • AWS Service Catalog operations (described in "Sid":"EnforceResourcePerimeterAWSResourcesS3" earlier in this document).

Additionally, es:ES* is included in the NotAction element of the policy statement, which is required to use HTTP methods on Amazon OpenSearch Service domains that reside within a VPC for which security groups are the mechanism to enforce IP-based access policies.

"Sid": "EnforceNetworkPerimeterOnEC2Roles"

This policy statement is included in the network_perimeter_ec2_policy and limits access to expected networks for service roles used by Amazon EC2 instance profiles. Expected networks are defined as follows:

  • Your on-premises data centers and static egress points in AWS such as a NAT gateway that are specified by IP ranges (<my-corporate-cidr>) in the policy statement.
  • Your organization’s VPCs that are specified by VPC IDs (<my-vpc>) in the policy statement.
  • Networks of AWS services that use your credentials to access resources on your behalf as denoted by aws:ViaAWSService in the policy statement. This access pattern applies when you access data via an AWS service, and that service takes subsequent actions on your behalf by using your IAM credentials.
  • Networks of AWS services that use service roles to access resources on your behalf. To permit access from AWS networks through the network perimeter, two methods are used:
    • Relevant service actions are listed in the NotAction element of the policy statement:
      • dax:GetItem, dax:BatchGetItem, dax:Query, dax:Scan, dax:PutItem, dax:UpdateItem, dax:DeleteItem, dax:BatchWriteItem, and dax:ConditionCheckItem – Required for Amazon DynamoDB Accelerator (DAX) operations. At runtime, the DAX client directs all of your application's DynamoDB API requests to the DAX cluster, which is designed to run in your VPC; even though these API requests originate from your VPC, they do not traverse a VPC endpoint.
    • The aws:PrincipalArn condition key:
      • The key’s value is set to arn:aws:iam::*:role/aws:ec2-infrastructure – Required for Amazon EBS volume decryption. When you mount an encrypted Amazon EBS volume to an Amazon EC2 instance, Amazon EC2 calls AWS KMS to decrypt the data key that was used to encrypt the volume. The call to AWS KMS is signed by an IAM role, arn:aws:iam::*:role/aws:ec2-infrastructure, which is created in your account by Amazon EC2.

Additionally, es:ES* is included in the NotAction element of the policy statement, which is required to use HTTP methods on Amazon OpenSearch Service domains that reside in a VPC for which security groups are the mechanism to enforce IP-based access policies.

The ec2:SourceInstanceARN condition key is used to target role sessions that are created for applications running on your Amazon EC2 instances.

"Sid": "PreventRAMExternalResourceShare"

This statement is included in the data_perimeter_governance_policy_1 and denies the creation of or updates to AWS Resource Access Manager (AWS RAM) resource shares that allow sharing with external principals.

Some AWS resources allow cross-account sharing via AWS RAM instead of resource-based policies. By default, AWS RAM shares allow sharing outside of an Organizations organization. You can explicitly restrict sharing of resources outside of AWS Organizations and then limit AWS RAM actions based on this configuration.

"Sid": "PreventExternalResourceShare"

This statement is included in the data_perimeter_governance_policy_1 and restricts resource sharing by capabilities that are embedded into services.

Some AWS services use neither resource-based policies nor AWS RAM.

Example data access patterns:

  • Amazon EC2 AMI: You can share AMIs with other accounts or make them public with the ModifyImageAttribute and ModifyFPGAImageAttribute APIs.
  • Amazon EBS snapshots: You can share Amazon EBS snapshots with other accounts, or you can make them public with the ModifySnapshotAttribute API.
  • VPC endpoint connections: You can grant permissions to another account to connect to your VPC endpoint service with the ModifyVpcEndpointServicePermissions API.
  • Systems Manager documents (SSM documents): You can share SSM documents with other accounts or make them public with the ModifyDocumentPermission API.
  • Amazon RDS Snapshots: You can share RDS and RDS cluster snapshots with other accounts or make them public with the ModifyDBSnapshotAttribute and ModifyDBClusterSnapshotAttribute APIs.
  • Amazon Redshift datashare: You can authorize the sharing of a datashare with other accounts with the AuthorizeDataShare API. You can also share a snapshot with other accounts with AuthorizeSnapshotAccess API.
  • AWS Directory Service directory: You can share a directory with other accounts with the ShareDirectory API.
  • Amazon CloudWatch Logs subscription filters: You can send CloudWatch Logs to cross-account destinations with the PutSubscriptionFilter API.
  • AWS Glue Data Catalog databases: You can grant data catalog permissions to another account by using the AWS Lake Formation tag-based access control method with the GrantPermissions and BatchGrantPermissions APIs.
  • Amazon AppStream 2.0 image: You can share an Amazon AppStream 2.0 image that you own with other accounts with the UpdateImagePermissions API.
  • Amazon Macie member accounts: You can add member accounts to your Macie administrator account with the CreateInvitations API.
  • AWS Security Hub member accounts: You can create and invite a member to your Security Hub administrator account with the CreateMembers and InviteMembers APIs.
  • Amazon GuardDuty member accounts: You can create and invite a member to your GuardDuty administrator account with the CreateMembers and InviteMembers APIs.
  • AWS Audit Manager assessment framework shares: You can create a share request for a custom framework in Audit Manager with the StartAssessmentFrameworkShare API.

"Sid": "ProtectActionsNotSupportedByPrimaryDPControls"

This statement is included in data_perimeter_governance_policy_1 and restricts actions that are not supported by primary data perimeter controls, such as those listed in theResourceOrgID condition key page.

Example data access patterns:

  • Transit gateway peering connections: You can create and manage a TGW peering connection with another account with the CreateTransitGatewayPeeringAttachment, AcceptTransitGatewayPeeringAttachment, RejectTransitGatewayPeeringAttachment, and DeleteTransitGatewayPeeringAttachment APIs.
  • VPC peering connections: You can create and manage a VPC peering connection with another account with the CreateVpcPeeringConnection, AcceptVpcPeeringConnection, RejectVpcPeeringConnection, and DeleteVpcPeeringConnection APIs.
  • VPC endpoint connections: You can create and manage an endpoint service connection with another account with the CreateVpcEndpoint, AcceptVpcEndpointConnections, and RejectVpcEndpointConnections APIs.
  • Amazon EC2 AMI: You can copy an image shared from a different account with the CopyImage and CopyFpgaImage APIs.
  • Amazon EBS snapshots: You can copy a snapshot shared from a different account with the CopySnapshot API.
  • Amazon EBS volumes: You can create a volume from a snapshot shared from a different account with the CreateVolume API.
  • Amazon Route 53 private hosted zone: You can associate and manage a VPC with a private hosted zone in a different account with the CreateVPCAssociationAuthorization, AssociateVPCWithHostedZone, DisassociateVPCFromHostedZone, ListHostedZonesByVPC, and DeleteVPCAssociationAuthorization APIs.
  • Amazon Macie member accounts: You can accept a Macie membership invitation that was received from a different account with the AcceptInvitation API.
  • AWS Security Hub member accounts: You can accept a Security Hub membership invitation that was received from a different account with the AcceptAdministratorInvitation API.
  • Amazon GuardDuty member accounts: You can accept a GuardDuty membership invitation that was received from a different account with the AcceptAdministratorInvitationAPI.
  • AWS Audit Manager assessment framework shares: You can accept a share request for a custom framework from a different account with the UpdateAssessmentFrameworkShare API.
  • Amazon OpenSearch cross-cluster search connections: You can create and accept a cross-cluster search connection with a source and a destination domain in different accounts with the CreateOutboundConnection and AcceptInboundConnection APIs.

You can also consider using service-specific condition keys such as ec2:AccepterVpc and ec2:RequesterVpc to restrict actions that are not supported by primary data perimeter controls (See Work within a specific account).

"Sid": "ProtectDataPerimeterTags"

This statement is included in the data_perimeter_governance_policy_1 and prevents the attaching, detaching, and modifying of tags used for authorization controls within the data perimeter.

"Sid": "PreventS3PublicAccessBlockConfigurations"

This statement is included in the data_perimeter_governance_policy_1 and prevents users from altering S3 Block Public Access configurations.

S3 Block Public Access provides settings for access points, buckets, and accounts to help you manage public access to Amazon S3 resources. With S3 Block Public Access, account administrators and bucket owners can set up centralized controls to limit public access to their Amazon S3 resources that are enforced, regardless of how the resources are created.

"Sid": "PreventPublicBucketACL"

This statement is included in the data_perimeter_governance_policy_1 and prevents users from applying public read and public read-write canned access control lists to Amazon S3 buckets.

"Sid":"PreventLambdaFunctionURLAuthNone"

This statement is included in the data_perimeter_governance_policy_2 and denies the creation of Lambda functions that have lambda:FunctionUrlAuthType set to NONE.

Lambda function URLs is a feature that lets you add HTTPS endpoints to your Lambda functions. When configuring a function URL for a new or existing function, you can set the AuthType parameter to NONE, which means Lambda won’t check for any IAM SigV4 signatures before invoking the function. If a function’s resource-based policy explicitly allows for public access, the function is open to unauthenticated requests.

"Sid":"PreventIdPTrustModifications"

This statement is included in the data_perimeter_governance_policy_2 and prevents users from making configuration changes to the IAM SAML identity providers, IAM OIDC identity providers, and AWS IAM Roles Anywhere trust anchors.

"Sid": "PreventDeploymentCodeStarConnections"

This statement is included in the data_perimeter_governance_policy_2 and limits the use of AWS CodeStar Connections.

AWS services such as AWS CodeStar Connections do not support deployment within a VPC and provide direct access to the internet that is not controlled by your VPC. You can block the use of such services by using SCPs or implementing your own proxy solution to inspect egress traffic.

"Sid":"PreventNonVPCDeploymentSageMaker", "Sid":"PreventNonVPCDeploymentGlueJob", "Sid": "PreventNonVPCDeploymentCloudShell", and "Sid":"PreventNonVPCDeploymentLambda"

These statements are included in the data_perimeter_governance_policy_2 and explicitly deny relevant Amazon SageMaker, AWS Glue, AWS CloudShell and AWS Lambda operations unless they have VPC configurations specified in the requests. Use these statements to enforce deployment in a VPC for these services.

Services such as Lambda, AWS Glue, CloudShell, and SageMaker support different deployment models. For example, Amazon SageMaker Studio and SageMaker notebook instances allow direct internet access by default. However, they provide you with the capability to configure them to run within your VPC so that you can inspect requests by using VPC endpoint policies (against identity and resource perimeter controls) and enforce the network perimeter.