VishaalY/solutions-architect-hf-dataset huggingface dataset:
Question: How do I prevent "Rate exceeded" errors in CloudFormation?

I sometimes get "Rate exceeded" errors when I use AWS CloudFormation. How do I prevent this error from happening?Short descriptionThe Rate exceeded error occurs when API calls to an AWS service exceed the maximum allowed API requests, and the API calls are throttled. Generally, these errors are temporary and resolve themselves as the API calls lessen.To prevent Rate exceeded errors, you can:Implement exponential backoffCreate or update stacks one at a timeUse the DependsOn attributeRequest a quota increase

ResolutionImplement exponential backoffWhen using AWS API endpoints, implement exponential backoff to decrease the number of API calls being made.The following example pseudo code for a DescribeStacks API call is configured to retry the API call after specific amounts of time:{Make ‘DescribeStacks’ API call if throttled: wait 2 sec; Make ‘DescribeStacks’ API call if throttled: wait 4 sec; Make ‘DescribeStacks’ API call if throttled: wait 8 sec; Make ‘DescribeStacks’ API call if throttled: wait 16 sec; Make ‘DescribeStacks’ API call if throttled: wait 32 sec; Make ‘DescribeStacks’ API call }Create or update stacks one at a timeCreating or updating multiple CloudFormation stacks concurrently can result in many API calls being made at the same time. To prevent the API calls from exceeding the maximum allowed API requests, create or update one stack at a time.Use the DependsOn attributeUnless a dependency is defined between resources, CloudFormation creates and updates resources at the same time. The DependsOn attribute defines dependencies between resources to control concurrent updates.The DependsOn attribute lets you specify when each dependent resource is created or updated. For example, if resource B is dependent on resource A, then you can specify that resource A be created or updated before resource B. This limits the number of API calls being made at at the same time and reduces the occurrence of throttling. You can also use the DependsOn attribute with nested stacks.Request a quota increaseIf the preceding resolutions don't work for your situation, then you can request a quota increase. Before you request a quota increase, identify the API call to determine the one that is exceeding the call rate.In your request for a quota increase, include your AWS Region, the time frame of the API throttling, and the reason for the increase.
Question: How can I find out which IAM user sent an email through Amazon SES?

I want to see which AWS Identity and Access Management (IAM) user sent an email through Amazon Simple Email Service (Amazon SES). How can I do that?Short descriptionUse Amazon SES event publishing with an Amazon CloudWatch destination to view more information about sent or delivered emails. This information on CloudWatch includes the IAM user who sent the email. Follow these steps:Create a configuration set with CloudWatch as the event destination.Send a test email from Amazon SES.Check the metric on CloudWatch.

ResolutionBefore you begin, you must have:A verified email address or domain in Amazon SES.Permissions to use Amazon SES and CloudWatch.Create a configuration set with CloudWatch as the event destinationOpen the Amazon SES console.From the navigation pane, choose Configuration Sets.Choose Create Configuration Set.For Configuration Set Name, enter a name for the configuration set. For example, enter CallerIdentity.Choose Create Configuration Set.From the list of configuration sets, choose the set that you just created to view its details.On the Event Destinations tab, for Add Destination, select CloudWatch.For CloudWatch Destination, enter the following:For Name, enter a name for the event destination. For example, enter NameOfCallerIdentity.For Event types, select Send at minimum. You can also select Delivery to be able to filter between messages that delivered successfully or messages that bounced.For Value Source, select Message Tag.For Dimension Name, enter a name for the dimension. For example, enter ses:caller-identity.For Default Value, enter the same value that you entered for Name.Choose Save.Send a test email from Amazon SESFrom the Amazon SES console, choose Email Addresses or Domains from the navigation pane, depending on whether you're using an email address or domain.Select your verified email address or domain. Then, choose Send a Test Email.Choose More options.Enter the following:For To, enter an email address where you want to receive the test email.For Configuration Set, enter the name of the configuration set that you created.For Subject, enter a subject line for the test email.Choose Send Test Email.Check CloudWatch for the metric on the test emailOpen the CloudWatch console.From the navigation pane, choose Metrics.On the All metrics tab, choose SES.Choose the dimension name that you entered when you created the configuration set. For example, choose ses:caller-identity.Under the ses:caller-identity column, you'll see the IAM user who sent the test email.

