Skip to content

Cross-Account and Cross-Region Access

LocalStack automatically namespaces all resources based on the account ID and, in some cases, the region. However, there are certain resource types that can be accessed across multiple accounts or regions. This document provides information to help design such setups.

Cross-account/cross-region access happens when a client attempts to access a resource in another account or region than what it is configured with:

Terminal window
# Create a queue in one account and region
AWS_ACCESS_KEY_ID=111111111111 awslocal sqs create-queue \
--queue-name my-queue \
--region ap-south-1
Output
{
"QueueUrl": "http://sqs.ap-south-1.localhost.localstack.cloud:443/111111111111/my-queue"
}
Terminal window
# Set some attributes
AWS_ACCESS_KEY_ID=111111111111 awslocal sqs set-queue-attributes \
--attributes VisibilityTimeout=60 \
--queue-url http://sqs.ap-south-1.localhost.localstack.cloud:443/111111111111/my-queue \
--region ap-south-1
# Retrieve the queue attribute from another account and region
# The required information for LocalStack to locate the queue is available in the queue URL
AWS_ACCESS_KEY_ID=222222222222 awslocal sqs get-queue-attributes \
--attribute-names VisibilityTimeout \
--region eu-central-1 \
--queue-url http://sqs.ap-south-1.localhost.localstack.cloud:443/111111111111/my-queue
Output
{
"Attributes": {
"VisibilityTimeout": "60"
}
}

Resources that can be accessed across accounts are identified by their Amazon Resource Names (ARNs) or other schemes such as SQS Queue URLs. The full list of resources and operations that allow cross-account access are listed below.

It is possible to create peered VPCs and transit gateway peering attachments that are in a different region or account than the requester. Ensure that the PeerRegion and PeerOwnerId arguments are correctly set when creating these resources.

  • CreateGrant
  • Decrypt
  • DescribeKey
  • Encrypt
  • GenerateDataKey
  • GenerateDataKeyPair
  • GenerateDataKeyPairWithoutPlaintext
  • GenerateDataKeyWithoutPlaintext
  • GenerateMac
  • GetKeyRotationStatus
  • GetPublicKey
  • ListGrants
  • RetireGrant
  • RevokeGrant
  • Sign
  • Verify
  • VerifyMac
  • AddLayerVersionPermission
  • CreateAlias
  • DeleteAlias
  • DeleteFunction
  • DeleteFunctionConcurrency
  • DeleteLayerVersion
  • GetAlias
  • GetFunction
  • GetFunctionConfiguration
  • GetLayerVersion
  • GetLayerVersionByArn
  • GetLayerVersionPolicy
  • GetPolicy
  • Invoke
  • ListAliases
  • ListLayerVersions
  • ListTags
  • ListVersionsByFunction
  • PublishVersion
  • PutFunctionConcurrency
  • RemoveLayerVersionPermission
  • TagResource
  • UntagResource
  • UpdateAlias
  • UpdateFunctionCode

Like AWS, LocalStack S3 has a bucket namespace which is shared by all accounts. This means that the bucket name has to be globally unique.

  • GetObject
  • ListObjects
  • PutObject
  • DeleteSecret
  • DescribeSecret
  • GetResourcePolicy
  • GetSecretValue
  • ListSecretVersionIds
  • PutResourcePolicy
  • PutSecretValue
  • RestoreSecret
  • TagResource
  • UntagResource
  • UpdateSecret
  • AddPermission
  • DeleteTopic
  • GetTopicAttributes
  • ListSubscriptionByTopic
  • Publish
  • RemovePermission
  • SetTopicAttributes
  • Subscribe

On AWS, all operations except AddPermission, CreateQueue, DeleteQueue, ListQueues, ListQueueTags, RemovePermission, SetQueueAttributes, TagQueue and UntagQueue allow cross-account access.

On LocalStack, all operations allow cross-account access.

AWS provides individual API endpoints for each region, and typically, resources can only be accessed within their respective regions.

On the other hand, LocalStack operates on a unified API endpoint, allowing interactions with services across regions.