For similar capabilities to Amazon Timestream for LiveAnalytics, consider Amazon Timestream for InfluxDB. It offers simplified data ingestion and single-digit millisecond query response times for real-time analytics. Learn more [here](https://docs.amazonaws.cn//timestream/latest/developerguide/timestream-for-influxdb.html). # Security in Timestream for InfluxDB Security Cloud security at Amazon is the highest priority. As an Amazon customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations. Security is a shared responsibility between Amazon and you. The [shared responsibility model](http://www.amazonaws.cn/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud: + **Security of the cloud** – Amazon is responsible for protecting the infrastructure that runs Amazon services in the Amazon Cloud. Amazon also provides you with services that you can use securely. The effectiveness of our security is regularly tested and verified by third-party auditors as part of the [Amazon compliance programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to Timestream for InfluxDB, see [Amazon Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). + **Security in the cloud** – Your responsibility is determined by the Amazon service that you use. You are also responsible for other factors including the sensitivity of your data, your organization's requirements, and applicable laws and regulations. This documentation will help you understand how to apply the shared responsibility model when using Timestream for InfluxDB. The following topics show you how to configure Timestream for InfluxDB to meet your security and compliance objectives. You'll also learn how to use other Amazon services that can help you to monitor and secure your Timestream for InfluxDB resources. **Topics** + [ # Overview ](timestream-for-influx-security.md) + [ # Database authentication with Amazon Timestream for InfluxDB ](timestream-for-influx-security-db-authentication.md) + [ # How Amazon Timestream for InfluxDB uses secrets ](timestream-for-influx-security-db-secrets.md) + [ # Data protection in Timestream for InfluxDB ](data-protection-for-influx-db.md) + [ # Identity and Access Management for Amazon Timestream for InfluxDB ](security-iam-for-influxdb.md) + [ # Logging and monitoring in Timestream for InfluxDB ](monitoring-influxdb.md) + [ # Compliance validation for Amazon Timestream for InfluxDB ](timestream-compliance.md) + [ # Resilience in Amazon Timestream for InfluxDB ](disaster-recovery-resiliency-influxdb.md) + [ # Infrastructure security in Amazon Timestream for InfluxDB ](infrastructure-security-influxdb.md) + [ # Configuration and vulnerability analysis in Timestream for InfluxDB ](ConfigAndVulnerability-timestream-for-influxdb.md) + [ # Incident response in Timestream for InfluxDB ](IncidentResponse-timestream-for-influxdb.md) + [ # Amazon Timestream for InfluxDB API and interface VPC endpoints (Amazon PrivateLink) ](timestream-influxb-privatelink.md) + [ # Security best practices for Timestream for InfluxDB ](security-best-practices.md) # Overview Overview This documentation helps you understand how to apply the [shared responsibility model](https://www.amazonaws.cn/compliance/shared-responsibility-model/) when using Amazon Timestream for InfluxDB. The following topics show you how to configure Amazon Timestream for InfluxDB to meet your security and compliance objectives. You also learn how to use other Amazon services that help you monitor and secure your Amazon Timestream for InfluxDB resources. You can manage access to your Amazon Timestream for InfluxDB resources and your databases on a DB instance. The method you use to manage access depends on what type of task the user needs to perform with Amazon Timestream for InfluxDB: + Run your DB instance in a Virtual Private Cloud (VPC) based on the Amazon VPC service for network access control. + Use Amazon Identity and Access Management (IAM) policies to assign permissions that determine who is allowed to manage Amazon Timestream for InfluxDB resources. For example, you can use IAM to determine who is allowed to create, describe, modify, and delete DB instances, tag resources, or modify security groups. + Use security groups to control what IP addresses or Amazon EC2 instances can connect to your databases on a DB instance. When you first create a DB instance, it's only accessible through rules specified by an associated security group. + Use Secure Socket Layer (SSL) or Transport Layer Security (TLS) connections with your DB instances. + Use the security features of your InfluxDB engine to control who can log in to the databases on a DB instance. These features work just as if the database was on your local network. For more information, see [Security in Timestream for InfluxDB](security-timestream-for-influxdb.md). **Note** You have to configure security only for your use cases. You don't have to configure security access for processes that Amazon Timestream for InfluxDB manages. These include creating backups, replicating data between a primary DB instance and a read replica, and other processes. **Topics** + [ # General security ](timestream-for-influx-getting-started-security.md) # General security General security **Topics** + [ ## Permissions ](#timestream-for-influx-getting-started-security-permissions) + [ ## Network access ](#timestream-for-influx-getting-started-security-network-access) + [ ## Dependencies ](#timestream-for-influx-getting-started-security-dependencies) + [ ## S3 buckets ](#timestream-for-influx-getting-started-security-s3-buckets) ## Permissions Permissions InfluxDB users should be granted least-privilege permissions. Only tokens granted to specific users, instead of operator tokens, should be used during migration. Timestream for InfluxDB uses IAM permissions to control user permissions. We recommend users be granted access to the specific actions and resources that they require. For more information, see [Grant least privilege access](https://docs.amazonaws.cn/wellarchitected/2022-03-31/framework/sec_permissions_least_privileges.html). ## Network access Network access The Influx migration script can function locally, migrating data between two InfluxDB instances on the same system, but it is assumed that the primary use case for migrations will be migrating data across the network, either a local or public network. With this comes security considerations. The Influx migration script will, by default, verify TLS certificates for instances with TLS enabled: we recommend that users enable TLS in their InfluxDB instances and do not use the `--skip-verify` option for the script. We recommend you use an allow-list to restrict network traffic to be from sources you are expecting. You can do this by limiting network traffic to the InfluxDB instances only from known IPs. ## Dependencies Dependencies The latest major versions of all dependencies should be used, including Influx CLI, InfluxDB, Python, the Requests module, and optional dependencies such as `mountpoint-s3` and `rclone`. ## S3 buckets S3 buckets If S3 buckets are used as a temporary storage for migration, we recommend enabling TLS, versioning, and disabling public access. **Using S3 buckets for migration** 1. Open the Amazon Web Services Management Console, navigate to **Amazon Simple Storage Service** and then choose **Buckets**. 1. Choose the bucket you wish to use. 1. Choose the **Permissions** tab. 1. Under **Block public access (bucket settings)**, choose **Edit**. 1. Check **Block all public access**. 1. Choose **Save changes**. 1. Under **Bucket policy**, choose **Edit**. 1. Enter the following, replacing ** with your bucket name, to enforce the use of TLS version 1.2 or later for connections: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EnforceTLSv12orHigher", "Principal": { "AWS": "*" }, "Action": [ "s3:*" ], "Effect": "Deny", "Resource": [ "arn:aws-cn:s3:::/*", "arn:aws-cn:s3:::" ], "Condition": { "NumericLessThan": { "s3:TlsVersion": 1.2 } } } ] } ``` ------ 1. Choose **Save changes**. 1. Choose the **Properties** tab. 1. Under **Bucket Versioning**, choose **Edit**. 1. Check **Enable**. 1. Choose **Save changes**. For information about Amazon S3 bucket best security practices, see [Security best practices for Amazon Simple Storage Service](https://docs.amazonaws.cn/AmazonS3/latest/userguide/security-best-practices.html). # Database authentication with Amazon Timestream for InfluxDB Database authentication with Amazon Timestream for InfluxDB Amazon Timestream for InfluxDB supports two ways to authenticate database users. Password and access Token database authentication use different methods of authenticating to the database. Therefore, a specific user can log in to a database using only one authentication method. In both cases InfluxDB performs all administration of user accounts and API tokens. ## Password authentication Password authentication During the InfluxDB DB instance creation process, you created an organization, user and password. The user has permissions to manage everything in your Timestream for InfluxDB DB instance. With this username and password combination you will be able to LogIn into your instance using the InfluxUI and also use the InfluxCLI to generate an operator token. An operator token is required to create users, delete buckets , organizations etc. For more information, see [Database authentication options](timestream-for-influx-db-connecting.md#timestream-for-influx-db-connecting-authentication-options). ## API tokens Token authentication InfluxDB API tokens ensure secure interaction between InfluxDB and external tools such as clients or applications. An API token belongs to a specific user and identifies InfluxDB permissions within the user’s organization. There are three types of API tokens in InfluxDB: + Operator Token: Grants full read and write access to all organizations and all organization resources in InfluxDB OSS 2.x. Some operations, for example, retrieving the server configuration, require operator permissions. To create an operator token manually with the InfluxDB UI, `api/v2` API, or Influx CLI after the setup process is completed, you must use an existing operator token or your username and password. To create a new operator token without using an existing one, see the [influxd recovery auth](https://docs.influxdata.com/influxdb/v2/reference/cli/influxd/recovery/auth/) CLI. **Important** Because operator tokens have full read and write access to all organizations in the database, we recommend [creating an All-Access token](https://docs.influxdata.com/influxdb/v2/admin/tokens/create-token/) for each organization and using those to manage InfluxDB. This helps to prevent accidental interactions across organizations. + All-Access API Token: Grants full read and write access to all resources in an organization. + Read/Write Tokens: Grants read access, write access, or both to specific buckets in an organization. All InfluxDb tokens are long lived tokens with no set expiration date, so it is not recommended to use your operator or all access tokens to sent monitoring data from your clients or Telegraf agents neither to embed them in your dashboarding applications. For these applications create read/write tokens with just the necessary permissions to get the job done. Fo more information on how to create influxDB token, see [Create a token](https://docs.influxdata.com/influxdb/v2/admin/tokens/create-token/). ## Secrets Secrets InfluxDB operator tokens are generated on instance setup; other kinds of tokens, such as all-access and read/write tokens, can be created using the [Influx CLI](https://docs.influxdata.com/influxdb/v2/tools/influx-cli/), Influx v2 API, or the Timestream for InfluxDB Multi-user rotation function. See [Manage API tokens](https://docs.influxdata.com/influxdb/v2/admin/tokens/) for how to generate, view, assign, and delete tokens. We recommend that you rotate Timestream for InfluxDB tokens often using Amazon Secrets Manager and store tokens via environment variables. See [Use Tokens](https://docs.influxdata.com/influxdb/cloud/admin/tokens/use-tokens/#add-a-token-to-a-cli-request) for token usage in environment variables and [Rotating the secret](timestream-for-influx-security-db-secrets.md#timestream-for-influx-security-db-secrets-rotation) for how to rotate Timestream for InfluxDB users and tokens. **See also:** + [Infrastructure security in Amazon Timestream for InfluxDB](infrastructure-security-influxdb.md) + [Security best practices for Timestream for InfluxDB](security-best-practices.md) # How Amazon Timestream for InfluxDB uses secrets How Timestream for InfluxDB uses secrets Timestream for InfluxDB supports username and password authentication through the user interface, and token credentials for least privilege client and application connections. Timestream for InfluxDB users have `allAccess` permissions within their organization while tokens can have any set of permissions. Following best practices for secure API token management, users should be created to manage tokens for fine-grain access within an organization. Additional information on admin best practices with Timestream for InfluxDB can be found in the [Influxdata documentation](https://docs.influxdata.com/influxdb/v2/admin/tokens/create-token/). Amazon Secrets Manager is a secret storage service that you can use to protect database credentials, API keys, and other secret information. Then in your code, you can replace hardcoded credentials with an API call to Secrets Manager. This helps ensure that the secret can't be compromised by someone examining your code, because the secret isn't there. For an overview of Secrets Manager, see [What is Amazon Secrets Manager](https://docs.amazonaws.cn/secretsmanager/latest/userguide/intro.html). When you create a database instance, Timestream for InfluxDB automatically creates an admin secret for you to use with the multi-user rotation Amazon Lambda function. In order to rotate Timestream for InfluxDB users and tokens, you must create a new secret by hand for each user or token you wish to rotate. Each secret can be configured to rotate on a schedule with the use of a Lambda function. The process to setup a new rotating secret consists of uploading the Lambda function code, configuring the Lambda role, defining the new secret, and configuring the secret rotation schedule. ## What's in the secret What's in the secret When you store Timestream for InfluxDB user credentials in the secret, use the following format. Single-user: ``` { "engine": "", "username": "", "password": "", "dbIdentifier": "" } ``` When you create a Timestream for InfluxDB instance, an admin secret is automatically stored in Secrets Manager with credentials to be used with the multi-user Lambda function. Set the `adminSecretArn` to the `Authentication Properties Secret Manager ARN` value found on the DB instance summary page or to the ARN of an admin secret. To create a new admin secret you must already have the associated credentials and the credentials must have admin privileges. When you store Timestream for InfluxDB token credentials in the secret, use the following format. Multi-user: ``` { "engine": "", "org": "", "adminSecretArn": "", "type": "", "dbIdentifier": "", "token": "", "writeBuckets": "", "readBuckets": "", "permissions": "" } ``` When you store Timestream for InfluxDB admin credentials in the secret, use the following format: Admin secret: ``` { "engine": "", "username": "", "password": "", "dbIdentifier": "", "organization": "", "bucket": "" } ``` To turn on automatic rotation for the secret, the secret must be in the correct JSON structure. See [Rotating the secret](#timestream-for-influx-security-db-secrets-rotation) for how to rotate Timestream for InfluxDB secrets. ## Modifying the secret Modifying the secret The credentials generated during the Timestream for InfluxDB instance creation process are stored in a Secrets Manager secret in your account. The [GetDbInstance](https://docs.amazonaws.cn/ts-influxdb/latest/ts-influxdb-api/API_GetDbInstance.html) response object contains an `influxAuthParametersSecretArn` which holds the Amazon Resource Name (ARN) to such secret. The secret will only be populated after your Timestream for InfluxDB instance is available. This is a READONLY copy as any updates/modifications/deletions to this secret doesn't impact the created DB instance. If you delete this secret, the [API response](https://docs.amazonaws.cn/ts-influxdb/latest/ts-influxdb-api/API_GetDbInstance.html#API_GetDbInstance_ResponseSyntax) will still refer to the deleted secret ARN. To create a new token in the Timestream for InfluxDB instance rather than store existing token credentials, you can create non-operator tokens by leaving the `token` value blank in the secret and using the multi-user rotation function with the `AUTHENTICATION_CREATION_ENABLED` Lambda environment variable set to `true`. If you create a new token, the permissions defined in the secret are assigned to the token and cannot be altered after the first successful rotation. For more information on rotating secrets, see [Rotating Amazon Secrets Manager Secrets](https://docs.amazonaws.cn/secretsmanager/latest/userguide/rotating-secrets.html). If a secret is deleted, the associated user or token in the Timestream for InfluxDB instance will not be deleted. ## Rotating the secret Rotating the secret You use the Timestream for InfluxDB single- and multi-user rotation Lambda functions to rotate Timestream for InfluxDB user and token credentials. Use the single-user Lambda function to rotate user credentials for your Timestream for InfluxDB instance, and use the multi-user Lambda function to rotate token credentials for your Timestream for InfluxDB instance. Rotating users and tokens with the single- and multi-user Lambda functions is optional. Timestream for InfluxDB credentials never expire and any exposed credentials pose a risk for malicious actions against your DB instance. The advantage of rotating Timestream for InfluxDB credentials with Secrets Manager is an added security layer which limits the attack vector of exposed credentials to the window of time until the next rotation cycle. If no rotation mechanism is in place for your DB instance, any exposed credentials will be valid until they are manually deleted. You can configure Secrets Manager to automatically rotate secrets for you according to a schedule that you specify. This enables you to replace long-term secrets with short-term ones, which helps to significantly reduce the risk of compromise. For more information on rotating secrets with Secrets Manager, see [Rotate Amazon Secrets Manager Secrets](https://docs.amazonaws.cn/secretsmanager/latest/userguide/rotating-secrets.html). ### Rotating users Rotating users When you rotate users with the single-user Lambda function, a new random password will be assigned to the user after each rotation. For more information on how to enable automatic rotation, see [Set up automatic rotation for non-database Amazon Secrets Manager secrets](https://docs.amazonaws.cn/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.html). #### Rotating admin secrets Rotating admin secrets To rotate an admin secret you use the single-user rotation function. You need to add the `engine` and `dbIdentifier` values to the secret since those values are not automatically populated on DB initialization. See [What's in the secret](#timestream-for-influx-security-db-secrets-definition) for the complete secret template. To locate an admin secret for a Timestream for InfluxDB instance you use the admin secret ARN from the Timestream for InfluxDB instance summary page. It is recommended that you rotate all Timestream for InfluxDB admin secrets since admin users have elevated permissions for the Timestream for InfluxDB instance. #### Lambda rotation function Lambda rotation function You can rotate a Timestream for InfluxDB user with the single-user rotation function by using the [What's in the secret](#timestream-for-influx-security-db-secrets-definition) with a new secret and adding the required fields for your Timestream for InfluxDB user. For more information on secret rotation Lambda functions, see [Rotation by Lambda function](https://docs.amazonaws.cn/secretsmanager/latest/userguide/rotate-secrets_lambda.html). You can rotate a Timestream for InfluxDB user with the single-user rotation function by using the [What's in the secret](#timestream-for-influx-security-db-secrets-definition) with a new secret and adding the required fields for your Timestream for InfluxDB user. For more information on secret rotation Lambda functions, see [Rotation by Lambda function](https://docs.amazonaws.cn/secretsmanager/latest/userguide/rotate-secrets_lambda.html). The single user rotation function authenticates with the Timestream for InfluxDB DB instance using the credentials defined in the secret, then generates a new random password and sets the new password for the user. For more information on secret rotation Lambda functions, see [Rotation by Lambda function](https://docs.amazonaws.cn/secretsmanager/latest/userguide/rotate-secrets_lambda.html). #### Lambda function execution role permissions Lambda function execution role permissions Use the following IAM policy as the role for the single-user Lambda function. The policy gives the Lambda function the required permissions to perform a secret rotation for Timestream for InfluxDB users. Replace all items listed below in the IAM policy with values from your Amazon account: + **\$1rotating\$1secret\$1arn\$1** — The ARN for the secret being rotated can be found in the Secrets Manager secret details. + **\$1db\$1instance\$1arn\$1** — The Timestream for InfluxDB instance ARN can be found on the Timestream for InfluxDB instance summary page. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret", "secretsmanager:GetSecretValue", "secretsmanager:PutSecretValue", "secretsmanager:UpdateSecretVersionStage" ], "Resource": "arn:aws-cn:secretsmanager:us-west-2:111122223333:secret:MySecret" }, { "Effect": "Allow", "Action": [ "secretsmanager:GetRandomPassword" ], "Resource": "*" }, { "Action": [ "timestream-influxdb:GetDbInstance" ], "Resource": "arn:aws-cn:timestream-influxdb:us-west-2:111122223333:db-instance/MyDbInstance", "Effect": "Allow" } ] } ``` ------ ### Rotating tokens Rotating tokens You can rotate a Timestream for InfluxDB token with the multi-user rotation function by using the [What's in the secret](#timestream-for-influx-security-db-secrets-definition) with a new secret and adding the required fields for your Timestream for InfluxDB token. For more information on secret rotation Lambda functions, see [Rotation by Lambda function](https://docs.amazonaws.cn/secretsmanager/latest/userguide/rotate-secrets_lambda.html). You can rotate a Timestream for InfluxDB token by using the Timestream for InfluxDB multi-user Lambda function. Set the `AUTHENTICATION_CREATION_ENABLED` environment variable to `true` in the Lambda configuration to enable token creation. To create a new token, use the [What's in the secret](#timestream-for-influx-security-db-secrets-definition) for your secret value. Omit the `token` key-value pair in the new secret and set the `type` to `allAccess`, or define the specific permissions and set the type to `custom`. The rotation function will create a new token during the first rotation cycle. You can't change the token permissions by editing the secret after rotation and any subsequent rotations will use the permissions that are set in the DB instance. #### Lambda rotation function Lambda rotation function The multi-user rotation function rotates token credentials by creating a new permission identical token using the admin credentials in the admin secret. The Lambda function validates the token value in the secret before creating the replacement token, storing the new token value in the secret, and deleting the old token. If the Lambda function is creating a new token it will first validate that the `AUTHENTICATION_CREATION_ENABLED` environment variable is set to `true`, that there is no token value in the secret, and that the token type is not type operator. #### Lambda function execution role permissions Lambda function execution role permissions Use the following IAM policy as the role for the multi-user Lambda function. The policy gives the Lambda function the required permissions to perform a secret rotation for Timestream for InfluxDB tokens. Replace all items listed below in the IAM policy with values from your Amazon account: + **\$1rotating\$1secret\$1arn\$1** — The ARN for the secret being rotated can be found in the Secrets Manager secret details. + **\$1authentication\$1properties\$1admin\$1secret\$1arn\$1** — The Timestream for InfluxDB admin secret ARN can be found on the Timestream for InfluxDB instance summary page. + **\$1db\$1instance\$1arn\$1** — The Timestream for InfluxDB instance ARN can be found on the Timestream for InfluxDB instance summary page. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret", "secretsmanager:GetSecretValue", "secretsmanager:PutSecretValue", "secretsmanager:UpdateSecretVersionStage" ], "Resource": "arn:aws-cn:secretsmanager:us-west-2:111122223333:secret:MySecret" }, { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "arn:aws-cn:secretsmanager:us-west-2:111122223333:secret:MyAdminSecret" }, { "Effect": "Allow", "Action": [ "secretsmanager:GetRandomPassword" ], "Resource": "*" }, { "Action": [ "timestream-influxdb:GetDbInstance" ], "Resource": "arn:aws-cn:timestream-influxdb:us-west-2:111122223333:db-instance/MyDbInstance", "Effect": "Allow" } ] } ``` ------ # Data protection in Timestream for InfluxDB Data protection The Amazon [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Amazon Timestream for InfluxDB. 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 Timestream for InfluxDB 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. For more detailed information on Timestream for InfluxDB data protection topics like Encryption at Rest and Key Management, select any of the available topics below. **Topics** + [ # Encryption at rest ](EncryptionAtRest-InfluxDB.md) + [ # Encryption in transit ](EncryptionInTransit-for-influx-db.md) # Encryption at rest Encryption at rest Timestream for InfluxDB encryption at rest provides enhanced security by encrypting all your data at rest using encryption keys stored in [Amazon Key Management Service (Amazon KMS)](https://aws.amazon.com/kms/). This functionality helps reduce the operational burden and complexity involved in protecting sensitive data. With encryption at rest, you can build security-sensitive applications that meet strict encryption compliance and regulatory requirements. + Encryption is turned on by default on your Timestream for InfluxDB DB instance, and cannot be turned off. The industry standard AES-256 encryption algorithm is the default encryption algorithm used. + Amazon KMS is used for encryption at rest in Timestream for InfluxDB. + You don't need to modify your DB instance client applications to use encryption. # Encryption in transit Encryption in transit All your Timestream for InfluxDB data is encrypted in transit. By default, all communications to and from Timestream for InfluxDB are protected by using Transport Layer Security (TLS) encryption. Traffic to and from Amazon Timestream for InfluxDB is secured using supported TLS versions 1.2 or 1.3. # Identity and Access Management for Amazon Timestream for InfluxDB Identity and Access Management Amazon Identity and Access Management (IAM) is an Amazon Web Services service that helps an administrator securely control access to Amazon resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use Timestream for InfluxDB resources. IAM is an Amazon Web Services service that you can use with no additional charge. **Topics** + [ ## Authenticating with identities ](#security_iam_authentication) + [ ## Managing access using policies ](#security_iam_access-manage) + [ # How Amazon Timestream for InfluxDB works with IAM ](security_iam_service-with-iam-influxb.md) + [ # Identity-based policy examples for Amazon Timestream for InfluxDB ](security_iam_id-based-policy-examples-influxb.md) + [ # Troubleshooting Amazon Timestream for InfluxDB identity and access ](security_iam_troubleshoot-influxdb.md) + [ # Controlling access to a DB instance in a VPC ](timestream-for-influxdb-controlling-access.md) + [ # Using service-linked roles for Amazon Timestream for InfluxDB ](using-service-linked-roles.md) + [ # Amazon managed policies for Amazon Timestream for InfluxDB ](security-iam-awsmanpol-influxdb.md) + [ # Connecting to Timestream for InfluxDB through a VPC endpoint ](timestream-influxdb-vpc-endpoint.md) ## Authenticating with identities Authentication is how you sign in to Amazon using your identity credentials. You must be authenticated as the Amazon Web Services account root user, an IAM user, or by assuming an IAM role. For programmatic access, Amazon provides an SDK and CLI to cryptographically sign requests. For more information, see [Amazon Signature Version 4 for API requests](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*. ### IAM users and groups An *[IAM user](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access Amazon using temporary credentials](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*. An [https://docs.amazonaws.cn/IAM/latest/UserGuide/id_groups.html](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.amazonaws.cn/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*. ### IAM roles An *[IAM role](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an Amazon CLI or Amazon API operation. For more information, see [Methods to assume a role](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*. IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, see [Cross account resource access in IAM](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*. ## Managing access using policies You control access in Amazon by creating policies and attaching them to Amazon identities or resources. A policy defines permissions when associated with an identity or resource. Amazon evaluates these policies when a principal makes a request. Most policies are stored in Amazon as JSON documents. For more information about JSON policy documents, see [Overview of JSON policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*. Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**. By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation. ### Identity-based policies Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*. ### Resource-based policies Resource-based policies are JSON policy documents that you attach to a resource. Examples include IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. You must [specify a principal](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Resource-based policies are inline policies that are located in that service. You can't use Amazon managed policies from IAM in a resource-based policy. ### Access control lists (ACLs) Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format. Amazon S3, Amazon WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see [Access control list (ACL) overview](https://docs.amazonaws.cn/AmazonS3/latest/userguide/acl-overview.html) in the *Amazon Simple Storage Service Developer Guide*. ### Other policy types Amazon supports additional policy types that can set the maximum permissions granted by more common policy types: + **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, see [Permissions boundaries for IAM entities](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*. + **Service control policies (SCPs)** – Specify the maximum permissions for an organization or organizational unit in Amazon Organizations. For more information, see [Service control policies](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *Amazon Organizations User Guide*. + **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.amazonaws.cn/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *Amazon Organizations User Guide*. + **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. For more information, see [Session policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*. ### Multiple policy types When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how Amazon determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*. # How Amazon Timestream for InfluxDB works with IAM **IAM features you can use with Amazon Timestream for InfluxDB** | IAM feature | Timestream for InfluxDB support | | --- | --- | | [Identity-based policies](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies) | Yes | | [Resource-based policies](#security_iam_service-with-iam-resource-based-policies-influxb) | No | | [Policy actions](#security_iam_service-with-iam-id-based-policies-actions-influxb) | Yes | | [Policy resources](#security_iam_service-with-iam-id-based-policies-resources-influxb) | Yes | | [Policy condition keys](#security_iam_service-with-iam-id-based-policies-conditionkeys-influxb) | No | | [ACLs](#security_iam_service-with-iam-acls-influxb) | No | | [ABAC (tags in policies)](#security_iam_service-with-iam-tags-influxb) | Yes | | [Temporary credentials](#security_iam_service-with-iam-roles-tempcreds-influxb) | Yes | | [Principal permissions](#security_iam_service-with-iam-principal-permissions-influxb) | Yes | | [Service roles](#security_iam_service-with-iam-roles-service-influxb) | No | | [Service-linked roles](#security_iam_service-with-iam-roles-service-linked-influxb) | Yes | To get a high-level view of how Timestream for InfluxDB and other Amazon services work with most IAM features, see [Amazon services that work with IAM](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. ## Identity-based policies for Timestream for InfluxDB Identity-based policies **Supports identity-based policies:** Yes Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*. ### Identity-based policy examples for Timestream for InfluxDB To view examples of Timestream for InfluxDB identity-based policies, see [Identity-based policy examples for Amazon Timestream for InfluxDB](security_iam_id-based-policy-examples-influxb.md). ## Resource-based policies within Timestream for InfluxDB Resource-based policies **Supports resource-based policies:** No Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or Amazon Web Services services. To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. For more information, see [Cross account resource access in IAM](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*. ## Policy actions for Timestream for InfluxDB Policy actions **Supports policy actions:** Yes Administrators can use Amazon JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation. To see a list of Timestream for InfluxDB actions, see [Actions, resources and condition keys for Amazon Timestream for InfluxDB](https://docs.amazonaws.cn/service-authorization/latest/reference/list_amazontimestreaminfluxdb.html) in the *Service Authorization Reference*. Policy actions in Timestream for InfluxDB use the following prefix before the action: ``` timestream-influxdb ``` To specify multiple actions in a single statement, separate them with commas. ``` "Action": [ "timestream-influxdb:action1", "timestream-influxdb:action2" ] ``` You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Describe`, include the following action: ``` "Action": "timestream-influxdb:Describe*" ``` ## Policy resources for Timestream for InfluxDB Policy resources **Supports policy resources:** Yes Administrators can use Amazon JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources. ``` "Resource": "*" ``` To see a list of Timestream for InfluxDB resource types and their ARNs, see [Resource types defined by Amazon Timestream for InfluxDB](https://docs.amazonaws.cn/service-authorization/latest/reference/list_amazontimestreaminfluxdb.html#amazontimestreaminfluxdb-resources-for-iam-policies) in the *Service Authorization Reference*. To learn with which actions you can specify the ARN of each resource, see [Actions, resources and condition keys for Amazon Timestream for InfluxDB](https://docs.amazonaws.cn/service-authorization/latest/reference/list_amazontimestreaminfluxdb.html). ## Policy condition keys for Timestream for InfluxDB Policy condition keys **Supports service-specific policy condition keys:** No Administrators can use Amazon JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all Amazon global condition keys, see [Amazon global condition context keys](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*. ## Access control lists (ACLs) in Timestream for InfluxDB ACLs **Supports ACLs:** No Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format. ## Attribute-based access control (ABAC) with Timestream for InfluxDB ABAC **Supports ABAC (tags in policies):** Yes Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and Amazon resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource. To control access based on tags, you provide tag information in the [condition element](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys. If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**. For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.amazonaws.cn/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.amazonaws.cn/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*. ## Using Temporary credentials with Timestream for InfluxDB Temporary credentials **Supports temporary credentials:** Yes Temporary credentials provide short-term access to Amazon resources and are automatically created when you use federation or switch roles. Amazon recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_credentials_temp.html) and [Amazon Web Services services that work with IAM](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. ## Cross-service principal permissions for Timestream for InfluxDB Principal permissions **Supports forward access sessions (FAS):** Yes Forward access sessions (FAS) use the permissions of the principal calling an Amazon Web Services service, combined with the requesting Amazon Web Services service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_forward_access_sessions.html). ## Service roles for Timestream for InfluxDB Service roles **Supports service roles:** No A service role is an [IAM role](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an Amazon Web Services service](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*. **Warning** Changing the permissions for a service role might break Timestream for InfluxDB functionality. Edit service roles only when Timestream for InfluxDB provides guidance to do so. ## Service-linked roles for Timestream for InfluxDB Service-linked roles **Supports service-linked roles:** Yes A service-linked role is a type of service role that is linked to an Amazon Web Services service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your Amazon Web Services account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles. For details about creating or managing service-linked roles, see [Amazon services that work with IAM](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Find a service in the table that includes a `Yes` in the **Service-linked role** column. Choose the **Yes** link to view the service-linked role documentation for that service. # Identity-based policy examples for Amazon Timestream for InfluxDB Identity-based policy examples By default, users and roles don't have permission to create or modify Timestream for InfluxDB resources. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies. To learn how to create an IAM identity-based policy by using these example JSON policy documents, see [Create IAM policies (console)](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_create-console.html) in the *IAM User Guide*. For details about actions and resource types defined by Timestream for InfluxDB, including the format of the ARNs for each of the resource types, see [Actions, resources, and condition Keys for Amazon Timestream for InfluxDB](https://docs.amazonaws.cn/service-authorization/latest/reference/list_amazontimestreaminfluxdb.html) in the *Service Authorization Reference*. **Topics** + [ ## Policy best practices ](#security_iam_service-with-iam-policy-best-practices-influxb) + [ ## Using the Timestream for InfluxDB console ](#security_iam_id-based-policy-examples-console-influxb) + [ ## Allow users to view their own permissions ](#security_iam_id-based-policy-examples-view-own-permissions-influxb) + [ ## Accessing one Amazon S3 bucket ](#security_iam_id-based-policy-examples-access-one-bucket) + [ ## Allowing all operations ](#security_iam_id-based-policy-examples-common-operations.all-influxdb) + [ ## Create, describe, delete and update a DB instance ](#security_iam_id-based-policy-examples-common-operations.cddd-influxdb) ## Policy best practices Identity-based policies determine whether someone can create, access, or delete Timestream for InfluxDB resources in your account. These actions can incur costs for your Amazon Web Services account. When you create or edit identity-based policies, follow these guidelines and recommendations: + **Get started with Amazon managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *Amazon managed policies* that grant permissions for many common use cases. They are available in your Amazon Web Services account. We recommend that you reduce permissions further by defining Amazon customer managed policies that are specific to your use cases. For more information, see [Amazon managed policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [Amazon managed policies for job functions](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*. + **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*. + **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific Amazon Web Services service, such as Amazon CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*. + **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.amazonaws.cn/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*. + **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your Amazon Web Services account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*. For more information about best practices in IAM, see [Security best practices in IAM](https://docs.amazonaws.cn/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*. ## Using the Timestream for InfluxDB console Using the console To access the Amazon Timestream for InfluxDB console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the Timestream for InfluxDB resources in your Amazon Web Services account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy. You don't need to allow minimum console permissions for users that are making calls only to the Amazon CLI or the Amazon API. Instead, allow access to only the actions that match the API operation that they're trying to perform. To ensure that users and roles can still use the Timestream for InfluxDB console, also attach the Timestream for InfluxDB `ConsoleAccess` or `ReadOnly` Amazon managed policy to the entities. For more information, see [Adding permissions to a user](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*. ## Allow users to view their own permissions This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the Amazon CLI or Amazon API. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws-cn:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` ## Accessing one Amazon S3 bucket In this example, you want to grant an IAM user in your Amazon account access to one of your Amazon S3 buckets, `amzn-s3-demo-bucket`. You also want to allow the user to add, update, and delete objects. In addition to granting the `s3:PutObject`, `s3:GetObject`, and `s3:DeleteObject` permissions to the user, the policy also grants the `s3:ListAllMyBuckets`, `s3:GetBucketLocation`, and `s3:ListBucket` permissions. These are the additional permissions required by the console. Also, the `s3:PutObjectAcl` and the `s3:GetObjectAcl` actions are required to be able to copy, cut, and paste objects in the console. For an example walkthrough that grants permissions to users and tests them using the console, see [An example walkthrough: Using user policies to control access to your bucket](https://docs.amazonaws.cn/AmazonS3/latest/userguide/walkthrough1.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"ListBucketsInConsole", "Effect":"Allow", "Action":[ "s3:ListAllMyBuckets" ], "Resource":"arn:aws-cn:s3:::*" }, { "Sid":"ViewSpecificBucketInfo", "Effect":"Allow", "Action":[ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource":"arn:aws-cn:s3:::amzn-s3-demo-bucket" }, { "Sid":"ManageBucketContents", "Effect":"Allow", "Action":[ "s3:PutObject", "s3:PutObjectAcl", "s3:GetObject", "s3:GetObjectAcl", "s3:DeleteObject" ], "Resource":"arn:aws-cn:s3:::amzn-s3-demo-bucket/*" } ] } ``` ------ ## Allowing all operations Allowing all operations The following is a sample policy that allows all operations in Timestream for InfluxDB. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "timestream-influxdb:*" ], "Resource": "*" } ] } ``` ------ ## Create, describe, delete and update a DB instance Create, describe, delete and update a DB instance The following sample policy allows a user to create, describe, delete and update a DB instance `sampleDB`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "timestream-influxdb:CreateDbInstance", "timestream-influxdb:GetDbInstance", "timestream-influxdb:DeleteDbInstance", "timestream-influxdb:UpdateDbInstance" ], "Resource": "arn:aws-cn:timestream-influxdb:us-west-2:111122223333:db-instance/MyDbInstance" } ] } ``` ------ # Troubleshooting Amazon Timestream for InfluxDB identity and access Troubleshooting Use the following information to help you diagnose and fix common issues that you might encounter when working with Timestream for InfluxDB and IAM. **Topics** + [ ## I am not authorized to perform an action in Timestream for InfluxDB ](#security_iam_troubleshoot-no-permissions-influxdb) + [ ## I want to allow people outside of my Amazon account to access my Timestream for InfluxDB resources ](#security_iam_troubleshoot-cross-account-access-influxdb) ## I am not authorized to perform an action in Timestream for InfluxDB If the Amazon Web Services Management Console tells you that you're not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your user name and password. The following example error occurs when the `mateojackson` user tries to use the console to view details about a fictional `my-example-widget` resource but does not have the fictional `timestream-influxdb:GetWidget` permissions. ``` User: arn:aws-cn:iam::123456789012:user/mateojackson is not authorized to perform: timestream-influxdb:GetWidget on resource: my-example-widget ``` In this case, Mateo asks his administrator to update his policies to allow him to access the `my-example-widget` resource using the `timestream-influxdb:GetWidget` action. ## I want to allow people outside of my Amazon account to access my Timestream for InfluxDB resources You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources. To learn more, consult the following: + [Controlling access to a DB instance in a VPC](timestream-for-influxdb-controlling-access.md) + To learn whether Timestream for InfluxDB supports these features, see [How Amazon Timestream for InfluxDB works with IAM](https://docs.amazonaws.cn/timestream/latest/developerguide/security_iam_service-with-iam-influxb.html). + To learn how to provide access to your resources across Amazon accounts that you own, see [Providing access to an IAM user in another Amazon account that you own](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*. + To learn how to provide access to your resources to third-party Amazon accounts, see [Providing access to Amazon accounts owned by third parties](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*. + To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*. + To learn the difference between using roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*. # Controlling access to a DB instance in a VPC Controlling access to a DB instance in a VPC Using Amazon Virtual Private Cloud (Amazon VPC), you can launch Amazon resources, such as Amazon Timestream for InfluxDB DB instances, into a virtual private cloud (VPC). When you use Amazon VPC, you have control over your virtual networking environment. You can choose your own IP address range, create subnets, and configure routing and access control lists. A VPC security group controls access to DB instances inside a VPC. Each VPC security group rule enables a specific source to access a DB instance in a VPC that is associated with that VPC security group. The source can be a range of addresses (for example, 203.0.113.0/24), or another VPC security group. By specifying a VPC security group as the source, you allow incoming traffic from all instances (typically application servers) that use the source VPC security group. Before attempting to connect to your DB instance, configure your VPC for your use case. The following are common scenarios for accessing a DB instance in a VPC: **A DB instance in a VPC accessed by an Amazon EC2 instance in the same VPC** A common use of a DB instance in a VPC is to share data with an application server that is running in an EC2 instance in the same VPC. The EC2 instance might run a web server with an application that interacts with the DB instance. **A DB instance in a VPC accessed by an EC2 instance in a different VPC** In some cases, your DB instance is in a different VPC from the EC2 instance that you're using to access it. If so, you can use VPC peering to access the DB instance. **A DB instance in a VPC accessed by a client application through the internet** To access a DB instance in a VPC from a client application through the internet, you configure a VPC with a single public subnet and use the public subnets to create the DB instance. You also configure an internet gateway in the VPC to enable communication over the internet. To connect to a DB instance from outside of its VPC, the DB instance must be publicly accessible. Also, access must be granted using the inbound rules of the DB instance's security group, and other requirements must be met. For more information on VPC security groups, see [Control traffic to your Amazon resources using security groups](https://docs.amazonaws.cn/vpc/latest/userguide/vpc-security-groups.html) in the *Amazon Virtual Private Cloud User Guide*. For details on how to connect to a Timestream for InfluxDB DB instance, see [Connecting to an Amazon Timestream for InfluxDB DB instance](timestream-for-influx-db-connecting.md). ## Security group scenario A common use of a DB instance in a VPC is to share data with an application server running in an Amazon EC2 instance in the same VPC, which is accessed by a client application outside the VPC. For this scenario, you use the Timestream for InfluxDB and VPC pages on the Amazon Web Services Management Console or the Timestream for InfluxDB and EC2 API operations to create the necessary instances and security groups: 1. Create a VPC security group (for example, `sg-0123ec2example`) and define inbound rules that use the IP addresses of the client application as the source. This security group allows your client application to connect to EC2 instances in a VPC that uses this security group. 1. Create an EC2 instance for the application and add the EC2 instance to the VPC security group (`sg-0123ec2example`) that you created in the previous step. 1. Create a second VPC security group (for example, `sg-6789rdsexample`) and create a new rule by specifying the VPC security group that you created in step 1 (`sg-0123ec2example`) as the source. 1. Create a new DB instance and add the DB instance to the VPC security group (`sg-6789rdsexample`) that you created in the previous step. When you create the DB, use the same port number as the one specified for the VPC security group (`sg-6789rdsexample`) rule that you created in step 3. ## Creating a VPC security group Creating a VPC security group You can create a VPC security group for a DB instance by using the VPC console. For information about creating a security group, see [Create a security group for your VPC](https://docs.amazonaws.cn/vpc/latest/userguide/creating-security-groups.html) in the *Amazon Virtual Private Cloud User Guide*. ## Associating a security group with a DB instance Associating with a DB instance Once a Timestream for InfluxDB DB instance has been created, you will not be able to associate it to new security groups since changes to these configurations are not currently supported. # Using service-linked roles for Amazon Timestream for InfluxDB Using service-linked roles Amazon Timestream for InfluxDB uses Amazon Identity and Access Management (IAM) [service-linked roles](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to an Amazon service, such as Amazon Timestream for InfluxDB. Amazon Timestream for InfluxDB service-linked roles are predefined by Amazon Timestream for InfluxDB. They include all the permissions that the service requires to call Amazon services on behalf of your dbinstances. A service-linked role makes setting up Amazon Timestream for InfluxDB easier because you don’t have to manually add the necessary permissions. The roles already exist within your Amazon account but are linked to Amazon Timestream for InfluxDB use cases and have predefined permissions. Only Amazon Timestream for InfluxDB can assume these roles, and only these roles can use the predefined permissions policy. You can delete the roles only after first deleting their related resources. This protects your Amazon Timestream for InfluxDB resources because you can't inadvertently remove necessary permissions to access the resources. For information about other services that support service-linked roles, see [Amazon services that work with IAM](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes **in the **Service-Linked Role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. **Contents** + [Service-Linked Role Permissions](#service-linked-role-permissions) + [ ## Creating a Service-Linked Role (IAM) ](#create-service-linked-role-iam) + [Editing a Service-Linked Role Description](#edit-service-linked-role) + [Using the IAM Console](#edit-service-linked-role-iam-console) + [Using the IAM CLI](#edit-service-linked-role-iam-cli) + [Using the IAM API](#edit-service-linked-role-iam-api) + [ ## Deleting a Service-Linked Role for Amazon Timestream for InfluxDB ](#delete-service-linked-role) + [ ### Cleaning Up a Service-Linked Role ](#service-linked-role-review-before-delete) + [ ### Deleting a Service-Linked Role (IAM Console) ](#delete-service-linked-role-iam-console) + [ ### Deleting a Service-Linked Role (IAM CLI) ](#delete-service-linked-role-iam-cli) + [ ### Deleting a Service-Linked Role (IAM API) ](#delete-service-linked-role-iam-api) + [ ## Supported Regions for Amazon Timestream for InfluxDB Service-Linked Roles ](#supported-regions) ## Service-Linked Role Permissions for Amazon Timestream for InfluxDB Service-Linked Role Permissions Amazon Timestream for InfluxDB uses the service-linked role named **AmazonTimestreamInfluxDBServiceRolePolicy** – This policy allows Timestream for InfluxDB to manage Amazon resources on your behalf as necessary for managing your clusters. The AmazonTimestreamInfluxDBServiceRolePolicy service-linked role permissions policy allows Amazon Timestream for InfluxDB to complete the following actions on the specified resources: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DescribeNetworkStatement", "Effect": "Allow", "Action": [ "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:DescribeNetworkInterfaces" ], "Resource": "*" }, { "Sid": "CreateEniInSubnetStatement", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface" ], "Resource": [ "arn:aws-cn:ec2:*:*:subnet/*", "arn:aws-cn:ec2:*:*:security-group/*" ] }, { "Sid": "CreateEniStatement", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface" ], "Resource": "arn:aws-cn:ec2:*:*:network-interface/*", "Condition": { "Null": { "aws:RequestTag/AmazonTimestreamInfluxDBManaged": "false" } } }, { "Sid": "CreateTagWithEniStatement", "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": "arn:aws-cn:ec2:*:*:network-interface/*", "Condition": { "Null": { "aws:RequestTag/AmazonTimestreamInfluxDBManaged": "false" }, "StringEquals": { "ec2:CreateAction": [ "CreateNetworkInterface" ] } } }, { "Sid": "ManageEniStatement", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterfacePermission", "ec2:DeleteNetworkInterface" ], "Resource": "arn:aws-cn:ec2:*:*:network-interface/*", "Condition": { "Null": { "aws:ResourceTag/AmazonTimestreamInfluxDBManaged": "false" } } }, { "Sid": "PutCloudWatchMetricsStatement", "Effect": "Allow", "Action": [ "cloudwatch:PutMetricData" ], "Condition": { "StringEquals": { "cloudwatch:namespace": [ "AWS/Timestream/InfluxDB", "AWS/Usage" ] } }, "Resource": [ "*" ] }, { "Sid": "ManageSecretStatement", "Effect": "Allow", "Action": [ "secretsmanager:CreateSecret", "secretsmanager:DeleteSecret" ], "Resource": [ "arn:aws-cn:secretsmanager:*:*:secret:READONLY-InfluxDB-auth-parameters-*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } } ] } ``` ------ **To allow an IAM entity to create AmazonTimestreamInfluxDBServiceRolePolicy service-linked roles** Add the following policy statement to the permissions for that IAM entity: ``` { "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole", "iam:PutRolePolicy" ], "Resource": "arn:aws-cn:iam::*:role/aws-service-role/timestreamforinfluxdb.amazonaws.com/AmazonTimestreamInfluxDBServiceRolePolicy*", "Condition": {"StringLike": {"iam:AmazonServiceName": "timestreamforinfluxdb.amazonaws.com"}} } ``` **To allow an IAM entity to delete AmazonTimestreamInfluxDBServiceRolePolicy service-linked roles** Add the following policy statement to the permissions for that IAM entity: ``` { "Effect": "Allow", "Action": [ "iam:DeleteServiceLinkedRole", "iam:GetServiceLinkedRoleDeletionStatus" ], "Resource": "arn:aws-cn:iam::*:role/aws-service-role/timestreamforinfluxdb.amazonaws.com/AmazonTimestreamInfluxDBServiceRolePolicy*", "Condition": {"StringLike": {"iam:AmazonServiceName": "timestreamforinfluxdb.amazonaws.com"}} } ``` Alternatively, you can use an Amazon managed policy to provide full access to Amazon Timestream for InfluxDB. ## Creating a Service-Linked Role (IAM) You don't need to manually create a service-linked role. When you create a DB instance, Amazon Timestream for InfluxDB creates the service-linked role for you. If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create a DB instance, Amazon Timestream for InfluxDB creates the service-linked role for you again. ## Editing the Description of a Service-Linked Role for Amazon Timestream for InfluxDB Editing a Service-Linked Role Description Amazon Timestream for InfluxDB does not allow you to edit the AmazonTimestreamInfluxDBServiceRolePolicy service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. ### Editing a Service-Linked Role Description (IAM Console) Using the IAM Console You can use the IAM console to edit a service-linked role description. **To edit the description of a service-linked role (console)** 1. In the left navigation pane of the IAM console, choose **Roles**. 1. Choose the name of the role to modify. 1. To the far right of **Role description**, choose **Edit**. 1. Enter a new description in the box and choose **Save**. ### Editing a Service-Linked Role Description (IAM CLI) Using the IAM CLI You can use IAM operations from the Amazon Command Line Interface to edit a service-linked role description. **To change the description of a service-linked role (CLI)** 1. (Optional) To view the current description for a role, use the Amazon CLI for IAM operation `[get-role](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-role.html)`. **Example** ``` $ aws iam get-role --role-name AmazonTimestreamInfluxDBServiceRolePolicy ``` Use the role name, not the ARN, to refer to roles with the CLI operations. For example, if a role has the following ARN: `arn:aws-cn:iam::123456789012:role/myrole`, refer to the role as **myrole**. 1. To update a service-linked role's description, use the Amazon CLI for IAM operation `[update-role-description](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/update-role-description.html)`. **Linux and MacOS** ``` $ aws iam update-role-description \ --role-name AmazonTimestreamInfluxDBServiceRolePolicy \ --description "new description" ``` **Windows** ``` $ aws iam update-role-description ^ --role-name AmazonTimestreamInfluxDBServiceRolePolicy ^ --description "new description" ``` ### Editing a Service-Linked Role Description (IAM API) Using the IAM API You can use the IAM API to edit a service-linked role description. **To change the description of a service-linked role (API)** 1. (Optional) To view the current description for a role, use the IAM API operation [GetRole](https://docs.amazonaws.cn/IAM/latest/APIReference/API_GetRole.html). **Example** ``` https://iam.amazonaws.com/ ?Action=[GetRole](https://docs.amazonaws.cn/IAM/latest/APIReference/API_GetRole.html) &RoleName=AmazonTimestreamInfluxDBServiceRolePolicy &Version=2010-05-08 &AUTHPARAMS ``` 1. To update a role's description, use the IAM API operation [UpdateRoleDescription](https://docs.amazonaws.cn/IAM/latest/APIReference/API_UpdateRoleDescription.html). **Example** ``` https://iam.amazonaws.com/ ?Action=[UpdateRoleDescription](https://docs.amazonaws.cn/IAM/latest/APIReference/API_UpdateRoleDescription.html) &RoleName=AmazonTimestreamInfluxDBServiceRolePolicy &Version=2010-05-08 &Description="New description" ``` ## Deleting a Service-Linked Role for Amazon Timestream for InfluxDB If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can delete it. Amazon Timestream for InfluxDB does not delete the service-linked role for you. ### Cleaning Up a Service-Linked Role Before you can use IAM to delete a service-linked role, first confirm that the role has no resources (clusters) associated with it. **To check whether the service-linked role has an active session in the IAM console** 1. Sign in to the Amazon Web Services Management Console and open the IAM console at [https://console.amazonaws.cn/iam/](https://console.amazonaws.cn/iam/). 1. In the left navigation pane of the IAM console, choose **Roles**. Then choose the name (not the check box) of the AmazonTimestreamInfluxDBServiceRolePolicy role. 1. On the **Summary** page for the selected role, choose the **Access Advisor** tab. 1. On the **Access Advisor** tab, review recent activity for the service-linked role. ### Deleting a Service-Linked Role (IAM Console) You can use the IAM console to delete a service-linked role. **To delete a service-linked role (console)** 1. Sign in to the Amazon Web Services Management Console and open the IAM console at [https://console.amazonaws.cn/iam/](https://console.amazonaws.cn/iam/). 1. In the left navigation pane of the IAM console, choose **Roles**. Then select the check box next to the role name that you want to delete, not the name or row itself. 1. For **Role actions** at the top of the page, choose **Delete role**. 1. In the confirmation page, review the service last accessed data, which shows when each of the selected roles last accessed an Amazon service. This helps you to confirm whether the role is currently active. If you want to proceed, choose **Yes, Delete** to submit the service-linked role for deletion. 1. Watch the IAM console notifications to monitor the progress of the service-linked role deletion. Because the IAM service-linked role deletion is asynchronous, after you submit the role for deletion, the deletion task can succeed or fail. If the task fails, you can choose **View details** or **View Resources** from the notifications to learn why the deletion failed. ### Deleting a Service-Linked Role (IAM CLI) You can use IAM operations from the Amazon Command Line Interface to delete a service-linked role. **To delete a service-linked role (CLI)** 1. If you don't know the name of the service-linked role that you want to delete, enter the following command. This command lists the roles and their Amazon Resource Names (ARNs) in your account. ``` $ aws iam get-role --role-name role-name ``` Use the role name, not the ARN, to refer to roles with the CLI operations. For example, if a role has the ARN `arn:aws-cn:iam::123456789012:role/myrole`, you refer to the role as **myrole**. 1. Because a service-linked role cannot be deleted if it is being used or has associated resources, you must submit a deletion request with the [delete-service-linked-role](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-service-linked-role.html) command. That request can be denied if these conditions are not met. You must capture the `deletion-task-id` from the response to check the status of the deletion task. Enter the following to submit a service-linked role deletion request. ``` $ aws iam delete-service-linked-role --role-name role-name ``` 1. Run the [get-service-linked-role-deletion-status](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-service-linked-role-deletion-status.html) command to check the status of the deletion task. ``` $ aws iam get-service-linked-role-deletion-status --deletion-task-id deletion-task-id ``` The status of the deletion task can be `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, or `FAILED`. If the deletion fails, the call returns the reason that it failed so that you can troubleshoot. ### Deleting a Service-Linked Role (IAM API) You can use the IAM API to delete a service-linked role. **To delete a service-linked role (API)** 1. To submit a deletion request for a service-linked roll, call [DeleteServiceLinkedRole](https://docs.amazonaws.cn/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html). In the request, specify a role name. Because a service-linked role cannot be deleted if it is being used or has associated resources, you must submit a deletion request. That request can be denied if these conditions are not met. You must capture the `DeletionTaskId` from the response to check the status of the deletion task. 1. To check the status of the deletion, call [GetServiceLinkedRoleDeletionStatus](https://docs.amazonaws.cn/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html). In the request, specify the `DeletionTaskId`. The status of the deletion task can be `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, or `FAILED`. If the deletion fails, the call returns the reason that it failed so that you can troubleshoot. ## Supported Regions for Amazon Timestream for InfluxDB Service-Linked Roles Amazon Timestream for InfluxDB supports using service-linked roles in all of the Regions where the service is available. For more information, see [Amazon service endpoints](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). # Amazon managed policies for Amazon Timestream for InfluxDB Amazon managed policies To add permissions to users, groups, and roles, it is easier to use Amazon managed policies than to write policies yourself. It takes time and expertise to [create IAM customer managed policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_create-console.html) that provide your team with only the permissions they need. To get started quickly, you can use our Amazon managed policies. These policies cover common use cases and are available in your Amazon account. For more information about Amazon managed policies, see [Amazon managed policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. Amazon services maintain and update Amazon managed policies. You can't change the permissions in Amazon managed policies. Services occasionally add additional permissions to an Amazon managed policy to support new features. This type of update affects all identities (users, groups, and roles) where the policy is attached. Services are most likely to update an Amazon managed policy when a new feature is launched or when new operations become available. Services do not remove permissions from an Amazon managed policy, so policy updates won't break your existing permissions. Additionally, Amazon supports managed policies for job functions that span multiple services. For example, the **ReadOnlyAccess** Amazon managed policy provides read-only access to all Amazon services and resources. When a service launches a new feature, Amazon adds read-only permissions for new operations and resources. For a list and descriptions of job function policies, see [Amazon managed policies for job functions](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*. ## Amazon managed policy: AmazonTimestreamInfluxDBServiceRolePolicy AmazonTimestreamInfluxDBServiceRolePolicy You cannot attach the AmazonTimestreamInfluxDBServiceRolePolicy Amazon managed policy to identities in your account. This policy is part of the Amazon TimestreamforInfluxDB service-linked role. This role allows the service to manage network interfaces and security groups in your account. Timestream for InfluxDB uses the permissions in this policy to manage EC2 security groups and network interfaces. This is required to manage Timestream for InfluxDB DB instances. To review this policy in JSON format, see [AmazonTimestreamInfluxDBServiceRolePolicy](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AmazonTimestreamInfluxDBServiceRolePolicy.html). ## Amazon-managed policies for Amazon Timestream for InfluxDB Amazon addresses many common use cases by providing standalone IAM policies that are created and administered by Amazon. Managed policies grant necessary permissions for common use cases so you can avoid having to investigate what permissions are needed. For more information, see [Amazon Managed Policies](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. The following Amazon managed policies, which you can attach to users in your account, are specific to Timestream for InfluxDB: ### AmazonTimestreamInfluxDBFullAccess You can attach the `AmazonTimestreamInfluxDBFullAccess` policy to your IAM identities. This policy grants administrative permissions that allow full access to all Timestream for InfluxDB resources. You can also create your own custom IAM policies to allow permissions for Amazon Timestream for InfluxDB API actions. You can attach these custom policies to the IAM users or groups that require those permissions. To review this policy in JSON format, see [AmazonTimestreamInfluxDBFullAccess](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AmazonTimestreamInfluxDBFullAccess.html). ## AmazonTimestreamInfluxDBFullAccessWithoutMarketplaceAccess You can attach the `AmazonTimestreamInfluxDBFullAccessWithoutMarketplaceAccess` policy to your IAM identities. This policy grants administrative permissions that allow full access to all Timestream for InfluxDB resources, excluding any marketplace-related actions. You can also create your own custom IAM policies to allow permissions for Timestream for InfluxDB API actions. You can attach these custom policies to the IAM users or groups that require those permissions. To review this policy in JSON format, see [AmazonTimestreamInfluxDBFullAccessWithoutMarketplaceAccess](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AmazonTimestreamInfluxDBFullAccessWithoutMarketplaceAccess.html). ## Timestream for InfluxDB updates to Amazon managed policies Policy updates View details about updates to Amazon managed policies for Timestream for InfluxDB since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the Timestream for InfluxDB Document history page. | Change | Description | Date | | --- | --- | --- | | [AmazonTimestreamInfluxDBFullAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess) – Update to an existing policy | Amazon Timestream for InfluxDB has added the RebootDbInstance and RebootDbCluster actions to the existing `AmazonTimestreamInfluxDBFullAccess` managed policy for rebooting Amazon Timestream InfluxDB resources. | 12/17/2025 | | [AmazonTimestreamInfluxDBFullAccessWithoutMarketplaceAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess-without-marketplace-access) – Update to an existing policy | Amazon Timestream for InfluxDB has added the RebootDbInstance and RebootDbCluster actions to the existing `AmazonTimestreamInfluxDBFullAccessWithoutMarketplaceAccess` managed policy for rebooting Amazon Timestream InfluxDB resources. | 12/17/2025 | | [AmazonTimestreamInfluxDBFullAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess) – Update to an existing policy | Amazon Timestream for InfluxDB has added the `ec2:DescribeVpcEndpoints` action to the existing `AmazonTimestreamInfluxDBFullAccess` managed policy for describing the VPC endpoints. | 11/13/2025 | | [AmazonTimestreamInfluxDBFullAccessWithoutMarketplaceAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess-without-marketplace-access) – Update to an existing policy | Amazon Timestream for InfluxDB has added the `ec2:DescribeVpcEndpoints` action to the existing `AmazonTimestreamInfluxDBFullAccessWithoutMarketplaceAccess` managed policy for describing the VPC endpoints. | 11/13/2025 | | [AmazonTimestreamInfluxDBFullAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess) – Update to an existing policy | Amazon Timestream for InfluxDB updated the existing managed policy `AmazonTimestreamInfluxDBFullAccess` that adds necessary permissions to access Marketplace APIs for managing subscription required for creating and updating Timestream for InfluxDB cluster resources. | 4/16/2025 | | [AmazonTimestreamInfluxDBFullAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess) – Update to an existing policy | Amazon Timestream for InfluxDB updated the existing managed policy `AmazonTimestreamInfluxDBFullAccess` that adds marketplace product ID to support subscription to InfluxDB enterprise marketplace offerings for Timestream for InfluxDB cluster resources. | 10/17/2025 | | [AmazonTimestreamInfluxDBFullAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess) – Update to an existing policy | Amazon Timestream for InfluxDB updated the existing managed policy `AmazonTimestreamInfluxDBFullAccess` that adds necessary permissions to access Marketplace APIs for managing subscription required for creating and updating Timestream for InfluxDB cluster resources. | 4/16/2025 | | [AmazonTimestreamInfluxDBFullAccessWithoutMarketplaceAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess-without-marketplace-access) – New policy | Amazon Timestream for InfluxDB added a new policy to provide administrative access to manage Amazon Timestream for InfluxDB instances and parameter groups except marketplace operations. | 04/16/2025 | | [AmazonTimestreamInfluxDBFullAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess) – Update to an existing policy | Amazon Timestream for InfluxDB updated the existing managed policy `AmazonTimestreamInfluxDBFullAccess` to also provide full administrative access to create, update, delete, and list Amazon Timestream InfluxDB clusters. | 2/17/2025 | | [AmazonTimestreamInfluxDBFullAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess) – Update to an existing policy | Added the `ec2:DescribeRouteTables` action to the existing `AmazonTimestreamInfluxDBFullAccess` managed policy. This action is used for describing your route tables | 10/08/2024 | | [Amazon managed policy: AmazonTimestreamInfluxDBServiceRolePolicy](#security-iam-awsmanpol-timestreamforinfluxdbServiceRolePolicy) – New policy | Amazon Timestream for InfluxDB added a new policy that allows the service to manage network interfaces and security groups in your account. | 03/14/2024 | | [AmazonTimestreamInfluxDBFullAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess) – New policy | Amazon Timestream for InfluxDB added a new policy to provide full administrative access to create, update, delete and list Amazon Timestream InfluxDB instances and create and list parameter groups. | 03/14/2024 | # Connecting to Timestream for InfluxDB through a VPC endpoint VPC endpoint You can connect directly to Timestream for InfluxDB through a private interface endpoint in your virtual private cloud (VPC). When you use an interface VPC endpoint, communication between your VPC and Timestream for InfluxDB is conducted entirely within the Amazon network. Timestream for InfluxDB supports Amazon Virtual Private Cloud (Amazon VPC) endpoints powered by [Amazon PrivateLink](https://docs.amazonaws.cn/vpc/latest/privatelink/). Each VPC endpoint is represented by one or more [Elastic Network Interfaces](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/using-eni.html) (ENIs) with private IP addresses in your VPC subnets. The interface VPC endpoint connects your VPC directly to Timestream for InfluxDB without an internet gateway, NAT device, VPN connection, or Amazon Direct Connect connection. The instances in your VPC do not need public IP addresses to communicate with Timestream for InfluxDB. **Regions** Timestream for InfluxDB supports VPC endpoints and VPC endpoint policies in all Amazon Web Services Regions in which Timestream for InfluxDB is supported. **Topics** + [ ## Considerations for Timestream for InfluxDB VPC endpoints ](#vpce-considerations) + [ ## Creating a VPC endpoint for Timestream for InfluxDB ](#vpce-create-endpoint) + [ ## Connecting to an Timestream for InfluxDB VPC endpoint ](#vpce-connect) + [ ## Controlling access to a VPC endpoint ](#vpce-policy) + [ ## Using a VPC endpoint in a policy statement ](#vpce-policy-condition) + [ ## Logging your VPC endpoint ](#vpce-logging) ## Considerations for Timestream for InfluxDB VPC endpoints Before you set up an interface VPC endpoint for Timestream for InfluxDB, review the [Interface endpoint properties and limitations](https://docs.amazonaws.cn/vpc/latest/privatelink/vpce-interface.html#vpce-interface-limitations) topic in the *Amazon PrivateLink Guide*. Timestream for InfluxDB support for a VPC endpoint includes the following. + You can use your VPC endpoint to call all [Timestream for InfluxDB API operations](https://docs.amazonaws.cn/ts-influxdb/latest/ts-influxdb-api/API_Operations.html) from your VPC. + You can use Amazon CloudTrail logs to audit your use of Timestream for InfluxDB resources through the VPC endpoint. For details, see [Logging your VPC endpoint](#vpce-logging). ## Creating a VPC endpoint for Timestream for InfluxDB You can create a VPC endpoint for Timestream for InfluxDB by using the Amazon VPC console or the Amazon VPC API. For more information, see [Create an interface endpoint](https://docs.amazonaws.cn/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) in the *Amazon PrivateLink Guide*. + To create a VPC endpoint for Timestream for InfluxDB, use the following service name: ``` com.amazonaws.region.timestream-influxdb ``` For example, in the US West (Oregon) Region (`us-west-2`), the service name would be: ``` com.amazonaws.us-west-2.timestream-influxdb ``` To make it easier to use the VPC endpoint, you can enable a [private DNS name](https://docs.amazonaws.cn/vpc/latest/privatelink/verify-domains.html) for your VPC endpoint. If you select the **Enable DNS Name** option, the standard Timestream for InfluxDB DNS hostname resolves to your VPC endpoint. For example, `https://timestream-influxdb.us-west-2.amazonaws.com` would resolve to a VPC endpoint connected to service name `com.amazonaws.us-west-2.timestream-influxdb`. This option makes it easier to use the VPC endpoint. The Amazon SDKs and Amazon CLI use the standard Timestream for InfluxDB DNS hostname by default, so you do not need to specify the VPC endpoint URL in applications and commands. For more information, see [Accessing a service through an interface endpoint](https://docs.amazonaws.cn/vpc/latest/privatelink/vpce-interface.html#access-service-though-endpoint) in the *Amazon PrivateLink Guide*. ## Connecting to an Timestream for InfluxDB VPC endpoint Connecting to a VPC endpoint You can connect to Timestream for InfluxDB through the VPC endpoint by using an Amazon SDK, the Amazon CLI or Amazon Tools for PowerShell. To specify the VPC endpoint, use its DNS name. If you enabled private hostnames when you created your VPC endpoint, you do not need to specify the VPC endpoint URL in your CLI commands or application configuration. The standard Timestream for InfluxDB DNS hostname resolves to your VPC endpoint. The Amazon CLI and SDKs use this hostname by default, so you can begin using the VPC endpoint to connect to an Timestream for InfluxDB regional endpoint without changing anything in your scripts and applications. To use private hostnames, the `enableDnsHostnames` and `enableDnsSupport` attributes of your VPC must be set to `true`. To set these attributes, use the [ModifyVpcAttribute](https://docs.amazonaws.cn/AWSEC2/latest/APIReference/API_ModifyVpcAttribute.html) operation. For details, see [View and update DNS attributes for your VPC](https://docs.amazonaws.cn/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) in the *Amazon VPC User Guide*. ## Controlling access to a VPC endpoint To control access to your VPC endpoint for Timestream for InfluxDB, attach a *VPC endpoint policy* to your VPC endpoint. The endpoint policy determines whether principals can use the VPC endpoint to call Timestream for InfluxDB operations on Timestream for InfluxDB resources. You can create a VPC endpoint policy when you create your endpoint, and you can change the VPC endpoint policy at any time. Use the VPC management console, or the [CreateVpcEndpoint](https://docs.amazonaws.cn/AWSEC2/latest/APIReference/API_CreateVpcEndpoint.html) or [ModifyVpcEndpoint](https://docs.amazonaws.cn/AWSEC2/latest/APIReference/API_ModifyVpcEndpoint.html) operations. You can also create and change a VPC endpoint policy by [using an Amazon CloudFormation template](https://docs.amazonaws.cn/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpcendpoint.html). For help using the VPC management console, see [Create an interface endpoint](https://docs.amazonaws.cn/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) and [Modifying an interface endpoint](https://docs.amazonaws.cn/vpc/latest/privatelink/vpce-interface.html#modify-interface-endpoint) in the *Amazon PrivateLink Guide*. **Note** Timestream for InfluxDB supports VPC endpoint policies beginning in July 2020. VPC endpoints for Timestream for InfluxDB that were created before that date have the [default VPC endpoint policy](#vpce-default-policy), but you can change it at any time. **Topics** + [ ### About VPC endpoint policies ](#vpce-policy-about) + [ ### Default VPC endpoint policy ](#vpce-default-policy) + [ ### Creating a VPC endpoint policy ](#vpce-policy-create) + [ ### Viewing a VPC endpoint policy ](#vpce-policy-get) ### About VPC endpoint policies For an Timestream for InfluxDB request that uses a VPC endpoint to be successful, the principal requires permissions from two sources: + A [IAM policy](security-iam-for-influxdb.md) must give principal permission to call the operation on the resource. + A VPC endpoint policy must give the principal permission to use the endpoint to make the request. ### Default VPC endpoint policy Every VPC endpoint has a VPC endpoint policy, but you are not required to specify the policy. If you don't specify a policy, the default endpoint policy allows all operations by all principals on all resources over the endpoint. However, for Timestream for InfluxDB resources, the principal must also have permission to call the operation from an [IAM policy](security-iam-for-influxdb.md) Therefore, in practice, the default policy says that if a principal has permission to call an operation on a resource, they can also call it by using the endpoint. ``` { "Statement": [ { "Action": "*", "Effect": "Allow", "Principal": "*", "Resource": "*" } ] } ``` To allow principals to use the VPC endpoint for only a subset of their permitted operations, [create or update the VPC endpoint policy](#vpce-policy-create). ### Creating a VPC endpoint policy A VPC endpoint policy determines whether a principal has permission to use the VPC endpoint to perform operations on a resource. For Timestream for InfluxDB resources, the principal must also have permission to perform the operations from a [IAM policy](security-iam-for-influxdb.md), Each VPC endpoint policy statement requires the following elements: + The principal that can perform actions + The actions that can be performed + The resources on which actions can be performed The policy statement doesn't specify the VPC endpoint. Instead, it applies to any VPC endpoint to which the policy is attached. 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*. Amazon CloudTrail logs all operations that use the VPC endpoint. ### Viewing a VPC endpoint policy To view the VPC endpoint policy for an endpoint, use the [VPC management console](https://console.amazonaws.cn/vpc/) or the [DescribeVpcEndpoints](https://docs.amazonaws.cn/AWSEC2/latest/APIReference/API_DescribeVpcEndpoints.html) operation. The following Amazon CLI command gets the policy for the endpoint with the specified VPC endpoint ID. Before using this command, replace the example endpoint ID with a valid one from your account. ``` $ aws ec2 describe-vpc-endpoints \ --query 'VpcEndpoints[?VpcEndpointId==`vpc-endpoint-id`].[PolicyDocument]' --output text ``` ## Using a VPC endpoint in a policy statement You can control access to Timestream for InfluxDB resources and operations when the request comes from VPC or uses a VPC endpoint. To do so, use one of the following [global condition keys](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#AvailableKeys) in a [IAM policy](security-iam-for-influxdb.md). + Use the `aws:sourceVpce` condition key to grant or restrict access based on the VPC endpoint. + Use the `aws:sourceVpc` condition key to grant or restrict access based on the VPC that hosts the private endpoint. **Note** Use caution when creating key policies and IAM policies based on your VPC endpoint. If a policy statement requires that requests come from a particular VPC or VPC endpoint, requests from integrated Amazon services that use an Timestream for InfluxDB resource on your behalf might fail. Also, the `aws:sourceIP` condition key is not effective when the request comes from an [Amazon VPC endpoint](https://docs.amazonaws.cn/vpc/latest/userguide/vpc-endpoints.html). To restrict requests to a VPC endpoint, use the `aws:sourceVpce` or `aws:sourceVpc` condition keys. For more information, see [Identity and access management for VPC endpoints and VPC endpoint services](https://docs.amazonaws.cn/vpc/latest/privatelink/vpc-endpoints-iam.html) in the *Amazon PrivateLink Guide*. You can use these global condition keys to control access to operations like [CreateDbInstance](https://docs.amazonaws.cn//ts-influxdb/latest/ts-influxdb-api/API_CreateDbInstance.html) that don't depend on any particular resource. ## Logging your VPC endpoint Amazon CloudTrail logs all operations that use the VPC endpoint. When a request to Timestream for InfluxDB uses a VPC endpoint, the VPC endpoint ID appears in the [Amazon CloudTrail log](logging-using-cloudtrail.md) entry that records the request. You can use the endpoint ID to audit the use of your Timestream for InfluxDB VPC endpoint. However, your CloudTrail logs don't include operations requested by principals in other accounts or requests for Timestream for InfluxDB operations on Timestream for InfluxDB resources and aliases in other accounts. Also, to protect your VPC, requests that are denied by a [VPC endpoint policy](#vpce-policy), but otherwise would have been allowed, are not recorded in [Amazon CloudTrail](logging-using-cloudtrail.md). # Logging and monitoring in Timestream for InfluxDB Logging and monitoring Monitoring is an important part of maintaining the reliability, availability, and performance of Timestream for InfluxDB and your Amazon solutions. You should collect monitoring data from all of the parts of your Amazon solution so that you can more easily debug a multi-point failure if one occurs. However, before you start monitoring Timestream for InfluxDB, you should create a monitoring plan that includes answers to the following questions: + What are your monitoring goals? + What resources will you monitor? + How often will you monitor these resources? + What monitoring tools will you use? + Who will perform the monitoring tasks? + Who should be notified when something goes wrong? The next step is to establish a baseline for normal Timestream for InfluxDB performance in your environment, by measuring performance at various times and under different load conditions. As you monitor Timestream for InfluxDB, store historical monitoring data so that you can compare it with current performance data, identify normal performance patterns and performance anomalies, and devise methods to address issues. To establish a baseline, you should, at a minimum, monitor the following items: + System errors, so that you can determine whether any requests resulted in an error. **Topics** + [ # Monitoring tools ](monitoring-automated-manual-influxdb.md) + [ # Logging Timestream for InfluxDB API calls with Amazon CloudTrail ](logging-using-cloudtrail-influxdb.md) # Monitoring tools Amazon provides various tools that you can use to monitor Timestream for InfluxDB. You can configure some of these tools to do the monitoring for you, while some of the tools require manual intervention. We recommend that you automate monitoring tasks as much as possible. **Topics** + [ ## Automated monitoring tools ](#monitoring-automated_tools-influxdb) + [ ## Manual monitoring tools ](#monitoring-manual-tools-influxdb) ## Automated monitoring tools Automated tools You can use the following automated monitoring tools to watch Timestream for InfluxDB and report when something is wrong: + **Amazon CloudWatch Alarms** – Watch a single metric over a time period that you specify, and perform one or more actions based on the value of the metric relative to a given threshold over a number of time periods. The action is a notification sent to an Amazon Simple Notification Service (Amazon SNS) topic or Amazon EC2 Auto Scaling policy. CloudWatch alarms do not invoke actions simply because they are in a particular state; the state must have changed and been maintained for a specified number of periods. For more information, see [Monitoring with Amazon CloudWatch](monitoring-cloudwatch.md). ## Manual monitoring tools Manual tools Another important part of monitoring Timestream for InfluxDB involves manually monitoring those items that the CloudWatch alarms don't cover. The Timestream for InfluxDB, CloudWatch, Trusted Advisor, and other Amazon Web Services Management Console dashboards provide an at-a-glance view of the state of your Amazon environment. + The CloudWatch home page shows the following: + Current alarms and status + Graphs of alarms and resources + Service health status In addition, you can use CloudWatch to do the following: + Create [customized dashboards](https://docs.amazonaws.cn/AmazonCloudWatch/latest/DeveloperGuide/CloudWatch_Dashboards.html) to monitor the services you care about + Graph metric data to troubleshoot issues and discover trends + Search and browse all your Amazon resource metrics + Create and edit alarms to be notified of problems # Logging Timestream for InfluxDB API calls with Amazon CloudTrail Timestream for InfluxDB is integrated with Amazon CloudTrail, a service that provides a record of actions taken by a user, role, or an Amazon service in Timestream for InfluxDB. CloudTrail captures Data Definition Language (DDL) API calls for Timestream for InfluxDB as events. The calls that are captured include calls from the Timestream for InfluxDB console and code calls to the Timestream for InfluxDB API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon Simple Storage Service (Amazon S3) bucket, including events for Timestream for InfluxDB. If you don't configure a trail, you can still view the most recent events on the CloudTrail console in **Event history**. Using the information collected by CloudTrail, you can determine the request that was made to Timestream for InfluxDB, the IP address from which the request was made, who made the request, when it was made, and additional details. To learn more about CloudTrail, see the [Amazon CloudTrail User Guide](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/). ## Timestream for InfluxDB information in CloudTrail CloudTrail is enabled on your Amazon account when you create the account. When activity occurs in Timestream for InfluxDB, that activity is recorded in a CloudTrail event along with other Amazon service events in **Event history**. You can view, search, and download recent events in your Amazon account. For more information, see [Viewing Events with CloudTrail Event History](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/view-cloudtrail-events.html). For an ongoing record of events in your Amazon account, including events for Timestream for InfluxDB, create a trail. A *trail* enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all Amazon Regions. The trail logs events from all Regions in the Amazon partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other Amazon services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following topics in the *Amazon CloudTrail User Guide*: + [Overview for Creating a Trail](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) + [CloudTrail Supported Services and Integrations](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations) + [Configuring Amazon SNS Notifications for CloudTrail](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/getting_notifications_top_level.html) + [Receiving CloudTrail Log Files from Multiple Regions](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) + [Receiving CloudTrail Log Files from Multiple Accounts](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html) + [Logging data events](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html) Every event or log entry contains information about who generated the request. The identity information helps you determine the following: + Whether the request was made with root or Amazon Identity and Access Management (IAM) user credentials + Whether the request was made with temporary security credentials for a role or federated user + Whether the request was made by another Amazon service For more information, see the [CloudTrail userIdentity Element](https://docs.amazonaws.cn/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html). # Compliance validation for Amazon Timestream for InfluxDB Compliance validation Third-party auditors assess the security and compliance of Amazon Timestream for InfluxDB as part of multiple Amazon compliance programs. These include the following: + GDPR + HIPAA + PCI + SOC # Resilience in Amazon Timestream for InfluxDB Resilience The Amazon global infrastructure is built around Amazon Regions and Availability Zones. Amazon Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. For more information about Amazon Regions and Availability Zones, see [Amazon Global Infrastructure](https://www.amazonaws.cn/about-aws/global-infrastructure/). Amazon Timestream for InfluxDB periodically takes internal backups and retains them for 24 hours to support availability and durability. Snapshots are taken during deletes and retained for 30 days to support restores. To access or use these, file a ticket at [Amazon support](https://support.console.aws.amazon.com/support/home?nc2=h_ql_cu#/). You can create your instance with Multi-AZ recovery capabilities. For more information, see [Multi-AZ DB instance deployments](https://docs.amazonaws.cn/timestream/latest/developerguide/timestream-for-influx-managing.html#timestream-for-influx-managing-multi-az-instance-deployments.html). # Infrastructure security in Amazon Timestream for InfluxDB Infrastructure security As a managed service, Amazon Timestream for InfluxDB is protected by the Amazon global network security procedures that are described in the [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) whitepaper. You use Amazon published control plane API calls to access Timestream for InfluxDB through the network. For more information, see [Control planes and data planes](https://docs.amazonaws.cn/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html). Clients must support Transport Layer Security (TLS) 1.2 or later. We recommend TLS 1.2 or 1.3. Clients must also support cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Most modern systems such as Java 7 and later support these modes. Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [Amazon Security Token Service](https://docs.amazonaws.cn/STS/latest/APIReference/Welcome.html) (Amazon STS) to generate temporary security credentials to sign requests. Timestream for InfluxDB is architected so that your traffic is isolated to the specific Amazon Region that your Timestream for InfluxDB instance resides in. ## Security groups Security groups Security groups control the access that traffic has in and out of a DB instance. By default, network access is turned off to a DB instance. You can specify rules in a security group that allow access from an IP address range, port, or security group. After ingress rules are configured, the same rules apply to all DB instances that are associated with that security group. For more information, see [Controlling access to a DB instance in a VPC](timestream-for-influxdb-controlling-access.md). # Configuration and vulnerability analysis in Timestream for InfluxDB Configuration and vulnerability analysis in Timestream for InfluxDB Configuration and IT controls are a shared responsibility between Amazon and you, our customer. For more information, see the Amazon [shared responsibility model](https://www.amazonaws.cn/compliance/shared-responsibility-model/). In addition to the shared responsibility model, Timestream for InfluxDB users should be aware of the following: + It is the customer responsibility to patch their client applications with the relevant client side dependencies. + Customers should consider penetration testing if appropriate (see [https://aws.amazon.com/security/penetration-testing/](https://www.amazonaws.cn/security/penetration-testing/).) # Incident response in Timestream for InfluxDB Incident response Amazon Timestream for InfluxDB service incidents are reported in the [Personal Health Dashboard](https://phd.aws.amazon.com/phd/home#/). You can learn more about the dashboard and Amazon Health [here](https://docs.amazonaws.cn//health/latest/ug/what-is-aws-health.html). Timestream for InfluxDB supports reporting using Amazon CloudTrail. For more information, see [Logging Timestream for InfluxDB API calls with Amazon CloudTrail](logging-using-cloudtrail-influxdb.md). # Amazon Timestream for InfluxDB API and interface VPC endpoints (Amazon PrivateLink) Amazon Timestream for InfluxDB API and interface VPC endpoints (Amazon PrivateLink) You can establish a private connection between your VPC and Amazon Amazon Timestream for InfluxDB control plane API endpoints by creating an *interface VPC endpoint*. Interface endpoints are powered by [Amazon PrivateLink](https://aws.amazon.com/privatelink). Amazon PrivateLink allows you to privately access Amazon Timestream for InfluxDB API operations without an internet gateway, NAT device, VPN connection, or Amazon Direct Connect connection. Instances in your VPC don't need public IP addresses to communicate with Amazon Timestream for InfluxDB API endpoints. Your instances also don't need public IP addresses to use any of the available Timestream for InfluxDB API operations. Traffic between your VPC and Amazon Timestream for InfluxDB doesn't leave the Amazon network. Each interface endpoint is represented by one or more elastic network interfaces in your subnets. For more information on elastic network interfaces, see [Elastic network interfaces](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/using-eni.html) in the *Amazon EC2 User Guide*. + For more information about VPC endpoints, see [Interface VPC endpoints (Amazon PrivateLink)](https://docs.amazonaws.cn/vpc/latest/userguide/vpce-interface.html) in the *Amazon VPC User Guide*. + For more information about Timestream for InfluxDB API operations, see [Timestream for InfluxDB API operations](https://docs.amazonaws.cn/ts-influxdb/latest/ts-influxdb-api/Welcome.html). After you create an interface VPC endpoint, if you enable [private DNS](https://docs.amazonaws.cn/vpc/latest/userguide/vpce-interface.html#vpce-private-dns) hostnames for the endpoint, the default Timestream for InfluxDB endpoint (https://timestream-influxb.*Region*.amazonaws.com) resolves to your VPC endpoint. If you do not enable private DNS hostnames, Amazon VPC provides a DNS endpoint name that you can use in the following format: ``` VPC_Endpoint_ID.timestream-influxb.Region.vpce.amazonaws.com ``` For more information, see [Interface VPC Endpoints (Amazon PrivateLink)](https://docs.amazonaws.cn/vpc/latest/userguide/vpce-interface.html) in the *Amazon VPC User Guide*. Timestream for InfluxDB supports making calls to all of its [API Actions](https://docs.amazonaws.cn/ts-influxdb/latest/ts-influxdb-api/Welcome.html) inside your VPC. **Note** Private DNS hostnames can be enabled for only one VPC endpoint in the VPC. If you want to create an additional VPC endpoint then private DNS hostname should be disabled for it. ## Considerations for VPC endpoints Considerations for VPC endpoints Before you set up an interface VPC endpoint for Amazon Timestream for InfluxDB API endpoints, ensure that you review [Interface endpoint properties and limitations](https://docs.amazonaws.cn/vpc/latest/privatelink/endpoint-services-overview.html) in the *Amazon VPC User Guide*. All Timestream for InfluxDB API operations that are relevant to managing Amazon Timestream for InfluxDB resources are available from your VPC using Amazon PrivateLink. VPC endpoint policies are supported for Timestream for InfluxDB API endpoints. By default, full access to Timestream for InfluxDB API operations is allowed through the endpoint. 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*. ### Creating an interface VPC endpoint for the Timestream for InfluxDB API Creating an interface VPC endpoint for the Timestream for InfluxDB API You can create a VPC endpoint for the Amazon Timestream for InfluxDB API using either the Amazon VPC console or the Amazon CLI. For more information, see [Creating an interface endpoint](https://docs.amazonaws.cn/vpc/latest/privatelink/create-endpoint-service.html) in the *Amazon VPC User Guide*. After you create an interface VPC endpoint, you can enable private DNS host names for the endpoint. When you do, the default Amazon Timestream for InfluxDB endpoint (https://timestream-influxb.*Region*.amazonaws.com) resolves to your VPC endpoint. For more information, see [Accessing a service through an interface endpoint](https://docs.amazonaws.cn/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) in the *Amazon VPC User Guide*. ### Creating a VPC endpoint policy for the Amazon Timestream for InfluxDB API Creating a VPC endpoint policy for the Amazon Timestream for InfluxDB API You can attach an endpoint policy to your VPC endpoint that controls access to the Timestream for InfluxDB API. The policy specifies 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*. **Example VPC endpoint policy for Timestream for InfluxDB API actions** The following is an example of an endpoint policy for the Timestream for InfluxDB API. When attached to an endpoint, this policy grants access to the listed Timestream for InfluxDB API actions for all principals on all resources. ``` { "Statement": [{ "Principal": "*", "Effect": "Allow", "Action": [ "timestream-influxb:CreateDbInstance", "timestream-influxb:UpdateDbInstance" ], "Resource": "*" }] } ``` **Example VPC endpoint policy that denies all access from a specified Amazon account** The following VPC endpoint policy denies Amazon account *123456789012* all access to resources using the endpoint. The policy allows all actions from other accounts. ``` { "Statement": [{ "Action": "*", "Effect": "Allow", "Resource": "*", "Principal": "*" }, { "Action": "*", "Effect": "Deny", "Resource": "*", "Principal": { "AWS": [ "123456789012" ] } } ] } ``` # Security best practices for Timestream for InfluxDB Security best practices Amazon Timestream for InfluxDB provides a number of security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don’t represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions. ## Implement least privilege access When granting permissions, you decide who is getting what permissions to which Timestream for InfluxDB resources. You enable specific actions that you want to allow on those resources. Therefore you should grant only the permissions that are required to perform a task. Implementing least privilege access is fundamental in reducing security risk and the impact that could result from errors or malicious intent. ## Use IAM roles Producer and client applications must have valid credentials to access Timestream for InfluxDB DB instances. You should not store Amazon credentials directly in a client application or in an Amazon S3 bucket. These are long-term credentials that are not automatically rotated and could have a significant business impact if they are compromised. Instead, you should use an IAM role to manage temporary credentials for your producer and client applications to access Timestream for InfluxDB DB instances. When you use a role, you don't have to use long-term credentials (such as a user name and password or access keys) to access other resources. For more information, see the following topics in the *IAM User Guide*: + [IAM Roles](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles.html) + [Common Scenarios for Roles: Users, Applications, and Services](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_common-scenarios.html) Use Amazon Identity and Access Management (IAM) accounts to control access to Amazon Timestream for InfluxDB API operations, especially operations that create, modify, or delete Amazon Timestream for InfluxDB resources. Such resources include DB instances, security groups, and parameter groups. + Create an individual user for each person who manages Amazon Timestream for InfluxDB resources, including yourself. Don't use Amazon root credentials to manage Amazon Timestream for InfluxDB resources. + Grant each user the minimum set of permissions required to perform his or her duties. + Use IAM groups to effectively manage permissions for multiple users. + Rotate your IAM credentials regularly. + Configure Amazon Secrets Manager to automatically rotate the secrets for Amazon Timestream for InfluxDB. For more information, see [Rotating your Amazon Secrets Manager secrets](https://docs.amazonaws.cn/secretsmanager/latest/userguide/rotating-secrets.html) in the *Amazon Secrets Manager User Guide*. You can also retrieve the credential from Amazon Secrets Manager programmatically. For more information, see [Retrieving the secret value](https://docs.amazonaws.cn/secretsmanager/latest/userguide/manage_retrieve-secret.html) in the *Amazon Secrets Manager User Guide*. + Secure your Timestream for InfluxDB influx API tokens by using the [API tokens](timestream-for-influx-security-db-authentication.md#timestream-for-influx-security-db-authentication-api-token). ## Implement Server-Side Encryption in Dependent Resources Data at rest and data in transit can be encrypted in Timestream for InfluxDB. For more information, see [Encryption in transit](EncryptionInTransit-for-influx-db.md). ## Use CloudTrail to Monitor API Calls Timestream for InfluxDB is integrated with Amazon CloudTrail, a service that provides a record of actions taken by a user, role, or an Amazon service in Timestream for InfluxDB. Using the information collected by CloudTrail, you can determine the request that was made to Timestream for InfluxDB, the IP address from which the request was made, who made the request, when it was made, and additional details. For more information, see [Logging Timestream for LiveAnalytics API calls with Amazon CloudTrail](logging-using-cloudtrail.md). Amazon Timestream for InfluxDB supports control plane CloudTrail events, but not data plane. For more information, see [Control planes and data planes](https://docs.amazonaws.cn/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html). ## Public accessibility Public accessibility When you launch a DB instance inside a virtual private cloud (VPC) based on the Amazon VPC service, you can turn on or off public accessibility for that DB instance. To designate whether the DB instance that you create has a DNS name that resolves to a public IP address, you use the Public accessibility parameter. By using this parameter, you can designate whether there is public access to the DB instance If your DB instance is in a VPC but isn't publicly accessible, you can also use an Amazon Site-to-Site VPN connection or an Amazon Direct Connect connection to access it from a private network. If your DB instance is publicly accessible, be sure to take steps to prevent or help mitigate denial of service related threats. For more information, see [Introduction to denial of service attacks](https://docs.amazonaws.cn/whitepapers/latest/aws-best-practices-ddos-resiliency/introduction-denial-of-service-attacks.html) and [Protecting networks](https://docs.amazonaws.cn/wellarchitected/latest/security-pillar/protecting-networks.html).