Related informationRetrieving Amazon SES Event Data from CloudWatch
Question: How can I resolve the error "native lambda error:InvalidSignatureException: Signature expired" when invoking a Lambda function using an AWS SDK?

When I invoke my AWS Lambda function using an AWS SDK, the function returns a signature expired error.

Short descriptionLambda expired signatures occurs when the client time and server time don't match similar to the following error:"Error: native lambda error:InvalidSignatureException: Signature expired: 20230118T161739Z is now earlier than 20230118T161739Z (20190318T162239Z - 5 min.)"An API request must reach AWS within five minutes of the timestamp in the request or AWS denies the request. In some scenarios, this issue can't be corrected by changing the client time to match the server time.

ResolutionWhen invoking a Lambda function synchronously using an AWS SDK, the connection lasts until the response is returned. The Node.js SDK allows 50 connections by default. If the connection limit is reached, then the SDK queues the request locally until there is an available connection. The connection limit might be reached if you received the signature expired error, and the following actions are also true:The Lambda function isn't throttling.The client time is correct.(Node.js SDK only) The correctClockSkew:true option was set when creating the client to make sure that the time is corrected when invoking.The Lambda function's invoked at a high rate and runs for an extended period of time.The Lambda function's invoked at a high rate.The SDK signs the request and then puts it in a queue pending an available connection. If the queue becomes too large and the request is pending for more than five minutes, then the signature expires. Any additional requests fail because the signature is expired.To resolve this issue, consider using asynchronous invocation for Lambda if the response from the invocation isn't needed. This allows the SDK to use the connection only for invoking the request and won't wait for a response.You can also increase the maximum number of connections allowed by the SDK.Note: Additional connections allow the Lambda function to invoke at a higher rate, which might cause throttling.

Related informationMonitoring and troubleshooting Lambda applicationsHow do I troubleshoot Lambda function invocation timeout errors?How do I determine if my Lambda function is timing out?
Question: What happens to Amazon RDS and Amazon Redshift queries that are running during a maintenance window?

I have Amazon Relational Database Service (Amazon RDS) or Amazon Redshift queries that are running during a maintenance window. What happens to queries that are running during a maintenance window?ResolutionAmazon RDS maintenanceAmazon RDS maintenance windows usually involve updates to the DB instance's operating system (OS), to the database engine version, or to the cluster version. If maintenance requires an instance reboot or an engine restart, then queries and transactions that are running are terminated and uncommitted transactions are rolled back during the engine restart to ensure Atomicity, Consistency, Isolation, and Durability (ACID) compliance. You must re-run the queries or transactions that are terminated. By default, both MySQL and PostgreSQL are ACID compliant, but it can be overridden by some parameter configurations. Check your engine's documentation to confirm that you don't have any parameters that would stop the engine from being ACID compliant. For more information, see the MySQL documentation for InnoDB and the ACID Model and the PostgreSQL documentation for synchronous_commit.Amazon Redshift maintenanceAmazon Redshift maintenance windows require the cluster to go offline or to restart during scheduled maintenance. If queries are running during scheduled maintenance, then queries are terminated and rolled back. To view which queries were terminated, see SVL_QLOG. It's a best practice to schedule around maintenance windows—especially long-running operations, such as large data loads or VACUUM operations. For more information, see Amazon Redshift best practices.Note: If the maintenance doesn't require a restart for the DB engine, cluster, or instance, then queries are not affected.

Related informationMaintaining a DB InstanceHow do I configure notifications for Amazon RDS or Amazon Redshift maintenance windows?How do I minimize downtime during required Amazon RDS maintenance?
Question: How do I delete a Device Farm project?

