# Data protection in Amazon SQS The Amazon [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Amazon Simple Queue Service. As described in this model, Amazon is responsible for protecting the global infrastructure that runs all of the Amazon Web Services Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the Amazon Web Services services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://www.amazonaws.cn/compliance/data-privacy-faq/). For data protection purposes, we recommend that you protect Amazon Web Services account credentials and set up individual users with Amazon IAM Identity Center or Amazon Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways: + Use multi-factor authentication (MFA) with each account. + Use SSL/TLS to communicate with Amazon resources. We require TLS 1.2 and recommend TLS 1.3. + Set up API and user activity logging with Amazon CloudTrail. For information about using CloudTrail trails to capture Amazon activities, see [Working with CloudTrail trails](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *Amazon CloudTrail User Guide*. + Use Amazon encryption solutions, along with all default security controls within Amazon Web Services services. + Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3. + If you require FIPS 140-3 validated cryptographic modules when accessing Amazon through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://www.amazonaws.cn/compliance/fips/). We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with Amazon SQS or other Amazon Web Services services using the console, API, Amazon CLI, or Amazon SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server. The following sections provide information about data protection in Amazon SQS. # Data encryption in Amazon SQS Data protection refers to protecting data while in-transit (as it travels to and from Amazon SQS) and at rest (while it is stored on disks in Amazon SQS data centers). You can protect data in transit using Secure Sockets Layer (SSL) or client-side encryption. By default, Amazon SQS stores messages and files using disk encryption. You can protect data at rest by requesting Amazon SQS to encrypt your messages before saving them to the encrypted file system in its data centers. Amazon SQS recommends using SSE for optimized data encryption. **Topics** + [Encryption at rest](sqs-server-side-encryption.md) + [Key management](sqs-key-management.md) # Encryption at rest in Amazon SQS Server-side encryption (SSE) lets you transmit sensitive data in encrypted queues. SSE protects the contents of messages in queues using SQS-managed encryption keys (SSE-SQS) or keys managed in the Amazon Key Management Service (SSE-KMS). For information about managing SSE using the Amazon Web Services Management Console, see the following: + [Configuring SSE-SQS for a queue (console)](sqs-configure-sqs-sse-queue.md) + [Configuring SSE-KMS for a queue (console)](sqs-configure-sse-existing-queue.md) For information about managing SSE using the Amazon SDK for Java (and the `[CreateQueue](https://docs.amazonaws.cn/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)`, `[SetQueueAttributes](https://docs.amazonaws.cn/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)`, and `[GetQueueAttributes](https://docs.amazonaws.cn/AWSSimpleQueueService/latest/APIReference/API_GetQueueAttributes.html)` actions), see the following examples: + [Using server-side encryption with Amazon SQS queues](sqs-java-configure-sse.md) + [Configuring KMS permissions for Amazon Web Services services](sqs-key-management.md#compatibility-with-aws-services) [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/Mw1NVpJsOZc?rel=0&controls=0&showinfo=0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/Mw1NVpJsOZc?rel=0&controls=0&showinfo=0) SSE encrypts messages as soon as Amazon SQS receives them. The messages are stored in encrypted form and Amazon SQS decrypts messages only when they are sent to an authorized consumer. **Important** All requests to queues with SSE enabled must use HTTPS and [Signature Version 4](https://docs.amazonaws.cn/general/latest/gr/signature-version-4.html). Some features of Amazon services that can send notifications to Amazon SQS using the Amazon Security Token Service `[AssumeRole](https://docs.amazonaws.cn/STS/latest/APIReference/API_AssumeRole.html)` action are compatible with SSE but work *only with standard queues:* [Auto Scaling Lifecycle Hooks](https://docs.amazonaws.cn/autoscaling/ec2/userguide/lifecycle-hooks.html) [Amazon Lambda Dead-Letter Queues](https://docs.amazonaws.cn/lambda/latest/dg/dlq.html) For information about compatibility of other services with encrypted queues, see [Configure KMS permissions for Amazon services](sqs-key-management.md#compatibility-with-aws-services) and your service documentation. Amazon KMS combines secure, highly available hardware and software to provide a key management system scaled for the cloud. When you use Amazon SQS with Amazon KMS, the [data keys](#sqs-sse-key-terms) that encrypt your message data are also encrypted and stored with the data they protect. The following are benefits of using Amazon KMS: + You can create and manage [Amazon KMS keys](#sqs-sse-key-terms) yourself. + You can also use the Amazon managed KMS key for Amazon SQS, which is unique for each account and region. + The Amazon KMS security standards can help you meet encryption-related compliance requirements. For more information, see [What is Amazon Key Management Service?](https://docs.amazonaws.cn/kms/latest/developerguide/overview.html) in the *Amazon Key Management Service Developer Guide*. ## Encryption scope SSE encrypts the body of a message in an Amazon SQS queue. SSE doesn't encrypt the following: + Queue metadata (queue name and attributes) + Message metadata (message ID, timestamp, and attributes) + Per-queue metrics Encrypting a message makes its contents unavailable to unauthorized or anonymous users. With SSE enabled, anonymous `SendMessage` and `ReceiveMessage` requests to the encrypted queue will be rejected. Amazon SQS security best practices recommends against using anonymous requests. If you wish to send anonymous requests to an Amazon SQS queue, make sure you disable SSE. This doesn't affect the normal functioning of Amazon SQS: + A message is encrypted only if it is sent after the encryption of a queue is enabled. Amazon SQS doesn't encrypt backlogged messages. + Any encrypted message remains encrypted even if the encryption of its queue is disabled. Moving a message to a [dead-letter queue](sqs-dead-letter-queues.md) doesn't affect its encryption: + When Amazon SQS moves a message from an encrypted source queue to an unencrypted dead-letter queue, the message remains encrypted. + When Amazon SQS moves a message from an unencrypted source queue to an encrypted dead-letter queue, the message remains unencrypted. ## Key terms The following key terms can help you better understand the functionality of SSE. For detailed descriptions, see the *[Amazon Simple Queue Service API Reference](https://docs.amazonaws.cn/AWSSimpleQueueService/latest/APIReference/)*. **Data key** The key (DEK) responsible for encrypting the contents of Amazon SQS messages. For more information, see [Data Keys](https://docs.amazonaws.cn/kms/latest/developerguide/concepts.html#data-keys) in the *Amazon Key Management Service Developer Guide* in the *Amazon Encryption SDK Developer Guide*. **Data key reuse period** The length of time, in seconds, for which Amazon SQS can reuse a data key to encrypt or decrypt messages before calling Amazon KMS again. An integer representing seconds, between 60 seconds (1 minute) and 86,400 seconds (24 hours). The default is 300 (5 minutes). For more information, see [Understanding the data key reuse period](sqs-key-management.md#sqs-how-does-the-data-key-reuse-period-work). In the unlikely event of being unable to reach Amazon KMS, Amazon SQS continues to use the cached data key until a connection is reestablished. **KMS key ID** The alias, alias ARN, key ID, or key ARN of an Amazon managed KMS key or a custom KMS key—in your account or in another account. While the alias of the Amazon managed KMS key for Amazon SQS is always `alias/aws/sqs`, the alias of a custom KMS key can, for example, be `alias/MyAlias`. You can use these KMS keys to protect the messages in Amazon SQS queues. Keep the following in mind: + If you don't specify a custom KMS key, Amazon SQS uses the Amazon managed KMS key for Amazon SQS. + The first time you use the Amazon Web Services Management Console to specify the Amazon managed KMS key for Amazon SQS for a queue, Amazon KMS creates the Amazon managed KMS key for Amazon SQS. + Alternatively, the first time you use the `SendMessage` or `SendMessageBatch` action on a queue with SSE enabled, Amazon KMS creates the Amazon managed KMS key for Amazon SQS. You can create KMS keys, define the policies that control how KMS keys can be used, and audit KMS key usage using the **Customer managed keys** section of the Amazon KMS console or the `[CreateKey](https://docs.amazonaws.cn/kms/latest/APIReference/API_CreateKey.html)` Amazon KMS action. For more information, see [KMS keys](https://docs.amazonaws.cn/kms/latest/developerguide/concepts.html#master_keys) and [Creating Keys](https://docs.amazonaws.cn/kms/latest/developerguide/create-keys.html) in the *Amazon Key Management Service Developer Guide*. For more examples of KMS key identifiers, see [KeyId](https://docs.amazonaws.cn/kms/latest/APIReference/API_DescribeKey.html#API_DescribeKey_RequestParameters) in the *Amazon Key Management Service API Reference*. For information about finding KMS key identifiers, see [Find the Key ID and ARN](https://docs.amazonaws.cn/kms/latest/developerguide/viewing-keys.html#find-cmk-id-arn) in the *Amazon Key Management Service Developer Guide*. There are additional charges for using Amazon KMS. For more information, see [Estimating Amazon KMS costs](sqs-key-management.md#sqs-estimate-kms-usage-costs) and [Amazon Key Management Service Pricing](http://www.amazonaws.cn/kms/pricing). **Envelope Encryption** The security of your encrypted data depends in part on protecting the data key that can decrypt it. Amazon SQS uses the KMS key to encrypt the data key and then the encrypted data key is stored with the encrypted message. This practice of using a KMS key to encrypt data keys is known as envelope encryption. For more information, see [Envelope Encryption](https://docs.amazonaws.cn/encryption-sdk/latest/developer-guide/how-it-works.html#envelope-encryption) in the *Amazon Encryption SDK Developer Guide*. # Amazon SQS Key management Amazon SQS integrates with the Amazon Key Management Service (KMS) to manage [KMS keys](https://docs.amazonaws.cn/kms/latest/developerguide/concepts.html#master_keys) for server-side encryption (SSE). See [Encryption at rest in Amazon SQS](sqs-server-side-encryption.md) for SSE information and key management definitions. Amazon SQS uses KMS keys to validate and secure the data keys that encrypt and decrypt the messages. The following sections provide information about working with KMS keys and data keys in the Amazon SQS service. ## Configuring Amazon KMS permissions Every KMS key must have a key policy. Note that you cannot modify the key policy of an Amazon managed KMS key for Amazon SQS. The policy for this KMS key includes permissions for all principals in the account (that are authorized to use Amazon SQS) to use encrypted queues. Amazon SQS distinguishes between callers based on their Amazon credentials, whether they are using different Amazon accounts, IAM users, or IAM roles. Additionally, the same IAM role with different scoping policies will be treated as distinct requesters. However, when using IAM role sessions, varying only the `RoleSessionName` while keeping the same IAM role and scoping policies will not create distinct requesters. Therefore, when specifying Amazon KMS key policy principals, avoid relying on `RoleSessionName` differences alone, as these sessions will be treated as the same requester. Alternatively, you can specify the required permissions in an IAM policy assigned to the principals that produce and consume encrypted messages. For more information, see [Using IAM Policies with Amazon KMS](https://docs.amazonaws.cn/kms/latest/developerguide/iam-policies.html) in the *Amazon Key Management Service Developer Guide*. **Note** While you can configure global permissions to send to and receive from Amazon SQS, Amazon KMS requires explicitly naming the full ARN of KMS keys in specific regions in the `Resource` section of an IAM policy. ### Configure KMS permissions for Amazon services Several Amazon services act as event sources that can send events to Amazon SQS queues. To allow these event sources to work with encrypted queues, you must create a customer managed KMS key and add permissions in the key policy for the service to use the required Amazon KMS API methods. Perform the following steps to configure the permissions. **Warning** When changing the KMS key for encrypting your Amazon SQS messages, be aware that existing messages encrypted with the old KMS key will remain encrypted with that key. To decrypt these messages, you must retain the old KMS key and ensure that its key policy grants Amazon SQS the permissions for `kms:Decrypt` and `kms:GenerateDataKey`. After updating to a new KMS key for encrypting new messages, ensure all existing messages encrypted with the old KMS key are processed and removed from the queue before deleting or disabling the old KMS key. 1. Create a customer managed KMS key. For more information, see [Creating Keys](https://docs.amazonaws.cn/kms/latest/developerguide/create-keys.html) in the *Amazon Key Management Service Developer Guide*. 1. To allow the Amazon service event source to use the `kms:Decrypt` and `kms:GenerateDataKey` API methods, add the following statement to the KMS key policy. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Service": "service.amazonaws.com" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "*" }] } ``` ------ Replace "service" in the above example with the *Service name* of the event source. Event sources include the following services. [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-key-management.html) 1. [Configure an existing SSE queue](sqs-configure-sse-existing-queue.md) using the ARN of your KMS key. 1. Provide the ARN of the encrypted queue to the event source. ### Configure Amazon KMS permissions for producers When the [data key reuse period](#sqs-how-does-the-data-key-reuse-period-work) expires, the producer's next call to `SendMessage` or `SendMessageBatch` also triggers calls to `kms:Decrypt` and `kms:GenerateDataKey`. The call to `kms:Decrypt` is to verify the integrity of the new data key before using it. Therefore, the producer must have the `kms:Decrypt` and `kms:GenerateDataKey` permissions for the KMS key. Add the following statement to the IAM policy of the producer. Remember to use the correct ARN values for the key resource and the queue resource. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "arn:aws-cn:kms:us-east-2:123456789012:key/111112222233333" }, { "Effect": "Allow", "Action": [ "sqs:SendMessage" ], "Resource": "arn:aws-cn:sqs:*:123456789012:MyQueue" } ] } ``` ------ ### Configure Amazon KMS permissions for consumers When the data key reuse period expires, the consumer's next call to `ReceiveMessage` also triggers a call to `kms:Decrypt`, to verify the integrity of the new data key before using it. Therefore, the consumer must have the `kms:Decrypt` permission for any KMS key that is used to encrypt the messages in the specified queue. If the queue acts as a [dead-letter queue](sqs-dead-letter-queues.md), the consumer must also have the `kms:Decrypt` permission for any KMS key that is used to encrypt the messages in the source queue. Add the following statement to the IAM policy of the consumer. Remember to use the correct ARN values for the key resource and the queue resource. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "arn:aws-cn:kms:us-east-2:123456789012:key/111112222233333" }, { "Effect": "Allow", "Action": [ "sqs:ReceiveMessage" ], "Resource": "arn:aws-cn:sqs:*:123456789012:MyQueue" } ] } ``` ------ ### Configure Amazon KMS permissions with confused deputy protection When the principal in a key policy statement is an [Amazon service principal](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services), you can use the [https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) or [https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition keys to protect against the [confused deputy scenario](https://docs.amazonaws.cn/IAM/latest/UserGuide/confused-deputy.html). To use these condition keys, set the value to the Amazon Resource Name (ARN) of the resource that is being encrypted. If you don't know the ARN of the resource, use `aws:SourceAccount` instead. In this KMS key policy, a specific resource from *service* that is owned by account `111122223333` is allowed to call KMS for `Decrypt` and `GenerateDataKey` actions, which occur during SSE usage of Amazon SQS. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "sqs.amazonaws.com" }, "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "*", "Condition": { "ArnEquals": { "aws:SourceArn": [ "arn:aws-cn:sqs:us-west-1:111122223333:resource" ] } } } ] } ``` ------ When using SSE enabled Amazon SQS queues, the following services support `aws:SourceArn`: + Amazon SNS + Amazon S3 + CloudWatch Events + Amazon Lambda + CodeBuild + Amazon Connect Customer Profiles + Amazon Auto Scaling + Amazon Chime ## Understanding the data key reuse period The [ data key reuse period](sqs-server-side-encryption.md#sqs-sse-key-terms) defines the maximum duration for Amazon SQS to reuse the same data key. When the data key reuse period ends, Amazon SQS generates a new data key. Note the following guidelines about the reuse period. + A shorter reuse period provides better security but results in more calls to Amazon KMS, which might incur charges beyond the Free Tier. + Although the data key is cached separately for encryption and for decryption, the reuse period applies to both copies of the data key. + When the data key reuse period ends, the next call to `SendMessage` or `SendMessageBatch` typically triggers a call to the Amazon KMS `GenerateDataKey` method to get a new data key. Also, the next calls to `SendMessage` and `ReceiveMessage` will each trigger a call to Amazon KMS `Decrypt` to verify the integrity of the data key before using it. + [Principals](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_elements.html#Principal) (Amazon Web Services accounts or users) don't share data keys (messages sent by unique principals always get unique data keys). Therefore, the volume of calls to Amazon KMS is a multiple of the number of unique principals in use during the data key reuse period. ## Estimating Amazon KMS costs To predict costs and better understand your Amazon bill, you might want to know how often Amazon SQS uses your KMS key. **Note** Although the following formula can give you a very good idea of expected costs, actual costs might be higher because of the distributed nature of Amazon SQS. To calculate the number of API requests (`R`) *per queue*, use the following formula: ``` R = (B / D) * (2 * P + C) ``` `B` is the billing period (in seconds). `D` is the [data key reuse period](sqs-server-side-encryption.md#sqs-sse-key-terms) (in seconds). `P` is the number of producing [principals](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_elements.html#Principal) that send to the Amazon SQS queue. `C` is the number of consuming principals that receive from the Amazon SQS queue. **Important** In general, producing principals incur double the cost of consuming principals. For more information, see [Understanding the data key reuse period](#sqs-how-does-the-data-key-reuse-period-work). If the producer and consumer have different users, the cost increases. The following are example calculations. For exact pricing information, see [Amazon Key Management Service Pricing](http://www.amazonaws.cn/kms/pricing/). ### Example 1: Calculating the number of Amazon KMS API calls for 2 principals and 1 queue This example assumes the following: + The billing period is January 1-31 (2,678,400 seconds). + The data key reuse period is set to 5 minutes (300 seconds). + There is 1 queue. + There is 1 producing principal and 1 consuming principal. ``` (2,678,400 / 300) * (2 * 1 + 1) = 26,784 ``` ### Example 2: Calculating the number of Amazon KMS API calls for multiple producers and consumers and 2 queues This example assumes the following: + The billing period is February 1-28 (2,419,200 seconds). + The data key reuse period is set to 24 hours (86,400 seconds). + There are 2 queues. + The first queue has 3 producing principals and 1 consuming principal. + The second queue has 5 producing principals and 2 consuming principals. ``` (2,419,200 / 86,400 * (2 * 3 + 1)) + (2,419,200 / 86,400 * (2 * 5 + 2)) = 532 ``` ## Amazon KMS errors When you work with Amazon SQS and Amazon KMS, you might encounter errors. The following references describe the errors and possible troubleshooting solutions. + [ Common Amazon KMS errors](https://docs.amazonaws.cn/kms/latest/APIReference/CommonErrors.html) + [Amazon KMS Decrypt errors](https://docs.amazonaws.cn/kms/latest/APIReference/API_Decrypt.html#API_Decrypt_Errors) + [Amazon KMS GenerateDataKey errors](https://docs.amazonaws.cn/kms/latest/APIReference/API_GenerateDataKey.html#API_GenerateDataKey_Errors) # Internetwork traffic privacy in Amazon SQS An Amazon Virtual Private Cloud (Amazon VPC) endpoint for Amazon SQS is a logical entity within a VPC that allows connectivity only to Amazon SQS. The VPC routes requests to Amazon SQS and routes responses back to the VPC. The following sections provide information about working with VPC endpoints and creating VPC endpoint policies. ## Amazon Virtual Private Cloud endpoints for Amazon SQS If you use Amazon VPC to host your Amazon resources, you can establish a connection between your VPC and Amazon SQS. You can use this connection to send messages to your Amazon SQS queues without crossing the public internet. Amazon VPC lets you launch Amazon resources in a custom virtual network. You can use a VPC to control your network settings, such as the IP address range, subnets, route tables, and network gateways. For more information about VPCs, see the *[Amazon VPC User Guide](https://docs.amazonaws.cn/vpc/latest/userguide/)*. To connect your VPC to Amazon SQS, you must first define an *interface VPC endpoint*, which lets you connect your VPC to other Amazon services. The endpoint provides reliable, scalable connectivity to Amazon SQS without requiring an internet gateway, network address translation (NAT) instance, or VPN connection. For more information, see [Tutorial: Sending a message to an Amazon SQS queue from Amazon Virtual Private Cloud](sqs-sending-messages-from-vpc.md) and [Example 5: Deny access if it isn't from a VPC endpoint](sqs-creating-custom-policies-access-policy-examples.md#deny-not-from-vpc) in this guide and [Interface VPC Endpoints (Amazon PrivateLink)](https://docs.amazonaws.cn/vpc/latest/userguide/vpce-interface.html) in the *Amazon VPC User Guide*. **Important** You can use Amazon Virtual Private Cloud only with HTTPS Amazon SQS endpoints. When you configure Amazon SQS to send messages from Amazon VPC, you must enable private DNS and specify endpoints in the format `sqs.us-east-2.amazonaws.com` or `sqs.us-east-2.api.aws` for the dual-stack endpoint. Amazon SQS also supports FIPS endpoints through PrivateLink using the `com.amazonaws.region.sqs-fips` endpoint service. You can connect to FIPS endpoints in the format `sqs-fips.region.amazonaws.com`. When using the dual-stack endpoint in Amazon Virtual Private Cloud, requests will be sent using IPv4 and IPv6. Private DNS doesn't support legacy endpoints such as `queue.amazonaws.com` or `us-east-2.queue.amazonaws.com`. ## Creating an Amazon VPC endpoint policy for Amazon SQS You can create a policy for Amazon VPC endpoints for Amazon SQS in which you specify the following: + The principal that can perform actions. + The actions that can be performed. + The resources on which actions can be performed. For more information, see [Controlling Access to Services with VPC Endpoints](https://docs.amazonaws.cn/vpc/latest/userguide/vpc-endpoints-access.html) in the *Amazon VPC User Guide* The following example VPC endpoint policy specifies that the user `MyUser` is allowed to send messages to the Amazon SQS queue `MyQueue`. ``` { "Statement": [{ "Action": ["sqs:SendMessage"], "Effect": "Allow", "Resource": "arn:aws:sqs:us-east-2:123456789012:MyQueue", "Principal": { "AWS": "arn:aws:iam:123456789012:user/MyUser" } }] } ``` The following are denied: + Other Amazon SQS API actions, such as `sqs:CreateQueue` and `sqs:DeleteQueue`. + Other users and rules which attempt to use this VPC endpoint. + `MyUser` sending messages to a different Amazon SQS queue. **Note** The user can still use other Amazon SQS API actions from *outside* the VPC. For more information, see [Example 5: Deny access if it isn't from a VPC endpoint](sqs-creating-custom-policies-access-policy-examples.md#deny-not-from-vpc). # Connect to Amazon SQS using Dual-stack (IPv4 and IPv6) endpoints Dual-stack endpoints support both IPv4 and IPv6 traffic. When you make a request to a dual-stack endpoint, the endpoint URL resolves to an IPv4 or an IPv6 address. For more information on dual-stack and FIPS endpoints, see the [SDK Reference guide](https://docs.amazonaws.cn/sdkref/latest/guide/feature-endpoints.html). Amazon SQS supports Regional dual-stack endpoints, which means that you must specify the Amazon Region as part of the endpoint name. Dual-stack endpoint names use the following naming convention: `sqs.Region.amazonaws.com`. For example, the dual-stack endpoint name for the `eu-west-1` Region is `sqs.eu-west-1.amazonaws.com`. For the full list of Amazon SQS endpoints, see the [Amazon General Reference](https://docs.amazonaws.cn/general/latest/gr/sqs-service.html).