I want to delete my AWS Device Farm project. How do I do that?ResolutionImportant: Deleting a Device Farm project permanently deletes all the project's underlying resources, including runs, reports, device pools, and files. After the resources are deleted, they can't be recovered.To delete a project using the Device Farm console1.    Open the Device Farm console.2.    In the left navigation pane, choose Projects under either Mobile Device Testing or Desktop Browser Testing, based on your use case.3.    Find the card that lists the name of the project that you want to delete. Then, select the check box in the upper right of the card.4.    At the top right of the page, choose Delete. A Delete project dialog box appears.5.    Read the message in the Delete project dialog box. Then, select the check box next to I understand and want to delete this project.6.    Choose Delete.To delete a project using the AWS CLINote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent version of the AWS CLI.1.    Get the Amazon Resource Name (ARN) of the project that you want to delete by running the following command:$ aws devicefarm list-projects --region us-west-2Note: The command output includes the names, ARNs, and creation timestamps for all your Device Farm projects.Example ARNarn:aws:devicefarm:us-west-2:123456789012:project:a5f5b752-8098-49d1-86bf-5f7682c1c77e2.    Delete the project by running the following command:Important: Replace the example ARN in the command with the ARN of the project that you want to delete.$ aws devicefarm delete-project --region us-west-2 --arn arn:aws:devicefarm:us-west-2:123456789012:project:a5f5b752-8098-49d1-86bf-5f7682c1c77e

Related informationDelete-project (AWS CLI command reference)List-projects (AWS CLI command reference)Create a project in AWS Device Farm
Question: How can I capture and analyze the SAML response to troubleshoot common errors with SAML 2.0 federation with AWS?

I'm using on-premises Active Directory with SAML integration, but I can't connect to the AWS Management Console.

Short descriptionIf you're using SAML federation, be sure that you've correctly configured Active Directory. For more information, see AWS federated authentication with Active Directory Federation Services (AD FS).If you're setting up federated access to your AWS accounts for the first time, it's a best practice to use the AWS IAM Identity Center (successor to AWS Single Sign-On) service to provide centrally managed IAM Identity Center access to multiple AWS accounts.To troubleshoot SAML-related errors:Capture and decode a SAML response from the browser.Review the values in the decoded file.Check for errors, and then confirm the configuration.

ResolutionCapture and decode a SAML responseCapture and decode a SAML response from the browser, and then review the information sent to AWS. For browser-specific instructions, see How to view a SAML response in your browser for troubleshooting.Review the values in the decoded fileReview the values in the decoded SAML response file:1.    Verify that the value for the saml:NameID attribute matches the user name for the authenticated user.2.    Review the value for https://aws.amazon.com/SAML/Attributes/Role. The Amazon Resource Names (ARNs) for the role and SAML provider are case-sensitive, and the ARNs must match the resources in your AWS account.3.    Review the value for https://aws.amazon.com/SAML/Attributes/RoleSessionName. Be sure that the value matches the correct value as the claim rule. If you configure the attribute value to be an email address or an account name, the value must correspond to the email address or account name of the authenticated Active Directory user.Check for errors and confirm the configurationCheck for errors with any of these values, and confirm that the following configurations are correct:1.    Confirm that the claim rules are configured to meet the required elements and that all ARNs are accurate. For more information, see Configuring your SAML 2.0 IdP with relying party trust and adding claims.2.    Confirm that you uploaded the latest metadata file from your IdP into AWS in your SAML provider. For more information, see Allowing SAML 2.0 federated users to access the AWS Management Console.3.    Confirm that you have the AWS Identity and Access Management (IAM) role's trust policy configured correctly. For more information, see Modifying a role.4.    Confirm that the Active Directory user attempting to log in to the console is a member of the Active Directory group that corresponds to the IAM role.For a list of common errors, see Troubleshooting SAML 2.0 federation with AWS. If you're configuring claim rules in Active Directory, be sure to configure SAML assertions for the authentication responses to identify the key attributes and values that AWS requires.
Question: How can I be sure that CloudWatch alarms activate actions?

My Amazon CloudWatch alarm isn't activated even though I can see from my CloudWatch graphs that the alarm metric exceeds the configured threshold. How can I be sure that my CloudWatch alarms are activated and the alarm actions are performed?Short descriptionCloudWatch alarms that measure time-aggregated metrics (such as five-minute averages) perform this measurement continuously in a rolling window. If all the data points collected during the evaluation period don't exceed the configured threshold, then the CloudWatch alarm isn't activated.CloudWatch alarms start actions when the alarm state changes and is maintained for a specified number of periods. For more information, see Creating CloudWatch alarms.Important: There is an exception to this behavior for CloudWatch alarms that are associated with Amazon EC2 Auto Scaling actions. A CloudWatch alarm keeps activating Auto Scaling actions when that alarm is in a specified state. This happens even if there are no state changes and the alarm remains in that state.

ResolutionBe sure to consider the mechanism used by CloudWatch to measure time-aggregated metrics when you create alarms.Consider lowering the metric data thresholds to be sure the alarm works as you expect.Troubleshooting exampleIn this example, there is an alarm based on average CPU utilization. The alarm is configured with a threshold of > 45. It runs for at least three consecutive periods of five minutes. The evaluation period is of three and a period of 300 seconds for the following time-aggregated metrics:05:25:00: data: {Avg=61.123}05:30:00: data: {Avg=57.847}05:35:00: data: {Avg=60.503}05:40:00: data: {Avg=55.473}05:45:00: data: {Avg=41.685}05:50:00: data: {Avg=58.390}05:55:00: data: {Avg=57.846}06:00:00: data: {Avg=61.123}These data points result in the following alarm states:05:35 ALARM05:40 ALARM05:45 ALARM to OK05:50 OK05:55 OK06:00 OK to ALARMThe data point collected at 05:55 exceeds the Average CPU Utilization threshold of 45%. However, the alarm remains in the OK state and doesn't activate the action at 05:55. This happens because the data point collected at 05:45:00, which doesn't exceed the threshold, is included in evaluation at 05:55. However, five minutes later, the alarm starts the action because the alarm state changes from OK to ALARM at 06:00.For the following time-aggregated metrics, the alarm state is ALARM after 05:35 because all the data points exceed the Average CPU Utilization threshold of 45%. Because there are no state changes, the alarm action isn't activated.05:25:00: data: {Avg=61.123}05:30:00: data: {Avg=57.847}05:35:00: data: {Avg=60.503}05:40:00: data: {Avg=55.473}05:45:00: data: {Avg=45.075}05:50:00: data: {Avg=58.390}05:55:00: data: {Avg=57.847}06:00:00: data: {Avg=61.123}Related informationDynamic scaling for Amazon EC2 Auto ScalingViewing available metrics
Question: How can I use AWS DMS to migrate from an Amazon RDS DB instance that is running SQL Server?

How can I use AWS Database Migration Service (AWS DMS) to migrate from an Amazon Relational Database Service (Amazon RDS) DB instance that is running SQL Server?Short descriptionYou can migrate data from one or more SQL Server DB instances using AWS DMS into any of the supported target DB engines.First, be sure to use the master user of the RDS SQL Server instance to configure the database and the tables. Then, create your source endpoint using the AWS DMS console or using the AWS Command Line Interface (AWS CLI).For more information about how SQL Server uses change data capture (CDC) and the prerequisites and requirements for using ongoing replication with SQL Server DB instances, see Using ongoing replication (CDC) from a SQL Server source.

ResolutionNote: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.AWS DMS offers two methods for capturing ongoing changes: MS-Replication and MS-CDC.Note: Amazon RDS instances that run SQL Server as the source must use MS-CDC because Amazon RDS doesn't support Sysadmin privileges.Run the following command using the master user to enable MS-CDC at the database level:EXEC msdb.dbo.rds_cdc_enable_db 'DBName';GOThen run the following command for each table to enable CDC at the table level:EXECUTE sys.sp_cdc_enable_table @source_schema = N'SchemaName', @source_name =N'TableName', @role_name = NULL;GOThen run the following command to increase the retention period for the transactions in the T-Log:EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 3599;GOWhen configuring ongoing replication for a SQL Server instance, it's a best practice to set the pollinginterval to retain changes for one day (86400 seconds). However, there is a known issue with some versions of SQL Server, so if the value of pollinginterval is set to more than 3599 seconds, then the value resets to the default, which is five seconds. When this happens, the T-Log entries are purged before AWS DMS reads them. To see which versions are still impacted by this issue, see the Microsoft documentation for Incorrect results occur when you convert "pollinginterval" parameter from seconds to hours in sys.sp_cdc_scan in SQL Server.After you create an AWS DMS task, you can monitor the status of your migration task. If you stop the task and resume the task after one hour, it might fail because the T-Log has been truncated and AWS DMS doesn't have the required log sequence numbers (LSNs) because of the issue mentioned previously. To prevent this, follow these steps:1.    Stop the capture job:use [DBName]exec sys.sp_cdc_stop_job;2.    Stop the AWS DMS task, and wait for all remaining activities to stop.3.    Resume the DMS task and wait for it to sync by monitoring the AWS DMS task’s source latency.4.    Restart the capture job:use [DBName]exec sys.sp_cdc_start_job;Related informationTroubleshooting Microsoft SQL Server specific issuesMigrating Microsoft SQL Server databases to the AWS Cloud
Question: How do I resolve the "Insufficient privileges for accessing data in S3" error while creating an import job in Amazon Personalize?

When I try to create the dataset import job in Amazon Personalize, I get the following error:"Insufficient privileges for accessing data in S3. Please look at https://docs.aws.amazon.com/personalize/latest/dg/granting-personalize-s3-access.html#attach-bucket-policy and fix bucket policy on S3 bucket".

ResolutionThis error occurs when Amazon Personalize can't read the data in the input bucket due to insufficient Amazon Simple Storage Service (Amazon S3) bucket permissions.After you upload all the input CSV files to your S3 bucket, Amazon Personalize imports data from the input location. This means that Amazon Personalize must have permissions to access your S3 bucket.To grant Amazon Personalize access to your S3 bucket, follow these steps:1.    Open the Amazon S3 console.2.    From the list of buckets, open the bucket where you uploaded the CSV files.3.    Choose Permissions, and then choose Bucket Policy.4.    In the Bucket policy editor text box, enter the following bucket policy:{  "Version": "2012-10-17",  "Id": "PersonalizeS3BucketAccessPolicy",  "Statement": [    {      "Sid": "PersonalizeS3BucketAccessPolicy",      "Effect": "Allow",      "Principal": {        "Service": "personalize.amazonaws.com"      },      "Action": [        "s3:GetObject",        "s3:ListBucket"      ],      "Resource": [        "arn:aws:s3:::DOC-EXAMPLE-BUCKET",        "arn:aws:s3:::DOC-EXAMPLE_BUCKET/*"      ]    }  ]}Note: Replace DOC-EXAMPLE-BUCKET with the name of your bucket.5.    Choose Save.For more information on setting up permissions to use Amazon Personalize, see Setting up permissions.

Related informationUploading to an S3 bucket
Question: How do I troubleshoot issues with compressing files in CloudFront?

I'm using Amazon CloudFront distribution to automatically serve compressed objects, but the content is not compressed in the viewer. How can I troubleshoot this?ResolutionCheck your CloudFront configurationMake sure the Compress objects automatically setting is set to Yes.Confirm that both Brotli and Gzip are enabled in the cache policy settings.Confirm that the TTL values in the cache policy are set to a value greater than zero. CloudFront doesn't compress objects when caching is turned off.Check the configuration for viewersFirst, get information about the detailed request headers sent by the browser bycapturing the HTTP Archive (HAR). Then, confirm the following:The request uses an HTTP version higher than HTTP 1.0. In lower version of HTTP, CloudFront removes the Accept-Encoding header and doesn't compress the object in the response.The Accept-Encoding header is included in the viewer request and contains either the gzip or br value.Verify the response that the origin server is returning to CloudFrontIf you have access to the origin, check the response that the origin server is returning to CloudFront. Then, confirm the following:The origin doesn't return a Content-Encoding header. This header indicates that the response is already compressed.The response Content-Length is present in the response from the origin and is within the supported range of 1,000 bytes to 10,000,000 bytes.The file type is supported for compression.The response HTTP status code is either 200, 403 or 404.If you observe a cache hit for the object, invalidate it from the cache. CloudFront doesn't compress objects that are already cached in edge locations when you turn on the compress image setting. CloudFront returns the "X-Cache: Hit from CloudFront" response when requests are served from the edge cache.